Building Remote: Sandbox Online, Forms Hardened

Working Out-of-State

The June 30 board demo collected a large backlog of decisions from Dr. Byrd, Janice, Linda, Catherine, and Roberto. Work resumed July 3, out-of-state — engineering and planning on a Windows laptop, build and verification on a Linux laptop, each piece committed after a manual read-back against SQLite. The database held at 20 tables through every change; all additions this week were columns, never new tables.

The Sandbox

Before anything else, the distance problem needed solving. Leads and volunteers had no way to see the app once the live demo ended, and development was continuing out-of-state. A second cloud-hosted copy of the codebase — pointing at a seeded test database — went up on Render's free tier and came live at mmdm-clinic.onrender.com on July 4.

Getting clinic.mmdm.org onto it required one additional step. mmdm.org is administered by eCatholic, the platform MMDM uses for its main website. Adding the subdomain meant reaching out directly, providing my technical role, and specifying exactly what DNS record I needed — a CNAME pointing the subdomain to the Render service. They handled it, and the domain resolved on July 7.

Key properties of the sandbox:

• Auto-deploys. Render watches the main branch and redeploys on every push. When the code updates, the sandbox updates.
• Code flows one way. Production to sandbox only. Volunteer feedback comes back as words, not commits.
• Hard safety interlock. The container refuses to start unless the environment explicitly flags it as a sandbox. Real patient data cannot land there by accident.
• Visible test-data banner. The UI carries a persistent "TEST DATA" notice. A few production-safety differences — secure cookies, a login rate-limit — are environment-driven, so there is zero code divergence from production.

This closes the gap the skeleton demo couldn't: leads can now look at and react to the actual forms while the build continues remotely.

Resilience and Session Handling

The first build addressed a silent-failure bug: after the server sat idle overnight, adding a drug in the Medical form did nothing with no error message. The root cause was a hardcoded 24-hour login cookie with no global handling for expired sessions. Fixed across five points: a global "session expired → back to login" path with a visible message, a top-level error boundary, a configurable session lifetime now set to 30 days and admin-adjustable, a guard against duplicate open visits inflating patient counts, and automatic cleanup of stale sessions on boot.

Clinical Corrections — Vision

Vision value-sets were trimmed to actual stocked inventory: removed drops and items not carried on the trip, extended the reader-strength range, and split sunglasses into their real SKU categories. Chief complaint was also moved to the top of the shared patient panel at the same visual weight as vitals — a usability flag from Janice at the demo.

Dental Odontogram

The dental tooth grid was rebuilt as a proper surface-level odontogram — a 1:1 reproduction of the paper dental chart with clickable tooth surfaces and per-day color coding, so cross-day work is visible at a glance. Data layers are built and verified; the odontogram is sized full-width for tablets with no horizontal scroll.

The visual and convention side — chart fidelity, surface orientation, whether caries can be charted without a procedure code, day color assignments, the returning-patient extraction flow — is deliberately held for a tablet session with Linda and Catherine before anything locks in. This is the one workstream paused by design.

Data Safety, Layout, and Registration

Data safety: Both export paths now redact sensitive fields — login tokens and PIN hashes never leave the machine — and declare what was redacted. Backup status and free-disk readout were added to the Diagnostics screen.

Layout: A responsive pass makes the app use the full screen width on desktop and large tablets, pins the patient side-rail so it doesn't scroll away, and stacks cleanly on portrait tablets. CSS only — no logic changes.

Registration: "Cedula" was relabeled to "National ID (e.g. Cedula, DL, Passport)" so one form covers any country without modification. An "additional names" overflow field handles full legal names. A guard now shows a read-only view when a patient already registered that day is selected again, closing the re-registration issue seen in Costa Rica.

Formulary Management

The Formulary Management screen gives admins the ability to add, edit, deactivate, and reactivate drugs as data — no code or database changes required. This was Phase 4.5, always gated on getting Dr. Byrd in the room.

Every drug's instructions now carry a review state: Draft until a clinician approves it, then Approved with a timestamp and name. The rule is enforced at the data layer: editing any sig automatically resets it to Draft. A changed instruction can never silently carry approval from its previous version. Prescribers see a non-blocking "sig unreviewed" flag when a Draft sig is selected. All 96 existing drugs start as Draft.

The Sig Worksheet

Ahead of Dr. Byrd's clinical review, a 96-drug sig worksheet was prepared — every formulary drug with a proposed instruction, dose, route, frequency, and single-visit dispense quantity, each cited to an authoritative reference (FDA/DailyMed, WHO, BNF). The worksheet deliberately surfaces problems: 84 drugs are consistent, 3 have source conflicts requiring his call, 3 have documentation gaps, and 6 are flagged as judgment calls specific to a single-visit mission context — for example, theophylline requiring lab monitoring, a 20-day leishmaniasis course, or antidepressant initiation with no follow-up capability. It also surfaces 7 drug-drug interactions between drugs already on the formulary.

The mechanism: proposed sig in the tool, doctor reviews and approves before the mission. The tool is done. The content review is the remaining clinical step.

Open Items

• Dental odontogram review with Linda and Catherine — the one build deliberately held, pending a tablet session.
• Dr. Byrd's sig-content review — clinical, not a build task; his approvals drive the medication-slip printout later.
• Printer and transport decision — still open; gates the medication-slip and triage-slip printout flows.
• Emergency services MOU — non-software, but flagged as the single highest planning priority for the mission, driven by the Costa Rica 2026 ambulance incident.
• Mission runway: Costa Rica, April 2027.