I’m the Clinical Safety Officer for the open source RCPCH Digital Growth Charts, and since 2020 when we started the project, one of the things I was determined to differently was the Clinical Safety Management File and Hazard Log.
It’s all got rather exciting recently with the advent of incredible agentic assistance, but it only works at high quality if you have the foundations already done. Luckily, I have been building those for half a decade and it’s all open source, free, and you can use it today.
TL;DR: skip to the last paragraph
2020 - Clinical safety, done in the open
I insisted on fully open, public clinical safety documentation from Day 1. All our clinical safety and medical device documentation is in the same public-facing website we use for our patient/patent, clinician, implementer and developer documentation. Open source clinical safety, in the open.
We eschewed the traditional ‘Word docs for safety case, Excel spreadsheets for hazard log, hide it all in Sharepoint’ approach in favour of modern data formats and Markdown documents, bringing the data about safety right into the same GitHub tools that manage the code.
2021- Build the foundations for others
Following that work I went through a series of stepwise efforts to make it easier to build open clinical safety management documentation, quickly and consistently:
One of the first steps was to get a version of the DCB0129 specification that was not in a PDF. I pulled it all out into Markdown with scripts and manual editing (in 2021 - WAY before LLMs were around!)
2022 - Make it easily reusable
Next, as we were working on other RCPCH projects that would need a Clinical Safety Case, I thought we could do with a GitHub Template Repo for this, so that future projects could have a very easy path to a comprehensive Clinical Safety documentation site.
It worked for me, but other Clinical Safety Officers I showed this to found it a bit too techy to get going… fair enough really, it required the CSO to know about GitHub, Git, and an editor like VSCode.
Initially it was powered by #CookieCutter, which worked, but was a bit brittle at times. And to get the site published you needed to be able to GitHub Pages publish it. It gave you a lot of help but we needed something easier to use.
2025 - Open Source Clinical Safety ‘As A Service’
Next up I worked with some friends who were similarly interested in open source clinical safety to build a simple open source ‘Turva’ platform around this template, to make it less techy and more accessible.
The idea was that the free Turva service would allow a CSO to make and manage a few Clinical Safety Management Files. No more Word docs for your CSMF. No more Excel sheets for Hazard Logs. Definitely better, but took quite a bit of engineering to build, and was still a ‘platform play’, which I think people rightly are becoming suspicious of because of ‘Adobification’ leading to spiralling subscription costs, and Enshittification, leading to a worse service.
2026 - ArcKit
Earlier this year I got to know about #ArcKit, an incredible suite of LLM skills for all kinds of documentation and compliance tasks across ALL OF GOVERNMENT I.T
I decided to contribute some DCB0129 and MDR documentation to see how it worked. It’s a HUGE project and a bit vibe-coded-feeling in places, but it does work. And the output is actually terrifyingly good.
Or should be terrifying if you sell CSO-by-the-hour type services, as many CSO shops do.
2026 - SAFETY.md
ArcKit is awesome enough, but it’s huge as it covers ALL of Governmental tech compliance. I had also separately been thinking about a way to bring Clinical Safety into the Git repo as a first-class citizen, and ArcKit is not designed that way, and is also too heavyweight for that.
My idea was that a SAFETY.md file sits in your repository root, like LICENSE, CONTRIBUTING.md and CODE-OF-CONDUCT.md
Start with one file on the day the project starts. Keep the clinical safety discussion close to the code. Scale up the CSMF as the project develops.
It’s still a work in progress but I figured it might be of interest to this audience. I’m always up for feedback, which could be in the form of comments here, on socials, or Issues in the repo.
LLMs need good tools or they hallucinate
My only other comment is probably not especially controversial, but it’s to observe that LLMs (in my opinion) now do a better job of the basic scaffolding of this kind of tedious, detail-oriented clinical safety and medical device documentation, and of keeping it tidy, updated, and meticulously consistent.
LLMs are here to stay and so we need to enable them by building open tools like this which give them access to the ‘raw materials’ of the DCB/MDR standards, spec, guides, templates, and of course Skills.