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

Medical device manufacturers often hit roadblocks during FDA inspections or when it comes time to submit a 510(k) application for their device. Regardless of whether your device is considered software as a medical device (standalone SaMD) or software in a medical device (SiMD), there are specific steps that must be taken regarding change and risk management from the earliest stages of development to avoid running afoul of FDA requirements with respect to medical devices’ software development life cycle (SDLC). It does not matter whether your software development happens in the cloud or on-prem.

Use IEC 62304 as Your Guide to SDLC Compliance

Where to start? That is easy. The definitive guide to medical device SDLC management is IEC 62304:2006/AMD 1:2015. This international standard for software life-cycle processes provides a framework for development processes, activities, and tasks, and is also an FDA-recognized consensus standard. The 2015 version is based on IEC 62304:2006 but with significant changes related to legacy software (now must comply with IEC 62304), software safety classification, user documentation, planning, and programmable electrical medical system (PEMS) requirements from IEC 60601-1:2005. If you already have a copy of the 2006 version, this amended version contains redlines with the changes plus a complete clean version.

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:

• Chapters 1-4 – Defines scope, references, terms, and general requirements.
• Chapter 5 – Software development process. This is where the meat of the standard begins. It provides foundational knowledge on software development planning, requirements analysis, architecture design, testing, and release. This chapter is among the most important because software development planning is the most important activity.
• Chapter 6 – Software maintenance. Delves into the need to establish a software maintenance plan, a problem and modification analysis, and an implementation of modifications.
• Chapter 7 – Software risk management. IEC 62304 assumes that you have a system-level process and plan that follows the ISO 14971 risk management standard. With that in mind, IEC 62304 discusses doing analyses of software contributing to hazardous situations, risk control, verification, and risk management related to software changes.
• Chapter 8 – Software configuration management. Discusses configuration identification, change control, and status accounting.
• Chapter 9 – Software problem resolution. This section deals with preparing problem reports, investigating problems, change control processes, trend analyses, record maintenance, resolution verification, and test document contents.

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

IEC/TR 80002-1:2009 Medical device software — Part 1: Guidance on the application of ISO 14971 to medical device software

• • This guidance does not add to or change the requirements of IEC 62304, but it will be helpful when addressing risk analysis, risk control, and other related issues found in section 7 and other areas of IEC 62304.

IEC 82304-1:2016 Health software — Part 1: General requirements for product safety

• • 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.

IEC 81001-5-1:2021 Health software and health IT systems safety, effectiveness and security — Part 5‑1: Security — Activities in the product life cycle

• • This standard, released in late 2021, covers software development, release, maintenance, risk management, and problem resolution.

You may be wondering how IEC/ISO 62304 dovetails with other standards such as ISO/IEC 27001 (cybersecurity), IEC 60601-1 (electrical safety), ISO/IEC 12207 (general SDLC for software), and ISO 13485 [medical device quality management systems (QMSs)]. Annex C of IEC 62304 contains numerous comparison tables showing direct links between each standard.

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.

FDA’s New Focus on Computer Software Assurance (CSA)

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
• Recognition of ANSI/AAMI SW91 – Classification Of Defects In Health Software
• Requirement to include your software architecture in premarket submissions
• Requirement to include your entire risk management file, not just a risk analysis

In addition, the new FDA guidance document puts a heavier emphasis on risk management via ISO 14971. As you may know, draft guidance is more than a suggestion from FDA. Although not finalized, it does reflect current FDA thinking on the topic and is recommended to be followed.

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.

Get answers right now. Call