Skip to content

Starter Instruction

Copy this prompt into a new AI session when continuing the project.

Continue the source-linked MkDocs Material knowledge wiki for DMedC NHS App continuation and/or adoption and NHS App architecture.

Purpose and direction:
This wiki exists to inform DMedC / DPHC NHS App guidance as a whole. Do not list that guidance as a research priority; treat research priorities as evidence gaps, synthesis gaps, implementation gaps, and confidence limits that prevent reliable guidance. Every page should either support a guidance-relevant conclusion, supply source evidence, define the relevant architecture or operating model, or identify a boundary that prevents safe conclusions.

Knowledge-base architecture:
Maintain the wiki as a structured evidence-and-synthesis system, not a loose note set. Keep these roles distinct:
- Source Register: provenance and source inventory.
- Evidence Matrix: claim-level support, confidence, and limitations.
- Evidence Validation Queue: To Do, unresolved evidence gaps, blockers, assumptions, and boundaries.
- Research Log: Done, completed passes, findings, and decisions made.
- Synthesis Pages: human-readable conclusions and current working position.
- Architecture / Model Pages: system, process, policy, domain, or implementation structure.
- Glossary: maintained terms, acronyms, and definitions.
- LLM Wiki: maintenance rules, project conventions, starter instructions, and agent guidance.
- Generated indexes / Graphify views / tool outputs: navigation and discovery aids, not source truth.

Controlling synthesis:
Use `docs/knowledge-base/modules/guidance-decision-model.md` as the guidance-facing answer surface, `docs/knowledge-base/modules/registration-state-model.md` as the cohort/registration classifier, and `docs/knowledge-base/modules/nhs-app-adoption-implementation.md` as the phased implementation anchor. Every adjacent feature, source, architecture, implementation, CORTISONE, or InterSystems cross-deck update must be checked against those pages.

Adoption and implementation model:
Preserve the phases: initial provision; secondary healthcare (SHC) appointments; DMICP primary healthcare (PHC) appointment visibility; DMICP PHC appointment management; clinical correspondence; test results; later CORTISONE patient data. For DMICP PHC appointment visibility claims, require both the source feed contract and the NHS-facing display route. For DMICP PHC appointment management claims, require bidirectional write-back, slot/schedule state, conflict handling, patient/proxy permissions, audit, supplier/practice enablement, and completed NHS-facing route assurance; treat management as likely not available at this stage on current public evidence. Keep clinical correspondence evidence separate from test-result evidence because the source systems, release controls, and NHS App routes can differ. Open sources do not expose DMICP appointment capabilities, API contracts, integration patterns, or adaptation / evolution options.

Architecture and evidence rules:
Use `docs/knowledge-base/modules/architecture-index.md` for route taxonomy and sequence diagrams. Separate user-facing outcomes, source systems, integration routes, policy constraints, data dependencies, assurance requirements, and implementation status. Treat DPHC-registered patient NHS App availability as unresolved unless direct MOD, DMedC / DPHC, NHS, supplier, or operational implementation evidence supports the claim. Distinguish ordinary NHS GP, DPHC Firmbase, and DPHC Overseas [DPHC(O)] care models. Keep own access separate from proxy / linked-profile access. Do not treat dependant status as a standalone NHS App eligibility category. Separate GP-linked features, Interface Mechanism 1 / supplier pairing, Spine Directory Service endpoint lookup, Patient Care Aggregator / Wayfinder secondary-care referrals and bookings, Patient Engagement Portal (PEP) functions, NHS Notify messaging evidence, MESH/API routes, and partner-onboarding / assurance evidence. Keep route-family or component labels only where they change confidence, applicability, evidence required, assurance requirements, or guidance status; otherwise use wider provider-route, general PEP, or broader component wording.

Content and writing standard:
Use `docs/knowledge-base/modules/defence-digital-content-and-writing-standard.md` as the user-facing content contract. Apply the MOD Defence Service Manual requirement to use GOV.UK content principles and styles for internal digital services: necessary content, plain English, short sentences and paragraphs, active voice, clear unique page titles, ordered semantic headings, descriptive link text, consistent labels, first-use expansion of unfamiliar acronyms on every page, accessible images/diagrams, exact authoritative military terminology, and correct classification/marking controls. Apply these rules to pages being created or materially revised without causing unrelated whole-wiki wording churn. For the formal IRTB(P), current internal JSP 101, the approved template and issuing-authority instructions remain controlling where document conventions differ.

Evidence request pack discipline:
Use evidence request packs sparingly. They add value only where a live assurance, procurement, delivery, research, or implementation claim needs concrete evidence such as product/version, validation scope, exclusions, component coverage, adjacent standards, or deployment artefacts. Before adding any new page, checklist, request pack, or evidence-domain layer, run a stop/go check: does it reduce repeated traversal across module pages, source register, evidence matrix, and validation queue; does it turn an active assurance claim into a concrete evidence request; and would a link to an existing reusable pattern or a queue entry be enough? If not, do not create new structure. Keep the gap in the Evidence Validation Queue, link to the reusable pattern, and update the relevant synthesis or anchor page only where the current model changes.

CORTISONE and InterSystems:
Cross-read InterSystems sibling wiki material for Programme CORTISONE, HealthShare Unified Care Record, Health Connect / Integration Platform evidence, and EMPI, but use `docs/cross-deck-evidence-carry-over.md` before promoting claims. Keep cross-deck material as synthesis unless primary source IDs are carried over. Treat HealthShare Unified Care Record, Health Connect / Integration Platform, EMPI, IM1, and GP Connect Patient Facing APIs as evidence targets for later CORTISONE integration, not proof of NHS App feature availability.

Maintenance:
Use strict builds, source IDs, explicit uncertainty labels, DESIGN.md as the styling source of truth, `npm run kb:update` for generated wiki/Graphify artifacts, and browser-local revision tooling only when learning workflows are in scope. When durable knowledge changes, update all affected durable artifacts: synthesis page, Guidance Decision Model, Registration State Model, Architecture Index, Source Register, Source Freshness, Cross-Deck Evidence Carry-Over, Evidence Matrix, Evidence Work Packages, Evidence Validation Queue, Research Log, Glossary, LLM Wiki, and Project Status where applicable.

Response rule:
After every substantive response, include a What Next section with exactly three numbered, discrete, high-impact next steps. Treat What Next as whole-project-aware triage: check Project Status, Guidance Decision Model, NHS App Adoption and Implementation, Architecture Index, Evidence Validation Queue, Evidence Work Packages, Research Log, and the relevant adjacent source/evidence domain before choosing steps. Balance the steps as: one closure step for the current evidence or implementation gap, one anchor-model step for affected synthesis / decision / architecture / status pages, and one breadth step into an adjacent source/evidence domain. Run a cycle guard first: if the latest thread is already bounded, parked, or blocked pending direct evidence, do not keep deepening it unless new evidence, a source response, a scheduled recheck, or the user explicitly triggers that trail. Reassess the total KB gap landscape and rotate to the next decision-blocking gap. Continue one topic only where the next pass can close a concrete gap, change confidence, or update a controlling anchor. Each step must be actionable in one follow-up pass and tied to a wiki page or project artifact where possible. Include rendered wiki URLs for referenced or updated wiki pages using the local MkDocs server base `[local preview URL]`; do not substitute filesystem Markdown links for user-facing wiki links.