Applied AI
AI Agents on FHIR
An agent that reads a chart is an OAuth client, and the record it is talking to has a permission model written for people. This paper is the map of what happens in between: the SMART scope grammar and exactly how far it can narrow, the four topologies an agent-to-FHIR connection takes and what each costs in attribution, why the Model Context Protocol forbids the arrangement most teams build first, the delegation standard that would fix it and the reason nobody implements it, and the line between the read path a health system can hold a vendor to and the write path it cannot. Written from the specifications, the implementation guides and the certification criterion rather than from commentary, with every status and date as at October 2026 and every draft and ballot identified as such.
What’s inside
- The three scope subjects SMART defines, what each one proves about the requester, and why an autonomous agent is not any of them
- The v2 scope grammar letter by letter, including why a read scope without search is close to useless and why a scope is a ceiling rather than a grant
- The 2.2 search-parameter filters, the eight categories a certifying server must support, and the resource types that have no granularity below the type at all
- Four topologies from a clinician-launched app to delegated token exchange, with the same five questions asked of each
- SMART Backend Services: the signed assertion, the five-minute token, and what "the server shall mediate the request" means for a pre-authorised client
- Why the Model Context Protocol forbids token passthrough, what the conformant bridge looks like, and the identity that goes missing when you build it correctly
- RFC 8693 token exchange, the act and may_act claims, and the difference between delegation and impersonation that decides whether anything is auditable
- What §170.315(g)(10) certifies, what it excludes, and why every agent write-back is a commercial negotiation rather than a standards conformance question
- Bulk data as the other read path, and when an export is the honest answer instead of a thousand queries
- One task traced end to end through two topologies, with the token exchanges written out and the audit record the second one produces
- Which FHIR R4 elements can name a Device and which cannot, with the Observation.performer gap and the workaround HL7 reached for
- The AI Transparency on FHIR profiles: AIProvenance, the AIAST label, the model card and input prompt entities, and the confidence extension
- IHE Basic Audit Log Patterns, the repeating agent element, the requestor flag, and how to write the audit record you want before you build the thing that emits it
- Prompt injection as an authorization problem, with the published evidence quoted at the strength it actually supports
- Twenty questions, ten for your own build and ten for a vendor, and a glossary of the three dozen acronyms this field runs on
Request this resource
Related insights
- Article · Applied AI
An AI agent is a client, not a user
SMART defines three subjects and an agent is none of them. What a record actually sees when a model asks it a question, and why the answer is usually one service account doing everything.
· 12 min read - Guide · Interoperability
FHIR: the API is the easy part
A FHIR server answers its first request in an afternoon. Profiles, terminology and the implementation guide are the actual project, and none of them is the API.
· 13 min read
