Documenting compliance with IEC 62304 in medical device software appears on the surface a vast, monumental task. A monolith that towers over your software team for the course of the project and can feel intimidating to get started on.
IEC 62304 is a software lifecycle standard and covers the safe design and maintenance of medical device software. Its nine parts have over three hundred elements of software assessment.
So, how do you prevent documenting your medical device software’s compliance with IEC 62304 from becoming an activity that all corners of your software team dread?
It depends on when you start documenting for compliance.
And on how effective and efficient you make the process.
In this blog post:
- When to start documenting compliance with IEC 62304
- Why start so early?
- What can be considered documentation in IEC 62304?
- How to make complying with IEC 62304 effective and efficient for your team and auditors
- Is it ever too late to start software documentation?
- Do you want to know if your medical device is IEC 62304 ready?
When to start documenting compliance with IEC 62304
The class of software your device has will affect the amount of work needed to document device software.
But the class doesn’t affect when the ideal time to start is. When’s the perfect time to start?
It’s best to start your documentation at project kick off.
There, that’s it. Blog post done.
Or is it?
Starting documentation is one thing; doing it so that it doesn’t hinder your team’s pace is ideal.
Why start so early?
Sure, you can try to retroactively begin documentation once you’ve started and gotten far into a project. But doing so will put you at a disadvantage.
Starting your documentation when you begin software activities means:
- You’re compiling evidence when those memories are fresh;
- You have a coherent record of software decisions from the start;
- Your documentation makes it easier for new team members to get onboarded to the project;
- You have a head start on what can be (for complex device projects) a massive volume of needed documentation.
Leaving it until the end opens you up to more of a slog than if you’d created it as you went and is more open to error.
It’s better to work on it little and often. And by working on it alongside software development, the software and documentation will continue to match your evolving requirements. Doing this means documentation starts to add value to your project and stops it from becoming a chore.
What can be considered documentation in IEC 62304?
Documentation isn’t necessarily something that’s a large written document. Though one part of it is and that’s your Software Development Plan. (And your SDP should only be as big as it needs to be.)
Your plan provides a top-level description of the processes used in creating this device’s software.
At its core, the Software Development Plan (for each step in the software creation process) will explain the design inputs and outputs.
Teams following Agile and Lean-Agile practices can also use the plan to state how continuous improvement works as part of their processes. By displaying this evolving setup from the get-go, it naturally enables changes directed by new knowledge gained during development.
Outside the plan, it’s possible to generate much of what you need for IEC 62304 from the artefacts created during software development and testing.
- Requirements that explain what the software features should do.
- A traceability matrix acts like a failure mode effects analysis (FMEA) showing links between hazardous situations, software items, and risk control measures. It is also used to track your requirements and their verification tests, so it’s possible to check current project requirements are being met.
- The configuration explains what tools the team uses, which versions and how they’re configured, and the software environment.
- User stories show how a piece of software will deliver a specific element of value back to the user/customer and your organisation, are created before code, and link back to software requirements.
- Unit tests, ideally created before developers write code (as you find in a test-first approach like Test-Driven Development (TDD)).
- Test scenarios are generated by practices like Behaviour-Driven Development (BDD). In BDD, you list given, when, and then style scenarios based (often) on user stories.
- Test reports and results from run tests on a given software version, such as where it passes or fails and recording anomalies beside them.
- Defect reporting, such as a platform that captures reports from end-users, testers or anyone who uncovers software defects, is logged for further assessment.
These are just some examples.
How to make complying with IEC 62304 effective and efficient for your team and auditors
There are a host of ways that you can make everyone’s life easier when it comes to documenting compliance with IEC 62304 in medical device software.
Start early, and do little and often
I’ve already said this, but the essential thing any team can do is not leave documentation to the end of a project. It is hugely unhelpful to treat it as a one-time activity.
Your team needs to make it a habit that they work on documentation alongside coding and testing.
And that also means that the team needs to keep going back to the Software Development Plan and requirements to review them and make sure they’re still relevant. If you’re working in sprints, then review the requirements as part of each sprint.
Use living documentation
Should your team be working in an Agile or Lean-Agile way, it’s possible to pull together much of what you need using living documentation. Living documentation is documentation that evolves alongside your codebase.
Living documentation helps cut time spent on documentation tasks, drawing upon much of what the team is already creating as part of their work. There is engineering time involved in making this all work together, but the return on investment by automating the collection of engineering artefacts is worth it.
Living documentation falls into your processes like this if you’re working in an Agile or Lean-Agile way:
You might notice that the diagram references AAMI TIR45. What is TIR45? It’s a way of doing Agile in a way that’s compatible with medical device software development, as explained by the FDA.
(Which moves us onto my next tip.)
Work in a Lean-Agile way
Okay, I’m biased on this one. Following Lean-Agile is how we develop all software here at Bluefruit. But we’ve shown repeatedly that:
- Lean-Agile software development is compatible with medical device software;
- Agile techniques like Test-Driven Development hugely help with traceability and quality in medical software;
- Working in a Lean-Agile way is consistent with pursuing FDA approval;
- Developing new forms of medical system is possible when working in a Lean-Agile way;
- Lean-Agile practices can help cut your time to market.
What does it mean to work in a Lean-Agile way? At its core, it means taking principles from Lean manufacturing and putting them together with Agile project management and technical practices. You end up with a software development process that limits waste while increasing quality. It all fits together like this:
Following Lean-Agile principles and practices means developing medical device software with solid feedback loops as a core part of development. It helps you to build better quality and safe software while complying with IEC 62304.
Suppose you’re not ready to go Agile or Lean-Agile. In that case, there are still things you can do to ensure documentation isn’t a headache.
Have a software analyst on your team
Software analysts live and breathe documentation. They can:
- Keep track of requirements and add references to them in user stories, BDD, and acceptance tests.
- Facilitate conversations between software teams and stakeholders.
- Complete requirement reviews to assess if there are missing requirements or clarifications required.
- Act as a final check for document version control, signing off changes.
- Create any software verification activities such as verification plans and verification tests for V&V.
- Help developers keep on track of software work versus requirements.
- Help developers and testers better understand how the software is meant to work.
- Maintain the traceability matrix to identify potential gaps in planning development work.
They can help you keep an eye on your documentation as the project progresses, ensuring requirements, your Software Development Plan, and more are up to date.
Ensure unique numbering for requirements and other documentation
If you’re using a manual tool like Word or Excel, do not use automatic numbering. When you use automatic numbering for requirements in apps like these, you can end up with misaligned numbers when making changes to the document. Misaligned numbers break the traceability chain between the requirements and anything else that references them (like test scenarios).
Tools dedicated to this complex documentation will have unique autonumbering as a default but prevent accidental changes. They can also check for duplicate IDs, easily occurring from copy/paste mistakes.
Make it easy to understand and navigate
Often, your software team loathes documentation because it’s not pleasant to interact with.
What can you do?
- Keep your documentation succinct. Include no more or less than what’s needed for all parties to have a shared understanding of what it’s saying.
- Write plainly and clearly. While relevant project and tech jargon are needed, that doesn’t excuse you from having documentation that’s not easy to read. The more accessible documentation is, the quicker people understand it and want to use it. So, invest in readability by using short sentences, writing in the active voice, and picking simpler words over complex ones.
- Make documentation easy to navigate. Living documentation tends to have this built-in because it’s a “hypertext”, but even manually hyperlinking between parts of documentation can help. Engineers, testers, and auditors will all be grateful. Putting this all in a dashboard or live-hosted page with links to documents and metrics can help everyone keep up to date.
Just as software that’s part of your product should be something that users want to use, your documentation should be something your team wants to be involved with. At the very least, it shouldn’t be hard to work with.
Is it ever too late to start software documentation?
What should you do if you’ve come to this blog post and not started your documentation yet and are well into your software project?
Start your documentation now.
It’s only too late to document software if your software is so poorly coded that performing things like code and design reviews are impossible retroactively. In which case, you might be looking at a software rewrite to have the documentation you need to meet IEC 62304.
Would you like to know more about how Bluefruit works to deliver high-quality embedded software? Watch our video:
Do you want to know if your medical device is IEC 62304 ready?
I hope you’ve found this blog post helpful. Aside from making sure you start working towards IEC 62304 as soon as possible, the advice here will help you and your team build worthwhile documentation.
Are you wondering how well your device software holds up against IEC 62304? Then download your copy of The essential IEC 62304 checklist today.
The essential IEC 62304 checklist will help you:
- Appreciate the role of IEC 62304 in medical device software auditing.
- Check whether your medical device software is audit-ready or not.
Discover valuable opportunities working to IEC 62304 presents for your business.
Download your checklist and answer:
Did you know that we have a monthly newsletter?
If you’d like insights into software development, Lean-Agile practices, advances in technology and more to your inbox once a month—sign up today!Find out more