Summarize with:

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.

Vendor approach
IRB depth and how it is built
Room to add modules later
When it fits
IRB-only vendors
Built solely for human subjects review, so IRB depth is usually strong and the roadmap stays dedicated to it. There are no other committees on the platform; grants, animal management, and other compliance sit in separate systems that have to be integrated from outside, if at all.
Adding another committee or an administrative function means buying and integrating a separate product, or replacing the IRB system with a broader one. The investment in the IRB tool does not extend to those functions.
Institutions where human subjects review is the whole workload today and is expected to stay that way, with little cross-committee or multi-committee growth anticipated.
Research-administration vendors that added compliance
Grants and financial administration are the core strength. Compliance was added to an administration-first platform, so IRB depth varies and is often secondary on the roadmap. Grants integration is typically genuine, while the IRB module can be shallower than a dedicated system.
Human subjects review and grants can grow together on one platform. Animal management and other safety committees are often thin or absent, so those needs still route to separate systems.
Institutions whose primary problem is research administration, with human subjects needs that are comparatively standard and stable.
Animal-management vendors that added compliance
Vivarium and animal-facility operations are the core strength, and IACUC support is usually mature. Human subjects review was added to an animal-first platform, so IRB depth and human-subjects-specific workflows, such as reliance, consent version control, and per-study continuing review logic, may be shallower or handled as a separate add-on.
Animal operations and IACUC scale well together. A growing human subjects program can outgrow the added IRB capability, which then has to be supplemented or replaced.
Institutions whose primary activity is animal research operations, with comparatively modest human subjects volume.
Providers offering a fully integrated research platform
IRB is a purpose-built module that shares protocol data and a common record with the other committees, while each committee keeps its own workflow. Depth still varies by provider, so confirm IRB depth specifically rather than assuming breadth equals depth.
The institution can implement what it needs now, for example, the IRB, and add IBC, IACUC, grants, or animal management later on the same platform, without a second migration. This protects the technology investment as the research portfolio grows.
Institutions consolidating oversight across committees, carrying cross-committee studies, anticipating research growth, or replacing more than one aging system at once.

‍

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.

Criterion
Why it decides the outcome
Evidence to ask for
Per-study continuing review logic
Studies in one portfolio carry different obligations under 45 CFR 46.109(f) and under FDA rules.
Two studies with different continuing review obligations, and the expiration date each one carries.
Lapse prevention
A lapsed approval halts enrolment and becomes a reportable event.
The alert sequence before expiration, and what the system does when approval lapses.
Inspection response
Office for Human Research Protections (OHRP), FDA, AAHRPP and sponsors ask for the review history on a named protocol.
The full history for one protocol, filtered by date range, generated live.
Informed Consent version control
Consent is a frequent audit focus, and version questions arrive during amendment review.
What changed between two consent versions, with attribution and timestamps.
Reliance and multi-site
Cooperative research under 45 CFR 46.114(b) requires documented reliance and local context.
A relying-site notification, and where the reliance documentation sits.
Cross-committee working
Studies touching several committees create duplicate entry and version conflicts.
A related protocol referenced from another committee without re-entering personnel or study data.
Grants and conflict of interest
Duplicate entry between compliance and administration is a recurring error source.
The current integration, not an architecture slide.
Configuration ownership
Policy changes should not queue behind a vendor services engagement.
A walkthrough of the administrator interface where required questions and routing rules are changed, and confirmation of which changes are institution-owned.
Security and hosting
Human subjects data raises the bar on access control and hosting.
Role-based access model, encryption, hosting certifications, and current security documentation.
Migration and validation
A switch fails when legacy protocols and approval histories do not carry over.
How active and historical records will be mapped, what stays in an archival environment, and a walkthrough of one migrated protocol end to end.
Support and roadmap
The relationship lasts longer than the implementation.
Named support model, response commitments, release cadence, and how institutional requests reach the roadmap.

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

Score both against the same criteria. A current system is usually worth keeping when the gaps are configuration or training problems that the institution can resolve itself, and worth replacing when the gaps are structural: per-study continuing review logic it cannot express, reliance workflows it was never built for, or a configuration model that sends every policy change to the vendor. The decision is easier when the cost of the current environment is quantified, in staff hours spent reconciling records, in avoidable revision cycles, and in any lapses over the past two years.

The case is scalability. An integrated platform runs the IRB alongside the IBC, IACUC, and radiation or chemical safety on one system, so cross-committee studies are entered once, related protocols stay linked, and leadership sees oversight in one view, with one configuration model, one security posture, and one vendor to manage. It also lets an institution start with the IRB and add other committees, research administration, or animal management as research grows, without replacing the platform underneath. That protects the technology investment and avoids a second migration. Even where human subjects review is the whole workload today, a standalone choice made now can commit the institution to another replacement later.

Lead with exposure and capacity rather than features. Exposure is the risk carried by the Institutional Official under the Federalwide Assurance: lapsed approvals, an audit response the institution cannot produce on the reviewer's timeline, and reliance documentation that cannot be located. Capacity is what the office could do with the administrative time currently spent on reconciliation and status queries. Both are easier to evidence than a feature comparison, and both are what leadership is accountable for.

The obligations diverge. As of September 2026, 21 CFR 56.114 permits rather than requires reliance on a single IRB for FDA-regulated cooperative research, and the FDA's proposed harmonizing rules from 2022 are not final. The FDA's final rule permitting waiver or alteration of Informed Consent for certain minimal risk clinical investigations took effect on 22 January 2024. The practical consequence is that a system must let the office apply the correct pathway and continuing review obligation per study rather than by institutional default, and must make that determination visible on the record.

Timelines vary with the number of committees in scope, the complexity of the institution's review pathways, and the state of the legacy data. The variable institutions most often underestimate is their own configuration and validation effort, not the vendor's implementation work. Scope the migration early, identify the difficult record relationships before contracting, and agree who inside the institution owns configuration after go-live. Those three decisions influence the schedule more than anything in the statement of work.

Analytics and AI add the most value when they are built into the platform rather than bolted on, because native analytics and AI work directly on the structured protocol data the system already holds. Built in, they help at specific points: a pre-submission check that flags missing elements, inconsistencies, or unclear consent language before a protocol reaches the committee; alerts that track regulatory updates from bodies such as the NIH and FDA; and dashboards showing review volume, turnaround, and bottlenecks without staff compiling them. These assist the office; they do not replace committee judgment.

‍

Summarize with:

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.

Vendor approach
IRB depth and how it is built
Room to add modules later
When it fits
IRB-only vendors
Built solely for human subjects review, so IRB depth is usually strong and the roadmap stays dedicated to it. There are no other committees on the platform; grants, animal management, and other compliance sit in separate systems that have to be integrated from outside, if at all.
Adding another committee or an administrative function means buying and integrating a separate product, or replacing the IRB system with a broader one. The investment in the IRB tool does not extend to those functions.
Institutions where human subjects review is the whole workload today and is expected to stay that way, with little cross-committee or multi-committee growth anticipated.
Research-administration vendors that added compliance
Grants and financial administration are the core strength. Compliance was added to an administration-first platform, so IRB depth varies and is often secondary on the roadmap. Grants integration is typically genuine, while the IRB module can be shallower than a dedicated system.
Human subjects review and grants can grow together on one platform. Animal management and other safety committees are often thin or absent, so those needs still route to separate systems.
Institutions whose primary problem is research administration, with human subjects needs that are comparatively standard and stable.
Animal-management vendors that added compliance
Vivarium and animal-facility operations are the core strength, and IACUC support is usually mature. Human subjects review was added to an animal-first platform, so IRB depth and human-subjects-specific workflows, such as reliance, consent version control, and per-study continuing review logic, may be shallower or handled as a separate add-on.
Animal operations and IACUC scale well together. A growing human subjects program can outgrow the added IRB capability, which then has to be supplemented or replaced.
Institutions whose primary activity is animal research operations, with comparatively modest human subjects volume.
Providers offering a fully integrated research platform
IRB is a purpose-built module that shares protocol data and a common record with the other committees, while each committee keeps its own workflow. Depth still varies by provider, so confirm IRB depth specifically rather than assuming breadth equals depth.
The institution can implement what it needs now, for example, the IRB, and add IBC, IACUC, grants, or animal management later on the same platform, without a second migration. This protects the technology investment as the research portfolio grows.
Institutions consolidating oversight across committees, carrying cross-committee studies, anticipating research growth, or replacing more than one aging system at once.

‍

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.

Criterion
Why it decides the outcome
Evidence to ask for
Per-study continuing review logic
Studies in one portfolio carry different obligations under 45 CFR 46.109(f) and under FDA rules.
Two studies with different continuing review obligations, and the expiration date each one carries.
Lapse prevention
A lapsed approval halts enrolment and becomes a reportable event.
The alert sequence before expiration, and what the system does when approval lapses.
Inspection response
Office for Human Research Protections (OHRP), FDA, AAHRPP and sponsors ask for the review history on a named protocol.
The full history for one protocol, filtered by date range, generated live.
Informed Consent version control
Consent is a frequent audit focus, and version questions arrive during amendment review.
What changed between two consent versions, with attribution and timestamps.
Reliance and multi-site
Cooperative research under 45 CFR 46.114(b) requires documented reliance and local context.
A relying-site notification, and where the reliance documentation sits.
Cross-committee working
Studies touching several committees create duplicate entry and version conflicts.
A related protocol referenced from another committee without re-entering personnel or study data.
Grants and conflict of interest
Duplicate entry between compliance and administration is a recurring error source.
The current integration, not an architecture slide.
Configuration ownership
Policy changes should not queue behind a vendor services engagement.
A walkthrough of the administrator interface where required questions and routing rules are changed, and confirmation of which changes are institution-owned.
Security and hosting
Human subjects data raises the bar on access control and hosting.
Role-based access model, encryption, hosting certifications, and current security documentation.
Migration and validation
A switch fails when legacy protocols and approval histories do not carry over.
How active and historical records will be mapped, what stays in an archival environment, and a walkthrough of one migrated protocol end to end.
Support and roadmap
The relationship lasts longer than the implementation.
Named support model, response commitments, release cadence, and how institutional requests reach the roadmap.

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

Score both against the same criteria. A current system is usually worth keeping when the gaps are configuration or training problems that the institution can resolve itself, and worth replacing when the gaps are structural: per-study continuing review logic it cannot express, reliance workflows it was never built for, or a configuration model that sends every policy change to the vendor. The decision is easier when the cost of the current environment is quantified, in staff hours spent reconciling records, in avoidable revision cycles, and in any lapses over the past two years.

The case is scalability. An integrated platform runs the IRB alongside the IBC, IACUC, and radiation or chemical safety on one system, so cross-committee studies are entered once, related protocols stay linked, and leadership sees oversight in one view, with one configuration model, one security posture, and one vendor to manage. It also lets an institution start with the IRB and add other committees, research administration, or animal management as research grows, without replacing the platform underneath. That protects the technology investment and avoids a second migration. Even where human subjects review is the whole workload today, a standalone choice made now can commit the institution to another replacement later.

Lead with exposure and capacity rather than features. Exposure is the risk carried by the Institutional Official under the Federalwide Assurance: lapsed approvals, an audit response the institution cannot produce on the reviewer's timeline, and reliance documentation that cannot be located. Capacity is what the office could do with the administrative time currently spent on reconciliation and status queries. Both are easier to evidence than a feature comparison, and both are what leadership is accountable for.

The obligations diverge. As of September 2026, 21 CFR 56.114 permits rather than requires reliance on a single IRB for FDA-regulated cooperative research, and the FDA's proposed harmonizing rules from 2022 are not final. The FDA's final rule permitting waiver or alteration of Informed Consent for certain minimal risk clinical investigations took effect on 22 January 2024. The practical consequence is that a system must let the office apply the correct pathway and continuing review obligation per study rather than by institutional default, and must make that determination visible on the record.

Timelines vary with the number of committees in scope, the complexity of the institution's review pathways, and the state of the legacy data. The variable institutions most often underestimate is their own configuration and validation effort, not the vendor's implementation work. Scope the migration early, identify the difficult record relationships before contracting, and agree who inside the institution owns configuration after go-live. Those three decisions influence the schedule more than anything in the statement of work.

Analytics and AI add the most value when they are built into the platform rather than bolted on, because native analytics and AI work directly on the structured protocol data the system already holds. Built in, they help at specific points: a pre-submission check that flags missing elements, inconsistencies, or unclear consent language before a protocol reaches the committee; alerts that track regulatory updates from bodies such as the NIH and FDA; and dashboards showing review volume, turnaround, and bottlenecks without staff compiling them. These assist the office; they do not replace committee judgment.

‍