NHS North West Genomics
2.1.4 - ci-build
NHS North West Genomics
2.1.4 - ci-build
NHS North West Genomics - Local Development build (v2.1.4) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
graph TD;
DocumentMessaging["<b>Document Messaging</b><br/><b>Laboratory Testing Workflow (LTW)</b><br/><br/>e.g. V2 Messaging (ORU_R01, MDM_T02, ORM_O01, OML_O21, etc) and FHIR Messaging/Transactions"]
DocumentSharing["<b>Document Sharing/<br/>EURIDICE Document Exchange</b><br/><br/>e.g. IHE XDS (SOAP API), IHE MHD and NHSE NRL (FHIR RESTful Query API) "]
DocumentEventNotifications[<b>Document Event Notifications</b><br/><br/>e.g. NHSE MNS and IHE DSUBm]
ClinicalDocumentArchitecture[<b>Clinical Document Architecture</b><br/><br/>e.g. CDA, FHIR Document<br/>EU Laboratory Report<br/>International Patient Summary]
DocumentWorkflow[<b>Document Workflow</b><br/><br/>e.g. IHE XDW]
DataSharig["<b>Data/Resource Sharing<br/>EURIDICE Resource Exchange</b><br/><br/> HL7 IPA/IHE QEDm, NHS England Care Connect API (FHIR RESTful Query API)"]
ResourceEventNotifications[<b>Resource Event Notifications</b><br/><br/>e.g. FHIR Subscription and NHSE MNS]
ConversationalMessaging[<b>Conversational Workflow</b><br/><b>Cross Organisation Task based Workflow</b><br/><br/>e.g. FHIR Workflow, NHSE Electroinc Prescription Service and Genomic Order Management System]
DocumentMessaging --> DocumentSharing
DocumentSharing --> DocumentEventNotifications
DocumentSharing --> ClinicalDocumentArchitecture
DocumentEventNotifications --> DocumentWorkflow
ClinicalDocumentArchitecture --> DocumentWorkflow
DocumentMessaging --> DataSharig
DataSharig --> ResourceEventNotifications
ResourceEventNotifications --> ConversationalMessaging
DocumentWorkflow --> ConversationalMessaging
DocumentSharing --> |expands to| DataSharig
DocumentEventNotifications --> ResourceEventNotifications
classDef green fill:#D5E8D4;
class DocumentMessaging,DocumentSharing,DataSharig green
This diagram provides a high-level view of enterprise interoperability across the NHS. Most NHS Trusts have implemented some form of Document Messaging, typically through HL7 v2 messaging and, increasingly, FHIR-based transactions.
Many Shared Care Record providers (including the former LHCREs) have also established Document Sharing capabilities. Examples include One London, Lancashire & South Cumbria, and Cheshire & Merseyside, enabling clinical documents to be exchanged and consumed across organisational boundaries.
Several regions have progressed further by implementing Data/Resource Sharing in addition to document sharing. Examples include the Yorkshire & Humber Care Record, SiDER, and the Great North Care Record. These initiatives support the exchange of structured clinical data through APIs and shared resource models, moving beyond traditional document-centric interoperability.
Collectively, these Shared Care Record platforms are likely to form a significant foundation for the emerging Single Patient Record (SPR) landscape.
As a newly established diagnostic organisation (April 2026), we have already implemented all three interoperability layers—Document Messaging, Document Sharing, and Data/Resource Sharing—building upon capabilities developed prior to our formal establishment.
Our strategic ambition is to progress towards Conversational Messaging, which aligns with the direction being taken by national diagnostic services such as the Genomic Order Management Service (GOMS). Conversational Messaging supports structured request-response interactions between systems that mirror real-world business processes (for example, "Can you fulfil this request?" followed by an acceptance, rejection, or request for further information), enabling more dynamic and workflow-oriented interoperability.
Realising this model depends on widespread adoption of Data/Resource Sharing through capabilities such as the Single Patient Record (SPR) and FHIR APIs, together with national eventing services such as the NHS Multicast Notification Service (MNS). Without these foundations, organisations typically revert to point-to-point HL7 v2 messaging or FHIR transaction and bundle patterns, which are less effective for coordinating complex, multi-organisational workflows.
Importantly, both Document Messaging and Conversational Messaging are likely to play a role in addressing the "write-back" challenge frequently discussed in relation to SPR. Document Messaging provides a proven mechanism for distributing updates to consuming systems, whilst Conversational Messaging offers a more sophisticated approach for coordinating actions, acknowledgements, and workflow state changes across organisational boundaries.
Genomic Enterprise Integration
This basic patten is the exchange of records via Document Messaging and is supported by a wide area of Messaging Patterns In NHS Trusts this is often supported by a Trust Integration Engine. This is the default option for HL7 v2 and in FHIR this is known as FHIR Messaging
graph LR;
s[Data Source]
d[Data Consumer]
s --> |v2 Message<br/>FHIR Message<br/>FHIR Transaction| d
The messages exchange all the data in one interaction, for example, a Laboratory Report could consist of
classDiagram
class Bundle["Bundle (message) - Document Message (FHIR Message)" ] {
MessageHeader
DiagnosticReport
Patient
Specimen
Observeration
PractitionerRole
}
class Bundle2["Bundle (transaction - Document Message (FHIR Transaction)" ] {
DiagnosticReport
Patient
Specimen
Observeration
PractitionerRole
}
Note: FHIR Transaction is considered an antipattern for loosely coupled systems in an enterprise environment.
Is based on Document Messaging and two flows are combined to create a workflow e.g. IHE Laboratory Testing Workflow (LTW)
graph LR;
subgraph s[Order Placer];
EPR
end
subgraph d[Order Filler];
LIMS
end
EPR --> |LAB-1 Laboratory Order OML_O21/ORM_O01| LIMS
LIMS --> |LAB-3 Laboratory Report ORU_R01| EPR
Document Messaging's main limitation is it is between two parties; often in health care many other practitioners are involved. Messaging can be used to solve this, but it begins to have scaling and data concurrency issues. In FHIR these API's are known as FHIR RESTful and FHIR Search
graph LR;
s[Document Consumer]
d[Document Registry & Repository]
s --> |Query API<br/>XDS API<br/>FHIR RESTful| d
See also Health Information Exchange - Document Exchange
graph LR;
s[Document Consumer]
subgraph d[Document Registry & Repository];
Registry
Repository
end
s --> |Find Document References ITI-67 FHIR RESTful<br/>Registry Stored Query ITI-18| Registry
s --> |Retrieve Document ITI-68<br/>Retrieve Document Set ITI-41| Repository
See NHS England National Record Locator
Electronic Document Management (EDM) is a common practice for storing and sharing documents across healthcare systems and common formats for the documents are often PDF. In diagnostics this is not desirable and so instead a document format called Clinical Document Architecture (CDA), in HL7 FHIR this is known as FHIR Document
This is described in [IHE https://wiki.ihe.net/index.php/Sharing_Laboratory_Reports](https://wiki.ihe.net/index.php/Sharing_Laboratory_Reports HL7 Europe Laboratory Report, NHS England Pathology is a based on this but it using Document Messaging, the EU is likely to use Document Sharing.
FHIR Document replaces HL7 CDA and unstructed documents such as PDF. The FHIR Document is a FHIR resource that is a container for the document content.
For example, for a Lab Report the content may contain:
classDiagram
class Bundle3["Bundle (document) - FHIR Document" ] {
Composition
DiagnosticReport
Patient
Specimen
Observeration
PractitionerRole
Practitioner
Organization
}
The FHIR Document can also be treated as a HTML document, for example, see Bundle 'document' - Genomic Report. Additional (laboratory) examples can be found on HL7 Europe Laboratory Report
Genomic Report FHIR Document rendered as HTML
Prerequisite is Document Sharing
graph LR;
Publisher[Document Notification Publisher]
Broker[Document Notification Broker]
Subscriber[Document Notification Subscriber]
Recipient[Document Notification Recipient]
Publisher --> |Event Publish| Broker
Subscriber --> |Event Subscription| Broker
Broker --> |Event Notify| Recipient
The majority of the data is obtained via Document Sharing, only an event notification is sent to the recipient. For example for Laboratory Reports the payloads can be:
classDiagram
class Bundle1["Bundle (message) - Pointer Event Message" ] {
MessageHeader - points to DocumentReference
}
class Bundle2["Bundle (history) - Pointer Event Message via MNS" ] {
SubscriptionTopic - points to DocumentReference
}
class Bundle3["Bundle (message) - Resource Event Message" ] {
MessageHeader
SubscriptionTopic - optional
DocumentReference
}
Process Flow
sequenceDiagram
participant OrderPlacer as Document Notification Publisher
participant DocumentExchange as Document Exchange
participant OrderFiller as Document Notification Recipient
OrderPlacer ->> DocumentExchange: Share document via Document Exchange
note over OrderPlacer,OrderFiller: Document Event Notification
OrderPlacer ->> OrderFiller: Document Notification
OrderFiller ->> DocumentExchange: Retrieve Document via Document Exchange
See NHS England Multicast Notification Service API
See IHE Document Subscription for Mobile (DSUBm)
See Cross-Enterprise Document Workflow Content Profile (XDW)
Can be considered an extension of Document Sharing where the data contained in the documents is queryable. This data is known as Resources and is related to Segments used in HL7 v2 Messaging.
This is the most common use of HL7 FHIR. In FHIR these API's are known as FHIR RESTful and FHIR Search
graph LR
provider[Resource Access Provider<br/><br/>Genomic Data Platform]
consumer[Resource/Data Consumer]
consumer --> |Request Resources| provider
provider --> |Respond| consumer
See also Health Information Exchange - Resource Exchange
Prerequisite is Data Sharing.
graph LR;
Publisher[Resource Notification Publisher]
Broker[Resource Notification Broker]
Subscriber[Resource Notification Subscriber]
Recipient[Resource Notification Recipient]
Publisher --> |Event Publish| Broker
Subscriber --> |Event Subscription| Broker
Broker --> |Event Notify| Recipient
The majority of the data is obtained via Data Sharing, only an event notification is sent to the recipient. For example for Laboratory Reports the payloads can be:
classDiagram
class Bundle1["Bundle (message) - Pointer Event Message" ] {
MessageHeader - points to Resource e.g. DiagnosticReport
}
class Bundle2["Bundle (history) - Pointer Event Message via MNS" ] {
SubscriptionTopic - points to Resource e.g. DiagnosticReport
}
class Bundle3["Bundle (message) - Resource Event Message" ] {
MessageHeader
SubscriptionTopic - optional
Resource e.g. DiagnosticReport
}
As only the event resource is sent, other resources can be retrieved via Data Sharing.
sequenceDiagram
participant OrderPlacer
participant OrderFiller
note over OrderPlacer,OrderFiller: LAB-1 Laboratory Order
OrderPlacer -->> OrderPlacer: Share Laboratory Order via Resource Access Provider
OrderPlacer -->> OrderFiller: Resource Event Notification
OrderFiller -->> OrderPlacer: Retrieve Resources
note over OrderPlacer,OrderFiller: LAB-3 Laboratory Report
OrderFiller -->> OrderFiller: Perform Test and share Laboratory Report via Resource Access Provider
OrderFiller -->> OrderPlacer: Event Notification
OrderPlacer -->> OrderFiller: Retrieve Resources
See Conversation Patterns For a FHIR implementation see FHIR Worfklow
This is a replacement for Document Messaging (i.e. HL7 v2, FHIR Messaging and FHIR Transaction)
Prerequisite is Data Sharing and Resource Event Notifications, polling can be used as an interim measure if event notification infrastructure is not available.
sequenceDiagram
participant OrderPlacer
participant OrderFiller
note over OrderPlacer,OrderFiller: LAB-1 Laboratory Order
OrderPlacer -->> OrderPlacer: Share Laboratory Order via Resource Access Provider
OrderPlacer -->> OrderFiller: Task Event Notification (Task status = requested)
OrderFiller -->> OrderPlacer: Retrieve Laboratory Order
alt accepted
OrderFiller -->> OrderPlacer: Task Event Notification (Task status = accepted)
note over OrderPlacer,OrderFiller: LAB-3 Laboratory Report
OrderFiller -->> OrderFiller: Perform Test and share Laboratory Report via Resource Access Provider
OrderFiller -->> OrderPlacer: Task Event Notification (Task status = completed)
OrderPlacer -->> OrderFiller: Retrieve Laboratory Order
else rejected
OrderFiller -->> OrderPlacer: Task Event Notification (Task status = rejected)
else other
alt Exception Order Filler initiated
OrderFiller -->> OrderPlacer: Task Event Notification (Task status = rejected/cancelled)
else Exception Order Placer initiated
OrderPlacer -->> OrderFiller: Task Event Notification (Task status = rejected/cancelled)
end
end
The payload example:
classDiagram
class Bundle3["Bundle (message) - Resource Event Message (FHIR Workflow)" ] {
MessageHeader
SubscriptionTopic - optional
Task
}
See NHS England Genomic Order Management System
See AU eRequesting Implementation Guide
See NHS England Electronic Prescription Service - Dispensing