StructureDefinition-UKCore-ServiceRequest

Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.

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.

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.

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.

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.

This might be an HTML page, PDF, etc. or could just be a non-resolvable URI identifier.

The request takes the place of the referenced completed or terminated request(s).

A shared identifier common to all service requests that were authorized more or less simultaneously by a single author, representing the composite or group identifier.

Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.

Requests are linked either by a "basedOn" relationship (i.e. one request is fulfilling another) or by having a common requisition. Requests that are part of the same requisition are generally treated independently from the perspective of changing their state or maintaining them after initial creation.

The 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.

Where the terminology does not clearly define what string should be used to identify code system versions, the recommendation is to use the date (expressed in FHIR date format) on which that version was officially published as the version date.

A symbol in syntax defined by the system. The symbol may be a predefined code or an expression in a syntax defined by the coding system (e.g. post-coordination).

Need to refer to a particular code in the system.

A representation of the meaning of the code in the system, following the rules of the system.

Need to be able to carry a human-readable meaning of the code for readers that do not know the system.

Indicates that this coding was chosen by a user directly - e.g. off a pick list of available items (codes or displays).

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.

Amongst a set of alternatives, a directly chosen code is the most appropriate starting point for new translations. There is some ambiguity about what exactly 'directly chosen' implies, and trading partner agreement may be needed to clarify the use of this element and its consequences more completely.

A human language representation of the concept as seen/selected/uttered by the user who entered the data and/or which represents the intended meaning of the user.

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.

Very often the text is the same as a displayName of one of the codings.

Set this to true if the record is saying that the service/procedure should NOT be performed.

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.

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.

If missing, the request is a positive request e.g. "do perform"

An encounter that provides additional information about the healthcare context in which this request is made.

Desired type of performer for doing the requested service.

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”.

Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc.

The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.

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).

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.

A location type where services are delivered.

A reference to the the preferred location(s) where the procedure should actually happen. E.g. at home or nursing day care center.

Indicates another resource that provides a justification for why this service is being requested. May relate to the resources referred to in supportingInfo.

This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. To be as specific as possible, a reference to Observation or Condition should be used if available. Otherwise when referencing DiagnosticReport it should contain a finding in DiagnosticReport.conclusion and/or DiagnosticReport.conclusionCode. When using a reference to DocumentReference, the target document should contain clear findings language providing the relevant reason for this service request. Use the CodeableConcept text element in ServiceRequest.reasonCode if the data is free (uncoded) text as shown in the CT Scan example.

Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.

Additional clinical information about the patient or specimen that may influence the services or their interpretations. This information includes diagnosis, clinical findings and other observations. In laboratory ordering these are typically referred to as "ask at order entry questions (AOEs)". This includes observations explicitly requested by the producer (filler) to provide context or supporting information needed to complete the order. For example, reporting the amount of inspired oxygen for blood gas measurements.

To represent information about how the services are to be delivered use the instructions element.

One or more specimens that the laboratory procedure will use.

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.

Any other notes and comments made about the service request. For example, internal billing notes.

Instructions in terms that are understood by the patient or consumer.

Key events in the history of the request.

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.