Onyx Blog

What’s Next in Interoperability Regulation: My 2027 Outlook 

CMS-0057 / Compliance

What’s Next in Interoperability Regulation: My 2027 Outlook 

  • Home
  • /
  • What’s Next in Interoperability Regulation: My 2027 Outlook 

The Medicare Plan Finder’s new provider directory data is now part of the 2027 plan shopping experience. Meanwhile, claims attachments, prior authorization, and patient cost transparency each have their own standards work and timelines. 

Taken together, these developments raise a question I’ve been asking for a long time: can FHIR handle transaction volumes comparable to X12? 

Here’s what I’m watching as we head into 2027. I’ll distinguish current requirements and standards work from my own predictions. 

Directories are moving toward shared standards 

For the 2027 plan year, CMS has begun incorporating Medicare Advantage provider and facility directory data into Medicare Plan Finder. Plans prepared for that rollout through CMS testing and made directory data available at contract-level URLs. CMS’s implementation Q&A describes a file-based approach aligned with FHIR bulk publishing, rather than direct access to live FHIR APIs. It is important to note that this does not remove the requirement from CMS-9115 to publish a Provider Directory API. What this does do is setup your FHIR Provider-Directory workflow as the source for the API and CMS Plan Finder. 

Other directory efforts are underway too. CMS’s Oklahoma QHP Directory Pilot is testing a shared statewide directory for Qualified Health Plans and providers. Separately, HL7’s National Directory of Healthcare Providers & Services implementation guide defines a FHIR framework for representing providers, organizations, and payer networks. These are distinct initiatives, but they point the same way: toward connected, standards-based directory exchange. 

I expect payer organizations to become a more visible part of this work. The HL7 directory guide already includes payer organization profiles, which leaves an open question about how a payer organization should be identified across directories and networks. 

My understanding is that CMS does not plan to create another national payer identifier, and that existing identifiers will be honored instead. I’m watching the Legal Entity Identifier (LEI) and its verifiable form, the vLEI. The LEI identifies legal entities; the vLEI adds verifiable digital credentials for organizations and the people acting on their behalf. Neither has been adopted for a CMS or industry directory yet. 

The Plan-Net ballot could shape the next Plan Finder update 

The Plan-Net and US Drug Formulary implementation guides are expected to return to ballot in January, with bulk publishing as one focus. Separately, the FY2027 IPPS final rule updated the adopted version of Plan-Net to 1.2.0, effective October 1, 2026. 

This matters because this year’s Medicare Plan Finder submissions used a CMS-designed manifest. The HL7 work could move future submissions to a standard FHIR bulk-publish approach. The current Plan-Net guide labels its bulk data guidance as draft and not yet fully tested. 

Here’s my forecast: after ballot review and reconciliation, an updated guide publishes around March. CMS then uses it as the basis for a Medicare Plan Finder update, referenced in a proposed rule for 2028. 

For plans, the change should be manageable. CMS’s current manifest requirements are close to what was tested at recent connectathons. The shift is from a custom manifest to one generated from a standard implementation guide. The manifests would still be published as files, not served from a FHIR server. 

Attachments: CMS-0053 and CMS-0062 

CMS-0053 is final. It adopts X12 standards and the HL7 CDA attachments implementation guide for claims attachments, along with electronic signature standards, with compliance required by May 26, 2028. CMS limited the final rule to claims and did not adopt standards for prior authorization attachments. Some payer teams have told us the claims requirements are manageable because X12 is already part of their claims operations. 

CMS-0062 is a proposed rule. Among other proposals, it would adopt FHIR standards for electronic prior authorization transactions under HIPAA, with CDex as the standard for prior authorization attachments. If finalized as proposed, those requirements would reach beyond the payer programs covered by CMS-0057 to any HIPAA covered entity that conducts electronic prior authorization. The proposal limits CDex to prior authorization attachments; it is not a general-purpose attachment requirement. 

Part of CMS-0062 is already in effect. The FY2027 IPPS final rule finalized updated versions of several standards proposed in CMS-0062, including CDex 2.1.0, for CMS’s API requirements, effective October 1, 2026. The HIPAA transaction proposals remain pending. 

The typical use case is a prior authorization that needs additional clinical documentation. CDex supports the payer’s request for that information and the provider’s response. That’s why the relationship between CMS-0053 and CMS-0062 is worth watching. 

CMS’s reorganization also brought the National Standards Group closer to the teams working on FHIR. I expect closer coordination between the X12 and FHIR work as a result. 

The five-year view: attachments could converge 

My view has not changed: the industry needs to show that FHIR can handle transaction volumes comparable to X12. Once that’s demonstrated at scale, workflows that are complicated today become simpler. 

Looking five years out, claims attachments and prior authorization attachments could converge on a single exchange channel. A provider would have one consistent way to send a claim, an attachment, or supporting documentation to a payer. On the payer side, the open question is where that information goes: claims operations, utilization management, or both. 

There are early examples of CDex being used beyond prior authorization, including for quality data exchange. A single channel is a long-term direction, not a near-term regulatory requirement. 

Cost transparency is another track to watch 

The No Surprises Act requires advanced explanations of benefits (AEOBs) and good faith estimates (GFEs), but the departments have said they won’t enforce those provisions until rulemaking is complete. The Da Vinci Patient Cost Transparency guide, version 2.0.1, provides FHIR implementation guidance for these exchanges. It’s a standards resource, not a federal requirement on its own. 

I expect more movement on AEOBs and GFEs over the next couple of years, and the FHIR groundwork is in place to support it. 

What to do now 

Each regulation has its own scope and deadline. Health care organizations can still prepare without treating every rule as an isolated project: 

  1. Follow the January ballot. Review the Plan-Net and Formulary changes as they develop. They could inform a future CMS proposal for Medicare Plan Finder. 
  1. Build from published standards where they fit. Directory publishing, prior authorization, attachments, and cost estimates are all evolving through standards work. Track what is draft, final, and required before committing to an implementation. 
  1. Manage compliance as one ongoing capability. Directories, prior authorization, attachments, and cost transparency draw on the same identity, data, and workflow foundation. Organizations that treat this as continuous compliance, rather than a series of deadline projects, absorb each new rule with less rework. 

At Onyx, we help health care organizations manage these rules as one program, starting with a clear baseline of what’s production ready and what only passes conformance testing. Our CMS Compliance Readiness Guide includes API-by-API validation checklists, an eight-domain self-assessment, and the mandate timeline through 2028. Download it to see where your organization stands.

Download the Guide

Mark Scrimshire

Mark Scrimshire

Chief Interoperability Officer, Onyx