Genetic database software as medical devices

1 INTRODUCTION

Physicians, clinical laboratories, and public human genetic variant databases (hereafter “variant databases”) all contribute to an interpretive “supply chain” supporting diagnosis and personalized care. Variant databases provide access to collective but rapidly evolving knowledge about associations between genomes and disease. Databases are increasingly used to inform clinical decision making and regulatory approvals of tests. In turn, policy makers are exploring ways to regulate the quality of these databases (U.S. Food and Drug Administration, 2018d). At the same time, more variant databases are also integrating innovative software tools to improve accessibility, usefulness, and interactivity. Such tools span from data retrieval, query, notification, and visualization functions, to risk prediction enabled by artificial intelligence. The United States National Center for Biotechnology Information's ClinVar database, for example, is developing processes to provide email alerts when a variant assertion changes (an assertion is an “informed assessment of a genotype–phenotype correlation [or lack thereof],” such as benign, pathogenic, or drug resistant). The BRCAExchange.org database, which pools publicly available knowledge on correlations between BRCA1/2 gene variants and breast and ovarian cancer, has developed a mobile app that provides a notification to patients interested in “following” their variant, and knowing if assertions change over time. In the era of big data, healthcare decision makers are faced with an unprecedented deluge of molecular and health-related data. Software will no doubt play a central role in the future of personalized medicine. Genomic communication software tools may also help to democratize access and make genetic data more useful and intelligible to patients and the lay public. Other tools enable risk prediction or stratification: the Breast and Ovarian Analysis of Disease Incidence and Carrier Estimation Algorithm (Cambridge University), for example, calculates the individual risk level for developing breast or ovarian cancer, based on their family history and other data. These tools join a growing ecosystem of publicly available software (i.e., distributed freely by database or third-party developers on the web or app stores) that supports the sharing and interpretation of genetic data.

Publicly available genomic software tools have the potential to improve the quality, intelligibility, and currency of data available to inform health-related decisions by health professionals and lay users. Because of the risk that inaccurate outputs could harm patients, users need assurances that software is of high quality. The global “distribution” of software to clinicians and patients over the internet also raises a pressing legal question for developers: when does a genomic software application qualify as a regulated medical device? This paper provides an international primer focused exclusively on medical device (MD) regulation for genomic communication and interpretation software. In doing so, it draws from the harmonizing guidance of the International Medical Device Regulators Forum (IMDRF), as well as the globally important US Food and Drug Administration's medical device regulations, the new European Union Medical Device Regulation (EU MDR) and European Union In Vitro Diagnostic Device Regulation (EU IVDR), and the Canadian Medical Devices Regulations. We discuss these regulatory frameworks generally, while highlighting salient differences. First, we define the regulatory schemes for medical and in vitro diagnostic devices. Second, we provide criteria, exceptions, and examples to guide the determination of when publicly available software is a MD. Third, we discuss factors that determine the risk classification of MDs, and how higher classification ties to more burdensome general, pre- and postmarket requirements. To conclude, we recommend strategies for ensuring and demonstrating that publicly available precision medicine software applications are safe and effective when used to support the predictive testing, diagnosis, and treatment of patients. While we focus on software developed to enhance the interactivity of variant databases in support of precision medicine, our discussion will also be relevant to other genomic software tools, including clinical decision support intended to provide users “with knowledge and person-specific information, intelligently filtered or presented at appropriate times, to enhance health and health care” (Senger & O'Leary, 2018), risk prediction algorithms (Hall et al., 2018), and in silico prediction tools (Prawira, Pugh, Stockley, & Siu, 2017). Our discussion is limited to the quality and regulation of genomic software. We do not address fundamental policy, technical, and possibly legal questions related to the quality of the underlying data shared by variant databases, as neither information alone nor the exercise of clinical judgment is subject to medical or in vitro diagnostic device regulation.

2 MEDICAL DEVICES, IN VITRO DIAGNOSTIC DEVICES, AND SOFTWARE

From privacy, to security, to consumer protection, many regulatory schemes potentially apply to genetic database software, and it may be complex for developers and users to navigate those that apply. In the United States, next-generation sequencing technologies are for the most part regulated under Clinical Laboratory Improvement Amendments as laboratory-developed tests (LDTs), though a number of cancer panels have recently been approved under MD regulations (U.S. Food and Drug Administration, 2017e). Both Congress and the Food and Drug Administration (FDA) have indicated that the FDA may yet become more involved in regulation of LDTs (Gibbs, 2018). In the EU, genomic data that can identify an individual is within the scope of and regulated by the General Data Protection Regulation. While each of these schemes presents its own set of policy challenges, we focus our discussion on MD and in vitro diagnostic device regulations. Under these schemes, software may be regulated when it falls under the relevant statutory definition in each jurisdiction (See Table 1).

The primary qualifying criterion of a MD or an in vitro diagnostic MD (IVD) is a manufacturer's “intended use” (discussed below). The basic premise of MD/IVD regulation is “that the devices should work as intended … a manufacturer must be able to provide a reasonable assurance of a device's safety and effectiveness under the intended conditions of use” (Senger & O'Leary, 2018). In the United States, regulation of MDs and IVDs remain procedurally similar. Indeed, in its overview of IVD regulation, the FDA indicates that “IVDs are medical devices [and] like other medical devices, […] are subject to premarket and postmarket controls” (U.S. Food and Drug Administration, 2018c). In addition, both are generally subject to regulatory control that is proportional to risk class. In the EU, MDs and IVDs are subject to similar requirements—the MDR and IVDR being separate regulations but sharing many articles and annexes. The apparent rationale for establishing distinct regulations for IVDs is based on regulatory disparities with other MDs in terms of “risk classification, conformity assessment procedures, and clinical evidence” (EU IVDR Recital 6).

Software used alone, or in combination with a MD, can qualify as a regulated MD in all three jurisdictions if intended to be used for one or more specific medical purposes (IMDRF SaMD Working Group, 2013). Software can be defined as a set of instructions or algorithms that processes input data and creates output data (MEDDEV 2.1/6—2016). Regulated software may be integral to a MD, used in the manufacture or maintenance of a MD, or stand alone. Previous guidance relating to the EU MDs Directive uses the terms accessories, modules, and stand-alone MDs (European Commission, 2016). Regulations are platform agnostic. As such, mobile and cloud-based apps may qualify as regulated MD/IVDs. Traditionally, regulators have been most concerned with software embedded in hardware MDs that could physically harm individuals, such as the Therac-25 radiation incident, where defective software had caused several fatal X-ray overdoses (Leveson & Turner, 1993). However, their perspective has been broadened by harms caused by other software. These would include stand-alone software, which is distant from the patient. Risk assessment is complicated, however, by a number of factors, such as: the ease of availability across platforms; the complex interconnection of systems and datasets; and challenges related to software development, updates, and distribution (IMDRF Software as a Medical Device (SaMD) Working Group, 2014). Consequently, in the EU context at least, it is important to determine whether a specific device counts as an MD or IVD, as this determination has downstream effects for how a device is classified and what information is required to evidence safety and efficacy.

For genetic variant database software, this determination is especially important, as it is unclear whether they might qualify as MDs or IVDs. If regarded as a natural extension of sequencing machines, they would certainly count as IVD devices. The MEDDEV 2.1/6 interpretation, for example, considers software to be an IVD if “intended to capture and analyze together results obtained for one patient by one or more IVD […] to provide information falling within the definition of an IVD MD, for example, differential diagnosis.” This guidance goes on to provide examples of IVD devices, one of which being “software that integrates genotype of multiple genes to predict risk of developing a disease or medical condition.” Yet, the US, the EU, and Canada all recognize the examination of “specimens” as the core element to the definition of IVDs (Table 1). It is our contention that to count the data extracted from sequenced data as a “specimen” itself is a stretch in interpretation. Doing so would dramatically expand the scope of what counts as an IVD device, given the fact that several devices operate on data derived from the examination of specimens at some stage. To retain a sensible distinction between MDs and IVDs, it makes sense to interpret “specimen” narrowly, excluding genetic variant database software from the definition of IVDs if they are separate to sequencers.

The application of regulations to software reflects a fundamental policy tension. On one hand, variant databases and developers who make software tools publicly available could potentially improve the quality, availability, currency, and usefulness of genomic knowledge informing diagnosis and treatment. On the other hand, inaccurate or outdated software outputs may lead to harmful healthcare decisions by clinicians or lay users, and raise concerns about database and developer liability. Under-regulation might expose the public to undue risk. Conversely, onerous regulatory controls, or simply uncertainty about what rules apply, can discourage the development and distribution of innovative software. Unsurprisingly, this policy uncertainty translates into legal uncertainty as to whether a given software will be regulated, compounded where software is distributed globally, engaging numerous regulatory regimes (that are also shifting unpredictably in an attempt to keep pace with rapid technological development).

3 MANUFACTURER'S “INTENDED USE”

At the highest level of generality, an instrument or software is an MD or IVD if its intended use is medical in nature (e.g., diagnosis, treatment, or prevention of disease) (Table 1). Most statutory definitions of MDs make explicit reference to the intended use of the product as a predefining characteristic. Specifically, the FDA defines “intended use” according to the manufacturer's “objective intent.” This definition flows from s. 801.4 of the US Code of Federal Regulations, which provides that “intended uses” are determined by expressions (any labeling, advertising, or statements), or by the circumstances of the device's distribution or use (known to the manufacturer) (U.S. Code of Federal Regulations, 2017). Still, the reader should bear in mind that, at the time of writing, there is ongoing controversy surrounding the FDA's application of this objective intent standard for determining a manufacturer's labeling requirements. In short, the FDA considered expanding s. 801.4 to allow investigating the “totality of evidence” to establish that a manufacturer objectively intended for a device to be used for a purpose other than that for which it had been approved, to then require the said manufacturer to update its labeling (U.S. Food and Drug Administration, 2017b). This interpretation appears to go beyond the currently applicable standard, which focuses solely on a manufacturer's knowledge of unapproved use, leaving industry members confused as to the role of knowledge alone in the determination of intended use (Kahan et al., 2017). In response, the FDA suspended these amendments. This controversy demonstrates the potential tension between manufacturers who require clarity about the obligations being placed upon them and regulators who wish to prevent regulation being evaded simply by avoiding overt medical claims.

In all likelihood, the Snitem judgment suggests that the court will increasingly emphasize the function of the device to determine the intended use of the device.

Compared to the United States and Europe, the role of “intended use” is less direct in Canada. Of all the jurisdictions studied in this article, Canada is the only one without explicit reference to “intended use” in the regulatory definition of a MD (though the definition of IVD does refer to “intended use”). Regardless, the intended use of a MD is the primary criterion for determining the device's risk class (Health Canada, 2010, 2015). Although the practical effect of this discrepancy remains unclear to us, it highlights how the same regulatory standard or term may be used differently across jurisdictions. To illustrate, in the United States, a manufacturer might be required to amend the labeling of its device if the said device was used in a manner that was not approved (under s. 801.4 of the CFR, and subject to the “knowledge” standard discussed previously). By contrast, in Canada, the use of a device in a manner not intended by the manufacturer does not affect the classification of the device—and presumably, applicable labeling requirements and regulatory controls (Health Canada, 2015). While the obvious follow-up question should be what “not intended by the manufacturer” means in Canadian practice, this comparison nevertheless illustrates the differential effects of third-party use on the labeling (and potentially the classification) of a device across United States and Canadian jurisdictions, complicating the calculus for software developers.

4 IS MY DATABASE SOFTWARE AN MD/IVD? CRITERIA AND EXCEPTIONS

Variant databases are often established to inform genetic medicine, so the natural assumption is that any software application these databases distribute will be a MD. There are, however, a number of relevant exceptions.

5 RISK CLASSIFICATION AND REGULATORY REQUIREMENTS

The rules or controls that apply to an MD/IVD in a particular jurisdiction depend on the device's risk classification (Table 2). The risk class is important to know in advance of software development and distribution. Regulatory requirements include general controls, labeling, premarket controls (notification or approval), general safety and performance requirements, and postmarket surveillance. In the EU, MDs that conform to regulatory requirements are labeled with the CE Marking (“Confirmité Européene”). General controls are the least stringent regulatory layer, and will generally be the sole applicable regulation when a MD is of the lowest risk class (IMDRF SaMD Working Group, 2013). Yet even general controls can be quite onerous. Typically, they pertain to labeling; adulteration; misbranding; establishment registration; device listing; premarket notification; banned devices; notification and repair, replacement, and refund; records and reports; restricted devices; and good manufacturing practices. Beyond general controls, the regulator may exercise specific controls, such as premarket approval and postmarket surveillance over medium- to high-risk devices. According to the FDA, premarket approval “is based on scientific evidence providing a reasonable assurance that the device is safe and effective for its intended use or uses” (U.S. Code of Federal Regulations, 2017). In Europe, premarket assessment of conformity is generally delegated to Notified Bodies (EU MDR, EU IVDR, Annex VII). From a practical perspective, it is key for a genomic software developer to determine if the software is a MD or an IVD, and how the software might be categorized with regards to risk, across jurisdictions where the software is made available.

Regulatory frameworks typically default to a risk-based approach to regulation. Stand-alone software, if qualifying as a MD/IVD, tends to fall in lower risk classes (unless errors could lead to immediate danger) (Quinn, 2017). Generally, whether the device is intended for use in a clinical context or for use by the public (e.g., self-testing) can affect risk categorization if risks are higher when inexperienced lay people use the app (IMDRF SaMD Working Group, 2014). The IMDRF risk-based approach has defined two general criteria for determining the risk class of software (IMDRF SaMD Working Group, 2014). The first factor is the significance of the information provided by the software to the healthcare decision. Software poses a high risk if outputs are used in the contexts of treatment or diagnosis to inform an immediate or near term action. Where outputs drive clinical management, by simply aiding in treatment or diagnosis, software is considered medium risk. Low risk software does not trigger an immediate action, and merely informs treatment or diagnostic options, or helps to aggregate relevant information. The second factor is the state of the healthcare situation or condition. In critical contexts, timely action is vital to avoid death, disability, or serious health deterioration. In serious contexts, timely intervention is important to mitigate long-term irreversible health consequences. In nonserious contexts, timely diagnosis or treatment is important but not critical to mitigate long-term irreversible consequences. More detail on these factors is available in Box 1. Examples of software classified according to risk are available in Box 2.

Some significant distinctions to the default risk-based approach must be noted. First, the FDA's future approach to patient decision supports software may be at odds with the IMDRF's risk-based framework. Specifically, while interpreting the statutory exemptions of clinical decision support software created by the Cures Act, the FDA has implemented a nonstatutory, policy exemption for patient decision support software (U.S. Food and Drug Administration, 2017c). While this policy exemption mirrors the statutory exemption for clinical decision support software, it is not explicitly risk-based. Instead, the Clinical Decision Support Guidance suggests that software will be regulated if it fails to provide a sufficient basis for its recommendation, regardless of risk. Predictably, stakeholders were concerned. The American Medical Informatics Association, for instance, highlighted the lack of discussion on “variability across patient populations in their health literacy” (American Medical Informatics Association, 2018). Risk assessment may also be affected by statutory or discretionary genetic exceptionalism, reflecting a belief that genetic data is more special (i.e., risky) than other health data. The EU IVDR, for example, adopts a deterministic approach to classify the risk of genetic IVDs, assigning all genetic tests to the same medium–high risk class regardless of whether the test is predictive or diagnostic (EU IVDR, Annex VIII). This classification mandates “comprehensive requirements for clinical evidence of performance and effectiveness” before a genetic IVD can receive a CE Marking and be placed on the market (Hall et al., 2018). This may result in procrustean regulation of genomic software: strict rules if they qualify as IVDs or no rules at all. In Canada, risk classification of MD/IVDs is rule based, and focused primarily on the device's intended use. While Health Canada is currently preparing draft guidance specifically for software as a MD (Health Canada, 2018), the current practice seems clear: the importance of the information transmitted by the device is secondary to the device's intended use (Health Canada, 2015, 2016). If nothing else, this increasing regulatory differentiation across the various jurisdictions may perhaps signal the need for further IMDRF harmonization.

6 RISK MANAGEMENT STRATEGIES

Genomic software developers have ethical and regulatory duties to mitigate the risk that their software outputs prompt a harmful healthcare decision. Among these duties is to ensure that the appropriate uses and limitations of software applications are clearly and transparently described. This follows the general expectation for variant databases that they curate and share genomic data in a manner that is “truthful and not misleading … in language that is clear and understandable” (U.S. Food and Drug Administration, 2018d). General software design, development, and documentation practices should be followed, informed by the software's purposes and reasonable foreseeable uses (IMDRF SaMD Working Group, 2014). It may also be important to consider how changes to the software will be implemented, which depends on one's ability to control versions and successive implementations of the software. As software development is often an iterative process, adequate records of product performance, validation, and quality assurance should be kept. The general regulatory concept of postmarket surveillance applies helpfully to software. One example of a postmarket surveillance system is the UK Medicines and Healthcare products Regulatory Agency's Yellow Card scheme, used to monitor adverse drug reactions, MD adverse incidents, and counterfeit MDs. Similarly, developers should take steps to capture user feedback, which can help to better understand the human factors that may affect how software is ultimately used. “After all, even as computers become increasingly sophisticated, there will always be challenges at the human–computer interface, where unintended “friction” between human and machine can rapidly defeat the potential benefits” (Senger & O'Leary, 2018). An intuitive user design, across platforms on which the software is likely to be implemented, can also ensure the software is appropriately used. Building on the concept of proper “labeling,” careful consideration should be given to the software's terms of use. These terms could include clear information about any quality limitations of algorithms or the underlying genomic data, which can help “users question the validity of output of the [s]oftware and avoid making incorrect or poor decisions” (IMDRF SaMD Working Group, 2014). Security to ensure the availability, integrity, and confidentiality of data is also an important consideration, especially where software ingests user data as inputs. Data protection laws and related duties of confidentiality for personal data may also apply.

Encouragingly, regardless of regulatory application, there exist strong incentives for developers to establish risk management practices. Among other incentives, responsible development and dissemination of software may decrease the chance that the software attracts the attention of regulators or lawmakers, or lessen the burden of transitioning to regulated status. In fact, the prospects of streamlined regulation for responsible developers may no longer be a mere mirage. The FDA has begun work on the Digital Health Software Precertification (Pre-Cert) Pilot Program. This Pre-Cert Program is intended to provide more “streamlined and efficient regulatory oversight of software-based devices developed by manufacturers who have demonstrated a robust culture of quality and organizational excellence, and who are committed to monitor real-world performance of their products once they reach the US market” (U.S. Food and Drug Administration, 2018a). Critically, under this program, the focus of the FDA is primarily the software developer, not the product. Indeed, upon completion of the Pre-Cert pilot program, Europe may soon follow with its own precertification analog. Assuredly, the promise of a more streamlined regulatory process could motivate software developers to foster an internal culture of responsible and responsive development.

7 CONCLUSIONS

It is not straightforward to determine if MD/IVD regulations are applied or should be applied to genomic software tools. The rules are in flux as law makers and regulators struggle to keep up with the “appification” of health and medicine, and to promote innovative device development while also protecting patients from harm. Appification has spurred incredible innovation, in part by democratizing both device “manufacture” —beyond well-resourced companies to include small scale developers—as well as device selection and use beyond medical institutions and professionals to include patients and lay users (Quinn, 2017). It has also fundamentally changed the nature and complexity of risks of devices, raising daunting conceptual and practical challenges for regulators. The data deluge of genomics is ripe for software intermediation, but genomic complexity and unfamiliarity may mean such tools are subject to exceptional regulatory scrutiny.

At the heart of the software as MD question lies the policy tension between access to innovative tools to interact with genetic information on one hand, and overexposure of the public to risk on the other. This is part of a broader debate about access to and the quality of our accumulating genomic knowledge. Previously, we have argued that public variant databases remain unlikely to attract legal duties toward patients for data quality and timeliness, despite their increasing medical importance. These duties continue to rest primarily with physicians, and in some cases laboratories (Thorogood, Cook-Deegan, & Knoppers, 2017). Sharing genomic software in addition to data may change this equation by establishing novel legal relationships between databases and users. Regardless, many variant databases are keen to adhere to curation and management standards, such as those recently released by the FDA (U.S. Food and Drug Administration, 2018d). Compliant databases can receive FDA recognition, meaning their data can be used as evidence in sequencing test regulatory submissions. While this paper has focused on MD/IVD regulation of software, broader legal questions—such as who bears responsibility for the quality and currency of genomic data used in health care (Stevens, Senner, & Marchant, 2017)—merit further exploration.

CONFLICT OF INTERESTS

The authors have no known conflicts of interest.