Add us as a preferred source
UK private hospitals and clinics recorded 953,000 inpatient and day-case admissions across insured and self-pay patients in 2025, the fourth consecutive record year, according to the Private Healthcare Information Network.
Behind every admission are decisions that depend on accurate records, medication information and test results reaching the right clinician. Software increasingly supports those decisions, but its design can also introduce risks, from warnings that are easily overlooked to information that fails to reach the right person.
For private healthcare providers, the question is no longer simply whether a digital system works. It is whether that system has been designed, tested and maintained with patient safety in mind.
Where clinical safety assurance falls short
A 2025 study published in the Journal of Medical Internet Research examined 14,747 digital health technology deployments across NHS organisations in England. Among the 9,292 deployments with comparable assurance data, just 17.3% had documented assessments against both national clinical risk standards, DCB0129 and DCB0160.
This does not prove that systems lacking documentation were unsafe, nor does it measure private sector performance. It does, however, raise questions about how consistently software risks are assessed.
The consequences can be serious. In a review of 50 patient safety investigations, the Health Services Safety Investigations Body (HSSIB) identified recurring problems with electronic patient records, including poor usability, difficulties sharing information and risks introduced through local configurations.
One investigation found hospital staff copying medication details onto paper because the computer used for electronic prescribing could not fit inside the medication room. The technology was available, but the clinical environment forced staff to work around it.
Although these investigations concern NHS settings, the underlying challenges are not unique to the NHS. Private providers also rely on software configured around local teams, facilities and clinical workflows. That makes understanding how technology performs in everyday practice just as important as assessing its technical capabilities.
Building safety into software from the start
DCB0129 governs clinical risk management in health IT development, while DCB0160 covers deployment and use. Developers must identify hazards, assess their consequences and document safeguards. Providers must consider how those systems will operate in their own clinical environments.
Although their precise applicability varies, NHS England strongly recommends adopting both standards, including for entirely privately funded healthcare technology.
In practice, this means considering more than whether individual features function correctly. Safety assessments must account for how clinicians encounter alerts, how information moves between teams and what happens when established processes fail. These questions need to inform design decisions before software reaches clinical settings.
For Dr Patrick Lester, Healthcode’s Clinical Safety Officer, effective risk management means understanding both the technology and the clinical decisions it supports.
“Ultimately, a lot comes down to a risk-benefit analysis of new functionality,” he explained in an April 2026 interview. Software directly influencing patient care, he argues, needs greater safeguards than systems designed primarily to reduce administrative work.
His experience as a radiographer has shaped that approach. Understanding who requests investigations, who interprets results and who is responsible for acting on them helps identify risks that may not be apparent from technical specifications alone.
Why oversight cannot stop at launch
Even software that has undergone a thorough safety assessment can develop new risks as it changes.
A HSSIB investigation documented a hospital relying on the manufacturer’s original safety case for adult prescribing without a local safety case covering subsequent modifications or its introduction into paediatric care.
The example illustrates why clinical oversight must continue throughout a product’s life. New features, system integrations and changes to clinical workflows can all introduce hazards that earlier assessments did not consider.
This requires clear communication between developers, healthcare providers and the clinicians using the technology. Risks identified during everyday use need to be reported, assessed and addressed, while software updates must be reviewed for their potential impact on existing safety measures.
Lester advocates a continuous process in which new risks are identified, prioritised and fed back into software development, ensuring that clinical concerns lead to practical improvements.
Putting clinical safety into practice
Healthcode aims to empower every healthcare professional to be the best they can be. Central to that ambition is technology that supports clinicians in their everyday work, with safety built in from the outset. Healthcode has formalised this approach through a clinical advisory board that brings healthcare professionals into product development, alongside Lester’s appointment as its first Clinical Safety Officer in September 2025.
Working through clinical safety consultancy ETHOS Ltd, Lester is helping embed risk management into the development of Healthcode’s ePractice platform as it expands into clinical functions, including prescribing.
In February 2026, Healthcode reported progress on baseline safety checks, a clinical safety plan and a hazard log for ePractice Prescribing. These provide a framework for assessing potential hazards and responding as the software evolves.
For private healthcare providers, this points to a broader responsibility: asking not only what digital systems can do, but how their suppliers assess and manage the risks those systems introduce.
As healthcare becomes more digital, clinical expertise must shape the technology supporting patient care. The most important safeguards are those built into software from the outset and maintained as that technology changes.
