1up Platform
1up Patient Connect
1up Population Connect
1up Comply
1up Exchange
1up Analyze
Interoperability rules published by CMS often reference specific system and data standards to be used in the implementation of solutions. The reason for this is obvious: if you want to be interoperable, everyone needs to be implementing their solutions with a high degree of consistency, otherwise every integration is a one-off project.
The CMS Interoperability and Prior Authorization final rule (CMS-0057) is no exception to this rule, and references a bevy of different data standards for its implementation, with various recommendations and requirements for the APIs and data involved in compliance with this rule. However, tracking all of the moving pieces and updates since many payers’ initial implementations of Patient Access (CMS-9115) is not easy, so let’s step through the various data domains and use cases covered under the new rule, and take a look at what’s changed since the standards that may have been used in the initial implementation of Patient Access APIs.
Patient Access API
Clinical Data
Clinical data is required to adhere to the US Core Implementation Guide, which corresponds to USCDI data standards for representing clinical data. In the initial implementation, that requirement was for US Core 3.1.1, corresponding to USCDI v1, but as USCDI version requirements have been bumped up, so too have requirements for the version of US Core to be used in Patient Access APIs.
These requirements are not defined directly in the final rule, but are inherited from standards established in other rules. HTI-1 sunsets USCDI v1 and makes USCDI v3 the new requirement, effective January 1, 2026. These changes roll up into CMS-0057 compliance, and now require US Core 6.1.0 accordingly. Also worth noting, HTI-2 will then sunset USCDI v3 and make USCDI v4 the new requirement, effective January 1, 2028. This will then make the new requirement US Core 7.0.0.
Substantively, the updates to the US Core versions largely consist of net new profiles representing new data classes/elements added in the corresponding versions of USCDI, as well as some tweaks to the way existing data elements and classes are modeled, although those changes are generally not huge.
Financial Data
Financial data is recommended to be modeled in line with the CARIN IG for Blue Button, STU 2.0.0. While this is not a requirement, there are several good reasons to move up to the latest version of the CARIN IG for Blue Button, which has recently even published version 2.1.0, moving beyond the version recommended in the most recent rule.
Since the initial CMS Interoperability and Patient Access final rule was published, the CARIN IG for Blue Button has had a number of updates, covering the following:
- A new profile for representing oral claim data
- Updating the professional claim representation to include explicit support for vision claims
- A related person profile for representing non-patient, non-practitioner people in claims data (relevant for claims paid to a subscriber who is not the patient)
- Data modeling updates and general cleanup
- Basis profiles for use in representing claims data with cost-filtering applied (only in the latest 2.1.0 release)
Formulary Data
Formulary data, while technically a part of the Patient Access API, is entirely separate from the rest of the Patient Access API, as it’s public data not affiliated with any patient, more akin to the provider directory data. The latest rule recommends use of the DaVinci PDex US Drug Formulary IG STU 2.0.1.
With this said, just as with the CARIN IG, while this is not a requirement, there are several good reasons to move up to the latest version, and it’s worth noting that there has also already been a new version of this IG published since the rule, with version 2.1.0 bringing some nice small fixes, although no huge changes.
The initial version of the DaVinci PDex US Drug Formulary IG available at the time of initial Patient Access implementations was very simple, drawing its formulary information model from that used by formularies for Qualified Health Plans (QHPs) on the federal health insurance marketplace for healthcare.gov. Unfortunately, while this data model worked within that use case, it turned out to be ill-equipped to handle the complexity of the modeling used for formularies outside of that use case, where the number of plans offered by a payer can balloon, and drugs are reused across many formularies, which are also reused across many plans.
Given this, the newer versions of the implementation guide have adopted a more flexible data model, where drugs and “formulary items” are represented as separate resources to avoid the need to duplicate basic drug data for each formulary it appears on. Similarly, plans and formularies are now represented as separate resources, so that all plans can be represented appropriately in the Formulary API without copying every drug on the formulary for each plan that shares it.
Prior Authorization Data
Prior Authorizations are a new class of data added to the Patient Access API with the CMS Interoperability and Prior Authorization final rule (CMS-0057). There’s a Prior Authorization profile published in the DaVinci Payer Data Exchange IG, but it’s marked as “Experimental” and a draft, so this representation isn’t particularly mature or well tested yet. This is a standard where keeping a close eye on the continuous build and staying up to date with the latest conversations will be valuable as work is done to incorporate this new data into Patient Access APIs.
Provider Directory API
The Provider Directory API data standards have been largely unaffected by new regulation, but there has been a new version of the DaVinci PDex Plan Net IG published in February 2025, which updated profiles to inherit newer US Core standards for relevant provider profiles, along with a variety of smaller updates and fixes. There are also a number of health plans whose current provider directories are not fully representing plan details, networks, and relationships indicating which network(s) providers belong to.
Given that, it may be prudent for payers to take their CMS-0057 implementation as an opportunity to also update the representation of their provider directory data.
Moving Forward
CMS-0057 is ushering the industry forward into an era of greater payer interoperability, including Payer-to-Payer Data Exchange and Provider Access enabling far more data exchange. In this world, more attention will be focused on the data served through the Patient Access API than ever before, and solid underlying data will be key. Moreover, any additional use cases that hope to leverage FHIR data beyond CMS-0057 compliance are far more feasible when the data is high-quality and standardized.
At 1upHealth, we’ve been hard at work on our data modeling to update all of our standards to reflect the latest implementation guides, and creating documentation and processes to make your implementation as high-quality and seamless as possible. If you’re a payer interested in working with us on your CMS-0057 compliance solution, contact us to talk to a 1upHealth team member about how we can enable you to build for compliance and beyond!
