Healthcare software,
built to pass assurance.
Custom healthcare software for UK providers and healthtech teams — clinical systems, patient platforms and FHIR integration, with DTAC and DCB0129 evidence built in.
Custom healthcare software
development services.
Magora is a London healthcare software development company. We design and build custom clinical systems, patient platforms, telehealth and remote-monitoring tools, and the FHIR, HL7 and GP Connect integrations that connect them to the records already in place — with the DTAC, DCB0129 and UK GDPR evidence an NHS or private buyer will ask for produced alongside the code.
Clinical and care-management systems
Caseload, referrals, triage, notes, handover and scheduling for clinics, providers and care teams — built around a working day with the number of taps counted, and an audit trail on every record.
Patient portals and engagement
Appointments, results, care plans, questionnaires and secure messaging, designed for people who are unwell rather than people testing software. Accessible by default.
Telehealth and remote monitoring
Video consultation, wearables and home devices feeding a clinical dashboard, with alerting rules a clinician can tune rather than a black box.
FHIR, HL7 and GP Connect integration
Reading and writing records in the systems already in place — EMIS, SystmOne, a trust PAS — through HL7 FHIR R4, HL7 v2 and GP Connect, with SNOMED CT and dm+d coding.
Health data, reporting and AI
Outcome tracking, service dashboards, data exports for research, and AI where it earns it — summarisation, triage support, analysis — always with a human in the loop.
Medical device and SaMD support
Intended purpose written down in week one, the UK MDR question answered with your advisor, and the software-lifecycle evidence a regulated product needs produced as the features land.
Healthcare organisations
we work with.
The same discipline, different pressures: a startup needs to survive procurement, a provider needs adoption, a life-science team needs data it can trust.
Clinics and healthcare providers
Private clinics, diagnostic services and provider groups replacing spreadsheets and disconnected tools with one auditable system.
Healthtech and digital health startups
Founders who need an MVP that will survive an NHS buyer's first questions — DTAC, clinical safety, data residency — without a rewrite later.
Pharma and life-science teams
Field and commercial tools for pharmaceutical companies — as in Pharm Card, built for the sales branch of an international pharma group.
Medical technology companies
Data platforms around a clinical product, like the web application we built with Focalyx to track prostate cancer focal-treatment outcomes across partner clinics.
Care, wellbeing and mental health
Home care, wellbeing and mental-health services where privacy, safeguarding and accessibility come before features.
Healthcare administration
Cost modelling, operational reporting and back-office tools — the category of InnovoCare, a calculator of the true cost of care pathways.
Clinical safety is not
a phase at the end.
Three questions decide whether healthcare software reaches patients. All of them 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 wording, so we raise it in the first fortnight — a product that crosses the line quietly is a product that stops at procurement.
DTAC, DCB0129 and DSPT
The evidence a buyer asks for shapes the architecture: audit logging, role separation, data residency, failure behaviour. We write the DTAC technical responses and keep the DCB0129 hazard log live through the build, so the answers are true on the day you submit them.
UK GDPR and patient data
Patient data stays yours and in the UK or EU by default. We act as processor under your controllership, with a DPIA, data-flow documentation and least-privilege access agreed before a single record moves.
From clinical workflow
to live software.
The same process we run on every engagement, with the healthcare 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.
Regulatory and safety scoping
1 weekIntended purpose written down, the medical-device question answered with your advisor, DTAC and DCB0129 obligations identified, data flows and residency agreed.
Free working prototype
5 – 10 daysA running prototype of the core journey before any paid engagement — the fastest way to find out whether we understood you.
Integration spike
1 – 3 weeksThe hardest integration proven end to end against a real endpoint or sandbox — FHIR, HL7 v2, GP Connect, a trust PAS — before the build is priced.
Build in two-week slices
8 – 24 weeksWeekly demos, a working build at the end of every sprint, and the safety documentation written as features land rather than reconstructed at the end.
Assurance, handover and support
OngoingDTAC responses and technical evidence handed to your team, full IP transfer on payment, then SLAs, patches and feature work for as long as it is useful.
Healthcare software
development cost.
2026 prices in GBP. Every engagement starts with a free working prototype and an NDA on day one, and ownership of source, designs and IP transfers to you on payment. Integration depth and assurance scope are what move a healthcare estimate — discovery is where both are priced properly.
Free working prototype
A running prototype of your core clinical or patient journey, built from your brief in 5–10 working days. Yours to keep, no commitment.
Product Discovery
Two weeks with a senior Product Owner and Solution Architect: workflow research, intended purpose, integration map, architecture, estimate and roadmap.
Startup MVP
A production-grade MVP for a funded healthtech startup — one core pathway, built to be assessed, typically 6–8 weeks.
Full production build
A full custom web, mobile or platform build by a senior in-house team, with the assurance pack written alongside the code.
Bespoke enterprise platform
Multi-role, audit-logged, integration-heavy platforms for providers and life-science organisations.
Support and evolution
SLAs, security patching, framework upgrades and iterative feature work after launch — for as long as it is useful.
The healthcare
engineering stack.
Interoperable, auditable and boring where boring is a virtue.
- HL7 FHIR R4
- HL7 v2
- GP Connect
- SNOMED CT · dm+d
- REST & webhooks
- Node.js · NestJS
- Python · FastAPI
- PHP · Laravel
- .NET
- TypeScript · React
- Next.js · Vue
- Swift · Kotlin
- React Native · Flutter
- Accessible by default
- PostgreSQL
- Encrypted at rest
- UK / EU data residency
- Audit logging
- Role-based access
- Apple HealthKit
- Google Health Connect
- BLE wearables
- Home monitoring kit
- DTAC responses
- DCB0129 hazard log
- DSPT alignment
- UK GDPR · DPIA
- Human-in-the-loop AI
What clients
say.
Independently verified on Clutch — 4.9 out of 5 across 60+ reviews, from clients including AstraZeneca, Danone, Unilever, Toyota and Cisco.
Rather than choose the flattering ones, we point at all of them. Every review on our Clutch profile is verified with the client, including the projects that ran harder than expected.
Healthcare and life-science
software we've shipped.
Four from the wider portfolio — real products, not mock-ups. More in healthcare and fitness projects.
Focalyx
A web application for clinics tracking patient data, AI analysis results and prostate cancer focal-treatment outcomes.
See case study → Pharma · EnterprisePharm Card
Bespoke tablet software for a pharma sales branch, replacing hundreds of spreadsheets, with offline working and sync.
See case study → Healthcare · OperationsInnovoCare
A web calculator for the true cost of healthcare services across the whole pathway, from diagnosis to recovery.
See case study → AI · VulnerabilityEmpath AI
Vocal-biomarker SaaS that flags signs of caller vulnerability — anxiety, depression, cognitive decline — in real time.
See case study →Healthcare software
questions, answered.
It depends on scope and, in healthcare, on two things that make the same product cost more than in other sectors: how much integration it needs and how much assurance evidence a buyer will ask for. Our 2026 pricing (GBP): a free working prototype first, Product Discovery from £3,000, a Startup MVP from £10,000, a full production build from £30,000, and multi-role, integration-heavy enterprise platforms from £80,000. Support retainers run £3,500–£9,000 a month.
A discovery ends with a written scope, architecture and estimate that you own and can take elsewhere. For a quick range, try the app cost calculator or our UK software development pricing guide.
A working prototype of the core journey lands in 5–10 working days. A production build typically runs 8–24 weeks from kickoff, and healthcare sits at the longer end whenever a real integration is involved. That is why we prove the hardest integration in a spike before we quote the build, rather than discovering it in month three.
Possibly, and it is the first question worth settling. Under UK MDR, software intended to support a diagnostic or treatment decision can be a medical device (Software as a Medical Device, SaMD) that needs UKCA marking; administrative, wellbeing and information products usually are not. The line turns on intended purpose and on how results are worded to the user.
Magora is not your regulatory advisor. What we do is raise it in the first fortnight, write the intended-purpose statement with you, and build to whichever answer your advisor gives. More on this on our healthcare and SaMD development page.
Yes, as the supplier side of it. We produce the technical responses a DTAC (Digital Technology Assessment Criteria) assessment asks for, maintain the DCB0129 hazard log through the build, and align hosting and access controls with the Data Security and Protection Toolkit. The system is structured so that the answers about audit logging, data residency and role separation are true rather than aspirational.
DCB0129 also requires a named Clinical Safety Officer — a clinical role that sits with you or with a specialist we work alongside. The deploying organisation then carries its own obligations under DCB0160.
The technical routes are well travelled and we build to them: HL7 FHIR R4, HL7 v2, GP Connect, and SNOMED CT and dm+d for clinical coding. What decides the timeline is usually access rather than engineering — partner agreements, sandbox access and assurance sign-off from the system supplier or the trust. We scope that honestly at the start, including the parts that are not in our gift.
For integration-heavy work outside healthcare, see our API integration services.
You own both. Source code, designs and IP transfer to you on payment, and the repository is yours from the first commit. Patient data stays yours throughout and in the UK or EU by default; we work as processor under your controllership, with a DPIA and data-flow documentation under UK GDPR. We sign an NDA on day one.
A healthcare app is usually one patient- or clinician-facing product on a phone or tablet. Healthcare software is the wider system around it: the clinical back office, the integrations with records systems, the reporting and the audit trail that let a provider actually adopt it. Most of our healthcare projects are both. If you are building a patient or clinician app first, see healthcare app development.
Where it earns its place — triage support, document summarisation, coding assistance, analysis of uploaded data — and always with a human in the loop. AI that influences a clinical decision is exactly the case that can turn a product into a medical device, so we settle that question before the model is chosen, not after. See our AI and ML development work, including Empath AI.
Healthcare software
on the brief?
30-minute call with a senior architect who has shipped healthcare products. 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.