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.
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
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
For our final
version we have integrated several insightful edits and suggestions from the
Thank you for
engaging with us on this.
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.
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
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
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 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?
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:
- 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
- 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
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,
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.