
In July, the US Centers for Medicare & Medicaid Services (CMS) announced an ambitious plan to create a framework aimed at simplifying the exchange of healthcare data between patients and providers.
According to the CMS, 21 networks, 11 health systems and providers, and seven electronic health record (EHR) providers in the US have pledged to participate.
Discover B2B Marketing That Performs
Combine business intelligence and editorial excellence to reach engaged professionals across 36 leading media platforms.
Following the development of the framework, the CMS plans to launch a healthcare data sharing system called CMS Aligned Networks, which is slated for a 2026 rollout.
The Advanced Medical Technology Association (AdvaMed) for the initiative as outlined by US health secretary Robert F Kennedy (RFK) Jr, with CEO Scott Whitaker asserting that greater access to patients’ protected health information (PHI) would “promote the personalised, precise medtech design, utilisation, and care patients deserveâ€.
On paper, a system that gives US patients easier access to their PHI is an encouraging development, one that could resolve longstanding patient frustration over limited data access.
However, to successfully provide patients with easy access to their PHI, CMS and its partners must carefully address potential security risks to avoid data breaches, says Joel Burleson-Davis, CTO at digital identity company Imprivata.

US Tariffs are shifting - will you react or anticipate?
Don’t let policy changes catch you off guard. Stay proactive with real-time data and expert analysis.
By GlobalData³Ô¹ÏºÚÁÏÍø Network spoke with Burleson-Davis to explore the key factors that must be carefully considered to ensure CMS’s aims are achieved in a safe manner.

This interview has been edited for length and clarity.
Ross Law (RL): What potential issues stand out to you about the CMS’s plans?
Joel Burleson-Davis (JBD): The CMS wants to create a system that makes it easier for people to access their healthcare information via standardised application programming interfaces (APIs). While in principle this approach will indeed make it easier for people to access their PHI, it may also give rise to an easier mechanism by which malicious actors can steal that information.
For healthcare, this is a particularly problematic dynamic. PHI is valuable, sensitive information, and there’s good reason it’s protected in the US by regulation such as the Health Insurance Portability and Accountability Act (HIPAA).
For cybercriminals, PHI has long been viewed as a valuable target. Under the CMS’s plans, PHI will be easier to get access to, for both the right end users and malicious actors, meaning the level of security and scrutiny around the CMS’s roll-out of this plan, along with the healthcare organisations who participate in it, will have to be very strong, otherwise the initiative could ultimately end up opening the floodgates for PHI to get exfiltrated to the dark web.
RL: What are the key security protocols you would hope the CMS addresses to safely bring its plans to fruition?
JBD: Embracing OpenID Connect (OICD) authentication and mandating the idea that there needs to be programmatic access via APIs will be good calls. That’s how this concept is going to be useful. The second dynamic is that consumers aren’t going to build their own apps to leverage those APIs to get to their PHI. Rather, a consumer app market will likely arise.
An app ecosystem will make those APIs useful for consumers, which is a good thing, but then you have to make sure that the consumers of those APIs, i.e. the app developers that show up, are also secure, or else, again, we open the floodgates for malicious actors.
Overall, designing this becomes much of a supply chain security dynamic, with PHI held in an organisation that is now exposed via API towards relaying this information to the consumer, or patient, of whom its functionally supposed to serve. As such, it’s going to be important that this entire chain maintains high levels of security and safety.
RL: In building out the framework, what are the core focuses for the CMS and the organisations who have signed on to take part in it?
JBD: The apps likely to emerge that will leverage APIs of participating entities are going to have to think about their entire security programme. Such apps are going to be handling a whole different level of protected information. They will therefore have to make sure that their operations are up to the job, irrespective of whether they are apps developed by the participating entities or third parties.
When you think about how modern organisations work, a healthcare system has lots of other non-employee and third-party technology vendor providers that aren’t part of that system. Business associate agreements get signed with these entities to ensure they’re going to do everything commercially reasonable to protect that PHI, and that security obligation gets pushed on to their vendors and contractors, too.
New or existing organisations that develop apps for patients to access their PHI are going to have to do the same thing. Not only do they have to worry about their own security programme, but if they use non-employees and contractors and technology vendors, they’re going to have to make sure that protection obligation fence continues to expand for all of the parties involved.
RL: For the end user accessing the relevant APIs via apps, what security protocols would you hope to see put in place?
JBD: Those providing API access through an app will need to do strong yet approachable authentication to make sure someone accessing their PHI is who they say they are. App providers will need to leverage modern standards for strong authentication such as facial authentication along with passkeys to make sure that chain from original source of data to the consumer is maintained. If they do something simple, like maintaining the old paradigm with just passwords, it’ll likely find itself in a breach quite easily.
RL: The CMS has said it plans to roll out the data sharing initiative in early 2026. Does this seem overly ambitious?
JBD: I think they can get some of this done by 2026, but if you’re talking about the entire ecosystem being completely rolled out and mature in 2026 – probably not.
The CMS initiative is asking organisations to expose information they have never exposed before to a population much larger than they have exposed that to before. Therefore, I think setting a more aggressive timeline is more about engendering a sense of urgency. If the CMS had said they expected a full roll-out of their planned system by 2028, those involved may only have started mobilising much closer to that point.
In the healthcare space, people are making a lot of decisions about how much money and time to spend. Therefore, if a goal is placed a little too far into the future, people are less engaged because they will always have other more pressing obligations. But if you really want to get it on the docket for people to really engage and get motivated, new initiatives must be made a bit more, or at least seemingly, aggressive.