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

The SMART Team Comments on the 21st Century Cures Act Interoperability Rule

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.

In advance of posting our public comments, we post a draft here for community feedback.

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.

Thank you for engaging with us on this.

Ken Mandl


Draft 

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 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 provider can charge for cost recovery and on a per API call basis.  Affordability of this capability is essential. Data providers must be able to afford the enhanced health IT systems that have APIs to permit the fundamental interoperability that many believe should be native properties of any modern software system. The data providers must also be able to afford the cost of API access resulting from the use of apps that connect and provide value. There is a risk that the economics of paying for API calls to enable API provider cost recovery will be limiting.

In the 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 understand that ONC may be pursuing the cost-based pricing program out of necessity, but not that API Providers 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 a year after the implementation of the Rule, O NC 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 or Google Cloud for Healthcare 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?

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, currently being balloted through the HL7 standards organization (http://docs.smarthealthit.org/flat-fhir/ ).

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). API connectivity ensures that patients can have a seamless experience for accessing all of their health data, not just a core data set.

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

API connectivity will ensure that patients can have a seamless experience for accessing all of their health data, not just a core data set and healthcare providers have the option to 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.

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.

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.


Ensuring that the 21st Century Cures Act Health IT Provisions Promote Interoperability and Data Exchange

Kenneth D. Mandl, MD, MPH,1,2 Dan Gottlieb, MPA,2 Josh Mandel, MD,1,2,3

1. Computational Health Informatics Program, Boston Children’s Hospital, Boston, MA

2. Department of Biomedical Informatics, Harvard Medical School, Boston, MA

3. Microsoft Healthcare, Redmond, WA

The opportunity has never been greater to, at long last, develop a flourishing health information economy based on apps which have full access to health system data–for both patients and populations–and liquid data that travels to where it is needed for care, management and population and public health. A provision in the 21st Century Cures Act could transform how patients and providers use health information technology. The 2016 law requires that certified health information technology products have an application programming interface (API) that allows health information to be accessed, exchanged, and used “without special effort” and that provides “access to all data elements of a patient’s electronic health record to the extent permissible under applicable privacy laws.”

After nearly two years of regulatory work, an important rule on this issue is now pending at the Office of Management and Budget (OMB), typically a late stop before a proposed rule is issued for public comment. It is our hope that this rule will contain provisions to create capabilities for patients to obtain complete copies of their EHR data and for providers and patients to easily integrate apps (web, iOS and Android) with EHRs and other clinical systems.

Modern software systems use APIs to interact with each other and exchange data. APIs are fundamental to software made familiar to all consumers by Google, Apple, Microsoft, Facebook, and Amazon. APIs could also offer turnkey access to population health data in a standard format, and interoperable approaches to exchange and aggregate data across sites of care.

The Office of the National Coordinator of Health IT (ONC)-funded SMART on FHIR API specification enables apps to connect with EHRs in a standards-based way, giving users a frictionless way to choose their favorite apps. This property of substitutability defines a new form of interoperability. SMART leverages the Health Level Seven (HL7) Fast Health Interoperability Resources (FHIR) standard and has been implemented by the major EHR products. The SMART app gallery, and EHR-specific app stores such as Epic’s App Orchard and Cerner’s code App gallery host scores of app that connect to EHRs.

Two particularly intriguing uses of SMART are (1) Apple’s use of the API to connect its health app to hundreds of health systems enabling users to download copies of their health records to their smartphones; and (2) the Centers for Medicare and Medicaid’s implementation of “Blue Button 2.0”, enabling beneficiaries to connect apps to their healthcare financial data.

Because the specifics of the final rule matter greatly, we strongly encourage policy makers to attend carefully to a few key requirements which derive from the phrases “without special effort” and “all data elements.”

Expanded data access. ONC has proposed a set of standardized clinical data that will grow over time from the 2015-era “Common Clinical Data Set” to a forward-looking “US Core Data for Interoperability”. This kind of consistent, standards-based data set holds tremendous promise for the ecosystem. At the same time, standards can lag behind clinical practice and cutting-edge technology development, so the Cures Act goal of “all data elements” would be challenging to achieve through detailed clinical modeling standards alone. We should not allow the perfect to be the enemy of the good. We propose a three-pronged approach to meeting the Cures provisions for “all data elements”:

  1. Use standards that exist today. For example, FHIR “US Core” profiles cover the 2015 era Common Clinical Data Set, providing a common basis for communicating patient demographics, medidcations, conditions, lab results, vital signs, and more. These core data should be made available through APIs to provider- and patient-facing apps.
  2. Continue developing these standards over time. For example, efforts like HL7’s Argonaut Project are driving common support for new data types like clinical notes as a fast-moving 2018 roadmap. We should start building a community-maintained “profile backlog” to articulate and prioritize the most valuable data that haven’t yet been standardized.
  3. Enable flexible approaches to cover the gap between our well-standardized-and-growing “core data” definitions and the long tail implied by the Cures provision for “all data elements.” As one example to illustrate how EHR vendors could ensure that innovators have programmatic access to all of the clinical data accessible in the system: similar to the way vendors publicly document a subset of APIs today, they might expand this documentation to include database schema, tables, columns, and enumerations used to store complete clinical records.

This approach (use standards, develop standards, and cover the gap) would empower early adopters to develop cutting edge clinical integrations ahead of the standardization process, building experience to guide the standards process that follows.

Standard and ubiquitous APIs for patient facing apps, provider facing apps and population analytics. Our vision is that an app written once should run anywhere in the healthcare system. The availability of standardized APIs, ubiquitously implemented across care settings, is essential to driving down the “special effort” that is still typically required to create, distribute and use health apps.

  1. Standardize APIs for apps. The SMART Health IT (a.k.a. SMART on FHIR) specification is sufficiently mature to be considered as an industry standard for launching and authorizing apps in an EHR or patient portal. It is in widespread use in clinical settings, has achieved consensus through the Argonaut process, is implemented in EHR products, and its core elements are being incorporated into the next release of the FHIR standard.

While the SMART-based app integration focuses on one‐patent‐at‐a‐time access to health system data, population level data export is critical for value‐based care, postmarket surveillance, quality improvement, and clinical research. The API should enable a user or an app to specify export of all EHR data or EHR data on defined cohorts at the discretion of the data owner. Under ONC funding, a standard for bulk data export in a FHIR‐formatted flat file has been proposed and the Argonaut implementation group is working to pilot it in 2018.

  1. Allow multiple pathways to register apps for connection to EHRs and other HIT. As more EHR vendors build support for standards-based apps, developers are discovering that they need to independently register each new app with each vendor and complete a set of on-boarding, review, or “vetting” steps before users are able to install the app and authorize a data connection. The app registration and vetting landscape is evolving quickly as vendors create developer programs, launch partnerships, and build out their own app marketplaces. App vetting procedures review and assess critical aspects of integration including security, usability, and business/privacy practices and offer value to end-users, who expect a clean, safe, experience of choosing, installing, and running apps.

Nonetheless, we have observed that these vetting practices can cause friction for some use cases and believe it is too early to define a “one size fits all” standardized app vetting process.  As such, we propose an “escape hatch” in the form of an at your own risk principle, by which provider organizations and individual patients should be able to accept the risk of connecting an un-vetted app to their own data without vendor review. While many apps will follow a conventional path of registration and vetting, this option provides a route to ensure that all apps, even small-scale apps (e.g., one-offs produced by individual tinkerers, open-source developers, research efforts) can reach visibility and commercial viability within the real-world clinical landscape, and that providers have the opportunity to select any apps of their choice.

  1. Ownership terms. App developers should have the option of retaining all intellectual property related to the app, regardless of how the app connects to the EHR and which underlying EHR APIs the app consumes.
  2. Maintain free registration of apps for patients. As required now under Meaningful Use Stage 3, patients should always be able to connect apps of their choice, without cost.
  3. App connections should be long lasting, when desired. In other words, the user should not need to reauthorize the app to the system each time data is accessed. This property will enable apps to perform functions on behalf of patients and providers, without special effort (for example, checking periodically for new lab results).

Summary. We are so pleased that ONC has and the OMB have gotten to the is stage in which a proposed rule is pending at OMB. We are on the precipice of creating a national-scale apps model for health, based on an API that promotes interoperability and data exchange via substitutable apps. The simple imperatives we enumerate above, could reshape the health IT industry by providing a channel for innovators to distribute and/or sell their software applications by enabling customers to select and integrate EHR-connected apps as easily as they do for smartphones. As the final proposed language implementing the 21st Century Cures Act API provisions is reviewed and prepared for release is decided, we encourage policy-makers to keep all eyes on this prize.

This blog has been cross posted at The Health Care Blog.

Push Button Population Health Data: Extending the HL7 FHIR Standard to Support Bulk Data Export

Activities such as managing population health, delivering value-based care, and conducting discovery science require access to large population data sets. The existing FHIR and SMART APIs work well for accessing small amounts of data, but large exports perform poorly, requiring an impractical number of API requests to be issued serially. By adding asynchronous primitives to FHIR and defining an export operation, the Bulk Data API enables secure integration of third-party, externally-hosted applications into diverse EHR and data warehouse environments.

On behalf of the ONC, The Boston Children’s Hospital Computational Health Informatics Program and SMART hosted a meeting in December 2017 to discuss standardizing bulk data exports from EHR systems and data warehouse environments. This meeting brought together key stakeholders from across health care, including the Director of the Office of the National Coordinator for Health Information Technology (ONC) and other members of the ONC staff, as well as representatives from payers, health systems, EHR vendors, and other health technology innovators.

A summary report is now available:

Also, get involved in the ongoing, early stage, FHIR Bulk Data API Project by reviewing the draft specification and joining the discussion group!

SMART at HIMSS 2018!

All times are PST. Session schedule may change – check back for updates.

  • Tuesday (3/6)

    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | HL7 – Booth 5623
    • Sync for Science and the CMS Blue Button on FHIR API: Claims Data for Research
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Carly Medosch, Program Analyst, CMS
      2:00 – 3:00pm | CMS Booth #10110
    • SMART on FHIR: Building apps that integrate with clinical systems through open standards
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project; Josh Mandel, Health IT Ecosystem Lead, Verily
      Learn how SMART Health IT’s open source, standards-based technology platform enables innovators to create apps that run seamlessly and securely across the healthcare ecosystem.
      3:30 – 4:15pm | HIMSS Developer Innovation Lab (Hall G, Booth 9900-DL)
  • Wednesday (3/7)

    • Sync For Science Scientific Session
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session, the Sync for Science team will sit down with the research community to talk through use cases, challenges, wish lists, and pragmatics of working with EHR data.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • Argonaut Project Town Hall Meeting
      Micky Tripathi, President & CEO, MAeHC; Aneesh Chopra, President, CareJourney; Ryan Howells, Principal, Leavitt Partners; Josh Mandel, Health IT Ecosystem Lead, Verily; Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      The town hall will cover 1) Argonaut Project 2017 deliverables and 2018 work plan, 2) CARIN Alliance consumer directed exchange trust framework updates and TEFCA alignment, 3) SMART and ONC efforts to accelerate bulk data access via FHIR APIs.
      5:30pm – 6:30pm | Hall G, Booth 11955ET | RSVP Here
  • Thursday (3/8)

    • Sync For Science Demonstration
      Josh Mandel, Health IT Ecosystem Lead, Verily; David Kreda, Healthcare IT Designer and Consultant; Teresa Zayas Caban, Chief Scientist, ONC
      In this session we’ll review the consumer workflow, the underlying technologies and the regulatory environment that support Sync for Science, and describe upcoming extensions to support new data types.
      10:00 – 10:45am | The Venetian, Room Zeno 4601
    • CDS Hooks: Integrating decision support at the point of care
      Josh Mandel, Health IT Ecosystem Lead, Verily; David McCallie, Senior Vice President for Medical Informatics, Cerner
      We’ll review the technology, clinical use cases, standards development, and real-world implementation experience for the emerging CDS Hooks specification.
      11:40am – 12:10pm | HL7 – Booth 5623
    • FHIR for Bulk Data
      Dan Gottlieb, Senior Technical Lead, SMART Health IT Project
      Learn about an exciting new effort by SMART and HL7 to bring the FHIR standard to bear on the challenges of bulk-data export.
      1:00 – 1:30pm | Hall G, Booth 9900-DL

Response to ONC’s proposed Trusted Exchange Framework and Common Agreement

Next week is the final opportunity for public comment on the ONC’s proposed Trusted Exchange Framework and Common Agreement. I’ve prepared a set of comments and recommendations that focus on the scope and mechanics of individual access, including technical standards, security requirements, identity proofing, authentication, and authorization.

Given the importance of health data exchange to the SMART Health IT community, I’m sharing the full letter and 15 recommendations here in PDF.

Draft Model RFP Language for Purchasing Extensible Health IT

We’re updating our model RFP language to reflect the changes in the health IT landscape over the past few years, and drafted the version below for community input. Our goal is to finalize this in September – please review and post any suggestions or feedback to the SMART discussion group at https://groups.google.com/forum/#!forum/smart-on-fhir .

RFP Language for Purchasing Extensible HIT

SMART Platform (www.smarthealthit.org) is a project that lays the groundwork for a more flexible approach to sourcing health information technology tools. Like Apple and Android’s app stores, SMART creates the means for developers to create and for health systems and providers to easily deploy third-party applications in tandem with their existing electronic health record, data warehouse, or health information exchange platforms.

To deploy SMART-enabled applications, health systems must ensure that their existing health information technology infrastructure supports the SMART on FHIR API. The SMART on FHIR starter set detailed below lists the minimum requirements for supporting the API and SMART-enabled applications. You may wish to augment this list of minimum requirements with suggestions from the Add-On Functionality listed depending on the types of applications your organization wishes to deploy.

This document is intended as a resource for providers and health systems as they draft Request for Proposals (RFPs) and negotiate with their HIT vendors for added functionality. It has multiple authors from across the SMART team and its advisors. Feedback is welcome.

The vendor must support the SMART on FHIR platform, a vendor agnostic API that allows third-party developers to build external apps and services that integrate with the vended product.

At a minimum, the vendor product should include the following components in order to support SMART on FHIR and SMART-enabled applications:

Data Access

  • Provide automated, standards-based, read-only access through the FHIR API and FHIR data models (resources) to:
    • a well-defined set of real-time discrete data (including support for the API parameters and resources described in the Argonaut Implementation Guide)
    • free-text clinical notes

Data Manipulation

  • Write structured data from third-party apps back to the organization’s EHR and, where relevant, a data warehouse, using the FHIR REST API to communicate data including:
    • free-text clinical notes

Standards-Based App Authorization

  • Protect data and identity endpoints with standards-based authorization mechanisms (including the OAuth2 profiles described in the Argonaut Implementation Guide).
  • Provide access to data endpoints with an approach that does not require user intervention subsequent to the initial setup such as the method described in the draft SMART Backend Services Profile (http://docs.smarthealthit.org/authorization/backend-services/) Provide capability to restrict this access to a specified set of patients (roster).
  • Enable Health System to connect any any third‐party app of their choice that is conformant with the API without pre‐registering the app with HIT Vendor.
  • Enable patients to connect any third‐party app of their choice that is conformant with the API without pre‐registering the app with HIT Vendor through the OAuth Dynamic Registration protocol.
  • Provide OAuth refresh tokens with a duration of one year to patient and provider facing apps that support the SMART Client Secret profile.

Identity Management

  • Act as as standards-based Identity Provider using OpenID Connect. This ensures that users can authenticate to plug-in apps using single-sign-in via their existing EHR or patient portal credentials.
  • Act as a standards-based relying party to a customer-selected Identity Provider using OpenID Connect. This ensures that users can sign into the EHR or patient portal using an external, hospital-supplied single-sign-on account.

Workflow

  • Support standards-based embedding of external application UI (HTML5). This ensures that app developers can build Web apps, and these apps can run directly inside of the EHR.
  • Support the launch of external applications in the clinician’s workflow (this is not limited to the EHR, and should include non-EHR integrated tools such as smart phones and tablets). For example, a clinician that has opted to use a third-party-developed native iPad app to visualize a patient’s BMI over time can seamlessly use the application alongside the EHR via single-sign-on.
  • Support notifications to and from running applications. For example, an embedded app can notify the EHR when the user is “done” with it.

Add-On Functionality

The provider organization may also want to consider the following additions to its RFP depending on the types of applications it wishes to develop and run in the future.

Bulk Data Export

  • Provide automated access to bulk export of data (complete representation of all data in the MU Common Clinical data set as well as free text notes) using a method like the SMART Flat FHIR draft proposal (http://docs.smarthealthit.org/flat-fhir)

Data Manipulation

  • Write structured data from third-party apps back to the organization’s EHR and, where relevant, a data warehouse, using the FHIR REST API to communicate data including:
    • medication prescriptions
    • lab and diagnostic imaging orders
  • Support the dependent transactions necessary to ensure that actions completed by third-party applications using the API are valid in the EHR and data warehouse.

Context-Specific Service Hooks

  • Support the ability to call an external standards-based service in specific workflow steps, through the CDS Hooks specification, including:
    • opening a patient record
    • new prescriptions
    • new lab orders
    • new imaging studies

Intellectual Property

The IP of any app integrated through the SMART on FHIR API belongs to the author and not the vendor.

Custom SMART on FHIR Extension to a Proprietary API

Should a vendor neglect to provide SMART on FHIR natively, the client has the right to provide a custom extension to the vendor’s API. The ownership of the IP for the custom extension is negotiable between the client and the vendor, but the ownership of the app using the custom extension belongs to its author.

New Report On Connected Apps in Healthcare

In an evaluation developed in partnership with SMART and funded by the Office of the National Coordinator for Health Information Technology (ONC), KLAS Research spoke with clinical leaders at nearly 50 healthcare organizations about how they select and use clinical apps today, what they would like to see in the future, and the concerns they have around adopting apps.

Findings include:

  • Around half of the healthcare organizations interviewed use apps at the point-of-care.
  • Looking forward, many providers are interested in purchasing or developing apps around patient engagement, followed by EHR data visualization, diagnostic tools and decision support tools.
  • Usability is the most important factor healthcare organizations consider when purchasing an app, followed by cost, clinical impact and integration with existing systems.
  • Pilot programs and demos represent providers preferred way to evaluate apps, with peer recommendations, web content and video demonstrations also being popular.
  • Privacy and security is by far the biggest concern around adopting apps, although app credibility, concerns regarding ongoing maintenance, and the need for integration with existing systems are also high on the list.

The role of apps in healthcare is growing, with many organizations looking to third-party vendors to supply niche solutions that improve patient care and organizational efficiency.

Increasing adoption of the SMART and FHIR application programming interfaces (APIs) by EHR vendors and health systems is streamlining the process of connecting these apps to clinical systems, and strong regulatory support requiring APIs in certified health IT is expected to continue driving this trend. With app discovery tools, such as the SMART App Gallery, making it easier for healthcare providers to find and evaluate apps, there is a bright future for connected apps in healthcare.

View the full report, “Connected Apps in Healthcare 2017: A Look at Trends and Provider Attitudes in a Growing Market”

We’ll Be At HIMSS!

himss17-header-logo


 

  • Monday, February 20th
    • 1:00pm – 2:00pm / Quest Diagnostics Panel (room 203C)
    • 1:40pm – 2:10pm  / Introduction to SMART on FHIR at HL7 booth (#943)
    • 3:00pm – 3:30pm / SMART App Gallery 2.0 Beta Launch at Federal Health IT Pavilion (booth #230)
  • Tuesday, February 21st
    • 11:00am – 11:45am / HSPC Interoperability Showcase Demonstration (booth #9000)
    • 2:30pm – 4:30pm / Argonaut Roundtable (room 240ABC)
    • 4:20pm – 4:50pm / Introduction to SMART on FHIR at HL7 booth (#943)
  • Wednesday, February 22nd
    • 11:40am – 12:10pm / Introduction to SMART on FHIR at HL7 booth (#943)