01 Overview

Writing a clinical note is not a thinking problem — the clinician already knows what happened. It is a typing problem: the same eight paragraphs again, with today's tooth number, today's shade, and today's carpule count dropped into the right places, worded consistently enough that the note still reads clearly when someone pulls the chart two years later. Smart Note asks for the parts that change and writes the parts that do not, then hands over a finished note to paste into the practice management software.

02 Why I built it

Snippet expanders and canned templates get most of the way there and then leave the fiddly part behind: the note still has to agree with itself. One tooth or three changes "presents" to "present" and "crown" to "crowns" in four places. A lower molar makes half the injection-site list wrong. A blank field leaves a dangling colon that someone has to notice and delete. Those are small things individually, and collectively they are why templated notes end up hand-edited every time — which is most of the work the template was supposed to remove.

So the interesting part of this project is not the form. It is that the note is composed rather than filled in: the template describes how to say things, and the app assembles a sentence that agrees with the answers it was given.

03 What I built & how it works

One file, split in half. Above the line, procedures as data. Below it, a small engine that knows nothing about dentistry.

Fig. 1 — the preview and the finished note come from the same builder, so they cannot disagree about what the note will say.

One builder, two modes

A template returns its note from a single build(answers, h). The helper h.slot('shade') returns the answer wrapped in sentinel characters in preview mode and the bare answer in final mode — so the live preview is not a mock-up of the note, it is the note, drawn with markers. Two separate rendering paths would eventually drift, and the preview would start promising a sentence the finished note did not produce. Sharing one builder makes that impossible rather than unlikely.

The sentinels are private-use codepoints, so they cannot collide with clinical text, and the note is HTML-escaped before they are converted to highlight spans — the note is treated as untrusted text the whole way through.

Composition, not substitution

Counts drive wording. One tooth gives "Tooth #3 presents with recurrent decay and a crack. Crown indicated to restore form and function"; three teeth gives "Teeth #3, #4, #5 present with…" and "Crowns indicated…", and the temporary becomes plural to match. Reasons picked from a list are joined into one grammatical sentence rather than pasted as fragments. Selecting a lower tooth filters the injection sites to the mandibular ones, so the anesthesia section cannot offer a nerve block that belongs to the other arch.

Write-ins everywhere

Every chip list, the yes/no toggles, the tooth chart, and both halves of the anesthesia row carry a free-text Write in option. Typed text is merged over the chosen option before the template ever sees it, so a write-in behaves exactly like a built-in choice downstream. The fixed list covers the common case; the write-in covers the case the template author did not think of, which in clinical work is not a rare event.

04 🛠 Skills & tech used

05 Notable challenges & decisions

Most of the decisions here are subtractions — the interesting ones are what the app deliberately will not do.

A composition aid, not a record system. The chart still lives in the practice management software. This writes text and hands it over; it keeps no copy, has no accounts, and has no audit trail — because it holds nothing worth auditing.

06 Results

Counted from the source. The engine is ~610 lines; the rest is the three templates and their shared option lists. The second procedure needed no engine change at all and the third added one question type, while the crown-prep note stayed byte-identical across every change.

07 Screenshots

Captured from the public build. Every clinical value shown is invented — there is no patient here.

08 Honest status

This is a small, focused practice utility, and the scope is genuinely narrow: three procedures are implemented — crown prep, composite restoration and adult prophy — with perio maintenance and pediatric prophy planned next. The two newest were transcribed from photographs of the office's Notepad skeletons and have not yet been checked against the files themselves. It is Universal tooth numbering only, with no primary-tooth lettering, and there is no print styling because the workflow ends at the clipboard. An unanswered slot in the middle of a sentence leaves a doubled space; the obvious repair would break the note's deliberate column alignment, so it is documented rather than papered over. There is no test suite — the app is a pure function from answers to text, and the honest check is walking a procedure and reading the note, which is what the build notes ask you to do.

It is not a clinical record system and does not try to be: no accounts, no audit trail, no retention, no PHI handling to speak of, because it deliberately holds nothing. The demo linked above is the same code as the working copy with a demo banner added — not a reduced or defanged version.