Clinical safety written at the end
The hazard log and safety case are reconstructed after the build, so risks surface late and every mitigation turns into rework.
Healthcare software development · UK
Healthcare Software Development Company in the UK
We build software for UK clinics, care providers and health-tech companies — together with the assurance evidence that has to travel with it: DSPT inputs, clinical safety documentation for DCB0129 and DCB0160, accessibility testing and UK hosting. We build and document to your requirements; sign-off stays with your organisation.
- Clinical safety evidence produced as we build
- Synthetic test data by default
- Hosting in UK regions when you need it
Choosing a health-tech partner
Why health software stalls before go-live.
Most of the delays have little to do with code. They come from assurance work left too late, and integration assumptions nobody checked.
What a careful partner does differently
- Assurance planned in discovery and produced every sprint
- Integration access confirmed before it is designed around
- Synthetic data for development and testing
- Your CSO, DPO and IG lead involved from the start
Claims that do not survive questions
A supplier promises the product is “NHS compliant”. No single badge by that name exists — buyers ask for specific evidence, and it is not there.
Integrations assumed, not confirmed
The plan depends on a clinical system’s API, then it turns out access needs a partner agreement, an assurance process, or is simply not offered.
The regulatory question, asked late
A feature that suggests a diagnosis or a dose can bring medical device regulation with it — discovered after launch rather than during design.
Live patient records in test
Copies of real records in development and test environments: a UK GDPR problem, and a question your DSPT submission will not answer well.
Journeys that exclude patients
Small text, complex forms and flows that fail with a screen reader shut out older and disabled patients — often the people who most need the service.
Who it is for
Health and care organisations we build for.
Different organisations carry different assurance duties. We ask early which ones are yours.
Booking, portals and payments
Patient booking, pre-appointment questionnaires, secure messaging and payments that fit around your practice management system.
Tools for care teams
Visit scheduling, care notes, handovers and family updates, designed for staff using a phone between visits.
A first product buyers can assess
A first release built with the clinical safety, data protection and accessibility evidence that NHS and private buyers will ask for.
New modules and integrations
Extra engineering capacity for new features, FHIR integrations and the assurance updates each release needs.
Ordering, results and prescriptions
Online ordering, test booking, results delivery and prescription workflows, with the right checks at each step.
A second team for a new service
A new product line or market built alongside your core team, working to your quality management and safety processes.
Assurance
DSPT and clinical safety: what we build and document.
Organisations with access to NHS patient data and systems complete the Data Security and Protection Toolkit (DSPT), a self-assessment of how they protect that data. It is your organisation’s submission, not ours to make, but much of its evidence is technical: how access is controlled, how data is encrypted and backed up, how incidents are detected, and where data flows. We document all of that as we build, in a form your IG lead can use directly.
Clinical safety sits under two standards. DCB0129 applies to the manufacturer of a health IT system — usually the health-tech company, or the provider commissioning software for its own use — and DCB0160 applies to the organisation deploying it. Both need a Clinical Safety Officer: a registered clinician who owns the hazard log and signs the safety case. That person sits on your side. We work to their clinical risk management plan, build the mitigations they specify, and give them design decisions, test evidence and release notes mapped to each hazard.
We are software engineers, not a compliance consultancy, and we do not give regulatory or legal advice. We build and document to your requirements; sign-off stays with your organisation.
- Data-flow diagrams and control descriptions for your DSPT and DPIA
- Hazard log inputs from every design decision
- Test evidence mapped to clinical safety mitigations
- Release notes that describe clinical impact, not just code
Regulation
The medical device question, asked at the start.
Software can be a medical device in the UK when its intended purpose is medical — to diagnose, prevent, monitor or treat a condition, for example. A booking app or a staff rota usually is not; a symptom checker that suggests a likely condition, or a tool that calculates a dose, may well be. What decides it is the purpose you describe, not the technology underneath.
If it is a device, the MHRA’s rules apply, and they change what the project must produce: depending on its classification, a quality management system, technical documentation, risk management, clinical evaluation and a plan for monitoring the product once it is in use. Standards such as IEC 62304 describe how medical device software should be developed and maintained.
We raise the question in discovery, before the scope is fixed, so you can take specialist regulatory advice while changing direction is still cheap. If the answer is yes, we work within your quality management system and produce the development records it requires. If your advisers conclude it is not a device, the reasoning is recorded alongside the design, so it can be revisited when features change.
- Intended purpose discussed before scope is agreed
- Features that could change the answer flagged early
- Development records to suit your quality management system
- Regulatory advice from specialists, not from us
Engineering choices
Integrations, accessibility and hosting, done carefully.
The technical decisions buyers and assessors ask about most. We make them explicitly, write them down and build them to be checked.
FHIR and UK Core profiles
HL7 FHIR APIs, using UK Core profiles where the other system supports them — with the supplier’s access terms confirmed before we design around them.
Integration services
NHS service onboarding
National services such as NHS login, and clinical system suppliers, run their own onboarding and assurance. We plan that time into the roadmap and prepare the technical material they ask for.
Accessibility for every patient
WCAG 2.2 AA, plain English and patterns from the NHS digital service manual where they fit — tested with keyboard, zoom and screen readers.
Accessible design
UK data residency
AWS’s London region when your policy or your customers require UK hosting, with encryption, tested backups and infrastructure defined as code in your own account.
Cloud hosting
Synthetic test data
Realistic synthetic records for development and testing, so engineers rarely need live patient data — and when they do, access is agreed, limited and logged.
Security engineering
The sector view
Patient apps, clinical admin automation, document AI and dashboards — what we build for healthcare, and the AI we consider safe to use.
Healthcare solutions we build
How we work
Building and assuring, side by side.
Seven stages, with an assurance track running alongside the build — so the safety case and data protection evidence grow with the product.
- 01
Discovery
Users, workflows and data flows mapped with your clinical and IG leads — plus the questions that decide the assurance: which standards apply, could it be a medical device, which systems must it connect to?
Scope with assurance duties identified
- 02
Strategy
Scope, integrations and hosting agreed, with the clinical safety and data protection work estimated as visible line items rather than buried in the build.
Plan, assurance track and fixed quote
- 03
UX & architecture
Prototypes tested with patients and staff, accessibility designed in, and a hazard identification session with your Clinical Safety Officer before the architecture is fixed.
Tested prototype and initial hazard log
- 04
Development
Two-week sprints with a demo at the end of each. Your CSO is invited, and the hazard log and data-flow diagrams are updated as features change.
Working software and current evidence
- 05
Testing
Automated and manual tests, WCAG 2.2 AA checks, integration testing against supplier sandboxes, and evidence mapped to each clinical safety mitigation.
Test evidence for the safety case
- 06
Launch
Go-live once your CSO has signed the safety case and your IG lead is satisfied, with monitoring, backups and an incident process agreed in advance.
Signed-off, monitored release
- 07
Optimisation & support
After launch we fix, measure and improve — a support retainer, a roadmap of next features, or a clean handover to your own team.
Support plan or handover
Engagement models
Ways to start a healthcare project.
A discovery sprint identifies the assurance work as well as the build. After that, a fixed-price project — or dedicated developers working to your quality and safety processes.
Discovery sprint
From £2,000 fixed fee
You have an idea or a problem, but not yet a scope you would trust a quote against.
- Workshops with your team
- Prototype or technical spike
- Written scope, plan and estimate
Fixed-scope project
Quoted after discovery
A defined build — an MVP, a rebuild or a feature set — with milestones and a fixed budget.
- Agreed milestones and deliverables
- Milestone-based billing
- A demo at the end of every sprint
Dedicated developers
From £2,900 per developer / month
Ongoing roadmap work where you want named engineers inside your own sprints.
- Named, senior engineers
- Work inside your tools and sprints
- Scale up or down as the roadmap changes
Prices are in GBP. Every estimate is confirmed in writing after a discovery call — the figures above are where engagements start, not a quote.
Relevant work
Health and care products we have built.
Telemedicine, online pharmacy and AI-assisted imaging — read how each was scoped and built, and the stack behind it.
All case studiesHealthcare · Web
Tekish Health
Telemedicine web platform: booking, video consultations and patient records.
Next.jsWebRTCFHIRAWS
Read the case studyHealthcare · eCommerce
Cyber Medic
Online pharmacy and lab-test booking app with prescriptions and delivery.
React NativeNode.jsStripeFirebase
Read the case studyHealthcare · AI
Dental.AI
AI-assisted dental imaging platform that flags conditions for clinician review.
Next.jsPythonTensorFlowAWS
Read the case studyWhy Techsleight
How we work with clinical and IG teams.
The working habits that make assurance a by-product of delivery rather than a scramble before go-live.
Your Clinical Safety Officer in the loop
Invited to sprint demos, with the hazard log reviewed as features change — so the safety case grows with the product instead of being written at the end.
Synthetic data first
We build and test with realistic synthetic records. Access to live patient data is the exception, agreed with you and logged.
Documentation as we go
Data-flow diagrams, architecture notes and test evidence kept current each sprint, ready for your DPIA, DSPT and customer assessments.
Designed for every patient
Plain language, large touch targets, and keyboard and screen-reader testing against WCAG 2.2 AA — with real users wherever we can arrange it.
Honest about integrations
We confirm what a supplier’s API or FHIR endpoint actually allows, and which approvals are needed, before promising a feature that depends on it.
No compliance theatre
No certification claims and no “NHS compliant” badges. We build and document to your requirements; sign-off stays with your organisation.
UK hosting and a UK contract
Hosting in UK regions when your policy or customers require it, and a contract with a UK company. Our engineers are based in the UK and India and work UK business hours.
FAQs
Assurance and supplier questions, answered.
Straight answers on scope, cost, timelines and how we work. If yours is not here, ask us directly.
Is your software “NHS compliant”?
There is no single NHS compliance badge, and we do not claim one. What buyers look for is specific evidence: a DSPT submission from the organisation handling the data, clinical safety documentation under DCB0129 and DCB0160, a DPIA, accessibility and security testing, and sometimes their own assessment. We build and document to whichever of those apply to you.
Who is responsible for DCB0129 — you or us?
The manufacturer of the system — usually your company, or your organisation if you are commissioning software for your own use. Your Clinical Safety Officer owns the hazard log and signs the safety case. We contribute throughout: design decisions, mitigations built as specified, test evidence and release notes mapped to hazards.
Do you complete the DSPT for us?
No — the DSPT is your organisation’s self-assessment and has to be submitted by you. We make it easier by documenting the technical controls it asks about as we build them: access control, encryption, backups, logging, incident detection and data flows, ready for your IG lead to use.
Will your engineers see patient data?
Not by default. We build and test with synthetic data, and production access is limited to named people, agreed with you, logged and reviewed. Our engineers are based in the UK and India, so if access from outside the UK is ever needed, we set out how it is controlled and how the transfer is covered, for your DPO to assess.
What does connecting to national NHS services involve?
National services such as NHS login, and the suppliers of clinical systems, each have their own onboarding, approval and assurance steps, and access is granted to your organisation rather than to us. We check early what access you have or can obtain, plan the onboarding time into the roadmap, and build to the published specifications once access is agreed.
What should we ask a healthcare software supplier before signing?
Ask who will provide which assurance evidence, whether engineers will see live patient data and from where, where the system will be hosted, how clinical safety is handled release by release, and who owns the code and accounts. A supplier who answers with a badge rather than specifics is worth questioning further.
How do you test accessibility with patients in mind?
We design and test to WCAG 2.2 AA from the first prototype: plain English, large touch targets, clear error messages, and journeys tested with keyboard, zoom and screen readers. Where we can, we test with the patients and staff who will use the service, including older users and people with little confidence online.
How is a healthcare project priced?
A discovery sprint starts from £2,000 and identifies the build, the integrations and the assurance duties. The build is then quoted as a fixed price with milestone billing, with clinical safety inputs, DPIA support and accessibility testing listed separately. For longer roadmaps, dedicated developers start from £2,900 a month.
How long does a healthcare software project take?
A focused first release is typically planned over weeks rather than months, but assurance and integration steps often set the pace more than the code — clinical safety sign-off, DPIA review and supplier onboarding all have their own timelines. After discovery you get a dated plan that shows the build and the assurance track side by side.
What happens if a safety issue is found after go-live?
We follow the incident process agreed before launch: triage with your team, your Clinical Safety Officer informed straight away, a fix released through the normal review and testing route — faster, but not skipped — and the hazard log and safety case updated to reflect what happened.
Start a project
Planning health or care software?
Tell us about the service, who will use it and which systems it must connect to. We will reply with questions — including the clinical safety and data protection ones — and a realistic first step.
What happens next
- 1A senior engineer reads your brief within one working day, and replies with questions or a first view.
- 2A 30-minute call to understand the goal, constraints and what good looks like — no sales script.
- 3A written proposal with scope, milestones, team and a GBP estimate you can take to your board.
Techsleight Labs is a trading name of Krapton IT Consultancy.
Explore