Patient Controlled Health Data: Balancing Regulated Protections with Patient Autonomy


September 3, 2019

Cross Posted on The Health Care Blog

A patient can, under the Health Insurance Portability and Accountability Act (HIPAA), request a copy of her medical records in a “form and format” of her choice “if it is readily producible.” However, patient advocates have long complained about a process which is onerous, inefficient, at times expensive, and almost always on paper. The patient-driven healthcare movement advocates for turnkey electronic provisioning of medical record data to improve care and accelerate cures.

There is recent progress. The 21st Century Cures Act requires that certified health information technology provide access to all data elements of a patient’s record, via published digital connection points, known as application programming interfaces (APIs), that enable healthcare information “to be accessed, exchanged, and used without special effort.”  The Office of the National Coordinator of Health Information Technology (ONC) has proposed a rule that will facilitate a standard way for any patient to connect an app of her choice to her provider’s electronic health record (EHR).  With these easily added or deleted (“substitutable”) apps, she should be able to obtain a copy of her data, share it with health care providers and apps that help her make decisions and navigate her care journeys, or contribute data to research. Because the rule mandates the ”SMART on FHIR” API (an open standard for launching apps now part of the Fast Healthcare Interoperability Resources ANSI Standard), these apps will run anywhere in the health system.

Apple recently advanced an apps-based information economy, by connecting its native “Health app” via SMART on FHIR, to hundreds of health systems, so patients can download copies of their data to their iPhones. The impending rule will no doubt spark the development of a substantial number of additional apps.

Policymakers are grappling with concerns that data crossing the API and leaving a HIPAA covered entity are no longer governed by HIPAA. Instead, consumer apps and the data therein fall under oversight of the Federal Trade Commission (FTC). When a patient obtains her data via an app, she will likely have agreed to the terms and the privacy policy for that app, or at least clicked through an agreement no matter how lengthy or opaque the language.  For commercial apps in particular, these are often poorly protective. As with consumer behavior in the non-healthcare apps and services marketplace, we expect that many patients will broadly share their data with apps, unwittingly giving up control over the uses of those data by third parties.

Some patients may wish to explore the nascent emerging marketplace offering options to monetize their data. “Information altruists” and self-assembling patient groups will donate data to speed social and direct benefit through innovation and research. Notably, the monetary value of an individual record is generally low, with exceptions for patients having rare or complex conditions and histories.

How do we support a patient’s autonomy to use tools of her choice to improve her health and contribute to research, provide her with options to share in the monetary value from downstream uses of her data, while also protecting her from predatory practices?

HIPAA does not adequately address the issue. While it does allow an app developer to become a business associate of a covered entity (such as a provider or healthcare institution) this arrangement only applies when an app is managing health information on behalf of the covered entity — whereas in a consumer-centric ecosystem, many apps will choose to have a relationship with a consumer directly.  Importantly, the covered entity itself may be a conflicted party when the patient wishes to use an app that either (1) shares data with a competing health care provider or (2) competes with the functionality of the entity’s EHR. These conflicts could limit data flow across institutions, and raise the barrier to entry for new, innovative apps.

Further, the HIPAA business associate framework does not prevent commercial use of patient’s data without consent. Patient data in de-identified format are already shared widely in healthcare on hundreds of millions of patients, generally in ways that are opaque and not reported to the patients whose data have oft times been aggregated sold, and used for profit, and sometimes in ways that enable downstream re-identification.

A federal taskforce recognized that enabling patient autonomy to share data comes with inherent risk, and largely left these trade-offs in the patient’s hands. We propose strengthening the federal role in protecting health data under patient-mediated data exchange, while maintaining patient choice.

  • Require the EHR, upon exposing data across the API to a patient, to provide a standardized summary, at a sixth-grade reading level, of an app’s privacy policy and terms of service, highlighting risks for consumers (such as the ONC model privacy notice), and summarizing with an indication of whether they meet some specific bar (such as the CARIN code of conduct or a professional society or patient organization endorsement).
  • Establish best practices and federal standards for privacy policies and terms and conditions, relying on user-centered design as in large-scale federally funded research studies. Consider multimedia and semi-structured questionnaires (quizzes) to promote and confirm comprehension. Methods used to de-identify or aggregate data and their re-identification risk should be transparent, as should be intentions to commercialize the data.
  • Define a robust auditing process with oversight authority by either the Department of Health and Human Office for Civil Rights (OCR) or the FTC regardless of how the data are obtained.
  • Define penalties for violation of the terms of service and demonstrate strong and public federal enforcement.
  • Develop a consumer hotline and website for complaints to the OCR or the FTC, and publicize those complaints.
  • Introduce legislation to protect patients from predatory uses of their health data. Consider as model the Genetic Information Nondiscrimination Act of 2008, which prevents discrimination on the basis of genetic information in both health insurance and employment.

There are promising approaches available to protect a patient’s health data without limiting choice or creating a bottleneck to innovation by new and smaller entrants into the Health IT ecosystem. Now is the time to consider these carefully.

Kenneth D. Mandl, MD, MPH is director of the Computational Health Informatics Program at Boston Children’s Hospital and the Donald A.B. Lindberg Professor of Pediatrics and Professor of Biomedical Informatics at Harvard Medical School. He can be found on Twitter @mandl

Dan Gottlieb, MPAis a clinical informaticist and software consultant working with the Harvard Medical School Department of Biomedical Informatics and Boston Children’s Hospital Computational Health Informatics Program on tools to empower patients and researchers. He can be found on Twitter @gotdan

Joshua C. Mandel, MDis a physician and software developer working to fuel an ecosystem of health apps with access to clinical and research data. He can be found on Twitter @joshcmandel

Comments on the 21st Century Cures Act Proposed Interoperability Rule

May 20, 2019

Dear SMART Community:

10 years ago, the SMART project launched with a New England Journal of Medicine article proposing that EHRs could serve as a platform with a universal API supporting substitutable apps. Now, the 21st Century Cures Act requires the very API we envisioned and the draft rule, by the Office of the National Coordinator of Health Information Technology, following from Cures, is open for public comment.

The rule specifies that the SMART on FHIR API will be universally required so that an app written once can run anywhere in the healthcare system, and gain access to all of the elements of a patient’s electronic data, without special effort.

Getting the details right could not be more important to realizing a future healthcare system underpinned by a robust health information economy, driven by apps and real world information.

We post a copy of our public comment here.

The input is from our perspective as founders and members of the SMART on FHIR team that developed the SMART API, defined with HL7 and ONC the Bulk Data Export API specification, and launched the CDS Hooks project.

For our final version we have integrated several insightful edits and suggestions from the community.

Thank you for engaging with us on this.

Ken Mandl

Public comments on the Proposed Rule for the 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program 

Dan Gottlieb, Josh Mandel, Kenneth Mandl

@gotdan @joshcmandel @mandl

Overview. Our first and overarching comment is that the ONC’s drafting of this rule reflects clear thought, responsiveness to the community, attention to detail, and tremendous skill in expressing critical desiderata for a robust health IT ecosystem. The product of these efforts, the Proposed Rule, is extraordinarily impressive to us. The Rule addresses and reinforces virtually all of the major underpinnings which are currently feasible and needed to produce an interoperable apps-based ecosystem.

We state clearly and emphatically that the Rule should be largely left intact in its spirit and in most of its details.

Priority Goals

1. Improve App Connectivity for Patients and Providers

Connectivity. We cannot overemphasize the importance of standardizing the capability for a SMART on FHIR app written one time, to run unmodified anywhere in the healthcare system, regardless of the EHR or database vendor or version, accessing all of a patient’s electronic health data.  The app should be substitutable–easily added to or deleted from an EHR or related database, as easily as apps are added to iPhones and Android mobile devices.  The ONC has taken an enormous step forward with the certification requirement for the SMART application launch framework with the declaration of FHIR as a foundational standard, constrained by the Argonaut- or US Core-defined profiles. 

Weakening of any of the API requirements or information blocking provisions would potentially interfere with this objective.

Affordability. A patient’s access to all elements of her electronic medical record, across the SMART API, without cost, is well-supported in the Rule. The power of the provision is illustrated by the ease and speed with which Apple connected its Health App to more than 500 health systems across the SMART API, enabling patients at those institutions to download their data to iPhones for subsequent use in iOS apps. Under the Proposed Rule, any other app can connect to the same systems across the same SMART API.

Equally important, however, is that when a data provider (e.g., a practice or a healthcare system) also acts as an API user, they must be able to connect any app of their choice to their EHR. This ability is well-supported in the Rule, including important guardrails around what an API Technology Supplier can charge for cost recovery and on a per API call basis. It is essential that the proposed fee structures are such that providers can afford to connect third-party applications to their EHRs via APIs, opening up the interoperability that is a core property of any modern software system. There is a risk that the economics of paying for API calls to enable API Technology Supplier cost recovery will be limiting.

In an API/Apps model, the EHR and related IT serve as a platform for multi-sided business. It will take some time to understand and support the economics underpinning a nascent apps-based economy. Getting it right will strongly promote American business innovation, job creation and improved infrastructure to deliver value-based healthcare.

Evaluation. We recommend two evaluations. One concerns the real-world costs of APIs being used by health systems. The other concerns the actual patient experience of successfully obtaining their own electronic health information from specific providers.

With regard to the costs of APIs, we understand that ONC may be pursuing the cost-based pricing program out of necessity, but not that API Technology Supplier will not have an incentive to drive down their own costs. Additionally, current levels of revenue for API providers are not necessarily maintainable for a health system seeking value and growth in the diversity of app developers. API pricing structures should ideally level the playing field between first-party EHR functionality and third-party app functionality for a modular, extensible IT infrastructure.

Therefore, we propose that within six to twelve months after the implementation of the information blocking provisions of the Rule, ONC conduct a study to evaluate the real-world cost of APIs being used by health systems for areas such as clinical decision support, payments, machine learning, and precision medicine, and use the results to drive future policy. Benchmarking these costs will be difficult, but potentially useful metrics could include:

  • Comparing the cost of accessing data via APIs to that of accessing the same data with traditional EHR front end interfaces by amortized EHR licensing costs and adjusting for expected use. 
  • Comparing the cost of accessing data via EHR APIs to that of similar APIs, including those from cloud providers such as Microsoft Azure API for FHIR[1] or Google Cloud for Healthcare[2] and those provided as part of software solutions in other industries.
  • Examining the business models being used. For example, are API providers charging for system upgrades only, or are there substantial ongoing fees that limit app usage?

With regard to evaluating patient access, consumers continue to express tremendous variability in the ability and ease of gaining access to their own data. We therefore further propose that within twelve months after the API provisions of the Rule take effect, ONC conduct a study on patient access to their medical records, across the SMART on FHIR API without special effort.

2. Embrace Community Driven API Standards

Population API Access. We are extremely pleased to see that the Rule supports Population API Access (including and This requirement should specifically mandate the use of the FHIR Bulk Data Access Standard for all USCDI elements, including $export operations at the population level and including SMART Backend Services for authorizations. These specifications are currently being standardized through HL7 ( ).

Provide API Access for Data Exports. On the subject of full EHI access, we are concerned about the gap between the Proposed Rule for EHI Export and the regulatory intent of the 21st Century Cures Act to achieve interoperability with APIs that provide “access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.” In ONC’s proposal for certified API access, “all data elements” has been interpreted to mean “a limited set of data elements.” While not all data have been standardized, ONC should still include a functional requirement that the EHI Export capabilities must be available through a documented (if potentially vendor-specific) API, and accessible to patients. Specifically, to provide a usable consumer experience, the EHI Export capability must be:

  • Accessible directly to a patient (or authorized representative), rather than (or in addition to) being built as a feature for clinic staff. This is to ensure that patients don’t need to make a request by, e.g., phoning the medical records department, and waiting while the departmental staff hits the “export” button in response to a request — a friction-laden process.
  • Exposed end-to-end through an API, rather than being implemented exclusively as a button hidden deep within a patient portal experience, or being crippled by the exchange of physical media like CD-ROMs. This is critical because:
  • Portal experiences vary, making features difficult to find and correctly describe (e.g., if a third party is trying to guide patients toward the export functionality in a variety of portals). This was a clear challenge for anyone trying to identify the “Transmit to a third party” features of a patient portal in the MU2 timeframe.
  • Managing physical media, e.g., CDs, would take access outside the realm of modern, convenient consumer experiences, and would violate the without special effort requirement.
  • Managing files may be challenging on many patient devices (e.g., mobile phones), and some files may be best suited for off-device storage (e.g., in the cloud).

Our key recommendation on EHI Export is that ONC should require certified EHRs to support full EHI export at the patient level via patient-accessible API, and at the population level via data-provider-accessible API, even without standardizing the API or the data payloads. This will meet the Cures intent for API access.

API connectivity will provide patients with a seamless experience for accessing all of their health data, not just a core data set, and will ensure that healthcare providers can connect apps to data that is not currently available through the USCDI dataset. Providing access through open APIs, even for data that are not structured in open formats, will further this goal.

We have heard concerns about the overall scope of EHI access in a variety of exceptional circumstances (e.g., for data not stored in the EHR itself, or for data that represent purely internal system implementation details). As a baseline, we recommend that the data to be included in EHI Export should encompass the complete set of information that an EHR vendor currently makes available through their widely adopted data warehouse products, through their user interfaces, or through their reporting infrastructure.

SMART on FHIR.  The Rule should Specify which SMART on FHIR capabilities an API provider will need to support, at a minimum. The Proposed Rule requires mandatory support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” requirements. However, to ensure consistent implementation the Rule should also specify mandatory support for the following ten SMART capabilities: sso-openid-connect, launch-standalone, launch-ehr, client-public, client-confidential-symmetric, context-ehr-patient, context-standalone-patient, permission-patient, permission-user, permission-offline.

USCDI. The USCDI is a strong successor to the Common Clinical Dataset. To cover an expanded set of app use cases, we recommend the addition of data elements that cover clinical encounters and clinical imaging metadata.

In addition to considering data elements for read API access, ONC should look ahead to a future-state USCDI definition that includes some write API requirements, as well. Each element of the USCDI should include a list of required operations; today, these would all be “read access,” but this would provide a clear placeholder for future expansion of functionality (rather than just a list of data elements).

FHIR R4. The need to support multiple versions of standards can hinder interoperability.  ONC should adopt FHIR R4 as the only allowed version for standard API access moving forward, with an advancement process as described in the Proposed Rule.

Backend Services Access. To ensure that API Data Providers have the flexibility to innovate on top of the APIs provided by API Technology Suppliers, ONC should introduce a condition of certification ensuring that API Data Providers can obtain automated system-level access to all API calls from the API servers offered by API Technology Suppliers (e.g., via the SMART Backend Services authorization guide), with “system/*.*” scopes. This condition would enable API Data Providers to create additional services (e.g., API proxy or gateway functionality) on top of the APIs offered by API Technology Suppliers — an important “escape valve” for introducing new functionality or policies on top of existing data services.

Token Introspection. Again, to ensure that API Data Providers have the flexibility to innovate on top of the APIs provided by API Technology Suppliers, ONC should introduce a condition of certification ensuring that API Data Providers can perform token introspection using services enabled by API Technology Suppliers. This will ensure that additional resource servers (e.g., PACS systems that might expose FHIR imaging resources) can work with the same access tokens and authorization policies as the resource servers built directly by API Technology Suppliers.

ARCH. The ONC proposes the “API Resource Collection in Health” (ARCH) Version 1 implementation specification in § 170.215(a)(2), which would list a set of base FHIR resources that Health IT Modules certified to the proposed API criterion (§ 170.315(g)(10)) would need to support. While we see value in providing a catalog, we strongly recommend that ONC populate it using community-developed standards by groups like Argonaut and HL7, who can take functional requirements from USCDI versions, and produce Implementation guides. If ONC maintains an ARCH definition, this definition should be limited to referencing implementation guidance from community-developed processes; ONC should not “get out ahead” of the community process. For example, the ARCH should not make unilateral determinations about which FHIR resource or data elements are needed to meet a given USCDI requirement. Instead, that determination should be made through a community-driven, iterative process with real world testing of use cases.

Immature Standards. The vast majority of referenced standards in the Rule are mature, in real world use, and widely embraced by the community.  Two standards, however, strike us as “not ready for prime time:” Data segmentation for privacy (DS4P) and Consent2Share. While we recognize privacy maintenance and consenting as essential functions in health care, we are very concerned that a premature push for adoption of these immature standards would have unintended negative effects. ONC should omit these from the certification criteria (including voluntary certification) and focus on driving real-world implementation experience before pursuing regulations.

3. Move Beyond EHR Data

Clinical Imaging. We are concerned that sharing of images, an essential data type for patient care, may slip through the cracks. EHR systems often contain metadata around the available imaging studies, however, the imaging studies themselves are frequently stored in separate systems known as picture archiving and communication system (PACS). Providers should be responsible for sharing this imaging data, regardless of the technology supplier they choose. We recommend making PACS vendors subject to EHR certification rules, specifically for API access requirements.

Laboratory Data. While some clinical laboratory result data are accessible to patients through EHR APIs, historical data may not be comprehensive. Recently, national laboratory companies have begun to make these data available through API access for select apps. To promote a robust ecosystem of clinical applications, guidance should be provided on how this access should be expanded to an open ecosystem of apps to comply with the information blocking restrictions in the Rule.