There’s nothing quite like the moment when a second year administration really starts to get its machinery humming and starts to absolutely cook. And cooking indeed we are. The CMS interoperability team appears to have spent the first year of this administration staging ammunition and the second year firing it wildly everywhere, as we saw our second major health tech rule drop from them in a three week period.
Health API Guy is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.
This proposed rule, while slightly more unexpected, is logical and very predictable.
CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) mandated that CMS-regulated payers implement APIs for electronic prior authorization, but the standards are split here. Medical procedures use Da Vinci FHIR Implementation Guides, but the rule deferred on medication prior authorizations, as NCPDP. SCRIPT ePA has more real-world use.
I imagine we’ll see some comments to the extent of “we should use FHIR to have a single prior authorization standard”, but the die is cast here. ASTP added provider-side electronic prior authorization certification requirements for both medical procedures via Da Vinci and medications via NCPDP in HTI-4 in July. This will add the payer-side requirements.
Good lord, how wrong I was! The die was very much not cast. Rather than waiting for the comments I predicted, CMS went ahead and proposed FHIR right off the bat as a full-on HIPAA standard.
What's In The Box
And beyond that, this is not just a little bolt-on for drug PA. Buried under the very mundane headline of extending prior authorization requirements to drugs, is an absolute banger of a proposed rule:
Moves the Da Vinci CRD, DTR, and PAS implementation guides from “strongly recommended” to required for the Prior Authorization API.
Expands the universe of regulated payers by pulling small group market plans on the federal small business exchange (FF-SHOPs) into all existing interoperability requirements.
Extends NCPDP SCRIPT, Formulary & Benefit (F&B), and Real-Time Prescription Benefit (RTPB) electronic prescribing prior authorization standards beyond Medicare Part D to apply to Medicaid, CHIP, and qualified health plan (QHP) issuers for the first time.
Creates a parallel FHIR-based drug PA track for drugs covered under a medical benefit through the existing Prior Authorization API
Proposes expanded API usage metrics across all interoperability APIs and new prior authorization reporting metrics, including numeric counts and drug-specific PA data.
Requires impacted payers to report API endpoints for all five interoperability APIs to CMS for a centralized directory, within 60 days of the final rule.
Contains the first-ever proposal to adopt FHIR as a HIPAA Administrative Simplification standard, replacing the X12N 278 for prior authorization transactions across all HIPAA covered entities.
Sets insanely aggressive implementation timelines for all of the above (with most hitting in October 2027)!
If you thought the 2024 Interoperability and Prior Authorization final rule (CMS-0057) was the big one (as I did), we were deceived, my friends. It’s apparent that was the appetizer and this is the entrée. And to top it all off, it comes with five RFIs that collectively telegraph the next three years of regulatory activity.
The Ghost of HTI-2
If you’re wondering where we are, we are here in the history of health tech regulation:
caption...
The pace of regulatory change certainly has picked up, but also the flavor and focus is shifting. As evidence in that last row, payers are increasingly a major, if not the primary, target of regulatory action in regards to health technology in this era. I’m certain they yearn for the carefree, spectator-seat days of Meaningful Use and the 2010s before the Feds shifted their gaze from clinical to administrative data.
Along those lines, the biggest bombshell of this new proposed rule (for me at least) was not even in the main content of the rule. It was this suggestion and the associated Request for Information:
We are also exploring opportunities to leverage existing programs, such as the ONC Health IT Certification Program, to ensure that API technology used by payers meets the technical requirements we establish.
If you are feeling a strange sense of deja vu, well, that’s because the ghost of the Mickey Tripathi ASTP admin hath rose again. In the HTI-2 proposed rule, the ASTP proposed to expand the set of certification criteria to include health IT used by payers, not just providers:
The rule adds criteria for categories of payer software developers, who were previously not included in the program (Note: this is something we help with at HTD)
Like so many things we do in health technology, partisanship only plays a role to claim an idea as a win for the current admin, but in reality we drive towards the same policy outcomes. The interoperability policy trajectory has been remarkably consistent across administrations: Meaningful Use under Obama, 21st Century Cures and information blocking under Trump I, the interoperability final rules and HTI series under Biden, and now this under Trump II. The personnel rotate, the branding changes, the press releases claim credit, but the regulatory vector keeps pointing the same direction.
The RFI in Section III.C explains the “why” here: the CMS “continues to receive stakeholder reports of incomplete or broken API implementations” They lay out three escalating tiers of potential action:
Tier 1: Mandatory testing and transparency. CMS floats requiring payers to run conformance tests using tools like ONC’s Inferno testing framework and either publish the results publicly or report them to CMS for publication. This is the lightest touch, essentially a “prove your API actually works” requirement.
Tier 2: Sandbox requirements. CMS says they’re “considering whether to propose to require impacted payers implement and maintain a sandbox environment for testing.” This would let app developers and trading partners verify their integrations against a payer’s API without needing a production connection. If you’ve ever tried to build against a payer API and found yourself staring at a blank wall with no test environment, this one’s for you.
Tier 3: Full certification through the ONC Health IT Certification Program. CMS explicitly asks whether ONC should establish certification criteria for payer API technology, whether certification should be voluntary or mandatory, and what a “roadmap” to get there would look like. They even ask the tell-me-when question: “If payer API technology certification is not appropriate at this time, how would CMS and ONC know when conditions exist to propose certification criteria and requirements?” That’s a question designed to build a record for future rulemaking. They want commenters to define the trigger so CMS can pull it later.
I expect this RFI to draw a lot of commentary. As a reminder, developers of certified health IT are information blocking actors. Payers and most payer technology vendors today are not! If payer API technology becomes certifiable through the ONC Health IT Certification Program, the vendors building that technology would become developers of certified health IT, which would make them information blocking actors subject to the same enforcement framework that currently applies to providers, EHR vendors, and health information networks (kind of). That's a significant expansion of who falls under information blocking and it would give ONC and OIG a direct enforcement mechanism against payer technology vendors who drag their feet on interoperability.
Right now, if a payer's API is broken, returns incomplete data, or quietly fails to conform to required IGs, the enforcement path is indirect: CMS can enforce against the payer as a program participant, but if the payer is not building themselves, the technology vendor building the API sits outside direct enforcement. Certification would change that. With certification, the vendor would have independent obligations, and independent liability.
Expect them to resist! When I wrote about HTI-2's payer certification proposals, I flagged the post-Chevron question: does ONC have the authority to certify payer technology when HITECH only gave them authority over EHR developers? Payer software vendors were never included in HITECH or subsequent legislation defining the certification program's boundaries. I noted at the time that payers "almost certainly" feel burdened by these requirements, that ONC has traditionally had "zero authority" over payers or their vendors, and that payers "have the resources and the stubbornness to pursue judicial action."
That said, the CMS is the final boss compared to the ASTP and has significantly more direct regulatory leverage over these payers than ONC does:
The CMS controls the Medicare Advantage contract.
The CMS conditions federal Medicaid matching funds on state compliance.
The CMS runs the federal exchange certification process for QHP issuers.
If CMS decides that API conformance testing is a condition of program participation, that's a much harder requirement to challenge than ONC stretching its HITECH certification authority to cover payer vendors it was never given jurisdiction over. Of course, payers could still make the argument that CMS’s programmatic authority covers how they administer benefits, not what technology they use to do it. Post-Loper Bright, that distinction carries more weight than it used to. Whether this rule, or a future certification requirement, is the the straw that breaks the camel’s back and provokes a challenge remains to be seen.
Wrap Up
This article is already long and we’ve only scratched the surface. In upcoming installments, I’ll dig into:
The payers who got away. CMS keeps expanding the “impacted payer” definition incrementally, and the FF-SHOP addition is welcome. But state-based exchange issuers, SBE-FP issuers, dental plans, and the entire employer-sponsored market remain outside the interoperability mandate. We’ll look at how big those gaps actually are and what it would take to close them.
The standards zoo. This rule has nearly infinite acronyms: FHIR, NCPDP SCRIPT, F&B, RTPB, X12N 278 (being replaced), X12N 270/271 (partially being replaced), US Core, SMART App Launch, CRD, DTR, PAS, and CDex. Keeping track of which standard applies to which transaction for which payer type for which category of drug is going to be its own full-time job. We’ll map it out.
The X12 counterattack. CMS is proposing to replace the X12N 278 with FHIR for prior authorization, three weeks after finalizing the X12N 275 for claims attachments. The X12 community will not take this lying down, and the comment period is going to be spicy. We’ll preview the arguments on both sides.
The benefit routing problem nobody has solved. CMS is proposing a dual-track drug PA framework (FHIR for medical benefit, NCPDP for pharmacy benefit) and then asked commenters how providers are supposed to know which track to use. The CRD CoverageInformation extension, NCPDP RTPB, and the F&B standard are all candidates, and none of them were designed for this purpose. We’ll look at what exists, what doesn’t, and what needs to be built.
The monolithic EHR advantage. If you control both the e-prescribing module and the CPOE workflow in a single platform, the dual-track architecture is a solvable problem. If you’re a standalone e-prescribing vendor or a best-of-breed shop, it’s a nightmare. We’ll explore how this rule’s architecture, probably unintentionally, reinforces the integrated EHR platform advantage.
The other four RFIs. The payer certification RFI is the wild one, but others have significant blast radius too. In particular, the Step Therapy RFI asks whether payers should honor step therapy determinations from a previous payer when a patient switches plans, which would give the Payer-to-Payer API its first killer use case. And in a move that could be a tailwind (or major threat) to existing ADT networks, CMS is asking about expanding ADT notification requirements to ACOs, payers, EMS, behavioral health, and social service providers (with explicit questions about TEFCA and the Da Vinci Unsolicited Notifications IG).
Stay tuned. There’s a lot of rule left to chew on.
I believe you are a fellow toddler parent - maybe you'll appreciate that I'm now singing Miss Rachel's "what's in the box? what could it be?" song ;) Thanks for the write-up. I hadn't flagged that RFI!
Banger post sir ! Appreciated.
I believe you are a fellow toddler parent - maybe you'll appreciate that I'm now singing Miss Rachel's "what's in the box? what could it be?" song ;) Thanks for the write-up. I hadn't flagged that RFI!