North West Genomic Medicine Service Alliance
0.0.1 - ci-build
DRAFT Implementation Guide
This is for collaboration and discussion purposes and is subject to change.
North West Genomic Medicine Service Alliance - Local Development build (v0.0.1) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions
The architecture generally follows Domain Driven Design [DDD], Domain Driven Design and Data Mesh
Data Mesh
The Intermediary, North West GMSA Regional Integration Engine (RIE) is an Enterprise Service Bus most commonly known in the NHS as a Trust Integration Engine (TIE).
This implement as series of Enterprise Integration Patterns based around messaging, the diagrams below follow conventions used for these patterns.
The ESB has a Canonical Data Model which is expressed in this Implementation Guide using HL7 FHIR. This model is common to all the exchange formats used in the ESB:
This canonical model is a mandatory extension to HL7 UK Core and includes requirements from
This canonical model is not specific to Genomics. It is focused on standard message construction patterns in particular CorrelationIdentifier such as Order Numbers and Episode/Stay Identifiers and use of Clinical Coding Systems such as UK SNOMED CT.
Genomic Specific modelling, which this model supports, can be found on NHS England FHIR Genomics Implementation Guide
To support genomics workflow, this guide is aligned to enterprise workflow processes described in IHE Laboratory Testing Workflow, terminology from this guide especially around Actors is used throughout this Implementation Guide.
Three types of messages are used within this workflow process:
Message Type | HL7 Name | IHE Name | Description |
---|---|---|---|
Command Message | Laboratory Order O21 | LAB-1 | To request a laboratory order |
Document Message | Laboratory Report R01 | LAB-3 | Used to transfer the report to interested parties |
Phase 1a ESB Architecture
Phase 1b
The use of a Polling Consumer is not optimal. This phase will send messages directly to Trust Integration Engines. As we are using http RESTful for communication between the Trust Integration Engines, this security and authorisation can be solved in a number of ways such as:
These are practical for point-to-point connections, but as the solution grows it can become complicated, so it is preferred we move to enterprise level security such as OAuth2 Client Credentials Grant.
See Authorisation for more details.
Phase 2a
Phase 2b