Privacy and Security in the Internet-Connected World of Precision Medicine

Precision Medicine

The first step necessary to understand the privacy implications of modern precision medicine is to understand the nature of “precision medicine”—its history and future.¹ Precision medicine, formerly known as personalized medicine, stratified medicine, and P4 medicine (predictive, preventive, personalized, and participatory medicine), describes a process of categorization of medical diagnosis and treatment based on multiple “characteristics” of an individual or small group of people. As used in more modern medicine, “precision medicine” refers to individualized diagnosis or treatment plans based upon individual characteristics of the patient, based on his or her genomics/genetics and other health-related data.

What distinguishes “precision” medicine from its predecessors is the focus on genetics. In order to target specific therapies and treatments, modern researchers and physicians will not only categorize patient disorders based on symptoms and medical histories but also on specific genetic markers. Precision medicine will rely in part on data collection, data analytics, and data science. In order to determine the best treatments with the best outcomes, large numbers of patients will need to be studied, their treatment options analyzed, and their short- and long-term outcomes tracked. Specific and highly sensitive information about these patients—not only their medical histories and treatments, but their specific genetic makeups—have to be inventoried, categorized, and tracked.

The creation, storage, transfer, and analysis of the databases necessary to implement precision medicine into the world of clinical medicine create genuine security, privacy, integrity, and other risks to individuals, medical providers, and society in general. The tools of modern data science—including machine learning, “big data” analytics, artificial intelligence (AI), predictive intelligence, and heuristics—use data to predict outcomes often without researchers or practitioners having any understanding of why the algorithm is preferring one treatment over another. In the future practice of “precision medicine,” treatment decisions often will be predicated on an algorithm that is not well understood. Moreover, to be useful, these databases must be accessible to researchers and providers alike, creating challenges for security and authentication of users.

DNA Databases

Because much of precision medicine will be based on genomics, it will necessarily require the patient to undergo a genetic testing of some kind. Currently this testing does not consist of sequencing the entire DNA of the individual, but rather sequencing small portions of the DNA to look for specific markers. Depending on how these DNA databases are collected and stored, as well as for what purposes the genetic information will be used, they may or may not enjoy legal protection from a privacy and data security standpoint.

As a general rule, medical information—collected by medical providers for the purposes of diagnosis and treatment (as well as payment or administration)—is protected by medical privacy laws such as HIPAA and state or local equivalents.² Thus, DNA samples collected by a doctor or hospital, or a laboratory working with a doctor or hospital, are likely to be subject to relatively strict data privacy or data security requirements.

On the other hand, entities like 23andMe, Ancestry.com, and device manufacturers like Fitbit, Apple, Garmin, and others who provide hardware that measures information that will be used in precision medicine databases are not covered by either the privacy or data security laws. To make matters worse, there are virtually no laws regulating the collection, storage, or (for the most part) use of genetic information. Many private DNA databases are now searchable and linked to other genetic databases that allow those with access to identify individuals who have given DNA samples for ancestry or other reasons. Public genetic genealogy databases also are linked either directly or indirectly with commercial semipublic DNA databases from entities like Ancestry.com and 23andme.com that not only collect and analyze DNA samples voluntarily submitted by their customers, but often contain detailed genealogical information through which genetic genealogy matches can be cross-referenced by name and that permit a DNA sample to be identified to a close or distant relative in the database based on familial DNA or mitochondrial DNA samples. Law enforcement agents may obtain DNA information through DNA “dragnets” of these sites. It is not yet clear whether police may obtain DNA samples or information from medical providers through a simple “third-party” subpoena, or whether a search warrant supported by probable cause would be required,³ but currently there is no prohibition on law enforcement obtaining all of the specimens from a commercial laboratory and using their data points for a criminal DNA⁴ database. To the extent that electronic health records contain DNA information, the DNA sequencing, phenotype, and other data may be available to law enforcement through legal process.

Internet of Things

Like precision medicine, the term “Internet of Things” has become something of a shibboleth in modern society—meaning different things to different people. In general, the Internet of Things, or IoT, refers to devices that connect to the Internet—either directly or indirectly—and collect and share data, typically without direct human intervention. Typically, an IoT device will contain a sensor that senses some parameter or change in parameter, a data collector that accepts inputs from the sensor, an analytics engine that processes or pre-processes the data from the sensor, and a transmitter that transmits the data from the processor to some Internet-connected device. The data can then be transmitted to the Internet, where they can be analyzed, or collated with like data and then analyzed, with conclusion obtained by data analytics, and ITS results transmitted back to the IoT device. It senses, it analyzes, it transmits, and it reacts.

Internet of Medical Things

Because precision medicine requires large amounts of highly personal data, it is a natural complement for the creation and expansion of the “Internet of Medical Things” (IoMT). The IoMT consists of an infrastructure that includes medical devices, implantables, wearables, telematics, and remote diagnosis and treatment; it also can include things like routers, hubs, wireless routers, cell phones, transmitters, repeaters, and any other devices that can sense, transmit, store, process, or analyze data about a person’s health. An electronic thermometer can be part of the IoMT, as can an iPhone or any other mobile phone. While we typically think of things like implantable cardio-defibrillators, pacemakers, insulin pumps, or other traditional medical devices as the IoMT, the term really encompasses an entire ecosystem, which also includes the sensors, the transmitters, the cloud, the data analytics engines, the devices, the actuators, and everything in between.

The Dark Side

One of the biggest problems with applying traditional medical technologies to the Internet in general and the IoT is particular is that these devices—and the data generated by them—were never intended to be on a publicly accessible forum like the Internet. Many IoT sensors—and, by extension, IoMT sensors—are designed to be cheap, low powered, short range, and often disposable. A radio frequency identification (RFID) device of the kind used for inventory control at a department store may cost less than a penny and contain little of the infrastructure necessary for data security, data integrity, and other sophisticated security – and privacy-ready capabilities. Even more expensive devices like insulin pumps, cardio-defibrillators, remote radiology, and other telematics and telemedicine devices are not really designed with privacy protection and security in mind.

Security Basics

In the end, data security (and device integrity) is about letting “good guys” in and keeping “bad guys” out. “Guys” include humans, bots, viruses, worms, malware, and other malicious programs or people. The goal of security is to protect the “CIA”—confidentiality, integrity, and availability—of data and the devices that store, process, and maintain them.

We already have identified one problem with data security and integrity when it comes to the IoMT. It’s not a single device or infrastructure. It is an entire ecosystem.

A remote sensor, worn or implanted in a patient, measures “something” and collects data on what it has measured. What is the supply chain for that device? Where was it manufactured? Where were the components manufactured that make up the device, and under what conditions? Is this “device” a medical “device” subject to FDA or other regulation, or is it essentially unregulated? Was the device intended to collect data for diagnosis or treatment, or is that merely inferred?

Moreover, it is not just about what a device measures—it is about what can be inferred from what a device measures. Inferences could be made to use devices like mobile phones, Fitbits, smartwatches, and other nonmedical devices to predict fever, stroke, or other medical conditions. Simple surveillance cameras might warn of medical conditions based on unusual sweatiness, gait analysis, or other information. For example, researchers at the University of Illinois Urbana-Champaign demonstrated that a simple fitness band in a smartwatch could be used to accurately guess both a participant’s password and what he or she was typing on a keyboard simply by analyzing the data collected by the watch’s accelerometer. In another case, a woman filed a police report indicating that she had been sexually assaulted, and the responding officers found the home in disarray with overturned furniture, a knife, and a bottle of vodka in plain view. Police analyzed data from the victim’s Fitbit activity tracker and found that, at the time she claimed to have been awakened by the attacker, she was actually already awake and active. Thus, even defining what is a “medical device” or part of the IoMT infrastructure is not easy.

The problem for IoMT devices is that they are often relatively inexpensive, low powered, and not designed with security in mind. The kinds of security things we take for granted for computers, computer networks, and even smartphones—such as access control, passwords, multifactor authentication, encryption of data (in situ and in transmission), access logging, endpoint management, intrusion detection and prevention, software and firmware code review, life-cycle management, supply chain management, and other fundamentals for data and network security—are rarely components of an IoMT device. Even those who design implantable pacemakers whose software can be updated remotely rarely consider the security and authentication requirements for the device. Often such security ends up being “bolted on” as an afterthought, rather than “baked in” as part of security by design and privacy by design.

As a result, the U.S. FDA has recognized the need for both before-market and aftermarket data and device “cyber-security hygiene.”⁵ Compliance should be, but not necessarily will be, a priority for future IoMT devices.

Misuse of Data

We assume that IoMT devices will collect the data that they need for the specific purposes needed (e.g., pulse, blood pressure, EKG, etc.). But at their heart, IoMT devices contain sensors and data analytics that can be used for purposes other than for diagnosis or treatment of a specific disease. The volume, nature, and sensitivity of data collected by IoMT devices—and the ecosystem of devices through which these data travel—are much greater and more personal than anything collected by a Fitbit or a smartwatch.

Government Regulation

For IoMT devices, there are two principal U.S. government regulations that apply. First, the Food and Drug Administration may regulate these devices as “medical devices.” If the IoT device is considered a medical device (a big “if”), FDA regulations specify the procedure for obtaining clearance to market and sell the device. This includes both premarket⁶ and postmarket security⁷ requirements.

The first question is whether an IoMT device—or, more accurately, an IoMT ecosystem—is a “medical device” under the Food and Drug Act. A medical device is defined within the Food Drug & Cosmetic Act as an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is: recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.⁸

FDA regulation of devices—including IoMT devices—is dictated by the risk associated with the device.⁹ This risk is measured by potential harm to the patient if the device malfunctions. It is not the risks associated with data leakage, loss of privacy, and, in particular, the massive collection and analysis of the kinds of personal information typically collected by IoMT devices. The FDA premarket guidance on cybersecurity of medical devices recommends that providers identify the risks (including cyber risks), threats, and vulnerabilities of the devices; the likelihood of an exploit of that risk; the impact to the patient of such an exploit; and the best way to mitigate or eliminate the risk.¹⁰

The problem with applying these guidances to most IoMT devices is that the devices are frequently small, low power, inexpensive, and not designed to be medical devices in the first place. Little if any attention is given to the risks associated with the risk of leakage of medical information from these devices or even the risk that the devices will be exploited for other reasons.

Privacy Rules and Gaps

Federal laws and regulations protect the privacy of medical information—at least in theory. HIPAA privacy rules generally prohibit health care providers and other covered entities like insurers and administrators from disclosing certain kinds of protected health information without either the patient’s written authorization or some legal process, but these rules apply only to HIPAA-covered entities and their “business associates” who provide services for them. Covered entities are defined in the HIPAA rules as (1) health plans, (2) health care clearinghouses, and (3) health care providers who electronically transmit any health information in connection with transactions for which HHS has adopted standards.

It is not clear whether IoMT device manufacturers, and software as a service (Saas) providers who are collecting health-related information on their own behalf (and not as business associates of covered entities), are covered by the HIPAA privacy and data security rules. Thus, many things we might think of as medical devices may not be covered by the HIPAA privacy rules because they are not provided through covered entities. Thus, the commercial use of data generated from these devices is subject to simple “fairness” rules under the Federal Trade Commission rules that prohibit unfair or deceptive trade practices in connection with data collection and use, rather than the more stringent and comprehensive rules for health information.

Moreover, under both HIPAA privacy and other privacy regimes, the data streams generated by these IoMT devices are subject to search, seizure, and government analysis with either a court order or other administrative process. Individual’s DNA, dental records, body fluid or tissue typing, samples, or analysis cannot be disclosed under this provision but may be disclosed in response to a court order, warrant, or written administrative request.

Data collected by IoMT devices may not be covered by HIPAA privacy rules while on the devices themselves, in transmission, or while on the “cloud.” If a consumer is using such a device on his or her own without the intercession of a “covered entity,” the data stream is not covered by HIPAA. If the consumer/patient transmits the data directly to a provider, insurer, or other covered entity, then the data stream may be covered by HIPAA’s privacy and data security rules. But in the IoMT environment, the data stream may be a hybrid. EKG records may be collected and stored and analyzed by computer code or software provided by the device manufacturer—with no covered entity involved at all. A consumer/patient may collect and store (or have data collected and stored on the cloud) certain IoMT data, and then may voluntarily provide that information to a doctor, clinic, or other covered entity. Just as the IoMT ecosystem has to be evaluated as a whole, the addition of covered entities to the mix must be examined based on risk and regulatory compliance.

Hacking Prevention

The FDA guidance on cybersecurity for medical devices presupposes that someone will identify the devices as a medical device and apply the guidelines. To be effective for the use in precision medicine, the devices and the data they collect need to be accessible for data analytics. While the analytics can be performed on anonymized or de-identified data, ultimately for the treatment to be “personal,” the data must be linked to a specific person. For example, if a patient were exhibiting a certain set of symptoms and we wanted to make a recommendation for treatment (whether we diagnosed a specific disease or not), we could upload the patient’s DNA, symptoms, health care records, IoT, and other biometric data to some significantly large and diverse database, which would use an algorithm to come up with a diagnosis and treatment plan based on the data provided. This would require large databases of medical information, accessible by virtually every provider—a security and privacy nightmare.

Conclusion

The collection, storage, transmission, and use of a wide variety of data from DNA are largely unregulated, or, worse, regulated by a patchwork quilt of overlapping laws and regulations that leave patients and providers scratching their respective heads in an attempt to comply. Medical information created by Internet of Things devices can be misused to create detailed profiles of individuals, and actuators attached to IoT devices can be accessed and triggered—leading to potentially disastrous results. As much as DNA and IoMT will be in our future health care world, the law and technology will have to keep pace. 

Endnotes

1. Erman Ayday et al., Protecting and Evaluating Genomic Privacy in Medical Tests and Personalized Medicine, Proceedings of the 12th ACM Workshop on Privacy in the Elec. Soc’y 95 (Nov. 2013).

2. See, for example, State Medical Records Laws, FindLaw, https://statelaws.findlaw.com/health-care-laws/medical-records.html, for a compendium of state medical privacy laws in the United States.

3. In Carpenter v. United States, Dkt. No. 16-402, 138 S. Ct. 2206 (June 22, 2018), the Supreme Court limited the so-called third-party doctrine and required law enforcement to obtain a search warrant to search the telephone company’s geolocation data about specific individuals, holding that these individuals had a reasonable expectation of privacy in records held by a third party—in that case, the telephone company. Applying this rationale, it is possible that the Court would require police to have a search warrant or other court order to obtain either specific or general DNA samples from medical providers or from ancestry sites.

4. The federal law that deals with the collection and use of genetic information is GINA (the Genetic Information Nondiscrimination Act of 2008, Pub. L. No. 110-233, 122 Stat. 881 (enacted May 21, 2008)). GINA is essentially an antidiscrimination law that prevents group health and Medicare supplemental plans—but not life, disability, or long-term care plans—from using genetic information to discriminate against individuals when it comes to insurance and restricts the use of genetic information in employment decisions, such as hiring, firing, and promoting by employers with more than fifteen employees.

5. Food & Drug Admin., Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff (Oct. 2, 2014), [hereinafter FDA Premarket Submissions] https://www.fda.gov/downloads/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm356190.pdf; Food & Drug Admin., Postmarket Management of Cybersecurity in Medical Devices: Guidance for Industry and Food and Drug Administration Staff (Dec. 28, 2016), [hereinafter FDA Postmarket Management] https://www.fda.gov/downloads/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/UCM482022.pdf.

6. FDA Premarket Submissions, supra note 5.

7. FDA Postmarket Management, supra note 5.

8. 21 U.S.C. § 321(h).

9. Based upon the level of sophistication and potential harm to a patient, the FDA classified devices in three “classes” I, II, and III, with increasing levels of premarket testing and approvals for marketing and use. The FDA also considers “accessories”—which are intended to support the device—as requiring the same level of testing and approval as the underlying device itself. Simple things like cotton balls, tongue depressors, adhesive bandages, and the like would be considered Class I and would require no premarket approval and would be subject to general quality controls based on risk. Intermediate devices would require certain “special controls,” which might include things like labeling requirements, certification of compliance with performance standards, premarket (presales) notification to the FDA, and clearance to market under what is called the 510(k) clearance process. For Class III devices, the kinds of things that support or sustain human life, the review and clearance processes and the certification procedures are even more stringent.

10. See, e.g., 21 C.F.R. § 820.30(g).