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 which are a medical device on their own – Software as a Medical Device – have grown to become an inherent part of the users’ life. The application of SaMD are not just limited to diagnosis but have also made their place in the monitoring and treatment process.

Seeing the growing inclusion of  SaMD in the everyday healthcare, The International Medical Device Regulators Forum have described the concept and SaMD risk categories in detail for the medical app development industry to follow. 

* SaMD is not the only compliance that healthcare industry stakeholders – mHealth applications entrepreneurs and device manufacturers should follow. There are other compliances as well, such as FDA, HIPAA, HL7, and FCPA. We have touched upon these compliances in much detail in our mHealthcare App Development Guide. 

In this article, we are going to throw some light on what is SaMD, the regulations that it entails, and what mHealth app types 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

• SaMD is a medical device and includes some in-vitro diagnostic (IVD) medical device. 
• SaMD 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 device. 
• SaMD may be used with other products such as medical devices.
• SaMD 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

There are two ways through which SaMDs are characterized:

A. Information provided by SaMD

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

B. Healthcare Condition

• Critical condition
• Serious condition
• Non-serious condition

On the basis of these characterizations, SaMDs are divided into four categories. 

[table id=35 /]

Category Wise Examples of SaMD

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 builds a structural map which reveals different growth patterns for providing diagnosis or identification if the lesion is benign or malignant.
• SaMDs combining data from the immunoassays to the screen for mutable pathogens outbreak that can be highly communicable.

Category III:

• SaMD which makes use of phone’s microphone for detecting interrupted breathing during sleep.
• SaMD 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 use individuals’ health record data for predicting the risks of heart disease or stroke and create prevention strategies.
• SaMD which integrate and analyze multiple tests to offer recommendations for diagnosis in certain clinical indications. 

Category I:

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

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 knowledgeable mHealth app development company who works alongside medical practitioners who understand these regulations and compliances to their entirety. 

FAQs About SaMD 

Q. What are examples of software that are not Software as a Medical Device?

1. Apps that hardware medical devices need for performing its role.
2. Apps which are dependent on the medical device data.
3. 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?

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?

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

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 Client on the optimal approach to FDA.