“We support HL7.” “We’re FHIR-enabled.” “Fully interoperable.” Arizona organizations evaluating health-IT products hear these phrases constantly, and they are nearly meaningless on their own. Interoperability is not a checkbox; it is a set of specific, testable capabilities. This field guide offers the questions that turn a vague claim into a verifiable answer — written from a vendor-neutral standpoint, because no product is named or endorsed here.
The problem with the claims
“HL7” names a standards organization that publishes many standards — HL7 v2 messaging, the C-CDA document standard, and FHIR among them. Saying a product “supports HL7” does not say which. “FHIR-enabled” can mean anything from a fully profiled, US Core-conformant API to a single read-only endpoint. The vagueness is not always deceptive, but it is never sufficient for a purchasing decision.
Questions for any interoperability claim
Ask these, and expect specific answers:
- Which standard, which version? HL7 v2? FHIR R4? C-CDA? “All of the above” deserves follow-up on each.
- For FHIR: which US Core version? Conformance to a stated US Core release is what makes endpoints behave predictably. A vendor who cannot name a version is telling you something.
- Which USCDI data is actually supported? This is the difference between an API that exists and one that returns the data you need.
- What has it been tested against? Real exchange partners, a recognized testing process, or only the vendor’s own lab? Untested conformance is a hope, not a fact.
- How does it handle identity and consent? Patient matching and consent enforcement are where interoperability gets dangerous if done poorly.
For device and supply integration, add
- How is device data coded? Are measurements carried with LOINC codes, or as uncoded values that cannot be trended or aggregated?
- Is UDI captured and carried forward? For device-bearing workflows, does the system hold the device identifier in a usable field, or only in free text?
What good answers look like
A capable vendor answers these crisply: a named standard and version, a stated US Core conformance, a specific USCDI baseline, evidence of testing against outside partners, and a clear account of identity and consent handling. Evasiveness on any of them is itself informative.
The neutral-table value
AzHeC names no products and recommends no vendors. What we offer Arizona organizations is the literacy to evaluate claims on their merits — to ask the questions above and recognize a real answer from a deflection. That literacy is the most durable protection a buyer has. Start with the plain-language primers in our Standards work area, and keep the glossary of Health IT terms handy as you read the responses you get back.