The Case for the Doctor-Led Dev Team: How Clinical Architecture Builds Better Medical Software

Physicians gave their own EMR software a mean usability score of 45.9 out of 100 in a study published in Mayo Clinic Proceedings — a grade of F. For context, Google scores 93 on the same scale. Even Microsoft Excel, widely considered frustrating, scores 57.

To put that into perspective: doctors rate the tools they use every day closer to unusable than acceptable.

This is not a marginal issue. It is systemic.

This is not a technology problem. The technology exists. It is a translation problem — and it starts the moment a developer who has never sat in a consultation room opens a blank database schema.

I know this because I am a gynecologist who built one from scratch.

What you will learn in this article:

• Why EMR interfaces consistently fail to match real clinical thinking — and how clinical experience drives minimalist design
• The three infrastructure options, the wrong assumption that almost derailed the architecture, and why only a clinician could correct it
• How a single WhatsApp message revealed the biggest advantage of building your own software
• What IT skills a doctor actually needs to be effective inside a tech team
• Why a clinical consultant is not a substitute for a clinician-founder — and what the combination produced in practice

---

The interface that exposed a developer's fingerprint

The first time I reviewed a competitor's EMR seriously, I did not need to read the documentation. I could see exactly how it was built.

The navigation was organized into separate lists: prescriptions, examinations, investigations, lab results. Each category had its own module, its own screen, its own entry point.

It was a perfect replica of database tables.

The problem is that this is not how medicine works. A doctor does not think in categories — a doctor thinks in consultations. Every visit has a date, a reason, a set of findings, a decision, a follow-up plan. Everything that happened that day belongs together. The prescription written during a consultation belongs to that consultation, not to a global prescription list the patient shares with every visit across five years.

When I designed doctoLys, the structure was the opposite: a chronological list of consultations, and inside each consultation, everything that occurred during that visit. Navigation becomes immediate. Context is never lost. The interface mirrors the mental model a doctor already has after years of working with paper records.

This is not a design preference. It is the difference between software that gets adopted and software that gets abandoned.

The minimalism question cuts even deeper when you consider who the user actually is. Our target users had spent years — often decades — working with paper. Moving them to a screen with twenty buttons, twelve modules, and a navigation bar full of icons is not digitization. It is abandonment dressed up as modernization. When we hired an experienced UX designer early in the project, their instinct was to benchmark existing EMR solutions. The problem was that those solutions had already failed the usability test. Benchmarking failure produces better-looking failure.

The clinical insight I brought was simpler: a paper consultation note has a date, a reason for the visit, findings, a decision, and a follow-up. That is five elements. The interface should reflect exactly that — nothing more on the first screen. Every additional element is friction for a doctor who is already managing a waiting room. As we explored in why mobile-first design is critical for clinical adoption, the interface design challenge is not about adding features — it is about removing everything a paper-trained doctor does not immediately recognize.

---

The database decision that developers always get wrong

Before any interface could be designed, there was a more fundamental question: how should the data be structured?

I had to learn PostgreSQL from scratch — tables, foreign keys, one-to-many and many-to-many relationships. Not to become a developer, but because I understood something the dev team did not: a wrong data architecture in a medical application is not a bug you fix in the next sprint. It is a wall you hit two years later when you try to scale.

Because I mastered the clinical reality, I could define exactly what entities existed, how they related to each other, and — critically — what edge cases the schema needed to handle from day one. A consultation can contain multiple prescriptions. A prescription can reference multiple drugs. A pregnancy follow-up has a completely different structure from a gynecology visit. These relationships are obvious to any gynecologist. They are invisible to a developer working from a generic health data model.

The result was a schema built around clinical truth, not technical convenience. That decision quietly prevented several scalability problems that typically surface eighteen months into a product's life.

---

The infrastructure debate — and the wrong assumption that almost broke everything

When we began discussing infrastructure, three options were on the table.

Option 1 — On-premise desktop application. Pros: no dependency on internet connectivity, no data sovereignty complications, no cloud compliance headaches. Cons: no remote access, data security dependent on the doctor's own hardware, updates requiring manual installation on every machine, and — critically — no viable path to data sharing of any kind.

Option 2 — Cloud with a single shared database, multi-user access. Pros: accessibility, security managed centrally, automatic updates. Cons: internet dependency, and a serious data location problem. Because doctoLys was designed from the beginning to be borderless — to work for any doctor in any country, as we explored in borderless medical software architecture — a single shared cloud database immediately raised questions about where patient data was physically stored, and which regulatory frameworks applied. GDPR, HIPAA, local health data laws: in a multi-country product, a single database architecture creates compliance exposure that has no clean solution.

Option 3 — Cloud with a multi-tenant architecture. One isolated database per medical office, with multi-user access within each office. Each doctor's data stays in a defined, auditable location. Regulatory compliance becomes manageable. Remote access is preserved. Updates happen centrally.

The dev team's instinct was to rule out option 3 — and their reasoning revealed a critical assumption. They believed doctors would need to give colleagues and patients direct access to patient records. If that were true, a multi-tenant architecture — where each office has its own isolated database — would indeed be wrong. Shared access across offices would require a shared database.

The assumption was completely wrong. And only a clinician could know that immediately.

Doctors do not give other doctors — let alone patients — direct access to their medical records. The record is not just patient data. It is the doctor's personal clinical notes: observations, impressions, uncertainties, things written in the moment of a consultation that were never meant to be read by anyone else. Doctors consider that record their own professional property, even when the underlying data belongs to the patient.

What doctors actually need to share is a static document: a report, a prescription, a referral letter. A formatted output, not a live record. Multi-tenant architecture handles this perfectly — the static document is generated from the isolated database and shared externally. The data itself never moves.

I was not comfortable with the on-premise option either, and for reasons that had nothing to do with architecture. I asked three questions no infrastructure engineer could answer from a whiteboard:

What happens when a doctor needs to access a record during an emergency call at night? A locally installed application on an office computer is inaccessible. A cloud system is not.

Can doctors manage a local server when it stops working? In my experience practicing in Tunisia, the answer is no. Asking a solo practitioner to restart a localhost server is asking them to become their own IT department. Most will stop using the software within weeks.

Will doctors accept losing the last 24 hours of data if a local backup fails? No. Not once. Not ever.

We built on cloud with multi-tenant architecture — and added a load-balanced infrastructure from the start. Medical practice has zero tolerance for downtime. A doctor mid-consultation who loses access to a patient record does not reschedule. They stop trusting the software entirely. Load balancing was not a nice-to-have at scale. It was a clinical requirement from day one.

---

The WhatsApp message that 2 lines of code — and what it revealed

Several months after the MVP launched, I received a message on WhatsApp from a gynecologist colleague.

"Hi Sadok — the new prescription module is really good. Could you add the dates corresponding to 37 weeks and 40 weeks of pregnancy on the main page of the patient record?"

I read it, understood it immediately, and had it prioritized the same day. The feature was two lines of code. It took a developer less than an hour to implement. For any gynecologist managing pregnancies, it is genuinely useful — those two dates are the boundaries of term pregnancy, and having them visible without calculation saves a small but real amount of cognitive effort dozens of times per day.

Now consider what happens when that same message arrives in a traditional product workflow. It goes into a ticketing system. A product owner who is not a clinician reads it, does not fully understand the clinical context, writes a specification that misses the point, schedules it for a future sprint, and eventually a developer implements something slightly wrong. Three iterations later, the feature ships — six weeks after the original message, instead of one day.

This is not an exceptional story. It is the standard cost of the translation gap in medical software development. Multiply it across every feature request, every piece of user feedback, every clinical edge case — and you begin to understand why EMR usability scores a grade of F.

Being the end user, the product owner, and the domain expert simultaneously is not an advantage you can replicate by hiring a clinical consultant. It is a structural property of the product itself.

---

The DICOM problem I solved on my own ultrasound machine

One of the most requested features from gynecologist users was direct integration between the EMR and ultrasound machines — automatic capture of images and measurements into the patient record, without manual re-entry.

Every existing solution I found relied on a local network connection between the ultrasound machine and the software. Our architecture was cloud-based. The two approaches were incompatible.

I researched the problem myself. I learned the DICOM protocol — the standard for medical imaging data — along with structured reports and DICOM worklists. I tested on my own ultrasound machine in my practice, generating fictive examinations to validate the integration. Because my colleagues trusted me as a peer, several of them gave me direct access to their machines across different brands and models — something no external researcher or developer would have been offered.

The solution I found was one that worked entirely over the internet, compatible with our cloud architecture and with every machine model tested. It took longer than a developer-led investigation would have taken in a local-network environment. But it produced the right answer — because I knew precisely what clinical outcome was required, and I would not accept a solution that did not achieve it.

This is what the translation advantage looks like at its most concrete: not just understanding the problem, but being trusted enough by the people who have it to get real access to their environment.

And it introduced a testing methodology that no external team could replicate. Before any feature reached end users, it passed through two layers of validation. The first was technical — the dev team's standard testing for bugs and edge cases. The second was clinical — I tested every feature in my own practice, on real consultations, against the friction a doctor actually feels in the moment. When something was wrong, I did not write a ticket. I coached the developer directly, showing them what the clinical workflow required and why the current implementation missed it. Only after that cycle — gather feedback, test in my office, refine, validate again — did a feature ship to other doctors.

This is the difference between software that passes QA and software that survives contact with a real consultation room.

---

"But couldn't a doctor just be a consultant?"

At this point, a reasonable objection arises: why does the doctor need to be the founder? Could the same outcome be achieved by hiring a clinical consultant to advise the development team?

In theory, yes. In practice, no — and the reason is not about knowledge. It is about continuity and consequence.

A consultant provides input at defined moments — a requirements meeting, a design review, a user testing session. But a medical software product is not built in defined moments. It is built in hundreds of small decisions made daily, across database schemas, API contracts, infrastructure configurations, and feature specifications. Many of these decisions look purely technical on the surface. The ones I described in this article — the cloud vs. on-premise choice, the multi-tenant architecture, the database schema — were all presented to me as technical questions. They were clinical questions in disguise.

A consultant who is not present when those questions are asked cannot answer them. And a development team under deadline pressure will not wait. They will make the technically reasonable choice — which is often the clinically wrong one.

There is a second problem: a consultant's involvement ends when the contract ends. The consequences of a wrong architectural decision do not. They compound quietly for eighteen months and then become very expensive to fix — if they can be fixed at all.

This is why the combination matters: not just clinical knowledge, but daily involvement, full accountability, and the kind of technical fluency that lets you recognize a clinical question when it is wearing a technical disguise.

What this actually requires — the specific IT skills, the product ownership approach, the team dynamics — is a topic that deserves its own article. We explore it in depth in an upcoming piece on digital health project management: what clinicians need to know before leading a software development team, and the mistakes that kill health tech projects before they reach their first user.

---

What IT skills does a doctor actually need inside a tech team?

This is the practical question the consultant objection raises — and it deserves a direct answer.

The goal is not to become a developer. It is to become fluent enough in technical language that you can recognize when a technical decision is actually a clinical one, ask the right questions, and evaluate the answers you receive.

In my experience, four areas of knowledge made the most difference:

Database fundamentals. Understanding what a table is, what a foreign key does, and what one-to-many versus many-to-many relationships mean is enough. You do not need to write SQL queries. You need to be able to sit in a schema design meeting and say: "This relationship is wrong — a consultation can have many prescriptions, not the other way around." That single intervention, made at the right moment, can prevent a year of pain.

Infrastructure concepts. VPS, cloud vs on-premise, load balancers, backups, data location — not the technical implementation, but the clinical implications of each choice. Enough to ask: "What happens to our users if this server goes down for two hours?" and understand the answer.

Product ownership basics. Backlog management, sprint planning, ticket writing. Not as a project manager — as a clinician who can translate a WhatsApp message from a doctor colleague into a precisely specified development task in the same afternoon.

Regulatory awareness. GDPR, HIPAA, and local health data laws are not just legal requirements — they are architectural constraints. A doctor who understands that data location regulations vary by country can push back before the database is built, not after it is deployed in the wrong jurisdiction.

None of this requires a computer science degree. It requires curiosity, time, and the motivation that comes from building something you actually use yourself. We will go deeper on exactly this — the learning path, the team dynamics, and the project management mistakes that kill health tech ventures before they reach users — in an upcoming article on digital health entrepreneurship.

---

What the combination actually produced

This is not a story about a doctor who learned to code. It is a story about what happens when clinical judgment is present at every decision point in a software product — from the first database schema to the last infrastructure call.

The outcomes were concrete:

Fewer scalability problems. The database schema was designed around clinical reality from day one. The architectural rewrites that typically hit medical software at 500 users, then again at 5,000, did not happen. The decisions that usually become expensive surprises were made correctly before the first line of code was written.

Better UX and higher retention. The consultation-centred interface, the minimalist design, the zero-IT-setup onboarding — these were not caught in user testing after they shipped. They were the result of a product owner who was also an end user and would not accept an interface that did not feel like medicine.

More efficient team management. Features were specified precisely the first time, eliminating the back-and-forth iterations that consume most of a development team's capacity. The 37WA example is not an exception — it is the rhythm. A two-line feature shipped in a day instead of a six-week ticket cycle.

A product that works where others do not. Because infrastructure decisions were made with the clinical realities of doctors in Tunisia and the broader developing world in mind — not the assumptions of Western enterprise software — doctoLys runs on 4G, requires no IT support, and imposes no country-specific constraints.

Research published in JMIR Medical Informatics consistently identifies poor workflow alignment as the primary reason EMR products are rejected. The combination of clinical judgment and daily technical involvement is the only reliable way to prevent that misalignment from being built into the product in the first place.

If you are evaluating medical software — particularly if you practice outside the US or Europe — the most important question to ask is not about features or pricing. It is: who made the decisions about how this was built, and did they ever sit in a consultation room?

Everything described in this article happened before AI entered the picture. The translation advantage was real — but it was slow, manual, and dependent on one person being in every room at the right time. In an upcoming article, we explore how generative AI finally solved the clinical input paradox — and why the combination of clinical judgment and AI-assisted development has unlocked capabilities that were simply not possible before.

The challenge is not just to digitize healthcare — but to align software with clinical thinking.

---

Written by Dr. Sadok Derouich, a practicing gynecologist since 2012, digital health entrepreneur, and CEO of doctoLys — the AI medical office app built for doctors worldwide.