FHIR CI-Build

This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions icon

Orders and Observations icon 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.

Short DisplayA request for a service to be performed
Cardinality0..*
TypeDomainResource
Alternate Namesdiagnostic request; referral; referral request; transfer of care request
Summaryfalse
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.

Short DisplayIdentifiers assigned to this order
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.

Short DisplayInstantiates FHIR protocol or definition
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.

Short DisplayInstantiates external protocol or definition
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.

Short DisplayWhat request fulfills
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).

Short DisplayWhat request replaces
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.

Short DisplayComposite Request ID
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.

Short Displaydraft | active | on-hold | revoked | completed | entered-in-error | unknown
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.

Short Displayproposal | plan | directive | 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").

Short DisplayClassification of service
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.

Short Displayroutine | urgent | asap | stat
Cardinality0..1
Terminology BindingRequestPriority (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.

Short DisplayTrue if 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 or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that have been requested.

Short DisplayWhat is being requested/ordered
Cardinality0..1
Terminology BindingProcedure Codes (SNOMED CT) (Example)
TypeCodeableReference(ActivityDefinition | PlanDefinition)
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.

Short DisplayAdditional order information
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).

Short DisplayService amount
Cardinality0..1
TypeQuantity|Ratio|Range
[x] NoteSee Choice of Datatypes 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).

Short DisplayIndividual or Entity the service is ordered for
Cardinality1..1
TypeReference(Patient | Group | Location | Device)
Summarytrue
ServiceRequest.focus
Element IdServiceRequest.focus
Definition

The actual focus of a service request when it is not the subject of record representing something or someone associated with the subject such as a spouse, parent, fetus, or donor. The focus of a service request could also be an existing condition, an intervention, the subject's diet, another service request on the subject, or a body structure such as tumor or implanted device.

Short DisplayWhat the service request is about, when it is not about the subject of record
Cardinality0..*
TypeReference(Any)
Summarytrue
ServiceRequest.encounter
Element IdServiceRequest.encounter
Definition

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

Short DisplayEncounter in which the request was created
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.

Short DisplayWhen service should occur
Cardinality0..1
TypedateTime|Period|Timing
[x] NoteSee Choice of Datatypes 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.

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

When the request transitioned to being actionable.

Short DisplayDate request signed
Cardinality0..1
TypedateTime
Alternate NamesorderedOn
Summarytrue
ServiceRequest.requester
Element IdServiceRequest.requester
Definition

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

Short DisplayWho/what is requesting service
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.

Short DisplayPerformer role
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.

Short DisplayRequested performer
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.location
Element IdServiceRequest.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.

Short DisplayRequested location
Cardinality0..*
Terminology BindingServiceDeliveryLocationRoleType icon (Example)
TypeCodeableReference(Location)
Summarytrue
ServiceRequest.reason
Element IdServiceRequest.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.

Short DisplayExplanation/Justification for procedure or service
Cardinality0..*
Terminology BindingProcedure Reason Codes (Example)
TypeCodeableReference(Condition | Observation | DiagnosticReport | DocumentReference | DetectedIssue)
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, use concept.text element 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.

Short DisplayAssociated insurance coverage
Cardinality0..*
TypeReference(Coverage | ClaimResponse)
Summaryfalse
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.

Short DisplayAdditional clinical information
Cardinality0..*
TypeReference(Any)
Alternate NamesAsk at order entry question; AOE
Summaryfalse
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.

Short DisplayProcedure Samples
Cardinality0..*
TypeReference(Specimen)
Summarytrue
Comments

The purpose of the ServiceRequest.specimen is to reflect the actual specimen that the requested test/procedure is asked to be performed on, whether the lab already has it or not. References to specimens for purposes other than to perform a test/procedure on should be made using the ServiceRequest.supportingInfo or the Specimen.parent where the Specimen.parent would enable descendency and ServiceRequest.supportingInfo a general reference for context.

ServiceRequest.bodySite
Element IdServiceRequest.bodySite
Definition

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

Short DisplayCoded location on Body
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.bodyStructure
Element IdServiceRequest.bodyStructure
Definition

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

Short DisplayBodyStructure-based location on the body
Cardinality0..1
TypeReference(BodyStructure)
Requirements

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

Alternate NameslocationStructure
Summarytrue
Invariants
Defined on this element
bdystr-1Rule bodyStructure SHALL only be present if bodySite is not presentbodySite.exists() or bodyStructure.exists()
ServiceRequest.note
Element IdServiceRequest.note
Definition

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

Short DisplayComments
Cardinality0..*
TypeAnnotation
Summaryfalse
ServiceRequest.patientInstruction
Element IdServiceRequest.patientInstruction
Definition

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

Short DisplayPatient or consumer-oriented instructions
Cardinality0..1
Typestring
Summarytrue
ServiceRequest.relevantHistory
Element IdServiceRequest.relevantHistory
Definition

Key events in the history of the request.

Short DisplayRequest provenance
Cardinality0..*
TypeReference(Provenance)
Summaryfalse
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.