How to move from isolated hospital systems to event‑driven, FHIR‑based architectures in a context with poor connectivity and legacy vendors.

In many private clinics in Venezuela, “digital transformation” has meant installing a Hospital Information System (HIS) and maybe an Electronic Health Record (EHR). The problem is that most of these systems do not expose standard APIs, or do it in a very limited way.

As an engineer, the real challenge is not “going paperless”, but making systems talk to each other: getting lab, pharmacy, admissions, telemedicine and billing to exchange data without adding more technical debt.

In this post I’ll share a practical architectural approach, from a developer’s perspective, to move a typical clinic environment from ad‑hoc integrations to an HL7 FHIR + event‑driven architecture.

The starting point: interoperability level 1–2
In practice, most clinics I work with operate like this:

Manual CSV or PDF exports.

Occasional point‑to‑point HL7 v2 interfaces (if you’re lucky).

No formal API documentation.

Human “copy‑paste” processes between systems.

In HIMSS terms, that’s level 1–2 interoperability. A realistic technical goal is to bring critical systems up to level 3 (semantic), where data means the same thing everywhere.

Why FHIR fits this environment
FHIR brings several properties that are extremely valuable in this context:

API‑first. Everything revolves around HTTP resources.

Well‑known structures. JSON with clear fields for Patient, Observation, Encounter, Medication, etc.

Mature implementations. HAPI FHIR in Java, for example, lets you spin up a server quickly.

A minimal viable pattern looks like this:

Deploy a FHIR server (e.g., HAPI FHIR) as the central point.

Expose a small, focused subset of resources for the first use case: Patient, Encounter, Observation, Medication, DiagnosticReport.

Build one adapter per legacy system that:

Consumes events or exports from the source system.

Transforms them into the corresponding FHIR resource.

Publishes them to the FHIR server via its REST API.

Integration layer: avoiding point‑to‑point hell
Without an integration layer, every integration is a fixed pair of systems. With ten systems, you have forty‑five possible pairs.

Recommended architecture:

An event bus (Apache Kafka for high‑volume scenarios, RabbitMQ for more modest loads).

Microservices (Java + Spring Boot, for example) responsible for:

Subscribing to domain‑specific topics (lab, pharmacy, admissions, etc.).

Transforming messages to the FHIR model.

Publishing to the FHIR server.

In parallel, an integration engine like Mirth Connect can simplify HL7 v2 → FHIR handling.

This shifts the problem from “every system talks to every other system” to “every system talks to the bus”, and “the bus talks FHIR to the outside world”.

Dealing with unreliable connectivity
In Venezuela, you simply cannot assume stable connectivity, not even within the same city. From a software architecture standpoint, this means:

Implementing the Outbox Pattern in source systems.

Using local queues to buffer events when the connection is down, and flush them when it comes back.

Designing idempotent consumers on the event bus side to avoid duplicates and inconsistencies.

From this perspective, the FHIR server becomes the consolidated source of truth, but local systems must still be able to operate with a subset of data while offline.

Security by design, not as an afterthought
Two concrete recommendations:

• For client applications (web, mobile, clinical front‑end): SMART on FHIR on top of OAuth 2.0, with fine‑grained scopes per resource.
• For server‑to‑server integrations: OAuth 2.0 with trusted clients, managed certificates and TLS 1.3 everywhere.

Trying to “bolt on” security at the end is a terrible idea in a domain where data is, by definition, highly sensitive.

Conclusion and next steps
If you’re in a similar environment (private clinic in LATAM with multiple legacy systems) and want to start working with FHIR, my suggestion is:

Pick one small but critical use case (for instance, integrating lab results into the EHR).

Stand up a FHIR server with a minimal resource model.

Build a single adapter for one source system.

Add the event bus and security from day one, even if you only have a couple of systems.

From there, adding new systems becomes a repeatable pattern, not a heroic project every single time.

Call to action for dev.to
If you’re working on healthcare interoperability in LATAM and want to compare architectures or trade war stories, I’d be happy to connect. You can find more details and case studies at codebymelendez.com or reach out to me on LinkedIn.