AI Transparency on FHIR walkthrough — meta.security labels, Provenance, and a live German ambulatory rollout — Aug 6, 2026
CI build: build.fhir.org/ig/HL7/aitransparency-ig/branches/main/en/
Scope of the IG — transparency without judgment
John Moehrke (security co-chair on the project, and one of the EHR Work Group's regulars) walked through the current CI-build version of the AI Transparency on FHIR IG, which is in ballot reconciliation with the normative content largely unchanged from the ballot. The framing was deliberate up front: the IG is not a position on whether AI in healthcare is good, bad, risky, or appropriate. It is purely a mechanism for making AI use observable.
The IG's sole purpose is transparency of AI's use. It doesn't take a position on how wonderful AI is or how horrible AI is, or where it's appropriate to use.
The concrete use cases are prosaic: mark data that was influenced by AI so it can be told apart from purely human-authored data, record which AI system and prompt produced it, and — critically — enable retrospective discovery when a model or a prompt is later found to be problematic, so downstream data can be triaged. A fifth use case covers PDF-to-FHIR extraction; the IG describes how to record the extraction happened, not how to do it. Nikolai raised a related pattern from a previous meetup — a team storing span-level source references directly on extracted resources — and Sam Schifman flagged where those extensions actually belong:
Those extensions belong on Provenance, not directly on the resource — otherwise you're just adding a lot of bloat to the resource that may or may not be useful to consumers.
Two levels of observability — labels and full Provenance
The IG defines two mechanisms that can be used together or independently. The lightweight path is a security label — the AIAST ("Artificial Intelligence asserted") code from terminology.hl7.org — carried in meta.security. It's blunt: it says AI was involved, but nothing about which AI, which model, or which prompt. The heavier path is a full Provenance resource, profiled to reference the AI as a Device and its model card and prompt as DocumentReferences.
Whether labeling should be required alongside Provenance is the biggest open question at ballot reconciliation. The current text lets implementers pick either mechanism; John's view has shifted toward always requiring the label, and the Zulip discussion is going the same way:
If you don't use the label, you're always probing for Provenance. But if you're probing for Provenance, you're probably a special case anyway. Zulip response has been almost universally for making the label required.
For element-level labeling, the IG borrows the DS4P inline mechanism: a PROCESSINLINE code in top-level meta.security signals that inline extensions are present, and an extension-inline-sec-label extension marks specific elements (for example, only the conclusionCode of a DiagnosticReport). meta.tag was considered and rejected — since the AIAST code already lives in meta.security, using meta.tag would force consumers to check two places.
Modeling the AI — Device, model card, and prompt
Provenance itself isn't extended, only profiled. The AI system is represented as a normal FHIR Device resource (manufacturer, version, software identifiers). Model cards are carried in a profiled DocumentReference because they aren't FHIR — Hugging Face defines them as YAML-fronted Markdown, CHAI defines them as XML, both have a MIME type. Prompts get their own DocumentReference profile with a distinct type code, and can either be contained in the Provenance when they're one-off, or stand alone and be referenced when they're reused across cases.
Element-level Provenance uses two extensions that were added to the extension registry in R5 but are usable in R4: one targets an element by path (Procedure.followup.text), the other by element ID for iterated elements. Any other data the AI saw — lab results, family history, whatever else was passed in — becomes additional entity entries on the Provenance; a human reviewer of the output becomes an additional agent.
Malte's live German ambulatory implementation
Malte Sussdorff implemented the IG in a German ambulatory-care IG and product, and confirmed it works in production across two practices with about ten doctors. His pipeline is a chain: speech-to-text, pseudo-anonymization to keep raw PHI away from the LLM, LLM extraction into FHIR resource suggestions, doctor approval, and finally saving the resource with Provenance attached. Before this call he was only using Provenance; John's UI argument prompted him to open a ticket during the meeting to add AIAST labeling as well.
About an hour with an AI agent to wire up the IG plus our product plus our frontend, then a day of implementation. It was so well written the agent could co-author the change across the whole chain.
The UI pattern he's building rests on the label. Any AI-touched field gets an "AI assisted" chip next to it in the web application, and clicking the chip surfaces the full Provenance behind the value. The label drives the display logic, the Provenance drives the detail view — clean separation between "did AI touch this?" and "what exactly did AI do here?". John noted a similar UI was one of the first things demoed at the first connectathon by May Terry (MITRE).
Cascading AI — an unresolved corner
Nikolai raised a voice-agent case Health Samurai is prototyping — a phone call that fills out a Questionnaire — and asked how to model the Provenance. Should the recording itself be a Binary or DocumentReference, referenced as the source? Gino Canessa flagged the deeper issue this exposes:
Then you need a Provenance for the AI that did the transcription, a separate Provenance for the AI that did the extraction, and a separate Provenance for the AI that did the filling.
John acknowledged cascading AI models aren't addressed in the IG. In theory Device can reference another Device, but there's no explicit guidance today — he took an action to add a note clarifying cascades are out of scope for this version. Malte's team already handles the cascade manually: they save the speech-to-text result as a separate resource with a dictation-asserted label and its own Provenance, then feed that text into the next step, so each AI leg has its own attributable record.
Publication, connectathon, and how to contribute
The team is targeting STU1 publication. Another ballot is possible but not certain — the group is working almost entirely pro bono, and normative content has barely moved since the ballot. Two other IGs want to reference this one, which is adding pressure to get to STU1 sooner rather than later.
Sam Schifman announced the team will be at the September 2026 HL7 connectathon to test the IG, and put a call out for participants (he dropped his email in the meeting chat before hopping to his next call). Ongoing engagement lives in the AI Transparency Zulip channel, the monthly public EHR Work Group meeting, and quarterly Work Group meetings; fresh Jira tickets are still being accepted, and John encouraged watching the CI build directly for anyone tracking the reconciliation.