Release 4

This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU) in it's permanent home (it will always be available at this URL). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4

Orders and Observations Work GroupMaturity Level: 2 Trial UseSecurity Category: Patient Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson

Detailed Descriptions for the elements in the ServiceRequest resource.

ServiceRequest
Element IdServiceRequest
Definition

A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.

Cardinality0..*
TypeDomainResource
Alternate Namesdiagnostic request; referral; referral request; transfer of care request
Invariants
Defined on this element
prr-1Rule orderDetail SHALL only be present if code is presentorderDetail.empty() or code.exists()
ServiceRequest.identifier
Element IdServiceRequest.identifier
Definition

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

NoteThis is a business identifier, not a resource identifier (see discussion)
Cardinality0..*
TypeIdentifier
Summarytrue
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.

ServiceRequest.instantiatesCanonical
Element IdServiceRequest.instantiatesCanonical
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.

Cardinality0..*
Typecanonical(ActivityDefinition | PlanDefinition)
Summarytrue
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.

ServiceRequest.instantiatesUri
Element IdServiceRequest.instantiatesUri
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.

Cardinality0..*
Typeuri
Summarytrue
Comments

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

ServiceRequest.basedOn
Element IdServiceRequest.basedOn
Definition

Plan/proposal/order fulfilled by this request.

Cardinality0..*
TypeReference(CarePlan | ServiceRequest | MedicationRequest)
Alternate Namesfulfills
Summarytrue
ServiceRequest.replaces
Element IdServiceRequest.replaces
Definition

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

Cardinality0..*
TypeReference(ServiceRequest)
Alternate Namessupersedes; prior; renewed order
Summarytrue
ServiceRequest.requisition
Element IdServiceRequest.requisition
Definition

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

Cardinality0..1
TypeIdentifier
Requirements

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

Alternate NamesgrouperId; groupIdentifier
Summarytrue
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.

ServiceRequest.status
Element IdServiceRequest.status
Definition

The status of the order.

Cardinality1..1
Terminology BindingRequestStatus (Required)
Typecode
Is Modifiertrue (Reason: This element is labeled as a modifier because it is a status element that contains status entered-in-error which means that the resource should not be treated as valid)
Summarytrue
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 Event Pattern for general discussion) or using the Task resource.

ServiceRequest.intent
Element IdServiceRequest.intent
Definition

Whether the request is a proposal, plan, an original order or a reflex order.

Cardinality1..1
Terminology BindingRequestIntent (Required)
Typecode
Is Modifiertrue (Reason: This element changes the interpretation of all descriptive attributes. For example "the time the request is recommended to occur" vs. "the time the request is authorized to occur" or "who is recommended to perform the request" vs. "who is authorized to perform the request)
Summarytrue
Comments

This element is labeled as a modifier because the intent alters when and how the resource is actually applicable.

ServiceRequest.category
Element IdServiceRequest.category
Definition

A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").

Cardinality0..*
Terminology BindingService Request Category Codes (Example)
TypeCodeableConcept
Requirements

Used for filtering what service request are retrieved and displayed.

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

ServiceRequest.priority
Element IdServiceRequest.priority
Definition

Indicates how quickly the ServiceRequest should be addressed with respect to other requests.

Cardinality0..1
Terminology BindingRequest priority (Required)
Typecode
Meaning if MissingIf missing, this task should be performed with normal priority
Summarytrue
ServiceRequest.doNotPerform
Element IdServiceRequest.doNotPerform
Definition

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

Cardinality0..1
Typeboolean
Is Modifiertrue (Reason: If true this element negates the specified action. For Example, instead of a request for a procedure, it is a request for the procedure to not occur.)
Meaning if MissingIf missing, the request is a positive request e.g. "do perform"
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.

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

ServiceRequest.code
Element IdServiceRequest.code
Definition

A code that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested.

Cardinality0..1
Terminology BindingProcedure Codes (SNOMED CT) (Example)
TypeCodeableConcept
Alternate Namesservice requested
Summarytrue
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.

ServiceRequest.orderDetail
Element IdServiceRequest.orderDetail
Definition

Additional details and instructions about the how the services are to be delivered. For example, and order for a urinary catheter may have an order detail for an external or indwelling catheter, or an order for a bandage may require additional instructions specifying how the bandage should be applied.

Cardinality0..*
Terminology BindingService Request Order Details Codes (Example)
TypeCodeableConcept
Alternate Namesdetailed instructions
Summarytrue
Comments

For information from the medical record intended to support the delivery of the requested services, use the supportingInformation element.

Invariants
Affect this element
prr-1Rule orderDetail SHALL only be present if code is presentorderDetail.empty() or code.exists()
ServiceRequest.quantity[x]
Element IdServiceRequest.quantity[x]
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).

Cardinality0..1
TypeQuantity|Ratio|Range
[x] NoteSee Choice of Data Types for further information about how to use [x]
Requirements

When ordering a service the number of service items may need to be specified separately from the the service item.

Summarytrue
ServiceRequest.subject
Element IdServiceRequest.subject
Definition

On whom or what the service is to be performed. This is usually a human patient, but can also be requested on animals, groups of humans or animals, devices such as dialysis machines, or even locations (typically for environmental scans).

Cardinality1..1
TypeReference(Patient | Group | Location | Device)
Summarytrue
ServiceRequest.encounter
Element IdServiceRequest.encounter
Definition

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

Cardinality0..1
TypeReference(Encounter)
Alternate Namescontext
Summarytrue
ServiceRequest.occurrence[x]
Element IdServiceRequest.occurrence[x]
Definition

The date/time at which the requested service should occur.

Cardinality0..1
TypedateTime|Period|Timing
[x] NoteSee Choice of Data Types for further information about how to use [x]
Alternate Namesschedule
Summarytrue
ServiceRequest.asNeeded[x]
Element IdServiceRequest.asNeeded[x]
Definition

If a CodeableConcept is present, it indicates the pre-condition for performing the service. For example "pain", "on flare-up", etc.

Cardinality0..1
Terminology BindingSNOMED CT Medication As Needed Reason Codes (Example)
Typeboolean|CodeableConcept
[x] NoteSee Choice of Data Types for further information about how to use [x]
Summarytrue
ServiceRequest.authoredOn
Element IdServiceRequest.authoredOn
Definition

When the request transitioned to being actionable.

Cardinality0..1
TypedateTime
Alternate NamesorderedOn
Summarytrue
ServiceRequest.requester
Element IdServiceRequest.requester
Definition

The individual who initiated the request and has responsibility for its activation.

Cardinality0..1
TypeReference(Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device)
Alternate Namesauthor; orderer
Summarytrue
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.

ServiceRequest.performerType
Element IdServiceRequest.performerType
Definition

Desired type of performer for doing the requested service.

Cardinality0..1
Terminology BindingParticipant Roles (Example)
TypeCodeableConcept
Alternate Namesspecialty
Summarytrue
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”.

ServiceRequest.performer
Element IdServiceRequest.performer
Definition

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

Cardinality0..*
TypeReference(Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson)
Alternate Namesrequest recipient
Summarytrue
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).

ServiceRequest.locationCode
Element IdServiceRequest.locationCode
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.

Cardinality0..*
Terminology BindingV3 Value SetServiceDeliveryLocationRoleType (Example)
TypeCodeableConcept
Summarytrue
ServiceRequest.locationReference
Element IdServiceRequest.locationReference
Definition

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

Cardinality0..*
TypeReference(Location)
Summarytrue
ServiceRequest.reasonCode
Element IdServiceRequest.reasonCode
Definition

An explanation or justification for why this service is being requested in coded or textual form. This is often for billing purposes. May relate to the resources referred to in supportingInfo.

Cardinality0..*
Terminology BindingProcedure Reason Codes (Example)
TypeCodeableConcept
Summarytrue
Comments

This element represents why the referral is being made and may be used to decide how the service will be performed, or even if it will be performed at all. Use CodeableConcept.text element if the data is free (uncoded) text as shown in the CT Scan example.

ServiceRequest.reasonReference
Element IdServiceRequest.reasonReference
Definition

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

Cardinality0..*
TypeReference(Condition | Observation | DiagnosticReport | DocumentReference)
Summarytrue
Comments

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

ServiceRequest.insurance
Element IdServiceRequest.insurance
Definition

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

Cardinality0..*
TypeReference(Coverage | ClaimResponse)
ServiceRequest.supportingInfo
Element IdServiceRequest.supportingInfo
Definition

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

Cardinality0..*
TypeReference(Any)
Alternate NamesAsk at order entry question; AOE
Comments

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

ServiceRequest.specimen
Element IdServiceRequest.specimen
Definition

One or more specimens that the laboratory procedure will use.

Cardinality0..*
TypeReference(Specimen)
Summarytrue
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.

ServiceRequest.bodySite
Element IdServiceRequest.bodySite
Definition

Anatomic location where the procedure should be performed. This is the target site.

Cardinality0..*
Terminology BindingSNOMED CT Body Structures (Example)
TypeCodeableConcept
Requirements

Knowing where the procedure is performed is important for tracking if multiple sites are possible.

Alternate Nameslocation
Summarytrue
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.

ServiceRequest.note
Element IdServiceRequest.note
Definition

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

Cardinality0..*
TypeAnnotation
ServiceRequest.patientInstruction
Element IdServiceRequest.patientInstruction
Definition

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

Cardinality0..1
Typestring
Summarytrue
ServiceRequest.relevantHistory
Element IdServiceRequest.relevantHistory
Definition

Key events in the history of the request.

Cardinality0..*
TypeReference(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.