Connecting legacy hospital systems without disrupting operations requires an interoperability layer that keeps existing systems running while translating, validating, and distributing data in HL7 v2, FHIR, or proprietary formats. The safest approach combines incremental deployment, asynchronous processing, parallel operation, data reconciliation, and a real rollback capability.
Why Hospital Integration Cannot Depend on a Single Cutover
In hospitals, downtime does not only affect productivity: it can prevent access to allergies, laboratory results, prescriptions, beds, and identification data. Therefore, replacing all interfaces within a single deployment window—the so-called big bang—usually represents an unnecessary risk.
The most common environment contains a combination of:
- a legacy HIS or hospital management system;
- an electronic health record, or EHR;
- LIS laboratory systems;
- RIS and PACS radiology systems;
- pharmacy, billing, prescribing, and bed management systems;
- devices that send data through proprietary protocols;
- HL7 v2 messages using different versions and profiles;
- recent REST APIs without a standardized clinical model;
- databases accessed through files, views, or point-to-point integrations.
The initial goal should not be to “modernize everything.” First, it is necessary to ensure that each clinical event reaches the correct destination exactly once, with its identity, meaning, and traceability preserved.
The Role of HL7 v2 and FHIR in the Architecture
HL7 v2 and FHIR do not need to compete. In a well-planned transition, both can operate simultaneously.
Where HL7 v2 Remains Relevant
HL7 v2 is widely used for hospital events and communication between internal systems. Common examples include:
- ADT for admission, transfer, and discharge;
- ORM or OML for orders;
- ORU for results and observations;
- SIU for scheduling;
- financial messages, depending on the implemented workflow.
Messages usually travel through MLLP over TCP, although files and other transports also exist. Receipt should produce an ACK or NACK, but a technical ACK only confirms the processing agreed upon by the parties; it does not replace clinical validation or confirmation that all downstream systems have been updated.
It is also not enough to declare support for “HL7 v2.” The version, message type, event, required segments, codes, custom fields, and expected behavior when errors occur must be documented.
Where FHIR Adds Value
FHIR organizes information into resources such as Patient, Encounter, Observation, Condition, MedicationRequest, and DiagnosticReport. These resources can be accessed through REST APIs, searches, operations, and other mechanisms defined by the standard.
FHIR is especially useful for:
- exposing a standardized clinical API;
- integrating applications, portals, and analytics platforms;
- reducing dependence on a vendor’s internal database;
- controlling access by resource and context;
- building new services without immediately modifying the legacy system.
Even so, an API is only interoperable when a clear contract exists. The FHIR version, profiles, terminologies, cardinalities, extensions, HTTP codes, and search rules must be defined. “FHIR-compatible JSON” does not guarantee interoperability without validation against the adopted profiles.
Architecture for Migrating Without Disrupting the Hospital
The recommended strategy follows the strangler pattern: new capabilities are built around the legacy system and gradually take over workflows. The old system remains active until the new path demonstrates stability and completeness.
A typical architecture has five components.
1. Input Adapters
Each system connects through an adapter compatible with its environment: MLLP, API, file, queue, controlled database access, or another authorized protocol. The adapter should separate transport from clinical rules, preventing connection changes from affecting the entire workflow.
2. Integration Engine
The engine receives, validates, transforms, and routes messages. It should also preserve the original message, generate correlation identifiers, and prevent a temporary failure from resulting in silent data loss.
3. Canonical Model
An intermediate model reduces the number of transformations. Instead of creating dedicated converters between every pair of systems, each source is translated into the canonical model, and each destination receives its specific transformation.
FHIR can be part of this model, but not all legacy data has a direct and immediate equivalent. Extensions, mapping tables, and provenance rules must be governed to prevent semantic loss.
4. Queues and Asynchronous Processing
Queues decouple systems and absorb spikes. If the LIS becomes unavailable, for example, events can remain queued and be resent later, within the defined operational limits.
For this to work, consumers must be idempotent. Reprocessing the same event cannot create two admissions, duplicate an observation, or repeat a charge.
5. Observability and Audit Trail
The team must be able to answer quickly:
- which system originated the event;
- when it was received;
- which transformations were applied;
- which destinations confirmed processing;
- why a message failed;
- whether resending or manual intervention occurred.
Technical logs, metrics, and tracing should use correlation identifiers, but they should not expose unnecessary clinical data. Access to the audit trail must be controlled and auditable.
Seven-Stage Deployment Plan
1. Inventory the Actual Workflows
Map systems, owners, versions, transports, volume, acceptable latency, critical windows, and the consequences of failure. Compare documentation with actual traffic: old interfaces frequently contain undocumented custom fields.
2. Classify Criticality
Separate workflows by impact. Admissions, allergies, medications, and critical results require different controls than administrative reports. Define RTO, RPO, and contingency procedures for each group instead of using a generic target for the entire hospital.
3. Formalize Contracts
For each interface, document:
- source and destination;
- triggering event;
- HL7 or FHIR version;
- required and optional fields;
- terminologies and units;
- patient and encounter identifiers;
- ACK, error codes, and retry policy;
- deduplication and reconciliation rules.
4. Test with Representative Data
Tests should include accented characters, patients with the same name, patients without identification documents, demographic changes, corrected results, out-of-order messages, empty fields, duplicates, network outages, and high volumes. Real data should only be used when an appropriate legal basis, access control, and protection are in place; test environments should favor synthetic or properly de-identified data.
5. Run in Shadow Mode
In shadow mode, the new integration receives a copy of the events but does not yet control the care delivery process. Its outputs are compared with the existing path to measure discrepancies without affecting users.
Advancement criteria may include the valid-message rate, absence of data loss, latency by percentile, identifier consistency, and reconciliation completion. Thresholds should be defined according to the criticality of the workflow, not by a universal percentage.
6. Perform a Progressive Rollout
First activate a lower-risk unit, event type, or destination. Keep the previous path available until the new workflow meets the agreed criteria over a representative period, including shift changes and peaks in patient volume.
7. Decommission Based on Evidence
An old interface should only be removed after reconciliation and joint approval by the clinical, operational, and technical departments. Preserve the required documentation, audit trails, and restoration procedure according to institutional policy.
Production Readiness Checklist
Before cutting over any workflow, confirm:
- [ ] versioned and approved HL7/FHIR contracts;
- [ ] validated patient and encounter identification;
- [ ] duplicate messages handled with idempotency;
- [ ] queues, retries, and a failed-message queue configured;
- [ ] alerts for latency, errors, and message backlogs;
- [ ] reconciliation between source and destination automated whenever possible;
- [ ] rollback tested, not merely documented;
- [ ] clinical contingency procedures known by on-call teams;
- [ ] permissions based on least privilege;
- [ ] encryption in transit and protection of secrets;
- [ ] log retention compatible with the LGPD and internal policies;
- [ ] vendors and responsible personnel available during deployment.
Trade-Offs That Must Be Decided
Real-time versus asynchronous processing: urgent clinical events may require low latency, while historical loads work better in batches. Requiring real-time processing for everything increases costs and coupling.
Native FHIR versus translation: immediately replacing all models with FHIR can extend the project timeline. A translation layer accelerates coexistence, but it needs governance to avoid becoming an opaque collection of rules.
Immediate versus eventual consistency: queues increase resilience, but some destinations may temporarily lag behind. The tolerable limit must be explicit for each workflow.
Database access versus an official interface: accessing tables may seem fast, but it creates dependency on the internal schema, security risks, and problems during upgrades. It should be a controlled exception when no supported interface is available.
Buying versus building: off-the-shelf engines accelerate connectivity and operations; custom development provides flexibility. The decision should consider licensing, support, internal expertise, volume, observability, and maintenance costs over several years.
Security and the LGPD in Interoperability
Health data is sensitive personal data. The architecture must apply data minimization, environment segregation, access control, auditing, secrets management, and encryption. The legal basis, purpose, retention, and responsibilities shared between the hospital and vendors must also be defined with support from legal counsel and the data protection officer.
Do not indiscriminately log complete clinical payloads. When content is required for support or auditing, apply restricted access, masking whenever possible, a retention period, and access logging. Backups and queues are also part of the protection perimeter.
How Predictor Solutions Addresses This
Predictor Solutions has hands-on experience with healthcare integrations using HL7 v2 and FHIR, combining software engineering, data engineering, cloud/DevOps, and security. The work begins with an inventory of interfaces and clinical risks, followed by versioned contracts, adapters, queues, observability, load testing, and progressive deployment without requiring the immediate replacement of legacy systems.
The company also develops Predictor Health, focused on health dashboards and wearables, and Predictor AI Hospitals, designed to predict sepsis, myocardial infarction, and pneumonia in ICUs. This experience requires treating interoperability not merely as format conversion, but as a guarantee of identity, clinical context, quality, provenance, and availability.
Across its software, data, and automation projects, Predictor Solutions serves 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. In hospital integration, any target must be validated separately according to the systems, volume, infrastructure, and criticality of care.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.