Journal
Field DeploymentLessons

On-Mission Reset: Rebuild Beats Patch

When the patient-creation flow broke live in the field, the call was to reset OpenEMR in place rather than run an insecure fallback. What that decision looked like under pressure.

In discussion with MMDM president Roberto Orlandi on solutions to the initial patient bug.

The Break

Midway through the Costa Rica field trial, the patient-creation button stopped responding entirely. No network request. No console error. No validation feedback. Patients were waiting; the morning's paper shadow had ended; the team was ready to enter data.

Diagnosis pointed to a backend configuration error: the patient-creation endpoint was returning a plain-text error string instead of the JSON the frontend expected. The running version was corrupted.

A fallback to a previous build restored the patient-creation flow — but that build was missing required server updates. Running it would mean holding patient data on a system that could not be hardened. That was not an acceptable trade.

The Call

The decision, made during the mission: reset OpenEMR entirely and rebuild in place, rather than accept either a broken system or an insecure one.

This was not a comfortable call. It meant downtime during a live clinic. It meant re-entering configuration that had taken weeks to build. But the constraint was clear: you cannot compromise the security of a clinical system to avoid inconvenience.

The reset ran without error. Patient creation was confirmed working within the hour. No patient data was lost — the trial was still paper-primary, so paper records held the day's intake. The evening EMR-entry session proceeded on schedule.

The Lesson

The patch-versus-rebuild question comes up in every system. The instinct is to patch — it is faster, it preserves state, it avoids the appearance of going backward. But a corrupted state is not a stable baseline. Patching on top of a corrupted foundation does not eliminate the corruption; it hides it.

The rebuild revealed something else: the configuration process, while tedious the first time, was well-documented enough to execute under pressure. That documentation turned out to be load-bearing infrastructure.

Future deployments will carry a verified, snapshot-backed baseline that can be restored without a full reconfiguration. The lesson is not just "rebuild beats patch" — it is "make rebuilds cheap enough that the call is never difficult."