HEALTH INTEROPERABILITYREVIEW

Move data. Preserve meaning. Prove the exchange.

Coverage desk

Exchange Governance Evidence

Source-backed reporting and analysis connected to the companies, capabilities, authorities, and operating domains it affects.

VSAC and PHIN VADS serve different value-set programs

NLM's VSAC is the central authority and repository for official CMS electronic clinical quality measure value sets. CDC's PHIN VADS distributes value sets tied to public-health and HL7 implementation-guide use. Teams should identify the governing program before choosing, versioning, or migrating terminology content.

Clinical Architecture PIQXL scores need use-case acceptance rules

Clinical Architecture says PIQXL Gateway uses its PIQI Framework to score exchanged patient information and highlight root causes of data-quality issues. A score can direct investigation, but a receiving organization still has to define the exchange population, the measure, the threshold, the exception owner, and whether a particular record is fit for its intended use.

Kno2 Direct payloads need receiver ingestion contracts

Kno2’s official Direct Secure Messaging page describes exchange of PDFs, C-CDA documents, HL7 v2 messages, and FHIR JSON resources over a Direct route. That range makes recipient, payload type, patient match, parsing, acknowledgement, and clinical filing separate obligations; secure delivery is not proof that a receiving workflow used the data correctly.

b.well consumer-mediated exchange needs consent-version receipts

b.well Connected Health presents a consumer-mediated health-data network and says patient consent is central to some life-sciences workflows. Consent should be a versioned, purpose- and recipient-specific authorization with downstream receipts; a connected record, app session, or earlier approval does not establish that every later acquisition, disclosure, normalization, or use remains authorized.

Aidbox tenants need explicit FHIR-version boundaries

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.

RCE QHIN lists need designation-and-route timestamps

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.

TEFCA exchange needs agreement-and-SOP version pairing

The Recognized Coordinating Entity describes the TEFCA Common Agreement as a contract supported by technical infrastructure, governance, and standard operating procedures, with Version 2 adding FHIR-based exchange. Each production exchange still needs the exact agreement, SOP, technical framework, role, purpose, and implementation version that governed it.

Moxe data exchange needs request-to-use lineage

Moxe presents secure clinical-data exchange connecting payers and providers and transforming data for payment and operational uses. Buyers still need to reconstruct the request purpose, permitted scope, source selection, transformation, provenance, delivery, acceptance, and downstream use for every exchange.

CMS API version advancement needs endpoint-by-endpoint compatibility evidence

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.

An eHealth Exchange query needs permitted-purpose and responder-scope evidence

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.

CommonWell pairs a master person index with record location—but retrieval is not identity proof

CommonWell's official site presents a nationwide exchange platform with a Master Person Index, Record Locator Service, Data Broker, and Trust Network. Those services can support discovery and retrieval across connected organizations, but a returned document does not by itself prove that every identity attribute is correct, the record belongs to the intended person, or the data is fit for a clinical decision.

Epic offers record exchange, patient-directed APIs, and partner access—but those routes are not interchangeable

Epic's interoperability page describes Care Everywhere record exchange, FHIR-based patient-directed APIs, Community Link access, government connections, health-plan data, referrals, Share Everywhere, and public interface specifications. Each route serves a different actor and purpose, so buyers need route-specific authority, payload, identity, workflow, and acceptance tests.

TEFCA entry can run through a QHIN, Participant, or Subparticipant

The Recognized Coordinating Entity describes a network-of-networks hierarchy in which organizations may connect directly to a QHIN or use a Participant or Subparticipant path, with contracts and roles preserved at each layer.