NIH RFA-CA-27-020: Advanced Development of Informatics Technologies for Cancer Research and Management (U24)

NIH RFA-CA-27-020: Advanced Development of Informatics Technologies for Cancer Research and Management (U24 Clinical Trial Optional)

RFA-CA-27-020 is part of the NCI Informatics Technology for Cancer Research (ITCR) portfolio and targets advanced development, enhancement, and dissemination of informatics tools for cancer research. The title is technical, but the implication is practical: NIH is funding software, methods, and data systems that can move the field forward, not pure concepts in search of a problem.

It is posted as a U24 cooperative agreement (Clinical Trial Optional) with a published date of May 21, 2026, earliest opening date of June 1, 2026, and two main NIH due windows listed in the key dates (July 1, 2026 and October 19, 2026). NIH commits $2,600,000 in FY2027 for an estimated 3 awards, and the NOFO defines a budget ceiling of $600,000 in direct costs per year (excluding consortium F&A), with project periods up to five years.

This is a current window, not a historical reference opportunity. If you were looking only for a permanent list item in the distant past, this one is actively configured as open for this cycle and relevant to the 2026/2027 timeline.

Key details

What this opportunity is genuinely for (and what it is not)

A common mistake is reading “informatics” and assuming this is a pure discovery grant for academic computing research. The NOFO is narrower and more implementation oriented: it funds advanced development and enhancement of informatics technologies that have already moved beyond early pilot stage and can materially improve cancer research across the continuum.

The mechanism is U24, which has a distinct profile versus classic R01-style grants. It emphasizes sustained development, maturation, interoperability, and community use, with NIH’s expectation of post-award scientific/programmatic involvement. In this NOFO, the required collaborative ethos appears in several places: tools must be useful to end users, plans must account for feedback from active researchers, and awardees should show routes to broader deployment through collaboration, outreach, training, and technical dissemination.

What the NOFO explicitly includes:

• Cancer biology, prevention, epidemiology, diagnostics, treatment, early detection, supportive care, and population-level translational contexts.
• Software and technical resources that improve acquisition, analysis, visualization, interpretation, and integration of data.
• Tool strengthening projects where the technology is real, already developed enough to be improved, and likely to improve existing research workflows.

What it explicitly excludes from review:

• Proposals where most of the budget is raw data generation (>10% of annual budget).
• Exploratory or very early-stage technology work.
• Proposals that are merely applying existing methods without clear development of a tool or resource.
• Projects without evidence of the current version and state of existing software being enhanced.

If your idea sounds like a pure algorithm paper or an early-stage hypothesis concept, this is likely the wrong mechanism. This one fits teams that have code, prototypes, and real users already engaged.

Why this is tied to the ITCR program strategy

This call is not standalone. The opportunity text repeatedly places the work inside ITCR’s broader aim: improving data-driven cancer research through interoperable, usable, and community-facing informatics tools. The review and post-award expectations reflect this:

• Collaboration beyond your immediate group is expected, not optional.
• Outreach, training, and usability are central because NIH wants adoption, not just technical novelty.
• Collaborative activities are budgeted and expected, with required set-aside logic from year two onward.
• NIH explicitly mentions cross-network and post-award expansion activities (for example, API integration, interoperability work, and adaptation to additional research contexts).

For proposal strategy, the implication is straightforward: describe how your technology fits into real workflows outside your institution, not only how cool the algorithm is.

Eligibility details and compliance gates

This is one of the biggest practical differentiators. Many teams skip these lines and then lose time fixing ineligible setup issues late. The NOFO is unusually broad on organization types, but strict on compliance and submission architecture.

The following broad organization groups are listed as eligible in the notice:

• Higher education institutions (public and private)
• Nonprofits (including 501(c)(3) and other nonprofit entities)
• For-profit organizations including small businesses
• Local, state, county, city, and tribal governments
• Federally eligible agencies
• A set of additional organizational structures including independent school districts and faith-based/community organizations
• Non-domestic organizations are specifically listed as eligible entities, and foreign components are not impossible, but
• No foreign subawards or subcontracts may be included.

So this is open in principle but constrained operationally. Foreign entities may participate as components or entities, but if you plan international contracting, this call is not the right mechanism and may be flagged.

Registration is a hard gate:

1. SAM registration (including UEI and CAGE/NCAGE as applicable)
2. eRA Commons registration
3. Grants.gov registration

Missing registrations are a known cause of late or noncompliant submissions. The NOFO notes that registrations can take weeks, and late completion is not accepted as a reason to miss the deadline. For teams starting after a posting date, registration backlog is your first planning line item.

PI requirements are also strict:

• All PD(s)/PI(s) must have valid eRA Commons IDs.
• PI(s) must be linked to ORCID IDs.
• Multi-PI teams can apply, but must comply with NIH multi-PI policy.
• Minimum PI effort is built in: 1.8 person-months/year for single-PI, 1.2 person-months/year for each PI in multi-PI.

Cost sharing is not required, which matters: unlike some NIH mechanisms with mandatory matching components, this one does not demand institutional match. The barrier is compliance quality rather than co-financing.

Funding structure and practical planning around budget

The NOFO sets straightforward funding constraints:

• Total commitment intent: $2.6M in FY2027
• Estimated awards: 3
• Per-award budget cap: $600,000 Direct Costs per year
• Project duration: up to 5 years

That combination implies competition is selective, and budget quality can be as important as technical quality. Reviewers and program staff are likely to look for projects where every proposed line can map to a mature technical milestone and a measurable pathway to adoption.

Special budget item to notice: from budget period 2 onward, applicants must set aside 10% of direct costs as collaborative funds. These funds should support collaboration with qualified groups and are reviewed for relevance by ITCR steering structures. In practical terms, this means you should budget for partnership work from the start, not as a last-minute add-on.

The NOFO also requires annual travel to at least one ITCR meeting for one team investigator. This is operational but often missed in early drafting. The meeting location varies, so include a realistic travel line with a year-by-year rationale.

Who this is best for

Strong candidates generally share five characteristics:

1. Technology maturity: Existing software/resource already exists with evidence of adoption or near-adoption.
2. Specific cancer-research problem: A clearly identified technical gap in cancer biology/epidemiology/clinical/translational workflows.
3. User design: A defined pathway for engagement with end users, not only developers.
4. Validation mindset: A reproducible plan for benchmarking model/tool performance and security/privacy protections.
5. Dissemination discipline: A plan for making outputs usable outside your lab (documentation, training, release process, licensing, interoperability).

This is a good fit for teams with one of these profiles:

• Multi-disciplinary informatics groups with cancer collaborators.
• Academic labs operating clinical or translational platforms where software is central.
• Consortia-backed teams with established user communities and deployment pathways.
• Organizations with internal compliance systems already aligned to NIH submission workflows.

If your team is mostly discovery-based without clear user integration and no current deployment plan, this opportunity will likely underperform in review.

Timeline planning for this cycle

Key dates from the NOFO:

• Posted: 2026-05-21
• Open: 2026-06-01
• Deadlines: 2026-07-01 and 2026-10-19
• Expiration of opportunity: 2026-10-20

A pragmatic schedule:

• Week 1-2: Validate eligibility, map your applicant organization, and begin/confirm registrations.
• Week 3-4: Finalize target technology scope, partner letters, and user engagement plan.
• Week 5-6: Draft Research Strategy with explicit milestones and collaboration logic.
• Week 7-8: Build and lock administrative pieces (registration proof, budget logic, DMS plan requirements, ORCID/eRA checks).
• Week 9+: Run technical and compliance check against NIH-specific instructions, then submit early.

For teams with complex institutions, the “early submission” path is realistic even if first deadline is early July. NIH explicitly advises early submission because technical errors are common and corrections must be in before the due date.

Application pathway and required submission artifacts

The NOFO gives three official paths:

• NIH ASSIST
• Institutional S2S via Grants.gov with eRA tracking
• Grants.gov Workspace with eRA Commons tracking

In practice, the path can matter less than pre-submission readiness. Reviewers focus on content quality, but administrative systems are strict gatekeepers; an otherwise strong proposal can fail if package-level compliance is weak.

From the NOFO instructions and standard NIH policy, prepare with these components:

• Full Research Strategy section aligned to reviewer criteria
• User engagement and adoption plan
• Performance evaluation plan for model/software
• Collaborative activities statement and budget set-aside narrative
• Security and privacy considerations
• Data Management and Sharing plan (DMSP format)
• Resource sharing plan (especially for software output)
• Software and model sharing plan with license and accessibility approach
• Evidence of current software maturity (repository, running instance, installation route, or similar support artifact)

For machine-learning-related proposals, model card requirements are explicitly called out: model purpose, use cases, limitations, training data, and evaluation information are expected in a structured plan.

What reviewers are likely to score highly on

The review criteria are the NIH standard structure with program-specific emphasis:

• Significance: Does the project clearly address an existing gap in cancer research with a plausible pathway to impact?
• Investigator capability: Can the team demonstrate both technical and collaborative capability?
• Innovation: Is the proposed technology demonstrably distinct from existing options?
• Approach: Are milestones realistic? Is there a rigorous plan for validation, security, and integration?
• Environment: Is the institutional environment adequate for sustained software/informatics development?

Program-specific review language puts additional weight on:

• evidence of an existing tool and its current status,
• end-user engagement and support,
• algorithm validity and transparency,
• security and privacy controls,
• post-award collaborations and interoperability plans.

Reviewer expectations are therefore not satisfied by generic claims. They expect a concrete chain: existing technology → user needs → improvement plan → validation plan → dissemination strategy.

Common mistakes that reduce competitiveness

1. Treating this as a pure innovation-funding idea without an existing software base. The NOFO explicitly seeks advanced development, not exploratory pilots.

2. Using vague collaboration language. Statements like “we will collaborate with researchers” without named contacts, usage cases, or workflow design are weak.

3. Ignoring non-responsiveness rules. If data generation dominates your budget, or your proposal is mainly analysis reuse with no development, it likely becomes non-responsive.

4. Underestimating the registration burden. SAM/eRA/Grants.gov delays are common in first-cycle submissions.

5. Underbudgeting for required collaboration and annual travel costs. These are explicitly defined and should be real, not placeholders.

6. Weak software-sharing plan. Plans must be realistic. Open-source licensing is encouraged, and restrictions should still support scientific reuse and extension.

7. Submitting late or incomplete technical sections. The NOFO is explicit: late/corrected submissions after deadline can be considered late and non-compliant.

8. Assuming foreign subawards are allowed. This is one of the highest compliance risks in this specific opportunity. Non-U.S. entities can be part of the application, but foreign subcontracts are not allowed.

FAQ for fast decision-making

Is this only for US-based organizations?

The NOFO allows several non-domestic entities and foreign components, but it is strict on foreign subawards/subcontracts. If your budget structure depends on those, verify eligibility before finalizing scope.

Is there cost sharing?

No cost sharing requirement is stated.

Is this a grant or a cooperative agreement?

Funding instrument is a cooperative agreement (U24). In NIH terms, this means NIH staff can have substantial programmatic involvement.

Are clinical trials required?

No. This is clinical trial optional.

What is the budget ceiling?

Direct costs are limited to $600,000 per year.

Can a project submit more than one application?

Yes, if each application is scientifically distinct and not overlapping or duplicate under review.

Submission checklist before you start drafting

Use this as a pre-application gate list:

• Confirm PI, organization, and collaborator institutional details are final.
• Confirm all registrations are active (SAM, eRA, Grants.gov).
• Confirm ORCID links for all key personnel.
• Gather concrete evidence of current software state (repo, running instance, docs, or reproducible install path).
• Define user community and engagement strategy with named collaborators.
• Draft measurable milestones per year and align 10% collaboration funds with concrete plans.
• Draft software sharing, model sharing, and DMS plans.
• Draft training, outreach, and documentation strategy.
• Validate page limits and component instructions from NIH guidance.
• Build and review a schedule that includes internal compliance checks before first due date.

Final takeaway

RFA-CA-27-020 is not a generic AI for health grant. It is an advanced development instrument for technology that already exists in some form and can be improved in a way that materially benefits the cancer research ecosystem. The “open window” nature, hard compliance requirements, and explicit non-responsiveness exclusions make this a high-discipline opportunity: teams that combine scientific depth with operational readiness usually outperform stronger-sounding but less structured teams.

If your team has a real informatics artifact already used by researchers, a realistic roadmap to improve adoption, and the administrative capacity to execute strict NIH submission controls, this is one of the better 2026/2027 cancer-focused technology routes.

Official links

• Official NOFO: https://files.simpler.grants.gov/opportunities/21641587-9295-49dc-811b-95337df4af5c/attachments/3e265edd-9e45-4b63-8761-312a02b836cb/RFA-CA-27-020-Full-Announcement.html
• NIH How to Apply guide: https://grants.nih.gov/grants/how-to-apply
• NCI ITCR program page: https://www.cancer.gov/about-nci/organization/cssi/research/itcr
• Grants.gov (NOFO ecosystem): https://www.grants.gov/