3 - Are Electronic Health Records Medical Devices?

Summary

Are Electronic Health Records Medical Devices? While statute (largely) excludes EHRs from the medical device category, commentators have struggled to offer a justification. They have argued that EHRs inform but do not replace clinical decision-making, do not directly interact with patients, and are constantly being upgraded and modified. But all these characteristics are often true of many medical devices. I argue the key aspect of EHRs that render them foreign to the FDA’s jurisdiction is their systemwide interconnectedness. The patient’s EHR affects others. EHRs must work in a certain way, for the integrity of the whole system. EHR data is used for both clinical and quality management research. Alternatively, the safety of EHRs involves greater systematic, upstream regulation – of third-party networks, data formats, and other issues that present collective action problems. This goes far beyond the mandate of the FDA that fails to consider such issues and lacks jurisdiction over many necessary third parties. I argue that the distinction between EHR functions that have a direct and primary effect on the particular patient versus those such as data format and interoperability that present these third-party and systematic considerations should determine the respective jurisdictions of the FDA and health data subagencies.

Are Electronic Health Records (EHRs) medical devices? Answering this question is important. It will determine, in part, which agency will regulate EHRs, and under what paradigms. Either the Food and Drug Administration (FDA) will regulate EHRs as medical devices, or the Office of the National Coordinator of Health Information Technology (ONC), another subagency within HHS that focuses on health data regulation, will provide the framework. This chapter argues that the task should be divided between the two agencies in a way that reflects their respective expertise to produce an optimum outcome. The criterion should be the extent to which the particular function being regulated involves networking with other systems and users. To the degree that it does, the ONC should hold primacy. But for more patient-facing functions that do not involve networking, the FDA should run point. Thus, the ONC should control data-format standardization in EHRs; the FDA might lead clinical decision support (CDS) efforts.

At the outset, some may argue that the question I raise is moot, and my solution is impossible. Section 520(o)(1)(C) of the Food Drug and Cosmetic Act (FDCA), inserted by the 21st Century Cures Act of 2016 (Cures Act), seems to shift the balance of power toward the ONC. It provides that EHRs are not medical devices if they were “created, stored, transferred, or reviewed by health care professionals,” “are part of health information technology that is certified” by the ONC, and “such function is not intended to interpret or analyze patient records.”¹ But at the same time, the HHS Secretary has the authority to undo the exclusion, admittedly subject to notice and comment rulemaking, and a finding that a particular “software function would be reasonably likely to have serious adverse health consequences.”² If the exclusion of EHRs from FDA jurisdiction does not make sense, then, the Secretary could likely take steps to undo or modify the statutory mandate.

The question then is, should they? And the statute provides no answer to that question. On one hand, the statute does exclude EHRs as medical devices. But at the same time, by negative implication, Section 520(o)(1)(C) suggests that but for its exclusion, EHRs would be medical devices – after all, why bother to say a product was not a device, if that product would not have, anyway, been covered in the definition of device?³ While the statute quite clearly excludes EHRs as medical devices, neither the statute, nor the legislative history, is clear on the reasons for doing so. Thus, there is little guidance in the statute as to how the Secretary can and should exercise discretion.

I argue that the key aspect of EHRs that render them foreign to the FDA’s jurisdiction is their systemwide interconnectedness; they affect and are affected, both directly and indirectly, by third parties. First, a patient’s EHR affects others. The EHRs must work in a certain way, not just for the safety of the patient, but for the integrity of the system as a whole. The data from EHRs is used for both clinical and quality management research, for example. On the other hand, the safety of EHRs involves greater systematic, upstream regulation – of third-party networks, data formats, and other issues that present collective action problems. This goes far beyond the mandate of the FDA that fails to consider such issues and lacks jurisdiction over many necessary third parties.⁴

While I therefore endorse some aspects of the FDA’s historic reasoning with respect to EHRs, which I describe below, I argue that it should be allowed to regulate only those functions that have a direct and primary effect on the particular patient – such as the quality of a particular algorithm that renders CDS. However, it should not be allowed to regulate aspects of EHRs such as data format and interoperability that present these third-party and systematic considerations.

3.1 Existing Reasons Against Regulating EHRs and their Shortcomings

The Food, Drug, and Cosmetic Act of 1938 was amended in 1976 to include medical devices within the FDA’s ambit. A device is:

[A]n instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including any component, part, or accessory, which is … intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease.⁵

Devices are categorized as Class I through III, depending on the extent to which they support or sustain human life, or present a risk of injury. Class I devices do not support or sustain human life and do not unreasonably risk injury; Class II devices are somewhere in the middle, as they support or sustain human life and present a higher risk; Class III devices present a high risk of injury.⁶ FDA controls are commensurate with device risk. Class I devices are subject to “general controls” – for example, prohibitions on misbranding. Class II devices are subject to some additional, discretionary controls. Class III devices require premarket approval from the Secretary, though there are methods for obtaining exemptions.⁷

Turning next to EHRs, these consist of software that offers various kinds of functionality, including data entry, storage, retrieval, transmission, and CDS, among others.⁸ In the late 1980s and early 1990s, EHRs began to take on their modern form, offering functions such as computerized order entry, CDS, and medical device interfaces – even though the early computer systems were slow, had low storage capacity, and paper was omnipresent.⁹

On my account, the FDA regulates EHRs in whole or in part when it takes on regulation of these functions, including when these functions appear in an EHR context. Thus, if the FDA declares authority over CDS regulation, it engages in regulation of EHRs to some degree because of the ubiquity of CDS in EHR contexts. Starting in the late 1980s, as EHRs took on their modern form, the FDA offered various reasons both for and against regulating EHRs and EHR-type products.

On one hand, the reasons for regulating EHRs seem obvious – it falls within the medical device definition. It seems that EHRs constitute an “apparatus” or “contrivance” that is “intended for use” in the process of disease diagnosis, as well as in “the cure, mitigation, treatment, or prevention of disease.” Thus, when data from bloodwork is fed into an EHR, and a medical professional looks at the EHR to make a diagnosis, and also looks at the EHR to determine what other medication a patient is taking, so that they can determine what should be prescribed, the EHR plays a role in both the process of diagnosis and treatment. Prominent data regulation scholars, Sharona Hoffman and Andy Podgurski, similarly conclude: “Given that they feature decision support, order entry, and other care delivery and management functions, one might reasonably conclude that EHR systems are as essential to patient care as are many regulated devices. Furthermore, their software can be more complicated than that found in many computer-controlled medical devices that are subject to FDA jurisdiction.”¹⁰

This understanding appears to have undergirded the thinking of at least one senior FDA official, who, a decade ago, suggested that EHRs should be regulated as medical devices. As he explained, Health Information Technology – in this case, it would appear from context, specifically EHRs, are vulnerable to various errors that affect patient safety. These include “(1) errors of commission, such as accessing the wrong patient’s record … (2) errors of omission or transmission, such as the loss or corruption of vital patient data (3) errors in data analysis, including medication dosing errors of several orders of magnitude and (4) incompatibility between multi-vendor software applications and systems, which can lead to any of the above.”¹¹ Two years later, a dissenting view in an Institute of Medicine Report advanced similar reasons for regulating EHRs as medical devices.¹² EHR “components participate directly in diagnosis, cure, mitigation, treatment, and prevention of specified individual human beings” squarely falling within the definition of medical devices.¹³ Indeed, for reasons I will not engage here, the dissent argued that EHRs should be regulated as Class III devices.

On the other hand, over the years, regulators have offered various reasons against regulating EHRs as devices, though none seem to overcome the squarely textual reasoning above. First, the FDA has noted EHR outputs are subject to independent clinical judgment. Physicians can use their independent experience and knowledge to evaluate the EHR output and make their own decisions concerning patients.¹⁴ Second, “health IT is constantly being upgraded and modified to reflect new evidence and clinical interventions, changing work flows, and new requirements … Constantly evolving systems … don’t lend themselves to discontinuous oversight mechanisms such as those used for medical devices.”¹⁵ Third, the FDA lacks “capacity” to regulate;¹⁶ and fourth, that “regulation of health IT [including EHRs] by FDA as a Class III device could have” an impact “on innovation.”¹⁷

But there are problems with these rationales. The independent review rationale also founders because professionals are just as reliant on EHRs as they are on many other devices (and relatedly, unable to carry out fully independent reviews). Indeed, depending on the error, a professional may be more likely to see if an x-ray machine malfunctioned – because the image is fuzzy, perhaps – than if an EHR contains wrong data. Similarly, as Hoffman and Podgurski note, “in the midst of surgery or in the intensive care unit” it would be hard for a provider to reflect on the data that the EHR has provided.¹⁸ Further, the concept of “intervention” is hard to suss out. Does “intervention” require the practitioner to follow the EHR’s output or recommendation only if it accords with their assessment, but ignore it otherwise? If so, the value-add of the EHR is unclear – if the practitioner is going to stick to their judgment no matter what.

Similarly, the other rationales also fail. On the second objection, medical devices generally are subject to various kinds of upgrades and “constant[] evol[ution]”; the FDA has offered a preliminary discussion regarding upgrading different kinds of software, with different tracks for “locked” versus continuously evolving algorithms.¹⁹ As for the third, FDA funding and support can be increased. And the fourth concern goes to the kind of regulation that would be appropriate for EHRs as medical devices – it does not speak to whether EHRs are devices, and whether the FDA should have control.

Thus, while it is clear that many stakeholders have concerns with giving the FDA full control over EHR regulation, they have not provided strong rationales.

3.2 Additional Rationale: Networked versus NonNetworked Aspects of EHR Use

In this section, I argue that fundamental aspects of EHRs – namely, their systemwide interconnectedness – render at least some important EHR functionalities foreign to FDA expertise. Thus, I argue that the FDA should refrain from regulation on aspects of EHRs that directly implicate data networks. That regulation should remain in the hands of the ONC, which has relationships with data networks and EHR developers.²⁰ However, FDA regulation may be appropriate where the subject of regulation is the point at which the EHR interacts directly with patient care.

In other work, I have explained that EHR use occurs at two levels: at the individual level, and a population-based level.²¹ At the individual level, a medical professional uses EHR for the care of a specific patient. They look up a patient’s medical history, past medical conditions, treatments and the like. They can use the data to treat the patient, ensuring that there are no adverse drug interactions.

At a systemwide level, many EHRs are connected in ways that allow the data they contact to be pulled together and analyzed to draw conclusions on the safety and effectiveness of treatments and procedures, among other purposes, across vast populations. For this purpose, troves of data are cleaned, collated, and analyzed. The goal of a so-called learning health system would be to pull together data – much, if not most of it, in the form of EHRs – in real-time to figure out what interventions work best based on current knowledge, to reenter data back into the system, which in turn, is then used to refine the outcome for future interventions on other patients in an iterative feedback loop.²² While not all EHRs can carry out these functions, many of them do so, and the goal is to have full interconnectivity.

Further, it is not just the uses of EHRs that invite population and systemwide considerations. Pulling together EHRs involves other population- and system-level considerations. For example, the data formats and elements that one EHR uses have ramifications for how other, unrelated EHR systems work – if they do not use the same formats and elements, the overall system cannot function properly.²³ Thus, as one regulatory entity put it: “[i]ndividual health IT components may meet their stated performance requirements, yet the system as a whole may yield unsafe outcomes.”²⁴

These questions of population-level data and interconnected networks should determine the bounds of FDA jurisdiction. The operation of EHRs in a certain instance, then, is fundamentally interconnected to a broader system. When a doctor deploys an EHR in a particular context, their action draws on data, data formats, users (who may have input the data years ago), and networks. More than that, their engagement with the EHR can have implications for patient care – not just that of their patient, but, if the EHR is agglomerated and used elsewhere, on that of other patients.

This is the key difference between most devices and EHRs. As long as other devices are integrated into the relevant medical system of which they are a part, they fulfil their primary function. Safety considerations therefore focus on the particular context in which the device is used – while there may be downstream effects, they are less important. The purpose of EHRs however, is to record, transmit, aggregate, and use information downstream. At a fundamental level EHRs must engage with other systems and subsequent patients – or the same patient in subsequent visits.

Because of this interconnected nature, unlike with other devices, where the safety of a particular MRI is not (within reason) dependent upon which supplier the provider obtained it from, it is harder to tease EHR and their data away from how it was delivered and sourced, and how it may play with other systems. In regulating EHRs, the FDA would not have to just consider the particular EHR system at hand. It would have to consider how the EHR system works with other EHR systems and formats, and other users. It would have to consider downstream uses of the data thus input, as it may be used for future analyses.

Limiting the FDA’s ability to engage with the third party and indirect effects of EHRs fits in with the broader approach it currently takes. In previous work, I have argued that the FDA generally lacks expertise and has limited authority to regulate inter alia indirect drug effects and drug effects on third parties. As I explain, an indirect cause is one which is “separated from an effect by an intervening cause. This intervening cause must 1) be independent of the original act, 2) be a voluntary human act or an abnormal natural event, and 3) occur in time between the original act and the effect.”²⁵ Thus, the use of birth control may lead (some claim) to higher incidents of STDs, since individuals may have condomless sex. But such condomless sex is a voluntary, intervening act. Similarly, “[t]hird-party harm occurs when the drug is prescribed for use, and actually used by person A, but person B is harmed by the use either directly or indirectly.”²⁶ Such harm includes, for example, secondhand smoke directly inhaled by third parties who do not use cigarettes. Some harms are both indirect and third party, such as downstream partners who may contract an STD caused by condomless sex that some claim occurs due to the availability of birth control.²⁷ I explain that while the FDA should sometimes regulate indirect and third-party harm, its expertise and authority are at its nadir when it does so, and its intervention should be limited. That is the situation in which EHRs reside.

Without considering its implications for regulatory control, two regulatory entities have recognized that EHRs raise questions of indirect and third-party harms. They are part of “a complex sociotechnical system.”²⁸ Yet, they do not distinguish the networked and nonnetworked aspects of EHRs. Rather, they focus on the interaction of users with EHRs, and the error that results. As they emphasize, the interactive nature of EHRs, organizational workflow, and user understanding, determine safety.²⁹ Scholars, such as Sara Gerke and coauthors, writing in the context of artificial intelligence (AI), have similarly argued that AI in health implicates a “system” view, by which they mean the intersection of humans, and organizational workflow, with technology.³⁰

But in the EHR context,³¹ the distinguishing factor is not user-technology interaction. After all, other devices raise concerns regarding user-technology interactions, and the errors that result, and the FDA has, to some degree at least, sought to regulate such concerns by reviewing labeling, and the like.³² There are limits – for example, the FDA cannot “regulate the practice of medicine.”³³ But the user-error concerns here arise with respect to all medical devices. They are not unique to EHRs (or, for that matter, to medical software more generally). Rather, the relevant boundary is between networked and nonnetworked EHR functions.

Separating EHR use into two aspects allows us to determine the bounds of FDA jurisdiction. On one hand, it may make sense for the FDA to regulate certain aspects of the EHR as they pertain to a specific patient – subject to the limits on regulating the practice of medicine. But when networked aspects of the EHR are involved, the FDA should step back. In that situation, the ONC, which has developed relationships with EHR developers, national data networks, and indeed, has created a process to create a voluntary national health data network, should step in and regulate. How might this play out? Let us consider a taxonomy developed by various HHS agencies and see how the approach works.

3.3 Applying the Framework

The Food and Drug Administration Safety and Innovation Act (FDASIA) required the FDA, ONC, and the Federal Communications Commission (FCC) to develop “a report that contains a proposed strategy and recommendations on an appropriate, risk-based regulatory framework pertaining to health information technology, including mobile medical applications, that promotes innovation, protects patient safety, and avoids regulatory duplication.”³⁴

The report separated Health IT into three sets of functions:

1) administrative health IT functions [namely ‘billing and claims processing, practice and inventory management, and scheduling’], 2) health management health IT functions [namely ‘health information and data exchange, data capture and encounter documentation, electronic access to clinical results, most clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching’], and 3) medical device health IT functions [namely ‘computer aided detection software, remote display or notification of real-time alarms from bedside monitors, and robotic surgical planning and control’].³⁵

The report suggested that only category 3) functions were subject to FDA regulation. That seems correct, but not for the reasons in the Report.

First, administrative functions – “billing and claims processing, practice and inventory management, and scheduling” – are not patient facing, and can be separated on that ground.

Next, health management health IT functions include “health information and data exchange, data capture and encounter documentation, electronic access to clinical results, most clinical decision support, medication management, electronic communication and coordination, provider order entry, knowledge management, and patient identification and matching.”³⁶ The Report concluded that it did not have to regulate these functions because they presented a lower risk.³⁷ In so concluding, it cited little evidence. The better reason is that these functions all have to do with EHR integration with other systems and its interaction with multiple users. They all have to do with EHR as a networked product – networked with both technology and system users. The FDA, which rarely regulates at a systemwide level, focused primarily on the interaction between device and patient, is ill-suited for such regulation. Rather, the ONC, which has developed relationships with multiple players in the health data world, should take the lead role.³⁸

Finally, medical device health IT functions include “computer aided detection software, remote display or notification of real-time alarms from bedside monitors, and robotic surgical planning and control.”³⁹ The Report suggested that these functions are higher risk, and therefore fall within the FDA’s purview. On my account, these functions are more focused on HIT functionality as it pertains to specific patients, rather than networking aspects. It therefore falls more within FDA expertise.

Similar issues arise in the context of CDS regulation. Cures Act Section 520(o)(1)(C) excludes software that is meant to display medical information about a patient and the like, as long as the “health care professional [can] independently review the basis for such recommendations that such software presents so that it is not the intent that such health care professional rely primarily on any of such recommendations to make a clinical diagnosis or treatment decision regarding an individual patient.”⁴⁰ In guidance, the FDA explained that whether a professional exercised such judgment depended on “[t]he purpose or intended use of the software function; The intended user (e.g., ultrasound technicians, vascular surgeons); The inputs used to generate the recommendation (e.g., patient age and gender); and [t]he rationale or support for the recommendation. In order for the software function to be excluded from the definition of device, the intended user should be able to reach the same recommendation on his or her own without relying primarily on the software function.”⁴¹

Commenters responded with confusion.⁴² As Professor Efthimios Parasidis noted,

“The FDA’s statement does not represent a reasonable interpretation of the statute, because it focuses on the physician’s ability to come up with a treatment decision independent of the CDS program, rather than focusing on the ability of the physician to independently review ‘the basis of such recommendation that such software presents.’ It is one thing to be able to diagnose a patient independent of a CDS program, and another to understand and independently review the output of a CDS program. The statute covers the latter, while the FDA’s draft guidance appears to cover the former.”⁴³

In 2019, the FDA doubled down on this approach, however.⁴⁴

On my account, CDS should fall within the FDA’s purview to the extent it involves the quality of an algorithm and the outputs it produces. The ONC has little expertise on issues of algorithmic quality, while the FDA encounters such issues in its regulation of other devices apart from EHR.⁴⁵ However, CDS relies on the data collected from a range of different EHRs. To the extent that a CDS problem arises with data quality, transmission, or input from EHRs – that is, issues relating to the quality of networking across the national health information network – it falls under the ONC’s authority. The HHS Secretary should use their authority to recalibrate the relevant authority between the two agencies in this way.

3.4 Conclusion

I have argued that the delineation of authority between the FDA and the ONC should not be based on the extent of provider intervention or control over HIT, which involves conceptually hard distinctions. It should not be based on how risky a piece of HIT is as such outcomes are highly context-dependent and still empirically hard to ascertain. Rather, they should be based on whether the aspect of the HIT subject to regulation involves its ability to network with other systems and users. To the degree that it does, the HIT should fall within ONC regulation. However, as long as the focus of the HIT function does not implicate networking – such as the quality of algorithmic analysis – FDA jurisdiction is appropriate. The line between the categories can be blurry – after all, the analysis of algorithmic quality might implicate questions of data collection and standardization. But if history is any guide, such blurriness will inevitably be the case, no matter what standard is adopted, as we move to more and more automated health systems.