13 min read
If you’re part of a software engineering team in digital health, medtech, medical devices, Software as a Medical Device (SaMD), etc. you have to comply with regulatory standards. And one of the biggest challenges engineering leads have in this sector is figuring out what they have to do to achieve software delivery compliance.
So, to cut right to the chase, if you are looking for an automated solution to prove that your SDLC is being followed, for a tool that will integrate with your stack and gather the documentation and evidence for your test results, unit tests, code reviews etc. you should head over to our audit and compliance page.
But, if you’re here to drill into the finer points of all the various standards for medical devices, and are wondering how delivering software fits into the bigger picture, you should keep reading.
Navigating the world of compliance for medical device standards
There’s several reasons why those concerned with proving compliance for the way the actual software makes it to the actual device find the advice they’re looking for so hard to come by.
Most standards concern high level requirements and the marketplace is full of products and services designed to walk managers through the certification process for this high level stuff. Also, when software compliance is mentioned in connection with standards it is usually in vague terms that are difficult to interpret and apply to the situation you’re in.
It’s particularly hard if you are trying to align automated ways of delivering software (continuous integration, continuous testing, DevOps, Cloud, etc) with regulations that seem to relate to old fashioned ways of embedded software delivery that can be adequately managed with pen and paper record keeping.
And, when it comes to the standards themselves there’s an awful lot of terminology, acronyms, and numbers to pick through. Which parts of which standards are relevant for your company? And how do you follow them? Is it ISO 13485? MSDAP? Maybe it’s 21 CFR 11? Or 21 CFR 820? How about IEC 62304?
So, again, to be super specific, if you’re looking for automation to gather the evidence that shows you’ve done all your unit tests, code reviews, etc. - you should go here.
Software Validation v Software Verification
One of the biggest causes of confusion when it comes to discussion of standards lies in the difference between what is meant by Validation and Verification. Wikipedia has an article on it and provides the best definition:
So, validation is a high level question about requirements and building the right thing to satisfy the user’s needs. Verification is about making sure those requirements are being built correctly into the product.
Those of you specifically concerned with proving that all unit tests, code reviews, security scans, etc. have been executed before deployment are in the verification business. Understanding this distinction goes a long way to making everything else clearer.
But, let’s zoom out again and think about big picture compliance and how software delivery fits into the wider approach medical device manufacturers must take before they start writing any code. You can’t achieve compliance to any of the key standards without a Quality Management System (QMS), so let’s take a look at that.
What is a Quality Management System for medical software?
A Quality Management System (QMS) for medical software is a structured system that covers all aspects of design, manufacturing, supplier management, risk management, complaint handling, clinical data, storage, distribution, product labeling, and more. The FDA has developed the IMDRF Quality Management System for Software as a Medical Device (SaMD) framework to help manufacturers and international regulators attain a common understanding and vocabulary for SaMD.
A (QMS) documents processes, procedures, and responsibilities for achieving quality policies and objectives. It is a set of internal rules that are defined by a collection of policies, processes, documented procedures, and records.
It helps organizations drive continuous improvement, establish compliance with regulatory authorities, and ensure that quality is built into every aspect of the product or service. It helps coordinate and direct an organization’s activities to meet customer and regulatory requirements and improve its effectiveness and efficiency on a continuous basis. A QMS can be paper-based, hybrid, or entirely electronic.
Let’s look at what industry standards have to say about Quality Management Systems and what organizations need to do to ensure that their QMS is in compliance. ISO 9001 is a high level set of guidelines for defining your QMS, so let’s begin there.
How does ISO 9001 define the quality management system?
ISO 9001 defines a Quality Management System as a set of internal rules that are defined by a collection of policies, processes, documented procedures, and records. This system defines how a company will achieve the creation and delivery of the products and services they provide to their customers.
ISO 9001:2015 specifies requirements for a quality management system when an organization needs to demonstrate its ability to consistently provide products and services that meet customer and applicable statutory and regulatory requirements.
Organizations use the standard to demonstrate the ability to consistently provide products and services that meet customer and regulatory requirements.
Is software delivery compliance required for ISO 9001?
ISO 9001 does not specifically require software delivery compliance. However, the standard requires organizations to demonstrate their ability to consistently provide products and services that meet customer and applicable statutory and regulatory requirements.
However, if software delivery is part of the products or services provided by the organization, then the organization needs to ensure that the software delivery process is consistent with customer and regulatory requirements through its QMS.
The QMS should include procedures for monitoring and measuring the software delivery process to ensure that it meets the requirements. To understand what ISO 9001 means for medical devices we need to look at ISO 13485.
What is ISO 13485 based upon?
ISO 13485 is based on ISO 9001 for Quality Management Systems, which is reviewed every five years to ensure it’s always relevant. Organizations using ISO 13485 can be involved in any stage of the medical device life-cycle, including design, development, production, distribution, servicing, maintenance, and customer service.
The standard specifies requirements for a QMS where an organization needs to demonstrate its ability to provide medical devices and related services that consistently meet customer and applicable regulatory requirements.
In the latest version of ISO 13485, the standard has more explicit requirements for software validation. The standard specifies that any business wanting to achieve certification must develop procedures to validate and revalidate their quality management system software.
What is the difference between ISO 13485 and ISO 9001?
ISO 9001 and ISO 13485 are both recognized standards for quality management, but while ISO 9001 acts as the generic guideline across many industries and product lines, ISO 13485 focuses on the specific requirements for the medical device sector. Both standards emphasize the need to approach both production and business from a risk perspective and use the Plan-Do-Check-Act cycle.
ISO 13485 incorporates most of ISO 9001 within it, but there are some key differences. For example, ISO 13485 has more explicit requirements for software validation. While ISO 9001 is intended to help standardize how a QMS is designed, ISO 13485 is designed to be used by organizations involved in the design, production, installation, and servicing of the medical devices themselves and any software services related to them.
How do I validate software for ISO 13485 compliance?
Process validation is essential for medical device manufacturers, and should be considered a stand-alone discipline. ISO 13485 has specifically mandated requirements for process validation, including processes affected by computer software in production
However, there are no specific instructions on how to validate software in ISO 13485:2016, but technical reports ISO/TR 80002-2 and AAMI TIR 36 provide more explanation on things to be taken into account.
ISO/TR 80002-2:2017 applies to any software used in device design, testing, component acceptance, manufacturing, labeling, packaging, distribution, and support processes.
The validation process for ISO/TR 80002-2:2017 should cover the entire software life cycle, including design, testing, component acceptance, manufacturing, labeling, packaging, distribution, and complaint handling. The validation process should be documented, and the documentation should be maintained throughout the software life cycle
What about ISO 14971? Does it require process validation?
You may be wondering if you also have to ensure software validation for ISO 14971. It deals with the application of risk management to medical devices. It specifies a process for risk management of medical devices, including software as a medical device and in vitro diagnostic medical devices.
However, it does not specifically mention process validation as part of the risk management process. ISO 14971 focuses on identifying and controlling risks associated with medical devices throughout their entire lifecycle.
Process validation is a separate process that ensures that a product or process consistently meets its predetermined specifications and quality attributes. However, ISO/TR 80002-2:2017 (see above) provides guidance on the application of ISO 14971:2007 for the development, validation, and routine maintenance of software used in medical devices.
What is the purpose of MDSAP?
What about MDSAP? How does that fit into the overall picture? The Medical Device Single Audit Program (MDSAP) is a program that allows a single regulatory audit of a medical device manufacturer’s quality management system to satisfy the requirements of multiple regulatory authorities (RAs).
The program is designed to improve regulatory oversight of medical devices sold in participating countries and ensure that the devices meet the regulatory requirements of those countries.
MDSAP is a way that medical device manufacturers can be audited once for compliance with the standard and regulatory requirements of up to five different medical device markets, including Australia, Brazil, Canada, Japan, and the United States.
How does MDSAP relate to ISO 13485 and other standards?
MDSAP can be combined with an assessment for ISO 13485. While ISO 13485 is a standard that defines the QMS requirements, MDSAP verifies compliance with those requirements and applicable country regulations.
The MDSAP audit process includes validation of software in compliance with FDA recognized consensus standards, including IEC 62304 and our old friend IEC /TR 80002-1. To recap:
ISO/TR 80002-2:2017 applies to:
- software used in the quality management system,
- software used in production and service provision, and
- software used for the monitoring and measurement of requirements.
It does not apply to:
- software used as a component, part or accessory of a medical device, or
- software that is itself a medical device.
To ensure compliance with software not included in ISO/TR 80002-2:2017, the key stipulation is set out in FDA 21 CFR 820 which we’ll cover next.
That concludes the summary of what you need to know about the ISO standards related to medtech. Next, we want to look at the aforementioned, highly relevant section of the FDA guidelines, and the all important IEC 62304.
Compliance with FDA 21 CFR 11 & FDA 21 CFR 820
21 CFR 11 and 21 CFR 820 are regulations issued by the US Food and Drug Administration (FDA) related to medical devices. Compliance with both regulations is required for medical device manufacturers in the US
21 CFR 11 is the regulation that establishes the criteria under which electronic records and electronic signatures are considered trustworthy, reliable, and equivalent to paper records and handwritten signatures. It applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted under any records requirements set forth in FDA regulations.
21 CFR 820 is the Quality System Regulation (QSR) that specifies the requirements for a quality management system (QMS) for medical devices. The QSR applies to the methods used in, and the facilities and controls used for, the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished medical devices intended for human use.
Specifically, 21 CFR 820.70(i) states:
“When computers or automated data processing systems are used as part of production or the quality system, the manufacturer shall validate computer software for its intended use according to an established protocol. All software changes shall be validated before approval and issuance. These validation activities and results shall be documented.”
How do I achieve compliance with IEC 62304?
Ok! IEC 62304 establishes specific requirements for software verification in the medical device industry. The standard outlines the software life cycle processes and provides guidance for creating quality software systems.
The specific requirements for software verification in IEC 62304 include verifying that the software meets the needs defined in the intended use statement, identifying and mitigating any identifiable risks, ensuring that the software meets regulatory requirements, and taking into account the principles of development life cycle, risk management, including information security, verification, and validation.
The standard also requires that the software be developed in accordance with the principles of the software development life cycle. Again, go to section 5.8 to really get into technical detail on building, testing, deploying, etc. Compliance with IEC 62304 is necessary to ensure the safety and reliability of software used in medical devices. The easiest way to prove that you’ve followed your process - with all evidence to back it up - is with Kosli.
Software verification for MDR Classification Rule 11
You need to pay attention to this one if you’re operating in the European Union (EU). To comply with MDR classification rule 11, manufacturers of Software as a Medical Device (SaMD) must ensure that their products are properly classified as Class IIa or higher if they provide clinical information used for making decisions for diagnosis or treatment. Compliance with MDR classification rule 11 requires software verification and validation (V&V) to ensure the safety and reliability of the software used in medical devices.
Manufacturers can seek guidance from FDA recognized consensus standards, including - you’ve guessed it - IEC 62304, AAMI TIR45, IEC /TR80002-1, AAMI TIR 36, and FDA guidance documents to ensure compliance with software V&V requirements.
The technical documentation to be drawn up by the manufacturer must include the risk class of the device and the justification for the classification rule(s) applied in accordance with Annex VIII of the MDR.
The manufacturer must also update the clinical evaluation with clinically relevant information coming from post-market surveillance, in particular the post-market clinical follow-up. Compliance with MDR classification rule 11 is necessary for manufacturers of SaMD to ensure that their products are properly classified and regulated under the MDR.
What is software verification for IMDRF?
The International Medical Device Regulators Forum (IMDRF) is a group of medical device regulators from around the world that have harmonized the regulatory requirements for medical products that vary from country to country.
It provides guidance on software verification and validation (V&V) requirements for medical devices Compliance with software V&V requirements is necessary to ensure the safety and reliability of software used in medical devices.
The FDA requires medical device manufacturers to comply with FDA recognized consensus standards, including IEC 62304, AAMI TIR45, IEC /TR80002-1, and AAMI TIR 36, and FDA guidance documents to ensure compliance with software V&V requirements.
The IMDRF’s Working Group develops guidance that supports innovation and timely access to safe and effective Software as a Medical Device (SaMD) globally. The work is intended to identify commonalities, establish a common vocabulary, and develop approaches for appropriate regulatory controls. Compliance with IMDRF guidance on software V&V is necessary for manufacturers of medical devices to ensure that their products are properly classified and regulated under the MDR.
Conclusion
This article is intended as a high level summary of what software engineering leads need to know about compliance to various medical safety standards. But it is also meant to point them towards the easy button for compliance and audit in the software delivery life cycle.
As you can see, it’s not always entirely clear what compliance means when you have to prove that you have followed your defined process for building, testing, reviewing and ultimately deploying to a device.
The best way to remove this uncertainty, and have your software delivery in compliance with any standard, is to automate the recording of your entire software development process in Kosli.
By doing this you can see that all of your tests, scans, pull requests, etc have been done, and you can immediately export the evidence that they’ve been done to CSV. And you can do it without manual evidence gathering, paperwork, tickets systems or meetings.
Ask us for a demo or check out our case studies.
