Understanding IEC/ISO 62304 and FDA Requirements for Medical Device Software Development Life Cycle (SDLC) Management

Use IEC 62304 as Your Guide to SDLC Compliance

IEC 62304 does not require a specific software life cycle and does not prescribe how you should meet requirements. While it does specify what you should document, IEC 62304 does not tell you where it should go. If you are not familiar with this standard, it is divided into the following major sections:
IEC 62304 places software into three classes of risk: A, B, and C. Some activities within the standard are not required for Class A and B software, so it is important to understand your classification right away.

Additional Documents You Will Want in Your Digital Arsenal

• This standard applies to health software that does not have associated hardware. It covers all life-cycle activities from design and development to end of life.
• This standard, released in late 2021, covers software development, release, maintenance, risk management, and problem resolution.

Basic Steps in the Process

• Define and document software requirements
• Verify software requirements (review not testing)
• Describe software structure and interfaces
• Specify function and performance requirements for software of unknown provenance (SOUP)
• Verify software architecture (usually technical analysis / review)
• Break down software architecture into software units
• Document detailed design for each software unit
• Verify detailed design (usually technical analysis / review)
• Write the code
• Establish acceptance criteria (coding standards)
• Establish verification strategies, methods, and procedures (reviews, static analyses, unit tests, etc.)
• Perform and document results of software unit verification
• Integrate the software units (build the software system)
• Verify the software integration (did the build work’)
• Test the integrated software (functionality, behavior, performance, etc.)

During this process, you may combine integration testing (architecture/design) and software system testing (to the requirements). You will define levels of testing by what is required, how the software is architected, what / where you want to test, and what you can verify through other methods such as analysis or inspection. In all cases, you will need to ensure software verification is complete and results have been evaluated before release.
IEC 62304 also takes into account the fact that many software development manufacturing teams use a continuous integration / continuous deployment or delivery (CI/CD) pipeline process. CI/CD uses automation and continuous monitoring throughout the life-cycle process, supporting development and operations teams using agile methodology.

Manufacturers of medical device software have traditionally relied on a computer system validation (CSV) model. This model tends to focus 80% of effort on producing the documentation auditors want to see rather than testing the software itself. After recognizing that many manufacturers were not seeing the forest for the trees, FDA set out to release (as of April 2022) new computer software assurance (CSA) guidance that flips this formula on its head. With this CSA guidance, manufacturers will (hopefully) spend 80% of their time testing activities associated with risk rather than producing the paperwork needed to pass an FDA inspection.

Making Sure You Are Prepared for Your 510(k) Submission

If you are preparing your software or device for an eventual 510(k) submission to FDA, be sure to download the new FDA draft 2021 guidance on premarket submissions for device software functions. This new guidance (once finalized) will replace a version from 2005 and includes important changes such as:

• Recognition of ISO 62304 as noted above
• Requirement to include your software architecture in premarket submissions
• Requirement to include your entire risk management file, not just a risk analysis

One last thing. If your medical device incorporates off-the-shelf (OTS) software, you will definitely want to download the FDA guidance, Off-The-Shelf Software Use in Medical Devices, from September 2019. While SDLC is not applicable for OTS software, it still has a role in the safe and effective performance of devices. This guidance will also answer many of the questions you may have about which information must be provided as part of a 510(k) submission. On that note, you may find some inconsistencies between this 2019 document and the 2021 premarket submission guidance noted above. It is probably best to follow the 2021 guidance as FDA is aware of the issue and plans to update the OTS guidance.

Want to Learn More?

As if coding software was not hard enough, compliance with medical device regulatory requirements adds a level of complexity many other developers do not have to worry about. Regardless of whether you are maintaining/improving software already on the market or preparing a new product for FDA submission, clean compliance is every bit as essential as clean code. Fortunately, Oriel STAT A MATRIX has a class specifically designed to get compliance right. Check out our virtual class, Medical Device Software Development Life Cycle Training.