What the US taught us about patient data—  lessons from CMS mandates for the EU 

US payers have now lived through the first real test of CMS-0057-F, the Centers for Medicare & Medicaid Services’ Interoperability and Prior Authorization Final Rule. The pattern that emerged along the way is a genuinely useful gift for anyone preparing for the EU’s own version of interoperability regulations at this moment. Not because the US did anything the EU couldn’t have predicted, but because it is always easier to spot a mistake in someone else’s rollout than to notice you are making one.

The European Health Data Space (EHDS), the EU regulation that sets binding interoperability requirements across all 27 member states, entered into force in March 2025. Its compliance deadlines are fixed: the first wave in March 2029, a second wave in 2031. The detailed technical rules that will make it operational, including the exact specifications for the European Health Record Exchange Format, are expected from the European Commission around March 2027, so the destination is set even though several of the specifics are still being worked out.

If you have been following our Interoperability series, this will sound familiar: the fragmentation problem that leaves patients like Denise St. Clair without a diagnosis for eight years is the same problem both CMS-0057-F and EHDS are trying to solve, just through different regulatory instruments. What the US experience adds is specific, observable detail about where organizations actually stumbled once the deadline stopped being an abstraction, and that detail is exactly what the EU can use now.

Three mistakes worth learning from, not repeating

Assuming there was still time. In our own conversations with payers preparing for this rule, we kept hearing a version of the same thing: work that should have started early got pushed back, because the deadline still felt far enough away to defer. That instinct is understandable. It is also exactly the pattern that turned a rule announced roughly two years in advance into a scramble in its final months for a meaningful share of the market. A firm date on a calendar does not, by itself, create urgency. Something inside the organization has to decide to treat it as real before the deadline does that job for you.

Letting it become an IT problem instead of a business decision. In our own webinar with Opala about what went wrong for payers preparing for this rule, one line sums up the failure mode better than any framework: “Who owns this? And it better not be IT.” Handing the whole thing to a technical team without a named business owner meant no one was accountable for data quality, no one caught compliance gaps until late, and the work that did happen was optimized for shipping an API, not for the operational outcome the rule actually required.

Confusing a working API with an organization that is actually ready. This is the most expensive mistake, because it stays invisible right up until it isn’t. CMS-0057-F was not the first time US payers built a FHIR-based Patient Access API. They built one under an earlier rule, CMS-9115-F, and by most accounts it was constructed to check a compliance box, not to support real day-to-day use.

That weak foundation is now complicating the current rule, because a system that was never stress-tested at real operational scale does not suddenly become one under a new deadline. Building the API is not the same as building something anyone actually uses, and payers that treated the two as interchangeable are finding that out now.

What this means for the EU

None of these three mistakes are US-only problems. They are organizational ones, and every organization preparing for EHDS is exposed to all three in exactly the same way US payers were.

EHDS is structurally more exposed to the ownership problem than a single payer’s internal systems ever were. CMS-0057-F asked individual US payers to fix their own data and stand up their own APIs. EHDS asks 27 member states to build interoperable national infrastructure, including MyHealth@EU access points and a shared European Health Record Exchange Format (EEHRxF), on top of health systems that already vary enormously in data quality and governance maturity. If a single, well-resourced US payer could end up scrambling, a 27-country rollout has more places, not fewer, for the same “who owns this” question to go unanswered until it’s too late (or expensive to fix).

What EU organizations can do now

Name a business owner for EHDS readiness now, and make sure it isn’t purely an IT or compliance function. The US experience says clearly that “who owns this” is not a question you want to still be asking once the deadline is a year out.

Start the data quality and governance work now, without waiting for the European Commission’s implementing acts, expected around March 2027, to spell out every technical detail. Waiting for full clarity before touching the underlying data problem is exactly how US payers ended up compressing years of governance work into their final months.

Build for the outcome the regulation actually cares about, cross-border data that clinicians and patients can genuinely use, rather than the minimum that gets an audit checkmark. A system built only to satisfy a compliance requirement tends to need rebuilding the moment anyone tries to actually use it or when requirements get stricter further down the line, which is expensive to discover after the fact.

Treat the 2029-to-2031 phasing as two forcing functions, not one deadline with a grace period attached. CMS-0057-F’s own two-wave structure only helped the payers who used the first wave as real pressure to get governance right before the second wave arrived.

The point of watching someone else go first

The US showed good effort but might have encountered a first-mover disadvantage. Going in first clearly left a specific record of where things went wrong: deadlines that felt distant until they weren’t, ownership questions left unanswered too long, and technical compliance mistaken for genuine readiness. The EU gets to read that record before living it. That is the actual lesson worth taking from CMS-0057-F.

In the end, none of this is really about mistakes. It’s about what those mistakes cost when nobody corrects them in time. EHDS is not being built so a member state can produce a compliant API on schedule. It exists so that a patient’s medical history is available whenever and wherever they need it. It exists so that a scan taken in one country and the diagnosis determined in another are available to the specialist back in a citizen’s home country.

It’s why a patient like Denise St. Clair (watch her story if you haven’t already) could spend eight years moving from doctor to doctor while her own data sat unreachable somewhere between systems that were never built to talk to each other, and it’s exactly what an earlier diagnosis and an earlier start to treatment actually depend on: not more goodwill from clinicians, but data that follows the patient instead of getting stuck behind them.

It’s worth remembering that every mistake described above is not just a compliance risk. For someone still waiting on a diagnosis, it’s time they will never get back.