NHS North West Genomics - Local Development build (v2.2.0) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions

Use Case: iGene Orders and Reports (Alder Hey, MFT, Liverpool)

iGene Orders and Reports: how Alder Hey, Manchester Foundation Trust (MFT) and Liverpool Women's send genomic test orders directly to NW Genomics, and receive reports back, via the Regional Integration Engine (RIE).

References

1. Regional Integration Engine (RIE) - the message-processing and routing infrastructure this use case relies on
2. Genomic Test Order
3. Ask At Order Entry Questions
4. LTW - Laboratory Order (LAB-1) / Laboratory Report (LAB-3)
5. Diagnostic Model Overview

Clinical Pathway Overview

What is being tested

This page isn't about one specific clinical test - it's about how three NHS Trusts (Alder Hey, MFT and Liverpool Women's), plus Clatterbridge for immunology, place genomic and immunology test orders directly with NW Genomics and receive reports back, rather than via a national order comms system. The underlying tests are whatever each Trust's clinicians order from the NW Genomics test directory.

The end-to-end clinical journey

1. Order placed at the Trust - a clinician at Alder Hey, MFT or Liverpool Women's orders a genomic test (or, for Clatterbridge, a genomic or immunology test) using the Trust's EPR.
2. Order reaches NW Genomics - the order is exported from the Trust's EPR and reaches NW Genomics via the Trust's own Trust Integration Engine (TIE) and the RIE, arriving at the destination LIMS (currently iGene).
3. Testing performed - NW Genomics carries out the requested test.
4. Report compiled and returned - a report is produced and routed back to the ordering Trust via the RIE, so it reaches the same EPR the order came from.
5. Clinical decision - the ordering clinician acts on the result.

flowchart LR
    A[Clinician at Trust<br/>orders test] --> B[Order reaches<br/>NW Genomics via RIE]
    B --> C[Testing<br/>performed]
    C --> D[Report<br/>compiled]
    D --> E[Report returned<br/>to Trust via RIE]
    E --> F[Clinical decision]

Why this matters for developers

• This use case describes the NHS Trust side of the relationship: which Trusts integrate directly, what they send, and how their TIE converts to the NW Standard before the order ever reaches the RIE.
• For what happens once the order or report is with the RIE (validation, enrichment, LIMS routing, shared care record wire-tap), see Regional Integration Engine (RIE) - Current Process - this use case does not repeat that detail.
• iGene is the Order Filler for these Trusts today, but not necessarily the system that performs every test: iGene may sub-contract work out to other labs (see Regional Integration Engine (RIE) - Sub-Contracted and Reflex Orders), and the RIE may in future route some orders directly to StarLIMS instead of iGene - StarLIMS was the main LIMS for the Liverpool GLH, and iGene the main LIMS for the Manchester GLH, before the two merged into a single North West Genomics service. See StarLIMS / iGene Integration for that routing.

Actors

Transactions

Current Process

Alder Hey, MFT and Liverpool Women's each send genomic orders directly to NW Genomics and receive reports back, rather than via a national order comms system - Clatterbridge does the same for immunology test requests, and additionally receives combined genomic and immunology reports.

Order Process

Each Trust exports its order from its EPR to its own Trust Integration Engine (TIE) as a local HL7 v2 ORM_O01 - see Regional Integration Engine (RIE) - Order Process for what happens from here onwards. How each Trust converts that local ORM_O01 into the NW Standard before sending it to the RIE differs. The RIE then forwards the order to the destination LIMS (iGene) as a V2 order:

• Alder Hey and Liverpool Women's - the EPR is Meditech; the TIE sends the order to a Docker service (built using Apache Camel and HAPI FHIR) which converts the local ORM_O01 into a FHIR Message O21 (NW Standard).
• Manchester Foundation Trust (MFT) - the conversion from local ORM_O01 to the NW HL7 Standard happens within the MFT TIE itself.

flowchart LR
    subgraph AH["Alder Hey / Liverpool Women's"]
        EPR1["EPR (Meditech)"] --> TIE1[TIE] --> Conv["Docker service<br/>(Apache Camel + HAPI FHIR)"]
    end
    subgraph MFT["Manchester Foundation Trust (MFT)"]
        EPR2["EPR (EPIC, HODS)"] --> TIE2["TIE<br/>(converts internally)"]
    end
    Conv -- "FHIR Message O21<br/>(NW Standard)" --> RIE
    TIE2 -- "NW HL7 Standard<br/>ORM_O01" --> RIE

    subgraph LIMS["Internal LIMS Systems"]
        L1[LIMS iGene<br/>HL7 flavour A]
    end

    subgraph RIE["NW Genomics Regional Integration Engine"]
        direction TB
        T[Message Distribution and Transform to<br/>individual LIMS HL7]
    end
    RIE -- "Orders V2" --> L1

Report Process and Technical Diagram

Reports flow back from the RIE to each Trust as ORU_R01, NW Standard - see Regional Integration Engine (RIE) - Report Process for the RIE-side detail (LIMS conversion, PDS/ODT validation and enrichment, ODS-code routing). The diagram below shows the four Trusts covered by this use case alongside the RIE and its internal LIMS - for each Trust the report flows from the RIE to the Trust's TIE and on to the Trust's EPR.

flowchart LR
    subgraph LIMS["Internal LIMS Systems"]
        L1[LIMS iGene<br/>HL7 flavour A]
    end

    subgraph RIE["NW Genomics Regional Integration Engine"]
        direction TB
        T[Message Distribution and Transform to<br/>standardised HL7]
    end

    subgraph TR1G["Manchester Foundation Trust (MFT)"]
        TIE1[TIE] --> EPR1["EPR (EPIC and HODS)"]
    end
    subgraph TR2G["Alder Hey"]
        TIE2[TIE] --> EPR2["EPR (Meditech)"]
    end
    subgraph TR3G["Liverpool Women's"]
        TIE3[TIE] --> EPR3["EPR (Meditech)"]
    end
    subgraph TR4G["Clatterbridge<br/>Immunology test requests +<br/>Genomic and Immunology reports"]
        TIE4[TIE] --> EPR4["EPR (Meditech)"]
    end

    L1 -- Reports V2 --> RIE
    RIE -- "NW Diagnostic Core Standard reports (ORU_R01)<br/>Genomics and Haemato-Oncology" --> TIE1
    RIE -- "NW Diagnostic Core Standard reports (ORU_R01) Genomics" --> TIE2
    RIE -- "NW Diagnostic Core Standard reports (ORU_R01) Genomics" --> TIE3
    RIE -- "NW Diagnostic Core Standard reports (ORU_R01)<br/>Genomics and Immunology" --> TIE4

Future Process

No Trust-specific future-state changes are planned beyond those already described for the RIE as a whole - see Regional Integration Engine (RIE) - Future Process, which covers potential interfacing with National Genomic Order Comms systems.

Data Models

This use case uses the same Diagnostic Core and Genomic Model (Placer Order LAB-1 / Reports LAB-3) data models as the RIE generally - see Regional Integration Engine (RIE) - Data Models for the full detail, including the Account Number, Placer Order Number, NHS Number and Requested Procedure Code identifiers these Trusts' orders and reports carry.

• ServiceRequest - the Laboratory Order, carried in the FHIR Message O21
• DiagnosticReport - the Laboratory Report, carried in the FHIR Message R01
• Message Exchange [MQ] - the FHIR Messaging pattern both O21 and R01 use

These two Questionnaires are the actual LAB-1 data model for this use case, in both HL7 v2 (ORM_O01/NW Standard) and FHIR (Message O21) form - Genomic Test Order for the common core order fields, NW Genomic General Test Order for the default Ask At Order Entry questions (Consent, infection risk, pregnancy/neonatal, etc.) these four Trusts use. This is what Alder Hey, MFT, Liverpool Women's and Clatterbridge's own EPR/TIE actually sends, described in Order Process above.

The Laboratory Order O21 Mapping table below is a different thing, despite the name and heavy field overlap: it's the shape of iGene Laboratory Order Export, which documents LAB-2 - iGene's own daily CSV re-export of an order after it has been received (via LAB-1) or manually entered, not the LAB-1 message itself. It's reproduced here (for IG purposes, so this use case has its own worked mapping, rather than only a link that may drift from NEYManagementInformation.html over time) because most of its fields still apply once an order from these Trusts reaches iGene. There's an open TODO to look at whether the LAB-1 model (GenomicTestOrder/GenomicGeneralAskAtOrderEntry) and this LAB-2 model (iGeneLaboratoryOrderExport/iGeneWorkOrderExport) should eventually be merged into one - not attempted here, since the two currently serve different stages of the same order's journey.

Laboratory Order O21 Mapping

Laboratory Report R01 Mapping

Same underlying model as Laboratory Order O21 Mapping above, with one addition: unlike NE&Y's management-information copy (which strips the clinical PDF), the Laboratory Report these Trusts receive carries the full Narrative Report.

See ctDNA Management Information - Laboratory Report R01 Mapping for the open questions the worked ctDNA example surfaces against this same model (identifier ambiguity between FillerOrderNumber/TestAccessionIdentifier/ ReportIdentifier, and Specimen not currently being included in the R01 Bundle) - not repeated here since they aren't specific to this use case.

Outstanding Issues

HODS-originated orders from MFT use PV1-3/PV1-4 non-standardly. MFT sends orders from both EPIC and HODS through the same TIE (see Actors above) - but HODS orders carry a site code in PV1-3 and a HODS Order Placer Number in PV1-4, rather than either field's usual meaning. This IG's own PV1 definition models PV1-3 as Assigned Patient Location (the ward/clinic/bed the patient is assigned to, which can include a facility component) - a site code isn't necessarily inconsistent with that, but isn't confirmed either. PV1-4 isn't modelled by this IG at all, and standard HL7 v2.5.1 defines it as Admission Type, not an order identifier - HODS appears to be repurposing it to carry an order-level identifier on what is otherwise a visit/admission segment. Not yet resolved:

• Whether the RIE/conversion pipeline that turns MFT's local ORM_O01 into the NW Standard (see Order Process above) currently reads PV1-4 for HODS orders, or only looks at the usual ORC/OBR placer-order fields.
• Whether the HODS Order Placer Number in PV1-4 should map onto ServiceRequest.identifier (OrderIdentifier, type=PLAC) the same way PlacerOrderNumber does elsewhere in this use case's Laboratory Order O21 Mapping above, or whether it represents a distinct identifier from a standard Placer Order Number.

Examples

FHIR examples for the Laboratory Order (LAB-1) and Laboratory Report (LAB-3) interactions described above:

• ​Example: Laboratory Order - LAB-1 examples in FHIR format
• ​Example: Laboratory Report - LAB-3 examples in FHIR format

Security Considerations

Includes:

• OAuth2 Standard for Authorisation
  • including use of JWT access tokens and future support for SMART-on-FHIR Scopes
• FHIR AuditEvent/IHE BALP for Audit Logging
• TLS for Transport Security/Encryption

Developer Guides

• 03 - Orders: Building a FHIR Order Message from a CSV - builds a laboratory-order Bundle following the laboratory-order MessageDefinition
• 04 - Reports: HL7 v2 ORU^R01 into FHIR - converts a lab's own HL7 v2 report into a FHIR R01 Message
• 10 - Histocompatibility and Immunogenetics: HL7 v2 to and from the NW Standard - hand-builds the field-level conversion a Trust Integration Engine (TIE) does between its own Trust's local HL7 v2 flavour and the shared NW HL7 v2 standard

See Developer Guides for the full notebook series.