The Load-Bearing Wall
PDI Med — Post 1 of an ongoing series
I had two grandfathers.
One was an architect and a college professor.
He was someone who understood, at a level I didn’t have language for as a child, that the visible and the structural are not the same problem. That a window is only possible because of what’s holding up the wall around it. That a building which looks simple from the outside is usually a triumph of constraint hidden from view. I watched him work with a kind of reverence I couldn’t explain. He would spend more time on what you couldn’t see than on what you could. When I asked why, he said something I’ve turned over in my mind for thirty years: the structure is the design. Everything else is just finish.
The other grandfather was a physician.
I didn’t fully understand until I was deep in my own training how much of what he was had quietly become part of how I thought — the obligation to the person in front of you, the tolerance for uncertainty, the discipline of working a problem completely rather than stopping when you’ve found something plausible. He practiced in an era before the tools existed that now surround his profession. He practiced anyway, carefully, for decades.
I am both of them. I didn’t choose it. It’s just what happened.
I am an OB/GYN attending in my board certification collection year.
This means I’m in the phase of training where I document every significant case I manage — a log that will eventually be reviewed by a board of examiners who will decide whether I’ve practiced with sufficient breadth and depth to be certified in my specialty.
I have four children. The youngest is thirteen weeks in utero as I write this. My oldest is five. There is always noise in my house. There is always something that needs attention. I have learned to think in the margins.
My wife Jantsen has been beside me through all of it. Not just the last eight years of marriage — through most of college, medical school, residency, and now this. She has watched me build something in the hours that aren’t claimed by clinical practice or family, and she has never once asked me to stop. That is a specific kind of grace that I don’t take lightly.
Six generations of physicians came before me in my family. My father broke the chain — deliberately, I think, because he wanted to give us something the family had been missing: a foundation in faith, in hard work, and in keeping your priorities straight before keeping your career straight. He succeeded. And partly because of what he gave me, I found my way back to medicine — not just as a profession but as a vocation.
I tell you all of this not because it’s relevant to the architecture of a clinical software platform. I tell you because what I’m building came out of a specific life, and you can’t understand why I built it the way I did if you don’t understand the person who built it.
About eighteen months ago, I started going on walks at night with my dog.
Not for the walks. For the thinking.
I had a problem I couldn’t let go of, and the way I’ve always worked is to keep a problem ever-present in my mind — turning it over, inverting it, applying a different frame, coming back to it from a different angle each night — until something gives. The walks were just the container. The problem was the thing I was actually doing.
Here is the problem, stated plainly:
Medicine has accumulated an enormous amount of data and almost no usable intelligence from it.
The electronic health record — the system physicians spend more time with than almost any other tool in their professional lives — was not designed to preserve clinical reasoning. It was designed to document billable events. The diagnosis codes that structure most clinical data aren’t clinical assertions; they’re billing artifacts applied after the encounter to capture reimbursement. The physician’s note — the richest artifact of clinical thinking that exists in medicine — was turned into a template, and the template was optimized for auditors, not for the physicians who would need to read it next week, next year, or a decade later.
The result is a system that is information-rich and continuity-poor. A physician sees a patient, thinks carefully, makes decisions, documents what happened — and then, when that patient returns two months later or when a result comes back or when something changes, the physician is often starting from scratch. The original thread of reasoning isn’t preserved. It decayed into the record somewhere between the billing codes and the checkbox fields.
I found this maddening as a new attending. I still find it maddening. Not because I’m idealistic about technology — I’ve become considerably less idealistic about technology over the last eighteen months than I was when I started. But because the gap between what physicians need from their tools and what their tools actually do is not a technical limitation. It is a design choice. And it is a design choice made for someone else’s benefit.
I kept waiting for someone to build something. I watched mentor after mentor clearly see the problem. They identified it precisely, described it accurately, and then moved on. No one organized a solution. That lit a fire under me — not just for myself, but out of something like obligation to the people who had taught me to think critically enough to see the problem clearly in the first place. I wanted to honor that clarity with action, not just acknowledgment.
So I started building.
I need to be direct about what that means, because it’s easy to make founding stories sound cleaner than they were.
I am not an engineer. I had never written a production codebase before this. My identical twin brother — who is, by any fair accounting, a de facto co-founder of the company I now hold — is the one who was the technical brain I bounced ideas off across years of thinking. He gave me a foundation I didn’t have on my own. What followed, though — the testing, the implementation, the security methodology, the architecture decisions made at two in the morning — I did on my own, using AI code assistance primarily through Claude, in the margins of a clinical practice that never paused to let me catch up.
Some people might see that as a liability. A physician building clinical infrastructure without formal engineering training. I understand the concern.
But here is what I understood early: if I wanted to build a trust-first clinical intelligence platform that physicians would actually use, it couldn’t just be good enough. It had to be damn good. Ironclad. Because the people I was building it for hold their patients’ data as a sacred trust, and any tool that violated that trust — even quietly, even accidentally, even with good intentions — would be worse than no tool at all.
That standard focused me in a way that formal engineering training might not have. I didn’t have the luxury of shipping something rough and iterating. I had to think through the structure before I touched the implementation. The two hundred hours of architecture before two hours of code, rather than the two hundred and two hours spent building the wrong thing.
This instinct didn’t come from nowhere. In medical school, I found myself staring at research databases of four thousand patients, all requiring the same two or three variables extracted by hand. There has to be a better way, I thought. That thought never left me. Python gave me my first vocabulary for it — for loops, dictionaries, functions designed around one premise and only that premise, libraries built for one specific purpose. I started thinking in effects rather than in actions. I started asking second and third order questions before first order ones.
Constraint, it turns out, is the substrate for excellence. A fragmented mind is the burial ground for good ideas. If you do not focus on one thing well — one problem, one domain, one question — you never develop the expertise that creates insight you can actually transfer to someone else. The lens through which you see one problem, if it’s ground finely enough, can illuminate many others.
The constraint I chose is physician sovereignty.
The proposition that the physician is the structural principal in the architecture of clinical AI — not a user, not an endpoint, not a data source. That the intelligence derived from physician work belongs, structurally and not merely by policy promise, to the physicians who generated it. That a system which quietly surveils physicians, ranks them, or converts their clinical reasoning into leverage for administrators and payers is not a neutral technology. It is a clinical risk.
Everything in PDI Med is downstream of that constraint.
The vault, which keeps identified clinical data local and physician-controlled. The de-identification pipeline, which lets intelligence travel without letting identity travel with it. The parse-review-commit architecture, which treats physician approval not as a UX nicety but as a load-bearing wall — nothing becomes authoritative without a physician having seen it and affirmed it. The federated intelligence layer, which lets collective patterns emerge from individual physician data without requiring that data to be surrendered to a central custodian.
These aren’t features. They are the structure.
In medicine’s AI landscape, almost everyone is building windows. Beautiful, capable, increasingly impressive windows. I became convinced, on those walks, that the problem was the wall. That if you didn’t solve the structural question first — who owns the data, who governs the intelligence, what happens when the incentives of a software company and the interests of a physician diverge — then the windows, no matter how good, would eventually become instruments of the very system they were supposed to improve.
My grandfather’s phrase again: the structure is the design.
This Substack is the external record of an internal thinking process.
The posts here are the best representation I could find of a complex problem, synthesized after months of turning it over on walks, in quiet moments between cases, in the particular kind of stillness that comes at the end of a long day when the children are finally asleep. I don’t pretend these ideas arrived clean. They arrived in fragments, in dictations, in conversations with a language model that asked good questions back. What you’re reading is the version that survived enough scrutiny to feel worth sharing.
I will write about the problems I was trying to solve before I built anything. About the first principles I kept arriving at when I stripped the problem down far enough. About the decisions I made and the ones I reversed and what I learned from both. About the mental models — Munger’s inversion, Chesterton’s fence, Goodhart’s Law, first through fourth order effects — that I kept reaching for because they fit the shape of the problems I was working on.
I will write about building as a physician, which means building under the specific obligation that your tool will be used by people whose errors can harm patients. That is a different obligation than most software founders carry, and it changes what you’re willing to ship.
I will write about the architecture in enough detail that someone who wants to evaluate it can. This is not a marketing document. If I’m wrong about something, I want to know. The standard I was trained to hold in medicine is the same standard I’m trying to hold here: you do not get credit for intention. You get credit for outcome.
And I will write, occasionally, about the dog walks. About what it means to keep a problem alive in your mind across months of clinical pressure and a house that is always, beautifully, loudly full of small people who need you. About the particular kind of stubbornness required to build something you are not sure anyone else wants yet, because you are certain it needs to exist.
I had two grandfathers. One taught me that structure is the design. The other taught me what it means to care for another person under conditions of uncertainty, incomplete information, and no guarantee of outcome.
I don’t know if PDI Med will outlast me. I don’t know if it will work the way I think it will, or find the audience I believe it deserves, or become the infrastructure layer for physician-sovereign AI that I am trying to make it.
What I know is that the load-bearing walls are where I put them for reasons I can articulate. That the constraint wasn’t the enemy of what I was trying to build — it was the thing that made it possible to build anything worth building at all.
This is where I start.
Dan Bristow, MD Founder, Physician Driven Innovations, LLC (PDI Med) Kansas City, Missouri
Next: The problem that medicine can’t see because it’s inside the record — why the EHR was built for the wrong person, and what that costs physicians every day.