Start with the part that is final—and the part that is not
ONC said on July 31 that HHS finalized seven health-IT standards and implementation specifications through the FY 2027 Hospital Inpatient Prospective Payment System final rule. They cover electronic prior authorization, payer-provider exchange, consumer access to payer data, drug-formulary exchange, provider directories, and clinical-data exchange. Where the action replaces a version previously adopted through the HTI-4 final rule, the new version takes effect October 1, 2026.
That is a standards decision. ONC also says those standards are referenced in payer API requirements that CMS proposed separately in CMS-0062-P. Those proposed payer requirements are not turned into final requirements merely because HHS finalized the underlying standards. Keep the two statuses on separate lines in any project plan: adopted standard and still-proposed use requirement.
The version is now part of the claim
The final rule names seven implementation guides. Three address prior authorization; four address payer data, formularies, directories, and clinical-data exchange. A vendor saying it supports FHIR, Da Vinci, prior authorization, or payer data has not yet identified which of these jobs—or which release—it means:
- Da Vinci Coverage Requirements Discovery, version 2.2.1 (STU 2.2).
- Da Vinci Documentation Templates and Rules, version 2.2.0 (STU 2.2).
- Da Vinci Prior Authorization Support, version 2.2.1 (STU 2.2).
- CARIN Consumer Directed Payer Data Exchange for Blue Button, version 2.2.0 (STU 2.2).
- Da Vinci Payer Data Exchange US Drug Formulary, version 2.1.0 (STU 2.1).
- Da Vinci Payer Data Exchange Plan Net, version 1.2.0 (STU 1.2).
- Da Vinci Clinical Data Exchange, version 2.1.0 (STU 2.1).
Do not merge the August 29 and October 1 pathways
There is a second date in the standards calendar. ONC announced the three updated prior-authorization guides among its 2026 SVAP-approved versions on June 30. They become available for voluntary certification on August 29. A developer updating an already certified module through this pathway must provide advance notice to clients and its ONC-authorized certification body; ONC also ties the updated standards to the applicable real-world-testing plan and results.
The October 1 final-rule effective date and the August 29 voluntary-certification date are different mechanisms. ONC also says updated test tools and procedures for the 2026 SVAP standards will be available by December 2026. Ask which route a supplier is relying on, what evidence is available on the date of the claim, and whether an announced upgrade has actually reached the environment your practice would use.
Give every version change its own ledger row
A small consultant pharmacy practice does not need to reproduce the federal standards table. It does need a compact change record that stops an old version, a future version, and a live version from being described as the same capability.
- Named standard: the full guide, version, maturity label, profile, and certification criterion when one is claimed.
- Pathway and dates: final-rule adoption or SVAP, the applicable availability or effective date, and the source checked.
- Current state: the version running in the named module and environment today, with evidence and observation date.
- Proposed state: the version in a notice or roadmap, intended release date, and whether it is certified, available, configured, or still planned.
- Affected seam: the source and destination products, modules, and organizations that must remain compatible during the change.
- Open transition: unanswered compatibility, notice, mapping, support, rollback, or timing questions, each with an owner and review date.
Make the upgrade notice reconcile with the ledger
When a supplier sends an upgrade notice, compare it with the ledger rather than overwriting the existing row. Does the notice name the guide and version? Which module and customers are affected? Is the date a certification option, general availability, customer rollout, required change, or retirement date? What has the other endpoint confirmed? Preserve the earlier answer until the transition is complete.
If the two sides will run different versions for a period, record the supported combination and its evidence. If compatibility, sequencing, or customer work remains unclear, leave it open. The ledger is not proof that an interface performs correctly; it is the control that keeps the version claim, date, and unresolved dependency visible while the broader implementation evidence is gathered.
Let the new rule change the question, not answer it
A standard's adoption can make more consistent exchange possible. It does not demonstrate a live interface for an independent consultant pharmacist, prove that two named products interoperate, or finalize every policy that references the standard. The immediate buying question is narrower: which exact version is current, which change is actually scheduled, and what remains unresolved between them?