Interoperability’s blind spot: What happens to data after systems retire?
As healthcare advances FHIR-based exchange and replaces aging applications, interoperability strategies must account for the historical records left behind—ensuring legacy data remains accessible, secure, governed and usable long after its original system leaves production.
As impacted payers prepare for the CMS-0057-F API requirements that generally take effect January 1, 2027, the industry is understandably focused on live exchange: expanded patient access, new provider and payer-to-payer APIs, and FHIR-based prior authorization. Those are significant and overdue advances, but the rule is principally about API-based exchange among current payer and provider workflows; it does not establish a lifecycle framework for what should happen to records after the EHR or other application that created them is decommissioned.
That distinction deserves more attention. Hospitals and health systems routinely retire EHRs and practice-management platforms, replace enterprise applications, and inherit additional technology through mergers and acquisitions. Kaufman Hall cited 46 announced hospital and health-system transactions in 2025, while a September 2026 Becker's review identified 26 hospitals and health systems that had announced new EHR implementations or major platform changes during the year. Each transition can create a new inventory of applications, databases, interfaces, documents, and historical records that must be retained, migrated, archived, or securely disposed of rather than simply forgotten.
The data does not stop mattering because its original application is no longer strategic. Patient-access obligations continue for records maintained in archived systems, and security obligations continue for electronic protected health information that an organization or its business associate still maintains. Retention requirements vary by record type, state law, federal program, contract, and other obligations; HIPAA does not establish a single universal medical-record retention period. The practical result is that retirement of the application and retirement of responsibility are two different events.
The invisible risk of legacy applications
Most interoperability conversations begin with systems that are connected, supported, and available to exchange data. That framing works for active provider-to-payer exchange, portal access, network queries, and other contemporary workflows, but it becomes harder when a health system consolidates multiple legacy platforms into one enterprise EHR, an acquired organization winds down its prior system, or a practice closes while records still need to follow patients and remain available for legitimate business and regulatory purposes.
The records can still be required for continuity of care, release-of-information requests, audits, litigation, billing questions, and patient access. Under the HIPAA right of access, individuals generally retain access to protected health information in designated record sets for as long as the information is maintained, including when it is old, stored remotely, or archived; HHS generally requires action on a request within 30 calendar days, with one additional 30-day extension permitted under specified conditions. Archived records, therefore, remain operationally relevant even when they are no longer part of the primary clinical platform.
A common workaround is to keep a retired application running in read-only mode, as it appears to preserve access with the least immediate disruption. In some cases that may be a sensible interim step, but it is not the same as having a durable archive strategy: unsupported software, aging infrastructure, shrinking vendor support, obsolete interfaces, and the loss of staff who understand the system can make access progressively harder while increasing operational and cybersecurity risk.
The HIPAA Security Rule requires appropriate administrative, physical, and technical safeguards for electronic protected health information that a regulated entity maintains. That obligation does not disappear because the application holding the data has been labeled legacy, which means decommissioning plans need to address security, availability, authentication, auditability, and eventual disposition rather than treating a read-only server as the end state.
Accountability doesn't retire with the system
Active enterprise systems usually have clear ownership: a vendor relationship, a governance structure, designated technical and operational leaders, access controls, and established processes for changes and audits. After a replacement goes live, accountability can become diffused. Staff who understood the old data model may change roles or leave; the vendor contract may lapse; interfaces may be disconnected; and responsibility for retrieval may migrate informally from one department to another.
That is where a lifecycle problem becomes an interoperability problem. If clinicians cannot readily retrieve clinically relevant history, if compliance teams cannot produce records efficiently, or if patients encounter avoidable delays when requesting information, the organization still has a data-access problem even though the legacy application is no longer considered part of its active interoperability architecture. The question is not simply whether the data still exists; it is whether the organization can find, authenticate, interpret, produce, and audit that data when it is needed.
At the same time, national exchange infrastructure is becoming more mature. TEFCA provides a nationwide network-of-networks model with common legal and technical requirements, while the voluntary CMS framework for CMS-Aligned Networks is pushing FHIR-based access, identity, network transparency, and record-location capabilities across participating organizations. Those initiatives are focused on making current electronic health information easier to discover and exchange; health systems still need an internal counterpart that governs information after source applications leave production.
In practice, that means planning the data disposition at the same time as the system retirement or migration. Organizations should decide what must be converted into the new platform, what can be maintained in a separate archive, what can be lawfully disposed of who owns the retained information, how users will authenticate, and how access will be logged and audited. Archived information does not need to behave exactly like a production EHR, but it should remain retrievable, governed, secured, and understandable on timelines appropriate to clinical, legal, operational, and patient-access needs.
What executive leaders should decide now
Interoperability is more than a real-time data exchange problem; it is also a data-lifecycle management problem. Ahead of the 2027 CMS API requirements, many healthcare executives can describe their strategy for FHIR APIs, payer exchange, and prior authorization in considerable detail. A parallel question deserves the same attention: How many systems has the organization retired during the past five to ten years, what information remains in each one, who is accountable for it, and how quickly can the organization produce that information when a clinician, patient, auditor, attorney, or regulator needs it?
Building that inventory before an audit, acquisition, records request, or security event creates the opportunity to address risk deliberately rather than under pressure. It also allows system-retirement criteria to become part of future technology purchases, migrations, and M&A integration plans from the outset, including decisions about retention, archival format, access, stewardship, vendor exit terms, security controls, and the cost of keeping data usable over time.
CMS-0057-F is accelerating an important part of healthcare interoperability by setting expectations for data in motion among impacted payers and their partners. It does not solve the equally persistent problem of data at rest after the source system is retired. Closing that gap requires healthcare leaders to treat archival access and application retirement as part of interoperability architecture itself, not as cleanup work that begins after the migration team has gone home.
Shawn Fichter is CEO of Legacy Data Access, a company that provides healthcare data archiving and legacy application retirement services.