Insights from Kristen Valdes, founder & CEO and Jill DeGraff, SVP of Privacy, Regulatory Affairs & Compliance at b.well Connected Health| Original Post
In the wake of CMS’s announcement of its new Interoperability Framework to support its vision for a patient-centric healthcare ecosystem, a wave of confusion, speculation, and misinformation quickly took over headlines and social media. While some commentary raised valid questions about the details of implementation and how this will work, others shared misinformed information. What’s missing from the public narrative is a grounded understanding of the legal foundations, technical safeguards, and voluntary nature of this framework.
b.well has spent a decade working in support of a secure connected health ecosystem that overcomes data silos and fragmented care to bring more personalized consumer experiences to healthcare. We’ve consistently operated at the intersection of healthcare, health IT policy and trusted data exchange, and we want to share our perspective of the facts as we understand them. Below, we unpack the 10 most common myths we’ve seen circulating and explain what the law, the policy history, and the CMS framework actually say.
Myth 1: “This is a new centralized government health database managed by CMS.”
Reality: There is no centralized database. CMS’s framework is a voluntary, decentralized blueprint that outlines how health data can be exchanged between independent networks using open FHIR standards and that is centralized around the patient. CMS explicitly states that the federal government will not host, manage, or retain a national repository of health records (beyond what it already maintains as a payer in federal health programs like Medicare). Instead, its focus is to accelerate interoperability through FHIR APIs, so:
- Providers and care teams can more easily access health data for treatment at the point of care
- Patients can easily access and share their full medical record, not just structured data but real world clinical documentation
- EHRs must now share appointments and encounters (outpatient, inpatient, ED, and telehealth within 24 hours of occurrence
- Value-based organizations, where appropriate, can access a subset of data relevant to managing attributed populations
This new framework also expands transparency to patients, showing exactly when their data is shared, with whom, and making their preferences easy to see and manage.
Myth 2: “This is TEFCA 2.0.”
Reality: This is not a replacement or rebranding of TEFCA (Trusted Exchange Framework and Common Agreement), a voluntary, government-endorsed, network-to-network exchange framework created under the 21st Century Cures Act and governed by the Office of the National Coordinator for Health IT (ONC). It connects Health Information Networks (HINs) through Qualified Health Information Networks (QHINs).
Under TEFCA, exchange is only permitted for specific “Permitted Purposes” defined in its Common Agreement. These include:
- Treatment: Direct exchange of health information for the provision of healthcare services.
- Payment: Activities necessary to obtain reimbursement for healthcare services.
- Healthcare Operations: Administrative, quality improvement, and coordination activities under HIPAA.
- Public Health: Reporting to and collaboration with public health authorities.
- Government Benefits Determination: Verifying eligibility for government programs like Medicaid or VA benefits.
- Individual Access Services (IAS): Allowing individuals to access their own records (but only if the QHIN or participant supports IAS).
While Individual Access Services is one of the permitted purposes, TEFCA’s IAS participation is optional for QHINs and their participants and is often deprioritized in early onboarding. Most TEFCA activity today centers on Treatment and Public Health data flows—use cases driven by providers, payers, and government agencies, not patients.
Like TEFCA, the CMS Interoperability Framework is voluntary and government-endorsed. However, the framework is driven by consumer-centric principles that will make Individual Access the central use case — not a side option. It doesn’t require QHIN participation, doesn’t restrict sharing to only HIPAA treatment/payment/operations boundaries, and uses real-time FHIR APIs to let patients send their data to any app or service they choose. Most importantly, all participants must commit to not requiring patients to have a Portal or know their Portal login and password. Next to information blocking that prevents patients from lawfully accessing all their health data through their choice of application, the friction of having to have, remember and re-enter a multitude of portal login is the single largest barrier to empowering patients with access to all of their health data in one place.
Myth 3: “Tech companies outside of HIPAA will be able to freely monetize or sell patient data.”
Reality: This is incorrect. Nothing in the CMS Framework changes the compliance guardrails. FHIR-based access to data is still subject to HIPAA. This means patient consent and data access are nonnegotiables. Tech companies operating outside of HIPAA often operate in states (19 and counting) that have enacted comprehensive consumer privacy laws, effectively raising the compliance floor – in many ways this floor is significantly higher than HIPAA because they recognize consumer rights that increase transparency about their data practices and gives consumers more choices – whether to revoke their consent and have their data deleted, for example. (Contrast that with HIPAA which lacks similar consumer transparency and preferences.)
Also, tech companies outside of HIPAA are subject to FTC enforcement under both its Health Breach Notification Rule and its Section 5 authority—which prohibits undisclosed, un-consented data uses. In addition, there are numerous precedents where tech companies outside of HIPAA are held to consumer privacy standards outside of regulatory mandates. Examples include:
- App distribution platforms like Google Play and the Apple App Store, which hold apps to higher data safety compliance standards when they collect, process or maintain personal health data.
- Developers listed on myhealthapplication.com, which choose to align their privacy and data practices to the CARIN Alliance Code of Conduct for Consumer-Facing Applications.
- The Medicare Blue Button 2.0 connected app gallery, which only includes apps that have been vetted by Medicare staff for compliance with the Medicare Blue Button privacy standards.
- TEFCA, which requires non-HIPAA tech companies that offer Individual Access Services to adopt more stringent privacy, security and breach notification practices as a condition of participation in trusted data exchange.
Giving tech companies a “free pass” to monetize health data without complying with federal and state privacy law obviously puts companies in serious legal jeopardy. Nothing in the CMS Framework suggests that CMS will deviate from the “pantheon” of voluntary consumer-centric privacy frameworks so that consumers can differentiate between apps that meet reasonable consumer expectations for privacy.
Myth 4: “Sensitive health data information will be shared without patient control.”
Reality: The framework is built on explicit patient consent. Consumers choose the apps or services with which to access, use and share their information. As one line of defense, pledging EMR vendors can offer patients an online method to communicate their data restriction preferences. Patient consent preferences must be shared with all involved parties, including for treatment use cases. These preferences must be supported when required by law or policy, including honoring a patient’s right to request restrictions on disclosures of their information for certain purposes.
In addition, once data is released to patients through apps of developers outside of HIPAA, most developers are subject to consumer privacy frameworks with affirmative requirements that support consumer transparency and control.
Notably, the CMS Framework establishes new transparency and audit log requirements, which will create more accountability for data sharing between HIPAA-regulated entities than is required today in HIPAA, because the patient right to an accounting of disclosures includes an exception for disclosures between HIPAA covered data partners for permitted treatment, payment or healthcare operations. In effect, CMS is taking steps to raise the privacy floor.
Myth 5: “This is just a reboot of the failed MyHealthEData initiative.”
Reality: Health interoperability is ongoing and from our experience is consistently building on top of the successes of prior initiatives. When it launched in 2018, MyHealthEData raised awareness about the importance of enabling electronic patient information access, years before federal regulators finalized the first API interoperability rules in 2020. An important success of MyHealthEData was Medicare Blue Button 2.0.
Today, we are at a more mature point in the country’s health interoperability journey. CMS is leveraging its influence as a convener to accelerate the advancement of interoperability and make what should already work, actually work. Also, while CMS’ vision for a patient-centric digital health ecosystem may be cut from the same cloth as MyHealthEData, the regulatory mandates behind FHIR-based interoperability creates an entirely different context. That, if paired with a commitment to enforce patient-facing API mandates, creates a regulatory environment where CMS really could lead a voluntary movement that rapidly accelerates FHIR-based interoperability and creates a catalyst for a robust, standards-based, connected health ecosystem to emerge, drive innovation, and deliver more patient-centric solutions that helps to solve healthcare’s unification problem.
Myth 6: “To participate, you have to know someone in the Administration.”
Reality: This is incorrect. CMS leaders repeatedly state that the aim of this pledge is to build a movement that galvanizes stakeholders around common principles and use cases, and collaborate to execution within defined deadlines. In various forums, these leaders explain that their estimates were wildly exceeded by the number of organizations wanting to sign onto the framework. Instead of getting a small handful of organizations to pledge – maybe 10 – they had over 60 pledging organizations at the White House events announcing the initiative on July 30, 2025. Many more have indicated their interest in signing on since then, and the CMS has open arms, with an important caveat. CMS plans to hold pledging organizations to their pledge commitments. This is a movement of doers, not watchers. If you are willing to put in the work, to meet the requirements in the stated timelines, you should pledge. But if you are not ready to commit, there will be ongoing opportunities, because from everything we’ve heard to date, CMS doesn’t view the near term deadlines as one-and-done objectives, but minimum viable use cases as they iteratively advance interoperability with patient and provider needs at the center.
Myth 7: “Patients and patient privacy will suffer under this Framework.”
Reality: The CMS Interoperability Framework actually raises the privacy bar, going beyond what HIPAA requires, while making permitted uses more transparent to patients. Under HIPAA, some data can already be shared without a patient’s explicit consent, depending on who initiates the exchange, who responds, and under what circumstances.
This framework adds protections by requiring participating networks to log and share patient consent preferences, and to honor them where required by law. It also enables new, privacy-preserving use cases, such as supporting value-based care companies, without sharing the patient’s entire medical record when it’s not necessary. This further limits data exposure while still enabling better care coordination.
Importantly, the CMS Framework does not give CMS access to any new data. The HIPAA Privacy Rule and Security Rule were groundbreaking for their time, but permitted exceptions in the HIPAA Privacy Rule allow some HIPAA protected health information to be shared and used without informed consent of patients. Without explicitly overriding HIPAA, the CMS framework establishes principles that will allow for more transparency about the parties involved in trusted exchange, because of advances in modern cloud-based infrastructure and security practices. This will raise the floor for HIPAA permitted disclosures, not just for disclosures with non-HIPAA tech vendors. While more components of the framework will be published, participants will be required to share patient consent preferences, and to honor them when required by law.
Myth 8: “There are no legal safeguards to prevent misuse of patient data.”
Reality: The framework aligns to established legal requirements: HIPAA, HITECH, the 21st Century Cures Act, CMS’s existing rules on FHIR APIs, ONC’s certification criteria for apps and EHRs, and Information Blocking. The framework explicitly states that it adheres to HIPAA, the HIPAA Rules, and the Privacy Act of 1974. Federal agencies are held to stricter privacy rules than HIPAA. Thus, while more details remain to be seen, CMS is signaling an intent to raise the floor on controls that must be implemented to safeguard and prevent misuse of patient data. Examples include: requirements for verifying the identity and authority of PHI requesters, ensuring that the purpose of use or disclosure of PHI is permitted; implementing the minimum necessary standard; ensuring data protection agreements are in place with downstream service providers; and notifying affected individuals, HHS, and, as applicable, the media, of reportable breaches of unsecured PHI.
Myth 9: “This is a Big Tech power grab where patients lose control of their data.”
Reality: The truth is, today’s healthcare system already shares patient data constantly—often without the patient’s knowledge—under Business Associate Agreements (BAAs). These arrangements allow data to flow between organizations for a wide range of purposes, and patients are rarely notified when it happens.
The CMS Interoperability Framework flips that script. It requires all participating networks to log, and make visible to patients, every time their data is requested, who requested it, and why. Big Tech companies participating in the framework (Apple, Amazon, Google, OpenAI, and others) have already committed to patient authorization, data minimization, and transparency. We would love to see CMS explore a public-facing app certification and trust framework, similar to the Blue Button 2.0 effort under Medicare.
This isn’t about platforms gaining more control. This is about patients finally getting visibility and in some cases authority of use of their own data.
Myth 10: “This is just hype. Nothing will happen by 2026.”
Reality: As of the announcement date on July 30, over 60 organizations had already signed on with more pledging to get involved every day. Many of them are already compliant with CMS’s existing FHIR mandates for payers and EHR vendors. The technical requirements—like USCDI v3, real-time FHIR APIs, and support for write-back are already published, not theoretical or in planning mode. CMS has set a realistic timeline, with live demonstrations anticipated by Q1 2026. The challenge to the industry was to get live this year. This is not speculation and is already in motion. Make no mistake, this is a race, and given the activity we’ve already seen, there are companies way ahead of the starting line.
