Software as a Medical Devices: Definition & Scope of Regulations

By Dileep Gupta

8. min read

Last update on: June 7, 2021

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 market size 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.

Need-of-Software-in-Medical-Devices

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.

* 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 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.

Table of Content

What is Software as A Medical Device?

IEC-62304-Framework

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.
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

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

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

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

SaMD types landscape

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 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:

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

Conclusion

Healthcare app development companies in USA currently developing software to be used in connection with medical devices, or as a standalone medical device, should be aware of these changes and make sure to implement the measures to ensure their software is compliant with the new regime.

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 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.