Patient apps, clinician tools, remote monitoring and the integration work nobody warns you about — FHIR, HL7, GP Connect. Built with the evidence pack an NHS buyer will ask for, because they always ask.
Healthcare software we ship
Four products in this sector already, and the same pattern in each: the clinical workflow is the hard part, not the app.
Patient-facing apps
Appointments, medication reminders, results, care plans and messaging — designed for people who are unwell, not for people testing an app.
Clinitian 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
Wearables and home devices into a clinical dashboard, with alerting rules a clinician can tune rather than a black box.
Reporting & 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.
How we build successful healthcare startups.
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 the 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 in 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.
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
We 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. Shadowing, Personas, Pathway map
Regulatory and Safety Scoping
Intended 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. Intended purpose, UK MDR check, Hazard log
Free Working Prototype
A 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. Clickable, No commitment, Yours to keep
Integration Spike
Before 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. FHIR R4, GP Connect, Sandbox proof
Build, in Two-week Spike
Weekly 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. Weekly demos, Living hazard log, Audit trail
Handover and Support
Source, 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. Full IP transfer, SLA options, Clean handover