Scope of the Privacy Rule’s Individual Data Access Right

Section 164.524 of the Privacy Rule grants people a right to inspect and receive copies of data identifiable to themselves if the data are maintained by a HIPAA-covered entity, such as a clinic, hospital, clinical laboratory, and some but not all research laboratories. The “designated record set” (DRS) refers to the data to which an individual has access under HIPAA.¹⁸ The DRS includes much of the data stored in a covered entity’s files that can be traced to the requesting individual.¹⁹ It includes all records “[u]sed, in whole or in part … to make decisions about individuals.”²⁰ HHS has emphasized that this includes data used in non-medical as well as medical decision-making, and the DRS includes data the covered entity uses to make decisions about any individuals, even if the data were not so used when making decisions about the person requesting the data.^{Reference Evans21} For example, if a hospital ever uses blood pressure data to make decisions about any of its patients, you could access your own blood pressure data stored in your medical records, even if blood pressure was not relevant to any decisions the hospital made in the course of treating you.

A person’s DRS is not limited to clinically significant information and might include, for example, speculative notes included in a patient’s chart or individual research results stored in a person’s files at a HIPAA-covered institution.²² Any information that is ascribed to a person carries potential privacy concerns and might lead to discrimination or stigmatization. Low-quality data can be as stigmatizing as high-quality data, and sometimes even more so. Accordingly, the DRS for laboratory data “includes not only the laboratory test reports but also the underlying information generated as part of the test, as well as other information concerning tests a laboratory runs on an individual.”²³ HHS has clarified that the DRS for genomic testing includes “the completed test report, the full gene variant information generated by the test, as well as any other information in the designated record set concerning the test.”²⁴

HIPAA’s access right is subject only to a few exceptions and they are narrow.²⁵ For example, the Privacy Rule lets HIPAA-covered research institutions suspend research participants’ access rights temporarily during a clinical trial.²⁶ However, this exception allows research data to be withheld only if the individual consented to the access denial when consenting to the research,²⁷ and access must resume as soon as the trial is complete.²⁸ The existence of this exception confirms HIPAA’s general rule, which is that research data raise privacy concerns, and people need access in order to understand and manage their privacy risks and to grant truly informed consents for secondary uses of the data. Moreover, HIPAA’s access right is an important lever people can use to free their data for use in other research projects.

Individual Access Rights in Non-HIPAA Mobile Health Research Environments

This article adopts Wiggins’ and Wilbanks’ definition of citizen science as “a range of participatory models for involving non-professionals as collaborators in scientific research.”^{Reference Wiggins and Wilbanks29} This concept is broad and encompasses the upper three of four tiers of participation that Bobe et al. recently described,^{Reference Bobe, Meyer and Church30} drawing on Arnstein’s “ladder of participation.”^{Reference Arnstein31} The traditional 20th-century research model for which regulations like the Common Rule were originally conceived presumed the lowest level of participation, rife with informational and power asymmetries, in which research was done to you. ^{Reference Hurley32} Citizen science, as described by Wiggins and Wilbanks, embraces three higher levels of participation, in which research is done for you (as when a patient advocacy or family group commissions professional researchers to study a particular question or assembles data and tissue specimens to aid such research), or with you (as when a scientist or research app developer engages research participants as active partners in research), or even by you (as in a do-it-yourself project, where the participants are the researchers).³³ Rothstein et al. explain why such research often escapes regulation under the Common Rule, the FDA’s research regulations, and the HIPAA Privacy Rule.³⁴

Outside the HIPAA-regulated environment, individuals’ access to their personal health data grows dicey. Unless users happen to enjoy state-law protections that include access rights, the users must rely primarily on the law of contract: privacy policies stated in companies’ end-user agreements and terms of use that many users click through without reading.

Scott Peppet surveyed the privacy policies of twenty popular consumer sensor devices and found only four that addressed data ownership.^{Reference Peppet35} Three of those four asserted that the sensor manufacturer/app developer (hereinafter, “mobile health company”), rather than the user, owns data that the sensor generates, with some asserting that the company has “sole and exclusive” ownership. Such assertions are legally questionable, but it is fair to say that mobile health companies that gather and store people’s data enjoy a level of control that is tantamount to ownership. The information they store is “out of circulation even though it is not, strictly speaking, owned”^{Reference Hall36} and many mobile health companies and app developers treat personal data “as if it were their private property.”^{Reference Rodwin37}

Professor Peppet notes the potential for “sensor fusion,” in which “information from two disconnected sensing devices can, when combined, create greater information than that of either device in isolation.”³⁸ For example, fitness tracker data on heart rate and respiration — each innocuous and hardly stigmatizing in itself — can, when combined, allow inferences about substance abuse.³⁹ Linking sensor data that reflect lifestyle, exposures, and environment to traditional health and genomic data, as some mobile research apps seek to do, could compound these privacy concerns.

To appreciate their privacy risks, users need access to the data that mobile health companies, including research app developers, gather and store. People also need to understand how their data might be shared with third parties. As for individual access, Professor Peppet’s survey found that policies announced in end-user agreements and terms of service were inconsistent concerning individual access to, and exportation of, one’s own raw sensor data.⁴⁰ In contrast to the HIPAA-regulated space, users have limited individual access rights that, all too often, are badly described. For example, some companies’ policies allow user access to personally identifying information (PII) but not to non-PII,⁴¹ while failing to define either of these terms. Does PII only include the user’s name and other overt identifiers, or is sensor data considered PI if it is re-identifiable?⁴²

As in the HIPAA-regulated space, re-identification of mobile health data is a growing concern. Professor Peppet cites an intelligence source for the proposition that if a fitness tracker reveals the gait at which a person walks, unique individual identification may be feasible.⁴³ Failure to define PII leaves the scope of a user’s access rights indefinite. Professor Peppet cites Debjanee Barua et al. for the proposition that users want to be able to obtain copies of their data: “This is the simplest level of control over one’s data—the ability to inspect, manipulate, and store your own information. But it’s not usually possible.”^{Reference Barua, Berkovsky and Freyne44}

Mobile health companies often reserve the right to share or sell people’s non-personal information (non-PII) more broadly than their PII, but these same uncertainties leave users guessing which types of personal data might be shared with third-party researchers.⁴⁵ Absent a clear policy to the contrary and absent relevant state privacy protections, users should assume that a company’s promise not to share PII amounts to a promise to strip consumers’ data of overt identifiers before it is shared.

In principle, these problems have a straightforward solution. Where the law of contract governs, problems can be resolved by agreement of the parties without recourse to ponderous legislative and regulatory solutions. As a group, people who use mobile health devices — and, in particular, those who participate in citizen science projects — are an educated, empowered lot.⁴⁶ Mobile health companies face strong incentives to be responsive to their users. If users demand HIPAA-equivalent individual access rights and boycott mobile health companies that do not grant them, the problem seemingly can be solved. Unfortunately, this approach raises potential FDA compliance issues for developers of research apps that harness data from mobile health devices.

FDA Oversight of Software Used in Mobile Health Research

This section explores the impact of the FDA’s medical device and research regulations on a software developer that creates a research software platform to gather and study data from participants’ mobile health devices. Let us assume the mobile health devices are of a sort — for example, fitness trackers — that qualify as general wellness devices that the FDA does not regulate as medical devices. In 2013 and 2015 guidance documents, the FDA indicated it would regulate such products only if they performed medical device functions that might pose a safety risk if the mobile product failed to function as intended.⁴⁷ The 21st Century Cures Act of 2016⁴⁸ confirmed that the FDA lacks authority to regulate software for encouraging wellness or a healthy lifestyle, unless the software crosses the line into “diagnosis, cure, mitigation, prevention, or treatment of a disease or condition.”⁴⁹ In September 2019, the FDA issued final guidance clarifying the line between regulated and non-regulated wellness software after 21st Century Cures.⁵⁰

This discussion assumes the mobile health company that supplies the fitness tracker has positioned its product as a low-risk general wellness device by adhering to the FDA’s guidance regarding appropriate claims for such devices. For example, the mobile health company markets its product as a fitness tracker for use by healthy people to log their maximum heart rate and aerobic fitness while exercising. With these claims, the fitness tracker is exempt from FDA oversight.

The research app developer creates a new software platform that gathers data from people’s fitness trackers and conducts research using those data. The study participants are people who own the fitness tracker and agree to download their data into the research software, which mines the data to discover new associations between people’s daily heart rate history and various medical conditions. For example, the research software might search for patterns of heart activity that diagnose or predict various health events, such as asthma attacks or strokes.

The question is whether the FDA can regulate the research software platform as a medical device, or at least regulate the human-subject research that relies on the platform. In recent years, the FDA has asserted authority to regulate “software as a medical device” (SaMD), which is “software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.”⁵¹ Such software “utilizes an algorithm (logic, set of rules, or model) that operates on data input (digitized content) to produce an output for a medical use specified by the manufacturer.”⁵²

There are two ways to characterize the research app developer’s activities, and both carry a risk that the software developer might fall under the FDA’s medical device regulations unless the developer proceeds very carefully. The first characterization is that the research app developer is repurposing fitness trackers that are lawfully marketed as general wellness devices, altering their intended use and thereby transforming them into a new medical device capable of diagnosing or predicting health conditions such as asthma attacks and strokes. The FDA’s intended use regulation at 21 C.F.R. § 801.4 states that a party who alters the intended use of an existing device is responsible for demonstrating that the device is safe and effective in the new intended use. “If, for example, a packer, distributor, or seller [or software developer] intends an article [in this case, the fitness tracker] for different uses than those intended by the person [that manufactured the fitness tracker], such packer, distributor, or seller [or software developer] is required to supply adequate labeling in accordance with the new intended uses.”⁵³ To supply adequate labeling, it would be necessary to prove to the FDA that the fitness tracker is safe and effective in the new intended use — in other words, to seek a clearance or premarket approval for that use. Note that the research app developer, rather than the mobile health company that makes the fitness tracker, is the party on the hook to prove that the fitness tracker is safe and effective, when used together with the new software, to diagnose and predict asthma attacks and strokes. To the extent this has not yet been proved, the suggested new use is experimental and potentially might be subject to the FDA’s research regulations, as discussed further below.

The second characterization is that the research software platform is SaMD, offered as a separate accessory to people’s fitness trackers. A device accessory is potentially subject to regulation as a device in its own right. The definition of medical devices that the FDA can regulate includes “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, in man or other animals….”⁵⁴ If the research app developer intends for its software to be used to diagnose or predict asthma attacks and strokes, then the research software is a medical device that the FDA can regulate. Once again, if the research software has not yet been shown safe and effective for that use, then it is an experimental device, and the FDA potentially can regulate human-subject research that uses the software.

How can the research app developer avoid these outcomes? The FDA’s research regulations are described in a companion article in this same issue,⁵⁵ and readers are referred there for background. The key points here are that much depends on the app developer’s intent and on the risks posed by the citizen-science study. Does the software developer intend to submit data from the citizen-science study to the FDA to support clearance or premarket approval of the software for future use as a diagnostic or predictive product? If so, compliance with the FDA’s research regulations is required.

Even if the answer to that first question is “no,” does the software developer intend for the research software to be used “in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease,”⁵⁶ or does the developer instead merely intend to use the software to conduct basic scientific “investigations to expand medical knowledge or conduct medical research”?⁵⁷ The FDA’s investigational device exemption (IDE) regulations⁵⁸ generally do not apply to basic scientific research that uses an experimental device, unless the research incorporates a device study — that is, a study that aims to prove the experimental device is safe and effective.⁵⁹ Finally, does the research that uses the fitness tracker together with the new software pose significant risk to the research participants? If so, the FDA can nevertheless require an IDE.

How the FDA answers these questions could depend on whether research participants will have access to individualized data and results generated by the research software platform. Sharing individual research findings — such as a finding that a participant’s heart rate data, as analyzed by the research software, seem to indicate an elevated risk of a stroke — might cause the FDA to infer that the software developer does intend diagnostic uses of the research software. Moreover, sharing such information with participants might place them at significant risk if the inferences drawn by the research software turn out to be wrong.

Individual data access policies are one of many factors the FDA can consider when determining whether research requires an IDE. This reasoning was apparent in two draft guidances on laboratory-developed tests that the FDA published in 2014⁶⁰ but later abandoned.⁶¹ One of the draft guidances indicated that research laboratories would need an IDE if research participants would have access to experimental test results that had not been confirmed by a medically accepted diagnostic product or procedure.⁶² It did not seem coincidental that the FDA published this draft guidance three days before the compliance date of a HIPAA rule change that greatly expanded HIPAA’s access right to data held at HIPAA-covered laboratories.⁶³ The timing suggests that the FDA viewed expanded HIPAA access as posing risks to research participants, or else regarded individual access as a factor suggesting intent for diagnostic use of research data. The fact that the FDA eventually withdrew this draft guidance is a hopeful sign that the agency realizes that providing HIPAA access does not imply any particular intent on the part of a HIPAA-covered laboratory, other than an intent to comply with a mandatory federal privacy law.

The fact that HIPAA’s regulations are mandatory for HIPAA-covered researchers may have helped persuade the agency not to read too much intent into the fact that a laboratory honors individuals’ access rights. In the non-HIPAA-covered space of mobile health research and research software developers, however, the FDA might view things differently. Creating a HIPAA-equivalent access right for participants in citizen-science projects would, in all likelihood, be done through policies reflected in software developers’ end-user agreements and terms of service. When no state or federal law makes individual access rights mandatory, the FDA might be more inclined to view a software developer’s decision to grant such rights as evidence that the developer intends diagnostic use of information from research. There is considerable evidence that people’s willingness to enroll in a research project depends on whether they will find out information about themselves.^{Reference Parker and Terry64} One survey found that “[t]he most influential factor affecting the respondent’s willingness to participate in the study seemed to be the offer of individualized results.”⁶⁵ Developers of research apps presumably are aware of these facts. Their voluntary choice to adopt policies allowing individual access to research data could be seen as a way of marketing their software to users who, according to the evidence just cited, have every intent to make diagnostic use of the data they receive.

The FDA’s intended use regulation provides that “if a manufacturer knows, or has knowledge of facts that would give him notice that a device introduced into interstate commerce by him is to be used for conditions, purposes, or uses other than the ones for which he offers it, he is required to provide adequate labeling for such a device which accords with such other uses to which the article is to be put.”⁶⁶ Even if a software developer intends for its software to be used only for basic scientific research, the fact that the developer is voluntarily granting individual access rights (when law does not require it to do so), together with the fact that participants plan to use their data for self-diagnosis,⁶⁷ might lead the FDA to infer that the software developer intends the diagnostic use. If that happens, the research app becomes SaMD that the FDA can regulate, including by requiring an IDE for the research if the FDA deems it to pose significant risk to the participants.

A typical application to the FDA for an IDE or IND (investigational new drug exemption) is thousands of pages long and requires many months and sometimes years to prepare.⁶⁸ Imposing IDE requirements on the software platforms used in citizen-science projects thus could have a profoundly chilling effect on citizen science activity. Efforts to create HIPAA-equivalent individual access rights for persons participating in citizen science projects have a potential to create costly and burdensome FDA compliance obligations for research app developers. Despite the importance of individual access rights as a crucial privacy protection, the potential FDA compliance impacts of providing such rights in non-HIPAA-covered mobile health research may hinder attainment of privacy parity.