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 NHSEngland-ServiceRequest-Genomics
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 prior test which contain clinical context).
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.
| Profile url | FHIR Module | Normative Status |
|---|---|---|
| https://fhir.nhs.uk/StructureDefinition/NHSEngland-ServiceRequest-Genomics | NHS England Genomics | trial-use |
| Canonical_URL | Status | Current_Version | Last_Updated | Description |
|---|---|---|---|---|
| https://fhir.nhs.uk/StructureDefinition/NHSEngland-ServiceRequest-Genomics | active | 0.3.0 | 2026-04-16 | This profile defines the Genomics constraints and extensions on the UK Core FHIR resource ServiceRequest. |
Tree View
| NHSEngland_ServiceRequest_Genomics (ServiceRequest) | C | UKCoreServiceRequest | |
| id | Σ | 0..1 | id |
| meta | Σ | 0..1 | Meta |
| implicitRules | Σ ?! | 0..1 | uri |
| language | 0..1 | codeBinding | |
| text | 0..1 | Narrative | |
| contained | 0..* | Resource | |
| extension | C | 1..* | Extension |
| sourceOfServiceRequest | C | 0..1 | Extension(CodeableConcept) |
| additionalContact | C | 0..* | Extension(Reference(Organization | Practitioner | PractitionerRole)) |
| coverage | C | 1..1 | Extension(CodeableConcept) |
| genomicParticipantCount | C | 0..1 | Extension(integer) |
| genomicPatientRole | C | 0..1 | Extension(CodeableConcept)Binding |
| modifierExtension | ?! C | 0..* | Extension |
| identifier | Σ | 1..* | Identifier |
| identifierGMSOrder | Σ | 0..1 | Identifier |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| use | Σ ?! | 0..0 | codeBinding |
| type | Σ | 0..0 | CodeableConceptBinding |
| system | Σ | 1..1 | uriFixed Value |
| value | Σ | 1..1 | string |
| period | Σ C | 0..0 | Period |
| assigner | Σ C | 0..0 | Reference(Organization) |
| localIdentifier | Σ | 0..* | Identifier |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| use | Σ ?! | 0..1 | codeBinding |
| type | Σ | 0..1 | CodeableConceptBinding |
| system | Σ | 1..1 | uriFixed Value |
| value | Σ | 1..1 | string |
| period | Σ C | 0..1 | Period |
| assigner | Σ C | 1..1 | Reference(Organization) |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| reference | Σ C | 0..0 | string |
| type | Σ | 0..1 | uriBinding |
| identifier | Σ | 1..1 | IdentifierFixed Value |
| display | Σ | 0..1 | string |
| instantiatesCanonical | Σ | 0..* | canonical(ActivityDefinition | PlanDefinition) |
| instantiatesUri | Σ | 0..* | uri |
| basedOn | S Σ C | 0..* | Reference(CarePlan | UKCoreMedicationRequest | NHSEngland_ServiceRequest_Genomics) |
| replaces | Σ C | 0..1 | Reference(NHSEngland_ServiceRequest_Genomics) |
| requisition | Σ | 0..1 | Identifier |
| status | S Σ ?! | 1..1 | codeBinding |
| intent | S Σ ?! | 1..1 | codeBinding |
| category | S Σ | 1..* | CodeableConcept |
| genomicsWholeCaseSequencing | Σ | 0..* | CodeableConceptBinding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| coding | Σ | 0..* | Coding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| system | Σ | 0..1 | uriFixed Value |
| version | Σ | 0..1 | string |
| code | Σ | 0..1 | code |
| display | Σ | 0..1 | string |
| userSelected | Σ | 0..1 | boolean |
| text | Σ | 0..1 | string |
| reasonForTesting | S Σ | 1..* | CodeableConceptBinding |
| priority | S Σ | 0..1 | codeBinding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| priorityReason | C | 0..* | Extension(CodeableConcept) |
| value | 0..1 | System.String | |
| doNotPerform | Σ ?! | 0..0 | boolean |
| code | S Σ | 1..1 | CodeableConceptBinding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| coding | Σ | 0..* | Coding |
| DGTSCode | Σ | 0..1 | Coding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| genomicTestCodeVersion | C | 0..* | Extension(decimal) |
| system | Σ | 0..1 | uriFixed Value |
| version | Σ | 0..1 | string |
| code | Σ | 0..1 | code |
| display | Σ | 0..1 | string |
| userSelected | Σ | 0..1 | boolean |
| text | Σ | 0..1 | string |
| orderDetail | Σ C | 0..* | CodeableConceptBinding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| coding | Σ | 0..* | Coding |
| genomicsTestPanelCode | Σ | 0..* | Coding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| genomicTestCodeVersion | C | 0..* | Extension(decimal) |
| system | Σ | 0..1 | uriFixed Value |
| version | Σ | 0..1 | string |
| code | Σ | 0..1 | code |
| display | Σ | 0..1 | string |
| userSelected | Σ | 0..1 | boolean |
| text | Σ | 0..1 | string |
| quantity[x] | Σ | 0..0 | |
| subject | S Σ C | 1..1 | Reference(NHSEngland_Patient_Genomics) |
| encounter | Σ C | 0..1 | Reference(Encounter) |
| occurrence[x] | Σ | 0..1 | |
| occurrenceDateTime | dateTime | ||
| occurrencePeriod | Period | ||
| occurrenceTiming | Timing | ||
| asNeeded[x] | Σ | 0..0 | |
| authoredOn | S Σ | 1..1 | dateTime |
| requester | S Σ C | 1..1 | Reference(NHSEngland_PractitionerRole_Genomics) |
| performerType | Σ | 0..0 | CodeableConcept |
| performer | Σ C | 0..1 | Reference(UKCoreOrganization) |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| reference | Σ C | 0..1 | string |
| type | Σ | 0..1 | uriBinding |
| identifier | Σ | 1..1 | Identifier |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| use | Σ ?! | 0..1 | codeBinding |
| type | Σ | 0..1 | CodeableConceptBinding |
| system | Σ | 0..1 | uriFixed Value |
| value | Σ | 0..1 | string |
| period | Σ C | 0..1 | Period |
| assigner | Σ C | 0..1 | Reference(Organization) |
| display | Σ | 0..1 | string |
| locationCode | Σ | 0..0 | CodeableConcept |
| locationReference | Σ C | 0..0 | Reference(Location) |
| reasonCode | Σ | 0..* | CodeableConceptBinding |
| DGTSTestPackage | Σ | 1..1 | CodeableConceptBinding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| coding | Σ | 0..* | Coding |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| genomicTestCodeVersion | C | 0..* | Extension(decimal) |
| system | Σ | 0..1 | uriFixed Value |
| version | Σ | 0..1 | string |
| code | Σ | 0..1 | code |
| display | Σ | 0..1 | string |
| userSelected | Σ | 0..1 | boolean |
| text | Σ | 0..1 | string |
| reasonReference | Σ C | 0..* | Reference(https://fhir.nhs.uk/StructureDefinition/NHSEngland-Condition-Genomics) |
| insurance | C | 0..0 | Reference(ClaimResponse | Coverage) |
| supportingInfo | C | 0..* | Reference(Resource) |
| specimen | Σ C | 0..* | Reference(Specimen) |
| bodySite | Σ | 0..0 | CodeableConceptBinding |
| note | 0..* | Annotation | |
| id | 0..1 | string | |
| extension | C | 0..* | Extension |
| annotationType | C | 0..* | Extension(CodeableConcept) |
| author[x] | Σ | 0..1 | |
| authorReference | Reference(Organization | Patient | Practitioner | RelatedPerson) | ||
| authorString | string | ||
| time | Σ | 0..1 | dateTime |
| text | Σ | 1..1 | markdown |
| patientInstruction | Σ | 0..0 | string |
| relevantHistory | C | 0..0 | Reference(Provenance) |
Detailed Descriptions
| ServiceRequest | |||
| Short | A request for a service to be performed | ||
| Definition | A record of a request for service such as diagnostic investigations, treatments, or operations to be performed. | ||
| Cardinality | 0..* | ||
| Alias | diagnostic request, referral, referral request, transfer of care request | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.id | |||
| Short | Logical id of this artifact | ||
| Definition | The logical id of the resource, as used in the URL for the resource. Once assigned, this value never changes. | ||
| Cardinality | 0..1 | ||
| Type | id | ||
| Summary | True | ||
| Comments | The only time that a resource does not have an id is when it is being submitted to the server using a create operation. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.meta | |||
| Short | 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. | ||
| Cardinality | 0..1 | ||
| Type | Meta | ||
| Summary | True | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.implicitRules | |||
| Short | 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. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Modifier | True | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.language | |||
| Short | Language of the resource content | ||
| Definition | The base language in which the resource is written. | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Binding | A human language.
| ||
| 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). | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.text | |||
| Short | Text summary of the resource, for human interpretation | ||
| 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. | ||
| Cardinality | 0..1 | ||
| Type | Narrative | ||
| Alias | narrative, html, xhtml, display | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.contained | |||
| Short | Contained, inline Resources | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Resource | ||
| Alias | inline resources, anonymous resources, contained resources | ||
| 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. | ||
| Mappings |
| ||
| ServiceRequest.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 1..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.extension:sourceOfServiceRequest | |||
| Short | This represents the source of referral | ||
| Definition | This represents the source of referral. | ||
| Cardinality | 0..1 | ||
| Type | Extension(CodeableConcept) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.extension:additionalContact | |||
| Short | Details of an additional contact | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension(Reference(Organization | Practitioner | PractitionerRole)) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.extension:coverage | |||
| Short | The funding category for the Service Request | ||
| Definition | 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. | ||
| Cardinality | 1..1 | ||
| Type | Extension(CodeableConcept) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.extension:genomicParticipantCount | |||
| Short | Optional Extensions Element | ||
| Definition | Genomics specific extension used to record the total number of participants in a group test request.(e.g. family, duo / trio). SHALL be provided on the Proband test request which is part of a group. This will be copied to the RequestGroup to inform lab orchestration. | ||
| Cardinality | 0..1 | ||
| Type | Extension(integer) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.extension:genomicPatientRole | |||
| Short | Optional Extensions Element | ||
| Definition | Genomics specific extension to support family testing. SHALL be present on requests in Duo/Trio use cases where there is a need to differentiate a request for a Proband (which needs to be reported on), from the request for a consultand, which may not result in a report. It is expected that this will impact the Tasks spun up by the central service, though this is currently still under development. | ||
| Cardinality | 0..1 | ||
| Type | Extension(CodeableConcept) | ||
| Binding | |||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.modifierExtension | |||
| Short | Extensions that cannot be ignored | ||
| 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). | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Modifier | True | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier | |||
| Short | Identifiers assigned to this order | ||
| Definition | 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. | ||
| Cardinality | 1..* | ||
| Type | Identifier | ||
| Summary | True | ||
| 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. | ||
| Slicing | Unordered, Open, by system(Pattern) | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder | |||
| Short | Identifiers assigned to this order | ||
| Definition | Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller. | ||
| Cardinality | 0..1 | ||
| Type | Identifier | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.use | |||
| Short | usual | official | temp | secondary | old (If known) | ||
| Definition | The purpose of this identifier. | ||
| Cardinality | 0..0 | ||
| Type | code | ||
| Binding | Identifies the purpose for this identifier, if known . | ||
| Modifier | True | ||
| Summary | True | ||
| Requirements | Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers. | ||
| Comments | Applications can assume that an identifier is permanent unless it explicitly says that it is temporary. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.type | |||
| Short | Description of identifier | ||
| Definition | A coded type for the identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Cardinality | 0..0 | ||
| Type | CodeableConcept | ||
| Binding | A coded type for an identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Summary | True | ||
| Requirements | Allows users to make use of identifiers when the identifier system is not known. | ||
| Comments | This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.system | |||
| Short | The namespace for the identifier value | ||
| Definition | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. | ||
| Cardinality | 1..1 | ||
| Type | uri | ||
| Summary | True | ||
| Requirements | There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers. | ||
| Comments | Identifier.system is always case sensitive. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/Id/GMSOrder | ||
| Examples | Generalhttp://www.acme.com/identifiers/patient | ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.value | |||
| Short | The value that is unique | ||
| Definition | The portion of the identifier typically relevant to the user and which is unique within the context of the system. | ||
| Cardinality | 1..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Examples | General123456 | ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.period | |||
| Short | Time period when id is/was valid for use | ||
| Definition | Time period during which identifier is/was valid for use. | ||
| Cardinality | 0..0 | ||
| Type | Period | ||
| Summary | True | ||
| Comments | A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:identifierGMSOrder.assigner | |||
| Short | Organization that issued id (may be just text) | ||
| Definition | Organization that issued/manages the identifier. | ||
| Cardinality | 0..0 | ||
| Type | Reference(Organization) | ||
| Summary | True | ||
| Comments | The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier | |||
| Short | Identifiers assigned to this order | ||
| Definition | Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller. | ||
| Cardinality | 0..* | ||
| Type | Identifier | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.use | |||
| Short | usual | official | temp | secondary | old (If known) | ||
| Definition | The purpose of this identifier. | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Binding | Identifies the purpose for this identifier, if known . | ||
| Modifier | True | ||
| Summary | True | ||
| Requirements | Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers. | ||
| Comments | Applications can assume that an identifier is permanent unless it explicitly says that it is temporary. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.type | |||
| Short | Description of identifier | ||
| Definition | A coded type for the identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Cardinality | 0..1 | ||
| Type | CodeableConcept | ||
| Binding | A coded type for an identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Summary | True | ||
| Requirements | Allows users to make use of identifiers when the identifier system is not known. | ||
| Comments | This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.system | |||
| Short | The namespace for the identifier value | ||
| Definition | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. | ||
| Cardinality | 1..1 | ||
| Type | uri | ||
| Summary | True | ||
| Requirements | There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers. | ||
| Comments | Identifier.system is always case sensitive. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/local-identifier/servicerequest | ||
| Examples | Generalhttp://www.acme.com/identifiers/patient | ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.value | |||
| Short | The value that is unique | ||
| Definition | The portion of the identifier typically relevant to the user and which is unique within the context of the system. | ||
| Cardinality | 1..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Examples | General123456 | ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.period | |||
| Short | Time period when id is/was valid for use | ||
| Definition | Time period during which identifier is/was valid for use. | ||
| Cardinality | 0..1 | ||
| Type | Period | ||
| Summary | True | ||
| Comments | A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner | |||
| Short | Organization that issued id (may be just text) | ||
| Definition | Organization that issued/manages the identifier. | ||
| Cardinality | 1..1 | ||
| Type | Reference(Organization) | ||
| Summary | True | ||
| Comments | The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.reference | |||
| Short | Literal reference, Relative, internal or absolute URL | ||
| Definition | A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources. | ||
| Cardinality | 0..0 | ||
| Type | string | ||
| Summary | True | ||
| Comments | Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1, ref-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.type | |||
| Short | Type the reference refers to (e.g. "Patient") | ||
| Definition | The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources). | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Binding | Aa resource (or, for logical models, the URI of the logical model). | ||
| Summary | True | ||
| Comments | This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.identifier | |||
| Short | Logical reference, when literal reference is not known | ||
| Definition | An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference. | ||
| Cardinality | 1..1 | ||
| Type | Identifier | ||
| Summary | True | ||
| Comments | When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy. When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it. Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any). | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | {
"system": "https://fhir.nhs.uk/Id/ods-organization-code"
} | ||
| Mappings |
| ||
| ServiceRequest.identifier:localIdentifier.assigner.display | |||
| Short | Text alternative for the resource | ||
| Definition | Plain text narrative that identifies the resource in addition to the resource reference. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.instantiatesCanonical | |||
| Short | 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. | ||
| Cardinality | 0..* | ||
| Type | canonical(ActivityDefinition | PlanDefinition) | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.instantiatesUri | |||
| Short | 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. | ||
| Cardinality | 0..* | ||
| Type | uri | ||
| Summary | True | ||
| Comments | This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.basedOn | |||
| Short | What request fulfills | ||
| Definition | 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 where prior requests contain clinical context). 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, making the sample to be reprocessed unambiguous. In cases the data is required, rather than reprocessing of the sample itself, 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 SHALL be referenced from ServiceRequest.specimen as above. If multiple outputs are associated with a previous request, i.e. data from multiple samples, a ServiceRequest SHOULD reference the data to be reinterpreted/reanalysed through ServiceRequest.supportingInfo. | ||
| Cardinality | 0..* | ||
| Type | Reference(CarePlan | UKCoreMedicationRequest | NHSEngland_ServiceRequest_Genomics) | ||
| Must Support | True | ||
| Summary | True | ||
| Alias | fulfills | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.replaces | |||
| Short | What request replaces | ||
| Definition | The request takes the place of the referenced completed or terminated request(s). | ||
| Cardinality | 0..1 | ||
| Type | Reference(NHSEngland_ServiceRequest_Genomics) | ||
| Summary | True | ||
| Alias | supersedes, prior, renewed order | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.requisition | |||
| Short | Composite Request ID | ||
| Definition | SHALL be added for Duo/Trio (familial) requests in order to link tests together. Requisition Identifiers are used to generate RequestGroup resources that assist with management of linked requests. SHALL NOT be populated for other types of test (singleton) or other scenarios where requests/results need to be linked (see For subsequent requests which are part of a group, it is expected the requisition identifier will be retrieved from the prior request, e.g. for the proband, either from the central broker or via some offline means, and will be recreated on the additional request exactly, including system and assigner, so the requests can be linked. | ||
| Cardinality | 0..1 | ||
| Type | Identifier | ||
| Summary | True | ||
| Alias | grouperId, groupIdentifier | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.status | |||
| Short | draft | active | on-hold | revoked | completed | entered-in-error | unknown | ||
| Definition | SHALL be provided. ServiceRequests SHOULD be marked as 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. | ||
| Cardinality | 1..1 | ||
| Type | code | ||
| Binding | The status of a service order. | ||
| Must Support | True | ||
| Modifier | True | ||
| Summary | True | ||
| Comments | 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 Interactions for general discussion) or using the Task resource. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.intent | |||
| Short | proposal | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option | ||
| Definition | 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. | ||
| Cardinality | 1..1 | ||
| Type | code | ||
| Binding | The kind of service request. | ||
| Must Support | True | ||
| Modifier | True | ||
| Summary | True | ||
| Comments | This element is labeled as a modifier because the intent alters when and how the resource is actually applicable. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category | |||
| Short | Classification of service | ||
| Definition | Category SHALL be populated with the reason for the 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-ReasonforTesting ValueSet SHOULD be used for this categorisation. | ||
| Cardinality | 1..* | ||
| Type | CodeableConcept | ||
| Binding | Classification of the requested service. | ||
| Must Support | True | ||
| Summary | True | ||
| 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. | ||
| Slicing | Unordered, Open, by coding.system(Value) | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing | |||
| Short | Classification of Genomics service | ||
| Definition | 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 | ||
| Cardinality | 0..* | ||
| Type | CodeableConcept | ||
| Binding | Classification of the requested service. | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..* | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.system | |||
| Short | Identity of the terminology system | ||
| Definition | The identification of the code system that defines the meaning of the symbol in the code. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.hl7.org.uk/CodeSystem/UKCore-GenomeSequencingCategory | ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.version | |||
| Short | Version of the system - if relevant | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.code | |||
| Short | Symbol in syntax defined by the system | ||
| Definition | 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). | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Summary | True | ||
| Requirements | Need to refer to a particular code in the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.display | |||
| Short | Representation defined by the system | ||
| Definition | A representation of the meaning of the code in the system, following the rules of the system. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Requirements | Need to be able to carry a human-readable meaning of the code for readers that do not know the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.userSelected | |||
| Short | If this coding was chosen directly by the user | ||
| Definition | Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays). | ||
| Cardinality | 0..1 | ||
| Type | boolean | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:genomicsWholeCaseSequencing.text | |||
| Short | Plain text representation of the concept | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.category:reasonForTesting | |||
| Short | Classification of service | ||
| Definition | A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure"). | ||
| Cardinality | 1..* | ||
| Type | CodeableConcept | ||
| Binding | Classification of the requested service. | ||
| Must Support | True | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.priority | |||
| Short | routine | urgent | asap | stat | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Binding | Identifies the level of importance to be assigned to actioning the request. | ||
| Must Support | True | ||
| Summary | True | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Meaning when missing | If missing, this task should be performed with normal priority | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.priority.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.priority.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.priority.extension:priorityReason | |||
| Short | A SNOMED CT concept representing the reason a Service Request is urgent. | ||
| Definition | A SNOMED CT concept representing the reason a Service Request is urgent | ||
| Cardinality | 0..* | ||
| Type | Extension(CodeableConcept) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.priority.value | |||
| Short | Primitive value for code | ||
| Definition | Primitive value for code | ||
| Cardinality | 0..1 | ||
| Type | System.String | ||
| Maximum string length | 1048576 | ||
| ServiceRequest.doNotPerform | |||
| Short | True if service/procedure should not be performed | ||
| Definition | 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. | ||
| Cardinality | 0..0 | ||
| Type | boolean | ||
| Modifier | True | ||
| Summary | True | ||
| 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" | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code | |||
| Short | What is being requested/ordered | ||
| Definition | SHOULD be provided if known. If populated, Code SHOULD contain an appropriate test code, preferrably a DGTS Genomic Test code, though NGTD codes MAY be used during the transition period, currently available at https://www.england.nhs.uk/publication/national-genomic-test-directories/. There is currently a prototype DGTS FHIR API in development to support querying/retrieving codes. Codes from the Genomic Test Directory SHOULD also specify the version number of the test at the time the test is being ordered, to ensure the test methods used are consistent with that version. | ||
| Cardinality | 1..1 | ||
| Type | CodeableConcept | ||
| Binding | A set of codes that define a procedure or a procedure with explicit context. Selected from the SNOMED CT UK coding system. | ||
| Must Support | True | ||
| Summary | True | ||
| Alias | service 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.code.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..* | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Slicing | Unordered, Open, by system(Pattern) | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..1 | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.extension:genomicTestCodeVersion | |||
| Short | Optional Extensions Element | ||
| Definition | Optional Extension Element - found in all resources. | ||
| Cardinality | 0..* | ||
| Type | Extension(decimal) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.system | |||
| Short | Identity of the terminology system | ||
| Definition | The identification of the code system that defines the meaning of the symbol in the code. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/CodeSystem/England-DigitalGenomicTestService | ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.version | |||
| Short | Version of the system - if relevant | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.code | |||
| Short | Symbol in syntax defined by the system | ||
| Definition | 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). | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Summary | True | ||
| Requirements | Need to refer to a particular code in the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.display | |||
| Short | Representation defined by the system | ||
| Definition | A representation of the meaning of the code in the system, following the rules of the system. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Requirements | Need to be able to carry a human-readable meaning of the code for readers that do not know the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.coding:DGTSCode.userSelected | |||
| Short | If this coding was chosen directly by the user | ||
| Definition | Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays). | ||
| Cardinality | 0..1 | ||
| Type | boolean | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.code.text | |||
| Short | Plain text representation of the concept | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail | |||
| Short | Additional order information | ||
| Definition | If additional coded details need to captured as part of a test order, e.g. Panels or targeted genes, these SHOULD be represented using the 'orderDetail' field, with the main indication captured using the 'reasonCode' field. 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 For Cancer WGS, where no panel or test-level details are relevant, orderDetail SHOULD be omitted. | ||
| Cardinality | 0..* | ||
| Type | CodeableConcept | ||
| Binding | Codified order entry details which are based on order context. | ||
| Summary | True | ||
| Alias | detailed instructions | ||
| Comments | For information from the medical record intended to support the delivery of the requested services, use the | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1, prr-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.orderDetail.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..* | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Slicing | Unordered, Open, by system(Value) | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..* | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.extension:genomicTestCodeVersion | |||
| Short | Optional Extensions Element | ||
| Definition | Optional Extension Element - found in all resources. | ||
| Cardinality | 0..* | ||
| Type | Extension(decimal) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.system | |||
| Short | Genomics Test Panel Code | ||
| Definition | The identification of the code system that defines the meaning of the symbol in the code. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/CodeSystem/England-GenomicTestPanelCode | ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.version | |||
| Short | Version of the system - if relevant | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.code | |||
| Short | Symbol in syntax defined by the system | ||
| Definition | 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). | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Summary | True | ||
| Requirements | Need to refer to a particular code in the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.display | |||
| Short | Representation defined by the system | ||
| Definition | A representation of the meaning of the code in the system, following the rules of the system. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Requirements | Need to be able to carry a human-readable meaning of the code for readers that do not know the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.userSelected | |||
| Short | If this coding was chosen directly by the user | ||
| Definition | Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays). | ||
| Cardinality | 0..1 | ||
| Type | boolean | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.orderDetail.text | |||
| Short | Plain text representation of the concept | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.quantity[x] | |||
| Short | 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). | ||
| Cardinality | 0..0 | ||
| Type | Quantity | Range | Ratio | ||
| Summary | True | ||
| Requirements | When ordering a service the number of service items may need to be specified separately from the the service item. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.subject | |||
| Short | Individual or Entity the service is ordered for | ||
| Definition | 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 | ||
| Cardinality | 1..1 | ||
| Type | Reference(NHSEngland_Patient_Genomics) | ||
| Must Support | True | ||
| Summary | True | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.encounter | |||
| Short | Encounter in which the request was created | ||
| Definition | An encounter that provides additional information about the healthcare context in which this request is made. | ||
| Cardinality | 0..1 | ||
| Type | Reference(Encounter) | ||
| Summary | True | ||
| Alias | context | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.occurrence[x] | |||
| Short | When service should occur | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | dateTime | Period | Timing | ||
| Summary | True | ||
| Alias | schedule | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.asNeeded[x] | |||
| Short | Preconditions for service | ||
| Definition | If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example "pain", "on flare-up", etc. | ||
| Cardinality | 0..0 | ||
| Type | boolean | CodeableConcept | ||
| Binding | A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. | ||
| Summary | True | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.authoredOn | |||
| Short | Date request signed | ||
| Definition | SHALL be populated by the client upon submission, either manually by the user or automatically by the system integrating with the central GMS. | ||
| Cardinality | 1..1 | ||
| Type | dateTime | ||
| Must Support | True | ||
| Summary | True | ||
| Alias | orderedOn | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.requester | |||
| Short | Who/what is requesting service | ||
| Definition | 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). | ||
| Cardinality | 1..1 | ||
| Type | Reference(NHSEngland_PractitionerRole_Genomics) | ||
| Must Support | True | ||
| Summary | True | ||
| Alias | author, orderer | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performerType | |||
| Short | Performer role | ||
| Definition | Desired type of performer for doing the requested service. | ||
| Cardinality | 0..0 | ||
| Type | CodeableConcept | ||
| Binding | Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. | ||
| Summary | True | ||
| Alias | specialty | ||
| 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”. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer | |||
| Short | Requested performer | ||
| Definition | 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). | ||
| Cardinality | 0..1 | ||
| Type | Reference(UKCoreOrganization) | ||
| Summary | True | ||
| Alias | request recipient | ||
| 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). | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.performer.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.reference | |||
| Short | Literal reference, Relative, internal or absolute URL | ||
| Definition | A reference to a location at which the other resource is found. The reference may be a relative reference, in which case it is relative to the service base URL, or an absolute URL that resolves to the location where the resource is found. The reference may be version specific or not. If the reference is not to a FHIR RESTful server, then it should be assumed to be version specific. Internal fragment references (start with '#') refer to contained resources. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | Using absolute URLs provides a stable scalable approach suitable for a cloud/web context, while using relative/logical references provides a flexible approach suitable for use when trading across closed eco-system boundaries. Absolute URLs do not need to point to a FHIR RESTful server, though this is the preferred approach. If the URL conforms to the structure "/[type]/[id]" then it should be assumed that the reference is to a FHIR RESTful server. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1, ref-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.type | |||
| Short | Type the reference refers to (e.g. "Patient") | ||
| Definition | The expected type of the target of the reference. If both Reference.type and Reference.reference are populated and Reference.reference is a FHIR URL, both SHALL be consistent. The type is the Canonical URL of Resource Definition that is the type this reference refers to. References are URLs that are relative to http://hl7.org/fhir/StructureDefinition/ e.g. "Patient" is a reference to http://hl7.org/fhir/StructureDefinition/Patient. Absolute URLs are only allowed for logical models (and can only be used in references in logical models, not resources). | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Binding | Aa resource (or, for logical models, the URI of the logical model). | ||
| Summary | True | ||
| Comments | This element is used to indicate the type of the target of the reference. This may be used which ever of the other elements are populated (or not). In some cases, the type of the target may be determined by inspection of the reference (e.g. a RESTful URL) or by resolving the target of the reference; if both the type and a reference is provided, the reference SHALL resolve to a resource of the same type as that specified. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier | |||
| Short | Logical reference, when literal reference is not known | ||
| Definition | An identifier for the target resource. This is used when there is no way to reference the other resource directly, either because the entity it represents is not available through a FHIR server, or because there is no way for the author of the resource to convert a known identifier to an actual location. There is no requirement that a Reference.identifier point to something that is actually exposed as a FHIR instance, but it SHALL point to a business concept that would be expected to be exposed as a FHIR instance, and that instance would need to be of a FHIR resource type allowed by the reference. | ||
| Cardinality | 1..1 | ||
| Type | Identifier | ||
| Summary | True | ||
| Comments | When an identifier is provided in place of a reference, any system processing the reference will only be able to resolve the identifier to a reference if it understands the business context in which the identifier is used. Sometimes this is global (e.g. a national identifier) but often it is not. For this reason, none of the useful mechanisms described for working with references (e.g. chaining, includes) are possible, nor should servers be expected to be able resolve the reference. Servers may accept an identifier based reference untouched, resolve it, and/or reject it - see CapabilityStatement.rest.resource.referencePolicy. When both an identifier and a literal reference are provided, the literal reference is preferred. Applications processing the resource are allowed - but not required - to check that the identifier matches the literal reference Applications converting a logical reference to a literal reference may choose to leave the logical reference present, or remove it. Reference is intended to point to a structure that can potentially be expressed as a FHIR resource, though there is no need for it to exist as an actual FHIR resource instance - except in as much as an application wishes to actual find the target of the reference. The content referred to be the identifier must meet the logical constraints implied by any limitations on what resource types are permitted for the reference. For example, it would not be legitimate to send the identifier for a drug prescription if the type were Reference(Observation|DiagnosticReport). One of the use-cases for Reference.identifier is the situation where no FHIR representation exists (where the type is Reference (Any). | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.use | |||
| Short | usual | official | temp | secondary | old (If known) | ||
| Definition | The purpose of this identifier. | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Binding | Identifies the purpose for this identifier, if known . | ||
| Modifier | True | ||
| Summary | True | ||
| Requirements | Allows the appropriate identifier for a particular context of use to be selected from among a set of identifiers. | ||
| Comments | Applications can assume that an identifier is permanent unless it explicitly says that it is temporary. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.type | |||
| Short | Description of identifier | ||
| Definition | A coded type for the identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Cardinality | 0..1 | ||
| Type | CodeableConcept | ||
| Binding | A coded type for an identifier that can be used to determine which identifier to use for a specific purpose. | ||
| Summary | True | ||
| Requirements | Allows users to make use of identifiers when the identifier system is not known. | ||
| Comments | This element deals only with general categories of identifiers. It SHOULD not be used for codes that correspond 1..1 with the Identifier.system. Some identifiers may fall into multiple categories due to common usage. Where the system is known, a type is unnecessary because the type is always part of the system definition. However systems often need to handle identifiers where the system is not known. There is not a 1:1 relationship between type and system, since many different systems have the same type. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.system | |||
| Short | The namespace for the identifier value | ||
| Definition | Establishes the namespace for the value - that is, a URL that describes a set values that are unique. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Summary | True | ||
| Requirements | There are many sets of identifiers. To perform matching of two identifiers, we need to know what set we're dealing with. The system identifies a particular set of unique identifiers. | ||
| Comments | Identifier.system is always case sensitive. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/Id/ods-organization-code | ||
| Examples | Generalhttp://www.acme.com/identifiers/patient | ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.value | |||
| Short | The value that is unique | ||
| Definition | The portion of the identifier typically relevant to the user and which is unique within the context of the system. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | If the value is a full URI, then the system SHALL be urn:ietf:rfc:3986. The value's primary purpose is computational mapping. As a result, it may be normalized for comparison purposes (e.g. removing non-significant whitespace, dashes, etc.) A value formatted for human display can be conveyed using the Rendered Value extension. Identifier.value is to be treated as case sensitive unless knowledge of the Identifier.system allows the processer to be confident that non-case-sensitive processing is safe. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Examples | General123456 | ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.period | |||
| Short | Time period when id is/was valid for use | ||
| Definition | Time period during which identifier is/was valid for use. | ||
| Cardinality | 0..1 | ||
| Type | Period | ||
| Summary | True | ||
| Comments | A Period specifies a range of time; the context of use will specify whether the entire range applies (e.g. "the patient was an inpatient of the hospital for this time range") or one value from the range applies (e.g. "give to the patient between these two times"). Period is not used for a duration (a measure of elapsed time). See Duration. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.identifier.assigner | |||
| Short | Organization that issued id (may be just text) | ||
| Definition | Organization that issued/manages the identifier. | ||
| Cardinality | 0..1 | ||
| Type | Reference(Organization) | ||
| Summary | True | ||
| Comments | The Identifier.assigner may omit the .reference element and only contain a .display element reflecting the name or other textual information about the assigning organization. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.performer.display | |||
| Short | Text alternative for the resource | ||
| Definition | Plain text narrative that identifies the resource in addition to the resource reference. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Comments | This is generally not the same as the Resource.text of the referenced resource. The purpose is to identify what's being referenced, not to fully describe it. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.locationCode | |||
| Short | Requested location | ||
| Definition | The preferred location(s) where the procedure should actually happen in coded or free text form. E.g. at home or nursing day care center. | ||
| Cardinality | 0..0 | ||
| Type | CodeableConcept | ||
| Binding | A location type where services are delivered. | ||
| Summary | True | ||
| Comments | Not all terminology uses fit this general pattern. In some cases, models should not use CodeableConcept and use Coding directly and provide their own structure for managing text, codings, translations and the relationship between elements and pre- and post-coordination. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.locationReference | |||
| Short | Requested location | ||
| Definition | A reference to the the preferred location(s) where the procedure should actually happen. E.g. at home or nursing day care center. | ||
| Cardinality | 0..0 | ||
| Type | Reference(Location) | ||
| Summary | True | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode | |||
| Short | 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 | ||
| Cardinality | 0..* | ||
| Type | CodeableConcept | ||
| Binding | A set of codes that define a reason for a service request. | ||
| Summary | True | ||
| 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 | ||
| Slicing | Unordered, Open, by coding.system(Pattern) | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage | |||
| Short | Explanation/Justification for procedure or service | ||
| Definition | reasonCode SHALL be populated with the Test Package code for the order. | ||
| Cardinality | 1..1 | ||
| Type | CodeableConcept | ||
| Binding | A set of codes that define a reason for a service request. | ||
| Summary | True | ||
| 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 | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding | |||
| Short | Code defined by a terminology system | ||
| Definition | A reference to a code defined by a terminology system. | ||
| Cardinality | 0..* | ||
| Type | Coding | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.extension:genomicTestCodeVersion | |||
| Short | Optional Extensions Element | ||
| Definition | Optional Extension Element - found in all resources. | ||
| Cardinality | 0..* | ||
| Type | Extension(decimal) | ||
| Alias | extensions, user content | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.system | |||
| Short | Identity of the terminology system | ||
| Definition | The identification of the code system that defines the meaning of the symbol in the code. | ||
| Cardinality | 0..1 | ||
| Type | uri | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Fixed Value | https://fhir.nhs.uk/CodeSystem/England-DigitalGenomicTestService | ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.version | |||
| Short | Version of the system - if relevant | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.code | |||
| Short | Symbol in syntax defined by the system | ||
| Definition | 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). | ||
| Cardinality | 0..1 | ||
| Type | code | ||
| Summary | True | ||
| Requirements | Need to refer to a particular code in the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.display | |||
| Short | Representation defined by the system | ||
| Definition | A representation of the meaning of the code in the system, following the rules of the system. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| Requirements | Need to be able to carry a human-readable meaning of the code for readers that do not know the system. | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.coding.userSelected | |||
| Short | If this coding was chosen directly by the user | ||
| Definition | Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays). | ||
| Cardinality | 0..1 | ||
| Type | boolean | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonCode:DGTSTestPackage.text | |||
| Short | Plain text representation of the concept | ||
| Definition | 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. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.reasonReference | |||
| Short | Explanation/Justification for service or service | ||
| Definition | Reference SHOULD be associated to the primary condition being tested for. Required if additional information related to the condition, such as onsetAge, needs to be captured for interpretation. | ||
| Cardinality | 0..* | ||
| Type | Reference(https://fhir.nhs.uk/StructureDefinition/NHSEngland-Condition-Genomics) | ||
| Summary | True | ||
| 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 | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.insurance | |||
| Short | Associated insurance coverage | ||
| Definition | Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service. | ||
| Cardinality | 0..0 | ||
| Type | Reference(ClaimResponse | Coverage) | ||
| Comments | References SHALL be a reference to an actual FHIR resource, and SHALL be resolveable (allowing for access control, temporary unavailability, etc.). Resolution can be either by retrieval from the URL, or, where applicable by resource type, by treating an absolute reference as a canonical URL and looking it up in a local registry/repository. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.supportingInfo | |||
| Short | Additional clinical information | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Reference(Resource) | ||
| Alias | Ask at order entry question, AOE | ||
| Comments | To represent information about how the services are to be delivered use the | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.specimen | |||
| Short | Procedure Samples | ||
| Definition | 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 For requests based on prior requests where multiple samples 'active' are associated with the prior request. The specific sample to be reprocessed SHALL be referenced from ServiceRequest.specimen. | ||
| Cardinality | 0..* | ||
| Type | Reference(Specimen) | ||
| Summary | True | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.bodySite | |||
| Short | Location on Body | ||
| Definition | Anatomic location where the procedure should be performed. This is the target site. | ||
| Cardinality | 0..0 | ||
| Type | CodeableConcept | ||
| Binding | Codes describing anatomical locations. May include laterality. | ||
| Summary | True | ||
| Alias | location | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note | |||
| Short | Comments | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Annotation | ||
| Comments | For systems that do not have structured annotations, they can simply communicate a single annotation with no author or time. This element may need to be included in narrative because of the potential for modifying information. Annotations SHOULD NOT be used to communicate "modifying" information that could be computable. (This is a SHOULD because enforcing user behavior is nearly impossible). | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note.id | |||
| Short | Unique id for inter-element referencing | ||
| Definition | Unique id for the element within a resource (for internal references). This may be any string value that does not contain spaces. | ||
| Cardinality | 0..1 | ||
| Type | string | ||
| Mappings |
| ||
| ServiceRequest.note.extension | |||
| Short | Additional content defined by implementations | ||
| Definition | 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. | ||
| Cardinality | 0..* | ||
| Type | Extension | ||
| Alias | extensions, user content | ||
| 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. | ||
| Slicing | Unordered, Open, by url(Value) Extensions are always sliced by (at least) url | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note.extension:annotationType | |||
| Short | The type of annotation | ||
| Definition | The type of annotation. This extension can be used to map the v2 NTE-4 comment type field. | ||
| Cardinality | 0..* | ||
| Type | Extension(CodeableConcept) | ||
| Alias | extensions, user content | ||
| Comments | This is used to identify the type of annotation. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note.author[x] | |||
| Short | Individual responsible for the annotation | ||
| Definition | The individual responsible for making the annotation. | ||
| Cardinality | 0..1 | ||
| Type | Reference(Organization | Patient | Practitioner | RelatedPerson) | string | ||
| Summary | True | ||
| Comments | Organization is used when there's no need for specific attribution as to who made the comment. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note.time | |||
| Short | When the annotation was made | ||
| Definition | Indicates when this particular annotation was made. | ||
| Cardinality | 0..1 | ||
| Type | dateTime | ||
| Summary | True | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.note.text | |||
| Short | The annotation - text content (as markdown) | ||
| Definition | The text of the annotation in markdown format. | ||
| Cardinality | 1..1 | ||
| Type | markdown | ||
| Summary | True | ||
| Comments | Systems are not required to have markdown support, so the text should be readable without markdown processing. The markdown syntax is GFM - see https://github.github.com/gfm/ | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.patientInstruction | |||
| Short | Patient or consumer-oriented instructions | ||
| Definition | Instructions in terms that are understood by the patient or consumer. | ||
| Cardinality | 0..0 | ||
| Type | string | ||
| Summary | True | ||
| Comments | Note that FHIR strings SHALL NOT exceed 1MB in size | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
| ServiceRequest.relevantHistory | |||
| Short | Request provenance | ||
| Definition | Key events in the history of the request. | ||
| Cardinality | 0..0 | ||
| Type | Reference(Provenance) | ||
| 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. | ||
| Conditions | The cardinality or value of this element may be affected by these constraints: ele-1 | ||
| Constraints |
| ||
| Mappings |
| ||
Table View
| ServiceRequest | 0..* | |
| ServiceRequest.id | id | 0..1 |
| ServiceRequest.meta | Meta | 0..1 |
| ServiceRequest.implicitRules | uri | 0..1 |
| ServiceRequest.language | code | 0..1 |
| ServiceRequest.text | Narrative | 0..1 |
| ServiceRequest.contained | Resource | 0..* |
| ServiceRequest.extension | Extension | 1..* |
| ServiceRequest.extension:sourceOfServiceRequest | Extension | 0..1 |
| ServiceRequest.extension:additionalContact | Extension | 0..* |
| ServiceRequest.extension:coverage | Extension | 1..1 |
| ServiceRequest.extension:genomicParticipantCount | Extension | 0..1 |
| ServiceRequest.extension:genomicPatientRole | Extension | 0..1 |
| ServiceRequest.modifierExtension | Extension | 0..* |
| ServiceRequest.identifier | Identifier | 1..* |
| ServiceRequest.identifier:identifierGMSOrder | Identifier | 0..1 |
| ServiceRequest.identifier:identifierGMSOrder.id | string | 0..1 |
| ServiceRequest.identifier:identifierGMSOrder.extension | Extension | 0..* |
| ServiceRequest.identifier:identifierGMSOrder.use | code | 0..0 |
| ServiceRequest.identifier:identifierGMSOrder.type | CodeableConcept | 0..0 |
| ServiceRequest.identifier:identifierGMSOrder.system | uri | 1..1 |
| ServiceRequest.identifier:identifierGMSOrder.value | string | 1..1 |
| ServiceRequest.identifier:identifierGMSOrder.period | Period | 0..0 |
| ServiceRequest.identifier:identifierGMSOrder.assigner | Reference(Organization) | 0..0 |
| ServiceRequest.identifier:localIdentifier | Identifier | 0..* |
| ServiceRequest.identifier:localIdentifier.id | string | 0..1 |
| ServiceRequest.identifier:localIdentifier.extension | Extension | 0..* |
| ServiceRequest.identifier:localIdentifier.use | code | 0..1 |
| ServiceRequest.identifier:localIdentifier.type | CodeableConcept | 0..1 |
| ServiceRequest.identifier:localIdentifier.system | uri | 1..1 |
| ServiceRequest.identifier:localIdentifier.value | string | 1..1 |
| ServiceRequest.identifier:localIdentifier.period | Period | 0..1 |
| ServiceRequest.identifier:localIdentifier.assigner | Reference(Organization) | 1..1 |
| ServiceRequest.identifier:localIdentifier.assigner.id | string | 0..1 |
| ServiceRequest.identifier:localIdentifier.assigner.extension | Extension | 0..* |
| ServiceRequest.identifier:localIdentifier.assigner.reference | string | 0..0 |
| ServiceRequest.identifier:localIdentifier.assigner.type | uri | 0..1 |
| ServiceRequest.identifier:localIdentifier.assigner.identifier | Identifier | 1..1 |
| ServiceRequest.identifier:localIdentifier.assigner.display | string | 0..1 |
| ServiceRequest.instantiatesCanonical | canonical(ActivityDefinition | PlanDefinition) | 0..* |
| ServiceRequest.instantiatesUri | uri | 0..* |
| ServiceRequest.basedOn | Reference(CarePlan | UKCoreMedicationRequest | NHSEngland_ServiceRequest_Genomics) | 0..* |
| ServiceRequest.replaces | Reference(NHSEngland_ServiceRequest_Genomics) | 0..1 |
| ServiceRequest.requisition | Identifier | 0..1 |
| ServiceRequest.status | code | 1..1 |
| ServiceRequest.intent | code | 1..1 |
| ServiceRequest.category | CodeableConcept | 1..* |
| ServiceRequest.category:genomicsWholeCaseSequencing | CodeableConcept | 0..* |
| ServiceRequest.category:genomicsWholeCaseSequencing.id | string | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.extension | Extension | 0..* |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding | Coding | 0..* |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.id | string | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.extension | Extension | 0..* |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.system | uri | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.version | string | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.code | code | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.display | string | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.coding.userSelected | boolean | 0..1 |
| ServiceRequest.category:genomicsWholeCaseSequencing.text | string | 0..1 |
| ServiceRequest.category:reasonForTesting | CodeableConcept | 1..* |
| ServiceRequest.priority | code | 0..1 |
| ServiceRequest.priority.id | string | 0..1 |
| ServiceRequest.priority.extension | Extension | 0..* |
| ServiceRequest.priority.extension:priorityReason | Extension | 0..* |
| ServiceRequest.priority.value | System.String | 0..1 |
| ServiceRequest.doNotPerform | boolean | 0..0 |
| ServiceRequest.code | CodeableConcept | 1..1 |
| ServiceRequest.code.id | string | 0..1 |
| ServiceRequest.code.extension | Extension | 0..* |
| ServiceRequest.code.coding | Coding | 0..* |
| ServiceRequest.code.coding:DGTSCode | Coding | 0..1 |
| ServiceRequest.code.coding:DGTSCode.id | string | 0..1 |
| ServiceRequest.code.coding:DGTSCode.extension | Extension | 0..* |
| ServiceRequest.code.coding:DGTSCode.extension:genomicTestCodeVersion | Extension | 0..* |
| ServiceRequest.code.coding:DGTSCode.system | uri | 0..1 |
| ServiceRequest.code.coding:DGTSCode.version | string | 0..1 |
| ServiceRequest.code.coding:DGTSCode.code | code | 0..1 |
| ServiceRequest.code.coding:DGTSCode.display | string | 0..1 |
| ServiceRequest.code.coding:DGTSCode.userSelected | boolean | 0..1 |
| ServiceRequest.code.text | string | 0..1 |
| ServiceRequest.orderDetail | CodeableConcept | 0..* |
| ServiceRequest.orderDetail.id | string | 0..1 |
| ServiceRequest.orderDetail.extension | Extension | 0..* |
| ServiceRequest.orderDetail.coding | Coding | 0..* |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode | Coding | 0..* |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.id | string | 0..1 |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.extension | Extension | 0..* |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.extension:genomicTestCodeVersion | Extension | 0..* |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.system | uri | 0..1 |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.version | string | 0..1 |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.code | code | 0..1 |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.display | string | 0..1 |
| ServiceRequest.orderDetail.coding:genomicsTestPanelCode.userSelected | boolean | 0..1 |
| ServiceRequest.orderDetail.text | string | 0..1 |
| ServiceRequest.quantity[x] | Quantity | Range | Ratio | 0..0 |
| ServiceRequest.subject | Reference(NHSEngland_Patient_Genomics) | 1..1 |
| ServiceRequest.encounter | Reference(Encounter) | 0..1 |
| ServiceRequest.occurrence[x] | dateTime | Period | Timing | 0..1 |
| ServiceRequest.asNeeded[x] | boolean | CodeableConcept | 0..0 |
| ServiceRequest.authoredOn | dateTime | 1..1 |
| ServiceRequest.requester | Reference(NHSEngland_PractitionerRole_Genomics) | 1..1 |
| ServiceRequest.performerType | CodeableConcept | 0..0 |
| ServiceRequest.performer | Reference(UKCoreOrganization) | 0..1 |
| ServiceRequest.performer.id | string | 0..1 |
| ServiceRequest.performer.extension | Extension | 0..* |
| ServiceRequest.performer.reference | string | 0..1 |
| ServiceRequest.performer.type | uri | 0..1 |
| ServiceRequest.performer.identifier | Identifier | 1..1 |
| ServiceRequest.performer.identifier.id | string | 0..1 |
| ServiceRequest.performer.identifier.extension | Extension | 0..* |
| ServiceRequest.performer.identifier.use | code | 0..1 |
| ServiceRequest.performer.identifier.type | CodeableConcept | 0..1 |
| ServiceRequest.performer.identifier.system | uri | 0..1 |
| ServiceRequest.performer.identifier.value | string | 0..1 |
| ServiceRequest.performer.identifier.period | Period | 0..1 |
| ServiceRequest.performer.identifier.assigner | Reference(Organization) | 0..1 |
| ServiceRequest.performer.display | string | 0..1 |
| ServiceRequest.locationCode | CodeableConcept | 0..0 |
| ServiceRequest.locationReference | Reference(Location) | 0..0 |
| ServiceRequest.reasonCode | CodeableConcept | 0..* |
| ServiceRequest.reasonCode:DGTSTestPackage | CodeableConcept | 1..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.id | string | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.extension | Extension | 0..* |
| ServiceRequest.reasonCode:DGTSTestPackage.coding | Coding | 0..* |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.id | string | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.extension | Extension | 0..* |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.extension:genomicTestCodeVersion | Extension | 0..* |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.system | uri | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.version | string | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.code | code | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.display | string | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.coding.userSelected | boolean | 0..1 |
| ServiceRequest.reasonCode:DGTSTestPackage.text | string | 0..1 |
| ServiceRequest.reasonReference | Reference(https://fhir.nhs.uk/StructureDefinition/NHSEngland-Condition-Genomics) | 0..* |
| ServiceRequest.insurance | Reference(ClaimResponse | Coverage) | 0..0 |
| ServiceRequest.supportingInfo | Reference(Resource) | 0..* |
| ServiceRequest.specimen | Reference(Specimen) | 0..* |
| ServiceRequest.bodySite | CodeableConcept | 0..0 |
| ServiceRequest.note | Annotation | 0..* |
| ServiceRequest.note.id | string | 0..1 |
| ServiceRequest.note.extension | Extension | 0..* |
| ServiceRequest.note.extension:annotationType | Extension | 0..* |
| ServiceRequest.note.author[x] | Reference(Organization | Patient | Practitioner | RelatedPerson) | string | 0..1 |
| ServiceRequest.note.time | dateTime | 0..1 |
| ServiceRequest.note.text | markdown | 1..1 |
| ServiceRequest.patientInstruction | string | 0..0 |
| ServiceRequest.relevantHistory | Reference(Provenance) | 0..0 |
XML View
JSON View
- ServiceRequest-NonWGSTestOrder-VariantReinterpretation-Example
- ServiceRequest-NonWGSTestOrderForm-Cancellation-Example
- ServiceRequest-NonWGSTestOrderForm-CancerSolidTumor-Example
- ServiceRequest-NonWGSTestOrderForm-CascadeTesting-Example
- ServiceRequest-NonWGSTestOrderForm-DeceasedPatient-Example
- ServiceRequest-NonWGSTestOrderForm-Example
- ServiceRequest-NonWGSTestOrderForm-FetalScenario-Example
- ServiceRequest-NonWGSTestOrderForm-FollowupTest-Example
- ServiceRequest-NonWGSTestOrderForm-HaemOncology-Example
- ServiceRequest-NonWGSTestOrderForm-HaemOncologyUpdated-Example
- ServiceRequest-NonWGSTestOrderForm-NewFollowupTest-Example
- ServiceRequest-NonWGSTestOrderForm-OutOfCountry-Example
- ServiceRequest-NonWGSTestOrderForm-UsingStoredSample-Example
- ServiceRequest-NonWGSTestOrderFormUpdated-Cancellation-Example
- ServiceRequest-NonWGSTestOrderForm-FetalScenarioFather-Example
- ServiceRequest-NonWGSTestOrderFormUpdated-SolidTumor-Example
- ServiceRequest-SavedTestOrder-Example
- ServiceRequest-SavedTestOrderUpdated-CascadeTesting-Example
- ServiceRequest-SavedTestOrderUpdated-Example
- ServiceRequest-SavedTestOrderWGS-Example
- ServiceRequest-TestOrderForm-StorageOfMaterial-Example
- ServiceRequest-WGSTestOrderForm-DirectToLab-Example
- ServiceRequest-WGSTestOrderForm-Example
- ServiceRequest-WGSTestOrderForm-TrioTestingProband-Example
- ServiceRequest-WGSTestOrderFormUpdated-DirectToLab-Example
- ServiceRequest-WGSTestOrderFormUpdated-TrioTesting-Example
- ServiceRequest-WGSTestOrderForm-TrioTestingProbandDGTS-Example
| FHIR | MDS | HL7v2 |
|---|---|---|
| ServiceRequest.requester | 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 | PRD-7 where PRD-1=RT |
| ServiceRequest.note | Raw specimen/biopsy - Sample to follow reason | NTE segment attached to ORC |
Additional Guidance
- meta
- extension:genomicParticipantCount
- extension:genomicPatientRole
- extension:additionalContact
- extension:coverage
- extension:servicerequest-order-callback-phone-number
- identifier
- basedOn
- requisition
- status
- intent
- category
- priority
- doNotPerform
- code
- orderDetail
- subject
- occurrence[x]
- authoredOn
- requester
- performer
- reasonCode
- reasonReference
- supportingInfo
- specimen
- note
meta
MAY be used to record details of the originating form, from which the ServiceRequest was populated, including form code and version (under investigation)."meta": { "tag": [ { "system": "http://epr.lth.nhs.uk/CodeSystem/forms", "code": "WGS-RareDisease-TestOrderForm", "extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-GenomicTestCode-Version", "valueDecimal": "1.0" ] } ] },
extension:genomicParticipantCount
Genomics specific extension used to record the total number of participants in a group test request.(e.g. family, duo / trio). SHALL be provided on the **Proband** test request only, as part of a group. This will be copied to the RequestGroup to inform lab orchestration.If more/fewer consultands are identified, it is expected the proband request will be updated to reflect the new participant count, which will in turn update the associated RequestGroup.
"extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-GenomicTest-ParticipantCount", "valueInteger": 3 },
extension:genomicPatientRole
Genomics specific extension to support family testing. SHALL be present on requests in Duo/Trio use cases where there is a need to differentiate a request for a Proband (which needs to be reported on), from the request for a consultand, which may not result in a report.It is expected that this will impact the Tasks spun up by the central service, though this is currently still under development.
"extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-Genomic-Patient-Role", "valueCodeableConcept": { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/patient-role-genomics", "code": "proband", "display": "Proband" } ] } },
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"
}
}
extension:servicerequest-order-callback-phone-number
Extension used for recording a callback telephone number for communications relating to the status or result of an order (ServiceRequest). This is separate from the requester or reporting contact details. The callback number SHOULD be a business or service contact number that is monitored during working hours and SHOULD be supplied in international format wherever possible. Additionally, where there are multiple contact numbers relevant to the order workflow, implementers MAY include additional instances of the extension.
{
"url": "https://hl7.org/fhir/extensions/StructureDefinition-servicerequest-order-callback-phone-number.html",
"valueContactPoint": {
"system": "phone",
"value": "+44 161 123 4567",
"use": "work"
}
}
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
SHOULD reference a parent request where this ServiceRequest is based on a previous request, if known, 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 where prior requests contain clinical context).Where the prior request cannot be found, relevant information SHOULD be added to the ServiceRequest.note field to support likage by downstream systems.
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, making the sample to be reprocessed unambiguous. In cases the data is required, rather than reprocessing of the sample itself, 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 SHALL be referenced from ServiceRequest.specimen as above. If multiple outputs are associated with a previous request, i.e. data from multiple samples, a ServiceRequest SHOULD reference the data to be reinterpreted/reanalysed through ServiceRequest.supportingInfo.
"basedOn": [ { "reference": "ServiceRequest/ServiceRequest-NonWGSTestOrderForm-FatherOfFayMutlow-Example" } ],
Non-genomic tests triggering genomic testing:
Where a genomic ServiceRequest is initiated following a preceding non-genomic investigation (for example, histopathology, cytogenetics, or other pathology testing), the genomic ServiceRequest SHOULD record the relationship to the originating non-genomic request using ServiceRequest.basedOn. As the originating non-genomic ServiceRequest is outside the scope of the Genomics Broker, ServiceRequest.basedOn SHOULD be populated as a logical reference using the identifier of the originating ServiceRequest, providing traceability to the clinical request that triggered genomic testing.
"basedOn": [ { "identifier": { "system": "http://B82033-pickeringmedicalpractice.com/labrequest", "value": "REQ-20220129-000241" }, "display": "Originating histopathology ServiceRequest" } ]
requisition
SHALL be added for Duo/Trio (familial) requests in order to link tests together. Requisition Identifiers are used to generate RequestGroup resources that assist with management of linked requests. SHALL NOT be populated for other types of test (singleton) or other scenarios where requests/results need to be linked (see `ServiceRequest.basedOn` guidance).For cases where the requisition identifier is required, it is expected that this is provided by client systems, as there are no rules on the central service that would be able to determine whether the test request is part of a Duo/Trio. As there are no central naming systems for requisition identifiers, it is expected the identifiers will be local identifiers following guidance on Referencing and Identifiers. Other mechanisms for determining or setting the requisition identifier, e.g. by the central service, or deterministically using patient/request identifiers are being investigated by the NHS England Genomics Unit.
For subsequent requests which are part of a group, it is expected the requisition identifier will be retrieved from the prior request, e.g. for the proband, either from the central broker or via some offline means, and will be recreated on the additional request exactly, including system and assigner, so the requests can be linked.
"requisition": { "system": "https://fhir.leedssth.nhs.uk//Id/grouptestId", "value": "RR-REQ12764", "assigner": { "identifier": { "system": "https://fhir.nhs.uk/Id/ods-organization-code", "value": "RR8" } } },
status
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
Category SHALL be populated with the reason for the 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-ReasonforTesting ValueSet SHOULD be used for this categorisation.
NOTE: The Genomics Sequencing Category coding is no longer in use as this information is captured within the mastered test data available through the DGTS API.
"category": [ { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/reasonfortesting-genomics", "code": "diagnostic", "display": "Diagnostic" } ] } ],
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
SHOULD be provided if known. If populated, Code SHOULD contain an appropriate test code, preferrably a DGTS Genomic Test code, though NGTD codes MAY be used during the transition period, currently available at https://www.england.nhs.uk/publication/national-genomic-test-directories/. There is currently a prototype DGTS FHIR API in development to support querying/retrieving codes.Codes from the Genomic Test Directory SHOULD also specify the version number of the test at the time the test is being ordered, to ensure the test methods used are consistent with that version.
"code": { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/England-DigitalGenomicTestService", "code": "GT1133", "display": "Common aneuploidy testing", "extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-GenomicTestCode-Version", "valueDecimal": 1.0 } ] } ] },
orderDetail
If additional coded details need to captured as part of a test order, e.g. Panels or targeted genes, these SHOULD be represented using the 'orderDetail' field, with the indication (TP code) captured within the same field. 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.It is expected that additional panels would be added as DGTS codes, and would need to concatenate TP and GT numbers, as such they SHOULD use the same system as the primary order code.
Not used in current implementation If a panel code is added as an additional panel, the system SHOULD come from the following NamingSystem: England-GenomicTestPanelCode
For Cancer WGS (or non-WGS tests), where no panel or test-level details are relevant, orderDetail SHOULD be omitted. This can be validated through the primary request being marked as having additional panels available and the additional order codes marked as being available as additional panels (exposed by the DGTS API within Library resources).
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:
"orderDetail": [ { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/England-DigitalGenomicTestService", "code": "TP145.GT1132", "extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-GenomicTestCode-Version", "valueDecimal": 0.1 } ], "display": "Hypertrophic cardiomyopathy - Panel sequencing", } ] } ],
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",
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)."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 SHALL be populated with the Test Package code for the order."reasonCode": [ { "coding": [ { "extension": [ { "url": "https://fhir.nhs.uk/England/StructureDefinition/Extension-GenomicTestCode-Version", "valueDecimal": 1 } ], "system": "https://fhir.nhs.uk/CodeSystem/England-DigitalGenomicTestService", "code": "TP229", "display": "Likely inborn error of metabolism" } ] } ],
reasonReference
Reference SHOULD be associated to the primary condition being tested for. Required if additional information related to the condition, such as onsetAge, needs to be captured for interpretation."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
For requests based on prior requests where multiple samples 'active' are associated with the prior request. The specific sample to be reprocessed SHALL be referenced from ServiceRequest.specimen.
"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.To support disambiguation of notes originating from different fields in a client system, the AnnotationType extension SHOULD 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: Due to architectural constraints in storing ethnicity and birth sex on the PDS record, these elements MAY appear in the notes element as an interim measure, until they are added to the master patient index.
"note": [ { "extension": [ { "url": "http://hl7.org/fhir/StructureDefinition/annotationType", "valueCodeableConcept": { "coding": [ { "system": "https://fhir.nhs.uk/CodeSystem/mds-questiontag-genomics", "code": "P-10", "display": "Patient - Sex defined at birth" } ] } } ], "authorReference": { "identifier": { "system": "https://fhir.nhs.uk/Id/sds-user-id", "value": "9999999999" }, "display": "Dr. Gene Smith" }, "text": "MALE" } ]