RequestOrchestration — Request orchestration
The R4 RequestGroup successor: a group of clinical requests linked by conditions, timing dependencies and alternatives. The core of CDS Hooks and executed PlanDefinitions.
Purpose
RequestOrchestration groups multiple Request-family resources (MedicationRequest, ServiceRequest, NutritionOrder, Task, etc.) with their relationships: temporal ordering, applicability conditions, exclusive alternatives. It is typically produced by applying a PlanDefinition (protocol) through a CDS (Clinical Decision Support) engine.
Typical use case: a post-operative protocol generated automatically at discharge from a procedure: analgesia, day-1 labs, day-30 follow-up. Each sub-action can condition or follow another.
Key fields
| Field | Type | Cardinality | Role |
|---|---|---|---|
status | code | 1..1 | Mandatory. draft, active, on-hold, revoked, completed, entered-in-error, unknown. |
intent | code | 1..1 | Mandatory. proposal, plan, directive, order, original-order, reflex-order, filler-order, instance-order, option. |
priority | code | 0..1 | routine, urgent, asap, stat. |
code | CodeableConcept | 0..1 | Orchestration type. |
subject | Reference(Patient | Group) | 0..1 | Beneficiary. |
encounter | Reference(Encounter) | 0..1 | Context. |
authoredOn | dateTime | 0..1 | Creation date. |
author | Reference(Device | Practitioner | PractitionerRole) | 0..1 | Author. |
instantiatesCanonical | canonical(PlanDefinition)[] | 0..* | Instantiated protocol. |
basedOn | Reference(Any)[] | 0..* | Parent requests. |
action | BackboneElement[] | 0..* | Actions composing the orchestration. |
Actions, conditions, relations
Each action can carry a target resource (MedicationRequest,
ServiceRequest, Task…) or be a grouping node (recursive action.action[]).
The condition[] elements define when the action applies (CQL or FHIRPath).
The relatedAction[] elements define temporal dependencies
(before-start, after-end, concurrent) with offsets.
JSON example
Post-op protocol with systematic analgesia and conditional lab workup:
{
"resourceType": "RequestOrchestration",
"id": "post-op-protocol-001",
"status": "active",
"intent": "order",
"priority": "routine",
"subject": { "reference": "Patient/doe-john" },
"encounter": { "reference": "Encounter/enc-postop-001" },
"authoredOn": "2026-05-15T14:00:00+02:00",
"author": { "reference": "Practitioner/dr-smith" },
"action": [
{
"title": "Post-op analgesia",
"description": "Paracetamol 1g PO every 6h for 48h",
"timingTiming": {
"repeat": { "frequency": 4, "period": 24, "periodUnit": "h", "duration": 48 }
},
"resource": { "reference": "MedicationRequest/mr-paracetamol-001" }
},
{
"title": "Day-1 lab workup",
"condition": [{
"kind": "applicability",
"expression": { "language": "text/cql", "expression": "PatientHasDiabetes" }
}],
"relatedAction": [{
"targetId": "lab-day-1",
"relationship": "after-end",
"offsetDuration": { "value": 24, "unit": "h" }
}],
"resource": { "reference": "ServiceRequest/sr-cbc-d1" }
}
]
}Common pitfalls
- Migration from R4 RequestGroup — the resourceType has changed. Old R4 RequestGroup must be transformed or back-ported.
- CQL conditions not evaluable — without an embedded CQL engine,
conditionare dead descriptions. Prefer FHIRPath for portability. - Cycles in
relatedAction— A after B and B after A = infinite loop. The execution engine must validate the DAG. - Confusing with Task — RequestOrchestration is static (the order), Task is dynamic (the execution).
- Target resources not created —
action.resourcemust point to an existing resource; otherwise the orchestration is broken.
Related resources
- PlanDefinition — the abstract protocol instantiated.
- Task — operational execution of actions.
- CarePlan — long-term patient view.
- MedicationRequest, ServiceRequest — typical targets.