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)?

What is software as a medical device (SaMD)?

Prior to 1996, most medical devices did not include software. The devices that did have software were called electrical medical devices. Electrocautery devices, multi-parameter monitoring systems, and laparoscopic imaging systems are examples of electrical medical devices. However, when radiographic imaging systems began using digital sensors, the medical industry also started developing software to display, manipulate, and measure DICOM images. Those stand-alone software imaging tools were called software as a medical device (SaMD), because there was no electrical medical device sold with the software. To help differentiate the types of software, software in electrical medical devices is now called software in a medical device (SiMD). Then medical device companies began to develop algorithms to predict and diagnose for other types of data. Next artificial intelligence and machine learning was used to accelerate algorithm development. Now the field of software medical devices has exploded.

Along with the increase in the number of SaMDs on the market, there has also been an increase in the number of start-up medical device companies that are developing SaMD products.

Five characteristics of most SaMD start-up medical device companies

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 –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 following outlines the software documentation that should be covered in each stage of your design process:

Planning (Phase 1)

Design planning requires identification of the software risk classification (i.e. A, B, or C) in accordance with IEC 62304, and the software documentation level (i.e., Basic or Enhanced) for your software in accordance with the FDA guidance for software documentation. Regardless of what the software documentation level 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. You plan should also reference your software development procedure and describe the software development environment.

Basic or enhanced documentation 1024x633 Software as a medical device (SaMD)
FDA eSTAR Screen Capture

Requirements (Phase 2)

This phase is when you should document you create a draft software description and create a draft software architecture diagram. The software requirements specification (SRS) must be documented in the second phase, but you should anticipate revisions as the project progresses. Software requirements should include data hazards, use specifications, security risks, and all of your test requirements. Typically, it is recommended to review your testing plan for verifying performance 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.

Specifications (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 the 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 usability testing during this phase as well. To help you prepare those protocols you will need to prepare a use-related risk analysis (URRA) and a cybersecurity risk analysis first. It is also an excellent idea to start drafting a software traceability matrix during this phase to ensure that each data hazard and SRS item is being addressed in your verification and validation plan.

Screen capture of Summative Protocol Template 1024x789 Software as a medical device (SaMD)

Verification & Validation (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.

Software documentation attachments for an FDA eSTAR 1024x501 Software as a medical device (SaMD)

Regulatory Review (Phase 5)

The last phase of design and development process for software as a medical device (SaMD) is the regulatory review. The FDA review process involves the following sub-steps:

    1. Technical Review: Days 1-15
    2. Substantive: Days 16-59
    3. FDA Decision (AI Hold or Interactive Review): Day 60
    4. Additional Information (AI) Hold: Up to 180 days
    5. Interactive Review: Days 61-89
    6. FDA SE Decision: Day 90

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:

  1. General Principles of Software Validation (2002)
  2. Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (2005)
  3. Content of Premarket Submissions for Device Software Functions (2023)
  4. Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (2023)
  5. Postmarket Management of Cybersecurity in Medical Devices (2016)
  6. Off-The-Shelf Software Use in Medical Devices (2019)

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 three types of quality systems: 1) paper-based quality systems, 2) virtual quality systems, and 3) an eQMS. Most start-up companies choose the virtual QMS option (i.e., #2) because they don’t want the extra cost of an eQMS. Some companies are afraid to abandon paper records, because they don’t want to validate record storage (i.e., Dropbox) and electronic signature software (e.g., DocuSign). However, if your company is smart enough to validate SaMD, you are smart enough to validate a virtual QMS 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. If you would like to read our evaluation of the most popular eQMS software for medical device companies, please enter a request in our Suggestion Portal.

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:

  1. Customer feedback
  2. Velocity of Agile/Scrum sprints
  3. Coding errors
  4. What is the development lead time?
  5. How fast does the software load?
  6. Technical support requests
  7. Software configuration errors
  8. Duration of software validation
  9. Software validation documentation burden
  10. Post-market surveillance of use errors
  11. How many software bugs 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top