This piece has an evidence version. The same subject was made again, with running code and screens that were actually rendered — The Tool That Refuses to Read — Keeping Judgment Outside a Clinic Flow. This one is left as it was written.
The exam room of family-medicine clinic director Han Do-gyeong (47) was narrow. A blood-pressure cuff on one side of the desk, a single monitor on the other. In the brief gap between patients, he turned the monitor around to show me. On the left of the screen, today's appointment list; in the center, one person's past flow, stacked in time order. "HbA1c 7.2 three months ago, meds adjusted," "Reported foot numbness six weeks ago — referred for nerve testing," "BP 145/92 two weeks ago." He skimmed those lines top to bottom once and said, "I should hear about this person's feet first today."
Sixty patients a day. Half of them follow-ups for chronic diseases like diabetes, hypertension, hyperlipidemia. He sees the same people once every few months, for years. The problem is the flow in between. Why the meds were changed last time, what he said to check next time, which symptom the patient mentioned in passing — if that's scattered across paper charts and memory, he has to grope from the start every time. "I'd find myself asking a follow-up like it was a first visit. The patient knows, too — that the doctor forgot their flow." So he built a screen. He said he'd never learned development.

Sixty a day, half of them follow-ups. How did you track that flow before?
Memory. And paper charts. With chronic-disease patients, you see one person for years. A diabetes patient comes every three months. What happened in between — why I raised the dose by 0.5 milligram last time, whether the foot numbness got better, when I said to recheck the kidney values — I have to pull all of that out of my head within the five minutes they walk into the exam room.
For one patient, that's fine. With sixty, the flows blur together. I'd start telling Mr. Park something meant for Mr. Lawson, then go "oh, that wasn't this person," and dig through the chart. Those few seconds may seem like nothing, but the patient feels it. The sense that my doctor is treating me like he's seeing me for the first time. Chronic disease is managed through trust, and that's exactly where the trust leaks out.
Once I told a patient whose BP meds I'd changed to come back in two weeks for a recheck, and I missed it. The patient forgot and didn't come either. When they came three months later, the BP had gone up further. It wasn't a major incident, but — if I'd been holding the flow, I could have prevented it. That's when I thought: my memory can't carry sixty people.
So you built your own tool. Did you learn to develop?
No. That's the heart of this story. I can't write code. All I did was decide what was needed. What should appear on the screen, in what order it should be shown, what's dangerous to miss — I know that because I've practiced for twenty years. Translating it into something a computer understands was always the wall, and makemind took over that part.
I didn't draw the screen — I spoke it. When I open a patient, show the past flow in time order, top to bottom. The points where meds were changed in a different color. The items to check next time on their own separate line. When you write down what to show and where like this, that becomes the screen. I didn't design anything — I just said what I needed.
"I didn't draw the screen, I spoke it. Because I know best how a visit should flow. I may not be able to draw, but I can speak."
Can you show me what actually happens behind that screen?
Of course. The screen comes last. There are stages before it. When a visit ends, the day's events stack up per patient; the next time that patient comes, the past flow is distilled onto one screen; the easy-to-miss items rise to the top — I didn't wire that flow, I only decided what goes in and what comes out of each stage.
The first stage — how does the visit record stack up?
When a visit ends, I write a line. "Dose up 0.5," "Foot numbness — referred for nerve testing," "Recheck BP in two weeks." I don't write long. I used to jot this in a corner of the paper chart, but here, the next time I open that patient, it's stacked up line by line in time order. The most recent on top.
What matters is that when, and why it happened gets attached too. When I wonder "why did I change this med again?", I can trace back to the note from that point. In medicine, the basis is everything. Later, when a patient asks "why did you do that back then?", I can answer with the line I wrote that day, not with my memory.
Next — where does each patient's flow stack up?
For each patient there's a place where facts stack up in time order. Things like "HbA1c 8.1 last autumn," "meds adjusted in winter," "down to 7.2 in spring," "foot numbness reported." And each line has the basis from that day attached (what value, what symptom).
This is the decisive difference from a paper chart. Paper shows only the current state, but this holds the change. Flows like "this patient's HbA1c has been coming down for half a year — they're keeping up well," or "BP has crept up three times in a row — I should look at the meds," become visible at a glance without my having to open up old records and compare them one by one. The comparison I used to do in my head, the data does in the same shape.
So how does today's patient's screen come up?
In the morning, it skims through today's appointment patients for me. When I open one person, the past flow comes up distilled. The most recent event on top, time order below. And in a separate box, "the things said to check next time" are gathered. Recheck BP in two weeks, kidney values in three months, check the foot's condition next time — so these don't get dropped.
This is the biggest change. Before, I relied on memory for "what did I say to check this time"; now it's right there on the screen. Because what I might drop is in front of my eyes, I don't have to worry about dropping it. I can spend that worry on looking at the patient's face.
This is the screen I see when I open one patient. Past flow at top, the "things to check next" box beside it. See that gray line down there? "BP trend over last 3 readings ↑" — I didn't draw that by opening old numbers one by one either; it pulled just the trend out of the stacked records and showed it. It shows the trend, but it doesn't diagnose. That much is the tool's job, and "so should I change the meds" is mine.
You just said "it doesn't diagnose." Is that intentional?
That's the most important design choice in this tool. This screen doesn't diagnose. It doesn't say "this symptom means this disease." It doesn't recommend meds, it doesn't interpret test results in my place, it doesn't score risk. It shows trends — BP is rising, a value is coming down. But what that means, what to do, I decide.
This isn't something I couldn't build because I overlooked it. It's something I deliberately didn't build. I decided it when I first designed it. Features like "diagnosis," "prescription recommendation," "risk rating" — I do not put on this screen. No matter how smart a screen looks, you can't call a feature that isn't there. If I don't build it, I can't cross that line even by mistake.
"Before deciding what to put on the screen, I first decided what to keep off it. The moment diagnosis goes into the tool, I'll lean on it. So I just didn't build it."
Why draw that line so firmly?
Medicine is work where the responsibility for judgment must be tied to a human. By law, by ethics, and above all for patient safety. If the screen puts up "this patient's diabetes-complication risk: 78%," then on a busy day I'd lean on it without realizing. Then my judgment gets dragged along by the screen. That's dangerous for the patient.
So that capability — I don't build it as a tool. Not building it is the first responsibility of the person building a tool in this domain. The flow is held by the tool, the judgment by me — and I draw that boundary. Where you draw that boundary is, in fact, something only someone who knows the practice can do. When an outside developer builds a "clinic app," they want to put more features in. "Shall I help with diagnosis too?" they'd say. I put fewer in. That's the difference.
To sum up, what did you, the director, do, and what did makemind do?
What I did was judge. In what order to show the flow, what's dangerous to miss, and what should not be built as a tool. Only someone who's practiced for twenty years knows that. What makemind did was carry that flow.
| Stage | What I decided (twenty years of judgment) | What the tool did |
|---|---|---|
| Record input | What to leave as a single line | Kept the notes I wrote, per patient |
| Flow accumulation | What to leave as fact | Stacked it with time order and basis |
| Next visit | What to check next | Distilled past flow and "things to check" onto one screen |
| Trend | Which trend to show | From stacked values, showed only the direction |
| Diagnosis & prescription | Decided not to build as a tool | (none — deliberately not built) |
| Screen | What to show and where | Rendered to screen as spoken |
The most important box I filled is the fifth row. The box there is empty, isn't it? The emptiness is the design. For the other boxes I decided what to put in; for that one row alone I decided what not to put in. Work that would have taken months if I'd learned to code, or tens of millions of won if I'd outsourced it — I did just by putting my judgment into words.
What changed the most?
The time I spend looking at the patient. The mind I used to spend groping for the flow, worrying about dropping something, comes loose — and that goes to the patient. It's the same five-minute visit, but the quality of those five minutes is different. When a follow-up patient comes in, because I'm already holding their flow, I don't ask from the start. When I begin with "how's that foot numbness from last time?", the patient's face changes. My doctor remembers me.
And to be honest, this tool doesn't change every visit. It shines in visits where the flow is clear — chronic-disease management, regular checkups, standard intake. Complex cases that are different and unpredictable every time can't be captured by a flow, and shouldn't be. So I left a skip and a free note at every stage. The flow mustn't trap me. The tool only suggests the flow. The signals outside the screen — the patient's expression, the symptom left unsaid — those, in the end, I have to see.
"The flow is held by the screen, the judgment by me. It shows the trend but doesn't diagnose. And drawing that boundary, too, turns out to be the part that belongs to the person who knows this work."
What would you say to other doctors?
Don't start grand. I didn't build all of this from the start either. I started with one line: "when I open a patient, past notes appear in time order." Once that worked, I added "things to check next time," added the trend display — I grew it one box at a time. And as I grew it, I asked every time: Is this flow, or is this judgment? If it was judgment, I didn't add it.
The key is this. What you know best is your work, not coding. You only have to speak that thing you know well. You may not be able to draw, but you can speak. And one more thing — as much as deciding what to build, deciding what not to build is your job too. For the judgment only a human should make, not building it as a tool is part of the design. A screen built by someone like me, who can't write a single line of code, is holding up my practice right now. The diagnosis — that, I still do.
makemind.dev "Field" — the person who knows the domain best, building their own tool with their own hands. Han Do-gyeong's clinic screen carries the flow but deliberately doesn't carry the diagnosis. Deciding what not to build is part of the design too.