Release 4 5 Preview #3
This page is part of the FHIR Specification (v4.0.1: R4 - Mixed Normative and STU ). This is the current published version in it's permanent home (it will always be available at this URL). For a full list of available versions, see the Directory of published versions
Orders and Observations Work Group Maturity Level : 2   Trial Use Security Category : Patient Compartments : Device , Encounter , Patient , Practitioner , RelatedPerson

Detailed Descriptions for the elements in the ServiceRequest resource.

ServiceRequest
Element Id ServiceRequest
Definition

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

Cardinality 0..*
Type DomainResource
Alternate Names diagnostic request; referral; referral request; transfer of care request
Invariants
Defined on this element
prr-1 Rule orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()
ServiceRequest.identifier
Element Id ServiceRequest.identifier
Definition

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

Note This is a business identifier, not a resource identifier (see discussion )
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.

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

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.

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

Cardinality 0..*
Type uri
Summary true
Comments

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

ServiceRequest.basedOn
Element Id ServiceRequest.basedOn
Definition

Plan/proposal/order fulfilled by this request.

Cardinality 0..*
Type Reference ( CarePlan | ServiceRequest | MedicationRequest )
Patterns Reference(CarePlan,ServiceRequest,MedicationRequest): Common patterns = Request
Alternate Names fulfills
Summary true
ServiceRequest.replaces
Element Id ServiceRequest.replaces
Definition

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

Cardinality 0..*
Type Reference ( ServiceRequest )
Alternate Names supersedes; prior; renewed order
Summary true
ServiceRequest.requisition
Element Id ServiceRequest.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.

Cardinality 0..1
Type Identifier
Requirements

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

Alternate Names grouperId; groupIdentifier
Summary true
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 Id ServiceRequest.status
Definition

The status of the order.

Cardinality 1..1
Terminology Binding RequestStatus ( Required )
Type code
Is Modifier true (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)
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 Event Pattern for general discussion) or using the Task resource.

ServiceRequest.intent
Element Id ServiceRequest.intent
Definition

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

Cardinality 1..1
Terminology Binding RequestIntent ( Required )
Type code
Is Modifier true (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)
Summary true
Comments

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

ServiceRequest.category
Element Id ServiceRequest.category
Definition

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

Cardinality 0..*
Terminology Binding Service Request Category Codes ( Example )
Type CodeableConcept
Requirements

Used for filtering what service request are retrieved and displayed.

Summary true
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 Id ServiceRequest.priority
Definition

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

Cardinality 0..1
Terminology Binding Request priority ( Required )
Type code
Meaning if Missing If missing, this task should be performed with normal priority
Summary true
ServiceRequest.doNotPerform
Element Id ServiceRequest.doNotPerform
Definition

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

Cardinality 0..1
Type boolean
Is Modifier true (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 Missing If 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.

Summary true
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 Id ServiceRequest.code
Definition

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

Cardinality 0..1
Terminology Binding Procedure Codes (SNOMED CT) ( Example )
Type CodeableConcept
Alternate Names service requested
Summary true
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 Id ServiceRequest.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.

Cardinality 0..*
Terminology Binding Service Request Order Details Codes ( Example )
Type CodeableConcept
Alternate Names detailed instructions
Summary true
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-1 Rule orderDetail SHALL only be present if code is present orderDetail.empty() or code.exists()
ServiceRequest.quantity[x]
Element Id ServiceRequest.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).

Cardinality 0..1
Type Quantity | Ratio | Range
[x] Note See 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.

Summary true
ServiceRequest.subject
Element Id ServiceRequest.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).

Cardinality 1..1
Type Reference ( Patient | Group | Location | Device )
Patterns Reference(Patient,Group,Location,Device): Common patterns = Participant
Summary true
ServiceRequest.encounter
Element Id ServiceRequest.encounter
Definition

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

Cardinality 0..1
Type Reference ( Encounter )
Alternate Names context
Summary true
ServiceRequest.occurrence[x]
Element Id ServiceRequest.occurrence[x]
Definition

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

Cardinality 0..1
Type dateTime | Period | Timing
[x] Note See Choice of Data Types for further information about how to use [x]
Alternate Names schedule
Summary true
ServiceRequest.asNeeded[x]
Element Id ServiceRequest.asNeeded[x]
Definition

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

Cardinality 0..1
Terminology Binding SNOMED CT Medication As Needed Reason Codes ( Example )
Type boolean | CodeableConcept
[x] Note See Choice of Data Types for further information about how to use [x]
Summary true
ServiceRequest.authoredOn
Element Id ServiceRequest.authoredOn
Definition

When the request transitioned to being actionable.

Cardinality 0..1
Type dateTime
Alternate Names orderedOn
Summary true
ServiceRequest.requester
Element Id ServiceRequest.requester
Definition

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

Cardinality 0..1
Type Reference ( Practitioner | PractitionerRole | Organization | Patient | RelatedPerson | Device )
Patterns Reference(Practitioner,PractitionerRole,Organization,Patient,RelatedPerson,Device): Common patterns = Participant
Alternate Names author; orderer
Summary true
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 Id ServiceRequest.performerType
Definition

Desired type of performer for doing the requested service.

Cardinality 0..1
Terminology Binding Participant Roles ( Example )
Type CodeableConcept
Alternate Names specialty
Summary true
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 Id ServiceRequest.performer
Definition

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

Cardinality 0..*
Type Reference ( Practitioner | PractitionerRole | Organization | CareTeam | HealthcareService | Patient | Device | RelatedPerson )
Patterns Reference(Practitioner,PractitionerRole,Organization,CareTeam,HealthcareService,Patient,Device,RelatedPerson): Common patterns = Participant
Alternate Names request recipient
Summary true
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 ServiceRequest.location
Element Id ServiceRequest.locationCode ServiceRequest.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..*
Terminology Binding V3 Value SetServiceDeliveryLocationRoleType ServiceDeliveryLocationRoleType ( Example )
Type CodeableConcept Summary true ServiceRequest.locationReference Element Id ServiceRequest.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. Cardinality 0..* Type Reference CodeableReference ( Location )
Summary true
ServiceRequest.reasonCode ServiceRequest.reason
Element Id ServiceRequest.reasonCode ServiceRequest.reason
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 .

Cardinality 0..*
Terminology Binding Procedure Reason Codes ( Example )
Type CodeableConcept 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 CodeableConcept.text element if the data is free (uncoded) text as shown in the CT Scan example . ServiceRequest.reasonReference Element Id ServiceRequest.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 . Cardinality 0..* Type Reference CodeableReference ( Condition | Observation | DiagnosticReport | DocumentReference )
Patterns CodeableReference(Condition,Observation,DiagnosticReport,DocumentReference): Common patterns = Event
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 Otherwise, use DiagnosticReport.conclusion concept.text 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 Id ServiceRequest.insurance
Definition

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

Cardinality 0..*
Type Reference ( Coverage | ClaimResponse )
Patterns Reference(Coverage,ClaimResponse): Common patterns = Event
ServiceRequest.supportingInfo
Element Id ServiceRequest.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.

Cardinality 0..*
Type Reference ( Any )
Alternate Names Ask at order entry question; AOE
Comments

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

ServiceRequest.specimen
Element Id ServiceRequest.specimen
Definition

One or more specimens that the laboratory procedure will use.

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.

ServiceRequest.bodySite
Element Id ServiceRequest.bodySite
Definition

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

Cardinality 0..*
Terminology Binding SNOMED CT Body Structures ( Example )
Type CodeableConcept
Requirements

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

Alternate Names location
Summary true
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 Id ServiceRequest.note
Definition

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

Cardinality 0..*
Type Annotation
ServiceRequest.patientInstruction
Element Id ServiceRequest.patientInstruction
Definition

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

Cardinality 0..1
Type string
Summary true
ServiceRequest.relevantHistory
Element Id ServiceRequest.relevantHistory
Definition

Key events in the history of the request.

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