What DCB0129 actually cost me

When I started, I'd read DCB0129:2018 twice and thought I understood the shape of it. Fifteen months on, most of what I understood was correct in outline and wrong in weight. The outline says: write a CSMS, appoint a CSO, build a hazard log, write a safety case, handle incidents, do post-market surveillance. What that undersells is which parts eat time, which parts eat sleep, and which parts you cannot fake.

The numbers

Where Kairos's clinical safety work sits today:

• One CSMS, structured around eight linked artefact folders that match the DCB0129:2018 lifecycle sections directly.
• One signed CRMP, baseline 1 April 2025. A 5×5 risk matrix with three acceptance bands. Two pages of substance, no policy padding.
• Fourteen hazards, HZ-001 through HZ-014, with initial and residual scores, controls, and status.
• Twelve safety requirements (SR-001–SR-012) mapped to eight test cases (TC-001–TC-008) in a traceability matrix.
• One Safety Case Report in draft, structured Goals / Strategies / Evidence. Not yet signed for external release — that's a story I'll come back to.
• Two live production incidents worked through end-to-end this month, with root cause analysis, seven CAPA items in one case, and hazard log updates in both.

None of that is a large volume of documentation by DCB0129 standards. But every artefact in that list is real and exercised, which turns out to matter more than volume.

What actually took the time

Not the writing. The writing is a weekend, per artefact, once you know what you're trying to say. The time went to three places I didn't predict.

Learning to write hazards from the workflow down, not from the code up. My first hazard log was software-out: what could this endpoint do wrong, what could that database column corrupt. That misses entire classes of clinical failure. The version I have now starts from the clinical workflow — what could go wrong for a GP trying to make a referral decision, and what part of the product participates in that going wrong. Rewriting the log through that lens took longer than writing it the first time.

Traceability that doesn't drift. A traceability matrix is trivial to draw and constant work to maintain. Hazards move, requirements get refined, tests get renamed. Every product release is an opportunity for the matrix to fall out of step. I now treat the matrix like schema migrations — you don't merge the code change without the matrix update, or the two drift apart and it costs a full afternoon to reconcile.

Being my own CSO, and knowing I can't stay that way. I'm acting as interim CSO (GMC 4622046, appointment recorded 1 April 2025). That's legitimate for building the CSMS and for writing the safety case internally. It is not a signature that carries weight in external procurement. DTAC C1.2.5 wants an independent clinician's sign-off, and rightly so — I authored the product, I own the company, I can't sensibly assure my own work for someone else to buy. Appointing an independent CSO is now the single biggest gate on Kairos's path into procurement conversations, and it's the thing I wish I'd budgeted for from month one rather than month twelve.

What the two incidents taught me

Both incidents happened this month, both on live production, both worked through as full DCB0129 CAPA cycles.

Incident one was a P0 crash on a contributor submission workflow. Root cause was a single line of code; downstream cause was a chain of three UX assumptions that hadn't survived first real use. Seven CAPA items shipped as code changes the same day. Effectiveness verified by re-running the workflow with a different contributor. What made the forensics tractable wasn't clever monitoring — it was that Kairos's baseline audit logging captures every user action, every content change, and every governance event. When you can reconstruct what actually happened minute-by-minute, root cause analysis stops being guesswork.

Incident two was subtler. A data-refresh pipeline had been stuck on a stale month for three months. The product was firing a passive "data may be outdated" warning, so users hadn't been misled — but the warning fired continuously and nobody was actively watching for it. The residual risk was ALARP on paper because the warning existed; the real residual risk was that a passive warning without an active alert is a mitigation nobody sees. The CAPA was structural: passive user warnings must be paired with active operator alerts, and any pipeline in this class gets a monitoring probe. The sibling-bug hunt found the same latent failure in an adjacent pipeline before it fired.

The single most useful lesson from both: your hazard log will move more from two real incidents than from twelve rounds of desk review. If you're starting fresh, expect the log to roughly double in your first six months of live use.

Would I do it differently

Three things.

I'd appoint the independent CSO in the first quarter, not the fifth. The interim-CSO position looked like a saving; it was actually a deferred bill.

I'd wire audit logging into the product before I wrote the first hazard — because when the first incident hits, the log is your reconstruction. It also anchors half your controls without needing a separate proof.

I'd treat the safety case as a working document from day one, not a launch artefact. Drafting it early, badly, with a clear do not present externally without CSO sign-off and version-scoped evidence banner across the top, would have caught structural gaps months before they mattered.

None of this is DCB0129 being difficult. It's DCB0129 being honest about what safe clinical software actually takes. That's a feature, not a bug. It just costs more than the outline suggests when you're the person doing all four evidence streams.