North West Genomic Medicine Service Alliance
0.0.1 - ci-build United Kingdom flag

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

Architecture

Introduction

The architecture generally follows Domain Driven Design [DDD], Domain Driven Design and Data Mesh

Data Mesh

Data Mesh


Enterprise Integration

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 Laboratory Order

Phase 1a

Phase 1a ESB Architecture


  • Accept Message The Order Placer (NHS trust) sends a FHIR Message (NW GMSA) Genomic Test Order O21 to the RIE via the $process-message endpoint
    • If the RIE doesn’t understand the message for technical reasons, it will respond immediately with an error message.
    • Validation The RIE performs FHIR Validation on the order against the requirements listed in this Implementation Guide. The validation contains no errors, it is accepted; any errors will cause the message to be rejected. The RIE responds to the order placer asynchronously via a message queue, this is accessed by the order placer via a Polling Consumer
  • Distribution List If the message is accepted, it is passed to a router, at present this router passes the message onto the next process. This router is for future use with the national broker.
  • Transform to HL7 v2 The RIE will convert the FHIR Message to a HL7 v 2.4 ORM O01 and send this to iGene.

Phase 1b Laboratory Order + OAuth2 Server

Phase 1b

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:

  • TLA-MA
  • openid

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 Laboratory Report - Greater Manchester Care Record

Phase 2a

Phase 2a


  • IGene sends the HL7 v2 ORU_R01 to RIE
  • GLH RIE sends the message onwards to MFT TIE
  • MFT TIE sends the message to GMCR

Phase 2b Laboratory Report - FHIR Repository

Phase 2b

Phase 2b


  • IGene sends the HL7 v2 ORU_R01 to RIE
  • Dynamic Router The RIE distributes the message to the recipients. The routing rules are held within Dynamic Rules Base, this is likely to be FHIR Subscription-based and held within the FHIR Repository.
  • The two recipients at this phase are the MFT TIE as per phase 1 and FHIR Repository. The FHIR Repository processing is:
    • ** Transform to HL7 FHIR Message** Convert the HL7 v2 ORU to HL7 FHIR Message ORU
    • ** Process the FHIR Message via FHIR Repository Adaptor, which applies business logic to the incoming message and updates the Clinical Data Repository (Genomics)