Building a Digital Health System from Scratch in a Resource-Constrained Country

I'm a backend engineer based in Venezuela. And I've been thinking about a problem that most developers in stable countries never have to deal with: what does a digital health system look like when you can't assume electricity, connectivity, or institutional data?
This is the question behind a series I'm building — a technical cluster on what it actually takes to digitalize healthcare in a country where the public system has been in freefall for over a decade, and the private sector is the only thing holding it together.
This post is the engineering introduction. Let me set the stage.

The situation on the ground
Venezuela's health system doesn't have a data problem. It has a no data problem.
There is no national EHR. No interoperability standard between hospitals. Patients carry their medical history in their heads, or on paper, or in a WhatsApp chat with their doctor. When a patient switches facilities, the new physician starts from zero — every single time.
The government announced a national digital health record platform in late 2025. That's a step forward. But there's a gap between a platform announced and a system running at scale, and that gap is exactly where most health digitalization projects fail.
The private sector — private clinics, labs, diagnostic centers — is where the real window of opportunity exists right now. These are organizations with decision-making capacity, some budget, and a direct incentive to improve operations. And most of them are still running on spreadsheets. Or paper.

The engineering constraints that change everything
Before talking stack, you have to understand what "resource-constrained" actually means here, because it shapes every technical decision:
Connectivity is unreliable. Not slow — unreliable. A cloud-first architecture that assumes a stable internet connection will fail in the field. Any system needs to work offline or near-offline, sync when it can, and not lose data when it can't.
Power is intermittent. Load shedding is a daily reality in many parts of the country. Systems need to be resilient to abrupt shutdowns, which means database integrity and recovery matter more than they would anywhere else.
Devices are whatever exists. You can't assume modern hardware. Any interface needs to run on a basic browser, on aging machines, without requiring local installations.
No existing data to migrate. This is actually the one advantage: you're not dismantling a legacy system. You're building on a blank slate, which means you can design the architecture correctly from the start.

The stack I'm proposing
Given those constraints, here's the technical approach I've landed on:
OpenMRS for the EHR layer.
It's open source, battle-tested in resource-limited environments — running in 5,700+ health facilities across developing countries — and modular enough to adapt to a specific clinic's workflow. Critically, it can operate with local infrastructure and sync to a central server when connectivity allows.
Spring Boot for the integration API layer.
Every system in a hospital needs to talk to something else: the EHR talks to the lab, the lab talks to billing, billing talks to inventory. A clean REST API built in Spring Boot is the integration backbone. I'm using standard HL7 FHIR resources for data modeling, even if nobody else in the local ecosystem is using FHIR yet — because building to a standard now is cheaper than migrating later.
n8n for workflow automation.
This is where things get interesting. Administrative workflows in a clinic — appointment reminders, low-stock alerts, discharge summaries, insurance pre-authorizations — are a massive operational burden when done manually. n8n lets you automate these without building custom integrations from scratch every time. It's also self-hostable, which matters when you can't depend on SaaS uptime.
WhatsApp Business API — but structured.
Doctors and patients in Venezuela already use WhatsApp for clinical communication. The problem is they use it in a completely unstructured, non-compliant way that generates no usable data. The solution isn't to ban it — it's to channel it through a controlled integration that defines the flow, avoids storing sensitive data on third-party servers, and logs what matters in the actual EHR.

The hardest engineering challenge: interoperability without a standard
In countries with mature health systems, you implement HL7 FHIR and the ecosystem meets you halfway. Labs, pharmacies, insurance companies — everyone speaks a common language.
In Venezuela, there is no common language. Every private clinic runs its own silo. So interoperability has to be built from first principles.
The approach: define a local FHIR profile as an internal standard for the systems you build, implement FHIR-to-CSV and FHIR-to-flat-file adapters for the systems that won't talk FHIR, and accept that you'll be doing translation work for a while. The goal isn't perfection — it's a data layer that can grow toward a standard as the ecosystem matures.

What I've learned so far
A few things I didn't fully appreciate before starting this:
The sequence matters more than the technology. The most common mistake is trying to implement AI diagnostics before you have clean structured data. There's no shortcut: first you build the EHR, then you accumulate quality data, then the AI has something to learn from. Skipping steps doesn't accelerate the process — it just makes it fail more expensively.
Adoption is the real engineering problem. A system that clinicians don't use is worse than no system — it creates the illusion of digitalization without the substance. The UX of clinical tools isn't a nice-to-have. It's the difference between a project that succeeds and one that gets abandoned after six months.
Offline-first architecture is underrated in the global tech conversation. Most of what's written about health tech assumes infrastructure that doesn't exist in large parts of the world. Building for intermittent connectivity from day one changes your data sync strategy, your conflict resolution logic, and your error handling in ways that make the system genuinely more robust — even for environments where connectivity is fine.
If you want the full strategic context — the epidemiological data, the phased roadmap, the business case for private clinics — I wrote a longer piece on my site:
👉 Digitalización del sistema de salud en Venezuela: estrategia real 2026 (Spanish)

I'm building this series because I think there's a gap in the technical literature around health systems in genuinely constrained environments. Most of what's written assumes rich infrastructure. I want to document what engineering looks like when you don't have that luxury.
If you're working on something similar — health tech in a developing economy, offline-first clinical systems, FHIR implementation from scratch — I'd genuinely like to hear from you.