Leading Edge Acceleration Projects (LEAP) FY2026 FINAL.pdf

U.S. Department of Health and Human Services

Office of the National Coordinator for Health Information Technology

Notice of Funding Opportunity Leading Edge Acceleration Projects (LEAP) in Health

Information Technology

Assistance Listings (CFDA) Number 93.345

Application Due Date: July 16, 2026

Anticipated Award Date: September 26, 2026

Program Contact Alison Kemp Anastasia Perchem Office of the National Coordinator 330 C Street SW Washington, D.C., 20201 ONC-LEAP@hhs.gov

Grants Contact Carmel Halloun Office of the National Coordinator 330 C Street SW Washington, D.C., 20201 ONCGrants@hhs.gov mailto:ONC-LEAP@hhs.gov mailto:ONCGrants@hhs.gov

Table of Contents

Executive Summary

A. Program Description/Purpose Background Description

Purpose Structure and Approach Areas of Interest Project Activities

Performance Goals and Objectives

B. Funding Opportunity Award Information Key Award Parameters

Cooperative Agreement and Substantial ONC Involvement Intergovernmental Review Key Dates

Informational Session Letter of Intent

C. Eligibility Information

D. Application and Submission Information Application Package Application Submission Instructions Restrictions on Oral Conversations

Funding Restrictions

E. Application Review Information Screening Review Merit Review Pre-Award Risk Assessment

Award Decisions

F. Federal Award Administration Information Federal Award Notices Terms and Conditions

G. Appendix

Appendix A – Tips for Writing a Strong Application Appendix B – Instructions – SF-424 Application for Federal Assistance Appendix C – Instructions – SF-424A, Budget Information for Non-Construction Programs Appendix D – Budget and Narrative Justification Template Appendix E – Letter of Commitment Template

Executive Summary

This Notice of Funding Opportunity (NOFO) seeks Leading Edge Acceleration Projects (LEAP) in Health Information Technology (Health IT) to address well-documented and fast emerging challenges that inhibit the development, use, and/or advancement of well-designed, interoperable health IT. Project solutions are expected to further a new generation of innovative health IT research and inform the development, implementation, and refinement of standards, methods, and techniques for overcoming major barriers in health information access, exchange, and use.

This NOFO outlines three Areas of Interest that are a priority for the Office of the National Coordinator for Health Information Technology (ONC):

• Area of Interest 1: Accelerate the use of agentic artificial intelligence solutions in clinical care and/or clinical trials;

• Area of Interest 2: Expand Lantern’s API monitoring capabilities by integrating secure, community-driven feedback that complements existing automated checks; and

• Area of Interest 3: Assess laboratory interoperability gaps to improve the adoption and use of standard terminology among small, independent laboratories.

ONC expects to issue one cooperative agreement award per area of interest. Area of Interest 1 will be awarded up to $1 million, and Areas of Interest 2 and 3 will be awarded up to $500,000 each, totaling up to $2 million for the three awards in fiscal year 2026. These awards will have a two-year project and budget period at initial award. However, applicants may submit their applications based on a three-year budget period. Additional funding for year three may be provided, contingent upon availability of funds, meaningful progress, and ONC priorities.

This funding opportunity will have a three-year open application period. ONC may issue future awards under this NOFO to other eligible applicants for future areas of interest.

A. Program Description/Purpose

Background Description

Created in 2004 through Executive Order 133351 and statutorily authorized by the Health Information Technology for Economic and Clinical Health Act (HITECH Act) of 20092, ONC is the principal federal entity charged with coordination of nationwide efforts to implement the most advanced health IT and the electronic exchange of health information. At the forefront of the administration’s health IT efforts, ONC is a resource to the entire health system to support the adoption of health IT and the promotion of nationwide, standards-based health information exchange to improve health care.

Since the HITECH Act was enacted, the health care ecosystem and the technology supporting it have rapidly evolved. Many providers have implemented electronic health record (EHR) systems, and sophisticated health IT tools and applications are quickly coming to market. As the electronic exchange of health information has matured, the amount and types of health data available has expanded. Data standards such as Health Level Seven International (HL7®) Fast Healthcare Interoperability Resources (FHIR®) and application programming interfaces (APIs) are making it easier for consumers to seamlessly access and share their health data with providers and allow health systems to integrate disparate data sources.

Passage of the 21st Century Cures Act3 (Cures Act) in 2016 strengthened ONC’s mandate to improve the interoperability of health information, facilitate information exchange, address barriers to interoperability, and reduce provider burden when using EHRs.

Purpose

While working to implement Cures Act provisions, ONC identified gaps with respect to leveraging EHR data to support population-level analyses and delivery of services, as well as integrating clinical knowledge into routine clinical practice. The reasons for these gaps range from a lack of data standards and interoperability to the digitization, integration, and presentation of new evidence into clinical workflows in safe, useful, and useable ways.

Therefore, this funding opportunity will support innovative and breakthrough solutions critical to maximize the potential of health IT and achieve the goal of a transformed health care delivery system through various methods, such as:

• Determining the fundamental questions, the answers to which will identify barriers to nationwide interoperability and electronic exchange of health data.

• Engaging the health IT industry, along with academic researchers, to identify and develop innovative solutions that address barriers to interoperability.

• Disseminating findings from research while fostering collaboration, advancement, and implementation of solutions and lessons learned with the health IT industry.

Structure and Approach

1 https://www.gpo.gov/fdsys/pkg/FR-2004-04-30/pdf/04-10024.pdf 2 https://healthit.gov/resources/health-information-technology-for-economic-and-clinical-health-hitech-act-of-2009/ 321st Century Cures Act, Pub. L. No. 114-255, 130 Stat. 1033 (December 13, 2016).

https://www.gpo.gov/fdsys/pkg/FR-2004-04-30/pdf/04-10024.pdf https://healthit.gov/resources/health-information-technology-for-economic-and-clinical-health-hitech-act-of-2009/

ONC expects to award three cooperative agreements for a project period of two years for each recipient to focus on areas where breakthrough improvements are needed to address problems that have impeded the innovative use of health IT and thereby accelerate progress in the areas identified.

Areas of Interest

The three Areas of Interest identified below describe priorities ONC is interested in continuing to explore and advance. The descriptions include ways in which applicants may approach developing a project. The Areas of Interest have been assigned numbers for ease of reference, not for prioritization. While there are many challenges associated with the use of health IT, these three Areas of Interest have been identified as critical priority areas for ONC.

Area 1: Accelerate the use of agentic artificial intelligence solutions in clinical care and/or clinical trials

Goal

ONC seeks proposals in this area of interest to accelerate the use of standards-based agentic artificial intelligence (AI) technologies to advance clinical care and enable innovation through AI. The area of interest builds on the recently released request for information Accelerating the Adoption and Use of Artificial Intelligence as Part of Clinical Care.

Background Agentic AI refers to artificial intelligence systems that can take autonomous actions and make decisions with minimal human intervention. Unlike traditional AI that responds to specific prompts or queries, agentic AI systems can break down complex objectives into subtasks, reason through multi-step processes, learn from feedback, and adapt their strategies to achieve desired outcomes. These systems demonstrate a degree of agency by independently navigating workflows, interacting with various tools and databases, and making context-appropriate decisions while working toward goals. In essence, agentic AI functions as an intelligent assistant or collaborator capable of managing processes rather than just individual tasks.

In health IT, agentic AI has tremendous potential to transform health care delivery and administration.

These systems could autonomously manage complex clinical workflows, such as coordinating patient care across multiple specialists, automatically reviewing and reconciling medical records, or orchestrating diagnostic processes by ordering appropriate tests and analyzing results in sequence.

Agentic AI could also revolutionize administrative functions by navigating insurance prior authorization systems, identifying and correcting coding errors in medical billing, or managing population health initiatives by proactively identifying at-risk patients and coordinating preventive interventions. For patients, an AI agent could monitor a patient's health records across multiple providers, identify gaps in care, and proactively remind patients about needed follow-ups. For example, if lab results indicate a patient should see a dermatologist but no appointment has been scheduled within a reasonable timeframe, the agent could alert the patient, and in the future, could even help schedule the appointment.

Or an AI agent with access to visit notes could translate medical information in the notes, explain test results in plain language, and answer follow-up questions patients think of after appointments. Another example of a program that seeks to support the development of agentic AI is the Agentic AI-Enabled Cardiovascular Care Transformation (ADVOCATE) program, which aims to transform advanced https://www.federalregister.gov/documents/2025/12/23/2025-23641/request-for-information-accelerating-the-adoption-and-use-of-artificial-intelligence-as-part-of https://www.federalregister.gov/documents/2025/12/23/2025-23641/request-for-information-accelerating-the-adoption-and-use-of-artificial-intelligence-as-part-of https://arpa-h.gov/explore-funding/programs/advocate https://arpa-h.gov/explore-funding/programs/advocate cardiovascular disease management with an agentic AI system that can provide 24/7 holistic clinical care.

A key advantage of using agentic AI in health care settings is that agentic AI can handle the intricate, multi-step processes that currently require significant human cognitive effort, potentially reducing clinician burnout while improving efficiency and patient outcomes. However, implementing agentic AI systems requires careful attention to safety, careful attention to privacy requirements like those in the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and maintaining appropriate human oversight for critical medical decisions. Additionally, as agentic AI tools are developed, healthcare organizations should consider the appropriate level of human involvement by ensuring end users remain engaged, minimizing automation bias, clarifying stakeholder roles, and supporting a stronger user experience.

The past decade of federal and industry investment in standards, advancements due to the Cures Act, and emerging nationwide interoperability frameworks such as the Trusted Exchange Framework and Common Agreement (TEFCA) has produced a robust foundation for electronic health information exchange across the US. The landscape of AI-API integration standards is rapidly evolving as the industry recognizes the need for consistent ways to connect AI systems with external tools and data sources. There are emerging open standards in the AI industry that provide a unified way for AI systems to discover and interact with data sources and tools through a client-server architecture. Similarly, function calling (or tool calling) has become a core capability standardized across major AI providers, allowing AI models to invoke APIs in structured ways by generating JSON specifications that match predefined schemas.

These emerging standards for AI-API integration allow AI systems to:

• interpret FHIR resources,

• broker interactions across multiple systems and endpoints,

• automatically transform, validate, or summarize data, and

• assist users in navigating the complexity of health data exchange.

However, it's important to note that this remains a fragmented and rapidly changing space—while multiple approaches are gaining traction, the industry has not yet settled on universal standards the way it has for traditional web technologies.

Key Objectives

There are eight key objectives for projects in this area of interest for the two-year period of performance:

1. Develop or adapt an agentic AI solution for at least one specific clinical and/or clinical investigation workflow (e.g., patient triage, diagnosis support, care coordination, clinical trial enrollment, etc.). The solution could improve an existing process or create a new process that was not feasible without AI.

a. Develop the agentic AI solution using open standards (i.e., publicly available, consensus-driven specifications that promote interoperability) and utilize applicable HHS-adopted data exchange standards. All agentic AI solutions must be compatible with FHIR.

b. The agentic AI solution must be interoperable with third-party client applications developed by unaffiliated organizations.

c. It must be independently implementable across multiple environments to support specific use cases.

d. Ensure that the agentic AI solution complies with all applicable laws, including those related to security and privacy.

e. The agentic AI solution should include appropriate escalation protocols, recognizing when human judgment is needed and making it easy for patients to access human support.

f. The agentic AI solution should clearly inform patients when they are interacting with AI and when a situation requires clinical human judgement.

g. Humans should be able to easily override or modify AI recommendations, with these interactions used as learning opportunities. Developers should also track when and why overrides happen to improve the system over time.

2. Conduct at least one pilot project demonstrating end-to-end agentic AI functionality in a real-world clinical setting of the agentic AI solution.

3. As part of the pilot project, successfully integrate the agentic AI solution with at least two different health IT system platforms, demonstrating cross-platform compatibility.

4. Apply a risk management methodology to evaluate the agentic AI solution used in this project and publish a detailed assessment report. The assessment report must evaluate:

a. The readiness and maturity of the incorporated agentic AI standards for health care applications and the intersection of AI and APIs,

b. The AI-enabled workflow and whether it improves efficiency, accuracy, and/or clinical outcomes compared to non-AI baseline approaches,

c. The usability of the solution, and

d. Whether the solution is ready for use in production environments.

5. Conduct at least one educational workshop or webinar for appropriate stakeholders within 12 months of the award date. The workshop or webinar should document the current state of agentic AI in health IT and provide stakeholders with information about the current status of this project and solution being developed.

6. Applicants must publicly release 100% of developed software components under an open-source license, accompanied by complete technical documentation, installation guides, and user manuals.

7. Submit for publication at least one peer-reviewed paper or white paper documenting project findings, recommendations for use by health IT developers, best practices, and lessons learned by the end of the 24-month period of performance.

8. Form a technical expert panel of key stakeholders to advise the project team throughout the period of performance. The coalition could include approximately 10 stakeholders and meet at least three times during the period of performance. Stakeholders could include but are not limited to clinical and care delivery teams, patients and patient advocates, AI/machine learning engineers, software developers, health IT specialists, privacy and security experts, and clinical informatics specialists. Applicants should include letters of commitment from proposed members of the panel.

Area 2:

Expand Lantern’s API monitoring capabilities by integrating secure, community-driven feedback that complements existing automated checks

Goal

The goal of this area of interest is to enhance Lantern’s ability to monitor FHIR endpoints by adding a secure, community‑driven feedback layer that complements existing automated checks. This project will enable implementers, vendors, app developers, and certification bodies to share actionable information about real‑world API behavior, improving reliability, transparency, and trust in FHIR APIs across the health care ecosystem.

Background

ONC’s Cures Act Final Rule (Cures Rule) supports patients’ and providers’ access to electronic health information through Health Level Seven (HL7®) Fast Healthcare Interoperability Resources (FHIR®) application programming interfaces (APIs). The Maintenance of Certification requirements at 45 CFR 170.404(b)(2) specify that service base URLs, otherwise known as “endpoints,” can be used by patients to access their electronic health information.

The FHIR API Monitoring System, otherwise known as Lantern, was created to help ONC monitor and provide nationwide analytics about the availability and standardization of FHIR endpoints deployed by health care organizations. FHIR endpoints can enable patient access to their electronic health information. The Lantern tool consumes public endpoint information, tests the accessibility of these endpoints, and then reports capability information to its public-facing dashboard. Lantern analytics are positioned to help shine a light on the health care industry’s usage of FHIR APIs and ongoing support of patient access.

Lantern uses data from several sources. It gathers information from FHIR Server Capability Statements—a publicly accessible FHIR resource that can be retrieved from each service’s base URL.

The Capability Statement serves as the primary data source Lantern processes, containing details about each FHIR server. Lantern also queries publicly available FHIR endpoints to assess endpoint availability (uptime) and monitors changes to FHIR APIs that may indicate accessibility issues. By combining these data sources, Lantern provides a picture of FHIR API service base URL availability, the health care organizations implementing them, and the software products associated with these endpoints. It also offers visualizations to illustrate FHIR adoption and patient data availability. Updating the existing Lantern system will bring these perspectives together to accelerate issue detection, support coordinated problem-solving and provide a clearer picture of API performance across provider and payer domains.

In doing so, the updated system will help standardize how those connecting to FHIR endpoints report observable issues—such as authorization failures, empty datasets, errors, throttling, or data staleness— and will aggregate and report them responsibly so that valid problems are surfaced transparently.

Key Objectives

There are six objectives in this area of interest for the two-year period of performance:

1. Identify the types of information related to performance, accessibility, data quality, and implementation experience that would be most valuable to entities seeking to discover, access, and use a range of FHIR endpoints, beyond those currently focused on patient access. This information could be informed by analysis of the Lantern monitoring system, other efforts to gather feedback on endpoint performance (such as Bulk FHIR), and input from stakeholders across the health IT community. Examples of potential data types may include performance issues not currently https://healthit.gov/regulations/cures-act-final-rule/ https://www.hl7.org/fhir/ https://healthit.gov/interoperability/investments/lantern-project/ captured, authentication or authorization failures, assessing the availability or completeness of data, errors encountered during the process of accessing the data, data timeliness, assessing the accuracy of the documentation, and observed workarounds or implementation patterns.

2. Create a technical solution integrated with the Lantern open-source tool that enables the collection and incorporation of the information identified in Objective 1. The project must support standardized data collection, so information is captured in a consistent, structured, and comparable format across endpoints, such as through a structured or semi-structured reporting tool linked to a specific endpoint.

3. Develop visualizations and other features that could be used within the Lantern system for categorizing and displaying community feedback so that feedback is integrated with the information that is currently monitored by Lantern. Additionally, features should accelerate issue detection, support collective problem-solving, and improve transparency.

4. Generate a machine readable, downloadable report at the developer level that summarizes information for each endpoint. For each endpoint, the report should include endpoint status, a summary of community feedback, and the existing monitoring approach. The report must be accessible to download using the technical solution developed in Objective 2.

5. Solutions shall rely on non-proprietary approaches and be independently implementable. The solution must be open-source and available on GitHub with complete technical documentation, installation guides, and user manuals.

6. Form a technical expert panel of key stakeholders to advise the project team throughout the period of performance. The panel could include approximately 10 stakeholders and meet at least three times during the period of performance. Applicants should include letters of commitment from interested parties.

Area 3: Assess laboratory interoperability gaps to improve the adoption and use of standard terminology among small, independent laboratories

Goal

The goals of this area of interest are to assess laboratory data quality and implement existing solutions aimed at improving the adoption and use of standard codes such as Logical Observation Identifiers Names and Codes (LOINC), SNOMED Clinical Terms (SNOMED CT), and Unified Codes for Units of Measure (UCUM) among small, independent laboratories. Projects should assess laboratory data quality and use that information to identify and pilot test different solutions (such as mapping tools) to facilitate the use of correct codes in laboratory data and to transition small, independent laboratories from using local laboratory codes to using standardized terminologies. Projects should focus on solutions that support conformance with national laboratory standards and can be widely implemented by small, independent laboratories.

Background

Quality of laboratory data Laboratory data are a critical piece of information that informs clinical decisions, public health surveillance, research, and population health, among other activities. As noted in the Congressional Report on Standards for Electronic Ordering and Reporting of Laboratory Test Results, robust use of laboratory standards is necessary to enable a common meaning or interpretation of laboratory tests and results between laboratories, providers, public health entities, and other users of these data.4

Despite the importance of using standard terminologies to ensure a common understanding, available assessment data suggest that the use of these standards for laboratory data varies widely – both by standard type and across entities – with smaller laboratories and providers less likely to use standard terminologies. Laboratories’ persistent use of locally defined names, terms, and codes instead of standardized vocabularies hinders data exchange. Due to limited resources, many laboratories and health systems continue to rely on internal codes developed to meet local workflow requirements, legacy system constraints, and historical reporting needs. These locally defined codes lack consistent meaning when shared outside of their originating systems, requiring receiving systems to manually map or interpret data. This increases the risk of fragmented patient data, delays, and misinterpretation of results, and adds operational burden—factors that can negatively impact patient safety, clinical decision-making, public health, and other secondary uses of data. Laboratories may select LOINC codes that do not align with the tests performed, resulting in data quality issues that can also impact patient safety.

Additionally, laboratories may incorrectly map their test catalog.

Newly developed data quality tools are available to help smaller laboratories assess whether they are over-relying on local codes or using incorrect LOINC codes when reporting data to providers and health information organizations. Existing mapping tools are available to help laboratories align their test catalog with nationally recognized laboratory coding standards, such as LOINC, SNOMED CT, and UCUM, to support and enable accurate and efficient data exchange.

Tools to Assess and Improve Data Quality Assessing electronic health record (EHR) data quality involves consideration across several dimensions, including conformance to standards.567 ONC has been unable to specifically measure the quality of laboratory data in terms of conformance to nationally recognized standards. Surveys have not proven to be a reliable measurement approach due to low response rates and lack of awareness of terminologies among respondents.

Data quality assessment tools that leverage real-world data offer promising new approaches to assess conformance to national laboratory standards. Recent analysis of laboratory data from laboratories and health care providers demonstrated it was possible to use real-world data to generate insights on the use of laboratory standards; however, that analysis involved using a customized tool and data from a small number of organizations.8 Researchers can now analyze real-world data using open-source tools that do not require customization and can be used by a broad array of organizations. Tools such as CumulusQ, which received LEAP funding in 2023 and 2020, operationalize data quality measurement by evaluating

4 Report to Congress: Standards for Electronic Ordering and Reporting of Laboratory Test Results. December,19, 2024.

https://www.govinfo.gov/content/pkg/CMR-HE1-00196380/pdf/CMR-HE1-00196380.pdf 5Lewis AE, Weiskopf N, Abrams ZB, Foraker R, Lai AM, Payne PRO, Gupta A. Electronic health record data quality assessment and tools: a systematic review. J Am Med Inform Assoc. 2023 Sep 25;30(10):1730-1740. doi:

10.1093/jamia/ocad120. PMID: 37390812; PMCID: PMC10531113.

6 Weiskopf NG, Weng C. Methods and dimensions of electronic health record data quality assessment: enabling reuse for clinical research. J Am Med Inform Assoc. 2013;20(1):144-51.

7 Kahn MG, Callahan TJ, Barnard J, Bauck AE, Brown J, et.al. A Harmonized Data Quality Assessment Terminology and Framework for the Secondary Use of Electronic Health Record Data. EGEMS (Wash DC). 2016 Sep 11;4(1):1244.

8 Report to Congress: Standards for Electronic Ordering and Reporting of Laboratory Test Results. December 19, 2024.

https://smarthealthit.org/cumulusq/ how EHR data align with interoperability standards encoded in the United States Core Data for Interoperability (USCDI). USCDI serves as a baseline set of data elements for health information exchange and interoperable health IT implementation. USCDI includes laboratory data, with specifications for the use of code systems such as LOINC, to encode these data. These standards-driven approaches, meaning approaches that assess or analyze data against established interoperability standards such as USCDI and LOINC, enable identification of structural and semantic errors, as well as potential approaches to resolve and correct errors.

Data quality tools can evaluate laboratory data to identify instances where data do not conform to nationally recognized standards or rely on using local codes. Determining the types of laboratory tests in laboratory data that are most frequently identified by local codes rather than by national standards is a critical first step towards improving the quality of laboratory data. Identifying commonly performed laboratory tests for which providers select the incorrect LOINC codes in their EHR system is also important to improving the quality of laboratory data. LOINC Regenstrief has a list of the LOINC codes most commonly used in laboratory data exchange.

Tools to Shift away from the Use of Local Codes Once small, independent laboratories identify laboratory tests using local codes, they can take additional steps to ensure that the correct codes from those national standards are used instead. Those steps include focusing directly on reducing the use of local codes by laboratories. Resources are available from LOINC Regenstrief to enable laboratory staff to map local codes to LOINC codes. Examples of these resources include the Regenstrief LOINC Mapping Assistant (RELMA), a mapping utility to search the LOINC database and map local codes to LOINC codes, and SearchLOINC, a web-based tool to search the LOINC database. LOINC Mapping Guides, summaries of best practices for mapping to LOINC across six laboratory domains, are also available. Laboratory information systems may also have their own mapping tools.

Other solutions to shift away from the use of local codes focus on addressing these issues further upstream. One such solution is embedding LOINC codes in the in-vitro-diagnostic (IVD) devices used to test samples outside the body for diagnosing diseases, monitoring health, or guiding treatment.

LOINC to In-Vitro-Diagnostic (LIVD) mapping specifications for IVD devices harmonize how IVD test information is represented using laboratory data standards. LIVD describes the same laboratory test across vendors and laboratories. The LIVD specification has been advanced through the efforts of Systemic Harmonization and Interoperability Enhancement for Laboratory Data (SHIELD), a public-private multi-stakeholder driven endeavor sponsored by the FDA that seeks to build solutions that address interoperability of IVD devices. The SHIELD initiative has developed a small number of LIVD files that provide a definitive source for LOINC to IVD test mapping and has published a white paper on Laboratory Interoperability Data Repository (LIDR), a potential solution for a repository of LIVD files.

Other open-source tools such as Komet also support this goal.

Paired with data quality assessment tools that identify data that does not conform to national standards or that does not accurately use standardized code systems (e.g., LOINC), these mapping tools for laboratories and IVD manufacturers have the potential to improve the quality of laboratory data so that it aligns with national standards.

Key Objectives

There are eight objectives in this area of interest for the two-year period of performance:

https://loinc.org/relma/ https://loinc.org/search-app/ https://loinc.org/guides/ https://www.ikehub.org/tools

1. Identify at least three small, independent laboratories to participate in pilot activities that will improve the adoption and use of standard terminologies and support conformance with LOINC for laboratory test identifiers; SNOMED CT for results, organisms, methods and conditions; and UCUM for units of measurement; and align with applicable USCDI data elements.

2. Conduct a readiness assessment for each participating laboratory to:

a. Understand if the laboratory’s staff are prepared to change their laboratory coding processes,

b. Understand if the laboratory’s IT system is capable of adopting new laboratory coding processes,

c. Identify risks and challenges the laboratory will face in adopting new laboratory coding processes,

d. Identify laboratory coding processes needing improvement,

e. Identify how changes and success will be measured,

f. Identify the most appropriate tools for data quality assessment and mapping, and

g. Identify any other topics the applicant determines to be necessary.

3. After the readiness assessment, pilot test at each participating small independent laboratory at least one open-source data quality tool to identify laboratory tests that the laboratory staff has frequently incorrectly coded or coded using local codes rather than standardized terminologies.

Once laboratory tests that are incorrectly coded or coded with local codes are identified, determine the root causes of incorrect and local code use.

4. Once the tests that are most frequently incorrectly coded or coded using local codes rather than standardized terminologies are identified, pilot test at each participating laboratory, two or more tools to improve the use of standardized terminology. Existing tools are available through LOINC Regenstrief and from the SHIELD community (such as RELMA, SearchLOINC, LOINC Hierarchy Browser, LOINC Mapping Guides, laboratory information system mapping tools, and existing LIVD specifications). The applicant may use these tools or other open-source tools to transform the incorrect or local codes into standard codes to increase the usage of standard codes at each participating laboratory.

5. Describe in a report the results of the readiness assessments and root cause analyses, and lessons learned from the pilot testing of tools that measure the quality of laboratory data and tools that support the use of standard terminologies on a broad scale. Also describe in the report how the tools used can improve consistent adoption and use of nationally recognized laboratory standard codes. Based upon the lessons learned, the report should include specific recommendations to update and improve existing tools to better support use by small, independent laboratories.

Lessons learned should include at a minimum:

o Identification of instances where existing tools or approaches were not effective in addressing laboratory interoperability or standardized code adoption challenges.

o Analysis of the underlying reasons why laboratories continue to rely on local codes or use incorrect standardized codes including technical, operational, workflow, cost, or resource-related factors.

o Assessment of whether and how the solutions address (or fail to address) these underlying drivers, and the implications for adoption and sustained use by small, independent laboratories.

o Identification of gaps or unmet needs that limit the effectiveness or uptake of existing tools and solutions.

o Recommendations for new or enhanced tools, approaches, or capabilities that could better address identified gaps, reduce reliance on local codes, improve the selection of accurate standardized codes, and support broad adoption of standardized laboratory codes.

6. Develop a dissemination plan that includes a public-facing version of the report described in Objective 5 and at least one educational workshop or webinar to share results from the readiness assessments and root cause analyses, lessons learned, and to explain how laboratories can adopt standardized laboratory codes with data quality and laboratory stakeholders.

7. All tools used and any developed processes or suggestions for adopting standardized laboratory codes should be interoperable with third-party client applications developed by unaffiliated organizations to support mapping, validation, and assessment of laboratory standard code usage.

All tools should also be use-case agnostic and support laboratory interoperability by enabling consistent use, validation, and assessment of standardized laboratory codes. Applicants should rely on non-proprietary approaches and propose solutions that are independently implementable and applicable across multiple laboratory data elements, using a technical approach to support diverse laboratory and data quality use cases.

8. Applicants shall include a technical expert panel of key laboratory and health IT stakeholders who will be directly involved in the project, such as laboratory information system (LIS) vendors, leadership from small and independent laboratories, developers of third-party laboratory data quality or terminology tools, public health partners, and members of the laboratory and health IT standards communities. Applicants should include letters of commitment from proposed members of the coalition of key laboratory and health IT stakeholders.

Applicants for an award in this area of interest shall include the following in their application:

• Describe in detail the technical barriers that impede laboratory interoperability, including challenges related to the adoption and use of standardized laboratory codes, data quality, conformance to national laboratory standards, and integration with third-party applications.

• Describe in detail technical solutions to the barriers, including:

o Sufficient technical details to demonstrate that the proposed solution is based on non-proprietary technologies and leverages open-source tools.

o A detailed plan on how the applicant plans to conduct the readiness assessment for using data quality and mapping tools (Objective 2).

o A detailed plan on how the applicant intends to complete the pilot tests described in

Objective 3 and Objective 4.

o How the proposed project will inform future improvements to technical infrastructure supporting laboratory interoperability and standards-based laboratory data exchange.

• Identify an approach to improve the exchange and use of standardized laboratory data while adhering to applicable data security and privacy requirements, including compliance with the HIPAA Privacy Rule9 and other relevant regulations.

Performance Goals and Objectives

A performance goal is a target level of performance expressed as a tangible, measurable objective, against which actual achievement can be compared.

9 Standards for Privacy of Individually Identifiable Health Information, 45 C.F.R. pts. 160 & 164 (2000)

ONC will utilize the following objectives to assess project performance and progress:

• The quality of the two-year project plan and the description of how performance goals and key objectives will be met.

• The identification and securement of subject matter experts (SMEs), as appropriate, to provide guidance and review strategies, research methods, and results.

• Scheduling, conducting, and participating in status, strategy and/or SME meetings with ONC and the panel of key stakeholders.

• Communicating findings and providing quarterly programmatic progress reports, including a risk mitigation plan to ensure timely deliverables.

B. Funding Opportunity Award Information

Key Award Parameters

Title: Leading Edge Acceleration Projects (LEAP) in Health Information Technology

Federal Funding Agency: Department of Health and Human Services Office of the National Coordinator for Health Information Technology

Announcement Type: Cooperative Agreement

Application Type: New

Funding Opportunity Number: NAP-AX-26-001

Catalog of Federal Domestic Assistance (CFDA) Number: 93.345

Eligible Applicants:

This is a competitive funding opportunity open to public or non-profit private institutions, such as a university, college, or a faith-based or community-based organization; units of local or state government, eligible agencies of the federal government, Indian/Native American Tribal Governments (federally recognized, other than federally recognized, and tribally designated organizations).

For-profit organizations may participate in projects as members of a consortia or as a sub-recipient only. Because the purpose of this NOFO is to improve health care in the United States, foreign institutions may participate in projects as members of a consortia or as a sub-recipient only.

Applications submitted by for-profit organizations or foreign institutions will not be reviewed.

Organizations described in section 501(c)4 of the Internal Revenue Code that engage in lobbying activities are not eligible.

HHS grants policy requires that the grant recipient perform a substantive role in the conduct of the planned project activity and not merely serve as a conduit of funds to another party or parties. If consortium/contractual activities represent a significant portion of the overall project, the applicant shall justify why the applicant organization, rather than the party(s) performing this portion of the overall project, should be the recipient and what substantive role the applicant organization will play.

Applicant organizations may submit more than one application, provided that each application is scientifically distinct.

Legislative Authority: Further Consolidated Appropriations Act, 2026 (FY2026 LHHS omnibus;

H.R.7148; P.L. 119-75)

Approximate Amount of Available Funding (inclusive of direct and indirect costs) :

Anticipated Number of Awards: Up to 3 (1 award per Area of Interest) https://www.congress.gov/bill/119th-congress/house-bill/7148 https://www.congress.gov/bill/119th-congress/house-bill/7148/text

Approximately Amount of Each Award: Up to $1,000,000 (Area 1) Up to $500,000 (Areas 2 and 3)

Anticipated Project Period: September 26, 2026 – September 25, 2029

Anticipated Budget Period(s): September 26, 2026 – September 25, 2028

Funding of future non-competing continuation awards will be determined by ONC and is conditioned on the availability of funds, satisfactory progress by the recipient, and an awarding office determination that continued funding of the award is in the best interests of the Government.

Cooperative Agreement and Substantial ONC Involvement

The funding instrument used for this program will be the cooperative agreement, an assistance mechanism in which substantial ONC programmatic involvement is anticipated during the project period. Under the cooperative agreement, the ONC purpose is to support and stimulate the recipient’s activities by involvement in, and otherwise working jointly with, each recipient in a partnership role.

ONC’s role is not to assume direction, prime responsibility, or a dominant role in the activities.

Consistent with this premise, the dominant role and prime responsibility resides with the recipient for the project as a whole. To facilitate appropriate involvement, during the period of this cooperative agreement, ONC and the recipient will be in contact monthly and more frequently when appropriate.

ONC involvement may include, but is not limited to:

• Participating in monthly (minimum) check-in meetings.

• Ensuring compliance of timely programmatic reporting, project progress, and other terms and conditions of the award.

• Reviewing and approving quarterly programmatic progress reports.

o Quarterly programmatic progress reports are due one month after each quarter (January, April, July, and October).

• Participating in the selection of key personnel.

• Releasing funds based on achievement of performance goals and objectives.

• Agency reviewing and approving of substantive provisions of proposed subawards or contracts.

• Reviewing and approving deliverables.

• Selecting meeting/panel members and subject matter experts.

• Participating in communities of practice.

• Providing tactical guidance and feedback during project execution.

• Engaging with leadership of the recipient’s organization to ensure successful execution of the cooperative agreement.

• Ending an activity if performance specifications are not met.

Program Income There are four potential ways in which ONC may require that a recipient apply program income as specified in the Notice of Grant Award (NGA): 1) deduct it from total allowable program costs to determine the net allowable costs on which the Federal share of costs is based; 2) add it to funds otherwise available for the program, generally resulting in an increase to the total approved budget; 3) use it to meet a matching or cost sharing requirement; or 4) a combination of these alternatives.

Costs paid by program income generally are subject to the applicable cost principles and other Federal requirements and shall be disbursed for program purposes before requesting additional payments of Federal funds. In the event program income remains at the end of the award, the additional income is considered part of the award funding and shall be returned to ONC. If program income is generated, the recipient shall use the additive method.

Intergovernmental Review

Applications for this Cooperative Agreement are not subject to review by states under Executive Order 12372, “Intergovernmental Review of Federal Programs” (45 CFR 100). Please check box “C” on item 19 of the SF 424 (Application for Federal Assistance) as Executive Order 12372 does not apply to this Cooperative Agreement.

Key Dates

Milestone Date NOFO Released

June 16, 2026

Informational Session

June 23, 2026

Letters of Intent Due

June 30, 2026

Applications Due

July 16, 2026

Anticipated Award Date

September 26, 2026

Anticipated Project Start Date

September 26, 2026

Anticipated Project End Date September 26, 2028

Informational Session

ONC will conduct an informational session, via a webinar, to:

• Discuss the background, purpose, scope, terms and conditions and other provisions in the NOFO;

• Explain the eligibility and application requirements;

• Describe the application review process; and

• Provide an opportunity for interested parties to ask questions.

Further details about the informational session – including the date, time, and instructions for joining – are available on healthit.gov.

To ensure that ONC addresses all comments and questions regarding this announcement during the information session, please submit any comments and questions, via email, to ONC-LEAP@hhs.gov no later than three days prior to the call.

Letter of Intent mailto:ONC-LEAP@hhs.gov

Although not required, applicants are strongly encouraged to submit a non-binding e-mail letter of intent to apply for this funding opportunity. This letter of intent will assist ONC in planning for the application review process.

The Letter of Intent is requested by 11:59 P.M. Eastern Time on June 30 and should be sent to ONC- LEAP@hhs.gov. The notice should identify the name of the applicant organization, the city and state in which the applicant organization is located, the Notice of Funding Opportunity title and number, and the area of interest the applicant organization will apply to. No information about project plans is necessary.

C. Eligibility Information

See Section B, Funding Opportunity Award Information, for eligibility, cost-sharing, and other key award information.

D. Application and Submission Information

Application Package

The following documents comprise, as applicable, the application package. Additional information regarding each of these documents is further provided. Tips for writing a strong application are available in Appendix A.

The application package:

• Project Abstract

• Project Narrative

• Appendices o Form SF-424, Application for Federal Assistance o Form SF-424A, Budget Information for Non-Construction Programs o Form SF-424B, Assurances for Non-Construction Programs o Form SF-LLL, Disclosure of Lobbying Activities o Budget Narrative Justification o Letters of Commitment o Proof of Non-Profit Status (if, applicable) o Indirect Cost Agreement(s) – including recipient, sub-recipient, and contractors’ agreements (if applicable)

Project Abstract Applicants shall include a one-page abstract that is no more than 500 words. This abstract is often distributed to the public and Congress and represents a high-level summary of the project. As a result, applicants should prepare a clear, accurate, and concise abstract that can be understood without reference to other parts of the application and that provides a description of the proposed project, including the project’s goal(s), objectives, overall approach, anticipated outcomes, products, and duration.

The applicant shall place the following information at the top of the Project Abstract (this information is not included in the 500-word maximum):

• Project Title

• Area of Interest

• Applicant Name

• Physical Address

• Contact Name

• Contact Phone Numbers

• E-Mail Address

• Web Site Address, if applicable

Project Narrative The project narrative should describe the proposed project in a clear and concise manner. The project narrative should address the elements articulated in the Areas of Interest section of this NOFO. The project narrative should also align with the Performance Goals and Objectives and Merit Review criteria presented in this NOFO.

The maximum length allowed for the project narrative is 35 pages. A project narrative that exceeds the 35-page limit will not be accepted. Resumes of key personnel (personnel required for the project), are not counted as part of the project narrative and are not included in the 35-page limit.

The project narrative sections of the application shall be double-spaced, on 8-1/2” X 11” plain white paper with 1” margins on all sides and use either Cambria or Times New Roman font size of not less than 11 point. Smaller font sizes may be used to fill in the Standard Forms, exhibits, and figures, though all text in forms, exhibits, and figures shall not be smaller than 8-point font.

The project narrative should include the following components.