To connect legacy hospital systems without disrupting operations, keep existing HL7 v2 flows in place, introduce an interoperability layer, and gradually expose new services through FHIR. A safe migration uses parallel execution, idempotent messages, data reconciliation, clinical and technical monitoring, and rollback procedures tested before each change.
Why replacing everything at once is risky
Hospitals typically operate a combination of HIS, electronic health records, LIS, RIS, PACS, ERP, pharmacy, billing, medical equipment, and departmental applications. These components may use legacy databases, files, proprietary APIs, or HL7 v2 messages transmitted over MLLP.
A complete replacement within a single window creates risks that are difficult to control:
- unavailability of registration, prescription, or results;
- duplication or loss of clinical events;
- association of an exam with the wrong patient;
- disruption of undocumented integrations;
- discrepancies between billing and care delivery;
- lack of rollback when the new system receives real data.
In a hospital environment, “not disrupting operations” does not mean eliminating all maintenance. It means preventing deployment from interrupting critical care processes and ensuring contingency procedures for registration, care delivery, prescriptions, exams, and discharge.
The safest strategy is similar to the strangler pattern: new integrations pass through an intermediate layer, while legacy flows are replaced individually. The legacy system remains active until each new flow has been validated.
HL7 v2 and FHIR serve different roles
HL7 v2 remains widely used for operational events. Messages such as ADT, ORM, ORU, and SIU communicate admissions, orders, results, and appointments. They are generally sent over MLLP, although file-based, queue-based, and other transport implementations also exist.
FHIR organizes information into reusable resources such as Patient, Encounter, Observation, Condition, DiagnosticReport, and MedicationRequest. These resources can be accessed through REST APIs, messages, documents, or operations defined by the standard.
FHIR should not be treated merely as “HL7 in JSON.” There are important differences:
- HL7 v2 is primarily message- and event-oriented;
- FHIR has a resource model and search rules;
- FHIR extensions require governance to prevent incompatibility;
- clinical terminologies must be preserved during mapping;
- FHIR versions and profiles must be explicitly declared.
In practice, HL7 v2 and FHIR often coexist. An HIS may continue emitting ADT messages while an interoperability layer converts the event into Patient and Encounter resources for newer applications.
Recommended architecture for integration without disruption
The architecture must decouple source and destination systems. Direct mesh connections increase the number of dependencies: five systems integrated with one another may require up to ten different bilateral connections.
1. Interoperability layer
An integration engine or equivalent service receives, validates, transforms, and routes messages. This layer may provide:
- MLLP listeners for HL7 v2;
- connectors for databases, files, queues, and APIs;
- structural and semantic validation;
- transformation between versions and formats;
- a FHIR API with defined profiles;
- error queues and controlled reprocessing;
- an audit trail with end-to-end correlation.
The engine does not solve semantic problems on its own. For example, it is necessary to document whether PID-3 contains the hospital identifier, CPF, or another code, and which assigning authority is responsible for the value.
2. Canonical model with clear boundaries
An intermediate model can reduce repeated transformations, but it should not attempt to represent the entire hospital in a generic structure. The best approach is to begin with the data required for each use case.
For a laboratory results flow, the initial scope may include the patient, encounter, order, specimen, test, result, unit, reference range, and status. Diagnoses, prescriptions, and billing may remain out of scope until they are needed.
3. Queues and temporary persistence
Queues absorb spikes and allow the destination to remain temporarily unavailable without losing events. Each message must have:
- a unique identifier;
- source and receipt date and time;
- producing system;
- schema version;
- number of attempts;
- processing status;
- clinical correlation key.
Retention must comply with operational needs, institutional policy, and Brazil’s General Data Protection Law (LGPD). Clinical content should not appear in full in standard logs.
Phased deployment plan
Step 1: Inventory the actual flows
Listing systems is not enough. Record the source, destination, protocol, frequency, volume, criticality, technical owner, and clinical owner. Capture anonymized message samples and identify local variations.
Classify each flow:
- critical: failure immediately affects care delivery or safety;
- high: manual operation is possible for a short period;
- moderate: a controlled delay is acceptable;
- low: processing can be rescheduled.
Step 2: Choose a reversible pilot flow
Avoid starting with prescriptions, medication administration, or primary patient identification. A read-only flow, such as secondary distribution of results, tends to support parallel validation with less impact.
Define measurable criteria before deployment:
- 100% of received messages must be accounted for;
- no message may disappear without a final status;
- duplicates must be detected and handled;
- critical clinical fields must preserve equivalence;
- maximum latency must meet the care delivery process requirements;
- rollback must be executable without improvised reconstruction.
Step 3: Run in shadow mode
In shadow mode, the new flow receives a copy of the events but does not yet control the official process. Its outputs are compared with the current system.
Validation must check record counts, patients, encounters, codes, units, dates, statuses, and results. Comparing only the total number of messages is insufficient: two messages may arrive and still be associated with the wrong encounter.
Step 4: Release by scope
Activate the integration by unit, message type, laboratory, insurance plan, or user group. Avoid releasing it to all departments simultaneously.
One possible progression is:
- test environment with synthetic data;
- validation environment with anonymized samples;
- shadow mode in production;
- production limited to one unit;
- expansion after a period of stability;
- deactivation of the legacy flow only after reconciliation.
Step 5: Retire the legacy system based on evidence
The legacy flow should only be removed after confirming that there are no hidden dependencies, retention has been defined, and the team has evidence of completeness. Keep documentation of the mapping and restoration procedure.
Idempotency, ACKs, and duplicate prevention
Networks fail, connections time out, and systems resend messages when they do not receive confirmation. Therefore, “receive twice and process twice” cannot be the default behavior.
In HL7 v2, ACKs must reflect the correct outcome: acceptance, error, or rejection. Acknowledging before safely persisting the message may cause data loss; acknowledging too late may increase retries. The decision depends on the contract defined between the sender and receiver.
In FHIR, uncontrolled create operations may also generate duplicate resources. Business identifiers, conditional searches, and update rules must be defined according to the use case.
An idempotency key may combine the message identifier, source system, and event. However, using only the control number is dangerous when systems reset counters or reuse values.
Security, LGPD, and traceability
Integration expands the attack surface because it connects previously isolated systems. Minimum controls include:
- TLS on compatible transports and a segregated network for legacy connections;
- authentication between systems and credential rotation;
- least privilege for service accounts;
- encryption at rest for queues and temporary storage;
- access and change auditing;
- data masking in logs and non-production environments;
- definition of the controller, processor, purpose, and retention in accordance with the LGPD;
- an incident response plan and access revocation procedures.
Technical logs must make it possible to answer “which event entered, how it was transformed, and where it failed” without exposing unnecessary data. Correlation identifiers can link technical records to the clinical event under controlled access.
Production cutover checklist
Before activating the new flow, confirm:
- [ ] mapping approved by technical and clinical owners;
- [ ] FHIR profiles, versions, and extensions documented;
- [ ] invalid HL7 v2 messages routed to an error queue;
- [ ] idempotent reprocessing tested;
- [ ] server clocks synchronized;
- [ ] dashboards monitoring volume, latency, errors, and queues;
- [ ] alerts have assigned owners and escalation criteria;
- [ ] manual contingency procedures documented;
- [ ] rollback rehearsed;
- [ ] post-deployment reconciliation has an owner and deadline;
- [ ] sensitive data does not appear in inappropriate observability tools;
- [ ] objective success and interruption criteria documented.
The main trade-off is speed versus control. A single cutover may seem faster, but it concentrates risks. A gradual migration temporarily requires operating two paths, but it provides comparison, learning, and reversibility.
How Predictor Solutions handles this
Predictor Solutions designs healthcare integrations using HL7 v2 and FHIR, beginning with an inventory of flows, data contracts, and care delivery risks. The implementation combines an interoperability layer, APIs, message transformation, queues, observability, idempotency testing, shadow execution, and progressive deployment.
The company also develops Predictor Health, a healthcare dashboard integrated with wearables, and Predictor AI Hospitals, focused on predicting sepsis, heart attacks, and pneumonia in ICUs. This work requires treating interoperability as operational and clinical engineering, not merely as format conversion.
Predictor Solutions, headquartered in Lavras, Minas Gerais, Brazil, has served 9 medium-sized and large companies. Across its software, automation, data, and artificial intelligence projects, it reports average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and profit growth of 43% in six months; these figures should not be interpreted as an automatic result of a specific hospital integration.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.