Johnattan's Laboratory
← All experiments

A phone-⁠first surgery registry for an orthopaedic team

An orthopaedic surgery team needed one place to plan, record and follow up its operations from a phone. I built a registry where each doctor's records stay private to them, and grew it from knee surgery to seven body areas.

  • Tools
  • Health
  • Data

Project page

Updated6 Oct 2026

The problem

An orthopaedic surgery team needed one place to keep each operation, from the plan to the last follow-up visit. It had to work on a phone, with as little typing as possible, and each doctor's patients had to stay visible only to that doctor.

What was out there

The app's own pitch sits between two options: a notebook or loose files, which leave gaps, and hospital record systems, which are far more complex than a surgical log needs. When I researched registry apps, a published usability study of REDCap's offline mobile app found that the step syncing offline data back to the server was the main usability failure.

What I built

A Spanish, mobile-first web app that installs on the phone's home screen. A doctor creates a patient, plans the surgery (team, date, procedure from a hierarchical taxonomy, materials), records what was done after the operation (implants, details, photos and radiographs) and adds follow-ups (pain, range of motion, wound, walking, photos) until closing them. It covers seven areas: knee, hip, foot and ankle, hand and wrist, shoulder and elbow, spine, and skull.

Row-level security in the database keeps each doctor's records to that doctor. Photos sit in a private storage bucket and are served through links that expire after four hours. Doctors join by invitation, statistics and Excel backups cover patients, surgeries and follow-ups, and a public demo account holds only fictional patients.

Two phone screens of the registry: a knee patient list with three example patients and their diagnoses, and a dark surgery planning screen with the patient card and chips for the seven body areas.
Each body area has its own patient list, and planning a surgery starts by choosing the area.
Two phone screens: the hip plan form with range-of-motion fields and a computed Harris Hip Score of 51.5 out of 100, and a light surgery detail screen for an example skull case with its original plan.
Functional scores are computed as the doctor fills the form, and each surgery keeps its original plan next to what was done.

Equipment

How I built it

  1. Built a working prototype in one day, then shaped the knee taxonomy and forms around the surgeon's feedback.
  2. Hardened privacy: row-level security on every table, a private photo bucket, and access requests that go through a server route instead of direct database inserts.
  3. Ran audit and design work as long unattended tasks, with Codex reviewing each batch and every visible change shown as before-and-after screenshots for approval.
  4. Built separate fictional demo and test accounts, so every live check runs on synthetic data.
  5. Added the other body areas and functional scores, then a release gate: unit tests, lint and build, followed by browser suites in WebKit and Chromium against a local copy that holds only fictional data.

Results

  • Version 1.15.0 has been live since 2026-10-06, with seven body areas.
  • 117 of 126 text fields now offer chips or predictive lists. A tap-only browser test records a full case in all seven areas without typing.
  • 927 orthopaedic diagnoses from ICD-10 (CIE-10 in Spanish), searchable by code or description.
  • Ten functional score instruments, entered item by item. Their labels are working summaries, not validated Spanish questionnaires.
  • The release gate runs 510 tests plus lint and build, then the browser suites, which add about 3 to 4 minutes.
  • Recompressing 185 stored photos cut them from 250 MB to 103 MB, and new uploads are encoded in the browser so iPhone photos land near 600 kB.
  • The last release went through four Codex (GPT-6 Astra, high) review passes.

What I learned

Test the rare paths for real. An acceptance test of account deletion showed it had failed for every doctor since an earlier migration, because one step deleted rows by a column that did not exist. A forward migration fixed it.

Make "tap-first" a rule with a test behind it. Typing is what doctors notice, so new fields now arrive with chips, lists or sliders, and the tap-only browser test has to keep passing.

Rollback only works for a while. Once real data depends on a migration, my rollback scripts refuse to run, so any fix after that point is a forward migration.

Lab notes

  1. I added a skull fracture workflow with optional cervical spine scoring, then hip and foot and ankle, ten functional scores and tap-first entry in every area, and released version 1.15.0.

  2. I recompressed 185 stored photos from 250 MB to 103 MB, ran a design loop where every visible change needed before-and-after screenshots, and gave the demo account its own fictional patients that reset at every demo sign-in, so checks never touch a real doctor's records.

  3. I started compressing photos in the browser before upload to keep storage under the free-tier cap, and later made the clinical photo storage private, with images served through links that expire after four hours.

  4. I added a public landing page and a way for new doctors to request access.

  5. I built the first version in a day: sign-in, patient records, the surgery workflow, several doctors and invitation codes.

© 2026 Johnattan García-Ruiz Last updated