This guide depends on the official HL7 AI Transparency Implementation Guide
package at the immutable snapshot hl7.fhir.uv.aitransparency#1.0.0-current.
The selected bytes are revision
62ed41054a7182dbb3ed45db7657727517efc024 of
https://github.com/HL7/aitransparency-ig.git, with package archive SHA-256
3ba311ece3eb16a6fdc074759dcf6d2e276f40b384464ac2e52451cac7b0dc45. The moving
CI alias is discovery-only and is never the identity of this dependency.
Consumers use the official AI-InputPrompt, AI-Device, AI-ModelCard,
AI-Provenance, and AIinputsCS artifacts unchanged, together with the
official http://terminology.hl7.org/CodeSystem/v3-ObservationValue#AIAST
security label. Praxis does not define replacements for those official
artifacts.
The snapshot's AI-Provenance profile cannot be used by the deployed validator
for the accepted-resource flow because its required Provenance.agent slice is
classified through the nested Reference-profile discriminator who.resolve().
The separate
https://fhir.cognovis.de/praxis/StructureDefinition/ai-provenance-compatibility
profile provides the same required AI-agent, AIAST reason, and AI-Device target
contract used by that flow, but classifies the AI agent through a direct
agent.role pattern. It derives directly from base FHIR R4 Provenance; it
does not modify, shadow, or claim conformance to the official
AI-Provenance canonical.
This is a bounded Aidbox 2606.2 compatibility contract, not a general replacement for every representation allowed by the official profile. The profile and role semantics remain product- and source-system-neutral; the runtime limitation is the reason this additional conformance surface exists. If the upstream discriminator changes, the overlay must be re-tested against the official profile before it is retained.
The direct role discriminator uses the same fixed official role as the upstream
profile:
http://hl7.org/fhir/uv/aitransparency/CodeSystem/AIdeviceTypeCS#Artificial-Intelligence.
The overlay also preserves the upstream requirement that AIagent.type is
present and must-support; agent.type describes how the AI was used, while the
fixed role identifies the agent as artificial intelligence.
The ballot profile bound AIReason to
http://hl7.org/fhir/uv/aitransparency/ValueSet/ProvenanceVS, whose codes came
from AddedProvenanceCS. The selected current snapshot replaces that contract
with the exact fixed code
http://terminology.hl7.org/CodeSystem/v3-ObservationValue#AIAST. This is a
breaking emitter migration: producers must stop emitting ballot
AddedProvenanceCS reason codes and emit AIAST instead. Producers of the
compatibility profile must also replace the former Praxis-local ai-model role
with the official AIdeviceTypeCS#Artificial-Intelligence role and provide
AIagent.type.
The official AI-InputPrompt profile is the standalone DocumentReference
contract for a prompt given to an AI system. Prompt content in this guide is
limited to placeholder text. Patient prompt content is not stored in the
Implementation Guide.
AI Provenance describes the lineage of an accepted clinical or administrative
FHIR resource. Its Provenance.target points to the resource that was actually
accepted and persisted. The compatibility profile records the AI system through
the unchanged official AI-Device target profile and records the AI assertion
with the official AIAST reason. Optional model-card and input-prompt entity
slicing is not part of this bounded profile and no compatibility claim is made
for it.
Application proposal state before acceptance is not represented as FHIR. A candidate suggested by an application remains in that application's proposal store until a user accepts it. Acceptance creates or updates the final FHIR resource; AI Provenance is written only when AI actually contributed to that accepted result.
Ordinary authorship, import, update, and other audit events that do not involve
AI use the base FHIR R4 Provenance resource. They do not use the AI
Transparency profile or the compatibility profile.
The dependency is pinned to the reviewed hash-verified snapshot. The local compatibility profile is limited to the accepted-resource lineage contract and does not broaden AI authorship or non-AI audit semantics. Conformance checks fail when the reviewed upstream differential changes, requiring an explicit conformance review.