Category: Blog

This response from the SMART Health IT team (www.smarthealthit.org) at the Boston Children’s Hospital Computational Health Informatics Program, offers integrated technology and policy recommendations designed to realize a tangible vision of a learning health system accessible to every American. Our approach shifts the regulatory focus from overseeing isolated system capabilities to ensuring robust, standardized, and functional data connections that directly support truly meaningful use in real-world healthcare settings.

Ken Mandl, MD, MPH Boston Children’s Hospital
Josh Mandel, MD Microsoft*
Dan Gottlieb, MPA Central Square Solutions

*Special recognition to Josh Mandel for leadership assembling the detailed comments.

View the full version with our detailed comments included

Executive Summary

We face an unprecedented opportunity to reshape healthcare into a truly interconnected, intelligent, and patient-centered system. We applaud CMS and ASTP for championing this vision—driving the adoption of meaningful health technology, removing persistent barriers to data access, and empowering patients, providers, and innovators alike.

Despite widespread EHR adoption across the U.S. healthcare system, competing proprietary platforms have failed to create the intended free-market conditions necessary for innovation. Instead, the health IT market has become distorted, characterized by a shrinking number of dominant, centrally controlled platforms that stifle competition, restrict critical clinical data within proprietary silos [1], and leverage client dependency (“stickiness”) to prevent vendor switching. These dominant platforms increasingly seek further control by managing artificial intelligence applications and payer relationships, systematically discouraging investments in interoperability due to misaligned incentives. Consequently, AI developers, pharmaceutical companies, and researchers remain unable to reliably access essential clinical data, while major health systems treat data as competitive assets rather than promoting open interoperability—posing risks to innovation, patient choice, and a genuinely open healthcare ecosystem.

Incumbent vendors have also influenced EHR certification requirements and standards-setting processes, raising barriers to market entry and suppressing competition from innovative newcomers. Such structural market failures ensure that, absent government intervention, interoperability advances slowly or regresses into proprietary ecosystems. This inefficiency directly raises the cost of care, ultimately impacting taxpayers, as CMS pays for unnecessary tests and avoidable medical complications resulting from poor data exchange.

Federally funded interoperability R&D has proven essential, breaking vendor lock-in, creating genuine market competition, and enabling unprecedented patient access to electronic health information [2]. Without these government-supported investments, data accessibility and open system interfaces would remain severely limited. In the current era of AI, health systems, clinicians, and innovators urgently require interoperable, universal, standardized, and low-cost access to both structured and unstructured EHR data [3]. LLMs dramatically enhance clinical value by efficiently unlocking insights previously accessible only through manual review of clinical notes [4,5]. FHIR APIs are particularly well-suited to this AI-driven landscape, providing simple, standardized, programmatic access to structured data and clinical notes—accessible to individual patients and clinicians, as well as IT teams at the population level—enabling efficient data extraction by LLMs to power transformative healthcare innovation [6].

Deregulatory, administrative simplification – system to system interfaces. Building a robust digital learning ecosystem in healthcare depends on reproducible, modular, and thoroughly tested components. EHRs should evolve from isolated, monolithic systems into flexible modules within a dynamic, data-driven environment. For optimal care and analytics, health information at both the individual and population levels must flow efficiently, securely, and with proper authorization across diverse IT platforms.

A key driver of this evolution is the standardized application programming interface (API), a modern technology widely adopted across the tech sector to enable reliable and consistent data exchange between computer systems. APIs notably drove the success of the iPhone starting in 2008, empowering millions of third-party apps by providing developers standardized, well-documented access to device features such as GPS, contacts, and sensors, without the need for direct negotiation with Apple.

In healthcare, the HITECH Act was a pivotal milestone, investing $48 billion to accelerate EHR adoption. Within this context, our team introduced the concept of a public healthcare API [7] designed to standardize access to electronic health information across diverse EHR platforms. We led development of the SMART on FHIR API [8,9], which allows web and mobile applications (including those for iOS and Android) to uniformly and securely retrieve and interact with clinical data formatted as FHIR. Federal support and bipartisan legislative backing through the 21st Century Cures Act encouraged broad adoption of SMART, fueling a robust ecosystem of both open-source and commercial products [10]. Real-world deployments demonstrated practical viability and wide-ranging utility, ultimately informing the federal regulatory requirement that, as of the end of 2022, all certified EHRs must support standardized FHIR APIs [11].

Today, every certified EHR in the U.S. must support two public APIs developed by our team. The SMART on FHIR API securely provides patient-level data access for web and mobile apps. The HL7 Bulk FHIR Access API [12] enables organizational-level data access for large patient cohorts, essential for population health management, research, and artificial intelligence applications. Both APIs afford access to a defined set of more than 100 standardized data elements (the US Core Data for Interoperability, USCDI), including structured data formatted in FHIR and the narrative clinical text of notes. Versions of these APIs also facilitate standardized retrieval of Medicare coverage information, explanation-of-benefits, and CMS claims data in FHIR format.

Unleashing Prosperity Through Deregulation of the Medicare Program. CMS should consider shifting certification requirements away from specific EHR functionalities and instead focus on certifying standardized APIs themselves. By emphasizing the certification of APIs rather than individual EHR features, CMS can simplify regulatory processes and help foster a market-oriented, interoperable ecosystem. Simpler certifications will also reduce perverse barriers to new entrants. The EHR Association (EHRA) recently proposed eliminating the requirement to support Bulk FHIR. Their proposal is precisely the wrong direction. Weakening or removing Bulk FHIR creates critical gaps in interoperability, undermines large-scale population health management and analytics, and effectively rewards vendor inaction—stalling progress toward truly patient-centric, data-driven healthcare.The EHRA proposal is transparently self-serving, reflecting vendors’ reluctance to allow data to leave their proprietary systems [13]. Such resistance to open data exchange hampers America’s competitiveness in healthcare innovation, including in the rapidly evolving field of healthcare AI—a matter of national security.

Patient control of and access to their own health data. For too long, the patient’s experience in managing their healthcare journey has been one of fragmentation. A patient today may have records scattered across a dozen different provider portals, each with its own login and password. Simply creating these accounts can require an in-person visit, a significant hurdle for many. To address this, we must simplify and secure the very first step of digital engagement. 

The SMART on FHIR approach creates critical infrastructure that enables individuals to exercise their right to obtain their health information. It allows consumers to connect healthcare apps—such as the Apple Health app—directly to their electronic medical records, giving patients straightforward access to their own clinical data [2]. By supporting direct data transfers, patients can now effortlessly retrieve and manage their information in a standardized, machine-readable form. This ensures timely availability and easy sharing with healthcare tools (including AI-driven apps leveraging large language models), healthcare providers, family, and caregivers. Importantly, by enabling patient-driven data integration [14–16], SMART on FHIR helps patients consolidate information from multiple providers into a coherent, unified record.

By championing a fully remote account provisioning and single sign-on requirement for patient portals, underpinned by secure, remote identity verification, we can reduce login friction and provide patients a single, trusted key to their digital health journey. Increased enforcement of the existing ONC requirement for patients to be in control of how long an app can access their data (including the ability to enable access until it is explicitly revoked) will remove the need for patients to enter their login information repeatedly. Yet, logging in is only the first step. Once inside, patients often find only a small fraction of their information.True empowerment comes from having the complete picture. Imagine a patient, newly diagnosed with a complex condition, trying to get a second opinion from a doctor or AI tool. They shouldn’t have to spend weeks making phone calls and tracking down faxes. 

Since the end of 2023, the 21st Century Cures Act Rule has required that patients can request a complete copy of their EHR data–not just the elements of the USCDI. We strongly urge that patients should be able to achieve this by making a single, modern, digital request from an app of their choice and receive their full Electronic Health Information (EHI) via a standardized API. This must include everything: the structured data, the narrative text from physician notes, and critically, their diagnostic-quality medical images. To ensure accurate use, the data should be available in FHIR format for elements defined in USCDI and in well documented, vendor specific formats for the remainder of the record. To accommodate human and AI use, a patient’s complete record in PDF format should also flow through the API and not require a separate manual records request. This single change would be revolutionary, giving patients and their chosen applications the comprehensive data needed for genuine health management. A FHIR implementation guide for EHI export was defined by the Argonaut FHIR accelerator in 2022 [17] and an ASTP/ONC-funded prototype was developed by the SMART Health IT team the following year [18]. Of note, rather than supporting patient autonomy and celebrating patient access to their own data, the EHRA also, disappointingly, but perhaps not surprisingly, opposes the Cures Act individual right of access to full EHI. This is not the first time the EHR industry has attempted to block patient right of access [19].

Substitutable apps for patients and clinicians. Once a patient has their data, they must be able to act on it. An engaged patient will have questions. We can make digital health tools indispensable by allowing patients to communicate directly through them. By enabling open messaging APIs, a patient could highlight a confusing lab result or a documentation error in an application and send a secure message to their provider’s office from that same screen. This transforms applications from passive data viewers into active communication hubs, fostering the very engagement CMS seeks to encourage.

When Apple integrated SMART on FHIR into its Health app, enabling consumers to securely download their medical records, it created a powerful demand signal prompting healthcare providers to broadly implement FHIR endpoints. Importantly, these endpoints were not just available to Apple but became openly accessible to any subsequent app following the same standard. Indeed, the “S” in SMART stands for substitutable, highlighting that apps built on SMART APIs must be interchangeable. If HHS creates new demand signals by commissioning new apps to drive similar demand for SMART on FHIR or Bulk FHIR APIs, then ensuring substitutability will be essential to creating an open and competitive ecosystem.

SMART on FHIR fully supports clinician-facing apps embedded directly within EHR workflows. This capability seamlessly connects EHRs to the broader web ecosystem, enabling turnkey integration of external software and services directly into patient care contexts [20–22].

Population data accessibility and exchange. Historically, extracting and analyzing population data for mission-critical tasks—e.g., public health monitoring, registry creation, quality reporting, comparative effectiveness research, and surveillance of drugs and devices—has been costly, complex, and has required specialized expertise to handle non-standard formats and difficult access. Fortunately, the 21st Century Cures Act is crystal clear; All elements of a patient’s record must be accessible across an API “without special effort.”

The FHIR Bulk Data Access standard, required in all certified health IT by the Cures Act Rule, promises “push button” retrieval of large datasets, including notes, in a standardized format. Because these datasets already conform to the FHIR standard, institutions can seamlessly share information without additional data transformation, facilitating simultaneous solutions across clinical care, payment models, research, and public health activities.

Standardized Bulk FHIR access eliminates complexity and expense when implementing broad-ranging digital health use cases [23]. This scalable solution democratizes participation, enabling not only advanced health systems but also smaller or resource-limited providers to meaningfully engage in population-level projects. In contrast to conventional methods that rely on translating data into common research-centric models—which impose significant costs, risk losing valuable clinical context, and introduce semantic distortion—Bulk FHIR preserves data in its original clinical representation. By adopting FHIR directly as the data model, clinical applications and analytic tools can immediately access standardized data elements representing real-world care processes, allowing reliable execution across diverse healthcare environments. This consistency ensures scalable deployment, rapid adoption, and immediate integration within workflows that directly improve patient care. Additionally, applications and analytic tools designed once against this standard can reliably execute across disparate healthcare environments, enabling consistent, scalable deployment and accelerating real-world adoption.

However, disappointingly, even today, more than two years since the Cures Act Rule requirements went into effect, many current EHR Bulk Data implementations demonstrate “checkbox compliance,” technically meeting regulatory requirements without delivering meaningful performance or a satisfactory user experience. This uncovers a flaw in the EHR certification process which does not guarantee meaningful functionality, only adherence to a limited technical specification. We worked with a consortium of healthcare leaders to assess performance across multiple vendor implementations [24]. The key insight from this regulatory science is that current EHR vendor Bulk FHIR implementations remain inadequate. Indeed, it is widely recognized that the largest vendor has chosen not to invest in building a performant Bulk FHIR interface, instead providing a substandard implementation that has been used as an excuse to actively discourage customers from adopting public APIs.

Contrast these poor implementations with the work of a high performing informatics team at Regenstrief Institute that under federally funded R&D solved the problem in a matter of weeks. The Regenstrief Institute implementation leveraged existing code mapping to US Core FHIR profiles and required only a few weeks [6] to add new FHIR mappings and a Bulk FHIR interface. Its efficient database design resulted in exports that substantially outperformed certified Bulk FHIR interfaces from Epic and Oracle Cerner.

By underinvesting in standardized data formats, EHR vendors shift data mapping costs onto customers—an inefficiency that slows innovation, and prevents the use of these interfaces in provider to payer data exchange for initiatives such as quality measurement and mandated reporting. ONC has an important role in accountability. We propose an export performance parity requirement to better align the capabilities of regulated bulk data interfaces with those of non-regulated, proprietary bulk data interfaces such as CSV exports from a data warehouse. Additionally, as CMS reporting requirements look to take advantage of Bulk FHIR interfaces, CMS can require that healthcare institutions and their vendors meet service level agreements for Bulk Export, mandating export of USCDI data on the entire population at a health system within 24 hours.

Our team recently launched Good Neighbor [25], a community site where EHR users can share experiences [26], tips, and strategies for setting up FHIR Bulk Data interfaces and leveraging them in real-world use cases. Our joint effort also aims to quantify real-world performance and help EHR vendors understand where their systems are succeeding—and where additional investment is needed to better support patients, clinicians and innovators. On the Good Neighbor website, we have made available Bulk FHIR performance tools and our ONC/ASTP-funded Cumulus Q tool for assessing USCDI quality in bulk FHIR exports [27].

Opportunities for CMS. Concatenating claims data, which comprehensively document patient interactions across various healthcare settings, with EHR data, which contain richer clinical detail such as structured lab results, clinical notes, and diagnostic insights, produces an exceptionally valuable dataset. Claims alone do not provide sufficient clinical granularity or standardized detail available from EHRs, whereas EHRs alone fail to capture healthcare services delivered at external institutions. Having both claims and EHR data in a unified FHIR format enables system-wide analytics directly on standardized data at all sites of care, substantially enhancing capabilities for value-based care, AI model accuracy, and continuous improvement across the healthcare ecosystem.

To advance interoperability in healthcare, CMS can leverage several key strategies. To complement ONC requirements, CMS could mandate the use of Bulk FHIR from EHRs in a wide variety of real world programs. This could create a strong incentive for EHR vendors to invest in performant interfaces. Encouraging the use of FHIR APIs across both clinical and payer claims data will help drive the development of cohesive digital infrastructures. CMS can also mandate the use of regulated EHR interoperability for critical healthcare transactions, such as prior authorization, value-based care reporting, and claims submission. We are particularly pleased by the recent announcement that CMS’s Data at the Point of Care (DPC) API initiative will advance beyond pilot status to full-scale national deployment. There is an opportunity for private payers as well. The successful real-world implementation and rigorous testing of DPC provides an exceptionally robust functional specification and elements like attributing subscribers and exporting claims through a bulk interface should directly inform a comprehensive implementation guide for private payers. While the DaVinci Project specifications represent industry collaboration, DPC’s demonstrated effectiveness, reliability, and scalability in real-world settings uniquely positions it as a foundational reference for the private sector. 

If CMS places a strong demand signal on the Bulk FHIR API—comparable to Apple’s impact on the SMART on FHIR API—and simultaneously doubles down on widespread availability and use of the CMS payer-data APIs, the resulting downstream effects would be transformative. This would enable unprecedented population-level access to structured data and clinical notes, directly benefiting AI developers, pharmaceutical companies, regulatory agencies conducting postmarket surveillance or evaluating real-world evidence for expanded indications of regulated products, researchers, and public health organizations engaged in biosurveillance.

This seamless flow of information is just as critical for providers operating in a value-based world. They need the ability to understand and manage the health of their entire patient population, a task that requires robust, efficient data export capabilities. Mandating performant bulk FHIR export with support for incremental data requests would allow providers to receive timely updates on their patient panels that can power clinical apps, data exchange with payers, analytics, research studies and other uses without wrestling with proprietary data access approaches and formats. To rapidly achieve success, CMS should work with ASTP/ONC to pair these requirements with new functional requirements including API-driven tools to create patient groups, allowing for the targeted analysis essential for population health and quality measurement. Furthermore, by adopting FHIR subscriptions for data changes, we can support an event-driven model where a provider is automatically notified when a patient is discharged from the hospital enabling proactive and timely follow-up care.

TEFCA as a complementary component of nationwide exchange. While TEFCA holds promise as part of the broader interoperability solution, it is primarily designed for single-patient data exchange within clinical care contexts. Currently, TEFCA lacks essential capabilities required for large-scale research data transfers, population-level analytics, AI model development, and public-health research. However, the robust, scalable data-exchange technologies emerging from federally funded interoperability R&D—particularly the Bulk FHIR API—can ultimately be integrated into TEFCA’s trust networks, significantly enhancing its capabilities. Universal support for Bulk FHIR would provide TEFCA with a standardized, efficient pathway for large-scale, high-fidelity data exchange, eliminating costly, ad-hoc interfaces.

For TEFCA to succeed as a nationwide framework, it must build public trust by offering individuals meaningful control over their data. Patients have legitimate concerns about broad data sharing; therefore, TEFCA must incorporate intuitive patient controls  [28] such as a simple data “freeze”,an “ask-me-first” option for sensitive queries, and a clear, accessible audit trail to show precisely who has accessed their information. Continued federal investment in interoperability standards alongside TEFCA ensures the optimal combination – effective single-patient data sharing coupled with secure, efficient, population-level data availability to support research, analytics, AI-driven innovation, and public-health analysis.

Technical summary. By weaving open ‘Lego block’ capabilities together—simple account provisioning and sign-on, complete EHI access, integrated messaging, powerful bulk data tools, subscription capabilities, and trustworthy exchange—we create a virtuous cycle. An empowered patient is more engaged, providing better information that fuels a more responsive and efficient system for providers. Adopting these foundational technology policies will not be an incremental improvement; it will be the catalyst that builds the patient-centric, learning health system we all envision.

The role of federal funding – consider how the Internet itself was born. When ARPA funded university teams to create ARPANET in 1969, it was not replacing the FCC – it was doing what a regulator could not – placing high-risk, high-reward bets on unproven technologies. That gamble birthed the open protocols (TCP/IP) that industry later adopted and the FCC eventually incorporated into policy. Healthcare now faces an analogous moment in which

• ASTP/ONC is the rule-setter, excelling in certification, consensus standards, and enforcement after technologies have been proven. While ONC maintains a modest budget for prototyping new technologies, it currently lacks budget and scope necessary for large-scale R&D.
• Federal funding, through agencies logically suited to this role – such as ARPA-H, NIH and others—can provide the risk capital needed for moonshot R&D to address complex, unsolved problems such as real-time, privacy-preserving population-level queries and next-generation FHIR-based architectures.

Over the past decade and a half, modest federal research investments in healthcare interoperability have consistently produced transformative infrastructure adopted by hospitals, insurers, and technology companies nationwide — creating precisely the open, competitive conditions in which free markets can thrive. Federal R&D has repeatedly catalyzed marketplace competition, allowing industry stakeholders to rapidly adopt, innovate upon, and differentiate around openly available standards rather than proprietary, fragmented solutions. CMS stands to reap significant rewards from these investments. 

Specifically, federal funding can

• prototype and rigorously stress-test innovative architectures by engaging academic and industry labs, creating broad coalitions among research institutions, technology firms, and healthcare providers.
• de-risk complex technologies such as secure multiparty computation and federated AI training, enabling rapid commercialization by industry.
• ​​establish vendor‑neutral, large‑scale testbeds that exercise complete interoperability stacks under real‑world workloads—free from commercial bias—to refine component interplay and yield reference architectures optimized for performance, security, and usability.
• upon maturity, offer proven technologies to ONC for national certification and policy integration, mirroring the successful “prototype first, standardize and enforce second” approach that turned ARPANET into today’s Internet, and that scaled SMART on FHIR to nation-wide use.

Standards with well-defined specifications and existing implementations can be adopted directly. The development of less mature specifications can be catalyzed by an indication that they will be adopted by CMS, encouraging the industry to focus on their maturation. When coupled with direct funding for reference implementations and software libraries, both the standards development process and industry adoption can be dramatically accelerated.

Development of the SMART on FHIR API was supported by R&D funding from the ONC [29], and led by the SMART Health IT team (www.smarthealthit.org). The team created an open, liberally licensed, royalty-free API specification, tested it in real-world hospital environments, and refined it collaboratively by helping stand up the first industry FHIR accelerator, the Argonaut Project [30]. Today, SMART on FHIR is the universal interface behind patient-facing apps from Apple, Google, and hundreds of startups, connecting patients seamlessly to thousands of hospitals. Without this open standard, companies like Apple simply wouldn’t have been able to establish connectivity into the full spectrum of Health IT systems. Instead, SMART on FHIR raised the baseline for healthcare interoperability—a rising tide that lifts all boats.

Bulk FHIR was similarly jump-started by targeted ONC R&D investment during the first Trump administration, supporting early development and real-world testing. Within a year, CMS had moved Bulk FHIR into production pilots, enabling rapid, secure transfer of population-level clinical datasets. These pilots empowered providers, payers, and analytics firms to exchange comprehensive health information in minutes, replacing processes that previously took weeks—thus significantly enhancing quality measurement, public health surveillance, and artificial intelligence development. Subsequent funding by ONC, CDC, and ARPA-H has proven essential to ecosystem development because interoperability standards require continual iteration between real-world use and evolving regulatory and technical frameworks. Ongoing practical deployment—including integration with cutting-edge language models and AI techniques—provides vital feedback into standards development, regulatory guidelines, and performance measurement strategies. Critically, these federally funded efforts have generated broadly applicable, open tools for assessing performance, data quality, and compliance—generalized resources that simply would not have emerged without public-sector investment. This iterative cycle, uniquely enabled by government-supported R&D, is the foundation for a continually improving, widely adopted healthcare data ecosystem

Critically, these federally funded efforts have generated broadly applicable, open tools for assessing performance, data quality, and compliance—generalized resources that simply would not have emerged without public-sector investment. For example, the open-source and freely available CumulusQ tooling for evaluating Bulk FHIR data quality and performance would have been highly unlikely to emerge in a purely commercial environment, where proprietary approaches restrict the evolution and use of data quality tools. Similarly, the SMART on FHIR API, developed through government funding and released openly under the Apache 2 license, intentionally avoided embedding any proprietary business model. This decision enabled a vibrant ecosystem supporting diverse commercial approaches without vendor lock-in. Proprietary, for-profit imitators never achieved comparable adoption or impact, precisely because Argonaut Project participants deliberately chose the openly available SMART on FHIR standard over vendor-dependent alternatives, avoiding restrictive licensing and potential lock-in. This iterative cycle, uniquely enabled by government-supported R&D, establishes the foundation for a continually improving, widely adopted healthcare data ecosystem.

In short, ONC maintains the alignment of standards; federally funded innovation lays the essential new rails. Applying this ARPANET playbook to healthcare is the swiftest path to an open, AI-ready, and patient-empowering health-data ecosystem.

Openness is key. Open specifications that can be easily accessed by innovators create positive disruption in healthcare rather than serving as barriers put up by incumbents. Witness the explosion of HealthIT startups building on FHIR, many of them new entrants to the healthcare marketplace. Across many industries, specifications created in isolation have proven cumbersome and costly to implement, while those developed alongside prototypes or reference implementations more directly and effectively address user needs. Open-source software libraries simplify the creation of standards-compliant systems, preventing industry from repeatedly incurring unnecessary costs building out routine, non-innovative infrastructure components. Crucially, these open-source tools also empower innovators and tinkerers to prototype new ideas quickly and inexpensively, a key ingredient for generating the next generation of healthcare solutions. Indeed, without open-source software like Linux, it’s possible transformative companies such as Google and Amazon would never have emerged.

The history of FHIR APIs and the SMART Team role. A Wall Street Journal editorial commented on our 2009 introduction of the idea of a public EHR API in 2009 [7]. The editorial noted that healthcare interoperability thrives best in an open, competitive marketplace driven by free markets, “allowing competition and ‘natural selection’ for high-value, low-cost products.” This approach sharply contrasts with traditional, top-down, committee-based designs, which often stifle innovation through cumbersome processes and entrenched interests. 

Our foundational work under the HITECH Act/ONC SHARP [9,29] program in 2010 led to the widely-adopted SMART on FHIR API. This illustrates how Federal R&D funding serves precisely as the catalyst that enables these open platforms to emerge, empowering market-driven competition and rapidly delivering impactful innovation. Our team has extensive expertise and a long history of innovation in API development, healthcare applications, FHIR standards, federated networks, and healthcare reporting requirements. 

Working with a bipartisan Congressional coalition, we (KDM) influenced the drafting of the 21st Century Cures Act, establishing the requirement that all certified health IT include APIs capable of providing access to all elements of a patient’s electronic health record “without special effort.”

In 2017, at the request of the National Coordinator, we convened key stakeholders to design a population-health analog to SMART on FHIR, resulting in a mandate for the Bulk FHIR API. With continued ONC support, we also developed the SMART App Gallery and sandbox, a widely utilized public platform supporting developers from major technology firms including Apple, Microsoft, and Google. Our team subsequently designed and deployed the Bulk FHIR API and associated software, including a bulk data reference server and client tools. Within months of the initial draft API release, CMS adopted Bulk FHIR to share claims data with Accountable Care Organizations. With funding from the ONC Leading Edge Acceleration Projects (LEAP) program, we designed and tested SMART-PopHealth in 2018, a substitutable population-health analytics app enabling payers to directly access permitted EHR and claims data—including derivative metrics—for covered populations via the API. The successful real-world testing of this artifact within an ACO provided some of the necessary evidence of practical, real-world use to support inclusion of the Bulk FHIR requirement in the 21st Century Cures Act Final Rule.

Further advancing adoption, we hosted another meeting on behalf of ONC in November 2019, bringing together EHR vendors, cloud providers, and federal agencies such as CDC, FDA, NIH, and CMS, to explore and support diverse research and public health use cases. We played a central role in launching and sustaining the Argonaut FHIR Accelerator, collaborating broadly to establish SMART and Bulk FHIR as ANSI-accredited standards incorporated into the ONC Cures Rule. Recognizing the critical role of real-world testing, we convened the 2022 SMART Multisolving Conference, engaging a diverse group of stakeholders including CMS, FDA, NIH, CDC, and industry to advance practical use cases. Additionally, our team led CDC-funded listening sessions [31] exploring public health applications of standardized APIs and initiated federally funded real-world testing of Bulk FHIR and supporting new software components at scale through the CDC Data Modernization Initiative. Real-world testing complements standards development by validating the practical application and guiding the refinement and enforcement of standards. In collaboration with agencies like ARPA-H, these efforts can foster the high-risk, high-reward innovation necessary to build robust digital infrastructure for healthcare.

Federally funded R&D by the SMART Health IT team has not occurred in a vacuum. The team has served as a critical convening force, actively bringing together industry leaders who have enthusiastically engaged, collaborated, and directly benefited from these efforts [32]. The world’s largest technology companies, health systems, and payors—including Google, Apple, Microsoft, Quest Diagnostics, Eli Lilly, Humana, Optum, Blue Cross Blue Shield Association , HCA Healthcare, and Providence Health and Systems—have consistently relied on the SMART Health IT team’s strategic and technical leadership. This public-private synergy has accelerated interoperability adoption, reinforced industry consensus, and translated early-stage government investment into widespread, real-world healthcare innovation.

View the full version with our detailed comments included

Bibliography

1. Mandl KD, Kohane IS. Escaping the EHR trap–the future of health IT. N Engl J Med New England Journal of Medicine (NEJM/MMS); 2012 Jun 14;366(24):2240–2242. PMID: 22693995

2. Mandl K. Apple will Finally Replace the Fax Machine in Health Care. CNBC 2018 Jan 30; Available from: https://www.cnbc.com/2018/01/30/apple-will-finally-replace-the-fax-machine-in-health-care-commentary.html [accessed Nov 11, 2020]

3. Mandl KD, Gottlieb D, Mandel JC. Integration of AI in healthcare requires an interoperable digital data ecosystem. Nat Med Nature Publishing Group; 2024 Jan 30;1–4.

4. McMurry A, Zipursky AR, Geva A, Olson KL, Jones J, Ignatov V, Miller T, Mandl KD. Moving biosurveillance beyond coded data: AI for symptom detection from physician notes. bioRxiv. 2023. doi: 10.1101/2023.09.24.23295960

5. McMurry AJ, Phelan D, Dixon BE, Geva A, Gottlieb D, Jones JR, Terry M, Taylor D, Callaway HG, Mahoharan S, Miller T, Mandl KD. Large Language Model Symptom Identification from Clinical Text: A Multi-Center Study. Health Economics. medRxiv; 2024. Available from: https://www.medrxiv.org/content/10.1101/2024.12.16.24319044v1

6. McMurry AJ, Gottlieb D, Miller TA, Jones JR, Atreja A, Crago J, Desai PM, Dixon BE, Garber M, Ignatov V, Kirchner LA, Payne PRO, Saldanha AJ, Shankar PRV, Solad YV, Sprouse EA, Terry M, Wilcox AB, Mandl KD. Cumulus: a federated electronic health record-based learning system powered by Fast Healthcare Interoperability Resources and artificial intelligence. J Am Med Inform Assoc 2024 Jun 11; PMID: 38860521

7. Mandl KD, Kohane IS. No Small Change for the Health Information Economy. N Engl J Med 2009 Mar 26;360(13):1278–1281. PMID: 19321867

8. 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;23(5):899–908. PMCID: PMC4997036

9. Mandl KD, Mandel JC, Murphy SN, Bernstam EV, Ramoni RL, Kreda DA, McCoy JM, Adida B, Kohane IS. The SMART Platform: early experience enabling substitutable applications for electronic health records. J Am Med Inform Assoc 2012 Jul;19(4):597–603. PMCID: PMC3384120

10. 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 1;21(2):e12902. PMCID: PMC6376332

11. Mandl KD, Kohane IS. Data Citizenship under the 21st Century Cures Act. N Engl J Med 2020 May 7;382(19):1781–1783. PMID: 32160449

12. Mandl KD. Meeting to Advance Push Button Population Health: SMART/HL7 Bulk Data Export/FLAT FHIR. SMART Health IT. 2019. Available from: http://smarthealthit.org/wp-content/uploads/SMART-2019_FHIR-Bulk-Data-Meeting_final.pdf

13. Gordon WJ, Mandl KD. The 21st Century Cures Act: A Competitive Apps Market and the Risk of Innovation Blocking. J Med Internet Res 2020 Dec 11;22(12):e24824. PMID: 33306034

14. Mandl KD, Kohane IS. Time for a Patient-Driven Health Information Economy? N Engl J Med Massachusetts Medical Society; 2016 Jan 21;374(3):205–208.

15. Mandl KD, Szolovits P, Kohane IS. Public standards and patients’ control: how to keep electronic medical records accessible but private. BMJ 2001 Feb 3;322(7281):283–287. PMCID: PMC1119527

16. Mandl KD, Kohane IS. Tectonic shifts in the health information economy. N Engl J Med 2008 Apr 17;358(16):1732–1737. PMID: 18420506

17. EHI.API\EHI Export Operation – FHIR v4.0.1. Available from: https://build.fhir.org/ig/argonautproject/ehi-api/ehi-export.html [accessed Jun 14, 2025]

18. Phelan D, Gottlieb D, Mandel JC, Ignatov V, Jones J, Marquard B, Ellis A, Mandl KD. Beyond compliance with the 21st Century Cures Act Rule: a patient controlled electronic health information export application programming interface. J Am Med Inform Assoc 2024 Jan 29; PMID: 38287642

19. Mandl KD, Kohane IS. Epic’s call to block a proposed data rule is wrong for many reasons. STAT News 2020 Jan 27; Available from: https://www.statnews.com/2020/01/27/epic-block-proposed-data-rule/ [accessed Aug 6, 2023]

20. Twichell SA, Rea CJ, Melvin P, Capraro AJ, Mandel JC, Ferguson MA, Nigrin DJ, Mandl KD, Graham D, Zachariah JP. The Effect of an Electronic Health Record-Based Tool on Abnormal Pediatric Blood Pressure Recognition. Congenit Heart Dis 2017 Jul;12(4):484–490. PMCID: PMC5647583

21. Kawamoto K, Kukhareva P, Shakib JH, Kramer H, Rodriguez S, Warner PB, Shields D, Weir C, Del Fiol G, Taft T, Stipelman CH. Association of an Electronic Health Record Add-on App for Neonatal Bilirubin Management With Physician Efficiency and Care Quality. JAMA Netw Open 2019 Nov 1;2(11):e1915343. PMCID: PMC6902796

22. Kawamoto K, Kukhareva PV, Weir C, Flynn MC, Nanjo CJ, Martin DK, Warner PB, Shields DE, Rodriguez-Loya S, Bradshaw RL, Cornia RC, Reese TJ, Kramer HS, Taft T, Curran RL, Morgan KL, Borbolla D, Hightower M, Turnbull WJ, Strong MB, Chapman WW, Gregory T, Stipelman CH, Shakib JH, Hess R, Boltax JP, Habboushe JP, Sakaguchi F, Turner KM, Narus SP, Tarumi S, Takeuchi W, Ban H, Wetter DW, Lam C, Caverly TJ, Fagerlin A, Norlin C, Malone DC, Kaphingst KA, Kohlmann WK, Brooke BS, Del Fiol G. Establishing a multidisciplinary initiative for interoperable electronic health record innovations at an academic medical center. JAMIA Open 2021 Jul;4(3):ooab041. PMCID: PMC8325485

23. Jones J, Gottlieb D, Mandel JC, Ignatov V, Ellis A, Kubick W, Mandl KD. A landscape survey of planned SMART/HL7 bulk FHIR data access API implementations and tools. J Am Med Inform Assoc 2021 Mar 1; PMID: 33675659

24. Jones JR, Gottlieb D, McMurry AJ, Atreja A, Desai PM, Dixon BE, Payne PRO, Saldanha AJ, Shankar P, Solad Y, Wilcox AB, Ali MS, Kang E, Martin AM, Sprouse E, Taylor DE, Terry M, Ignatov V, SMART Cumulus Network, Mandl KD. Real world performance of the 21st Century Cures Act population-level application programming interface. J Am Med Inform Assoc 2024 Mar 6; PMID: 38447593

25. EHR Good Neighbor. EHR Good Neighbor. Available from: https://good-neighbor.smarthealthit.org/ [accessed Jun 14, 2025]

26. Case Studies. EHR Good Neighbor. Available from: https://good-neighbor.smarthealthit.org/case-studies/ [accessed Jun 14, 2025]

27. Performance & Quality. EHR Good Neighbor. Available from: https://good-neighbor.smarthealthit.org/performance/ [accessed Jun 14, 2025]

28. Mandel JC, Pollak JP, Mandl KD. The Patient Role in a Federal National-Scale Health Information Exchange. J Med Internet Res Journal of Medical Internet Research; 2022 Nov 4;24(11):e41750.

29. Strategic Health IT Advanced Research Projects (SHARP) Program. Available from: https://www.healthit.gov/data/quickstats/strategic-health-it-advanced-research-projects-sharp-program [accessed Apr 1, 2023]

30. Health Level Seven. Argonaut Project Home. Available from: https://confluence.hl7.org/display/AP/Argonaut+Project+Home [accessed Jun 4, 2023]

31. Centers for Disease Control and Prevention. Listening Session on Real-World Testing of 21st Century Cures Act Requirements. 2022. Available from: https://www.cdc.gov/surveillance/pubs-resources/dmi-summary/index.html [accessed Apr 1, 2023]

32. SMART Advisory Committee. SMART Health IT. 2014. Available from: https://smarthealthit.org/an-app-platform-for-healthcare/advisory-committee/ [accessed Jun 5, 2023]

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

October 1, 2024

Thank you for the opportunity to comment on the HTI-2 proposed rule! We strongly support the ASTP proposals in the rule that expand the use of open standards in healthcare, and believe they will drive innovation that empowers patients, improves care and reduces costs. 

With regard to the Bulk Data Export certification requirement, we agree with ASTP that server support for the _since and _type parameters is a powerful mechanism to reduce the export of extraneous data and improve patient privacy. ASTP notes the lack of a standard process for creating the groups necessary for invoking the “group-export” operation. There is early work in the Argonaut Project to enhance the Bulk Data Access IG in this area, and we propose a general requirement based on the FHIR Group API that can later be updated to a more specific approach, such as the work being done in Argonaut, through the SVAP process. Finally, we propose the inclusion of an export performance parity provision in HTI-2 to better align the capabilities implemented for regulated bulk data interfaces with those of non-regulated, proprietary bulk data interfaces. 

We applaud ASTP for addressing the challenges associated with EHI Export in the HTI-2 proposed rule. To ensure this critical capability is meeting patent needs, we propose additional functional requirements for EHI download functionality in patient portals, EHI access via third-party apps and the adoption of a common approach for non-computable EHI formats (e.g., PDF or HTML).

Medical images are a critical data element for clinical decisions and we strongly support their inclusion in the proposed rule. However, we are concerned that the proposed manner of relying on “imaging links” as the only API-based (i.e., programmatic, automatable) path to access images could fail to solve the access problem. We recommend clarifications to the API requirement to ensure that implementations meet the intent of the rule.

We commend ASTP’s proposal to require subscription capabilities for US Core data. This addition is crucial for enabling real-time data exchange and supporting various use cases across clinical, individual access, and public health domains. However, we recognize that implementing a comprehensive subscription system to provide visibility into all FHIR data changes would present implementation challenges for many real-world EHR systems. We believe a phased approach that prioritizes simplicity and alignment with existing standards can serve to establish a solid foundation for subscription-based data exchange while allowing for future expansion based on real-world experience and feedback and point ASTP to the Argonaut Project’s recent work in this area.

The adoption of dynamic registration for healthcare applications will simplify how apps can securely connect with EHR systems. The proposed rule focuses on using CA-signed certificates and trust communities for dynamic registration. This approach, while robust, may unintentionally exclude individuals and hobbyists who want to explore and innovate with healthcare data in limited contexts, such as individuals developing apps to meet their own health needs or those of friends/family. We recommend a requirement for EHR systems supporting dynamic registration to also accept self-signed certificates for application identity when registering via the HL7 UDAP Security for Scalable Registration IG. By providing users with information on the registrant, a capability present today in app registration systems from vendors such as Epic and Oracle Cerner, this  approach can provide necessary flexibility without compromising security.

Finally, as AI driven recommendations become more prevalent in healthcare, the ability to integrate them into EHR systems through a standards based, interoperable interface is essential for their deployment, monitoring, evaluation and substitutability. In this context, we are excited by the inclusion of the CDS Hooks 2.0 specification in the proposed rule and view this as a core component to build a robust AI ecosystem in healthcare.

FHIR Bulk Data Enhancements

Export Performance Parity

ASTP notes the performance challenges identified by early adopters of the Bulk FHIR interfaces in certified EHR systems. For example, some vendors currently support high performance, non-standard bulk data export of clinical data through a data warehouse product and lower performance, FHIR based bulk data export of clinical data through their transactional system.

Congress explicitly mandated in the 21st Century Cures Act that “interoperability” encompass “complete access, exchange, and use of all electronically accessible health information” and that health IT developers “allow health information from such technology to be accessed, exchanged, and used without special effort through the use of application programming interfaces”.  A reasonable interpretation is that the API must be performant. 

As cited in the Proposed Rule, we have documented poor API performance in EHRs at multiple sites of care¹. In contrast, we have also demonstrated capacity for a large health information exchange to rapidly implement the a highly performant Bulk FHIR API in a matter of weeks²

Unfortunately, currently, regulated interfaces in EHRs often perform more poorly than proprietary interfaces and act as a tax on developers and users by making many use cases unworkable using the regulated interface, forcing them to build different versions of their software for each vendor, and often pay additional fees on top of the cost of their certified system just to have access to performant data export.

This harms innovation in healthcare by causing otherwise promising projects to be too costly to pursue, and reduces equity by restricting the ability of institutions with limited resources to participate in research in the same way as larger institutions. Being pushed into proprietary interfaces also serves to lock healthcare institutions into their current EHR vendor, as software built to these interfaces is not portable when an institution changes its EHR. 

We propose an export performance parity provision in HTI-2 to better align the capabilities of regulated bulk data interfaces with those of non-regulated, proprietary bulk data interfaces. 

Our Recommendations:

For any Health IT Module that is part of a system capable of exporting electronic health information for multiple patients simultaneously, and where this information includes data elements from the USCDI v3 dataset:

1. The system must support the FHIR bulk data export operation for such exports.
2. The FHIR bulk data export operation must meet the following criteria
   • Performance: The speed and efficiency of data retrieval and export must be comparable to that of non-FHIR export formats (e.g., CSV) when exporting similar volumes of data for a comparable number of patients on equivalent hardware. 
   • Scalability: The system’s ability to handle increasing data volumes and patient numbers must not be significantly different between FHIR and non-FHIR export methods.
   • Timeliness: The currency and up-to-date nature of exported data must be equivalent across FHIR and non-FHIR export methods.
   • Customization: Users must have similar capabilities to tailor the scope and content of exports (e.g., selecting specific data fields or date ranges) in FHIR bulk data exports as they do in non-FHIR export formats.
3. Vendors must provide documentation demonstrating compliance with these requirements as part of the certification process.
4. Vendors must provide system administrators with the ability to review metrics about recent bulk and non-bulk exports including the volume of data retrieved and the time to generate and retrieve the export.

Server support for patient group creation

ASTP notes the lack of a standard process for creating the groups necessary for invoking the “group- export” operation and the group size limitations present in some systems. The community has begun the process of defining an API for standardized creation of cohorts for use in bulk export at https://build.fhir.org/ig/HL7/bulk-data/branches/argo24/group.html. We recommend that the ASTP review this preliminary work and consider signaling its potential adoption in a future rule. We propose that the ASTP require EHR systems to support the creation, modification and deletion of FHIR Group resources with no size restrictions other than the total number of patients in the system. When the community reaches consensus on an update to the Bulk Data Access IG to standardize this approach, it could be supported in the regulation through the SVAP process.

Server support for _since and _type

We strongly support the ASTP proposal to require server support for _since and _type since enabling users to scope the output of a bulk export operation to their needs will limit the export of extraneous data and improve patient privacy. 

Useful support for the _since parameter necessitates that EHR systems track when content in FHIR resources are updated and apply this criteria to the data being returned. We propose that EHR systems apply the same criteria used to trigger a subscription notification for a resource to track these changes so the data returned in response to an _since parameter meets user expectations and aligns with the subscription requirements proposed in HTI-2.

EHI Export

We applaud ASTP for addressing the challenges associated with EHI Export in the HTI-2 proposed rule. However, we are concerned that the proposed approach to EHI Export does ensure consistent and user-friendly access to full EHI for all patients.

Congress explicitly mandated in the 21st Century Cures Act that “interoperability” encompass “complete access, exchange, and use of all electronically accessible health information” and that health IT developers “allow health information from such technology to be accessed, exchanged, and used without special effort through the use of application programming interfaces”. This indicates that patients should have ready access to their full EHI, ideally through automated, standards-based mechanisms.

ASTP’s proposed rule falls short of fulfilling this Congressional intent. The current process for requesting full EHI often burdens patients with navigating a confusing patchwork of health system-specific and vendor-specific processes that involve multiple phone calls, emails, and faxes. This creates significant barriers to patient access and control over their own health information. Indeed, under ONC funding we developed a prototype based on the Argonaut implementation guide, which could serve as a starting point³.

Our Recommendations:

To achieve the Congressional vision of complete access to EHI, we urge ASTP to adopt the following functional requirements for certified health IT:

1. EHI Download Functionality in Patient Portals: ASTP should establish a functional requirement that certified health IT include built-in functionality for patients to request a full EHI export directly through their patient portal. This download may require asynchronous participation from health system staff before it is fulfilled, but should not require additional interaction from the patient, and should notify the patient when the export has finished and the files are ready to download.
2. EHI Access via Third-Party Apps: ASTP should establish a functional requirement that patients be able to approve sharing their full EHI with third-party applications through the same authorization flow that is used for sharing “US Core” data. This would leverage the existing SMART on FHIR framework already mandated for USCDI data access.

Note: This functional requirement does not necessitate standardizing the API or data models for EHI. Rather, it ensures that patients have a clear and consistent process to authorize access to their complete medical records, paving the way for future standardization. To encourage industry alignment and promote interoperability, we strongly recommend that ASTP review the Argonaut Project’s EHI API Implementation Guide (https://build.fhir.org/ig/argonautproject/ehi-api/) and consider signaling its potential adoption in a future rule.

3. Common approach for non-computable EHI formats (e.g., PDF or HTML): ASTP should establish a functional requirement that certified health IT include built-in functionality for patients to request a EHI in non-compatible formats using the methods described in #1, and #2 above. The ability to retrieve and share their EHI in either non-computable and computable formats through a single workflow at each healthcare site will reduce the learning curve for patients and enable clearer documentation of the steps involved. This is important, since patients with complex conditions often have the greatest need to obtain their EHI from sites of care, but also may be the most limited in their time and ability to successfully navigate the records request process at each institution.

By implementing these recommendations, ASTP would empower patients with greater control over their health information, foster innovation in patient-facing applications, and drive progress towards a truly interoperable healthcare system.

Image Links in API Responses

We applaud ASTP’s initiative to improve the accessibility of medical images through the proposed rulemaking. However, we are concerned that the proposed manner of relying on “imaging links” as the only API-based (i.e., programmatic, automatable) path to access images could fail to solve the access problem. 

The Proposed Rule does not ensure that links are shareable or that links enable automated access. With these limitations, API access to Imaging Links would fail to meet the policy objective of enabling applications to access imaging data. For example, the following concerns apply:

• Contextual Restrictions: Imaging Links might be bound to specific user authorization context, network, or timespan, irrespective of the intent of the authorizing user. A link that works in one context (say, for a particular user or in a particular jurisdiction) may be unusable in another context (say, for a new treating provider in another jurisdiction), making the link unshareable.
• Obstacles to Automation: Imaging Links returned in API responses could lead to a broken or incoherent experience for application users. APIs might return links intended for human rather than machine consumption, preventing apps from dereferencing the links to retrieve imaging content.

Our Recommendations:

1. Maintain Proposed Functional Requirements for “View and Download” of images: ASTP’s proposed requirements for patient View and Download access (i.e., access to diagnostic quality images, not links) are crucial for establishing common patterns of data access. These should be maintained.
2. Clarify the Imaging Links API Requirement to ensure programmatic access is enabled: ASTP should clarify the proposed API requirements to ensure that certified systems enable end-to-end automated access to imaging data. This approach can stop short of naming standards, because a carefully designed functional API requirement should encourage EHR and PACS vendors to collaborate on integration strategies that provide a cohesive and user-friendly experience. These clarifications can be introduced in a way that maintains consistency with the Proposed Rule. The critical clarifications are:
   • Ensure that a patient can authorize API access to imaging data in the same flow where they authorize access to clinical data.
   • Ensure that any “Imaging Links” returned by the API will enable programmatic access, meaning that an authorized application can dereference the link to access imaging data without additional user interaction.
   • Note: These functional requirements could be met by using the Imaging API documented at https://github.com/sync-for-science/imaging. In this scheme, developed as part of the Sync for Science project in 2018 and refined by the Argonaut Project in 2023, a FHIR server returns an ImagingStudy with reference to a DICOM Web endpoint, and the app can access the DICOM Web “Imaging Link” programmatically, using the same authorization that granted access to the FHIR API.
3. Encourage Industry Collaboration on Best Practices: ASTP should suggest that EHR and PACS vendors can meet the functional requirements above by building on work from industry initiatives like the Argonaut Project. Signaling the desire to include standards in a future rule would help drive industry progress on implementation guidance, while ensuring working (if variable) API access in the interim.

Subscriptions for US Core Data

We commend ASTP’s proposal to require subscription capabilities for US Core data. This addition is crucial for enabling real-time data exchange and supporting various use cases across clinical, individual access, and public health domains. Subscriptions will significantly improve the timeliness and efficiency of data sharing.

However, we recognize that implementing a comprehensive subscription system to provide visibility into all FHIR data changes would present implementation challenges for many real-world EHR systems. We believe an initial requirement focusing on the most important data changes would allow for a more manageable implementation process while still delivering significant value. A phased approach prioritizes simplicity and alignment with existing standards, establishing a solid foundation for subscription-based data exchange while allowing for future expansion based on real-world experience and feedback.

We believe the Argonaut Project’s draft design for a US Core Patient Data feed at https://github.com/argonautproject/us-core-patient-data-feed/blob/main/spec.md forms a solid basis for ASTP requirements. Briefly, the design provides:

• A single topic that allows access to any patient-linked data in US Core, but initially requires support for only a small set of data including DocumentReference, Encounter, DiagnosticReport, Observation resources.
• Ability to subscribe to data with or without a “patient=” filter, meaning that apps can subscribe to a single patient’s data or a cross-patient feed (e.g. for public health or clinical enrollment systems).
• Flexibility for servers to send notifications on a key set of important lifecycle events, rather than requiring every FHIR-visible change to trigger a notification.

Our Recommendations:

1. Version Alignment: Refer to version 1.1 of the Topic-Based Subscriptions Backport IG, with the option to support version 1.2 via SVAP after version 1.2 is published.
2. Subscription Topic: Describe a single Patient Data Feed similar to the Argonaut Project’s draft design, rather than introducing distinct concepts of “USCDI change notifications” and “Resource notifications”. 
3. Phased Expansion: Begin with a limited set of required FHIR resources and expand over time to cover all of USCDI.
4. Focused Filters: Align filter requirements with existing US Core search parameters, reducing implementation complexity.
5. Flexibility in Trigger Implementation: Require notifications for resource status changes (create, update, delete) but allow flexibility for servers in determining which underlying EHR system events will trigger “update” notifications.
6. US Core Integration: Support the development of subscription guidance within US Core to provide a cohesive set of standards for implementers.

Dynamic Registration outside of Trust Frameworks

We applaud ASTP’s proposed adoption of dynamic registration for healthcare applications, simplifying and securing how apps connect with EHR systems. We recommend an important addition to the proposed rule to ensure dynamic registration is accessible to everyone: require EHR systems supporting dynamic registration to also accept self-signed certificates for application identity when registering via the HL7 UDAP Security for Scalable Registration IG. 

The proposed rule focuses on using CA-signed certificates and trust communities for dynamic registration. This approach, while robust, may unintentionally exclude individuals and hobbyists who want to explore and innovate with healthcare data in limited contexts, such as individuals developing apps to meet their own health needs or those of friends/family. Requiring these individuals to join trust communities creates an unnecessary barrier to entry, limiting their ability to participate in the API ecosystem.

Notably, this change provides necessary flexibility without compromising security, as EHR systems can still inform users that an app’s identity is self-attested when authorizing access to apps using self-signed certificates. Similarly, current app registration approaches from vendors such as Epic and Oracle Cerner provide information to app users about the app’s registrant, but do not censor non-fraudulent registrations by individuals. 

Proposed Language Modification: Add the following to §170.315(j)(2), “Dynamic registration” – “A Health IT Module supporting dynamic registration under §170.215(o) must also support self-signed certificates for application identity.”

Expanding dynamic registration access will foster creativity and empower individuals to engage with their healthcare data in new and beneficial ways.

CDS Hooks

We applaud ASTP’s inclusion of CDS Hooks 2.0 as a certification requirement as well as the requirements for patient-view and order-sign hooks. As AI driven recommendations become more prevalent in healthcare, the ability to integrate them into EHR systems through a standards based, interoperable interface is essential for their deployment, monitoring, evaluation and substitutability. For example, a standards based DSI that integrates with EHR systems though CDS Hooks could be tested with a site’s data prior to implementation using a CDS Hooks simulator environment, rather than requiring custom infrastructure.

Bibliography 

1. Jones JR, Gottlieb D, McMurry AJ, Atreja A, Desai PM, Dixon BE, Payne PRO, Saldanha AJ, Shankar P, Solad Y, Wilcox AB, Ali MS, Kang E, Martin AM, Sprouse E, Taylor DE, Terry M, Ignatov V, SMART Cumulus Network, Mandl KD. Real world performance of the 21st Century Cures Act population-level application programming interface. J Am Med Inform Assoc [Internet]. 2024 Mar 6; Available from: http://dx.doi.org/10.1093/jamia/ocae040 PMID: 38447593 ↩︎
2. McMurry AJ, Gottlieb D, Miller TA, Jones JR, Atreja A, Crago J, Desai PM, Dixon BE, Garber M, Ignatov V, Kirchner LA, Payne PRO, Saldanha AJ, Shankar PRV, Solad YV, Sprouse EA, Terry M, Wilcox AB, Mandl KD. Cumulus: a federated electronic health record-based learning system powered by Fast Healthcare Interoperability Resources and artificial intelligence. J Am Med Inform Assoc [Internet]. 2024 Jun 11; Available from: http://dx.doi.org/10.1093/jamia/ocae130 PMID: 38860521 ↩︎
3. Phelan D, Gottlieb D, Mandel JC, Ignatov V, Jones J, Marquard B, Ellis A, Mandl KD. Beyond compliance with the 21st Century Cures Act Rule: a patient controlled electronic health information export application programming interface. J Am Med Inform Assoc [Internet]. 2024 Jan 29; Available from: http://dx.doi.org/10.1093/jamia/ocae013 PMID: 38287642 ↩︎

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

June 1, 2023

Thank you for the opportunity to comment on the HTI-1 proposed rule! We understand that it takes time to see the effects of recent changes, as many of the effects of previous regulations are just now making their way into practice. It’s important to learn from experience and focus new regulations on demonstrated approaches. Given the design and demonstrated value of SMART on FHIR and SMART/HL7 Bulk FHIR Access API, we urge strong consideration of their use, or at least testing, in addressing use cases. The bandwidth of Health IT developers to reliably surface multiple APIs addressing minimally different use cases (e.g., quality metric reporting, eCR) may be better spent on ensuring performant SMART APIs with reliably mapped USCDI elements.

In the current landscape, we see many reasons for encouragement based on the roll-out of API access in 2023, especially for single-patient use cases (clinician and patient-facing apps). However, we recognize ongoing challenges that API users are experiencing with FHIR API performance and workflow for high-value population-level use cases at scale. More clarity on expectations from ONC and CMS is needed to ensure consistent and performant population-level APIs as are meaningful metrics.

USCDI Definitions and Expansions

We strongly support USCDI as a common basis of exchange. However, there are challenges in a one-size-fits-all model of “the core data set” — some elements are a stretch for EHRs, and other elements (such as, concepts common to payors systems) aren’t addressed deeply enough. We’ve also seen significant standards-development challenges around vague or ambiguous elements in USCDI. This leads to churn in the standards process, widespread optionality in the standard profiles, and, due to wide variation in formats, limited capabilities that may be unsuited for the use cases of the submitters who advocated for the inclusion of these elements in USCDI.

Our Recommendations

1. When adding elements to USCDI, ONC should:
   • Explain a set of intended use cases
   • Provide details about how and how frequently these data are being used to meet the intended use cases in real-world systems today, which will help the standardization effort to build on real-world experience and achieve ONC’s desired outcomes.
2. Within USCDI, ONC in its coordination role can pre-group data subsets, for example tagging them as related to demographics, clinical, financial / payment / insurance, or imaging.These tagged subsets could then be pulled in by other programs beyond the EHR, such as CMS regulation of  the APIs and data responsibilities of payors.

Decision Support Interventions

This is a significant and expanding area of great clinical import. Many predictive capabilities are expanding rapidly. Transparency and mitigation of bias are imperative. However, we believe that regulating a specific set of data and model attributes is premature, as there is not yet consensus on the set or structure of such attributes. Many techniques are evolving in parallel, and even a functional requirement that’s opinionated about (numerous!) specific data classes risks producing unintended consequences, such as information overload in the clinical UX and incomplete and unhelpful “box checking” data.

Targeting new regulations at EHRs here may also have unintended consequences. EHRs are integration points for diverse decision support, and choices about how to assess and manage risk are a core responsibility of the clinical providers deploying decision support. Imposing requirements on EHR vendors may lead to proliferation of decision support that route around the EHR rather than through it.

Our Recommendations

1. Add first-class support for CDS Hooks as an alternative to InfoButton
2. Do not regulate a specific set of attribute unless/until such attributes are successfully incorporated into some real-world deployments
3. Do not regulate “data review” UX requirements unless/until this is demonstrated to work in practice
4. Emphasize the importance of providing model cards and similar data to health systems at the time of selecting/configuring decision support, rather than overloading clinician-facing UX at runtime.
5. Emphasize that responsibility for risk assessment and mitigation should be shared with DSI providers, rather than falling onto EHRs.

Public Health: Electronic Case Reporting and Surveillance 

There is a substantial opportunity to empower Public Health with data from the care delivery system in far more robust ways than have been accomplished in the past. The most promising approach will be to ensure that Public Health does not rely on one-off solutions, even ones specified in rules and regulations, but rather derives data from common data infrastructures used by CMS and other entities.

Proposed case reporting and surveillance standards are complex for EHRs, with dynamic behavior required from every EHR, intricate temporal logic, and value sets that change over time without standard update protocols. Proposed case reporting standards are also brittle, with significant effort to support public-health-specific APIs, requirements that still vary by jurisdiction, and limited ability to predict future needs.

Our Recommendations

1. Focus on enabling public health use cases through existing SMART on FHIR and SMART/HL7 Bulk FHIR Access APIs rather than one-off public health-specific protocols
2. Leverage SMART on FHIR backend services and apps that:
   • Can be authored or sponsored by public health
   • Can manage alerting logic nimbly without per-EHR repeated work
   • Consume existing FHIR APIs and trigger from US Core data
3. Expand existing APIs to ensure support for cross-patient queries, such as:
   • GET /Encounter sorted by time, code, category
   • GET /Observation sorted by time, code, category
   • GET /Condition sorted by time, code, category
4. Invest in FHIR Subscriptions as a performance optimization, such as “US Core Event Feed” as a Subscription Topic, which supports filtering by resource type, patient, code, and category
5. Expand required parameter support on the FHIR bulk data API to:
   • Mandate support for the “_since” parameter, allowing apps to request only data modified after a specified date
   • Mandate support for “_typeFilter”, specifically to allow filtering of:
     • Patient resources by demographic information
     • Observations, Conditions, and other US Core resources by category (where applicable) and code (where applicable).

EHR Reporting Program

We appreciated the chance to participate in prior rounds of measure planning and applaud ONC’s introduction of specific measures. However, we are concerned about the complexity of the proposed measures, with multiple numerators, denominators, and stratifications, and unclear exactly what reporting data are being proposed. We are also concerned that many measures imply the collection of new types of data, such as app categories and intended audiences.

We are further concerned that some metrics propose to segregate by an unreliable concept of “two different endpoint types: patient-facing and non-patient-facing.” FHIR endpoints can serve multiple and broad audiences and need not have a “type” like “patient endpoint” or “provider endpoint”.

Our Recommendations

1. Start with a smaller reporting set and expand over time
2. Focus on data elements already known/available
3. Assess usage based on user types (e.g., patient vs provider — these are tracked and consistent), not “endpoint types” (which are not distinct in all deployments).
4. For bulk data requests, include at least one metric to track the real-world performance of implementations
5. Key metrics:
   • Consumer access (SMART on FHIR)
     • Count of distinct apps connected
     • Count of app connections per patient
     • Count of portal sessions per patient
   • Clinician access (SMART on FHIR)
     • Count of distinct apps connected
   • FHIR Bulk Data API
     • Count of export requests
     • Export time per resource (average)
     • Group size for successful exports (average)

FHIR Endpoint for Service Base URLs

We strongly support the ONC’s addition of specific metadata requirements for endpoint URL lists to help patients identify the correct endpoints for their healthcare providers. We are concerned about the specificity of the guidance around FHIR resources and data elements in the regulations and believe that introducing more detailed functional requirements instead would encourage the industry to refine and align on technical data profiles.

Our Recommendations

1. Enhance the existing functional requirements by mandating that published endpoint lists support: physical locations, organizational hierarchies, patient-facing brand names, and institution logos.
2. Encourage industry evaluation of detailed FHIR implementation guides to meet these functional requirements. A starting point is the Argonaut Project’s 2022 “SMART Patient Access Brands” profiles (available at https://build.fhir.org/ig/HL7/smart-app-launch/branches/pab/brands.html).

Standards Updates: SMART v2

We have been encouraged to see the breadth of adoption and are pleased to see the enumeration of SMART capabilities and clear rationale in HTI-1 — such considerations help justify industry investments. We agree with the features that HTI-1 proposes to require.

There has been ongoing confusion about consumer ability to connect browser-based apps persistently, without the need to re-authenticate. Previous ONC regulations guaranteed this ability for some apps but not others, drawing distinctions by client type (confidential vs public, or native vs browser-based). Previous ONC regulations also do not require support for Cross-Origin Resource Sharing, leading to a situation where some server configurations prevent browser-based apps from receiving an access token. SMART 2 introduced support for PKCE to reliably bind token issuance to a client’s authorization request, mitigating previous concerns. However, the HTI-1 proposal stil does not ensure long-term access for “public clients,” even though “public clients” can offer better data segregation than “confidential clients” by avoiding the need for consumer data to transit through a developer’s backend server. Such restrictions impose unnecessary risk by encouraging app developers to use a backend server and limit patient choice by artificially limiting the capabilities of browser-based local apps.

Our Recommendations

1. Adopt the current release — i.e., SMART 2.1 (not 2.0), which includes:
   • Improved FHIR Context management
   • App State capability

2. Mandate support for client-side browser-based apps:
   • Mandate that consumers can approve “offline_access” scope for any registered app, not just confidential or native clients
   • Mandate that servers “support purely browser-based apps” per https://hl7.org/fhir/smart-app-launch/app-launch.html#considerations-for-cross-origin-resource-sharing-cors-support

Information Blocking: TEFCA Condition for “Manner” exception

Organizations today have the right to negotiate the manner of access, however, HTI-1 notes that “it is reasonable and necessary for actors who have chosen to become part of the TEFCA ecosystem to prioritize use of these mechanisms”. We believe that artificially limiting this right for organizations that participate in TEFCA may have unintended consequences. TEFCA has not yet launched, and it is unknown what full-scale challenges may emerge. Some organizations may participate in TEFCA out of necessity, driven by certain use cases, but may not be well served by TEFCA for all use cases.

For single-patient use cases, there may be a significant delay before TEFCA’s draft FHIR roadmap is widely implemented. In the meantime, organizations should be able to negotiate for the manner of access that suits their requirements, including access to a certified EHR’s SMART on FHIR patient API endpoints. For population-level use cases, TEFCA may not offer any pragmatic alternative to bulk FHIR export, even if TEFCA supports access to all of the data elements and patients associated with a bulk request. Organizations should be able to negotiate for the manner of access that suits their requirements, including access to a certified EHR’s SMART on FHIR Population API endpoints.

Our Recommendations

1. Do not introduce a TEFCA Condition for the information blocking “Manner” exception
2. Instead, monitor TEFCA deployments closely with an eye to utility, completeness, timeliness, ease of access, security, privacy, transparency, and consumer participation. Base decisions on real-world experience.

Patient Right To Request a Restriction (proposed new criterion)

We strongly support individual rights, including the right to restrict disclosure of PHI. However, HTI-1’s proposal does not ensure patient rights and is very likely to lead to confusing UX, mistaken expectations, and violated trust. Consumers have the ability to request restrictions, but providers do not need to follow them, and provider technology does not offer a good way to enforce restrictions even if a provider wants to. Techniques to manage and enforce such restrictions are still an open research challenge.

Our Recommendations

1. Do not introduce a non-binding requirement for requesting restrictions to disclosures at this time.
2. Instead, adopt two pragmatic approaches that empower patients with controls over and insights into the use of their data:
   • Controls at the source: Let patients ensure data accuracy at the source, to prevent sharing of inaccurate information. Introduce a functional requirement aligning with the HIPAA right to request corrections and amendments to erroneous information. This would:
     • Ensure that patient portals and patient APIs provide patients an easy path to requesting corrections to their medical records, or to amending records in the case that providers decline to apply corrections.
     • Provide a clear market signal to drive participation in standardization efforts through HL7’s patient empowerment workgroup
   • Insights and controls for exchange: Let patients see who’s querying their data in TEFCA, and provide opt-out controls. Since most uses of TEFCA would fall under “treatment, payments, and operations,” TEFCA represents the largest-scale non-accountable PHI flow in history. See our perspective “The Patient Role in a Federal National-Scale Health Information Exchange” at https://www.jmir.org/2022/11/e41750 for background. ONC should prevent TEFCA from driving such “dark” traffic by providing a mechanism for patients to review:
     • Who made a query for my records?
     • When?
     • For what purpose of use?
     • Who responded to the query?

RFI Response: FHIR Subscriptions

FHIR has included preliminary support for subscriptions since R3 and has recently introduced support for “topic-based subscriptions” incorporating industry feedback to enable scalable deployment. Topic-based subscriptions are available starting with FHIR R4 based on the “Backport IG” at https://hl7.org/fhir/uv/subscriptions-backport, and are natively supported in FHIR R5.

Given ONC’s current investment in FHIR R4, we suggest that introducing topic-based subscriptions via the Backport IG is the most pragmatic and incremental way to expand capabilities of the current deployed base of FHIR implementations. Using this Backport approach, the certification program could require implementers to support a limited starter set of subscription topics, functionally defined to align with core regulatory priorities. A suggestion for initial use cases would be:

1. “Patient data updates.” Allow notifications when new/updated patient data are available in association with a specific patient ID. This could be used to allow monitoring by patient-facing apps that currently have to poll at regular intervals. It could also help enable public health applications that are monitoring patient encounters in the context of a reportable condition.
2. “Encounter data update.” Allow notifications when a new encounter is created or when an encounter is updated within the health system. This could be used to enable integration of public health triggering and reporting logic into a clinical system without requiring each clinical system vendor to independently implement support for detailed temporal triggering and reporting logic. This might also be the starting point for a FHIR-based encounter notifications alternative to ADT, but in our experience, it is easiest to drive adoption around new capabilities rather than reworking the mechanisms for already available capabilities.

Both of these use cases could be supported by a single “US Core Event Feed” topic, which would enable subscriptions to the resources defined in FHIR US Core with filtering available by:

• Resource Type
• Category (as applicable)
• Code (as applicable)
• Patient ID (for subscriptions at the single-patient level)

RFI Response: CDS Hooks

CDS Hooks is an HL7 standard for integrating external decision support into the clinical workflow. CDS Hooks represents a mature target for standards adoption. A suitable initial target is CDS Hooks 2.0, with mandatory support for the “patient-view” hook, mandatory support for prefetch of US Core data queries, and mandatory support for “fhirAuthorization” access tokens. With this functionality enabled, CDS Hooks can be permitted in regulations an alternative to InfoButton. Beyond this introduction, ONC should articulate use cases and desired outcomes to spur industry development and maturation of additional hook types.

RFI Response: SMART Health Cards and SMART Health Links

The SMART Health Cards (SHC) specification has been used to provide COVID-19 immunization and lab results to individuals at scale including deployments in at least 15 countries. Implementers include major EHRs, and pharmacy chains, as well as public health programs from over 24 US states. Immunization records are available as SMART Health Cards for over 225M people in the USA. By leveraging FHIR and W3C Verifiable Credentials, SMART Health Cards allows sharing of static data sets, with a focus on data that are small enough to fit in a single QR code.

Building on SHC’s format, signature scheme, and trust infrastructure, the SMART Health Links specification allows for more advanced usage including larger data sets (e.g., a full immunization history or patient summary) as well as dynamic data sets (e.g., an immunization history that can be augmented when a patients receives vaccine doses). The SHL specification underwent an initial round of design, prototyping, and feedback through the Argonaut standards accelerator in 2022. Early industry adoption of SHL in 2023 has focused on immunizations and health insurance coverage details, with additional prototypes demonstrating a workflow for sharing International Patient Summary documents.

We believe ONC can foster broader adoption of SHC and SHL by sponsoring programs to identify and address unmet needs in consumer mediated data exchange. In particular, SHCs demonstrate how reducing friction to health data access makes a tangible difference for patients, and SHLs enable this access pattern to be scaled to nearly any data type or use case. In the near-term, SHC and SHL provide a common pattern for sharing use-case-specific data bundles, expanding the reach of FHIR implementation guides for sharing with minimal coordination across organizations. Over time, we see a path for this technology to support more interactive sharing paradigms that could address some of the high-frequency, high-friction touch points that people have with healthcare. This could include prompted sharing (e.g., before a clinical visit, patients might receive an information sharing request that they can review and respond to using a personal health app or wallet) as well as assisted form-filling (e.g., when presented with a blank clipboard asking for clinical information, a personal health app could pre-fill many items and, when desired, could attach verifiable provenance to the submission).

RFI Response: Industry-Led Innovation Activities

Even as API access to clinical data has become routine in practice, API access to imaging data has remained challenge. This year the Argonaut Project has organized development and testing of a specification for SMART app access to Imaging data, building on the SMART on FHIR API capabilities of Certified EHR Technology. The Argonaut design leverages existing EHR app-registration and app-approval workflows, augmenting the available data from an EHR’s “clinical server” with an additional set of imaging data from an imaging endpoint. The imaging endpoint hosts a narrow subset of FHIR and DICOMweb functionality, authorized using SMART on FHIR token introspection to allow SMART apps to list the studies available for a patient and retrieve user-selected studies. We believe this architecture offers a promising and scalable approach to enhance patient and provider access to imaging studies alongside clinical data. Such access would facilitate diverse use cases for providers and patients including:

• For Providers
  • Support analysis w/ preferred tools, such as speciality-specific viewers, image-driven severity scoring, or image-driven risk calculations 
  • Streamline consultation workflows
• For Patients
  • Enable access, compilation of full data
  • Ensure data are available to specialists
  • Facilitate second opinions and 
  • Streamline data donations for research

ONC could identify opportunities to support Argonaut Imaging and functionality that expands on the API capabilities of Certified EHR Technology. Over time, projects like Argonaut Imaging Access can serve as a model for widespread application access to a growing swath of Electronic Health Information.

Sincerely,

The SMART Health IT Team

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

November 29, 2022

We applaud CMS’s vision for expanding availability and improving accuracy of healthcare directory information while reducing the provider burden associated with keeping directory listings up to date.

There is an opportunity to build on the existing, widely used, National Provider Plan and Enumeration System (NPPES) directory infrastructure to incrementally address these challenges. Crucially, improvements in incentives, user experience, and federation are needed to unlock the full potential of NPPES.

Overview. We propose that rather than developing a new centralized directory, enhanced NPPES listings could serve as a “primary key” for healthcare directory information, maintaining the unique id used to tie together data from multiple organizations and storing links to flat files in FHIR format with additional, frequently-updated, information maintained by payor and provider organizations (e.g., details about services, hours, plan participation, and facilities). The term “API” sometimes refers to fine-grained interfaces (e.g., supporting queries like “at which locations does Dr. Smith practice,” or “What time is Dr. Smith’s clinic open next Tuesday”), but we believe a simpler API might be a better starting point — beginning with the ability to host a set of “flat files” at a well-known URL. Hosting flat files that are updated on a frequent basis would satisfy many consumption use cases. Leveraging SMART/HL7 FHIR Bulk Data standards would take advantage of tools and infrastructure designed for working with FHIR data. Third-party aggregators could use the data in NPPES and the referenced flat files to create applications targeted at specific use cases (e.g., a user-friendly, patient-facing application for people to find new healthcare providers).

Incentives. The RFI notes that provider data in the NPPES directory is frequently inaccurate. Without strong incentives for providers to keep the data up to date, technology changes are unlikely to improve data quality. One approach to addressing this challenge would be attestation requirements, such as mandating that providers participating in CMS payment programs periodically attest to the accuracy of their information in the NPPES directory. Additionally, the more the NPPES data are actively used in CMS operations, the more likely providers are to keep it up to date, suggesting another avenue for incentives. For example, the contact information in the directory could be used for all communications around provider payment, necessitating up-to-date information and ongoing engagement with the system.

Improving User Experience. Anecdotally, we’ve heard from users that updating their information on the NPPES website can be cumbersome, particularly when managing listings for multiple providers. It seems common for organizations to be listed multiple times in NPPES, perhaps because creating a new entry is easier than gaining administrative control over a previous entry. CMS should launch a user centered design effort to understand how the site is being used and redesign it to better accommodate common use cases. For example, a simplified interface may be useful for solo practitioners, functionality to create or update listing by uploading a spreadsheet may be beneficial for users at mid-sized organizations, and the ability to integrate through an API may be preferred by users at large institutions.

Federation (hub and spoke). While a single repository for all healthcare directory data is an attractive notion, it would be costly to build and maintain, and would also risk a single point of failure for a system that has high uptime requirements. Furthermore, a single directory with multiple constituencies, varied data granularity, and a range of update frequencies for different data elements introduces substantial complexity in the data model. In a hub-and-spoke federated model, core metadata would be centrally hosted by NPPES while auxiliary information such as a provider’s hours at an institution and whether they are accepting new patients would be maintained in a file directly on the relevant organization’s website, and easily updated when the data changes. To aggregate this data, consuming systems would follow URLs to the files from the NPPES directory. Similarly, payer organizations could publish files listing plan information and participating providers, and the locations of the payer files could be published in a new section of the NPPES directory. By using providers’ NPPES ids to join the data in these files with those on provider sites, third parties can build up comprehensive databases to power specific apps without the need for novel, centrally maintained infrastructure. A similar approach has been successfully adopted with the SMART Scheduling Links project; working with the US Digital Service, participants enabled distributed discovery of COVID-19 immunization appointments across major pharmacies and healthcare providers (https://github.com/smart-on-fhir/smart-scheduling-links).

RFI: https://www.federalregister.gov/documents/2022/10/07/2022-21904/request-for-information-national-directory-of-healthcare-providers-and-services

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.

---

Kenneth D. Mandl, MD, MPH,^1,2 Dan Gottlieb, MPA,² 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.

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.

(A version of this blog was published by CNBC)

January 30, 2018

Ken Mandl (Twitter @mandl)

Despite spectacular advances in diagnostic imaging, non-invasive surgery, and gene editing, healthcare still faces a lackluster problem: many patients can only get health records from their doctor if the fax machine is working. Even when records are stored electronically, different chunks of every patient’s health information sit in the non-interoperable, inaccessible electronic record systems in different doctor’s offices.  

Anyone who needs her medical files gets them either printed or faxed, or has to log on into separate portals for each doctor and hospital, and even then getting view-only access. View-only apps can’t access data to help patients share information with family and healthcare providers, make decisions, monitor disease, stay on course with medications, or just stay well.

On the positive side, this is changing, sort of. Using the iPhone Health app, patients will soon be able to download and view health records on their phones. On the one hand, don’t get too excited–it will initially only work for patients at a handful of institutions, Android users are still out in the cold, and the data available will be limited. And, some dismiss the impact of Apple’s move because of others’ failures to give patients control of their records.

However, Apple’s move is a decisive and consequential advance in patients’ struggle to get a copy of their own health data. Apple wisely chose to use open, non-proprietary approaches that will float all boats–even for Android users.  

Every patient deserves a ‘bank account’ of her health data, under her control, with deposits made after every healthcare encounter. After my colleagues and I demonstrated an open, free version of a “bank account” to companies in 2006, Google and Microsoft launched similar personally controlled health records — GoogleHealth and Microsoft Healthvault. Walmart and other employers offered our version, Indivo, as an employee benefit. Unfortunately, even these industry giants couldn’t shake loose data from the proprietary computer systems in doctors’ offices, or make the case to patients that curating the data was worth the effort.

But 12 years later, Apple’s product enters healthcare under different circumstances.  A lot more patient data is electronic after a $48 billion federal investment in promoting the adoption of information technology to providers. But those products, mostly older software and purchased at enormous expense, still don’t promote record sharing with doctors or patients.

Recognizing this unacceptable limitation and having received a generous grant comprising a tiny fraction of that federal investment, our team created SMART on FHIR. SMART is an interface to make doctors’ electronic health records work like iPhones do. Apps can be added or deleted easily. The major electronic health record brands have built this interface into their products.

Apple uses SMART to connect the Health app to hospitals and doctors offices. The good news for patients, doctors, and innovators is that Apple chose a standardized, open connection over a proprietary, closed one. This approach lets any other app, whether running on the web,  iPhone, or Android, use that very same interface to connect.

So Apple will compete on value and customer satisfaction, rather than on an exclusive lock on the data. Does Apple’s approach help Americans trying to stay well or manage their conditions? Yes. But only with follow-through by Apple, health systems, technology companies, patient groups, policy makers, and government regulators. The emerging ecosystem’s nuances must be appreciated.

First of all, the floodgates for patient information are at least a crack open and will be very hard to close. As patients gain access to their data, they will recognize it is incomplete and feel frustrated it’s not available everywhere. But, patients in need will drive demand for data access in their role as health consumers.

Secondly, the government is effectively using law and regulations to compel an open interface. By selecting SMART on FHIR, Apple and its healthcare launch partners mark the importance of standardization. A uniform approach is critical for scale. Imagine if every electrical product required a differently shaped 120V outlet. Understanding this, Google, Quest Diagnostics, Eli Lily, Optum, and many other companies are using the same interface to plug into healthcare.

Thirdly, Apple’s first version of health records brings data onto the phone, but from there, like the portals many patients are already familiar with, the data are still “view-only.”  In 2009, I had the chance to meet with Apple’s rockstar Bud Tribble and talk about how the iPhone could serve healthcare. We concluded that crucial data–like the medication list–had to be as easy for iOS developers to use in their apps as contacts and location are now.  I would not be at all surprised if this is the next step in Apple’s journey–making the health records available to iPhone app developers. Here too is an opportunity to chose open interfaces, and to allow patients to export the data to another device.

Lastly, competition in healthcare IT is hot. Amazon, Google, Apple and Facebook all have healthcare divisions.  Apple’s extraordinary hardware, including sensors in the phone and watch, will monitor patients at home.  Google’s artificial intelligence will lead doctors and patients to diagnoses and decisions.  Amazon is rumored to be eying pharmacy management. Facebook has sifted through posts to detect and possibly intervene when users may be suicidal.

There are so many opportunities to compete. Locking up a patient’s data should never be one of them.  

Ken Mandl, MD, MPH directs the Boston Children’s Hospital Computational Health Informatics Program and is the Harvard Medical School Donald A.B. Lindberg Professor of Pediatrics and Biomedical Informatics.