The most common mistake in FHIR planning is not technical. It is citing a version that stopped being current on New Year’s Day.

The RealityThree version numbers expired on 1 January 2026

⚠️

The Problem

A plan built on expired version numbers.

Scoping against US Core 3.1.1 and SMART 1.0.0, both of which stopped counting for certification this January.

🔧

The Solution

Scope against what is adopted now.

The current implementation guides, the right criterion, and a clear-eyed view of what certification does and does not give you.

✅

The Resolution

A project that matches what vendors actually ship.

Endpoints you can reach, data classes you can rely on, and no surprises at integration time.

The certification criteria, and the versions that count

Start with the regulation, because this is where the version numbers are binding rather than aspirational.

45 CFR 170.215 adopts HL7 FHIR Release 4.0.1, the HL7 FHIR US Core Implementation Guide STU 6.1.0, the SMART App Launch Implementation Guide Release 2.0.0, FHIR Bulk Data Access v1.0.0 STU 1, and OpenID Connect Core 1.0. Those are the standards behind the standardised API for patient and population services criterion.

The same section carries expiry dates, and they have passed. US Core STU 3.1.1 expired on 1 January 2026. SMART App Launch Release 1.0.0 expired on 1 January 2026. And under 45 CFR 170.213, USCDI v1 expired on 1 January 2026, leaving USCDI v3 as the version adopted for certification.

One small correction worth carrying: ONC’s own API resource guide renders the Bulk Data version as v1.0.1. The regulation says v1.0.0. Use the regulation.

What the standardised API criterion actually requires

The criterion is more specific than “has a FHIR endpoint”, and the specifics are what you can hold a vendor to.

The standardised API criterion requires a module to respond to requests for a single patient’s data according to the adopted FHIR and US Core standards, and to respond to requests for multiple patients’ data as a group using the bulk data specification. It requires the authorization server to enable an application to register, to issue a refresh token valid for no less than three months to applications using the confidential app profile, and to revoke an authorised application’s access at a patient’s direction within one hour of the request.

It also requires complete accompanying documentation containing at minimum API syntax, function names, required and optional parameters and their data types, return variables and their types or structures, and exceptions and exception handling methods and their returns — and that documentation must be available via a publicly accessible hyperlink without any preconditions or additional steps.

That last clause is the one to use. If you cannot find a vendor’s API documentation without signing something, that is not what the criterion describes.

The endpoint list is a different rule

A common miscitation, and it matters because it is the rule that tells you where to connect.

The obligation to publish service base URLs is not part of the API criterion. It sits in 45 CFR 170.404 as a Maintenance of Certification condition, requiring certified API developers to publish, at no charge, the service base URLs and related organization details, in FHIR Endpoint and Organization resource format, collected into a Bundle, reviewed quarterly and updated as necessary.

The same section sets the timeline a practice cares about when registering an app: authenticity verification must be completed within ten business days of receipt, and the developer must register and enable all applications for production use within five business days of completing that verification.

Bulk data access, USCDI, and what SVAP does not mean

Two practical points that decide what a project can actually pull.

Bulk data is the mechanism for population-level extraction, and the regulation mandates support specifically for the group-export operation. That is narrower than the full bulk specification, so a vendor meeting the criterion is not obliged to support every export shape the guide describes.

On data scope, USCDI v3 is the adopted version. Its data classes cover allergies and intolerances, health status and assessments, problems, assessment and plan of treatment, immunizations, procedures, care team members, laboratory, provenance, clinical notes, medications, unique device identifiers for implantable devices, clinical tests, patient demographics, vital signs, diagnostic imaging, encounter information, goals, and health insurance information.

And a distinction that costs projects time: the Standards Version Advancement Process lets developers voluntarily move to newer versions, and newer ones are approved. Voluntary is the operative word. SVAP approval is not a requirement, and the regulatory floor remains US Core 6.1.0. A vendor shipping a newer guide is ahead of the floor, not compelled to be there, and another vendor sitting at the floor is compliant. Reconciling two systems at different points on that curve is ordinary interface work.

Prior authorization, and a rule that is not about you

This is the federal rule generating the most noise, and most practices have its scope wrong.

CMS-0057-F, the Interoperability and Prior Authorization final rule, applies to Medicare Advantage organizations, state Medicaid and CHIP fee-for-service programs, Medicaid managed care plans, CHIP managed care entities, and qualified health plan issuers on the federally facilitated exchanges. That is payers. A practice is affected by what those payers build, not by an obligation of its own, with one exception: an attestation-based electronic prior authorization measure that MIPS eligible clinicians report beginning with the CY2027 performance period.

The payer API requirements land primarily on 1 January 2027, with some operational provisions from 1 January 2026, including decision timeframes of 72 hours for expedited and seven calendar days for standard requests, and a requirement to give a specific reason for denials.

Now the awkward part, and it is worth knowing before you plan around it. CMS-0057-F names US Core STU 3.1.1 and SMART App Launch 1.0.0 among its required standards. Those are the versions whose certification adoptions expired on 1 January 2026. The two federal frameworks are not aligned on version, and anyone telling you they are has not read both.

Information blocking, briefly

One point relevant to a practice asked for API access it cannot or will not provide.

The knowledge standard differs by actor. For a health care provider, information blocking requires that the provider knows the practice is unreasonable and is likely to interfere with access, exchange or use of electronic health information — a higher bar than the knows-or-should-know standard applied to developers and networks. Where a practice genuinely cannot deliver what was asked, the infeasibility and manner exceptions are usually the relevant ones, and the reasoning should be recorded at the time.

• Check the version before anything else. Three expired on 1 January 2026.
• Ask for the documentation link. No preconditions is the rule.
• Endpoints come from 170.404, not the API criterion. Different rule, quarterly updated.
• SVAP is voluntary. The floor is still US Core 6.1.0.

Qventive works as a FHIR API medical practice company in New Jersey, and this kind of integration usually runs through our interface engine rather than as a bespoke build per connection.

Where a project touches how the clinical system is configured, that sits with EHR consulting and managed IT support, and every new endpoint belongs in your HIPAA risk analysis before it goes live.

FHIR in practice: common questions