Two Apps, One Spine: Building the Health App That Connects Clinic, Hospital, Doctor and Patient
Walk into almost any private clinic in Europe and you will find the same quiet chaos. Appointments live in a practice management system. Results live in a lab portal. Referrals live in a PDF attached to an email. Consultants coordinate with each other on WhatsApp, which is a wonderful piece of software and an absolutely dreadful clinical record. And the patient, the person all of this is theoretically for, finds out their scan is ready when somebody at reception has a free moment to phone them.
The instinct is to fix this with an app. That instinct is right and the execution is usually wrong, because almost everybody builds one app: a patient-facing one, glossy, with a booking screen and a nice logo. Six months later the clinicians are still on WhatsApp, because nobody built them anything. The app became one more system to check rather than the system that replaced the checking.
What actually works is a dual app: two front ends with completely different jobs, sitting on one shared spine. Patients on one side, clinicians and clinic operations on the other, and a single source of truth in the middle that neither side can drift away from. This is the architecture our team in London builds for clinic groups, and it is a genuinely different product to “a health app.”
1. What “Dual App” Actually Means
Two apps. Two audiences with almost nothing in common. One backend they both have to agree with.
The patient app is a consumer product competing for attention with Instagram, so it has to be fast, calm and obvious. The clinician app is a professional tool competing with a paper diary and thirty years of habit, so it has to be dense, keyboard-friendly and forgiving of interruption. Ship the same UI to both and you will produce something that annoys everyone equally.
The Patient App
Consumer-grade · Mobile-first- Book, reschedule and cancel without phoning anyone
- See upcoming appointments, location, and which consultant
- Complete pre-visit forms and consent before arrival
- Receive results and letters, with a plain-language summary
- Secure message their care team, with clear response-time expectations
- Pay, claim, or see what their insurer covers
The Clinician & Clinic App
Professional tool · Speed over polish- A single worklist across clinics, sites and sessions
- Patient timeline: history, notes, results, correspondence in one scroll
- Refer, hand over and escalate inside the system, not over email
- Dictate or draft notes and letters, sign them off in seconds
- Approve results for release, with a hold for anything that needs a conversation first
- Manage rota, capacity and DNA risk across the whole group
2. The Spine: The Part Nobody Demos
The two apps are what people buy. The spine is what makes them worth buying. It is the least glamorous part of the build and the only part that determines whether the whole thing survives contact with a second clinic site.
What the shared layer has to own
One patient identity across every site, so the same person booking at the Harley Street clinic and at the imaging centre is one record, not two that quietly drift apart for eighteen months. One clinical data model, ideally FHIR-shaped from day one, so lab systems, PACS and any future EHR can be plugged in rather than translated by hand. One notification service, so a rescheduled appointment updates the patient, the consultant, the rota and the room booking in a single transaction. One audit trail, capturing who viewed what, when and why, because in healthcare “we can add logging later” is not a technical decision, it is a compliance failure with a delay fuse.
Build the apps first and the spine second and you will spend year two rewriting year one. We have inherited enough of those projects to say it without hedging.
3. The Business Case, In Numbers Rather Than Adjectives
Clinic directors do not buy architecture. They buy fewer empty chairs and fewer hours of admin. Fortunately the evidence here is unusually good, because the NHS has measured the problem at a scale no private group could afford to.
| Lever | What the Evidence Shows | Where It Lands |
|---|---|---|
| Missed appointments | 7.6% of 103m NHS outpatient appointments were DNAs in 2021/22 — around 650,000 slots a month | Direct revenue recovery |
| Reminders that reply back | Two-way reminders have reduced DNAs by up to 80% in published NHS interventions | Highest ROI feature you will ship |
| Digital self-service | One provider reported a 39% difference in DNA rates between portal-registered and unregistered patients | Compounds as adoption grows |
| Reminders + online rescheduling | Royal Orthopaedic Hospital: DNAs from 10.9% to 7.1% in nine weeks, with ~£100k projected annual saving | Nine weeks, not nine quarters |
| Market tailwind | UK private admissions hit 953,000 in 2025, a fourth consecutive record year, roughly 70% insured / 30% self-pay | Self-pay patients expect app-grade UX |
Note what the winning interventions have in common: none of them are clever. Two-way reminders and self-serve rescheduling are boring features, and they are boring features that require both apps to exist, because a patient rescheduling on one side is only useful if a clinician’s diary moves on the other side instantly.
4. Compliance Without the Panic
Healthcare compliance has a reputation for being the thing that kills projects. In our experience it kills projects that treat it as a phase near the end. Handled as an architectural constraint from week one, it is closer to a checklist than a crisis.
If you intend to sell into or work alongside the NHS, the Digital Technology Assessment Criteria (DTAC) is the framework buyers will hold you to. NHS England rolled out a revised form in February 2026 with roughly 25% fewer questions, de-duplicated against the Data Security and Protection Toolkit, and the previous version was retired from 6 April 2026. Five sections, and every one of them maps to something you either design in early or retrofit expensively.
| DTAC Section | What It Means For The Build |
|---|---|
| Clinical safety | DCB0129/0160 hazard logging, a named clinical safety officer, safety cases written alongside features |
| Data protection | UK GDPR lawful basis, DPIA, data minimisation, retention schedules, and a real answer on sub-processors |
| Technical security | Encryption in transit and at rest, penetration testing, secure SDLC, credential and secrets hygiene |
| Interoperability | FHIR UK Core alignment, documented APIs, no proprietary data prison |
| Usability and accessibility | WCAG 2.2 AA, tested with real patients including the ones who are not 28 and fluent in app |
The other question worth settling early: is this a medical device? Broadly, an app that books, reminds, messages and displays records is administrative software. The moment it starts triaging symptoms, scoring risk or telling a clinician what to do next, it moves towards being a regulated software medical device in the UK, with MHRA classification and a UKCA route attached. That is not a reason to avoid clinical intelligence. It is a reason to know which side of the line each feature sits on before it enters a sprint, and to take regulatory advice on the specific feature set rather than on the general vibe of the product.
5. What It Costs and How Long It Takes
Every timeline below assumes the dual-app shape described here: two front ends, one spine, real integrations. It excludes the cost of your existing systems being hostile, which is unfortunately not a joke. A practice management vendor with no API can add months on its own.
| Scope | What You Get | Typical Timeline |
|---|---|---|
| Pilot / single site | Booking, reminders, secure messaging, clinician worklist, one integration | 10–14 weeks |
| Production dual app | Full patient and clinician apps, results release, referrals, payments, audit, DTAC pack | 5–8 months |
| Multi-site / group | Cross-site identity, rota and capacity, reporting, role hierarchies, SSO | 8–14 months |
Our detailed breakdown of what actually drives software budgets lives in How Much Does It Cost to Build a Web App in 2026, and the logic holds here with one healthcare-specific addition: compliance and integration work is typically 20–30% of the build, and it is not optional. A quote that omits it is not cheaper, it is incomplete.
6. Five Ways These Builds Quietly Fail
One app for two audiences. A single app with a “clinician mode” toggle. It always ends with consultants pinching to zoom on a worklist designed for a patient’s thumb.
The integration left until last. The lab feed, the PACS link, the billing hook. These are discovery work, not implementation work, and they belong in week two.
Clinicians consulted at UAT. If a consultant sees the product for the first time in acceptance testing, you are not gathering feedback, you are gathering objections. Two clinicians in the room from sprint one changes the entire product.
Results released without a human gate. Automatically pushing every result straight to the patient app is a great feature right up until an oncology result lands at 11pm on a Friday. Build the hold-and-release workflow first, not as a patch.
No plan for the patients who will not download it. A meaningful share of any clinic’s list will never install an app. SMS and email fallbacks are not a nice-to-have, they are how you avoid running a two-tier service.
7. How We Approach It
Our team in London builds these systems the same way each time: spine first, clinician app second, patient app third. It feels backwards to clients who arrived with a patient app in mind, and it is precisely why the patient app ships in a state worth launching. You cannot build a calm patient experience on top of a clinical workflow that does not exist yet.
On the delivery side, we lean heavily on AI-assisted engineering for the parts of healthcare software that are enormous and unglamorous: FHIR resource mapping, integration adapters, test coverage across permission matrices, audit instrumentation. It is genuinely faster, and we have written honestly about where it helps and where it does not in Lessons from Building Production Apps with Claude Code. The clinical safety judgement, the release workflow, the decision about what a patient sees at 11pm on a Friday, that stays with people in a room, with clinicians present.
Connecting a clinic, a hospital and a hundred consultants?
Our London team builds dual-app healthcare platforms spine-first, with clinical safety, UK GDPR and DTAC designed in from the first commit rather than bolted on the week before procurement.
Talk To Our Team →