Compliance moves with the product so the service can enter live care

In regulated software, a working demo is only the beginning.

This digital health platform had to move from an inherited mid-build state into live patient and clinician use. The business also had to answer the questions that arrive before a health service can be trusted: how is data protected, what clinical risks were considered, who reviews the output and what evidence supports the answers?

We delivered the working platform and the compliance work as one programme. The service began serving patients in four months. The remaining compliance work was completed inside the next two. That sequence gave the client a route to live use without leaving the safety and security case as an open-ended task at the end.

Client background

Our client is a digital health company operating a patient app and clinician portal across NHS care systems. The platform handles information that affects real people, so the definition of “done” must include more than screens and integrations.

The service has to be usable by patients, useful to clinicians and reviewable by security and clinical-safety stakeholders. Those audiences ask different questions, but they all need confidence that the same underlying system behaves as described.

Business challenge

The platform was inherited mid-build with technical debt and incomplete delivery work. A product team could continue adding features, but that would not answer the questions that could block live use.

The business needed to make progress on several fronts at the same time:

• recover the patient and clinician workflows;
• provide bounded AI-assisted reporting;
• protect sensitive patient information;
• make clinical risks explicit;
• document the privacy decisions;
• and respond to the client's security review.

The danger in separating those tasks is familiar. Product teams build a demo first, then discover that the data flow, clinical safety case or security evidence does not support the intended use. The result is more rework and a longer wait for the people who were supposed to use the service.

Implementation

We rebuilt the platform backend, patient app and clinician portal as a connected service. That gave the product a working path through the real user journey instead of a collection of isolated features.

The report-generation component was bounded and reviewable. It prepared a draft from information in the platform, while the clinician remained responsible for reviewing and signing the final report. The design made the human approval visible rather than hiding it behind an apparently finished AI output.

Security and clinical-safety work ran alongside delivery. Cyber Essentials and the NHS Data Security and Protection Toolkit, or NHS DSPT, addressed the baseline security and data-protection evidence. DCB 0129 and DCB 0160 clinical safety cases documented the risks and controls for the health software. ISO 27001 and HIPAA requirements formed part of the wider delivery context, together with the data protection impact assessment and client security questionnaires.

The evidence was tied to the system that would actually run. That matters because a policy document about an intended architecture cannot prove that the live workflow follows it. The review had to see how the patient, clinician, data and approval paths behaved together.

Why it was difficult

Compliance is not one final checkbox. It is a set of questions about how the product behaves when a real person uses it, when information is missing and when something goes wrong.

The team had to keep delivery moving without turning speed into a reason to skip evidence. It also had to explain technical controls in terms that a clinical or operational reviewer could use. A row of standards does not establish trust by itself. The page has to show what changed in the workflow and why the control mattered.

The four-month live milestone and the two-month follow-on compliance milestone are therefore delivery facts, not a promise that every regulated platform can be completed on the same schedule. The transferable lesson is that the first working path and the evidence around it should be developed together.

Value delivered

• The inherited platform began serving patients in four months.
• The remaining compliance work was completed inside the following two months.
• Security, privacy and clinical safety questions were addressed alongside the working product.
• The patient and clinician workflows had a clear human review and sign-off point.
• The client received a connected service rather than a demo that still needed a separate evidence programme.
• The platform could continue to evolve with its controls and review trail in place.

The business value is reduced uncertainty at the point where regulated delivery often stops. The client could see what was working, which evidence existed and which professional remained responsible for the decision.

What this means for your business

The same problem appears in financial services, professional advice, insurance, property and any workflow where a security questionnaire or compliance review can stop a useful build.

Treat evidence as part of the product. Define the human approval, connect it to the live workflow and test the system against real cases before the final review. That gives the buyer something more useful than a promise of compliance: a working process with a reasoned record of how it is controlled.

Related: Compliance-ready delivery · Platform engineering · Digital health and NHS suppliers