Ordering And Results

Lab Network supports end-to-end electronic laboratory ordering and result retrieval using FHIR R4.

It enables client systems to submit orders, validates orders against configured laboratory compendia, routes them to appropriate laboratory partners, and returns results as standardized FHIR resources for downstream use.

Order Lifecycle Overview

A typical laboratory workflow follows these stages:

1. A client system creates a laboratory order
2. Lab Network validates the order against compendium and configuration rules
3. The order is routed to the appropriate laboratory
4. The laboratory processes the order
5. Results are returned to Lab Network
6. Results are made available through FHIR APIs

Results become available only after the performing laboratory completes processing and delivers them to Lab Network.

Order Submission

Laboratory orders are submitted using FHIR R4 resources. A complete order includes:

• A RequestGroup representing the overall order
• One or more ServiceRequest resources representing individual tests or panels

Each ServiceRequest is included in or referenced by the RequestGroup, allowing multiple tests to be grouped into a single order. Orders must also include references to:

• Patient
• Practitioner (ordering provider)
• Organization (ordering facility)

Optional resources may include:

• Specimen for sample details and collection context
• Supporting clinical data required by the laboratory

All requested tests must align with the selected laboratory’s compendium.

Example Payload

{
  "resourceType": "RequestGroup",
  "status": "active",
  "intent": "order",
  "subject": {
    "reference": "Patient/12345"
  },
  "author": {
    "reference": "Practitioner/67890"
  },
  "action": [
    {
      "resource": {
        "reference": "#test1"
      }
    }
  ],
  "contained": [
    {
      "resourceType": "ServiceRequest",
      "id": "test1",
      "status": "active",
      "intent": "order",
      "code": {
        "coding": [
          {
            "code": "005009",
            "display": "CBC with Differential"
          }
        ],
        "text": "CBC with Differential"
      },
      "subject": {
        "reference": "Patient/12345"
      }
    }
  ]
}

Validation

Before routing, Lab Network validates each order.

Some tests require additional inputs at order time. These inputs must be included in the order or validation will fail.

Validation includes:

• Verifying that requested test codes exist in the configured lab compendium
• Ensuring all required fields, references, and inputs are present
• Confirming the order is compatible with tenant configuration and routing rules

If validation fails, the request is rejected and an OperationOutcome is returned.

Routing

After successful validation, orders are routed to the appropriate laboratory based on:

• Compendium alignment
• Laboratory connectivity
• Tenant configuration
• Routing constraints such as facility, vendor, or workflow requirements

Orders that include tests that cannot be fulfilled by a single laboratory may require separation into multiple orders. Routing occurs through secure, standards-based transport.

Order Status And Tracking

Order status is represented within FHIR resources and reflects lifecycle progression.

Common states include:

• active: Order submitted and in progress
• completed: Results available
• cancelled: Order not fulfilled

Clients can track status by retrieving the RequestGroup resource or subscribing to event notifications.

Result Retrieval

After laboratory processing is complete, results are returned and made available through FHIR R4 APIs.

Structured Results

Structured results are returned as:

• DiagnosticReport: Overall report
• Observation: Discrete result values

These resources support clinical systems, analytics, and downstream workflows.

Unstructured Results

Document-based results are returned as:

• DocumentReference: Metadata and document linkage
• Binary: Downloadable file content such as PDFs or images

A single order may produce structured results, unstructured results, or both.

Result Queries

Common query patterns include:

• GET /fhir/R4/DiagnosticReport?based-on=RequestGroup/{order-id}
• GET /fhir/R4/Observation?based-on=RequestGroup/{order-id}
• GET /fhir/R4/DocumentReference?subject=Patient/{patient-id}&category=laboratory

Example DiagnosticReport Response

{
  "resourceType": "DiagnosticReport",
  "status": "final",
  "subject": {
    "reference": "Patient/12345"
  },
  "result": [
    {
      "reference": "Observation/obs1"
    }
  ]
}

Resource Relationships

Lab Network maintains relationships between resources to preserve clinical context and traceability across the ordering and results lifecycle.

Key relationships include:

• RequestGroup groups one or more ServiceRequest resources representing individual tests
• ServiceRequest.specimen references a Specimen resource with collection details
• DiagnosticReport.basedOn → RequestGroup links the report to the originating order
• DiagnosticReport.result → Observation links the report to discrete result values
• Observation.basedOn → RequestGroup links discrete results to the originating order
• DocumentReference.subject → Patient associates document-based results with the patient

These relationships allow systems to:

• Associate all results with the originating order
• Reconstruct the full order-to-result workflow
• Maintain traceability for audit and reconciliation

Event Notifications

Lab Network supports event-driven workflows using FHIR Subscription.

Subscriptions can be configured to receive notifications for:

• Order status changes
• Result availability

Notifications are delivered when relevant resources are created or updated, allowing systems to retrieve results without polling. Event-driven workflows improve timeliness and reduce unnecessary API requests.

Example Subscription Payload

{
  "resourceType": "Subscription",
  "status": "active",
  "criteria": "DiagnosticReport?status=final",
  "channel": {
    "type": "rest-hook",
    "endpoint": "https://client.example.com/webhook",
    "payload": "application/fhir+json"
  }
}

Workflow Considerations

For reliable implementation:

• Validate test codes against the lab compendium before submission
• Store order identifiers returned at creation time
• Use event-driven subscriptions where possible instead of polling
• Reconcile all returned results with the originating order
• Handle OperationOutcome responses for validation and routing errors

These practices help ensure accurate order processing, efficient result retrieval, and consistent system behavior.

Summary

Laboratory ordering and result retrieval follow a FHIR R4-based workflow.

Orders must conform to compendium and routing requirements, and results are returned as structured and document-based FHIR resources linked to the originating order.

Resource relationships and event-driven notifications support accurate, traceable, and efficient integration across the full lifecycle.