Connecting legacy hospital systems without disrupting operations requires an interoperability layer that enables HL7 v2, FHIR, and proprietary formats to coexist. The safest approach is to migrate one workflow at a time, maintain parallel processing, validate clinical data, and prepare a rollback plan before replacing any interface in production.
Why hospital integrations cannot be treated like ordinary APIs
In a hospital, an integration failure can prevent a prescription from being updated, delay the release of a laboratory result, or create discrepancies in a patient’s record. The problem is not merely technical: it affects continuity of care, billing, auditing, and patient safety.
Hospital environments commonly combine:
- Hospital Information Systems (HIS) or hospital ERPs;
- electronic health records;
- laboratory systems, known as LIS;
- radiology systems, such as RIS and PACS;
- pharmacy, prescribing, and dispensing systems;
- monitoring equipment;
- administrative and billing systems;
- proprietary applications developed years ago;
- external services, health insurance providers, and public platforms.
These components may use HL7 v2, DICOM, CSV files, XML, shared databases, SOAP web services, or proprietary APIs. Even systems that claim to support the same standard frequently implement fields, codes, and events differently.
For this reason, the first rule is simple: do not replace all interfaces at once. The integration must be decoupled, observable, and reversible.
The role of HL7 v2 and FHIR in the architecture
HL7 v2 and FHIR are not competing standards that require an exclusive choice. They address different contexts and can coexist throughout the modernization process.
Where HL7 v2 remains relevant
HL7 v2 is widely used for event-driven message exchange. Typical workflows include:
- ADT for admission, discharge, and transfer;
- ORM for examination and procedure orders;
- ORU for results and observations;
- SIU for scheduling;
- MDM for clinical documents.
In many environments, messages are transmitted through MLLP over TCP. The receiver must interpret segments, validate required fields, and respond with an ACK or NACK. It must also handle local particularities, such as Z-segments, custom tables, and different HL7 v2 versions.
When an existing HL7 v2 interface is stable, replacing it simply because it is old may increase risk without generating any clinical benefit. It is safer to encapsulate it and normalize its data in the integration layer.
Where FHIR adds value
FHIR represents healthcare information through resources such as Patient, Encounter, Observation, Condition, MedicationRequest, and DiagnosticReport. These resources can be accessed through REST APIs, searched using parameters, and grouped into a Bundle.
FHIR tends to facilitate:
- web and mobile applications;
- patient portals;
- integration with modern services;
- structured data sharing;
- clinical analytics and data engineering;
- controlled use of artificial intelligence.
Implementing FHIR, however, does not simply mean converting data to JSON. Profiles, cardinalities, terminologies, identifiers, and business rules must be defined. The team must also verify which version and which Implementation Guides are supported by each system.
Recommended architecture to keep the hospital running
The most resilient architecture introduces an intermediary layer between producers and consumers. It operates as an anti-corruption layer: it receives legacy formats, applies validations, and publishes a canonical representation or one adapted to the destination.
The most common components are:
- Inbound adapters: receive MLLP, files, SOAP, controlled database queries, or REST calls.
- Integration engine: routes messages, applies transformations, and executes rules.
- Queue or broker: decouples systems and absorbs spikes without blocking the source.
- Terminology and mapping repository: maps local codes to the adopted standards.
- FHIR server: validates, stores, or exposes resources according to the use case.
- Observability: records metrics, logs, traces, and alerts.
- Exception queue: preserves messages that require reprocessing or human intervention.
The legacy system should not directly access the new system’s internal structures, nor should the new system depend on the legacy system’s private tables. Explicit contracts reduce the impact of future changes.
Step-by-step migration plan
1. Inventory interfaces and dependencies
Before writing code, document the following for each workflow:
- source and destination systems;
- event that triggers the exchange;
- protocol and format;
- frequency and volume;
- required fields;
- clinical and technical owners;
- network and infrastructure dependencies;
- behavior in case of unavailability;
- impact of delays, duplicates, or losses.
Classify the criticality. An urgent laboratory result, for example, requires different handling from an administrative demographic update.
2. Define the canonical model without erasing the source
The canonical model reduces point-to-point transformations, but it must not eliminate information required for auditing. Preserve the original message, source identifier, receipt date, and version of the mapping that was applied.
Patient identity must also be resolved. Name and date of birth alone are not sufficient. The design must consider local identifiers, documents, medical record numbers, and institutional reconciliation rules, preventing different records from being merged automatically and unsafely.
3. Build a pilot interface
Start with a well-defined workflow with a known volume and the possibility of verification. The goal is to validate connectivity, semantics, performance, and operations—not merely to demonstrate that a message reached its destination.
The pilot should test:
- valid and invalid messages;
- missing fields;
- special characters and encoding;
- duplicate or out-of-order messages;
- network outages;
- destination unavailability;
- resubmission and reprocessing;
- demographic changes during the encounter.
4. Run in parallel mode
In parallel mode, the current workflow remains the operational reference while the new integration receives a copy of the events. Outputs are compared without interfering with patient care.
Reconciliation should evaluate at least:
- number of events at the source and destination;
- associated patients, encounters, and identifiers;
- clinical values, units, and codes;
- dates and time zones;
- percentage of rejected messages;
- latency between generation and availability.
Acceptance criteria must be defined by the hospital. As an example of an SLO, and not as a universal rule, an institution may require 99.9% monthly availability and latency below 60 seconds for a specific workflow. The correct target depends on clinical criticality and the existing infrastructure.
5. Perform the cutover with rollback prepared
The transition should occur by workflow, unit, specialty, or controlled group of users. Before the cutover, confirm:
- message backup and retention;
- active monitoring;
- technical team availability;
- a decision channel with care team representatives;
- a tested rollback procedure;
- queues have been drained or accounted for;
- the window and criteria for aborting the change.
Rollback cannot mean improvising a restoration. There must be a documented path for returning traffic to the previous interface without losing events received during the attempt.
Essential reliability controls
Idempotency and duplicates
Resubmissions are inevitable. Each message or operation must have an idempotency key based on reliable identifiers, such as message control, source system, and event. This prevents a repeated message from creating two admissions, two examinations, or two prescriptions.
ACK, retries, and exception queues
In HL7 v2, receiving an ACK does not necessarily guarantee that the entire clinical process has been completed; this depends on the interface contract. Distinguish between technical acceptance, semantic validation, and final processing.
Retries should use increasing intervals and a configurable limit. Unrecoverable messages must be sent to an exception queue with enough context for analysis and safe reprocessing.
End-to-end observability
An operational dashboard should display:
- messages received, processed, and rejected;
- queue size and age;
- latency by interface;
- NACK rate and errors by cause;
- connector availability;
- last event processed by each system;
- discrepancies found during reconciliation.
Logs should use correlation identifiers while avoiding unnecessary exposure of personal and clinical data.
Security, LGPD, and clinical governance
Health data is sensitive personal data under Brazil’s LGPD. The integration must apply role-based access control, system-to-system authentication, encryption in transit, secrets management, audit trails, and retention policies.
Plain MLLP does not, by itself, provide all the protections expected in modern networks. Depending on the architecture, it may be necessary to use a segregated network, VPN, TLS through intermediary components, and source and destination restrictions.
In FHIR, the API must not be exposed without authentication and authorization controls. OAuth 2.0 and OpenID Connect may be part of the solution, but permissions must reflect the purpose, user profile, and data scope. Security does not end with the token: broad queries, exports, and logs also require governance.
Checklist for choosing the strategy
Before starting, confirm whether the proposal clearly answers:
- Which workflows will remain on HL7 v2?
- Which use cases justify FHIR?
- Where will the semantic transformation take place?
- How will Z-segments and local codes be handled?
- Is there reliable identification of the patient and encounter?
- How will duplicates and out-of-order events be processed?
- What is the maximum acceptable delay for each workflow?
- How will messages be audited and reprocessed?
- Has the rollback actually been tested?
- Who decides whether a discrepancy is technical or clinical?
If these answers are not documented, the risk is merely hidden inside the implementation.
How Predictor Solutions addresses this
Predictor Solutions designs healthcare integrations with HL7 v2 and FHIR, connecting legacy systems to APIs, data platforms, and clinical applications through adapters, queues, validation, observability, and gradual migration. The team also develops Predictor Health, focused on healthcare dashboards and wearables, and Predictor AI Hospitals, designed to predict sepsis, myocardial infarction, and pneumonia in ICUs.
The implementation combines assessment of care workflows, interface contracts, testing with properly protected real-world messages, parallel operation, and a rollback plan. As a reference for the company’s operational capacity, Predictor Solutions has served 9 medium-sized and large companies, with reported average results of R$ 1.32 million in savings per client per year, a 70% increase in productivity, and a 43% increase in profit over six months; however, each hospital project must define and measure its own indicators.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246