HL7 standards are often described as a technical issue, but healthcare leaders make decisions that shape whether data exchange works in daily operations. Knowing how HL7 v2, FHIR, and related standards differ helps teams ask clearer questions about workflows, data meaning, testing, and responsibility before an integration begins.

Schedule a demo

What do HL7 standards define?

Health Level Seven (HL7) standards describe ways to structure, encode, and exchange health information between systems. The term does not refer to one format or a plug-and-play connection. It covers a family of standards, implementation guidance, and supporting specifications used for different exchange patterns and purposes.

A standard gives systems a shared set of expectations. It does not, by itself, ensure that two organizations use the same fields, local codes, workflow rules, or interpretation of a data element. An interface still needs configuration, mapping, testing, and operational ownership. A message can be technically valid yet fail to support the receiving team’s actual process.

That distinction matters when evaluating an electronic medical record (EMR), electronic health record (EHR), imaging, or virtual-care connection. Ask not only, “Does it support HL7?” Ask which version or standard, which use case, what data moves in each direction, and how the parties verify the meaning and handling of that data. For background on the organization and its work, see HL7’s FHIR implementation guide for NHSN reporting, a specific example of implementation guidance supporting a defined reporting purpose.

Which HL7 standards are most likely to come up?

Healthcare leaders commonly encounter HL7 v2 messaging, Clinical Document Architecture (CDA), and Fast Healthcare Interoperability Resources (FHIR). They are related through the broader goal of health information exchange, but they are not interchangeable versions of the same interface. Each has different structures and implementation patterns.

HL7 v2: event-oriented messages

HL7 v2 is widely used to exchange structured messages between healthcare applications. A system may send a message when an event occurs, such as an admission, a change in patient details, an order, or a result. The receiving system processes the message according to the agreed interface and local configuration.

In practice, v2 implementations can vary. Organizations may use different optional segments, local codes, field conventions, and workflow assumptions. Therefore, a vendor’s statement that it “supports HL7 v2” does not answer whether it supports the specific message types and fields your teams require. Request the interface specification and examples relevant to your use case.

FHIR: resources and defined exchange patterns

FHIR organizes health information into resources that can be exchanged through defined interfaces and implementation patterns. A project may use FHIR to retrieve, create, or update selected information, depending on the participating systems and the agreed scope. FHIR is a family of specifications, not a guarantee that every system exposes the same data or supports the same capabilities.

Implementation guides narrow a standard to a particular use case, jurisdiction, or program. They can specify profiles, terminology, and exchange expectations. For example, the HL7 FHIR implementation guide for NHSN reporting is explicitly about standards for reporting to the National Healthcare Safety Network. That kind of use-case detail is why buyers should ask which guide and version a vendor supports, not only whether it supports FHIR.

CDA: structured clinical documents

CDA is used to represent clinical documents in a structured form. It is document-centered: information is packaged as a clinical document, rather than only exchanged as a series of individual event messages or resource requests. A project that exchanges summaries or other documents may have different requirements from one that transmits discrete events.

These standards can coexist in a health IT environment. A system may use one approach for a particular workflow and another for a separate exchange. The right choice depends on the participating systems, the information to be exchanged, and the operational need, not on a simple ranking of standards as old or new.

How do HL7 v2 and FHIR relate?

HL7 v2 and FHIR address health information exchange through distinct models. A v2 interface commonly sends structured messages in response to events. FHIR commonly represents information as resources and supports defined interactions. Neither label alone tells a buyer whether a particular clinical or administrative workflow is supported.

Teams may need to connect newer applications to systems that already rely on established v2 interfaces. In such cases, the practical question is how the integration handles each system’s data and workflow. It may involve translating between formats, applying mappings, and deciding which system is authoritative for a particular field. Do not assume that a format conversion preserves all meaning automatically.

Likewise, a FHIR endpoint is not proof that all desired information is available, current, or usable for every purpose. Confirm the resources, operations, profiles, terminology, and access conditions in scope. For more background on the broader standard, see this guide to what FHIR means in healthcare. For a project-focused evaluation, compare those details with the organization’s FHIR guide for healthcare leaders and avoid treating either as a substitute for a system-specific specification.

What should buyers compare across standards?

Start with the exchange requirement, then compare standards and implementation options against it. A useful discussion identifies the workflow, the systems involved, the direction of exchange, the data elements, and what users need to do with the information. The table below is a starting point; actual capabilities depend on the systems, versions, configuration, and use case.

Use this comparison to make vendors explain the fit to your actual workflow. A table of supported standards is a useful first screen, not an acceptance test or evidence that a complete interface is ready to operate.

How should teams define data mapping?

Data mapping explains how a value in one system corresponds to a value in another. It includes more than matching field names. Teams need to clarify format, code systems, units where relevant, identifiers, allowed values, null or missing-value behavior, and what happens when a source value has no direct destination.

For each field that matters, identify the source of truth and the expected receiving behavior. For example, ask which system owns a patient or encounter identifier for the workflow; do not assume two similar-looking identifiers have the same meaning. Determine whether a receiving application rejects, queues, or accepts a message with an unknown code. Confirm whether corrections or cancellations are represented and handled.

Clinical and operational representatives should review mappings alongside interface analysts. A technically valid transformation may still be unsuitable if it changes the meaning or timing of information. Keep a version-controlled mapping document that records decisions, open questions, and approval owners. When an application update changes a field or workflow, revisit the affected mappings rather than assuming the interface remains equivalent.

Where the project includes imaging, keep the scope explicit. HL7 may carry information about a workflow or related data, while imaging data and image management involve their own standards and systems. Buyers assessing image exchange should ask how the proposed interface relates to the organization’s DICOM and PACS workflows. Teleray’s PACS and imaging workflow guide provides related context, and its medical image software overview addresses that adjacent evaluation area. Avoid assuming one standard handles every kind of healthcare data.

What integration questions should you ask vendors?

Use questions that require a concrete answer tied to your use case. Ask for the supported standard, version, use case, and implementation guide where applicable. Then ask how the interface behaves in practice and who owns each part of the work.

• Scope: Which systems and workflows are included? Is data exchanged one way or both ways? Which actions are in scope, and what is explicitly excluded?
• Specification: Which messages, resources, documents, profiles, fields, or operations are supported? Can the vendor provide a current interface specification and representative examples?
• Mapping: Who defines and approves field and terminology mappings? How are local codes, missing values, duplicates, corrections, and conflicts handled?
• Responsibility: Which party configures each endpoint, supplies test data, approves mappings, monitors failures, and coordinates changes?
• Operations: How are errors surfaced? What logs, alerts, retries, acknowledgments, and reconciliation processes are available? Who responds when exchange stops or data is rejected?
• Change management: How are upgrades, version changes, and changes to a source system assessed? Who gives notice, tests the change, and approves production deployment?
• Security: How is access controlled? What authentication, authorization, encryption, audit, retention, and incident processes apply to this connection?
• Evidence: What testing has been completed for this specific scope? What remains to be configured or validated in the customer’s environment?

Ask for answers in writing. A proposal should separate standard support from project-specific configuration, customer responsibilities, assumptions, and any additional work. This makes it easier for clinical, IT, security, and procurement stakeholders to identify gaps before they become production issues.

How should teams test an HL7 integration?

Plan testing around representative workflows, including normal cases and foreseeable exceptions. A test plan should cover data creation, changes, cancellations or corrections when relevant, invalid or incomplete values, duplicate delivery, delayed delivery, and recovery after an interruption. Choose cases with the clinical and operational owners; a purely technical pass may not show whether the process meets user needs.

1. Agree on acceptance criteria. Define what information must arrive, where it should appear, how quickly the workflow requires it, and how users can identify an exception. Keep criteria measurable and specific to the project.
2. Validate mapping and meaning. Compare source records, transmitted content, and destination display. Have qualified representatives verify that codes, identifiers, and contextual details are understood as intended.
3. Test errors and recovery. Confirm how malformed, incomplete, or unsupported data is reported. Test the agreed correction and replay process, and document who owns each action.
4. Check access and audit behavior. Verify that only intended users and systems can access the interface and that required events are recorded in the relevant systems.
5. Obtain operational sign-off. Confirm that clinical, technical, privacy, and security stakeholders accept the defined scope and know how to escalate a failure.

Do not treat a successful test message as proof that every workflow is ready. Testing should reflect realistic data and the configuration that will be used. Keep test evidence, unresolved issues, and approvals with the interface documentation so a later support team can understand what was verified.

What security and governance questions belong in the review?

Standards describe exchange structures; they do not replace an organization’s security, privacy, and governance review. Determine what information is exchanged, where it is processed, which users and services can access it, and how access is removed when it is no longer needed. Review the connection under the organization’s policies and applicable obligations rather than assuming that use of a particular standard makes an interface secure or compliant.

Ask vendors to explain the safeguards and evidence relevant to the proposed service and connection. Clarify responsibilities for identity and access management, audit records, incident handling, data retention, and subcontracted services where applicable. For Teleray, review its security and compliance information and validate the documentation and scope applicable to your organization. Teleray describes its platform as HIPAA compliant, SOC 2 Type II, and offers FDA 510(k)-cleared diagnostic viewing; these statements do not imply FDA endorsement or replace a customer’s review of intended use, system scope, and clinical judgment.

Governance also includes ownership after go-live. Name the business owner, technical owner, and operational escalation contacts. Decide how mapping changes are requested and approved, how incidents are reviewed, and how access and data flows are periodically reassessed. The Teleray EMR information can help frame product-specific integration questions, but ask the vendor to confirm which details apply to the proposed configuration and workflow.

Schedule a demo

Frequently asked questions

Is HL7 v2 the same as FHIR?

No. Both support health information exchange, but they use different models and implementation patterns. Confirm the specific workflow, version, and supported content rather than treating one as a direct substitute for the other.

Does “supports HL7” mean an integration will work?

No. The phrase does not specify versions, message types, fields, profiles, mappings, or workflow behavior. Ask for the implementation scope, interface specification, responsibilities, and test evidence for your use case.

Can an organization use v2 and FHIR at the same time?

Yes. Different systems or workflows may use different exchange approaches. The project team should document how the interfaces relate, whether transformation is involved, and how data meaning and errors are managed.

What is an HL7 implementation guide?

An implementation guide narrows a standard for a defined use case or program by setting more specific expectations. Ask which guide and version a vendor uses and whether it applies to the exchange your organization is planning.

Who should approve an HL7 integration?

Approval usually requires input from the people who own the workflow, interface and application teams, and appropriate privacy and security stakeholders. The exact approval path depends on the organization and the information exchanged.

Make interoperability requirements specific

HL7 standards create a shared foundation for exchanging health information, but successful interoperability depends on precise scope, agreed mappings, realistic testing, secure operations, and clear ownership. Define the workflow first, ask vendors to document the details, and involve clinical and technical stakeholders before accepting an integration as ready. For additional context, explore Teleray’s guides to EMR and EHR integration and reporting and EMR integration.