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
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]
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
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
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]
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]
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]
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]
You must be logged in to post a comment.