Connecting legacy hospital systems without interrupting operations requires an incremental architecture: keep existing interfaces, capture clinical events, normalize the data, and publish it through HL7 v2 or FHIR APIs. The transition should occur by clinical workflow, with parallel execution, message validation, reconciliation, and rollback capability—never through a full replacement within a single maintenance window.
Why hospital integration cannot depend on a single cutover
Hospitals operate continuously, and an integration failure can prevent an admission from being recorded, delay a laboratory result, or associate information with the wrong patient. Therefore, replacing the HIS, LIS, RIS, PACS, electronic health record, and administrative systems simultaneously usually represents an unnecessary risk.
Legacy systems are also not uniform. A device may send HL7 v2.3 over TCP/IP, an administrative system may work with CSV files over SFTP, and a newer application may provide REST APIs. Even implementations that claim to use the same HL7 v2 version may handle fields, codes, and optional segments differently.
The safest approach is the progressive modernization pattern, also known as the strangler pattern: an interoperability layer begins managing new integrations while the legacy systems continue operating. Each workflow is migrated, observed, and validated separately.
HL7 v2 and FHIR serve different roles
HL7 v2 remains widely associated with exchanging events between hospital systems. Messages are event-driven and consist of delimited segments such as MSH, PID, PV1, ORC, and OBX. Common examples include:
- ADT: admission, discharge, transfer, and demographic updates;
- ORM or OML: test and procedure orders;
- ORU: laboratory results and clinical observations;
- SIU: scheduling;
- MDM: clinical documents.
FHIR, or Fast Healthcare Interoperability Resources, represents information through resources such as Patient, Encounter, Observation, DiagnosticReport, Condition, and MedicationRequest. It usually uses HTTP APIs and JSON, although the standard is not limited to REST.
FHIR is not simply a conversion from HL7 v2 to JSON. An ADT event may affect Patient, Encounter, and related resources, while an ORU may require Observation and DiagnosticReport. The modeling must preserve context, identifiers, codes, authorship, and clinical dates.
In practice, both standards can coexist: HL7 v2 remains in communication with legacy systems, while FHIR provides a more consistent layer for portals, applications, analytics, and new services.
Recommended architecture for modernization without downtime
A transition architecture usually has five components.
1. Source adapters
They receive data through the available protocols: MLLP/TCP, database, SOAP, REST, files, or queues. The adapter should acknowledge receipt only after the message has been durably recorded.
2. Integration engine
It performs routing, transformation, validation, and exception handling. It should also record the version of each mapping rule because changes to fields or codes can alter the clinical meaning.
3. Canonical model
It reduces coupling between source and destination. Instead of building independent conversions for each pair of systems, the data is normalized into an intermediate model and then transformed into HL7 v2, FHIR, or another format.
4. Durable repository and queue
Messages need to survive temporary outages. Queues, controlled retries, and a dead-letter queue prevent silent loss and allow reprocessing.
5. FHIR APIs and services
The FHIR layer serves modern consumers and must enforce authentication, authorization, auditing, and versioning. When necessary, profiles and implementation guides constrain resources for a specific context.
The inventory that must precede any change
Before developing connectors, map the actual environment. The inventory must answer:
- Which systems produce and consume each piece of information?
- Which system is the source of truth for the patient, encounter, order, and result?
- Which HL7 v2 versions and events are active?
- Which local fields, Z-segments, and proprietary tables are used?
- How are patients and encounters identified in each system?
- What are the average and peak message volumes?
- What delay is acceptable for each workflow?
- Does the system send ACKs, support reprocessing, and preserve event order?
- How are cancellations, corrections, and medical record merges handled?
- Which team responds to failures outside business hours?
Anonymized real-world samples are more useful than isolated manuals. Documentation may state that a particular field is mandatory, while the live operation has been sending empty values or local codes for years.
Patient identity is the most critical point
The greatest risk is not a technically invalid message, but a valid message associated with the wrong person. The integration needs to distinguish at least three identifiers:
- the patient identifier in the source system;
- the enterprise or master patient identifier;
- the encounter or clinical episode identifier.
Patients should not be reconciled based on name alone. Date of birth, identification documents, registered sex, phone number, and other attributes can support matching, but the rules must account for duplicates, demographic changes, and data quality.
When no reliable enterprise identifier exists, it may be necessary to implement a master patient index. Uncertain matches should be sent for review instead of being linked automatically.
Six-stage migration plan
1. Choose a relatively low-risk workflow
Start with a domain that has clear boundaries and allows verification. Avoid starting with the most critical set simply because it has greater visibility.
2. Capture without interfering
Mirror messages or replicate events to the new layer while keeping the current destination. This shadow-mode execution makes it possible to understand volume, variations, and errors without affecting patient care.
3. Validate structure and semantics
Check segments, cardinalities, types, codes, and relationships. A message may be syntactically correct while still representing the unit, status, or result date incorrectly.
4. Run in parallel
Send events through both the old and new paths for a period determined by volume and criticality. Compare metrics such as:
- total events produced, received, and processed;
- rejected or pending messages;
- latency at the 50th, 95th, and 99th percentiles;
- identifier and code discrepancies;
- corrected or canceled results;
- recovery time after an outage.
There is no universal number of days for validation. The period should include peak loads, weekends, and less frequent events such as transfers, cancellations, and demographic merges.
5. Perform the cutover by consumer
Migrate one system or workflow at a time. Keep the previous mechanism available for a controlled period and document objective rollback criteria.
6. Reconcile and decommission deliberately
After the cutover, compare counts and clinical samples. A legacy interface should only be shut down when there are no hidden consumers and when auditing, retention, and reprocessing are assured.
Essential reliability and security controls
Every message needs a correlation identifier, receipt timestamp, source, destination, status, and retry history. Processing must be idempotent: resending a message cannot create two orders or two results.
Other essential controls include:
- encryption in transit and at rest;
- role-based access and least privilege;
- tamper-resistant audit trails;
- masking personal data in logs;
- retention consistent with the intended purpose and applicable obligations;
- monitoring of queues, latency, errors, and outages;
- restoration and continuity testing;
- separation between development, testing, and production.
In Brazil, health data is sensitive personal data under the LGPD. The architecture must limit collection, exposure, and access without indiscriminately using real clinical information in test environments.
Criteria for choosing whether to retain HL7 v2, adopt FHIR, or combine both
Retain HL7 v2 when the existing system already has a stable interface and changing the protocol does not provide an operational benefit. Adopt FHIR when new consumers need searchable APIs, structured resources, and contracts better suited to web and mobile applications.
Use a hybrid strategy when:
- devices and legacy systems depend on HL7 v2;
- new channels need to consume APIs;
- analytics requires normalized data;
- replacement of the electronic health record will occur gradually;
- multiple vendors need to share a consistent contract.
The decision should consider criticality, total cost, team capabilities, vendor support, volume, latency, and semantic governance—not only how modern the standard is.
How Predictor Solutions solves this
Predictor Solutions, a software house based in Lavras, Minas Gerais, develops healthcare systems with HL7 v2 and FHIR integration. Its work combines interface inventory, source-of-truth definition, semantic mapping, adapter development, APIs, observability, parallel testing, and progressive migration to reduce operational risk.
The company also develops Predictor Health, focused on health dashboards and wearables, and Predictor AI Hospitals, designed to predict sepsis, heart attacks, and pneumonia in ICUs. These products require clinical data to be identified, contextualized, and made reliably available; artificial intelligence does not fix an integration that lacks governance.
Across its software, data, and automation projects, Predictor Solutions reports serving 9 medium and large companies, average savings of R$ 1.32 million per client per year, an average 70% increase in productivity, and 43% profit growth in six months. These figures are overall portfolio results and not an automatic promise for every interoperability project.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.