Finding the Corner Pieces:
Why We Built Synthetic Hospital
Medicine can sometimes feel like being handed a thousand-piece puzzle while someone is actively shaking the table. The pieces are all there somewhere: a CT from six months ago, a surgery from three years ago, a medication buried in an old note, a lab result from this morning, a one-line consult note that suddenly turns out to be very important. The problem is that when you actually need the answer, you usually do not have an afternoon to sit down, spread everything across the floor, and admire the puzzle. Sometimes you have five minutes. Sometimes you have five patients. And sometimes all five of them seem to get sick at the same time. That tension between how much information exists in medicine and how difficult it is to actually use it is a big part of what eventually led me from neurosurgery into a computer science PhD and ultimately to Synthetic Hospital.
My pursuit of medicine began with the brain but not in the operating room. It began in intimate moments with my grandparents as they lost themselves to Alzheimer’s disease. Growing up, I watched my grandpa’s identity dissolve year by year, yet I still saw joy when I brought him canned peaches which were small moments that remained anchors of meaning. Years later, my grandma followed a similar path. Though she lost her independence and memory, she never lost her capacity to feel presence and connection. These experiences shaped my earliest understanding of the brain as the seat of identity and purpose and they drew me toward neurosurgery to protect what makes life meaningful when everything else is stripped away.
For a long time, I thought that was how I would have the greatest impact. Neurosurgery gives you the opportunity to help people in an unusually direct way. There is a patient in front of you, something is wrong, and sometimes you can physically do something about it. The responsibility can be enormous but so can the privilege.
As I got further into training, though, I started noticing another kind of problem. Some of the hardest problems in medicine were not caused by a lack of information. They were caused by having too much of it. One of the most frustrating situations in clinic is meeting a new patient who has been going from provider to provider trying to figure out what is wrong. They have had scan after scan, test after test, sometimes procedure after procedure, but they still do not have an answer. Their medical record keeps getting bigger without necessarily becoming more understandable. You see a more urgent version of the same thing in critically ill patients. A patient keeps getting worse. Another test gets ordered. Another consultant gets involved. More information accumulates. Yet the team may still be struggling to understand what is driving the decline. More data does not automatically mean more understanding.
The nights on call made that problem much more concrete for me. Imagine several critical consults coming in at once. You are trying to figure out who needs to be seen first, but before you can triage well, you need to understand who these patients actually are. One patient has metastatic cancer. Another has had multiple shunt revisions. Another has a complicated surgical history scattered across years of notes. So you start clicking. Progress note. Operative note. Oncology note. Discharge summary. Imaging report. Another discharge summary. Another progress note. You want to know as much as possible before you walk into the room because those details matter. They change the questions you ask. They change the differential diagnosis. They change what you worry about. But you also cannot spend 30 minutes reconstructing every patient’s history while someone sick is waiting for you.
I remember thinking many times how AI could be helpful. Not by replacing me or by making the decision for me but by helping me get oriented. Giving me the neurosurgical version of this patient’s history. Telling me what cancer treatments they have already received. Showing me the major procedures and how they relate to what is happening now. And if it gives me a summary, showing me which parts of the chart support it so I don’t have to simply trust that the model got it right. That alone would have made some call nights much better.
I should also admit that clinicians contribute to the problem. I certainly have. When you are busy, the indication you enter for an imaging study is not always your finest work. Sometimes it is something beautifully informative like “f/u.” Now imagine being the radiologist who receives a third head CT on the same patient that day with that indication. Follow up what? Are we watching an intracranial hemorrhage? Checking ventricular size? Looking for postoperative changes? Did the neurological exam change? Is there concern for a new complication? The radiologist now has to open the chart and reconstruct what the ordering clinician was thinking. Again, the information is probably there. The problem is getting to it. Wouldn’t it be nice if the EHR could understand the patient’s context and automatically turn “f/u” into an actually useful imaging indication? That sounds like a small thing. Multiply small things like that across an entire hospital, and they stop being small.
By the middle of my neurosurgery training, I had published more than 100 peer-reviewed papers. On paper, I was doing a lot of research. But I increasingly felt that I was not having the kind of impact I wanted to have. At the same time, AI was advancing extraordinarily quickly. I started spending more time working in machine learning and clinical AI, and the gap between what models could do on benchmarks and what I actually needed during a night on call became difficult to ignore. A model answering a medical multiple-choice question correctly is interesting. But can it understand a patient whose story unfolds over years? Can it find the right evidence buried across dozens of notes? Can it summarize the same chart differently for a neurosurgeon, an oncologist, and a cardiologist? Can it figure out why an imaging study was ordered? Can it navigate an EHR without getting lost? And perhaps most importantly: how do we know when it got those things right?
Eventually, I made the decision to take a leave of absence from neurosurgery training and pursue a PhD in computer science. From the outside, that probably looks like a fairly dramatic change in direction. It did not feel that way to me. I was not trying to leave medicine. I wanted to learn a different set of tools for solving the problems I kept encountering inside medicine. I wanted to be around people pushing the technical frontier and understand these systems deeply enough that I could help build better ones rather than simply use whatever happened to exist.
There was also a question of scale. In neurosurgery, you can make a profound difference for the patient in front of you. That is difficult to replicate anywhere else. But I became increasingly interested in whether there was another way to have a positive impact: by building tools that could eventually make life easier for many clinicians and, through them, help many more patients. That is one of the things that drew me to computer science. It did not feel like abandoning the reason I entered medicine. It felt like trying to pursue the same goal from another direction.
And there was another piece that became increasingly important to me: openness. A lot of clinical AI research is difficult to participate in unless you happen to be at the right institution, with access to the right data, the right infrastructure, the right agreements, and the right collaborators. There are very good reasons for many of those restrictions (medical data should be protected) but the result is that a relatively small number of groups can work on some of the most important problems. I would love for clinical AI research to look more like the best parts of open-source software, where someone builds something useful, someone else finds a weakness, another group improves it, a clinician notices that the task does not actually match how medicine is practiced and proposes a better one, an engineer makes the system faster, and a researcher on the other side of the world comes up with an idea none of the original team considered.
If AI is going to become genuinely useful in healthcare, I do not think any one lab, company, hospital, or model is going to get us there alone. We need clinicians who understand the workflows, computer scientists who understand the models, engineers who know how to build reliable systems, researchers who know how to evaluate them, and many others who bring perspectives none of us has individually. Making clinical AI research more open gives more people a chance to contribute.
The problem, of course, is that healthcare data are not like images of cats on the internet. Real electronic health records are understandably difficult to share. Patient privacy matters. Access often requires institutional agreements, credentialing, data-use agreements, and lengthy approval processes. Even when you can access real clinical records, another problem appears: the ground truth is messy. A chart is not a perfect representation of a patient. Something can be true and never documented. Two notes can contradict each other. A diagnosis may be mentioned once and never appear again. Different physicians may interpret the same evidence differently. So if an AI system gives a different answer from the chart, sometimes the model is wrong. But sometimes the chart is incomplete. That makes it surprisingly hard to answer a deceptively simple question: is the model actually getting better?
This is where Synthetic Hospital came from. Synthetic Hospital is our attempt to create an open environment where researchers can study realistic clinical AI problems without needing access to private patient records, while still having verifiable ground truth. The basic idea is straightforward. Instead of asking an LLM to invent a patient from scratch and then treating whatever it wrote as truth, we first construct the patient’s underlying clinical state. We start with public medical educational material, extract diagnoses and findings, ground them to medical ontologies, connect them in a structured knowledge graph, and assemble compatible cases into longitudinal patients. Only after that underlying patient is fixed do we generate the clinical documentation.
That ordering matters. The prose can change. The wording can change. The style of the note can change. The underlying patient does not. And the information we use to score models comes from that structured patient state rather than from whatever wording the narrative generator happened to produce. The result is a fully synthetic hospital where we can ask questions that look much more like the ones I actually cared about clinically. Can you reconstruct this patient’s longitudinal problem list? Can you summarize the chart? Can you create a summary specifically for the specialty that is about to see the patient? Can you find the evidence supporting a particular diagnosis? Can you figure out the clinical question behind an underspecified imaging order? And because we know how the patient was constructed, we can actually score the answers.
One of the things I am most excited about is that we can make this environment open. You should not need access to a particular hospital system to work on these problems. You should not need to spend months getting access to a private dataset just to test whether your idea works. The hope is that researchers can use Synthetic Hospital as shared infrastructure: build a model, test an agent, discover a failure mode, create a better retrieval method, improve the evaluation, and share what they learn. I do not want this to just be another benchmark with another leaderboard. I would much rather see it become a place where people build things.
We also used Synthetic Hospital to explore a question that has become increasingly popular in AI: should we turn these models into agents and let them navigate the EHR themselves? At first glance, the answer seems obvious. Surely a model that can search through the chart, call tools, and decide what information it needs should be better than one that simply gets a big block of text. Interestingly, that is not what we consistently found. When the relevant information could already be provided directly to the model, turning it into a multi-turn agent generally did not improve performance. In many cases, performance got worse. The agents made extra calls, accumulated more context, sometimes failed to return a usable answer, and introduced additional opportunities for things to go wrong.
The notable exception was longitudinal diagnosis. When the task genuinely required assembling information scattered across the patient’s history, allowing the model to retrieve its own evidence could help. I like that result because it is a reminder that making a system more complicated does not automatically make it more useful. Sometimes the answer is not a more autonomous AI. Sometimes the answer is simply making sure a good model has the right information at the right time.
Which brings me back to that thousand-piece puzzle. I do not think the future of clinical AI is a robot doctor that takes the puzzle away from the clinician, disappears behind a curtain, and comes back with the completed picture. I think a much more useful system is the person sitting next to you who has already found the corner pieces. It has sorted the colors. It remembers that the strange-looking blue piece came from a scan two years ago. If it thinks two pieces fit together, it can show you why. And when you are missing something, it can help you find it. The physician still needs to understand the picture. The physician still has to make the decision. But maybe we do not have to spend quite so much of our time searching under the couch for the missing pieces.
My path from watching my grandparents lose their memories, to neurosurgery, to late nights clicking through patient charts, to taking a leave of absence for a computer science PhD has felt circuitous at times. But to me, it has all been part of the same goal. I went into medicine because I wanted to help people when something frightening was happening inside their bodies and they did not know why. Neurosurgery gave me one incredibly direct way to do that. Clinical AI offers the possibility of helping in a different way and at a different scale: by building tools that make clinicians better equipped to care for the people in front of them.
Making those tools and research environments open creates another level of impact. If more people can work on these problems, challenge our assumptions, find our mistakes, and build things we never would have thought of ourselves, then progress does not depend on any one of us. That is ultimately what I hope Synthetic Hospital can contribute: not just a dataset or a benchmark, but one small piece of an open community trying to make AI genuinely useful and beneficial for healthcare.
I am still trying to do the same thing that brought me into medicine in the first place. I just spend a little less time holding a scalpel these days and a little more time building tools that might help all of us put the pieces together.