Form Design as Clinical Workflow: Building Station-Specific LBFs
Paper forms are the canonical spec. Every deviation from them requires a station lead to justify it. Here is how that discipline shaped six custom forms across five clinical stations.


The Rule
Before any form went into development, one constraint was established: the paper form is the spec. Digital equivalents must match paper field-for-field unless a station lead explicitly approves a change and can state why the digital version is better.
This sounds conservative. It is conservative. It is also correct. The station leads have conducted 26 and 32 missions respectively on paper. They know which fields get filled, which get skipped, and which the paper version gets wrong. Deferring to them saved weeks of rework.
What Was Built
Six station forms were built, each derived from its paper original. This was the first real attempt at digitizing MMDM's clinical workflow inside OpenEMR — and, as the Vision form below shows, the one that eventually surfaced why OpenEMR itself was the wrong foundation to build on:
Registration is the patient's first contact and the source of truth for the visit. The digital version adds two surname fields (paternal and maternal) where the paper had one — a deliberate deviation to capture the Costa Rican naming convention properly. It also adds three vitals fields the paper omitted: pulse oximetry, respiratory rate, and last menstrual period. The station lead reviewed and approved both changes.
Triage is where vitals are entered once and propagated to all downstream forms. Allergies captured here appear highlighted across every other station's view. The chief complaint is a direct patient quote, entered at triage, read-only everywhere downstream. The vision lead changed the age cutoff for routing patients to the eye doctor midway through the Costa Rica deployment — which drove a hard requirement: routing thresholds must be editable by the clinic lead without touching code.
Vision is a full custom form, replacing the built-in eye exam module that the vision lead found too complex. It captures the autorefractor output (currently as a photo attachment with optional structured fields), visual acuity with and without correction, glasses dispensed, and diagnosis checkboxes. The autorefractor device prints thermal tape that fades within months — the photo capture is a preservation mechanism, not a convenience.

This paper form is the one referenced above — the long-standing source of truth that the OpenEMR build, and later the custom system, both had to reproduce field for field.

This is the eform inside OpenEMR, not the system that eventually replaced it. The PHP warning visible at the top of the screenshot is authentic output, not a staged example — and it is part of why this architecture did not last. The patient shown is test data.
Dental mirrors the paper form with one significant omission: the pre-medication and medication history sections were intentionally made optional. In practice, those sections are never filled at field missions. Making them optional prevents them from blocking form completion without sacrificing the data model.
Medical is built on OpenEMR's SOAP note with additions: a structured six-field prescription block (name, dose, route, frequency, duration, instructions), a dedicated diagnosis prompt (the medical lead missed the diagnosis field approximately half the time on paper without an explicit prompt), and a non-sequential entry model — the provider fills the history section before the exam and the assessment after.
Pediatrics adds a parent/guardian relationship field, weight prominently displayed for weight-based dosing, a top-16 recurring-diagnosis checklist, and a sample-dispensing tracker. A separate interpreter flag distinguishes the indigenous Cabecar language from Spanish — these are different interpreter needs and were previously undifferentiated.
What Was Not Built
The dental tooth chart is a known gap. The paper form uses a full Universal Notation diagram with hand-drawn circles and X marks. A visual tooth chart in the digital form requires a canvas-based or SVG UI that was scoped but deferred. The current dental form captures the structured data (tooth number, procedure) without the diagram. It is sufficient for the first deployment; the diagram is planned for a dedicated session before Laredo.
The Takeaway
Clinical forms designed without clinical input are clinical forms that do not get used. The investment in pre-build station-lead interviews — and the discipline of treating paper as the spec — produced forms that the station leads recognized as theirs, not as something imposed on them. That discipline carried forward.
What did not carry forward was OpenEMR itself. Building six forms this way, field by field through a web UI built for a different kind of clinic, surfaced a deeper problem than any single form could fix. The architectural reset that followed covers what that problem was and what replaced it.