StructureDefinition AuditEvent

Created by the central GMS infrastructure on any CRUD event.

Can be searched on for auditability and obtaining status history for Tasks (as an alternative to the Task _history option).

It is not expected or permitted that a client system would update or post AuditEvents to the central service.

AuditEvents are expected to be created for any CRUD events which affect resources on the server. Where resources do not exist on the server, e.g. empty SearchSets or failed POSTs, no AuditEvents will be created. Failed updates may still trigger creation of AuditEvent resources but the outcome.code will record that the event was unsuccessful.

AuditEvents for resources created by the server will record the server identity within the who element.

The below profile is therefore provided to support parsing for clients if returned through a GET request.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/AuditEvent HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
typeΣ1..1CodingBinding
subtypeΣ0..*CodingBinding
actionΣ0..1codeBinding
periodI0..1Period
recordedΣ1..1instant
outcomeΣ0..1codeBinding
outcomeDescΣ0..1string
purposeOfEventΣ0..*CodeableConceptBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
type0..1CodeableConceptBinding
role0..*CodeableConcept
whoΣ I0..1Reference(PractitionerRole | Practitioner | Organization | Device | Patient | RelatedPerson)
altId0..1string
name0..1string
requestorΣ1..1boolean
locationI0..1Reference(Location)
policy0..*uri
media0..1CodingBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
address0..1string
type0..1codeBinding
purposeOfUse0..*CodeableConceptBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
site0..1string
observerΣ I1..1Reference(PractitionerRole | Practitioner | Organization | Device | Patient | RelatedPerson)
type0..*CodingBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
whatΣ I0..1Reference(Resource)
type0..1CodingBinding
role0..1CodingBinding
lifecycle0..1CodingBinding
securityLabel0..*CodingBinding
nameΣ I0..1string
description0..1string
queryΣ I0..1base64Binary
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
type1..1string
valueStringstring
valueBase64Binarybase64Binary



Additional Guidance

action

SHALL be present. Code from base HL7 resource, only C (create), R (read) and U (update) would usually be expected.
"action": "U",

agent

SHOULD be present for any user initiated actions. Reference to the user or system that triggered the creation/read/update. Identity SHOULD be determined through the appropriate authentication token within the request header, e.g. CIS2 auth token.
"agent":  [
        {
            "type": {
                "coding":  [
                    {
                        "system": "http://terminology.hl7.org/CodeSystem/v3-ParticipationType",
                        "code": "AUT",
                        "display": "author (originator)"
                    }
                ]
            },
            "who": {
                "reference": "PractitionerRole/PractitionerRole-TestClinicalScientist-Example",
                "identifier": {
                    "system": "https://fhir.nhs.uk/Id/sds-user-id",
                    "value": "9999999997"
                }
            },
            "name": "Test Clinical Scientist",
            "requestor": true
        }
    ],

entity

SHOULD be present where the resource exists on the server. Reference to the resource which was affected by the event.
"entity":  [
        {
            "what": {
                "reference": "Task/Task-NonWGSRareDiseaseTestOrderRejected-Example"
            },
            "type": {
                "system": "http://hl7.org/fhir/resource-types",
                "code": "Task",
                "display": "Task"
            },
            "role": {
                "system": "http://terminology.hl7.org/CodeSystem/object-role",
                "code": "20",
                "display": "Job"
            }
        }
    ]


StructureDefinition BodyStructure

The Genomics BodyStructure is currently based on the HL7 international version of the resource as a profile for BodyStructure does not exist in UKCore. Once this profile becomes active in UKCore its suitability for use and need for profiling within Genomics will be assessed.

The base BodyStructure resource is provided below for completeness.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/BodyStructure HL7 International trial-use

Usage

Use of this resource is meant to replace the Genomics extensions for topology and morphology on the Specimen profile

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
activeΣ ?!0..1boolean
morphologyΣ0..1CodeableConcept
locationΣ0..1CodeableConcept
locationQualifier0..*CodeableConcept
descriptionΣ0..1string
imageI0..*Attachment
patientΣ I1..1Reference(Patient)


FHIRMDSHL7v2
BodyStructure.morphologyPrimary Sample - Solid tumour morphologyAdditional SPM-4/5 qualifiers
BodyStructure.locationPrimary Sample - Solid tumour histological type (topography)SPM-8

StructureDefinition Bundle

The Genomics Bundle is currently pending Clinical and Technical Assurance of the base UKCore resource. Once this profile becomes active in UKCore its suitability for use and need for profiling within Genomics will be assessed.

The profile for the UKCore-Bundle is provided below for completeness.

Bundles within Genomics will be limited to Transactions for Test orders and updates; Transaction-responses for responses to transactions (housing sets of OperationOutcomes); or Searchsets, returned in response to search queries.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/Bundle HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
identifierΣ0..1Identifier
typeΣ1..1codeBinding
timestampΣ0..1instant
totalΣ I0..1unsignedInt
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
relationΣ1..1string
urlΣ1..1uri
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
fullUrlΣ0..1uri
resourceΣ0..1Resource
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
modeΣ0..1codeBinding
scoreΣ0..1decimal
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
methodΣ1..1codeBinding
urlΣ1..1uri
ifNoneMatchΣ0..1string
ifModifiedSinceΣ0..1instant
ifMatchΣ0..1string
ifNoneExistΣ0..1string
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
statusΣ1..1string
locationΣ0..1uri
etagΣ0..1string
lastModifiedΣ0..1instant
outcomeΣ0..1Resource
signatureΣ0..1Signature


Additional Guidance

type

SHALL be present. The type of Bundle. This is expected to be `transaction` for Bundles POSTed to the central broker, `transaction-response` for responses to transaction Bundles returned by the broker and `searchset` for collections of resources returned in response to search (GET) requests, as per standard HTTP FHIR rules.
"type": "transaction",

total

Only relevant for searchset Bundles. Details the number of resources in the bundle matching the search criteria, not including resources included via the _include criteria.
"total": 3,

link

Only relevant for searchset bundles. Details the query string that resulted in the searchset (to allow future queries using the same parameters). `"relation": "self"` will only ever be used.

Links related to response pagination such as next/prev are pending Non-Functional Requirements finalisation for the order management central broker.

"link": [
        {
            "relation": "self",
            "url": "https://api.service.nhs.uk/genomic-order-management-service/FHIR/R4/Specimen/?_include=Specimen%3Asubject&identifier=RGT03135"
        }
    ],

entry

Transactions

An entry in the bundle. For transaction Bundles, each entry SHOULD contain a fullURL to ensure resources in the Bundle can reference each other, these can be the locations within the source system or urn:uuids.

Resources are expected to contain ids to allow referencing within Bundles, though these will be replaced by server assigned ids when saved by the central broker. If additional identifiers need to be persisted e.g. NHS Number, these should be captured within the identifier field.

Transaction Bundle entries also SHALL contain a request object, specifying the method (either PUT for updates or POST for creates) and the url to send the resource to (equivalent to the resource type for the resource).

Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS

"entry": [
        {
			"fullUrl": "http://example.org/fhir/Specimen/Specimen-BloodEDTA-Example",
			"resource": {
				"resourceType": "Specimen",
				"id": "Specimen-BloodEDTA-Example",
				"identifier": [
					{
						"system": "https://fhir.add.nhs.uk/Id/specimenId",
						"value": "RGT03135"
					}
				],
				"status": "unavailable",
				"type": {
					"coding": [
						{
							"system": "http://snomed.info/sct",
							"code": "445295009",
							"display": "Blood specimen with EDTA"
						}
					]
				},
				"subject": {
					"reference": "Patient/Patient-MeirLieberman-Example",
					"identifier": {
						"system": "https://fhir.nhs.uk/Id/nhs-number",
						"value": "9449307873"
					}
				},
				"request": [
					{
						"reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-Example"
					}
				]
			},
            "request": {
                "method": "POST",
                "url": "Specimen"
            }
		}
	]

Transaction Responses

These Bundles are returned in response to transaction requests. These will only contain OperationOutcome resources (one for each recource contained in the transaction request). See Acknowledgements and responses for more information.

These entries will contain a response object detailing the response status of the individual resource operation and an OperationOutcome detailing any relevant diagnostics, such as validation messages.

Entries will also contain a location element, detailing the relative path of the resource, where the operation has resulted in a resource being created or updated. These URLs will be version specific (using the _history suffix to denote the version number of the resource) if the resource has been updated.

"entry": [
    {
      "response": {
        "status": "201 Created",
        "location": "ServiceRequest/4d70678c-81e4-4ff4-8c67-17596fd0aa46/",
        "lastModified": "2024-01-30T12:01:24Z",
        "outcome": {
          "resourceType": "OperationOutcome",
          "meta": {
            "lastUpdated": "2024-01-30T12:01:24Z"
          },
          "issue": [
            {
              "severity": "information",
              "code": "informational",
              "diagnostics": "No issues detected during validation."
            }
          ]
        }
      }
    }
  ]

Searchsets

These Bundles are returned in response to GET requests without an ID. entries within these bundles will depend on the endpoint queried and the search parameters included.

Each entry is expected to include a fullUrl identifying the URL that can be used to retrieve the resource on the server; the resource itself; and a search element detailing whether the resource was included in the search response due to it matching the query parameters, "mode": "match", or whether it was included via the _include parameter, "mode": "include".

"entry": [
        {
            "fullUrl": "https://api.service.nhs.uk/genomic-order-management-service/FHIR/R4/44707473",
            "resource": {
                "resourceType": "Specimen",
                "id": "44707473",
                "meta": {
                    "versionId": "1",
                    "lastUpdated": "2024-05-13T14:28:05.843+00:00",
                    "source": "#CJ6XJLTGD315XL2Z"
                },
                "identifier": [
                    {
                        "system": "https://fhir.add.nhs.uk/Id/specimenId",
                        "value": "RGT03135"
                    }
                ],
                "status": "unavailable",
                "type": {
                    "coding": [
                        {
                            "system": "http://snomed.info/sct",
                            "code": "445295009",
                            "display": "Blood specimen with EDTA"
                        }
                    ]
                },
                "subject": {
                    "reference": "Patient/44707475",
                    "identifier": {
                        "system": "https://fhir.nhs.uk/Id/nhs-number",
                        "value": "9449307946"
                    }
                },
                "request": [
                    {
                        "reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-Example"
                    }
                ]
            },
            "search": {
                "mode": "match"
            }
        }
    ]


StructureDefinition UKCore-Composition

Compositions within Genomics will be limited to documents generated by the central broker for capturing snapshots of Test orders and results in order to maintain historical accuracy, as per the DocumentReference generate OperationDefinition. These will typically form the first entry of a Document Bundle and as such will not be exposed via their own endpoint, nor allow creates,reads or updates from client systems on the resource itself.

Usage of the Compostion resource and generation of documents is pending internal review

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Composition UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
careSettingTypeI0..1Extension(CodeableConcept)
modifierExtension?! I0..*Extension
identifierΣ0..1Identifier
statusS Σ ?!1..1codeBinding
typeS Σ1..1CodeableConceptBinding
categoryΣ0..*CodeableConceptBinding
subjectS Σ I0..1Reference(Resource)
encounterΣ I0..1Reference(Encounter)
dateΣ1..1dateTime
authorS Σ I1..*Reference(Practitioner | PractitionerRole | Device | Patient | RelatedPerson | Organization)
titleΣ1..1string
confidentialityS Σ0..1codeBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
mode1..1codeBinding
time0..1dateTime
partyI0..1Reference(Patient | RelatedPerson | Practitioner | PractitionerRole | Organization)
custodianS Σ I0..1Reference(Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
code1..1codeBinding
targetIdentifierIdentifier
targetReferenceReference(Composition)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
codeΣ0..*CodeableConcept
periodΣ I0..1Period
detailΣ I0..*Reference(Resource)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
title0..1string
code0..1CodeableConceptBinding
authorI0..*Reference(Practitioner | PractitionerRole | Device | Patient | RelatedPerson | Organization)
focusI0..1Reference(Resource)
textI0..1Narrative
mode0..1codeBinding
orderedBy0..1CodeableConceptBinding
entryI0..*Reference(Resource)
emptyReasonI0..1CodeableConceptBinding
sectionI0..*see (section)


FHIRMDSHL7v2

Additional Guidance

status

Fixed value of 'final'
"status": "final",

type

SNOMED CT code for either a Laboratory Request (24691000000102) or Genetic report (1054161000000101)
"type": {
    "coding": [
        {
            "system": "http://snomed.info/sct",
            "code": "1054161000000101",
            "display": "Genetic report (record artifact)"
        }
    ]
},

subject

Matches subject reference included in either the DiagnosticReport or ServiceRequest
"subject": {
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9999999999"
        }
    },

date

SHALL be the dateTime the Composition was generated by the central broker
"date": "2022-07-11T09:00:00Z",

author

Fixed to an identifier for the central broker (TBC). The author for the underlying ServiceRequest or DiagnosticReport can be retrieved by interrogating the appropriate resources.
"author": [
    {
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/spine-ASID",
            "value": "200000000215"
        }
    }
],

title

SHALL match the SNOMED CT display used within Composition.type
"title": "Genetic report (record artifact)",

section

SHALL only include the ServiceRequest or DiagnsoticReport forming the base of a GraphDefinition.
"section": [
    {
        "mode": "snapshot",
        "entry": [
            {
                "reference": "DiagnosticReport/DiagnosticReport-AnitaLamberts-Example"
            }
        ]
    }
]


StructureDefinition UKCore-Condition

For detailing any Condition related information about the proband/consultands within a test order.

It is expected that the information used to populate this resource SHOULD be sourced from the requesters EHR system. As such, there is no limit on the amount of detail that can be provided, though at a minimum the code and subject fields SHOULD be populated.

It is also highly preferred if the verificationStatus, onsetDateTime, recordedDate, recorded and abatementDateTime are populated if applicable/known.

The primary condition, being tested for SHOULD be referenced via ServiceRequest.reasonReference, additional relevant conditions SHOULD be referenced via ServiceRequest.supportingInfo.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Condition UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
bodyStructureR6I0..1Extension(Reference(BodyStructure))
conditionEpisodeI0..*Extension(CodeableConcept)
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
clinicalStatusS Σ ?! I0..1CodeableConceptBinding
verificationStatusS Σ ?! I0..1CodeableConceptBinding
category0..*CodeableConceptBinding
severityS0..1CodeableConceptBinding
codeS Σ0..1CodeableConceptBinding
bodySiteΣ0..*CodeableConceptBinding
subjectS Σ I1..1Reference(Patient | Group)
encounterΣ I0..1Reference(Encounter)
onsetDateTimedateTime
onsetAgeAge
onsetPeriodPeriod
onsetRangeRange
onsetStringstring
abatementDateTimedateTime
abatementAgeAge
abatementPeriodPeriod
abatementRangeRange
abatementStringstring
recordedDateΣ0..1dateTime
recorderS Σ I0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)
asserterΣ I0..1Reference(Practitioner | PractitionerRole | Patient | RelatedPerson)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
summaryI0..1CodeableConcept
assessmentI0..*Reference(ClinicalImpression | DiagnosticReport | Observation)
type0..1CodeableConcept
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
codeΣ I0..*CodeableConcept
detailΣ I0..*Reference(Resource)
note0..*Annotation


FHIR MDS HL7v2
Condition Patient Clinical Presentation, Diabetic complications DG1
Condition.bodySite Has multiple primary tumours, Count of tumours, Site of tumour (many), Abnormal infection history site, Abnormal infection history site organism Multiple DG1 segments (bodySite for condition not in scope for HL7v2)
Condition.verificationStatus Known/suspected disease DG1-6
Condition.recordedDate Date of diagnosis, Diagnosis during pregnancy DG1-5
Condition.clinicalStatus Disease status, Is patient in treatment free remission, Is diabetes in remission Potentially mapped to DG1-17
Condition.code Phenotypic details (Many), Solid tumour type, Liquid tumour type, Laterality of hearing loss, Fetal maternal screening genotype, Fetal paternal screening genotype, Thyroid gland state, Pituitary tumour type, Pancreatic tumour type, Phaeochromocytoma, Progeroid features, Severity of hearing loss, Retinal degeneration, Hepatic vs neurological presentation, Suspected inborn error type(s) Additional DG1 segments (DG1-3)
Condition.onsetDateTime Date of disease onset, Duration of hyperinsulism (when compared to abatementDateTime for non OML messages PRB-16
Condition.evidence.detail( reference( FamilyMemberHistory, Media ) ) Pedigree details/diagram, Disease penetrance N/A not in scope for HL7v2, could be added as additional DG1 segments related to relatives (representation of family history in HL7v2 still pending investigation)
Condition.evidence.code Symptoms at onset Separate DG1 with DG1-17=S

Additional Guidance

extension:bodyStructureR6

Extension provided to allow users to ascribe topology and morphology items to conditions themselves. For collection of body structure information for primary and secondary tumours separately, these should be referenced from conditions associated with the primary and secondary tumour respectively.
"extension": [
{
"url": "http://hl7.org/fhir/6.0/StructureDefinition/extension-Condition.bodyStructure",
"valueReference": {
"reference": "BodyStructure/BodyStructure-BodySiteLocationLungs-Example"
}
}
]

code

SHOULD be present. SNOMED CT coding is preferred, though alternative codings MAY be provided subject to review of the Coding system by the NHS England Genomics Unit.
"code": {
"coding": [
{
"system": "http://snomed.info/sct",
"code": "95820000",
"display": "Bilateral hearing loss"
}
]
},

subject

SHALL be present. Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
"reference": "Patient/Patient-MeirLieberman-Example",
"identifier": {
"system": "https://fhir.nhs.uk/Id/nhs-number",
"value": "9449307873"
}
},

note

For recording additional information regarding the condition where this does not fit into the structured fields or cannot be structured due to the way this information has been recorded in source systems.
"note": [
{
"text": "hearing loss since childhood (example)"
}
]


StructureDefinition UKCore-DiagnosticReport

The requirements of a specific Genomics DiagnosticReport is currently under review.

The draft profile is provided below for completeness.

Currently, only requirements for initial Pathology reports, provided with a test order, have been reviewed. DiagnosticReports containing the results of genomic testing are expected to be attached/provided as PDF documents during the alpha phase of the GMS development programme.

It is expected structured DiagnosticReports will mimic the structure proposed within the HL7 International Genomic Reporting IG, though customizations for use within the UK still need to be investigated.

Genomic DiagnosticReports which have been updated post submission SHALL be accompanied by Provenance resources, referencing the DiagnosticReport which detail when the resource was changed, who made the change and why.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-DiagnosticReport UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(Composition)
mediaR5I0..*Extension(Complex)
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueAnnotationAnnotation
id0..1string
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueCodeableConceptCodeableConcept
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(Procedure | Observation | DiagnosticReport)
url1..1uriFixed Value
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
basedOnI0..*Reference(CarePlan | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest)
statusS Σ ?!1..1codeBinding
categoryS Σ0..*CodeableConcept
codeS Σ1..1CodeableConceptBinding
subjectS Σ I0..1Reference(Patient | Group | Device | Location)
encounterS Σ I0..1Reference(Encounter)
effectiveDateTimedateTime
effectivePeriodPeriod
issuedS Σ0..1instant
id0..1string
deviceReferenceI0..1Extension(Reference(Device))
referenceΣ I0..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
id0..1string
deviceReferenceI0..*Extension(Reference(Device))
referenceΣ I0..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
specimenI0..*Reference(Specimen)
resultS I0..*Reference(Observation)
imagingStudyI0..*Reference(ImagingStudy)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
comment0..1string
conclusion0..1string
conclusionCode0..*CodeableConceptBinding
presentedFormI0..*Attachment


FHIRMDSHL7v2
DiagnosticReportPrevious Genomic Report, Previous Diagnostic ReportOBX
DiagnosticReport.effectiveDateTimePLCM activity - Date and time dataset created, PLCM activity - Turnaround time (calendar days), Previous genomic report - Test performed date, Previous non genomic report - Test performed dateDerived from OBR-7 in the ORU response message for the activity based on the OML request, OBX-19
DiagnosticReport.identifierPLCM activity - Local report identifier, Previous genomic report - Report identifier, Previous non genomic report - Report identifierOBR-3 for report
DiagnosticReport.resultPLCM activity - Test outcome code (Many), Previous non genomic report - Test result value comparator, Previous non genomic report - Test result value unit of measure, Previous non genomic report - Test result reference range low, Previous non genomic report - Test result reference range high, Previous non genomic report - Test result test method, Previous non genomic report - Test result reference range text, Previous non genomic report - Test result clinical summaryOBX-3 elements for resulting report, OBX-5, OBX-6, OBX-7 (before operator), OBX-7 (after operator), OBX-17, OBX-7, OBX-8
DiagnosticReport.conclusionPrevious genomic report - Report referral summary, Previous non genomic report - Report referral summaryOBX-5
DiagnosticReport.presentedFormPrevious genomic report - Report file/link, Previous non genomic report - Report file/linkOBX-5 where OBX-2=ED or RP
DiagnosticReport.subjectPrevious genomic report - Patient's first name, Previous genomic report - Patient's surname, Previous genomic report - Patient's address, Previous genomic report - Patient's post code, Previous genomic report - Patient's country, Previous genomic report - Patient's date of birth, Previous genomic report - Patient's NHS number, Previous genomic report - Patient's alternative identifier, Previous genomic report - Patient's relationship to requesting patient, Previous genomic report - Patient's clinical genetics number, Previous genomic report - Patient's pedigree numberPID attached to Patient Prior
DiagnosticReport.basedOnPrevious genomic report - Report lab test number, Previous genomic report - Original requester full name, Previous genomic report - Original requester organisation ODS code, Previous genomic report - Original requester reason for request, Previous non genomic report - Original requester full name, Previous non genomic report - Original requester organisation ODS code, Previous non genomic report - Original requester reason for requestORC-2, ORC-12, ORC-21.10, ORC-16
DiagnosticReport.conclusionCodePrevious genomic report - Report of genetic analysis, Previous non genomic report - Report resultOBR-5
DiagnosticReport.performerPrevious genomic report - Report performer full name, Previous genomic report - Report performer organisation ODS code, Previous non genomic report - Report performer full name, Previous non genomic report - Report performer organisation ODS codeOBX-16, OBX-23.10
DiagnosticReport.codePrevious non genomic report - Test typeOBR-4

Additional Guidance

extension:mediaR5

TBC. Only relevant for structured genomic reports. Reference to DocumentReference resources pointing to the Genomic Data Files used as the basis for the report. Usage of this field over extension:supporting-info is pending further investigation.
"extension" : [
        {
            "url" : "http://hl7.org/fhir/5.0/StructureDefinition/extension-DiagnosticReport.media.link",
            "extension" : [
                    {
                        "url" : "link",
                        "valueReference": {
                            "reference" : "DocumentReference/DocumentReference-PharmCAT-Example"
                        }
                    }
                ]
            }
        }
    ],

extension:recommended-action

TBC. Only relevant for structured genomic reports (included in the [Genomic Report Profile in the Genomics Reporting IG](https://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-genomic-report.html)). Reference to Task resource indicating recommended action to take in response to the report's result/conclusion.
"extension" : [
        {
            "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/recommended-action",
            "valueReference" : {
                "reference" : "Task/MedicationRecommendationExample1"
            }
        }
    ],

extension:genomic-study

TBC. Only relevant for structured genomic reports (included in the [Genomic Report Profile in the Genomics Reporting IG](https://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-genomic-report.html)). Reference to Procedure resources indicating the analyses performed as part the genomic test order.
"extension" : [
    {
      "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genomic-study-reference",
      "valueReference" : {
        🔗 "reference" : "Procedure/PGXGenomicStudy"
      }
    }
  ]

extension:supporting-info

TBC. Only relevant for structured genomic reports (included in the [Genomics Report IG Genomic Report Profile](https://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-genomic-report.html)). Reference to the genomic data files analysed as part of the test order, forming the report. Reference to DocumentReference resource which links to the binary data file. ```json "extension" : [ { "url" : "http://hl7.org/fhir/StructureDefinition/workflow-supportingInfo", "valueReference" : { "reference" : "DocumentReference/DocumentReference-PharmCAT-Example" } } ], ```

extension:workflow-relatedArtifact

TBC. Only relevant for structured genomic reports (included in Genomic Report Profile in the Genomics Report IG) . A reference to the guidelines or other knowledge artifacts which were used to guide interpretation or recommended actions included within this DiagnosticReport.

If entries constitute published papers, they SHOULD be referenced using a known citation style, e.g. Vancouver/Harvard. Alternatively for online texts, these MAY be referenced via URL only.

A fixed value of 'citation' is expected for the type element, though this recommendation is pending further use cases.

"extension" : [
        {
            "url" : "http://hl7.org/fhir/StructureDefinition/workflow-relatedArtifact",
            "valueRelatedArtifact" : {
                "type" : "citation",
                "url" : "https://cpicpgx.org/guidelines/guideline-for-clopidogrel-and-cyp2c19)"
            }
        }
    ],

basedOn

SHOULD reference the originating ServiceRequest if this is an instance of a genomic diagnostic report resulting from a GMS test order.
"basedOn":  [
        {
            "reference": "ServiceRequest-SavedTestOrder-Example"
        }
    ],

status

SHALL use base HL7 codes for DiagnosticReport.status. A DiagnosticReport SHOULD only be marked as final if the report is complete and verified by an authorised person.
 "status": "final",

code

SHOULD use a record artifact concept from SNOMED CT where an appropriate code exists, else text is preferred to indicate the document type.
"code": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "4321000179101",
                "display": "Hematology report (record artifact)"
            }
        ]
    },

subject

SHALL be present. Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

performer

SHOULD reference the organization responsible for the testing, preferably by ODS code.
"performer":  [
        {
            "identifier": {
                "system": "https://fhir.nhs.uk/Id/ods-organization-code",
                "value": "REP"
            }
        }
    ],

resultInterpreter

SHOULD reference the person responsible for interpreting the raw results, preferably by a recognised NHS identifier, such as SDS code.
"resultsInterpreter":  [
        {
            "identifier": {
                "system": "https://fhir.nhs.uk/Id/sds-user-id",
                "value": "999999999999"
            }
        }
    ],

specimen

SHOULD reference the specimen used during testing to generate the report, if the document is a Genomic report.
"specimen":  [
        {
            "reference": "Specimen/Specimen-BloodEDTA-Example"
        }
    ],

conclusionCode

If possible, unstructured reports wrapped within DiagnosticReports, SHOULD contain a conclusionCode element indicating the coded finding from the report, to aid analytics.
"conclusionCode":  [
        {
            "coding":  [
                {
                    "system": "http://snomed.info/sct",
                    "code": "738542003",
                    "display": "Dihydropyrimidine dehydrogenase poor metabolizer (finding)"
                }
            ]
        }
    ],

presentedForm

Genomic reports SHALL include a presentedForm element either referencing the location of the PDF report (located and accessible on either the source/client system or via NRL using appropriate authentication) or include the PDF report as a base64 encoded attachment within the message payload.

Note: this guidance may change in the future as work on Structured Reporting matures

"presentedForm": [
        {
            "url": "https://example.com/GenomicReports/ExampleReport.pdf"
        }
    ]

result

Raw results included within the report, to aid interpretation. These SHOULD take the form of Observation references, if providing a structured report.
"result" : [
        {
            "reference" : "Observation/TherapeuticImplicationExample1",
            "display" : "impact for high risk allele"
        },
        {
            "reference" : "Observation/GenotypeExample1"
        },
        {
            "reference" : "Observation/OverallInterpExample1"
        }
    ]


StructureDefinition DocumentReference

The DocumentReference resource is used to reference data files generated as part of genomic testing and allow these files to be retrieved through the DRS API standard.

Primarily, the ServiceRequest SHALL be referenced via DiagnosticReport.basedOn. The DocumentReference then links back to the report via DocumentReference.context.related.

If following the Genomic Reporting IG, you could also reference the DocumentReference from the DiagnosticReport using the following chain: DiagnosticReport.extension:genomic-study -> Procedure (Genomic Study).extension:genomic-study-analysis -> Procedure (Genomic Study Analysis).extension:output.extension:file.valueReference -> DocumentReference (Genomic Data File)

This requires use of the Genomic Study and Genomic Study Analysis profiles which have not yet been assessed for suitability in the UK. As such, this reference chain is only provided for reference.

The NHS England Genomics unit is also investigating backporting the R5 DiagnosticReport.media.link reference to DocumentReference to support referencing the data files from the DiagnosticReport directly. Until investigation is complete, DiagnosticReport resources MAY reference the DocumentReference for the data used by the report though the DiagnosticReport.extension:supporting-info element. In all cases the DocumentReference SHOULD reference the DNA Specimen from which the data originated and the ServiceRequest which triggered the capture of the data.

The Genomics-DocumentReference is currently based on the HL7 international version of the resource as the UKCore-DocumentReference profile is still in a draft status (and is pending use cases from the Unified Genomic Record project). Once this profile becomes active in UKCore its suitability for use and need for profiling within Genomics will be assessed.

The base DocumentReference resource is provided below for completeness.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/DocumentReference HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
masterIdentifierΣ0..1Identifier
identifierΣ0..*Identifier
statusΣ ?!1..1codeBinding
docStatusΣ0..1codeBinding
typeΣ0..1CodeableConceptBinding
categoryΣ0..*CodeableConcept
subjectΣ I0..1Reference(Patient | Practitioner | Group | Device)
dateΣ0..1instant
authorΣ I0..*Reference(Practitioner | PractitionerRole | Organization | Device | Patient | RelatedPerson)
authenticatorI0..1Reference(Practitioner | PractitionerRole | Organization)
custodianI0..1Reference(Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
codeΣ1..1codeBinding
targetΣ I1..1Reference(DocumentReference)
descriptionΣ0..1string
securityLabelΣ0..*CodeableConceptBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
attachmentΣ I1..1Attachment
formatΣ0..1CodingBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
encounterI0..*Reference(Encounter | EpisodeOfCare)
event0..*CodeableConcept
periodΣ I0..1Period
facilityType0..1CodeableConcept
practiceSetting0..1CodeableConcept
sourcePatientInfoI0..1Reference(Patient)
relatedI0..*Reference(Resource)


Additional Guidance

subject

SHOULD be present if related to a patient. Reference to the Patient this data file is pertaining to. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

author

SHOULD reference the organization responsible for creating the data file, preferably by ODS code.
"performer":  [
        {
            "identifier": {
                "system": "https://fhir.nhs.uk/Id/ods-organization-code",
                "value": "REP"
            }
        }
    ],

description

Human readable description for the data file. NOTE: this is being used in place of DocumentReference.type until suitable LOINC or SNOMED CT concepts are identified for the file types expected.
 "description": "Phenotype Report",

content

SHOULD be a DRS compatible reference to the data file.
"content": [
    {
      "attachment": {
        "contentType": "application/json",
        "url": "drs://drs.genomicsengland.nhs.uk/ga4gh/drs/v1/objects/42375e7d-071c-4eb3-b1c8-cec11e245cf0",
        "title": "PharmCAT JSON report"
      }
    }
  ],

context

In all cases the DocumentReference SHOULD reference the DNA Specimen from which the data originated, where available, and the ServiceRequest which triggered the capture of the data.

The DiagnosticReport using the data file SHOULD reference the DocumentReference via the DiagnosticReport.extension:supporting-info element. This guidance will be updated upon release of the R5 backport of DiagnosticReport.media, allowing references to DocumentReference. Once backported, the DiagnosticReport.media.link SHOULD be used to reference the DocumentReference resources for data files analysed for the report instead.

"context": {
    "related": [
      {
        "reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-NewFollowupTest-Example"
      },
      {
        "reference": "Specimen/Specimen-BloodEDTA-Example"
      }
    ]
  }


StructureDefinition UKCore-FamilyMemberHistory

For collecting relevant Family Member History to aid interpretation of Genomic results. This is limited to collection of Pedigree information. The FamilyMemberHistory resource is not to be used to record participants involved in testing, e.g. in the case of Duo/Trio scenarios (in this case the RelatedPerson resource SHOULD be used instead.

The Genomics FamilyMemberHistory is currently pending Clinical and Technical Assurance of the base UKCore resource. Once this profile becomes active in UKCore its suitability for use and need for profiling within Genomics will be assessed.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-FamilyMemberHistory UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
associatedEncounterI0..1Extension(Reference(Encounter))
id0..1string
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueCodeableConceptCodeableConcept
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(Patient | Practitioner | PractitionerRole | RelatedPerson | Device | Organization | CareTeam)
url1..1uriFixed Value
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
instantiatesCanonicalΣ0..*canonical(PlanDefinition | Questionnaire | ActivityDefinition | Measure | OperationDefinition)
instantiatesUriΣ0..*uri
statusS Σ ?!1..1codeBinding
dataAbsentReasonΣ0..1CodeableConceptBinding
patientS Σ I1..1Reference(Patient)
dateS Σ0..1dateTime
nameS Σ0..1string
relationshipS Σ1..1CodeableConceptBinding
sexΣ0..1CodeableConceptBinding
bornPeriodPeriod
bornDatedate
bornStringstring
ageAgeAge
ageRangeRange
ageStringstring
estimatedAgeΣ I0..1boolean
deceasedBooleanboolean
deceasedAgeAge
deceasedRangeRange
deceasedDatedate
deceasedStringstring
reasonCodeΣ0..*CodeableConcept
reasonReferenceΣ I0..*Reference(Condition | Observation | AllergyIntolerance | QuestionnaireResponse | DiagnosticReport | DocumentReference)
note0..*Annotation
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
code1..1CodeableConceptBinding
outcome0..1CodeableConceptBinding
contributedToDeath0..1boolean
onsetAgeAge
onsetRangeRange
onsetPeriodPeriod
onsetStringstring
note0..*Annotation


FHIRMDSHL7v2
FamilyMemberHistoryPedigree details/diagram, Disease penetranceN/A not in scope for HL7v2, could be added as additional DG1 segments related to relatives (representation of family history in HL7v2 still pending investigation)

Additional Guidance

extension:genetics-observation

An extension on the FamilyMemberHistory resource to include Observations relevant to Genomic testing/interpretation.
"extension":  [
        {
            "url": "http://hl7.org/fhir/StructureDefinition/family-member-history-genetics-observation",
            "valueReference": {
                "reference": "Observation/Observation-BloodPressure-Example"
            }
        }
    ],

identifier

This SHOULD be NHS number or local identifier (if NHS number is unavailable e.g. for non UK residents). If a local identifier is used, an assigner SHALL be provided. The FamilyMemberHistory.identifier field SHALL match the identifier used for a RelatedPerson resource if the same person is being referenced.
   "identifier": {
      "system": "urn:oid:2.16.840.1.113883.2.1.3.2.4.18.24",
      "value": "FT-RWT13521",
      "assigner": {
        "identifier": {
          "system": "https://fhir.nhs.uk/Id/ods-organization-code",
          "value": "RAX"
        }
      }
    }
  }

status

Used to mark the completeness of a given family member's clinical history. If the history of a family member is expected but no history could be obtained, this element SHOULD be filled with 'health-unknown'.

Assertions regarding absence of relevant history SHOULD follow guidance within the HL7 FHIR R4 FamilyMemberHistory resource

"status": "completed",

patient

SHALL be present. Reference to the associated proband Patient for which this family history is being obtained. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    }

relationship

SHALL be present. Relationship between the person the FamilyMemberHistory references and the proband Patient. Clinical histories for each family member are expected to be recorded in separate FamilyMemberHistory resources. If multiple resources are required, both FamilyMemberHistory and related clinical artifacts such as Condition/Observation resources, these MAY be contained within a List resource to improve readability.
"relationship": {
        "coding":  [
            {
                "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                "code": "PRN",
                "display": "parent"
            }
        ]
    }


StructureDefinition UKCore-Observation

Used to represent the bulk of clinical information to be sent alongside a Genomic Test Order, as well as clinical results included within structured Diagnostic Reports.

Observations within Genomics are used to represent a point-in-time observation made about a patient or specimen. This means Observations SHOULD NOT be updated post-submission unless the original Observation has been entered in error or incorrectly coded (in this case, the appropriate status SHALL be used, e.g. entered-in-error or corrected).

For new observations which invalidate previous observations made about a patient, a new Observation resource SHOULD be created, the new observation MAY reference the invalidated observation via the observation-replaces extension.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Observation UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
id0..1string
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(Observation)
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueCodecode
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueStringstring
url1..1uriFixed Value
bodyStructureR5I0..1Extension(Reference(BodyStructure))
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
basedOnΣ I0..*Reference(CarePlan | DeviceRequest | ImmunizationRecommendation | MedicationRequest | NutritionOrder | ServiceRequest)
partOfΣ I0..*Reference(MedicationAdministration | MedicationDispense | MedicationStatement | Procedure | Immunization | ImagingStudy)
statusS Σ ?!1..1codeBinding
categoryS0..*CodeableConceptBinding
codeS Σ1..1CodeableConceptBinding
subjectS Σ I0..1Reference(Patient | Group | Device | Location)
focusΣ I0..*Reference(Resource)
encounterΣ I0..1Reference(Encounter)
effectiveDateTimedateTime
effectivePeriodPeriod
effectiveTimingTiming
effectiveInstantinstant
issuedΣ0..1instant
performerS Σ I0..*Reference(Practitioner | PractitionerRole | Organization | CareTeam | Patient | RelatedPerson)
valueQuantityQuantity
valueCodeableConceptCodeableConcept
valueStringstring
valueBooleanboolean
valueIntegerinteger
valueRangeRange
valueRatioRatio
valueSampledDataSampledData
valueTimetime
valueDateTimedateTime
valuePeriodPeriod
dataAbsentReasonI0..1CodeableConceptBinding
interpretation0..*CodeableConceptBinding
note0..*Annotation
bodySite0..1CodeableConceptBinding
method0..1CodeableConceptBinding
specimenI0..1Reference(Specimen)
deviceI0..1Reference(Device | DeviceMetric)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
lowI0..1SimpleQuantity
highI0..1SimpleQuantity
type0..1CodeableConceptBinding
appliesTo0..*CodeableConcept
ageI0..1Range
text0..1string
hasMemberΣ I0..*Reference(Observation | QuestionnaireResponse | MolecularSequence)
derivedFromΣ I0..*Reference(DocumentReference | ImagingStudy | Media | QuestionnaireResponse | Observation | MolecularSequence)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
codeΣ1..1CodeableConceptBinding
valueQuantityQuantity
valueCodeableConceptCodeableConcept
valueStringstring
valueBooleanboolean
valueIntegerinteger
valueRangeRange
valueRatioRatio
valueSampledDataSampledData
valueTimetime
valueDateTimedateTime
valuePeriodPeriod
dataAbsentReasonI0..1CodeableConceptBinding
interpretation0..*CodeableConceptBinding
referenceRange0..*see (referenceRange)


Observation-AutisticBehaviour-Example
Observation-BlastPercentage-Example
Observation-Bruising-Example
Observation-Cellularity-Example
Observation-CellularityKayBurbridge-Example
Observation-DelayedSpeechLanguageDevt-Example
Observation-DiseasePenetrance-Example
Observation-DiseasePenetrancePheobeSmitham-Example
Observation-DutchLipidScore-Example
Observation-EnlargedKidney-Example
Observation-Haemoglobin-Example
Observation-HepaticCysts-Example
Observation-Immunodefficiency-Example
Observation-IntellectualDisabilityMild-Example
Observation-IntellectualDisabilityProfound-Example
Observation-NatureAndAgeOfHearingLoss-Example
Observation-Necrosis-Example
Observation-NecrosisKayBurbridge-Example
Observation-NeoplasticCell-Example
Observation-NeoplasticCellKayBurbridge-Example
Observation-Neutrophils-Example
Observation-GenomicEthnicity-Example
Observation-MultipleRenalCysts-Example
Observation-Nephronophthisis-Example
Observation-NoBoneMarrowTransplantProbandFather-Example
Observation-NoBoneMarrowTransplantProbandMother-Example
Observation-NoFirstTrimesterFetalAnomalies-Example
Observation-NoPregnancy-Example
Observation-NoSecondTrimesterFetalAnomalies-Example
Observation-NoTransfusion-Example
Observation-NoTransfusionProbandFather-Example
Observation-NoTransfusionProbandMother-Example
Observation-NoTransplant-Example
Observation-NonConsanguinousUnion-Example
Observation-NonConsanguinousUnionProband-Example
Observation-NonConsanguinousUnionProbandFather-Example
Observation-NonConsanguinousUnionProbandMother-Example
Observation-NucleatedCellCount-Example
Observation-Platelets-Example
Observation-PregnancyConfirmation-Example
Observation-QueryXanthoma-Example
Observation-RenalInsufficiency-Example
Observation-SimonBroomeCriteria-Example
Observation-TumourType-Example
Observation-TumourTypeKayBurbridge-Example
Observation-UnknownConsanguinousUnionStatus-Example
Observation-WhiteBloodCell-Example
Observation-SampleCellContent-Example
Observation-HistoryOfFetalLoss-Example

FHIRMDSHL7v2
ObservationRaw specimen/biopsy - Additional specimen/biopsy information, Extracted specimen - Additional specimen information, Further clinical informationOBX segments (may be attached to SPM)
Observation.codePatient - Sexual orientation, Patient - Karyotypic sex, Patient - Pregnancy status, Patient - Fetal karyotypic sex, Patient - Is from consanguinous union, Fetus - Karyotypic sex, Fetus - Is testing for fetal loss from 24 weeks of gestation, PLCM activity - DNA concentration, PLCM activity - DNA quantification, PLCM activity - Test outcome code (Many), Raw specimen/biopsy - Taken alive/post mortem, Diabetic complications, Has absent reflexesOBX-5 with appropriate SNOMED/READ/LOINC code
Observation.componentPatient - Pregnancy gestation period, Patient - Fetal gestation, Patient - Estimated Delivery Date (EDD), Patient - Pregnancy type, Absent reflexes detailOBX-14 (compared with other ORC segments), OBR segments with appropriate codes
Observation.value\[x\]Patient - Height (m), Raw specimen/biopsy - Skin/Bone affected status, Raw specimen/biopsy - Blasts %, Raw specimen/biopsy - Neoplastic cell content (%), Raw specimen/biopsy - Necrosis, Raw specimen/biopsy - Nucleated cell count, Raw specimen/biopsy - Tumour cellularity, Raw specimen/biopsy - Maternal cell contamination (MCC), Previous non genomic report - Test result value comparator, Previous non genomic report - Test result value unit of measure, Genomic ethnicity, ISTH BAT score, MODY probability calculator score, Patient BMI at time of genomic test request, Patient BMI at time of diagnosis, Maternal BMI at time of request, Paternal BMI at time of request, Birth weightOBX-5/6
Observation.referenceRange.lowPrevious non genomic report - Test result reference range lowOBX-7 (before operator)
Observation.referenceRange.highPrevious non genomic report - Test result reference range highOBX-7 (after operator)
Observation.methodPrevious non genomic report - Test result test methodOBX-17
Observation.referenceRange.textPrevious non genomic report - Test result reference range textOBX-7
Observation.interpretationPrevious non genomic report - Test result clinical summaryOBX-8
Observation.bodySiteSubcutaneous fat loss areas, Increased fat deposition areasOBX-5

Additional Guidance

extension:observation-replaces

A core extension on the base HL7 International Observation resource. Used to link to previous Observation resources which have been invalidated by this Observation instance, e.g. for cases where a previously present HPO term is now no longer applicable. For new observations which invalidate previous observations made about a patient, the new Observation resource SHOULD be created, and MAY reference the invalidated observation via the observation-replaces extension.

    {
      "url": "http://hl7.org/fhir/StructureDefinition/observation-replaces",
      "valueReference": {
        "reference": "Observation/Observation-IntellectualDisabilityMild-Example"
      }
    }

status

SHOULD be marked as final for most observations unless corrected after submission. Observations within Genomics are used to represent a point-in-time observation made about a patient or specimen. This means Observations should not be updated post-submission unless the original Observation has been entered in error or incorrectly coded (in this case, the appropriate status SHALL be used, e.g. entered-in-error or corrected, respectively).

"status": "final",

code

SHALL be present. SNOMED CT coding is preferred, though it is expected that alternative codings will be used depending on the appropriateness for a particular observation e.g. HPO or other codings found within the HL7 International Genomic Reporting IG as their use may already be widespread within Genomics. If a SNOMED CT equivalent exists for a code regularly captured within another CodeSystem, additional 'coding' elements within 'code' SHOULD be provided to aid analytics.

"code": {
        "coding":  [
            {
                "system": "https://hpo.jax.org/app/",
                "code": "HP:0000105",
                "display": "Enlarged kidney"
            }
        ]
    },

subject

SHALL be present. Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

focus

For recording the Specimen the observation relates to, when the observation is not related to the patient from which the sample was taken e.g. Sample nucleated cell count.

This can also be used for observations related to the state of the patient at the time of collection e.g. pregnancy status.

"focus": {
        "reference": "Specimen/Specimen-BloodEDTA-Example"
    },

effectiveDateTime

It is expected that all Observations SHOULD include the effective time the observation was made, if known, to aid interpretation.
"effectiveDateTime": "2022-07-11T09:00:00Z",

value[x]

The value element SHOULD use the most appropriate data type for the observation in question. Using preferred CodeSystems as specified within HL7 International FHIR R4 or the UK Core. For asserting absence of a particular condition/situation, the finding SHOULD be specified within the 'code' element and 'valueBoolean' set to 'false' or 'valueCodeableConcept' set to an appropriate qualifier value code from SNOMED CT. For an assertion of a particular situation being present, e.g. a Condition or Procedure having been performed, these SHOULD be collected within the relevant clinical resources, alongside additional information needed to inform interpretation.
"valueQuantity": {
        "value": 6.5,
        "system": "http://unitsofmeasure.org",
        "code": "10*12/L"
    }

component

SHOULD be used to group qualifiers of an observation. In particular, details regarding observations related to a pregnancy SHOULD be added as components on a pregnancy status observation.

Examples of how pregnancy information can be captured within Observations (pregnancy status with EDD, gestation etc. recorded as components) will be added to the Fetus Management Clinical Scenario.

"component": [
		{
			"code": {
				"coding": [
					{
						"system": "http://snomed.info/sct",
						"code": "720451000000102",
						"display": "Assisted conception"
					}
				]
			}
		},
		{
			"code": {
				"coding": [
					{
						"system": "http://snomed.info/sct",
						"code": "226081000000107",
						"display": "Gestational age"
					}
				]
			},
			"valueQuantity": {
				"value": 87,
				"unit": "day",
				"system": "http://unitsofmeasure.org",
				"code": "d"
			}
		},
		{
			"code": {
				"coding": [
					{
						"system": "http://snomed.info/sct",
						"code": "161714006",
						"display": "Estimated date of delivery"
					}
				]
			},
			"valueDateTime": "2024-05-01"
		}
	],


StructureDefinition OperationOutcome

The Genomics OperationOutcome is the same as provided within FHIR R4. The FHIR R4 OperationOutcome is provided below for completeness.

OperationOutcomes are expected for any create or update operations made on the server resulting in validation messages (or any create or update operations made within a transaction bundle). It is not expected that connecting systems would need to construct OperationOutcome resources or submit these to the server, though key elements within the resource are detailed here for receiving systems.

It is expected that all issue codes raised by the Genomic Medicine Service will fall under existing codes bound in the below resource. If further codes are needed, these will be promoted to UK Core for release in a future ballot/sprint.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/OperationOutcome HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
severityΣ1..1codeBinding
codeΣ1..1codeBinding
detailsΣ0..1CodeableConcept
diagnosticsΣ0..1string
locationΣ0..*string
expressionΣ0..*string

Additional Guidance

issue

An issue element will be included within the OperationOutcome for each issue that needs to be communicated to the requesting system, e.g. errors, warnings or informational messages. Appropriate 'severity' and 'code' codes will be assigned to help categorization of an messages returned, using the standard HL7 bound ValueSets.

The diagnostics field will be used to present a human readable version of the message and location will be used to detail the location within the request payload that resulted in the associated issue/message.

If an error or warning is returned, the 'details' element will be populated with any validation specific messages. Details of the systems and codes used for these messages will be determined by the validation package used by the central order management broker (this is still to be determined at the time of publication).

"issue":[
            {
              "severity":"error",
              "code":"processing",
              "details":{
                "coding":[
                  {
                    "system": "http://terminology.hl7.org/CodeSystem/operation-outcome",
                    "code": "MSG_LOCAL_FAIL",
                    "display": "Unable to resolve local reference to resource Patient/Patient-MeirLieberman-Example"
                  }
                ]
              },
              "diagnostics": "Validation errors occurred during processing",
              "location": [
                  "Bundle.entry[1].resource.ofType(ServiceRequest)"
              ]
            }
          ]


StructureDefinition UKCore-Organization

Organization is not expected to be sent within Test Order or other interactions with the central GMS. Instead, client systems SHOULD strive to reference organizations via their ODS code and display name only.

The below profile is provided for information, if referencing by ODS code is intractable (though repeated issues with requester ability to reference via ODS code SHOULD be reported to the NHS England Genomic Unit for investigation).

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Organization UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
mainLocationI0..1Extension(Reference(Location))
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valuePeriodPeriod
modifierExtension?! I0..*Extension
id0..1string
extensionI0..*Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ1..1uriFixed Value
valueΣ1..1string
periodΣ I0..1Period
assignerΣ I0..1Reference(Organization)
id0..1string
extensionI0..*Extension
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ1..1uriFixed Value
valueΣ1..1string
periodΣ I0..1Period
assignerΣ I0..1Reference(Organization)
activeS Σ ?!0..1boolean
typeΣ0..*CodeableConceptBinding
nameS Σ I0..1string
alias0..*string
telecomS I0..*ContactPoint
addressS I0..*Address
partOfΣ I0..1Reference(Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
purpose0..1CodeableConceptBinding
name0..1HumanName
telecomI0..*ContactPoint
address0..1Address
endpointI0..*Reference(Endpoint)


FHIRMDSHL7v2
Organization.nameRequestor - Organization name, Additional contact - Organization name, address and ODS codeORC-21
Organization.addressRequestor - Organization address, Additional contact - Organization addressORC-22
Organization.identifierRequestor - Organization ODS code, Additional contact - Organization ODS code, Patient - GP Practice ODS Code, Previous genomic report - Report performer organisation ODS code, Previous genomic report - Original requester organisation ODS code, Previous non genomic report - Report performer organisation ODS code, Previous non genomic report - Original requester organisation ODS codeORC-21.10, OBX-23.10
Organization.partOfPLCM activity - ODS code of commissioning regionN/A - not in scope for HL7v2

StructureDefinition UKCore-Patient

The focal resource for recording who a test order and genomic report are for.

It is expected that client's will need to post Patient resources to the central GMS as some demographic information specific to Genomics will not have been captured within other systems such as PDS.

For patients included within PDS, it is expected source systems SHOULD only send genomic specific information not recorded against PDS, e.g. birthSex, genomic specific identifiers and a link to the PDS record, as well as the NHS number identifier. (NOTE: examples provided for patient resources are fully expanded to illustrate how information should be structured but any infomation already recorded by PDS SHOULD NOT be duplicated within the genomic order management services). Querying patient demographic information, will be supported using the search parameters provided by the Genomic Order Management Service, whch will pass through parameters to PDS where demographics are stored against this system. Client systems will then be required to follow the PDS link within the Genomics-Patient record to retrieve the PDS patient.

It is a requirement on source systems that patient NHS numbers are traced and verified with PDS, if the patient is registered with PDS, before creation of patient resources on the Genomic Order Management broker

For patients not included on PDS, e.g. private/overseas patients or fetal records, the requester SHOULD send all information necessary to facilitate testing and interpretation of the request. Where this patient is later registered on PDS, identified through assignment of an NHS number, demographic details SHALL be stripped from the genomic record to avoid data duplication.

Alternatively, systems MAY opt to include pointers to the Patient resource on their local system, though the mechanism preferred by the NHS England Genomics Unit has yet to be decided.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Patient UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueAddressAddress
birthSexI0..1Extension(CodeableConcept)
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueBooleanboolean
contactPreferenceI0..1Extension(Complex)
deathNotificationStatusI0..1Extension(Complex)
ethnicCategoryI0..1Extension(CodeableConcept)
fetalStatusI0..1Extension(code)
residentialStatusI0..1Extension(CodeableConcept)
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueBooleanboolean
nhsNumberUnavailableReasonI0..1Extension(CodeableConcept)
modifierExtension?! I0..*Extension
id0..1string
nhsNumberVerificationStatusI0..1Extension(CodeableConcept)
useΣ ?!0..1codeBinding
typeΣ0..1CodeableConceptBinding
systemΣ1..1uriFixed Value
valueΣ1..1string
periodΣ I0..1Period
assignerΣ I0..1Reference(Organization)
activeS Σ ?!0..1boolean
nameS Σ0..*HumanName
id0..1string
extensionI0..*Extension
id0..1string
otherContactSystemI0..1Extension(CodeableConcept)
value0..1System.String
valueΣ0..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ I0..1Period
genderS Σ0..1codeBinding
id0..1string
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueDateTimedateTime
value0..1System.Date
deceasedBooleanboolean
deceasedDateTimedateTime
id0..1string
addressKeyI0..*Extension(Complex)
useΣ ?!0..1codeBinding
typeΣ0..1codeBinding
textΣ0..1string
lineΣ0..*string
cityΣ0..1string
districtΣ0..1string
stateΣ0..1string
postalCodeΣ0..1string
countryΣ0..1string
periodΣ I0..1Period
maritalStatus0..1CodeableConceptBinding
multipleBirthBooleanboolean
multipleBirthIntegerinteger
photoI0..*Attachment
id0..1string
contactRankI0..1Extension(positiveInt)
copyCorrespondenceIndicatorI0..1Extension(boolean)
modifierExtensionΣ ?! I0..*Extension
relationship0..*CodeableConceptBinding
name0..1HumanName
id0..1string
extensionI0..*Extension
id0..1string
otherContactSystemI0..1Extension(CodeableConcept)
value0..1System.String
valueΣ0..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ I0..1Period
address0..1Address
gender0..1codeBinding
organizationI0..1Reference(Organization)
periodI0..1Period
id0..1string
id0..1string
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueCodingCoding
id0..1string
extensionI0..0Extension
url1..1uriFixed Value
valueCodingCoding
url1..1uriFixed Value
modifierExtensionΣ ?! I0..*Extension
language1..1CodeableConceptBinding
preferred0..1boolean
generalPractitionerI0..*Reference(Organization | Practitioner | PractitionerRole)
managingOrganizationS Σ I0..1Reference(Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
otherΣ I1..1Reference(Patient | RelatedPerson)
typeΣ1..1codeBinding


FHIRMDSHL7v2
Patient.identifierPatient - NHS number, Patient - Local identifier, Patient - Pedigree/Family Identifier, Fetus - Local identifier, Previous genomic report - Patient's NHS number, Previous genomic report - Patient's alternative identifier, Previous genomic report - Patient's clinical genetics number, Previous genomic report - Patient's pedigree numberPID-3
Patient.extension:nhsNumberUnavailableReasonPatient - Reason for unavailable NHS number, Patient - Withheld identity reasonN/A, could use PID-32 as surrogate
Patient.name.prefixPatient - TitlePID-5.5
Patient.name.givenPatient - First name, Previous genomic report - Patient's first namePID-5.2
Patient.name.familyPatient - Surname, Previous genomic report - Patient's surnamePID-5.1
Patient.birthDatePatient - Date of birth, PLCM activity - Patient age at activity date, Previous genomic report - Patient's date of birthPID-7, Age derived from the difference between PID-7 and TQ1-7 for the relevant activity
Patient.addressPatient - Address, Previous genomic report - Patient's addressPID-11
Patient.address.postalCodePatient - Postcode, Previous genomic report - Patient's post codePID-11.5
Patient.address.countryPatient - Country, Previous genomic report - Patient's countryPID-11.6
Patient.deceasedBooleanPatient - Life status at time of requestPID-30
Patient.deceasedDateTimePatient - Date of deathPID-29
Patient.extension:EthnicCategoryPatient - EthnicityPID-22
Patient.extension:birthSexPatient - Sex assigned at birthPID-8
Patient.extension:patient-genderIdentityPatient - Gender IdentityN/A - not part of the HL7v2 standard, though PID-8 or an OBX segment could be used
Patient.generalPractitionerPatient - GP Practice ODS Code, Patient - GP full name, Patient - GP GMC numberPD1-4
Patient.genderFetus - Observed sexPID-8

Additional Guidance

extension:UKCore-birthSex

Extension used for recording the phenotypic sex of the patient, as recorded at birth.
    {
      "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-BirthSex",
      "valueCodeableConcept": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v3-AdministrativeGender",
            "code": "M",
            "display": "Male"
          }
        ]
      }
    }

identifier

SHALL be present for Patients within the Genomic Order Management ecosystem. It is preferred that all patients with an NHS number have this included within the Patient resource upon submission of a test order. Patient who do not have an NHS number SHOULD have a temporary one registered/assigned with PDS.

For patient records where the NHS number has been traced from PDS, the trace status SHOULD be provided within the NHS Number identifier slice.

Additional identifiers SHOULD include an appropriate naming system scheme which clearly identifies the assigner (to disambiguate the identifier from other resources where these are not nationally unique). Alternatively, the OID for local identifier MAY be used, with the 'assigner' organization explicitly referenced.

"identifier":  [
        {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307946",
            "extension":  [
                {
                    "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-NHSNumberVerificationStatus",
                    "valueCodeableConcept": {
                        "coding":  [
                            {
                                "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-NHSNumberVerificationStatusEngland",
                                "version": "2.2.0",
                                "code": "01",
                                "display": "Number present and verified"
                            }
                        ]
                    }
                }
            ]
        },
        {
            "system": "urn:oid:2.16.840.1.113883.2.1.3.2.4.18.24",
            "value": "RWT14789",
            "assigner": {
                "identifier": {
                    "system": "https://fhir.nhs.uk/Id/ods-organization-code",
                    "value": "RAX01"
                }
            }
        }
    ],

generalPractitioner

Where patients are registered with a General Practitioner within the UK, both the ODS code for the practice and GMP number for the practitioner SHOULD be provided, where known, as separate objects within the generalPractitioner array.
"generalPractitioner":  [
        {
            "identifier": {
                "system": "https://fhir.hl7.org.uk/Id/gmp-number",
                "value": "G9999999"
            },
            "display": "Dr. Aero Smith"
        },
        {
            "identifier": {
                "system": "https://fhir.hl7.org.uk/Id/ODS-code",
                "value": "AP123"
            },
            "display": "anywhere place"
        }
    ],

link

For patient records where additional information exists elsewhere, for example, within PDS or the source system EHR, this MAY be referenced through the link field, specifying the url through which the related patient information can be accessed.
"link":  [
        {
            "other": {
                "reference": "https://api.service.nhs.uk/personal-demographics/FHIR/R4/Patient/9449307946"
            },
            "type": "seealso"
        }
    ]


StructureDefinition UKCore-Practitioner

Practitioner is not expected to be sent within Test Order or other interactions with the central GMS. Instead, client systems SHOULD strive to reference practitioners via their identifier within a national coding system and display name only.

The below profile is provided for information, if referencing by identifier is intractable (though repeated issues with requester ability to reference via identifier/code SHOULD be reported to the NHS England Genomic Unit for investigation).

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Practitioner UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierS Σ0..*Identifier
activeΣ0..1boolean
nameS Σ0..*HumanName
telecomS Σ I0..*ContactPoint
addressΣ0..*Address
genderΣ0..1codeBinding
birthDateΣ0..1date
photoI0..*Attachment
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
identifier0..*Identifier
code1..1CodeableConcept
periodI0..1Period
issuerI0..1Reference(Organization)
communication0..*CodeableConceptBinding


FHIRMDSHL7v2
Practitioner.nameRequestor - Full name, Additional contact - Full name, Patient - GP full name, Previous genomic report - Report performer full name, Previous genomic report - Original requester full name, Previous non genomic report - Report performer full name, Previous non genomic report - Original requester full nameORC-12, PD1-4.2 and PD1-4.3, OBX-16, ORC-12
Practitioner.identifierRequestor - Professional registration number, Additional contact - Professional registration number, Patient - GP GMC numberORC-12.1, PD1-4.1
Practitioner.identifier.system, Additional contact - Professional registration number typeRequestor - Professional registration number typeORC-12.9

StructureDefinition UKCore-PractitionerRole

PractitionerRole resources SHOULD be used where information about both a practitioner and their role within a specific organization is required, e.g. as the ServiceRequest.requestor.

References to Practitioner and Organization resources SHOULD only be made via identifier, rather than appending Practitioner and Organization resources to test order bundles. Issues with referencing via identifier SHOULD be reported to the NHS England Genomics Unit for investigation.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-PractitionerRole UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
activeS Σ0..1boolean
periodS Σ I0..1Period
practitionerS Σ I0..1Reference(Practitioner)
organizationS Σ I0..1Reference(Organization)
codeΣ0..*CodeableConcept
specialtyS Σ0..*CodeableConceptBinding
locationS Σ I0..*Reference(Location)
healthcareServiceI0..*Reference(HealthcareService)
telecomS Σ I0..*ContactPoint
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
daysOfWeek0..*codeBinding
allDay0..1boolean
availableStartTime0..1time
availableEndTime0..1time
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
description1..1string
duringI0..1Period
availabilityExceptions0..1string
endpointI0..*Reference(Endpoint)


FHIRMDSHL7v2
PractitionerRole.practitionerRequestor - Full name, Requestor - Professional registration number, Requestor - Professional registration number type, Additional contact - Full name, Additional contact - Professional registration number, Additional contact - Professional registration number type, Patient - GP full name, Patient - GP GMC number, Previous genomic report - Report performer full name, Previous genomic report - Original requester full name, Previous non genomic report - Report performer full name, Previous non genomic report - Original requester full nameORC-12, ORC-12.1, ORC-12.9, PD1-4.2 and PD1-4.3, PD1-4.1, OBX-16, ORC-12
PractitionerRole.codeRequestor - Job Title, Additional contact - Job TitleCTD-1
PractitionerRole.specialtyRequestor - Current Specialty, Requestor - Department name, Additional contact - Current Specialty, Additional contact - Department nameAdditional CTD-1 segments
PractitionerRole.telecomRequestor - Phone, Requestor - Email address, Requestor - Genomic report delivery method, Requestor - Central email for address and reporting (many), Additional contact - Phone, Additional contact - Email address, Additional contact - Genomic report delivery method, Additional contact - Central email for address and reporting (many)ORC-14
PractitionerRole.organizationRequestor - Organization name, Requestor - Organization address, Requestor - Organization ODS code, Additional contact - Organization name, address and ODS code, Additional contact - Organization address, Additional contact - Organization ODS code, Patient - GP Practice ODS Code, Previous genomic report - Report performer organisation ODS code, Previous genomic report - Original requester organisation ODS code, Previous non genomic report - Report performer organisation ODS code, Previous non genomic report - Original requester organisation ODS codeORC-21, ORC-22, ORC-21.10, OBX-23.10
PractitionerRole.healthcareServicePLCM activity - ODS code of the laboratory site delivering requested test, PLCM activity - Commissioned service category codeAdditional CTD-1 segments

Additional Guidance

practitioner

SHALL be present. Users SHOULD reference practitioners using an appropriate naming system within the NHS defined within the NHS England IG .Display name MAY be included to aid readability and verification of included identifiers.
 "practitioner": {
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/sds-user-id",
            "value": "9999999999"
        },
        "display": "Dr. Gene Smith"
    },

organization

SHALL be present. Users SHOULD reference organizations using an ODS code. Display name MAY be included to aid readability and verification of included identifiers. Requester ODS codes SHOULD use the lowest level site code rather than trust code (most granular code available) where possible, to aid contact retrieval.
 "organization": {
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/ods-organization-code",
            "value": "RGT01"
        },
        "display": "Addenbrooke's Hospital"
    },

specialty

The specialty field SHOULD be used to record department for the requesting clinician, issues with the use of this field, including issues with the [bound UK Core ValueSet](https://fhir.hl7.org.uk/CodeSystem/UKCore-PracticeSettingCode) not representing certain departments SHOULD be reported to the NHS England Genomics Unit
"specialty":  [
        {
            "coding":  [
                {
                    "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-PracticeSettingCode",
                    "code": "120",
                    "display": "Ear Nose and Throat"
                }
            ]
        }
    ],

telecom

The telecom field SHOULD be used to record contact details for the practitioner. For central mailboxes, e.g. those used for providing reports back to the requester, these SHOULD be marked with an appropriate 'contactpoint-comment' extension. Additionally, where are there multiple Practitioners involved in providing care, the contact details for each Practitioners for that location (or service) SHOULD be specified.
"telecom":  [
        {
            "system": "phone",
            "value": "01223586638"
        },
        {
            "system": "email",
            "value": "gene.smith@nhs.net"
        },
        {
            "system": "email",
            "value": "Add-tr.entsecretaries@nhs.net",
            "extension":  [
                {
                    "url": "http://hl7.org/fhir/StructureDefinition/contactpoint-comment",
                    "valueString": "reporting"
                }
            ]
        }
    ]


StructureDefinition UKCore-Procedure

Used for detailing information on procedures the patient has had performed, to aid interpretation of Genomic test results.

Assertion of an absence of a procedure being performed SHOULD be recorded using an Observation resource, as described in Profile-UKCore-Observation

At a minimum, Procedure resources are expected to contain the status, code, subject and performedDateTime, though additional information conforming to the FHIR profile below MAY be included if relevant.

Genomic Study and Genomic Study Analysis profiles on Procedure may also be used as part of structured reporting. Mandated usage of these profiles is pending data standard discovery work to identify the items required within Genomic Test Reporting. As such, elements called out, and guidance suggested on this page, may be subject to change.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Procedure UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
instantiatesCanonicalΣ0..*canonical(PlanDefinition | ActivityDefinition | Measure | OperationDefinition | Questionnaire)
instantiatesUriΣ0..*uri
basedOnΣ I0..*Reference(CarePlan | ServiceRequest)
partOfΣ I0..*Reference(Procedure | Observation | MedicationAdministration)
statusS Σ ?!1..1codeBinding
statusReasonΣ0..1CodeableConcept
categoryΣ0..1CodeableConcept
codeS Σ0..1CodeableConceptBinding
subjectS Σ I1..1Reference(Patient | Group)
encounterΣ I0..1Reference(Encounter)
performedDateTimedateTime
performedPeriodPeriod
performedStringstring
performedAgeAge
performedRangeRange
recorderΣ I0..1Reference(Patient | RelatedPerson | Practitioner | PractitionerRole)
asserterΣ I0..1Reference(Patient | RelatedPerson | Practitioner | PractitionerRole)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
functionΣ0..1CodeableConcept
actorΣ I1..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)
onBehalfOfI0..1Reference(Organization)
locationΣ I0..1Reference(Location)
reasonCodeΣ0..*CodeableConcept
reasonReferenceΣ I0..*Reference(Condition | Observation | Procedure | DiagnosticReport | DocumentReference)
bodySiteΣ0..*CodeableConceptBinding
outcomeΣ0..1CodeableConcept
reportI0..*Reference(DiagnosticReport | DocumentReference | Composition)
complication0..*CodeableConceptBinding
complicationDetailI0..*Reference(Condition)
followUp0..*CodeableConcept
note0..*Annotation
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
action0..1CodeableConceptBinding
manipulatedI1..1Reference(Device)
usedReferenceI0..*Reference(Device | Medication | Substance)
usedCode0..*CodeableConcept


FHIRMDSHL7v2
ProcedurePatient - Had transplant, Patient - Had transfusion, Is patient on TKI therapy, Insulin treated within 6 months of diagnosis, Is on Ig replacementPresence of OBR segment with OBR-44 code for transplant/transfusion etc.
Procedure.performedDateTimePatient - Fetal gestation (to determine termination date), Patient - Transplant date, Patient - Transfusion dateOBR-7
Procedure.codePatient - Pregnancy type, Patient - Type of transplant, Patient - Type of transfusion, Neonatal hypoglycemia treatment details, Current exocrine pancreatic treatmentOBR segments with appropriate codes, OBR-44, OBR/RXA segments
Procedure.performedPeriod.startNeonatal hypoglycemia treatment start date, Exocrine pancreatic treatment start dateOBR-7, RXA-3
Procedure.performedPeriod.endNeonatal hypoglycemia treatment end dateOBR-8

Additional Guidance

extension:genomic-study-analysis

TBC. From the Genomic Reporting IG Genomic Study profile. Reference to the Genomic Study Analysis resource, detailing the analyses performed as part of genomic test.

"extension" : [
    {
      "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genomic-study-analysis-ext",
      "valueReference" : {
        "reference" : "Procedure/PGXGenomicStudyAnalysis"
      }
    }
  ],

Genomic Study Analysis extensions

TBC. From the Genomic Reporting IG Genomic Study Analysis profile. Various extensions covering the metadata related to a genomic test, e.g. regions studied, change types tested for etc. For the full list of extensions, please see the linked profile page.

Use of the profile and its extensions is pending further discovery of the data standards required for Genomic Reporting in the UK.

"extension" : [
    {
      "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genomic-study-analysis-genome-build",
      "valueCodeableConcept" : {
        "coding" : [
          {
            "system" : "http://loinc.org",
            "code" : "LA26806-2",
            "display" : "GRCh38"
          }
        ]
      }
    },
    {
      "extension" : [
        {
          "url" : "sequencing-coverage",
          "valueQuantity" : {
            "value" : 100
          }
        }
      ],
      "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genomic-study-analysis-metrics"
    },
    {
      "extension" : [
        {
          "url" : "description",
          "valueString" : "protein-coding and exon-splicing regions"
        },
        {
          "url" : "studied",
          "valueCodeableConcept" : {
            "coding" : [
              {
                "system" : "http://www.genenames.org",
                "code" : "HGNC:2621",
                "display" : "CYP2C19"
              }
            ]
          }
        },
        {
          "url" : "studied",
          "valueCodeableConcept" : {
            "coding" : [
              {
                "system" : "http://www.genenames.org",
                "code" : "HGNC:2623",
                "display" : "CYP2C9"
              }
            ]
          }
        },
        {
          "url" : "studied",
          "valueCodeableConcept" : {
            "coding" : [
              {
                "system" : "http://www.genenames.org",
                "code" : "HGNC:23663",
                "display" : "VKORC1"
              }
            ]
          }
        }
      ],
      "url" : "http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/genomic-study-analysis-regions"
    }
  ],

status

Status SHALL use the codes recommended in the base Procedure resource, appropriately tagging procedures as having been completed or in-progress etc. depending on the actual status of the procedure.

"status": "completed",

code

SHALL be present. SNOMED CT coding is preferred, though alternative codings MAY be provided subject to review of the Coding system by the NHS England Genomics Unit.

For the Genomic Study profile, expected to be from the Genomic Study Type ValueSet

"code": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "23719005",
                "display": "Transplantation of bone marrow"
            }
        ]
    },

subject

SHALL be present. Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS.

"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

performed[x]

performed SHOULD be provided wherever possible, using the appropriate data type, to aid in interpretation of Genomic test results.

"performedDateTime": "2020-01-19"


StructureDefinition Provenance

The Genomics Provenance SHOULD be provided alongside updates to controlled documents such as ServiceRequests and DiagnosticReports by integrated systems on any update operation to ensure auditability for any changes to resources.

It is not expected that updates which do not affect the clinical content of the document will need associated Provenance resources, e.g. addition of local identifiers (though for the purporses of the Genomic Order Management Alpha, all updates to ServiceRequest and DiagnosticReport resources will be expected to have accompanying Provenance resources). On material changes to controlled resources, ServiceRequest and DiagnosticReport, users SHOULD use the transaction endpoint on the server to bundle the updated resource and Provenance event into a single transaction.

The HL7 FHIR specification also provides the capability to attach a Provenance resource using a custom header parameter. Using this mechanism would allow clients to submit requests to the resource specific PUT enpoints for ServiceRequests and DiagnosticReports, while still aloowing changes to be captured within a Provenance resource using a single interaction. This mechanism will not be supported within the Genomic Order Management Alpha but will be investigated by the NHS England Genomics Unit for implementation in future phases.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/Provenance HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
targetΣ I1..*Reference(Resource)
occurredPeriodPeriod
occurredDateTimedateTime
recordedΣ1..1instant
policy0..*uri
locationI0..1Reference(Location)
reason0..*CodeableConceptBinding
activity0..1CodeableConceptBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
typeΣ0..1CodeableConceptBinding
role0..*CodeableConcept
whoΣ I1..1Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization)
onBehalfOfI0..1Reference(Practitioner | PractitionerRole | RelatedPerson | Patient | Device | Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
roleΣ1..1codeBinding
whatΣ I1..1Reference(Resource)
agent0..*see (agent)
signature0..*Signature


Additional Guidance

target

SHALL be provided. This SHOULD be a reference to the resource on the central GMS system that was updated.
"target":  [
        {
            "reference": "ServiceRequest/ServiceRequest-SavedTestOrderUpdated-Example"
        }
    ],

recorded

SHALL be provided, the date/time when the update took place.
"recorded": "2023-08-10T11:10:00Z",

reason

The reason why the update took place. If the codes provided by HL7 are not granular enough, or additional notes need to be recorded detailing the reasoning behind a change, this SHOULD be added as text to 'reason.text'.
"reason":  [
        {
            "coding":  [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v3-ActReason",
                    "code": "TREAT",
                    "display": "treatment"
                }
            ],
            "text": "Test inappropriate for patient"
        }
    ],

agent

SHOULD be provided where actions are user initiated. The user which performed the change, as identified through CIS2 authentication token.
"agent":  [
        {
            "type": {
                "coding":  [
                    {
                        "system": "http://terminology.hl7.org/CodeSystem/provenance-participant-type",
                        "code": "author",
                        "display": "Author"
                    }
                ]
            },
            "who": {
                "reference": "PractitionerRole/PractitionerRole-TestClinicalScientist-Example",
                "identifier": {
                    "system": "https://fhir.nhs.uk/Id/sds-user-id",
                    "value": "9999999997"
                }
            }
        }
    ],

signature

Signed, encrypted copy of the document, for validation that the document has not been tampered with (the requirement to include this field has not yet been validated).
 "signature":  [
        {
            "type":  [
                {
                    "system": "urn:iso-astm:E1762-95:2013",
                    "code": "1.2.840.10065.1.12.1.15",
                    "display": "Addendum Signature"
                }
            ],
            "when": "2023-08-10T11:10:00Z",
            "who": {
                "reference": "PractitionerRole/PractitionerRole-TestClinicalScientist-Example",
                "identifier": {
                    "system": "https://fhir.nhs.uk/Id/sds-user-id",
                    "value": "9999999997"
                }
            },
            "data": "DQo8U2lnbm...F0dXJlPg0K"
        }
    ]


StructureDefinition Questionnaire

The Genomics Questionnaire is currently based on the UKCore resource, without any need for profiling.

The profile for the UKCore-Questionnaire is provided below for completeness.

It is not expected that any Questionnaire resources will be submitted to the central service, instead the GMS solution will contain a library of Questionnaires relevant to Genomics that it can use to validate QuestionnaireReponses (such as the example Record of Discussion Questionnaire).

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/Questionnaire HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
urlΣ0..1uri
identifierΣ0..*Identifier
versionΣ0..1string
nameΣ I0..1string
titleΣ0..1string
derivedFrom0..*canonical(Questionnaire)
statusΣ ?!1..1codeBinding
experimentalΣ0..1boolean
subjectTypeΣ0..*codeBinding
dateΣ0..1dateTime
publisherΣ0..1string
contactΣ0..*ContactDetail
description0..1markdown
useContextΣ0..*UsageContext
jurisdictionΣ0..*CodeableConceptBinding
purpose0..1markdown
copyright0..1markdown
approvalDate0..1date
lastReviewDate0..1date
effectivePeriodΣ I0..1Period
codeΣ0..*Coding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
linkId1..1string
definition0..1uri
codeI0..*Coding
prefix0..1string
text0..1string
type1..1codeBinding
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
question1..1string
operator1..1codeBinding
answerBooleanboolean
answerDecimaldecimal
answerIntegerinteger
answerDatedate
answerDateTimedateTime
answerTimetime
answerStringstring
answerCodingCoding
answerQuantityQuantity
answerReferenceReference(Resource)
enableBehaviorI0..1codeBinding
requiredI0..1boolean
repeatsI0..1boolean
readOnlyI0..1boolean
maxLengthI0..1integer
answerValueSetI0..1canonical(ValueSet)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
valueIntegerinteger
valueDatedate
valueTimetime
valueStringstring
valueCodingCoding
valueReferenceReference(Resource)
initialSelected0..1boolean
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
valueBooleanboolean
valueDecimaldecimal
valueIntegerinteger
valueDatedate
valueDateTimedateTime
valueTimetime
valueStringstring
valueUriuri
valueAttachmentAttachment
valueCodingCoding
valueQuantityQuantity
valueReferenceReference(Resource)
itemI0..*see (item)


FHIRMDSHL7v2
QuestionnaireRoD Questionnaire Schema

StructureDefinition QuestionnaireResponse

The Genomics QuestionnaireResponse is currently based on the core HL7 resource, without any need for profiling.

The profile for QuestionnaireResponse is provided below for completeness.

No additional guidance has been provided on this page as there are no Genomic-specific considerations which need to be made. However, all QuestionnaireResponses submitted to the central service SHALL reference a Questionnaire definition in order to aid validation and presentation of the response content.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/QuestionnaireResponse HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..1Identifier
basedOnΣ I0..*Reference(CarePlan | ServiceRequest)
partOfΣ I0..*Reference(Observation | Procedure)
questionnaireΣ0..1canonical(Questionnaire)
statusΣ ?!1..1codeBinding
subjectΣ I0..1Reference(Resource)
encounterΣ I0..1Reference(Encounter)
authoredΣ0..1dateTime
authorΣ I0..1Reference(Device | Practitioner | PractitionerRole | Patient | RelatedPerson | Organization)
sourceΣ I0..1Reference(Patient | Practitioner | PractitionerRole | RelatedPerson)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
linkId1..1string
definition0..1uri
text0..1string
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
valueBooleanboolean
valueDecimaldecimal
valueIntegerinteger
valueDatedate
valueDateTimedateTime
valueTimetime
valueStringstring
valueUriuri
valueAttachmentAttachment
valueCodingCoding
valueQuantityQuantity
valueReferenceReference(Resource)
item0..*see (item)
item0..*see (item)


FHIRMDSHL7v2
QuestionnaireResponseRecord of DiscussionCON segments
QuestionnaireResponse.item.answerRoD questions with appropriate linkId: RoD - Patient category, Test type, RoD - Research opt out reason, RoD - Remote consent, RoD - Recording clinician, RoD - Responsible clinician, RoD - Patient choice status, RoD - Has research participation been discussed, RoD - SignatureCON (for OML, included in RoD, referenced from NTE-3)

StructureDefinition UKCore-RelatedPerson

Used for linking Patients with other participants of a test order, e.g. in the case of proband and consultand within duo and trio testing.

For instances where clinical/demographic information for the related person are required, a Patient resource for the related person (consultand) SHOULD be included, with the Patient.link field referencing the RelatedPerson resource for the same individual. Elements duplicated across both the Patient and RelatedPerson for the same individual SHOULD in this case be captured within the Patient resource only. The RelatedPerson resource then references the proband Patient resource through the RelatedPerson.patient field.

A diagram illustrating the links between resources is provided below (Duo Scenario):




Further use cases surrounding the use of RelatedPerson are pending further Duo/Trio scenarios.
Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-RelatedPerson UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
contactPreferenceI0..1Extension(Complex)
copyCorrespondenceIndicatorI0..1Extension(boolean)
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
activeS Σ ?!0..1boolean
patientS Σ I1..1Reference(Patient)
relationshipS Σ0..*CodeableConceptBinding
nameS Σ0..*HumanName
id0..1string
extensionI0..*Extension
id0..1string
otherContactSystemI0..1Extension(CodeableConcept)
value0..1System.String
valueΣ0..1string
useΣ ?!0..1codeBinding
rankΣ0..1positiveInt
periodΣ I0..1Period
genderΣ0..1codeBinding
birthDateΣ0..1date
addressS Σ0..*Address
photoI0..*Attachment
periodI0..1Period
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
language1..1CodeableConceptBinding
preferred0..1boolean


FHIRMDSHL7v2
RelatedPerson.relationshipPatient - Relationship to proband, Previous genomic report - Patient's relationship to requesting patientNK1-3

Additional Guidance

patient

SHALL be provided. This SHOULD be a reference to the Patient resource and/or the identifier, e.g. NHS number, for the patient constituting the target of the relationship. This can be visualised using the nomenclature:
{Source (identifier)} is the {Relationship type (relationship)} of {Target (patient)}
'Ryanne Boulder' is the 'natural mother' of 'Fetus of Ryanne Boulder'

In this case the fetal identifier should be used in the patient element.

"patient": {
    "reference": "Patient/Patient-FoetusOfRyanneBoulder-Example",
    "identifier": {
      "system": "urn:oid:2.16.840.1.113883.2.1.3.2.4.18.24",
      "value": "FT-RWT13521",
      "assigner": {
        "identifier": {
          "system": "https://fhir.nhs.uk/Id/ods-organization-code",
          "value": "RAX"
        }
      }
    }
  },

identifier

SHALL be provided. This SHOULD be NHS number or local identifier (if NHS number is unavailable e.g. for non UK residents) for the source of the relationship. This can be visualised using the nomenclature:
{Source (identifier)} is the {Relationship type (relationship)} of {Target (patient)}
'Ryanne Boulder' is the 'natural mother' of 'Fetus of Ryanne Boulder'

In this case the Ryanne Boulder's identifier should be used for the RelatedPerson.identifier.

If a local identifier is used, an assigner SHALL be provided. The RelatedPerson.identifier field SHALL match the identifier used for a FamilyMemberHistory or Patient resource if these resources are about the same person.

   "identifier": [
      {
        "system": "https://fhir.nhs.uk/Id/nhs-number",
        "value": "9999999999"
      }
    ],

relationship

SHOULD use the UK Core bound ValueSet and SHOULD be present in all instances of RelatedPerson wherever possible.
"relationship":  [
        {
            "coding":  [
                {
                    "system": "http://terminology.hl7.org/CodeSystem/v3-RoleCode",
                    "code": "SIS",
                    "display": "sister"
                }
            ]
        }
    ]


StructureDefinition ResearchSubject

The need for a Genomics ResearchSubject is currently under review.

The profile for the international FHIR ResearchSubject is provided below for completeness.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/ResearchSubject HL7 International trial-use

The CareConnect profile will be uplifted to the R4 UKCore in a future release

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
statusΣ ?!1..1codeBinding
periodΣ I0..1Period
studyΣ I1..1Reference(ResearchStudy)
individualΣ I1..1Reference(Patient)
assignedArm0..1string
actualArm0..1string
consentI0..1Reference(Consent)



StructureDefinition UKCore-ServiceRequest

Focal resource for test order messages. All additional information or resources SHOULD be linked back to the ServiceRequest or be referenced from the ServiceRequest directly.

ServiceRequests which have been updated post submission SHALL be accompanied by Provenance resources, referencing the ServiceRequest which detail when the resource was changed, who made the change and why.

An illustrative diagram of the links between ServiceRequests and other resources is provided below. Note: not all resource links are represented, to increase legibility of the diagram.

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-ServiceRequest UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
sourceOfServiceRequestI0..1Extension(CodeableConcept)
additionalContactI0..*Extension(Reference(Organization | Practitioner | PractitionerRole))
coverageI0..1Extension(CodeableConcept)
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
instantiatesCanonicalΣ0..*canonical(ActivityDefinition | PlanDefinition)
instantiatesUriΣ0..*uri
basedOnS Σ I0..*Reference(CarePlan | ServiceRequest | MedicationRequest)
replacesΣ I0..*Reference(ServiceRequest)
requisitionΣ0..1Identifier
statusS Σ ?!1..1codeBinding
intentS Σ ?!1..1codeBinding
id0..1string
extensionI0..*Extension
id0..1string
extensionI0..*Extension
systemΣ0..1uriFixed Value
versionΣ0..1string
codeΣ0..1code
displayΣ0..1string
userSelectedΣ0..1boolean
textΣ0..1string
id0..1string
priorityReasonI0..*Extension(CodeableConcept)
value0..1System.String
doNotPerformΣ ?!0..1boolean
codeS Σ0..1CodeableConceptBinding
orderDetailΣ I0..*CodeableConceptBinding
quantityQuantityQuantity
quantityRatioRatio
quantityRangeRange
subjectS Σ I1..1Reference(Patient | Group | Location | Device)
encounterΣ I0..1Reference(Encounter)
occurrenceDateTimedateTime
occurrencePeriodPeriod
occurrenceTimingTiming
asNeededBooleanboolean
asNeededCodeableConceptCodeableConcept
authoredOnS Σ0..1dateTime
requesterS Σ I0..1Reference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)
performerTypeΣ0..1CodeableConcept
performerΣ I0..*Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)
locationCodeΣ0..*CodeableConcept
locationReferenceΣ I0..*Reference(Location)
reasonCodeΣ0..*CodeableConceptBinding
reasonReferenceΣ I0..*Reference(Condition | Observation | DiagnosticReport | DocumentReference)
insuranceI0..*Reference(Coverage | ClaimResponse)
supportingInfoI0..*Reference(Resource)
specimenΣ I0..*Reference(Specimen)
bodySiteΣ0..*CodeableConceptBinding
note0..*Annotation
patientInstructionΣ0..1string
relevantHistoryI0..*Reference(Provenance)


FHIRMDSHL7v2
ServiceRequest.requesterRequester (more details in PractitionerRole resource mappings), PLCM activity - Commissioned service category code, Previous genomic report - Original requester full name, Previous genomic report - Original requester organisation ODS code, Previous genomic report - Original requester reason for request, Previous non genomic report - Original requester full name, Previous non genomic report - Original requester organisation ODS code, Previous non genomic report - Original requester reason for requestVarious ORC/STF segments
ServiceRequest.extension:additionalContactAdditional Contact (more details in PractitionerRole resource mappings)Various STF segments
ServiceRequest.subjectPatient (more details in Patient resource mappings), Patient - Is relativeFirst PID segment in OML message, relatives referenced through NK1 segments
ServiceRequest.identifierTest request - Test request id, PLCM activity - NGIS referral identifier, Previous genomic report - Report lab test numberORC-2, ORC-3
ServiceRequest.extension:coverageTest request - Payment statusIN1-15
ServiceRequest.authoredOnTest request - Date and time request sent, PLCM activity - Financial month, PLCM activity - Financial year, PLCM activity - Turnaround time (calendar days)ORC-9 (for TAT subtracted from OBR-7)
ServiceRequest.priorityTest request - Is urgentTQ1-9
ServiceRequest.extension:priorityReasonTest request - Urgency reasonN/A could possibly use TQ1-10
ServiceRequest.code.coding.systemTest request - Test Directory versionOBR-4.3
ServiceRequest.codeTest request - CI code, Test request - CITT code, PLCM activity - Service code, PLCM activity - Point of delivery code, PLCM activity - Local point of delivery code, PLCM activity - Test method codeOBR-4
ServiceRequest.orderDetailTest request - CI code for multipurpose CITT, Test request - Type of reanalysis, Test request - DNA storage informationNTE segment attached to OBR
ServiceRequest.reasonCodeTest request - Reason for testing, Test request - Reason for reanalysisOBR-13 segment linked to ORC
ServiceRequest.supportingInfoTest request - Detail of reason for reanalysis, Test request - Further informationNTE segments linked to OBR segment for reanalysis reason, Additional segments attached to ORC/OBR
ServiceRequest.occurrenceDateTimeTest request - Date report required byOBR-8
ServiceRequest.performerPLCM activity - ODS code of organisation commissioned to deliver requested testPRD-7 where PRD-1=RT
ServiceRequest.noteRaw specimen/biopsy - Sample to follow reasonNTE segment attached to ORC

Additional Guidance

extension:additionalContact

Extension used for recording additional personnel who should be contacted regarding questions related to a test order. This is separate from the requester or reporting address.

The additional contact SHOULD be a reference to a PractitionerRole resource wherever possible and SHALL contain contact details for the practitioner.

Additionally, where are there multiple practitioners involved in providing care who need to be listed as contacts, the contact details for each practitioner (or service) SHOULD be specified through additional additionalContact entries.

{
    "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-AdditionalContact",
    "valueReference": {
        "reference": "PractitionerRole/PractitionerRole-AdditionalContact-Example"
    }
},

extension:coverage

SHALL be present for Genomic Order Management test orders. Extension for recording how work against the test order is being funded. The ValueSet bound to this extension is currently under review by the NHS England Genomics Informatics Working Advisory Group and subject to change.
{
    "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-Coverage",
    "valueCoding": {
        "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-FundingCategory",
        "code": "nhs",
        "display": "NHS"
    }
}

identifier

Automatically assigned by the central service, though source systems MAY provide a local identifier for tracking within their own system, in which case the central order number is appended to the identifiers array.
    "identifier":  [
        {
            "system": "https://fhir.nhs.uk/Id/GMSOrder",
            "value": "ROA43728"
        }
    ],

basedOn

SHALL reference a parent request where this ServiceRequest is based on a previous request, e.g. in the case of reanalysis and cascade testing, or Germline Late tests in the Tumour First/Germline Late scenario.
"basedOn":  [
        {
            "reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-FatherOfFayMutlow-Example"
        }
    ],

status

SHALL be provided. ServiceRequests SHOULD be marked as 'draft' until submitted, after which they will be marked as 'active' automatically by the central GMS system.

A ServiceRequest may be marked as 'on-hold' if work against it cannot continue temporarily, e.g. due to certain prerequisite information not being provided. A ServiceRequest SHOULD be marked as 'revoked' if cancelled, either by the lab performing work against the order or at the request of the requesting clinician, though in each case a Provenance resource SHALL be provided to capture why the state change has occurred. The requesting clinician may also mark the ServiceRequest as entered-in-error, though implications for work already in progress needs to be investigated further.

A ServiceRequest SHOULD only be marked as completed by the requesting clinician upon receipt and review of the resulting DiagnosticReport.

For the full list of expected/supported ServiceRequest statuses, please see the table below:

Status Description Genomic workflow usage
Draft The request has been created but is not yet complete or ready for action. Saved but not submitted to central service (out of scope for Alpha).
Active The request is in force and ready to be acted upon. Submitted to central service.
On Hold The request (and any implicit authorization to act) has been temporarily withdrawn but is expected to resume in the future. Issue with the authorization for the test (potentially recoverable), not expected to be driven by on-hold statuses of Tasks.
Revoked The request (and any implicit authorization to act) has been terminated prior to the known full completion of the intended actions. No further activity should occur. Unrecoverable issue with order. Either used when the test is no longer needed or there is an is an unrecoverable failure with its fulfillment (driven by the requesting clinician). This status will propagate down to any Tasks which have not already moved into in-progress, Tasks not started will be marked with the status of cancelled.
Completed The activity described by the request has been fully performed. No further activity will occur. Completed order, marked by requestor once DiagnosticReport is received and accepted.
Entered in Error This request should never have existed and should be considered 'void'. (It is possible that real-world decisions were based on it. If real-world activity has occurred, the status should be "revoked" rather than "entered-in-error".) MAY be used for ServiceRequests created in error, can only be set if no Tasks have been started. If a Task has been moved out of its initial state, the status of Revoked SHOULD be used instead. This status will propagate down to Tasks, marking the tasks as entered-in-error.
Unknown The authoring/source system does not know which of the status values currently applies for this request. Note: This concept is not to be used for "other" - one of the listed statuses is presumed to apply, but the authoring/source system does not know which. Should not be used.
"status": "active",

intent

SHALL be provided. ServiceRequests SHOULD be marked as 'order' unless they have been raised by a lab in response to an existing ServiceRequest, in which case they SHOULD be marked as 'reflex-order'. For reflex orders, the ServiceRequest.basedOn field SHALL be populated with the original ServiceRequest, for traceability.
"intent": "order",

category

ServiceRequests SHOULD use the [Genomics Sequencing Category](https://simplifier.net/resolve?scope=fhir.r4.ukcore.stu3.currentbuild@0.0.6-pre-release&filepath=package/ValueSet-UKCore-GenomeSequencingCategory.json) ValueSet when categorising the test order in order to aid analytics (e.g. PLCM). This list is pending review from the Informatics Working Advisory Group, after which a full list of possible categorisations will be finalised.
"category":  [
        {
            "coding":  [
                {
                    "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-GenomeSequencingCategory",
                    "code": "rare-disease-non-wgs",
                    "display": "Rare Disease - Non-WGS"
                }
            ]
        }
    ],

priority

ServiceRequests marked as urgent (i.e. not routine) SHOULD populate the extension:priorityReason with why an urgent test is being requested. This SHOULD ideally be coded using SNOMED CT concepts. Multiple priorityReason extensions are allowed within a single ServiceRequest in order to aid post-coordination.
"priority": "urgent",
"_priority": {
        "extension" : [ 
            {
                "url" : "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-PriorityReason",
                "valueCodeableConcept" : {
                    "coding": [
                        {
                            "system": "http://snomed.info/sct",
                            "code": "722480002",
                            "display": "Chemotherapy started"
                        }
                    ]
                }
            }
        ]
    }

doNotPerform

For the purposes of Genomic Test Ordering, the doNotPerform field SHALL NOT be used. All ServiceRequests requests received by the system will be assumed to be orders for services/testing.

code

SHALL be provided. Code SHOULD contain the CI or CITT Test Directory code, currently available at https://www.england.nhs.uk/publication/national-genomic-test-directories/. There is currently no CodeSystem or queryable API for retrieving codes but work to address this is underway within the NHS England Genomics Unit.

Codes from the Genomic Test Directory SHOULD also specify the version number of the test directory at the time the test is being ordered, to ensure the test methods used are consistent with that version of the directory.

"code": {
        "coding":  [
            {
                "system": "https://fhir.nhs.uk/CodeSystem/England-GenomicTestDirectory",
                "code": "R67.2",
                "display": "Monogenic hearing loss",
                "version": "7"
            }
        ]
    },

orderDetail

If multiple codes are being requested within one Test Order, these SHOULD be represented using the 'orderDetail' field, with the main indication captured using the 'code' field above. If completely separate pathways/samples etc. are required for processing against the codes, it is expected these would be requested via multiple ServiceRequests instead of a single ServiceRequest with multiple orderDetail codes. The exact cut-off for when orderDetail vs. multiple ServiceRequest should be used is still being investigated. An appropriate code(Panel codes) SHOULD come from the following NamingSystem: England-GenomicTestPanelCode
"orderDetail": [
    {
        "coding":  [
            {
                "system": "https://fhir.nhs.uk/CodeSystem/England-GenomicTestDirectory",
                "code": "R67.1",
                "display": "Monogenic hearing loss"
            }
        ]
    }
],

subject

SHALL be provided. Reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS
"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

occurrence[x]

If a result is required by a specific date, this MAY be indicated though occurrenceDateTime, though there is no guarantee from the GMS that the ServiceRequest will be processed in the time frame specified.
"occurrenceDateTime": "2023-08-25",

autoredOn

SHALL be populated by the client upon submission, either manually by the user or automatically by the system integrating with the central GMS.
"authoredOn": "2023-08-05",

requester

SHALL be populated on all ServiceRequests submitted to the central GMS. This SHALL reference a PractitionerRole resource also submitted to the system (either within a single transaction or previously POSTed).
"requester": {
        "reference": "PractitionerRole/PractitionerRole-GeneSmithENT-Example"
    },

performer

Allows a requester to assign processing of the ServiceRequest to a particular organization (e.g. a remote GLH). The performer field SHOULD be populated with the ODS code for the managing organization/GLH.

In the future state, ServiceRequests may be kept open, by not specifying a performer, allowing them to be picked up by the local GLH or otherwise routed based on by test routing (TBC).

"performer": [
        {
            "identifier": {
                "system": "https://fhir.nhs.uk/Id/ods-organization-code",
                "value": "RGT01"
            }
        }
    ]

reasonCode

reasonCode SHOULD be populated with the type of request being ordered e.g. Diagnostic, Carrier, Predictive, Stored DNA etc. The final list of applicable codes which can be selected is still under review. It is expected that a fixed list of SNOMED CT codes will be permissible, to allow appropriate categorisation by the central service.

This mapping is currently under review as the CI/CITT code is also technically the reason/indication for testing.

"reasonCode":  [
        {
            "coding":  [
                {
                    "system": "http://snomed.info/sct",
                    "code": "103693007",
                    "display": "Diagnostic procedure"
                }
            ]
        }
    ],

reasonReference

Reference SHOULD be associated to the primary condition being tested for. i.e,
"reasonReference": {
        "reference": "Condition/Condition-LungTumor-Example"
    },

supportingInfo

Any clinical information provided about the patient for whom the testing is being requested SHALL be referenced though the supportingInfo field, to ensure all the information relevant to the ServiceRequest can be easily retrieved. This includes Observations, Conditions, Procedures, FamilyMemberHistories etc.

This also includes resources related to family members included as part of testing (consultands), e.g. in Duo/Trio scenarios. In this instance, RelatedPerson and Patient resource references for the consultands SHALL be added to the supportingInfo array, as well as any clinical resources related to these individuals. This is to ensure the number of participants for a given test can be calculated correctly, e.g. through counting the number of RelatedPerson resources referenced from ServiceRequest.supportingInfo plus the subject of the ServiceRequest itself (the proband).

For WGS testing, where Records of Discussion are required in order to process the test, Consent resources SHOULD also be added to the supportingInfo array once available.

"supportingInfo":  [
        {
            "reference": "Observation/Observation-DiseaseStatus-Example"
        },
        {
            "reference": "Observation/Observation-GenomicEthnicity-Example"
        },
        {
            "reference": "Observation/Observation-NoPregnancy-Example"
        },
        {
            "reference": "FamilyMemberHistory/FamilyMemberHistory-NonConsanguinousUnion-Example"
        },
        {
            "reference": "Observation/Observation-NoTransplant-Example"
        },
        {
            "reference": "Observation/Observation-NoTransfusion-Example"
        },
        {
            "reference": "Condition/Condition-HearingLoss-Example"
        },
        {
            "reference": "RelatedPerson/RelatedPerson-AliceSmithamProbandMother-Example"
        },
        {
            "reference": "Patient/Patient-PheobeSmithamMother-Example"
        },
    ],

specimen

ServiceRequests where the required samples already exist, e.g. in the case where a specimen already in storage needs to be processed, SHOULD reference these samples through the ServiceRequest.specimen field. Where samples need to be collected to support testing, these SHOULD instead reference the ServiceRequest, through Specimen.request (i.e. the service request has prompted collection of the sample), and these Specimen resources do not need to be referenced from within ServiceRequest.supportingInfo. The referenced Specimen resources SHOULD either be contained within the test order transaction bundle or already exist on the central GMS.

In the case of Reanalysis or Reinterpretation tests, Specimens related to previous ServiceRequest are not required to be added to the new test request. The links from the previous ServiceRequest can be followed to identify the Specimens that resulted in the data being reanalysed, e.g. (reanalysis) ServiceRequest.basedOn -> (prior) ServiceRequest, (prior) ServiceRequest <- (original) Specimen.request

"specimen": [
        {
            "reference": "Specimen/Specimen-BloodSerum-Example"
        }
    ],

note

Any information which cannot be readily be structured SHOULD be entered into the note field, though prolific use of the field to capture clinical information which better fits in level 3/4 FHIR resources is discouraged.
"note":  [
        {
            "text": "No family history of genomic testing"
        }
    ]


StructureDefinition UKCore-Specimen

Used to capture information on Samples which will undergo or have undergone processing for genomic testing.

Within FHIR R4, there is no way to capture location against a sample to aid tracking, one of the key requirements of the Genomic Medicine Service. Investigation of a possible solution through backporting the container.location element within R5 is currently being investigated. Until this backport is adopted by UK Core, the location of samples, including interactions to manage and track samples, will be performed through changes to Task resources generated on submission of a ServiceRequest.

A diagram illustrating the links between resources is provided below (Duo Scenario)

Note: links from ServiceRequest.supportingInfo to samples collected after submission are pending further investigation

Profile url FHIR Module Normative Status
https://fhir.hl7.org.uk/StructureDefinition/UKCore-Specimen UKCore trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
sampleCategoryI0..1Extension(CodeableConcept)
modifierExtension?! I0..*Extension
identifierΣ0..*Identifier
accessionIdentifierΣ0..1Identifier
statusS Σ ?!0..1codeBinding
typeS Σ0..1CodeableConceptBinding
subjectS Σ I0..1Reference(Patient | Group | Device | Substance | Location)
receivedTimeS Σ0..1dateTime
parentI0..*Reference(Specimen)
requestI0..*Reference(ServiceRequest)
id0..1string
specialHandlingI0..*Extension(CodeableConcept)
modifierExtensionΣ ?! I0..*Extension
id0..1string
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(Patient | RelatedPerson)
referenceΣ I0..1string
typeΣ0..1uriBinding
identifierΣ0..1Identifier
displayΣ0..1string
collectedDateTimedateTime
collectedPeriodPeriod
durationΣ I0..1Duration
quantityI0..1SimpleQuantity
method0..1CodeableConcept
id0..1string
id0..1string
extensionI0..*Extension
url1..1uriFixed Value
valueReferenceReference(BodyStructure)
codingΣ0..*Coding
textΣ0..1string
fastingStatusCodeableConceptCodeableConcept
fastingStatusDurationDuration
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
description0..1string
procedure0..1CodeableConcept
additiveI0..*Reference(Substance)
timeDateTimedateTime
timePeriodPeriod
id0..1string
deviceR5I0..1Extension(Reference(UKCoreDevice))
locationR5I0..1Extension(Reference(UKCoreLocation))
modifierExtensionΣ ?! I0..*Extension
identifierΣ0..*Identifier
description0..1string
type0..1CodeableConceptBinding
capacityI0..1SimpleQuantity
specimenQuantityI0..1SimpleQuantity
additiveCodeableConceptCodeableConcept
additiveReferenceReference(Substance)
conditionΣ0..*CodeableConceptBinding
note0..*Annotation

FHIRMDSHL7v2
SpecimenSample/Biopsy inc germline, Extracted SpecimenSPM
Specimen.subjectFetus - Is sample for fetal or unregistered neonate, Raw specimen/biopsy - Family member provided byPID segment attached to SPM
Specimen.collection.quantityPLCM activity - Sample volume, Raw specimen/biopsy - VolumeSPM-12
Specimen.typePLCM activity - Sample category codeSPM-4
Specimen.identifier.assignerRaw specimen/biopsy - Id assigning authority ODS code (many), Raw specimen/biopsy - Is assigning authority a histopathology laboratory (many), Extracted specimen - Id assigning authority ODS code (many)SPM-2.1.2
Specimen.identifier.valueRaw specimen/biopsy - Id (many), Extracted specimen - Id (many)SPM-2
Specimen.container.identifierRaw specimen/biopsy - Sample well identifierSAC-3
Specimen.noteRaw specimen/biopsy - Location details (will use backported R5 container.location once released), Extracted specimen - Location details, Raw specimen/biopsy - Sample to follow reason, Raw specimen/biopsy - Additional specimen/biopsy information, Extracted specimen - Additional specimen informationSAC-15, NTE segment attached to ORC, OBX segments attached to SPM
Specimen.extension:sampleCategoryRaw specimen/biopsy - WGS specimen type categorySPM-5
Specimen.typeRaw specimen/biopsy - Type, Raw specimen/biopsy - Blood component, Extracted specimen - TypeSPM-4
Specimen.conditionRaw specimen/biopsy - StateSPM-24
Specimen.processingRaw specimen/biopsy - Sample preparation (submitted to GLH)Combination of SPM-6/SPM-24 or NTE segments if other processing
Specimen.collection.collectedDateTimeRaw specimen/biopsy - Obtained dateSPM-17
Specimen.receivedTimeRaw specimen/biopsy - Received dateSPM-18
Specimen.collection.extension:specimen-specialHandling.valueCoding.codeRaw specimen/biopsy - High risk reason, Raw specimen/biopsy - Option for products of conceptionSPM-16.2, SPM-15
Specimen.collection.bodySiteRaw specimen/biopsy - Biopsy siteSPM-8/SPM-9
Specimen.statusRaw specimen/biopsy - Sample to followN/A implied through absence of SPM segment in test order
Specimen.conditionExtracted specimen - StateSPM-24
Specimen.processing.timeDateTimeExtracted specimen - Extracted dateOBR-7 attached to processing procedure in SAC-30

Additional Guidance

extension:sampleCategory

Allows the categorisation of a sample into either tumour or germline. Additional terms may be added upon review though the valueCodeableConcept.text field MAY be used as a free text representation if needed.
"extension": [
        {
            "url": "https://fhir.hl7.org.uk/StructureDefinition/Extension-UKCore-SampleCategory",
            "valueCodeableConcept": {
                "coding": [
                    {
                        "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-SampleCategory",
                        "code": "germline",
                        "display": "Germline"
                    }
                ]
            }
        }
    ]

identifier

Multiple identifiers MAY be assigned to a sample as it travels between labs. Each lab SHOULD append their local identifier to the identifier array if needed, ensuring either the system or assigner, is able to disambiguate any identifiers from possibly overlapping numbers from other organizations. Assigner is preferred in this case (see identifier example on the
Command 'pagelink' could not render: Page not found.
page for further guidance)

Note: accessionIdentifier is unused by the Genomic Medicine Service to facilitate movement of samples across organizational boundaries.

"identifier":  [
        {
            "system": "https://fhir.add.nhs.uk/Id/specimenId",
            "value": "RGT03135"
        }
    ],

status

If a Specimen has not been collected, the status SHOULD be marked as 'unavailable'. If the quality of the Specimen is such that it cannot be processed, the status SHOULD be 'unsatisfactory' (this is equivalent to a QC status of Failed). If the Specimen passes quality control, the status SHOULD be set as 'available
"status": "unsatisfactory",

type

The sample type, SNOMED CT preferred. Used to differentiate between raw and extracted (DNA) samples.

ConceptMaps for the allowed values for primary (raw) and final (extracted DNA) samples upon release of MDSv1.04, to aid identification of whether a sample is primary vs. final

"type": {
        "coding":  [
            {
                "system": "http://snomed.info/sct",
                "code": "445295009",
                "display": "Blood specimen with EDTA"
            }
        ]
    },

subject

SHALL be provided. This SHOULD be a reference to the Patient resource or the identifier, NHS number, for the patient.

Samples collected from a Fetus SHOULD reference a Patient resource for the Fetus. This should then be linked to relevant maternal/paternal resources through the RelatedPerson resource. Further information can be found on the Fetus Management clinical scenario. It is not envisaged that samples would need to be linked to more than one person e.g. both fetus and mother, though this assumption will be tested within the Alpha phase of the Genomic Medicine Service.

"subject": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

receivedTime

SHOULD be updated upon receipt at a destination lab
"receivedTime": "2023-09-18T18:30:00Z"

parent

If a sample has been split into multiple parts, such as DNA being extracted from a primary sample, each SHOULD be represented using an additional Specimen resource, referencing the parent sample through the parent element.

The central Order Management broker will only create Tasks for Specimen resources which do not have a parent element, i.e. primary samples. If required, clients can create Tasks for processing of derivative samples manually.

"parent": [
        {
            "reference": "Specimen/Specimen-BloodEDTA-Example"
        }
    ],

request

SHALL be provided. This SHOULD be a reference to the request which initiated collection of the sample. SHALL NOT be updated if the sample is used for another test e.g. for re-analysis. In the case that a Specimen needs to be processed as part of a new request, e.g. using a sample in storage, the ServiceRequest SHALL reference the pre-existing sample via ServiceRequest.specimen.
"request":  [
        {
            "reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-Example"
        }
    ]

collection

Additional information which can be collected about the circumstances under which as sample was collected, if relevant. This include extensions for specialHandling of the sample, e.g. due to high risk of infection, as well as an extension to bodySite to extend the coding to a BodyStructure reference, for more detailed collection of structural information e.g. where tumour morphology and topography need to be collected.

Where the collector is an Organization, or where the individual is not known, ODS codes MAY be used as identifiers in place of SDS-User-IDs. However, if referencing a resource, the PractitionerRole resource SHOULD still be referenced. In this case the PractitionerRole.identifier and PractitionerRole.practitioner reference would not be filled, leaving only the reference to an Organization from PractitionerRole.organization.

Note on quanitities

The Specimen.collection.quantity is the amount of the sample collected at collection time. This quantity does not change as the sample is processed.

The Specimen.container.specimenQuantity is the amount of sample remaining in a container, this is equivalent to GEL 1001 banked volume. This value should be updated as the specimen is used.

If a specimen is split, additional specimen resources SHOULD be created (referencing the parent specimen), with individual container.specimenQuantity values.

"collection": {
        "collector": {
            "identifier": {
                "system": "https://fhir.nhs.uk/Id/sds-user-id",
                "value": "999999"
            }
        },
        "collectedDateTime": "2022-07-11T09:00:00Z",
        "quantity": {
            "system": "http://unitsofmeasure.org",
            "code": "mL",
            "value": 2.5
        },
        "method": {
            "coding":  [
                {
                    "system": "http://snomed.info/sct",
                    "code": "129300006",
                    "display": "Puncture - action"
                }
            ]
        },
        "bodySite": {
            "coding":  [
                {
                    "system": "http://snomed.info/sct",
                    "code": "14975008",
                    "display": "Forearm structure (body structure)"
                }
            ]
        }
    },

processing

SHOULD be updated if processing occurs on the sample which affects later use, e.g. additives added
"processing": [
    {
      "description": "Acidify to pH < 3.0 with 6 N HCl.",
      "procedure": {
        "coding": [
          {
            "system": "http://terminology.hl7.org/CodeSystem/v2-0373",
            "code": "ACID"
          }
        ]
      },
      "additive": [
        {
          "display": "6 N HCl"
        }
      ],
      "timeDateTime": "2015-08-18T08:10:00Z"
    }
  ],

container

The UK Core STU3 version of Specimen backports the R5 changes to the container BackboneElement to support capturing of storage location for a sample (through `container.location`) and recursive capture of device identifiers (e.g. tube, well, rack, freezer through `container.device`).

Additional examples/guidance will be provided within this IG once use of the fields has been appropriately tested.

Sample tracking information SHOULD be added to Tasks acting on Specimen resources, e.g. Tasks marked SamplePreparation or SampleProcessing, on either the output or input elements. This information MAY include consignment number, destination, date sent etc.

"container":  [
        {
            "extension":  [
                {
                    "url": "http://hl7.org/fhir/5.0/StructureDefinition/extension-Specimen.container.location",
                    "valueReference": {
                            "reference": "Location/Location-NTGLHFridge-Example"
                    }
                }
            ]
        }
    ]

condition

Used to record the condition of a specimen. Within Genomics, SHOULD be used to record the fixed/frozen state, using the UK Core bound ValueSet.
"condition":  [
        {
            "coding":  [
                {
                    "system": "https://fhir.hl7.org.uk/CodeSystem/UKCore-BiopsyState",
                    "code": "fresh-frozen",
                    "display": "Fresh Frozen"
                }
            ]
        }
    ]


StructureDefinition Subscription

The Genomics Subscription is currently pending Clinical and Technical Assurance of the base UKCore resource. Once this profile becomes active in UKCore its suitability for use and need for profiling within Genomics will be assessed.

The profile for the NHSDigital/England Subscription is provided below for completeness.

In the Alpha build of the Genomic Medicine Service, MESH/email will be used as the primary notification procedure though a FHIR native solution is being investigated.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/Subscription HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
statusΣ ?!1..1codeBinding
contactΣ I0..*ContactPoint
endΣ0..1instant
reasonΣ1..1string
criteriaΣ1..1string
errorΣ0..1string
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
typeΣ1..1codeBinding
endpointΣ0..1url
payloadΣ0..1codeBinding
headerΣ0..*string


StructureDefinition Task

The core workflow resource for managing processing of a ServiceRequest from order through to delivery of a DiagnosticReport and completion is Task. Task tracking is a core requirement of the central Genomic Medicine Service.

Each ServiceRequest submitted will instantiate a series of High Level Tasks, which MAY be assigned to different organizations for managing the test request e.g. Sample Processing, Interpretation, Reporting etc. The full list of possible Task types/codes, their associated business statuses, and status reasons is pending internal review.

Tasks will be automatically created by the central broker but updates to statuses and attachment of input/output resources is the responsibility of the assigned organizations.

An illustrative diagram of the links between ServiceRequests and Tasks are provided below (for the initial sample processing). Note: not all resource links are represented, to increase legibility of the diagram. In most cases, the full library of 10 tasks, as defined within Genomic-Task-Code, will be 'spun-up', on submission of a Test order. Tasks related to Samples may be duplicated per Sample to allow tracking of work related to individual Samples as part of the same test request, or equally, may be omitted as in the case of Re-Analysis or Re-Interpretation where data from an existing sample is used, eliminating the need for additional wet-work. For the full cardinality breakdown see further guidance for the Task.code element.

Profile url FHIR Module Normative Status
http://hl7.org/fhir/StructureDefinition/Task HL7 International trial-use

idΣ0..1string
metaΣ0..1Meta
implicitRulesΣ ?!0..1uri
language0..1codeBinding
text0..1Narrative
contained0..*Resource
extensionI0..*Extension
modifierExtension?! I0..*Extension
identifier0..*Identifier
instantiatesCanonicalΣ0..1canonical(ActivityDefinition)
instantiatesUriΣ0..1uri
basedOnΣ I0..*Reference(Resource)
groupIdentifierΣ0..1Identifier
partOfΣ I0..*Reference(Task)
statusΣ ?!1..1codeBinding
statusReasonΣ0..1CodeableConcept
businessStatusΣ0..1CodeableConcept
intentΣ1..1codeBinding
priority0..1codeBinding
codeΣ0..1CodeableConcept
descriptionΣ0..1string
focusΣ I0..1Reference(Resource)
forΣ I0..1Reference(Resource)
encounterΣ I0..1Reference(Encounter)
executionPeriodΣ I0..1Period
authoredOnI0..1dateTime
lastModifiedΣ I0..1dateTime
requesterΣ I0..1Reference(Device | Organization | Patient | Practitioner | PractitionerRole | RelatedPerson)
performerType0..*CodeableConceptBinding
ownerΣ I0..1Reference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)
locationΣ I0..1Reference(Location)
reasonCode0..1CodeableConcept
reasonReferenceI0..1Reference(Resource)
insuranceI0..*Reference(Coverage | ClaimResponse)
note0..*Annotation
relevantHistoryI0..*Reference(Provenance)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
repetitions0..1positiveInt
periodI0..1Period
recipientI0..*Reference(Patient | Practitioner | PractitionerRole | RelatedPerson | Group | Organization)
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
type1..1CodeableConcept
valueBase64Binarybase64Binary
valueBooleanboolean
valueCanonicalcanonical()
valueCodecode
valueDatedate
valueDateTimedateTime
valueDecimaldecimal
valueIdid
valueInstantinstant
valueIntegerinteger
valueMarkdownmarkdown
valueOidoid
valuePositiveIntpositiveInt
valueStringstring
valueTimetime
valueUnsignedIntunsignedInt
valueUriuri
valueUrlurl
valueUuiduuid
valueAddressAddress
valueAgeAge
valueAnnotationAnnotation
valueAttachmentAttachment
valueCodeableConceptCodeableConcept
valueCodingCoding
valueContactPointContactPoint
valueCountCount
valueDistanceDistance
valueDurationDuration
valueHumanNameHumanName
valueIdentifierIdentifier
valueMoneyMoney
valuePeriodPeriod
valueQuantityQuantity
valueRangeRange
valueRatioRatio
valueSampledDataSampledData
valueSignatureSignature
valueTimingTiming
valueContactDetailContactDetail
valueContributorContributor
valueDataRequirementDataRequirement
valueExpressionExpression
valueParameterDefinitionParameterDefinition
valueRelatedArtifactRelatedArtifact
valueTriggerDefinitionTriggerDefinition
valueUsageContextUsageContext
valueDosageDosage
valueMetaMeta
valueReferenceReference()
id0..1string
extensionI0..*Extension
modifierExtensionΣ ?! I0..*Extension
type1..1CodeableConcept
valueBase64Binarybase64Binary
valueBooleanboolean
valueCanonicalcanonical()
valueCodecode
valueDatedate
valueDateTimedateTime
valueDecimaldecimal
valueIdid
valueInstantinstant
valueIntegerinteger
valueMarkdownmarkdown
valueOidoid
valuePositiveIntpositiveInt
valueStringstring
valueTimetime
valueUnsignedIntunsignedInt
valueUriuri
valueUrlurl
valueUuiduuid
valueAddressAddress
valueAgeAge
valueAnnotationAnnotation
valueAttachmentAttachment
valueCodeableConceptCodeableConcept
valueCodingCoding
valueContactPointContactPoint
valueCountCount
valueDistanceDistance
valueDurationDuration
valueHumanNameHumanName
valueIdentifierIdentifier
valueMoneyMoney
valuePeriodPeriod
valueQuantityQuantity
valueRangeRange
valueRatioRatio
valueSampledDataSampledData
valueSignatureSignature
valueTimingTiming
valueContactDetailContactDetail
valueContributorContributor
valueDataRequirementDataRequirement
valueExpressionExpression
valueParameterDefinitionParameterDefinition
valueRelatedArtifactRelatedArtifact
valueTriggerDefinitionTriggerDefinition
valueUsageContextUsageContext
valueDosageDosage
valueMetaMeta
valueReferenceReference()

Task-NonWGSRareDiseaseTestOrder-Cancellation-Example
Task-NonWGSRareDiseaseTestOrder-Example
Task-NonWGSRareDiseaseTestOrderAccepted-Example
Task-NonWGSRareDiseaseTestOrderAccepted-FetalScenario-Example
Task-NonWGSRareDiseaseTestOrderAccepted-FollowupTest-Example
Task-NonWGSRareDiseaseTestOrderAccepted-HaemOncology-Example
Task-NonWGSRareDiseaseTestOrderAccepted-Reanalysis-Example
Task-NonWGSRareDiseaseTestOrderAccepted-SufficientSample-Example
Task-NonWGSRareDiseaseTestOrderCancelled-FollowupTest-Example
Task-NonWGSRareDiseaseTestOrderCompleted-CascadeTesting-Example
Task-NonWGSRareDiseaseTestOrderCompleted-FollowupTest-Example
Task-NonWGSRareDiseaseTestOrderForwarded-OutOfCountry-Example
Task-NonWGSRareDiseaseTestOrderForwarded-SolidTumor-Example
Task-NonWGSRareDiseaseTestOrderRejected-Example
Task-NonWGSRareDiseaseTestOrderHold-Example
Task-NonWGSRareDiseaseTestOrderRejected-CancerSolidTumor-Example
Task-NonWGSRareDiseaseTestOrderRejected-FetalScenario-Example
Task-NonWGSRareDiseaseTestOrder-InsufficientSample-Example
Task-NonWGSTestOrderAccepted-VariantReinterpretation-Example
Task-NonWGSTestOrderFormAccepted-UsingStoredSample-Example
Task-TestOrderFormAccepted-StorageOfMaterial-Example
Task-WGSRareDiseaseTestOrder-Example
Task-WGSRareDiseaseTestOrderAccepted-Example
Task-WGSRareDiseaseTestOrderAccepted-DirectToLab-Example
Task-WGSRareDiseaseTestOrderAccepted-TrioTestingProband-Example
Task-WGSRareDiseaseTestOrderCompleted-DirectToLab-Example
Task-WGSRareDiseaseTestOrderCompleted-TrioTestingProband-Example
Task-WGSRareDiseaseTestOrderForwarded-Example
Task-WGSRareDiseaseTestOrderHold-DirectToLab-Example
Task-WGSRareDiseaseTestOrderHold-TrioTestingProband-Example
Task-WGSRareDiseaseTestOrderRequested-DirectToLab-Example
Task-NonWGSTestOrderFormRequested-UsingStoredSample-Example
Task-WGSRareDiseaseTestOrderAccepted-TrioTestingFather-Example
Task-WGSRareDiseaseTestOrderAccepted-TrioTestingMother-Example
FHIRMDSHL7v2
Task.executionPeriod.startPLCM activity - Activity start date and timeDerived from TQ1-7 in the ORL response message for the activity based on the OML request
Task.executionPeriod.endPLCM activity - Activity end date and timeDerived from TQ1-8 in the ORL response message for the activity based on the OML request
Task.ownerPLCM activity - ODS code of organisation submitting to PLCM, PLCM activity - ODS code of organisation delivering requested test, PLCM activity - ODS code of the laboratory site delivering requested testOBR-32.7 if sourced from principle results interpreter, OBX-32.10, AFF-2.10 associated with performing organization
Task.statusPLCM activity - Sample plating quality controlImplied through status recorded in ORC-25 indicating plating quality control had passed
Task.statusReasonPLCM activity - Sample plating quality control fail codeORC-25
Task.outputExtracted specimen - Location detailsSAC-15

Additional Guidance

basedOn

This element will not be used within the Genomic Medicine Service. The ServiceRequest a Task is seeking to fulfill SHALL be referenced through the `focus` element. Specimen resources being acted upon by tasks related to specimen prep/processing SHOULD be referenced through the `Task.input` element.

status

Initially, automatically populated by the central service upon instantiation. Tasks will be first marked as 'draft' until their prerequisites have been satisfied, after which they will be marked as 'requested' until accepted/claimed by an organization. Upon acceptance, the owning organization is responsible for updating the status up until completion (or if the owning organization is not integrated into the GMS, the organization who has referred the task to the unintegrated org).

If a ServiceRequest is cancelled, any Tasks which have not already moved into in-progress SHALL be moved into the cancelled state, any in-progress Tasks will require lab processes to manage closure of the Task and appropriate reimbursement.

For the full list of expected Task statuses in use by the GMS, please refer to the table below. For the allowed Task status transitions, please see the FHIR R4 Task state machine model.

Status Description Genomic workflow usage
Draft The task is not yet ready to be acted upon. Initial state for Tasks. Used for tasks which require prerequisite tasks to be completed first.
Requested The task is ready to be acted upon and action is sought. Status indicating a task can be worked on/claimed, all prerequisites have been satisfied.
Received A potential performer has claimed ownership of the task and is evaluating whether to perform it. NOT USED within Genomics as Tasks will be polled for rather than being sent out to assigned organizations. Most likely not used unless tasks are automatically assigned and organizations are notified by the central service, e.g. to GLH.
Accepted The potential performer has agreed to execute the task but has not yet started work. Used when an assigned owner has accepted the task after being assigned.
Rejected The potential performer who claimed ownership of the task has decided not to execute it prior to performing any action. Used if an organization was assigned to a task but is unable to perform work against it. It is expected if an alternative organization can be assigned, this is done as an owner update rather than marking the task as rejected. If subsequent work does occur, a duplicate task will need to be created as the 'rejected' state is a terminal one.
Ready The task is ready to be performed, but no action has yet been taken. Used in place of requested/received/accepted/rejected when request assignment and acceptance is a given. NOT USED within Genomics as it is not assumed that Tasks will be automatically accepted when prerequisites are satisfied.
Cancelled The task was not completed. Used when a task has been created but later identified as unneeded, e.g. due to modifications to test order such as the ServiceRequest being cancelled. Automatically set by the central broker.
In Progress The task has been started but is not yet complete. When work has commenced.
On Hold The task has been started but work has been paused. A holding state where work is expected to continue but is being blocked through some external issue. Suppliers will need to state reason why work is on hold through the statusReason field e.g. Awaiting Sample.
Failed The task was attempted but could not be completed due to some error. Indicates the task cannot continue and is unrcoverable without external intervention. If modifications to the test order allow the task to be resumed, a new task should be created e.g. a new sample is provided to replace a previous sample which has failed quality control. If the Task results in an unrecoverable error, the ServiceRequest may need to be revoked.
Completed The task has been completed. Marked once all actions against a task are complete, and follow on Tasks can commence.
Entered in Error The task should never have existed and is retained only because of the possibility it may have used. May be used if user created Tasks are created in error, e.g. duplicate Tasks, or Tasks have been created by the central broker and the ServiceRequest has subsequently been marked as entered-in-error.
"status": "rejected",

statusReason

Reasons why a Task has been marked as on-hold, cancelled etc. SHOULD use the Genomic-Task-StatusReason CodeSystem. NOTE: The list of appropriate statusReasons is pending finalization.
"statusReason": {
        "coding":  [
            {
                "system": "https://fhir.nhs.uk/CodeSystem/task-status-reason-genomics",
                "code": "further-information-needed",
                "display": "Further Information Needed"
            }
        ]
    },

businessStatus

Genomic specific business statuses for capturing more granular information as part of processing the task. SHOULD use the Genomic-Business-Status CodeSystem. NOTE: The list of appropriate buinessStatuses is pending finalization. Mapping business statuses to the high level container Tasks and statuses is still ongoing.
"businessStatus": {
        "coding":  [
            {
                "system": "https://fhir.nhs.uk/CodeSystem/business-status-genomics",
                "code": "sample-sent",
                "display": "Sample Sent"
            }
        ]
    },

code

High level coding for the Task, matches the NGTP stages for genomic test processing. Clients SHOULD use the Genomic-Task-Code CodeSystem. NOTE: The list of appropriate codes is pending finalization.

The currently allowed code list and their definition is provided in the table below. The table also provides the cardinality of each Task per ServiceRequest or Sample attached to the request as generated by the central broker on submission of a test request. Note: the cardinalities listed reflect the number of concurrent active tasks per service request at any one time, there may be cases where additional Tasks need to be spun up manually, e.g. on failure such as when a new sample needs to be processed after a previous sample fails Quality Control, or when further preparation is required. This cardinality supports the use cases for both requests with multiple participants, e.g. Duo/Trio, and multiple samples per participant e.g. Cancer testing.

Task.code display Definition of work within Task Cardinality (general case) Cardinality (Reanalysis/Reinterpretation) Cardinality (DNA Storage)
Process Genomic Test Request Test code requested is ratified by the lab against provided patient information (checking eligibility) 1..1 (per ServiceRequest) 1..1 1..1
Request & Sample Alignment The lab confirms/validates the data and sample(s) required for given test type are present 1..* (1 per Specimen referenced from or referencing the ServiceRequest) 1..1 (At least 1 will always be required, e.g. for validation of data in the No Sample scenario) 1..* (per Sample)
Sample Preparation Sample is prepared, as appropriate for the selected test type, and DNA extracted. May have multiples if further preparation is required 1..* (1 per Sample) 0..0 (Not required for Reanalysis/Reinterpretation requests where a sample does not need to be prepared) 1..* (1 per Sample)
Sample Processing DNA sample(s) are sequenced, generating read/sequence data to feed into analysis 1..* (1 per Sample or extracted DNA sample) 0..0 (Not required for Reanalysis/Reinterpretation requests where a sample does not need to be sequenced) 0..0 (Not required for DNA storage where a sample does not need to be sequenced)
Genetic/Genomic Data Processing Sequence data is passed through a bio-pipeline, generates variant priorities lists for analysis 1..* (1 per Sample or read data) 0..* (For Reanalysis, should match the number of Samples for the parent request. Not required for Reinterpretation requests) 0..0 (Not required for DNA storage requests)
Interpretation Results analysis is organised and interpreted by a Clincial Scientist 1..* (1 per Sample or variant priorities list) 1..* (For Reanalysis/Reinterpretation, should match the number of Samples for the parent request 0..0 (Not required for DNA storage requests)
Produce Interim Report A report is created and deemed interim pending MDT, if necessary 1..* (1 per Sample. TBC whether one interim report would be generated per sample/set of genetic data or 1 per request) 1..* (For Reanalysis/Reinterpretation, should match the number of Samples for the parent request 0..0 (Not required for DNA storage requests)
Genomic MDT Multi-Diciplinary-Team consults on the interim report 1..1 (max 1 per ServiceRequest, for the purposes of the Alpha an MDT task will always be created, even if not needed) 1..1 0..0 (Not required for DNA storage requests)
Produce Final Report Interim report is deemed final or is updated following MDT 1..1 (per ServiceRequest) 1..1 1..1
Distribute Report Final report is distributed or marked as distributable/available 1..1 (per ServiceRequest or Final Report) 1..1 1..1

Rendered within a diagram, the Task cardinalities and their inputs are illustrated in the diagram below:

GenomicOrderManagementTaskModel

"code": {
        "coding":  [
            {
                "system": "https://fhir.nhs.uk/CodeSystem/task-code-genomics",
                "code": "sample-processing",
                "display": "Sample Processing"
            }
        ]
    },

focus

The ServiceRequest the Task is fulfilling. Autopopulated by the central service.
"focus": {
        "reference": "ServiceRequest/ServiceRequest-SavedTestOrder-Example"
    },

for

A reference to the Patient resource or the identifier, NHS number, for the patient for whom the Task is for. Autopopulated by the central service if the Task is automatically generated.

If a Task is created by client system or user interaction, for SHALL be populated with a reference to the associated Patient. This MAY be through a resource reference if the ID on the central service is known (or provided within the transaction bundle) or through NHS number where this is known and has been traced through PDS.

"for": {
        "reference": "Patient/Patient-MeirLieberman-Example",
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/nhs-number",
            "value": "9449307873"
        }
    },

executionPeriod

MAY be used to capture start and end DateTimes associated with execution of a Task. It is expected the start time will be populated as a Task is moved to in-progress and the end time will be populated as a Task is marked as completed. Usage of this field will be investigated during the Alpha phase of the Genomic Order Management project as timelines for task execution can also be derived from the AuditEvents recorded as Tasks are updated.
"executionPeriod": {
        "start": "2023-10-31T10:25:05+00:00",
        "end": "2023-11-15T16:45:05+00:00"
    },

authoredOn

Autopopulated by the central service on creation of the Task.
"authoredOn": "2023-09-18T18:30:00Z"

lastModidified

Time at which a change to the task was made, e.g. status updated. SHALL be updated on change.
"lastModified": "2023-09-18T19:11:00Z"

requester

The original requester of the ServiceRequest the Task is fulfilling. Autopopulated by the central service.
"requester": {
        "reference": "PractitionerRole/PractitionerRole-GeneSmithENT-Example"
    },

owner

Autopopulated by the central service if a performer is assigned at Test submission. By default, this will the Home GLH for the submitting organization, unless an alternative is specified. The Home GLH/original performer (managing entity) SHOULD remain the owner for the Process Genomic Test Task, throughout the test order-fulfillment process.

This field can be updated by the organization claiming the task (though this could also be autopopulated if automated per test routing tables are integrated into the central service functionality). Owner SHOULD be populated using organization ODS code references.

The responsibility for routing/reassigning ownership of Tasks lies with the current owner following the transfers of responsibility as per the National Genomic Testing Process (NGTP). The different scenarios for how follow-on routing may be achieved is summarised in the points below:

  • In most cases, by default the test will be routed to the home GLH (or other lab/GLH as dictated by the initial routing table).
  • This would mean all Tasks by default would have this organization, e.g. home GLH, as the initial owner, it would then be the responsibility of the GLH to reassign tasks to other organizations, where they 'send away' or commission work.
  • Once that work is complete, the send-away organization can choose to reassign the current Task (where another organization needs to conduct work against the same Task before it can be marked as complete)/or assign the follow-on Task (where the current task can be marked as complete) to the next organization, if this is known.
  • If the next organization to send work to is unknown, responsibility should lie with the original/previous owner e.g. Home GLH to reassign the task to the next organization that needs to complete work. This should be captured by having the current owner reassign the task back to the GLH (or organization which assigned the task to them) if further work needs to occur within the current task; or the next task in the NGTP moves from the draft state into the requested state (indicating all its prerequisites have been satisfied). The owner of that task, e.g home GLH, then either starts work or assigns this to the relevant organization.
  • In further phases, a routing advice service may be provided by NHS England to aid organizations in identifying which organization should be assigned, after completing their work.

Tasks assigned to a particular organization SHOULD be searched for using the owner search parameter with the :identifier modifier i.e. [base]/Task?owner:identifier=8J834 or [base]/Task?owner:identifier=https://fhir.nhs.uk/Id/ods-organization-code|8J834

"owner": {
        "identifier": {
            "system": "https://fhir.nhs.uk/Id/ods-organization-code",
            "value": "69010"
        },
        "display": "Pathology Lab - ADDENBROOKE'S HOSPITAL LABORATORY"
    },

note

Used for messaging between owner and other orgnizations e.g. during handover of task or requesting information from requesting clinician.
"note":  [
        {
            "text": "Sample has not been received within 4 week window. Task will be closed unless further communication is received"
        }
    ]

input

Used to attach inputs to a Task, if relevant. e.g. references to Specimen's which a Sample Processing task is acting on. No CodeSystem exists for this field as of publication but this will be investigated as future work.

Specimen references SHOULD be added to Tasks acting on Specimen resources, e.g. Tasks marked SamplePreparation or SampleProcessing. This is to clearly disambiguate which specimen a task is acting on, where multiple specimens are necessary for processing the test request.

The table below provides possible inputs that could be provided for certain Tasks as part of fulfillment of a test order. A finalised list is pending business analysis work to identify the operational data generated as fulfilment against a test order progresses and the need for this data to pass between organizations.

Task.code display Possible Task.input
Process Genomic Test Request N/A, all information required should be part of or refernced from the ServiceRequest
Request & Sample Alignment Specimen resource to be aligned and potentially Consent resources where these are captured post submission of a test request
Sample Preparation Specimen resource to be prepared as part of this Task
Sample Processing DNA Specimen resource to be sequenced as part of this Task as well as Consignment, Rack and Well identifiers to allow for specimen tracking
Genetic/Genomic Data Processing Sequence data generated from the previous Task, potentially referenced using DocumentReference resources, these SHOULD reference the Specimen from which the data originated
Interpretation Variant Priorities lists generated from the previous Task, the representation of these lists is still under investigation
Produce Interim Report Guidance/Recommendations generated though data interpretation, the representation of these items is still under investigation
Genomic MDT Interim reports, references to Diagnostic report resources containing either structured Genomic reports or binary representations of the reports
Produce Final Report Interim reports and potentially recommendations from the MDT, whether these are represented within the DiagnosticReport itself or contained as other resource types is still under investigation
Distribute Report The final report to be distributed
"input":  [
    {
            "type": {
                "coding":  [
                    {
                        "system": "https://fhir.nhs.uk/CodeSystem/AdditionalInfoTypeGenomics",
                        "code": "Specimen",
                        "display": "Specimen"
                    }
                ]
            },
            "valueReference": {
                "reference": "Specimen/Specimen-CancerSolidTumor-Example"
            }
        }
    ]

output

Used to attach outputs from a Task, if relevant. e.g. VUS files during processing or a DiagnosticReport upon completion of reporting stage. No CodeSystem exists for this field as of publication but this will be investigated as future work.

Sample tracking information SHOULD be added to Tasks acting on Specimen resources, e.g. Tasks marked SamplePreparation or SampleProcessing, on either the output or input elements. This information MAY include consignment number, destination, date sent etc. Further modelling of the types/format expected are pending clinical scenarios.

The table below provides possible outputs that could be generated by certain Tasks as part of fulfillment of a test order. A finalised list is pending business analysis work to identify the operational data generated as fulfilment against a test order progresses and the need for this data to pass between organizations.

Task.code display Possible Task.output
Process Genomic Test Request N/A, may result in updates to the ServiceRequest if codes or supporting information needs to change
Request & Sample Alignment Aligned Specimen resource for request (except for Reanalysis/Reinterpretation)
Sample Preparation DNA Specimen resource as well as Consignment, Rack and Well identifiers to allow for specimen tracking
Sample Processing Sequence/Read data
Genetic/Genomic Data Processing Variant information
Interpretation Potentially structured guidance/recommendations
Produce Interim Report Interim reports
Genomic MDT Potentially ammended Interim/combined report or recommendations from MDT
Produce Final Report Final Report
Distribute Report N/A, final report will be included as input to Task
"output":  [
       {
          "type": {
            "coding": [
              {
                "system": "https://fhir.nhs.uk/CodeSystem/AdditionalInfoTypeGenomics",
                "code": "DiagnosticReport",
                "display": "DiagnosticReport"
              }
            ]
          },
          "valueReference": {
            "reference": "DiagnosticReport/DiagnosticReport-PhoebeSmithGeneticReport-Example"
          }
        }
    ]