Patient & Order Identification

What it is, why it exists, and how the workflow editor exposes it. Scope: hospital-level deployments (OPD + IPD + ED + OR + ICU + L&D + Blood Bank + Lab + Imaging + Pharmacy).

Why this exists

A hospital workflow is a chain of stations (registration → encounter → wards → orders → results → billing). Every station that handles a patient or an order has to identify what’s in front of it — by reading a wristband, scanning a sticker, or pulling up a record from a QR/MRN/HN. Today the workflow editor lets a designer wire up the what happens (form, command, API), but not the what gets handed off (label printed, QR rendered, deeplink generated).

This series documents the identification artifact layer that was added on claude/add-patient-id-options-8UsIY:

• The configuration contract that lives on a workflow node (data.identification).
• The UI that surfaces it in the node panel (the Identification & Printables section).
• Coverage of which hospital-level node types do / don’t yet expose it (sanity check).
• The runtime contract — what services need to consume data.identification to actually print/render at runtime.
• Region-pack deltas (Japan / Philippines / Thailand / Bizbox migration).

The contract

web/src/common/components/medical/builder/main-flow-editor/components/workflow/nodes/_base/components/identification-options/types.ts

export type IdentificationConfig = {
  patient?: {
    printables?: PatientPrintableKind[]   // 'wristband' | 'idSticker' | 'registrationReceipt' | 'visitSummaryCard'
    digital?: PatientDigitalKind[]        // 'patientQrCard' | 'encounterQrPass' | 'shortUrlDeeplink'
  }
  order?: {
    printables?: OrderPrintableKind[]     // 'orderLabel' | 'specimenLabel' | 'requisitionSlip' | 'pharmacyDispenseLabel'
    digital?: OrderDigitalKind[]          // 'orderBarcode1d' | 'orderQr' | 'fhirDeeplink'
  }
  trigger?: 'manual' | 'on-enter' | 'on-complete' | 'on-order-create'
  printTemplateKey?: string               // e.g. 'wristband.ipd.v1'
  printerTarget?: string                  // e.g. 'ZD420-OPD-01'
  qrPayloadKind?: 'patient-id' | 'mrn' | 'encounter-id' | 'order-id' | 'fhir-bundle' | 'short-url'
}

Persisted on the node via handleNodeDataUpdateWithSyncDraft({ id, data: { identification } }). It rides through the existing workflow draft → workflow_template save path. No new tables, no new endpoints — this is design-time intent that the runtime reads.

The UI

web/src/common/components/medical/builder/main-flow-editor/components/workflow/nodes/_base/components/identification-options/index.tsx

A collapsible Tailwind card titled Identification & Printables rendered inside the Settings tab of any node panel that opts in. Three modes:

Mode	Sections	Use for
patient	Patient printables + digital	Registration, admission, transfer, discharge nodes
order	Order printables + digital	Lab/imaging/medication/blood-bank order nodes
both	All four	Intake (issues both a wristband and routine intake order labels), generic decision nodes

The summary line on the collapsed header shows live counts (patient: 2 · order: 3) so the designer can see the configuration without expanding.

Where it’s wired today

Panel file	Mode	Reach (BlockEnums)
nodes/register/panel.tsx	patient	Register
nodes/create-visit/panel.tsx	patient	CreateVisit
nodes/patient-intake/panel.tsx	both	PatientIntake, WaitCheckIn, CheckIn
nodes/hospital-checkin/panel.tsx	patient	PatientAdmission, IPDPendingBed, IPDReadyToAdmit, WaitAcknowledgement
nodes/_generic-medical/panel.tsx	auto (regex on nodeType)	~200 BlockEnums incl. LabOrder, ImagingOrder, MedicationOrder, RadiologyOrder, BloodBankRequest, all Pathology*, all Wellness*, all ICU*, all ED* extended, all LD*, all Nutrition*, etc.

This covers the whole patient-flow spine as long as the bespoke panel is the entry point or the node falls back to GenericMedicalPanel.

Where it isn’t (yet)

There are 30+ bespoke hospital panels that still don’t expose the section. Some matter — HospitalLabWorkPanel, HospitalPharmacyPanel, IPDMedicationAdministrationPanel, the seven EMAR* panels — others are either non-clinical (revenue cycle) or already covered by an upstream node. Full breakdown in 01-coverage-matrix.md.

Documents in this series

1. 00-overview.md — this file
2. 01-coverage-matrix.md — every hospital BlockEnum, current panel, ID status, gap severity
3. 02-patient-flow.md — patient identity lifecycle (registration → discharge) with artifact handoffs
4. 03-order-flow.md — order identity lifecycle (placement → result → billing) per modality
5. 04-runtime-contract.md — what the runtime needs to do with data.identification (print/QR dispatch, FHIR deeplinks)
6. 05-region-deployment-notes.md — Japan / Philippines / Thailand / Bizbox specifics