Healthcare app development,
clinically grounded.
Magora is a London healthcare app development company. Patient apps, clinician mobile tools and remote-monitoring apps for iOS and Android — with the FHIR, HL7 and GP Connect integration and the evidence pack an NHS buyer will ask for.
Healthcare apps
we ship.
Six products in this sector already, and the same pattern in each: the clinical workflow is the hard part, not the app. Building clinical systems, integrations or back-office software rather than an app? See healthcare software development.
Patient apps for iOS and Android
Appointments, medication reminders, results, care plans and messaging — designed for people who are unwell, not for people testing an app.
Clinician mobile tools
Triage, caseload, referrals, notes and handover. Built around what a working day actually looks like, with the number of taps counted.
FHIR, HL7 and GP Connect
Getting data in and out of the systems already in place — EMIS, SystmOne, trust PAS — is where these projects live or die.
Remote monitoring and wearables
Wearables, Apple HealthKit, Google Health Connect and home devices feeding an app and a clinical dashboard, with alerting rules a clinician can tune rather than a black box.
Reporting and analytics
Service dashboards, outcome tracking and the audit trail that has to exist before anyone will sign anything off.
The compliance pack
DTAC responses, DCB0129 hazard logs, DSPT alignment and clinical safety documentation produced alongside the build, not scrambled together afterwards.
Clinical safety is not
a phase at the end.
Three things that decide whether a healthcare build reaches patients, all of which are cheaper to settle in week one than in month six.
Is it a medical device?
Software that supports a diagnostic or treatment decision can fall under UK MDR and need UKCA marking — the boundary turns on intended purpose and on how the output is worded. We raise it in the first fortnight, because a product that crosses that line quietly is a product that stops at procurement.
The evidence a buyer will ask for
DTAC, DCB0129 and a clinical safety officer's sign-off are not paperwork you bolt on. They shape the architecture: audit logging, data residency, role separation, failure behaviour. Built in from the start they cost little; retro-fitted they cost a re-write.
Integration is the project
The app is rarely the hard part. Reading and writing a record in the systems a trust or practice already runs — and proving you did it safely — is where the weeks go. We scope that first and price it honestly.
Telemedicine and
remote monitoring.
Two ways care leaves the clinic: apps patients use on their own phone, and dashboards clinicians work from. Both raise the medical-device question and the escalation rules early, so we settle them first.
Video consultation and follow-up
Booking, secure video, in-app messaging, questionnaires before the appointment and notes and outcomes captured for the clinical record. Designed for patients on a poor connection and clinicians with ten minutes.
Wearables and home devices
Readings from Apple HealthKit, Google Health Connect, Bluetooth wearables and home monitoring kit feed a clinical dashboard. Alert thresholds are rules a clinician can see and tune, not a black box.
Alerts, escalation and failure
Who is told when a reading is out of range, what happens when a device goes quiet, and who owns the response. These go into the hazard log in the first fortnight, because monitoring that diagnoses or triggers treatment can make an app a medical device.
Wellbeing app
or medical device?
A short test, not regulatory advice: your regulatory advisor or the MHRA makes the call. What decides it is what the app claims to do, not how it is built.
Tracks and informs
Mood, sleep and habit logs, fitness tracking, appointment booking, a patient record that replaces a paper file. MHRA says monitoring general fitness, health and wellbeing is not usually considered a medical purpose.
Diagnoses, scores or advises
Symptom checkers that rank conditions, apps that assess skin from photos, tools that work out a dose or a risk score from a patient’s data. These can need UKCA marking.
Intended purpose
The same app can land on either side depending on what it claims. We write the intended-purpose statement with you in week one. See four worked examples in the table on our healthcare software page, and our SaMD guide.
From idea to something
a clinician will use.
The same process we run on every engagement, with the healthcare-specific questions asked early rather than discovered late.
Clinical workflow research
1 – 2 weeksWe sit with the people who will use it — clinician, patient, administrator, carer — and map the day as it is, not as the org chart describes it. Every healthcare product we have shipped changed shape after this.
Regulatory and safety scoping
1 weekIntended purpose written down, the medical-device question answered, DTAC and DCB0129 obligations identified, data flows and residency agreed. This is the fortnight that decides the next six months.
Free working prototype
5 – 10 daysA running prototype of the core journey, built from your brief, before any paid engagement. Yours to keep either way — it is the fastest way to find out whether we understood you.
Integration spike
1 – 3 weeksBefore the build is priced, we prove the hard integration end to end against a real endpoint or sandbox — FHIR, HL7 v2, GP Connect, a trust PAS. An estimate that assumes the integration works is not an estimate.
Build, in two-week slices
8 – 24 weeksWeekly demos, a working build at the end of every sprint, and the safety documentation written as the features land rather than reconstructed from memory at the end.
Handover and support
OngoingSource, designs and IP transfer to you on payment. We stay on for patches, framework upgrades and feature work for as long as it is useful, and hand to your team when they are ready.
Technologies
we work on.
The actual stack on healthcare app engagements — native and cross-platform mobile, interoperable, auditable, and boring where boring is a virtue.
- Swift · SwiftUI
- Kotlin · Compose
- React Native
- Flutter
- TypeScript · React
- Next.js
- Vue
- Accessible by default
- Node.js · NestJS
- Python · FastAPI
- PHP · Laravel
- .NET
- HL7 FHIR R4
- HL7 v2
- GP Connect
- SNOMED CT · dm+d
- PostgreSQL
- Redis
- Encrypted at rest
- UK data residency
- Apple HealthKit
- Google Health Connect
- BLE wearables
- Home monitoring kit
- DTAC responses
- DCB0129 hazard log
- DSPT alignment
- UK GDPR · DPIA
- Triage support
- Document summarisation
- Coding assistance
- Always human-in-the-loop
Healthcare apps
we've shipped.
Six from the wider portfolio — real products, not mock-ups. Building for a pharma company? See pharma app development.
InnovoCare
Care software built with Magora — the full story, including what changed along the way.
Doctor OTC
Connecting patients with over-the-counter guidance, designed around how people actually search for help.
Medical Tourism App
Treatment abroad, from enquiry to aftercare, across providers, languages and currencies.
Healthy diet app
Nutrition tracking that people keep using past week two — the only metric that matters in this category.
BodySync
AI-drafted treatment plans for clinicians, restricted to peer-reviewed sources and built for HIPAA and GDPR. The MVP is in use in UK clinics.
Focalyx
A web application that tracks prostate cancer focal-treatment outcomes across partner clinics, with patient data and AI analysis results in one place.
The honest
questions.
Pavel co-founded Magora in 2010 and runs the company. He reviews how the teams and delivery processes described on this page are set up and run.
Pick a slot below
and let's talk.
No commitment, no charge. We'll review your project, scope the next step, and tell you the realistic price + timeline. Free working prototype + senior PO analysis before any paid engagement.
Healthcare app
on the brief?
30-minute call with a senior architect who has shipped healthcare products before. We'll go through the integration, the medical-device question and the evidence an NHS buyer will ask you for — and tell you what we would actually build if it were us.