Defining SaMD

Medical device software was traditionally a standalone piece of code, serving two diverse purposes – medical and non-medical. To aid the classification of Software as Medical Device, the International Medical Device Regulatory Forum, a voluntary association of global healthcare regulators, first defined the term ‘Software as a Medical Device’ as a software that is

• Intended to serve a medical purpose or functionality
• Performs this function without being part of any hardware device

The other type of medical device software is ‘software in a medical device’ – like the device drivers, firmware, connectivity applications, and other system software packages.

So, what defines a medical purpose? Here are some key examples

• Investigation and diagnosis of a physiological condition like diseases and injuries.
• Treatment and mitigation (of diseases), or alleviation (of injury)
• Prognosis/prediction of physiological condition

Medical purposes may also include

• Monitoring of body vitals, e.g., heart rate, blood oxygen, and life support
• Disinfection of medical devices
• Assisting and control of conception/fertilizationg., for in-vitro fertilization or IVF

SaMDs are categorized based on

1. Significance of information output that aids medical decisions
   1. To diagnose disease, treat/mitigate by connecting data streams from another diagnostic or therapeutic device
   2. To drive enhanced use of medicine, risk prediction for disease, definitive diagnosis, early detection of disease
   3. To inform treatment options, provide aggregated patient medical history information
2.  Criticality of condition addressed
   1. Critical, life-threatening
   2. Serious health impact but not life-threatening
   3. Non-serious

SaMD use cases and where AI/ML technologies add value?

Some types of SaMD can support remote monitoring for in-patient and out-patient use cases for data collection and management for clinical efficiency and productivity. These would involve sensor data acquisition, connectivity, cloud integration, and user application development. AI/ ML technologies can be used in SaMDs for supporting diagnostic (imaging as well as non-imaging) and prescriptive use cases, often using aggregated multi-modal data. Here are some examples.

1. Analyzing image data streams from diverse modalities like MRIs, X-ray scans, and CT scans to detect and diagnose physiological conditions, abnormalities
   1. Detecting symptoms of distinct types of acute stroke or meningitis in brain MRI scans to help initiate the proper treatment early
   2. Categorizing malignant or benign lesions based on maps of growth patterns into the adjoining skin
2. Analyzing non-image data streams like audio and biochemical test data
   1. Spotting interrupted breathing while sleeping from sound captured via the microphone of a smart device
   2. Projecting outbreaks of pandemics attributed to mutating pathogens from immunoassay data at a macro level
3. Analyzing heterogeneous medical history data to aid decisions for an individual, group, or population at large
   1. Predicting the risk score for developing disease and prescribing time-critical treatment for
      1. life-threatening or disability causing conditions like strokes
      2. non-critical conditions like migraine

What are the critical components of these SaMDs

Like any other AI and machine learning application, these SaMDs are broadly comprised of

• Data management pipeline for preprocessing and tuning data across modalities
• Algorithm training, including feature extraction
• Inferencing, interpretability, and evaluation

In January 2021, the FDA published an action plan for SaMDs covering good design practices. It also plans to publish guidance for SaMD design and development considering patient safety. The action plan covers the following considerations for the manufacturers and providers to consider.

1. SaMD Pre-Specifications – These describe ‘what’ changes the provider/manufacturer anticipates as the algorithm learning occurs. These changes could be to algorithm performance, inputs, or intended use of the SaMD in scope.
2. Algorithm Change Protocol (ACP )– Once the scope and quantum of anticipated changes are identified, the ACP specifies the steps to be followed to ensure patient sfety and device effectiveness. These include monitoring and even controlling for mitigating any significant performance loss of the SaMD and subsequent risk to the patient’s health.
3. Good Machine Learning Practices – These practices span across the SaMD solution components mentioned above, from data management to inference. They are intended to ensure the development and oversight of cutting-edge technologies used in these SaMDs – particularly with many ML methods being very opaque in terms of their inner workings. The FDA is working with other regulatory organizations, industry bodies, and standards organizations to define these practices for the manufacturers of AI/ML-based SaMDs.
4. Patient data transparency and security – There needs to be a clearly labeled indication that the SaMD employs AI/ML technologies that evolve and the end-use of its output. Patient engagement over these issues is imperative to drive adoption for the AI/ML based SaMDs.
5. Managing algorithm bias and robustness – Healthcare data has numerous demographic parameters that impact the overall delivery of health services. There is a possibility that training using this data unintentionally introduces these biases into the algorithms for AI/ ML based SaMDs. SaMD providers need to incorporate methods that eliminate or neutralize such bias from the solution specifications. Numerous industry and academic groups are working on enhancing these methods for SaMD applications.

In subsequent parts of this series, we explore the regulatory framework that are shaping up for these cutting-edge healthcare offerings.

eInfochips, an Arrow company, is a leading product engineering services provider with extensive experience in building innovative connected healthcare solutions across the device-connectivity-cloud continuum. We have strong expertise in developing FDA class II/III device and data solutions for diagnostic, therapeutic, telehealth, and remote patient monitoring applications.  For more information, please contact our extperts today.