Policy & Regulation
Featured illustration: This generated image represents a product concept. It is not an NIH system, endorsement, or verified commercial product.
Opportunity score: 66/100. Recommendation: investigate before building.
A federal reporting change can create a software opening, but only when the new administrative pain is expensive enough to make people replace the tools they already use.
That is the question behind a possible NIH Data Management and Sharing evidence tracker. Beginning in fiscal year 2027, NIH expects existing awards and applications covered by its Data Management and Sharing Policy to align with an updated DMS Plan format. Active awards will transition through the Research Performance Progress Report process, and NIH says recipients must use RPPR Section C.5.c beginning October 1, 2026, to report progress and notify NIH about changes such as different repositories or sharing timelines.[1]
This is a real operational change. It is not yet proof of a software business.
What NIH is changing
The underlying NIH Data Management and Sharing Policy is not new. The updated format is intended to standardize plans and improve reporting. NIH says the format change does not change the policy itself.[1]
The transition reaches beyond new applications. NIH’s July 2026 implementation notice says active awards subject to the 2023 policy must move to the updated format at the next RPPR. Awards that were subject to the older 2003 data-sharing policy and are expected to generate scientific data must provide an updated-format plan with the FY2027 RPPR.[1]
Research organizations already report on DMS activity. NIH’s 2024 RPPR questions ask whether data has been generated, whether it has been shared, its status when it has not been shared, the repository and unique digital identifiers when it has, corrective actions for missed commitments, and anticipated plan changes.[2]
The FY2027 change may increase the number of awards that research offices must bring into a common structure at roughly the same time. That is the business signal.
The possible product is an evidence tracker, not another plan writer
A weak product would compete directly with document templates and free plan-writing tools. A stronger product would sit between the approved DMS Plan and the annual report.
Its job would be to answer six practical questions for every NIH-funded project:
- What did the approved plan promise?
- What data has actually been generated and shared?
- Which repository received the data?
- What repository link or persistent identifier proves the deposit?
- What changed, slipped, or still needs corrective action?
- Who owns the next action and who confirmed it?
That suggests a small portfolio dashboard rather than a broad research-administration platform. Each award would have its approved commitments, responsible people, expected dates, current repository, identifiers, change history, unresolved issues, and supporting evidence. Before an RPPR is due, the system could produce an administrator-reviewed evidence packet instead of forcing staff to reconstruct the year from email, spreadsheets, shared drives, and individual investigators.
The important boundary is that software would organize evidence and workflow. It would not decide whether a project complies, replace the institution’s signing official, or submit an NIH report without human review.
Why the score is only 66 out of 100
The regulatory signal is credible. The willingness-to-pay signal is not.
NIH has described the new format as simpler and intended to reduce administrative burden. Its February 2026 notice says NIH institutes and centers had evaluated more than 1,100 DMS Plans, and the majority were acceptable initially or after minor revisions.[3] That cuts against a breathless claim that every research office suddenly faces a crisis.
There is also a strong free incumbent. DMPTool describes itself as a free, community-supported service for creating machine-actionable data management and sharing plans. It offers funder-specific templates, institutional customization, collaboration, feedback, guidance, and DMP identifiers.[4]
DMPTool is aimed heavily at creating and improving plans. The possible opening is post-award portfolio tracking and annual reporting evidence. But that distinction may not be large enough to support a separate subscription. Universities may extend DMPTool, add fields to an existing grants platform, or keep using spreadsheets and shared drives.
A founder should assume the cheap tools are good enough until research administrators say otherwise.
A narrow first version
If interviews uncover real pain, the first version should do less than most software founders will want it to do.
A credible pilot could include:
- A portfolio view of NIH awards and upcoming RPPR dates
- A record of approved DMS commitments by project
- Repository name, deposit status, link, and persistent identifier
- Named owners for investigator, data steward, library, and research-office tasks
- Change and delay notes tied to dates and people
- Evidence uploads or links with an administrator signoff field
- A review screen mapped to the information NIH asks for in RPPR reporting
- Exportable evidence summaries for human review
It should not start with automatic eRA Commons submission, artificial-intelligence compliance judgments, or a promise that the software guarantees NIH compliance. Those features add risk before the buyer problem has been proven.
The product also should not store research data. It should store administrative metadata and evidence references whenever possible. Keeping scientific data, protected health information, or other sensitive material out of the product would reduce security and privacy exposure.
Pricing is a hypothesis
A reasonable interview price card might be:
- $149 per month for a small portfolio
- $399 per month for a department or larger portfolio
Those numbers are not validated market prices. They are a way to force an honest conversation. If administrators like the demonstration but will not discuss a paid pilot at either level, the problem may be useful without being valuable enough to support a standalone company.
A services-assisted pilot may be easier to sell than self-serve software. The founder could import several awards, map each approved plan, configure the evidence fields, and help the office prepare one reporting cycle. That would reveal whether the recurring work belongs in software or whether the real opportunity is consulting and implementation.
The ten-interview test
Do not build the full product first.
Create a fake but realistic working example using fictional projects. Show a dashboard with three awards: one on track, one waiting for a repository identifier, and one with a delayed sharing timeline. Include an RPPR preparation view and a clear audit trail showing who supplied each item and who reviewed it.
Then show it to ten people who actually manage NIH research administration, sponsored programs, research data services, or institutional reporting.
Ask:
- How do you track this today across multiple awards?
- What breaks or consumes time before an RPPR is submitted?
- Which existing system should already solve this?
- What evidence do you chase repeatedly from investigators?
- Would you pay for a pilot this reporting cycle, and from which budget?
The minimum signal should be three people willing to pay for a bounded pilot, not three people saying the idea is interesting. Ask for a real next step: a paid design-partner agreement, a purchase process, or permission to scope a pilot with the budget owner.
If fewer than three of ten will pay, stop or reposition. Possible alternatives include a managed DMS reporting service, an add-on for an existing research-administration system, or a workflow package built around tools the institution already owns.
The decision
This opportunity earns 66/100 because the federal change is verified, the administrative workflow is understandable, and the first demonstration would be inexpensive. It does not score higher because free and embedded alternatives are credible, institutional sales can be slow, and no paying customer has been established.
The next move is not product development. It is ten buyer conversations built around a realistic evidence-tracking demonstration.
Driving Virginia will continue separating verified policy changes from software ideas that merely sound plausible. Virginia founders, research administrators, and economic-development partners testing this problem can contact Driving Virginia with the workflow they use today. This article is opportunity analysis, not NIH compliance or legal advice.