Implementation Guide for the NHS Genomics Medicine Service
Notice
Important: This guidance is under active development by NHS England and content may be added or updated on a regular basis.
This Implementation Guide is currently in Draft and SHOULD NOT be used for development or active implementation without express direction from the NHS England Genomics Unit.
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.
Note on inheritance from prior requests
It is expected that the ServiceRequest.basedOn SHALL reference a parent request where this ServiceRequest is based a previous request, e.g. in the case of reanalysis (where prior outputs/data are used) and cascade testing (where processing of a prior request has triggered the current request), or Germline Late tests in the Tumour First/Germline Late scenario (to link tests which need to be processed together).
It is expected that the prior request should be referenced from ServiceRequest.basedOn if data or outputs from the prior request are required in order to properly interpret the current request. If a banked sample needs to be processed, e.g. in the case of a request on Stored DNA, it is expected that this would be referenced directly from ServiceRequest.specimen.
Where multiple samples are associated with a previous request, it is expected only one would be active, e.g. marked as available. Additionally, in most cases the data is required, rather than reprocessing of the sample itself, in which case referencing the previous request is sufficient. However, if there are multiple active samples associated with a previous request, and a subset of the samples need to be reprocessed, the sample(s) itself SHOULD be referenced from ServiceRequest.specimen as above. If multiple outputs, i.e. data from multiple samples, are associated with a previous request, a ServiceRequest MAY reference the data to be reinterpreted/reanalysed through ServiceRequest.supportingInfo.
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.
dom-2: If the resource is contained in another resource, it SHALL NOT contain nested Resources contained.contained.empty()
dom-3: If the resource is contained in another resource, it SHALL be referred to from elsewhere in the resource or SHALL refer to the containing resource contained.where((('#'+id in (%resource.descendants().reference | %resource.descendants().as(canonical) | %resource.descendants().as(uri) | %resource.descendants().as(url))) or descendants().where(reference = '#').exists() or descendants().where(as(canonical) = '#').exists() or descendants().where(as(canonical) = '#').exists()).not()).trace('unmatched', id).empty()
dom-4: If a resource is contained in another resource, it SHALL NOT have a meta.versionId or a meta.lastUpdated contained.meta.versionId.empty() and contained.meta.lastUpdated.empty()
dom-5: If a resource is contained in another resource, it SHALL NOT have a security label contained.meta.security.empty()
dom-6: A resource should have narrative for robust management text.`div`.exists()
prr-1: orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()
There are no (further) constraints on this element
Element id
ServiceRequest.meta
Short description
Metadata about the resource
Definition
The metadata about the resource. This is content that is maintained by the infrastructure. Changes to the content might not always be associated with version changes to the resource.
There are no (further) constraints on this element
Element id
ServiceRequest.implicitRules
Short description
A set of rules under which this content was created
Definition
A reference to a set of rules that were followed when the resource was constructed, and which must be understood when processing the content. Often, this is a reference to an implementation guide that defines the special rules along with other profiles etc.
Comments
Asserting this rule set restricts the content to be only understood by a limited set of trading partners. This inherently limits the usefulness of the data in the long term. However, the existing health eco-system is highly fractured, and not yet ready to define, collect, and exchange data in a generally computable sense. Wherever possible, implementers and/or specification writers should avoid using this element. Often, when used, the URL is a reference to an implementation guide that defines these special rules as part of it's narrative along with other profiles, value sets, etc.
There are no (further) constraints on this element
Element id
ServiceRequest.language
Short description
Language of the resource content
Definition
The base language in which the resource is written.
Comments
Language is provided to support indexing and accessibility (typically, services such as text to speech use the language tag). The html language tag in the narrative applies to the narrative. The language tag on the resource may be used to specify the language of other presentations generated from the data in the resource. Not all the content has to be in the base language. The Resource.language should not be assumed to apply to the narrative automatically. If a language is specified, it should it also be specified on the div element in the html (see rules in HTML5 for information about the relationship between xml:lang and the html lang attribute).
There are no (further) constraints on this element
Element id
ServiceRequest.text
Short description
Text summary of the resource, for human interpretation
Alternate names
narrative, html, xhtml, display
Definition
A human-readable narrative that contains a summary of the resource and can be used to represent the content of the resource to a human. The narrative need not encode all the structured data, but is required to contain sufficient detail to make it "clinically safe" for a human to just read the narrative. Resource definitions may define what content should be represented in the narrative to ensure clinical safety.
Comments
Contained resources do not have narrative. Resources that are not contained SHOULD have a narrative. In some cases, a resource may only have text with little or no additional discrete data (as long as all minOccurs=1 elements are satisfied). This may be necessary for data from legacy systems where information is captured as a "text blob" or where text is additionally entered raw or narrated and encoded information is added later.
These resources do not have an independent existence apart from the resource that contains them - they cannot be identified independently, and nor can they have their own independent transaction scope.
Comments
This should never be done when the content can be identified properly, as once identification is lost, it is extremely difficult (and context dependent) to restore it again. Contained resources may have profiles and tags In their meta elements, but SHALL NOT have security labels.
May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Supports recording of additional contacts, who should be contacted regarding questions arising from the service request. This differs from the requester and responsibleClinician.
Alternate names
extensions, user content
Definition
Details of an additional contact, who should be contacted regarding questions arising from the service request.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Supports the exchange of information describing the method of funding for the Service Request.
Alternate names
extensions, user content
Definition
The funding category for the Service Request.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
There are no (further) constraints on this element
Element id
ServiceRequest.modifierExtension
Short description
Extensions that cannot be ignored
Alternate names
extensions, user content
Definition
May be used to represent additional information that is not part of the basic definition of the resource and that modifies the understanding of the element that contains it and/or the understanding of the containing element's descendants. Usually modifier elements provide negation or qualification. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer is allowed to define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension. Applications processing a resource are required to check for modifier extensions.
Modifier extensions SHALL NOT change the meaning of any elements on Resource or DomainResource (including cannot change the meaning of modifierExtension itself).
Requirements
Modifier extensions allow for extensions that cannot be safely ignored to be clearly distinguished from the vast majority of extensions which can be safely ignored. This promotes interoperability by eliminating the need for implementers to prohibit the presence of extensions. For further information, see the definition of modifier extensions.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
There are no (further) constraints on this element
Element id
ServiceRequest.identifier
Short description
Identifiers assigned to this order
Definition
Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.
Comments
The identifier.type element is used to distinguish between the identifiers assigned by the orderer (known as the 'Placer' in HL7 v2) and the producer of the observations in response to the order (known as the 'Filler' in HL7 v2). For further discussion and examples see the resource notes section below.
There are no (further) constraints on this element
Element id
ServiceRequest.instantiatesCanonical
Short description
Instantiates FHIR protocol or definition
Definition
The URL pointing to a FHIR-defined protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest.
Comments
Note: This is a business identifier, not a resource identifier (see discussion). It is best practice for the identifier to only appear on a single resource instance, however business practices may occasionally dictate that multiple resource instances with the same identifier can exist - possibly even with different resource types. For example, multiple Patient and a Person resource instance might share the same social insurance number.
There are no (further) constraints on this element
Element id
ServiceRequest.instantiatesUri
Short description
Instantiates external protocol or definition
Definition
The URL pointing to an externally maintained protocol, guideline, orderset or other definition that is adhered to in whole or in part by this ServiceRequest.
Comments
This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.
There are no (further) constraints on this element
Element id
ServiceRequest.requisition
Short description
Composite Request ID
Alternate names
grouperId, groupIdentifier
Definition
A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.
Requirements
Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.
Comments
Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.
The status is generally fully in the control of the requester - they determine whether the order is draft or active and, after it has been activated, competed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding event (see Event Pattern for general discussion) or using the Task resource.
A code that classifies the service for searching, sorting and display purposes.
Definition
A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").
Requirements
Used for filtering what service request are retrieved and displayed.
Comments
There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.
A code that classifies the service for Genomics, whether it is a Whole Case Genome Sequencing or non-Whole Genome Sequencing for cancer or rare diseases
Requirements
Used for filtering what service request are retrieved and displayed.
Comments
There may be multiple axis of categorization depending on the context or use case for retrieving or displaying the resource. The level of granularity is defined by the category concepts in the value set.
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
A reference to a code defined by a terminology system.
Requirements
Allows for alternative encodings within a code system, and translations to other code systems.
Comments
Codes may be defined very casually in enumerations, or code lists, up to very formal definitions such as SNOMED CT - see the HL7 v3 Core Principles for more information. Ordering of codings is undefined and SHALL NOT be used to infer meaning. Generally, at most only one of the coding values will be labeled as UserSelected = true.
May be used to represent additional information that is not part of the basic definition of the element. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
The identification of the code system that defines the meaning of the symbol in the code.
Requirements
Need to be unambiguous about the source of the definition of the symbol.
Comments
The URI may be an OID (urn:oid:...) or a UUID (urn:uuid:...). OIDs and UUIDs SHALL be references to the HL7 OID registry. Otherwise, the URI should come from HL7's list of FHIR defined special URIs or it should reference to some definition that establishes the system clearly and unambiguously.
The version of the code system which was used when choosing this code. Note that a well-maintained code system does not need the version reported, because the meaning of codes is consistent across versions. However this cannot consistently be assured, and when the meaning is not guaranteed to be consistent, the version SHOULD be exchanged.
Comments
Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.
A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).
Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).
Requirements
This has been identified as a clinical safety criterium - that this exact system/code pair was chosen explicitly, rather than inferred by the system based on some rules or language processing.
Comments
Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.
A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.
Requirements
The codes from the terminologies do not always capture the correct meaning with all the nuances of the human using them, or sometimes there is no appropriate code at all. In these cases, the text is used to capture the full meaning of the source.
Comments
Very often the text is the same as a displayName of one of the codings.
May be used to represent additional information that is not part of the basic definition of the resource. To make the use of extensions safe and manageable, there is a strict set of governance applied to the definition and use of extensions. Though any implementer can define an extension, there is a set of requirements that SHALL be met as part of the definition of the extension.
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
Supports the underlying reason why a Service Request is urgent.
Alternate names
extensions, user content
Definition
A SNOMED CT concept representing the reason a Service Request is urgent
Comments
There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone.
There are no (further) constraints on this element
Element id
ServiceRequest.doNotPerform
Short description
True if service/procedure should not be performed
Definition
Set this to true if the record is saying that the service/procedure should NOT be performed.
Requirements
Used for do not ambulate, do not elevate head of bed, do not flush NG tube, do not take blood pressure on a certain arm, etc.
Comments
In general, only the code and timeframe will be present, though occasional additional qualifiers such as body site or even performer could be included to narrow the scope of the prohibition. If the ServiceRequest.code and ServiceRequest.doNotPerform both contain negation, that will reinforce prohibition and should not have a double negative interpretation.
Meaning when missing
If missing, the request is a positive request e.g. "do perform"
A code that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested.
Comments
Many laboratory and radiology procedure codes embed the specimen/organ system in the test order name, for example, serum or serum/plasma glucose, or a chest x-ray. The specimen might not be recorded separately from the test code.
Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.
Comments
For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.
The cardinality or value of this element may be affected by these constraints: prr-1
Constraints
ele-1: All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
Mappings
v2: NTE
rim: .code
quick: Procedure.procedureCode
quantity[x]
Σ
0..1
There are no (further) constraints on this element
Element id
ServiceRequest.quantity[x]
Short description
Service amount
Definition
An amount of service being requested which can be a quantity ( for example $1,500 home modification), a ratio ( for example, 20 half day visits per month), or a range (2.0 to 1.8 Gy per fraction).
Requirements
When ordering a service the number of service items may need to be specified separately from the the service item.
Constraints
ele-1: All FHIR elements must have a @value or children hasValue() or (children().count() > id.count())
The individual or entity the service is ordered for.
Definition
On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).
The individual who initiated the request and has responsibility for its activation.
Comments
This not the dispatcher, but rather who is the authorizer. This element is not intended to handle delegation which would generally be managed through the Provenance resource.
There are no (further) constraints on this element
Element id
ServiceRequest.performerType
Short description
Performer role
Alternate names
specialty
Definition
Desired type of performer for doing the requested service.
Comments
This is a role, not a participation type. In other words, does not describe the task but describes the capacity. For example, “compounding pharmacy”, “psychiatrist” or “internal referral”.
There are no (further) constraints on this element
Element id
ServiceRequest.performer
Short description
Requested performer
Alternate names
request recipient
Definition
The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.
Comments
If multiple performers are present, it is interpreted as a list of alternative performers without any preference regardless of order. If order of preference is needed use the request-performerOrder extension. Use CareTeam to represent a group of performers (for example, Practitioner A and Practitioner B).
Explanation/Justification for procedure or service
Definition
An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInfo.
Comments
This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. Use CodeableConcept.text element if the data is free (uncoded) text as shown in the CT Scan example.
There are no (further) constraints on this element
Element id
ServiceRequest.reasonReference
Short description
Explanation/Justification for service or service
Definition
Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.
Comments
This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to Observation or Condition should be used if available. Otherwise when referencing DiagnosticReport it should contain a finding in DiagnosticReport.conclusion and/or DiagnosticReport.conclusionCode. When using a reference to DocumentReference, the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in ServiceRequest.reasonCode if the data is free (uncoded) text as shown in the CT Scan example.
There are no (further) constraints on this element
Element id
ServiceRequest.supportingInfo
Short description
Additional clinical information
Alternate names
Ask at order entry question, AOE
Definition
Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.
Comments
To represent information about how the services are to be delivered use the instructions element.
There are no (further) constraints on this element
Element id
ServiceRequest.specimen
Short description
Procedure Samples
Definition
One or more specimens that the laboratory procedure will use.
Comments
Many diagnostic procedures need a specimen, but the request itself is not actually about the specimen. This element is for when the diagnostic is requested on already existing specimens and the request points to the specimen it applies to. Conversely, if the request is entered first with an unknown specimen, then the Specimen resource points to the ServiceRequest.
Anatomic location where the procedure should be performed. This is the target site.
Requirements
Knowing where the procedure is performed is important for tracking if multiple sites are possible.
Comments
Only used if not implicit in the code found in ServiceRequest.code. If the use case requires BodySite to be handled as a separate resource instead of an inline coded element (e.g. to identify and track separately) then use the standard extension procedure-targetBodyStructure.
There are no (further) constraints on this element
Element id
ServiceRequest.relevantHistory
Short description
Request provenance
Definition
Key events in the history of the request.
Comments
This might not include provenances for all versions of the request – only those deemed “relevant” or important.
This SHALL NOT include the Provenance associated with this current version of the resource. (If that provenance is deemed to be a “relevant” change, it will need to be added as part of a later update. Until then, it can be queried directly as the Provenance that points to this version using _revinclude
All Provenances should have some historical version of this Request as their subject.
Requester (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 request
Various ORC/STF segments
ServiceRequest.extension:additionalContact
Additional Contact (more details in PractitionerRole resource mappings)
Various STF segments
ServiceRequest.subject
Patient (more details in Patient resource mappings), Patient - Is relative
First PID segment in OML message, relatives referenced through NK1 segments
ServiceRequest.identifier
Test request - Test request id, PLCM activity - NGIS referral identifier, Previous genomic report - Report lab test number
ORC-2, ORC-3
ServiceRequest.extension:coverage
Test request - Payment status
IN1-15
ServiceRequest.authoredOn
Test 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.priority
Test request - Is urgent
TQ1-9
ServiceRequest.extension:priorityReason
Test request - Urgency reason
N/A could possibly use TQ1-10
ServiceRequest.code.coding.system
Test request - Test Directory version
OBR-4.3
ServiceRequest.code
Test 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 code
OBR-4
ServiceRequest.orderDetail
Test request - CI code for multipurpose CITT, Test request - Type of reanalysis, Test request - DNA storage information
NTE segment attached to OBR
ServiceRequest.category
Test request - Reason for testing, Test request - Reason for reanalysis
Likely ORC-29
ServiceRequest.supportingInfo
Test request - Detail of reason for reanalysis, Test request - Further information
NTE segments linked to OBR segment for reanalysis reason, Additional segments attached to ORC/OBR
ServiceRequest.occurrenceDateTime
Test request - Date report required by
OBR-8
ServiceRequest.performer
PLCM activity - ODS code of organisation commissioned to deliver requested test
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.
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.
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.
SHALL reference a parent request where this ServiceRequest is based on a previous request, e.g. in the case of reanalysis (where prior outputs/data are used) and cascade testing (where processing of a prior request has triggered the current request), or Germline Late tests in the Tumour First/Germline Late scenario (to link tests which need to be processed together).
It is expected that the prior request should be referenced from ServiceRequest.basedOn if data or outputs from the prior request are required in order to properly interpret the current request. If a banked sample needs to be processed, e.g. in the case of a request on Stored DNA, it is expected that this would be referenced directly from ServiceRequest.specimen.
Where multiple samples are associated with a previous request, it is expected only one would be active, e.g. marked as available. Additionally, in most cases the data is required, rather than reprocessing of the sample itself, in which case referencing the previous request is sufficient. However, if there are multiple active samples associated with a previous request, and a subset of the samples need to be reprocessed, the sample(s) itself SHOULD be referenced from ServiceRequest.specimen as above. If multiple outputs, i.e. data from multiple samples, are associated with a previous request, a ServiceRequest MAY reference the data to be reinterpreted/reanalysed through ServiceRequest.supportingInfo.
SHALL be provided. ServiceRequests SHOULD be marked as `draft` until ready to be acted upon, after which the user should mark the ServiceRequest as `active`.
A ServiceRequest with the status of draft is assumed to be incomplete, i.e. missing information required for further processing. As such, a central order management broker SHOULD refrain from adding Tasks for the ServiceRequest until it is marked as active, at which time the necessary Tasks are spun up automatically by the broker (this is to be tested within the Genomic Order Management beta). Keeping a ServiceRequest in the draft state allows other parties to populate additional data required, such as phenotypic information from a dedicated service, or further information via a web portal. It is expected that draft ServiceRequests will be purged from the system after a period of inactivity with appropriate warnings (yet to be determined) to avoid stale orders from obscuring live tests/results.
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.
For the Genomic Order Management Service central broker, in some instances the ServiceRequest.status value is cascaded down to Tasks which are generated to fulfill that request.
The list of automated state transitions from ServiceRequests to all Tasks pointing to the ServiceRequest via Task.focus are provided in the table below:
ServiceRequest.status
Task.status
Note
active
requested
Not implemented within alpha, however it is expected the transition of a ServiceRequest from draft to active will allow Tasks to be spun up with a default state of requested
revoked
cancelled
Only tasks which have not moved to in-progress or subsequent stages can be automatically marked as cancelled, as these Tasks will require the owners to perform sone form of closure activities upon revokation of a request
entered-in-error
entered-in-error
This status transition is only permissible if none of the Tasks have moved into in-progress or their subsequent states, if this is the case, the ServiceRequest will need to be marked as revoked instead
on-hold
on-hold
TBC Not implemented within the alpha but Tasks may be automatically moved to on-hold of the focal request is marked as on-hold, to stop unneccessary processing/work against tasks
completed
completed
TBC Not implemented within the alpha but Tasks may be automatically moved to completed if the focal request is marked as completed, to reduce orphaned Tasks
It is not expected that Task statuses will propagate up to the ServiceRequest status, though certain task failure types may require revokation of the authorising request (pending investigation).
"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 SHOULD additionally 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, the Genomic-Reason-for-Testing CodeSystem SHOULD be used for this categorisation.
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.
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.
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
Extension-GenomicTestCode-Version:
The DGTS (Genomic Test Services) and PanelApp both maintain release versions and individual test code versions. The Extension-GenomicTestCode-Version has been provided to record specific test code version number, as shown in the snippet below:
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
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",
authoredOn
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).
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).
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.
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
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.
To support disambiguation of notes originating from different fields in a client system, the AnnotationType extension MAY be used, specifying the UI element name in text (coded elements for the full list of free text UI elements expected within Test Order forms is pending finalisation and addition to the Genomic Order Management MDS). The author element MAY also be used to reference a Practitioner, by identifier or name (string), indicating the person who created the note.
"note": [
{
"extension": [
{
"url": "http://hl7.org/fhir/StructureDefinition/annotationType",
"valueCodeableConcept": {
"text": "Has any other members of the family previously had genomic testing (e.g. BRACA, NIPD testing etc)?"
}
}
],
"authorReference": {
"identifier": {
"system": "https://fhir.nhs.uk/Id/sds-user-id",
"value": "9999999999"
},
"display": "Dr. Gene Smith"
},
"text": "No family history of genomic testing"
}
]
