Software as a Medical Device (SAMD): Examples, Regulatory Guidance, and Development

The digital age has caused a paradigm shift in the field of medical research. With the constant technological evolution of healthcare and all things related, there is a rising demand for the development of applicable computer software. According to the International Medical Device Regulators Forum (IMDRF), a group that creates rules to harmonize device regulations, there are three different types of medical software:

• Software as a Medical Device (SaMD) – This software functions completely independent of devices that already exist. It can work in conjunction with other medical devices, such as analyzing pictures or data from a separate machine, but must be its own entity. (e.g., an application that monitors an EKG and alerts doctors if there’s a problem.)
• Software in a Medical Device (SiMD) – This is the software that helps a medical device to carry out its intended use. Any application built into a machine that allows it to run. (e.g., programs embedded in MRI and X-ray machines.)
• Software used in the manufacturing of a medical device – Programs or applications used in the process of developing a device intended for medical purposes. Each medical software is regulated in a different way. Software as a Medical Device (SaMD) can be confusing since it is considered to be its own product, but doesn’t fit into the same category as other medical devices.

Software as a Medical Device Regulations

The Food and Drug Administration (FDA) is in charge of monitoring any and all devices that could influence the well-being of humans in the U.S., which includes medical devices and medical software. The regulations for traditional devices depend on what class the product fits into. If you’re developing medical hardware, check out our page on medical device classifications and requirements.

The rules for SaMD are different because these programs don’t interact with patients the same way, and don’t physically break or fall apart. The FDA acknowledges the unique challenges that come with software.

The International Standardization Organization (ISO) and International Electrotechnical Committee (IEC) are two regulatory bodies that work closely to maintain standards worldwide in their respective fields. One area of overlap is in the production of medical software. Together, ISO and IEC created regulation 62304:2006 – Software Life Cycle Processes. The FDA acknowledges IEC 62304:2006 as “a consensus standard for which a person may submit a program declaration of conformity in order to meet a premarket submission requirement.” This means that while IEC 62304 approval is not the only route, it is an acceptable path to reach market clearance.

IEC 62304 and SaMD

This standard can be purchased from ISO to make the process of developing a commercial medical software significantly easier. It takes time to shape device life cycle requirements through a set of activities, tasks, and processes. Following IEC 62304 in combination with maintaining a good quality and risk management system encourages the safe design of medical software. Examples of requirements that may be applicable to software, but not other medical devices include:

• Error checks – Constant checking of input variables to make sure the software does not malfunction when given a certain code.
• Security tests – Software that is connected to a network of some kind can be at risk of being hacked or bugged, these tests confirm that data will stay protected.
• Reboot protocols – If a software does crash, there must be a quick and effective method to get it working again.

IEC 62304 serves as a guideline for developers who want to make safer software. That’s why in2being takes the standards into account when helping an inventor develop a product.

Different Types of SaMD: Off-The-Shelf (OTS) vs. Software of Unknown Provenance (SOUP)

Between IEC 62304 and the FDA there are two additional forms of software that should be mentioned–OTS and SOUP. OTS software, or off-the-shelf software, is the FDA term for any software component that’s being used by a device manufacturer that cannot claim life cycle control. SOUP, which is software of unknown provenance, is a program that’s already available, but has not been developed to integrate into the medical device. Previous software without adequate development records is also referred to as SOUP.

Software that is an available component for a medical device, like an operating system, is both OTS and SOUP. Software that is generally available but not inherently a part of the device, like an operating system that controls a sterilization process, is OTS but not SOUP. Lastly, software that is not generally available and was developed without a documented life cycle process is SOUP and not OTS.

SOUPs are treated as software components instead of a medical device, meaning it’s not regulated the same way. IEC 62304 is a process standard and does not test the quality of the finished software product. If the components are being developed according to guidelines, the end result doesn’t have to meet specific standards to earn approval. Small differences in documentation and intended use can dramatically alter the regulations that apply to a medical device. Without the help of experienced product developers, it can become extremely difficult to navigate OTS, SOUP, and IEC 62304.

Medical Device Software Development

Developing your own medical device software requires frequent documentation and attention to regulations. After creating a software development plan, you’ll have to create a prototype with extensive coding and programming. The prototype should then be tested rigorously to confirm it carries out its intended function. After compiling all the necessary information required to receive market clearance, a case needs to be submitted to the FDA for review. Product manufacturing and commercialization cannot begin until after confirmation has been received that the SaMD is safe and comparable with other, similar products.

Reach Out to in2being For Your FDA Software Guidance

Software as a Medical Device development presents specialized regulatory challenges that require ample preparation and experience. Here at in2being, we have the knowledge and resources to guide you through the steps. We can provide a solid regulatory foundation with a strong IEC 62304 software development plan that puts you on the right path.

Tailoring your SaMD development process to meet organizational regulations can be difficult if you don’t understand the language. Working with a device development firm can make the process easier while also increasing the chances of manufacturing a marketable product. For more information or guidance, contact a member of our team today.