ONC finalized updated versions of seven FHIR implementation guides — CRD, DTR, PAS, CARIN for Blue Button, PDex US Drug Formulary, PDex Plan Net and CDex — in the FY2027 IPPS final rule, effective October 1, 2026. They replace the versions adopted last year in HTI-4. The provisions were proposed in CMS-0062-P, which is still proposed, which means the standards for a rule that is not final were adopted through a rule that is.
If you have been tracking implementation guide versions through the CMS-0062 docket, you have been watching the wrong document.
ONC finalized the adoption of seven updated FHIR implementation guides in the FY2027 IPPS final rule (CMS-1849-F), published August 4, 2026, effective October 1, 2026. Not in an interoperability rule. In the acute care inpatient payment rule. The provisions were originally proposed in the 2026 CMS Interoperability Standards and Prior Authorization for Drugs proposed rule — CMS-0062-P, published April 14, 2026 — and CMS-0062 has not been finalized.
That is four weeks out.
Read these off carefully, because a wrong minor version in a build plan is a re-validation cycle:
HL7 FHIR Da Vinci — Coverage Requirements Discovery (CRD) IG, Version 2.2.1 – STU 2.2. Documentation Templates and Rules (DTR) IG, Version 2.2.0 – STU 2.2. Prior Authorization Support (PAS) FHIR IG, Version 2.2.1 – STU 2.2. CARIN Consumer Directed Payer Data Exchange (CARIN IG for Blue Button), Version 2.2.0 – STU 2.2. Da Vinci Payer Data Exchange (PDex) US Drug Formulary IG, Version 2.1.0 – STU 2.1. Da Vinci PDex Plan Net IG, Version 1.2.0 – STU 1.2. Da Vinci Clinical Data Exchange (CDex) IG, Version 2.1.0 – STU 2.1.
Note the pattern in the prior-auth trio: CRD and PAS are patch releases (2.2.1), DTR is a minor (2.2.0), all three at STU 2.2. That is a coordinated release train, not seven independent version bumps, and it matters for sequencing — you cannot upgrade PAS and leave DTR where it was and expect the documentation-gathering handoff to behave.
ONC's own language is the important part: where it previously adopted a version of one of these standards in the HTI-4 final rule — released July 2025 as part of the FY2026 IPPS final rule, CMS-1833-F — it has finalized to replace the previously adopted versions with the updated versions upon the effective date of the FY2027 IPPS final rule, October 1, 2026.
Replace, not add. There is no stated dual-version window in the fact sheet.
So the same agency, through two consecutive years of the same annual inpatient payment rule, has adopted one set of versions and then replaced it fourteen months later. If your certification or build work was scoped against HTI-4 in the back half of 2025, that scope has a shelf life measured in weeks.
Three different things reference these IGs, and they are at three different stages of finality. Conflating them is where teams are getting this wrong.
Adopted and final: the standards themselves, via CMS-1849-F, effective October 1. ONC adopted them on behalf of HHS.
Final and binding on developers: ONC health IT certification criteria for electronic prior authorization reference these standards. A certified health IT module that must conform to an adopted standard now has a different target as of October 1.
Proposed only: the payer API requirements in CMS-0062-P that reference these versions. The comment period on CMS-0062 closed in June 2026 and no final rule has published.
The consequence is asymmetric and worth being precise about. If you are a health IT developer carrying certification for e-prior-auth criteria, the version change is directly load-bearing on October 1. If you are a payer building toward CMS-0057-F, the adoption changes what "the adopted version" means in every downstream reference, but the requirement that would explicitly bind your APIs to these versions is in a proposed rule that has not landed.
Which brings up the thing nobody says out loud about CMS-0057-F: it requires four FHIR APIs — Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization — by January 1, 2027, for Medicare Advantage organizations, state Medicaid and CHIP FFS and managed care plans, and QHP issuers on the federally facilitated exchanges. It does not, in its own text, mandate conformance to a specific Da Vinci IG version. The IGs were recommended.
If that holds, the October 1 change is not a compliance cliff for payers. It is a specification-drift problem, which in practice is worse, because compliance cliffs have dates on a slide and specification drift shows up as a failed connectathon in November.
The calendar is unusually unforgiving this cycle. October 1: seven IG versions replace their predecessors. January 1, 2027: four production APIs under CMS-0057-F. Thirteen weeks between them, spanning a holiday freeze that most organizations honor from mid-December.
Three concrete things to do with the next four weeks.
First, inventory your version pins. Every place a package version, a profile URL, a CapabilityStatement, or a vendor contract names one of these seven IGs, write it down. If you cannot produce that list in an afternoon, that is the finding.
Second, separate your certification exposure from your API exposure, because the October 1 date binds one and merely re-anchors the other. Teams treating a single deadline are either over-scoping payer work or under-scoping developer work, and both are expensive in different directions.
Third, ask your vendor which version their next release targets and what their support window is for the HTI-4-era versions. If the answer is that they are waiting for CMS-0062 to be finalized before moving, that answer was reasonable in July and is not reasonable now, because the standards moved without the rule.
The versions changed in a payment rule. The requirement that points at them is still a proposal. Where does your build plan think it is pointing?
Discover how Addie helps health systems, post-acute providers, and payers improve throughput, reduce avoidable days, and deliver better transitions of care.
Get Started
