What a Federal Rule Written for Autonomous AI Reveals About Governing Health Data After Interoperability Is Solved
Electronic health record systems have been required to expose standardized, FHIR-based APIs since 2022, and information blocking has been federally prohibited since 2021. Interoperability, the problem of getting two systems to speak the same format, is substantially solved. A new problem has taken its place: a December 2025 proposed federal rule is the first to explicitly contemplate autonomous AI retrieving and sharing patient data through those same APIs, and nothing about a standardized format answers whether that access was authorized, attributable, or unaltered. This paper extends The Governed Signal to health data exchange, after the interoperability problem, not instead of it.
Electronic health record interoperability is not the unsolved problem it is often described as. The 21st Century Cures Act, the Office of the National Coordinator's 2020 Final Rule, and a series of enforceable deadlines running through 2023 have made standardized, FHIR-based API access to patient data a federal requirement, not an aspiration. Information blocking, a healthcare provider or vendor obstructing legitimate data access, has been federally prohibited since April 2021. Judged purely as a format and access problem, interoperability has a regulatory answer, and that answer has teeth.
This paper argues that solving the format problem surfaced a different one underneath it, and that a December 2025 proposed federal rule, HTI-5, makes the new problem explicit for the first time: standardized API access answers whether two systems can exchange data in a compatible format. It does not answer whether a specific request for that data, increasingly from an autonomous AI agent rather than a human user, was authorized, whether the data was altered between systems, or who is accountable if it was. This paper applies Signal Paper I's doctrine, Captured ≠ Governed, to that gap, and states plainly where public cost estimates for EHR systems could not be reconciled into a usable figure.
A patient record that moves correctly from one electronic health record system to another, in a standardized format, retrievable through a standardized API, has cleared a real and, until recently, genuinely difficult bar. For most of the history of electronic health records, moving structured clinical data between systems built by different vendors, EPIC, Oracle Health, and dozens of smaller players, on different underlying data models, was itself the primary obstacle to a patient's history following them across providers. That obstacle has a federal regulatory answer now, discussed in full in Section 02.
What a successful, standards-compliant exchange does not establish is a separate question this paper treats as the actual governance gap: whether the record that arrived is the same as the record that was sent, whether the party that requested it was authorized to, and whether that authorization can be verified after the fact rather than assumed at the time. A FHIR-compliant API response is a statement about format compatibility. It is not a statement about custody.
The 21st Century Cures Act, signed into law in December 2016, and the Office of the National Coordinator's May 2020 Final Rule implementing it, require electronic health record systems seeking federal certification to expose a standardized API built on HL7's Fast Healthcare Interoperability Resources standard, specifically FHIR Release 4, under certification criterion 45 CFR 170.315(g)(10). Compliance deadlines under that rule ran through the end of 2022 for the API criterion itself and the end of 2023 for a separate requirement that certified systems support full electronic health information export through an API on request. Separately, information blocking, defined broadly as practices that interfere with the access, exchange, or use of electronic health information, has been federally prohibited since April 5, 2021, under 45 CFR Part 171, with enforcement authority and penalties attached.
Epic, the dominant vendor in the large hospital-system segment with an estimated 19.5 percent share of the ambulatory EHR market, and every other certified vendor, now operates under this requirement. The practical effect is real: a properly authorized application can request a patient's data from a certified system using a standard API and receive it in a standard format, a capability that was not reliably available a decade ago. Judged against the specific problem it was built to solve, format and access standardization, this is a genuine regulatory success, not an unsolved failure this paper is claiming to discover.
illumin8's approach to health data exchange applies the architecture described across this series to the moment a FHIR request is authorized and fulfilled, rather than to the format the resulting data takes. Synergy®, described in Signal Paper VIII as evaluating a sensor-fusion output before a downstream system acts on it and in Signal Paper XIV as assessing any declared action within its surrounding context, is positioned here as the layer that evaluates a data-access request itself: not only whether the requesting application holds a valid OAuth token, which SMART on FHIR already checks, but whether the request's pattern, timing, and scope are consistent with legitimate use. A governed exchange carries a SecuriSync™ Trust Record from the moment of authorization onward, extending this series' "governed at the point of action" pattern to a data request rather than a sensor capture or a creative composite.
Governance in this architecture is not limited to the moment of transmission. A record or clinical image delivered as a governed .wv file carries more than encryption as protection: the file itself governs how it can subsequently be accessed and used, independent of the system that stores or forwards it, the same property Signal Papers X through XII describe for placement licenses and rendered assets. A FHIR API call secures the exchange in transit; the governed file format is what continues to control the record's use after the exchange is complete, when the receiving system, not the sender, has custody of it.
This distinction matters most in exactly the scenario HTI-5 contemplates for the first time: an autonomous AI agent, not a human user clicking through an authorization screen, requesting patient data on an ongoing basis. A human-facing authorization flow assumes a person is available to notice something wrong. An AI agent operating continuously does not have that check built in by default, which is precisely why governance at the point of the request, not just at the point of initial credential issuance, becomes the operative question once autonomous access is the thing being authorized.
The architectural basis for extending this claim to structured clinical data and API-mediated exchange follows the same patent scope established in Signal Paper I: MindAptiv's foundational patents are drafted around digital signals generally, a framing this series has now applied to sensor readings, recordings, composited media, and interface data. This paper does not re-derive that claim or its stated limits; see Signal Paper I, Section 05.
As of this paper, the interoperability framework described in Section 02, the Cures Act, the 2020 ONC Final Rule, and the information-blocking prohibition, is finalized and enforceable federal regulation. HTI-5, the proposed rule announced in December 2025, is not yet final; it proposes removing more than half of the ONC's existing certification criteria to reset the certification program's scope around FHIR-based APIs, and it explicitly updates relevant definitions to contemplate autonomous AI retrieving and sharing health data, the first time a federal rule in this space has done so directly. The proposal also tightens information-blocking exceptions, including a proposal to remove the TEFCA Manner Exception, narrowing the paths available for withholding data on technical or procedural grounds.
The separate CMS Interoperability and Patient Access Final Rule (CMS-9115-F) extends comparable API and data-sharing obligations to payers, meaning the same governance gap described in this paper, format-compliant access without a verifiable record of who accessed what and why, applies on the payer side of the health system as well as the provider side.
This paper does not claim that illumin8 has been deployed at any specific health system, EHR vendor, or payer, and no specific data exchange, breach, or enforcement action is represented here. It does not claim that HTI-5 is final; as of this paper it is a proposed rule, and its provisions, including the specific language addressing autonomous AI, could change before, or if, it is finalized. It does not claim a specific cost figure for EHR implementation or interoperability integration; Section 01 states why no such figure is used. It does not claim that FHIR or SMART on FHIR are inadequate standards for what they were built to do; this paper's argument is that they were built to solve format and session-level authentication, not request-level governance, and that this is a scope distinction, not a defect.
.wv file, that governance travels with it: access and use controls are intrinsic to the file, not solely a property of the system that transmitted or currently holds it, so protection does not end once the exchange is complete.Health data exchange inherits the governance pattern Signal Paper XIV established for text and interface data, extended here to a narrower, more heavily regulated case: structured clinical records moving through a federally mandated API rather than a general-purpose interface. Both papers address a signal that is resolved through declared, machine-readable structure rather than raw sensor capture, and both concern data that a policy or regulatory framework already governs in part, leaving a specific, identifiable gap between what the framework requires and what it actually verifies.
It follows Interface specifically because both papers make the same underlying point in different domains: a system built to make something possible at scale, universal language coverage in one case, standardized health data access in the other, does not automatically make that access accountable. Solving the access problem and solving the governance problem are different projects, and this series treats them as such rather than assuming one implies the other.
This series continues to grow past its initial twelve-paper arc, adding verticals as illumin8's product line and the regulatory landscape around it develop. This paper's argument is time-sensitive in a way few others in this series are: HTI-5 remains a proposed rule, and its final form, if finalized at all, may address the autonomous-AI-access question differently than currently proposed. A later paper in this series may need to revisit this vertical once that rule's status changes.
FHIR-based API access has been federally required since 2022, and a December 2025 proposed rule is the first to explicitly contemplate autonomous AI retrieving and sharing patient data through it. illumin8 governs the exchange at the point of request, not the format after the fact, so accountability for who accessed what, and whether it was altered, does not depend on a human being present to notice something wrong. This is Signal Paper XV.
Request Platform Access → Full White Paper Series