Skip to main content

ADR-0046: Retire Dedicated Requisitions / Referrals Microservice

Status: Accepted
Date: 2026-04-06
Decision Drivers: Platform architecture, reduction of duplicate bounded contexts, alignment with shipped CPOE and document management
Affected Components:

1. Context​

An early module specification described a standalone requisitions-referrals-service owning requisition PDF generation, dispatch (print/fax/email/lab), referral lifecycle, and parallel NATS subjects (clinical.requisitions.*, clinical.referrals.*).

The platform has since matured:

  • CPOE (specs/modules/orders-cpoe/SPEC.md) already models lab, radiology, procedure, and referral as orderType values with clinical.orders.{patientId} events and FHIR ServiceRequest mapping.
  • Document management (specs/modules/document-management/SPEC.md) owns versioned templates, PDF artifacts, and DocumentReference / Binary persistence.
  • No apps/services/requisitions-referrals-service/ implementation exists in the repository.

Maintaining a separate service would duplicate clinical order intent and document lifecycle without adding a distinct deployment boundary.

2. Decision​

Do not implement or schedule a requisitions-referrals-service. Canonical behavior is:

DomainOwner
Lab / imaging / procedure / referral order intent and lifecycleorders (CPOE)
Requisition PDF, branded forms, chart documentsdocument-management
Fax / email of generated documentsmessaging (inputs: documentReferenceId or DMS-signed URL; correlation: orderId)
Referral appointment coordinationscheduling consuming order.* events (see consolidation note for payload extensions)
FHIR ServiceRequest (non-medication)Existing CPOE → fhir-gateway mapping

NATS: Clinical order-related integration SHALL use clinical.orders.> (stream CLINICAL_ORDERS) as the primary subject family. Dedicated clinical.requisitions.> streams for the same business events are not introduced.

Specifications: The folder specs/modules/requisitions-referrals/ is retired; see RETIRED.md. Historical files are preserved under specs/_archive/requisitions-referrals/ for audit.

3. Consequences​

Positive​

  • Single source of truth for “what was ordered” (orders + FHIR ServiceRequest).
  • No parallel state machines or duplicate REST surfaces for lab/referral workflows.
  • Aligns with document-management/INTEROP_MAPPINGS.md §6 (render context uses ServiceRequest without duplicating LIS-owned rows).

Negative / follow-up​

  • Product concepts such as “requisition submitted” or “referral declined” must be mapped to CPOE OrderStatus and typed details JSONB (and optional new order.* event types). This is specified in REQREF_CONSOLIDATION.md and follow-on orders-cpoe spec updates.
  • Dispatch audit and lab handoff events require explicit design in CPOE and/or messaging (see REQREF_RETIREMENT_IMPLEMENTATION_PLAN.md).

4. Compliance​

  • Licensing for these workflows uses ehr.orders, ehr.documents, engage.messaging, and FHIR gateway keys as applicable — not separate REQUISITIONS / REFERRALS product modules unless the licensing catalogue is extended for marketing reasons only (same technical gates).

5. References​