Maintenance Notice

Due to necessary scheduled maintenance, the JMIR Publications website will be unavailable from Wednesday, July 01, 2020 at 8:00 PM to 10:00 PM EST. We apologize in advance for any inconvenience this may cause you.

Who will be affected?

Advertisement

Citing this Article

Right click to copy or hit: ctrl+c (cmd+c on mac)

Published on 11.12.20 in Vol 22, No 12 (2020): December

This paper is in the following e-collection/theme issue:

    Viewpoint

    The 21st Century Cures Act: A Competitive Apps Market and the Risk of Innovation Blocking

    1Department of Medicine, Brigham and Women's Hospital, Boston, MA, United States

    2Mass General Brigham, Boston, MA, United States

    3Harvard Medical School, Boston, MA, United States

    4Computational Health Informatics Program, Boston Children's Hospital, Boston, MA, United States

    Corresponding Author:

    Kenneth D Mandl, MD, MPH

    Computational Health Informatics Program

    Boston Children's Hospital

    300 Longwood Ave

    Landmark 5506, Mail Stop BCH3187

    Boston, MA,

    United States

    Phone: 1 6173554145

    Email: Kenneth_Mandl@harvard.edu


    ABSTRACT

    The 21st Century Cures Act and the recently published “final rule” define standardized methods for obtaining electronic copies of electronic health record (EHR) data through application programming interfaces. The rule is meant to create an ecosystem of reusable, substitutable apps that can be built once but run at any hospital system “without special effort.” Yet, despite numerous provisions around information blocking in the final rule, there is concern that the business practices that govern EHR vendors and health care organizations in the United States could still stifle innovation. We describe potential app ecosystems that may form. We caution that misaligned incentives may result in anticompetitive behavior and purposefully limited functionality. Closed proprietary ecosystems may result, limiting the value derived from interoperability. The 21st Century Cures Act and final rule are an exciting step in the direction of improved interoperability. However, realizing the vision of a truly interoperable app ecosystem is not predetermined.

    J Med Internet Res 2020;22(12):e24824

    doi:10.2196/24824

    KEYWORDS



    Introduction

    In May 2020, the Department of Health and Human Services and the Office of the National Coordinator for Health Information Technology (ONC) published a final rule implementing health information technology provisions of the 21st Century Cures Act [1]. The rule defines standardized methods for obtaining computable, electronic copies of electronic health record (EHR) data through an application programming interface (API). APIs enable granular, computable, immediate access to data and allow patients or provider organizations to connect an app directly to the EHR that exchanges data without an intermediary. The rule standardizes the Fast Healthcare Interoperability Resources (FHIR) data model and the Substitutable Medical Applications, Reusable Technologies (SMART) on FHIR standard [2,3], which specifies how users are authorized and how apps launch. The rule restricts providers and EHR vendors from “information blocking” — preventing the exchange of electronic health information.

    Intense lobbying against the rule, preceding its release, by EHR vendors and hospital systems signals that control over data and revenue are both at stake. The rule not only enables patient and provider access to medical record data in computable formats but also shifts how they interact with the health care system, which entities control those interactions, and the underlying business models that could either threaten or accelerate interoperability’s potential to improve care delivery.


    Supporting an Interoperable App Economy

    The rule is designed to foster a competitive ecosystem of substitutable (often third-party) apps that can be written once and connect to standardized health system data anywhere. The Cures Act requires an API that makes “all data elements” of a patient’s record available “without special effort” [4]. Examples of apps that leverage such an API include Apple’s Health Records on iPhone product, which enables patients to download computable copies of their medical records from hundreds of health systems [5]; a neonatal bilirubin management app that improves management [6]; and a commercially successful app, sold through multiple app stores, that dynamically generates patient-specific medication instructions [7]. Because apps access data using the SMART on FHIR API, they can be installed or deleted at any institution, independent of the underlying EHR, akin to smartphone apps. The “without special effort” clause should necessitate that the public API enable this capability without purchasing paywalled features from an EHR vendor. An interoperable apps–based economy could drive down costs, support improved public health surveillance and response [8], bring machine learning to the point of care [9], and accelerate genome-informed medicine [10,11].

    Smartphone apps are distributed through app stores. The Apple App store and Google Play store, for example, are large “one-stop shopping” markets, enable turnkey installation, and offer customer review aggregation, technical and security reviews, and payment processing. As such, they are a unique and invaluable channel to deliver technology to an end user. However, innovators are charged as much as 30% of revenue, and Apple has found itself under intense scrutiny for controlling both the platform (the iPhone) and the marketplace (the App Store) [12]. Since EHR vendors have taken a similar tack [13], the final ONC rule wisely prohibits anticompetitive behaviors, including offering different service terms to similar apps, noncompete and exclusivity clauses, and intellectual property–transfer requirements. The major EHR vendors now have app store equivalents, like the Epic App Orchard, Cerner App Gallery, or AllScripts Application Store, as do new entrant companies constructing proprietary health care app ecosystems separate from the EHR vendors.


    Risks of Misaligned Incentives and Anticompetitive Behavior

    Despite information blocking provisions, business practices could stifle innovation and reduce choice. First of all, there is an issue of pricing and fees. Under the HITECH Act, the United States has already invested US $48 billion toward the promotion of EHR adoption. Because most EHR products are based on pre-internet software, the opportunity to layer on a modern infrastructure is essential for progress. The final ONC rule does not quantify permitted API fees, but allows for recouping fees “reasonably incurred” by the EHR vendor. How costs will be passed down is unclear. Health system leaders would be right to ask how much they should be expected to pay to get their own data out of EHR products they have already purchased. Patients too have already effectively paid for their data, through insurance premiums, taxes, or directly out of pocket. The Apple and Google app stores are proven to inspire developers to produce millions of apps. It is far from clear to us that the EHR marketplaces would lead to similar much-needed innovation in health care.

    Secondly, we are concerned that EHR vendors may limit functionality and data availability across the public APIs and instead shift app connections to higher functioning proprietary APIs. The rule would permit an EHR vendor to profit from value-added services, as long as those services are not necessary for developing and deploying software that uses the API. It is extremely important that the public, regulated APIs give patients, providers, and innovators robust functionality. One issue is that the rule only requires a subset of data elements to be exposed through public APIs — the US Core Data for Interoperability (USCDI). Another is that the rule focuses on reading data from the EHR, rather than writing data back to the EHR. If the government does not expand the USCDI rapidly enough, or stalls on advancing a write capability, the proprietary APIs may outpace open, public, standardized APIs. An app written once would require a different version and set of agreements for each marketplace, analogous to a need to create a different version of a web page for every different web browser. Furthermore, EHR vendors may circumvent the spirit of the Cures Act and ONC rule by levying prohibitive revenue-sharing schemes for apps that access a modified version of the public API, charge for favorable placement in EHR-associated app stores, or limit important usability features, for example, requiring nonpreferred apps to frequently “log back in” to receive updated data. Health care organizations may be unaware of these innovation-blocking behaviors and powerless to stop them.

    Thirdly, the ONC final rule applies to certified API developers — for now, these are predominantly EHR vendors. However, the rule may not apply to emerging secondary platforms that use the public API to move data into a proprietary system with a proprietary API, for example solutions built on iOS or Android. We could end up exchanging one closed ecosystem (EHRs) for another (secondary platforms), which will further segment the market, block innovation, and limit physician and patient choice.

    Finally, assessing real-world implementation of the Cures Act will be challenging. Infractions of the “without special effort” provision could emerge through interpretations of the final rule, be hidden behind business contracts and nondisclosure agreements, or be promulgated through hesitancy to address EHR vendor business practices. Initial API usage has not been high [14,15], and much of it is attributable to Apple Health Records on iPhone alone. The good news is that the slow pace allows time to shape the unfolding ecosystem as the rule’s provisions take effect over the next 2 years. Both manual and automated processes are needed to measure key provisions of the final rule [16] and assess whether the Cures Act has produced a robust apps economy where an app written once can run widely throughout health care.


    Conclusion

    While the Cures Act and ONC final rule place guardrails around information blocking, a truly interoperable plug-and-play app ecosystem is far from predetermined. There is ample room for “innovation blocking” even by vendors who are regulatorily compliant. Measurement of progress toward an open app ecosystem and additional regulation are needed to ensure return on the massive investment in national digital infrastructure.

    Conflicts of Interest

    WG reports receiving research funding from IBM and consulting fees from the Office of the National Coordinator, Department of Health and Human Services, United States. KM chairs the scientific advisory Board for Medal, Inc. Boston Children’s Hospital receives corporate philanthropic support for KM’s laboratory from SMART Advisory Committee members, which include the American Medical Association, the BMJ Group, Eli Lilly and Company, First Databank, Google Cloud, Hospital Corporation of America, Microsoft, Optum, Premier Inc, and Quest Diagnostics.

    References

    1. Department of Health and Human Services. 21st Century Cures Act: Interoperability, Information Blocking, and the ONC Health IT Certification Program. Federal Register. 2020 May 01.   URL: https:/​/www.​federalregister.gov/​documents/​2020/​05/​01/​2020-07419/​21st-century-cures-act-interoperability-information-blocking-and-the-onc-health-it-certification [accessed 2020-11-28]
    2. Mandel JC, Kreda DA, Mandl KD, Kohane IS, Ramoni RB. SMART on FHIR: a standards-based, interoperable apps platform for electronic health records. J Am Med Inform Assoc 2016 Sep 17;23(5):899-908 [FREE Full text] [CrossRef] [Medline]
    3. Mandl KD, Mandel JC, Kohane IS. Driving Innovation in Health Systems through an Apps-Based Information Economy. Cell Syst 2015 Jul;1(1):8-13 [FREE Full text] [CrossRef] [Medline]
    4. Public Law 114 - 255 - 21st Century Cures Act. U.S. Government Information. 2016 Dec 13.   URL: https://www.govinfo.gov/app/details/PLAW-114publ255 [accessed 2020-11-30] [WebCite Cache]
    5. Gordon WJ, Bates DW, Fuchs D, Pappas J, Silacci S, Landman A. Comparing Characteristics of Patients Who Connect Their iPhones to an Electronic Health Records System Versus Patients Who Connect Without Personal Devices: Cohort Study. J Med Internet Res 2019 Aug 22;21(8):e14871 [FREE Full text] [CrossRef] [Medline]
    6. Kawamoto K, Kukhareva P, Shakib JH, Kramer H, Rodriguez S, Warner PB, et al. Association of an Electronic Health Record Add-on App for Neonatal Bilirubin Management With Physician Efficiency and Care Quality. JAMA Netw Open 2019 Nov 01;2(11):e1915343 [FREE Full text] [CrossRef] [Medline]
    7. Mandl KD, Gottlieb D, Ellis A. Beyond One-Off Integrations: A Commercial, Substitutable, Reusable, Standards-Based, Electronic Health Record-Connected App. J Med Internet Res 2019 Feb 01;21(2):e12902 [FREE Full text] [CrossRef] [Medline]
    8. Mishra NK, Duke J, Lenert L, Karki S. Public health reporting and outbreak response: synergies with evolving clinical standards for interoperability. J Am Med Inform Assoc 2020 Jul 01;27(7):1136-1138. [CrossRef] [Medline]
    9. Gruendner J, Schwachhofer T, Sippl P, Wolf N, Erpenbeck M, Gulden C, et al. KETOS: Clinical decision support and machine learning as a service – A training and deployment platform based on Docker, OMOP-CDM, and FHIR Web Services. PLoS ONE 2019 Oct 3;14(10):e0223010 [FREE Full text] [CrossRef] [Medline]
    10. Alterovitz G, Warner J, Zhang P, Chen Y, Ullman-Cullere M, Kreda D, et al. SMART on FHIR Genomics: facilitating standardized clinico-genomic apps. J Am Med Inform Assoc 2015 Nov;22(6):1173-1178. [CrossRef] [Medline]
    11. Ryu B, Shin S, Baek R, Kim J, Heo E, Kang I, et al. Clinical Genomic Sequencing Reports in Electronic Health Record Systems Based on International Standards: Implementation Study. J Med Internet Res 2020 Aug 10;22(8):e15040 [FREE Full text] [CrossRef] [Medline]
    12. Antitrust: Commission opens investigations into Apple's App Store rules. European Commission. 2020 Jun 16.   URL: https://ec.europa.eu/commission/presscorner/detail/en/ip_20_1073 [accessed 2020-11-28]
    13. Allen A. Developers complain of high EHR fees for SMART apps. Politico. 2018 Aug 06.   URL: https://www.politico.com/story/2019/09/23/developers-ehr-fees-smart-apps-721486 [accessed 2020-11-28]
    14. Adler-Milstein J, Longhurst C. Assessment of Patient Use of a New Approach to Access Health Record Data Among 12 US Health Systems. JAMA Netw Open 2019 Aug 02;2(8):e199544 [FREE Full text] [CrossRef] [Medline]
    15. Gordon WJ, Patel V, Thornhill W, Bates DW, Landman A. Characteristics of Patients Using Patient-Facing Application Programming Interface Technology at a US Health Care System. JAMA Netw Open 2020 Oct 01;3(10):e2022408 [FREE Full text] [CrossRef] [Medline]
    16. Savage M, Neinstein A, Adler-Milstein J. Measure The Impact Of The ONC's New Interoperability Rules Now. Health Affairs Blog. 2020 Jul 20.   URL: https://www.healthaffairs.org/do/10.1377/hblog20200701.58142/full/ [accessed 2020-11-28]


    Abbreviations

    API: application programming interface
    EHR: electronic health record
    FHIR: Fast Healthcare Interoperability Resource
    ONC: Office of the National Coordinator for Health Information Technology
    SMART: Substitutable Medical Applications, Reusable Technologies
    USCDI: US Core Data for Interoperability


    Edited by G Eysenbach; submitted 07.10.20; peer-reviewed by N Sharma, J Lee; comments to author 28.10.20; revised version received 01.11.20; accepted 09.11.20; published 11.12.20

    ©William J Gordon, Kenneth D Mandl. Originally published in the Journal of Medical Internet Research (http://www.jmir.org), 11.12.2020.

    This is an open-access article distributed under the terms of the Creative Commons Attribution License (https://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work, first published in the Journal of Medical Internet Research, is properly cited. The complete bibliographic information, a link to the original publication on http://www.jmir.org/, as well as this copyright and license information must be included.