The Record That Will Not Follow

There is a woman I will call Margaret. She is sixty-one years old. She has lived with Type 2 diabetes for fourteen years, managed — with considerable discipline — by a team at a regional health system in central Ohio that she has trusted for a decade. She knows her A1C history by heart. She knows which insulin formulations her body tolerates and which produce the particular constellation of symptoms she has learned, through trial and error and two frightening nights in the emergency department, to recognize and dread. Margaret is not passive about her health. She is an expert in herself.

Last spring, Margaret's husband accepted a position in Portland, Oregon. They moved in March. In April, she sat in the office of a new primary care physician — a capable, well-meaning internist who had never met her before — and watched that physician open an electronic health record that contained almost none of what Margaret's Ohio providers knew about her. Her medication history was incomplete. Her specialist notes were absent. The nuanced picture that a decade of careful management had produced — the picture that lived, in extraordinary detail, in a system she could not access and could not transfer — simply did not arrive with her.

She had brought paper printouts. She had tried to request her records electronically. The request had been partially fulfilled, weeks late, in a format the new system could not fully import. The internist did her best. Margaret started over.

This is not a story about a bad system. It is a story about a good system that was designed, at every critical junction, to serve entities other than Margaret.

I. The Self and Its Shadow

Ralph Waldo Emerson believed that the most dangerous institution was the one that persuaded you your own experience required its mediation. "Man is timid and apologetic," he wrote. "He is no longer upright. He dares not say 'I think,' 'I am,' but quotes some saint or sage." The church had done this for centuries. The academy had done it for generations. In the twenty-first century, the electronic health record has done it to the body itself.

Your medical record is not a document about you. It is, in the most literal sense, a representation of you — a shadow cast in data by every encounter you have had with the healthcare system. It contains the measurements of your blood at rest, the electrical signature of your heart under stress, the pharmaceutical record of what your body has accepted and rejected, the clinical impressions of the people who have examined you at your most vulnerable. It is more intimate than your financial records. It is more revealing than your text messages. It is the story of your body told in the language of medicine, and it follows you — or it should — the way a shadow follows a body in motion.

Except that it doesn't. In the United States in 2026, your medical record is far more likely to follow your previous provider than it is to follow you. It is stored in a system your provider chose, in a format that system's vendor controls, accessible through interfaces that vendor has chosen to build or chosen not to build, subject to policies that vendor has negotiated with your insurer, your hospital network, and the software ecosystem in which it operates. You are, in the eyes of the architecture, a secondary concern.

"The health data economy has a peculiar property: the entity that produces the most valuable asset in the system — the patient — is the one with the least control over it."

— Health Affairs, 2023

This is not an accident. It is an outcome. And understanding it requires tracing a chain of decisions made over thirty years by people who were not thinking about Margaret, and who were not required to.

II. The Architecture of Captivity

The electronic health record was born in the 1990s as an efficiency tool, not a patient tool. The clinical notes, the lab results, the medication lists — these were digitized to help providers document faster, bill more accurately, and coordinate internally. The patient was the subject of the record. The patient was not the audience.

This origin story matters because it shaped every subsequent design decision. The EHR was architected around the workflow of the clinician and the financial needs of the institution. Data was stored in proprietary formats. Interfaces between competing systems were not a priority because competing systems had no incentive to share. Network effects rewarded the largest vendors. By the mid-2000s, the market had consolidated around a small number of dominant players — Epic, Cerner (now Oracle Health), Meditech — whose installations represented billions of dollars of sunk cost for the health systems that ran them.

The financial structure of these relationships created what economists call switching costs so severe as to be functionally prohibitive. A large academic medical center that has deployed Epic across its enterprise has invested not just in software licenses but in years of customization, training, workflow redesign, and integration with hundreds of ancillary systems. The cost of switching is not the cost of new software. It is the cost of rebuilding an institution's nervous system. No hospital CFO makes that decision lightly.

The vendors understood this. They also understood something more subtle: that the data inside their systems was not just operationally valuable but strategically valuable. A health system's patient data — its longitudinal records, its population health profile, its clinical outcomes — is an asset. It informs research partnerships. It enables analytics products. It is, in some configurations, licensable. The more of it a vendor controls exclusively, the more leverage the vendor has.

Information blocking — the practice of restricting access to electronic health information in ways that harm patients, providers, or the healthcare system — was not a fringe behavior. A 2020 ONC report found that it was widespread, documented, and often performed through means technically compliant with existing law. The mechanisms were varied: charging prohibitive fees for data access, implementing interfaces that worked slowly or incompletely, citing privacy exceptions that did not apply, requiring proprietary software to receive data that could have been transmitted in standard formats.

Margaret, moving from Ohio to Oregon, was encountering the downstream consequence of a decade of these decisions — decisions made in conference rooms she was never invited into, by people who never thought about her specifically but whose choices shaped her life precisely.

III. What the Law Said

The 21st Century Cures Act, passed in December 2016, was the federal government's most ambitious attempt to address this problem. Its information blocking provisions — codified in 45 CFR Part 171, implemented in April 2021 — created, for the first time, an explicit legal prohibition on practices that interfere with the access, exchange, or use of electronic health information.

The law defined information blocking broadly. It covered health IT developers, health information networks, and — crucially — healthcare providers. It created a set of exceptions under which information blocking was permitted: privacy protections, security concerns, legitimate operational limitations. But it established the default as openness, with the burden of justification falling on those who would restrict access rather than those who would seek it.

The ONC's companion Final Rule, released in March 2020, went further. It required that certified health IT systems implement standardized FHIR R4 patient access APIs — interfaces through which patients and their authorized applications could retrieve their own data in a modern, interoperable format. It required payers to implement similar APIs for their member data. It set deadlines. It created enforcement mechanisms.

On paper, this was transformative. If fully implemented and enforced, it would mean that Margaret — moving from Ohio to Oregon — could authorize a FHIR-compatible application to retrieve her complete record from her Ohio health system and share it with her new provider. She could do this herself, without requesting permission from anyone, without waiting weeks for a records department to process her request, without receiving a CD-ROM in the mail containing files her new system could not read.

The question is not what the law said. The question is what happened next.

IV. The Exceptions That Swallowed the Rule

The information blocking exceptions were written to be reasonable. They were designed to accommodate legitimate concerns: a provider shouldn't be required to share information in a way that endangers patient safety; a system shouldn't be required to build interfaces faster than is technically feasible; privacy protections should be honored. These are not bad principles.

But exceptions have a physics of their own. In a regulatory environment, the exception tends to expand toward the boundary of what can be claimed rather than contracting toward what can be justified. Health IT legal teams are skilled at this expansion. The "infeasibility" exception, intended for genuine technical limitations, was invoked for situations that were infeasible primarily because a vendor had chosen not to make them feasible. The "privacy" exception was cited for disclosures that HIPAA explicitly authorized. The "security" exception was applied to data sharing arrangements that posed no meaningful security risk.

The enforcement mechanism revealed its own limitations. The OIG, charged with investigating provider violations, received thousands of information blocking complaints in the first years after implementation. Resolution has been slow. As of early 2026, a small fraction of complaints have resulted in formal enforcement actions. The penalty structure — theoretically severe — has functioned, in practice, as a background cost of doing business for vendors with sufficient legal resources to contest findings.

Epic Systems, the dominant EHR vendor, has been the subject of particular scrutiny. The company controls approximately one-third of the hospital EHR market and a much larger share of large academic medical centers. Its data-sharing practices, its interface fees, and its terms of service for third-party developers have been the subject of congressional inquiry, investigative journalism, and formal information blocking complaints. The company maintains that it supports interoperability while continuing to operate the most extensive proprietary health data network in the country.

"The companies that most loudly proclaim their commitment to interoperability are often the ones who have built systems in which interoperability is, quietly, hardest to achieve."

— Health Affairs Blog, 2024

This is not a claim that Epic acts illegally. It is an observation about the relationship between stated principles and structural incentives. A company whose business model depends on the network effects of its data ecosystem has structural incentives to make that ecosystem sticky — to make leaving expensive and arriving difficult. These incentives do not disappear because a law was passed. They adapt.

V. The Grammar of Liberation

HL7 FHIR — Fast Healthcare Interoperability Resources — is not a solution. It is a language. And like all languages, what matters is not whether it exists but whether the people who need to communicate actually choose to speak it.

FHIR R4, the standard version mandated by ONC, is genuinely elegant. It represents the healthcare data community's most serious attempt to build an interoperability standard that is simultaneously clinically rigorous and developer-friendly — that can represent the complexity of a longitudinal patient record while remaining accessible enough for a small software team to implement without specialized HL7 expertise. The FHIR resource model — Patient, Encounter, Condition, Observation, MedicationRequest, and dozens of others — provides a common vocabulary for health data that, if universally adopted, would allow records to move between systems the way email moves between servers.

The promise of FHIR patient access APIs is specific: a patient should be able to open an application on their phone, authenticate with their health system's patient portal, authorize the application to retrieve their data, and receive a structured, machine-readable representation of their medical history — not a PDF, not a CD-ROM, not a printout, but actual data that a receiving system can import, parse, and act on. This is technically achievable. It is not science fiction. Health systems that have implemented FHIR APIs correctly demonstrate it daily.

This is not a utopian vision. It is the intended state of the law as written. The gap between this vision and Margaret's actual experience is not a technical gap. It is a political and economic gap — a gap created by the distance between what the law requires and what institutions have found they can avoid, and a gap created by the extraordinary difficulty of building reliable interoperability across a healthcare ecosystem fragmented by decades of proprietary architecture.

The FHIR community is not naive about this. The Argonaut Project, launched in 2014 by a coalition of health IT companies and health systems, worked to accelerate FHIR adoption through real-world implementation profiles. The Da Vinci Project brought payers and providers into the same FHIR development ecosystem for the first time. TEFCA — the Trusted Exchange Framework and Common Agreement, launched in 2023 — created a governance structure for nationwide health information exchange. Each of these represents genuine progress. None of them has closed the gap that Margaret experienced last spring.

VI. The Sovereignty Argument

There is a way to frame the interoperability problem as purely technical, and in that framing it becomes a problem of standards, of APIs, of trust frameworks, of enforcement mechanisms. These are real problems and they require technical and policy solutions. But the technical framing conceals a prior question, a more fundamental question, one that Emerson would have recognized immediately.

To whom does your medical record belong?

The practical answer, in 2026, is: primarily to your provider, secondarily to your health system, tertiarily to your insurer, and only then — in theory, by right, through a series of legal mechanisms you may or may not be aware of — to you. The law says you have a right to your records. HIPAA's right of access, codified in 45 CFR 164.524, requires covered entities to provide you with a copy of your protected health information within 30 days of your request, in the format you specify if readily producible. The information blocking rules extend this. The ONC patient access API requirements extend it further.

And yet. The average patient, moving between health systems, encounters friction so significant that many simply give up. They fill out the paper forms. They wait the weeks. They receive the incomplete record. They hand their new provider a stack of printouts that represent a fraction of what the previous provider knows, and they begin the process of being known again from scratch. The theoretical right and the practical experience are separated by a gap that only those with time, persistence, and — crucially — the knowledge that alternatives exist can bridge.

This is not incidental. Systems that are difficult to navigate sort their users by resources. The patient who knows to request records in advance, who knows to ask for FHIR-formatted output, who knows to use a patient-facing application to pull their data before changing providers — that patient gets continuity of care. The patient who doesn't know these things does not. The burden of interoperability, in the current system, falls disproportionately on the patients least equipped to bear it.

Emerson's concept of self-reliance was never a counsel of isolation. It was a demand for conditions in which self-reliance was possible — conditions in which the individual was not systematically dependent on institutions for access to what was rightfully theirs. The church that held scripture in Latin denied laypeople access to their own tradition. The guild that controlled technical knowledge denied workers access to their own skill. The health system that controls your medical record — not through malice, but through the accumulated architecture of a market that was never required to serve you first — denies you access to your own history.

Sovereignty over your medical data is not a feature request. It is a precondition for informed self-determination in an era where health decisions are among the most consequential decisions a person makes. You cannot meaningfully participate in your own care without access to the evidence of your own body. And you cannot have that access if the system that holds the evidence was not designed to give it to you.

VII. What Synthetic Data Teaches Us About Real Data

There is something instructive in the contrast between the landscape described above and the world of synthetic patient data — a world in which records move freely because they were designed to move freely, where the concerns that make real data sticky do not apply.

A synthetic FHIR R4 patient record has no privacy burden. It can be shared without restriction, transmitted without authorization, imported without negotiation, studied without IRB oversight. It can be used to build the tools that the interoperable healthcare system requires — the patient-facing applications, the provider-side importers, the payer-provider exchange connectors, the clinical decision support systems — without the legal and institutional friction that surrounds real patient data.

This is not a trivial contribution. The interoperability infrastructure of the future has to be built somewhere, by someone, using data that behaves like clinical data without being clinical data. The software teams building FHIR patient access applications need records to test against. The health systems evaluating interoperability solutions need realistic data to populate their sandboxes. The researchers studying data exchange need datasets that reflect the structure and complexity of real-world health information without exposing real patients.

In this sense, synthetic patient data is not merely a substitute for real data. It is the R&D layer of the interoperable healthcare system. It is the place where the tools get built before the data can move freely — the workshop in which the grammar of liberation is being learned, tested, and refined, in preparation for the day when the systems that hold Margaret's record are required, really required, to let it follow her.

That day is not yet here. But the work is being done. And the quality of that work depends on the quality of the synthetic data used to do it — on whether the records are realistic enough in their structure, their coding, their comorbidity patterns, their insurance relationships, to stress-test the tools that will eventually move real records for real patients.

VIII. What We Owe the Data — and the People It Represents

Margaret's record will eventually follow her. The law will be enforced more rigorously, or the technology will become ubiquitous enough that friction disappears, or patients will develop the tools and the knowledge to navigate the system as it exists. Progress on interoperability is real, even when it is slower than the law intended and slower than patients need.

But the pace of progress is itself a moral question. Every month that Margaret's record does not follow her is a month of duplicated tests, of reconstructed medication histories, of clinical decisions made with incomplete information. Every patient who moves between systems — and in a mobile country, in a fragmented insurance market, there are millions — carries this cost. Some of them pay it in money. Some pay it in time. Some pay it in outcomes.

The Emersonian tradition demands that we look at institutions not only in terms of what they intend but in terms of what they produce — in terms of whether they enlarge or diminish the capacities of the people who depend on them. A health IT ecosystem that produces the experience Margaret had in April 2026 has failed by that measure, whatever its stated intentions, whatever its technical achievements, whatever its compliance posture.

The question is not whether better is possible. It demonstrably is. The standards exist. The legal framework exists. The technical infrastructure is being built. The question is whether the people with the power to accelerate that progress — the vendors, the health systems, the policymakers, the payers — will choose to do so at the pace the patients require, or at the pace that is convenient for them.

Emerson wrote: "The soul is not an institution." He meant that the living, feeling, thinking human being cannot be reduced to the structures that claim to serve it. The patient is not the record. The patient is not the portal. The patient is not the encounter ID or the member number or the clinical note. The patient is the person who produced all of that data through the vulnerability of illness and the labor of recovery, and who deserves — not as a courtesy, not as a feature, but as a matter of right — to have it follow them wherever they go.

Margaret is in Portland now. She is being re-known. She is patient about it, because she has learned to be patient. But she shouldn't have to be. And the day when she doesn't have to be is the day this work is finished.

We are not there yet. We should be working as if we intend to get there soon.