HL7, FHIR, and health information exchange for agency systems

Reference article · 5 min read

A county behavioral health agency replacing its electronic health record, or a public health division that needs lab results and case reports to arrive automatically, will hear that every product on the market is interoperable. That word covers three unrelated technologies, several networks, and a great deal of per-interface labor. Interface quotes vary widely for no visible reason when the solicitation asked for interoperability in general instead of naming specific messages moving in a specific direction to a named partner.

Standards, implementation guides, and federal programs in this area change regularly, so confirm current versions and obligations with the standards body, your state health department, and your counsel.

HL7 v2: the traffic that already exists

Most clinical data still moves as HL7 version 2 messages: pipe-delimited text, usually sent over a TCP connection using minimal lower layer protocol and acknowledged message by message. Versions 2.3.1 and 2.5.1 are both common, and two partners in the same building often differ. The message types matter more than the version:

• ADT. Admit, discharge, transfer, registration, and demographic updates. Also the basis of most syndromic surveillance feeds.
• ORU. Observation results, which is how lab results arrive, including electronic laboratory reporting to public health.
• ORM and OML. Orders placed to a lab or another ancillary system.
• VXU and QBP/RSP. Immunization updates to, and queries against, a state immunization information system.

HL7 v2 is a framework more than a fixed format. Optional fields, local code sets, and custom Z-segments mean two systems that both claim 2.5.1 still need mapping work. That mapping is the real content of an interface quote.

C-CDA documents and FHIR APIs

C-CDA is an XML clinical document: a continuity of care document, referral note, discharge summary, or care plan, carrying narrative alongside coded entries. Documents suit transitions of care, usually sent by Direct secure messaging or retrieved through a health information exchange.

FHIR is a web API. Data is exposed as resources such as Patient, Encounter, Observation, and Condition over REST with JSON, secured with OAuth 2.0. R4 is the version most implementations target. FHIR by itself is permissive, so profiles do the constraining work: US Core specifies which elements are required and which code systems apply, tracking the data classes in USCDI. Certified electronic health records are generally expected to expose a standardized FHIR API using US Core, including bulk export, though those criteria are set by federal rule and do shift.

FHIR does not retire your v2 feeds. Lab results and ADT will keep arriving as v2 for years. Plan to run both.

The networks: state HIEs, QHINs, and public health gateways

• State or regional HIE. Many states operate or designate one. It may offer record lookup, notification when a client is admitted or discharged, and one connection in place of point-to-point interfaces with every hospital.
• National frameworks. Carequality, CommonWell, and eHealth Exchange have carried query-based exchange for years. Under TEFCA, qualified health information networks exchange under a common agreement with defined purposes, including public health. Participation terms continue to evolve.
• Public health gateways. Immunization registries, laboratory reporting, syndromic surveillance, and electronic case reporting each have their own onboarding path and queue. Treat each as a project, not a checkbox.
• Direct secure messaging. Addressed, encrypted transport for documents. Limited, but far cheaper than a custom interface.

Writing the requirement: name the interfaces

Replace "the system must be interoperable" with an interface inventory. For each interface, state:

1. Trading partner and direction: inbound, outbound, or both.
2. Message or document type and standard version, or the FHIR resources and profiles.
3. The implementation guide that governs it, by name and release.
4. Transport and security: MLLP over a site-to-site VPN, SFTP, Direct, or REST with OAuth 2.0.
5. Terminology expected, such as LOINC, SNOMED CT, RxNorm, ICD-10-CM, and CVX.
6. Volume, frequency, and acceptable latency.
7. Who performs mapping, who performs testing, and who owns the connection after go-live.

Price interfaces you cannot enumerate yet as a unit rate in the same solicitation, so later additions are competitively priced rather than sole-source change orders.

Testing, onboarding, and who pays for changes

Require a test environment with synthetic data that remains available after go-live, sample messages from the vendor before award, and acceptance based on end-to-end flow with the actual trading partner rather than a demonstration. Public conformance and validation tools exist for several of these standards and can be named in the acceptance criteria.

Then address change. Trading partners revise specifications, registries update guides, and federal criteria move. State in the contract which work needed to stay conformant with a named guide is included, which is billable, and at what rate. Require that interface configurations, maps, and documentation belong to the agency and are exportable.

Consent and what you may send

Technical capability is not authority. HIPAA, state health privacy law, and, for substance use disorder treatment records, the federal Part 2 rules shape what may be disclosed, to whom, and with what consent. Behavioral health programs often need consent handling that general-purpose products manage poorly. Ask how the system records, enforces, and revokes consent at the interface level, and confirm the rules with counsel, since they have been amended recently.

What to ask vendors

• Which of our named interfaces have you built before, and with which specific systems?
• Do you use an interface engine, and can agency staff view and maintain the channels?
• What is included in the base price, and what triggers a new interface fee?
• How do you detect and alert on a stalled feed, and who watches it?
• What happens to our mappings and documentation at contract end?

HQT works with state and local agencies on integration architecture and interface specification of the kind described here.

Frequently asked questions