Challenges & Opportunities in Emerging Digital Health Technologies
Digital health is transforming the health care landscape through new technologies and platforms in patient care management, conducting of clinical trials, patient data collection, and the diagnosis and treatment of disease. Emerging digital health technologies (DHTs) may improve the quality of life for patients with chronic and debilitating diseases and provide novel health care solutions for patients with unmet medical needs. As digital health sits at the intersection of technical, scientific, and regulatory disciplines involving medical devices, drugs, and biologics, the successful development of novel DHTs will require significant collaboration with health care stakeholders to overcome regulatory, technical, and life-cycle management challenges.
The COVID-19 pandemic underscores the importance of DHTs through the increased reliance on telemedicine services and remote patient monitoring programs to ensure patient safety and triage scarce hospital resources.1 ,2 Given the public health emergency, health authorities offered greater flexibilities in the use of digital health platforms and technologies such as:
- Enhanced HIPAA (Health Insurance Portability and Accountability Act of 1996) flexibilities in the use of telemedicine services3
- Emergency use authorization (EUA) to increase the availability of remote or wearable monitoring devices to treat patients and reduce the risk of exposure of health care providers to SARS-CoV-24 ,5
- Regulatory discretion in the use of virtual patient monitoring and remote clinical outcome assessments for clinical trials during the COVID-19 pandemic6
Moving forward, the health care community should adopt important lessons learned from the pandemic by leveraging DHTs to accelerate research and development of new medical therapies, supporting evidenced-based and data-driven health outcomes, and empowering patients in their health care management.
What Is Digital Health?
Digital health is a broadly defined topic that encompasses the application of digital technologies in health care, living, and society to help deliver or provide access to health care products and services.7 DHTs may include mobile medical applications, health information technology, wearable devices, wireless sensors, telemedicine, electronic health records (EHRs), digital therapeutics, software as a medical device (SaMD), and artificial intelligence and machine learning (AI/ML) technology.8 ,9 More broadly, a DHT may refer to a system that uses computing platforms, connectivity, software, and sensors for health care and related uses.10 Given the proliferation and confusion of various digital health terms, this article includes a compiled glossary of core DHT terms and definitions (see Table 1). Together, DHTs may be intended as a medical product to improve the prevention, diagnosis, treatment, monitoring, and management of health-related issues; an adjunct to other therapies such as devices, drugs, and biologics; a tool to collect and analyze data as part of a clinical study; or an aid to monitor and manage a patient’s lifestyle or habits.6 ,11
DHT Tools
In December 2021, the US FDA issued a cross-center draft guidance with recommendations on the use of digital health technology tools (DHTTs) to acquire data remotely from participants in clinical investigations for medical products.23 DHTTs are electronic technology tools intended for use in clinical investigations (inclusive of clinical trial and post-market settings) or clinical practice.7 The FDA’s draft guidance provides additional clarity on the regulatory expectations for selection of DHTTs used in a clinical investigation, for those used in verification and validation activities, use of DHTTs in collection of clinical trial endpoints, and identification and management of associated risks with the use of the DHTT. As the guidance notes, the DHTT requirements may vary depending on whether the DHTT meets the definition of a device and if the DHTT is only meant to be used in the context of a clinical investigation.
DHT | Description |
---|---|
Artificial intelligence (AI)/machine learning (ML) |
AI: The use of algorithms or models to mimic human capabilities or behaviors such as learning, making decisions, and making predictions. ML: Subset of AI that contains a model or algorithm that enables a computer to perform a task without being explicitly programmed. An ML-enabled medical device uses ML, in part or in whole, to achieve its intended medical purpose.12 |
Digital health technology tools (DHTTs) |
The term “DHTTs” is used to differentiate from the broader category of DHTs, but these two terms are often used interchangeably. As clarified in this article, DHTTs are electronic technology tools intended for use in clinical investigations (inclusive of clinical trial and post-market settings) or clinical practice.7 |
Digital therapeutics | Digital therapeutics are a subset of SaMD with the primary function of delivering software-generated therapeutic interventions directly to patients to prevent, manage, or treat a medical disorder or disease.7 An example of a digital therapeutic is EndeavorRx, which is a videogame-based digital therapy for treating patients with attention deficit hyperactivity disorder (ADHD).13 |
Electronic health record (EHR) | An EHR is a subset of health information technology and consists of an individual patient record contained within an EHR system. A typical individual EHR may include a patient’s medical history, diagnoses, treatment plans, immunization dates, allergies, radiology images, pharmacy records, and laboratory and test results.14 |
General wellness apps | General wellness apps are low-risk products that promote or encourage a healthy lifestyle (general wellness) and are not involved in the diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.15 |
Health information technology (IT) | Health IT encompasses the use of computer hardware, software, or infrastructure to record, store, protect, and retrieve clinical, administrative, or financial information. These can include the use of EHRs and electronic prescriptions.16 |
Medical device data systems (MDDSs) | MDDSs consist of hardware and software that is meant to transfer, store, convert formats, and display medical device data or medical imaging data. These devices are generally considered low risk if they are not meant to interpret or analyze clinical data. 17 |
Mobile medical application (MMA) | MMA is a software application that can be run on a mobile platform that incorporates device software functionality that is to be used as an accessory to a regulated medical device or to transform a mobile platform into a regulated medical device.18 |
Software as a medical device (SaMD) or software in a medical device (SiMD) | SaMD relates to software that is intended for one or more medical purposes without being part of a hardware medical device. SiMD relates to software that is intended for one or more medical purposes that is used to control a hardware medical device or is necessary for a hardware medical device to achieve its intended use. SaMD and SiMD are also referred to as medical device software under the European Union Medical Device Regulation and In Vitro Diagnostic Regulation.17 ,19 ,20 |
Telemedicine or telehealth | Telemedicine or telehealth is technology that enables patients to connect with their health care providers through live phone or video conferencing, secure messaging, and remote monitoring.21 |
Wearables | Wearables are a type of digital technology that users can wear and are designed to collect data or to inform users of their personal health and wellness.7 |
Wireless medical devices | Wireless medical devices use wireless radio frequency communication such as wifi, Bluetooth, and cellular/mobile phone technology.22 |
The European Medicines Agency (EMA) has also issued regulatory considerations on the use of DHTTs to study or monitor medicinal products.24 . DHTTs subject to EMA regulatory oversight include DHTTs used in the development of a medicinal product or monitoring of a medicinal product before or after authorization, or any DHTT having an impact on the benefit-risk assessment of a medicinal product marketing authorization application (MAA). Important considerations as part of the EMA qualification process include ensuring the technology is fit for purpose, whether the measurement of interest is clinically meaningful, and whether the underlying methodology is reliable and robust. However, beyond qualification of the DHTT as part of a medical product development program, EMA guidance is limited on how to apply applicable regulatory requirements for DHTTs classified as medical devices, compliance with EU data protection regulations, and other ethical guidelines.
Low-Risk Attribute | Moderate or High-Risk Attribute |
---|---|
Intended to collect, interpret, and/or analyze data solely as part of exploratory scientific research. |
Intended to collect, interpret, and/ or analyze data to support regulatory decision-making, such as a tool used in a clinical investigation to support a medical product marketing authorization. |
Health care provider can independently review the basis of the DHT recommendation or output. |
Intended to diagnose, cure, mitigate, treat, or prevent a disease or condition. |
Use of the DHT does not pose additional unnecessary risks to the intended user (e.g., invasive monitoring). |
Interpret or analyze patient or clinical laboratory test data. |
Intended to transfer, store, convert, or display health care data. |
Health care provider relies primarily on the DHT recommendation to make a clinical diagnosis or treatment decision. |
Intended solely for promoting or supporting a healthy lifestyle (general wellness). |
Intended to be used with another medical product that is essential for its safe and effective use. |
Uses ML algorithms to make decisions and predictions for a noncritical, nonserious, or nonlife-threatening disease or condition. |
Uses ML algorithms to make decisions and predictions for a critical, serious, or life-threatening disease or condition. |
Expanded adoption and use of DHTTs may accelerate the drug development process by more efficiently collecting and analyzing large amounts of patient-generated data, enhancing pharmacovigilance capabilities, and offering greater participation from diverse groups of patients who may have limited access to clinical investigation sites. However, several challenges and uncertainties remain with the use of DHTTs in clinical investigations because global health authorities have not harmonized on regulatory requirements and standards, nor have they clearly defined regulatory policies on DHTTs based on context of use. There are important considerations if the DHTT is classified as a medical device, which may change the level of regulatory controls and evidentiary requirements to support its appropriate use, such as off-label versus on-label use of a device with prior marketing authorization. As global health authorities develop DHTT regulatory requirements, they need to find the appropriate balance to foster innovation while maintaining product safety, efficacy, and quality.
Risk-Based Framework
To support digital health innovation, a risk-based framework is needed to identify and understand the critical attributes that inform the level of controls to ensure safe and appropriate context for use of the DHT (see Table 2).
For example, a DHT may have a lower risk if it is intended solely for exploratory scientific research and have a higher level of risk if it is intended for collection and analysis of a clinical trial endpoint to support a marketing authorization. Another consideration is if the health care provider uses the output of the DHT as supporting information (lower risk) versus using the DHT output as the sole basis for making a clinical diagnosis or treatment decision (higher risk). Additionally, the use of AI/ML algorithms in a DHT may not necessarily pose higher risks if the output is used to inform a nonserious or nonlife-threatening condition.
The application of risk management principles for DHTs is not clearly defined and depends on whether the technology is classified as a medical product based on its intended use. However, for certain DHTs classified as devices or SaMD, ISO 14971:2019 specifies the terminology, principles, and process for application of risk management.25 Furthermore, the International Medical Device Regulators Forum (IMDRF) proposed a possible risk categorization framework for SaMD based on a four-tiered system (category I having the lowest level of impact and category IV having the highest level of impact), based on the combination of the significance of information provided by the SaMD to the health care decision as well as the context in which the SaMD will be used.26 However, this framework is limited because it does not consider DHTs that do not meet the definition of SaMD, nor does it provide recommendations on how category I products should be regulated. Also, this framework does not include considerations for using DHTs in the context of a clinical investigation or as exploratory scientific research.
A DHT should not automatically be classified as a medical device and not all software that is used in the health care setting is considered to be a SaMD. The DHT classification depends on the intended use, potential risks, and specific software functions, where applicable. Understanding DHT regulations and classification under a medical device regulatory framework is complex given the lack of global harmonization and regulatory guidance. For example, although the 21st Century Cures Act (Cures Act) in the United States and the European Union Medical Device Regulations and In Vitro Diagnostic Regulations (EU MDR/IVDR) both include provisions for DHTs classified as medical devices, these two regulatory frameworks are unfortunately not fully aligned.
Section 3060(a) of the Cures Act amended the Food Drug and Cosmetic Act (FD&C Act) to exclude certain software functions from the statutory definition of a device. 27 This includes certain DHTs that are used for administrative support, maintaining a healthy lifestyle, EHRs, and software that is intended to store or display health care data. The Cures Act also defined clinical decision support (CDS) software that may be excluded from device regulations based on certain lower-risk criteria.28
Adding to the complexity of the FDA’s digital health framework are certain DHTs that meet the definition of the device, but the FDA chooses to apply enforcement discretion given the low risk to patients. The FDA describes these products under enforcement discretion if they are intended to inform clinical management for nonserious situations or conditions, help patients self-manage their disease or conditions without providing specific treatment, or automate simple tasks for health care providers.18 ,28 However, additional clarity is needed for industry in understanding the scope of DHTs under the FDA’s enforcement discretion policy, exemptions under the Cures Act, and those DHTs that meet the statutory definition of a device.
In contrast to the US regulatory framework, the EU MDR/IVDR implemented more stringent qualification and classification criteria for software regulated as medical device software (MDSW). Unlike the FDA’s risk-based framework for exercising enforcement discretion and exclusion of certain software functions from FDA regulations, under EU MDR/IVDR, the risk of a software product’s harm to patients and users is not a criterion for whether the software qualifies as a medical device, nor are there exemptions for certain low-risk medical device software functions.29 For example, although certain CDS software is excluded from medical device regulations in the US, under EU MDR Rule 11, any software that is intended to provide information to assist in making decisions for diagnosis or therapeutic purposes or that is intended to monitor physiological processes is classified at minimum as a class IIa device requiring a notified body conformity assessment.29
Additionally, certain MDR/IVDR requirements also apply if the software is meant to process, analyze, create, or modify medical information with a medical intended purpose, or if the software is intended to drive or influence the use of a medical device.29 Similar to the US regulatory framework, software with a nonmedical intended purpose or software meant for simple search, data storage, archival, or communication is not considered medical device software under EU MDR/IVDR, nor are EHRs, telemedicine, and administrative hospital information systems.
The health care community should adopt important lessons learned from the pandemic by leveraging DHTs to accelerate research and development of new medical therapies, supporting evidenced-based and data-driven health outcomes, and empowering patients in their health care management.
Regulatory divergence with US and EU regulatory requirements makes DHT development and adoption more challenging. To better understand the differences and similarities in how certain DHTs are regulated and classified, Table 3 provides a summary of two hypothetical examples of products that are used to calculate insulin dosing. Table 3 describes the application of three different SaMD frameworks: the IMDRF SaMD Risk Categorization Frame-work, the US FDA Framework, and EU MDR/IVDR Framework for an insulin dosing calculator and an insulin management system. Table 3 illustrates the regulatory divergence for certain products under the US and EU systems and the limitations of the harmonized IMDRF SaMD Risk Categorization Framework. Also, as shown in Table 3, the product’s intended use, technological characteristics, and application of regulatory guidelines can have a significant impact on the product’s regulatory burden.
Life-Cycle Management
Effective DHT life-cycle management requires integrated product development and close collaboration with stakeholders (e.g., users, patients, and health care providers) to ensure effective product design, safety, and quality. Given the rapid and iterative nature of DHTs, organizations need to effectively respond to potential cybersecurity threats, software updates, customer complaints, adverse events, and other potential safety concerns.
To adapt to the rapid and iterative nature of new and updated software, the FDA created the Software Precertification Pilot program.30 This pilot aims to have a flexible regulatory framework to reduce the time and cost of market entry for software developers that have a demonstrated a culture of quality and organization excellence. The pilot program takes a total product life-cycle (TPLC) approach by ensuring continued monitoring and evaluation of a product’s safety from the pre-market development phase through post-market surveillance.31 However, it remains unclear which types of regulated DHTs may become eligible for FDA precertification and if the excellence appraisal system can adequately safeguard against potential product safety and quality issues.
Insulin Dosing Calculator | Insulin Management System | |||
---|---|---|---|---|
Description | • Intended for use by a health care professional. | • Intended for use by a health care professional. | ||
• Calculates insulin dose based on accepted clinical practice guidelines and published literature. • Does not control or connect to a medical device. |
• Calculates insulin dose based on a proprietary algorithm that incorporates real-time data and historical patient data from EHR to provide adaptive insulin dosing to support intravenous insulin regimens and optimizes management of a patient’s blood glucose in a hospital setting. Insulin delivery is independent of insulin management system. |
|||
IMDRF SaMD Risk Categorization Framework 26 |
Category I: SaMD that provides information to inform clinical management for a disease or condition in a nonserious situation or condition is a Category I and is considered to be of low impact. | Category II: SaMD that provides information to drive clinical management of a disease or condition in a serious situation or condition and is considered to be of medium impact. | ||
US FDA Cures Act Framework28 |
Excluded from the definition of a medical device because it meets all four criteria for CDS described in Section 520(o)(1)(I) of the FD&C Act: | Meets the definition of a medical device and does not satisfy criterion 1 and 4 for CDS described in Section 520(o)(1)(E) of the FD&C Act: | ||
1. Not intended to acquire, process, or analyze medical images or signals. | ✔ | 1. Intended to process and analyze a patient’s real-time blood glucose measurements. |
||
2. Intended for the purpose of displaying, analyzing, or printing medical information about a patient. | ✔ | 2. Intended for the purpose of displaying, analyzing, or printing medical information about a patient. |
✔ | |
3. Intended to provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition. | ✔ | 3. Intended to provide recommendations to a health care professional about prevention, diagnosis, or treatment of a disease or condition. | ✔ | |
4. Health care professional can independently review the basis for the recommendation. | ✔ | 4. Health care professional cannot independently review the basis for the recommendation. | ||
EU MDR/IVDR Framework 29 |
Example of software qualified as medical device software (MDSW) under EU MDR: MDSW that provides insulin dose recommendations to a patient regardless of the method of delivery of the prescribed dose, whether via an insulin pump, insulin pen, or insulin syringe. | |||
Covered by Medical Device Regulations according to decision tree per Medical Device Coordination Group (MDCG) Guidance 2019-11: | Covered by Medical Device Regulations according to decision tree per MDCG document 2019-11: | |||
1. Is the product “software” according to the definition of MDCG 2019-11? | YES | 1. Is the product “software” according to the definition of MDCG 2019-11? | YES | |
2. Is the software an “MDR Annex XVI device,” an “accessory” for a medical device according to Art. 2(2) of the MDR or IVDR, or “software driving or influencing the use of a (hardware) medical device?” | NO | 2. Is the software an “MDR Annex XVI device,” an “accessory” for a medical device according to Art. 2(2) of the MDR or IVDR, or “software driving or influencing the use of a (hardware) medical device?” | NO | |
3. Is the software performing an action on data different from storage, archival, communication, or simple search? | YES | 3. Is the software performing an action on data different from storage, archival, communication, or simple search? | YES | |
4. Is the action for the benefit of individual patients? | YES | 4. Is the action for the benefit of individual patients? | YES | |
5. Is the software MDSW according to MDCG 2019-11? | YES | 5. Is the software MDSW according to MDCG 2019-11? | YES |
Beyond a potential precertification DHT regulatory scheme, the current quality management system framework for medical devices needs to be adapted for DHTs to ensure adequate surveillance based on risk. Although the consensus standard, IEC 62304:2006, provides a framework for life-cycle management activities and tasks to ensure safety and performance of medical device software, the framework may not be appropriate for DHTs not classified as medical devices.32 Also, given the scope and breadth of DHTs using connected systems and platforms, the roles and responsibilities of DHT manufacturers and developers need to be clearly defined to support life-cycle management issues. Additionally, DHT product malfunctions, errors, and adverse events need to be appropriately reported and investigated in a timely manner as part of the continuous improvement process.
Vendor Considerations
To advance digital health innovations, the pharmaceutical industry needs to effectively partner with third-party vendors of novel DHTs. Digital health vendors may have expertise in developing software tools using agile development processes with quick turnaround, but this partnership framework needs to account for patient safety, effectiveness, and product quality.
HealthXL published industry guidance outlining 13 different categories on digital health vendor assessment for clinical trials spanning such issues as quality management principles, data handling, interoperability, and cybersecurity.33 However, in the context of this article, we propose three key criteria as part of due diligence activities to happen before DHT vendor qualification by a pharmaceutical organization. These due diligence efforts should be commensurate with the “intended use” of the DHT and associated patient harm.
Three key criteria in the vendor evaluation process include technical, quality system, and regulatory expertise:
- Technical expertise: The vendor should have subject matter expertise and experience in development, launch, and maintenance of the relevant DHT. For example, if considering a DHTT for remote patient temperature monitoring, the vendor should have technical understanding of the temperature sensors, data acquisition, visual display of outputs, and wireless connectivity.
- Quality system expertise: The vendor should have adequately established processes, procedures, and responsibilities related to the DHT. In the case of a remote temperature monitoring example, processes need to be in place for managing HIPAA and general data protection regulation (GDPR) requirements for the product as required.
- Regulatory expertise: The vendor should have experience in interacting with health authorities and submitting pre-submissions and marketing authorization applications. The vendor’s regulatory experience can enable a better understanding of the appropriate regulatory requirements and pathways for using and commercializing a DHT.
Market Access and Reimbursement
Beyond marketing authorization, DHTs also need to satisfy payer evidence requirements for reimbursement and pricing, which are essential to gain market access. Policies and guidelines are needed not only for reimbursement of DHTs used as medical products, but also when DHTs are used to generate clinical evidence for medicines. Adding to these challenges, pricing and reimbursement processes remain dependent on regional and country-specific requirements. For example, although a product may be CE marked under EU MDR/IVDR, reimbursement and pricing requirements are not harmonized across EU member states, which makes planning and launching products a major challenge.
DHT developers need to evaluate pricing and reimbursement options as early as possible for cost evaluations and options. In various geographies, the pricing and reimbursement process is less well known or challenging due to political and economic circumstances. Health care delivery depends largely on the technologies available at the point of care. The accessibility of new technologies within health care depends on the availability of the technology to patients. For a technology to be considered in a country, the technology’s safety and efficacy need to be evaluated to support the authorization for accessibility. Once the technology has received authorization, it will follow additional assessments to ensure it is a wise use of resources before receiving support for adoption and use within the country. This includes cost-of-illness analysis, cost-benefit analysis, and cost-utility analysis. To understand the challenges with development, coverage, and adoption of DHTs, we outline a three-phase process for their systematic evaluation: marketing authorization, health technology assessment, and utilization decision-making (see Table 4).
Phase | Process | Description |
---|---|---|
One | Marketing Authorization | Evaluation of a technology’s safety and efficacy profile to support authorization for use. Marketing authorization does not ensure the technology will be adopted for use in the country’s national health care system. |
Two | Health Technology Assessment | The bridge between research and decision-making to inform policy makers of their recommendations for use and reimbursement under evaluation. |
Three | Utilization Decision-Making | Assessment if the new technology provides any incremental benefit compared to current practice as an economic analysis is executed. |
The Centre for Innovation in Regulatory Science (CIRS) published a report on digital technologies for clinical evidence generation, which identified opportunities for reducing barriers for DHTs used in the review and reimbursement of medicines.34 One of the key recommendations included developing a common digital infrastructure to improve data accessibility, trust, and collaboration between regulators and HTA organizations. Also, the limited knowledge and familiarity of DHTs within the HTA community underscores the need for greater education and harmonization on DHT terms and concepts among stakeholders.
In the US, reimbursement and coverage of breakthrough and innovative medical devices and DHTs remain uncertain with the proposed rule by the Centers for Medicare & Medicaid Services (CMS) to repeal a final rule titled “Medicare Coverage of Innovative Technology (MCIT) and Definition of Reasonable and Necessary”. 35 The MCIT final rule would have established a Medicare coverage pathway for innovative technologies based on the FDA’s marketing authorizations of breakthrough medical devices. DHTs would have benefited from the MCIT rule as several notable DHTs classified, as medical devices have obtained FDA breakthrough device designation in recent years.36 ,37 However, with the proposed repeal, CMS noted that there is limited clinical evidence of Medicare beneficiaries in the clinical trials as the basis for FDA approval, and the FDA and CMS operate under different statutory and regulatory standards for marketing authorization and coverage. Given the ongoing challenges with DHT reimbursement, the proposed repeal of the MCIT rule may be a significant setback for DHT adoption.
Conclusion
The COVID-19 regulatory flexibilities, risk-based framework, medical product development considerations, life-cycle management issues, vendor due diligence, and market access challenges and opportunities discussed in this article provide important reflections on the successful development and adoption of novel DHTs.
However, despite the enormous potential of emerging DHTs, access to essential health care services and great health disparities within and across both developed and emerging economies remain huge challenges. With a growing digital divide, health authorities, health care providers, patient advocacy organizations, and industry stakeholders need to collaborate to develop appropriate guidelines and best practices to foster DHT innovation and ensure access to high-quality medicines.
Recognizing this urgent need, the World Health Organization (WHO) Global Strategy on Digital Health advocates for the development of sustainable digital health ecosystems, robust governance structures, and patient-centered approaches to management of DHTs.38 As digital health continues to transform the health care landscape, DHTs will significantly improve the quality of life and lifespan of patients with chronic and debilitating diseases as long as the health care community develops and uses DHTs to empower patients with their health care decisions while maintaining privacy, transparency, and integrity.
- 1Bestsennyy, O., G. Gilbert, A. Harris, and J. Rost. “Telehealth: A Quarter-Trillion-Dollar Post-COVID-19 Reality?” McKinsey & Company website. Published 9 July 2021. https://www.mckinsey.com/industries/healthcare-systems-and-services/our-insights/telehealth-a-quarter-trillion-dollar-post-covid-19-reality?cid=eml-web
- 2Pronovost, P. J., M. D. Cole, and R. M. Hughes. “Remote Patient Monitoring During COVID-19: An Unexpected Patient Safety Benefit.” Journal of the American Medical Association 327, no. 12 (2022): 1125–1126. doi:10.1001/jama.2022.2040
- 3US Department of Health and Human Services Office for Civil Rights. “FAQs on Telehealth and HIPAA during the COVID-19 Nationwide Public Health Emergency.” Published 2 October 2020. https://www.hhs.gov/guidance/sites/default/files/hhs-guidance-documents//telehealth-faqs-508.pdf
- 4US Food and Drug Administration. “Guidance for Industry and Food and Drug Administration Staff. Enforcement Policy for Non-Invasive Remote Monitoring Devices Used to Support Patient Monitoring During the Coronavirus Disease 2019 (COVID-19) Public Health Emergency (Revised).” Updated October 2020. https://www.fda.gov/media/136290/download
- 5US Food and Drug Administration. “Digital Health Policies and Public Health Solutions for COVID-19.” Published 28 April 2022. https://www.fda.gov/medical-devices/coronavirus-covid-19-and-medical-devices/digital-health-policies-and-public-health-solutions-covid-19?utm_medium=email&utm_source=govdelivery
- 6 a b US Food and Drug Administration. “Guidance for Industry, Investigators, and Institutional Review Boards. Conduct of Clinical Trials of Medical Products During the COVID-19 Public Health Emergency.” Published March 2020. Updated 30 August 2021. https://www.fda.gov/media/136238/download
- 7 a b c d e Pharmaceutical Research and Manufacturers of America. “Biopharmaceutical Digital Health Lexicon.” Published 19 October 2020. https://www.phrma.org/-/media/Project/PhRMA/PhRMA-Org/PhRMA-Org/PDF/P-R/PhRMA-Digital-Health-Lexicon.pdf
- 8European Federation of Pharmaceutical Industries and Associations. “Digital Health.” https://www.efpia.eu/about-medicines/development-of-medicines/digital-health/
- 9US Food and Drug Administration. “What Is Digital Health?” Published 22 September 2020. https://www.fda.gov/medical-devices/digital-health-center-excellence/what-digital-health
- 10National Library of Medicine. “BEST (Biomarkers, EndpointS, and other Tools) Resource Glossary.” Published 28 January 2016. Updated 29 November 2021. https://www.ncbi.nlm.nih.gov/books/NBK338448/#IX-D
- 11European Commission. “eHealth: Digital Health and Care: Overview.” https://ec.europa.eu/health/ehealth-digital-health-and-care/overview_en
- 23US Food and Drug Administration. “Draft Guidance for Industry, Investigators, and Other Stakeholders. Digital Health Technologies for Remote Data Acquisition in Clinical Investigations.” Published 22 December 2021. https://www.fda.gov/media/155022/download
- 12International Medical Device Regulators Forum. “Machine Learning-Enabled Medical Devices—A Subset of Artificial Intelligence-Enabled Medical Devices: Key Terms and Definitions.” Published 16 September 2021. https://www.imdrf.org/sites/default/files/2021-10/Machine%20Learning-enabled%20Medical%20Devices%20-%20A%20subset%20of%20Artificial%20Intelligence-enabled%20Medical%20Devices%20-%20Key%20Terms%20and%20Definitions.pdf
- 13De Novo Classification Request for EndeavorRx (DEN200026). https://www.accessdata.fda.gov/cdrh_docs/reviews/DEN200026.pdf
- 14US Food and Drug Administration. “Draft Guidance for Industry. Real-World Data: Assessing Electronic Health Records and Medical Claims Data to Support Regulatory Decision-Making for Drug and Biological Products.” Published September 2021. https://www.fda.gov/media/152503/download
- 15US Food and Drug Administration. “Guidance for Industry and Food and Drug Administration Staff. General Wellness: Policy for Low Risk Devices.” Published 26 September 2019. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices
- 16Office of the National Coordinator for Health Information Technology. “What Is Health IT?” https://www.healthit.gov/faq/what-health-it
- 17 a b US Food and Drug Administration. “Guidance for Industry and Food and Drug Administration Staff. Medical Device Data Systems, Medical Image Storage Devices, and Medical Image Communications Devices.” Published 27 September 2019. https://www.fda.gov/media/88572/download
- 18 a b US Food and Drug Administration. “Guidance for Industry and Food and Drug Administration Staff. Policy for Device Software Functions and Mobile Medical Applications.” Published 27 September 2019. https://www.fda.gov/media/80958/download
- 19US Food and Drug Administration. “Draft Guidance for Industry and Food and Drug Administration Staff. Content of Premarket Submissions for Device Software Functions.” Published 4 November 2021. https://www.fda.gov/media/153781/download
- 20International Medical Device Regulators Forum. “Software as a Medical Device (SaMD): Key Definitions.” Published 18 December 2013. https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
- 21US Department of Health and Human Services. “What Is Telehealth?” Published 29 June 2022. https://telehealth.hhs.gov/patients/understanding-telehealth/#what-does-telehealth-mean
- 22US Food and Drug Administration. “Guidance for Industry and FDA Staff. Radio Frequency Wireless Technology in Medical Devices.” Published 14 August 2013. https://www.fda.gov/media/71975/download
- 24European Medicines Agency. “Questions and Answers: Qualification of Digital Technology-based Methodologies to Support Approval of Medicinal Products.” Published 1 June 2020. https://www.ema.europa.eu/en/documents/other/questions-answers-qualification-digital-technology-based-methodologies-support-approval-medicinal_en.pdf
- 25International Organization for Standardization. “ISO 14971:2019. Medical Devices — Application of Risk Management to Medical Devices.” Published December 2019. https://www.iso.org/standard/72704.html
- 26 a b International Medical Device Regulators Forum. “Software as a Medical Device: Possible Framework for Risk Categorization and Corresponding Considerations.” Published 18 September 2014. https://www.imdrf.org/sites/default/files/docs/imdrf/final/technical/imdrf-tech-140918-samd-framework-risk-categorization-141013.pdf
- 27US Food and Drug Administration. “Guidance for Industry and Food and Drug Administration Staff. Changes to Existing Medical Software Policies Resulting from Section 3060 of the 21st Century Cures Act.” Published 26 September 2019. https://www.fda.gov/media/109622/download
- 28 a b c US Food and Drug Administration. “Draft Guidance for Industry and Food and Drug Administration Staff. Clinical Decision Support Software.” Published 27 September 2019. https://www.fda.gov/media/109618/download
- 29 a b c d Medical Device Coordination Group. “MDCG 2019-11. Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR.” Published October 2019. https://ec.europa.eu/health/document/download/b45335c5-1679-4c71-a91c-fc7a4d37f12b_en
- 30US Food and Drug Administration. “Digital Health Innovation Action Plan.” https://www.fda.gov/media/106331/download
- 31US Food and Drug Administration. “Developing a Software Precertification Program: A Working Model, v1.0.” Published January 2019. https://www.fda.gov/media/119722/download
- 32International Organization for Standardization. “IEC 62304:2006: Medical Device Software—Software Life Cycle Processes.” Published May 2006. https://www.iso.org/standard/38421.html
- 33HealthXL. “Digital Health Vendor Assessment for Clinical Trials.” Published September 2021. https://hxlsales.s3.eu-west-1.amazonaws.com/DIGITAL+HEALTH+VENDOR+ASSESSMENT.pdf
- 34Centre for Innovation in Regulatory Science. “2021 Workshop Report–Digital Technologies for Clinical Evidence Generation.” Published 22 February 2022. https://www.cirsci.org/publications/2021-workshop-report-digital-technologies-for-clinical-evidence-generation/
- 35US Federal Register. “Medicare Program; Medicare Coverage of Innovative Technology (MCIT) and Definition of ‘Reasonable and Necessary’.” Published 15 September 2021. https://www.federalregister.gov/documents/2021/09/15/2021-20016/medicare-program-medicare-coverage-of-innovative-technology-mcit-and-definition-of-reasonable-and
- 36MedtechDive. “Digital Health, Heart Disease Devices Feature in Latest FDA Breakthrough Designations.“ Published 2 August 2021. https://www.medtechdive.com/news/digital-health-heart-disease-devices-feature-in-latest-fda-breakthrough-de/604265/
- 37Med-Tech News. “FDA Grants Breakthrough Designation for Novel Heart Monitor.” Published 21 March 2022. https://www.med-technews.com/news/Medtech-start-up-news/fda-grants-breakthrough-designation-to-novel-heart-monitor/
- 38World Health Organization. “Global Strategy on Digital Health 2020-2025.” Published 18 August 2021. https://www.who.int/publications/i/item/9789240020924
Acknowledgments
The authors thank Lavanya Uppugonduri, Director, Quality Engineering, Device and Combination Products at Bristol Myers Squibb, for her feedback and comments that improved the content of this article.