I have spent my career in two rooms. In one, I am a vascular neurologist — trained at Georgetown, then through neurology residency and a vascular neurology fellowship at Mayo Clinic in Scottsdale — making time-critical decisions with imperfect information. In the other, I am Neuvora's chief technical architect, deciding how a monitoring platform models a patient, what an alert is allowed to interrupt, and where a click can be deleted. The thesis of this essay is that healthcare software changes fundamentally depending on whether those two rooms share an occupant.
Why does clinical software so often fight the clinician?
Not because the engineers are careless. The people building health IT are, in my experience, conscientious and often idealistic. The problem is structural: most clinical software is built from a description of clinical work rather than from clinical work itself.
Consider how a requirement typically travels. A clinician mentions a problem to an analyst. The analyst writes it up. A product manager prioritizes and reframes it. An engineer implements what the ticket says. At each hop, fidelity is lost — not through negligence, but because each translator carries a different mental model of what happens in an exam room. The clinician said "I need to see the trend before I call the patient." The ticket says "display historical values." The feature shows a table, sorted by date, on a separate screen, behind a click. Every word of the requirement was honored; the point of it was lost.
Multiply that loss across hundreds of requirements and you get the software clinicians actually live with: systems that are feature-complete on paper and adversarial in practice, where documentation demands attention during the visit, where the workflow the vendor imagined and the workflow the clinic runs diverge on day one. The industry's answer has been to hire clinical consultants, run advisory panels, and shadow users — all genuine improvements, all still translation layers. A consultant who left practice five years ago is remembering clinic; a panel that meets quarterly is summarizing it.
There is also an asymmetry in what gets lost. The requirements that survive translation are the nameable ones — fields, reports, buttons. What dies in translation is the tacit layer: the order in which a clinician's attention actually moves, the interruptions that are tolerable at minute two of a visit and intolerable at minute twelve, the difference between information that supports a decision and information that merely attends it. No ticket format captures that layer, because the people who live it do not experience it as requirements. They experience it as the day.
What changes when the architect is a practicing physician?
The translation chain collapses to zero hops.
When I design the charge-capture flow or the alert model, there is no analyst between the clinical requirement and the technical decision, because the person holding the requirement and the person making the decision are the same person. I do not need the workflow described to me. I ran it this week. The questions that consume weeks of requirements-gathering — what does the nurse actually look at first, what interrupts a practitioner acceptably and what does not, which data point changes the decision and which is decoration — are not research questions. They are recall.
This is not an argument that physicians are better engineers. It is an argument about where fidelity lives. Two things change concretely:
Workflow empathy becomes architecture, not decoration. In most health IT, clinical input arrives late — a usability pass over decisions already made, a color change on a data model that was wrong from the start. When the architect is a clinician, clinical reality shapes the layer that is expensive to change: what the system considers an event, how a patient's state is represented, what the software believes a "task" is. Empathy applied at the interface makes software pleasant. Empathy applied at the architecture makes it correct.
"Feature-complete" and "clinic-viable" stop being the same claim. Feature-complete means the ticket's acceptance criteria pass. Clinic-viable means the feature survives contact with a Tuesday afternoon — the double-booked schedule, the patient who answers the phone mid-documentation, the reading that arrives during another patient's visit. Software built from specs optimizes for the first, because the spec is the only clinic the builder has visited. Software built by someone who will use it optimizes for the second, because he has to.
Does this actually make builds faster?
Yes — but the honest version of that claim is about loop length, not effort.
Software development speed is dominated by iteration cycles: build something, discover it is subtly wrong, correct course. In conventional health IT, that loop runs through scheduling — build for six weeks, demo to clinicians, collect feedback through the same lossy translation chain that created the misunderstanding, rebuild. The loop is measured in weeks, and each turn of it burns trust along with time.
When the architect is the clinician, the loop runs at the speed of one person's judgment. A design that would fail in clinic dies at the whiteboard, the same hour it was drawn, because the person drawing it has already lived the failure it would cause. A prototype gets validated against lived workflow the day it exists, not at next month's demo. The build is not faster because anyone works more hours; it is faster because it takes fewer wrong turns, and discovers the wrong turns it does take in hours instead of quarters.
This compounding is the mechanism behind a small company shipping working software against incumbents with far larger teams. Team size scales the number of loops you can run in parallel. Loop length determines how much each one teaches you. I will take the shorter loop.
What does "validated" mean at Neuvora?
Three specific things, none of them a certification theater.
Built against real workflow. Every feature in our platform earns its place against the question "what does this remove from a clinic's day?" — asked by someone who has that day. Our software sits inside a full stack we run ourselves — the platform, FDA-cleared devices, and the care-delivery layer — which means our own monitoring operations are the first user of everything we ship. When the alert triage is wrong, we feel it before any customer does.
Measured in clicks and minutes. The unit of value in clinical software is not the feature count; it is the attention returned to the clinician. We count the clicks between a reading and its documentation, the minutes between an alert and its resolution, the number of screens a nurse touches to close a patient-month. When a release does not move those numbers, it did not help, whatever the release notes say.
HIPAA-first architecture. Compliance designed in at the data layer — how PHI is stored, moved, logged, and audited — rather than wrapped around the outside after the fact. This is also where the physician-architect model earns its keep quietly: knowing what data clinical work genuinely requires is the difference between minimum necessary as a principle and as an afterthought.
Integration follows the same philosophy. Our EHR integrations with Tebra, PrognoCIS, and eClinicalWorks are live, bidirectional connections — monitoring data and documentation landing in the chart as structured records — because an integration that ends in a PDF is a translation layer of its own, and we have spent this whole essay against those.
What does workflow minimization look like in practice?
Two generic examples of the design philosophy, chosen because they generalize beyond us.
Charge capture that follows the encounter instead of interrupting it. In most systems, billing documentation is a separate act performed after the clinical work — a second pass through the same information, at the end of a day that has no room for it. The alternative is to let the billing artifact fall out of the clinical workflow itself: the time log accrues as the nurse works the readings, the transmission-day count assembles itself from the device data, and the month-end billing file is a report, not a project. The clinician's attention is spent once, on the patient.
Alerts triaged by clinical priority rather than timestamp. A queue sorted by arrival time treats a critical value and a borderline reading as equals, and trains staff to distrust the queue. A queue sorted by clinical priority — what a physician would want to see first, encoded by one — protects the scarcest resource in the clinic, which is attention. The difference between the two queues is invisible in a feature list and decisive at 4 p.m. on that Tuesday.
Neither example is exotic. Both are the kind of decision that gets made correctly when the person making it will sit in the resulting workflow, and incorrectly when the workflow is a paragraph in a requirements document.
Why does this matter for a practice choosing partners?
Because the question "who built this?" predicts your next two years better than any feature comparison. Software built through translation layers will fit your clinic approximately, and the gap becomes your staff's daily workaround. Software built by someone who runs the workflow it serves starts closer to correct and closes the remaining gap in short loops rather than annual releases.
Neuvora's model — physician-founded, physician-architected, full-stack from software through devices to the care layer — is one implementation of that idea, and our RPM program is where most practices encounter it first. If the argument here resonates, or if you want to test it against your clinic's ugliest workflow, talk to us — bring the workflow.
This essay reflects the author's professional views on healthcare software development and is general information, not legal, billing, or medical advice.
