Software as a Medical Device (SaMD)

‍Software as a Medical Device (SaMD), or software regulated as a medical device, is software that functions as a device in its own right, separate from any physical hardware, or to software that is an integral, regulated component of a medical device system.

SaMD is defined by its application: ISO 14971 specifically notes that the standard is intended to apply to software as a medical device (SaMD), as well as in vitro diagnostic devices (IVD). In essence, SaMD is a software application or component whose primary purpose is medical (e.g., diagnosis, monitoring, therapy calculation) and is therefore subject to the same rigorous quality and risk requirements as physical medical devices.

Software is increasingly recognized as a critical component in the medical field, and regulators globally have increased scrutiny on software quality and safety.

Examples of Regulated SaMD (or Software-Heavy Devices)

Here are examples of devices regulated primarily due to their software component and algorithms:

Digital Therapy Devices: These are prescription devices that provide a computerized version of therapy (behavioral therapy, cognitive function assessment) intended as an adjunct to treatment for conditions such as gastrointestinal conditions, psychiatric disorders, or Attention Deficit Hyperactivity Disorder (ADHD).

Diagnostic Algorithms:

• Retinal Diagnostic Software Device—a prescription software device that uses an adaptive algorithm to evaluate ophthalmic images for diagnostic screening.
• Radiological Computer Aided Triage and Notification Software—an image processing prescription device intended to aid in prioritization and triage of radiological medical images.
• Photoplethysmograph Analysis Software for over-the-counter use—analyzes data and provides information for identifying irregular heart rhythms but is not intended to provide a diagnosis.

Contraception: A software application for contraception provides user-specific fertility information based on analysis of patient data (e.g., temperature, menstrual cycle dates) to distinguish between fertile and non-fertile days.

Medical Device Data System (MDDS): A hardware device intended for the electronic transfer, storage, conversion, or display of medical device data, without controlling or altering functions or parameters of connected devices, is generally a Class I device.

Regulatory Status and Classification

Software's regulatory classification determines the stringency of the Quality Management System (QMS) requirements applied:

• Expanded Scope: Under the EU MDR (Medical Device Regulation), the definition of a medical device has broadened, and software was not considered a medical device before these changes. The MDR introduced new, more rigid classification rules which particularly impact manufacturers of software.
• Definition as a Component: Software is explicitly defined as a component within the QMS. A component is any raw material, substance, piece, part, software, firmware, labeling, or assembly intended to be included as part of the finished, packaged, and labeled device.
• Design Controls: Design controls (21 CFR 820.30) are mandated for all Class II and Class III devices, and specifically apply to certain Class I medical devices, including devices automated with computer software.
• Recalls: Failures related to Software are cited as one of the most frequent causes for recalls in the medical device industry.

Mandatory Software Validation

For any device incorporating software, strict verification and validation processes are mandatory and essential for proving safety and effectiveness.

• Required Documentation: Design validation procedures must include software validation where appropriate. The FDA states that this requirement is almost always appropriate unless the manufacturer can justify otherwise.
• Scope of Validation: For devices that incorporate software, the manufacturer must provide a section containing all relevant software information and testing, including, but not limited to, appropriate device hazard analysis, hardware, and system information.
• Computer System Control: When computers or automated data processing systems are used as part of production or the quality system, the manufacturer must validate computer software for its intended use according to an established protocol. All software changes must be validated before approval and issuance, and these validation activities and results must be documented.
• RCA and CAPA: If a failure occurs, the root cause analysis (RCA) may lead to corrective actions that necessitate strengthening pre-market software validation, as seen in examples involving insulin pump malfunctions.

Cybersecurity and Risk Management (The "Special Controls" of Software)

Due to the inherent risks of connectivity, software-based devices often require specific "Special Controls" focusing on cybersecurity and risk mitigation:

Risk Management Mandate: SaMD manufacturers need to understand risk management and how to apply it to their software devices.

Software Verification, Validation, and Hazard Analysis (V&V) must be performed for devices containing software.

Cybersecurity Requirements: Software documentation often requires a cybersecurity vulnerability and management process to assure software functionality. This is critical for systems that rely on data transmission.

Failure Mitigation: Manufacturers must document measures to ensure that safe therapy is maintained when communication with digitally connected devices is interrupted, lost, or re-established after an interruption. Validation testing must demonstrate that critical events are handled appropriately.

Risk Plan Detail: A risk management plan must include a justification of how cybersecurity vulnerabilities of third-party software and services are reduced by the device’s risk management mitigations, addressing risks like loss of image, altered metadata, corrupted image data, or degraded image quality.

‍