Integrating legacy hospital systems without interrupting operations requires an intermediary architecture that receives HL7 v2, FHIR APIs, files, and proprietary events, normalizes the data, and distributes it with traceability. The safest approach is to deploy the integration in parallel, validate messages with controlled real-world data, and migrate each flow gradually while preserving the ability to roll back.
Why hospital integration cannot be an abrupt replacement
Hospitals operate electronic health records, laboratory, radiology, pharmacy, billing, bed management, and equipment systems that evolved at different times. One system may send HL7 v2 messages over MLLP, another may expose a REST API, and a third may depend on CSV files, network shares, or scheduled routines.
Replacing everything at once creates clinical and operational risks. An outage may prevent access to results, delay medication dispensing, or produce duplicate records. Therefore, the goal should not be merely to “make the systems communicate,” but to preserve four properties:
- Continuity: the source system continues operating during deployment.
- Consistency: the same patient, encounter, and test must be identified across applications.
- Traceability: each message must have a source, destination, timestamp, status, and processing history.
- Recovery: failures must trigger controlled retries or routing for analysis, without silent data loss.
The first step is to map existing flows before choosing technologies. For each integration, document the source and destination systems, protocol, average and peak volume, acceptable latency, clinical criticality, owner, and the manual procedure used when the flow fails.
HL7 v2 and FHIR serve different purposes
Where HL7 v2 remains relevant
HL7 v2 is widely used in message-oriented hospital integrations. Events such as admission, transfer, and discharge are commonly represented by ADT messages; orders and results may use families such as ORM and ORU, depending on the version and local implementation.
In practice, two applications that claim to support HL7 v2 are not automatically compatible. Optional fields, local codes, versions, and custom segments vary. An integration profile must be produced to document:
- the version used, such as 2.3, 2.4, or 2.5.1;
- accepted message types and events;
- required fields and conditional rules;
- code tables and units;
- custom segments, usually identified by the letter Z;
- ACK, timeout, and resend behavior.
MLLP is a common transport for HL7 v2 messages over persistent TCP connections. It is simple, but by itself it does not address encryption, authentication, retention, monitoring, or reprocessing. These controls must be implemented in the network, integration engine, or additional components.
Where FHIR helps
FHIR organizes clinical and administrative information into resources such as Patient, Encounter, Observation, Condition, and MedicationRequest. These resources can be accessed through HTTP APIs, searched, and combined in modern workflows for applications, portals, analytics, and artificial intelligence services.
FHIR does not mean merely transforming an HL7 v2 message into JSON. The integration must define profiles, terminologies, cardinalities, references, and validation rules. The official specification is available at hl7.org/fhir, but each project must still establish its own implementation guide.
A common strategy is to retain HL7 v2 at the boundary of older systems and use FHIR as the contract for new services. This avoids requiring immediate changes to the legacy system.
Architecture for integrating without stopping hospital operations
A resilient architecture typically contains six layers:
- Input adapters: receive HL7 v2/MLLP, APIs, files, or proprietary events.
- Initial persistence: records the received content before any significant transformation.
- Validation: checks structure, required fields, codes, and business rules.
- Canonical model: represents patients, encounters, tests, and observations independently of the vendor.
- Asynchronous distribution: queues or streams decouple source and destination and absorb traffic spikes.
- Observability: metrics, correlated logs, alerts, and dashboards show the status of each flow.
The canonical model reduces point-to-point transformations. Without it, five systems may require up to 20 distinct directional connections. With an intermediary layer, each application maintains more predictable input and output contracts. The trade-off is the need to govern the model and prevent it from becoming overly broad or abstract.
Identity, idempotency, and ordering
The patient identifier is one of the greatest risk areas. CPF should not be assumed to be a universal clinical identifier because it may be missing, incorrect, or improperly shared. The solution must preserve local identifiers and maintain a cross-reference table, ideally with reconciliation rules and human review for ambiguous cases.
An idempotency key must also be defined. A message resent after a timeout cannot create a second admission or duplicate a result. The key may combine the message identifier, sending system, and event version, provided that the behavior is formally documented.
Not every flow requires global ordering. However, events related to the same encounter may need to be processed in the correct sequence. Partitioning queues by patient or encounter helps preserve order without serializing the entire hospital.
Seven-step migration plan
1. Inventory and classify
Classify each interface by clinical impact, volume, and tolerance for downtime. Start with an observable and reversible flow, not the most critical process.
2. Capture a baseline
Measure before the change: messages per minute, latency, failures, duplicates, and resolution time. Without a baseline, there is no way to prove that the new integration is better or to identify regressions.
3. Create contract tests
Build valid and invalid examples, remove or anonymize personal data whenever possible, and test missing fields, unknown codes, duplicate messages, and unavailable destinations. Synthetic data helps, but it does not replace validation against variations found in real-world operations.
4. Run in shadow mode
In shadow mode, the new platform receives a copy of the events, processes them, and compares the results, but it does not control the official flow. Discrepancies are analyzed without affecting patient care.
5. Use dual writes cautiously
When necessary, send data through both the old and new paths for a limited period. Define which system is the source of truth; otherwise, concurrent corrections may diverge. Prolonged dual writes increase complexity and must have an explicit termination criterion.
6. Migrate by flow and unit
Activate one message type, department, or unit first. Monitor latency, negative ACKs, queue backlog, and reconciliation. Expand only when the acceptance criteria have been met.
7. Maintain operational rollback
Rollback is not merely restoring a version. It must specify how to redirect messages, reprocess accumulated events, and reconcile changes made during the rollback window.
Technical checklist before going into production
- [ ] Versioned HL7 v2 or FHIR profiles approved by the system owners.
- [ ] Timeouts, ACKs, resends, and retry limits defined.
- [ ] Idempotency tested with repeated messages.
- [ ] Queue for unprocessed messages, including the reason and reprocessing procedure.
- [ ] Logs without unnecessary exposure of personal or clinical data.
- [ ] Encryption in transit and at rest according to the architecture.
- [ ] Least-privilege access and audit trail.
- [ ] Alerts for increased latency, errors, and unexpected absence of messages.
- [ ] Backup, restoration, and disaster recovery tested.
- [ ] Contingency plan understood by clinical, operational, and IT teams.
Security and LGPD in interoperability
Health data is sensitive personal data under the LGPD. The integration must limit collection, access, retention, and sharing to what is necessary for the defined purpose. Development and testing environments should not receive complete copies of production data without appropriate controls.
Secrets must remain outside the source code. APIs must use authentication and authorization appropriate to the risk; legacy connections may require network segmentation, VPNs, or protected gateways. Logs must record enough technical identifiers for investigation while avoiding the storage of complete clinical content for convenience.
Technical controls do not replace governance. Hospitals, vendors, and operators must define responsibilities, legal bases, retention periods, and incident response procedures.
How Predictor Solutions handles this
Predictor Solutions, a software house based in Lavras, Minas Gerais, designs healthcare systems with HL7 v2 and FHIR integration. Its work includes flow discovery, contract definition, adapters for legacy systems, messaging, canonical models, automated testing, observability, cloud/DevOps, and security controls.
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. Across its software projects, Predictor Solutions reports having served nine medium-sized and large companies, with 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 results are aggregated and depend on the context of each operation.
The interoperability goal is to migrate in stages, keep the legacy system operating, and create a verifiable foundation for new portals, automations, analytics, and AI applications.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246