Connecting legacy hospital systems without disrupting operations requires a gradual integration architecture: HL7 v2 maintains existing workflows, FHIR provides a modern API layer, and an integration engine translates, validates, and monitors messages. The safest strategy is to run old and new interfaces in parallel, start with non-critical data, and only complete the transition after validating integrity, performance, and rollback procedures.
Why hospital integration cannot depend on a big-bang cutover
Hospitals operate electronic health records, laboratories, imaging systems, pharmacies, billing systems, devices, and administrative applications that were implemented at different times. Some use HL7 v2 over MLLP, while others exchange files, query databases directly, or expose proprietary APIs.
Shutting down these integrations and replacing them all at once creates clinical and operational risks. A failure could prevent a discharge from being recorded, a laboratory result from reaching the electronic health record, or a prescription from being processed.
The alternative is the approach known as the strangler pattern: the new interoperability layer progressively takes over workflows without requiring the immediate replacement of source systems. During the transition, the legacy system continues to operate as the system of record while messages and events are replicated to the new architecture.
The principles are:
- do not change the source, transport, and destination simultaneously;
- maintain versioned interface contracts;
- preserve clinical and administrative identifiers;
- run parallel processing before the transition;
- measure losses, duplicates, latency, and semantic errors;
- maintain a tested rollback path.
HL7 v2 and FHIR serve different purposes
HL7 v2 and FHIR are not direct competitors. In hospitals with legacy systems, they are typically used together.
Where HL7 v2 remains necessary
HL7 v2 is widely used for message-oriented integration. Common examples include:
- ADT: admission, discharge, transfer, and demographic updates;
- ORM: exam and procedure orders;
- ORU: transmission of results and observations;
- SIU: scheduling;
- DFT: financial transactions.
Messages are usually transported over MLLP and acknowledged through ACK responses. The integrator must properly handle positive acknowledgments and errors, including codes such as AA, AE, and AR, as well as timeouts and retransmissions.
HL7 v2 does not guarantee uniformity merely because it is present. Versions, custom Z-segments, optional fields, and local interpretations mean that two ADT interfaces may have different structures.
Where FHIR adds value
FHIR organizes data into resources accessible through HTTP APIs, such as Patient, Encounter, Observation, DiagnosticReport, ServiceRequest, and MedicationRequest. It facilitates the development of portals, applications, dashboards, artificial intelligence models, and data exchange with modern platforms.
The standard also supports profiles, extensions, terminologies, operations, searches, and Bundle packages. However, installing a FHIR server does not automatically solve interoperability. It is necessary to define which profiles will be accepted, required fields, identifiers, terminologies, and access rules.
In practice, a common architecture receives HL7 v2 from the legacy system, validates the message, converts its content into a canonical model, and publishes FHIR resources for modern consumers.
Recommended architecture for integration without downtime
A transition architecture must separate hospital systems from transformation logic. The main components are:
- Input adapters: receive HL7 v2, files, events, APIs, or, when unavoidable, database changes.
- Integration engine: routes, transforms, validates, and enriches messages.
- Queue or bus: absorbs spikes and prevents the unavailability of a destination from blocking the source.
- Canonical model: represents patients, encounters, exams, and results independently of proprietary formats.
- FHIR server or gateway: exposes resources and applies interoperability profiles.
- Identity layer: correlates identifiers for patients, encounters, professionals, and facilities.
- Observability: records metrics, logs, traces, and alerts.
- Rejected message queue: preserves events that require correction and reprocessing.
Communication should be asynchronous whenever an immediate response is not clinically necessary. This reduces coupling and allows a system to be temporarily unavailable without losing data.
Querying the legacy database directly should be the last option. This approach depends on undocumented internal structures, may increase transactional load, and often bypasses rules implemented by the application. When necessary, it should use read replicas or controlled change data capture mechanisms.
Six-step migration plan
1. Inventory systems and workflows
Record the source, destination, protocol, frequency, volume, criticality, owner, and dependencies of each interface. The inventory must identify which workflows can tolerate delays, which require acknowledgment, and which directly affect patient care.
It is also necessary to identify customizations, Z-segments, local tables, character encodings, and undocumented rules.
2. Define data contracts
For each workflow, create a contract containing:
- source event;
- HL7 version and profile used;
- required and optional fields;
- mapping to FHIR resources;
- terminology systems;
- identification and deduplication rules;
- behavior in the event of errors;
- acceptable latency threshold;
- reprocessing policy.
The contract must be versioned alongside the code. Incompatible changes require a new version rather than silent modifications.
3. Implement a low-risk workflow first
Starting with prescriptions, critical results, or hospital discharges increases the impact of any error. An initial project should prioritize a representative workflow with manageable operational risk.
The goal is to validate connectivity, transformation, authentication, monitoring, and support before expanding the scope.
4. Run in shadow mode
In shadow mode, the new system receives a copy of the events but does not control the main process. Its outputs are compared with those produced by the current integration.
The comparison must verify:
- total messages received and processed;
- missing required fields;
- uncorrelated patients or encounters;
- discrepancies in codes and units;
- duplicate messages;
- latency at relevant percentiles;
- rejection and reprocessing rates.
Matching message counts alone is not enough. Ten thousand messages may have been transported correctly while still containing incorrectly interpreted units, identifiers, or dates.
5. Transition by consumer
After parallel processing, migrate one consumer or unit at a time. This approach limits the impact radius and makes it possible to observe actual differences in load and behavior.
During the transition, preserve the ability to route traffic back through the previous path. The rollback procedure must specify how to handle events processed during the window, preventing loss or duplication.
6. Decommission based on evidence
An old interface should only be removed when there is evidence of stability, updated documentation, active alerts, and a trained team. Logs and artifacts required for auditing must follow the institution's retention policy.
Technical controls that prevent loss and duplication
The delivery of a message does not mean that it was applied correctly. To improve reliability, implement:
- idempotency: repeating the same event must not create duplicate results or encounters;
- correlation identifier: tracks the event from source to destination;
- functional acknowledgment: distinguishes technical receipt from successful processing;
- retries with progressive backoff: prevents overloading an unavailable service;
- dead-letter queue: isolates messages that have exceeded the allowed number of attempts;
- ordering by entity: preserves the sequence when admission and discharge depend on each other;
- periodic reconciliation: compares source and destination records;
- version control: prevents mapping changes from altering existing integrations without traceability.
At a minimum, an operational dashboard should display messages per minute, latency, errors by type, queue size, age of the oldest message, and the number of events awaiting intervention.
Identity, semantics, and security are the greatest risks
The most dangerous error is usually not a refused connection, but technically valid data associated with the wrong patient. Correlation must consider institutional identifiers and explicit rules. Name and date of birth alone must not be treated as a unique key.
Semantic normalization also requires attention. Local exam, medication, and procedure codes must be mapped to agreed-upon terminologies without discarding the original value. Units should only be converted using verifiable and traceable rules.
Because health data is sensitive personal data under the LGPD, the integration must apply:
- authentication between systems;
- authorization based on role and purpose;
- encryption in transit and, when applicable, at rest;
- segregation of development, staging, and production environments;
- masking or synthetic data in tests;
- audit logs without unnecessary exposure of clinical information;
- secure credential rotation and storage;
- retention and disposal policies.
For FHIR APIs, OAuth 2.0 and OpenID Connect may be part of access control, depending on the adopted architecture. This does not replace authorization based on resource, scope, and care context.
Checklist before putting the integration into production
- [ ] All systems, owners, and dependencies have been inventoried.
- [ ] The HL7/FHIR contract is documented and versioned.
- [ ] Tests cover valid, invalid, duplicate, and out-of-order messages.
- [ ] Patient and encounter identifiers have been reconciled.
- [ ] Queues, retries, idempotency, and reprocessing have been tested.
- [ ] Metrics and alerts are monitored by a responsible team.
- [ ] Shadow mode has demonstrated technical and semantic equivalence.
- [ ] Rollback has been performed in the staging environment.
- [ ] Security has been reviewed in accordance with the LGPD.
- [ ] The operations team knows how to identify, escalate, and correct failures.
How Predictor Solutions addresses this
Predictor Solutions builds healthcare systems with HL7 v2 and FHIR integration, data engineering, cloud/DevOps, and security. The work begins with an inventory of workflows and contracts, followed by the implementation of adapters, a canonical model, queues, FHIR APIs, observability, and progressive migration without depending on the immediate replacement of legacy systems.
The company also develops Predictor Health, focused on health and wearable dashboards, and Predictor AI Hospitals, designed to predict sepsis, heart attacks, and pneumonia in the ICU. These products require traceable and interoperable clinical data; therefore, semantic validation, security, and monitoring are part of the architecture rather than later steps.
Across its software and automation projects, Predictor Solutions has served 9 medium-sized and large companies, with reported results of R$ 1.32 million in average savings per client per year, an average productivity increase of 70%, and 43% profit growth in six months. These indicators do not replace the specific assessment of risk, scope, and return for each hospital integration.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.