View raw Markdown
type: resourceresource: 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.

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, 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; and could be summarized in a DiagnosticReport detailing the performance and outcomes, perhaps through referencing select instances of Observation, ImagingStudy, 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.

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 may be needed.

This resource is a request resource from a FHIR workflow perspective - see 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, Observation, DiagnosticReport, ImagingStudy, or similar resource. In contrast to ServiceRequest, 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 section of 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.

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.

Notes

Notes:

StructureDefinition

Elements (Simplified)

Mappings

Implementation Guide

implementationguide-ServiceRequest-core.xml

<?xml version="1.0" encoding="UTF-8"?>

<ImplementationGuide xmlns="http://hl7.org/fhir">
  <id value="ServiceRequest-core"/>
  <version value="0.1"/>
  <name value="ServiceRequestHL7Extensions"/>
  <title value="Service  Request  H L7  Extensions"/>
  <status value="draft"/>
  <date value="2015-02-12T00:00:00.000"/>
  <publisher value="Health Level Seven, Inc. - FHIR WG"/>
  <description value="Defines common extensions used with or related to the Service Request resource"/>
</ImplementationGuide>

Resource Packs

list-ServiceRequest-packs.xml

<?xml version="1.0" encoding="UTF-8"?>

<List xmlns="http://hl7.org/fhir">
  <id value="ServiceRequest-packs"/>
  <status value="current"/>
  <mode value="working"/>
  <entry>
    <item>
      <reference value="ImplementationGuide/ServiceRequest-core"/>
    </item>
  </entry>
</List>

Search Parameters

Full Search Parameters

Examples

Full Examples

Mapping Exceptions

servicerequest-fivews-mapping-exceptions.xml

Divergent Elements

Unmapped Elements

servicerequest-request-mapping-exceptions.xml

Divergent Elements

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

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 for general discussion) or using the Task resource.

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.

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.

See additional guidance here. | 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