An admission message arrives. Should the next system receive an ADT^A01, or should an app fetch an Encounter resource? That sounds like a standards question. It is really a workflow question wearing angle brackets.
FHIR and HL7 v2 are not two rungs on one upgrade ladder. They package work differently. Start with the business event, authority, and consumer. The wire format comes later.
Takeaways:
- HL7 v2 sends event messages; FHIR organizes exchange around resources and defined interactions.
- Hospitals often need both because events, documents, queries, and app access are different jobs.
- A standard name does not settle profiles, local codes, identity, authorization, retries, or ownership.
- Export in an HL7 or FHIR format is not proof of a live interface.
HL7 is the family name
“HL7 versus FHIR” is common shorthand, but it hides the family tree. Health Level Seven International publishes HL7 Version 2 and FHIR, along with other standards. The useful comparison is HL7 v2 versus FHIR.
HL7 v2 is message-oriented. A sending system reports an event, such as an admission, order, or result, using a message whose segments carry fields. Implementations commonly exchange those messages over interfaces that define triggers, fields, local codes, acknowledgments, retries, and operations. HL7 describes Version 2 as a standard for exchanging clinical data among systems (HL7 v2 product brief).
FHIR is resource-oriented. HL7 defines resources for clinical and administrative concepts and several ways to exchange them. A resource has identity, metadata, structured elements, and possible human-readable text. Resources can reference one another, and REST is one specified exchange style (FHIR resource architecture, FHIR RESTful API).
| Dimension | HL7 v2 | FHIR |
|---|---|---|
| Usual unit | Event message | Resource or bundle of resources |
| Common shape | Delimited segments and fields | JSON, XML, or other defined representations |
| Typical motion | Sender pushes a business event | Client reads, searches, creates, or updates within allowed interactions |
| Contract evidence | Interface specification plus message samples | Capability statement, profiles, implementation guide, scopes, and examples |
| Frequent trap | Assuming the standard eliminates local variation | Assuming a REST endpoint behaves like a generic database API |
Neither column is inherently more correct. The receiving workflow decides.
Follow one admission through both models
Suppose registration completes an inpatient admission.
In an HL7 v2 flow, the registration system may emit an admission event. The receiver processes the message, matches the patient and visit, applies field mappings, updates local state, and returns an acknowledgment under the interface contract. If a field is missing or a destination is unavailable, the parties need an agreed retry and reconciliation path.
In a FHIR flow, an authorized client may read or search Patient and Encounter resources, or receive a notification under an implementation pattern defined for that environment. The server’s capabilities, profiles, search support, authorization, and local policy determine what the client can do. FHIR does not imply that every client may create or update every resource.
The two approaches can coexist. A hospital can continue event-driven HL7 v2 feeds while exposing selected FHIR APIs for app access. An integration service may even translate between representations, but translation does not automatically preserve business meaning. The owner still has to decide which event becomes which resource state and how conflicts resolve.
Choose with a five-line use case
Before a standards workshop, write this card:
- When this real-world event occurs…
- this source is authoritative for…
- this consumer needs these data to perform…
- within this time and authorization boundary…
- with this recovery path when exchange fails.
Now compare options.
A lab result delivered to an existing hospital result interface may fit the established HL7 v2 route. A patient-authorized application reading a standardized data set from a certified API may fit FHIR plus SMART App Launch. A longitudinal summary sent as a document may call for a different standard again. The card prevents “modern” from becoming the sole requirement.
FHIR brings web patterns, not magic
FHIR’s RESTful API specification defines interactions such as read, search, create, update, and history, with HTTP behavior and FHIR representations (FHIR RESTful API). That familiarity helps web developers, but a healthcare API still carries domain rules.
Ask for these artifacts:
- the FHIR version and server base URL;
- the server’s CapabilityStatement;
- required profiles and implementation guides;
- supported resources, interactions, search parameters, and operations;
- terminology and value-set bindings;
- authorization scopes and launch context;
- identifier and patient-matching rules;
- provenance, update, deletion, and history behavior; and
- rate limits, errors, downtime, and support ownership.
The US certification criterion for standardized patient and population services references FHIR R4, US Core, USCDI, and SMART App Launch requirements. It also includes API and token-related obligations for certified developers (ASTP/ONC standardized API fact sheet). That is a defined regulatory context, not proof that every FHIR server supports every imagined workflow.
HL7 v2 is not one universal message
Two systems can both say “HL7 v2” and disagree about version, trigger, required segments, repeated fields, local codes, identifiers, and acknowledgment meaning. The interface specification is where those differences become testable.
Record at least:
- business event and trigger;
- sending and receiving applications;
- version and message structure;
- required, optional, and prohibited fields;
- local code sets and owners;
- patient, visit, order, and result identifiers;
- acknowledgment boundary;
- duplicate and out-of-order behavior;
- transport and security; and
- queue, alert, replay, and reconciliation ownership.
An AA acknowledgment means only what the parties define it to mean. Did the receiver parse the message, queue it durably, or update the final clinical system? Put that state in the contract.
Identity breaks both standards
A well-formed message or resource can still point to the wrong person, encounter, order, or organization. Treat identity as its own design surface.
Test exact matches, changed demographics, twins, reused local numbers, merged records, unknown identifiers, and cross-organization identifiers. Preserve source identifiers and provenance. Do not use a display name as a join key because it looked unique in a fixture.
FHIR resources distinguish logical identity from business identifiers, and HL7’s specification explains that resources can carry identifiers representing the underlying real-world entity (FHIR Resource). The application still needs rules for issuer, system, scope, and reconciliation.
Acceptance evidence beats a standards logo
For HL7 v2, keep approved messages for ordinary, missing-field, duplicate, delayed, and out-of-order cases. Prove acknowledgment and replay behavior. Reconcile the source event to the destination record.
For FHIR, keep requests, responses, authorization cases, profile validation, terminology failures, pagination, rate-limit behavior, and version evidence. Test a denied scope. Test a server that omits an optional field your user interface quietly assumed would exist.
For both, name who owns changes. A local field or profile can change without a compiler warning in the other organization.
Patient Square’s export boundary
Patient Square is an AI clinical platform. Practice Copilot brings the whole practice under one AI copilot: an ambient AI Medical Scribe that hands back a structured SOAP note, ICD-10 suggestions, and a prescription draft minutes after the visit, plus a bundled AI EHR, scheduling, and messaging as you move up the plan. Hospitals get Hospital Copilot.
Patient Square states “EHR-ready export (PDF · HL7 · FHIR).” That phrase describes export formats. It does not claim FHIR R4 conformance, an HL7 interface, SMART authorization, a named EHR connection, automatic filing, bidirectional exchange, or write-back. A practice can use Patient Square EHR from the Copilot tier or keep its existing EHR, but a live exchange remains a separate design and acceptance problem.
If an evaluation begins with “Do you support HL7 or FHIR?”, hand the team the five-line card first. The answer may be both, neither, or a simple export. Only the workflow can tell you which answer is useful.