Not all digital health solutions require regulatory approval. So why then would pharma choose to create those that do over those that don’t? In short, as the regulatory and evidence requirements increase for a given solution, so too does its value to healthcare.
Low-level, low-impact solutions, like those focusing on patient education, onboarding, or initial engagement don’t typically require regulatory approval, but these alone won’t drive the value pharma companies, and patients, need.
Software as a Medical Device, or SaMD
Regulated solutions are also called software as a medical device (SaMD), and they follow a similar approval process to medical devices.
Put simply, SaMD is (as per the International Medical Device Regulators Forum), “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.” Software does not however meet the definition of SaMD if its intended use is to drive a hardware medical device or simply fetch data.
SaMD solutions are better placed to differentiate pharma products in the market by working alongside medication in the management, treatment, and monitoring of diseases. This more than justifies their greater regulatory requirements.
Benefits of regulated digital health solutions for pharma
While digital health solutions classified as SaMD are often more complex to develop, embracing these solutions offers a series of significant benefits, including:
- Improving treatment outcomes, since SaMD solutions are more likely to play a direct role in the care of an individual and provide evidence to support the intended use and claim, compared with other unclassified digital health applications.
- Increasing confidence among clinicians, thus increasing adoption as a result when compared with non-regulated digital health options.
- Providing greater reassurance to patients that these solutions are regulated, safe, and appropriate to use, building trust in digitally delivered treatment elements.
- Differentiating pharmaceutical treatments by combining them with digital solutions that influence outcomes.
- Furthering research and insights on disease trajectory by capturing standardized, real-world data across regions.
- Supporting reimbursement with real-world data and improving engagement with payors and healthcare providers as a result.
Digital health regulatory classification
The specific regulatory expertise required for digital health solutions and SaMD are distinctly different to those familiar with bringing pharmaceutical products to market. Pharma companies typically engage an expert partner to handle the regulatory process for an SaMD solution.
SaMD classification is based on the intended use of the product, the claims it makes, and the potential risks it presents to patients and users. The higher the classification, the more evidence required to validate your SaMD claims.
Working to a clear regulatory roadmap is essential for ensuring you know exactly what is required for a specific regulatory pathway, how it needs to be done, and how long it will take to roll out your SaMD solution.
While regional requirements are reasonably consistent thanks to standards (such as an ISO 13485 quality management system, IEC 62034 for medical device software development, and ISO 14971 for medical device risk management), getting the process right demands careful planning to ensure all relevant needs are met. This will include market-specific approaches to SaMD classification depending on where you launch (like the FDA’s Clinical Decision Support Software guidance, or the EU MDCG guidance on qualification), as well as classification of software under the MDR.
The diagram below shows the regulatory classes under the FDA in the US, and MDR in the EU; two of the most prominent markets for launching a digital health solution. You can find an overview of the regulatory pathways of some of the most prominent countries here.
For more information on SaMD, download our whitepaper here.
Keep up to date with our latest blogs by subscribing to our newsletter below:
