The short answer
HL7’s AI Transparency on FHIR implementation guide gives a standard way to show that a FHIR resource was created, updated or otherwise influenced by AI. It works at three levels: a security label on the resource or on specific elements, an AI Provenance record of the model, inputs and outputs, and an AI Device describing the AI system, optionally with a model card.12 When we checked on 27 October 2026, the latest version was 1.0.0-ballot, the first STU ballot (January 2026), and no official version had been published.1 It’s about observability, telling downstream users that AI was involved, and explicitly not about endorsing or validating the AI or its output.1
Deedglass
The server said “saved”. Deedglass looked.
Deedglass reads it back
Status and scope
| Item | Value |
|---|---|
| Version | 1.0.0-ballot, STU 1 Ballot 11 |
| Base | FHIR R4 (usable with R4B)1 |
| Status | Trial use, maturity level 2; no official version yet1 |
| Purpose | Observability of AI algorithms that produce or manipulate health data1 |
| Not its purpose | Endorsing, validating or invalidating AI or its data; setting governance1 |
| Not yet supported | HL7 CDA and HL7 v21 |
The guide defines “AI algorithm” broadly: any computer-based logic that touches health data in a way that might change how it’s understood downstream, from note summarisers and image interpreters to concept extraction and synthetic data generators.1
Three levels of marking
| Level | How | Answers |
|---|---|---|
| Tag | A code in meta.security saying AI was involved; inline labels on specific elements |
Was AI involved in this resource or this field? |
| AI Provenance | A Provenance record of the AI model’s use, its input data and its output | Which model, given what, produced what? |
| AI Device | A Device representing the AI system, with kind and optional model card | What is this AI system? |
Sources:2. The levels build on each other. A tag is cheap and lets a consumer filter or flag AI-touched data. Provenance links the resource to the generating activity; FHIR R4 Provenance already tracks the activity that created, revised or signed a version of a resource.3 The Device gives the model an identity that many Provenance records can point to.
One example in the guide tags a DiagnosticReport’s conclusion and conclusion code with an AI-asserted security label (AIAST), leaving the rest of the report unlabelled.2 That element-level granularity matters: often only one field was AI-generated.
The profiles
The artifacts page lists four resource profiles:2
- AI Provenance: a record of an AI model’s use in generating or enhancing FHIR resources, with the model, the input data and the output.
- AI Device: a Device for an AI system such as an LLM, with recommended
Device.typecodes, anAIKindextension for the specific kind of AI technology, and aModelCardDescriptionextension to reference a model card. - AI Model-Card DocumentReference: a DocumentReference holding a model card.
- AI Data: the input and output data used by an AI model (a DomainResource profile used for validation).
Examples include lab results and a procedure created by an AI system and verified by a human.2
A worked example
An AI tool drafts the interpretation of a lab panel; a pathologist reviews and signs.
Code What the screen or file shows, copied as is.
DiagnosticReport/dr-88
meta.security: AI involved (guide's provenance code)
conclusion ← inline label AIAST (AI-asserted)
Provenance (AI Provenance profile)
target: DiagnosticReport/dr-88/_history/1
agent: Device/lab-llm (AI Device, model card attached)
entity: input = Observations used; output = draft conclusion
Provenance (signature by the pathologist)
target: DiagnosticReport/dr-88/_history/2
agent: Practitioner/dr-sen, role: verifier
A consumer seeing the report can tell that the conclusion was AI-asserted, which model produced the draft, from what inputs, and that a named person verified version 2. That’s the transparency the guide aims for.
What the guide doesn’t cover
By its own scope, the guide doesn’t validate AI output or set governance.1 For teams using AI agents that write to records, a few questions stay open:
| Question | Covered by the guide? |
|---|---|
| Was AI involved, and which model? | Yes2 |
| What inputs and outputs? | Yes, via AI Provenance and AI Data2 |
| What rule allowed the write, and was it held for a person? | No |
| Who approved, before the write? | Via ordinary Provenance agents, not a dedicated structure |
| Did the server store what the AI produced? | No |
| Can a third party check the record wasn’t altered? | Not specified |
Those gaps are where action-level records come in. Our open draft, AAP-H, profiles Provenance and AuditEvent with a signed envelope recording the rule decision, approver, the agent’s claim and what the system shows afterwards.4 It’s a v0.1 draft for comment, not an HL7 publication.4 And like any signed record, a valid one shows the values weren’t changed, not that the AI was right.4
The two fit together: AI Transparency marks the data; an action record explains the write.
What to do now
- Start tagging. Even before the guide is final, a
meta.securitycode for AI involvement is cheap and useful. Use the guide’s codes so you don’t need to migrate later.2 - Give each AI system a Device with a stable identity and, where you can, a model card.2
- Record Provenance per version, so you can tell the AI draft from the human-verified version.
- Comment on the ballot if you implement it; that’s what ballots are for.
- Add action records for writes agents make, with the rule decision and a read-back.
Questions people ask
Is AI Transparency on FHIR an official standard?
Not as of our 27 October 2026 check. It was at 1.0.0-ballot, the first STU ballot, with no official version published.1
Does tagging data as AI-generated make it safe?
No. The guide is about observability; it explicitly doesn’t validate AI output.1
Does it support HL7 v2?
Not yet; it assumes data is in FHIR.1
See how AI writes can be held, checked and recorded on our healthcare page, with the record format in the AAP-H spec and evidence on server behaviour in the FHIR write integrity study. 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.