Connecting legacy hospital systems without interrupting operations requires a transition architecture: existing systems continue to operate while an interoperability layer translates, validates, and distributes HL7 v2 messages and FHIR resources. Migration should occur by clinical workflow, with parallel operation, shadow testing, data reconciliation, monitoring, and rollback capability.
Why HL7 v2 and FHIR Need to Coexist
Hospitals can rarely replace electronic health records, laboratory, radiology, pharmacy, billing, and departmental systems simultaneously. Some of these systems use proprietary databases; others expose files, specific APIs, or HL7 v2 messages transmitted via MLLP.
HL7 v2 remains relevant for established transactional events such as:
- ADT: admission, discharge, transfer, and demographic updates;
- ORM: exam and procedure orders;
- ORU: laboratory results and clinical observations;
- SIU: scheduling;
- ACK: positive or negative processing acknowledgment.
FHIR, in turn, organizes data into resources accessible through APIs, such as Patient, Encounter, Observation, ServiceRequest, DiagnosticReport, and MedicationRequest. It facilitates integrations with web applications, devices, analytics platforms, and new services, but it does not automatically eliminate rules built over years in legacy systems.
Therefore, the practical decision is not “HL7 or FHIR.” In most environments, the solution is HL7 v2 for operational compatibility and FHIR to standardize new access methods and future developments.
Architecture for Integration Without Shutting Down Legacy Systems
The recommended architecture inserts an interoperability layer between producers and consumers. It avoids point-to-point connections, in which every change to one system requires changes to several others.
A typical workflow operates as follows:
- The source system produces an HL7 v2 message, file, or proprietary event.
- An adapter receives the content and records the original message without modifications.
- The integration layer validates the structure, required fields, and codes.
- The data is converted into a canonical model or FHIR resources.
- Routing rules determine which systems should receive the event.
- The destination confirms processing or returns a traceable error.
- Metrics, logs, and audit trails make it possible to track the entire journey.
This layer may include an interface engine, FHIR server, message queues, API gateway, and observability mechanisms. Its composition depends on the volume, criticality, and capabilities of each vendor.
Why Use Messaging
A queue decouples systems. If the laboratory is temporarily unavailable, for example, patient admission does not need to stop: the event remains stored and can be reprocessed when the destination becomes available again.
For this to work, the implementation must account for:
- at-least-once delivery and duplicate handling;
- a unique identifier for each message or event;
- retries at controlled intervals;
- a queue for unprocessed messages, also known as a dead-letter queue;
- ordering when the clinical sequence is relevant;
- time limits and a circuit breaker for unstable destinations.
Gradual Migration in Six Steps
1. Inventory Systems and Clinical Workflows
The assessment should not begin with database tables, but with processes: who registers the patient, who orders the exam, where the result is validated, and which systems depend on that result.
For each interface, document:
- source, destination, and technical owner;
- HL7 version and profile in use;
- messages, segments, and fields actually consumed;
- transport protocol;
- normal volume and peaks;
- acceptable latency;
- behavior in the event of duplicates or unavailability;
- clinical and operational impact of a failure.
Messages declared as HL7 v2.5, for example, may contain custom Z segments, local codes, and different interpretations of the same field. The nominal version does not replace the analysis of actual messages.
2. Define Contracts and Semantics
Syntactic interoperability means being able to read the message. Semantic interoperability means interpreting the data in the same way across all systems.
The contract must establish:
- field cardinality and required fields;
- date, unit, and precision formats;
- terminology systems adopted;
- handling of missing values;
- identification of the patient, encounter, and professional;
- rules for updates, cancellations, and corrections.
Whenever possible, terminologies such as LOINC, SNOMED CT, and ICD can reduce ambiguities while respecting licensing, scope, and institutional adoption. Local codes may still exist, but they require versioned and auditable mapping tables.
In FHIR, profiles, extensions, terminologies, and permitted operations must also be defined. Exposing a generic endpoint without an implementation guide merely transfers ambiguity to the API.
3. Address Identity and Deduplication
The same patient may have different numbers in the electronic health record, laboratory, and billing systems. Using only the patient’s name and date of birth creates a risk of incorrect matching.
The integration must maintain identifiers with their respective issuers and, when necessary, use a master patient index. The matching process must combine deterministic rules, human review for ambiguous cases, and an audit trail. Low-confidence automatic matches must not silently alter clinical records.
Idempotency must also be guaranteed. If a message is received twice, the expected result is usually a single update—not two exams, two prescriptions, or two charges.
4. Run Shadow Tests
In shadow mode, the new integration receives a copy of real traffic but does not yet control the official process. Its outputs are compared with those of the existing workflow.
Validation must measure at least:
- percentage of messages processed;
- messages rejected by error type;
- average latency and tail percentiles, such as p95 and p99;
- discrepancies in codes, units, statuses, and identification;
- duplicates and out-of-order events;
- recovery time after unavailability.
There is no universal target. Thresholds must be defined according to clinical criticality, volume, and the operational agreement. An administrative dashboard tolerates different conditions from a workflow that delivers results used in care decisions.
5. Cut Over by Workflow, Not the Entire Hospital
Activation may begin with one unit, message type, or consuming system. Examples include starting with ADT for an administrative application, then laboratory results, and finally workflows with greater clinical impact.
During the transition, it is possible to use:
- dual write: sending to both the old and new destinations;
- dual read: comparing two sources;
- feature flags: activation by unit or user group;
- canary: release to a small portion of traffic;
- blue-green: switchable environments for a rapid return.
Dual write requires care: success at one destination and failure at the other may create discrepancies. Therefore, acknowledgment, reconciliation, and reprocessing must be part of the design.
6. Maintain Rollback and Reconciliation
Rollback is not merely restoring a software version. It means knowing which messages were processed, which remain pending, and which produced irreversible effects.
Before each cutover, document:
- the objective condition for interrupting the deployment;
- the person responsible for deciding to revert;
- the procedure for redirecting traffic;
- how accumulated messages will be reprocessed;
- the method for reconciling source and destination;
- communication channels with clinical and administrative teams.
Security, LGPD, and Traceability
Health data is considered sensitive personal data under the LGPD. The integration must apply data minimization, access control, a defined purpose, and protection during transmission and storage.
Technical controls include TLS, service-to-service authentication, credential rotation, environment segregation, encryption at rest, and access logging. Logs must not expose complete medical records or tokens; when clinical data is essential for support, access must be restricted and auditable.
Each event must have a correlation identifier that makes it possible to follow its journey without relying on full exposure of its content. The audit must answer: who sent it, when it was received, which transformation was applied, who accessed it, and what the outcome was.
Checklist Before Putting the Integration into Production
- [ ] Clinical workflows and dependencies have been mapped.
- [ ] Actual messages, including custom segments, have been evaluated.
- [ ] FHIR profiles and mapping tables are versioned.
- [ ] Patient identity and idempotency have been tested.
- [ ] Queues, retries, and the dead-letter queue are operational.
- [ ] Availability, latency, rejection, and backlog metrics are available.
- [ ] Shadow testing compared old and new results.
- [ ] The rollback plan includes data reconciliation.
- [ ] Care teams know how to report inconsistencies.
- [ ] Access, logs, and retention comply with security and LGPD requirements.
Errors That Increase Risk the Most
The most frequent problems are directly integrating production databases, treating HL7 as a universal format without variations, ignoring local codes, and migrating all workflows in a single window. Another mistake is treating technical receipt as proof of success: an ACK confirms a specific stage of the protocol, but by itself it does not guarantee that the data produced the expected clinical effect.
It is also risky to convert each message directly to FHIR without preserving the original content. Retaining the received payload, mapping version, and transformation result facilitates auditing, correction, and reprocessing.
How Predictor Solutions Solves This
Predictor Solutions, a software house based in Lavras, Minas Gerais, works on healthcare system integration using HL7 v2 and FHIR. Its work combines workflow inventory, contract design, legacy adapters, FHIR APIs, messaging, observability, shadow testing, security, and gradual deployment.
The company also develops Predictor Health, focused on health dashboards and wearables, and Predictor AI Hospitals, aimed at predicting sepsis, heart attacks, and pneumonia in ICUs. These products require traceable clinical data and integrations that preserve the operation of source systems.
Across its overall project portfolio, Predictor Solutions reports serving 9 medium-sized and large companies, 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 are aggregate results from the company’s operations and should not be interpreted as a specific guarantee for an interoperability project; each hospital depends on scope, data quality, and operational maturity.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246