Software Development
Security Services
Cloud Services
AI Services
Other Services
TechMagic Academy
Building AI Agents on Medplum: FHIR-Native Data and AuditEvent Governance
Last updated:25 September 2026
By February 2026, more than 80% of US health care technology executives told Deloitte they expect agentic AI to deliver moderate-to-significant value across clinical and back-office healthcare work this year. It is a sharp jump from the wait-and-see mood of 2024.
None of that value survives contact with a regulator, an enterprise customer's security review, or an investor's due-diligence checklist unless you can prove exactly what the agent did and who signed off on it.
This article makes the business case for building Medplum AI agents the right way: on FHIR-native data, with a human-approval gate and an audit trail built in from day one. AI systems must comply with HIPAA and other regulations. Get that foundation right, and the project holds up under real scrutiny. Skip it, and it stalls in review the moment someone asks for proof.
Key Takeaways
- A Medplum AI agent reads and proposes actions on patient data through the same access controls that govern a human user. Every action is logged automatically, giving you a record you can hand to a regulator or an enterprise buyer.
- The safe default is approval-gated writes: the agent proposes, a person approves, and nothing reaches the record without sign-off. An AI mistake gets caught before it costs you anything.
- FHIR-native data is faster and cheaper to build on than it sounds. It's a format most AI models already understand, with interoperability built in.
- AI-driven workflows require fine-grained permissions for safety.
- AI agents automate unstructured data extraction from formats like faxes and clinical papers. They can reduce confusion in patient communications.
What Are Medplum AI Agents?
Medplum AI agents in healthcare are Large Language Model (LLM)–driven agents that read and act on FHIR-native clinical data through Medplum's APIs. They're governed by the same permission rules as a human user – an AccessPolicy – and every action they take is logged automatically to an AuditEvent, the record you'll eventually need to show a regulator or an enterprise customer's security team.
Medplum also ships a product literally called "Agent", and it is important not to confuse these two things. The Medplum Agent is an on-premises connectivity tool that runs inside a hospital's firewall and talks to legacy devices over HL7 v2, DICOM, and (in alpha) ASTM.
In practice, a Medplum AI agent reads a chart, summarizes a history or lab trend, drafts a note or message, and proposes a write: an order, a task, an observation. It's the same shape of work AI agents are taking on elsewhere in healthcare, scoped here to FHIR-native data and Medplum's own access rules. By default, it doesn't save that write itself.
Why Build AI Agents on FHIR-Native Clinical Data?
FHIR-native, API-first data with access control built in is what actually moves an agent from a weekend demo into something your team can run in production. This is the difference between a short pilot and a multi-quarter integration project.
Three things make that difference. FHIR is a standard most AI models already understand well. Because models perform best against predictable, semantically rich data, an agent working with patient records, lab results, or medication data can reason over that structure directly, which means less engineering work and fewer surprises later.
API-first access gives an agent the patient's full clinical context on demand: labs, meds, encounters, documents, not a stale export that's already out of date by the time someone reads it. And Medplum's built-in interoperability covers labs, medications, secure messaging, scheduling, and billing. That's what actually lets an agent talk to the rest of a real healthcare system.
How Do You Build an AI Agent on Medplum?
Teams asking how to build AI agents on Medplum, or how to create AI agents on Medplum, usually start in the same place.
An AI agent on Medplum is assembled from pieces the platform already ships and has already battle-tested. Your team doesn't need to build, secure, and maintain custom infrastructure from scratch. That matters for the budget and the timeline as much as the architecture diagram.
The building blocks
These are the building blocks most teams reach for when creating AI agents on Medplum, or building AI agents with Medplum from an existing FHIR deployment.
- The $ai operation – Medplum's built-in way to connect a model to your data and power an in-app AI assistant: it takes a natural-language prompt, queries a FHIR resource, and renders the answer from a chart summary to a quick lookup directly inside your healthcare application, no custom wiring required.
- The Medplum MCP server – a pre-built, secure channel for a model to reach FHIR data, so your team isn't building and maintaining that integration alone.
- Bots and Subscriptions – automation that reacts to events (a new appointment, a lab result) without a person triggering it. One live example uses this exact pattern to automate the appointment-confirmation calls that used to eat a scheduler's whole day, and to schedule follow-ups and create tasks that would otherwise be manual work.
- SMART App Launch – puts the agent's interface directly inside the tools your clinical or ops team already uses.
A safe request path
Every request follows the same path. The user's identity and permissions pass through to the agent, so it can act only within that approved scope, and everything it touches is logged automatically. In a chat interface, a read needs no approval (summarizing a chart, say). The agent can also draft messages and propose updates to the patient record for a person to review.
A write is different. It's proposed, shown to a person in plain language as exactly what will change, and only committed once approved – a hard requirement in regulated healthcare workflows. One independent Medplum build of this pattern puts it well: the agent "reads the chart, proposes writes, and saves nothing without your approval." That single design decision is what keeps an AI mistake a caught-and-corrected non-event instead of a liability.
Where the model itself runs matters too, whether you use Medplum's own model integration or bring your own: the system's safety comes from the policy and audit layer around the model, not from which model you pick. Patient data should only reach a model provider under a signed Business Associate Agreement (BAA), and ideally only after it's been stripped down to what the task actually needs – more on that below.
Worth knowing about a different, publicly documented pattern: one Medplum shop built a patient-facing conversational concierge – a chat UI rendering live dashboard widgets. It solves a different problem, patient self-service rather than governed backend automation, and its own write-up says plainly the reference build "doesn't add application-level audit logging for AI interactions," leaving that for whoever takes it to production.
How Do You Govern AI Agents With AuditEvent and Human Oversight?
A governed healthcare AI agent and HIPAA-compliant LLMs stands or falls on what happens the moment it tries to write something. Here's exactly how that works on Medplum.
Can suggest, not act
The pattern, in one line: the agent drafts or recommends, a human approves, and only the approved action is written to the record. Medplum's own documentation frames it this way, and it's the same shape a production Medplum agent build uses: propose, surface the exact change to a person, commit only on approval.
What that looks like in practice, concretely:
AccessPolicy and the audit trail
An AI agent in Medplum is bounded exactly like a human user: an AccessPolicy is the source of truth for what it can read and write, down to the individual patient where that's needed, so an agent built for one care team can't see another team's panel just because nobody scoped it. Every read, proposed write, approval, and rejection the agent performs is logged automatically to an AuditEvent – a timestamped record of who or what touched a given record, and what they did with it.
That record is what turns "we think the agent behaved" into "here's proof" in a form your compliance team, an enterprise customer's security reviewer, or an auditor can actually work with. It's the piece most reference builds skip until someone asks for it in a security review, because healthcare AI has to hold up in real, regulated workflows, not just in a demo.
Designing that layer in alongside the build, rather than bolting it on after a security review flags the gap, is exactly what our team does on Medplum development engagements: the AccessPolicy, the AuditEvent trail, and the human-review workflow scoped together from the start.
What a BAA does and doesn't cover
A signed BAA with the model provider is necessary, not sufficient. It covers liability if the provider mishandles the data you send; it doesn't shrink what you send in the first place. That's a separate decision: minimizing the context window to what the task needs, and working with de-identified or synthetic data in development and test environments so PHI never has to leave at all. We go deeper on what to strip and where teams get this wrong in a dedicated guide.
What Are the Risks, and What Should You Avoid?
Three red flags a CTO can check for directly:
- An agent, or a vendor's default configuration, that can write to the chart without a human approval step.
- Broad, all-resource access instead of a scoped, patient-level AccessPolicy built for that agent.
- PHI reaching a model provider with no signed BAA and no audit trail of what left your environment.
If any of those describe your setup, that's the fix to make before scaling further. The hard stop: an AI agent assists under human oversight; it does not diagnose a patient, does not make an autonomous clinical decision, and no platform makes an organization HIPAA-compliant on its own. The right AccessPolicy design, audit logging, and review workflow make an organization HIPAA-ready. The compliance work itself is still yours to do.
Our Expertise
We have built on Medplum before, for a digital-health startup focused on early cancer detection: Medplum as the FHIR foundation for a HIPAA-ready platform with role-based access across patients, physicians, and administrators. That project demonstrates the FHIR/Medplum depth and HIPAA-first discipline any governed AI agent has to sit on, and it's the same team that would be scoping your build.
AI agent development on Medplum is still new enough that most public guidance comes straight from Medplum's own docs. Creating AI agents with Medplum safely means pairing that platform depth with the governance layer – AccessPolicy, AuditEvent, and human review. Except for proper model integration, you need expertise and technical depth, and that pairing is where our team's Medplum experience carries over directly.
Whether you're scoping a single pilot workflow or a full governance-first rollout, it's worth talking through the architecture before it's locked in, rather than after a security review sends you back to the drawing board. That's the stage our healthcare AI agent development team gets involved.
HIPAA-compliant app built with Medplum to support early cancer detection
Final Thoughts
Prototyping a Medplum AI agent takes an afternoon. The AccessPolicy and AuditEvent layer underneath it is what takes the rest of the project to get right. That's the part that lets you run the agent against real patient data instead of a synthetic demo, whether it's a first pilot or your own Medplum project already in production.
The goal, ultimately, is to create AI agents on Medplum that a compliance team will actually sign off on, not just ones that demo well.
Interoperability is essential for AI to function in healthcare, and that's the deeper reason FHIR-native data matters here. A well-scoped agent can already trigger actions across the healthcare ecosystem with FHIR: placing an order, updating a record, notifying a care team. It just needs a human to sign off first.
That same interoperability is what lets different AI interaction patterns reach the same Medplum data through one governed channel instead of three separate integrations: a Medplum AI agent proposing a write, a conversational AI interface answering a patient's question, or an ambient scribe that captures a doctor-patient conversation and turns it into a structured data entry.
The Model Context Protocol is part of how that happens. It enables AI models to securely interact with patient records without each one needing its own custom connector.
A few one-line predictions. Governance stops being a differentiator and becomes the entry ticket, with procurement asking for a sample AuditEvent trail instead of a promise. Approval-gated writes become the shipped default, not something bolted on after a security review.
By 2030, Gartner predicts 80% of Global 500 companies will contractually make their CIO or Chief AI Officer the organization's "Evidence Custodian" for AI accountability. The trail an agent leaves behind is becoming as important as what it does.
That's the case for building the audit trail and approval gate in from the start: scaling later becomes a formality instead of a rebuild.
We are here to help
FAQ
LLM-driven agents that read and act on FHIR-native clinical data through Medplum's APIs, using natural-language requests for summaries or actions. They're governed by the same AccessPolicy as a human user and recorded in a FHIR AuditEvent trail.
From existing building blocks: the $ai operation, the Medplum MCP server, Bots and Subscriptions for event-triggered logic, and SMART App Launch to embed the agent in a clinical workflow. Not a custom stack from scratch.
Writes are approval-gated: the agent proposes a note, order, or task, a person sees exactly what will change, and only an approved action is committed. Reads don't need approval; writes always do.
It is safe only under a signed BAA with the model provider, and only after minimizing what reaches the context window. Ideally, using de-identified or synthetic data in development and test so PHI doesn't need to leave at all.
The Medplum Agent connects legacy devices over HL7 v2, DICOM, and ASTM; no LLM involved. A Medplum AI agent is an LLM-based agent reading and proposing actions on FHIR data. The names collide while the products don't.
Always ask about real FHIR-native experience, least-privilege AccessPolicy design built in from day one, an AuditEvent trail you can actually see, a documented BAA/PHI-handling practice naming the model provider, and a human-review workflow that holds up as the underlying model changes.
