Healthcare Is Discussed From Too Far Away
What mobile dentistry taught me about the distance between designing healthcare and actually delivering it.
If you wanted to understand why healthcare fails, where would you go?
The usual answers are some version of: a ministry, an insurer, a university, a technology conference. There you would find intelligent people discussing reimbursement systems, clinical guidelines, interoperability and artificial intelligence. These are reasonable places to look, and I have sat in a number of them myself, nodding at diagrams.
I would take you somewhere else. I would take you to Room 214 of a nursing home.
There you might meet someone like Frau Keller, who is 86, has moderate dementia, and has broken her lower denture. The problem sounds straightforward enough: repair the denture. Clinically, it may even be straightforward.
But first, someone has to notice that she is eating less. Someone has to work out whether the denture is broken, painful or simply missing. Her daughter may need to be contacted. Her medical history and medication list must be available. A member of the nursing staff has to accompany her. The dentist needs the right equipment in the building. The denture may need to travel to a laboratory and come back without getting lost, and everyone involved needs to know what happens next.
The actual dental procedure might take twenty minutes. Delivering those twenty minutes can take several days and half a dozen people.
This is the first thing distance hides: the treatment is often the smallest part of delivering the treatment.
The altitude problem
Healthcare looks different depending on the altitude from which you observe it.
From 10,000 metres, it consists of populations, budgets, institutions and policies. From 1,000 metres, it consists of pathways, professional groups, contracts and information systems. At ground level, it consists of a particular person, in a particular room, needing someone to do something.
Each altitude shows something true. None of them shows enough on its own, and the trouble begins when we design healthcare at one altitude and assume it will behave the same way at another.
A policy document might contain an arrow between “assessment” and “treatment”. On paper, the arrow occupies two centimetres. In reality, that arrow may contain three phone calls, a missing consent form, an unavailable caregiver, incompatible software, an unanswered email and a patient who no longer remembers why a dentist is standing in her room.
Healthcare accumulates complexity inside its arrows.
From far away, the arrows look free.
Three maps of the same system
My own view of healthcare has changed mostly because I have kept changing professions inside it.
As a dentist, I was trained to read the clinical map: diagnosis, treatment options, risks and outcomes. As a health economist, I learned the incentive map: who pays, what is reimbursed, what gets measured, and which behaviours the system quietly encourages. As a data scientist, I learned the information map: which events become data, which variables disappear, and how confidently we can infer anything from the record that remains.
Then I built and operated a healthcare organisation, and discovered a fourth map that nobody had trained me to read. Call it the operational map. It holds the things that almost never appear in scientific papers or policy presentations: who calls the patient’s daughter, where the equipment is stored, whether the nursing home has a working elevator, who notices an incomplete form, and what happens when the only person who understands a process is on holiday.
Each of these maps can be accurate and still dangerously incomplete. A clinically excellent intervention fails because nobody is paid to coordinate it. A financially attractive programme fails because it does not fit into anyone’s working day. A beautiful dataset describes only the parts of care that generate a billable event, and a technically impressive product dies because it adds forty seconds to a task performed two hundred times a day.
Healthcare does not happen on any one of these maps. It happens where they overlap.
Why a new reimbursement code does not create care
Imagine that a health system wants more preventive examinations in nursing homes. A new service is defined, eligibility criteria are written, a reimbursement code is created, and a presentation is produced showing the expected improvement in access.
From a distance, the causal chain appears obvious:
New benefit → providers perform it → patients receive better care.
A reimbursement code, however, is not a care-delivery system. Someone must identify eligible patients. Consent may need to be obtained. A visit must be coordinated with the facility. Documentation requirements must be understood. The service has to fit among other clinical responsibilities, and information must move between organisations that may use entirely different systems. If the work surrounding the reimbursed activity is more difficult than the activity itself, utilisation stays low.
When that happens, it is sometimes read as resistance from professionals. Occasionally it is. More often it is a design problem: the system has funded the visible clinical act while leaving the surrounding coordination unpaid, unowned and invisible.
Incentives do not decide whether healthcare workers care about their patients. They decide which forms of caring can survive contact with a crowded schedule. Those are different questions, and a great deal of policy disappointment lives in the gap between them.
Data records events, not reality
The same distance problem runs through healthcare data.
Suppose a dataset shows that a patient received no dental treatment during a particular year. What does that mean? Perhaps the patient was healthy. Perhaps the patient declined treatment. Perhaps nobody examined her. Perhaps an examination took place but was documented elsewhere. Perhaps treatment was needed, but transport could not be organised. Perhaps the care was delivered and simply is not represented by the code being analysed.
In the dataset, these very different realities look identical: nothing happened.
That is one of healthcare data’s most seductive qualities. It presents a clean surface over an untidy world. The numbers may be correct while the interpretation is wrong, which is a more dangerous combination than an honest error.
Claims data can tell us a great deal about what a system paid for. It is far less reliable about what patients needed, what professionals attempted, or why an apparently indicated intervention never took place. None of this makes the data useless. It makes proximity essential: researchers need to understand how the data were produced, clinicians need to understand what disappears when care becomes data, and policymakers need to know which parts of the system are visible only because they happen to be easy to count.
Otherwise we improve the metric and leave the patient in Room 214 exactly where she was.
Technology has an altitude problem too
Healthcare technology is usually demonstrated from very far away.
A product can analyse an image, draft a clinical note or predict a risk with extraordinary accuracy. The capabilities are real, and they are getting more impressive by the quarter. But capability is not the same thing as usefulness.
Take an AI system that reviews a dental radiograph in seconds and performs beautifully in a controlled evaluation. Now place it inside a working clinic. Can it access the image without a manual upload? Does it know which patient the image belongs to? Can its result enter the clinical record? Is the dentist expected to check a separate screen? What happens when the internet fails? Who is responsible when the model is uncertain? Does the system remove work, or merely move it to someone who appears on no slide?
Nothing about the model’s accuracy has changed. Its value has.
I have come to hold every healthcare technology, very much including our own, to three questions:
Where, exactly, does it enter the workflow?
Whose work becomes easier or unnecessary?
What happens when it is wrong, unavailable or ignored?
A product without good answers to these questions may be an impressive technology. It is not yet a functioning part of care.
Responsible AI, in other words, is not only a matter of model performance, bias and data protection, although all of those matter. It is also a matter of operational honesty. A system should not claim to save clinicians time when it merely transfers work to assistants. It should not claim to improve access when it serves only the patients who already navigate the system successfully. And nobody should call a prediction “actionable” unless someone has both the authority and the capacity to act on it.
The real unit of innovation is not the algorithm. It is the completed workflow.
What mobile care makes visible
At SwissMedAI, much of our work involves delivering dentistry to older people, including residents of nursing homes. I used to think of mobile dentistry as conventional dentistry performed in a different location. The field cured me of that idea fairly quickly. Mobile care is a different operating environment altogether.
In a conventional practice, most of the conditions required for care are already in place before anyone picks up an instrument. The patient has arrived. The chair, the instruments and the records are within reach. The building itself is designed around treatment, and the surrounding organisation stays invisible mainly because it is familiar.
Mobile care removes that illusion. The clinical team must bring not only the treatment but a portion of the system that makes treatment possible: equipment, information, coordination, continuity. This is what makes mobile care difficult, and it is also what makes it revealing. Weaknesses that stay hidden in a conventional setting have nowhere to hide in a nursing home corridor. Poor information exchange shows up immediately. So does ambiguous responsibility, and inadequate reimbursement, and technology that was designed without anyone ever watching the user work.
Nursing homes are commonly treated as a marginal corner of healthcare. I have come to see them as the opposite: stress tests for healthcare design. If a process only works for people who can organise appointments, follow complex instructions, travel independently and coordinate several professionals, it is not a robust process; it is a process that quietly depends on healthy patients doing part of the system’s work.
Proximity is not the same as truth
There is, however, a danger in romanticising the frontline, and I would rather name it myself before someone else does. Being close to care does not automatically make a person right.
A clinician can mistake personal experience for general evidence. An operator can optimise a local process while missing its wider consequences. A single compelling patient story can drown out data from thousands of patients nobody tells stories about. Distance has real advantages: comparison, abstraction, perspective.
The remedy is not to replace policy with anecdote, or research with intuition, but to build a better elevator between the altitudes. Policy informed by what implementation actually requires. Research that tests whether frontline impressions generalise. Technology teams that observe the work before redesigning it. Clinicians who understand the incentives and constraints shaping the systems around them.
We need both the map and the room.
Starting from the room
This publication will be written from that intersection.
I will write about clinical care, incentives, data, regulation and technology, but I intend to begin, each time, with what is actually happening: not with what the workflow is supposed to look like, not with what the database implies must have happened, and not with what a product presentation promises will happen. What actually happens when a policy reaches a clinic? When an algorithm meets a professional workflow? When a theoretically available service reaches a person who cannot independently access it?
Sometimes the answer will come from evidence. Sometimes it will come from operational experience. Sometimes it will remain a hypothesis worth testing, and I will try to be clear about which is which.
I am not arguing that healthcare is impossibly complicated. I am trying to locate where its complexity actually lives, so that we can build systems that deal with it honestly.
Frau Keller eventually receives her repaired denture.
She eats lunch.
It is not a spectacular outcome. Nobody announces it at a technology conference, it appears on no executive dashboard, and depending on the data, we may not even be able to distinguish it from a hundred other repairs. But this is what healthcare is for: making ordinary human outcomes reliably possible.
To build it better, we need to get closer.
A note on Frau Keller: she is a composite, assembled from situations that recur in mobile care. No detail in this essay identifies a real patient.




