AI Agent EHR Write Access

Skip key takeaways

Updated August 26, 2026

• A server may legally ignore the provenance header that is supposed to prove authorship The FHIR Provenance specification defines the X-Provenance header for exactly this problem, but the same page states that servers MAY ignore it and only SHOULD process it if they support provenance, so attaching the header is a claim about the agent's own behavior, not a guarantee about the server.
• A granted write scope is a ceiling, not a floor SMART App Launch scopes such as cruds confirm what an app might be allowed to do, but the specification itself says modeling the underlying permission layer is a lower-level responsibility in the access control stack, so a write can still return a 403 Forbidden response even inside a granted scope.
• The agent and the server author two different records of the same write The agent's own application prepares the Provenance resource, while the server typically authors the AuditEvent resource, and under a shared service account AuditEvent.agent.who usually names the account rather than the person who triggered the write.
• FHIR has no signed status, and the AI Act's transparency duty does not care A resource can sit at a status like final without anyone having attested to it, because attestation is pushed into a separate Provenance resource FHIR does not require. MDCG 2025-6 states that the AI Act's Article 50 transparency duty applies regardless of MDR or IVDR class, so the duty to disclose an AI-authored entry attaches to the system even though the record format it writes into has no field built to carry that disclosure.
• A notified body will ask for the same five caveats as a technical file's documentation Sweden's Medical Products Agency reportedly found one AI scribe's Class I self-classification incompatible with the MDR, by that vendor's own published account of a preliminary report that binds nobody but the inspected party, and MDCG 2025-6 confirms that a class requiring a notified body satisfies the AI Act's Article 6(1) high-risk bar. For a product on that side of the line, the write-path caveats above are not just engineering choices, they are what a technical file has to justify to a notified body.

Copy takeaways

Two people ask if an agent can write to the chart, and get different answers

A health system CTO or VP of Clinical Informatics asks whether an agent should be allowed to write into the record at all, wanting a yes-or-no gate before anything else. An EHR integration lead asks a narrower question: which scope to request in the app registration, and whether to post a transaction or a batch Bundle. A smaller third buyer, a digital health product owner, asks what the product does the day the agent writes the wrong thing. All three are write-path questions, and this article assumes a working FHIR connection already exists; it does not compare HL7 v2, FHIR and SMART on FHIR or price out an integration project.

Five things about a FHIR write are true at the specification level and are not stated together, as caveats, on capminds, motomtech, nirmitee or themomentum, the competitor pages reviewed for this article: a server may ignore the header meant to prove who wrote a resource, a granted write scope is not itself a permission, the record an agent controls and the record the server keeps about it have two different authors, an atomic write across a resource and its provenance is not guaranteed on every server and FHIR has no signed status for a clinical resource at all. This article states each caveat once, then turns to the regulatory question sitting underneath a subset of these systems: whether the agent doing the writing has just built a medical device.

The header that is supposed to prove who wrote this, and the sentence that undoes it

FHIR has a purpose-built header for exactly this problem. The Provenance resource specification introduces it directly: "The custom header X-Provenance to provide a provenance resource when performing PUT or POST operations using the RESTful interface". An agent that writes a resource can attach a Provenance record to the same call, naming the software or the account that produced it.

The specification then removes the guarantee a vendor pitch usually implies. The same page states plainly that "Servers MAY ignore the header, but SHOULD process it if they support provenance". A server is free to drop the header on the floor and still be a conforming FHIR server. A claim that every write an agent makes is provenance-tracked because the agent attaches this header is a claim about the agent's own behavior, not about what any given server is obliged to do with it.

The confusion this caused elsewhere is worth naming once. http.html, the page documenting the RESTful interactions the header attaches to, contains no mention of X-Provenance at all, confirmed by a direct search of the page. Reading that page alone and concluding the header does not exist in FHIR mistakes a page-scoped absence for a specification-wide one; the header lives one page over.

The scope you were granted is not the permission you think it is

SMART App Launch scopes look like a permission system. The write permissions are a compact set, create, read, update, delete and search, combined into strings like user/*.cruds, which the specification itself glosses as "Permission to read and write all resources that the current user can access".

The same page names the gap directly. Modeling what it calls the underlying permission layer is, in the specification's own words, "a lower-level responsibility in the access control stack", and neither SMART on FHIR nor the FHIR Core specification does it. The stated consequence is a "403 Forbidden response to a write interaction that appears to be allowed by the granted scopes". An agent that checks its own granted scopes before writing has confirmed the ceiling on what it might be allowed to do, not the floor of what a specific server will actually accept.

Two records, two authors and you only write one of them

An agent that writes into the chart does not fully control what the record of that write looks like. The AuditEvent specification draws the line: "Provenance resources are prepared by the application that initiates the create/update of the resource and may be persisted with the AuditEvent target resource." AuditEvent itself, by contrast, is "often (though not exclusively) created by the application responding to the create/read/query/update/delete/execute etc. event", meaning the EHR, not the agent, usually writes it.

So the agent builder authors Provenance and the server authors AuditEvent, and the two can disagree about who did what. That split gets sharper under a shared service account. SMART Backend Services runs an agent under system/*.cruds, whose rights derive from a pre-configured client-specific policy rather than from any one clinician, so AuditEvent.agent.who ends up naming the service account, not a person. Provenance can carry a richer onBehalfOf structure naming the real actor, but the header caveat above still governs whether a given server keeps it. Locking down which account an agent runs under, and what it may impersonate, is a narrower instance of the identity problem our securing AI agents in production guide covers generally; this article is about the record a mis-attributed write leaves behind, not the access control around the agent itself.

Why the write and its provenance are not guaranteed to land together

The RESTful API specification gives an agent two ways to send more than one change at once. A batch Bundle runs each entry independently; a transaction Bundle is meant to run as a single atomic unit, "where the entire set of changes succeed or fail as a single entity". The specification's own motivating example for why the atomic form exists is storing a Provenance resource alongside the clinical resource it describes in one call, so the write and its own audit trail cannot end up out of step.

Then the specification takes the guarantee back. "Note that transactions and conditional create/update/delete are complex interactions and it is not expected that every server will implement them. Servers that don't support the batches or transactions SHOULD return an HTTP 400 error". A production EHR is free to refuse the transaction Bundle outright, which leaves an agent with no atomic way to write a resource and its Provenance together, only two separate calls with a real interval between them in which one exists without the other. Conditional create, update, patch and delete carry a second warning at the top of their own sections in the same specification, reproduced exactly because the source itself reads this way: "Unlike this rest of this page, the conditional create, update, patch and delete are trial use until further experience is gained with their use." Trial use is not a synonym for optional detail; it means the behavior itself may still change.

There is no 'signed'

A written resource can sit at a status like final without anyone having attested to it. The Observation status definitions push anything past that point into a different resource entirely: it states that additional information such as released or signed "would be represented using Provenance which provides not only the act but also the actors and dates and other related data." There is no signed status field on the clinical resource itself, on an Observation or a MedicationRequest, the two resource types checked for this article.

Attestation, in other words, has to be built as a separate Provenance assertion, deliberately, by whoever is responsible for producing it. A final Observation and an attested one read identically on the wire unless somebody added that second resource, and the header caveat above still governs whether the server kept it. An agent architecture that treats a status change as proof a clinician signed off has confused two questions FHIR itself keeps apart.

A retraction is a status change, not an undo

FHIR gives a wrong entry a status to move to, not a way to make it disappear. entered-in-error sits alongside amended and corrected in the Observation status value set, and the three are not synonyms: amended covers "updates/new information and corrections", while corrected is narrower, "modified to correct an error in the test result". Setting entered-in-error changes the resource's status; the resource and its version history stay in place underneath it.

Nothing in FHIR core propagates that status change to a system that already pulled the earlier version. A downstream consumer that read the resource before the correction has no obligation, from the specification itself, to notice it was retracted afterward. Subscriptions can notify a consumer of a change, but nothing requires that consumer to act on it. Who is authorized to set entered-in-error on an agent's own write, and under what scope, is a question the specification leaves entirely to the deployer, because retracting a clinical statement is a clinical act, not a technical one. What happens after a harmful write is reported is a separate question with its own clocks, covered in our AI Act serious incident reporting guide; this section is only about what the record itself does and does not do.

The US mandate that never became a write mandate

In the United States, the API certification criterion that actually governs standardized access, ONC/ASTP section 170.315(g)(10), was built around reading, not writing. The criterion requires a certified Health IT Module to expose read services over a secure API for a single patient and for a population, and it does not require a write capability at all. Among the ONC certification criteria checked for this article, principally the (g)(10) standardized API criterion covered above, none requires a certified system to support a FHIR write.

That single fact explains a lot of what otherwise reads as folklore about write access: why the exact scopes a hospital grants vary so much by site, and why getting write access into Epic or Cerner is a commercial conversation with an administrator rather than a technical negotiation over a published API. Every write path an agent uses in the US is discretionary vendor functionality, negotiated per site, not a certified and uniform surface the way read access is, and nothing in that regime certifies the write itself, which leaves a different body of law to decide whether the thing making it is regulated at all.

Sweden's regulator already lists ambient scribes as medical devices, a position it added in April 2026

Sweden's Medical Products Agency, Läkemedelsverket, states two pieces of this puzzle itself, as a general position addressed to healthcare providers, in guidance dated 2026-04-02 (Dnr 3.1.3-2025-108678). Page 6 lists, among examples of AI-driven medical devices, "AI-assistenter för tolkande journaldokumentation (s.k. ambient scribes)" (an unofficial translation: AI assistants for interpreting medical-record documentation, so-called ambient scribes).

The word tolkande, interpreting, is doing real work: the agency did not list scribes flatly, it listed scribes that interpret the record, close to the test that separates a device from a plain transcript elsewhere in medical device law.

Page 5 of the same guidance states the mechanism connecting device class to AI Act status: "AI-system som utgör säkerhetskomponent i en produkt, i sig är en produkt eller del i en produkt där den medicintekniska riskklassen medför krav på granskning via anmält organ hamnar per definition i kategorin AI-system med hög risk" (an unofficial translation: AI systems that constitute a safety component of a product, are themselves a product or are part of a product where the medical device risk class requires review by a notified body fall by definition into the category of high-risk AI systems). Both passages are new: a direct-text search of the 2023 edition of the same guidance, dated 2023-09-12 (Dnr 4.2.1-2023-077449), turns up neither passage anywhere in that earlier document, a datable shift in the regulator's position rather than a longstanding rule restated.

The guidance itself never closes the gap between naming a scribe as a device category and naming its class: a direct-text search of the document finds no use of the words Rule 11 or sub-rule 11a, and no statement that an ambient scribe specifically sits at Class IIa. Whether scribes as a category clear the notified-body bar the guidance sets up is the next section's question. Whether the EHR system itself carries its own separate market-placement obligations under the EHDS is a different question, answered on our EHDS conformity assessment page, not here.

Whether the thing you built is a medical device at all

MDCG 2025-6, the joint AI Board/MDCG FAQ on AI Act/MDR interplay, contains zero mentions of write, EHR or electronic health, per a direct-text search; its frame is Rule 11a: software providing information for a decision. A transcribe-and-file agent gives no diagnostic information: sub-rule 11c, all other software, Class I, no notified body, not high-risk under Article 6(1) - though Article 5's prohibited practices and Article 50's transparency duties apply regardless of MDR or IVDR class (MDCG 2025-6, page 6, question 4), so it is never outside the AI Act altogether. An agent whose output feeds a later care decision falls instead under sub-rule 11a: Class IIa minimum, a notified body, high-risk.

By Tandem Health's own published account of an inspection of Tandem Health, Sweden's Medical Products Agency found its AI scribe's Class I self-classification incompatible with the MDR, and the vendor is now Class IIa certified. That account rests on a preliminary report, with a definitive report still pending when Tandem published its summary, and it binds nobody but the inspected party. This fork's two-track test, Article 6(1) against Article 6(2), is explained in our AI Act high-risk classification guide.

The Class I split the short version leaves out

MDCG 2025-6's own Table 1 is captioned a non-exhaustive list, and stating it as a two-outcome rule, in-house is out and Class IIa and above is in, drops outcomes the table itself states. The table gives eight rows.

Plain MDR Class I, meaning non-sterile, non-measuring and non-reusable-surgical, sits outside the AI Act's Article 6(1) high-risk bracket, with no notified body involved. MDR Class I that is instead sterile, measuring or a reusable surgical instrument sits inside, because that subset does need a notified body. MDR Class IIa, IIb and III, and MDR Annex XVI devices, sit inside for the same reason, and the IVDR side mirrors it: plain IVDR Class A sits outside, sterile IVDR Class A and IVDR Class B, C and D sit inside. An in-house device built under MDR/IVDR Article 5(5) sits outside, on its own separate basis.

The whole table reduces, by the document's own account, to one column: whether a notified body is involved in third-party conformity assessment at all.

The causation the table implies runs one way only, and most commentary states it backwards: the MDR or IVDR classification decides the AI Act's high-risk outcome, not the reverse. Once that bracket applies, Article 43(3) folds the AI Act's conformity requirements into the manufacturer's existing MDR assessment rather than a second, parallel audit, so the same notified body assesses both. Two costs follow that none of capminds, motomtech or nirmitee states, because none of them reaches past HIPAA into the AI Act layer at all: the notified body itself must be designated for AI Act purposes by 28 January 2028, a supply problem for a manufacturer whose notified body has not applied, and the self-assessment route survives only if harmonised standards also cover the AI Act's requirements. What Article 43 costs beyond the medical-device case is covered at length in our AI Act conformity assessment routes guide; the device-specific overlay above is this article's only new addition to that machinery.

What a defensible write actually requires

None of the five caveats above is solved by better code; each is a boundary to design around, not assume away.

• A defensible write asks for the narrowest scope the task needs, never a blanket cruds grant, because the scope is a ceiling and not a promise the write will succeed.
• Rather than trusting a header a receiving server is free to discard, especially across a server the agent's own team does not operate, it writes its own Provenance assertion.
• A transaction Bundle is never assumed to be honored; a reconciliation path is built for the case where it is not.
• Because no clinical resource carries a signed status of its own, attestation is treated as an explicit, separate act.
• And it has an explicit, pre-agreed path for retracting a write and telling every downstream system that already consumed it, because FHIR itself does not do that automatically.

Each of the five caveats above is also a line item in a Class IIa technical file. A notified body reviewing the design expects a written justification: why a server that may ignore X-Provenance still leaves the write defensible, why a granted cruds scope is a ceiling and not a permission, why Provenance and AuditEvent can name different authors for the same event, why an unsupported transaction Bundle cannot be assumed and how attestation is recorded when the resource has no signed status. None of that is new work; it is the same five decisions, documented rather than left implicit.

Put those two facts together. MDCG 2025-6 states that the AI Act's Article 50 transparency duty applies regardless of MDR or IVDR class, so the duty to disclose an AI-generated entry attaches to the system, not to the format it writes through. FHIR, the format nearly all of these systems use, has no signed status and no field marking a resource as AI-authored, and a receiving server is free to ignore the header meant to carry that disclosure. An unconditional duty lands on a format that, by default, cannot express it.

Whether a notified body will ever look at this product is decided before the product exists, and that decision, not a separate design track, determines which requirements actually govern the write once it happens. A scribe that only transcribes is a different thing, in law, from a scribe whose output is treated as a basis for a later care decision, and right now only one national regulator has said which is which for one vendor's product, and only by that vendor's own published account of a preliminary report that binds nobody but the inspected party. Building the write path and building the compliance file were never two projects, and neither half is optional once the classification question is answered.

Sources: HL7 FHIR specification pages for Provenance (the X-Provenance header), the RESTful API (batch and transaction Bundles, conditional create/update/delete), SMART App Launch scopes and launch context, AuditEvent and the Observation status value set; the ONC/ASTP standardized API for patient and population services certification criterion, 170.315(g)(10); Läkemedelsverket (Sweden's Medical Products Agency) guidance on AI in Swedish healthcare dated 2026-04-02 (Dnr 3.1.3-2025-108678), checked against its 2023-09-12 predecessor (Dnr 4.2.1-2023-077449); MDCG 2025-6, the joint AI Board/MDCG FAQ on AI Act/MDR interplay; and Tandem Health's own published account of a Swedish Medical Products Agency inspection of Tandem Health, which rests on a preliminary report and binds nobody but the inspected party. Read on 26 August 2026. This article is engineering guidance, not legal advice. Confirm every requirement against the primary text with qualified counsel.

FAQ

Last updated: August 26, 2026

Quick answers to common questions about custom software development, pricing, process and technology.

Expand all Collapse all

Search FAQs

Popular

Type to filter questions and answers. Use Topic to narrow the list.

Showing all 5

• ★ Featured question. Can an AI agent write directly into a FHIR-based EHR?

  Copy link Copies a direct link to this answer to your clipboard.

  Mechanically, yes, provided the connecting app holds a write-capable scope such as cruds and the server accepts the interaction. The specification does not guarantee the write lands atomically with its own provenance record, that a human ever attested to it or that a later retraction reaches every system that already read it, so a working connection is only the starting condition, not the whole answer.

• Does a granted FHIR write scope guarantee that a write will succeed?

  Copy link Copies a direct link to this answer to your clipboard.

  No. The SMART on FHIR specification states directly that neither it nor the FHIR Core specification models the underlying permission layer a write actually depends on, so a write can return a 403 Forbidden response even though it appears to be inside the scopes the app was granted. Checking a token's scopes confirms the ceiling on what an app might do, not the floor of what a specific server will accept.

• Who controls the audit record when an AI agent writes to a chart?

  Copy link Copies a direct link to this answer to your clipboard.

  Two different parties, for two different resources. The agent's own application prepares the Provenance resource describing the write it just made.

  The server, not the agent, is typically the one that creates the AuditEvent resource describing the request it received. Under a shared service account, that AuditEvent usually names the account rather than a person, and Provenance can name the real actor only if the agent builds that structure itself and the server keeps it.

• Is an AI agent that writes clinical documentation a medical device under EU law?

  Copy link Copies a direct link to this answer to your clipboard.

  It depends on what the output is used for, and neither the general EU guidance nor Sweden's own resolves the question either way. An agent that only transcribes and files a note points toward the narrow, non-device reading.

  An agent whose output is treated as a basis for a later care decision points toward the broad reading, Class IIa or above with a notified body involved. One national regulator has ruled broadly for one vendor's product, but only by that vendor's own published account of an inspection of itself, a preliminary report with a definitive version still pending and a ruling that binds nobody but the inspected party. A narrow classification only removes a product from Article 6(1) high-risk status; it does not remove it from the AI Act's prohibited-practice or transparency rules.

• Can an AI-written entry be deleted from a patient record?

  Copy link Copies a direct link to this answer to your clipboard.

  Not in the sense of making it disappear. FHIR models a retraction as a status change, setting a resource to entered-in-error, rather than as a deletion, and the resource together with its version history stays in place underneath that status.

  Nothing in the FHIR core specification obliges a system that already read the earlier version to notice or act on the correction afterward, which is why a retraction plan has to be built as its own workflow rather than assumed.

I work with startup founders who need a dedicated software development team but don’t want to gamble on hiring, random outsourcing, or opaque delivery.
Most founders face the same problem sooner or later.
Early technical and team decisions lock the product into tech debt, slow delivery, missed milestones and constant re-hiring. By the time this becomes visible, fixing it is already expensive.

As a CTO and software architect, I help founders design, build and run dedicated development teams that work as a true extension of the startup. Not as a black-box vendor.

My focus is on complex products where mistakes are costly:

• Web3 and blockchain platforms
• FinTech and regulated products
• High-load startup systems
• MVP → scale transitions

We don’t do body-shopping.
We don’t sell generic outsourcing.

Instead, we help founders:

• build the right team structure from day one
• keep technical ownership and transparency
• scale delivery without losing control
• avoid vendor lock-in and hidden risks

Teams are aligned with the product roadmap, business goals and long-term architecture. Not just short-term velocity.