Evidence · Submitted July 14, 2026 · Prototype

What we built for the HL7 FHIR AI Challenge, and what it proves

In July 2026 we submitted a working system under the title “Runtime-Governed Agentic Access to FHIR.” This is the submission as a document rather than a credential: the architecture, the constraints we chose, the audit shape, and two pieces of standards feedback. It makes no claim about the challenge outcome.

The task

A discharge summary, governed inside the loop

An agent is asked to draft a discharge summary for a patient. In a FHIR workflow, that means a sequence of searches across Patient, Encounter, Condition, MedicationRequest, AllergyIntolerance, and DocumentReference. Three Gates governs that loop at runtime.

Detected sensitive values in tool responses are tokenized before the model sees them and rehydrated on the return path. The clinician gets a usable draft while the model held tokens for the detected values. Authorization and routing are re-evaluated as the workflow progresses, instead of being judged once at the door.

The demonstration ran end to end in Azure against the Epic FHIR sandbox, with gpt-4o-mini reached through Azure in the recording. It was submitted as a prototype: a complete working pipeline with no pilot site and no production users. The design partner program is the path beyond that state.

Classify

Inspect the data in the request and every tool response.

Authorize

Bind the declared clinical purpose to the requester and allowed tools.

Route

Select a model destination matched to the request risk.

Granted is not authorized

An EHR connection grant defines the outer boundary of what is reachable. A declared clinical purpose defines a narrower boundary inside it: what this request, for this purpose, may actually use.

In the demonstration, the Coverage resource is reachable through the Epic connection but excluded from the clinical discharge purpose, because a discharge summary has no clinical need for insurance data. The exclusion is enforced at the tool-authorization layer, not left to the model's judgment. A single EHR connection legitimately needs broad scopes to serve many purposes, while any one request needs far less.

Purpose is declared, never inferred. Inference over content is used only as a cross-check against the declaration, never as the grant. Silent purpose switching was evaluated and rejected because an authorization basis the user did not knowingly assert is not an authorization basis.

The evidence outlives the artifact

Inline citations in AI-drafted clinical notes are ephemeral. In current EHR workflows they are stripped when the note is signed. What a vendor retains internally is not visible to the organization, so it is not evidence the organization can produce.

For governed FHIR workflows like this one, Three Gates projects the request as standard FHIR R4 AuditEvent and Provenance resources. The AuditEvent records the requesting user and the model, with the model as an agent in the access. The Provenance records the clinician-facing response as a derivation from tokenized sources.

In the demonstration run, 25 FHIR resources were accessed. The exported bundle shows the model received tokenized derivations of them, with no detected raw values retained in the audit record. The records persist independently of the note, in a form a FHIR-native audit repository can store and query. Governance evidence expressed in the same standard as the clinical data it governs is the design choice we would defend most strongly.

How the FHIR integration works

The Epic connection authenticates as a backend service using OAuth 2.0 client credentials with an asymmetric-key JWT client assertion, through Epic's SMART Backend Services interface and the HL7 SMART App Launch Backend Services pattern. The scoped grant is the outer authorization boundary. FHIR resource structure also tells the platform where identifiers, references, and narrative live, so structural knowledge supplements content detection at the tool boundary.

The boundary we state plainly

Detection is probabilistic. The guarantee starts after it.

Values the platform detects are tokenized before model invocation, and the audit record reflects what was detected and tokenized. Every no, zero, and never claim on this site is scoped to detected values. The detection baseline is published separately so the word “detected” carries a number.

Detected demographic attributes, including race, ethnicity, and language, are tokenized before model invocation like other detected identifiers. Their placeholders are neutral rather than realistic synthetic values, because realistic surrogates can inject fabricated demographic signal. This is not a bias-mitigation claim. A capable model can still infer demographic associations from clinical content that legitimately remains in view. The audit record instead supplies attributional evidence about the direct disclosure of detected attributes.

Read the local detection baseline

Standards feedback

Two things HL7 could improve

We ended the submission as a contributor rather than a contestant, and both items stand.

Provenance survival at note signing

There is no standard expectation that AI-derivation evidence attached to a clinical note survives signing. Inline attribution is stripped at the moment the note becomes the legal record. A standard linkage between a signed note and the Provenance of its AI-assisted drafting, preserved through signing, would let the ecosystem stop working around this gap.

Vocabulary for AI participation

FHIR R4 expressed the structure cleanly: the model is an AuditEvent agent with requestor false and a Provenance performer referenced as a Device. The friction is vocabulary. DICOM 110150, “Application,” cannot distinguish a generative model from an interface engine, and no standard slot carries model identity, version, or hosting provider. A participation vocabulary for AI agents and a standard home for model identity would make AI involvement queryable without parsing display strings.