Are Streetlight Effects Always Bad?

It would be wrong to condemn the streetlight approach to regulating genomics without first mentioning its possible justifications. For example, placing genomic technologies under pre-existing drug and device, privacy, or environmental regulations can be seen as a response to concerns about genetic exceptionalism, which is the idea that “genetic tests should be treated differently from other laboratory tests for oversight purposes.”⁸ The notion that genetic information might be special or unique from a public policy perspective arose during deliberations of the Task Force on Genetic Information and Insurance, formed in 1991 as part of the Joint National Institutes of Health-Department of Energy (NIH-DOE) Working Group on the Ethical, Legal, and Social Implications of Human Genome Research.⁹ Genetic exceptionalism later became a topic of scholarly debate.¹⁰ Writing in 2008, the Secretary's Advisory Committee for Genetics, Health, and Society observed a growing trend toward the rejection of exceptionalist approaches.¹¹

Lumping genomics together with other medical technologies, for purposes of regulation, may be part of this larger critique of genetic exceptionalism. Naturally, there is nothing wrong with adopting genomicsspecific laws if genomics does, in fact, pose exceptional problems. However, early calls for special regulations may have been tainted by hype and excessive hope about how informative genetic testing was going to be. An example was concerns in the 1990s that the genome is a “future diary,” “uniquely powerful and uniquely personal,” and able to “predict an individual's medical future.”^{Reference Annas12} Twenty years on, scientists still struggle to make this alleged Oracle say useful things about the future. It seems prudent, in retrospect, to require a high burden of proof before concluding that genomic tests raise special problems that require sui generis regulatory approaches. Shoving genomics into existing, general-purpose regulatory frameworks imposes a discipline of nonexceptionalist thinking.

A second point is that repurposing existing regulations to address new problems is a revered American tradition. The United States, dating back to the 1870s, has crafted well-functioning regulatory solutions for many different economic sectors.^{Reference Kearney and Merrill13} When mature regulatory institutions already exist, it may save time and money to use them instead of crafting new regulations from whole cloth. This reasoning prevailed as Congress considered (and ultimately rejected) proposals in the 1970s and 80s to enact comprehensive bio-technology legislation for recombinant DNA technology.¹⁴ A Working Group on Biotechnology established under the White House Cabinet Council on Natural Resources and the Environment recommended that agencies like the Food and Drug Administration (FDA), the Environmental Protection Agency (EPA), and the U.S. Department of Agriculture (USDA) regulate new biotechnologies as well as could be done with their existing legal authorities.¹⁵ The division of their responsibilities was clarified in the 1986 Coordinated Framework for the Regulation of Biotechnologies,¹⁶ with updates in 1992¹⁷ and 2017.¹⁸

This history casts an interesting light on FDA's current struggles to oversee the very latest genomic technologies, like CRISPR-Cas9, using a biologics framework with roots in the late 19th century when diphtheria antitoxin and smallpox vaccine were the forefront of biomedical research. Fortunately, U.S. regulators are experienced at adapting old laws to emerging challenges, and their statutes often confer jurisdiction broad enough to accommodate new technologies. The Coordinated Framework has functioned reasonably well despite occasional gaps where new products fail to fit into any of the available jurisdictional buckets — such as “drug,” “pesticide,” “medical device,” “plant pest,” “chemical” — that Congress has authorized FDA, EPA, and USDA to regulate.^{Reference Waltz19}

Relying on existing regulatory frameworks, as opposed to creating new ones, offers various advantages apart from mere expediency. For example, emerging industries often face shortages of skilled personnel, which makes it challenging for newly formed regulatory agencies to compete for staff in an already-strained industry workforce. Established regulatory agencies may have personnel with relevant skills who can be rapidly deployed. Emerging industries can benefit from the predictability of having a regulatory agency with a known track record, even if the regulator's prior experience may not always be precisely on point. An agency's overall mindset and behavior can be inferred from irrelevant precedents as well as relevant ones. Finally, it promotes administrative economy to avoid proliferating new laws and regulatory agencies every time a new technology emerges. Once created, regulatory frameworks require a certain amount of resolve and effort to decommission, even if time and technology pass them by. In an advanced regulatory state replete with well-developed regulatory institutions, regulatory solutions search for problems, as well as the other way around. Shoehorning genomics into existing regulations can seem attractive for these and other reasons, but is it the best answer? That depends on spotting and managing the streetlight effects it can cause.

Case 1. Protecting Genetic Privacy Under the HIPAA Streetlight

This article explores three instances of possible street-light effects in the regulation of genomics. The first is Congress's decision to repurpose the Health Insurance Portability and Accountability Act of 1996²⁰ (HIPAA) Privacy Rule²¹ — a federal medical privacy regulation — to serve as the United States's principal federal genetic privacy regulation, even though the vast majority of the human genome appears to have no medical significance whatsoever (at least not based on current scientific understanding).

People undergoing whole genome sequencing can expect it to detect about 3 million genetic variants — deviations from a human reference genome — with about 10,000 of these variants located in the exome, which is the roughly 1.5% of the genome that contains the genes that code for proteins and affect people's physical attributes.^{Reference Kohane22} A 2014 study found that fewer than 130 of these variants had a well-established medical significance based on the science of that time.^{Reference Dewey23} Most genomic information is not health information, and it may never be, unless one adopts the most expansive form of the assertion that all data are health data (because, in a larger sense, everything in the Universe relates to everything else).

The question is whether Congress's decision to place genetic information under the HIPAA Privacy Rule was a streetlight error — a case of repurposing an existing regulation simply because the Privacy Rule was where the streetlight was. Congress made this decision as part of the Genetic Information Non-discrimination Act of 2008 (GINA),²⁴ which defines “genetic information” in a broad way that includes non-clinically-significant test results and raw data in addition to clinically significant findings, including from tests conducted in research as well as clinical settings.²⁵ GINA ordered all such information to be placed under the protections of the HIPAA Privacy Rule, whenever the information is stored at a HIPAA-covered facility.²⁶ When debating GINA's passage, some members of Congress expressed doubts that this approach would be adequate to address the concerns people feel about their genetic privacy.²⁷ Such doubts persist even now. A recent LawSeq consensus paper concluded, after a detailed analysis to which interested readers are referred, that the genetic privacy protections HIPAA provides are “largely a mirage.”^{Reference Clayton28}

In theory, the privacy risks affecting genomic information are similar to those affecting medical records more generally. For example, both kinds of data are subject to the risk that de-identified data might be reidentified. There is nothing intrinsic to genetic information that makes it uniquely subject to this risk. Any dense, multiparametric personal data set — such as a person's electronic health record — is potentially re-identifiable, because there may be only one person in the world that all the data in the record would fit. Yet re-identification risks are especially salient and easy for people to comprehend when genomic data are involved. After all, law enforcement agencies are not in the habit of using people's pattern of doctor visits to identify crime suspects, whereas they do regularly use genomic information for this purpose.²⁹ The re-identification risks are similar, but the personal impacts may not be. The Privacy Rule's lax de-identification standards, while arguably somewhat stronger than those of the Common Rule,³⁰ fail to resolve these concerns, especially when combined with both those regulations' tolerance for unconsented sharing of de-identified data.^{Reference Evans and Jarvik31} These concerns exist even with traditional health data, but grow even more stark when genomic information is added to the mix. These and other well-known soft spots in HIPAA's privacy protections at least raise the question, “Would a little genetic exceptionalism really be so wrong?”

It is important to note that the desire for exceptionalist privacy policies cuts in two directions. While some commentators argue that genomic information deserves more privacy protections than the HIPAA Privacy Rule provides,³² others argue that HIPAA's protections are inappropriate for genomic information and should be reduced.³³ One of the most sustained critiques of this latter type has been from entities objecting to HIPAA's individual access right — the right for individuals to inspect and receive copies of data about themselves held by HIPAA-covered facilities³⁴ — as it applies to genomic information. Since December 2000, when the Privacy Rule was first finalized, it has included an access right.³⁵ However, this right could not be exercised at laboratories in all 50 states until 2014, because some states had laws blocking individuals' direct access to laboratory test results. In 2014, HHS promulgated a final rule³⁶ preempting state laws limiting individuals' access rights at HIPAA-covered laboratories, and all such laboratories became subject to the access right. This expanded individuals' access to genomic information stored at those laboratories.

HIPAA's access right is part of a 50-year tradition of federal privacy laws that treat access to one's own data as a core data privacy protection.^{Reference Cate and Winn37} Individual access rights are a “cornerstone”³⁸ of federal data privacy laws for various reasons.^{Reference Evans39} It is felt that people cannot correctly understand their data privacy risks unless they know what types of data others are storing and sharing about them.⁴⁰ People cannot give a valid, informed consent for secondary uses of their stored data if they do not know what kinds of data, precisely, they would be consenting to share.⁴¹ A number of state, as well as federal, privacy laws also protect individual access rights,⁴² as do privacy laws of other leading jurisdictions such as the European Union.⁴³ The notion that strong privacy protections include individual access rights is hardly controversial among privacy scholars and regulators.

Nevertheless, there was strong resistance to extending this protection to genomic information. One example is a 2018 report by the National Academies of Science, Engineering, and Medicine,⁴⁴ which recommends changing the HIPAA Privacy Rule to limit individuals' access to their genomic information.^{Reference Evans and Wolf45} Another example is the consent document for the National Institutes of Health's All of Us research program,⁴⁶ which suggests that HIPAA's access right extends only to genomic information that is acquired as part of a person's external electronic health records. The relevant passage of the All of Us consent poses the question, “Will I be able to see my data?” It then responds that participants will be able to see “[a]ny data you give us, like your health data” and “[y]our physical measurements” but only “[s]ome measurements taken from your samples.”⁴⁷ The consent document later states that “[r]esults explain or interpret data”⁴⁸ — which seems to exclude raw, uninterpreted variant data generated during genomic testing⁴⁹ — and only commits that “[w]e may tell you if there are results about you.”⁵⁰

This language is legally problematic. The Office for Civil Rights, which administers the HIPAA Privacy Rule, has made clear that an individual's right of access under HIPAA includes “not only the laboratory test reports but also the underlying information generated as part of the test”⁵¹ — in other words, uninterpreted variant data as well as “results”⁵² that explain or interpret those data. Some of the entities involved in the All of Us research program are HIPAA-covered academic medical centers and HIPAA-covered CLIA laboratories. At such sites, it is not correct to say that HIPAA-covered laboratories may tell people if there are results about them; such sites must tell people that there are data and results about them, if the people ask. Genomic information the All of Us program derives by studying people's biospecimens will be subject to HIPAA's access right, if it is stored at HIPAA-covered entities. The All of Us consent document does not make this clear. This advances a form of reverse exceptionalism that would afford genomic information less privacy protection than traditional health information enjoys. Doing so is at odds with Congress's mandate, in GINA, to place genomic information under the protections of the HIPAA Privacy Rule.

Turning back to the original question: Was GINA's privacy mandate a streetlight error, in which Congress repurposed the HIPAA Privacy Rule as the major federal genomic privacy regulation simply because HIPAA was there? The answer appears to be “no.” There were strong, pragmatic reasons to place genomic information under the same federal privacy regulation that governs traditional health information. Some genomic information is health information, and that subset of a person's genomic information was already subject to the HIPAA Privacy Rule even before GINA. Had GINA crafted a different set of privacy protections for non-health-related genomic information, this would have forced covered entities to comply with two sets of regulations — the HIPAA Privacy Rule for health-related genomic information, and a new and different regulation for all other genomic information. Such a scheme would have been almost impossible for covered entities to administer, because the line between health-related and non-health-related genomic information is blurry and constantly evolving. Moreover, this is not a line that institutional privacy officers are qualified to parse. Because some genomic information was already subject to the HIPAA Privacy Rule, it appears that the only workable solution was to place all of it under that same regulation.

Those who object to the Privacy Rule's individual access right, in effect, are objecting to a core feature of virtually all modern data privacy laws implemented after 1970. The problem is not that individual access is costly and troublesome to administer. The problem is that data privacy itself is costly and troublesome to administer, yet people want and deserve data privacy.

Case 2. Regulating Medical Practice Issues Under the Medical Product and Clinical Laboratory Streetlights

In genomics, there has been a persistent tendency to frame clinical practice issues as product safety questions about the tests themselves, not always based on the regulatory substance, but because FDA is perceived to be more competent than some of the regulatory alternatives. These alternatives include, for example, oversight by state medical practice regulators or self-regulation by the medical profession. Genomics policy recommendations often treat FDA as where the streetlight is, implicitly dismissing practice regulators as dim bulbs unlikely to shed much light on the appropriate clinical use of genomic information. This bias was evident as far back as the 1997 NIH-DOE report on genetic testing^{Reference Holtzman and Watson53} and the 2000 report of the Secretary's Advisory Committee on Genetic Testing.⁵⁴ Both reports called for expanded FDA oversight of genetic tests destined for clinical use, but said surprisingly little about what state medical practice regulators might need to do to get ready for a world where genetic and genomic tests are in widespread clinical use.

A central regulatory concern in genomic testing is whether the findings have sufficient quality to inform clinical decision making. A companion article in this LawSeq special issue^{Reference Evans55} explores the challenge of regulating test quality, where quality is often conceived in terms of analytic validity (whether testing reliably detects genetic variants), clinical validity (whether, based on current knowledge, those variants have known associations with particular health conditions); and clinical utility or actionability (whether such knowledge can be harnessed in clinical settings to improve patients' actual health outcomes).⁵⁶ Yet even when genomic data or test results lack these indicia of quality, this does not mean they are inherently dangerous or unsafe. Lesser-quality results have many important research, educational, regulatory, personal, and other uses that pose little risk to people's health and safety. Such data raise safety concerns only if diverted into inappropriate clinical uses. Even test results that are overtly “wrong,” in the sense of lacking analytic validity, have a place in the larger genomic information ecosystem: while not useful in clinical care, they might be highly useful for research or for regulatory science that compares the performance of different genomic testing modalities.

There are two possible ways to frame the quality challenge facing FDA and other regulators like state medical practice boards and the Centers for Medicare and Medicaid Services (CMS), which oversees laboratories under the Clinical Laboratory Improvement Amendments of 1988⁵⁷ (CLIA) regulations.⁵⁸ The first framing focuses regulatory attention at the boundary between genomic testing laboratories and the outside world. Regulators scrutinize the equipment laboratories purchase and the procedures they follow with the goal of making sure that genomic information leaving a laboratory will meet the standards of quality appropriate for use in clinical care. Regulators like FDA and CMS restrict outflows of lesser-quality information, unless those outflows fit within narrow exceptions protecting worthy uses such as research.

The second framing focuses regulatory effort at the point of clinical care. The goal is to block inappropriate clinical use — misuse is a better term — of genomic information that lacks sufficient quality for use in clinical settings (for example, direct-to-consumer tests of uncertain quality, or research-quality results to which a participant gains access). Much has been said about the potential for individuals to suffer medical injuries if they have access to low-quality genomic information about themselves. FDA warns that “[i]naccurate tests could cause healthy individuals to seek further testing and treatment to address an erroneous belief that they have, or could develop a certain condition.”⁵⁹ Yet the fact remains that a person is unlikely to experience such injuries without the complicity of a clinician who performs unnecessary prophylactic surgery or orders costly tests not justified by the person's symptoms and clinical presentation. Unsophisticated laypeople cannot perform unnecessary surgery on themselves; for bad things to happen, there has to be a clinician in the loop who proceeds without appropriate clinical indications or confirmatory testing. When injuries occur, this second framing portrays the injuries as a medical practice issue best addressed by state medical practice regulators, medical professional societies, and/or the medical malpractice system. By this view, the problem is not to make all data be good, but to promote policies that foster greater clinician awareness of data-quality differences and appropriate clinical responses to data of varying quality.

In theory, policymakers could pursue both approaches simultaneously: FDA and CMS would continue their efforts to enhance the quality of genomic information that flows out of laboratories and to require clear labeling to reveal any quality concerns. Simultaneously, governmental and informal practice regulators would strengthen barriers and incentives to deter inappropriate clinical reliance on lesser-quality findings that, for many legitimate reasons, will always be part of the overall genomic information ecosystem.

In practice, the United States has relied very heavily on the first approach, deploying its federal medical product and clinical laboratory regulators to try to police flows of information leaving laboratories. As a CMS official once explained, “In general, when patient-specific results are reported from the laboratory, it is assumed that they will or could be used for patient care purposes” and thus, in CMS's view, they should be subject to CLIA.⁶⁰ It is worth calling out the biases implicit in a statement like the one just quoted. It presumes state medical product regulators are ineffectual or helpless to control how clinicians use genomic information. It presumes that members of the medical profession cannot or will not make sound decisions about the appropriate clinical use of any genomic information that falls into their hands — even if, for example, CMS or FDA required the information to carry a warning that it is unsuitable for use in clinical decision-making. It presumes that federal product and laboratory regulators are where the light is.

These presumptions leave important questions unanswered. Suppose, for the sake of argument, that CMS is correct that genomic information, regardless of its quality, will (or could be) used for patient care purposes, if it ever is allowed outside the laboratory. What conditions might cause clinicians, who as a class are very concerned about patient safety, to do this? For one thing, the lesser-quality data might be the only data available, if the patient's insurer refuses to reimburse confirmatory testing. Also, there is no well-defined standard of appropriate follow-up care when an asymptomatic patient comes to a clinician with troubling unconfirmed test results, but no other clinical indication or history of disease.⁶¹ These conditions place clinicians in a difficult position as gatekeepers, charged with denying imprudent or wasteful follow-up care yet potentially liable for doing so. Medical practice regulators, state legislators, and the medical profession urgently need to engage with the problem of elaborating an appropriate standard of care for genomic testing follow-up. Framing patient safety as merely a matter of product and laboratory regulation distracts from needed policy development in these and other areas.

The streetlight approach ultimately cannot optimize patient safety. The laboratory boundary is porous, and genomic information of varying quality will flow out of laboratories and enter the larger genomic information ecosystem. This porosity is unavoidable for several reasons. FDA admits there are limits to its capacity to make premarket determinations about the safety and effectiveness of genome-scale tests, which generate some additional information unsuitable for clinical use as a byproduct of detecting clinically useful variants.⁶² Moreover, the scientific understanding of the genome is constantly evolving, and information a lab releases today, thinking it is clinically significant and suitable for use in clinical care, may later turn out not to be. There are limits — statutory and constitutional — on FDA's and CMS's authority to block data flows leaving laboratories.⁶³ In addition, laboratories have ethical and legal duties, under certain circumstances, to share information with tested individuals, even if the information may not meet the quality standards for use in clinical decision-making.⁶⁴ It would be neither lawful nor desirable for FDA and CMS to try to block all flows of genomic information that fall below standards for use in clinical care.

Keeping patients safe requires regulatory efforts on multiple fronts, including at the laboratory boundary and at the point of care. Looking for solutions under the FDA and CMS streetlights cannot make patients safe, if the key lies (at least in part) in promoting appropriate clinical use of genomic information and appropriate policies for reimbursement of confirma-tory testing.

Case 3. Regulating Genomic Software Under the FDA Streetlight

Genomic software, as discussed elsewhere in this special issue,⁶⁵ supports three analytical processes during genomic testing. Primary analysis converts the raw data detected by a physical device — the sequencing instrumentation — into a listing of the nucleotides found in each DNA fragment the instrument tested.^{Reference Celesti, Goldfeder and Moorthie66} Secondary analysis software reassembles these fragmentary readings probabilistically into a complete model of the tested portions of the person's genome. The result is a variant call format (VCF) file that identifies the person's genetic variants, highlighting locations where the person's genome differs from an idealized human reference genome.⁶⁷ Tertiary analysis seeks to interpret what these variants mean, in terms of potential impacts on the person's health. The software used in tertiary analysis helps prioritize variants for further analysis, links the variants to currently known information about their potential clinical significance, and prioritizes variants that should be discussed in the person's test report.⁶⁸ The phrase “bioinformatics pipeline” is sometimes used to refer collectively to these various steps of analysis.

The quality of information produced by a genomic test depends very critically on how well this software performs. This fact makes it seem wise to subject genomic testing software to some form of regulatory oversight. The oversight could, for example, be provided through formal governmental regulation, through private accreditation bodies such as the Joint Commission or the College of American Pathologists (CAP) that are approved to carry out certain oversight responsibilities under the CLIA program,⁶⁹ or through another professional body recognized in the software industry, such as the Institute of Electrical and Electronics Engineers.

FDA has relevant experience, because it has long regulated software embedded in physical medical devices such as pacemakers, drug infusion pumps, and diagnostic imaging equipment.⁷⁰ To the extent FDA regulates genome sequencing hardware, FDA would also regulate its embedded software. Many genomic testing laboratories, however, rely on stand-alone (non-embedded) software for all or part of their bioinformatics pipelines. This stand-alone software might be supplied by a cloud provider or an independent software vendor, or it might include code that the lab created on its own. In 2013, FDA cooperated with counterpart regulators in other countries to conceptualize “software as a medical device” (“SaMD”): stand-alone medical software that, in its own right, fits the regulatory definition of a medical device that FDA can regulate.⁷¹ This concept would enable FDA to regulate stand-alone genomic software, even though it is not embedded in an FDA-regulated sequencing instrument.

But should FDA regulate genomic testing software? Some observers view FDA as the most qualified federal agency — perhaps the only qualified agency — to serve as a genomic software regulator, and FDA has signaled its intent to embrace this role.⁷² Yet two important nuances need further study.

The first nuance is that FDA clearly has jurisdiction, under the 21st Century Cures Act,⁷³ to regulate much of the software in the genomics bioinformatics pipeline, but it is not so obvious that FDA has jurisdiction to regulate all of it.⁷⁴ “Software” is an extremely broad term, encompassing systems that perform diverse functions to support a wide variety of activities, which may lie within the scope of different regulatory frameworks. It is unwise to decide which regulator should regulate “software,” without considering the functions the software performs.

By analogy, “robotics” is also a very broad term. Robots that drive trucks and robots that aid in surgery are performing very different functions in very different environments. Optimal regulatory policy might assign different regulators to oversee the activities of these robots — for example, having the state highway department oversee the truck-driving robots, while medical product and practice regulators oversee the robotic surgeon. The same is true of software: the right regulator depends on what the software does.

Genomic software performs two conceptually distinct functions. The first function is to enhance the performance of sequencing instrumentation. The software used in primary and secondary analysis helps a medical device accurately do its job, which is to detect a person's genetic variants. This is rightly characterized as a device-related function, and it squarely falls within the subject matter FDA regulates. The software performs signal processing to convert the raw signals a physical device detects into accurate, useful outputs in a format humans can use: in this case, variant calls identifying a person's genetic variants.

In contrast, tertiary analysis software performs a very different function that is not device-like. It instead mimics functions traditionally performed by humans in the context of clinical laboratory analysis and the practice of medicine. This software helps interpret how the variants detected during sequencing may affect an individual's health. Tertiary analysis software enhances the performance of people — the laboratorians and clinicians who must diagnose and treat a person who is in their care. “The interpretive process typically requires a mix of interpretive software and expert human judgment.”⁷⁵ It is not so clear that FDA is the right regulator for tertiary analysis software.

In part, this is because of a second nuance that has been left unexplored in FDA's discussions of software regulation. Placing software under FDA regulation has the side effect of placing it under a product liability tort regime. FDA would be deeming the software to be a device — a product rather than a professional or informational service. Courts accord significant deference to FDA's determinations. If FDA determines that a piece of software is a medical product, state courts are likely to treat it as such. This means the software would be subject to strict product liability suits, as opposed to the far-more-lenient malpractice or general negligence tort regimes that currently apply when laboratory errors contribute to a patient injury.^{Reference Marchant76}

Strict product liability seems appropriate for primary and secondary analysis software, which performs a device-related function integral to the safety and effectiveness of the sequencing hardware, which itself is subject to strict product liability. In contrast, product liability seems far less appropriate for genomic interpretation software used in tertiary analysis. Physicians and laboratory professionals, when engaged in genomic interpretation, are liable only for negligence, usually measured relative to a professional or general reasonability standard. Diagnostic determinations by human professionals have never been subject to strict liability, where a wrong diagnosis is actionable no matter how much care was taken to get the diagnosis right. A negligence standard, rather than strict liability, seems appropriate for software that interprets the clinical significance of gene variants.

Under the Supreme Court's holdings in Medtronic v. Lohr ⁷⁷ and Riegel v. Medtronic, ⁷⁸ strict liability failure-to-warn suits for FDA-regulated SaMD appear unlikely to be preempted. Device manufacturers enjoy protection against product liability suits for devices approved through FDA's premarket approval process, but not for devices cleared through FDA's 510(k) process.⁷⁹ This is because premarket approval involves a product-specific determination by FDA that the device is safe and effective, which preempts state lawsuits that would impose alternative safety requirements.⁸⁰ FDA's current proposals for regulating SaMD,⁸¹ which are still evolving, move away from product-specific premarket review altogether. Instead, FDA would review attributes of the software developer,⁸² such as whether it “demonstrate[s] a culture of quality and organizational excellence based on objective criteria, for example, that … [the developer] can and do[es] excel in software design, development, and validation (testing).”⁸³ Under Lohr and Riegel, it is hard to see how this sort of review by FDA would preempt state product liability suits for injuries involving genomic software.

Since 2015, FDA has held a series of well-attended one- and two-day Public Workshops to clarify the agency's future role in regulating next-generation sequencing and the software it utilizes. In reviewing 2,845 pages of verbatim transcripts from these meetings, not once were the phrases “products liability” or “product liability” or “strict product liability” uttered, nor was there any discussion of the serious unintended consequences product liability could have for the gene sequencing industry.⁸⁴ FDA appears to be setting policy without full consideration of the broader legal context in which the agency — and its regulated entities — operate.

Because of these potentially serious legal consequences, it is crucial to delineate which portions of the genomic testing bioinformatics pipeline FDA can regulate: Can FDA regulate only the primary and secondary analysis software performing device-related analytical functions, or can FDA also regulate the tertiary software used in variant interpretation? In a 2017 draft guidance document,⁸⁵ FDA suggested that it can regulate all “algorithms that … analyze and interpret genomic data (such as genetic variations to determine a patient's risk for a particular disease.”⁸⁶ In September 2019, FDA replaced that document with a second draft guidance,⁸⁷ but reiterated the agency's view that bioinformatics software used to process high-volume “omics” data (such as by processing signals from genomic tests) is subject to FDA device regulation if it produces patient-specific information, whether or not the software is clinical decision support (CDS) software.⁸⁸ Moreover, FDA stated that “bioinformatics software products that query multiple genetic variants against reference databases or other information sources to make patient-specific recommendations” is a medical device.⁸⁹ This suggests that FDA views all phases of the genomic testing bioinformatics pipeline — including variant interpretation — as subject to FDA medical device regulation. The more recent draft guidance concluded its public comment period in December 2019, with some comments questioning FDA's broad assertion of jurisdiction to regulate essentialy all genomic software.

It is debatable whether the position stated in FDA's September 2019 draft guidance is consistent with the 21st Cures Act. Section 3060(a) of that Act removes several categories of medical software from FDA's regulatory jurisdiction by expressly excluding them from the definition of a “medical device”⁹⁰ that FDA can regulate. Relevant to this discussion is a partial exclusion for CDS software,⁹¹ which was the subject of FDA's 2017 and 2019 draft guidances.⁹² The Cures Act allows FDA to regulate some, but not all, such software.⁹³ The term CDS “is used broadly and in different ways, depending on the context,”⁹⁴ but the Cures Act and FDA treat it as software that combines general medical knowledge (for example, insights from peer-reviewed literature) with person-specific data (such as a person's test results) to provide diagnostic or treatment recommendations to medical personnel.⁹⁵

The resulting partial exclusion for CDS software, codified at 21 U.S.C. § 360j(o)(1)(E), is Congress's attempt to draw a line between CDS software that performs device-like functions that FDA appropriately can regulate, versus CDS software whose functions are in the nature of medical practice that FDA should not regulate. The text of § 360j(o)(1)(E) is convoluted, but when the text is carefully unpacked, Congress did a laudable job of sketching an intelligible line.

The baseline assumption in the Cures Act is that CDS software is excluded from FDA regulation. This recognizes that it performs a practice-related function. There are, however, two situations in which Congress deems FDA oversight to be appropriate:

• FDA can regulate software when the “function is intended to acquire, process, or analyze a medical image or a signal from an in vitro diagnostic device or a pattern or signal from a signal acquisition system.”⁹⁶ For ease of discussion, I will call this “signal processing software,” and it is a category of software FDA long has regulated. An example would be software that enhances mammogram images to highlight areas suspicious for disease, to help radiologists focus on the suspected lesion.^{Reference Thompson97} The Cures Act allows FDA to continue regulating such software, just as the agency has done in the past.

• The second category of CDS software that FDA can regulate is sometimes referred to as “black box”^{Reference Price98} medical software: software that makes recommendations, the basis for which is not transparent to the user who receives the recommendation. If the software is not “black box” software, Congress seems to consider it a medical practice issue to ensure that health care providers vet the recommendations and decide whether to follow them. If such vetting is not possible, however, Congress wants FDA to regulate the software. Thus, the Cures Act allows FDA to regulate black-box CDS software that is not intended to enable the “health care professional to independently review the basis for such recommendations that such soft-ware presents” so that there is an intent that the “health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”⁹⁹

FDA's assertion that it can regulate software that processes signals from genomic testing devices¹⁰⁰ is consistent with this first exception. Genomic software used in primary and secondary analysis seemingly fits this description — it processes and analyzes signals detected by the sequencing analyzer. It is not clear, however, whether variant interpretation software used in tertiary analysis is correctly characterized as signal processing software. FDA's 2019 draft guidance seems to recognize that variant calls are not mere “signals” that must be further processed to yield a test result.¹⁰¹ Rather, variant calls are completed test results in their own right, reporting specific genetic variants that a person possesses.

FDA's 2019 draft guidance instead seeks to fit the variant interpretation software used in tertiary analysis into the second exception above, that is, the exception that allows FDA to regulate black-box software. Note, however, that Cures Act only allows FDA to regulate CDS software if it is so non-transparent that users have no way “to independently review the basis for such recommendations that such software presents.”¹⁰² FDA's 2019 draft guidance asserts that “software products that query multiple genetic variants against reference databases and other information sources” are medical devices because “the HCP [healthcare professional] is not expected to be able to independently evaluate the basis for the software's recommendations.”¹⁰³ Yet if genomic interpretation software relies on publicly available reference databases (such as ClinGen Expert Curated Human Variant Data, which FDA has recognized as a form of reliable scientific evidence¹⁰⁴) and other information (such as peer-reviewed literature) to which health care providers have access, then the software is not properly characterized as a black box.

The fact that it might be difficult or time-consuming for a health care professional to look up the reference sources is not the type of inscrutability that triggers FDA regulation under the 21st Century Cures Act.¹⁰⁵ Elsewhere in FDA's 2019 draft guidance, the agency makes clear that CDS software that relies on publicly available information sources such as FDA-approved drug labeling, clinical practice guidelines and other accepted clinical practices, and peer-reviewed clinical studies is not a device under the 21st Century Cures Act.¹⁰⁶ FDA's 2019 draft guidance engages in genetic exceptionalism by deeming these same public sources of information to be inscrutable if they happen to relate to genomics. Is FDA deeming laboratorians and clinicians to be so confused by genomics that even publicly available data resources like peer-reviewed genomics literature, practice guidelines, and ClinGen are inscrutable to them? If that is what FDA is assuming, then there is certainly a problem, but it would appear to be a medical workforce problem that FDA's device regulations have little power to fix.

FDA's second line of attack, in its 2019 draft guidance, is to assert that tertiary analysis software is a black box because it prioritizes a person's genetic variants for further analysis and interpretation and, in doing so, eliminates some variants from consideration.¹⁰⁷ This, according to FDA, means that such software is a black box, because the health care professional who uses genomic testing reports “cannot verify that the determination to exclude such information was appropriate.”¹⁰⁸ This reasoning is extremely strained. Clinical laboratories that receive insurance reimbursement for genomic testing are HIPAA-covered entities. Bioinformatics service providers that process data for them are their business associates and, consequently, are also HIPAA-covered entities. Thus, patients already have a right, under HIPAA, to request a copy of their full VCF file from HIPAA-covered entities.¹⁰⁹ Therefore, genomic testing is not a black box that hides variants that were not priori-tized for further analysis. These data are available for patients and, if they wish, their doctors to inspect.

A patient could take the VCF file to their health care professional and ask, “Doc, did the software the laboratory uses overlook anything important?” The health care professional might not be able to answer that question, but this would not be because bioinformatics software was used. Rather, it is because virtually all laboratory testing requires laboratories to prioritize some findings for further analysis and reporting, while deeming other findings to be irrelevant. Whether this prioritization is done by human experts or by software, a laboratory's final report to a clinician quite often leaves out some information. At some point, clinicians must trust that CLIA-certified laboratories are doing their jobs competently; clinicians are not in a position to second-guess all of the internal decisions laboratories make during testing. This is true regardless of the bioinformatics software a laboratory uses or does not use.

The fact that tertiary analysis software prioritizes genetic variants for further analysis and interpretation, without reporting all variants to the patient's health care provider, does not make it a black box that qualifies for FDA regulation under the Cures Act. It simply means that clinical laboratories should make sure to receive a copy of the patient's variants from their bioinformatics service provider and take responsibility for ensuring that appropriate variants were considered during the tertiary analysis. Making sure relevant variants are considered is already a responsibility of clinical laboratory directors under CLIA. It is not grounds for FDA to regulate tertiary analysis software as a medical device. If anything, the amount of data clinical laboratories should request back from their bioinformatics service providers and what the laboratories should do with those data after they receive them are CLIA regulatory issues. Framing these questions as FDA regulatory matters seems driven by a perception that FDA is where the street-light is.

To summarize, FDA's 2019 draft guidance exhibits genetic exceptionalism and threatens to place all variant interpretation software used in tertiary analysis under a product liability tort regime. The longstanding view is that variant interpretation is in nature of a diagnostic activity, which is an aspect of clinical care and thus subject to malpractice liability under a negligence (rather than strict liability) standard. Software that helps health care professionals interpret variants is not signal-processing software¹¹⁰ and it is not inevitably a black box. Rather, it is CDS software and should be subject to the same jurisdictional rule Congress enunciated in the 21st Century Cures Act.¹¹¹