Software in Medical Devices, by MD101 Consulting

Rebuilding the IEC 62304 template repository with Claude Code

A blog post by Yannis Rizos gave me the push I needed. He described how Claude Code can become your new teammate. Not a chatbot assistant you query, but like a team mate you hand a task to and who carries it through to completion, commit by commit, pull request by pull request.
I happened to have exactly that kind of task waiting.

For several years I have been publishing on this blog a set of software process templates for medical device development. Useful, but with good old MS Office files. Probably, too old. I had to convert them to something closer to the code. Something that software engineers can put in their repo and update while they update their code.

The idea was straightforward: take those templates, reorganise them as .md files into a structured Git repository. But I never had the time to do it. Then Claude Code came on the market. Able to do the repetitive job. It was time, I had no more excuse to procrastinate converting my templates.

Converting the templates: accelerated time

The templates were produced in three waves from 8 March to 19 March. Something that would have taken me months to do with Claude code. Between productive tasks, which bring money. Productive tasks first, templates when I have time.
Thanks to my new team mate, it took 2 weeks only.
Only one team mate? No, an infinity of team members doing the job for you. You can fire multiple branches at the same time, asking Claude different tasks. The only caveat is maintaining consistency between branches, by rebasing and merging. Not a big deal for software engineering teams.

As if I was operating in a relativist world, where time stretches in an uncanny manner for newtonian beings. My Claude team does the job and meanwhile, I can do something else. In my Claude rocket, it takes two weeks. On the earth ground, it takes ages.

I had an experience like this a looong time ago, with Redmine. A few of my clients used to place lots of documents in Redmine. Every change was managed thanks to Redmine workflow. Drawbacks: Redmine wiki was basic, its GUI was basic (though doing the job) and it has become a bit old, compared to more modern tools like commercial e-QMS and e-Documentation I won't quote here (this is enough with Claude!). Redmine was definitely not relativist!

Review and merge

Of course, you have to review what Claude does. But this is exactly the workflow, which sets the foundation of git paradigm. Somebody writes code. Somebody else reviews it. Here, Claude writes .md files, I review them and merge.

More, Github remembers every bit of changes in your files. It helps a lot in recording documentary changes in a change control process. Placing software documents as close as possible to source code also helps managing changes in agile iterations. It eases the verification of DONE status at the end of an iteration.
The closer the software documentation to the IDE, the better.

Methodic work

This was not like "vibe coding" — some fancy tool giving you an application with bells and whistles in one prompt (hello, fake prompt engineering). It was structured work, with explicit tasks, conventions documented in the CLAUDE.md file (for those who don't know, it is a kind of configuration file but written in natural language, giving general instructions to Claude), and a separate pull request for each deliverable.
It was fed in a RAG-like manner with my own internal repository of documents.

Claude Code managed file creation: I copied the content of doc templates as raw text. Claude converted them to md files. And that rascal actually had the nerve to give me some great ideas for improvement!
More, it had the ability to maintain consistency over time. Decisions made on 8 March — the structure, the naming conventions — are respected on the subsequent iterations, without explicit reminders. All of this thanks to that CLAUDE.md file.

Manually updating

The limits show up too. Several manual passes were needed to fix this and that throughout the documents. I could have written my instructions to Claude in a better manner, to limit these manual fixes. But that is inherent to iterative development. Claude Code is no exception to that rule.

The result: a library of 20 templates

Ten days and 34 pull requests later, the repository contains:

• 4 planning templates: project management plan, software development plan, configuration management plan, and the brand new data management plan for you AI models + a new review report,
• 1 software requirements specification + a new review report,
• 1 software architecture document + a new review report,
• 1 software design specification + a new review report,
• 1 new pull request review checklist,
• 1 software unit implementation and a new review report,
• 3 verification templates (plan, description, report) + a new test plan review report,
• 1 version delivery description,
• 1 a new release review report,
• 1 data management report (design phase).

Precision: there's not fully AI-generated. The content is similar to the good old word files. Their conversion to .md files is AI-generated.

Theses templates are published on this public GitHub page: templates repository for MDSW. The templates are reusable with CC-BY-SA License.

Conclusion

Yannis's article was right: Claude Code changes the nature and the pace of your work. Building this repository by hand would have taken months. With Claude Code, two weeks were enough.

But the tool does not replace judgement. Claude Code executes, you take decisions. It does not make them for you.
I'm the manager, Claude is like an infinity of teammates.

This is the equivalent of coding with AI for Quality Assurance and Regulatory Affairs. This AI-augmented QARA.