This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in JMIR Medical Informatics, is properly cited. The complete bibliographic information, a link to the original publication on http://medinform.jmir.org/, as well as this copyright and license information must be included.
A compendium of US laws and regulations offers increasingly strong support for the concept that researchers can acquire the electronic health record data that their studies need directly from the study participants using technologies and processes called consumer-mediated data exchange. This data acquisition method is particularly valuable for studies that need complete longitudinal electronic records for all their study participants who individually and collectively receive care from multiple providers in the United States. In such studies, it is logistically infeasible for the researcher to receive necessary data directly from each provider, including providers who may not have the capability, capacity, or interest in supporting research. This paper is a tutorial to inform the researcher who faces these data acquisition challenges about the opportunities offered by consumer-mediated data exchange. It outlines 2 approaches and reviews the current state of provider- and consumer-facing technologies that are necessary to support each approach. For one approach, the technology is developed and estimated to be widely available but could raise trust concerns among research organizations or their institutional review boards because of the current state of US law applicable to consumer-facing technologies. For the other approach, which does not elicit the same trust concerns, the necessary technology is emerging and a pilot is underway. After reading this paper, the researcher who has not been following these developments should have a good understanding of the legal, regulatory, technology, and trust issues surrounding consumer-mediated data exchange for research, with an awareness of what is potentially possible now, what is not possible now, and what could change in the future. The researcher interested in trying consumer-mediated data exchange will also be able to anticipate and respond to an anticipated barrier: the trust concerns that their own organizations could raise.
Researchers who need electronic health record (EHR) data [
Theoretically, researchers could overcome these logistical challenges by obtaining comprehensive longitudinal electronic patient records from a clinical data research network, a clinical data repository, and/or a health information exchange, but practically, both convenience and data completeness challenges remain [
Consumer-mediated data exchange [
There has been strong and enduring US federal support for the principle that individuals should have access to their own EHRs and that individuals can share their records with third parties, including researchers [
To implement these principles, the Centers for Medicare and Medicaid Services (CMS) had incentivized providers to give patients the ability to view, download, and transmit their own data electronically, originally through the Meaningful Use program [
CMS and ONC took another major step in February 2019 when both agencies released notices of proposed rulemaking, on the same day, intended to accelerate the interoperability of electronic health information in the United States by leveraging consumer-mediated data exchange [
In summary, in the United States, there is strong legal and regulatory support for the principle that consumers have a right to access their own electronic health information and that consumers can use their data however they wish, including contributing them to a research database.
For consumer-mediated data exchange for research to be viable at scale, the following conditions must exist:
All study participants must receive care from providers who have the technical capability to respond to patient requests either to download their own data (approach 1: Download and Send) or to direct their own data to a researcher (approach 2: Transmit). In addition, there must be consumer-facing technologies to support the participant.
The data obtained through this method must be useful for the study.
The participants, providers, researcher’s organization and Institutional Review Board (IRB) must have any potential trust concerns allayed. This paper focuses on trust concerns that the researcher’s organization or IRB could raise, because if they are not addressed, they may refuse to approve the study. (If providers have trust concerns, they will not make this service available to their patients, which for this paper is indistinguishable from a technical barrier. If prospective participants have trust concerns, they would decline to participate, and presumably, there would be others without such concerns for the study to proceed).
This paper first reviews the contemporary technology landscape to assess the level of technical support for both approaches to consumer-mediated data exchange, along with the types of data that researchers could expect to receive. The paper does not address data completeness, provenance, harmonization, and other utility barriers in using EHR data for research, as these have been documented elsewhere [
The paper will explain why technical viability in theory is now strong for the
The paper concludes with a summary, limitations, and a review of potential future developments.
For the
The ONC had estimated that, in 2015, 87% of hospitals and 41% of office-based physicians gave patients the ability to download their own medical records [
Since the 2015 reports, estimates of provider prevalence with capabilities have continued to increase. In 2018, the ONC reported [
In a 2017 report to the Congress, the US Government Accountability Office reported that most providers achieved the view, download, and transmit functionality through patient portals [
On the basis of ONC estimates, it is likely that most, if not all, US providers either currently (March 2019) have the
For the
In 2015, the ONC reported that 66% of hospitals [
Transmission by insecure email would likely be unacceptable to researchers. Transmission by Direct Messaging, however, requires the electronic address of the recipient, which the patient must know and be able to share with the transmitting provider.
This is problematic for usability. Hospitals’ most commonly reported barrier to electronic information exchange was difficulty locating the electronic addresses of the recipient [
Provider directories containing digital contact information exist in both the private and public domains. The nonprofit organization, DirectTrust, maintains a directory [
Publicly, CMS maintains a directory called the National Plan and Provider Enumeration System (NPPES) [
With respect to researcher inclusion in the NPPES, CMS directions for obtaining an identifier, and for becoming listed in the NPPES, convey through use of examples such as “physician” and “hospital” that CMS uses the word “provider” to refer to an individual or organization that delivers medical care. However, some individuals and organizations now listed in the NPPES have research-related taxonomy codes. Due to the novelty of consumer-mediated data exchange, we doubt that these providers are receiving consumer-directed electronic health information. Rather, we believe that their presence in the NPPES facilitates administrative mechanisms required to charge a research study when its participants receive clinical care. However, the fact that research-related individuals and organizations already appear in the NPPES demonstrates that researchers interested in receiving consumer-directed electronic health information do have a mechanism for listing themselves in this public directory.
Usability challenges do remain but could be addressed by the ONC. For example, the ONC already publishes a Patient Engagement Playbook [
This review suggests that although provider-facing technology should support transmit functionality, usability is a barrier, particularly for consumer attempts to direct the transmission of data using portal-based technology. It is possible that these usability issues will be addressed, and it also is possible that the introduction and use of new technology will address usability issues in other ways. Between 2015 and 2019, technology evolved through the maturation and testing of standards that were in development at the time that ONC finalized its 2015 certification requirements. The emerging technology rapidly gaining adoption involves the exchange of electronic health information through
When both provider- and consumer-facing technologies use the FHIR APIs, the OAuth 2.0-protected consumer can easily access his or her data from the provider and then transmit the data to a target of the user’s choice. In theory, the target could be another provider, to facilitate interoperability. The target could be the consumer’s device, which is functionally equivalent to the
For this emerging technology to support research, all US providers must have technology that can support FHIR APIs with OAuth 2.0. The rule that ONC proposed in February 2019 [
In summary, to support patient care, most providers now have technology that supports
If ONC estimates are correct, it is likely that, as of early 2019, most US providers already have technology capable of supporting the
It is likely that, in a few years, all providers will have technology that has been certified to support the
The
At least two vendors of consumer-facing apps, both relying on portal download technology, promote their research utility. The vendor Carebox boasts that its app can collect medical records automatically, once the user establishes the connection [
Consumer-facing apps that use FHIR APIs conceivably can access the consumers’ electronic health information from providers and then send them to a designated target, which includes the consumer’s own device, which is functionally equivalent to the
When patient portals were first introduced, they were called personal health records. Later, when consumer-facing applications that gathered data from multiple sources entered the market, these too were called personal health records. To differentiate between them, market analysts and some researchers began referring to the patient portal as a tethered personal health record and referring to the consumer-facing application as an untethered personal health record. As patient portals became more common, and included convenience functions such as making appointments online, paying bills, sending secure messages to providers, the vocabulary changed again, and writers simply referred to patient portals as “patient portal”. Once the word “tethered” was less often used to refer to patient portals, its antonym, “untethered”, was less often used to refer to consumer-facing applications that can compile data from multiple sources.
None of the apps that we reviewed, which rely on portal technology, advertise any ability to help the user direct their providers to transmit their data to a third party, either other providers or a research database. Apps that use FHIR APIs could authorize providers’ technology to transmit the data to other providers or to a research database. There are growing numbers of consumer-facing apps that use FHIR APIs and one has been designed to support data transmission for research. This is the app designed and built for the Sync for Science project, on behalf of the All of Us Research Program. We have discussed Sync for Science in more detail below, in the context of future possibilities.
As shown in
State of provider- and consumer-facing technology to support consumer-mediated data exchange for research, as of March 2019.
Approach | Provider-facing technology | Consumer-facing technology |
Approach 1: Download and send | Likely ubiquitous or nearing ubiquity among US providers, using download capabilities from the patient portal. | Many consumer-facing applications on the market tha give users ability to download records and compile them. Two vendors are known to take responsibility for transmitting users’ records to researchers, with user consent. |
Approach 2: Transmit | Capabilities from the patient portal exist but insufficient use of digital contact information poses usability barriers. Many providers have technology that uses FHIR APIsa, and this technology would support the approach, but there are social, business and usability obstacles. These could be removed within several years if ONC’sb February 2019 proposed rule is finalized. | There are no indications that applications exist in the consumer-facing market that support “transmit” from the portal technology. |
A growing number of applications, with Apple as a market leader, use the FHIR API technology which could be deployed for “transmit”. Sync-For-Science is a prominent pilot testing the technology for research use, but scale is currently limited to four EHRc vendors and approximately 12 providers. | ||
This holds great promise for the future, but current opportunities are limited. |
aFHIR API: Fast Healthcare Interoperability Resources open application programming interface.
bONC: Office of the National Coordinator for Health Information Technology.
cEHR: electronic health record.
As a social concept,
For this paper, there are 3 actors (participant, researcher, and vendor of the consumer-facing app), and thus, there are 3 trust relationships:
Relationship 1:
Relationship 2:
Relationship 3:
All relationships could be violated if the vendor uses participant data in ways that neither the researcher nor the patient authorized [
In the most common current use of existing technology, which does not rely on FHIR-based APIs, consumers who use commercial personal health record apps to download their data from providers must give the app necessary credentials for accessing their data, such as a patient portal username and password. In addition, the vendor will be exposed to the data during the process of transferring them from the provider to the patient’s device. The vendor will also be exposed if the vendor takes responsibility for transferring the records from the consumer’s device to the research database. Thus, the developers of the consumer-facing apps have access to personal health information that they have the potential to abuse, raising concerns about the integrity of the trust relationships.
These concerns have been enduring [
As there is little disagreement about the basic privacy and security protections to which personal health record apps should adhere [
No other US federal agency has this authority either. The Office of Civil Rights and the Federal Trade Commission (FTC) are the 2 federal agencies with the closest authority. The Office of Civil Rights investigates every reported HIPAA violation and has the authority to impose fines or other punishments for violations. However, by definition, commercial vendors of untethered health record apps are not HIPAA-covered entities [
The FTC has authority to investigate complaints of consumer harm, although unlike the Office of Civil Rights, which investigates every reported HIPAA violation, the FTC chooses which complaints to investigate, typically on the basis of the magnitude of harm [
Some believe that the FTC and the Office of Civil Rights already have the authority they need [
As there are unlikely to be changes in US law that would address these concerns, there now are activities underway to better leverage the FTC’s existing authority. The CARIN Alliance is a prominent multisector group within the health care industry that works collaboratively with US government leaders to promote consumers’ ability to access their electronic health information via open APIs [
The press release announcing the framework and Code says:
For the first time, health care organizations and other organizations can have an enforceable code of conduct for third-party applications not covered by HIPAA to self-attest to in order to access health care data on behalf of consumers.
The CARIN Code has stakeholder support from consumers and caregivers, health information networks, former regulators, app vendors, health care providers, medical home networks, and health plans [
We believe this is unlikely. The Exchange is intended to be the implementation of a provision of the 21st Century Cures Act which directs the ONC to create a framework and agreement for the exchange of electronic health information between health information networks. As noted above, in January 2018 the ONC released a draft of the Trusted Exchange Framework and Common Agreement [
However, these requirements that ONC would impose upon non-covered entities apply only to entities that wish to participate in the Exchange by offering Individual Access Services. ONC still does not impose any requirements upon non-covered entities that choose not to participate in the Exchange, including noncovered apps that help consumers access their data directly from their providers, rather than health information networks.
The Office of Civil Rights, in early 2016, issued strongly worded Guidance directed toward providers that (1) reaffirmed that providers are legally required to provide patients access to their own EHRs upon request and (2) stated that providers were not liable if, upon complying with a patient request, the patient subsequently placed the privacy and/or security of their own records at risk [
Research organizations undoubtedly would welcome comparable guidance that specifies liability if studies
This silence can provoke uncertainty for research organizations’ legal and risk departments, and they may contemplate
The most likely source of guidance would come from the organization,
In conclusion, research organizations or IRBs could be concerned about studies that acquire EHR data using unregulated vendors. The professional society,
The trust concerns associated with the
The research team could proactively build trusted relationships with commercial developers through the following mechanisms:
Only consider vendors that have adopted the ONC’s Model Privacy Notice [
Collaborate with the CARIN Alliance to implement the third phase of its Trust Framework, in which third parties certify apps and their vendors for their adherence to the Code and can also create other certification criteria. Research organizations, for example, could develop criteria related to the vendor’s ability to support research needs, including—if applicable—its willingness and ability to securely transfer user data to the research team if the user consents, and to configure these data so that they are analytically digestible.
Impose the organization’s security and privacy requirements upon the vendor contractually, detailing the consequences to the vendor if the organization learns that the vendor has compromised participant data.
Establish monitoring systems for the vendor’s privacy policies and the movement of data through the vendor’s system, intervening if there is suspicious activity.
A research organization could create its own app that its study participants could use, which would take the vendor out of the mix of trusted relationships, so that trust would only be established and maintained between the study participant and the research team. This increases the burden on the research team, which now has to build and maintain a consumer app. The burden is lower if the study is retrospective, only requiring participant records that exist at the time the study begins. The research team’s burden increases if the study is prospective, meaning that new records must be obtained as they become available, which then means that the researcher will have to maintain the app over time and potentially release upgrades that are compatible with changes in the broader environment. The burden is particularly high if the researcher would like to use the app as an incentive to attract participants, offering them the personal data management capabilities that commercial vendors offer.
If the research team is not troubled by these potential burdens, then building and managing its own consumer-facing app could potentially mitigate trust concerns and allow the study to proceed. A faculty member at the Yale Center for Clinical Investigation did just that, which is how the Hugo app was developed [
If neither of the options mentioned above are viable, the researcher could use an app that relies on the FHIR API technology so that the data can be transmitted from the provider to the user’s device without traversing the vendor’s network. Among the consumer-facing apps that say they use FHIR APIs, Apple is the most well-known, and the ONC cited Apple by name in its 2019 proposed rule. However, using Apple could impose limitations on the study. Apple’s app will only work with an iPhone, which means that the study can enroll only iPhone users. In addition, Apple’s app only downloads data from providers who are members of Apple’s partnership. The partnership has grown steadily since Apple first launched the app in January 2018 [
Researchers unable to work within the existing limitations could prepare themselves for a future that may hold one or more of the following:
If Apple’s partnership eventually includes all US providers, then limitations in data only coming from participating providers would be removed, leaving only the limitation of iPhone use. This limitation will also evaporate as other vendors develop and promote consumer personal health record products using FHIR APIs. In the future, all consumers may be able to download their electronic health data to their devices using FHIR APIs, and researchers could adapt to whatever device and app and prospective study the participant prefers.
This still would leave open the challenge of getting the data from the participants’ devices to the research database. It is technically feasible for a consumer-facing research app to use the FHIR API standard to request and receive data from a consumer-facing personal health record app, and although we are unaware of apps that support this now, an enterprising developer could create one in the future.
If the CARIN Alliance succeeds in fostering its Trust Framework, and vendors of personal health records self-attest to adhering to its Code of Conduct, and symbols of this attestation appear on app stores and product labels, then the symbol could serve as a
The norms around vendor behavior would be strengthened if it were publicly known that the FTC will investigate vendors that violate pledges to adhere to the Code. Research organizations could then be assured that there would be externally imposed consequences upon vendors who fail to uphold the standards of conduct.
In the
In the spring of 2016, the National Institutes of Health, in collaboration with the ONC, contracted with Harvard Medical School to create a standards-based open source technology framework called Sync for Science [
After several years of design, development, and consultation with IRBs, in September 2018, a pilot began to test the Sync for Science transmit technology on behalf of the All of Us Research Program [
At no point does the study participant give the research app his or her portal access credentials nor does the app ever see or manage the participant’s private health information. The app merely facilitates, on behalf of the patient/consumer/participant, the exchange of data between the HIPAA-covered entity and research team. Thus, the approach eliminates the primary sources of trust concerns that the researcher’s organization or IRB may have.
The pilot described above is intended to test the technology with a limited number of EHR vendors and providers. It will only enroll patients who receive care from one of the pilot’s providers. If that participant happens to receive care from other providers, not involved in the pilot, the EHR data from the other providers will not be available. It is a technical proof of concept, rather than a test of how the
For this process to work at scale for any study, all US providers must be served by health information technology that complies with the Sync for Science technical framework. The research team must use a consumer-facing app that has the same technical capabilities as the app built by the Sync for Science team, and the apps’ developers must have registered their products with all Sync for Science-compliant health information technology vendors in the United States. The vendors must extend the product’s registration to all the providers that the technology vendor supports [
The Sync for Science technical framework is none other than the FHIR API coupled with OAuth 2.0 authentication. If the ONC’s February 2019 proposed rule is finalized, all vendors of provider-facing health information technology that meet ONC certification requirements will support this framework. CMS will likely require all providers participating in its value-based purchasing programs to use health information technology that satisfies the ONC’s now-proposed certification requirements, and this is the mechanism through which all US providers would acquire the necessary technology. The ONC’s 2019 proposed rule, if finalized, also would remove known technical and business barriers to widespread use of the technical framework. The ONC proposes to require vendors of provider-facing technology to (1) respond within 5 business days to consumer-facing apps’ registration requests, (2) publish technical documentation that enables consumer-facing apps to build connections to the vendors’ APIs, and (3) refrain from charging fees to apps or providers other than the fees designed to differentiate themselves in the market with value-added services. With these and other proposed certification criteria, the ONC intends to break down barriers that now inhibit this technically sophisticated approach to consumer-mediated data exchange.
The ONC proposes to require vendors to meet the updated certification requirements no later than 24 months after the rule is finalized. If finalization occurs in mid-2019 with these proposed requirements intact, by the middle of 2021, the provider-facing technology should be available to support the
With regard to the existence of consumer-facing apps that support the
Previously, we discussed directories containing providers’ digital contact information in the context of the portal-supported
Although it is administratively and technically possible for researchers to list themselves in the NPPES, it may not be necessary if the study participant uses a research app with a FHIR API with OAuth 2.0 as its core technology. With this technology, the research app already will tell the provider’s technology where to send the requested data, and so neither the provider nor user will have to look up an address in a directory.
However, while the FHIR API technology may eliminate the need for researchers or their studies to be listed in the NPPES, a directory of providers will still be necessary because the study participants will need to tell the research app who their providers are. In the Sync for Science pilot now underway, a small directory exists that only includes the providers participating in the pilot. In the future, at scale, there will need to be a directory that lists every US provider with the technology to respond to a request to transfer data using an FHIR API.
The NPPES may not be a good vehicle for meeting these research needs. Although it is publicly accessible, it was designed to facilitate exchanges of information between HIPAA-covered entities; it was not designed to meet consumer needs. It contains records for health plans and for individual clinicians and facilities. For each entry, there could be several types of electronic addresses used [
However, there is an alternative, in which the research app that study participants will use contain its own provider directory, with a user interface designed to help participants search for their providers and select them when they find them. The apps’ developers could use the content of the NPPES (which is publicly available via download) to populate the consumer-friendly research app directory.
In summary, the FHIR API technology eliminates the need for a directory containing digital contact information for the research database, because the target that receives the data will be identified within the research app that the study participants will use. The FHIR API technology does not eliminate the need for a directory containing a list of US providers, but the task of designing and populating a directory that consumers can use will probably be assumed by the developers of the research apps.
There are 2 approaches to consumer-mediated data exchange for research. In one approach, which we call
As of early 2019, technical support for the
Alternatively, the researcher could wait until the environment becomes more favorable. Activities are underway now that could produce a much more favorable environment within several years. These include CARIN Alliance’s efforts to establish a universally accepted trust framework, in which the FTC could investigate actors who publicly commit to adhering to it and then violate that pledge. In addition, the ONC has proposed rules which, if finalized, would stimulate universal adoption among providers of next-wave technologies that support the
For the researcher interested in using consumer-mediated data exchange, there are potential limitations other than those that we already addressed:
The paper assumes that ONC estimates about the widespread prevalence of the necessary provider-facing technology are correct. As the ONC estimates are based on provider self-reporting and vendor attestation, rather than actual patient experience, this assumption could be incorrect. In addition, the ONC estimates rely on the presence of the necessary technology, not whether the provider is actually using it, or that the patients can use it as well [
The paper assumes that study participants are willing and able to use the necessary consumer-facing technology and that they have credentials that allow them to access their own data from their providers. Although there is evidence that consumers are increasingly taking advantage of patient portals [
The paper assumes that data obtained through consumer-mediated data exchange will contain the data elements in the Common Clinical Data Set [
In the absence of the limitations described above, researchers could be using the
application programming interface
Centers for Medicare and Medicaid Services
electronic health record
Fast Health Care Interoperability Resources
Federal Trade Commission
Health Insurance Portability and Accountability Act
Institutional Review Board
Merit-Based Incentive Payment System
National Plan and Provider Enumeration System
Office of the National Coordinator for Health Information Technology
Funding was provided through internal research and development funds at RTI International. The authors acknowledge input from David Kreda representing Sync for Science, and input from Fred Trotter, at CareSet Systems, who provided invaluable insight into the NPPES.
All authors contributed to this manuscript by conducting background research, writing, and editing drafts.
None declared.