Connecting legacy hospital systems without disrupting operations requires a coexistence architecture: the current system continues to operate while an integration layer translates, validates, and distributes HL7 v2 messages and FHIR resources. Migration must occur by clinical workflow, with parallel processing, contract testing, monitoring, reconciliation, and rollback—never through an abrupt replacement of the entire environment.
Why Hospital Integration Is Especially Difficult
Hospitals operate a combination of electronic health records, laboratory, radiology, pharmacy, billing, medical devices, and departmental applications. Many of these systems were deployed at different times and use incompatible databases, codes, and protocols.
The complexity is not limited to the data format. The clinical meaning, event sequence, and correct identity of patients and professionals must be preserved. A technically valid message can cause problems if it associates a laboratory result with the wrong encounter or incorrectly interprets a unit of measurement.
The main obstacles are:
- different HL7 v2 versions and customizations;
- optional fields treated as mandatory by local systems;
- proprietary codes for tests, medications, and departments;
- duplicate or conflicting patient records;
- systems that only send files or access databases directly;
- dependence on vendors to modify interfaces;
- lack of representative staging environments;
- continuous clinical operations, including nights and weekends.
Therefore, “without disrupting operations” does not mean the complete absence of risk. It means reducing risk through controlled coexistence, reversible changes, and fault isolation.
What Is the Role of HL7 v2 and FHIR?
HL7 v2 and FHIR are not mutually exclusive alternatives. In a hospital with legacy systems, both standards normally coexist.
HL7 v2 for Operational Events
HL7 v2 is widely used to transmit clinical and administrative events. An ADT message can communicate an admission, transfer, or discharge; an ORM, an order; and an ORU, a test result.
Transport usually occurs through MLLP over TCP, although there are implementations based on files, queues, and other mechanisms. Each message contains segments such as MSH, PID, PV1, and OBX. The receiver responds with an ACK, indicating technical acceptance or rejection.
Receiving an ACK does not guarantee that the data was processed correctly at the destination. The integration must distinguish at least three states:
- message delivered to the channel;
- message accepted syntactically;
- event correctly applied to the destination system.
FHIR for APIs and Modern Ecosystems
FHIR organizes information into resources such as Patient, Encounter, Observation, DiagnosticReport, MedicationRequest, and Condition. These resources can be accessed through REST APIs, searches, operations, documents, messages, and subscriptions, depending on the use case.
FHIR facilitates connections with web applications, analytics platforms, patient applications, and artificial intelligence services. However, publishing JSON with names similar to those of the resources does not make an API compatible. The version, profiles, terminologies, cardinalities, extensions, and validation rules must be defined.
The official specifications should be consulted at HL7 v2 and FHIR.
Recommended Architecture for Integration Without Disruption
The safest architecture adds an intermediary layer without requiring all systems to be modified simultaneously.
Integration Engine
The integration engine receives messages, validates structures, transforms fields, applies rules, routes events, and records processing. It decouples the systems: the laboratory does not need to know the details of the FHIR API used by an analytics application.
A typical architecture includes:
- MLLP, REST, file, queue, or database connectors;
- normalization into a canonical model;
- terminology and mapping service;
- temporary storage for reprocessing;
- message queue with retry control;
- FHIR API or interoperability facade;
- correlated logs and an operational dashboard;
- exception queue for human intervention.
The engine must not become an opaque set of rules. Transformations must be versioned, reviewed, and covered by automated tests.
Canonical Model and Translation
Without an intermediary model, each new system requires point-to-point integrations. With ten systems, the potential number of connections grows quickly and increases maintenance costs.
The canonical model represents common concepts—patient, encounter, observation, order, and result—regardless of the source format. A workflow can follow this sequence:
HL7 v2 → validation → canonical model → terminology normalization → FHIR resource → consuming system
Not all HL7 v2 data has a direct and unique equivalent in FHIR. The mapping must document decisions, information loss, and the extensions used. Unknown fields must not be silently discarded.
Step-by-Step Deployment Plan
A secure integration is delivered in small, measurable increments.
1. Inventory Systems and Workflows
The inventory must identify owners, vendors, versions, protocols, volumes, and criticality. For each interface, document:
- source and destination;
- message or resource types;
- average volume and hourly peak;
- maximum acceptable delay;
- behavior in the event of unavailability;
- identifiers used for patients and encounters;
- ability to resend and reconcile;
- permitted change window.
Prioritize a relevant workflow with a controllable impact. Noncritical laboratory results for an analytics platform, for example, may be a safer starting point than medication orders.
2. Capture a Representative Sample
Layouts provided in documents rarely cover all real-world variations. The team must analyze anonymized or protected messages, including normal cases, cancellations, corrections, duplicates, and missing fields.
The sample must account for operational peaks and differences between facilities. Production data must only be used with controls compatible with the LGPD, a defined purpose, and restricted access.
3. Create Contract Tests
The tests must verify structure and semantics. Examples include:
- PID contains the expected patient identifier;
- PV1 references the correct encounter;
- OBX preserves the unit, value, range, and status;
- duplicate messages do not create duplicate records;
- corrections replace or supplement the previous result;
- FHIR resources comply with the agreed profiles;
- failures generate understandable operational codes and messages.
A set of “golden messages,” with expected inputs and outputs, makes it possible to detect regressions when rules are changed.
4. Run in Shadow Mode
In shadow mode, the new pipeline receives a copy of the events but does not interfere with the primary clinical process. Its outputs are compared with those of the current workflow.
The following should be measured:
- percentage of valid messages;
- patient and encounter discrepancies;
- latency at the 50th, 95th, and 99th percentiles;
- volume of duplicates;
- messages without terminology mappings;
- failures by source, type, and version.
Progress depends on agreed criteria. In critical clinical workflows, accepting “almost everything” without analyzing the exceptions can be dangerous.
5. Perform a Gradual Cutover
The cutover can occur by facility, message type, consuming system, or patient group. For a period, maintain parallel processing and daily reconciliation.
The rollback plan must specify who makes the decision, how traffic returns to the previous workflow, and how accumulated events will be handled. A rollback without a data strategy may restore the system while leaving information inconsistent.
Observability, Security, and Continuity
Monitoring only CPU and memory is insufficient. Observability must track clinical events end to end using a correlation identifier, without unnecessarily exposing sensitive data in logs.
Minimum indicators include:
- messages received, processed, rejected, and pending;
- latency by channel and destination system;
- age of the oldest message in the queue;
- negative ACK or timeout rate;
- number of retries;
- discrepancies found during reconciliation;
- availability of connectors and dependencies.
For security, apply encryption in transit when supported, network segmentation, strong authentication, least privilege, secret rotation, and audit trails. FHIR APIs exposed to applications must validate authorization at the required level because authenticating a user does not mean granting unrestricted access to all resources.
Retention periods, masking in nonproduction environments, and incident response must also be defined. Logs containing a patient’s name, diagnosis, or identifier are personal data and may contain sensitive personal data under the LGPD.
Checklist for Determining Whether the Integration Is Ready
Before directing production traffic, confirm:
- [ ] interface contracts and mappings are versioned;
- [ ] correction, cancellation, and duplicate scenarios have been tested;
- [ ] a persistent queue or equivalent loss-prevention mechanism exists;
- [ ] reprocessing is idempotent;
- [ ] alerts have assigned owners and escalation criteria;
- [ ] reconciliation between source and destination has been automated;
- [ ] the rollback plan has been rehearsed;
- [ ] access follows the principle of least privilege;
- [ ] logs do not expose more data than necessary;
- [ ] clinical and technical users have validated the behavior;
- [ ] the vendors involved are aware of the window and contingency plan.
How Predictor Solutions Handles This
Predictor Solutions, a software house based in Lavras, Minas Gerais, implements hospital integrations with HL7 v2 and FHIR using interface assessment, a translation layer, APIs, automated testing, observability, and gradual deployment. The company also develops Predictor Health, focused on health dashboards and wearables, and Predictor AI Hospitals, aimed at predicting sepsis, heart attack, and pneumonia in ICUs.
Its approach combines interoperability, data engineering, cloud/DevOps, and offensive security to treat integration as a continuous operation, not merely as file conversion. Across the company’s projects, the reported consolidated results include 9 medium-sized and large companies served, average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and 43% profit growth in six months; each result depends on the scope and operational context.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246