FHIR R5 is a release—not a production migration verdict

Publication answers one question

The permanent HL7 publication establishes that FHIR R5 exists as version 5.0.0 and provides the specification architects can inspect. It does not answer whether a particular network, implementation guide, regulator, vendor, or trading partner is ready for an R5 production exchange. Version availability and ecosystem readiness are different claims.

Buyers should therefore separate standards assessment from migration authorization. The first asks what changed and what maturity or normative status applies to the artifacts the organization uses. The second asks whether the complete exchange community can implement, test, govern, and support the chosen version without breaking a required workflow.

The dependency graph controls the decision

A production interface rarely depends only on the base FHIR release. It may use one or more implementation guides, profiles, extensions, terminology packages, value sets, capability statements, subscriptions, validation tooling, and partner-specific agreements. Each dependency can carry its own version and compatibility boundary.

A credible product evaluation should inventory those dependencies and show which are native, translated, proxied, or unsupported. Buyers need explicit version negotiation, package provenance, terminology handling, and validation behavior. A platform that can parse an R5 resource has not necessarily demonstrated the business transaction or conformance profile the buyer must operate.

Migration needs evidence at the semantic boundary

Syntax conversion can hide semantic loss. A field added, removed, renamed, constrained, or represented differently may affect clinical meaning, workflow state, search, decision support, analytics, consent, or downstream documentation. Buyers should select the resources and operations that carry material decisions and test both directions across the proposed boundary.

The evidence should include source and target instances, profiles, validator versions, terminology packages, transformations, exceptions, round-trip behavior where relevant, and human review of the business meaning. Known gaps need an owner and operating control. A successful HTTP exchange is transport evidence, not proof that the intended meaning survived.

Use a staged compatibility proof

A bounded proof can compare the current production stack with an R5 candidate for one end-to-end workflow. The provider should demonstrate dependency resolution, conformance validation, terminology, access control, audit context, error handling, partner negotiation, rollback, and monitoring. The buyer should define which evidence would authorize a pilot and which dependencies keep the interface on its existing release.

HL7 publishes the specification but does not endorse a vendor or direct an organization to migrate. Applicable implementation guides, contracts, regulations, partner capabilities, clinical safety processes, and local governance remain controlling. The useful buyer outcome may be migration, dual-version support, a translation boundary, or a documented decision to wait.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.