Clinical requirements & serviceability

Call GET /v1/programs/{programId}/requirements for the exact Program, optionally including item_id and region, before constructing an order. The response distinguishes subject fields, ordering-provider requirements, additional order questions and other governed requirements.

• Required and optional questions are explicit; each declares its answer type and, where applicable, allowed values.
• Send only declared question keys. Unknown keys, invalid types and values outside the allowed set are rejected rather than stored as free-form clinical data.
• A facet without configured authority is reported as not configured; it is never inferred from a similarly named field.

• Serviceability — whether the requested item, collection model and region can be fulfilled.
• Clinical eligibility — whether governed clinical policy permits the requested path.
• Provider and order requirements — which subject, provider, consent or question fields must accompany the order.
• Fulfillment — the operational collection and laboratory path after acceptance.

If clinical policy cannot be resolved safely, the system returns a fail-closed manual-review outcome. Sandbox rehearses the same decision semantics with synthetic data; it does not weaken Production rules.

Clinical answers and demographics belong only in governed order fields when the requirements endpoint asks for them. Generic telemetry, webhook metadata and event payloads carry only allow-listed identifiers and coarse states, never clinical answers, analyte values or report documents.