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

Connecting legacy hospital systems without disrupting operations requires an interoperability layer that maintains existing HL7 v2 workflows while making data available through FHIR APIs. The safest strategy combines interface assessment, identifier normalization, idempotent processing, parallel operations, reconciliation, and gradual migration by clinical workflow.

Why replacing everything at once is risky

Hospitals typically operate a heterogeneous ecosystem: HIS, electronic health records, LIS, RIS, PACS, pharmacy, billing, monitoring, equipment, and departmental solutions. Some systems send HL7 v2 messages via MLLP; others use files, shared databases, SOAP, or proprietary protocols.

An abrupt replacement creates clinical and operational risks because hospital integrations do not carry only registration data. They handle admissions, discharges, transfers, prescriptions, test orders, results, allergies, and information used in care decisions.

“Not disrupting operations” does not mean the complete absence of risk. It means avoiding broad planned downtime through coexistence, incremental deployment, and rollback mechanisms. The migration must preserve the current system until the new workflow has been proven equivalent.

HL7 v2 and FHIR serve different purposes

HL7 v2 remains widely used for events within hospitals. Messages such as ADT, ORM, ORU, and SIU represent patient movements, orders, results, and scheduling, respectively. Transport can occur through MLLP over TCP, with ACK confirmations indicating acceptance or an error.

FHIR organizes clinical information into resources accessed primarily through HTTP APIs. Some of the most common resources include:

• Patient: patient and identifiers;
• Encounter: appointment, admission, or visit;
• Observation: vital signs and individual results;
• DiagnosticReport: report or set of results;
• ServiceRequest: test or procedure request;
• MedicationRequest: medication prescription;
• Appointment: scheduling;
• Organization and Practitioner: institution and healthcare professional.

FHIR should not be treated as a simple JSON conversion. It defines structure, terminologies, references, and interoperability rules. It also does not automatically eliminate HL7 v2: in many projects, HL7 v2 remains the operational protocol while FHIR serves as the canonical model or interface for new applications.

Recommended architecture for integration without downtime

A resilient architecture separates clinical systems from the specific rules of each consumer. Instead of creating point-to-point connections, an intermediary mechanism is used to receive, validate, transform, route, and monitor data.

1. Input adapters

Adapters receive messages through MLLP, APIs, queues, files, or controlled database queries. Each input must preserve the original message, receipt time, source, and a correlation identifier.

A direct connection to the legacy database should be the last resort. When unavoidable, prefer read replicas or change data capture—CDC—to reduce locking and dependence on the internal schema.

2. Integration engine

The engine interprets HL7 v2 versions and local variations, applies validations, and routes messages. Two systems that claim to use HL7 v2.5.1 may populate segments, fields, and codes differently; therefore, the interface agreement must document the values actually used.

Essential functions include:

• ACK and timeout control;
• retries with backoff;
• error message queue;
• idempotency to prevent duplicates;
• transformation versioning;
• audit trail;
• controlled reprocessing.

3. Canonical model and FHIR server

A canonical model reduces the number of transformations. Instead of each system understanding all the others, each source is converted into a central format, and each destination consumes that format.

FHIR can serve this role, but profiles, extensions, terminologies, and identifiers must be defined. The project must specify, for example, which HL7 v2 field populates Patient.identifier, how an admission becomes an Encounter, and which code represents each test type.

4. Decoupled consumers

Dashboards, applications, artificial intelligence models, and portals should consume APIs or events without depending directly on the HIS. This decoupling allows new capabilities to be modernized without immediately changing the systems responsible for core operations.

Seven-step migration plan

1. Inventory the actual workflows

List the source, destination, protocol, frequency, volume, version, criticality, owner, and operational window of each interface. Analyze actual anonymized samples: documentation often differs from production traffic.

Classify workflows into three levels:

1. critical to immediate care;
2. important to operations and billing;
3. analytical or administrative and tolerant of delays.

Start with a workflow that has a controlled scope, not necessarily the simplest or the most critical one.

2. Define patient identity

Incorrect patient matching is one of the greatest risks. CPF cannot be assumed to be a universal identifier: it may be missing, incorrect, or shared in temporary registrations.

Define an MPI—Master Patient Index—or equivalent rules, preserving the medical record number, assigning authority, and merge history. Probabilistic matching can support review, but it should not automatically merge records without criteria and governance appropriate to the risk.

3. Create interface contracts

For each workflow, document:

• source event and triggering condition;
• required and optional fields;
• codes and terminologies;
• transformation rules;
• expected response;
• retry policy;
• cancellation and correction handling;
• incident owner.

Use positive, negative, and edge-case examples. A laboratory interface should test a corrected result, canceled test, missing unit, and patient with multiple identifiers.

4. Run in shadow mode

In shadow mode, the new pipeline receives copies of the traffic without controlling the clinical process. Outputs are compared with the current system, making it possible to identify losses, duplicates, semantic differences, and ordering problems.

Validation should verify at least:

• 100% of critical events reconciled;
• no duplicates with clinical impact;
• rejected messages are identifiable and recoverable;
• latency within the limit defined with the care team;
• complete traceability from source to destination.

These are recommended acceptance criteria, not automatic guarantees from using HL7 or FHIR.

5. Activate through a canary deployment

Route one unit, department, test type, or controlled group to the new workflow. Avoid changing registration, prescriptions, laboratory, and billing simultaneously.

The canary deployment needs a rollback plan: routing switch, previous version available, on-call personnel, and a procedure for reconciling messages produced during the rollback.

6. Expand gradually

After stabilization, expand by department or workflow. Maintain comparable metrics between the legacy system and the new integration. Expansion must be stopped if events are lost, queues continue to grow, or identity discrepancies arise.

7. Decommission based on evidence

Only remove the old interface after the agreed period of parallel operation, reconciliation, and clinical, technical, and operational approval. Document remaining dependencies and preserve messages according to legal and institutional policies.

Security, LGPD, and observability

Health data is considered sensitive personal data under the LGPD. The integration must apply role-based access control, authentication between services, encryption in transit and at rest, secrets management, auditing, and data minimization.

Test environments must not receive production databases without anonymization or adequate protection. Logs also require care: recording complete HL7 messages can expose names, diagnoses, identification documents, and test results.

The operational dashboard needs to show:

• messages received, processed, and rejected;
• average latency and percentiles such as p95 and p99;
• queue size and age;
• negative ACK and timeout rates;
• reprocessing attempts;
• patient and code discrepancies;
• availability by interface.

Alerts should indicate impact and context, not only “service unavailable.” A growing queue may be more relevant than a process that is technically active.

Checklist before putting the integration into production

• [ ] Workflows and owners have been inventoried.
• [ ] HL7 v2 versions and specific characteristics have been documented.
• [ ] FHIR profiles and resources have been defined.
• [ ] Patient and encounter identifiers are consistent.
• [ ] Duplicates are neutralized through idempotency.
• [ ] ACK, timeout, retry, and error queue handling have been tested.
• [ ] Corrections, cancellations, and out-of-order messages have been simulated.
• [ ] End-to-end correlation and auditing are in place.
• [ ] Sensitive data is protected in logs.
• [ ] Shadow mode and reconciliation have been completed.
• [ ] Rollback has been tested, not merely documented.
• [ ] Clinical, operational, security, and infrastructure teams have approved the change.

Main trade-offs

Using FHIR as the canonical model facilitates APIs and modern applications, but requires governance of profiles and terminologies. Keeping HL7 v2 reduces changes to current systems but preserves local variations and semantic limitations.

Synchronous processing provides an immediate response but increases coupling and the impact of outages. Asynchronous queues absorb spikes and facilitate retries, but require handling of out-of-order messages and eventual consistency.

Building connectors internally provides control but transfers the maintenance of versions, security, and observability to the team. Adopting an integration engine accelerates common functions, although it does not eliminate the work of mapping specific clinical rules.

How Predictor Solutions addresses this

Predictor Solutions designs hospital integrations with HL7 v2 and FHIR using interface inventories, versioned contracts, idempotency mechanisms, queues, observability, reconciliation testing, and gradual activation. The company also develops healthcare systems such as Predictor Health, focused on dashboards and wearables, and Predictor AI Hospitals, designed to predict sepsis, heart attacks, and pneumonia in ICUs.

The approach combines software engineering, data, cloud/DevOps, and offensive security to prevent interoperability from being treated merely as message conversion. Across the software house’s projects, recorded overall results include 9 medium-sized and large companies served, average savings of R$1.32 million per client per year, an average 70% increase in productivity, and 43% profit growth in six months; the result of each integration depends on its scope, infrastructure, and operational maturity.

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