Skip to main content
So you have a Fitbit or activity tracker? How is it going – is it helping motivate you to move more, perhaps monitoring your heart rate? That is great – but is your doctor using the data to make decisions about your health? Probably not. However, this is the kind of question we begin to ask when considering Software as a Medical Device (SaMD). By definition, these are applications (software) intended for medical use without the use of hardware (International Medical Device Regulators Forum (IMDRF) . They are not software fixed in a medical device. “Medical use” is defined as providing “diagnosis, prevention, monitoring, treatment, or alleviation of disease/injury, supporting or sustaining life” (IMDRF guidance). SaMD can include software that might interface with hardware and/or medical devices and mobile apps that meet the definition as well. This answer, while fairly specific, can leave room for interpretation. Clinical Evaluation and categorization of the SaMD can facilitate a risk-based approach to validation.
The various guidance documents produced by the IMDRF are not intended to supersede the pre and post market regulatory requirements set forth for any medical device. SaMD is a medical device. Yet, the process of Clinical Evaluation may help drive validation requirements and a risk-based approach. SaMD Clinical Evaluation is the process to assess “the analytical validity (the SaMD’s output is accurate for a given input), and where appropriate, the scientific validity (the SaMD’s output is associated to the intended clinical condition/physiological state), and clinical performance (the SaMD’s output yields a clinically meaningful association to the target use of the SaMD) of the SaMD.” IMDRF guidance). Each validity check has a specific aim and outcome. Validation is part of the process of creating confirmation of analytical validity. In practice, the already required process of computer system validation can feed into the Clinical Evaluation. IMDRF guidance even states: “analytical validity evidence of a SaMD is generated during the verification and validation activities in a manufacturer’s quality management system process and is always expected for a SaMD.” The IMDRF offers a risk categorization framework document. They define four categories. These are based on the “state of health care situation or condition (critical, serious, non-serious)” and the “significance of the information provided by SaMD to healthcare division (treat or diagnose, drive clinical management, and inform clinical management)” (IMDRF guidance). It is advisable to use this categorization to drive the risk-based process for verification and validation, particularly for the rigor of evidence gathering. The GAMP 5 process to risk-based computer system validation is likely to be of use here.
Validation of Software as a Medical Device is essentially no different than the validation of any computerized system. It is best to think of it in this way. However, one cannot simply put up “blinders” and ignore the singularity of a SaMD when assessing risk and right-sizing one’s validation effort.
