Defence record and exchange mechanisms
Public sources describe several Defence mechanisms: clinical records, registration services, referrals, secure email, specialist advice and record requests. They do not establish one universal NHS–Defence interface. This account uses public primary evidence checked on 16 October 2026. Undocumented mechanisms remain unknown.
The Defence context establishes the service setting and transition need. This page tests the proposed information flows against published mechanisms before the wiki turns to capabilities, assurance and procurement. An inspection establishes what was observed at a named service and date. It does not establish current deployment across the Defence estate.
What the public evidence establishes
| Mechanism | Evidence and date | What this establishes | What remains unknown |
|---|---|---|---|
| Defence Medical Information Capability Programme (DMICP) | MOD background quality report, 9 July 2026. 079 | An integrated primary Health Record supports clinical use; a separate pseudonymised warehouse supports analysis. Primary healthcare and some MOD specialist providers contribute records. | Complete system inventory, interfaces, permissions and current coverage by specialty. |
| Patient registration and demographic coordination | NHS England PCRM service page, 24 August 2026. 075 | Primary Care Registration Management includes DMS and coordinates registration with the Personal Demographics Service (PDS). | The implementation used by each Defence application. Registration does not establish clinical-record transfer. |
| External referral | NHS e-RS service page, 15 October 2026; CQC Stonehouse report, 25 February 2025. 071, 076 | NHS England lists DMS among e-RS users. At Stonehouse, most external referrals used e-RS; some used email. | Coverage for each specialty, overseas site and receiving provider; exact interfaces and fallback rules. |
| Internal referral and follow-up | CQC Stonehouse report, 25 February 2025. 076 | DMICP supported referral to the Primary Care Rehabilitation Facility, caseload management and clinical tasking. A centralised DPHC process supported referral tracking and transfer between practices. | Estate-wide rollout, message specification, and whether tracking updates are automatic or manual. |
| Diagnostic requests and results | CQC Marham report, 23 May 2025. 077 | Clinicians requested tests through DMICP; results returned through Path Links. A register and clinical tasks supported follow-up. | Wire format, transport, laboratory coverage, reconciliation rules and automated acknowledgements. |
| Secure clinical email | NHSmail guidance, 26 July 2022; secure email standard page, 9 October 2026. 085, 086 | Published guidance explicitly treats mod.gov.uk as secure for healthcare information sent from NHSmail to DPHC. |
Whether a particular mailbox is the correct, monitored clinical destination; whether a message was filed or acted on. |
| Deployed record and specialist advice | CQC Mount Pleasant report, 5 June 2025, following inspection on 7 May. 078 | DMICP(D), clinical tasking, verbal communication, specialist email and PANDO advice recorded in the patient record were described locally. | Current capability elsewhere, synchronisation behaviour and a uniform deployed interface specification. |
| Service-leaver record request | NHS service-leaver guide and DHSC answer, 19 January 2026. 009, 038 | An NHS GP can request the full Defence record; the FMed133A summary supports the request. | A universal automatic electronic transfer, its completeness, latency and reconciliation outcome. |
The Stonehouse and Marham statements above were checked against indexed passages from CQC's official reports. Direct PDF retrieval was blocked. Their source entries retain this limitation. Neither report is used as a complete technical specification. 076, 077
Separate the mechanisms before designing an interface
Registration, clinical records and activity are different objects
PCRM coordinates the patient's registered GP and demographic updates with PDS. GP2GP is a separate record-transfer service. DMS participation in registration infrastructure therefore does not prove that its entire clinical record moves through GP2GP. The published NHS registration guide makes these service boundaries explicit. 075, 006
For COPPER TIGER, specify these as distinct proposed information objects:
| Object | Question the design must answer |
|---|---|
| Patient identity | Which identifier and assigning organisation identify this person? How are duplicate or conflicting identities resolved? |
| GP registration | Which practice is registered, from when, and under which nation's process? |
| Clinical encounter | What care occurred, where, when, and under which treating service? |
| Correspondence | What report or request was authored, for whom, and with which clinical actions? |
| Record transfer | Which history and attachments moved, and what failed or required reconciliation? |
| Admission, discharge or transfer event | Which episode or location changed, and which systems need the event? |
These are design distinctions, not a claim that Defence publishes or exchanges all six objects. The reviewed sources do not establish a Defence-wide HL7 ADT feed, event catalogue or FHIR interface. They also do not identify every use of MESH, ITK or a shared-care viewer. Those interfaces remain unknown until public evidence identifies the sender, receiver, payload and implemented route.
Referrals require tracking as well as transmission
The Stonehouse account connects referral transmission with follow-up: staff reviewed a register, pursued outstanding referrals and sought outcome letters. That supports a workflow model with referral state and unresolved work, alongside the referral document itself. It does not establish the protocol used by the tracking process. 076
COPPER TIGER should therefore distinguish a referral being created, sent, received, triaged, accepted, booked and completed. A rejected, redirected or cancelled referral also needs an accountable next action. These are proposed modelling states. A local implementation must define which system records each state and which team acts on it.
Secure email protects transport; the care process still needs assurance
The NHSmail guidance identifies a secure transport relationship with the MOD domain for healthcare. It does not authorise every disclosure to every MOD employee. Apply the purpose and access analysis before selecting the recipient and information. 085, 012
DCB1596 covers secure email, including organisational procedures and service configuration. Its accreditation lasts one calendar year. Verify the applicable current service and local controls when implementing a route. A domain match alone does not demonstrate those controls for an arbitrary mailbox. 086
For an email-based correspondence route, the proposed design must identify the clinical mailbox owner, absence cover, patient matching, record filing and escalation. Transport delivery, record ingestion and clinical action are separate outcomes. Urgent care needs an agreed escalation route rather than reliance on an unattended inbox. This is a workflow requirement derived from the correspondence and responsibility distinction, not evidence of one existing MOD process.
Deployed care needs explicit record reconciliation
At Mount Pleasant, CQC reported reduced DMICP(D) functionality and difficulties transferring live data to the deployed system. It also described recording specialist advice back into patient notes. This is bounded evidence of a local continuity problem and a local documentation process. It does not prove that every deployed setting has the same infrastructure. 078
At Marham, a business-continuity process used paper during outages and later uploaded documentation to DMICP. This shows why restoration needs a clinical reconciliation process, as well as restored connectivity. 077
The proposed design should preserve the original author, care time, later entry time and source document. It must expose duplicate entries, conflicting updates and unresolved tasks for review. These are proposed requirements. Public evidence reviewed here does not establish a Defence-wide offline synchronisation or conflict-resolution algorithm.
Defence documents and terminology
| Term or document | Meaning in this account | Boundary |
|---|---|---|
| DMS | Defence Medical Services. | Expand the acronym on first use; it can mean different things in other NHS technical contexts. |
| DPHC | Defence Primary Healthcare. | A clinical service context; MOD is the controller identified in its privacy notice. 012 |
| FMed133A | Medical summary supplied to a service leaver. | It helps the receiving GP request the military record; it is not that complete record. 009 |
| FMed23 | Record of medical board proceedings. | Medical discharge here concerns leaving service, not discharge from a hospital episode. The MOD report describes statistical use as secondary to administering the individual's discharge. 079 |
| JPA | Joint Personnel Administration system. | It supports pay, leave and personnel administration. It is not the clinical primary record. 079 |
| Clinical task | An assigned item of work within a clinical process. | Observed DMICP tasking does not establish a standard message type or transfer clinical responsibility automatically. 076 |
The report maps Read-coded data to ICD-10 for medical-discharge statistics. This does not establish the terminology used by every Defence interface. 079
Announced change and existing capability
Keep observed or described service, announced change and proposed architecture separate. The dated examples above identify specific settings; announcements do not prove delivered interfaces, migration completeness or operational readiness. The Medical Operating Concept is forward direction, not delivery evidence. 039
The historical owner qualification cannot establish the current public-source baseline. The programme definition remains supplier agnostic and future-looking. Evaluate existing commitments without treating them as fixed architectural decisions.
Relevant differences across the four nations
England is the reference baseline. Cross-border care still needs the actual receiving nation's identifiers, referral process and document route.
| Nation | Publicly documented distinction | Implication for COPPER TIGER |
|---|---|---|
| England | PCRM and PDS coordinate GP registration; e-RS supports referral workflows and explicitly includes DMS users. 075, 071 | Identify the particular receiving service and integration. National service availability does not establish local Defence implementation. |
| Scotland | The national access policy specifies the Community Health Index (CHI) identifier where available, Armed Forces/veteran status where applicable, and continuity of pathway position when Armed Forces patients move. NHS Education for Scotland describes clinical images attached to SCI Gateway referrals. 081, 084 | Preserve identifier authority, referral attachments and pathway position. Do not assume an England e-RS workflow applies. |
| Wales | DHCW describes the Welsh Clinical Communications Gateway for GP-to-hospital referrals and GP2GP between Welsh practices. Medicines Transcribing and E-discharge (MTeD), within the Welsh Clinical Portal, supports hospital summaries sent to GPs. 082, 080 | Distinguish Welsh record-transfer and correspondence routes from the England service descriptions. Neither page proves a Defence endpoint. |
| Northern Ireland | The Department of Health reported completion of encompass rollout across the five HSC Trusts on 8 May 2025. 083 | Treat the trust record platform as a separate integration context. That announcement does not prove Defence access or universal GP-record ingestion. |
These differences are a technical scope map. The legal framework separately addresses territorial extent, service duties and confidentiality rules. A shared UK data-protection framework does not make all NHS contracts, statutory duties or technical services UK-wide.
Public evidence questions that develop the concept
These questions broaden the reference model. They do not request confidential operational details or assume an undocumented capability exists.
| Research question | Evidence needed to answer it |
|---|---|
| How do GP, community and hospital source accounts contribute relevant information to the primary record of care (PRC), and how is each source account retained? | Published record policy, service descriptions and information standards with a defined clinical scope; distinguish record roles from applications. |
| Which Defence services send each correspondence type, and how do replies reach the responsible team? | Public service guidance or inspection findings identifying sender, recipient, route and follow-up. |
| Which patient and organisation identifiers are used at each NHS–Defence boundary? | Published identifier standards and implementation guidance; explicit rules for cross-border matching. |
| Which event notifications are exchanged, including admissions, discharges, transfers, corrections and cancellations? | A public implementation specification with event semantics, version, endpoint roles and acknowledgements. |
| Where are receipt, record filing and completion of clinical action separately recorded? | Public workflow or safety documentation that identifies each outcome and failure response. |
| How are specialist, occupational and employer-directed communications separated? | Public policy specifying purpose, information content, authorised recipients and disclosure conditions. |
| What persists when a patient changes military centre, enters deployed care or returns to civilian care? | Public continuity guidance covering open referrals, pending results, medicines, documents and record reconciliation. |
| What has actually changed under an announced modernisation programme? | Dated public service-release, implementation or assurance evidence; a procurement announcement alone is insufficient. |
Until that evidence is available, COPPER TIGER can define requirements and interface examples. It must label them as proposals rather than describe them as Defence's implemented design.
These evidence gaps inform the evolving discovery register. Continue with DSIC capabilities and assurance to examine how candidate products are described and assessed.