Health Level Seven

HL7 can mean an organization or a standard

HL7 International develops standards for health information exchange. In everyday vendor discussions, “HL7” may instead mean a specific interface, a Version 2 message, a FHIR API, a Clinical Document Architecture document, or another HL7 product.

Ask the speaker to name the artifact. The answer should include version, implementation guide or profile, message or resource type, terminology, transport, and partner. A broad label cannot support a purchase or release decision.

FHIR is one part of the HL7 family

FHIR uses modular resources and modern API patterns. ASTP/ONC describes it as an API-focused standard for representing and exchanging health information. Earlier HL7 messaging patterns remain widely deployed for event-driven exchange.

An ABA practice may encounter different approaches across referrals, eligibility, authorizations, appointments, clinical data, claims, or reporting. The receiving workflow determines which standard, guide, and data are appropriate.

Seven layers explain the name, not the implementation

The name refers to the application layer in the Open Systems Interconnection model. That history does not mean an HL7 specification supplies every network, identity, privacy, security, or operational control.

Transport may use an API, secure file route, messaging engine, or another mechanism. Authentication and authorization can sit elsewhere. A practice still needs to decide who may exchange which data, for what purpose, under which authority, and with what evidence.

Create an interface contract

For each HL7 exchange, record:

• business purpose, sender, receiver, owners, and environments
• standard family, version, implementation guide, profile, and artifact type
• required and optional fields, identifiers, code systems, units, and timestamps
• transport, authentication, authorization, encryption, and logging
• event trigger, expected volume, acknowledgement, retry, and duplicate behavior
• validation rules, exception queue, correction path, reconciliation, and monitoring
• downstream action, qualified decision-maker, and safe hold condition

Treat proprietary extensions and local codes as governed mappings. Record who owns them and how a version change is tested.

Syntax and meaning are different gates

A message can follow the expected structure and still carry the wrong meaning. “Service date,” “authorization status,” “provider,” and “location” can have different operational definitions. Terminology versions, null values, modifiers, timezones, and identifier namespaces can change interpretation.

Define a source-to-destination map with examples and acceptance criteria. Involve the people who own the clinical, payer, scheduling, billing, or privacy meaning. Technical staff should not invent clinical semantics to make a validation error disappear.

Define acknowledgements and exception ownership

An acknowledgement can confirm transport, structure, or business acceptance depending on the standard and partner. Name the artifact, sender, receiver, control number, response window, and meaning. Avoid using “accepted” without the layer.

Every negative acknowledgement, rejected resource, unmatched identity, and downstream processing failure needs an owned queue. Record the original content, error, received time, retry history, correction, and final disposition. Set alert and aging thresholds from the consequence. A delayed demographic update and a missing safety record can require different escalation. Reconcile totals across sent, received, accepted, rejected, held, and completed states so silent loss cannot look like successful delivery.

A fictional interface inventory

Samira's practice reviews 10 active interfaces. Eight have a current standard, version, message or resource type, mapping, owner, security route, exception workflow, and test result: 8 of 10, or 80%.

One partner upgraded a profile without completing regression tests. One legacy feed has no owner for rejected messages. Both remain open with safe holds and due dates. The percentage describes inventory completeness, not interoperability, accuracy, or clinical safety.

Test the complete workflow

Use authorized test data and include successful, missing, duplicate, corrected, late, out-of-order, and rejected cases. Confirm acknowledgements and error details. Compare source values, transmitted content, received content, and downstream state.

Measure interfaces passing every declared release gate divided by interfaces due for review. Report syntax failures, semantic mismatches, delivery failures, and unworked exceptions separately. Availability alone can hide a queue full of rejected records.

When a standard, guide, vendor, payer, or workflow changes, rerun affected tests. Preserve old mappings while historical records, corrections, claims, or appeals still depend on them.

A standard is one layer of governance

HL7 conformance does not establish a permitted disclosure, minimum-necessary decision, business-associate relationship, security posture, payer acceptance, or clinical fitness. Those decisions arise from their own sources and qualified roles.

Owners should know which interfaces contain ePHI, which vendors maintain it, how access is removed, where logs live, how incidents are reported, and how data is returned or deleted at exit. Keep a manual or alternate process for interface downtime and verify reconciliation afterward.