Project Buendia Legacy Software Recovery & Technical Stewardship

Executive Summary

When Médecins Sans Frontières (MSF) needed Project Buendia – an offline Electronic Patient Record (EPR) system for outbreak treatment centres – the software had been dormant for six years and could no longer be built. Through a rapid system takeover and technical stewardship, SolDevelo audited the stack, resolved EOL dependencies and Android crashes without rewriting core code, and packaged the system for field deployment.

Six Years Dormant, Back at the Bedside

In an outbreak treatment centre, infection control dictates a strict boundary: anything that enters the high-risk zone cannot easily leave, especially paper records. In 2014, Project Buendia was created to solve this problem. An open-source Electronic Patient Record (EPR) system engineered specifically for outbreak environments. Rugged tablets operated by clinicians in full personal protective equipment communicate over a local Wi-Fi network to a server stationed inside the facility, working entirely without an internet connection.

Then development stopped. The last commit from the original authors was logged on December 12, 2019. For six years, the repository sat untouched. When Médecins Sans Frontières (MSF) needed the system again for a treatment site in the Democratic Republic of the Congo (DRC), Project Buendia was a technical black box. The documentation described hardware that was no longer manufactured, and the build steps failed at the first hurdle.

The choice seemed stark: undertake a costly, multi-month rebuild, or find a way to navigate the vendor gap and bring the existing Global Good software back to life.

The Audit: The Code Was Fine, the World Had Moved

Instead of assuming a full rewrite was required, our team initiated a rapid system takeover. We stood up the entire stack end-to-end in two days to drive a real clinical workflow through it. The audit yielded 12 distinct findings, but zero high-severity defects in the core code.

The challenges were purely mechanical and localized:

• Discontinued Hardware: The original server appliance ran on an Intel Edison – a matchbox-sized single-board computer acting as server, Wi-Fi access point, and update source in one. Intel discontinued the chip in 2017, and the original target tablets were similarly obsolete.
• Decommissioned Infrastructure: Remote hosting infrastructure and build dependencies used in 2015 had been turned off.
• End-of-Life Stack: Nearly every layer beneath the application had passed its end-of-life, including the operating system, database, web server, and underlying runtime dependencies.
• OS-Level Crashes: The native Android app would not install on modern hardware. When forced onto a current device, it crashed instantly on launch.

System Recovery: Three Surgical Fixes

Restoring the system required targeted software maintenance rather than broad overhauls: 

• Ten lines between dead and working: On startup, the tablet app requested the device’s hardware phone identifiers. Permitted in 2014, this access has been strictly prohibited since Android 10, causing modern devices to terminate the app immediately. Adding ten lines of defensive code resolved the crash.
• Six megabytes of dead weight: The app bundle still carried 32-bit legacy encryption libraries it no longer used. Modern 64-bit Android operating systems rejected the installation package until those redundant binaries were removed.
• The bug that wasn’t a bug: During initial testing, saved clinical observations appeared on the chart for a fraction of a second and then vanished, even though the data remained intact in the database. Layer-by-layer tracing revealed a timezone mismatch between the application server and the database: the sync query was comparing timestamps two hours apart and quietly excluding every new record. It was not a code defect, but an environment configuration issue fixed with one startup flag and a single line in the operational runbook.

Such issues, although they might seem small once resolved, can deem the system unusable. And while fixing them is easy enough, identifying where the problem lies is a whole different story. With the original development team long gone, and no one who knows the system around to ask, it takes a lot of experience to quickly find and resolve the issue.

From Working Code to Field-Ready Package

Getting the code to run in a lab is only half the battle. The governing constraint of this pilot is that no software engineer will travel to the site in DRC. The system had to be packaged so that non-technical field staff could deploy and maintain it independently.

We modernized the architecture around practical field realities:

• Standard Laptop as Appliance: The discontinued single-board computer was replaced with containerized services running on a standard x86-64 laptop powered by Ubuntu and Docker. A laptop provides an intentional operational advantage: its internal battery serves as a built-in Uninterruptible Power Supply (UPS), ensuring power drops in the field do not corrupt patient records. Its screen also displays the QR codes used to provision tablets. 
• Two Commands, One Machine: System setup is reduced to two automated scripts: one run online to fetch dependencies, and one run offline on-site to configure the network, launch services, and perform system verification. 
• Zero-Config First Boot: The server container boots with its login configuration, ward structures, and bilingual English/French clinical forms pre-loaded. 
• Tablet Provisioning via QR Code: Tablets connect to the local Wi-Fi and install the app over the local network by scanning a QR code off the laptop screen – requiring no internet, no app store, and no cabling. 
• Decontamination-Safe Workflow: For high-risk areas, we designed a laminated card carrying two QR codes: one to join the local Wi-Fi network (eliminating the need to type passwords while wearing heavy protective gloves), and one to pull down the app installer. A replacement tablet can be brought into service inside the high-risk zone without anyone crossing a contamination boundary. 
• Single-Command Health Check: A verification utility executes ~17 automated checks to answer a crucial operational question: is the system usable by a nurse, not merely powered on. 
• Deliberate Platform Strategy: Project Buendia runs on OpenMRS Platform 1.10.6 (alongside Buendia Module 1.0 and Android App 1.0). Preserving this stable platform version for the initial pilot minimized risk, while establishing a documented upgrade path to modern standards like OpenMRS 3 and FHIR for future phases. 

Validated and Preparing for the Field

In July 2026, the complete kit was built from scratch and validated end-to-end on target hardware. A bare laptop was provisioned via USB stick, a tablet was joined to the network via QR code, and synthetic patient workflows were executed – admitting 2 synthetic patients, recording 8 encounters, logging 62 clinical observations, and issuing 1 treatment order – all verified directly in the database.

The software is fully built and validated on our staging hardware. MSF medical teams are currently authoring custom clinical forms and conducting acceptance testing at MSF Switzerland. A field deployment to one site in the Democratic Republic of the Congo is planned to follow.

Facing a vendor gap or an unbuildable legacy system?

Learn how our technical stewardship team stabilizes critical public health software and global goods.