Strategies for reducing software documentation burden

[dhruv]

Hi all,

I'm a product developer at a medical imaging startup and we are currently working on preparing our first 510k submission for a Class II device. I am the software engineering team lead managing the external software development resources as well as preparing the documentation for the submission.

The documentation burden for software seems insurmountable and intimidating. We have finished the first few docs, such as the Software Development Life Cycle SOP, Software Development Plan, Software Level of Concern, Software Description. Currently, I'm working through the SRS, SDS, Software dFMEA (hazard analysis), and Architecture Charts.

Seeing as how the FDA guidances don't seem to distinguish between important and less critical documentation, it is hard to tell what I should prioritize. Does anyone have strategies for how to do a 80/20 analysis on what to focus on first and what to leave for later stages? How complete is the FDA looking for the docs to be? What kind of holes do they usually focus on in the documentation? I want to focus on the submission and will have more time for supporting docs during the validation phase.

Any advice would be very quite helpful, as I am finding the documentation burden overwhelming,

Thank you,
Dhruv

 

[AndyN]

Are you preparing this documentation alone?

 

[dhruv]

Yes, I am mostly preparing the documentation alone with some help here and there as needed from the developers.


Dhruv

 

[Marcelo]

Really, the requirements for software simply mirror the good practices of software engineering.

One of the "differences" from software and hardware, then talking about safety and related stuff, is that as software does not have a "physical"final product which can be easily tested, software safety is very dependent on design and related documentation, that's one of the reasons of the focus on documentation requirements.

How complete is the FDA looking for the docs to be?

I think you are thinking backwards. The question should be - how complete do I need to have a documentation to guarantee a safe software? The fact that the FDA (or any other agency) will verify the documents is second to the responsibility of the manufacturer to have a safe product.

Anyway, a general comment on your questions - the important things in software documentation is a clear identification off software requirements (based on the device/system requirements in embedded systems) and clear traceability between the inicial requirements, detailed design, verification, validation (device/system validation in embedded systems) and output requirements.

You can take a look a documents such as IEC 62304 to have a general overview of the most important requirements (for example, the requirements that are applied to all devices in 62304 are really the basic documentation requirements).

 

[AndyN]

Yes, I am mostly preparing the documentation alone with some help here and there as needed from the developers.


Dhruv

No wonder you believe the task is overwhelming! One person shouldn't be doing this! You are making a monster which will, in time come back and bite you.

STOP - form a team and delegate the activities.

 

[mihzago]

the idea is that you create documentation as part of the process. So, normally you would start with a project plan and requirements document (e.g. SRS) and architecture, then you would develop the software further and create design specs. As you continue through the development process, you may be refining these documents and as you're getting into the V&V phase, so you should be creating test protocols and reports from testing or other V&V activities.
You also work on your risk management file throughout the project.


I've worked with teams where I would take on a lot of the work of providing templates or starting drafts with some examples, and coordinating creation of these documents, and sometimes even filling in some of the information they would provide, but it cannot be a job for one person that is detached from the development process.


And from my experience I can tell you that if the development team is not creating any documents or artifacts other than the code, then I can almost guarantee they'll end up with garbage software.

 

[g_ehs]

It sounds like you may have a small team?

Do you use github? (Or a similar tool to control code versions?)

If you can leverage the tools already in use, and get the team to understand that 'quality' doesn't reside in the documents you create, you might have a fighting chance.

For your work, the key is the traceability from Requirements through development, testing, and updating. Naturally, familiarize yourself with the ISO standards (ISO 62304 in particular).

Prioritize Safety of the end customer and make sure you have traceability/coverage of all requirements. Keep in mind - a document you create in MS Word, if your developers use a tool like github, will be severed from the work of your development team - so, stay general. If you get detailed and specific, your documents will probably be out of date as soon as you remove them from the printer. (I'm suffering through this right now.)

 

[TomaszPuk]

When you look at IEC 62304:2017 (please note the new version is still in review) standard you should start with the software safety classification. Let's assume for the simplicity here that Class II - corresponds to IEC 62304 Class B software safety classification. Then I would also advice to get your software development team to work on the bellow deliverables.

• Software Development Plan
• Configuration Management Plan
• Documentation Management Plan
• Documentation Index
• Tests Strategy
• Software Maintenance Plan
• Information Security Risk Assessment
• Information Security Risk Treatment File
• Technology Stack Requirements
• Technology Stack Specification
• Source Code Repository - Tool
• Tool: Configuration Management System
• Tool: Static Source Code System
• Tool: Continuous Integration System
• Tool: Continuous Integration System
• Tool: Issue Tracking System
• Tool: Documentation Management System
• Software Requirements
• SOUP Requirements Specification
• Environment Installation Manual
• Version Deployment Manual
• Operations Manuals
• Solution Architecture
• Solution Architecture - Interface Specification
• Source Code
• Test Plan
• Software Unit Test Level Specification
• Installation Tests Specification
• Deployment Tests Specification
• Integration Tests Level Specification
• Regression Tests Level Specification
• User Acceptance Tests Level Specification
• Release Completeness Tests Level Specification
• Issues Found
• Traceability Report
• Release Notes - Residual Anomalies
• Release Package
• Release Build Procedure
• Release Transfer Procedures
• Product Identification Procedure

 

[TomaszPuk]

Whenever you start a software project aiming at delivery of health software I would suggest starting with making all SDLC team members aware what is expected from them from IEC 62304 perspective. If you split the list of deliverables by the below roles it is not that challenging any more - just good old software engineering

I would suggest to think about the following roles / hats in the software project team:

1. Project Manager
2. Business Analyst (aka. System Analyst)
3. Technical Leader
4. Software Developer
5. Quality Assurance Engineer (aka. Tester)
6. DevOps (aka. Configuration Manager)

 

[dhruv]

Hi all,

I apologize for the delay in responding, but I really appreciate everyone's thoughtful and reasoned responses. I've been able to convince my team that more resources are needed for us to make a safe, effective medical device, and generate the documentation required to ensure that.

We are now in the process of gathering together a gigantic exhaustive list of documentation for the entire system, including the software bits.

@g_ehs Yes, we use bitbucket for all of our code (software and firmware) and use jenkins and a google cloud instance as a build server (just for software at the moment, hoping to integrate firmware into it soon). We also use SonarQube for static analysis.

Thank you all for the answers!

D