Software as a medical device (SaMD)

Can you combine the software development lifecycle with design controls when you are developing software as a medical device (SaMD)?

Don’t forget to subscribe to our YouTube channel for more medical device quality and regulatory training. There has been a remarkable increase in the number of medical devices developed in the past few years that consist of only software. The medical device industry refers to these products as software as a medical device (SaMD). Along with the increase in the number of SaMDs on the market, there has also been an increase in the number of companies that are developing these SaMDs without any prior medical device industry experience. Medical Device Academy specializes in helping start-up medical device companies, and we see common characteristics shared by these MedTech start-ups. First, they are usually successful in demonstrating proof of concept for their software device within months. Second, the development team is typically virtual (i.e. everyone lives in a different state or even in different countries). Third, the development team does not include anyone with quality or regulatory responsibility. Fourth, the company has not implemented software design controls or started a design history file (DHF). Fifth, the company is not even aware of the existence of IEC 62304 (less expensive than other websites) –the international standard that defines the life cycle requirements for medical device software.

The above situation is quite common, but it is not a serious problem. These Medtech start-ups just need guidance on how to comply with medical device regulations without creating an overly burdensome quality system and excessive documentation. At the same time, these companies need to stay small, agile, and thrifty. Most people believe that the quality system and software documentation process slows down the development process, but the intent is to prevent mistakes and to help you plan the design and development of your SaMD so that the resulting software is safe and performs as you intended (i.e. efficacious). In order to create a quality system and software documentation process that is lean and efficient, there are some common pitfalls you should avoid.

When do you need to implement a quality system for software as a medical device (SaMD)?

When a quality system is required depends upon which market you are launching your product in first. If you are launching your product in Canada, you need a special kind of quality system certificate before you can apply for a Canadian Medical Device License (i.e. MDSAP Certificate for ISO 13485:2016). MDSAP stands for “medical device single audit program,” and there are only 16 organizations that can issue this type of certificate. If you are launching your product in Europe, you will go through your ISO 13485 quality system certification in parallel with obtaining the CE Certification of your SaMD. If you are launching your product in the USA, you do not need your quality system to be complete until after you obtain 510(k) clearance and you are ready to register and list with the FDA. You also do not need ISO certification for the US market. If your SaMD is a Class 1 device in any of these three markets, you may have fewer quality systems and regulatory requirements.

Regardless of which market you are planning to launch your product in, you should not invest in a complete quality system and then develop your SaMD. You should either develop both in parallel, or you should develop your SaMD first. The only processes that are really important to implement at the beginning of product development are 1) design controls, 2) software development, 3) risk management, and 4) usability engineering or human factors testing. You can wait to implement the other 20+ procedures until you are entering the design transfer phase of your design and development project.

Do you need separate procedures for design controls, change control, and software development?

If you are developing a complex system that includes hardware and software you should probably have three separate procedures. The reason for this is that there are different quality systems and regulatory requirements for changes to hardware and software. If you are only developing SaMD, then you can easily combine these three processes into one procedure. The video at the beginning of this blog describes how to combine these three into one procedure, but the following outlines the software documentation that should be covered in each stage of your design process:

Phase 1 – Design planning requires identification of the software risk classification (i.e. A, B, or C) in accordance with IEC 62304, and the Level of Concern (LoC) for your software in accordance with the FDA guidance for software documentation. Regardless of what the LoC is for your SaMD, you will still need to develop the documentation required for the risk classification in IEC 62304–even if the FDA does not want to review all of that documentation in your 510(k) submission. You will also need to identify the regulatory pathway for your SaMD. Your design plan will identify the team members and each person’s role and responsibility. This phase is when you should document your software development environment, create a draft software description, and create a draft software architecture diagram.
Phase 2 – Design inputs must be documented and approved in the second phase. These inputs are testing requirements. Therefore, you need to develop a testing plan for your product based upon the regulatory pathway for that product, recognized international standards or common specifications, and any guidance documents that are specific to your type of SaMD. Typically, it is recommended to review your testing plan with a regulator in a pre-submission meeting prior to conducting your verification and validation testing–especially if animal preclinical studies or human clinical studies are required. This phase is when you should conduct a hazard analysis and approve your software requirements specification (SRS). The hazard analysis should include use-related risk analysis (URRA) and cybersecurity risk analysis.
Phase 3 – Design outputs are iteratively developed during the third phase. This is typically the longest phase of your development process, and the “Waterfall Diagram” is not an accurate depiction of most software development processes. The “V-Diagram” presented in IEC 62304 is a better representation of the software development process because you continuously repeat steps as you debug your code and add functionality to your software. Only the simplest firmware is written in a linear fashion without multiple debug and retest cycles, and lean product development methods (i.e. Agile programming) are intended to be iterative. This phase of development is complete when you conduct a “design freeze” and begin your verification and validation testing. Typically, companies that are developing SaMD can complete most of their unit testing and integration testing prior to the design freeze, but system validation may not be conducted until phase 4. Unfortunately, the unit testing and integration testing can only proceed so far if you have an embedded system (i.e. software embedded in hardware). If the SaMD requires human clinical studies, that software validation is performed during Phase 4. Phase 3 is when you should be documenting your software design specifications (SDS), unit testing, and integration testing. Any formative testing required for the user interface would be done during this phase. Formative testing may include: 1) evaluating very software functions, 2) developing directions for use, and 3) developing a training program for users. You should write testing protocols for system validation and summative usability testing during this phase as well. It is important to identify all of the critical tasks related to use-related risks during this phase and document them. These critical tasks determine the summative usability testing required. It is also an excellent idea to start drafting a traceability matrix during this phase to ensure that each hazard and SRS item is being addressed in your verification and validation plan.
Phase 4 – Design verification and validation of your SaMD are completed during this phase. At the end of this phase, you should have a complete traceability matrix, you should create a summary report of your unit testing and integration testing, and you should create a system validation report–including any benchtop, animal, or human performance testing is conducted. You should also create a revision history document and a bug report identifying any known bugs in the software with a justification for why the software is safe to release with these bugs. This phase is also when you should complete your risk management file and your summative usability testing report. Finally, you need to complete a final draft of your user manual for the software that includes directions for use and the indications for use. When all of this documentation is completed, you are ready for your regulatory submission.
Phase 5 – Product release is the last phase of design and development. Once you receive 510k clearance for your SaMD, then you can begin the final release of your product. You will need to update your “splash” or “about” screen for the software to include a Unique Device Identifier (UDI). The information will need to be uploaded to the FDA’s GUDID. You can assign the DI for the UDI anytime, but the GUDID data elements cannot be finalized until you have 510k clearance from the FDA. You will also need to manage revisions of your software for this minor change and revalidate the code. This type of change will not require a new 510k, because it is a minor device modification. However, you will need to review the FDA guidance on software changes for other types of software revisions you make in the future.

Should you outsource software documentation for software as a medical device (SaMD)?

You can outsource all of your software documentation for a SaMD, but the person(s) creating that documentation will still need the documents mentioned in phase 2. If you do not provide any documentation of hazards, a software description, or a crude sketch of your software’s architecture, it will be nearly impossible for anyone to create your software documentation. It is also extremely expensive to outsource software documentation. Even if you do outsource this task, you still will need to review and approve that documentation. Most people outsource tasks because they don’t know how to do it, but it is critical for medical device companies to learn how to document their software development because they will need to maintain that documentation when the software is updated to fix a software bug or to patch cybersecurity weaknesses. Everyone that is developing software for a SaMD should receive basic training on the requirements of IEC 62304 early in your project. Your team does not need to be an expert in IEC 62304, but you need to create draft documents that you can present to experts for feedback. Your team should also review all four of the guidance documents that the FDA released for software documentation:

Creating your documentation is the hard part that your team should be doing while reviewing and editing your documentation is a great task to hire an expert consultant for your first SaMD project. This will ensure your team is writing the software documentation to the correct level of detail, and that you are not missing anything critical. Expert consultants can also provide you with templates for your software documentation.

Does software as a medical device (SaMD) require an electronic quality management system (eQMS)?

There are two types of quality systems: 1) paper-based, and 2) electronic. Most start-up companies chose the paper-based option because they don’t want the extra hassle of having to validate an electronic system. However, if your company is smart enough to validate SaMD, you are smart enough to validate software for your quality system too. The applicable standard for validation of software tools is ISO/TR 80002-2:2017. You can also purchase templates for software tool validation from Medical Device Academy. Companies are always asking for a referral of which eQMS system to purchase. The problem is that every year software has more functionality and costs less. Therefore, my general advice is to never pay more than $10,000 for eQMS as a start-up and consider starting with free database software to organize all of the documentation that is in your traceability matrix. You can migrate the data into an eQMS later by mapping your free database to the new eQMS software database.

Who should be responsible for QA and RA for software as a medical device (SaMD)?

Quality and regulatory are two different functions, and it doesn’t always make sense to have one person be responsible for both requirements. The two primary standards that are applicable to the quality assurance of SaMD are 1) IEC 62304, and 2) ISO 13485. Anyone you are considering for the position of quality manager should be familiar with both standards, and they should be making sure that your development team is documenting the software verification and validation as you proceed through the iterative software development process that is typical of Agile software development teams. The person doesn’t need to be able to code software, but they should be able to help review software documentation and suggest changes. This person’s role is extremely important to make sure that software revisions are managed properly, your software is only released when all of the validation and revalidation are complete. This person should also be able to determine if a new 510(k) is required for software modifications.

The regulatory process is the preparation of the 510k submission and communications with the FDA. This is an activity that you will probably need to perform once every two years. The FDA requirements for a 510k change more frequently than once every two years, and it is extremely difficult to become proficient when you are filling out government forms so rarely. For these reasons, it is recommended to work with an expert regulatory consultant with SaMD experience until your company has enough software products and revisions that you need to file multiple 510k submissions each year. Therefore, a less experienced quality manager can gradually learn the regulatory requirements over time and they will need less help from a regulatory consultant each year.

How do you measure quality for SaMD?

A lot of software developers struggle with identifying quality metrics if they are developing software as a medical device (SaMD). There are many aspects of software development that you can measure. Here’s a list of examples:

customer feedback
the velocity of Agile sprints
coding errors
what is the development lead time?
how fast does the software load?
technical support requests
software configuration errors
duration of software validation
software validation documentation burden
post-market surveillance of use errors
How many software bug remain?

Do you need a corporate office?

Many MedTech companies are virtual companies, but the FDA will require a physical address to visit for an FDA inspection. FDA inspectors have visited the home of the company founder at other companies, but you probably will be more comfortable with an office space for the FDA inspector to visit. The FDA is unlikely to visit your company during the first year after you initially register your product. An inspection is more likely in the second year after initial registration and listing. Therefore, you might consider renting a co-working space where you can reserve a conference room if an FDA inspector visits. If you don’t have the funds to afford rent until after you launch your product, don’t worry. FDA inspectors are unlikely to visit so soon, and if they do–just relax and be honest about the situation. You are not alone.

About the Author

Robert Packard is a regulatory consultant with 25+ years of experience in the medical device, pharmaceutical, and biotechnology industries. He is a graduate of UConn in Chemical Engineering. Robert was a senior manager at several medical device companies—including the President/CEO of a laparoscopic imaging company. His Quality Management System expertise covers all aspects of developing, training, implementing, and maintaining ISO 13485 and ISO 14971 certifications. From 2009 to 2012, he was a lead auditor and instructor for one of the largest Notified Bodies. Robert’s specialty is regulatory submissions for high-risk medical devices, such as implants and drug/device combination products for CE marking applications, Canadian medical device applications, and 510(k) submissions. The most favorite part of his job is training others. He can be reached via phone at 802.258.1881 or by email. You can also follow him on Google+, LinkedIn, or Twitter.