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"
        }
    ]