ServiceRequest - FHIR v6.0.0-cibuild (2024)

12.18.1 Scope and Usage

This resource is a request resource from a FHIR workflow perspective - see Workflow.

ServiceRequest represents an order or proposal or plan, as distinguished by ServiceRequest.intent to perform a diagnostic or other service on or for a patient. ServiceRequest represents a proposal or plan or order for a service to be performed that would result in a Procedure or DiagnosticReport, which in turn may reference one or more Observations, which summarize 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 onepractitioner or organization to another when a patient is required to be referred to another provider for aconsultation/second opinion and/or for short term or longer term management of one or more health issues or problems.

Examples include:

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

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

12.18.2 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 which spans both intent and event and 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.

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.

See Also

Leitfaden: Was ist unter "Management von Serviceanfragen" zu verstehen?

Provide feedback here .

Codes identifying the lifecycle stage of a request.

Codes indicating the degree of authority/intentionality associated with a request.

An example value set of SNOMED CT concepts that can classify a requested service

Identifies the level of importance to be assigned to actioning the request.

Procedure Code: All SNOMED CT procedure codes.

The order detail parameter codes.

This value set includes all clinical findings from SNOMED CT - provided as an exemplar value set.

Roles of participants that may be included in a care team. Defined as: Healthcare professional (occupation) or Services (qualifier value).

ServiceDeliveryLocationRoleType

A role of a place that further classifies the setting (e.g., accident site, road side, work site, community location) in which services are delivered.

This example value set defines the set of codes that can be used to indicate a reason for a procedure.

This value set includes all codes from SNOMED CT where concept is-a 442083009 (Anatomical or acquired body site (body structure)).