The Essentials: Regulatory requirements for medical device software

Post Views: 844

Summary of Key Point

  • The key to address medical device software regulation starts with three questions: What does your software do? How do you plan to build it, and to test it?

  • Requirements are the cornerstone for building and maintaining software throughout its lifecycle.

  • The objective of regulatory agencies is to give a fair assessment whether your medical software is safe and it does what it‘s intended to do.

From connective care devices to EMR systems, software is often an integral part of medical device technology, and even a medical device itself sometimes. The key to fully address medical device software regulation starts with three questions:

  • What is your software intended to achieve (aka requirements)?

  • How do you plan to build the software (aka implementation)?

  • How do you plan to test your product (aka verification & validation)?

Guidance of Software Validation from the FDA, and IEC 62304 Medical Device Software Lifecycle Process are considered as the benchmark to review medical device software. These documents guide the development and maintenance through the lifecycle of the software within a quality management system. We suggest you to follow steps below:

1. Identify your software is a medical device or not.

According to the FDA, your software is likely a medical device if:

  • The software is used as a component, part, or accessory of a medical device

  • The software itself is a medical device (e.g. blood establishment software)

  • The software is used in the production of a device (e.g. programmable logic controllers in manufacturing equipment)

  • The software is used in implementation of the device manufacturer’s quality system (e.g. software that records and maintains the device history record)

You can also refer to the guidance document provided by CE Mark, including qualification criteria and the step-by-step procedure for medical device identification.

2. Identify classification of your software and understand how to approach the regulatory submission.

Under IEC 62304 the manufacturer shall assign software safety class (A, B, or C) to each software system according to the possible effects on the patient, operator, or other people resulting from a hazard to which the software system can contribute. Under FDA regulation, similar software safety class can be seen (Major, Moderate, or Minor level of concern). Depends on the software safety class, you might be required to provide extra software documentations to demonstrate that potential hazard during the software life cycle is fully addressed and sufficiently mitigated.

3. Think about how to design the software appropriately.

Good software is always built on well-defined requirements. Translating user requirements to software requirements requires iterative review among various stakeholders; unfortunately, this process is often overlooked by the manufacturers.

4. Determine what part of the modules or tools need validation early in development.

Software level of testing consists of unit, integration, system, and acceptance testing. Each test case should include a user case scenario, its respective acceptance criteria, and the test result. Developers and testers typically work together to come up with testing strategy that identifies the most vulnerable portion of the software and design test cases to eliminate any faulty behavior. Tools used to develop software such as compilers, open-source libraries, known as Software of Unknown Provenance (SOUP) or Off-the-Shelf software (OTS), require validation as well.

5. Think about what to include in the submission, and merging with design control and quality system of your organization.

When preparing an application, keep in mind that the objective of regulatory agencies is to give a fair assessment whether your medical software is safe and it does what it intends to do. Incorporating software validation steps with quality system of your organization is as important as the developing of the application itself.

Some other guidance documents worth looking into, depending on your product:

  • Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices

  • Guidance for Industry Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software

  • Content of Premarket Submission for Management of Cybersecurity in Medical Devices

  • Applying Human Factors and Usability Engineering to Medical Devices

  • Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices

Rook Quality System is experienced with software validation and testing during the initial design control through the final code freeze. Check back in May for a follow up blog post on Software Risk Management!

About the Author

Andrew Wu, Software Consultant at Rook Quality Systems.

“Working at the intersection of project and quality management, I believe better practice in software development and computer system validation can greatly benefit companies who are trying to put their novel medical technology in the hands of providers or patients”.

#medicaldevicesoftware #softwarevalidation #FDA #IEC62304 #softwaretesting

Back To Top