Software as a Medical Devices: Definition & Scope of Regulations

Since the past 40 years, the number of technology innovations both within and around medical devices have increased dramatically. Especially, the past 20 years have witnessed an acceleration in the sector, thanks to the Internet of Things and rise of its other corresponding parts like wireless connectivity, cloud computing, and AI, etc. These advancements have transformed the healthcare processes.

Even after 20 years, these leading-edge technologies are continuing to source a seismic shift in the process of healthcare administration and delivery. 

And now, mobile applications have also seeped in and have become an important part of these highly demanded, technology-based medical and non-medical purposes.

These apps or software are a medical device on their own, what we call Software as a Medical Device (SaMD) have grown to become an inherent part of the users’ life. The applications of SaMD are not just limited to diagnosis but have also made their place in the monitoring and treatment process. In fact it is SaMD that has led to the evolution of healthcare 1.0 to healthcare 3.0.

Seeing the growing inclusion of  SaMD in everyday healthcare, the international medical device regulators forum (IMDRF), of which the US FDA is a member, have described the concept and SaMD risk categories in detail for the medical app development industry to follow.  FDA software as a medical device has developed and clarified risk-based policies for better requirements communication and aligned its regulatory approach with the evolving nature of digital devices.

In this article, we are going to throw some light on SaMD, software as a medical device regulation, and mHealth app types and other types of medical software which are categorized as Software as a Medical Device. 

What is Software as A Medical Device?

The terminology – Software as a Medical Device stands for any software that is intended for use for one or multiple medical purposes and which performs these purposes without being integrated into a hardware medical device.

Here’s how IMDRAF defines SaMD – 

“The term “Software as a Medical Device” (SaMD) is defined as software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

How to Know if Your Mobile App is a SaMD?

The most obvious way to label a mobile app as a SaMD is to use it as its intended purpose. FDA approves if an app is utilized in the cure, detection, treatment, mitigation or prevention of diseases, it must be considered as a SaMD. 

For instance,a glucose monitoring app collects blood-sugar level data and saves it on the cloud. Another app that provides EKG data; if its intended purpose is to monitor irregularities in EKG data, then it is a medical device. 

Besides, with FDA approved documentation, below are the primary criteria of SaMD:

• SaMD is a medical device and includes some in-vitro diagnostic (IVD) medical devices. 
• It is able to run on general purpose (non-medical) computing platforms.
• Software does not meet the definition of SaMD if its intended purpose is to drive hardware medical devices. 
• It may be used with other products such as medical devices.
• It may be interfaced with other medical devices, including hardware medical devices and other SaMD software, as well as general purpose software.

Factors to Consider for SaMD Characterization

The first part to understand when it comes to characterizing SaMD is defending its statement. The key takeaway is that the definition statement forms a critical part of the basis of how SaMD are characterized. This means the characterization is heavily based on the information offered by SaMD. There are two ways through which SaMDs are characterized:

Information provided by SaMD

• To diagnose or treat patients
• To inform clinical management
• To drive clinical management

Healthcare Condition

• Critical condition
• Serious condition
• Non-serious condition

Once the information is defined on the basis of the above characterizations, SaMDs are divided into four categories- starting from I to IV.

Referring the above diagram, if the medical situation warrants a II and III categorization, then your medical device is a III. This also represents the entire lifecycle of a SaMD. 

What Are Examples Of Software As A Medical Device?

•  Software as a Medical Device can be interfaced with other medical gadgets, including hardware medical gadgets, and other software as a clinical device, also as a general use software. Software that gives boundaries becomes the input for a different hardware equipment or other SaMD. For instance, software as a medical device example can be therapy planning software that provisions data utilized in a linear accelerator is SaMD.
• For instance, software that is expected for analysis of a condition utilizing the tri-axial accelerometer that works on the installed processor on a consumer digital camera is viewed as Software as a Medical Device.
• Software that is connected with a medical hardware device but it isn’t required by that device to accomplish its medical purpose is Software as a Medical Device and not an accessory to the medical device.
•  SMD software is able to run on general purpose (i.e. non-clinical reason) computing platforms. These software running on these general purpose computing platforms could be situated in a hardware medical gadget.

Category Wise Examples of SaMD

As discussed above, the top IV categories of a SaMD are further explained below: 

Category IV:

• SaMDs which perform diagnostic image analysis for enabling treatment decisions when patients suffer an acute stroke
• SaMDs which calculate the fractal dimension of a lesion and build a structural map which reveals different growth patterns for providing diagnosis or identification if the lesion is benign or malignant.
• SaMDs combine data from the immunoassays to screen for mutable pathogens outbreak that can be highly communicable.

Category III:

• SaMD which makes use of the phone’s microphone for detecting interrupted breathing during sleep.
• It is used for providing information by clicking pictures, monitoring growth or other data to supplement other information that a healthcare provider uses for diagnosing if a skin lesion is benign or malignant. 

Category II:

• SaMDs that analyzes heart rate.
• SaMD which uses individuals’ health record data for predicting the risks of heart disease or stroke and create prevention strategies.
• SaMD which integrates and analyzes multiple tests to offer recommendations for diagnosis in certain clinical indications. 

Category I:

• Software medical Devices which gathers data from symptom diaries for providing information to gauge  occurrence of an asthma episode. 
• Software medical Devices analyzing images, movement of the eye for guiding the next diagnostic action for astigmatism. 
• Softwares which stores historic blood pressure information for health care providers to review. 
• Softwares using data of hearing sensitivity, speech in noise, and asking users to answer questionnaires about common listening situations for self-assessing hearing loss.

How Do You Classify Software As A Medical Device?

The new EU MDR (The European Union Medical Device Regulation) gives definitions, rules, classifications, and procedural necessities for medical device software standards.

The EU MDR Annex VIII talks about various software as medical device classification rules.

Rule 11 in Annex VIII relates to classification of software and specifically addresses classification of software used alone or in combination with medical devices.

Software planned to provide data which is utilized to make choices in terms of diagnosis or therapeutic purposes is classified as Class IIa, aside from if such choices have an effect that may cause death or an irreversible deterioration of an individual’s health. In such cases it is in Class III or a serious deterioration of an individual’s health condition or a surgical intervention, in which case it is classified as Class IIb.

Software expected to screen physiological processes is delegated as Class IIa, with the exception if it is proposed for observing essential physiological parameters, where the nature of varieties of those parameters is such that could bring about immediate threat to the patient, in which case it is named Class IIb. All other remaining software is delegated as Class I.

For instance, software used to screen heart rates or some other physiological parameters during a routine checkup is delegated as Class IIa. If by any chance the monitoring focuses on imperative physiological parameters, and where those parameters could bring about an immediate peril to the patient, the classification is raised to Class IIb.

What Can SaMD Manufacturers Do To Ensure Regulations?

SaMD companies should have a good Quality Management System incorporated into the development process to ensure compliance with any regulation. The chosen QMS platform should be capable of compliance with regulatory requirements like the FDA 21 CFR Part 820 and ISO 13485:2016. 

Any misstep in the direction can lead to severe consequences with your application getting banned being only the tipping point. Noting the cruciality, it is advised that you should partner with a healthcare app development company who works alongside medical practitioners who understand these regulations and compliances to their entirety. 

How can Appinventiv help you with healthcare software development?

Appinventiv specializes in offering top custom software development services that enables fast paced healthcare ecosystems with advanced digital solutions. From clinical management to advanced healthcare products and software, we help organizations implement innovative health strategies in their business.  

For instance, Appinventiv crafted a custom app solution called YouCoMM to provide real time access of medical help to in-hospital patients.  

Our team of medical software development has also created the very first resonant frequency based personal wellness system called Soniphi. Soniphi is a patient engagement platform that ensures every patient receives a remote monitoring care plan. 

Talk to our experts to get a customized SaMD aligned with your business needs. 

FAQs About SaMD

Q. What are examples of software that are not SaMD?

• Apps that hardware medical devices need for performing its role.
• Apps which are dependent on the medical device data.
• Apps that enable communication and streamlining of clinical workflow, like ones for scheduling visits, video or voice calling, etc  

The app examples are not limited to these. There are a number of other app types which do not fall under the definition of SaMDs.

Q. What can Software as a Medical Device actually do?

A.SaMD applications are those which act as a stand-alone health application that gives users the insight into their physical health by making diagnosis, doing X-ray processing, or calculating insulin doses.

Q. What is IEC 62304?

A. IEC 62304 is a standard that specifies the life cycle requirements needed for the creation of Software as a Medical Device and Software within medical devices. When used along with ISO 13485, it offers a framework that is important for safe designing and maintenance of medical device software.

Q. Describe your QMS process for medical device software development

A.We have our own internal QMS for working with medical device and pharmaceutical clients, to ensure our own quality. We do not get audited by clients, third parties, or regulators.

Stage 1 : Initiate Project: Conduct a kick-off teleconference with Client to:  

• Review the project plan and timeline
• Finalize key sources of information 
• Define the project team 

Stage 2 : Review Documentation: Evaluate and examine all relevant documents including existing product information, nonclinical data/plans, and regulatory documentation.  The sources of this information are: 

Non-clinical data, regulatory correspondence, product technical specifications, references to predicate devices, proposed product claims and intended/indications for use, etc.  

Stage 3: Determine Regulatory Pathway Using information from above section, Develop an FDA regulatory path determining whether 510(k) or de novo is most appropriate (a PMA regulatory strategy is more complex and will require a higher budget).  The goal will be to advise clients on the optimal approach to FDA.

THE AUTHOR

Dileep Gupta

DIRECTOR & CO-FOUNDER