What is FHIR and HL7?

Why It Matters

An agent is only as useful as the data it can reach, and in healthcare that data arrives through FHIR and the older HL7 messaging formats. FHIR’s contribution is structural: it defines named resources, Patient, Observation, Coverage, Claim among them, exposed over a REST API, which means access can be scoped to a resource type and a patient rather than to a database connection.

That structure is what makes an access bound enforceable. A policy that says “this request needs the chart evidence for these criteria” can be expressed as resource reads, and a policy that says “the agent may see everything” is what a broad service account already grants.

What an Agent Needs From It

Read access scoped by resource type and patient, sized to the purpose of the request. Write access to a narrow set of resources, typically documents and communications, with provenance attached to each write. And the same read path for retrieval that the application uses, so the agent cannot quietly widen its own scope by going around the API.

FHIR also carries the resources that make governance practical: Provenance and AuditEvent. Those map closely to what a decision record and an access history need to contain, which means the interoperability layer can be a source of evidence rather than a separate logging problem.

Where It Breaks

Connecting to the API is not the same as having the data. The record a workflow needs often sits in an unstructured note or in a system without a FHIR endpoint, and the unstructured layer is where retrieval quality is decided.

The second break is scope by convenience. Integrations are usually built with one credential that can read broadly, because that is the fastest way to get the first workflow running, and the agent inherits it. Minimum necessary then describes a diagram rather than a limit in the system.

The third is write provenance. An agent that writes to the chart without recording which model, which prompt version, and which sources produced the write leaves the record incomplete at exactly the point a reviewer would ask about it.

How Flytebit Handles It

We scope access by resource type and purpose rather than by connection, and tie it to a per-instance workload identity so the bound travels with the request. Writes carry their provenance into the decision record. The industry application is on our Healthcare & Life Sciences page, and the retrieval side is our RAG development work.