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.
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 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 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 process.
- Exposed end-to-end through an API, rather than being implemented exclusively as a button hidden deep within a patient portal experience, or being crippled by the exchange of physical media like CD-ROMs. This is critical because:
- Portal experiences vary, making features difficult to find and correctly describe (e.g., if a third party is trying to guide patients toward the export functionality in a variety of portals). This was a clear challenge for anyone trying to identify the “Transmit to a third party” features of a patient portal in the MU2 timeframe.
- Managing physical media, e.g., CDs, would take access outside the realm of modern, convenient consumer experiences, and would violate the without special effort requirement.
- Managing files may be challenging on many patient devices (e.g., mobile phones), and some files may be best suited for off-device storage (e.g., in the cloud).
Our key recommendation on EHI Export is that ONC should require certified EHRs to support full EHI export at the patient level via patient-accessible API, and at the population level via data-provider-accessible API, even without standardizing the API or the data payloads. This will meet the Cures intent for API access.
API connectivity will provide patients with a seamless experience for accessing all of their health data, not just a core data set, and will ensure that healthcare providers can connect apps to data that is not currently available through the USCDI dataset. Providing access through open APIs, even for data that are not structured in open formats, will further this goal.
We have heard concerns about the overall scope of EHI access in a variety of exceptional circumstances (e.g., for data not stored in the EHR itself, or for data that represent purely internal system implementation details). As a baseline, we recommend that the data to be included in EHI Export should encompass the complete set of information that an EHR vendor currently makes available through their widely adopted data warehouse products, through their user interfaces, or through their reporting infrastructure.
SMART on FHIR. The Rule should Specify which SMART on FHIR capabilities an API provider will need to support, at a minimum. The Proposed Rule requires mandatory support for “refresh tokens,” “Standalone Launch,” and “EHR Launch” requirements. However, to ensure consistent implementation the Rule should also specify mandatory support for the following ten SMART capabilities: sso-openid-connect, launch-standalone, launch-ehr, client-public, client-confidential-symmetric, context-ehr-patient, context-standalone-patient, permission-patient, permission-user, permission-offline.
USCDI. The USCDI is a strong successor to the Common Clinical Dataset. To cover an expanded set of app use cases, we recommend the addition of data elements that cover clinical encounters and clinical imaging metadata.
In addition to considering data elements for read API access, ONC should look ahead to a future-state USCDI definition that includes some write API requirements, as well. Each element of the USCDI should include a list of required operations; today, these would all be “read access,” but this would provide a clear placeholder for future expansion of functionality (rather than just a list of data elements).
FHIR R4. The need to support multiple versions of standards can hinder interoperability. ONC should adopt FHIR R4 as the only allowed version for standard API access moving forward, with an advancement process as described in the Proposed Rule.
Backend Services Access. To ensure that API Data Providers have the flexibility to innovate on top of the APIs provided by API Technology Suppliers, ONC should introduce a condition of certification ensuring that API Data Providers can obtain automated system-level access to all API calls from the API servers offered by API Technology Suppliers (e.g., via the SMART Backend Services authorization guide), with “system/*.*” scopes. This condition would enable API Data Providers to create additional services (e.g., API proxy or gateway functionality) on top of the APIs offered by API Technology Suppliers — an important “escape valve” for introducing new functionality or policies on top of existing data services.
Token Introspection. Again, to ensure that API Data Providers have the flexibility to innovate on top of the APIs provided by API Technology Suppliers, ONC should introduce a condition of certification ensuring that API Data Providers can perform token introspection using services enabled by API Technology Suppliers. This will ensure that additional resource servers (e.g., PACS systems that might expose FHIR imaging resources) can work with the same access tokens and authorization policies as the resource servers built directly by API Technology Suppliers.
ARCH. The ONC proposes the “API Resource Collection in Health” (ARCH) Version 1 implementation specification in § 170.215(a)(2), which would list a set of base FHIR resources that Health IT Modules certified to the proposed API criterion (§ 170.315(g)(10)) would need to support. While we see value in providing a catalog, we strongly recommend that ONC populate it using community-developed standards by groups like Argonaut and HL7, who can take functional requirements from USCDI versions, and produce Implementation guides. If ONC maintains an ARCH definition, this definition should be limited to referencing implementation guidance from community-developed processes; ONC should not “get out ahead” of the community process. For example, the ARCH should not make unilateral determinations about which FHIR resource or data elements are needed to meet a given USCDI requirement. Instead, that determination should be made through a community-driven, iterative process with real world testing of use cases.
Immature Standards. The vast majority of referenced standards in the Rule are mature, in real world use, and widely embraced by the community. Two standards, however, strike us as “not ready for prime time:” Data segmentation for privacy (DS4P) and Consent2Share. While we recognize privacy maintenance and consenting as essential functions in health care, we are very concerned that a premature push for adoption of these immature standards would have unintended negative effects. ONC should omit these from the certification criteria (including voluntary certification) and focus on driving real-world implementation experience before pursuing regulations.
3. Move Beyond EHR Data
Clinical Imaging. We are concerned that sharing of images, an essential data type for patient care, may slip through the cracks. EHR systems often contain metadata around the available imaging studies, however, the imaging studies themselves are frequently stored in separate systems known as picture archiving and communication system (PACS). Providers should be responsible for sharing this imaging data, regardless of the technology supplier they choose. We recommend making PACS vendors subject to EHR certification rules, specifically for API access requirements.
Laboratory Data. While some clinical laboratory result data are accessible to patients through EHR APIs, historical data may not be comprehensive. Recently, national laboratory companies have begun to make these data available through API access for select apps. To promote a robust ecosystem of clinical applications, guidance should be provided on how this access should be expanded to an open ecosystem of apps to comply with the information blocking restrictions in the Rule.