Industry
Software engineering for Healthcare
Clinical software where the details are the whole job, patient safety, information governance and interoperability with systems that were never designed to talk to each other.
Why the domain matters
Healthcare software sits closer to patient harm than almost anything else we build. A dropped message between a monitoring device and a clinician, a triage model that quietly drifts, a records integration that maps the wrong SNOMED code: these are not bugs you ship and patch on Friday. They are clinical-safety events. That reality shapes everything about how healthcare software should be designed, tested, released and operated, and it is the single biggest reason this sector moves more slowly than consumer software. The slowness is not incompetence. It is the cost of not hurting people.
We build for three broad audiences and the constraints differ for each. Providers and clinics (NHS trusts, GP practices, private hospitals), care about integration with entrenched systems, information governance and fitting into clinical workflows that already exist. Digital-health and health-tech companies care about DTAC assessment, clinical safety cases and getting through procurement without a two-year cycle. Med-tech companies building software as a medical device care about MHRA and UKCA marking, and increasingly the EU MDR. Most projects touch more than one of these, and the person who only knows the code but not the regulatory frame will build something that cannot be deployed.
Our position is blunt: anyone promising fast, cheap healthcare software without clinical-safety and information-governance rigour is selling you a liability. The hard part is rarely the feature. It is the clinical risk management, the DSPT and IG paperwork, and above all the interoperability: persuading Epic, Cerner, EMIS, SystmOne or the NHS Spine to exchange data reliably, in the right coding standard, without breaking when the upstream system changes. We do this work because we understand the domain, not because we can move a ticket to done.
The challenges in healthcare
Patient data is the most sensitive data there is
Health records are special-category data under UK GDPR and the Data Protection Act 2018, and equivalent PHI rules apply under HIPAA if you touch US patients. That raises the bar on lawful basis, minimisation, retention, access control and breach handling far above ordinary personal data. A design that would pass for an e-commerce app is negligent here.
Clinical safety is a regulated discipline, not a checkbox
Health IT deployed in the NHS must meet DCB0129 (for manufacturers) and DCB0160 (for deploying organisations). That means a named Clinical Safety Officer, a hazard log, and a clinical safety case maintained across the product’s life. Retrofitting this after build is expensive and often forces rework; it belongs in the design from day one.
Interoperability with legacy systems is the real battle
The EPR estate is decades deep. HL7 v2 messages with local quirks, FHIR endpoints at varying maturity, SNOMED CT and dm+d coding, DICOM for imaging: each integration is its own negotiation. Entrenched systems change on their own schedule, and your integration breaks when they do. This is usually where projects overrun.
Procurement and assurance gate everything
Even excellent software stalls at DTAC, DSPT, IG reviews and framework procurement. Digital-health founders routinely underestimate how long clinical, information-governance and cyber assurance takes, and build features while the thing that actually blocks deployment goes unaddressed until it is a crisis.
Software can be a regulated medical device
If your software diagnoses, screens, calculates a dose or drives a treatment decision, it may be Software as a Medical Device, needing UKCA marking under MHRA oversight and, for the EU, MDR conformity. Misjudging classification is a serious regulatory risk, build it as a device from the start or scope carefully to stay outside the definition, deliberately, not by accident.
Workflow fit decides adoption
Clinicians work under time pressure with limited tolerance for extra clicks. Software that ignores existing workflow, adds friction or duplicates data entry gets quietly abandoned regardless of how clever it is. CQC-regulated providers also need software that supports, not undermines, safe and well-led care. Adoption is a design constraint, not an afterthought.
What we build for healthcare
The systems this sector most often needs, built by engineers who understand the domain, not just the code.
Patient portals and NHS login integration
Secure portals for appointments, records access, messaging and results, with NHS login for identity verification where appropriate. Built around information-governance requirements, accessible to WCAG standards, and designed so patients with low digital confidence can still use them.
Telemedicine and remote consultation
Video consultation, asynchronous messaging and remote assessment tools with clinical-grade reliability, audit trails and safe fallback when a call drops. Integrated into the clinical record rather than bolted on beside it, so consultations do not vanish from the patient’s history.
Clinical workflow and EPR-adjacent tooling
Task management, referral tracking, e-forms and decision-support that sit alongside the EPR and write back through FHIR or HL7 where the platform allows. We design these to reduce clicks, not add them, and to keep the record as the single source of truth.
Remote monitoring and connected devices
Platforms that ingest data from home monitoring kit and wearables, apply alerting thresholds with clinical oversight, and surface trends to clinicians without drowning them in noise. Device data pipelines are built with the reliability and traceability that safety cases demand.
Practice and health-data platforms
Practice-management systems, population-health dashboards and research-grade data platforms with proper de-identification, role-based access and lineage. We treat data governance as a first-class feature, not a compliance tax added at the end.
AI triage and decision-support with human oversight
Triage, risk-stratification and documentation-assist models designed with a clinician in the loop, transparent reasoning where possible, monitoring for drift, and a clear boundary around what the model may and may not decide. We are honest about where a model belongs in the pathway and where it does not.
Where we help
GP practice patient app with EMIS/SystmOne integration
A patient-facing app for booking, prescriptions and record access that reads and writes to the practice clinical system via approved integration routes, with NHS login and full information-governance sign-off. The integration and assurance work, not the app UI, is the bulk of the effort.
Remote monitoring for a long-term-condition cohort
Home blood-pressure or glucose readings flowing into a monitoring platform, thresholds triggering review by a clinical team, and escalation logged in the record. Built with alert fatigue and safe-failure explicitly designed for, and a clinical safety case behind the alerting logic.
Imaging workflow with DICOM and reporting
A tool that pulls studies via DICOM, presents them for structured reporting, and returns results to the ordering system (coded in SNOMED CT), so the imaging result lands correctly in the patient record rather than as a loose PDF.
AI documentation assistant for consultations
An ambient or dictation-based assistant that drafts clinical notes for the clinician to review and sign, never to auto-file. Designed so the human remains accountable, with the model’s output clearly marked as a draft and every edit auditable.
How we build for healthcare
We start with clinical risk, not the feature list. Before writing meaningful code we work with a Clinical Safety Officer to open a hazard log and sketch the clinical safety case, because the hazards you find early are the ones that are cheap to design out. This is DCB0129 and DCB0160 thinking baked into the build rather than bolted on for the audit. If a project has no route to a named CSO, we say so plainly rather than pretending the paperwork will sort itself out later.
We build interoperability first and treat it as the highest-risk part of the plan. We prove the HL7, FHIR or DICOM integration against a real or realistic endpoint early, because that is where the surprises live, and we design for the upstream system to change under us. We prefer standards-based integration over brittle screen-scraping or private APIs, and we are candid when a target system simply does not offer a clean route, sometimes the honest answer is that a particular integration is not safely achievable within the budget.
And we operate what we build. Healthcare software fails in ways that matter at three in the morning, so we design for observability, safe degradation and auditability from the outset, and we stay involved after go-live. Senior engineers who understand the clinical context handle incidents, not a handoff to a first-line team who have never seen a hazard log.
The regulatory landscape
Healthcare software answers to three overlapping regimes, and you cannot ignore any of them. Clinical safety comes first: DCB0129 obliges manufacturers to manage clinical risk and DCB0160 obliges deploying organisations to do the same, each demanding a Clinical Safety Officer, a hazard log and a maintained safety case. These are mandatory information standards for NHS-connected systems, not optional best practice.
Data protection sits alongside it. Health data is special-category data under UK GDPR and the Data Protection Act 2018, so you need a defensible lawful basis, a completed DPIA, data-minimisation by design and clear retention. NHS deployment adds the Data Security and Protection Toolkit (DSPT) and formal information-governance review, and the DTAC assessment bundles clinical safety, data protection, technical security, interoperability and usability into one gate that digital-health products must pass. If you serve US patients, HIPAA imposes its own parallel obligations on protected health information.
Then there is medical-device regulation. If your software meets the definition of a medical device (and diagnostic, screening or dose-calculating software often does), it needs UKCA marking under MHRA oversight, with the EU MDR governing conformity for the European market. Classification drives everything that follows, so it must be decided deliberately and early. Providers also operate under CQC regulation, and software that touches safe or well-led care needs to support their evidence, not complicate it.
Systems and standards we integrate with
The interoperability layer is where healthcare projects are won or lost. We work with HL7 v2 for the large installed base of messaging, FHIR for modern API-based exchange, SNOMED CT and dm+d for clinical and medicines coding, and DICOM for imaging. Getting the coding right matters as much as moving the data: a value in the wrong terminology is worse than no value, because it looks trustworthy and is not.
On the systems side we integrate with the major EPR and EHR platforms (Epic, Cerner (Oracle Health), EMIS Web and SystmOne), through their supported integration routes, and with the NHS Spine and national services including NHS login and, where relevant, PDS and e-Referrals. Each of these has its own onboarding, assurance and technical constraints, and each moves at its own pace; we plan for that rather than assuming a clean API on day one.
We are realistic about what these systems will and will not allow. Some expose good FHIR endpoints; some offer limited write-back or none; some require a partner agreement before you can touch anything. We map the achievable integration honestly at the start so the roadmap reflects what the ecosystem actually permits, not what the pitch deck assumed.
Security and data protection
In healthcare, protecting patient data is non-negotiable and it is the part of the system we design first, not last. Encryption in transit and at rest is a baseline, not a feature. Access is role-based and least-privilege, so a receptionist, a clinician and an administrator each see only what their role requires, and every access to a record is authenticated against a verified identity.
Audit trails are as important as the data itself. Every read and write to a patient record must be attributable, timestamped and tamper-evident, because in a clinical or medico-legal dispute the audit log is the evidence. We build immutable, queryable audit from the ground up rather than reconstructing it from application logs after the fact, and we design retention and deletion to match both the DSPT and the organisation’s information-governance policy.
Beyond the record, we harden the whole surface: secrets management, dependency and vulnerability monitoring, secure development practices aligned to the DSPT and DTAC technical-security expectations, and a defined incident-response path. Because we operate what we build, the people who wrote the security model are the ones who respond when something looks wrong, which is exactly when domain knowledge counts most.
What changes
Deployable, not just demoable
Software that clears DTAC, DSPT and information-governance review because clinical safety and data protection were designed in, not a prototype that stalls at the assurance gate the founder forgot about.
Integrations that hold
HL7, FHIR, DICOM and EPR connections built against real endpoints and designed to survive the upstream system changing, so the data keeps flowing and lands in the right coding standard.
A defensible safety and audit position
A maintained hazard log, a clinical safety case and tamper-evident audit trails, so when a clinician, a regulator or a court asks how the system behaved, you have an answer.
What we build for healthcare
From a first platform to modernising what you already run. The disciplines this sector draws on most.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Building something for healthcare?
Tell us the problem and the constraints you are working under. A senior engineer will give you a straight view on what it would take, and say so plainly if we are not the right team for it.
Technologies we work in
Chosen per problem, not per fashion. A selection of the stack we most often reach for.
Why teams in healthcare choose us
We understand the regulatory frame, not just the code
We build with DCB0129/0160, UK GDPR, DTAC, DSPT and the SaMD rules in view from the start, so the software is designed to be deployable in a real NHS or regulated setting, not reworked after it fails assurance.
Senior engineers, no handoffs
The people designing the interoperability and the safety model are senior engineers who stay on the project. Healthcare integration and clinical risk are not work you delegate to whoever is cheapest and hope for the best.
We operate what we build
We stay involved after go-live because healthcare software fails at the worst times and needs people who understand the clinical context to respond. Observability, safe degradation and audit are designed in, not discovered during an incident.
Honest about trade-offs and limits
If an integration is not safely achievable in the budget, if a model does not belong in a decision, or if the timeline the assurance process demands is longer than you hoped, we tell you. We will not ship fabricated confidence into a setting where people can be harmed.
Related sectors
Adjacent sectors we also know.
Common questions
Do we need a Clinical Safety Officer, and can you provide one?
If your software is health IT deployed in the NHS, yes. DCB0129 and DCB0160 require a named Clinical Safety Officer and a maintained clinical safety case. We build to those standards and structure the work around the hazard log from the start. We work alongside your CSO, and where you do not have one we can help you establish that role and the safety-case process rather than pretending the requirement does not apply.
Will my software count as a medical device?
It depends on what it does. Software that diagnoses, screens, calculates a dose or drives a treatment decision often meets the definition of Software as a Medical Device, which brings MHRA oversight and UKCA marking in the UK, and MDR conformity for the EU market. Software that only stores, displays or communicates information usually does not. We assess classification deliberately and early, because getting it wrong is a serious regulatory risk either way.
How do you integrate with EPR systems like EMIS, SystmOne, Epic or Cerner?
Through each platform’s supported integration routes, using FHIR and HL7 v2 where available and the correct clinical coding. SNOMED CT, dm+d, DICOM for imaging. We prove the integration against a real or realistic endpoint early because that is the highest-risk part of the work, and we are honest when a target system offers only limited write-back or requires a partner agreement before any data can move.
Why is healthcare software slower and more expensive than a normal web app?
Because the cost of getting it wrong is patient harm. Clinical risk management, information-governance and DSPT paperwork, DTAC assessment and interoperability with legacy NHS systems all take real time, and interoperability in particular is usually the hardest and least predictable part. Anyone quoting you fast and cheap healthcare software without that rigour is either misunderstanding the domain or ignoring it, and both are dangerous.
Can you build AI triage or decision-support safely?
Within clear limits. We build AI triage, risk-stratification and documentation-assist with a clinician in the loop, monitoring for model drift, transparent reasoning where possible, and a firm boundary around what the model may decide versus what a human must. Where a model does not belong in a decision, we say so. We will not put an unsupervised model on a clinical pathway to hit a demo date.
Building for healthcare?
Tell us what the system has to do and what it cannot get wrong. A senior engineer reads it, and if healthcare is not a domain we know well enough to be useful in, we will say so rather than learn it on your budget.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.