HL7 and FHIR Integration: How to Connect Legacy Hospital Systems Without Interrupting Operations

Connecting legacy hospital systems without interrupting operations requires an incremental architecture: existing interfaces remain operational while an interoperability layer receives, transforms, validates, and distributes data in HL7 v2 and FHIR. The transition should occur by clinical workflow, with parallel processing, reconciliation, observability, and rollback—never through a complete replacement in a single cutover.

Why Hospital Integration Cannot Depend on a Large-Scale Migration

Hospitals operate systems with different life cycles: HIS, electronic health records, laboratory, radiology, pharmacy, billing, devices, and departmental solutions. Some use HL7 v2; others expose proprietary APIs, files, legacy web services, or direct database access.

Interrupting all these components to standardize them at the same time creates clinical and operational risks. Downtime can affect patient identification, test result release, prescriptions, bed occupancy, or billing.

The safest strategy is to preserve the existing systems of record and introduce an intermediate layer. This layer should:

• receive messages and events from legacy systems;
• validate structure, required fields, and codes;
• transform formats without changing the source system;
• correlate patients, encounters, and orders;
• deliver data to the destination in the expected standard;
• record each step for auditing and reprocessing.

The initial goal is not to modernize everything, but to decouple systems. After that, each integration can evolve without requiring simultaneous changes across the entire hospital.

HL7 v2 and FHIR Serve Different Roles

HL7 v2 is widely used to exchange clinical and administrative events. Messages such as ADT, ORM, ORU, and SIU can represent admissions and transfers, orders, results, and appointments. Transport commonly occurs through MLLP over TCP, although implementations using files, queues, and other methods also exist.

FHIR organizes information into resources such as Patient, Encounter, Observation, DiagnosticReport, and MedicationRequest. These resources can be accessed through REST APIs, documents, messages, or operations defined by the standard.

FHIR should not automatically be treated as an immediate replacement for HL7 v2. In a transitional architecture, it is common to:

1. retain HL7 v2 messages in systems that already depend on them;
2. convert selected events into FHIR resources;
3. provide a FHIR API for new applications;
4. preserve identifiers and traceability between source and destination.

Mapping is not merely a syntax conversion. An OBX segment, for example, can generate an Observation resource, but the transformation depends on the message context, unit, test code, patient reference, and link to the encounter.

Recommended Architecture for a Transition Without Downtime

1. Interoperability Layer

An integration engine receives events and applies routes, transformations, and validations. It avoids point-to-point connections, in which every change requires modifications to multiple systems.

This layer may include:

• HL7 v2, FHIR, REST, SOAP, SFTP, and database adapters;
• queues to absorb traffic spikes and temporary outages;
• terminology and normalization services;
• a patient index or patient correlation mechanism;
• temporary storage for reprocessing;
• technical logs and audit trails.

Direct access to a legacy system's database should be the last resort. When unavoidable, prefer read access through a replica, controlled view, or change data capture, avoiding heavy queries and changes to operational tables.

2. Internal Canonical Model

A canonical model reduces the number of required transformations. Instead of creating a different rule for every pair of systems, each source is converted into a common model, and each destination consumes that model.

At a minimum, this model must represent:

• local and enterprise identifiers;
• patient and demographic data;
• encounter, hospitalization, and location;
• order, specimen, result, and report;
• responsible practitioner and organization;
• event date, record date, and source system;
• clinical status and processing status.

The model may align closely with FHIR, but it should not invent equivalences. FHIR extensions must be documented, versioned, and used only when existing resources and profiles do not meet the requirement.

3. Asynchronous and Idempotent Processing

The system must support repeated messages without duplicating admissions, tests, or results. This requires an idempotency key based on stable identifiers, event type, version, and source.

Failed messages must not disappear or block the entire queue. They need to be sent to an exception queue containing the reason, original content, attempted retries, and an option for reprocessing after correction.

Implementation Plan by Clinical Workflow

Start with the inventory, not development. For each interface, record the source, destination, protocol, volume, peak hours, owner, criticality, and behavior in case of failure.

A controlled implementation can follow these steps:

1. Select a clearly scoped workflow: for example, sending laboratory results to a consuming system.
2. Capture a representative sample: include normal messages, cancellations, corrections, duplicates, and missing fields.
3. Define the contract: HL7 version, segments used, FHIR profile, terminologies, authentication, and error codes.
4. Run in shadow mode: the new integration processes copies of events without producing effects in the destination.
5. Compare the results: measure quantity, content, order, latency, and discrepancies between the old and new paths.
6. Release by group: activate a department, unit, test type, or percentage of traffic.
7. Maintain rollback: allow an immediate return to the previous route without losing accumulated events.
8. Deactivate the old path: only after stability and formal reconciliation.

The duration of shadow mode depends on volume and seasonality. As a practical criterion, it should cover daytime and nighttime routines, weekends, and at least one complete operational cycle for the department.

Clinical and Technical Validation

A syntactically valid message may still be clinically incorrect. Therefore, validation must involve integration professionals, hospital IT, and those responsible for the care process.

The minimum checklist includes:

• correct patient and no identifier collisions;
• correct encounter and episode of care;
• preservation of unit, scale, and reference range;
• distinction between preliminary, final, corrected, and canceled results;
• dates with defined time zone and precision;
• local codes mapped to appropriate terminologies;
• HL7 ACKs interpreted correctly;
• HTTP responses and OperationOutcome resources handled;
• attachments and reports preserved without truncation;
• duplicate messages processed idempotently.

Terminologies such as LOINC, SNOMED CT, and ICD-10 can support semantic interoperability, but their use depends on the context, the adopted version, and licensing rules. Local codes should not be discarded: they must remain associated with the normalized code for auditing purposes.

Observability, Security, and Continuity

Each event must have a correlation identifier that allows it to be tracked from source to destination. Operational dashboards need to display intake rate, deliveries, rejections, latency, queue sizes, and the age of the oldest message.

Alerts should consider impact, not only isolated errors. Examples of relevant conditions include a continuously growing queue, an unexpected absence of messages from a department, an increase in rejections, or critical results without delivery confirmation.

For security, apply:

• TLS for compatible transport methods and segregated networks for legacy integrations;
• authentication and authorization by system and purpose;
• least privilege for technical accounts;
• encryption of stored data;
• credential rotation and secrets kept outside the code;
• logs without unnecessary exposure of clinical data;
• audit trails and retention policies.

Because health data is sensitive personal data under the LGPD, the project must limit collection and access to the defined care or operational purpose. Test environments should use synthetic or anonymized data whenever possible.

Metrics and Criteria for Deciding on the Cutover

The migration should not be approved simply because “the messages are arriving.” Define indicators and thresholds in advance that are compatible with the workflow's criticality:

• percentage of events reconciled between source and destination;
• number of duplicates and losses;
• latency at the 50th, 95th, and 99th percentiles;
• volume and age of items in the exception queue;
• recovery time after an outage;
• percentage of unmapped codes;
• time required to detect and diagnose failures.

For critical clinical workflows, the goal should be to track 100% of events, including rejections and reprocessing. The latency threshold must be defined by the process: seconds may be necessary for an admission or alert, while analytical workloads may tolerate longer periods.

Errors That Increase Integration Risk

The most frequent problems are replacing everything at once, assuming that all vendors implement the standard in the same way, and embedding clinical rules in scripts without testing or versioning.

The following should also be avoided:

• using name and date of birth as the only method for correlating patients;
• ignoring cancellations and corrections;
• acknowledging receipt before securely persisting the event;
• failing to distinguish a transient failure from a data error;
• relying on a single server without documented recovery procedures;
• placing the new API directly on top of legacy system tables;
• storing sensitive data in debug logs.

How Predictor Solutions Addresses This

Predictor Solutions implements healthcare integrations with HL7 v2 and FHIR through interface assessments, contract definition, transformation mechanisms, APIs, queues, observability, and incremental implementation. The approach preserves systems in operation, validates workflows in parallel, and establishes reprocessing and rollback before the final migration.

The company also works with custom software, applied artificial intelligence, data engineering, cloud, DevOps, and offensive security. Its products include Predictor Health, focused on health dashboards and wearables, and Predictor AI Hospitals, designed to predict sepsis, myocardial infarction, and pneumonia in ICUs. Across its software and automation projects, Predictor Solutions has served 9 medium-sized and large companies, generated average savings of R$ 1.32 million per client per year, delivered an average productivity increase of 70%, and achieved 43% profit growth in six months.

Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246