ADT and event messaging
Admission, discharge and transfer (ADT) messages communicate changes in patient administration. A discharge event and a clinical discharge summary serve different purposes. The event can notify another system that an encounter has ended; the summary explains care, decisions and follow-up. 090, 018
This page uses HL7 v2.5.1 for concrete examples. It is a reference version, not a claim that every NHS or Defence interface uses that version. The deployed profile and interface agreement determine actual fields and behaviour. Public research has not established a Defence-wide ADT specification.
Trigger events
| Event | Meaning in the selected HL7 reference |
|---|---|
| A01 | Admission or visit notification |
| A02 | Patient transfer |
| A03 | Discharge or end of visit |
| A04 | Patient registration |
| A05 | Pre-admit a patient |
| A08 | Update of patient information |
| A11 / A12 / A13 | Cancellation of admission, transfer or discharge respectively |
| A28 / A31 | Add person/patient information / update person information |
| A40 | Merge of identifiers in the patient identifier list |
These events have distinct semantics. A40 must identify the surviving and prior identities; it is not an ordinary spelling correction. A04 registration must not be equated with registering with an NHS GP. 093
Fields and identifiers to inspect
| Reference field | Use |
|---|---|
MSH-9, MSH-10, MSH-12 |
Message type/trigger/structure, message identifier and HL7 version |
MSH-3–MSH-6 |
Sending and receiving application/facility |
MSH-15, MSH-16 |
Requested acknowledgement behaviour |
MSA-1, MSA-2 |
Response code and correlation to the incoming message identifier |
PID-3 |
Patient identifiers, with assigning-authority context |
PV1-2, PV1-3, PV1-19 |
Patient class, assigned location and visit identifier |
EVN-2, EVN-6 |
Recording time and event-occurrence time |
MRG-1 |
Prior patient identifiers for the relevant merge message |
The field references are version-specific. They do not constitute a complete required-field list or a conformant message. 093, 094
Acknowledgements are not clinical handovers
HL7 distinguishes original and enhanced acknowledgement modes. AA, AE and AR express application acceptance, error or rejection. Enhanced-mode CA, CE and CR concern commit acceptance, error or rejection. The agreed mode and profile determine which responses occur. MSA-2 correlates the response with the incoming MSH-10. 094
An application acknowledgement does not assert that a clinician reviewed a result or accepted care responsibility. COPPER TIGER should therefore track delivery, application processing and clinical work separately. The information-flow model explains the clinical distinction. 018, 021
Worked sequence: a corrected discharge
This fictional sequence illustrates a proposed receiving workflow. It is not a production payload or evidence of a Defence interface.
Source encounter: HOSPITAL-DEMO / VISIT-42
Patient identity: LOCAL-DEMO / PATIENT-17
10:00 A03 received, message DEMO-100: encounter reported ended
10:01 Application accepts DEMO-100
10:05 DEMO-100 is retried after a lost acknowledgement
10:08 A13 received, message DEMO-101: discharge cancelled
10:12 Clinical summary DOC-DEMO-8 arrives through a separate route
The proposed receiver records the duplicate without applying the event twice. It reconciles the cancellation against the same source encounter. The late document remains a clinical record of what was authored, but its relationship to the corrected encounter needs review. A document's arrival must not silently reapply the cancelled discharge.
The interface contract must decide which source is authoritative for encounter state, how conflicts are detected and who resolves them. It must also decide how an amended or withdrawn summary reaches its earlier recipients. Those are explicit design questions; the event codes alone do not answer them.
Documents, notifications and current state
FHIR R4 documents use a document Bundle with a Composition first. That Composition supplies clinical context and references supporting resources. An assembled document is immutable; a subsequently derived document needs a new Bundle.identifier. Changing only the resource's Bundle.id is not that requirement. This informs provenance and correction, but does not select R4 for an existing STU3 Transfer of Care route. 095
A notification may instead tell a recipient to retrieve a current record. NEMS publishes supported patient-related events to authorised subscribers; its API description uses STU3 and delivery through MESH. Current deprecation and retirement information is covered in exchange mechanisms. It is a separate national-service arrangement, not another name for all ADT messaging. 102, 103
Proposed reconciliation rules
| Failure or change | Question the interface contract must answer |
|---|---|
| Duplicate delivery | What identifies a repeat, for how long, and can it safely receive the earlier response? |
| Out-of-order events | Can source sequence or effective time establish order? When must processing wait for reconciliation? |
| Wrong or ambiguous patient | Is the message quarantined from clinical filing, and which team resolves the match? |
| Patient merge | Which identity survives, which source authorised it, and how are downstream links and later corrections handled? |
| Cancelled event | Which earlier event is reversed, and what clinical tasks or documents remain valid? |
| Sender or receiver outage | What is retained, retried and escalated? How are missed events compared with source state? |
| Conflicting clocks | Which timestamp represents clinical occurrence, recording, sending and receipt? How are time zones preserved? |
| Partial processing | Which changes were committed, what response is returned and what can safely be retried? |
These are proposed engineering requirements. They require a source-specific profile, representative messages and clinical-risk review before implementation. Published Defence inspection evidence does not establish those interface details; the Defence mechanism map states what is known.
The next specification should record the event catalogue, patient and encounter identity rules, acknowledgement mode, transport, correction semantics and recovery tests together. A list of event codes alone is insufficient.
Continue with governance and clinical responsibility to define who may access, disclose or act on the information. Technical delivery alone does not settle those decisions.