R4 Ballot #1 (Mixed Normative/Trial use)
WorkflowThis page is part of the FHIR Specification (v3.3.0: R4 Ballot 2). 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 Group | Maturity Level: 2 | Trial Use | Compartments: Device, Encounter, Patient, Practitioner, RelatedPerson |
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
STU Note: In terms of scope and usage, the Patient Care and Orders and Observations workgroups wish to draw the attention of reviewers and implementers to the following issues:
- ReferralRequest and ProcedureRequest have been merged into ServiceRequest since their content was nearly identical and no clear distinction was identified for managing the transfer of care responsibility from one practitioner/organization to another (Note that for STU3 DiagnosticRequest and ProcedureRequest were merged). We are seeking input on:
- How to represent whether a transfer of care is being requested
- Which elements if any in the ServiceRequest resource might not be applicable for a referral.
- The following elements have been added to this resource:
- Based on the workflow request pattern changes, the following have been updated:
- The
definitionelement was renamed to instantiates- The
requestercollapsed into a single element (requester.agentandrequest.onBehalfOfelements removed) and a reference to PractitionerRole added to the choices of reference targets- Additional reference targets added to the
performer, andreasonReferenceelements.- Added a statusReason standard extension - We would like implementer input on whether extension should be promoted to an inline element.
This resource is a request resource from a FHIR workflow perspective - see Workflow.
ServiceRequest is a record of a request for a procedure or diagnostic or other service to be planned, proposed, or performed, as distinguished by the ServiceRequest.intent field value, with or on a patient. The procedure will lead to either a Procedure or DiagnosticReport, that in turn may reference one or more Observations, that summarizes the performance of the procedures and associated documentation such as observations, images, findings that are relevant to the treatment/management of the subject. This resource may be used to share relevant information required to support a referral or a transfer of care request from one
practitioner or organization to another when a patient is required to be referred to another provider for a
consultation
/second opinion and/or for short term or longer term management of one or more health issues or problems.
Examples include:
Procedures may be performed by a healthcare professional, a friend or relative or in some cases by the patient themselves.
The principal intention of ServiceRequest is to support ordering procedures for one patient (which includes non-human patients in veterinary medicine). However, in many contexts, healthcare related processes include performing diagnostic investigations on groups of subjects, devices involved in the provision of healthcare, and even environmental locations such as ducts, bodies of water, etc. ServiceRequest supports all these usages. The service request may represent an order that is entered by a practitioner in a CPOE system as well as a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures referenced by a CarePlan may also be represented by this resource.
The general work flow that this resource facilitates is that a clinical system creates a service request. The service request is then accessed by or exchanged with a system, perhaps via intermediaries, that represents an organization (e.g., diagnostic or imaging service, surgical team, physical therapy department) that can perform the procedure. The organization receiving the service request will, after it accepts the request, update the request as the work is performed, and then finally issue a report that references the requests that it fulfilled.
The ServiceRequest resource allows requesting only a single procedure. If a workflow requires requesting multiple procedures simultaneously, this is done using multiple instances of this resource. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the Request pattern
ServiceRequest and CommunicationRequest are related. A CommunicationRequest is a request to merely disclose information. Whereas a ServiceRequest would be used to request information as part of training or counseling - i.e. when the process will involve verification of the patient's comprehension or an attempt to change the patient's mental state. In some workflows both may exist. For example, upon receiving a CommunicationRequest a practitioner might initiate a ServiceRequest.
This resource is referenced by Appointment, BiologicallyDerivedProduct, CarePlan, Claim, ClinicalImpression, DeviceUseStatement, DiagnosticReport, Encounter, EpisodeOfCare, ExplanationOfBenefit, Goal, ImagingStudy, Media, MedicationRequest, MedicationStatement, Observation, Procedure, QuestionnaireResponse and Specimen
Structure
UML Diagram (Legend)
XML Template
<ServiceRequest xmlns="http://hl7.org/fhir"><!-- from Resource: id, meta, implicitRules, and language --> <!-- from DomainResource: text, contained, extension, and modifierExtension --> <identifier><!-- 0..* Identifier Identifiers assigned to this order --></identifier> <instantiates value="[uri]"/><!-- 0..* Protocol or definition --> <basedOn><!-- 0..* Reference(CarePlan|ServiceRequest|MedicationRequest) What request fulfills --></basedOn> <replaces><!-- 0..* Reference(ServiceRequest) What request replaces --></replaces> <requisition><!-- 0..1 Identifier Composite Request ID --></requisition> <status value="[code]"/><!-- 1..1 draft | active | suspended | completed | entered-in-error | cancelled --> <intent value="[code]"/><!-- 1..1 proposal | plan | order + --> <category><!-- 0..* CodeableConcept Classification of service --></category> <priority value="[code]"/><!-- 0..1 routine | urgent | asap | stat --> <doNotPerform value="[boolean]"/><!-- 0..1 True if service/procedure should not be performed --> <code><!-- 0..1 CodeableConcept What is being requested/ordered --></code> <orderDetail><!--
0..* CodeableConcept Additional order information --></orderDetail> <subject><!-- 1..1 Reference(Patient|Group|Location|Device) Individual the service is ordered for --></subject> <context><!-- 0..1 Reference(Encounter|EpisodeOfCare) Encounter or Episode during which request was created --></context> <occurrence[x]><!-- 0..1 dateTime|Period|Timing When service should occur --></occurrence[x]> <asNeeded[x]><!-- 0..1 boolean|CodeableConcept Preconditions for service --></asNeeded[x]> <authoredOn value="[dateTime]"/><!-- 0..1 Date request signed --> <requester><!-- 0..1 Reference(Practitioner|PractitionerRole|Organization| Patient|RelatedPerson|Device) Who/what is requesting service --></requester> <performerType><!-- 0..1 CodeableConcept Performer role --></performerType> <performer><!-- 0..* Reference(Practitioner|PractitionerRole|Organization| CareTeam|HealthcareService|Patient|Device|RelatedPerson) Requested performer --></performer> <reasonCode><!-- 0..* CodeableConcept Explanation/Justification for procedure or service --></reasonCode> <reasonReference><!-- 0..* Reference(Condition|Observation|DiagnosticReport| DocumentReference) Explanation/Justification for service or service --></reasonReference> <insurance><!-- 0..* Reference(Coverage|ClaimResponse) Associated insurance coverage --></insurance> <supportingInfo><!-- 0..* Reference(Any) Additional clinical information --></supportingInfo> <specimen><!-- 0..* Reference(Specimen) Procedure Samples --></specimen> <bodySite><!-- 0..* CodeableConcept Location on Body --></bodySite> <note><!-- 0..* Annotation Comments --></note> <patientInstruction value="[string]"/><!-- 0..1 Patient or consumer-oriented instructions --> <relevantHistory><!-- 0..* Reference(Provenance) Request provenance --></relevantHistory> </ServiceRequest>
JSON Template
{
"resourceType" : "ServiceRequest",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // Identifiers assigned to this order
"instantiates" : ["<uri>"], // Protocol or definition
"basedOn" : [{ Reference(CarePlan|ServiceRequest|MedicationRequest) }], // What request fulfills
"replaces" : [{ Reference(ServiceRequest) }], // What request replaces
"requisition" : { Identifier }, // Composite Request ID
"status" : "<code>", // R! draft | active | suspended | completed | entered-in-error | cancelled
"intent" : "<code>", // R! proposal | plan | order +
"category" : [{ CodeableConcept }], // Classification of service
"priority" : "<code>", // routine | urgent | asap | stat
"doNotPerform" : <boolean>, // True if service/procedure should not be performed
"code" : { CodeableConcept }, // What is being requested/ordered
"orderDetail" : [{ CodeableConcept }], // C? Additional order information
"subject" : { Reference(Patient|Group|Location|Device) }, // R! Individual the service is ordered for
"context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
// occurrence[x]: When service should occur. One of these 3:
"occurrenceDateTime" : "<dateTime>",
"occurrencePeriod" : { Period },
"occurrenceTiming" : { Timing },
// asNeeded[x]: Preconditions for service. One of these 2:
"asNeededBoolean" : <boolean>,
"asNeededCodeableConcept" : { CodeableConcept },
"authoredOn" : "<dateTime>", // Date request signed
"requester" : { Reference(Practitioner|PractitionerRole|Organization|
Patient|RelatedPerson|Device) }, // Who/what is requesting service
"performerType" : { CodeableConcept }, // Performer role
"performer" : [{ Reference(Practitioner|PractitionerRole|Organization|
CareTeam|HealthcareService|Patient|Device|RelatedPerson) }], // Requested performer
"reasonCode" : [{ CodeableConcept }], // Explanation/Justification for procedure or service
"reasonReference" : [{ Reference(Condition|Observation|DiagnosticReport|
DocumentReference) }], // Explanation/Justification for service or service
"insurance" : [{ Reference(Coverage|ClaimResponse) }], // Associated insurance coverage
"supportingInfo" : [{ Reference(Any) }], // Additional clinical information
"specimen" : [{ Reference(Specimen) }], // Procedure Samples
"bodySite" : [{ CodeableConcept }], // Location on Body
"note" : [{ Annotation }], // Comments
"patientInstruction" : "<string>", // Patient or consumer-oriented instructions
"relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
Structure
XML Template
<ServiceRequest xmlns="http://hl7.org/fhir">
JSON Template
{
"resourceType" : "ServiceRequest",
// from Resource: id, meta, implicitRules, and language
// from DomainResource: text, contained, extension, and modifierExtension
"identifier" : [{ Identifier }], // Identifiers assigned to this order
"instantiates" : ["<uri>"], // Protocol or definition
"basedOn" : [{ Reference(CarePlan|ServiceRequest|MedicationRequest) }], // What request fulfills
"replaces" : [{ Reference(ServiceRequest) }], // What request replaces
"requisition" : { Identifier }, // Composite Request ID
"status" : "<code>", // R! draft | active | suspended | completed | entered-in-error | cancelled
"intent" : "<code>", // R! proposal | plan | order +
"category" : [{ CodeableConcept }], // Classification of service
"priority" : "<code>", // routine | urgent | asap | stat
"doNotPerform" : <boolean>, // True if service/procedure should not be performed
"code" : { CodeableConcept }, // What is being requested/ordered
"orderDetail" : [{ CodeableConcept }], // C? Additional order information
"subject" : { Reference(Patient|Group|Location|Device) }, // R! Individual the service is ordered for
"context" : { Reference(Encounter|EpisodeOfCare) }, // Encounter or Episode during which request was created
// occurrence[x]: When service should occur. One of these 3:
"occurrenceDateTime" : "<dateTime>",
"occurrencePeriod" : { Period },
"occurrenceTiming" : { Timing },
// asNeeded[x]: Preconditions for service. One of these 2:
"asNeededBoolean" : <boolean>,
"asNeededCodeableConcept" : { CodeableConcept },
"authoredOn" : "<dateTime>", // Date request signed
"requester" : { Reference(Practitioner|PractitionerRole|Organization|
Patient|RelatedPerson|Device) }, // Who/what is requesting service
"performerType" : { CodeableConcept }, // Performer role
"performer" : [{ Reference(Practitioner|PractitionerRole|Organization|
CareTeam|HealthcareService|Patient|Device|RelatedPerson) }], // Requested performer
"reasonCode" : [{ CodeableConcept }], // Explanation/Justification for procedure or service
"reasonReference" : [{ Reference(Condition|Observation|DiagnosticReport|
DocumentReference) }], // Explanation/Justification for service or service
"insurance" : [{ Reference(Coverage|ClaimResponse) }], // Associated insurance coverage
"supportingInfo" : [{ Reference(Any) }], // Additional clinical information
"specimen" : [{ Reference(Specimen) }], // Procedure Samples
"bodySite" : [{ CodeableConcept }], // Location on Body
"note" : [{ Annotation }], // Comments
"patientInstruction" : "<string>", // Patient or consumer-oriented instructions
"relevantHistory" : [{ Reference(Provenance) }] // Request provenance
}
Turtle Template
@prefix fhir: <http://hl7.org/fhir/> .
Alternate definitions: Master Definition XML + JSON, XML Schema/Schematron + JSON Schema, ShEx (for Turtle) + see the extensions & the dependency analysis
| Path | Definition | Type | Reference |
|---|---|---|---|
| ServiceRequest.status | The status of a service order. | Required | RequestStatus |
| ServiceRequest.intent | The kind of service request | Required | RequestIntent |
| ServiceRequest.category | Classification of the requested service. | Example | Service Request Category Codes |
| ServiceRequest.priority | Identifies the level of importance to be assigned to actioning the request | Required | RequestPriority |
| ServiceRequest.code | Codes for tests or services that can be carried out by a designated individual, organization or healthcare service. For laboratory, LOINC is (preferred)[http://build.fhir.org/terminologies.html#preferred] and a valueset using LOINC Order codes is available [here](valueset-diagnostic-requests.html). | Example | Procedure Codes (SNOMED CT) |
| ServiceRequest.orderDetail | Codified order entry details which are based on order context. | Example | Service Request Order Details Codes |
| ServiceRequest.asNeeded[x] | A coded concept identifying the pre-condition that should hold prior to performing a procedure. For example "pain", "on flare-up", etc. | Example | SNOMED CT Medication As Needed Reason Codes |
| ServiceRequest.performerType | Indicates specific responsibility of an individual within the care team, such as "Primary physician", "Team coordinator", "Caregiver", etc. | Example | Participant Roles |
| ServiceRequest.reasonCode | Diagnosis or problem codes justifying the reason for requesting the service investigation. | Example | Procedure Reason Codes |
| ServiceRequest.bodySite | Codes describing anatomical locations. May include laterality. | Example | SNOMED CT Body Structures |
: orderDetail.empty() or code.exists())code will often have this information embedded in it - for example, 'serum glucose' or 'chest x-ray'. Alternatively, the specimen or bodysite element may be used to specify it.reasonCode element is often for billing purposes. It may relate to the resources referred to in supportingInfo element and may be used to decide how a procedure or diagnostic investigation will be performed, or even if it will be performed at allSearch parameters for this resource. The common parameters also apply. See Searching for more information about searching in REST, messaging, and services.
| Name | Type | Description | Expression | In Common |
| authored | date | Date request signed | ServiceRequest.authoredOn | |
| based-on | reference | What request fulfills | ServiceRequest.basedOn (CarePlan, MedicationRequest, ServiceRequest) | |
| body-site | token | Where procedure is going to be done | ServiceRequest.bodySite | |
| category | token | Classification of service | ServiceRequest.category | |
| code | token | What is being requested/ordered | ServiceRequest.code | 8 Resources |
| context | reference | Encounter or Episode during which request was created | ServiceRequest.context (EpisodeOfCare, Encounter) | |
| encounter | reference | An encounter in which this request is made | ServiceRequest.context (Encounter) | 11 Resources |
| identifier | token | Identifiers assigned to this order | ServiceRequest.identifier | 25 Resources |
| instantiates | uri | Protocol or definition | ServiceRequest.instantiates | |
| intent | token | proposal | plan | order + | ServiceRequest.intent | |
| occurrence | date | When service should occur | ServiceRequest.occurrence | |
| patient | reference | Search by subject - a patient | ServiceRequest.subject (Patient) | 28 Resources |
| performer | reference | Requested performer | ServiceRequest.performer (Practitioner, Organization, CareTeam, Device, Patient, HealthcareService, PractitionerRole, RelatedPerson) | |
| performer-type | token | Performer role | ServiceRequest.performerType | |
| priority | token | routine | urgent | asap | stat | ServiceRequest.priority | |
| replaces | reference | What request replaces | ServiceRequest.replaces (ServiceRequest) | |
| requester | reference | Who/what is requesting service | ServiceRequest.requester (Practitioner, Organization, Device, Patient, PractitionerRole, RelatedPerson) | |
| requisition | token | Composite Request ID | ServiceRequest.requisition | |
| specimen | reference | Specimen to be tested | ServiceRequest.specimen (Specimen) | |
| status | token | draft | active | suspended | completed | entered-in-error | cancelled | ServiceRequest.status | |
| subject | reference | Search by subject | ServiceRequest.subject (Group, Device, Patient, Location) |
®© HL7.org 2011+. FHIR Mixed Nomative/Trial Use Ballot (v3.3.0-13671) generated on Tue, Apr 3, 2018 12:17+1000. QA Page
Links: Search |
Version History |
Table of Contents |
Credits |
Compare to DSTU3 |
|
Propose a change