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 HPO vocabularies, annotation files, tools and documentation are freely available.
The HPO is copyrighted to protect the integrity of the vocabularies, which means that changes to the HPO vocabularies need to be done by HPO developers. However, anyone can download the HPO and use the ontologies or other HPO files under three conditions:
That the Human Phenotype Ontology Consortium is acknowledged and cited
properly.
That any HPO Consortium file(s) displayed publicly include the date(s) and/or version number(s) of the relevant HPO file(s).
That neither the content of the HPO file(s) nor the logical relationships embedded within the HPO file(s) be altered in any way. (Content additions and modifications have to be suggested using our issue tracker
.)
Users of the HPO should add the following statement to their online presence. This service/product uses the Human Phenotype Ontology (version information). Find out more at http://www.human-phenotype-ontology.org
. We request that the HPO logo be included as well.
The Sequence Ontology: A tool for the unification of genome annotations. Eilbeck K., Lewis S.E., Mungall C.J., Yandell M., Stein L., Durbin R., Ashburner M. Genome Biology (2005) 6:R44
Please also include the version of SO used.Sequence Ontology data and data products are licensed under the Creative Commons Attribution 4.0 Unported License
.
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
.
Defines the content expected to be rendered in all representations of the artifact. The (c) symbol should NOT be included in this string. It is expected to be added by software when rendering the notation. Full details about licensing, restrictions, warrantees, etc. goes in the more general 'copyright' element. ( src
)
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 ( 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.
Cancer Background Information for Use Cases is a high-level page that pulls
together several of this IG's other diagnostic testing and
treatment-monitoring use cases - a genomics test following on from a
pathology test order can often
occur around cancer, and cancer referrals bring their own notification
patterns. Rather than a single pathway, this page follows the same simple
three-stage structure Macmillan Cancer Support uses on
macmillan.org.uk/cancer-information-and-support
-
Diagnosis
, Treatment
, and After Treatment
- and shows where
genomic/genetic testing fits within each, using worked examples from the
Cheshire and Merseyside Pathology
and
Haemato-Oncology Diagnostic Pathway
use cases.
Genomic and genetic testing does not happen at just one point in a cancer
pathway - it can help confirm a diagnosis, choose or adjust treatment, and
watch for the cancer coming back afterwards. The three sections below follow
Macmillan's own structure for
cancer information and support
,
so a family carer or patient reading this alongside a Macmillan guide can see
where the genomic/genetic testing fits in the wider picture.
Macmillan - Diagnosis
covers what happens when cancer is suspected and how a diagnosis is
confirmed. Genomic testing at this stage usually looks at the tumour sample
itself, to help confirm the diagnosis and check for an inherited condition
that could run in the family.
The GP referral
is most likely made via the NHS e-Referral Service (eRS)
- referrals like this are generally linked to IHE 360X and HL7 v2 REF_I12
. The resulting hospital outpatient/clinic report is returned to the GP via MESH
(in the "Kettering" EDT/XML format many GP systems still expect) or, increasingly, the NHS England Transfer of Care standard. Discharge summaries and hospital reports sent this way often use HL7 v2 MDM_T02
or ORU_R01
.
The GP referral
is most likely made via the NHS e-Referral Service (eRS)
- referrals like this are generally linked to IHE 360X and HL7 v2 REF_I12
. The resulting hospital outpatient/clinic report is returned to the GP via MESH
(in the "Kettering" EDT/XML format many GP systems still expect) or, increasingly, the NHS England Transfer of Care standard. Discharge summaries and hospital reports sent this way often use HL7 v2 MDM_T02
or ORU_R01
.
The genetic counselling referral above assumes the patient and their at-risk
relatives (consultands) all live in the same catchment as the diagnosing
genomics/genetics service. In practice a relative may live under a different
regional clinical genetics service - for example, a patient diagnosed in
Liverpool whose relatives live in Nottingham and Leeds. There is no national
system linking clinical genetics services across regions for this, so the
diagnosing service instead sends a family letter
- a clinical letter
summarising the variant, the inheritance pattern and the relatives thought to
be at risk - to each relative's GP or directly to the regional genetics
service covering them, inviting a local referral for cascade (predictive)
testing
.
A relative within the diagnosing service's own catchment (e.g. another
relative living locally in Liverpool) is typically seen directly by that
service instead.
Macmillan - Treatment
covers the different types of cancer treatment and what to expect. During
treatment, blood tests and other laboratory results are used regularly to
check how a patient is responding and to guide medicine doses - keeping
results flowing quickly and accurately between the hospital, community teams
and the laboratory matters just as much as the test itself.
Macmillan - After Treatment
covers follow-up care
once treatment finishes, including watching for signs the cancer may be
coming back. One newer approach is testing a blood sample for tiny traces of
tumour DNA circulating in the blood - often called "ctDNA" or a "liquid
biopsy" - which can pick up early warning signs without needing a further
scan or biopsy of the tumour itself.
Macmillan - After Treatment
covers follow-up care
once treatment finishes, including watching for signs the cancer may be
coming back. One newer approach is testing a blood sample for tiny traces of
tumour DNA circulating in the blood - often called "ctDNA" or a "liquid
biopsy" - which can pick up early warning signs without needing a further
scan or biopsy of the tumour itself.
Built against the Genomics England terminology server
(https://re-docs.genomicsengland.co.uk/terminology_server/,
https://ontoserver.aws.gel.ac/fhir
), HPO release 20191108
. That server
only publishes a SNOMED CT to HPOConceptMap
( sct-to-hpo
) by name,
but does support querying it in the HPO-to-SNOMED direction directly via
ConceptMap/sct-to-hpo/$translate?...&reverse=true
- see nw-gmsa/Testing
notebook 13
,
which uses the same server and surfaced this parameter. An initial pass of
this ConceptMap missed that: it instead found a candidate SNOMED CT concept
for each HPO term ( ValueSet/$expand
free-text search under the Clinical
finding ( 404684003
) subtree) and forward-verified it through
ConceptMap/sct-to-hpo/$translate
in the SNOMED-to-HPO direction - which
undercounted, since a genuinely-mapped HPO term can have a mapped SNOMED
code that isn't the one a text search happens to surface (e.g. Cataract
is
mapped, to SNOMED 128306009
, not the 193570009
a plain text search
returns first). This version instead queries reverse=true
directly for
every HPO code, with the equivalence
value taken directly from that
server response ( equivalent
in every case found).
Built on InterSystems Health Connect. This is the messaging layer: it
supports workflows between
NHS Organisations (Trust EPR to NW Genomics and
back), and internal process-to-process workflows between
LIMS (e.g. iGene
to StarLIMS Work Orders). Its design style follows Enterprise Integration
Patterns
Message-Oriented Middleware (MOM)
- like Apache
Kafka
, RabbitMQ
or AWS SQS, the RIE decouples producers and consumers and moves data
asynchronously, so a LIMS sending a report doesn't need to know or wait
on which Trusts will receive it. Unlike a general-purpose broker, though,
the RIE isn't a neutral pipe with topics/queues any consumer can
subscribe to - the transformation and routing logic (which destination,
in what HL7 flavour) is built into the RIE itself as configured
integration production rules, not left to consumer-side code.
Message-Oriented Middleware (MOM)
- like Apache
Kafka
, RabbitMQ
or AWS SQS, the RIE decouples producers and consumers and moves data
asynchronously, so a LIMS sending a report doesn't need to know or wait
on which Trusts will receive it. Unlike a general-purpose broker, though,
the RIE isn't a neutral pipe with topics/queues any consumer can
subscribe to - the transformation and routing logic (which destination,
in what HL7 flavour) is built into the RIE itself as configured
integration production rules, not left to consumer-side code.
Workflow Orchestration Tools
- like Apache
Airflow
, Prefect
or Dagster
, the RIE coordinates a sequence of
dependent steps for each message (validate, enrich via a PDS/ODT lookup,
convert, route) and handles retries/error routing when a step fails. The
difference is scope and cadence: these tools schedule and orchestrate
batch ETL/ELT DAGs over datasets on a timer; the RIE orchestrates a
workflow per individual message, in near real time, as each order or
report arrives.
Workflow Orchestration Tools
- like Apache
Airflow
, Prefect
or Dagster
, the RIE coordinates a sequence of
dependent steps for each message (validate, enrich via a PDS/ODT lookup,
convert, route) and handles retries/error routing when a step fails. The
difference is scope and cadence: these tools schedule and orchestrate
batch ETL/ELT DAGs over datasets on a timer; the RIE orchestrates a
workflow per individual message, in near real time, as each order or
report arrives.
Workflow Orchestration Tools
- like Apache
Airflow
, Prefect
or Dagster
, the RIE coordinates a sequence of
dependent steps for each message (validate, enrich via a PDS/ODT lookup,
convert, route) and handles retries/error routing when a step fails. The
difference is scope and cadence: these tools schedule and orchestrate
batch ETL/ELT DAGs over datasets on a timer; the RIE orchestrates a
workflow per individual message, in near real time, as each order or
report arrives.
Built on the InterSystems FHIR Repository. This is an operational data
platform
, not a messaging engine: it is populated by
wire-tapping
the messages and data flows
already passing through the RIE, rather than being sent to directly. Its
design style is different from the RIE's messaging patterns - it follows
aggregates
from Domain Driven
Design
, the
operational-data-platform pattern (query the current state of an entity, not
just the event stream that produced it), and domain archetypes from Data
Mesh
- see
Architecture
for how the domain split works. Its
interactions are FHIR RESTful ( GET
/ search
/ batch
/ transaction
, per
notebook 07
below) - it also supports SQL, via InterSystems' own SQL projection over the
stored FHIR resources, for analysts and reporting tools that don't speak
FHIR natively.
Built on the InterSystems FHIR Repository. This is an operational data
platform
, not a messaging engine: it is populated by
wire-tapping
the messages and data flows
already passing through the RIE, rather than being sent to directly. Its
design style is different from the RIE's messaging patterns - it follows
aggregates
from Domain Driven
Design
, the
operational-data-platform pattern (query the current state of an entity, not
just the event stream that produced it), and domain archetypes from Data
Mesh
- see
Architecture
for how the domain split works. Its
interactions are FHIR RESTful ( GET
/ search
/ batch
/ transaction
, per
notebook 07
below) - it also supports SQL, via InterSystems' own SQL projection over the
stored FHIR resources, for analysts and reporting tools that don't speak
FHIR natively.
Built on the InterSystems FHIR Repository. This is an operational data
platform
, not a messaging engine: it is populated by
wire-tapping
the messages and data flows
already passing through the RIE, rather than being sent to directly. Its
design style is different from the RIE's messaging patterns - it follows
aggregates
from Domain Driven
Design
, the
operational-data-platform pattern (query the current state of an entity, not
just the event stream that produced it), and domain archetypes from Data
Mesh
- see
Architecture
for how the domain split works. Its
interactions are FHIR RESTful ( GET
/ search
/ batch
/ transaction
, per
notebook 07
below) - it also supports SQL, via InterSystems' own SQL projection over the
stored FHIR resources, for analysts and reporting tools that don't speak
FHIR natively.
in particular, converting a SNOMED CT clinical finding into a Human
Phenotype Ontology (HPO)
term via
ConceptMap/sct-to-hpo/$translate
, used to derive a GenomicClinicalIndication
code from a patient's EPR problem list. Notebook
13
queries it live and is worth reading in full, since it also documents where
the mapping doesn't
work today: discrete findings (e.g. Ataxia, Seizure)
translate reliably, but coded diagnoses (e.g. Marfan syndrome, Cystic
fibrosis, Lynch syndrome) currently produce no mapping at all. The same
server and sct-to-hpo
map were used to hand-build this IG's own static
GMSWGSGuideHPOTermsToSCTConceptMap
- see notebook
13
's
own closing note on IHE Sharing Valuesets, Codes, and Maps
(SVCM)
for where this pattern
is heading.
in particular, converting a SNOMED CT clinical finding into a Human
Phenotype Ontology (HPO)
term via
ConceptMap/sct-to-hpo/$translate
, used to derive a GenomicClinicalIndication
code from a patient's EPR problem list. Notebook
13
queries it live and is worth reading in full, since it also documents where
the mapping doesn't
work today: discrete findings (e.g. Ataxia, Seizure)
translate reliably, but coded diagnoses (e.g. Marfan syndrome, Cystic
fibrosis, Lynch syndrome) currently produce no mapping at all. The same
server and sct-to-hpo
map were used to hand-build this IG's own static
GMSWGSGuideHPOTermsToSCTConceptMap
- see notebook
13
's
own closing note on IHE Sharing Valuesets, Codes, and Maps
(SVCM)
for where this pattern
is heading.
in particular, converting a SNOMED CT clinical finding into a Human
Phenotype Ontology (HPO)
term via
ConceptMap/sct-to-hpo/$translate
, used to derive a GenomicClinicalIndication
code from a patient's EPR problem list. Notebook
13
queries it live and is worth reading in full, since it also documents where
the mapping doesn't
work today: discrete findings (e.g. Ataxia, Seizure)
translate reliably, but coded diagnoses (e.g. Marfan syndrome, Cystic
fibrosis, Lynch syndrome) currently produce no mapping at all. The same
server and sct-to-hpo
map were used to hand-build this IG's own static
GMSWGSGuideHPOTermsToSCTConceptMap
- see notebook
13
's
own closing note on IHE Sharing Valuesets, Codes, and Maps
(SVCM)
for where this pattern
is heading.
Worked-example Jupyter notebooks from
nw-gmsa/Testing
- each
builds a piece of this IG's FHIR/HL7 v2 conversion by hand, in Python, against real
example data. They form a series ( 01
onward assumes the reader has read the earlier
ones), and most relate directly to one or more of this IG's Use Cases
.
Notebook 13's terminology-server pattern (querying a remote FHIR server's $lookup
/ $translate
operations live, rather than hand-maintaining a static map) is the same shape IHE Sharing Valuesets, Codes, and Maps (SVCM)
formalises as a profile - this IG is likely to adopt an SVCM-conformant terminology service for SNOMED CT/HPO/Genomic Test Directory conversions in future, rather than continuing to hand-build ConceptMap
s like GMSWGSGuideHPOTermsToSCT
notebook-by-notebook.
For a first look that doesn't need Python/Jupyter, the same requests notebooks
01
, 02
and 13
build by hand are also available as a ready-to-run
Postman
collection and environment, in
nw-gmsa/Testing/postman
:
For a first look that doesn't need Python/Jupyter, the same requests notebooks
01
, 02
and 13
build by hand are also available as a ready-to-run
Postman
collection and environment, in
nw-gmsa/Testing/postman
:
The notebooks above are aimed at integration/interoperability developers - FHIR and HL7
v2 message shapes, not analysis of genomic data itself. For that audience, Genomics
England publishes its own separate set of tutorials aimed at researchers and data
analysts working inside the Genomics England Research Environment: Genomics England
Research Environment - How-to
guides
. These cover cohort building
(phenotype-first and genotype-first, via Participant Explorer/CloudOS), querying
aggregate VCF datasets (AggV2/AggV3/somAgg), downstream analysis (association testing,
variant screening, survival analysis), and desktop tooling (LabKey, Airlock, IVA) using
Python, R, Jupyter notebooks and HPC workflows - a different layer of the same overall
genomics ecosystem this IG's own notebooks integrate with at the message/API level.
IHE PCC Technical Framework Supplement - 360X: Closed Loop Referrals
- the closed-loop referral profile this pattern is analogous to (not itself adopted here)
Current state:
where the referrer is a GP practice, the referral into a regional
clinical genetics service (e.g. Manchester Centre for Genomic Medicine, LCGM) is most
commonly made today via NHS e-Referral Service
(eRS)
- the national service GPs
already use to refer into secondary care generally, not a genomics-specific
mechanism. eRS is being generalised into this page's scope (rather than excluded, as
in an earlier version of this page) because it is, in practice, the primary route by
which patients first reach these services. eRS assigns each referral a Unique
Booking Reference Number (UBRN)
, which the receiving service uses to identify and
triage it.
eRS's FHIR API
currently represents the referral as a ReferralRequest
resource (STU3), profiled
as eRS-ReferralRequest-1
; a newer ServiceRequest
-based (R4) endpoint is in
development, on which the UBRN appears explicitly as
ServiceRequest.identifier
(system https://fhir.nhs.uk/Id/UBRN
), with
intent = order
and category
coded referral
(system
https://fhir.nhs.uk/CodeSystem/message-category-servicerequest
) - see the FHIR
Resource Model
below.
Booking the counselling/genetics appointment itself is deliberately out of scope for
this page. eRS has its own booking functionality, IHE's Closed Loop Referral profile
(360X) includes its own dedicated scheduling transactions, and NHS England's
Booking and Referral Standard (BaRS)
is itself primarily a booking-and-referral service for non-eRS pathways - any of
these could be the natural place scheduling would live if this pattern were ever
built out, but none is analysed further here.
The diagram below sketches how eRS's own FHIR API relates the resources involved in
a referral, taken from the worked examples published in eRS's FHIR API
catalogue
.
It uses the current (STU3) ReferralRequest
resource name; the same shape applies to
the newer ServiceRequest
-based (R4) endpoint once it is generally available.
NHS Booking and Referral Standard
(BaRS)
is NHS England's other FHIR-based referral mechanism, intended as a general-purpose
alternative to eRS for non-GP referral pathways. Checking its published
CapabilityStatement
and MessageDefinition
resources directly: BaRS defines no
referral-specific data model of its own
- there is no BaRS equivalent of eRS's
UBRN, ReferralPriority
, ReferralState
or Shortlist
extensions, and no
referral-specific identifier system was found anywhere in its published API
documentation.
Events and workflow are coordinated via
FHIR Task
resources rather than messaging - GOMS's incorporation of the national service into FHIR Workflow. In Enterprise Integration Patterns terms, this is a Conversation
pattern. At present, Task
events are not distributed as push notifications, so they must instead be retrieved via polling ( GET /Task
) - the same method already used to retrieve StarLIMS work orders from the FHIR Repository (see StarLIMS / iGene Integration
), as demonstrated in notebook 02 - Work Orders: A Worked Example
.
Events and workflow are coordinated via
FHIR Task
resources rather than messaging - GOMS's incorporation of the national service into FHIR Workflow. In Enterprise Integration Patterns terms, this is a Conversation
pattern. At present, Task
events are not distributed as push notifications, so they must instead be retrieved via polling ( GET /Task
) - the same method already used to retrieve StarLIMS work orders from the FHIR Repository (see StarLIMS / iGene Integration
), as demonstrated in notebook 02 - Work Orders: A Worked Example
.
This specification adds England-specific data modeling from NHS England Canonical Data Model ( NHS Futures - Canonical Data Model (CDM)
).
This specification also conforms to HL7 UK Core.
Feeds patient identity data into the Patient Identity Registry (PIX Patient Identity Feed ITI-8, or the mobile equivalent PIXm ITI-93). The NHS England HL7 v2 standard for this feed is the NHS England HL7 v2 ADT Message Specification
.
Queries the Patient Identity Registry for patient demographics (PDQm Mobile Patient Demographics Query ITI-78). This is roughly equivalent to the NHS Personal Demographics Service - FHIR API
.
Using an HL7 Europe Laboratory Report FHIR Document to share laboratory reports is a modernisation of IHE Sharing Laboratory Reports (XD-LAB)
, replacing HL7 Clinical Document Architecture (CDA) with an HL7 FHIR Document.
However, the genomic content of the Shire → HODS LAB-36Cytogenetic Genomic
Report
is itself a candidate for future modelling. The sample messages for this
pathway
( Shire-1
,
Shire-2
)
carry cytogenetic/molecular findings for suspected MDS and AML - a karyotype
(ISCN nomenclature) and, in Shire-2, a FISH result - but represent them
entirely as narrative free text: every line of the report is a separate
OBX|n|FT|CYTO||...
segment, OBR-4
(Universal Service Identifier) is not
populated with a coded test name, and there is no structured representation
of the abnormal karyotype, the FISH probe/assay used, or the proportion of
cells affected (e.g. "93 out of 100 interphase cells"). Report amendments are
also represented only as an inline text marker ( -Amendment 14/10/20
in
Shire-2) rather than as a distinct report/observation status. This is genomic
reporting in substance but does not currently align with the HL7 FHIR
Genomics Reporting Implementation
Guide
.
However, the genomic content of the Shire → HODS LAB-36Cytogenetic Genomic
Report
is itself a candidate for future modelling. The sample messages for this
pathway
( Shire-1
,
Shire-2
)
carry cytogenetic/molecular findings for suspected MDS and AML - a karyotype
(ISCN nomenclature) and, in Shire-2, a FISH result - but represent them
entirely as narrative free text: every line of the report is a separate
OBX|n|FT|CYTO||...
segment, OBR-4
(Universal Service Identifier) is not
populated with a coded test name, and there is no structured representation
of the abnormal karyotype, the FISH probe/assay used, or the proportion of
cells affected (e.g. "93 out of 100 interphase cells"). Report amendments are
also represented only as an inline text marker ( -Amendment 14/10/20
in
Shire-2) rather than as a distinct report/observation status. This is genomic
reporting in substance but does not currently align with the HL7 FHIR
Genomics Reporting Implementation
Guide
.
Shire's LAB-36Cytogenetic Genomic Report
(and any genomic content folded
into the combined LAB-3
report) is a candidate for restructuring in place
of the current free-text OBX|FT|CYTO
pattern seen in the sample Shire
messages
- note
this is the pathology laboratory's (Shire's) report, not the separate
molecular genomics laboratory's LAB-36
. Two complementary sources were
reviewed for this:
Note:
The Data Contract only exists between NHS Trusts and NW Genomics — it does not apply to local integrations with EPR or LIMS systems. See also the Canonical Data Model
pattern.
NHSBT's own national H&I Organ Transplant (Patients and Donors)
paper request form
( FRM1008
) - see NHSBT's published
form
.
This is the national form the HLA Tests - Transplant Questionnaire's own design notes
above already identify as FRM1008
, but that Questionnaire reflects Hive's own
narrower order-entry UI (Patient Type: Stem cell/Renal/Thoracic; Organ:
Kidney/Pancreas/Islets/Simultaneous Pancreas-Kidney/Simultaneous Islet-Kidney) rather
than this form's own Category
(Patient - Renal/Patient - Non-Renal/Donor, each
with its own sub-checklist) and Request details
(HLA type, HLA specific
antibodies, Live donor crossmatch, Auto crossmatch) sections. Modelled directly from
the paper form, the same approach as HSCT Recipients and
Donors
below, and reusing that
Questionnaire's Role
(Patient/Family Member - Potential Donor) pattern for its own
"Complete for new patients only" vs "Complete for Family Member / Potential Donor"
sections. Request details
maps to ServiceRequest.orderDetail
, not
ServiceRequest.code
, the same reasoning as HLA Tests -
Transplant
's Patient Test(s)
item above -
see Outstanding Issues
item 4.
These questions were extracted from a live Histotrac ORM^O01
order for a Chimerism
Testing (Performable) test - see
histotrac-MFT-chimerism.txt
.
Unlike HLA Tests - Transplant above, this order carries only two NTE
segments, and in
the reverse order (Specimen Source before Patient Test(s)):
Unlike the two Hive-derived Questionnaires above, this one models NHS Blood and
Transplant's (NHSBT) own national H&I Haematopoietic Stem Cell Transplantation
(Recipients & Donors)
paper request form ( FRM1010
) directly - see NHSBT's
published form
.
No live system message for this form has been sourced, so field mappings are this
IG's own best-effort candidates rather than confirmed against a live order.
A note on "top down".
In summary, this approach is top down - but not in
the usual sense of management or central NHS organisations (the
"penthouse") passing instructions down to the "engine rooms" actually
delivering the work. The analogy is borrowed from Gregor Hohpe's Architect
Elevator
. Here, "top" means the
practitioner
- who is focused on the patient, the real top of this whole
process - and "top down" means starting there and riding the elevator down
through every floor in between: workflow, information requirements, data
model, Interoperability Data Model, and only then implementation. Skipping
floors - whether that's the penthouse handing instructions straight to the
engine room, or a developer being handed a technical instruction with none
of the floors in between - is exactly the trap explored in Examples of
Common Interoperability Project
Problems
below.
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.
The daily iGene CSV export (step 3 of Current Process
above) has
the shape below - see NEYctDNA.csv
for a full example file. This table covers only the columns that populate the FHIR
Message O21 Laboratory Order - the same CSV's report/result columns instead populate
the separate FHIR Message R01 Laboratory Report, covered in Laboratory Report R01
Mapping
below. Many columns here reuse the same FHIR mapping as the
equivalent iGene Work Order Export
column, since this is the same underlying order data.
These two fields most directly relate to the Cheshire and Merseyside
Pathology
reflex use case, where a
genomic order follows on from a prior pathology order/report
( LAB-1
/ LAB-3
) rather than starting the clinical episode itself - that
page's own Current
Process
still models
the pathology-to-genomics handoff entirely as HL7 v2/FHIR messaging
( LAB-1
/ LAB-35
/ LAB-3
/ LAB-36
), which is why today's answer is free
text rather than a machine-resolvable reference. A query-based alternative
may remove the need to duplicate pathology content into the genomic
order/message at all: some NW pathology LIMS deployments (e.g. Medicus)
already support the Australian AU
eReq
FHIR IG for on-demand query
access to pathology orders (and potentially reports), and MFT separately
exposes pathology data through Epic's own FHIR Query
API
. If a genomics laboratory can query pathology
directly, these two free-text fields could be replaced by a reference
instead - the Pathology Order Filler Number, Pathology Patient Identifier
and/or Pathology Specimen Identifier - letting the genomic order carry a
pointer for on-demand lookup rather than the pathology detail itself.
The Questionnaires in this IG are regarded as Domain Archetypes
- a term
deliberately borrowed from openEHR
,
where an archetype is a formal, reusable model of a clinical/domain concept used to
elaborate a data model during a project's early stages, independent of how it's later
persisted or exchanged. FHIR logical models can serve the same elaboration purpose;
this IG uses Questionnaire
/ QuestionnaireResponse
instead, and the link to
openEHR's own archetype concept is intentional, not coincidental.
The twelve forms above are the NW GLH's own paper test request
forms
, plus the two
national
NHS Genomic Medicine Service (GMS) WGS forms NW GLH also uses
(distinct from the NW GLH-specific WGS local paper order) - each compared
directly against this Questionnaire below using the same fields every paper
order form needs to identify: NHS Number, Medical Record Number, Order
Placer Number, Account Number/Hospital Spell Identifier, Specimen
Identifier, Test Code, Ordering Facility, and Ordering Clinician (GMC/GMP).
Research summary (no NHS England-published order-comms/interoperability standard was
found for these fields)
: NHS England's published pathology standards
( Pathology Test and Results Standard
,
SNOMED CT for pathology reporting
)
do not cover Histocompatibility and Immunogenetics (H&I) order entry specifically. The
relevant national body is NHS Blood and Transplant (NHSBT)
, not NHS England: its
INF136 "User Guide for Histocompatibility and Immunogenetics Diagnostics
Services"
defines six national H&I request forms (Table 2) including FRM1008
"H&I Organ
Transplant (Patients and Donors)" and FRM1010
"H&I Haematopoietic Stem Cell
Transplantation (Recipients & Donors)", plus a sample-requirements table listing
"HLA type of patient, donors or family members
" for Solid Organ Transplantation -
confirming HLA Type is a fixed national list, not free text, even though NHSBT does not
publish a FHIR/LOINC/SNOMED binding for it. NHSBT's Solid Organ Transplantation section
(4.5.1) also describes 24-hour on-call cover for " renal
and, where appropriate,
cardiothoracic
transplantation", with liver/other transplant types noted separately
as not having HLA match as a primary factor - consistent with Patient Type being a
small, fixed list. The professional bodies BSHI
(British Society for
Histocompatibility and Immunogenetics) and BTS
(British Transplantation Society)
jointly publish clinical guidelines (e.g. the
2015 BTS/BSHI antibody characterisation guideline
)
but not data/interoperability standards. This IG's own dependency,
HL7's Genomics Reporting IG - Histocompatibility and Immunogenetic
Reporting
, profiles
structured HLA genotype/haplotype results
(LOINC 84413-4
Genotype display name,
48018-6
Gene studied, 13298-5
HLA-A [Type], the GL String and HGNC systems) but does
not address order-entry "ask at order" questions like these. See each item below for
LOINC panels and UK code lists relevant to that specific question.
Research summary (no NHS England-published order-comms/interoperability standard was
found for these fields)
: NHS England's published pathology standards
( Pathology Test and Results Standard
,
SNOMED CT for pathology reporting
)
do not cover Histocompatibility and Immunogenetics (H&I) order entry specifically. The
relevant national body is NHS Blood and Transplant (NHSBT)
, not NHS England: its
INF136 "User Guide for Histocompatibility and Immunogenetics Diagnostics
Services"
defines six national H&I request forms (Table 2) including FRM1008
"H&I Organ
Transplant (Patients and Donors)" and FRM1010
"H&I Haematopoietic Stem Cell
Transplantation (Recipients & Donors)", plus a sample-requirements table listing
"HLA type of patient, donors or family members
" for Solid Organ Transplantation -
confirming HLA Type is a fixed national list, not free text, even though NHSBT does not
publish a FHIR/LOINC/SNOMED binding for it. NHSBT's Solid Organ Transplantation section
(4.5.1) also describes 24-hour on-call cover for " renal
and, where appropriate,
cardiothoracic
transplantation", with liver/other transplant types noted separately
as not having HLA match as a primary factor - consistent with Patient Type being a
small, fixed list. The professional bodies BSHI
(British Society for
Histocompatibility and Immunogenetics) and BTS
(British Transplantation Society)
jointly publish clinical guidelines (e.g. the
2015 BTS/BSHI antibody characterisation guideline
)
but not data/interoperability standards. This IG's own dependency,
HL7's Genomics Reporting IG - Histocompatibility and Immunogenetic
Reporting
, profiles
structured HLA genotype/haplotype results
(LOINC 84413-4
Genotype display name,
48018-6
Gene studied, 13298-5
HLA-A [Type], the GL String and HGNC systems) but does
not address order-entry "ask at order" questions like these. See each item below for
LOINC panels and UK code lists relevant to that specific question.
Research summary (no NHS England-published order-comms/interoperability standard was
found for these fields)
: NHS England's published pathology standards
( Pathology Test and Results Standard
,
SNOMED CT for pathology reporting
)
do not cover Histocompatibility and Immunogenetics (H&I) order entry specifically. The
relevant national body is NHS Blood and Transplant (NHSBT)
, not NHS England: its
INF136 "User Guide for Histocompatibility and Immunogenetics Diagnostics
Services"
defines six national H&I request forms (Table 2) including FRM1008
"H&I Organ
Transplant (Patients and Donors)" and FRM1010
"H&I Haematopoietic Stem Cell
Transplantation (Recipients & Donors)", plus a sample-requirements table listing
"HLA type of patient, donors or family members
" for Solid Organ Transplantation -
confirming HLA Type is a fixed national list, not free text, even though NHSBT does not
publish a FHIR/LOINC/SNOMED binding for it. NHSBT's Solid Organ Transplantation section
(4.5.1) also describes 24-hour on-call cover for " renal
and, where appropriate,
cardiothoracic
transplantation", with liver/other transplant types noted separately
as not having HLA match as a primary factor - consistent with Patient Type being a
small, fixed list. The professional bodies BSHI
(British Society for
Histocompatibility and Immunogenetics) and BTS
(British Transplantation Society)
jointly publish clinical guidelines (e.g. the
2015 BTS/BSHI antibody characterisation guideline
)
but not data/interoperability standards. This IG's own dependency,
HL7's Genomics Reporting IG - Histocompatibility and Immunogenetic
Reporting
, profiles
structured HLA genotype/haplotype results
(LOINC 84413-4
Genotype display name,
48018-6
Gene studied, 13298-5
HLA-A [Type], the GL String and HGNC systems) but does
not address order-entry "ask at order" questions like these. See each item below for
LOINC panels and UK code lists relevant to that specific question.
Research summary (no NHS England-published order-comms/interoperability standard was
found for these fields)
: NHS England's published pathology standards
( Pathology Test and Results Standard
,
SNOMED CT for pathology reporting
)
do not cover Histocompatibility and Immunogenetics (H&I) order entry specifically. The
relevant national body is NHS Blood and Transplant (NHSBT)
, not NHS England: its
INF136 "User Guide for Histocompatibility and Immunogenetics Diagnostics
Services"
defines six national H&I request forms (Table 2) including FRM1008
"H&I Organ
Transplant (Patients and Donors)" and FRM1010
"H&I Haematopoietic Stem Cell
Transplantation (Recipients & Donors)", plus a sample-requirements table listing
"HLA type of patient, donors or family members
" for Solid Organ Transplantation -
confirming HLA Type is a fixed national list, not free text, even though NHSBT does not
publish a FHIR/LOINC/SNOMED binding for it. NHSBT's Solid Organ Transplantation section
(4.5.1) also describes 24-hour on-call cover for " renal
and, where appropriate,
cardiothoracic
transplantation", with liver/other transplant types noted separately
as not having HLA match as a primary factor - consistent with Patient Type being a
small, fixed list. The professional bodies BSHI
(British Society for
Histocompatibility and Immunogenetics) and BTS
(British Transplantation Society)
jointly publish clinical guidelines (e.g. the
2015 BTS/BSHI antibody characterisation guideline
)
but not data/interoperability standards. This IG's own dependency,
HL7's Genomics Reporting IG - Histocompatibility and Immunogenetic
Reporting
, profiles
structured HLA genotype/haplotype results
(LOINC 84413-4
Genotype display name,
48018-6
Gene studied, 13298-5
HLA-A [Type], the GL String and HGNC systems) but does
not address order-entry "ask at order" questions like these. See each item below for
LOINC panels and UK code lists relevant to that specific question.
Ask At Order Entry Questions
for NHS Blood and Transplant's (NHSBT) national
H&I Haematopoietic Stem Cell Transplantation (Recipients & Donors)
request form
( FRM1010
, form "3C" in NHSBT's own numbering) - see NHSBT's published
form
and Histocompatibility and
Immunogenetics
.
Ask At Order Entry Questions
for NHS Blood and Transplant's (NHSBT) national
H&I Organ Transplant (Patients and Donors)
request form ( FRM1008
, form "3B" in
NHSBT's own numbering) - see NHSBT's published
form
and Histocompatibility and
Immunogenetics
.
Each item's linkId
is the literal CSV column header, type
the FHIR datatype the
column's values coerce to, and definition
the FHIR field the column populates once
converted into the relevant FHIR Message - many of these reuse the exact same field as
the equivalent item already defined on Genomic Test Order
or iGene Work Order Export
, since
this is the same underlying order data plus report/result-specific columns those don't
carry. See NEYctDNA.csv
for the source file this was extracted from.
Each item's linkId
is the literal CSV column header, type
the FHIR datatype the
column's values coerce to, and definition
the FHIR field the column populates once
imported - many of these reuse the exact same field as the equivalent item already
defined on Genomic Test Order
, since a
sub-contracted work order carries the same underlying data as any other order. See
StarLIMS / iGene Integration - Work Order CSV Export from
iGene
for a simple description of each
column plus its FHIR mapping (also reused, unchanged, by OMICS DSS Result
Integration
), and
StarLIMSSampleData.csv
for the source file this was extracted from.
IHE PaLM Technical Framework Supplement - Specimen Event Tracking (SET)
- a specification for tracking specimen progress along this process (not adopted here - background/reference only)
IHE Specimen Event Tracking (SET)
is a specification for tracking the progress of specimens along this process, from
collection through to storage, biobanking or disposal. It defines a Specimen Event
Informer (SEI)
actor, which sends specimen lifecycle event messages ( LAB-40
) to a
Specimen Event Tracker (SET)
actor - covering around 15 distinct event types
across collecting, shipping, receiving and accepting a specimen. This would be the
natural specification to formalise the manual steps above, were this process ever
automated - not adopted here.
GS1 UK Healthcare
publishes UK
barcode standards (typically carried in a GS1 DataMatrix or GS1-128 symbol) that
could be used to encode the key identifiers
above on the test
request paperwork or shipping package, so they can be scanned rather than re-keyed -
not mandated here. GS1 identifies people, places and things using a small number of
standard identification keys, each with its own numeric Application Identifier (AI,
shown in brackets) inside the barcode:
Printed on a GS1-compliant patient wristband
under the NHS Scan4Safety programme; the NHS Number itself is the local reference the GSRN resolves to, not encoded directly
GS1's GDTIAI (253)
(Global Document Type Identifier) could identify the test request document
itself, but is not commonly used for this in UK pathology; more often carried as free text/local barcode alongside the GS1 keys above
GS1 UK's own pathology guidance
recommends a GIAI per specimen carrier (tube, slide, etc.), assigned when the specimen is taken or the carrier manufactured, and unchanged as it passes between laboratories
(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 codes SHOULD be taken from For example codes, see
Problems - IPS http://hl7.org/fhir/ValueSet/condition-code|4.0.1
( preferred
to http://hl7.org/fhir/uv/ips/ValueSet/problems-uv-ips
)
Identification of the condition, problem or diagnosis Binding:
Problems - IPS (preferred): Valueset to describe the actual problem experienced by the patient
The underlying concept - numbering a family/pedigree as a unit, distinct from
numbering each individual - is rooted in general clinical genetics/genetic
counselling practice, standardised by the National Society of Genetic
Counselors' pedigree
nomenclature
,
not invented by any single genomics programme.
HOSPITAL PROVIDER SPELL IDENTIFIER
-
a unique identifier for a period of care under one Trust (admission to
discharge), assigned by the PAS/EPR. No national OID; each Trust assigns its
own.
LOCAL PATIENT IDENTIFIER
-
a hospital-assigned identifier, not a nationally-issued number. There is no
single national OID or value format; each Trust's PAS/EPR assigns its own.
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
.
No NHS Data Dictionary entry for the general (pathology/genomics) specimen
accession number - it is a laboratory-assigned identifier, not a nationally
defined one. The closest NHS Data Dictionary analogue is
RADIOLOGICAL ACCESSION NUMBER
,
which applies to imaging studies rather than specimens.
In pathology and genomics, the accession number refers to the Specimen.
In imaging the accession number refers to the imaging test RADIOLOGICAL ACCESSION NUMBER
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 Orchestration 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.
Phase 2, elaborated in notebook 06 - EU Laboratory Report: FHIR Messages to a FHIR Document
, again wire-taps the LAB-3/ ORU_R01
feed, but this time the RIE also retrieves the linked Reportable Variant Observations (see OMICS DSS Result Integration
) from the FHIR Repository and combines them with the report. The result is wrapped in an HL7 Europe Laboratory Report FHIR Document - a Composition
-led Bundle
of type document
- and sent to the national solution, corresponding to the "Future Composition / Aggregated Laboratory Report" placeholder in overview.md
.
Each row of the source manifest ( Input/dWGS.csv
) gives one referral participant,
shown below in three forms: the QuestionnaireResponse
answering dWGS Sub-Order
Manifest
, the LAB-35
sub-order Bundle
it was
extracted into (same referrals and participants as the table above), and the HL7 v2
OML^O21
equivalent of that same Bundle (from
nw-gmsa/Testing
):
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
.
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
.
National NHS bodies
(e.g. NHS England, PDS, ODS) and NHS Trusts
are, in
Domain Driven Design
terms, natural bounded
contexts
in their own
right, each with its own internal data model - this guide doesn't cover
those models
. Instead, this guide's resources reference that data via
identifiers
(in FHIR, Reference.identifier
), rather than modelling
those bounded contexts directly.
National NHS bodies
(e.g. NHS England, PDS, ODS) and NHS Trusts
are, in
Domain Driven Design
terms, natural bounded
contexts
in their own
right, each with its own internal data model - this guide doesn't cover
those models
. Instead, this guide's resources reference that data via
identifiers
(in FHIR, Reference.identifier
), rather than modelling
those bounded contexts directly.
The relationship between
bounded contexts like these is what Enterprise
Integration
Patterns
calls a Canonical Data Model
, and what Data Engineering calls a Data
Contract
- in HL7 FHIR terms,
that's expressed as FHIR Profiles and the core models described below.
ServiceRequest
and DiagnosticReport
are the two separate aggregates
(in the Domain-Driven Design
sense) this model is built around - each with its own extension mechanism.
This basic patten is the exchange of records via Document Messaging
and is supported by a wide area of Messaging Patterns
In NHS Trusts this is often supported by a Trust Integration Engine.
This is the default option for HL7 v2 and in FHIR this is known as FHIR Messaging
This basic patten is the exchange of records via Document Messaging
and is supported by a wide area of Messaging Patterns
In NHS Trusts this is often supported by a Trust Integration Engine.
This is the default option for HL7 v2 and in FHIR this is known as FHIR Messaging
Electronic Document Management (EDM) is a common practice for storing and sharing documents across healthcare systems and common formats for the documents are often PDF. In diagnostics this is not desirable and so instead a document format called Clinical Document Architecture (CDA)
, in HL7 FHIR this is known as FHIR Document
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 Specification
should be followed and SHALL
be used in ORC-21.
For reports, the RIE will wire-tap
the ORU_R01
to send a copy of the report to a Shared Care Record - see
Regional Shared Care Records
for the detailed
convert/filter/deliver process (and its Lancashire and South Cumbria stub),
and ctDNA NHS England Unified Genomic Record (UGR)
for how
the NHS England Unified Genomic Record Phase 1 adapts the same wire-tap.
The data models used in these interactions follow a core canonical model ( nw-gmsa.github.io/en/diagnostic-core.html
) which is documented as a series of HL7 FHIR profiles and can be implemented in HL7 v2, ASTM, FHIR and other formats.
02 - Work Orders: A Worked Example
- finding a laboratory's current work orders ( Task
-based filtering) for Liverpool GLH (ODS K1S6S
), one of the regional LIMS the RIE integrates
04 - Reports: HL7 v2 ORU^R01 into FHIR
- converts a lab's own HL7 v2 report into a FHIR R01
Message, and on to the MDM_T02
document feed sent to shared care record providers
The proposed DLIMS work order metadata export (see Future Process
above, "mirroring the process already used for StarLIMS") is expected to reuse the same
CSV shape as iGene's existing StarLIMS work order export - see StarLIMS / iGene
Integration - Work Order CSV Export from iGene
for the canonical version of this table (kept there to avoid the two drifting apart) and
StarLIMSSampleData.csv
for an example file. DLIMS/Omics DSS work orders carry the same underlying
order/patient/specimen data as a StarLIMS work order, just a different downstream
processor:
02 - Work Orders: A Worked Example
- worked example of retrieving orders from the Resource Access Provider (FHIR Repository), the mechanism used by both the existing sub-contracting path and the future RIE-routed path (see Developer Guides
)
The regional integration engine (RIE) picks up these files and stores them in the FHIR Repository as Patient, ServiceRequest, and Specimen resources. Details of this data model are available at nw-gmsa.github.io/en/diagnostic-core.html
.
02 - Work Orders: A Worked Example
- worked example of retrieving orders from the Resource Access Provider (FHIR Repository), the mechanism used by both the existing sub-contracting path and the future RIE-routed path
