This is the Continuous Integration Build of FHIR (will be incorrect/inconsistent at times).
See the Directory of published versions 
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
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
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 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
.
Path | ValueSet | Type | Documentation |
ServiceRequest.status | RequestStatus | Required | Codes identifying the lifecycle stage of a request. |
ServiceRequest.intent | RequestIntent | Required | Codes indicating the degree of authority/intentionality associated with a request. |
ServiceRequest.category | ServiceRequestCategoryCodes | Example | An example value set of SNOMED CT concepts that can classify a requested service |
ServiceRequest.priority | RequestPriority | Required | Identifies the level of importance to be assigned to actioning the request. |
ServiceRequest.code | ProcedureCodesSNOMEDCT | Example | Procedure Code: All SNOMED CT procedure codes. |
ServiceRequest.orderDetail.parameter.code | ServiceRequestOrderDetailParameterCode | Example | The order detail parameter codes. |
ServiceRequest.asNeeded[x] | SNOMEDCTMedicationAsNeededReasonCodes | Example | This value set includes all clinical findings from SNOMED CT - provided as an exemplar value set. |
ServiceRequest.performerType | ParticipantRoles | Example | Roles of participants that may be included in a care team. Defined as: Healthcare professional (occupation) or Services (qualifier value). |
ServiceRequest.location | ServiceDeliveryLocationRoleType | Example | 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. |
ServiceRequest.reason | ProcedureReasonCodes | Example | This example value set defines the set of codes that can be used to indicate a reason for a procedure. |
ServiceRequest.bodySite | SNOMEDCTBodyStructures | Example | This value set includes all codes from SNOMED CT where concept is-a 442083009 (Anatomical or acquired body site (body structure)). |
Name | Type | Description | Expression | In Common |
authored | date | Date request signed | ServiceRequest.authoredOn | |
based-on | reference | What request fulfills | ServiceRequest.basedOn (CarePlan, MedicationRequest, RequestOrchestration, ServiceRequest) | |
body-site | token | Where procedure is going to be done | ServiceRequest.bodySite | |
body-structure | reference | Body structure Where procedure is going to be done | ServiceRequest.bodyStructure (BodyStructure) | |
category | token | Classification of service | ServiceRequest.category | |
code-concept | token | What is being requested/ordered | ServiceRequest.code.concept | |
code-reference | reference | What is being requested/ordered | ServiceRequest.code.reference | |
encounter | reference | An encounter in which this request is made | ServiceRequest.encounter (Encounter) | 29 Resources |
identifier | token | Identifiers assigned to this order | ServiceRequest.identifier | 65 Resources |
instantiates-canonical | reference | Instantiates FHIR protocol or definition | ServiceRequest.instantiatesCanonical (PlanDefinition, ActivityDefinition) | |
instantiates-uri | uri | Instantiates external protocol or definition | ServiceRequest.instantiatesUri | |
intent | token | proposal | plan | directive | order + | ServiceRequest.intent | |
location-code | token | The preferred location specified in the ServiceRequest (coded) | ServiceRequest.location.concept | |
location-reference | reference | The preferred location specified in the ServiceRequest (resource reference) | ServiceRequest.location.reference | |
occurrence | date | When service should occur | ServiceRequest.occurrence.ofType(dateTime) | ServiceRequest.occurrence.ofType(Period) | ServiceRequest.occurrence.ofType(Timing) | |
patient | reference | Search by subject - a patient | ServiceRequest.subject.where(resolve() is Patient) (Patient) | 65 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 | on-hold | revoked | completed | entered-in-error | unknown | ServiceRequest.status | |
subject | reference | Search by subject | ServiceRequest.subject (Group, Device, Patient, Location) | |
FAQs
A record of a request for service such as diagnostic investigations, treatments, or operations to be performed.
What is the difference between HL7 and FHIR standard? ›
The main difference between FHIR and HL7 is that FHIR leverages RESTful web services and open web technologies such as XML, JSON, and RDF, while HL7 only supports XML. FHIR builds on previous standards, including HL7 CDA, V2, and V3, but is easier to use since it covers a broader range of technologies.
What is a FHIR bundle? ›
A FHIR bundle contains an array of entries, each of which represents an operation, such as create, update, or delete, on a resource, such as an Observation or a Patient. See the detailed descriptions for the elements in the Bundle resource.
What is the FHIR standard? ›
Fast Healthcare Interoperability Resources (FHIR) is a Health Level Seven International® (HL7®) standard for exchanging health care information electronically.
What is a servicing request? ›
Service request - A formal user request for something new to be provided. Example: “I need a new Macbook.”
What are the stages of a service request? ›
What is the service request management process?
- In ITIL, a service request follows a series of steps, including the following:
- Submission. The service request management process begins when a employee reaches out to submit a service request. ...
- Assessment. ...
- Fulfillment. ...
- Completion. ...
- Follow up.
Is FHIR an API? ›
Fast Healthcare Interoperability Resources (FHIR) is a healthcare data standard with an application programming interface (API) for representing and exchanging electronic health records (EHR).
What are the advantages of FHIR over HL7? ›
FHIR is designed with modern technologies in mind, making it more intuitive for developers. Its compatibility surpasses that of HL7 standards, and its primary aim is to simplify interoperability. FHIR is not just about exchanging data but ensuring it's done seamlessly across different platforms.
How many versions of FHIR are there? ›
Major Milestones:
Version Number | Version Title | Date of Publication |
---|
0.01 | FHIR | 5/14/2012 |
0.0.82 | DSTU 1 (First Draft Standard for Trial Use) | 9/30/2014 |
1.0.2 | DSTU 2 (Second Draft Standard for Trial Use) | 10/24/2015 |
3.0.2 | FHIR Release 3 (STU - Standard for Trial Use) | 10/24/2019 |
3 more rows
What companies are using FHIR? ›
What companies use FHIR? Some of the companies that use FHIR include Bitcare GmbH, Smile Digital Health, Dice, Omnicell, 1upHealth, CVS Health, Deloitte, Andor Health, Olympus Corporation, GE HealthCare and many more. You can find a complete list of 4,342 companies that use FHIR on TheirStack.com.
FHIR servers facilitate healthcare data exchange between different apps and computer systems. They support data transmission using the FHIR standard, allowing disparate healthcare IT systems and platforms to communicate with one another.
What is an example of a related person in FHIR? ›
Functional relationships are represented in RelatedPerson. role . The directionality of the relationship is from the RelatedPerson to the Patient. For example, if the Patient is a child, and the RelatedPerson is the mother, the relationship would be PRN (parent) or MTH (mother).
What are the disadvantages of FHIR? ›
The disadvantages of FHIR are;
No central index. This lack of centralisation leads to many point to point integrations that are overall harder to maintain (though manageable at smaller scales). No workflow.
Why is FHIR important in healthcare? ›
The FHIR enables patients to more seamlessly interact with healthcare systems and be active in managing their health. This standard makes health data more accessible to patients and makes it easier to integrate systems they directly use.
When to use FHIR? ›
What are the use cases for FHIR interoperability? FHIR is used for personal health records, healthcare document sharing, clinical decision support, public health surveillance, clinical research, and patient engagement.
What is service request in 5g? ›
The Service Request procedure is used by a UE in CM-IDLE state or the 5GC to request the establishment of a secure connection to an AMF. The Service Request procedure is also used both when the UE is in CM-IDLE and in CM-CONNECTED to activate a User Plane connection for an established PDU Session.
What is the difference between an incident request and a service request? ›
Conclusion. In summary, the main difference between an incident and a service request is that an incident is an unplanned event that causes an interruption in service, while a service request is a pre-defined request for assistance or access to an IT service.
What is a service request vs change request? ›
Service requests focus on fulfilling user needs or providing support, while change requests focus on adapting to changing requirements or improving existing solutions.
What is the role of service request? ›
Service Request Requester (SRR)
This is the person who triggers a request via a Service Request (SR) form. This can be identical with a service or customer specific role.