An Institutional Review Board exists to protect the rights, safety, and welfare of human research participants. It does that by independently evaluating whether proposed research satisfies regulatory and ethical requirements before approval and, where required, throughout the conduct of the research. IRB software should fully support the board in fulfilling those responsibilities, and should serve as the system of record that keeps accurate documentation securely maintained and accessible to the appropriate people when they need it.
Most institutions weighing IRB software for research institutions already run a system. What they must consider is whether the existing system still supports the program they now operate.
A system can be functioning, familiar, and fully deployed while quietly failing the program around it. Approval dates drift into spreadsheets. Reliance agreements accumulate in a shared drive. Every policy change waits behind a vendor ticket. None of this appears as an outage, so nobody raises it. It surfaces as a lapsed approval, a slow audit response, or a research leader asking why median turnaround has not moved in three years.
This guide is written for the people who have to answer that question at an R1 or R2 institution: the IRB director, the Associate Vice President or Vice President for Research, the Institutional Official who signs the Federalwide Assurance, and the research administration leaders who will sit through the demonstrations.
It works through three things. First, how to assess whether your current environment is still fit for purpose. Second, what has changed in the regulatory and operational landscape that your system now has to support. Third, how to evaluate replacement options.
Part one: Is your current system still fit for purpose?
The signs below come up repeatedly in evaluations at research-intensive institutions. They are ordered by institutional risk, starting with the ones that create reportable events. If three or more describe your environment, the case for reassessment is usually already made.
Approval dates live outside the system
Across several thousand active protocols, the continuing review obligation now differs study by study. Some studies carry an annual review date because they are FDA-regulated or were approved by the convened committee. Others carry none, because the 2018 Requirements removed the obligation for research eligible for expedited review. The distinction is set at approval and has to be held against each study rather than applied as one portfolio rule.
The institutional consequence is concrete. When approval lapses, research activity has to stop, unless the IRB determines that continuing is in the interest of participants already enrolled. The lapse itself then becomes something the office has to document and explain. One missed date can suspend enrollment, delay a sponsor milestone, and generate a corrective action plan.
The audit response has to be assembled before it can be given
When the Office for Human Research Protections (OHRP), the FDA, a sponsor, or an Association for the Accreditation of Human Research Protection Programs reviewer asks for the review history on a named protocol, the institution has to produce it on their timeline, not its own. If the answer lives across a submission tool, an email thread, and a shared drive, someone has to reconstruct it first. Reconstruction is slow, and it leaves gaps that are visible to the reviewer.
The exposure sits with the institution. The Institutional Official signs the Federalwide Assurance, not the study team.
Reliance volume has outgrown the tool
Institutions that took on more cooperative research after 2020 now handle reliance agreements, relying-site notification, and site-specific local context as routine weekly work. Systems built for single-site review absorb this through email and manual tracking. The gap tends to show up first in the reliance documentation an auditor asks for, and second in the time it takes to activate a site.
Turnaround is the number leadership hears about
Incomplete submissions returned for correction restart the queue and add weeks before substantive review has even begun. Investigators experience that as the IRB being slow. It escalates to research leadership as a complaint about the office rather than about the software, which means the office absorbs a reputational cost created by a system limitation.
The same information is entered several times
A study that touches the IRB, the Institutional Biosafety Committee, and the Radiation Safety Committee, and that references a funded award, requires staff to re-enter the same personnel, funding, and study details in each place. Duplicate entry is where version conflicts originate, and reconciliation work is the tax the institution pays for it every week.
Every policy change becomes a vendor engagement
When an institution cannot adjust its own required questions, review pathways, and notification rules, policy updates queue behind a services request. Over the years, this makes an otherwise functional system feel unusable. It also determines how quickly the institution can respond when an obligation changes.
Part two: What has changed that your system now has to support
Three forces shape what an IRB system has to handle in 2026. The revised Common Rule, which is settled. FDA regulations, which have not yet been harmonised with it. And newer policy activity aimed squarely at what happens after a study is approved.
Read this section with one question in mind: can the system we run today handle each of these without a vendor ticket?
Continuing review is no longer one rule applied to every study
The 2018 revisions to the Common Rule, the federal regulation governing federally supported human subjects research, changed continuing review from a blanket annual obligation into a per-study determination.
Under 45 CFR 46.109(f), continuing review is not required for research eligible for expedited review, for research reviewed under limited IRB review, or for research that has progressed to data analysis only or to accessing follow-up clinical data, unless the IRB determines otherwise. Research reviewed by the convened board still requires continuing review at intervals appropriate to the degree of risk, and not less than once a year.
What this means for your system. It has to hold each study against its own obligation, not against an institutional default. A system that applies one rule across the portfolio will put the wrong expiration date on part of it, and nobody finds out until an approval lapses.
Single IRB review is the default for federally funded cooperative research
Under 45 CFR 46.114(b), a US institution engaged in cooperative research conducted or supported by a Common Rule agency must rely on a single IRB for the portion of the research conducted in the United States. The compliance date was 20 January 2020, and the exceptions are narrow.
What this means for your system : Reliance is now routine operational work rather than an exception. The system needs to hold reliance and authorization documentation with the protocol, notify relying sites when changes are approved, and capture site-specific local context, without that work happening in email.
Approved consent forms for federally funded trials must be posted publicly
Under 45 CFR 46.116(h), one IRB-approved Informed Consent form used to enroll participants in a federally conducted or supported clinical trial must be posted on a publicly available federal website after the trial closes to recruitment.
What this means for your system : Staff needs to identify which consent version was approved and in use, and retrieve it quickly, often long after the study team has moved on.
FDA-regulated studies follow different rules, and the difference is decided study by study
As of September 2026, 21 CFR 56.114 still permits rather than requires reliance on a single IRB for FDA-regulated cooperative research. The FDA proposed harmonizing rules in September 2022 covering cooperative research, Informed Consent content and continuing review. Those proposals are not final.
One piece did land. The FDA's final rule allowing an IRB to waive or alter Informed Consent for certain minimal risk clinical investigations took effect on 22 January 2024 at 21 CFR 50.22.
What this means for your system. Two studies sitting in the same queue can carry different continuing review and reliance obligations depending on whether they are FDA-regulated, Common Rule, or both. The office needs to apply the correct pathway per study, and the system must allow it.
What OHRP and the FDA expect your written procedures to cover
The joint Office for Human Research Protections (OHRP) and FDA guidance on IRB written procedures, reissued in June 2025, carries a checklist that reads almost as a specification for what a system has to produce.
It expects written procedures covering how the approval period and continuing review interval are determined and documented, how study approvals are tracked and continuing review scheduled to prevent lapses, what happens when an approval does lapse, how minutes are prepared and maintained, and how records are retained for at least three years after completion of the research and kept accessible for inspection.
What this means for your system. If your written procedures describe a process your software cannot actually execute, the gap might become an institutional finding later.
What is in motion but not yet in force
Sharing summary-level results with participants : On 27 August 2026, NIH issued NOT-OD-26-113, a request for information on a draft policy that would require researchers and institutions to share plain language summary-level study results with participants across NIH-supported clinical research. Comments are due 26 October 2026. This is a proposal, not a requirement.
Biosafety scope : On 19 August 2026, NIH issued NOT-OD-26-112, a request for comment on a draft NIH Biosafety Policy that would replace the NIH Guidelines for Research Involving Recombinant or Synthetic Nucleic Acid Molecules and broaden biosafety oversight. Institutions that route the same studies through the IRB and the Institutional Biosafety Committee should track the scope.
Post-approval obligations and cross-committee scope keep expanding. That makes one question a purchasing question rather than an implementation detail: when the next obligation lands, who changes the system, and how long does it take?
Part three: The institutional outcomes a system should produce
Before evaluating any product, it helps to agree internally on what the system is supposed to achieve. This section describes how the review lifecycle should run, and then the institutional outcomes worth holding any candidate against, including the one you already own.
How the review lifecycle should run
An IRB system should support the handoffs in the review process without changing who is accountable for the decisions. The system can check, route, version, notify, and document. While investigators, reviewers, and staff are responsible for reviewing and approving research activities, the institution remains responsible for the human research protection program as a whole.
Submission and pre-review : The principal investigator prepares the protocol in line with the institution's current requirements and all applicable regulations, and submits it to the IRB for review. The application includes the protocol, Informed Consent documents, recruitment materials, and study personnel with their human subjects protection training. IRB staff pre-review it for completeness before it goes to a reviewer or the convened committee. Incomplete applications are returned to the investigator, and every return adds a cycle before the substantive review of the research has begun.
Review pathway and reviewer work : The submission should move through the institution's applicable determination and review process, whether exempt, expedited, or convened. Reviewer assignments, comments, requested modifications, and recusals should stay associated with the protocol version they relate to, so the basis for a later determination does not have to be reconstructed from email.
Where a protocol goes to the convened board, the agenda, the meeting record, and the resulting determination should stay attached to the exact protocol version the board reviewed. Where a protocol is handled through exempt or expedited review, the same principle applies: the reviewer, the date, and the determination belong on the protocol record rather than in a separate log.
Determination and communication : The determination, any conditions of approval, the approval period, and related correspondence should remain tied to the protocol record. Investigators should be able to see current status and approved documents without asking the office or checking a tracking sheet to find out which version is in force.
Post-approval activity : Approval is not the end of the record. Amendments should create a new version without overwriting the version previously approved. Studies requiring continuing review should carry the schedule appropriate to that study, and institutions may apply their own post-approval tracking where continuing review is not federally required. Changes, reportable events, and personnel updates should stay connected to the study history rather than becoming separate administrative files.
The outcomes to hold a system against
Read any feature list backwards. Start with the outcome the institution needs, then ask which capability produces it and what evidence supports the claim.
Maintaining compliance at scale : The outcome is fewer suspended studies, fewer reportable lapses, and no enrollment halted because a date was missed. It is produced by holding each study against its own continuing review obligation rather than an institutional default, recording the approval period and expiration date set by the reviewing body, and issuing alerts ahead of the deadline. Amendments run on a separate track from continuing review so the two are never conflated. Training and certification expirations surface before they block work on an active protocol.
Better review performance : The outcome is fewer avoidable revision cycles, more predictable approval timelines, and a lower administrative load on investigators and IRB staff. It is produced by guided forms and completeness checks that reduce avoidable returns before substantive review begins, and by structured routing, reviewer assignment, and status visibility that reduce administrative handoffs and make potential delays easier to identify. The system supports the process; the principal investigator remains responsible for the protocol and the institution remains responsible for oversight.
A defensible position in an inspection : The outcome is that the office answers an Office for Human Research Protections (OHRP), FDA, AAHRPP, or sponsor request on the timeline the reviewer set, without a documentation scramble. It is produced by time-stamping and attributing every action on a protocol, keeping submissions, reviewer comments, stipulations, determinations, investigator responses, attachments, agendas, and minutes in one attributable sequence, and letting staff filter by protocol criteria and date range to generate exactly what was asked for. Records must also be retained and kept accessible for inspection under 45 CFR 46.115(b) and 21 CFR 56.115(b).
Confidence in the consent record : The outcome is that the institution can show which version of the Informed Consent document was approved, when it was in use, and what changed between versions. It is produced by full version history with timestamps and attribution, reviewer comments tied to the section they address, and straightforward retrieval of the posted form and its approval status for federally supported clinical trials covered by 45 CFR 46.116(h).
Oversight that holds across sites and committees : The outcome is that cooperative research stays documented across participating sites, and research involving more than one oversight committee is managed without duplicate entry or disconnected records. It is produced by supporting reliance documentation, relying-site communication and site-specific information alongside the protocol, and by letting related protocols be referenced across committees.
Shared information should not mean shared authority : The IRB, IBC, IACUC, RSC, and other committees operate under different oversight responsibilities and should retain their own submission requirements, review workflows, and determinations. The value of an integrated platform is that investigators and administrators do not recreate the same core information simply because more than one committee is involved.
Lower administrative burden without lowering standards : The outcome is that coordinators spend their time moving protocols rather than answering status questions, and leadership sees the portfolio without asking staff to compile it. It is produced by live protocol status visible to the study team, automated routing and notification, and dashboards showing open protocols, pending amendments, upcoming renewals, and reported events together.
Institutional visibility and readiness for analytics : The outcome is that research leadership can see review volume, turnaround, and bottlenecks as a matter of routine rather than as a special request. Consistently structured, attributable data is also the precondition for anything an institution later wants to do with analytics or responsible use of artificial intelligence. Institutions do not need an AI strategy to select an IRB system, but they should avoid selecting one that leaves their data in a shape nothing can be built on.
Security and data governance appropriate to human subjects data : The outcome is that access to participant-related information is limited to the people whose role requires it, and the institution can demonstrate that control. It is produced by role-based access, encryption in transit and at rest, hosting in audited data centers, and a documented information security posture that survives a procurement review.
Part four: How to evaluate the options
The feature list alone does not determine how institutions choose between vendors for human subjects review. The more important aspects to focus on are whether the system carries enough IRB depth for a research-intensive program, whether the other committees and administrative functions are genuinely part of one platform or added alongside it, and whether the institution can start with what it needs today and add compliance, research administration, or animal-management modules later without replacing the system underneath.
A single busy IRB with no other committees can be well served by a standalone system today. The harder question is whether that will still hold as the institution grows. Research portfolios expand, new integrations become necessary, and oversight increasingly reaches across committee boundaries. Where any of that is likely, choosing a standalone system now can commit the institution to a second replacement later, with the cost, migration risk, and disruption that another change carries.
An integrated platform lets an institution start with the IRB alone and add other committees, research administration, or animal management as needs develop, without replacing the system underneath. That scalability, and the protection it gives the institution's technology investment, is why many research-intensive institutions weigh the integrated approach even when their immediate need is human subjects review only.
Evaluation criteria and the evidence to ask for
Once the approach is settled, the comparison moves to specific criteria. Run every candidate through the same criteria, including the system you already own, and score each on the same scale so the results sit side by side. Involving the coordinators who will work in the system daily, before the decision rather than after, consistently improves the quality of the scoring.
The third column matters most. Many vendors may confirm the same capabilities. Asking to see it demonstrated on a live record is the real evidence of what a solution actually delivers.
Be realistic about what a demonstration can show. Expecting a vendor to configure your committee structure for a one-hour session is not reasonable, and refusing to look at a standard demonstration environment will not improve the decision. What is reasonable is asking for a scripted demonstration against scenarios you supply in advance.
Where a vendor cannot demonstrate something material to compliance, security, integration, or your core workflow, treat it as unresolved and resolve it before selection. Deferring a material gap to implementation planning is how institutions end up paying for a system that never closes it.
Part five: Protecting the institutional record through a change
Replacing an IRB system is not only a software implementation. The institution also has to preserve continuity of the regulatory and administrative record, and be able to defend it later.
Under 45 CFR 46.115(b) and 21 CFR 56.115(b), required IRB records must be retained and remain accessible for inspection for the applicable retention period. That does not mean every legacy artifact has to be converted into the new system's native format; the institution should know exactly which records move into the new platform, which remain accessible through a legacy or archival repository, and how staff retrieve either set when asked.
Scope the migration around the records the institution needs to continue using and defending. That typically includes active and in-review protocols, approved protocol and Informed Consent versions, determinations and correspondence, approval periods and applicable continuing review dates, meeting records, reliance and authorisation documentation, personnel information, and historical records still within the retention period.
The harder problems are relationships between records rather than the records themselves. An attachment may exist without a clear link to the protocol version it supported. Reviewer comments may have stayed in email. Legacy status values may not map cleanly onto the new review pathways. A consent document can migrate successfully as a file while losing the information that identifies when it was approved and when it was in use.
Deciding how this information migrates is the institution's responsibility. The institution determines which records move, how the relationships between them are preserved, and how legacy states are represented in the new system, because it is the institution that has to retrieve and defend the record afterward. Its job is to make those decisions and then work with the vendor to scope the migration effort and plan against them. The vendor supports and executes an agreed scope rather than owning the outcome.
Validation should test complete protocol histories rather than confirming a record count. A useful sample includes the difficult cases: convened-review studies with upcoming review obligations, multi-site studies with reliance documentation, protocols with several approved consent versions, and studies linked to other oversight committees.
For each sample, staff should be able to retrieve the current approved protocol, the relevant determination and correspondence, the approved consent version, the next required review date where one applies, the personnel information, and enough history to explain how the study reached its current status.
During cutover, define which system is authoritative for new activity. Where practical, retaining read-only access to the legacy record while new work happens in one designated system reduces the risk of two versions of the institutional record developing in parallel.
Ask each vendor to explain the migration mapping, the validation approach, how exceptions are handled, the archival access plan, and the training included in the engagement. A successful migration is demonstrated by the institution's ability to retrieve and defend its record after cutover, not by a count of records transferred.
Where Key Solutions eProtocol fits
eProtocol is the research compliance platform from Key Solutions, and IRB is one module within it. It is worth assessing against the same criteria as every other candidate.
Committee coverage on one platform : IRB, IACUC, IBC, Stem Cell Research Oversight (SCRO), RSC, CSC, and Controlled Substances run on the same platform. Each committee keeps its own submission form and review workflow, because each operates under a different regulatory framework. What is shared is the protocol data and the interface, so an investigator can reference a related protocol across committees without a second login. This is not one form routed to every committee.
Configuration is owned by the institution : eProtocol deploys with a standard question set that the institution modifies to its own policies, marking which questions are required and configuring forms and review workflows to match its committees.
Consistent review history across committees : Because committee actions are recorded on the same platform, the institution can produce the review history for a protocol, or across a set of protocols and a date range, without reconciling systems first.
Integration with research administration : eProtocol works with eGrants, Key Solutions' integrated grants management platform. eGrants provides Opportunity Finder, Pre Award, System to System (S2S) submission to grants.gov, Post Award, Sub Award, and SPA. eProtocol also integrates with eCOI for conflict of interest and with institutional human resources and finance systems.
Security posture : Role-based access limits investigators to the protocols where they are active personnel, data is encrypted in transit and at rest, applications are hosted in SOC 2-compliant data centers, and Key Solutions holds ISO 27001:2022 certification.
Implementation as part of the engagement : Key Solutions delivers implementation, data migration, testing and validation, third-party integration, training, and ongoing support as part of the engagement.
Choosing a system you will not outgrow
A replacement decision is easier to defend when it starts from the failure that prompted it.
For many R1 and R2 institutions, that failure stems from the systemic gaps identified in Part one. Rather than using feature lists, build your business case by identifying which of those gaps—or others—apply to your institution and quantifying what they have cost in staff time and operational risk over the last two years.
From there, the path is straightforward. Score the system you run today against the criteria in part four, using the same scale you will apply to every candidate. Ask for the evidence column in every demonstration you sit through, and supply your scenarios in advance so the demonstrations are comparable. Resolve material gaps before selection rather than after. And involve the coordinators who will live in the system daily before the decision is made, not once it has been announced.
If the current system scores well, it means no significant rehaul is needed. The purpose of this exercise is not to justify a purchase. It is to know, with evidence, whether the environment you run is still equal to the program you operate.
Frequently Asked Questions

.png)
