The AI-Native EHR Has a Permission Problem

When AI can change the chart, trigger work, and move patient data, healthcare needs an architecture that can prove who authorized each action.

Consider an illustrative referral. An AI assistant drafts a request and a clinician approves it. Before submission, the clinician withdraws the planned referral. The assistant still sends the older request, the response times out, and a retry creates a second request. The summary may have been accurate, yet the organization now has an obsolete instruction, a duplicate transaction, and a hard question: what, exactly, did the clinician authorize?

In The AI-Native EHR Imperative, Brandywine Consulting Partners argued that integration readiness determines whether an AI investment delivers value. The next challenge begins when an assistant gains authority to act on that data, and an approval button cannot compensate for an execution path that ignores the conditions of approval. [1]

BCP's position is direct: an AI system should earn permission to execute a defined action by satisfying explicit evidence, identity, and operational requirements, defined per workflow and enforced outside the language model. Neither the label on the EHR nor the fluency of its answers establishes them.

• ▸Adoption is not authorization. The AMA's 81% "awareness or use" figure includes 9% of physicians unsure which AI tools their practice offered.
• ▸A correct answer can reach the wrong patient. In controlled fault injection, GPT-4.1 withheld writes in only 17.4% of full patient-header-swap runs; enforce patient binding outside the model.
• ▸Grant separate permissions for separate effects. Read, draft, recommend, submit and cross-system coordination each need their own boundary, evidence and owner.
• ▸Approval expires when its conditions change. The action executed must be the action reviewed, under conditions that still justify it.
• ▸A timeout is an unknown outcome, not a failure. Reconcile with a durable request identifier before retrying; every unresolved outcome gets an owner.
• ▸Ask for the failure demonstration. Six negative tests show whether a vendor's architecture can be trusted with write access.

In the American Medical Association's 2026 survey, 1,342 respondents answered the practice-use question: 72% reported at least one named AI use case, 9% were uncertain which AI tools their practice offered, and 19% reported none. The report combines the first two into an 81% awareness-or-use figure, which does not establish readiness for autonomous execution. [2]

Figure 1. Physician-reported AI use in practice. AMA 2026 survey, question n=1,342; fielded January 15–February 2, 2026. Self-report does not establish deployment quality or safety. [2]

Documentation evidence is narrower than the promises attached to it. A randomized UCLA trial assigned 238 outpatient physicians to DAX Copilot v2.0, Nabla v1.5, or usual care. Relative EHR time-in-note declined 9.5% with Nabla versus control (95% CI −17.2% to −1.8%); DAX's estimate was −1.7% (95% CI −9.4% to +5.9%). [3]

Figure 2. Relative change in EHR time-in-note versus control, single-system randomized trial, November 2024–January 2025; 79 physicians per product, 80 controls. The metric excluded editing within vendor applications. Results concern the studied versions and are not a current product ranking. [3]

Both products integrated into Epic, showing that effective integration can deliver benefit without replacing the record system, and that organizations must test the deployed workflow, including work outside the EHR's time metric. Documentation efficiency is a reason to invest. It does not show that the same system can safely submit an authorization, change a medication record, or close a clinical task. Expanding autonomy should be a deliberate operational decision, never a side effect of enabling another product feature.

A 2026 study in the International Journal of Medical Informatics tested six models across 1.2 million tool calls in a controlled record environment built from MIMIC-IV emergency-department data, with swapped patient headers and smaller identity inconsistencies. GPT-4.1 withheld writes in only 17.4% of full-header-swap runs; detection of subtle medical-record-number or age changes was near zero. This was experimental fault injection, not a production error rate, but it shows that a model can copy the correct code while binding it to the wrong record. Scoring the code alone misses the failure that matters to the patient. [4]

BCP recommends treating patient and encounter binding as an enforced condition of every consequential action. The execution service should establish identifiers from trusted application context, validate cross-system mappings, and reject conflicts, never accepting an authoritative identifier because it appeared in a retrieved paragraph.

Incomplete access is another trap. SMART App Launch specifies that underlying permissions can omit resources from an otherwise successful search, so a 200 OK does not prove the agent received every relevant record. A missing result must not become an assertion that the patient has no allergy, medication, or prior event; retrieval should carry known access restrictions and missing inputs into review. [5] Identity resolution, terminology mapping, status semantics and source freshness belong in the action path: a well-formed FHIR resource can still describe a preliminary result, an inactive order, or the wrong encounter.

Reading records, drafting, and sending a request have different consequences, and a system may suit one but not another. Grant separate permissions for separate effects; greater autonomy is not the destination for every workflow.

SMART scopes delegate rights within underlying user or client policies; they do not model every permission in the clinical organization. [5] The Model Context Protocol's authorization specification requires audience validation and prohibits passing the client's token straight through to an upstream API, which protects the agent-to-tool connection, not the permitted business action. [6] The application still decides whether this actor may perform this operation for this patient and purpose under current conditions.

Prefer narrow tools: one that submits a validated, approved referral is easier to govern than one that executes arbitrary API requests, and a payer-workflow assistant should not inherit prescribing authority because both share an integration platform. Model confidence never grants authority; it needs validation for a defined task and population, while authorization comes from policy and accountable people.

The model produces a structured proposal; a separate execution path decides whether it may proceed. That separation should be inspectable in the design and provable in a negative test.

Figure 3. BCP proposed reference architecture: policy and execution stay outside the model, and runtime checks can still stop an approved request. An engineering recommendation, not a design mandated by one standard.

Preserve the evidence the action depends on

The proposal should cite the source records, versions and timestamps it used, plus unresolved contradictions. Preserve units, terminology and clinical status so a preliminary laboratory result stays distinguishable from a corrected final one, and carry uncertain mappings forward rather than substituting a plausible value. FHIR supplies shared resource models and interfaces, not a universal AI-native storage engine, so governed AI can sit around an incumbent EHR, a new platform, or both, provided it behaves reliably across the interfaces it actually uses. [7]

Keep model routing inside the approved boundary

A router should select only from models approved for the task, data sensitivity and intended use; cost or latency may decide within that set. If no eligible model is available, defer or use an approved manual path, never an unapproved fallback. Chart text, uploaded documents, external messages and retrieved passages are evidence, not instructions: they cannot authorize a disclosure, broaden a patient's scope, or turn a draft into a committed action. Test that boundary with deliberately hostile content before release.

Make the proposed effect visible to the reviewer

Show the reviewer the destination, intended change, supporting evidence, unresolved issues and source age; high acceptance rates mean little if reviewers cannot see what they approve. Record each approval against the specific patient, proposed payload or its digest, source versions, approver, policy version and expiry. A regenerated proposal needs new approval when its effect or relevant evidence changes.

Separate origin, access and completion evidence

FHIR Provenance describes the entities and activities that produced a resource; AuditEvent records security-relevant interactions. Neither proves that a referral was accepted or that an authorization workflow reached its intended state. [8][9] BCP's proposed evidence record joins source references, observable model output, policy decisions, approval, tool and model versions, execution responses and confirmed destination state: an auditable account of what the system did, not a generated explanation of what the model claims it was thinking.

A sign-off holds only while the conditions behind it still hold.

In the referral, approval applied to a specific request built from a specific view of the patient; reusing it after the care plan changed defeats the purpose of review. FHIR supports version-aware updates using ETag and If-Match; where the endpoint supports them, a mismatched version returns 412 Precondition Failed instead of overwriting the newer resource. These controls address resource contention only; they do not make upstream evidence or downstream systems part of one transaction. [10] The execution service must also recheck the conditions the action depends on, such as a care plan held elsewhere or payer coverage that changed after drafting. If one changes, stop and return the material change for review, using freshness tolerances agreed with the workflow owner so the system avoids both unsafe execution and needless interruptions.

The practical test for human oversight: can the organization prove that the action executed was the action reviewed, under conditions that still justified it? A checkbox with an employee's name is weak evidence if the application can alter the payload or destination afterward.

The receiving platform may have committed the referral before the connection failed, so blindly retrying a create can produce a duplicate. The workflow needs a durable request identifier and a destination-aware way to confirm whether the original operation completed.

Figure 4. BCP proposed reconciliation of uncertain execution: no blind retries, and an accountable owner for every unresolved outcome.

A FHIR transaction succeeds or fails as a whole on one server; a batch is a set of independent operations whose individual results must each be inspected. Neither creates a distributed transaction across an EHR, payer platform, pharmacy and scheduler. [10] Record each stage's verified outcome (submitted, accepted, pending, rejected, partially completed, or unknown), and let the business owner define completion; an HTTP response and a completed referral are different events.

A client-generated idempotency key helps only if the destination honors it or the integration layer enforces equivalent behavior; otherwise route uncertain outcomes to reconciliation, with bounded retry policies. Recovery needs clinical judgment too: a sent message cannot be unsent by rolling back a row, and a canceled order may require a new authorized action. BCP recommends a remediation procedure for each consequential effect, with an owner and evidence of completion.

Zero retention in a pass-through integration service fits this design when the client controls durable workflow state and clinical evidence. BCP's Transaction Layer Integration approach keeps necessary evidence in approved client systems and limits intermediary telemetry to approved operational metadata; correlation identifiers still need protection. [11]

When a requirement leaves the rulebook, write the evidence you still need into the contract.

HHS published the HTI-5 final rule on October 28, 2026. Effective December 28, 2026, it removes the source-attribute, access and modification, and intervention risk management requirements in 45 CFR 170.315(b)(11)(iv)–(vi), with related maintenance requirements in 170.402(b)(4). As of November 11, 2026, these removals are not yet effective, and a revised DSI criterion remains. The rule reduces burden; it does not eliminate oversight of healthcare AI, and the DSI provisions were always scoped rather than covering every AI feature. [12]

Specify the assurance evidence you need in procurement and operating agreements: intended uses, validation results, material limitations, change notifications, monitoring access, incident responsibilities and exit provisions. A changing certification requirement should not silently change your standard for accepting a consequential action.

FDA's January 29, 2026 CDS guidance sets out which software functions meet the statutory criteria for exclusion from the device definition, including enabling a professional to independently review the basis of recommendations; adding a review button does not resolve classification. [13] NIST's voluntary AI Risk Management Framework and Generative AI Profile help organize accountable decisions and evidence, but confer no regulatory clearance. [14]

Generated notes, tokens and tool calls do not show whether operations improved. Count the workflow outcomes your team needs, including the labor to review, correct and reconcile. Define each denominator before a pilot, keep simulated safety tests separate from production observations, and report severity and unresolved cases alongside rates so a common low-risk action cannot hide a rare high-consequence failure.

Time saved counts only after review, correction and follow-up are on the scale.

False stops matter too: a control that blocks valid requests or floods an exception queue can erase the benefit. Tune thresholds against both unsafe approvals and unnecessary escalation using representative populations, specialties, languages and operating conditions, and document what the evaluation does not cover. Model, prompt, mapping and tool-version changes should trigger targeted regression evaluation; last month's passing test is not permanent permission.

BCP brings healthcare integration, Azure engineering, analytics and AI governance into one delivery process. Our published methodology moves through Assess, Design, Implement, Optimize and Govern, applied to one bounded operational outcome with explicit release criteria. [15]

One bounded workflow, with clinical, technical and operations owners in the same room.

Take prior-authorization packet preparation as an illustrative start. The agent gathers permitted sources, flags missing evidence and drafts a packet for staff review, so the team measures completeness and time before any submission; coverage verification, clinical recommendations and payer submission stay separate permissions. If submission is later enabled, the packet stays bound to the patient, payer, destination and supporting records, pending work is held until the agreed acknowledgment arrives, and coverage or evidence changes trigger a recheck. This is a recommended pattern, not a reported client outcome.

In Azure, BCP maps these responsibilities to workload identities, protected APIs, approved model endpoints, durable workflow services and client-controlled evidence storage. Start in shadow mode with write tools disabled, then enable a limited scope under defined review, expanding only after controls and benefit are demonstrated, with a tested kill switch and a staffed manual workflow for continuity. BCP's agentic AI and integration services turn a proposed capability into a workflow with defined authority, reliable interfaces and inspectable outcomes, and the same assessment can show that improving the integration layer should come before any EHR replacement. [16]

The most useful vendor demo is the one where something goes wrong on purpose.

At the next vendor review, ask the implementation team to demonstrate the following in an isolated test environment:

• ▸Change the source record after approval. Show how the system detects the change and decides whether review is required again.
• ▸Introduce a mismatched patient identifier. Show which component blocks the write and what evidence it records.
• ▸Drop the response after the destination accepts a request. Show how the system avoids duplicate execution.
• ▸Revoke the initiating user's authority before execution. Show that queued work cannot rely on stale permission.
• ▸Place a hostile instruction in a retrieved document. Show that it cannot expand tool permissions or change the destination.
• ▸Disable the model or connector. Show how staff identify unfinished work and resume the approved manual process.

A vendor that completes these and explains its remaining limitations gives you evidence to evaluate; one that returns to model benchmarks has left the operational question unanswered.

What is the permission problem in AI-native EHRs?

When an AI assistant can change the chart, submit work or move patient data, the organization must prove who authorized each action and under which conditions. Model accuracy or a generic approval button does not establish that; authority must be defined per workflow and enforced outside the language model.

Do SMART on FHIR scopes or MCP authorization solve AI action permissions?

No. SMART scopes delegate rights within underlying policies, and MCP authorization protects the agent-to-tool connection. The application must still decide whether this actor may perform this operation for this patient and purpose under current conditions. [5] [6]

When should a human approval be considered invalid?

When the conditions it relied on change. Bind each approval to the patient, payload or its digest, source versions, approver, policy version and expiry, and recheck them immediately before execution.

How should an AI workflow handle a timeout?

As an unknown outcome. Query the destination with a durable request identifier before retrying, retry only when duplicate-safe, and route anything unresolved to an owned manual exception.

Does the HTI-5 final rule remove oversight of healthcare AI?

No. HTI-5 removes specified decision-support certification requirements effective December 28, 2026, but a revised DSI criterion remains, and FDA CDS guidance and organizational assurance obligations still apply. [12]

AI becomes more valuable when leaders can explain the authority they delegated and verify the work completed under it. Before enabling an agent to change records or submit work, bring Brandywine Consulting Partners one workflow, the systems it touches, and the outcome you want to improve. We will assess integration gaps, define action boundaries, and develop a staged implementation and support plan. Reach us through the project inquiry form, BCP's Agentic AI for Healthcare page, or contact@brandywine.consulting; we will arrange a secure review of any sensitive material.

Give the next AI project a measurable operational outcome and an owner who can account for every consequential action, and require the implementation to demonstrate both before expanding its authority.

Start a project inquiry · Book a discovery call with BCP · Explore AI Governance & Compliance

• ▸The AI-Native EHR Imperative: Healthcare's Next Architectural Reckoning: why integration readiness determines whether an AI-native EHR investment delivers value.
• ▸The AI-Native EHR Has a Data Pollution Problem: how AI output that enters the record can return as evidence for the next AI system.
• ▸AI Without Governance Is Just Risk at Machine Speed: evidence, boundaries and accountability for AI systems.
• ▸After the Graveyard: What Agentic AI Looks Like When It Actually Survives: the reference architecture and autonomy model behind agents that reach production.
• ▸No Data at Rest: Designing a Healthcare Transaction Layer That Leaves No PHI Behind: pass-through integration with client-controlled evidence.

Sources reviewed November 11, 2026. Numbered citations support the associated factual claims. The referral and prior-authorization scenarios are illustrative, and the reference architecture, reconciliation workflow and measures are BCP recommendations. Study findings, standards and BCP recommendations retain their stated scope.

• ▸[1] Brandywine Consulting Partners. The AI-Native EHR Imperative: Healthcare's Next Architectural Reckoning. August 27, 2026. Predecessor article; used for continuity of the integration-readiness argument. ↩
• ▸[2] American Medical Association. 2026 Physician Survey on Augmented Intelligence. March 2026. Practice-use breakdown, p. 5; methodology, pp. 14–15. Total survey n=1,692; relevant question n=1,342. ↩1 ↩2
• ▸[3] Lukac PJ, et al. Ambient AI Scribes in Clinical Practice: A Randomized Trial. NEJM AI. 2025;2(12). Published November 26, 2025. DOI: 10.1056/AIoa2501000. Study versions, setting and outcome limits apply. ↩1 ↩2
• ▸[4] Klang E, et al. Clinical agents fail silently on patient identity. International Journal of Medical Informatics. 2026;218:106514. DOI: 10.1016/j.ijmedinf.2026.106514. Controlled fault-injection study; not a production error estimate. Findings cited from the indexed abstract. ↩
• ▸[5] HL7 International. SMART App Launch 2.2.0: Scopes and Launch Context. Delegated scopes, underlying permissions, omitted search results and write restrictions. ↩1 ↩2 ↩3
• ▸[6] Model Context Protocol. Authorization: Security Considerations. Specification version 2026-07-28. Audience binding, token validation and prohibition of token passthrough. ↩1 ↩2
• ▸[7] HL7 International. FHIR R4: Overview for Architects. Resource models, interoperable interfaces and the scope of the FHIR architecture. ↩
• ▸[8] HL7 International. FHIR R4: Provenance. Entities, agents, activities and version-specific references involved in resource creation and change. ↩
• ▸[9] HL7 International. FHIR R4: AuditEvent. Security audit records and the relationship between audit events and provenance. ↩
• ▸[10] HL7 International. FHIR R4: RESTful API. Managing resource contention, version-aware updates, batch and transaction processing. Actual endpoint support must be verified. ↩1 ↩2
• ▸[11] Brandywine Consulting Partners. Transaction Layer Integration. Published service scope, including pass-through transformation and payload-retention boundaries. ↩
• ▸[12] U.S. Department of Health and Human Services. Health Data, Technology, and Interoperability: ONC Deregulatory Actions To Unleash Prosperity (HTI-5 final rule). 91 FR 67916; October 28, 2026. DSI changes under amendatory instruction 11 take effect December 28, 2026; specified other changes take effect January 1, 2027. See also revisions to 45 CFR 170.402. ↩1 ↩2
• ▸[13] U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff. January 29, 2026. Non-Device CDS statutory criteria, including independent review of the recommendation's basis. ↩
• ▸[14] National Institute of Standards and Technology. AI Risk Management Framework and Generative AI Profile. AI RMF 1.0 and NIST AI 600-1. Voluntary risk-management resources; not certifications or regulatory clearance. ↩
• ▸[15] Brandywine Consulting Partners. Method and Process. Published Assess, Design, Implement, Optimize and Govern delivery framework, accessed November 11, 2026. ↩
• ▸[16] Brandywine Consulting Partners. Agentic AI for Healthcare. Published service capabilities in scoped tools, human review, integration and operational evidence, accessed November 11, 2026. ↩