Acceptable software development follows a series of repeatable steps that ensure that all requirements are met. There is no single “correct” software development process, but any good process must incorporate the requirements of 21 CFR Part 820, IEC 62304, the CDRH guidance on software validation, FDA cGMP, ISO 14971, and all FDA guidances that elaborate on Part 820. The process needs to be both disciplined and flexible in order to accommodate both the FDA’s Software Levels of Concern rating system and IEC 62304’s Software Safety Classification system.
Here's a sample process consisting of ten components, only one of which includes actual coding:
- Configuration Management
- User Needs (End User Assessment)
- Risk Analysis & Security Analysis (Vulnerability Assessment)
- Requirements
- Architecture & Detailed Design
- Implementation (Coding)
- Code Reviews, Static Analysis & Unit Testing
- Integration Testing
- Micro Penetration Testing
- Human Factors Study
- System Testing
- Documentation & Traceability
When regulatory requirements are fully understood, and each component of software development is carefully implemented, the resulting medical device software meets standards of functionality, safety, and regulatory compliance.
Configuration Management
First things first: before you even begin looking at project specifics, you’ve got to make some decisions (and document them!) regarding configuration management for the project.
Configuration management systems ensure that development proceeds in a controlled, consistent, traceable, auditable manner. It includes change requests, defects tracking, and release management. During medical device development, it is essential that released packages are tightly managed and reproducible for the full lifetime of the device.
Version control during development comprises a significant element of configuration management. Version control facilitates parallel development by keeping your team working from the same central source of truth, making it easier to reconcile conflicts, and helping to protect the master project from any bugs or mistakes. However, version control alone isn’t sufficient to meet coding standards for medical device software. Configuration management goes further, determining version control workflows, tracking tasks and issues and documenting in medias res decisions and review findings, defining and enforcing release states to prevent “configuration drift,” and so on.
Given that, it should go without saying that configuration management applies to more than just code and software resources. It also includes all of the process records and quality artifacts produced, including design, risk, and requirements documents.
Selecting the right combination of CM tools and defining the CM process for your project is non-trivial. Fortunately, there are abundant resources available, including the contact form on our website. As consultants who’ve contributed to a wide variety of medical device projects for well-established industry majors as well as small start-ups, aimed a numerous indications, we’d be happy to offer tips, discuss best practices and lessons learned, and relate what we’ve seen work well for the smoothest development experience with the fewest speedbumps in the approval process.
In our next post, we’ll examine the two primary input phases of development – User Needs and Requirements – as well as Risk Management, which begins alongside Requirements development to inform inputs and continues concurrently with development for the duration of the project. If you’d rather not wait, click here to download our free white paper!
