Move data. Preserve meaning. Prove the exchange.
Source-backed reporting and analysis connected to the companies, capabilities, authorities, and operating domains it affects.
Health Samurai says Aidbox supports FHIR STU3, R4, R5, and R6, more than 500 implementation guides, custom profiles and terminology, and multitenant access control. Supporting that range does not establish which release, guide, profile, value set, authorization rule, or endpoint governs a particular tenant and exchange.
The Recognized Coordinating Entity distinguishes organizations that completed QHIN onboarding and are designated for TEFCA exchange from candidates still onboarding, and says the rolling list can change. A roster snapshot does not establish the route, relationship, exchange purpose, production status, or time that governed a particular transaction.
Microsoft says Azure API for FHIR retires September 30, 2026. The deadline calls for tested migration and rollback evidence—not assumed successor equivalence.
CMS lists standards and implementation-guide versions for Patient Access, Provider Access, Payer-to-Payer, Provider Directory, and Prior Authorization APIs and describes conditions for using updated versions. Version advancement can reduce technical stasis, but each payer still needs evidence that the chosen endpoint contract, data, authorization, clients, and transition preserve required access.
eHealth Exchange operates a nationwide health-information network and is a Designated QHIN under TEFCA, with official materials describing query, document exchange, public-health, federal, and other services. A successful query can prove that a request traveled and produced a response, but it does not by itself establish that the purpose, patient match, responders, data classes, and resulting use were appropriate and complete.
Firely presents server, API, validation, and conformance tooling for FHIR implementations. An endpoint can accept and return resources while still missing required profiles, terminology, search behavior, authorization, provenance, or production workflow semantics.
A common trust framework can govern network participation and exchange, while each disclosure still depends on the permitted purpose, requester, patient, data, law, policy, and technical event.
The current published specification gives architects a version to assess, but adoption still depends on implementation-guide dependencies, partner support, artifact maturity, and conformance evidence.
HL7's current PDex guide maps payer clinical, claims, encounter, and prior-authorization data into FHIR exchange. Trust depends on preserving source mappings, versions, provenance, and reconciliation.
HL7's current published guide separates export kickoff, status polling, completion manifest, files, and errors. A working endpoint is only the start; buyers need the whole job and its authorization boundary.
HL7 lists SMART App Launch 2.2 as the current published authorization guide. A FHIR endpoint still needs scoped access, token controls, and operating evidence.
