Software as a medical device (SaMD) products are everywhere in the healthcare industry \u2014 and beyond! They play an important role in the way that doctors interact with patients, how patients manage their own health (like tracking their wellness on smartphone apps), and how hospitals function on a daily basis. But what exactly is SaMD? And what makes it a medical device?<\/p>\n
<\/p>\n
Software as a Medical Device (SaMD) is \u201csoftware intended for one or more medical purposes that perform these purposes without being part of a hardware medical device,\u201d as defined by the International Medical Device Regulators Forum<\/a> (IMDRF). Before determining if it\u2019s categorized as SaMD, first, determine if it is a medical device at all. The Food, Drug, and Cosmetic Act<\/a> defines a medical device as, \u201can instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part or accessory\u201d that diagnoses, treats, and\/or interacts with the body and is intended by the manufacturer to be used for a medical purpose. To determine if your product meets the definition of a medical device, define the intended use and indications for use of your product. Intended use is the general purpose of the device, including indications for use (the condition that the device with diagnose, treat, prevent, or cure, as well as the intended patient population).<\/p>\n The key definition for SaMD categorization is that the software cannot function as part of a hardware device. For example, a mobile app that works with glucose monitors compared to medical device software controlling a device like a ventilator.<\/p>\n Some devices carry out diagnostic or therapeutic purposes via software alone. These may be software applications used via personal computers or mobile devices. If the application\u2019s intended use meets the definition of a medical device, it is subject to regulation as a medical device. Based on the device classification, it may require FDA authorization prior to distribution in the United States.<\/p>\n In most cases, when we think about a medical device, we’re thinking about something physical. However, SaMD doesn’t have anything to do with physical objects at all; it’s purely digital! Unlike physical devices like manual stethoscopes, SaMD runs on devices like computers or smartphones.<\/p>\n Healthcare providers and other consumers use SaMD, but that isn\u2019t its sole use. Software with a non-medical functionality but carrying out functions that meet the definition of a medical device (i.e. to treat or diagnose) is still considered SaMD. SaMD products can connect to a hardware medical device, but the device cannot rely on the software to perform its intended use.<\/p>\n SaMD is used in healthcare, diagnostics, and therapeutics to improve patient outcomes. They are also used outside of healthcare settings, with a lot of SaMD applications used for wellness devices.<\/p>\n SaMD examples include:<\/p>\n Even though software products are not physical objects, they still have to follow regulatory frameworks<\/a>.<\/p>\n For a software-based medical device (SaMD) distributed in the United States to be cleared by the Food and Drug Administration (FDA), it must be demonstrated to be safe and effective as well as meet all FDA regulations. This means that any SaMD product on the U.S. market has been thoroughly tested and meets all patient safety and cybersecurity standards set forth by the government agency. These requirements include the protection of a patient\u2019s digital health records. For example, SaMD software must have patient confidentiality protections.<\/p>\n As with any medical device, submissions must include detailed design information, test data, and more. Guidance documents provide guidance on everything that must be part of the submission, if they are needed at all (some devices do not require submission to the FDA). Of course, the regulatory pathway depends on the classification of the device.<\/p>\n The first step of any regulatory pathway is to determine if your application is a medical device. Then, determine the class of that medical device. As a reminder, there are three classes of medical devices, depending on the risks associated with the device and their intended use.<\/p>\n Class I devices are low-risk to the patient. They do not support or sustain life and cannot implant into the patient. Some examples include manual stethoscopes and bandages.<\/p>\n Class II devices are medium-risk. They are slightly more complicated than class I devices but still not used in life-saving situations. Some examples include glucose monitors and dental implants.<\/p>\n Class III devices have the highest risk. They are often used as life-supporting devices and can implant into the patient. Examples include some pacemakers and ventilators.<\/p>\n A proper quality management system (QMS) is required to design and develop the device in accordance with FDA regulations and maintain compliance once the device is distributed to market. The FDA has guidance for designing and developing software in a controlled manner. These requirements involve ensuring the designed software works for its intended use, is tested for performance and patient safety, and maintains the quality procedures needed throughout its development.<\/p>\n There are different criteria<\/a> for the clinical evaluation of medical software. This evaluation is divided into three main factions.<\/p>\n Like other medical devices, software must be tested for its safety and effectiveness. This verification process includes a variety of different software tests, depending on the complexity of the software.<\/p>\n SaMD is often connected to the internet in some way, so cybersecurity controls are extremely important to protect users and their information. This cybersecurity is included in the FDA\u2019s evaluation of the device\u2019s safety and effectiveness for its intended use. Connecting SaMD to the internet allows for more universal access, but increases the risk of security breaches. Developers must ensure that their device is designed securely and risks are mitigated through the product\u2019s Total Product Life Cycle.<\/p>\n SaMD development is already complicated; don\u2019t let the process of submitting to the FDA inhibit your device. The experts at A Wright Path<\/a> can help you meet regulatory requirements so you can focus on software development. Experience a partnership that helps you gain market clearance with the quality management system and other long-term benefits to maintain your status. Schedule a consultation today!<\/span><\/a><\/p>\n","protected":false},"excerpt":{"rendered":" Software as a medical device (SaMD) products are everywhere in the healthcare industry \u2014 and beyond! They play an important role in the way that doctors interact with patients, how patients manage their own health (like tracking their wellness on smartphone apps), and how hospitals function on a daily basis. But what exactly is SaMD? […]<\/p>\n","protected":false},"author":7,"featured_media":1049,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[8],"tags":[],"yoast_head":"\nWhat Makes SaMD Unique?<\/h3>\n
Examples of SaMD<\/h2>\n
\n
Regulatory Compliance of SaMD Products<\/h2>\n
Classification of Medical Devices<\/h3>\n
Class I<\/h4>\n
Class II<\/h4>\n
Class III<\/h4>\n
Quality Management System<\/h3>\n
Clinical Evaluation<\/h3>\n
\n
\n
Testing of Software<\/h3>\n
\n
\n
Cybersecurity Controls<\/h3>\n
Find a Regulatory Partner for Your Device Approval<\/h2>\n