CMS’s interoperability pledge shipped apps first and payers later. When the agency announced its interoperability framework at a White House event in July 2025, more than 60 companies pledged to deliver results for patients by the first quarter of 2026. On April 9, CMS held what it called the first wave launch, introducing a Medicare App Library and tools from more than 50 companies. By then, more than 700 organizations had signed the pledge.
That is a visible result, delivered roughly on schedule. It is also a result built around patients and their apps. The parts of the framework that depend on health plans, such as sharing claims data through aligned networks and supporting exchange between payers and providers, are at an earlier stage. By March, one payer had gone live on a CMS Aligned Network.
Key takeaways
- The first deadline produced a launch. CMS’s April 9 event introduced the Medicare App Library and highlighted tools from more than 50 companies, with more than 700 organizations pledged.
- The focus is patients. The first wave centered on digital check-in and on patient access to records through trusted apps.
- The rules for apps are specific. Apps in the library must verify identity through ID.me or CLEAR and pass an outside evaluation, among other conditions.
- Payers are early. The first payer went live on a CMS Aligned Network in March 2026, and CMS has said it will share claims data through aligned networks.
- FHIR is the next hurdle. CMS’s next set of goals requires apps to move to FHIR and add a record locator service and event notifications.
- Apps sit outside HIPAA. Most consumer apps are not HIPAA covered entities, so privacy protection depends on pledge terms and the Federal Trade Commission’s rules.
What the framework is
The CMS Interoperability Framework is voluntary. It sets criteria for organizations that want to take part in what CMS calls its health technology ecosystem, from data networks to app developers. Networks that meet the criteria can describe themselves as CMS Aligned Networks. Participants commit to provide or facilitate access to health data through FHIR APIs, with an emphasis on patients and the apps they choose.
At the July 2025 launch, 21 networks pledged to meet the criteria and 30 companies pledged to build tools for patients. Health systems and electronic health record vendors made commitments as well. The stated goal was to deliver results in the first quarter of 2026. CMS also said it intended to participate in trusted data exchange itself as early as that quarter.
The framework runs alongside TEFCA, the national exchange framework created under the 21st Century Cures Act. As we described in March, the 2 efforts share a technical direction, FHIR-based exchange with strong identity verification, but have separate governance, and CMS has not described a formal relationship between them.
How patient access got here
The framework is the latest step in an effort that has run for most of a decade. CMS launched Blue Button 2.0 in 2018, giving traditional Medicare beneficiaries a way to send their claims data to apps through an API. Its 2020 interoperability and patient access rule required Medicare Advantage plans and other public program payers, along with plans on the federal exchanges, to offer a Patient Access API, which CMS began enforcing in July 2021. The 21st Century Cures Act’s information blocking provisions added a legal obligation not to interfere with the “access, exchange, or use” of electronic health information.
Those rules made patient access possible. They did not make it common. Patients had to find apps and connect them plan by plan, trusting developers they knew nothing about. The framework’s contribution, if it works, is to organize that experience around a library of vetted apps and networks that can locate a patient’s records across organizations rather than one connection at a time.
What launched in April
CMS’s April 9 announcement described the first wave in terms of what patients can do. The headline feature, which CMS calls kill the clipboard, lets patients share information at check-in by scanning a code with their phone instead of filling out paper forms that repeat what their records already contain. Other tools offer guidance on wellness and chronic disease or let patients access and share their records through apps that meet the framework’s requirements.
The event also introduced the Medicare App Library as the place where Medicare beneficiaries can find apps that meet CMS’s criteria. CMS highlighted tools from more than 50 companies, some available immediately and others described as coming soon.
The check-in scenario shows what the framework is reaching for. A beneficiary arrives at a new specialist’s office. Instead of a clipboard with pages of medication lists and history, the front desk shows a code. The patient scans it with an app that has already verified their identity and approves what to share. The practice receives structured information drawn from the patient’s records across organizations. The forms the patient would have filled in by hand, often inaccurately, arrive as data.
What the announcement did not include is also informative. It did not list which networks had achieved aligned status or give counts of patients served. Payer participation went unmentioned too. Those are the measures that will show whether the framework is changing how data moves, rather than adding new front doors to the same systems.
What the app library requires
CMS laid out the rules for the Medicare App Library in February. According to the American Hospital Association’s summary, the library groups apps into 3 areas, from check-in tools to diabetes and obesity management. To be listed, an app must meet 4 requirements, shown in the table below. Participants in CMS’s ACCESS model for chronic care that join the ecosystem will be featured in the library with a special designation.
| Requirement | What it addresses |
|---|---|
| Sign the interoperability pledge | Commits the developer to the framework’s terms |
| Identity verification through ID.me or CLEAR | Confirms the person using the app is who they claim to be |
| Connection to CMS Aligned Networks | Links the app to networks that hold patients’ records |
| Evaluation by the Digital Medicine Society or the CARIN Alliance | Provides outside review before CMS considers the app |
Compiled from the American Hospital Association’s summary (February 2026).
Those requirements are more concrete than the pledge language of July. Identity verification through named providers addresses one of the hardest problems in patient access, which is being sure the person requesting records is the patient. An outside evaluation before listing gives the library at least some screening that a general app store does not.
Where payers stand
Payers appear in the framework in 2 ways. They hold claims and clinical data that patients and providers want, and they are expected to participate in aligned networks. Progress on both has been slower than on patient apps.
The first visible milestone came in March, when Clover Health became the first payer to go live on a CMS Aligned Network, according to TechTarget’s March 2026 review of interoperability. CMS itself has said it will share Medicare claims data through its Blue Button service by way of aligned networks, which would let a beneficiary’s app retrieve claims history through the same connections it uses for clinical records.
Plans have reasons to want in. A member’s claims history and prior authorizations are exactly the information a new provider needs and a member’s app can display. Aligned networks could also become the route by which plans receive clinical information from providers, if participants agree to answer plan requests.
For most plans, though, the near-term interoperability work is defined less by the voluntary framework than by CMS’s January 2024 interoperability and prior authorization rule. That rule requires impacted payers to stand up new APIs by January 2027, including a Prior Authorization API, on top of the Patient Access API they already run. The framework’s FHIR emphasis points in the same direction, and a plan that builds those APIs well will be in a strong position to join an aligned network. But the rule carries deadlines and obligations. The pledge does not.
That difference shapes plan priorities. A plan deciding where to spend its interoperability budget in 2026 has a regulatory deadline in January 2027 and a voluntary framework with uncertain commercial value. Most will build to the rule first. The framework’s success with payers may depend on whether CMS makes alignment the easiest way to meet the rule, not a separate project.
The first wave proved that patients can carry their data in their pockets. The next one has to prove that the systems behind them will answer.
What comes next
CMS officials described the next set of goals early in 2026. According to Fierce Healthcare, the agency wanted tangible results from the pledges live by March 31, and the following phase requires apps to move to the FHIR standard and add features such as a record locator service and event notifications. Vetted apps in the library are expected to integrate conversational AI to help beneficiaries with information about access to care. CMS has also committed to build a national provider directory.
Each of those features is harder than the first wave.
FHIR at scale. Moving from document exchange and screen-based check-in to structured FHIR APIs requires every connected system to expose and accept the same data elements consistently. That is the work TEFCA and the CMS rules have been pushing for years.
Record location. A record locator service tells an app where a patient’s records exist across organizations. Building one requires reliable patient matching across systems that use different identifiers, the same problem that limits network exchange today.
Event notifications. Admission and discharge notifications are among the most valuable data flows in health care, for care coordination and for plans. They also require participants to push information rather than wait for a query.
Conversational AI. Chatbots that answer beneficiaries’ questions about access to care raise accuracy and accountability questions that the framework has not yet addressed in detail.
The officials who launched the framework have been candid about the gap. In January, one acknowledged that the networks were not quite ready to meet some patient requests and that there might be glitches.
The privacy question
The framework moves data into consumer apps, and most consumer apps are not covered by HIPAA. HIPAA applies to covered entities and the business associates that work for them. An app that a patient chooses to use, and that is not acting on behalf of a covered entity, generally falls outside it. Once a patient directs a plan or provider to send records to such an app, HIPAA no longer governs what the app does with them.
Other protections apply. The Federal Trade Commission’s Health Breach Notification Rule, updated in 2024, requires many health apps to notify consumers and the commission of breaches of identifiable health information, and the commission can act against unfair or deceptive data practices. It has used both. In 2023, it brought its first enforcement action under the breach rule, against a prescription discount app that shared health data with advertisers, and it reached a separate settlement with an online counseling service over similar conduct. The framework’s pledge and the app library’s evaluation requirements add commitments of their own. But those are a patchwork compared with the obligations that bind the organizations the data came from.
For payers, the practical question is how to respond when a member’s app requests data through an aligned network. The Patient Access API rules already require plans to share data with apps a member chooses, subject to limited security grounds for refusal, and plans have been working through that obligation since 2021. Plans may also educate members about an app’s privacy practices before data is shared. The framework will increase the volume and variety of those requests, and plans will want a clear, consistent way to handle them.
Where Redlake stands
We build tools health plans use in utilization review, and 2 of the framework’s next features matter directly to review. Event notifications for admissions and discharges are the trigger for concurrent review and discharge planning. Today, many plans learn of an admission when a hospital calls or faxes. A reliable notification that arrives as the event happens would let a review begin with the facts rather than with a phone call. A record locator service could, over time, tell a reviewer where documentation for a request exists, which is the first step toward retrieving it without a fax.
We also think the framework’s success should be measured the way we suggested for any standard in February, which is by what it lets organizations stop doing. Digital check-in that retires the clipboard is a good start. The more important test is whether, a year from now, plans and providers are sending fewer faxes and making fewer phone calls to exchange the information that coverage decisions depend on.
For plans, the sensible sequence this year is clear. Build the APIs the January 2027 deadline requires, and design them so they can serve an aligned network when the plan is ready to join one. Every fact that arrives through these channels should carry its source and time, so that a reviewer and an auditor can see where it came from.
What to watch in 2026
- Aligned network roster. Which networks CMS recognizes as aligned, and whether it publishes measures of how much data they exchange.
- Payer participation. How many plans join aligned networks, and whether CMS offers any regulatory credit for doing so.
- Blue Button through networks. Whether CMS’s own claims data becomes available to beneficiaries’ apps through aligned networks.
- FHIR milestones. Whether apps and networks meet the next phase’s requirements, from FHIR APIs to event notifications.
- Relationship to TEFCA. Whether CMS and federal health IT officials define how aligned networks and QHINs relate, or leave the 2 tracks to converge on their own.
- Privacy incidents. How the framework and the Federal Trade Commission respond if an app in the library mishandles data.
- The national provider directory. Whether CMS’s directory becomes a shared source that plans and apps can rely on.
About this analysis
Basis. We reviewed CMS’s July 2025 and April 2026 announcements on the health technology ecosystem and the American Hospital Association’s summary of the app library requirements. Reporting by Fierce Healthcare and TechTarget supplied the framework’s goals and early results.
Data notes. Counts of pledging organizations come from CMS and from officials quoted in press coverage, and they rose over time as more organizations signed. CMS had not published measures of data exchanged through aligned networks at the time of writing. The privacy discussion is a general summary and not legal advice.
Sources. CMS, press releases (July 2025 and April 2026). American Hospital Association (February 2026). Fierce Healthcare (January 2026). TechTarget (March 2026). CMS, interoperability and prior authorization final rule fact sheet (January 2024).
Frequently asked questions
What is the CMS Interoperability Framework?
It is a voluntary set of criteria, announced in July 2025, for organizations that want to take part in CMS’s health technology ecosystem, from data networks to app developers. Networks that meet the criteria can become CMS Aligned Networks.
What launched in April 2026?
CMS held a first wave launch on April 9 that introduced the Medicare App Library and highlighted tools from more than 50 companies, led by digital check-in.
What must an app do to join the Medicare App Library?
An app must sign the interoperability pledge and connect to CMS Aligned Networks. It must also verify users’ identity through ID.me or CLEAR and complete an outside evaluation by the Digital Medicine Society or the CARIN Alliance before CMS reviews it.
How does the framework relate to TEFCA?
They are separate voluntary efforts with a shared direction toward FHIR-based exchange and strong identity verification. Some organizations take part in both, but CMS has not described a formal relationship between aligned networks and TEFCA’s Qualified Health Information Networks.
Are health plans required to join the framework?
No. The framework is voluntary. Plans covered by CMS’s interoperability and prior authorization rule do have mandatory API requirements due in January 2027, including a Prior Authorization API.