AI-drafted orders and clinician sign-off: modelling it in FHIR R4

The short answer

Picture an AI tool drafting a medication order that another system treats as ready before the doctor has seen it. The fix is in how the order is stored: as an unsigned draft that nothing acts on. Only the clinician’s own sign-off should turn it into a real order, with their name and the time recorded.

To keep an AI-drafted order from being acted on before a clinician signs it, write it in FHIR R4 with status: draft and intent: proposal. In R4, draft means the request “has been created but is not yet complete or ready for action”¹, and a proposal is a suggestion with no authority to act.² Only the clinician’s own action should change it to active with intent: order, with the clinician as requester.³ Then record who signed, when, and what they saw. This post is about records and workflow, not about which orders are clinically right.

Why this is a live question

AI tools are moving from drafting notes to queuing orders. Epic says its AI Charting, released in February 2026, “drafts the clinician’s note, and queues up orders”.⁴ Microsoft says of Dragon Copilot: “With supported EHRs, orders are directly entered into the EHR order module”.⁵

Inside one EHR, the vendor’s own order workflow handles the sign-off. The question gets harder when a third-party agent writes through FHIR. Epic’s public sandbox capability statement, for example, lists create and update for ServiceRequest but only read and search for MedicationRequest, and each customer’s configuration may differ.⁶ So what an agent can write varies by site, and the safe pattern has to work with whatever the server allows.

The three fields that matter

Two details from R4 make this work. First, in MedicationRequest both status and intent are modifier elements: they change the meaning of everything else in the resource.³ A system that ignores them is misreading the resource, so a draft proposal is clearly not an order to any conformant reader.

Second, requester is “the individual, organization, or device that initiated the request and has responsibility for its activation”, and recorder is the person who entered it on someone else’s behalf, as with a verbal or telephone order.³ Responsibility for activation belongs to a person. An AI tool can draft; it shouldn’t be the requester of an active order.

ServiceRequest and other request resources follow the same request pattern; MedicationRequest has its own status list, which still includes draft.³

A worked example

The agent drafts a lab order after a visit. It writes:

Code Data in JSON, the format software uses to pass records and settings.

{
  "resourceType": "ServiceRequest",
  "status": "draft",
  "intent": "proposal",
  "subject": { "reference": "Patient/p-12" },
  "code": { "text": "Lipid panel" },
  "note": [{ "text": "Drafted by AI assistant from visit note; not reviewed." }]
}

The clinician opens the draft, checks it against the visit, and signs. The signing action, made by the clinician in the EHR’s own interface, not by the agent, produces:

Code Data in JSON, the format software uses to pass records and settings.

{
  "resourceType": "ServiceRequest",
  "status": "active",
  "intent": "order",
  "requester": { "reference": "Practitioner/dr-rao" },
  "authoredOn": "2026-10-27T10:42:00+05:30"
}

The agent’s credentials should be able to create the first and never the second. If the agent can set status: active or name a practitioner as requester itself, the sign-off is a convention, not a control.

What the sign-off record should hold

The order resource shows the end state. It doesn’t show who drafted it, what changed between draft and signature, or whether the clinician looked at it. Keep a separate record. FHIR R4 Provenance exists for this: it tracks the activity that created, revised or signed a version of a resource.⁷

A useful sign-off record holds:

1. The draft version, as the agent wrote it, and the tool and model that wrote it.
2. The signed version, and the differences between the two.
3. The clinician who signed, the time, and how they authenticated.
4. What the clinician was shown when they signed.
5. A read-back of the stored order after activation, confirming it matches what was signed.

Our open draft for this, AAP-H, records which agent acted, what the rules decided, who approved, what the agent claimed and what the system of record shows afterwards, as FHIR R4 Provenance and AuditEvent profiles plus a JSON envelope.⁹ The spec page has examples.

Failure modes to design against

The rubber-stamp row deserves attention. People over-trust automated suggestions when checking is hard; our post on automation bias in health IT summarises the research. A design that makes signing faster than reading invites it.

A checklist

• Agents write requests only as status: draft, intent: proposal.¹²
• Only a clinician action sets active and order, with the clinician as requester.³
• The agent’s credentials can’t set active, order, or a practitioner requester.
• Every consumer of orders is tested to ignore drafts.
• Provenance is kept for the draft and the signature.⁷
• The stored order is read back after activation.
• Time-to-sign is measured, and very fast sign-offs are reviewed.

Questions people ask

Should an AI-drafted order use status draft or on-hold?

Draft. R4 defines draft as created but not ready for action¹; on-hold is for a request whose authorisation has been temporarily withdrawn.

Can a Device be the requester?

R4 allows a Device as requester³, but for an active order the responsible party should be the signing clinician.

Is this enough to make AI orders safe?

No. It makes sure nothing is acted on without a person’s signature and that the signature is recorded. Whether the order is clinically right is the clinician’s judgement.

To see a high-risk order held for a clinician in a sandbox, run npx deedglass health pilot; one of its four scenes does exactly that.⁸ The healthcare overview has more. To try approvals and read-backs on a real database in your browser, open the playground; to grade what an agent can reach on your own machine, run npx deedglass scan (the grade, explained).

Written with AI assistance and checked against our claims register.