Search
K
< Back

Requisition API

The Requisition API enables you to electronically submit diagnostic lab orders, track their status, and link resulting data to the original request. Each requisition acts as a structured FHIR resource that captures ordering context, requested tests, and associated patient and provider information.

This API is central to diagnostic workflows in the Lab Network. It ensures that orders are transmitted with all required details, routed to the appropriate lab, and traceable throughout the fulfillment process.

Resource Overview

supports both FHIR R4 and STU3. In R4, lab orders are submitted using the ServiceRequest resource. In STU3, the Requisition resource is used.

Each requisition includes:

  • Patient identity and demographics
  • Ordering Practitioner and submitting Organization
  • Requested tests (coded from the lab compendium)
  • Clinical context such as reasonCode, priority, and supportingInfo
  • Order status, timestamps, and routing metadata

Each order is versioned and uniquely identifiable. The API supports creation, retrieval, and status tracking using FHIR RESTful operations.

Supported Methods

MethodEndpointDescription
POST/fhir/R4/ServiceRequestSubmit a new lab order using FHIR R4
POST/fhir/STU3/RequisitionSubmit a new lab order using STU3 (legacy support)
GET/fhir/{version}/ServiceRequest/{id}Retrieve an existing order and check current status
GET/fhir/{version}/ServiceRequest?patient={id}Search for orders by patient
GET/fhir/{version}/Observation?based-on=ServiceRequest/{id}Retrieve structured results linked to the requisition
GET/fhir/{version}/DocumentReference?based-on=ServiceRequest/{id}Retrieve unstructured results linked to the requisition

Key Fields

Important fields in the ServiceRequest (R4) or Requisition (STU3) resource include:

  • subject: Reference to the patient
  • requester: Ordering practitioner
  • performer: Laboratory that will perform the test (if known)
  • identifier: Unique requisition identifier
  • status: Current state of the order (e.g., active, completed, cancelled)
  • code: Test codes from the compendium
  • reasonCode or reasonReference: Clinical justification for the order
  • supportingInfo: Related resources such as Conditions or Observations

All fields must comply with the FHIR version in use. CodeableConcept values should use LOINC, SNOMED CT, or lab-specific code systems where appropriate.

Order Lifecycle

Each requisition progresses through a defined set of lifecycle states.

  • Created: Order has been submitted
  • Validated: Order is confirmed to match the selected lab’s compendium
  • Routed: Order has been transmitted to the lab
  • In-progress: Lab is processing the order
  • Completed: Results are available and linked to the requisition
  • Rejected: Order was declined due to invalid data or unsupported test

Status updates can be retrieved via API or received via webhook.

Linking Results

Returned results are linked back to the originating requisition using references:

  • Observation.basedOn → ServiceRequest (R4) or Requisition (STU3)
  • DiagnosticReport.basedOn → Requisition
  • DocumentReference.context.related → Requisition

This linkage allows your system to associate each result with its originating order and to reconcile pending, fulfilled, or rejected orders.

Summary

The Requisition API provides a structured way to submit, track, and manage lab orders using FHIR resources. FHIR R4 is recommended for all new implementations using the ServiceRequest resource, but FHIR STU3 remains supported using Requisition. Each requisition serves as the foundation for downstream routing and result correlation. Use the API to maintain full visibility into order status and ensure accurate linkage between tests and outcomes.