Patient Controlled Health Data: Balancing Regulated Protections with Patient Autonomy

By KENNETH D. MANDL, MD, MPH, DAN GOTTLIEB, MPA, and JOSHUA MANDEL, MD

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 https://www.federalregister.gov/d/2019-02224/p-447 and https://www.federalregister.gov/d/2019-02224/p-837). 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 (http://hl7.org/fhir/us/bulkdata/ ).

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:

  1. 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.
  2. 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.


[1]
https://azure.microsoft.com/is-is/pricing/details/azure-api-for-fhir/

[2] https://cloud.google.com/healthcare/docs/pricing