If what you build can affect somebody's health, the review hinges on a hazard log that still has to match your product on the day a reviewer opens it, eleven releases after it was written. Safe products lose this review when the paperwork drifts away from the code.
✓ Your clinical safety officer signs the safety case · The build gives them evidence to sign
Your clinical safety officer decides the risk picture. Your information governance lead decides the data position. The build's job is to make the product evidence both, for a reviewer who will never meet the people who designed it.
Five topics that live in five different heads have to agree with each other in writing. Most of the work is finding where they contradict, before the assessor does.
Data flow detail, a retention position, penetration test results, an incident and support process, and a named person against each. The trust also runs its own clinical risk process under DCB0160, and that process feeds on your evidence. Anything that exists only as slides has to be produced properly.
Under DCB0129, the clinical risk standard for manufacturers of health IT, the hazard log carries that evidence. Built well, it traces each hazard to a feature and to the release it shipped in. A mitigation nobody can point at in running code is a mitigation on paper only.
Residency, access control, retention and deletion are schema and infrastructure decisions. Settle them after launch and you are migrating live patient data, which nobody enjoys and everybody notices.
Four of these apply on every gate. The fifth belongs to clinical work, and no amount of engineering closes it.
In every one of these the product is safe. What is missing is the proof, and from the reviewer's side of the table, missing proof looks the same as risk.
It was written at version one, and the product has shipped eleven times since. Like a service history with half the stamps missing, it leaves the reviewer wondering what else went unrecorded.
The assessment became a document produced for the submission instead of a process running alongside the build, so no product decision ever changed because of it.
A diagram that explains the product to a buyer does not say where a record physically sits, who can read it or for how long. Governance asks only the second kind of question.
The mitigation exists and the team remembers building it. The link between the hazard, the change and the version is missing, and that link is the evidence being asked for.
A named clinical safety officer takes responsibility for the clinical safety case. DCB0129 requires that person to be a suitably qualified and experienced clinician with current professional registration, and the judgement they make is theirs, never ours.
What they sign is a claim about how the software behaves, so the software has to make that claim checkable. Hazards are recorded in a form that survives the product changing, and every mitigation traces to the feature and the release that delivered it. Without both, the officer is signing a description of a product instead of the product itself.
If nobody holds this role yet, that is the first problem to solve, and you will hear it from us before a build is quoted.
The clinician who signs the safety case is putting their registration behind it. The least a build team owes them is a product that shows its working in every release, without anyone having to ask.
Philip Wasko
Co-founder, Foundry 5
The clinical version of the Week-One Review starts from what could go wrong for the person using the product, works out what the product has to do about it, and only then opens the roadmap. A founder leads the week, so the people deciding the sequence are the people who will build it.
Day 1 · Name the assessment, the trust and the person who signs the safety case
Day 2 · List the hazards and the evidence the submission will ask for
Day 3 · Test the current product and data model against that list
Day 4 · Decide the sequence and what stays out of version one
Day 5 · Price it, with the hazard log structure ready to maintain
5 days
The fee is quoted before you start and credited against the build when you proceed.
Take it to another supplier and it still works.
Clementine is a mental wellness platform built around guided hypnotherapy, expert-led courses and personalised affirmations. Wellbeing products sit in an awkward place. They are not medical devices, but the moment a health service, an employer or an insurer considers recommending one, the clinical questions arrive anyway.
So the answers were built in. The data position, the retention rules and who could reach what were settled as architecture, and the evidence already existed when the ORCHA review came, with nothing assembled under time pressure.
Clementine is ORCHA certified, has been covered in the Wall Street Journal, The Guardian and Forbes, and now serves more than 150,000 members with a 98% helpfulness score.
150K+
Trusted members
Most clinical work starts at Band 2. The hazard log, the data flow documentation and the evidence pack are part of the build, and they travel with every release instead of being produced once and filed.
Where the product is narrow and the trust relationship already exists, Band 1 can be enough. The Week-One Review tells you which applies before you commit.
Quoted after the Week-One Review
Every answer is about building the product. Clinical advice stays with your clinical safety officer.
No. A qualified clinical safety officer writes it, signs it and carries the responsibility for it. The build makes sure the product supports what they need to say, and that the hazard log traces to things that shipped.
With yours. If the role is empty, filling it comes before any build is scoped, because nothing in the hazard log can be signed until somebody holds it.
Its own governance list, which varies from trust to trust: data flows, retention, incident handling, test results and a named contact against each. The first week establishes which trust you face and what it has asked suppliers for before.
Yes, with more urgency. A product in live clinical use carries hazards now, so the review runs against what is running today instead of what was planned.
It is logged, assessed and traced to a change like any other, which works only if the log was built to be maintained. That is why its structure gets settled in the first build.
Yes, whenever your buyer has to answer to somebody else. Private providers, insurers and employers ask for much the same evidence, because their own governance borrowed the questions.
Those three shape the hazard log, the data position and how much version one can safely carry. Guess at them now and you rebuild them later, with less time and a reviewer already watching. Where a second gate sits behind this one, the regulated software page maps all four side by side.
NOT CLINICAL ADVICE / YOUR CLINICAL SAFETY OFFICER OWNS THE SAFETY CASE