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

Data Contracts and Issue Reporting

This implementation guide primarily focuses on the Diagnostic Workflow and how it integrates within the broader health data model, as illustrated in the diagram above.

• Patient Care and Patient Administration are typically found in NHS providers Electronic Patient Record systems
• Care Directory Service on the other hand, are centrally defined by NHS England, with supporting APIs also provided by NHS England (for example, the ODS API).

In software design, these areas are often referred to as domains. The Genomic Diagnostic Workflow operates across several of these domains — in software architecture terms, this is known as a bounded context.

Archetypes, Entities, and Events

This guide uses the following concepts:

• Health Informatics Archetype, this is model associated with messaging.
• Entities such as HL7 v2 segments and FHIR resources.
• Events such as HL7 v2 ADT and SET event feeds.

To align these perspectives, this guide defines the following relationship:

---
title: Archetype, Entities and Events
---
erDiagram 
    Archetype ||--|{ Entity : hasMany
    Archetype }|--|| Event : hasMany
    Event ||--|| Entity : oftenOne2One

The Archetype follows the Domain Archetype concept from Data Mesh principles and serves as a bridge between data architecture and software engineering.

• Domain Archetype may encompass multiple Entities and Events.
• Entities and a Events can have the same content and may be used interchangeably.

This domain focuses on genomic and molecular diagnostics, and the main Archetypes are:

• Genomic Test Order
• Genomic Test Report – Summarizes genomic testing results.
  • Variant – Represents a specific genetic variant or mutation.
  • Diagnostic Implication – Links variants to clinical significance (e.g., pathogenicity, treatment implications).

Data Contracts

Data contracts govern all interactions defined within this implementation guide and apply to all entities, messages (archetypes), and events. They are primarily specified using HL7 FHIR; where appropriate, mappings to HL7 v2 and IHE XDS are also provided.

graph TD
    EHR[EPR] <--> |HL7 v2<br/>Orders & Reports| RIE
    LIMS[LIMS] <--> |HL7 v2<br/>Orders & Reports| RIE

    subgraph HIE["Health Information Exchange"]
        RIE[Regional Integration Engine] --> |Store<br/>HL7 FHIR| CDR[Genomic Data Repository]
    end
    Clinician[Data Sharing<br/>Clinical Apps<br/>Single Patient Record] --> |Read<br/>HL7 FHIR| CDR
    AI[Operational AI] --> |Read<br/>HL7 FHIR| CDR
    Ops["Operations Monitoring (Real Time Analytics)"] --> |Read<br/>HL7 FHIR| CDR

    CDR --> OLAP[Data Warehouse]
    A[Analytics and AI] --> OLAP
    OLAP --> FDP[Federated Data Platform]
    A --> FDP

    classDef green fill:#D5E8D4;

    class FDP,OLAP,CDR,LIMS,EHR green

The diagram above illustrates the scope of the data contracts covered by this guide. Specifically, it excludes the definition of data contracts for the following systems and domains:

• EPR (Electronic Patient Record) systems (e.g. openEHR Genomics )
• Genomic Applications (e.g. Global Alliance for Genomics and Health)
• LIMS
• OLAP (Online Analytical Processing) and FDP (Federated Data Platform)

This guide includes the definition of data contracts for:

• Business-to-Business (B2B): Use of HL7 FHIR to read data from the Clinical Data Repository.
• Data Pipeline: Internal use of HL7 FHIR for data exchange between the Regional Integration Engine and the Clinical Data Repository.
• Business-to-Business (B2B): Use of HL7 v2 and HL7 FHIR for interactions between LIMS and EPR systems.
• Data Pipeline: Use of HL7 v2, HL7 FHIR and IHE XDS for data exchange between the CDR and Regional Document Sharing systems such as IHE XDS, GMCR and National Record Locator. Note: data contract downgrades will be present in these pipelines.

Key Differences from base HL7 FHIR, HL7 V2 standards, and HL7 UK Core

This model requires coordination between NHS Trusts and regional standardisation of HL7 (v2 and FHIR). Key changes include:

• Patient Identifiers: Medical Record Number (MRN): MRNs may overlap across Trusts, so they are augmented with the ODS code of the originating NHS organisation (assigning authority).
• Patient Identifiers: NHS Number, CHI Number, and HSNI become the primary patient identifiers. NHS Numbers must be verified against national demographic services. Patients may have multiple NHS identifiers.
• Order and Report Numbers:: Must indicate type (e.g. placer or filler) and originating NHS provider (assigning authority).
• Clinical Coding: SNOMED CT and LOINC are used for OBX segments and observations. The use of LOINC in genomics is a key requirement for cross-standard (HL7 v2, FHIR and openEHR) transformations, UK SNOMED CT will be added when supported at a national level. Local codes may still be included where required.
• Specimen: Specimen identifiers must be included in orders, requiring the use of HL7 v2.5.1 OML_O21 (rather than ORM_O01) and ORU_R01. This supports distributed genomic testing, where multiple tests may be performed on a single specimen across several laboratories.

The RIE will not undertake any transformation of HL7 messages to meet external system or individual NHS Trust requirements. Responsibility for transforming messages for supplier systems remains with each NHS Trust’s TIE. It is therefore the responsibility of the NHS Trust TIE to ensure that data is provided in the correct format for its system suppliers. Any amendments to this arrangement may be requested through the change process.

Key Data Contracts

Data Contract Issues and Change Process

1. Data consumers identify data constraints or issues.
2. Requirements or issues are logged in the NH Genomics IG issues
3. Business stakeholders, suppliers, and integration partners (collectively, the NW Genomics Data Team) review the item and assess its feasibility.
4. The data contract is created or updated within this implementation guide (for example, via a pull request).
5. The proposed change is reviewed and approved by the NW Genomics Data Team.
6. Once approved, the change is released.

flowchart TD
    A[Data Consumer<br/>Identifies Issue or New Constraint]
    B[Log Requirement / Issue<br/>NH Genomics IG Issues]
    C[NW Genomics Data Team<br/>Review & Feasibility Assessment]
    D["Create or Update<br/>Data Contract<br/>Implementation Guide (PR)"]
    E[NW Genomics Data Team<br/>Review & Approval]
    F[Release Change]

    A --> B --> C --> D --> E --> F

Relationship to Other Guides

The data model used in this guide is a combination of data and workflow requirements from a variety of other guides.

North West Genomics IG