FHIR ServiceRequest Resource: Orders & Referrals

Q: What is the FHIR ServiceRequest resource?

The HL7 FHIR ServiceRequest resource is the standard ordering and referral resource in FHIR R4 used to request diagnostic laboratory tests, radiology studies, surgical or clinical procedures, specialist consultations, and social determinants of health (SDOH) interventions for a patient.

Q: How does FHIR ServiceRequest map to HL7 v2 ORM and ORC/OBR segments?

In HL7 v2 to FHIR R4 translation, an ORM^O01 , OML^O21 , or OMG^O19 order message maps its Common Order ( ORC ) and Observation Request ( OBR ) segments to ServiceRequest : ORC-2/OBR-2 and ORC-3/OBR-3 map to identifier , ORC-4 maps to requisition , OBR-4 maps to code , OBR-5/ORC-7 maps to priority , ORC-9 maps to authoredOn , ORC-12/OBR-16 maps to requester , and OBR-31/DG1 maps to reasonCode and reasonReference .

Q: How is ServiceRequest used for referrals and diagnostic orders?

For diagnostic orders, the EHR creates an active ServiceRequest coded with LOINC or CPT, which the performing lab or imaging center references via DiagnosticReport.basedOn and Observation.basedOn when returning results. For closed-loop referrals (such as specialty eReferrals or HL7 Gravity Project SDOH referrals), the ServiceRequest is paired with a FHIR Task resource ( Task.focus = Reference(ServiceRequest) ) that tracks whether the receiving provider has received, accepted, scheduled, or completed the referral.

The FHIR ServiceRequest resource (ServiceRequest in HL7 FHIR R4, replacing the STU3 ProcedureRequest and ReferralRequest resources) is the universal clinical order and referral resource used to request any non-medication diagnostic test, laboratory panel, medical imaging study, surgical or bedside procedure, specialist consultation, nursing intervention, or social determinants of health (SDOH) community service.

Within the HL7 FHIR Workflow architecture, ServiceRequest embodies the Request pattern: it bridges definitional protocols (clinical order sets represented by PlanDefinition and ActivityDefinition) and completed clinical events (FHIR Procedure, DiagnosticReport, and FHIR Observation).

What Is the FHIR ServiceRequest Resource?

When clinical integration engineers evaluate what is the FHIR ServiceRequest resource, they examine how FHIR R4 unified previously fragmented ordering resources into a single, general-purpose fhir order resource (excluding medications, which use MedicationRequest; diets, which use NutritionOrder; and durable medical equipment, which uses DeviceRequest):

Definitional Layer                   Request Layer (The Order)              Event Layer (The Result / Act)
------------------                   -------------------------              ------------------------------
PlanDefinition / ActivityDefinition  ===instantiatesCanonical===> ServiceRequest <===basedOn=== Procedure
                                                                  ServiceRequest <===basedOn=== DiagnosticReport / Observation

Lifecycle Status (ServiceRequest.status, 1..1): Tracks the operational state of the order using the required value set draft | active | on-hold | revoked | completed | entered-in-error | unknown.
Order Intent (ServiceRequest.intent, 1..1): Differentiates clinical authority and workflow stage: proposal (a suggestion from a CDS engine or non-ordering staff), plan (an item inside a CarePlan not yet authorized for execution), order (an authorized clinician order ready for fulfillment), original-order, reflex-order (an automated laboratory add-on triggered by an abnormal screening result), or filler-order.
Priority & Timing (priority & occurrence[x]): Specifies urgency (routine | urgent | asap | stat), scheduled timing (occurrenceDateTime, occurrencePeriod, or occurrenceTiming), and conditional PRN triggers (asNeededBoolean or asNeededCodeableConcept).
Negative Orders (doNotPerform): A boolean modifier (0..1) that inverts the semantics of the request—used to record explicit orders not to perform an intervention (such as “Do not perform venipuncture in right arm” or “Do not intubate”).

How Does FHIR ServiceRequest Map to HL7 v2 ORM and ORC/OBR Segments?

In hospital interface engines translating HL7 v2 order messages—specifically ORM^O01 (General Order Message), OML^O21 (Laboratory Order), and OMG^O19 (General Clinical Order)—into FHIR R4, the Common Order (ORC) and HL7 OBR segment (Observation Request) fields map directly to ServiceRequest elements:

FHIR R4 `ServiceRequest` Element	Cardinality	Data Type & Terminology Binding	HL7 v2 `ORC` / `OBR` Segment Mapping
`identifier`	`0..*`	`Identifier` (`PLAC` Placer / `FILL` Filler ID)	`ORC-2` / `OBR-2` (Placer Order #) & `ORC-3` / `OBR-3` (Filler Order #)
`requisition`	`0..1`	`Identifier` (Shared group/requisition number)	`ORC-4` (Placer Group Number — groups multiple lab panels on one requisition)
`status`	`1..1`	`code` (`active`, `on-hold`, `revoked`, `completed`)	`ORC-1` (Order Control: `NW`, `HD`, `CA`, `DC`) & `ORC-5` (Order Status)
`priority`	`0..1`	`code` (`routine \| urgent \| asap \| stat`)	`ORC-7.6` / `OBR-5` / `OBR-27.6` (Priority: `R`, `S`, `A`, `T`)
`category`	`0..*`	`CodeableConcept` (SNOMED CT high-level domain)	Derived from message type (`OML` = Lab, `OMG` = Imaging/Clinical) or `OBR-24`
`code`	`0..1` (`1..1` US Core)	`CodeableConcept` (LOINC, SNOMED CT, CPT/HCPCS)	`OBR-4` (Universal Service Identifier)
`authoredOn`	`0..1`	`dateTime` (When order was signed)	`ORC-9` (Date/Time of Transaction)
`requester`	`0..1`	`Reference(Practitioner \| PractitionerRole \| Organization)`	`ORC-12` / `OBR-16` (Ordering Provider)
`reasonCode` / `reasonReference`	`0..*`	`CodeableConcept \| Reference(Condition \| Observation)`	`ORC-16` / `OBR-31` (Reason for Study) & associated `DG1` segments
`specimen`	`0..*`	`Reference(Specimen)`	`SPM` segment (or legacy `OBR-15` Specimen Source)

How Is ServiceRequest Used for Referrals and Diagnostic Orders?

Examining how is ServiceRequest used for referrals and diagnostic orders highlights how FHIR separates the clinical authorization (ServiceRequest) from the operational fulfillment state machine (Task):

1. Closed-Loop Referrals and SDOH Interventions (`ServiceRequest` + `Task`)

When a primary care clinician places a referral to a cardiologist, a behavioral health clinic, or a community-based Social Determinants of Health (SDOH) organization (under the HL7 Gravity Project or BSeR [Bidirectional Services eReferrals] Implementation Guides), ServiceRequest.status only tracks whether the ordering clinician’s request is active, revoked, or completed. It does not track whether the receiving specialist has reviewed, accepted, waitlisted, or rejected the referral. Instead, FHIR pairs the ServiceRequest with a FHIR Task resource:

`Task.focus` (`Reference(ServiceRequest)`): Points to the clinical referral order.
`Task.owner` (`Reference(PractitionerRole | Organization)`): Identifies the receiving specialist or community organization responsible for fulfilling the referral.
`Task.status`: Tracks the granular operational workflow across organizational boundaries: requested -> received -> accepted (or rejected) -> in-progress -> completed.
`Task.output`: Links the completed consultation note (DocumentReference) or procedure report (Procedure / DiagnosticReport) back to the referring EHR to close the referral loop.

2. US Core STU 6.1.0 ServiceRequest Profile Requirements

Starting in US Core FHIR STU 6.1.0 (aligned with ONC HTI-1 and USCDI v3), certified EHRs must support the US Core ServiceRequest Profile (http://hl7.org/fhir/us/core/StructureDefinition/us-core-servicerequest) across laboratory orders, diagnostic imaging orders, clinical procedure orders, and SDOH referrals:

Mandatory Elements (`1..1`): status, intent, category (sliced to support US Core categories including Laboratory procedure 108252007, Imaging 363679005, Surgical procedure 387713003, Counseling 409063005, and SDOH categories), code (bound to LOINC, SNOMED CT, CPT, or HCPCS), and subject (Reference(USCorePatientProfile)).
MustSupport Clinical Context: Certified servers must populate and support search parameters on authoredOn, occurrence[x], requester, and reasonCode / reasonReference so client applications can audit medical necessity and order turnaround times.

Frequently Asked Questions

What is the FHIR ServiceRequest resource?

The HL7 FHIR ServiceRequest resource is the standard ordering and referral resource in FHIR R4 used to request diagnostic laboratory tests, radiology studies, surgical or clinical procedures, specialist consultations, and social determinants of health (SDOH) interventions for a patient.

How does FHIR ServiceRequest map to HL7 v2 ORM and ORC/OBR segments?

In HL7 v2 to FHIR R4 translation, an ORM^O01, OML^O21, or OMG^O19 order message maps its Common Order (ORC) and Observation Request (OBR) segments to ServiceRequest: ORC-2/OBR-2 and ORC-3/OBR-3 map to identifier, ORC-4 maps to requisition, OBR-4 maps to code, OBR-5/ORC-7 maps to priority, ORC-9 maps to authoredOn, ORC-12/OBR-16 maps to requester, and OBR-31/DG1 maps to reasonCode and reasonReference.

How is ServiceRequest used for referrals and diagnostic orders?

For diagnostic orders, the EHR creates an active ServiceRequest coded with LOINC or CPT, which the performing lab or imaging center references via DiagnosticReport.basedOn and Observation.basedOn when returning results. For closed-loop referrals (such as specialty eReferrals or HL7 Gravity Project SDOH referrals), the ServiceRequest is paired with a FHIR Task resource (Task.focus = Reference(ServiceRequest)) that tracks whether the receiving provider has received, accepted, scheduled, or completed the referral.

HL7 FHIR ServiceRequest Resource: Diagnostic Orders, Referrals, and HL7 v2 ORC/OBR Mapping