Copy to clipboard 
Ask the Expert is a series of reader questions answered by industry advisors. Send us your questions.
Question: We already have standard operating procedures (SOPs) for Design Validation and Process Validation. Which one of those SOPs does Software Validation go into?
Answered by Dan Goldstein, Associate Director for Quality Assurance, MCRA: For many medical device manufacturers, the correct answer is “both, and yet neither.” “Both,” because FDA has distinct requirements for validating the software that’s part of a medical device, as opposed to the software that is used for quality and production purposes. And yet “neither,” because most manufacturers find that it’s easier to give software validation its own separate SOP, even though it ultimately feeds into the Design Control or Production Control processes.
This article draws on two FDA guidances: “Content of Premarket Submissions for Software Contained in Medical Devices” (2005) and “General Principles of Software Validation” (2002). There’s also a well-respected international standard for medical device software, IEC 62304 Medical Device Software Life Cycle Processes. While FDA does recognize IEC 62304, the FDA guidances are somewhat more stringent, which means that following them ensures compliance. (Some might say that the FDA guidances are also more clearly written than IEC 62304.) While FDA guidances are not regulatory law but only recommendations, it can still be difficult to explain during an FDA inspection why your own unique approach is just as good as FDA’s.
If your medical device contains software – or if the entire medical device is software, like the software used to interpret radiological images – you should comply with the guidance, “Content of Premarket Submissions for Software Contained in Medical Devices.” The guidance includes a chart of recommended software validation documents, beginning with the “Level of Concern” (LOC), which is FDA’s somewhat quirky guide to determining the level of risk inherent in the software’s use. If you follow the guidance, most software validations require about 11 distinct documents. (The lowest LOC requires only 7.) The 11 documents specified by FDA are:
- Level of Concern Memo
- Software Description
- Device Hazard Analysis
- Software Requirements Specification (SRS)
- Architecture Design Chart
- Software Design Specification (SDS)
- Software Development Environment Description
- Verification and Validation Documentation
- Traceability Analysis
- Revision Level History
- Unresolved Anomalies (bugs or defects)
I generally recommend a 12th document, not specified by FDA but indispensable all the same, namely the Software Validation Plan (SVP).
Like any other quality process, your SOP for software validation should describe how you implement FDA’s recommendations in your own Quality Management System (QMS). For example, some companies combine these validation documents according to developmental chronology, while other companies use the terminology of FDA guidances together with that of IEC 62304.
Even if your medical device contains no software, software validation can be a key activity in your QMS. For example, many companies are well versed in the software required for Computer Numerical Control (CNC) fabrication or 3D printing. However, medical device manufacturers also have to account for the software that’s used to maintain the QMS. This can be as simple as an Excel macro that tracks complaint trends, or as complex as an ERP system that allows a manager’s electronic signature to automatically release a device from quarantine.
Be it simple or complex, all software validation falls under the FDA guidance, “General Principles of Software Validation.” Unlike the “Content of Premarket Submissions” guidance, the “General Principles” are more of an introduction to the topic, with a variety of approaches to ensuring software quality. Having said that, the guidance offers a distinct (and much simpler) path for validating the software that controls quality processes, as opposed to the software that’s designed into the device. The guidance, which has well over 30 pages of content, devotes only about three pages to QMS software – because that’s all that is needed.
One general caution in this regard: While QMS software is easier to validate, it’s also easier to forget to validate. Therefore, when you acquire or update software that helps you maintain quality, your QMS should have controls to remind you to validate the software before it enters use. It’s better to be reminded by those internal controls than to be reminded by an FDA inspection.
As with most quality processes, there’s no “one size fits all” for software validation. Much depends on whether the company’s own devices include software, as well as the size of the company and the structure of the processes that software validation feeds into (design control, production control, risk management, etc.). There may also be unique considerations of cybersecurity or electromagnetic compatibility (EMC). Working with internal and external experts, each medical device manufacturer should find its own least burdensome path to software validation compliance.
Dan Goldstein, CQA, is Associate Director for Quality Assurance at MCRA, LLC, a Washington, D.C.-based medical device consultancy. Mr. Goldstein has worked since 2002 in medical device QA, with experience in devices ranging from autologous blood products for wound healing to computer-aided-detection software for lung diseases. He is certified by the American Society of Quality (ASQ) as a Certified Quality Auditor (CQA), and by Exemplar Global (RABQSA) as an ISO 13485:2016 Lead Auditor and an EU MDR Auditor.
