It is a condition of HGNC funding from NIH and the Welcome Trust that the nomenclature and information provided is freely available to all. Anyone may use the HGNC data, but we request that they reference the "HUGO Gene Nomenclature Committee at the European Bioinformatics Institute"
and the website where possible.
The UCUM codes, UCUM table (regardless of format), and UCUM Specification are copyright 1999-2009, Regenstrief Institute, Inc. and the Unified Codes for Units of Measures (UCUM) Organization. All rights reserved. https://ucum.org/trac/wiki/TermsOfUse
This material contains content that is copyright of SNOMED International. Implementers of these specifications must have the appropriate SNOMED CT Affiliate license - for more information contact https://www.snomed.org/get-snomed
or info@snomed.org
.
North West Genomic Medicine Service Alliance - Local Development build (v0.0.7) built by the FHIR (HL7® FHIR® Standard) Build Tools. See the Directory of published versions ( src
)
From ISO-13606
The set of information committed to one EHR as a result of a clinical encounter or a record documentation session. Examples of COMPOSITION are Progress note, Laboratory test result form, Radiology report, Referral letter, Clinic visit, Clinic letter, Discharge summary, Functional health assessment, Diabetes review.
Domain Archetype
is the result of a collaboration process which aims to form a series of common archetypes within a domain (the domain in this case is Genomics).
The initial format for this archetype is often a spreadsheet that is expressed in an electronic format. The format we are using in this guide is HL7 FHIR Questionnaire
, other formats can be used such as openEHR Archetype (see Genomic Variant Result
)
Domain Archetype
is the result of a collaboration process which aims to form a series of common archetypes within a domain (the domain in this case is Genomics).
The initial format for this archetype is often a spreadsheet that is expressed in an electronic format. The format we are using in this guide is HL7 FHIR Questionnaire
, other formats can be used such as openEHR Archetype (see Genomic Variant Result
)
The domain archetypes are implemented via a Canonical Data Model
, which is common across all technical formats (i.e. HL7 v2 and HL7 FHIR) and is described using HL7 FHIR.
This includes making use of FHIR Identifier assigner.identifier.value
(HL7 v2 Assigning Facility
in a variety of ID types) to distinguish these identifiers between different organisations, the recommendation is to use ODS Code
, e.g.
The coding (B0001, B0300, B0307, etc) is using local laboratory coding, ideally we want all organisations to communicate via standard coding and in the UK this preferred clinical coding is SNOMED CT UK Edition 83821000000107
and the preferred coding standard for units is UCUM
. To use local codes would mean 20+ organisation maintaining code mappings between all the different local codesystems, by using SNOMED (or LOINC) this means they only need to maintain mappings between local codes and SNOMED (or LOINC)
The coding (B0001, B0300, B0307, etc) is using local laboratory coding, ideally we want all organisations to communicate via standard coding and in the UK this preferred clinical coding is SNOMED CT UK Edition 83821000000107
and the preferred coding standard for units is UCUM
. To use local codes would mean 20+ organisation maintaining code mappings between all the different local codesystems, by using SNOMED (or LOINC) this means they only need to maintain mappings between local codes and SNOMED (or LOINC)
Internet searches also reveal several NHS Trusts providing documentation around Full Blood Count
, this often includes the local coding we saw with the HL7 v2 example. The example below is from University Hospitals of Liverpool Group - Full Blood Count
Document Consumer MHDIntermediaryRegional Integration Engine (RIE)Master Patient IndexMPIDocument Registry XDSIron IslandsDocument Registry XDSWesterlandsClinical Data Source QEDmWesterosDocument Responder MHDNational Record LocatorFind Document References [ITI-67]Retrieve patient's document pointers (GET)List of FHIR DocumentReference (UKCore)opt[Identify Systems with Records]Used to identify which systems have documents for the patientPatient Demographics Query [ITI-78]List of FHIR Patient (includes MRN from providers)Registry Stored Query [ITI-18]List of DocumentEntryRegistry Stored Query [ITI-18]List of DocumentEntryQuery Existing Data [PCC-44]HL7 IPA Finding and Retrieving Patient Information (DocumentReference)List of FHIR DocumentReferenceTransformandAggregateList of FHIR DocumentReference (UKCore + IHE UK metadata)
Document Consumer MHDIntermediaryRegional Integration Engine (RIE)Master Patient IndexMPIDocument Registry XDSIron IslandsDocument Registry XDSWesterlandsClinical Data Source QEDmWesterosDocument Responder MHDNational Record LocatorFind Document References [ITI-67]Retrieve patient's document pointers (GET)List of FHIR DocumentReference (UKCore)opt[Identify Systems with Records]Used to identify which systems have documents for the patientPatient Demographics Query [ITI-78]List of FHIR Patient (includes MRN from providers)Registry Stored Query [ITI-18]List of DocumentEntryRegistry Stored Query [ITI-18]List of DocumentEntryQuery Existing Data [PCC-44]HL7 IPA Finding and Retrieving Patient Information (DocumentReference)List of FHIR DocumentReferenceTransformandAggregateList of FHIR DocumentReference (UKCore + IHE UK metadata)
The Intermediary
optionally calls the Master Patient Index
. This is similar to the use of Cross-Community Patient Discovery (XCPD)
with XDS.b but uses ITI-78 in place of HL7 v3 ITI-55 or HL7 v2 PDQ ITI-21
Federated Genomic Data Access and Health Information Exchange (HIE)Clinical Data ConsumerHealth Information ExchangeRegional Integration Engine (RIE)Clinical Data SourceNW GMSAClinical Data SourceNHS England GOMSFHIR REST APIIHE Query Existing Data [QEDm)Federated Query Access StartFHIR REST APIIHE Query Existing Data [QEDm)ResponseFHIR REST APIIHE Query Existing Data [QEDm)ResponseAggregateResponsesFederated Query Access EndResponse
In this workflow, both the order and report are shared instead of being sent. The communication between the Order Placer and Filler changes to a conversation
rather than messaging pattern around the Fulfillment Task.
Within the system creating the genomics order, the practitioner will select a form for the test required. Below are several examples from North West Genomic Laboratory Hub - Test Request Forms
.
How this is implemented will vary between different NHS organisations and systems they use.
For submission, this form will be converted by the Order Placer
to a communication format called HL7 FHIR
(and for compatability reasons HL7 v2
.
If the Order Placer
has a FHIR enabled Electronic Patient Record (e.g. EPIC, Cerner, Meditech, etc), they may use HL7 SDC - Form Data Extraction
to assist with this process.
It is not expected the NW GLH Laboratory Information Management System (LIMS) will support UK SNOMED CT, and the RIE will handle the conversion either internally using FHIR ConceptMap
or a terminology service with the following capabilities IHE Sharing Valuesets, Codes, and Maps (SVCM)
Canonical model:
A standardised model ( Canonical model
), expressed in HL7 FHIR, that can be implemented using HL7 v2, FHIR, and IHE XDS. It aligns with the latest HL7 UK Core and NHS England Data Model and Dictionary. While primarily focused on genomics, it incorporates elements from pathology and radiology for compatibility, and mandates the use of NHS England National Procedure Codes.
In pathology and genomics, the accession number refers to the Specimen.
In imaging the accession number refers to the imaging test RADIOLOGICAL ACCESSION NUMBER
(copied from BE eHealth Platform Federal Core Profiles
) Extension able to hold a reference and a concept (Temporary solution until https://jira.hl7.org/browse/FHIR-44661 is solved and see Zulip: https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Backporting.20CodeableReference )
Note: links to HL7 FHIR Practitioner has removed several IHE XDS Document Entry fields, and just retained identifier and name. It is expected these values would be available via the NHS England Healthcare Worker API which may conform to IHE Mobile Care Services Discovery (mCSD)
interface contracts.
Secondary findings are genetic test results that provide information about variants in a gene unrelated to the primary purpose for the testing, most often discovered when Whole Exome Sequencing (WES)
or Whole Genome Sequencing (WGS)
is performed. This extension should be used to denote when a genetic finding is being shared as a secondary finding, and ideally refer to a corresponding guideline or policy statement.
Secondary findings are genetic test results that provide information about variants in a gene unrelated to the primary purpose for the testing, most often discovered when Whole Exome Sequencing (WES)
or Whole Genome Sequencing (WGS)
is performed. This extension should be used to denote when a genetic finding is being shared as a secondary finding, and ideally refer to a corresponding guideline or policy statement.
It is not clear in Enterprise/Regional use of FHIR which approach Resource
or Reference
should be taken, both HL7 v2 and FHIR support Reference aggregate or entities by identity
from Dommain Driven Design (DDD) and this appears to also be followed by IHE XDS and DICOM.
In addition, NHS England Data Dictionary
and NHS England HL7 v2 ADT Message Specification
favour Reference
NHS England FHIR STU3/R4 specifications around Messaging, tend to favour Resource
.
Simple Extension with the type CodeableConcept: (copied from BE eHealth Platform Federal Core Profiles
) Extension able to hold a reference and a concept (Temporary solution until https://jira.hl7.org/browse/FHIR-44661 is solved and see Zulip: https://chat.fhir.org/#narrow/stream/179280-fhir.2Finfrastructure-wg/topic/Backporting.20CodeableReference )
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).
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 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.
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.
This is based on the definition of PL from NHS England HL7 v2 ADT Message SpecificationSHOULD
be followed and SHALL
be used in ORC-12.
In addition, this includes of PL.11 to hold organisation ODS code.
Extended Composite Name and Identification Number for Organizations.
The definition of XON from NHS England HL7 v2 ADT Message SpecificationSHOULD
be followed and SHALL
be used in ORC-21.
Both guides are effectively merged in this guide and applied to both HL7 v2 and FHIR. The pattern used here is Canonical Data Mode
, this can also be applied to other formats such as IHE XDS and DICOM.
For NHS trusts with EPRs with FHIR REST APIs (e.g. EPIC
, Oracle and Cerner), the FHIR system used here SHOULD
be the same.
An OID can be used instead of a FHIR system, this may be defined for use with IHE XDS.
This guide follows IHE Laboratory Testing Workflow
, which describes how to use HL7 v2 orders and reports at an enterprise level. It will contain several modifications in order to support HL7 FHIR Messasging
, these messages will be closely related to HL7 v2 Messages to help with adoption.
For documentation purposes, HL7 v2 version used will be 2.5.1 (this also matches NHS England FHIR Genomics, HL7 International v2 standards around structured Genomic reporting and Digital Health and Care Wales standards around ORU_R01)
Message Bridge
between regional Trust Integration Engines (TIE)/GLH Laboratory Information System (LIMS) and the national Genomic Order Management Service (LAB-4 and LAB-5)
The NHS England Genomic Order Management Service - Process genomic test request
is effectively a HL7 Message same as the Genomic Order O21 Command Message. This does not support Genomic Report R01 Document Message
This differs from the current proposal to send in Genomic Test Requests
via messaging ( Process genomic test request
), instead they would be shared from the enterprise CDR, and the request to process genomic test request
would be Create a new Task
This differs from the current proposal to send in Genomic Test Requests
via messaging ( Process genomic test request
), instead they would be shared from the enterprise CDR, and the request to process genomic test request
would be Create a new Task
|
Propose a change
