Skip to main content

Overview

ServiceRequest is a record of a request for a procedure or diagnostic or other service to be planned, proposed, or performed, as distinguished by the ServiceRequest.intent field value, with or on a patient. The procedure will lead to either 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 Example Usage Scenarios: The following are example usage scenarios for the this profile: Query for a specific procedure or test request such as an electrocardiogram (ECG) order or a referral to a support program.
Query for a specific service offered to a patient such as a referral to a support program.
Query for category of service request (e.g. all cardiology requests)
Each Service Request has next elements:
  • a status
  • an intent code indicating whether the request is a proposal, plan, or order.
  • a code defining what is being requested
  • a patient

Profile specific implementation guidance

  • The ServiceRequest.category binding Must Support, at a minimum, the US Core ServiceRequest Category Codes. However, this valueset can be treated as extensible, and other category codes can be used instead.
  • The ServiceRequest.code valueset is broad to accommodate a wide variety of use cases andSHOULDbe constrained to a subset for a particular use case or domain. (for example, LOINC for laboratory orders.)
  • The ServiceRequest resource can communicate the reason or indication for referral or consultation using either a code in ServiceRequest.reasonCode or a reference using ServiceRequest.reasonReference.
    • As documented here, when using ServiceRequest.reasonReference, the referenced resources SHOULD be a US Core Profile.
  • See the Screening and Assessments guidance page for more information when exchanging Social Determinants of Health (SDOH) Service Requests.
This resource conforms to USCDI V3 profile for Procedure - refer to StructureDefinition US Core ServiceRequest. ServiceRequest response will be provided in JSON (refers to Capability Statement) format as per FHIR standard R4 version.

Must support elements, mandatory and optional search parameters

ServiceRequestmust support these elements:
  • status
  • intent
  • category
    • category:us-core
  • code
  • subject
  • occurrence[x]
  • authoredOn
  • requester
The following search parameters and search parameter combinations SHALL be supported: The syntax used to describe the interactions is described here. SHALL support both read ServiceRequest by id AND ServiceRequest search using the _id search parameter: GET [base url]/ServiceRequest/[id] or GET [base url]/ServiceRequest?_id=[id] SHALL support searching for all ServiceRequest for a patient using the patient search parameter: GET [base url]/ServiceRequest?patient={Type/}[id] SHALL support searching using the combination of the patient and category search parameters: GET [base url]/ServiceRequest?patient={Type/}[id]&category={system|}[code] SHALL support searching using the combination of the patient and code search parameters:
  • including optional support for OR search on code GET [base url]/ServiceRequest?patient={Type/}[id]&code={system|}[code]
SHALL support searching using the combination of the patient and category and authored search parameters:
  • including support for these authored comparators: gt,lt,ge,le
  • including optional support for AND search on authored GET [base url]/ServiceRequest?patient={Type/}[id]&category={system|}[code]&authored=[date]
The following search parameter combinations SHOULD be supported (optional): SHOULD support searching using the combination of the patient and status search parameters:
  • including support for OR search on status GET [base]/ServiceRequest?patient={Type/}[id]&status={system|}[code]{,{system|}[code],...}
SHOULD support searching using the combination of the patient and code and authored search parameters:
  • iincluding optional support for OR search on code
  • including support for these authored comparators: gt,lt,ge,le
  • including optional support for AND search on authored GET [base]/ServiceRequest?patient={Type/}[id]&code={system|}[code]{,{system|}[code],...}&authored={gt|lt|ge|le}[date]{&authored={gt|lt|ge|le}[date]&...}
The response to any search operation is always a list of resources in a Bundle or an Operation Outcome.

ServiceRequest By Patient Id

Search for ServiceRequest by patient. METHOD GET
PARAMS [base url] - FHIR base url [id] - Id for the Patient HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:

ServiceRequest By Id

Get ServiceRequest by ID. METHOD GET
or
PARAMS [base url] - FHIR base url {id} - Id for ServiceRequest resource HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:
Implementation Notes: This search allows searching by the logical id of the ServiceRequest resource using either the direct read operation or the _id search parameter.

ServiceRequest by patient and category

Get ServiceRequests for the specified patient and category METHOD GET
PARAMS [base url] - FHIR base url [id] - patient id {system|} - an identity of the terminology system used to specify the category of service request. FHIR search token parameter. See Search specification for more information. {code} - a code specifying the category of service request (e.g., laboratory, imaging, consult) HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:

ServiceRequest by patient and code

Get ServiceRequests for the specified patient and service code METHOD GET
PARAMS [base url] - FHIR base url [id] - patient id {system|} - an identity of the terminology system used to specify the requested service. FHIR search token parameter. See Search specification for more information. {code} - a code identifying the requested service HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:

ServiceRequest by patient and status

Get ServiceRequest by patient id and request status METHOD GET
PARAMS [base url] - FHIR base url [id] - a patient id {system|} - an identity of the terminology system used to specify the status of the service request. FHIR search token parameter. See Search specification for more information. {code} - a code specifying the status of the service request (e.g., draft, active, completed, cancelled) HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:

ServiceRequest by patient, category, and authored date

Fetches a bundle of all ServiceRequest resources for the specified patient, category, and authored date METHOD GET
PARAMS [base url] - FHIR base url [id] - patient id {system|} - an identity of the terminology system used to specify the category of service request. FHIR search token parameter. See Search specification for more information. {code} - a code specifying the category of service request [date] - the date when the service request was authored HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE:

ServiceRequest by patient, code and authored date

Get ServiceRequests for the specified patient, code and authored date METHOD GET
PARAMS [base url] - FHIR base url [id] - patient id {system|} - an identity of the terminology system used to specify the requested service. FHIR search token parameter. See Search specification for more information. [code] - a code identifying the requested service [date] - the date when the service request was authored HEADERS The Authorization token SHALL be obtained during the Authentication and Authorization process. Go to Authentication and Authorization for further details. RESPONSES EXAMPLE: