---
type: "resource"
title: "ServiceRequest"
resource: "ServiceRequest"
---
# ServiceRequest
## Introduction
## Scope and Usage
ServiceRequest represents an order or proposal or plan to perform a diagnostic or other service on or for a patient (including non-human patients in veterinary settings). Examples of the types of services that may be ordered by a ServiceRequest are:
> **Note to Balloters:**The new 'servicerequest-specimenSuggestion' extension is expected to be available soon in an upcoming release of the Extensions Pack.
- diagnostic tests/studies
- endoscopic procedures
- counseling
- biopsies
- therapies (e.g., physio-, social-, psychological-)
- (exploratory) surgeries or procedures
- exercises
- specialist consultation and assessments
- community services
- nursing services
- pharmacist medication review, and
- other clinical interventions.
A ServiceRequest can represent an order that is entered by a practitioner in a Computerized Physician Order Entry (CPOE) system, or a proposal made by a clinical decision support (CDS) system based on a patient's clinical record and context of care. Planned procedures, perhaps following a defined [CarePlan](careplan), may also be represented by this resource.
The `ServiceRequest.intent` element identifies if the resource represents an order, proposal, or plan to perform the indicated service for, or on, a patient. The service to be performed might result in a [Procedure](procedure); and could be summarized in a [DiagnosticReport](diagnosticreport) detailing the performance and outcomes, perhaps through referencing select instances of [Observation](observation), [ImagingStudy](imagingstudy), [Specimen](specimen) or other resources. The various generated resources are typically linked back to this ServiceRequest through their `basedOn` elements. The ServiceRequest resource may be used to share information to support a referral or transfer-of-care request from one practitioner or organization to another for a consultation, second opinion, or short- or longer-term management of health issues or problems.
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, perhaps via intermediaries, with a system 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.
Only a single procedure is requested by each ServiceRequest; if a workflow requires requesting multiple procedures simultaneously, this is done using multiple ServiceRequests. These instances can be linked in different ways, depending on the needs of the workflow. For guidance, refer to the [Request pattern](request).
Multiple ServiceRequests may exist that are associated in some way. When the association is a simple grouping, say for billing, that grouping can be indicated with the `ServiceRequest.requisition` element. When the ServiceRequest execution needs to be coordinated in some fashion, another resource such as [RequestOrchestration](requestorchestration) may be needed.
**This resource is a request resource from a FHIR workflow perspective** - see [Workflow](workflow).
## Boundaries and Relationships
ServiceRequest is a record of a proposal/plan or order for a service to be performed that would result in a [Procedure](procedure), [Observation](observation), [DiagnosticReport](diagnosticreport), [ImagingStudy](imagingstudy), or similar resource. In contrast to ServiceRequest, [Task](task) spans both intent and event, tracks the execution through to completion, and is intended for "administrative" actions like requesting and tracking things to be done to a record, or keeping track of a checklist of steps such to be performed as part of a fulfilment process. A ServiceRequest can be higher-level authorization that triggered the creation of Task, or it can be the "request" resource Task is seeking to fulfill. For further information about this separation of responsibilities between ServiceRequest and Task, refer to the [Fulfillment/Execution](request#fulfillment) section of the Request pattern.
ServiceRequest and [CommunicationRequest](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.
> **Note to Implementers:**
>
> The ServiceRequest.orderDetail structure is subject to further feedback based on use as the modeling creates a challenge when there is no focus, while an alternate structure would yield a requirement to repeat the focus attribute on each code/value pair.
>
> Provide feedback [here](http://hl7.org/fhir-issues).
## Notes
## Notes:
- Many service requests will create a need to specify a specimen, body site, or body system. The request `code` will often have this information embedded in it - for example, 'serum glucose' or 'chest x-ray'. Alternatively, the `servicerequest-specimenSuggestion` extension may be used to specify an existing specimen or the type of specimen expected to be collected, or a `bodyStructure` element may be used to specify a body site or body system.
- Most commonly the association between the Specimen and ServiceRequest resources will be from the Specimen to the ServiceRequest, as usually the ServiceRequest is created first and provides the authorization for the specimen to be collected, and the reference to the ServiceRequest is recorded using the [Specimen.request](specimen-definitions#Specimen.request) element.
- In the less common cases where the specimen to be used to perform the test is already known and available and needs to be specified at the time the ServiceRequest is created, it is preferable to use the 'specimenSuggestion' extension on the ServiceRequest resource, which enables specifying a particular specimen to be used either by a direct reference to a Specimen resource, more generally by a coded concept specifying the specimen type, or by a reference to another ServiceRequest that produced the existing specimen(s). When a specimen is suggested, it is expected to be used. If for some reason the suggested specimen is unable to be used (doesn't exist, wrong specimen type, insufficient quantity or quality, etc.), the decision to collect another specimen or to not perform the test must be based on established policies or determined by some other means agreed to with the requester.
- The `reason` element may be used to support billing. It may relate to the resources referred to in `supportingInfo` element and may also be used to decide how a procedure or diagnostic investigation will be performed, or even if it will be performed at all
- To capture the workflow around the solicitation of potential ServiceRequests based on time, price, etc, use the level 2 code "solicit-offer" on the "ask" ServiceRequest. For the ServiceRequest response to an "ask" ServiceRequest, use the level 2 code "offer-response" along with a basedOn reference to the "ask" ServiceRequest.
## StructureDefinition
### Elements (Simplified)
- **[ServiceRequest](/servicerequest-definitions#ServiceRequest)** [0..*]: - A request for a service to be performed
- **[ServiceRequest.identifier](/servicerequest-definitions#ServiceRequest.identifier)** [0..*]: [Identifier](/Identifier) Identifiers assigned to this order
- **[ServiceRequest.basedOn](/servicerequest-definitions#ServiceRequest.basedOn)** [0..*]: [Reference(CarePlan](/Reference(CarePlan), [DocumentReference](/DocumentReference), [ServiceRequest](/ServiceRequest), [MedicationRequest](/MedicationRequest), [RequestOrchestration](/RequestOrchestration), [NutritionOrder](/NutritionOrder), [DocumentReference)](/DocumentReference)) What request fulfills
- **[ServiceRequest.replaces](/servicerequest-definitions#ServiceRequest.replaces)** [0..*]: [Reference(ServiceRequest](/Reference(ServiceRequest), [MedicationRequest](/MedicationRequest), [RequestOrchestration](/RequestOrchestration), [CarePlan](/CarePlan), [DeviceRequest](/DeviceRequest), [CommunicationRequest](/CommunicationRequest), [NutritionOrder](/NutritionOrder), [VisionPrescription)](/VisionPrescription)) What request replaces
- **[ServiceRequest.requisition](/servicerequest-definitions#ServiceRequest.requisition)** [0..1]: [Identifier](/Identifier) Composite Request ID
- **[ServiceRequest.status](/servicerequest-definitions#ServiceRequest.status)** [1..1]: [code](/code) required:[request-status](/valueset-request-status) draft | active | on-hold | entered-in-error | ended | completed | revoked | unknown
- **[ServiceRequest.statusReason](/servicerequest-definitions#ServiceRequest.statusReason)** [0..*]: [CodeableConcept](/CodeableConcept) example:[servicerequest-status-reason](/valueset-servicerequest-status-reason) Reason for current status
- **[ServiceRequest.intent](/servicerequest-definitions#ServiceRequest.intent)** [1..1]: [code](/code) required:[request-intent](/valueset-request-intent) proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
- **[ServiceRequest.category](/servicerequest-definitions#ServiceRequest.category)** [0..*]: [CodeableConcept](/CodeableConcept) example:[servicerequest-category](/valueset-servicerequest-category) Classification of service
- **[ServiceRequest.priority](/servicerequest-definitions#ServiceRequest.priority)** [0..1]: [code](/code) required:[request-priority](/valueset-request-priority) routine | urgent | asap | stat
- **[ServiceRequest.doNotPerform](/servicerequest-definitions#ServiceRequest.doNotPerform)** [0..1]: [boolean](/boolean) True if service/procedure should not be performed
- **[ServiceRequest.code](/servicerequest-definitions#ServiceRequest.code)** [0..1]: [CodeableReference](/CodeableReference) example:[procedure-code](/valueset-procedure-code) What is being requested/ordered
- **[ServiceRequest.orderDetail](/servicerequest-definitions#ServiceRequest.orderDetail)** [0..*]: [BackboneElement](/BackboneElement) Additional information about the request
- **[ServiceRequest.orderDetail.parameterFocus[x]](/servicerequest-definitions#ServiceRequest.orderDetail.parameterFocus%5Bx%5D)** [0..1]: [CodeableConcept](/CodeableConcept), [Reference(Device](/Reference(Device), [DeviceRequest](/DeviceRequest), [Medication](/Medication), [MedicationRequest](/MedicationRequest), [BiologicallyDerivedProduct](/BiologicallyDerivedProduct), [Substance](/Substance), [SubstanceDefinition](/SubstanceDefinition), [MedicinalProductDefinition)](/MedicinalProductDefinition)), [canonical](/canonical) The context of the order details by reference
- **[ServiceRequest.orderDetail.parameter](/servicerequest-definitions#ServiceRequest.orderDetail.parameter)** [1..*]: [BackboneElement](/BackboneElement) The parameter details for the service being requested
- **[ServiceRequest.orderDetail.parameter.code](/servicerequest-definitions#ServiceRequest.orderDetail.parameter.code)** [1..1]: [CodeableConcept](/CodeableConcept) example:[request-orderdetail-parameter-code](/valueset-request-orderdetail-parameter-code) The detail of the order being requested
- **[ServiceRequest.orderDetail.parameter.value[x]](/servicerequest-definitions#ServiceRequest.orderDetail.parameter.value%5Bx%5D)** [1..1]: [Quantity](/Quantity), [Ratio](/Ratio), [Range](/Range), [boolean](/boolean), [CodeableConcept](/CodeableConcept), [string](/string), [Period](/Period) The value for the order detail
- **[ServiceRequest.quantity[x]](/servicerequest-definitions#ServiceRequest.quantity%5Bx%5D)** [0..1]: [Quantity](/Quantity), [Ratio](/Ratio), [Range](/Range) Service amount
- **[ServiceRequest.subject](/servicerequest-definitions#ServiceRequest.subject)** [1..1]: [Reference(Patient](/Reference(Patient), [Group](/Group), [Location](/Location), [Device)](/Device)) Individual or Entity the service is ordered for
- **[ServiceRequest.focus](/servicerequest-definitions#ServiceRequest.focus)** [0..*]: Reference([Resource](/Resource)) What the service request is about, when it is not about the subject of record
- **[ServiceRequest.encounter](/servicerequest-definitions#ServiceRequest.encounter)** [0..1]: Reference([Encounter](/Encounter)) Encounter in which the request was created
- **[ServiceRequest.occurrence[x]](/servicerequest-definitions#ServiceRequest.occurrence%5Bx%5D)** [0..1]: [dateTime](/dateTime), [Period](/Period), [Timing](/Timing) When service should occur
- **[ServiceRequest.asNeeded](/servicerequest-definitions#ServiceRequest.asNeeded)** [0..1]: [boolean](/boolean) Perform the service "as needed"
- **[ServiceRequest.asNeededFor](/servicerequest-definitions#ServiceRequest.asNeededFor)** [0..*]: [CodeableConcept](/CodeableConcept) example:[medication-as-needed-reason](/valueset-medication-as-needed-reason) Specified criteria for the service
- **[ServiceRequest.authoredOn](/servicerequest-definitions#ServiceRequest.authoredOn)** [0..1]: [dateTime](/dateTime) Date request signed
- **[ServiceRequest.requester](/servicerequest-definitions#ServiceRequest.requester)** [0..1]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [Patient](/Patient), [RelatedPerson](/RelatedPerson), [Device](/Device), [Group)](/Group)) Who/what is requesting service
- **[ServiceRequest.performerType](/servicerequest-definitions#ServiceRequest.performerType)** [0..1]: [CodeableConcept](/CodeableConcept) example:[participant-role](/valueset-participant-role) Performer role
- **[ServiceRequest.performer](/servicerequest-definitions#ServiceRequest.performer)** [0..*]: [Reference(Practitioner](/Reference(Practitioner), [PractitionerRole](/PractitionerRole), [Organization](/Organization), [CareTeam](/CareTeam), [HealthcareService](/HealthcareService), [Patient](/Patient), [Device](/Device), [RelatedPerson](/RelatedPerson), [Group)](/Group)) Requested performer
- **[ServiceRequest.location](/servicerequest-definitions#ServiceRequest.location)** [0..*]: [CodeableReference](/CodeableReference) example:[v3-ServiceDeliveryLocationRoleType](/valueset-v3-ServiceDeliveryLocationRoleType) Requested location
- **[ServiceRequest.reason](/servicerequest-definitions#ServiceRequest.reason)** [0..*]: [CodeableReference](/CodeableReference) example:[procedure-reason](/valueset-procedure-reason) Reason or indication for requesting the service
- **[ServiceRequest.insurance](/servicerequest-definitions#ServiceRequest.insurance)** [0..*]: [Reference(Coverage](/Reference(Coverage), [ClaimResponse)](/ClaimResponse)) Associated insurance coverage
- **[ServiceRequest.supportingInfo](/servicerequest-definitions#ServiceRequest.supportingInfo)** [0..*]: [CodeableReference](/CodeableReference) Additional clinical information
- **[ServiceRequest.specimen](/servicerequest-definitions#ServiceRequest.specimen)** [0..*]: Reference([Specimen](/Specimen)) Procedure Samples
- **[ServiceRequest.bodyStructure](/servicerequest-definitions#ServiceRequest.bodyStructure)** [0..1]: [CodeableReference](/CodeableReference) example:[body-site](/valueset-body-site) BodyStructure-based location on the body
- **[ServiceRequest.note](/servicerequest-definitions#ServiceRequest.note)** [0..*]: [Annotation](/Annotation) Comments
- **[ServiceRequest.patientInstruction](/servicerequest-definitions#ServiceRequest.patientInstruction)** [0..*]: [BackboneElement](/BackboneElement) Patient or consumer-oriented instructions
- **[ServiceRequest.patientInstruction.instruction[x]](/servicerequest-definitions#ServiceRequest.patientInstruction.instruction%5Bx%5D)** [0..1]: [markdown](/markdown), Reference([DocumentReference](/DocumentReference)) Patient or consumer-oriented instructions
- **[ServiceRequest.relevantHistory](/servicerequest-definitions#ServiceRequest.relevantHistory)** [0..*]: Reference([Provenance](/Provenance)) Request provenance
## Mappings
- [ServiceRequest Mappings](/servicerequest-mappings) — 112 mapping entries
## Implementation Guide
### implementationguide-ServiceRequest-core.xml
```xml
```
## Resource Packs
### list-ServiceRequest-packs.xml
```xml
-
```
## Search Parameters
- [authored](/servicerequest-search#authored) — **date** — Date request signed — `ServiceRequest.authoredOn`
- [based-on](/servicerequest-search#based-on) — **reference** — What request fulfills — `ServiceRequest.basedOn`
- [reference](/servicerequest-search#reference) — **reference** — Body structure where procedure is going to be done (reference) — `ServiceRequest.bodyStructure.reference`
- [body-structure-code](/servicerequest-search#body-structure-code) — **token** — Code for body structure where procedure is going to be done — `ServiceRequest.bodyStructure.concept`
- [category](/servicerequest-search#category) — **token** — Classification of service — `ServiceRequest.category`
- [code-concept](/servicerequest-search#code-concept) — **token** — What is being requested/ordered — `ServiceRequest.code.concept`
- [code-reference](/servicerequest-search#code-reference) — **reference** — What is being requested/ordered — `ServiceRequest.code.reference`
- [encounter](/servicerequest-search#encounter) — **reference** — An encounter in which this request is made — `ServiceRequest.encounter`
- [identifier](/servicerequest-search#identifier) — **token** — Identifiers assigned to this order — `ServiceRequest.identifier`
- [intent](/servicerequest-search#intent) — **token** — proposal | plan | directive | order + — `ServiceRequest.intent`
- [location-code](/servicerequest-search#location-code) — **token** — The preferred location specified in the ServiceRequest (coded) — `ServiceRequest.location.concept`
- [location-reference](/servicerequest-search#location-reference) — **reference** — The preferred location specified in the ServiceRequest (resource reference) — `ServiceRequest.location.reference`
- [occurrence](/servicerequest-search#occurrence) — **date** — When service should occur — `ServiceRequest.occurrence.ofType(dateTime) | ServiceRequest.occurrence.ofType(Period) | ServiceRequest.occurrence.ofType(Timing)`
- [patient](/servicerequest-search#patient) — **reference** — Search by subject - a patient — `ServiceRequest.subject.where(resolve() is Patient)`
- [performer](/servicerequest-search#performer) — **reference** — Requested performer — `ServiceRequest.performer`
- [performer-type](/servicerequest-search#performer-type) — **token** — Performer role — `ServiceRequest.performerType`
- [priority](/servicerequest-search#priority) — **token** — routine | urgent | asap | stat — `ServiceRequest.priority`
- [replaces](/servicerequest-search#replaces) — **reference** — What request replaces — `ServiceRequest.replaces`
- [requester](/servicerequest-search#requester) — **reference** — Who/what is requesting service — `ServiceRequest.requester`
- [requisition](/servicerequest-search#requisition) — **token** — Composite Request ID — `ServiceRequest.requisition`
- [status](/servicerequest-search#status) — **token** — draft | active | on-hold | revoked | completed | entered-in-error | unknown — `ServiceRequest.status`
- [subject](/servicerequest-search#subject) — **reference** — Search by subject — `ServiceRequest.subject`
- [group-or-identifier](/servicerequest-search#group-or-identifier) — **token** — Requisition ID or other identifier — `ServiceRequest.requisition | ServiceRequest.identifier`
[Full Search Parameters](/servicerequest-search)
## Examples
- [ambulation](/servicerequest-example-ambulation) — servicerequest-example-ambulation — Example of an order for anambulation procedure
- [appendectomy-narrative](/servicerequest-example-appendectomy-narrative) — servicerequest-example-appendectomy — Example of an order for an appendectomy procedure that is primarily narrative
- [benchpress](/servicerequest-example-benchpress) — servicerequest-example4 — Part of an exercise plan
- [colon-biopsy](/servicerequest-example-colon-biopsy) — servicerequest-example-colonoscopy-bx — Example of an order for a biopsy procedure that was part of a colonoscopy
- [colonoscopy](/servicerequest-example-colonoscopy) — servicerequest-example-colonoscopy — Example of an order for a colonoscopy procedure with complication
- [continuous-glucose](/servicerequest-example-continuous-glucose) — servicerequest-example-continuous-glucose — Continuous Glucose Monitoring
- [di](/servicerequest-example-di) — servicerequest-example-di — CT Scan order
- [do-not-turn](/servicerequest-example-do-not-turn) — servicerequest-example3 — An example of an order to not turn a patient
- [education](/servicerequest-example-education) — servicerequest-example-edu — Example of an order for patient education
- [example](/servicerequest-example-example) — servicerequest-example — An example of a Head CT procedure
- [example-implant](/servicerequest-example-example-implant) — servicerequest-example-implant — Example of an order for an implant
- [ft4](/servicerequest-example-ft4) — servicerequest-example-ft4 — Free T4 Add on Order
- [glucose](/servicerequest-example-glucose) — servicerequest-example-glucose — Glucose Monitoring
- [lipid](/servicerequest-example-lipid) — servicerequest-example-lipid — Lipid Panel Order
- [myringotomy](/servicerequest-example-myringotomy) — servicerequest-example-myringotomy — An example of a Myringotomy referral request
- [ob](/servicerequest-example-ob) — servicerequest-example-ob — Example of an order for an obstetric procedure
- [physical-therapy](/servicerequest-example-physical-therapy) — servicerequest-example-pt — Example of an order for a physical therapy evaluation procedure
- [physicaltherapy](/servicerequest-example-physicaltherapy) — servicerequest-example-physicaltherapy — An example of an order for physical therapy with a ratio quantity
- [physiotherapy](/servicerequest-example-physiotherapy) — servicerequest-example2 — An example of an order for home physiotherapy
- [servicerequest-example](/servicerequest-example-servicerequest-example) — servicerequest-example
- [servicerequest-example-ambulation](/servicerequest-example-servicerequest-example-ambulation) — servicerequest-example-ambulation
- [servicerequest-example-appendectomy](/servicerequest-example-servicerequest-example-appendectomy) — servicerequest-example-appendectomy
- [servicerequest-example-colonoscopy](/servicerequest-example-servicerequest-example-colonoscopy) — servicerequest-example-colonoscopy
- [servicerequest-example-colonoscopy-bx](/servicerequest-example-servicerequest-example-colonoscopy-bx) — servicerequest-example-colonoscopy-bx
- [servicerequest-example-continuous-glucose](/servicerequest-example-servicerequest-example-continuous-glucose) — servicerequest-example-continuous-glucose
- [servicerequest-example-di](/servicerequest-example-servicerequest-example-di) — servicerequest-example-di
- [servicerequest-example-edu](/servicerequest-example-servicerequest-example-edu) — servicerequest-example-edu
- [servicerequest-example-ft4](/servicerequest-example-servicerequest-example-ft4) — servicerequest-example-ft4
- [servicerequest-example-glucose](/servicerequest-example-servicerequest-example-glucose) — servicerequest-example-glucose
- [servicerequest-example-implant](/servicerequest-example-servicerequest-example-implant) — servicerequest-example-implant
- [servicerequest-example-lipid](/servicerequest-example-servicerequest-example-lipid) — servicerequest-example-lipid
- [servicerequest-example-myringotomy](/servicerequest-example-servicerequest-example-myringotomy) — servicerequest-example-myringotomy
- [servicerequest-example-ob](/servicerequest-example-servicerequest-example-ob) — servicerequest-example-ob
- [servicerequest-example-physicaltherapy](/servicerequest-example-servicerequest-example-physicaltherapy) — servicerequest-example-physicaltherapy
- [servicerequest-example-pt](/servicerequest-example-servicerequest-example-pt) — servicerequest-example-pt
- [servicerequest-example-subrequest](/servicerequest-example-servicerequest-example-subrequest) — servicerequest-example-subrequest
- [servicerequest-example-ventilation](/servicerequest-example-servicerequest-example-ventilation) — servicerequest-example-ventilation
- [servicerequest-example2](/servicerequest-example-servicerequest-example2) — servicerequest-example2
- [servicerequest-example3](/servicerequest-example-servicerequest-example3) — servicerequest-example3
- [servicerequest-example4](/servicerequest-example-servicerequest-example4) — servicerequest-example4
- [servicerequest-examples-header](/servicerequest-example-servicerequest-examples-header) — servicerequest-examples-header
- [servicerequest-examples-header 2](/servicerequest-example-servicerequest-examples-header 2) — servicerequest-examples-header 2
- [subrequest](/servicerequest-example-subrequest) — servicerequest-example-subrequest — Example with sub-requests derived from the request
- [vent](/servicerequest-example-vent) — servicerequest-example-ventilation — Order for mechanical ventilation with order details
[Full Examples](/servicerequest-examples)
## Mapping Exceptions
### servicerequest-fivews-mapping-exceptions.xml
### Divergent Elements
- **FiveWs.class** → **ServiceRequest.intent**
### Unmapped Elements
- **FiveWs.cause** — Unknown
- **FiveWs.version** — Unknown
- **FiveWs.witness** — Unknown
- **FiveWs.where** — Unknown
- **FiveWs.init** — Unknown
- **FiveWs.source** — Unknown
- **FiveWs.who** — Unknown
- **FiveWs.done** — Unknown
### servicerequest-request-mapping-exceptions.xml
### Divergent Elements
- **Request.identifier** → **ServiceRequest.identifier**
- shortUnmatched | reason=Unknown | pattern=Business Identifier for service request | resource=Identifiers assigned to this order
- definitionUnmatched | reason=Unknown | pattern=Business identifiers assigned to this service request by the author and/or other systems. These identifiers remain constant as the resource is updated and propagates from server to server. | resource=Identifiers assigned to this order instance by the orderer and/or the receiver and/or order fulfiller.
- commentsUnmatched | reason=Unknown | pattern=The identifier.type element is used to distinguish between the identifiers assigned by the requester/placer and the performer/filler.
Note: This is a business identifier, not a resource identifier (see [discussion](resource.html#identifiers)). 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. | resource=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.
- requirementsUnmatched | reason=Unknown | pattern=Allows identification of the service request as it is known by various participating systems and in a way that remains consistent across servers.
- **Request.basedOn** → **ServiceRequest.basedOn**
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Fulfills plan, proposal or order | resource=What request fulfills
- definitionUnmatched | reason=Unknown | pattern=A higher-level request resource (i.e. a plan, proposal or order) that is fulfilled in whole or in part by this service request. Authorization from the 'basedOn' request flows through to the referencing service request. | resource=Plan/proposal/order fulfilled by this request.
- commentsUnmatched | reason=Unknown | pattern=basedOn represents the 'authorization' chain for an action, not the 'reason for action'. For example, an order might be placed on hold under the authorization for a surgery. However the 'reason' for placing the hold is "to avoid interaction with anesthesia medications"
.
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing of authorization for the request and tracking whether proposals/recommendations were acted upon.
- **Request.replaces** → **ServiceRequest.replaces**
- missingTypes | reason=Unknown | pattern=Reference(Request)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Request(s) replaced by this service request | resource=What request replaces
- definitionUnmatched | reason=Unknown | pattern=Completed or terminated request(s) whose function is taken by this new service request. | resource=The request takes the place of the referenced completed or terminated request(s).
- commentsUnmatched | reason=Unknown | pattern=The replacement could be because the initial request was immediately rejected (due to an issue) or because the previous request was completed, but the need for the action described by the request remains ongoing.
- requirementsUnmatched | reason=Unknown | pattern=Allows tracing the continuation of a therapy or administrative process instantiated through multiple requests.
- **Request.groupIdentifier** → **ServiceRequest.requisition**
- shortUnmatched | reason=Unknown | pattern=Composite request this is part of | resource=Composite Request ID
- definitionUnmatched | reason=Unknown | pattern=A shared identifier common to all requests that were authorized more or less simultaneously by a single author, representing the identifier of the requisition, prescription or similar form. | resource=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.
- commentsUnmatched | reason=Unknown | pattern=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. | resource=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.
- requirementsUnmatched | reason=Unknown | pattern=Some business processes need to know if multiple items were ordered as part of the same "prescription" or "requisition" for billing or other purposes. | resource=Some business processes need to know if multiple items were ordered as part of the same "requisition" for billing or other purposes.
- **Request.status** → **ServiceRequest.status**
- shortUnmatched | reason=Unknown | pattern=draft | active | on-hold | revoked | completed | entered-in-error | unknown | resource=draft | active | on-hold | entered-in-error | ended | completed | revoked | unknown
- definitionUnmatched | reason=Unknown | pattern=The current state of the service request. | resource=The status of the order.
- commentsUnmatched | reason=Unknown | pattern=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, completed, cancelled or suspended. States relating to the activities of the performer are reflected on either the corresponding]](s) or using the]] resource. A nominal state-transition diagram can be found in the] documentation Unknown does not represent "other" - one of the defined statuses must apply. Unknown is used when the authoring system is not sure what the current status is. A status of 'active' when doNotPerform is true means that the request to not perform is currently in force.
A status of completed for a "doNotPerform" request indicates that the period of non-performance is now satisfied and the request no longer holds. | resource=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, revoked or placed on-hold. States relating to the activities of the performer are reflected on either the corresponding event (see [Event Pattern](event.html) for general discussion) or using the [Task](task.html) resource.
- **Request.statusReason** → **ServiceRequest.statusReason**
- definitionUnmatched | reason=Unknown | pattern=Captures the reason for the current state of the service request. Note that any change to the state requires the removal of any existing statusReasons, and, if appropriate, populating new statusReasons. | resource=Provides reason why the service request status is what it is. The statusReason can be used to explain why a service request is suspended, cancelled, or on hold, including administrative and clinical reasons.
- commentsUnmatched | reason=Unknown | pattern=This is generally only used for "exception" statuses such as "suspended" or "cancelled". The reason why the service request was created at all is captured in reasonCode, not here. . | resource=This is generally not present when the service request has a status of 'active' or 'completed'. There is potential overlap between ServiceRequest.reason (why the service is being requested) and ServiceRequest.statusReason (why the request is in its current status) early in the performance of the request when the reason for the service request might influence the initial status.
- **Request.intent** → **ServiceRequest.intent**
- shortUnmatched | reason=Unknown | pattern=proposal | plan | order (immutable) | resource=proposal | solicit-offer | offer-response | plan | directive | order | original-order | reflex-order | filler-order | instance-order | option
- definitionUnmatched | reason=Unknown | pattern=Indicates the level of authority/intentionality associated with the service request and where the request fits into the workflow chain. | resource=Whether the request is a proposal, plan, an original order or a reflex order.
- commentsUnmatched | reason=Unknown | pattern=This element is expected to be immutable. E.g. A "proposal" instance should never change to be a "plan" instance or "order" instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value.
One exception to this is that the granularity of Request.intent is allowed to change. For example, a Request identified as an "order" might later be clarified to be a "filler-order". Or, in rarer cases (to meet recipient constraints), the reverse might also occur.
When resources map to this element, they are free to define as many codes as necessary to cover their space and will map to "proposal, plan or order". Can have multiple codes that map to one of these. E.g. "original order", "encoded order", "reflex order" would all map to "order". Expectation is that the set of codes is mutually exclusive or a strict all-encompassing hierarchy. | resource=This element is expected to be immutable. E.g. A 'proposal' instance should never change to be a 'plan' instance or 'order' instance. Instead, a new instance 'basedOn' the prior instance should be created with the new 'intent' value.
One exception to this is that the granularity of ServiceRequest.intent is allowed to change. For example, a ServiceRequest identified as an 'order' might later be clarified to be a 'filler-order'. Or, in rarer cases (to meet recipient constraints), the reverse might also occur.
- requirementsUnmatched | reason=Unknown | pattern=Proposals/recommendations, plans and orders all use the same structure and can exist in the same fulfillment chain.
- **Request.priority** → **ServiceRequest.priority**
- definitionUnmatched | reason=Unknown | pattern=Indicates how quickly the service request should be addressed with respect to other requests. | resource=Indicates how quickly the ServiceRequest should be addressed with respect to other requests.
- **Request.doNotPerform** → **ServiceRequest.doNotPerform**
- shortUnmatched | reason=Unknown | pattern=true if request is prohibiting action | resource=True if service/procedure should not be performed
- definitionUnmatched | reason=Unknown | pattern=If true indicates that the service request is asking for the specified action to *not* occur. | resource=Set this to true if the record is saying that the service/procedure should NOT be performed.
- commentsUnmatched | reason=Unknown | pattern=The attributes provided with the request qualify what is not to be done. For example, if an effectiveTime is provided, the "do not" request only applies within the specified time. If a performerType is specified then the "do not" request only applies to performers of that type. Qualifiers include: code, subject, occurrence, performerType and performer.
In some cases, the Request.code may pre-coordinate prohibition into the requested action. E.g. "NPO" (nothing by mouth), "DNR" (do not recussitate). If this happens, doNotPerform SHALL NOT be set to true. I.e. The resource shall not have double negation. (E.g. "Do not DNR"). | resource=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.
- requirementsUnmatched | reason=Unknown | pattern=Supports things like Do Not Recussitate, Nothing by mouth, etc. | resource=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.
- **Request.category** → **ServiceRequest.category**
- shortUnmatched | reason=Unknown | pattern=Partitions the service request into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior. | resource=Classification of service
- definitionUnmatched | reason=Unknown | pattern=Partitions the service request into one or more categories that can be used to filter searching, to govern access control and/or to guide system behavior. | resource=A code that classifies the service for searching, sorting and display purposes (e.g. "Surgical Procedure").
- requirementsUnmatched | reason=Unknown | pattern=Categorization might be done automatically (inferred by code) or manually by user assertion. The absence of a category may limit the ability to determine when the element should be handled, so strong consideration should be given to how systems will be able to determine category values for legacy data and how data that cannot be categorized will be handled. As well, some categories might not be mutually exclusive, so systems should prepare for multiple declared categories - even within a single category 'axis'.
In general, there should not be a 'strong' binding ('required' or 'extensible') on the category element overall. Instead, the element can be sliced and bindings can be asserted that apply to particular repetitions. | resource=Used for filtering what service request are retrieved and displayed.
- **Request.code** → **ServiceRequest.code**
- missingTypes | reason=Unknown | pattern=CodeableConcept
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Service requested/ordered | resource=What is being requested/ordered
- definitionUnmatched | reason=Unknown | pattern=A code that identifies the specific service or action being asked to be done (or not done). | resource=A code or reference that identifies a particular service (i.e., procedure, diagnostic investigation, or panel of investigations) that has been requested.
- **Request.product** → **ServiceRequest.orderDetail.parameterFocus[x]**
- missingTypes | reason=Unknown | pattern=CodeableReference(BiologicallyDerivedProduct, Device, DeviceDefinition, Medication, NutritionProduct, Substance)
- extraTypes | reason=Unknown
- summary | reason=Unknown | pattern=true
- shortUnmatched | reason=Unknown | pattern=Product requested/ordered | resource=The context of the order details by reference
- definitionUnmatched | reason=Unknown | pattern=Indicates the product whose supply or manipulation is authorized by this service request. | resource=Indicates the context of the order details by reference.
- **Request.subject** → **ServiceRequest.subject**
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Individual the service is ordered/prohibited for | resource=Individual or Entity the service is ordered for
- definitionUnmatched | reason=Unknown | pattern=The individual or set of individuals the action is to be performed/not performed on or for. | resource=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).
- requirementsUnmatched | reason=Unknown | pattern=Links the request to the Patient context.
- **Request.encounter** → **ServiceRequest.encounter**
- shortUnmatched | reason=Unknown | pattern=Encounter the service request is tied to | resource=Encounter in which the request was created
- definitionUnmatched | reason=Unknown | pattern=The Encounter during which this service request was created or to which the creation of this record is tightly associated. | resource=An encounter that provides additional information about the healthcare context in which this request is made.
- commentsUnmatched | reason=Unknown | pattern=This will typically be the encounter during which the service request was created. However, some {{title}s may be initiated prior to or after the official completion of an encounter but still be tied to the context of the encounter (e.g. pre-admission activities).
- requirementsUnmatched | reason=Unknown | pattern=Links the service request to the Encounter context.
- **Request.occurrence[x]** → **ServiceRequest.occurrence[x]**
- shortUnmatched | reason=Unknown | pattern=When service should (not) occur | resource=When service should occur
- definitionUnmatched | reason=Unknown | pattern=The date or time(s) at which the activity or service is desired to occur or not occur. | resource=The date/time at which the requested service should occur.
- **Request.authoredOn** → **ServiceRequest.authoredOn**
- shortUnmatched | reason=Unknown | pattern=When request was created/transitioned to active | resource=Date request signed
- definitionUnmatched | reason=Unknown | pattern=For draft service requests, indicates the date of initial creation. For requests with other statuses, indicates the date of activation. | resource=When the request transitioned to being actionable.
- **Request.requester** → **ServiceRequest.requester**
- extraTypes | reason=Unknown
- definitionUnmatched | reason=Unknown | pattern=Who initiated the {{request}} and has responsibility for its activation. | resource=The individual who initiated the request and has responsibility for its activation.
- **Request.performerType** → **ServiceRequest.performerType**
- shortUnmatched | reason=Unknown | pattern=Desired kind of service performer | resource=Performer role
- definitionUnmatched | reason=Unknown | pattern=The type of individual that is desired to act upon/ not act upon the {{request}}. | resource=Desired type of performer for doing the requested service.
- commentsUnmatched | reason=Unknown | pattern=If specified without indicating a performer, this indicates that the performer must be (or can't be) of the specified type. If specified with a performer then it indicates the requirements of the performer if the designated performer is not available. If doNotPerform is true, then only one of performerType and performer should be present. | resource=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”.
- **Request.performer** → **ServiceRequest.performer**
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Specific desired (non)performer | resource=Requested performer
- definitionUnmatched | reason=Unknown | pattern=Indicates who or what is being asked to perform (or not perform) the {{request}}. | resource=The desired performer for doing the requested service. For example, the surgeon, dermatopathologist, endoscopist, etc.
- **Request.reason** → **ServiceRequest.reason**
- shortUnmatched | reason=Unknown | pattern=Why is service (not) needed? | resource=Reason or indication for requesting the service
- definitionUnmatched | reason=Unknown | pattern=Describes why the request is being made in coded or textual form, or Indicates another resource whose existence justifies this request. | resource=The reason or the indication for requesting the service (e.g., procedure, lab test).
- commentsUnmatched | reason=Unknown | pattern=Textual reasons can be captured using reasonCode.text. If doNoPerform is true, this will be the reason why the request is being made to not act. | resource=This element represents why the request 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. Use `reason.concept.text` element if the data is free (uncoded) text as shown in the [CT Scan example](servicerequest-example-di.html).
- **Request.insurance** → **ServiceRequest.insurance**
- definitionUnmatched | reason=Unknown | pattern=Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be relevant in delivering the requested service. | resource=Insurance plans, coverage extensions, pre-authorizations and/or pre-determinations that may be needed for delivering the requested service.
- **Request.supportingInfo** → **ServiceRequest.supportingInfo**
- missingTypes | reason=Unknown | pattern=Reference(Any)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Extra information to use in performing request | resource=Additional clinical information
- definitionUnmatched | reason=Unknown | pattern=Information that may be needed by/relevant to the performer in their execution of this service request. | resource=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.
- commentsUnmatched | reason=Unknown | pattern=See guidance on [notes vs. supportingInfo](request.html#notes). | resource=To represent information about how the services are to be delivered, use the orderDetail element.
- **Request.note** → **ServiceRequest.note**
- shortUnmatched | reason=Unknown | pattern=Comments made about service request | resource=Comments
- definitionUnmatched | reason=Unknown | pattern=Comments made about the service request by the requester, performer, subject or other participants. | resource=Any other notes and comments made about the service request. For example, internal billing notes.
- commentsUnmatched | reason=Unknown | pattern=See guidance on [notes vs. supportingInfo](request.html#notes).
- **Request.relevantHistory** → **ServiceRequest.relevantHistory**
- missingTypes | reason=Unknown | pattern=Reference(ProvenanceRelevantHistory)
- extraTypes | reason=Unknown
- shortUnmatched | reason=Unknown | pattern=Key events in history of service request | resource=Request provenance
- definitionUnmatched | reason=Unknown | pattern=Links to Provenance records for past versions of this resource or fulfilling request or event resources that identify key state transitions or updates that are likely to be relevant to a user looking at the current version of the resource. | resource=Key events in the history of the request.
- commentsUnmatched | reason=Unknown | pattern=This element does not point to the Provenance associated with the *current* version of the resource - as it would be created after this version existed. The Provenance for the current version can be retrieved with a _revinclude. Referenced provenances SHOULD adhere to the [provenance-relevant-history profile](provenance-relevant-history.html).
See additional guidance [here](request.html#history). | resource=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.
### Unmapped Elements
- **Request.deliverTo** — Unknown
- **Request.reported** — Unknown