Move data. Preserve meaning. Prove the exchange.
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’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.
iNTERFACEWARE says it supports both Iguana 6 and the newer IguanaX, plans to evolve them gradually, and does not intend to force disruptive migrations. Continued product support is important evidence, but each production interface still needs its own version, dependency, security, test, change, stay-or-migrate decision, parallel-run result, rollback plan, and operational acceptance.
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.
iNTERFACEWARE says it supports both Iguana 6 and the newer IguanaX, plans to evolve them gradually, and does not intend to force disruptive migrations. Continued product support is important evidence, but each production interface still needs its own version, dependency, security, test, change, stay-or-migrate decision, parallel-run result, rollback plan, and operational acceptance.
Qvera says its interface engine's AI Companion can generate mapping scripts, debug errored messages, and troubleshoot connectivity across an engine that supports HL7, FHIR, DICOM, X12, and other formats. Generated code can accelerate integration work, but it remains a proposed transformation until representative messages, versions, semantics, exceptions, privacy controls, and production receipts are validated.
CMS-0057-F requires impacted payers to share specified patient data through a Provider Access API with in-network or enrolled providers who have a treatment relationship, while maintaining attribution and allowing patients to opt out. Endpoint access alone cannot establish that a provider-patient-data relationship is currently permitted.
1upHealth describes a public FHIR R4 formulary API that publishes covered drugs, tiers, restrictions, alternatives, and cost information. A discoverable API response is not an individualized pharmacy claim or a guarantee of current member coverage unless source, plan, drug, effective period, synchronization, restrictions, and uncertainty are retained.
Microsoft says Azure Health Data Services can extract, redact, or replace protected-health-information entities in unstructured text for secondary use. A completed job does not establish that the output is anonymous, permitted for the intended recipient, fit for the analysis, or safe to link with other data.
TEFCA designation, network participation, exchange purpose, technical route, and local production reach are separate facts. The market map keeps organizational role and evidence class visible.
Read the market record →FHIR version, profile, authorization pattern, terminology, endpoint behavior, testing, and ongoing operations must be evaluated together; a generic FHIR claim cannot answer those questions.
Read the market record →Patient matching, provenance, vocabulary normalization, consent, and data-quality controls determine whether transported data can be trusted and used in the receiving workflow.
Read the market record →Routing, authorization, monitoring, exception handling, change control, endpoint discovery, support ownership, and recovery determine whether exchange remains usable after implementation.
Read the market record →Readiness records should be separated by API, implementation guide, source system, responsible party, test status, production status, and exception process.
Provider records should distinguish public-health connection from bidirectional production use, data quality, identity services, and operating support.
Developers and buyers need separate records for the mandatory baseline, voluntarily advanced version, and version actually deployed in a customer environment.
TEFCA has become a material exchange channel, but buyers still need organization-specific evidence for reach, exchange purpose, data quality, operating performance, and governance.
Enterprise exchange programs need explicit document-ingestion, validation, reconciliation, and extraction evidence in addition to FHIR API capability.
FHIR platform and integration claims should identify both the base FHIR release and the exact US Core guide version, supported profiles, tests, and production status.
The research connects the provider market, normalized capabilities, authority records, operating domains, and source limitations rather than presenting a score or universal winner.
Read the report →