MRAP, the NFL Foundation's Medical Research Approval Program, runs today on a single module of GAMS, on a version old enough that changing anything means changing nothing. So rather than propose a rebuild, we built one. It is live, it covers the whole request‑to‑decision path, and it does several things the GAMS module never could.
The fastest way through this proposal is to open the prototype and click around. Everything below is here to give that a frame.
Every research funding application the NFL Foundation receives has to be captured, sent to the right approvers in the right order, chased when someone goes quiet, and recorded when a decision lands. Today that happens through one module of a platform that can't be safely upgraded, with the rest of the work happening in inboxes and spreadsheets around it.
A purpose-built application for MRAP specifically, not a grants suite configured until it roughly fits. It carries the whole lifecycle from a saved draft to a recorded decision, and it is designed around the fact that the NFL Foundation's approvers are busy people who should not have to learn a system to say yes.
Live and clickable. Everything on this tab is something you can go press.
The status every investigator and administrator sees, on every request: the same three steps end to end.
An investigator, an administrator, and an approver want completely different things from this system. Each gets their own surface.
These are the pieces that go beyond replacing the GAMS module. They are the reasons the new platform changes how the program actually runs day to day.
Approvers act in a defined order. Each approver's clock and their reminders start only once the person above them has approved, so nobody gets chased for a decision they can't make yet.
A pending approval becomes "due" after a configurable number of idle days. Auto-send handles them on a schedule, or the team keeps a manual queue and sends with one click. Every reminder is kept in history with how it was sent.
When an approver gives their answer by phone or in a hallway, an admin records it, and the request permanently shows that an administrator entered it on their behalf. Honest audit trail instead of an untraceable status change.
The review team requests additional materials; the investigator sees a banner, writes a response, and attaches files. Both sides stay on the request instead of in a thread nobody else can see.
Who did what, and when: routing, decisions, follow-ups, status changes. Visible to the investigator too, so the program's fairness is legible rather than asserted.
Four reference sets plus the accounts behind them, all maintained in‑app. Each supports active/inactive, so retiring an option drops it out of new dropdowns without touching a single existing record.
The categories investigators pick from. Each shows how many requests it holds, and drills through to all of them.
The institutions investigators belong to.
A reusable directory. Routing a request auto-fills a saved approver's name and email, or takes a brand-new one.
Name, abbreviation, city, conference, division, and colors. Official team logos render throughout MRAP.
Created and managed by an administrator, with password resets. Investigators sign in and track their own requests.
Administrators and super users, plus the reminder threshold and auto-send toggle, all in-app, with no database edits.
The right-hand column is what the prototype does today, and every row is something you can go click. Parity with the GAMS module was the floor, not the goal.
| Capability | GAMS today | New MRAP platform |
|---|---|---|
| Submitting an application | ||
| Structured application formResearch type, proposed use, title, hypothesis, description | ✓ Yes | ✓ Yes, with guidance on every field |
| Investigator details auto-filledPulled from the profile, never re-typed | × No | ✓ Yes |
| Save a draft, then track it to a decisionFinish later, and see status without emailing to ask | × No | ✓ Yes |
| Routing and approving | ||
| Route to named approversAssign who decides, in what order | ~ By email, outside the system | ✓ Yes, in the system |
| Sequential approval orderEach approver's clock starts when the one above approves | × No | ✓ Yes |
| Approvers act without an accountOne tokenized link, no password | × No | ✓ Yes |
| Record a decision on an approver's behalfLogged as entered by an administrator | ✓ Yes | ✓ Yes |
| Chasing and visibility | ||
| Automated reminders to quiet approversConfigurable idle-day threshold, sent automatically or from a queue | × Manual chasing | ✓ Yes, auto or manual queue |
| Pipeline dashboardAwaiting routing, under review, follow-up, approved, reminders due | × No | ✓ Yes |
| Activity timeline per requestWho did what, when | × No | ✓ Yes |
| Administration and follow-up | ||
| Request additional materials in-systemWith multi-file attachments on the request, not a side email thread | × No | ✓ Yes |
| Self-service reference dataResearch types, organizations, approvers, NFL teams | ✓ Yes | ✓ Yes, with active/inactive and usage counts |
| Works on phone and tabletOff-desk access for approvers especially | × No | ✓ Yes |
A fixed cost to finish and launch the platform, then a single monthly line covering hosting and support. No per‑seat licensing, since approvers don't have accounts to license, and no separate maintenance contract to negotiate later.