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:
- 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
- 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:
- CMS Coverage with Evidence Development (CED): Reimbursement conditional on ongoing evidence generation
- FDA–CMS Parallel Review: For simultaneous approval and coverage evaluation
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:
- Health Technology Expert Review Panel (HTERP): For higher-risk digital and AI tools
- Multi-criteria decision analysis (MCDA) used in complex evaluations
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:
- Early Value Assessment (EVA): Rapid access for promising innovations.
- MedTech Innovation Briefings (MIBs): Inform clinicians and commissioners (now discontinued in 2023).
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.
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)
- Software as a Medical Device (SaMD): Key Definitions
- Software as a Medical Device (SaMD): Clinical Evaluation
- Software as a Medical Device (SaMD): Application of Quality Management Systems
- Software as a Medical Device (SaMD): Risk Management
- Software as a Medical Device (SaMD): Adverse Event Reporting
European Union
- MDCG 2019-11: Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 and 2017/746
- MDCG 2020-1: Guidance on Clinical Evaluation (MDR) / Performance Evaluation (IVDR) of Medical Device Software
- MDCG 2021-24: Guidance on Classification of Medical Devices
- MDCG 2023-1: Guidance on Cybersecurity for Medical Devices
- MDCG 2021-19: Guidance on Borderline Products
- MDCG 2021-5: Guidance on Standardisation for Medical Devices
- MDCG 2022-5: Guidance on Software and Artificial Intelligence (AI) in MDR/IVDR Context
Germany
- German Federal Joint Committee (G-BA) Digital Health Applications (DiGA) Directory
- G-BA Framework for Digital Health Applications (DiGA) - Guidance Document (in German)
France
- Haute Autorité de Santé (HAS) Medical Devices and Digital Health
- CNEDiMTS Guidelines on Health Technology Assessment
U.S.
- FDA Digital Health Policy Navigator
- Clinical Decision Support Software (2022)
- Software as a Medical Device (SaMD): Clinical Evaluation (2021)
- Policy for Device Software Functions and Mobile Medical Applications (2022)
- General Wellness: Policy for Low Risk Devices
- Deciding When to Submit a 510(k) for a Software Change to an Existing Device (2017)
- Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (2023)
- Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices (2005)
- Computer Software Assurance for Production and Quality System Software (2023)
- General Principles of Software Validation (2002)
- FDA Digital Health Policy Guidance Documents
- CMS National Coverage Determinations (NCD) for Digital Health
- FDA and CMS Guidance on Software as a Medical Device and Reimbursement
Canada
-
Guidance Document: Software as a Medical Device (SaMD): Definition and Classification
-
Guidance Document: Software Validation for Medical Device Manufacturers
-
Medical Device Single Audit Program (MDSAP) - Software as a Medical Device
-
Canadian Agency for Drugs and Technologies in Health (CADTH) Rapid Review Guidance
Australia
- How the TGA regulates software-based medical devices (SaMD)
- Classifying active medical devices (including software-based medical devices)
- Regulatory changes for software-based medical devices (2024 update)
- Guidance for the risk-based classification system for non-in-vitro diagnostic devices
- Update on Software as a Medical Device (SaMD)
- Essential Principles of Safety and Performance
- Medical Services Advisory Committee (MSAC) Guidelines
- TGA Guidance on Software as a Medical Device
- Australian Digital Health Agency – Digital Health Standards
United Kingdom (UK)
- MHRA: Medical device software and apps (including standalone software) guidance
- MHRA: Guidance on the Regulation of Software as a Medical Device (SaMD)
- MHRA: Guidance for manufacturers on cybersecurity for medical devices
- MHRA Guidance on Software and AI as a Medical Device
- SaMD Classification Flowchart
- NICE: Evidence standards framework for digital health technologies
- NICE: Medical technologies guidance
- NICE: Diagnostics guidance
- NHS England Digital Technology Assessment Criteria (DTAC)
European Union (EU)
- Regulation (EU) 2017/745 on Medical Devices (MDR)
- Regulation (EU) 2017/746 on In Vitro Diagnostic Medical Devices (IVDR)
United States (US) Food and Drug Administration (FDA)
- 21 CFR Part 820 – Quality System Regulation (QSR)
- 21 CFR Part 807 – Establishment Registration and Device Listing for Manufacturers
Health Canada
Australia Therapeutic Goods Administration (TGA)
U.K. Medicines and Healthcare products Regulatory Agency (MHRA)
International Standards
- IEC 62304 – Software Life Cycle Processes
- ISO 13485 – Quality Management Systems for Medical Devices
- ISO 14971 – Application of Risk Management to Medical Devices
- IEC/TR 80002-1 – Guidance on Risk Management for Medical Device Software
- IEC 82304-1 – Health Software Product Safety
- ISO/IEC 27000 Series – Information Security Management Systems
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.