AI Transparency on FHIR
1.0.0-current - STU1 Ballot
AI Transparency on FHIR
1.0.0-current - STU1 Ballot
AI Transparency on FHIR, published by HL7 International / Electronic Health Records. This guide is not an authorized publication; it is the continuous build for version 1.0.0-current built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/aitransparency-ig/ and changes regularly. See the Directory of published versions
| Page standards status: Normative |
The goal of this implementation guide is to provide observability of the use of AI in the production or manipulation of health data. To the end user, this means that in some way they can determine first that AI was involved and then discover more information about the AI and its usage. From this, we can understand that there are two levels of observability and multiple factors that can be observed within the second level.
Provenance, Device, and DocumentReference.Note: that both Security Labels and Provenance can be applied at the whole Resource level or at the Element level within a resource.
The Technical Actors defined in this IG are abstract technical roles that have responsibility defined in this IG. These abstract Technical Actors would be implemented in a variety of systems. The AI is important to the overall use-case but is outside the scope of constraints in this IG. The FHIR resources (clinical content) and Patient are also outside the scope of this IG, but are important to the overall use-case. The Technical Actors are:
Beyond 1st level observability, there are a number of factors that the end user or client system may be interested in knowing about. These factors can be broken down into 3 categories:
Data conforming to this guide carries a label, so inspecting .meta.security is the primary method of determining that AI was involved. Where Provenance has been recorded, it also shows AI involvement and explains how the AI was used. Provenance is not necessarily recorded for every AI-influenced Resource or element. A profile may require that it be recorded, and it may also be recorded where nothing requires it.
For a given FHIR Resource, if Labeling is used, then a FHIR Resource that has been influenced by AI will have the .meta.security element populated with one of the codes from the AI Transparency Provenance ValueSet. See details below
For a given FHIR Resource (e.g. Observation with id of 1234), if Provenance is used, then a search on Provenance.target for the value of your FHIR Resource will indicate all Provenance. Further refine that search to only those Provenance with a .reason code of AIReason.
GET [base]/Provenance?target=Observation/1234&reason=AIAST
If no results are returned then AI was not used, else the Provenance returned will explain how AI was used. See details below.
A label identifies the Resource or element that AI produced or manipulated. It does not convey the level of that influence, or any details about how the AI was used. Labeling is very light weight and does not add significant bloat to the payload or require additional lookups. A client system that needs more than the fact of AI involvement may fetch the Resource's Provenance.
💡 Tip
Use when one needs to quickly and easily identify Resources or elements inside a Resource that have been produced or manipulated by AI.
Labeling (also called Security Labels) uses the FHIR Resource definition .meta.security element that is at the top of all Resources, and as such can be found without Resource type specific processing. The use of security labeling follows the purpose for security labeling, as the domain of security covers protections against risks to Confidentiality, Availability, and Integrity (see Healthcare Privacy and Security Classification System (HCS) vocabulary). In this case focusing on Integrity is defined as completeness, veracity, reliability, trustworthiness, and provenance. In the case of AI Transparency we want to mark the AI participation to convey reliability, trustworthiness, and provenance.
Within the Integrity Security Tags Vocabulary is AIAST - Artificial Intelligence Asserted as a broad concept of any influence by any kind of artificial intelligence. Note: There is also DICTAST - Dictation asserted for when dictation, which might be AI driven, has been involved in translating dictation to data; DICTAST is not included in this IG.
classDiagram
class Resource {
<<FHIR Resource>>
id
meta.security = AIAST
...
}
A Resource label indicates that at least some part of the Resource was produced or manipulated by AI. It does not indicate how much of the Resource was affected, or which parts of it.
A Resource that conforms to this guide and that has been influenced by AI in any way SHALL carry the appropriate label in .meta.security. This applies whether the AI produced the entire Resource or only a single element within it. Applying the label consistently in this way means that all AI-influenced Resources are identifiable by the same lightweight method.
The key portion of that Resource is the following meta.security element holding the AIAST code. AIAST is an HL7 Observation value for metadata that indicates that AI was involved in producing or manipulating the data or information.
The AIAST code does not provide contextual indications, like for example if a clinician was involved in the use of the AI, or reviewed the output of the AI. Neither does it indicate the extent of the AI involvement. When it is useful to show exactly which elements the AI produced or manipulated, the Resource label is combined with element level labeling (see Element label within a Resource).
{
"resourceType" : "Observation",
"id" : "glasgow",
"meta" : {
"security" : [
{
"system" : "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"code" : "AIAST",
"display" : "Artificial Intelligence asserted"
}
]
},
"text" : {
...
An Element label will indicate that an element or a few elements within a Resource were produced or manipulated by AI, but not the whole Resource. Use when components of an example were authored by AI, but not the whole Resource.
meta.security holds a code defined in DS4P Inline Security Labels - PROCESSINLINE, and the inline-sec-label extension is on each element that was produced or manipulated by AI to indicate it is an AI asserted value. The AIAST code will be in the .meta.security element of the Resource also.
One of the key portions of that Resource is
"conclusionCode" : [
{
"extension" : [
{
"url" : "http://hl7.org/fhir/uv/security-label-ds4p/StructureDefinition/extension-inline-sec-label",
"valueCoding" : {
"system" : "http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
"code" : "AIAST",
"display" : "Artificial Intelligence asserted"
}
}
],
"coding" : [
{
"system" : "http://snomed.info/sct",
"code" : "428763004",
"display" : "Staphylococcus aureus bacteraemia"
}
]
}
]
There are a number of observability factors beyond simple labeling that are of interest to end users and downstream systems. Chief among these is the nature of the AI itself. The user would like to understand what algorithm / model was used, who developed it, how it was trained, any certifications it has, and so on… To do this, the guide outlines the use of the Provenance resource, which can then be linked to Device and DocumentReference to point to a Model-Card.
The overall Provenance model is shown below:
classDiagram
direction LR
class Resource {
<<FHIR Resource>>
id
meta.security = AIAST
...
}
class Provenance {
<<FHIR Resource>>
target : Reference resource created/updated
occurred : When
reason : `AIAST`
agent : Reference to AI Device
agent : Reference to human-in-the-loop
agent : References to other agents involved
entity : References to Input-Prompt DocumentReference
entity : References to Model-Card DocumentReference
entity : References to other data used
}
class Device {
<<FHIR Resource>>
id
identifier
type = "Artificial-Intelligence"
extension : Specific kind of AI
modelNumber
manufacturer
manufactureDate
deviceName
version
owner
contact
url
safety
extension : model-card
}
class DocumentReferenceModelCard {
<<FHIR Resource>>
id
type = AImodelCard
category = AIModelCardMarkdownFormat | AImodelCardCHAIformat
description
version
data / url = codeable model-card details
}
class DocumentReferenceInputPrompt {
<<FHIR Resource>>
id
type = AIInputPrompt
description
version
data / url = codeable Input-Prompt details
}
Resource "1..*" <-- Provenance : "Provenance.target"
Provenance --> Device : "Provenance.agent.who"
Device --> DocumentReferenceModelCard : "Device.extension.model-card"
Provenance --> DocumentReferenceInputPrompt : "Provenance.entity.what"
Further described below…
The Provenance profile provides clear ways to define:
Provenance.agent described with a Device conforming to the AIDevice profile identified with the role of Artificial-IntelligenceProvenance.entity with a role of derivation pointing to a DocumentReference conforming to the AIModelCard profileProvenance.entity with a role of derivation pointing to a DocumentReference conforming to the AIInputPrompt profileProvenance.entityProvenance.occurredProvenance.agentProvenance.targetAs with labeling, a Provenance can point at a whole Resource. In this way one can carry details in the Provenance, such as what AI was used and how.
Provenance can be just about some elements within a Resource. This is a supported use of Provenance, but it is especially important for AI use-cases. The support comes from extensions added to the extension-registry and explained in later versions of FHIR. The Provenance.target SHALL point at a specific element(s) within the targeted resource using the target element extension or target path extension.
Procedure.followup.text element.The AI system is described in a FHIR Device resource, which is profiled. The Device.type MUST be Artificial-Intelligence. There is an extension to hold more specific kinds of AI. There is an extension to point at a Model-Card if this Device is always used with that Model-Card. The Device resource referenced in a Provenance resource that describes the AI involvement in the creation or manipulation of the data.
The Model-Card encoding is defined by other standards organizations, and have distinct mime-type. To encode a Model-Card the DocumentReference resource is used. To make this more clear and searchable we define a codeSystem that has some codes to be used to identify that the DocumentReference is specifically an AI Model-Card or an AI Input Prompt
The industry is converging around standards for providing AI instructions and settings, generally called Model-Cards. Several different standards are emerging, including Hugging Face and CHAI Model Cards. This guide does not enforce any particular Model-Card, but does show how to encode any Model-Card in a AI Model-Card profiled DocumentReference, and these would be referenced in a AI profiled Device or within the Provenance.
This specification supports two model-card standards at this time, but recognize that there may be updates and new standards in the future. The choice of which model-card standard to use is up to the implementer, and this guide does not enforce any particular model-card standard.
The Hugging Face Model-Card is a combination of YAML that defines in codeable terms the details, and a Markdown that describes it in narrative. Given that Markdown can carry YAML, the overall object is Markdown.
Example Model-Card from https://github.com/huggingface/huggingface_hub/tree/main/tests/fixtures/cards
Here is an example given:
---
language:
- en
license:
- bsd-3-clause
annotations_creators:
- crowdsourced
- expert-generated
language_creators:
- found
multilinguality:
- monolingual
size_categories:
- n<1K
task_categories:
- image-segmentation
task_ids:
- semantic-segmentation
pretty_name: Sample Segmentation
---
The example above is encoded in a DocumentReference with Model-Card encoded inside
The Coalition for Health AI (CHAI) Applied Model Card utilizes XML encoding and PDF rendering.
An example from the CHAI Github Examples is included here in multiple DocumentReference formats:
Note that these are all the same example Model-Card, just encoded different ways depending on the needs. These three encoding methods are available for the HuggingFace format as well. Note that in the case of CHAI format, these examples include both the XML and the PDF rendering of the same as different .content entries.
When using an AI it is necessary to supply it with certain inputs. These inputs very based on the AI involved, but the industry generally refers to these inputs as the "prompt" (especially in the case of Generative AI).
💡 Tip
Use when the record needs to show the data inputs, such as to understand what data the AI had to inference on, vs what data was not provided.
There are different kinds of prompts supplied, including but not limited to:
In general, inputs should be captured using a Input-Prompt DocumentReference linked through the Provenance, but when specific clinical data is involved those Resources would be indicated as additional Provenance.entity elements.
Note
There is significant variation in what and how AI systems inputs are supplied, however capturing those inputs should remain relatively consistent.
The context documents all inputs involved in AI processing.
One useful thing to record is the prompt(s) given to the AI. This prompt(s) can be very important to the output, and the interpretation of the output. The prompt(s) is recorded as an attachment, using the Input-Prompt DocumentReference, and using a code as defined above
The first example is just showing the encapsulating mechanism. The Second example is a prompt that might be used to have the AI create a given Patient resource that meets the input requirements.
This is a full example of how to capture the AI process in FHIR.
IG © 2024+ HL7 International / Electronic Health Records.
Package hl7.fhir.uv.aitransparency#1.0.0-current based on FHIR 4.0.1.
Generated
2026-08-20
Links: Table of Contents |
QA Report
| Version History |
|
Propose a change