Software Development

Medical device software development and maintenance

READ ARTICLE

Introduction

The rapid integration of software into healthcare is transforming how we diagnose, treat, and manage diseases. Among these innovations, Software as a Medical Device (SaMD) has emerged as a distinct and regulated product category, with its own set of development, classification, and compliance requirements.

Unlike traditional medical devices with hardware components, SaMD functions independently of any physical device. This article delves into the definition, development process, classification systems, applicable standards, and regulatory expectations surrounding SaMD.

What is Software as a Medical Device (SaMD)?

The term Software as a Medical Device (SaMD) was formalised by the International Medical Device Regulators Forum (IMDRF) and refers to:

“Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”

This distinguishes SaMD from software integral to a device’s function (embedded software or Software in a Medical Device (SiMD)). SaMD products have independent functionality from any hardware device, while still serving a medical purpose such as diagnosis, prevention, monitoring, or treatment.

SaMD vs SiMD: What’s the difference?

It’s important to differentiate Software as a Device (SaMD) from Software in a Medical Device (SiMD).

Feature SaMD SiMD
Hardware dependency Operates independently Integral to a medical device
Regulatory classification As a standalone device Classified with the parent device
Examples AI diagnostic software, dosing calculators Firmware in a pacemaker, ventilator UI

Medical device software classification systems

Unlike traditional devices, SaMD classifications are largely risk-based, focusing on how the software impacts patient outcomes rather than its physical invasiveness. Below is an overview of classification schemes and evidence requirements for medical device software from the perspective of regulators, payers and health technology assessment (HTA) organisations in key regions: the EU, USA, Canada, Australia, and the UK.

Developing SaMD requires balancing software development best practices with medical device regulatory frameworks. Key factors to consider include:

  • Clinical evaluation and real-world performance
  • Cybersecurity and data protection
  • User-centred design, particularly for vulnerable populations
  • Interoperability with health IT systems
  • Lifecycle management, including post-market surveillance and updates

While regulatory classification determines market access, payers and HTA bodies require additional comparative evidence to support reimbursement and funding decisions. These assessments focus on clinical effectiveness, cost-effectiveness, usability, and impact on care pathways.

    International Medical Device Regulators Forum (IMDRF)

    The IMDRF SaMD Risk Framework classification framework is based on two criteria:

    1. State of the healthcare situation or condition:
      • Critical: Life-threatening situations (e.g., diagnosing strokes)
      • Serious: Requires prompt medical attention (e.g., managing chronic diseases)
      • Non-serious: General wellness or routine management
    2. Significance of information provided by the SaMD:
      • Treat or diagnose
      • Drive clinical management
      • Inform clinical management

    These dimensions create a four-tier risk classification system:

    SaMD Category Clinical Situation Significance of Information Example
    IV Critical Treat/Diagnose Software diagnosing sepsis in ICU
    III Serious Treat/Diagnose App managing insulin dosing
    II Serious Inform/Drive Mgmt Software alerting clinicians to abnormal lab results
    I Non-serious Inform Clinical Mgmt Wellness tracking apps

    This framework guides national regulators in assigning risk classes and determining regulatory requirements. While IMDRF provides the conceptual foundation, each regulator adapts classification according to local regulations.

    IEC 62304:2006 - Software life cycle processes

    IEC 62304 is the international standard for medical device software life cycle processes. This standard specifies safety classes, which determine the rigor of development, documentation, verification, and validation required:

    Class Risk Level Definition Evidence Burden
    Class A No injury or damage Software cannot contribute to a hazardous situation Least regulatory burden; minimal documentation and testing
    Class B Non-serious injury Software failure could lead to non-serious injury Moderate level of process and testing rigor
    Class C Death or serious harm Software failure could lead to death or serious injury Highest scrutiny — must demonstrate robust risk control and extensive testing

    The safety classes determine which clauses of IEC 62304 apply to the device in question, with B and C requiring the most extensive compliance.

    Under the Regulation (EU) 2017/745 (MDR), software is classified using Rule 11, which typically assigns higher-risk classes than under previous directives:

    Risk Class Description Examples
    Class I Very low-risk software (rare) Wellness apps, simple data logging with no analysis
    Class IIa–IIb Most Software as a Medical Device (SaMD) Diagnostic support tools, chronic disease monitoring
    Class III Software making critical treatment decisions Software for insulin dosing, cancer treatment planning

    The EU MDR has increased regulatory scrutiny, requiring notified body review for most SaMD and robust clinical evidence.

    HTA analysis is conducted at the country-level to determine reimbursement coverage and financing:

    Focuses on risk–benefit, comparative effectiveness, and value for money rather than regulatory class. EU HTA Regulation (2025 onward) provides for centralised HTA for high-risk medical devices including and AI-based or Digital Therapeutics (DTx) under EUnetHTA 21. Evidence requirements typically include:

    • Clinical: RCTs, pragmatic trials, or real-world evidence (RWE)
    • Economic: Cost-effectiveness modelling, budget impact analysis
    • Usability: Often required and based on conformity with IEC 62304
    • Organisational: Workflow adjustments and interoperability

    The FDA classifies SaMD under the same risk-based three-tier system (Class I, II, III) used for all medical devices, guided by:

    • Intended use
    • Level of risk to the patient
    • Existing predicate devices (for 510(k) pathway)
    FDA Class Description Examples
    Class I Low risk Minimal risk to patients/users Reminder systems, wellness tracking apps
    Class II Moderate risk Software used for diagnosis or treatment decisions ECG analysis, diabetes management apps
    Class III High risk Software essential to sustaining life or preventing harm Software controlling implanted devices, high-risk diagnostics

    The FDA Digital Health Center of Excellence and Pre-Cert Program (now inactive) have helped shape the evolving SaMD landscape in the U.S.

    HTA/Payer Stakeholders include private payers, Medicare/Medicaid (CMS), Institute for Clinical and Economic Review (ICER), which offers independent HTA. Regulatory classification affects the evidence bar for payer review, especially for CMS, and requirements typically include:

    • Clinical validity & utility: Strong focus from payers
    • Comparative effectiveness: Evidence against the current standard of care
    • Economic modelling: Especially for CMS or large payers
    • Digital Therapeutics (DTx): Must show impact on healthcare utilisation or outcomes

    Key Initiatives:

    Health Canada Medical Devices Regulations (SOR/98-282) follows a four-class system for SaMD (Class I–IV), aligned with IMDRF. Since 2019, Health Canada has clarified digital health classifications, emphasising intended use and patient impact. Standalone software is regulated independently from hardware. Software updates can affect classification:

    Health Canada Class Description Examples
    Class I Low Risk Wellness or lifestyle software not used for medical purposes Fitness trackers, general wellness apps
    Class II Moderate Risk Software that monitors non-critical parameters Apps for tracking blood pressure or glucose (non-acute)
    Class III Higher Risk Software that supports treatment of serious conditions Clinical decision support for chronic disease management
    Class IV Highest Risk Software for diagnosis or treatment of life-threatening conditions Imaging software for detecting cancer, software guiding radiotherapy

    The HTA body, Canada’s Drug Agency (CDA-AMC) (formerly Canada’s Drug and Health Technology Agency) and INESSS (Quebec) conducting provincial assessments does not tie HTA to regulatory class. Devices are often triaged by intended impact and cost, with evidence requirements including:

    • Clinical Effectiveness: Safety, accuracy, health outcomes
    • Cost-Effectiveness: Particularly for public funding
    • Real-World Evidence (RWE): Valued where RCTs aren’t feasible
    • Usability and accessibility: Increasingly considered important

    Key Initiatives:

    The Therapeutic Goods Administration (TGA) Therapeutic Goods (Medical Devices) Regulations 2002 uses a four-class model and updated its framework in 2021 to align with IMDRF and EU MDR. Many wellness and administrative software are now excluded or exempt, while clinical software remains regulated. Sponsors must ensure classification and Essential Principles conformity. Risk-based Classification (Class I, Is, IIa, IIb, III):

    TGA Class Description Examples
    Class I Low Risk Non-sterile, non-measuring software General health tracking apps, non-clinical calculators
    Class Is Low Risk (sterile) Class I software supplied in a sterile condition Not typical for software-only products
    Class IIa Moderate Risk Software providing diagnostic or clinical decision support Apps for skin condition triage, decision support for non-critical care
    Class IIb Moderate-Higher Risk Software that guides or influences therapeutic interventions Insulin titration calculators, dose optimization software
    Class III High Risk Software that controls or monitors high-risk therapy or conditions Software controlling implantable devices, radiation therapy planning

    The primary HTA pathway is through the Medical Services Advisory Committee (MSAC). The TGA device classification informs risk profile, but MSAC requires additional evidence. SaMD treated similarly to diagnostics/therapeutics based on intended purpose with evidence requirements icnluding:

    • Comparative clinical effectiveness
    • Cost-effectiveness analysis (CEA): Mandatory for public funding
    • System impact: Effect on care delivery, workforce, etc.
    • Co-dependent technologies: If software relies on or complements other interventions

    The U.K. Medicines and Healthcare products Regulatory Agency (MHRA) UK Medical Devices Regulations 2002 (as amended) is aligned to the legacy EU MDD (93/42/EEC) framework, pending reforms post-Brexit. It employs a risk-based classification (Class I, IIa, IIb, III) useing intended purpose and risk to determine classification:

    MHRA Class Description Typical Examples
    Class I Low Risk Non-invasive software with minimal impact on health General health tracking, wellness apps
    Class IIa Moderate Risk Software used for diagnosis or therapeutic decision-making Clinical decision support for non-serious conditions
    Class IIb Higher Risk Software influencing treatment of serious conditions Dosing calculators, ventilator control apps
    Class III High Risk Software with critical influence on life-threatening conditions Software guiding surgical interventions, controlling implantable devices

    UK-specific regulatory reform is underway with consultations held in 2023–2024. The government has recently launched a new QUANGO Centres of Excellence for Regulatory Science and Innovation (CERSIs) to advance regulatory science and ensure the UK’s regulatory system is fit for the future, particularly in areas like AI and digital health technologies.An AIaMD-specific regulatory pathway is evolving. In the interim, MHRA continues to accept CE marks under EU MDR until July 2028, for most devices.

    The National Institute for Health and Care Excellence (NICE) evaluates digital health, devices, and digital therapeutics (DTx). The Scottish Health Technologies Group (SHTG) evaluates health technology products in Scotland and Health Technology Wales (HTW) operates in Wales.

    NICE does not use the MHRA classification scheme, but assesses based on intended use and impact. NICE tiers focus on evidence standards required, not regulatory approval, but align well with increasing levels of risk and required clinical assurance:

    Tier Description
    Tier A – System service Supports system efficiency without impacting individual clinical decisions
    Tier B – Communication Enables communication between patients and professionals, or tracks personal data
    Tier B – Promoting Health Provides general, non-personalised health information or advice
    Tier C – Inform Mgmt Records or calculates data to inform future clinical decisions; includes personalised self-help
    Tier C – Drive Mgmt Informs diagnosis/treatment decisions, guides triage, or identifies early signs of disease
    Tier C – Diagnose Directly supports or performs immediate diagnosis or screening
    Tier C – Treat Directly treats, prevents, or mitigates a condition with an immediate effect

    The NICE Evidence Standards Framework for DHTs divides digital tools into tiers (A, B, C) based on function and risk. Each tier has graduated evidence expectations.

    Other NICE Tools:

    Development standards for SaMD

    Given SaMD’s unique challenges, multiple standards guide its design, development, validation, and lifecycle management. While no standard suffices alone, regulators widely accept and reference the following.

      IEC 62304 is the cornerstone standard for medical software development. It:

      • Defines a risk-based framework for software lifecycle activities
      • Requires software development planning, verification, validation, and maintenance processes
      • Categorises software into Classes A, B, or C based on safety risk

      IEC 62304-compliant development activities should be integrated with ISO 13485 – Quality Management Systems for Medical Devices. While not software-specific, ISO 13485 requires a robust QMS that includes software-specific processes under design controls, risk management, and post-market surveillance.

      Traditional waterfall models may be too rigid for modern software development. Many companies now use Agile or DevOps methodologies. However, these must be integrated with regulatory requirements to:

      • Maintain design control traceability during iterations
      • Document changes and validations as per IEC 62304
      • Apply configuration management rigorously
      • Some regulators, like the FDA, are open to Agile-based QMS, if appropriately controlled and documented.

      Because software can evolve after market release, regulators increasingly expect lifecycle oversight, including:

      • Automated error tracking and updates
      • User feedback mechanisms
      • Real-world performance monitoring
      • Change management protocols, especially for AI-based algorithms

      ISO 14971 – Application of Risk Management to Medical Devices is the standard that is critical for managing risk throughout the software lifecycle, particularly in:

      • Hazard identification
      • Risk estimation and control
      • Risk-benefit analysis for residual risks

      IEC/TR 80002-1 – Guidance on Risk Management for Medical Device Software provides practical guidance on applying ISO 14971 to software specifically, complementing IEC 62304.

      IEC 82304-1 – Health Software Product Safety focuses on the entire health software product, not just embedded software, and includes usability, security, and system-level requirements.

      The ISO/IEC 27000 series (often called ISO 2700x) is a family of international information security management systems (ISMS) standards. The ISO 2700x series is maintained by the ISO/IEC Joint Technical Committee 1 (JTC 1), specifically SC 27 on IT security techniques. The core and supplementary standards are:

      Standard Title / Purpose
      ISO/IEC 27000 Vocabulary and overview of the ISMS family
      ISO/IEC 27001 Requirements for establishing, implementing, maintaining an ISMS
      ISO/IEC 27002 Guidelines and controls for information security (a companion to 27001)
      ISO/IEC 27005 Risk management for information security
      ISO/IEC 27701 Extension to 27001 for privacy information management (PIMS)
      ISO/IEC 27017 Security controls for cloud services
      ISO/IEC 27018 Protection of personally identifiable information (PII) in public clouds
      ISO/IEC 27032 Cybersecurity (bridges IT, internet, critical infrastructure)
      ISO/IEC 27035 Incident management (detecting, reporting, and responding to breaches)

      For health tech companies, these standards ensure confidentiality, integrity, and availability of health data, meeting regulatory requirements, and enabling trust from users and partners:

      • Health Data Protection: Health tech platforms handle sensitive personal data, often regulated under GDPR, HIPAA, PIPEDA, etc. ISO 27001 + 27701 enables robust controls for data security and privacy compliance.
      • Cloud-based and Mobile Solutions: Cloud-hosted SaMD or digital tools must apply ISO/IEC 27017 and 27018 to secure multi-tenancy environments, encryption in transit and at rest, user authentication and access control. Incident Response and Cybersecurity: ISO/IEC 27035 + 27032 guides cyber incident handling. This is especially important for ransomware threats, zero-day vulnerabilities in connected devices, and coordinated vulnerability disclosures (CVDs).
      • Risk and Threat Modelling: ISO/IEC 27005 integrates with medical risk management (ISO 14971) to ensure consistency in threat identification (unauthorised access, malware), likelihood/severity assessment, and risk treatment options.
      • Supply Chain and Third Parties: Health tech companies often rely on third-party vendors (e.g., cloud hosting, API partners). ISO 27001 and 27002 require supplier risk management, due diligence, and security SLAs.

      Clinical evaluation of SaMD

      Unlike physical devices, SaMD often lacks tangible components to inspect. Instead, clinical evaluation focuses on three pillars:

      • Valid Clinical Association: Is there a scientifically validated relationship between the input data and clinical condition?
      • Analytical Validation: Does the software correctly process inputs and deliver accurate outputs?
      • Clinical Validation: Does the software achieve its intended purpose in the target population?

      Depending on the risk classification and tool type, these requirements may be fulfilled using retrospective datasets, clinical studies, or real-world performance data.

      Conclusion

      Developing SaMD is as much about navigating regulation as it is about innovation. With no physical form, software must prove its clinical value, safety, and performance through robust engineering and transparent evidence. Understanding the classification systems, risk frameworks, and relevant standards is essential to ensure that your software reaches the market and does so safely, compliantly, and with sustained impact.

      Resources

        International Medical Device Regulators Forum (IMDRF)

        European Union

        Germany

        France

        U.S.

        Canada

        Australia

        United Kingdom (UK)

        European Union (EU)

        United States (US) Food and Drug Administration (FDA)

        Health Canada

        Australia Therapeutic Goods Administration (TGA)

        U.K. Medicines and Healthcare products Regulatory Agency (MHRA)

        International Standards

        Acceptance Criteria: The predefined standards and specifications that a device must meet during testing and evaluation to be deemed suitable for its intended use and to comply with regulatory requirements.

        Audit: A systematic, independent examination of a manufacturer’s processes, procedures, and products to ensure compliance with regulatory standards and quality requirements. Also see Internal Audit.

        Authorised Representative: A natural or legal person appointed by a manufacturer to act on their behalf in carrying out specific tasks related to conformity assessment and regulatory compliance.

        Change Control: The systematic process of managing and documenting modifications to a device or its manufacturing process to ensure that all changes are assessed, approved, implemented, and tracked in compliance with regulatory standards and quality management systems.

        Compliance: Adherence to regulations, standards, and guidelines set forth by regulatory authorities.

        Controlled Environment: A workspace where environmental conditions such as temperature, humidity, and particulate levels are regulated to ensure product quality and process integrity.

        Design Transfer: The process of transitioning a product’s design from development and manufacturing into production while ensuring all specifications and requirements are met.

        Distributor: A natural or legal person in the supply chain, other than the manufacturer or importer, who makes a medical device available on the market.

        Economic Operator: Any person or entity engaged in the production, distribution, import, export, or supply of medical devices.

        International Medical Device Regulators Forum (IMDRF): A global regulatory collaboration focused on harmonising medical device regulations to facilitate patient access to safe and effective devices. This organisation was formerly the Global Harmonization Task Force (GHTF).

        ISO 13485: An international standard that specifies requirements for a quality management system (QMS) specific to the medical devices industry.

        ISO 14971: An international standard for the application of risk management to medical devices.

        Lifecycle Management: The process of overseeing a product, service, or system from its initial development through its growth, maturity, and eventual decline or disposal, ensuring optimal performance and resource utilisation at each stage.

        Manufacturer: A legal entity that designs, produces, assembles, or labels a medical device with the intention of placing it on the market.

        Process Controls: The tools and methods to monitor and manage medical device manufacturing processes.

        Process Performance Qualification (PPQ) Studies:

        • Installation Qualification (IQ): Verifying that equipment and installations meet the required specifications.

        • Operational Qualification (OQ): Confirming that equipment and processes operate correctly under defined conditions.

        • Performance Qualification (PQ): Demonstrating that processes perform effectively and reproducibly in real-world conditions.

        Process Validation: Ensures that the entire manufacturing process, supported by process controls, reliably produces products meeting all requirements.

        Quality Management System (QMS): A formalised system that documents the structure, responsibilities, and procedures required to achieve effective quality management.

        Quality Management System Regulation (QMSR): The U.S. Food and Drug Administration (FDA) regulation that aligns its medical device quality system requirements with ISO 13485:2016 to streamline global compliance and enhance device safety and effectiveness.

        Quality System Regulation (QSR): Outlined in 21 CFR Part 820, the U.S. Food and Drug Administration (FDA) framework requires medical device manufacturers to establish and maintain a quality management system to ensure their products consistently meet applicable requirements and specifications.

        Record: A documented piece of evidence detailing activities, decisions, or results, created and maintained to demonstrate compliance with regulatory requirements and quality management standards.

        Regulation: The rules, laws, standards, and requirements set by regulatory authorities to ensure the safety, efficacy, and quality of devices intended for medical use.

        Regulatory Authority: An official body overseeing and enforcing laws, regulations, and standards within a specific industry or sector to ensure compliance and protect public interests. Also known as a Regulatory Authority. Also see Competent Authority and Notified Body.

        Risk: The combination of the probability of occurrence of harm and the severity of that harm.

        Risk Analysis: The systematic use of available information to identify hazards and to estimate the risk.

        Risk Assessment: The overall process comprising risk analysis and risk evaluation.

        Risk Management (RM): The systematic application of management policies, procedures, and practices to the tasks of analysing, evaluating, controlling, and monitoring risk.

        Safety: The condition of being protected from or unlikely to cause danger, risk, or injury.

        Software Validation: The documented process of ensuring that software performs as intended for its specific use within a regulated environment.

        Standard: A document that provides guidance, requirements, or specifications established by regulatory bodies, industry organisations, or international consensus groups.

        User: Any individual who operates or interacts with a medical device, including healthcare professionals, patients, and caregivers.

        Validation: Confirmation by examining and providing objective evidence that the particular requirements for a specific intended use can be consistently fulfilled.

        Updated on 10 May 2024