Software-as-a-Medical Device: Another Leap towards Making Healthcare More Efficient and Effective

Technology has revolutionized the domain of healthcare with innovation in products and services enabling better healthcare and management. As specimens of technological innovation, medical devices have had a substantial impact and have evolved in functionality and usability.

Medical devices have evolved historically that range from:

• Acoustical – Stethoscopes, Ultrasound imaging
• Electrical signal based – ECG, EEG & Pacemakers
• Electromagnetic – X-Ray, CT scan, etc.

A specific goal of “Patient care with Safety & Accuracy”, led regulations to come into place, and concerning regulatory bodies formed risk-based classification. FDA, US based federal agency, made three distinct classes (Class I, Class II, and Class III) of devices based on the risk and handling by medical professionals.

With the rapid evolution of software and a flood of capable hardware on the market, medical devices were able to leverage the generic hardware to execute their functionalities. It enabled the users to utilize their own devices (BYOD model) and simplified procedure by separating the output and complex processing from the core medical hardware. As such, these software or Software as Medical Devices (SaMD) have achieved considerable popularity in time.

The International Medical Device Regulators Forum (IMDRF) has laid down specific guidelines that define SaMD:

• SaMD is compatible with general-purpose non-medical platforms.
• The software is not considered SaMD if it is intended to drive medical device hardware, usually, embedded software.
• SaMD can interface with other SaMD, hardware of other medical devices, and general-purpose software.
• SaMD is defined by the International Medical Device Regulators Forum (IMDRF) as “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”
• In general, input data source for SaMD could be medical devices, lab results,  medical images, IVD instrument results, vital signs, medication, patient demography, allergies etc. and SaMD can have algorithm to process this (with reference data) and provide output that could be used for medical purpose (Inform, Drive, Diagnose, Treat).

 

Examples of applications that can be classified as SaMD include a Windows desktop application for Sleep Disorder, Android and iOS applications for diabetic care, various therapies, and image transfer from an ultrasound device to the practitioner. In addition to assisting “core” medical devices, SaMD has evolved to newer areas of utility such as:

Viewing Therapy adherence: The data from an end medical device is pushed to a smart device and then to the cloud, where a health care practitioner can view the details. The SaMD resides on a generic device like a smartphone along with the cloud. This is a classic case of BYOD (smartphone) for the patient.

Processing raw data from medical devices: If we take EEG as an example, while the neuro device captures raw data from the patient and pushes to a desktop (generic hardware). The hosting application on desktop filters out unwanted noise and provides the right EEG waveform.

Telemedicine: With intelligent gadgets that can be worn by patient/users to get their vital signs that can be pushed to the cloud, and in scenarios where a small clinic can share data with expert medical practitioners to get their opinion and advice by sharing patient medical reports in secure manner, it has enabled improved patient care with early warnings and better guidance on treatments. 

While the concept of a SaMD has caught on, it comes with its own obvious set of challenges typical of a standalone software product:

• Dealing with host OS upgrades: It includes the failsafe methods of rigorous testing that includes the gamut of platforms. There should also be a smart notification mechanism that intimates users about possible errors and bugs.
• Bug-fixing and processing feedback: It is mandatory to get and consider valuable feedback on the SaMD program regularly. Constant product upgrade based on feedback is a robust mechanism to keep issues at bay.
• Issue resolution TAT: The cycle “time to correct” support needs to be fast and accurate.

The basic principles of developing SaMD programs should adhere to the International Standard IEC 62304 framework to accommodate the changes.

The risk-based decision model is to be adopted with the following major principles:

• Risk management
• Quality management
• Methodical systems engineering according to the best industry practices
• Follow SWEBoK guidelines

An appropriate level of change control needs to be maintained with special considerations for:

• Socio-technical environment – User skills; safeguard against issues arising from integrating with real-world clinical workflows
• Technology and system environment – Hardware, Network, or Software; lack of SaMD control
• Information security with respect to safety considerations – Information privacy management

Besides, other change scenarios to be considered are:

• Adaptive
• Corrective
• Perfective
• Preventive

SaMD has a shorter TAT in case of rectifications of glitches. TAT can be further shortened through pre-certification programs launched by the FDA.

The degree of challenges can be explained with two distinct scenarios where ownership has to be rolled-back to the SaMD owners. These are:

• Simple Use case – This scenario involves two SaMD (on-cloud and on-premise) owned by a single manufacturer. Here the ownership is well defined.

• Complex Use case – This scenario involves two SaMD (on-cloud and on-premise) owned by two manufacturers. This is becoming increasingly common due to the rapid adoption of cloud platforms.

The FDA can choose to “pre-certify” a set of digital health operators that demonstrate quality and excellence based on objective criteria including software design, development, and testing. Pre-certified developers can market the lower-risk SaMD without additional FDA review. The principles of excellence observed for it are:

• Product Quality – Exceeding expectation in development, testing, and maintenance of SaMD

• Patient Safety – Emphasizing patient safety as a critical factor across decision-making parameters
• Clinical Responsibility – Conducting clinical trials responsibly and addressing patient-centric issues like labeling and human factors
• Cybersecurity Responsibility – Proactively addressing cybersecurity issues by actively engaging with stakeholders
• Proactive Culture – Continuous learning through proactive surveillance and user need assessment

FDA Pre-certification Levels

There are two levels of FDA pre-certification for software based on the level of risk associated with it:

Level 1 Pre-certification – This level of certification allows organizations to develop and market certain lower-risk software without FDA review. This is awarded to organizations that have demonstrated excellence in product development across all five Excellence Principles, with a limited track record in developing, delivering and maintaining products. This may benefit organizations that have limited or no experience in delivering software products. At the same time, they would exhibit organizational elements and strategies indicating they possess the potential to deliver high-quality lower-risk SaMD that are both safe and effective.

Level 2 Pre-certification – This level of certification allows organizations to develop and market certain lower and moderate risk software without FDA review while a streamlined review for other types of software may be required. This is awarded to organizations that have demonstrated excellence in product development across all five Excellence Principles, with a proven track record in developing, delivering and maintaining products. This may benefit  organizations with considerable experience in delivering software products that suggest a level of assurance in the development of safe and effective lower to moderate risk SaMD.

Four distinct categories of SaMD are identified wherein the importance of the SaMD-generated information determines the category. The categories are listed based on decreasing level impact on the patient depending on the accuracy of the provided information:

• Category IV – Provides information for the treatment or diagnosis of diseases or conditions that are critical and are considered “very high impact”
• Category III – Provides information for the treatment or diagnosis or clinical management of diseases or conditions that are serious and are considered “high impact”
• Category II – Provides information for the treatment or diagnosis or clinical management of diseases or conditions that are non-serious and are considered “moderate impact”
• Category I – Provides information for the clinical management of diseases or conditions that are non-serious and are considered “low impact”

Significance of the SaMD-generated information in healthcare decision making

State of Healthcare

Treatment or Diagnosis

Facilitate Clinical Management

Inform Clinical Management

Critical

IV

III

II

Serious

III

II

I

Non-serious

II

I

I

 

Any SaMD that can be used across multiple healthcare-related situations or conditions as per the manufacturer's statement is classified at the highest category according to the definition of SaMD.

SaMD has been constantly evolving, especially in recent times, and so has been its scope in healthcare. Smartphone usage and the adoption of the cloud platform have been among the chief drivers of technology adoption. It has also led the medical device manufacturers to leverage generic hardware for processing and display. With a substantial increment in adoption, it becomes paramount that better regulations are applied to facilitate faster TAT and benefit the patients. SaMD manufacturers, on the other hand, will (and must) strive to stay updated on the constantly evolving regulations to adapt their offering accordingly.