IRB and Ethics Review Management Software Problems: The 7 That Stop Research, and How to Avoid Them

Why does the every committee, every submission type first release fail?

The pitch is compelling. Investigators want one front door instead of three portals, so the project scopes the institutional review board, the institutional animal care and use committee, biosafety and radiation safety together, with every submission type and a full migration of legacy protocols. Nine months later nothing is live, because each committee's determination logic turned out to be a different rule set and the migration inventory alone consumed a quarter.

What makes this specific to research administration is that the shared parts are genuinely shared and the different parts are genuinely different. Submission intake, routing, rosters, meeting management and the clock engine are common. Determination logic, required content and reporting obligations are not, and forcing them into one form produces a system that serves no committee well. Institutions that discover this in month seven usually end up with a compromise everyone works around.

Sequence it as one committee, new submissions only, with the clock queue in release one. That means branching smart forms, determination pathways, reviewer assignment, expedited and convened review, the expiration queue and agenda and minutes generation for the institutional review board. Additional committees come as separate versioned rule sets on the shared spine. Legacy protocols stay where they are and close out naturally, which removes the single largest schedule risk from the first release.

What goes wrong when you migrate legacy protocols?

The instinct is to bring everything across so there is one system. In practice, a study approved four years ago exists as a package of documents, a determination made under a policy that has since changed, an expiration date that may have been amended twice, and a set of study team members whose training status is stale. Re keying that produces a record that looks structured and is not, because the fields were invented during migration rather than captured during review.

The specific failure arrives during an audit or an accreditation visit. Someone asks how a determination made in a prior year was reached, and the migrated record shows the current form structure with values mapped into it, which cannot demonstrate what the rules were at the time. That is a worse position than pointing at the original file, because it implies a precision the record does not have.

Migrate selectively. Studies still active and likely to be audited are worth the effort, and even then the inventory and mapping pass should be its own workstream with its own owner rather than a data load bolted onto the build. Everything else stays in the old system as a read only archive with a clear pointer from the new one. The related discipline is policy versioning: from go live, every determination records the version of the rules that governed it, so the question an auditor asks becomes answerable going forward even though it is not answerable backwards.

Why do the research administration integrations break after launch?

Three connections matter and all three fail on identifiers rather than on technology. Grants and research administration is the first. Institutions want to report protocols against funding, and the identifiers rarely match, because a protocol number and an award number were never designed to relate to each other and the mapping is maintained by a person. When that person changes role, new links stop being made and nobody notices until a report comes back short.

Conflict of interest disclosure is the second, and it fails on timing. An annual import of disclosures means the screening at a convened meeting in October runs against data captured in March. A member who took a consulting role in June is screened as clean, participates in a vote, and the problem surfaces during minutes review or, worse, later.

Human subjects training records are the third. Certificates expire, a study team member is added mid study, and the completeness check passes because the roster in the protocol was never updated.

The fixes are mundane. Reconcile identifier mappings on a schedule and raise a named exception for any protocol with funding recorded upstream and no link downstream. Screen conflicts against live disclosure data rather than an annual snapshot, or if that is genuinely impossible, show the disclosure date on screen at agenda build so staff can see how old it is. And check training status at the point of submission and again at approval, not once.

What happens when quorum, conflicts and reliance are not properly covered?

Two gaps have consequences beyond inconvenience. The first is meeting validity. A convened meeting requires a majority present including at least one member whose primary concerns are in nonscientific areas, and a member with a conflicting interest must not participate in the vote on that study. Minutes must record the vote including those for, against and abstaining, and the basis for required determinations. Get this wrong and the review itself is invalid, which is a far worse problem than a late letter and one that can require re review of everything approved at that meeting.

Systems that fail here do so by enforcing at the wrong moment. Quorum checked at minutes review is quorum checked after the damage. It has to constrain the agenda builder, which means modelling the roster properly: member roles, scientific or nonscientific designation, affiliation status, alternates and who they may substitute for, term dates and expertise tags.

The second gap is reliance. Single institutional review board expectations for multi site work mean your office now spends real effort on studies it does not review, and packaged systems most often push that into a spreadsheet because the obligations of a relying site are administrative rather than deliberative. Treat a reliance agreement as an object with parties, scope and effective dates, and treat each ceded study as a first class record holding the external board, approval documents received, local ancillary reviews still required, local context requirements and the expiration to watch. Nobody outside an institutional review board office appreciates how much time this consumes or how invisible it is in most tools.

Should you build custom or configure what you already own?

Some institutions should not build. If you review a few dozen studies a year, cede most multi site work and have no local requirements above the federal floor, IRBNet or an external board will cost less than any build and free staff for work that actually protects subjects. It is affordable document routing, and at that volume document routing is what you need.

Do not build either if you are already deep in Huron for grants and awards. The integration value of one research administration suite is real, and giving it up to gain faster smart form changes is usually a bad trade. Advarra CIRBI is similarly the right answer if Advarra is your reviewing board, because the system is shaped around that service.

Build when two or more of these hold: you process more than roughly eight hundred submissions a year; your smart forms encode institution specific policy you change more than once a year and cannot change without a vendor; you serve as reviewing board for external sites and your reliance tracking lives in a spreadsheet; you run several committees and want one submission front door; or your last accreditation cycle produced a finding you could not evidence your way out of because the data was spread across systems.

How do hidden costs get into the quote?

Integration with grants and research administration is the most common escalator, because the identifier mapping problem is discovered rather than specified. Ask for it to be scoped explicitly, including who owns the mapping and what happens to unmatched records.

Live conflict of interest screening is the second. Screening against an existing disclosure system in real time is materially more work than an annual import, and the difference is often buried in a single line of a proposal. Third, historical migration, which is why the recommendation above is to avoid it: an inventory of several thousand legacy protocols is weeks of staff time before any engineering happens. Fourth, additional committees, since each brings its own determination rules and required content even on a shared spine. Fifth, accreditation evidence, if you want reporting to be a query rather than a project.

Two questions worth asking before contract. What exactly is included per additional committee. And what happens when the institution updates its exempt category guidance: if the answer is a change request, you have bought the same constraint in a different colour.

What separates a build that works from one that fails here?

Ask a prospective partner to whiteboard the clock model before you sign. A team that has done this draws study, submission, review, determination and expiration as separate objects and asks immediately how an amendment affects the expiration date. A team that draws a request with a status field has built helpdesk software and will build you helpdesk software again.

Then ask how the system reconstructs which policy version governed a submission approved two years ago. Systems that hold only current rules cannot answer the question auditors actually ask, and no amount of reporting compensates for that.

The builds that work also fix the front door, because most pre review delay is incomplete submissions rather than slow reviewers. Validation at submission, contextual help in your institution's language, consent templates carrying required elements, and a completeness check that flags what an analyst would flag: a risk in the protocol missing from the consent form, a team member without current training, a procedure with no corresponding consent item, an advertisement whose claims exceed the protocol. The builds that fail ship an elegant reviewer interface and leave intake untouched, then discover that turnaround did not improve because the delay was never in the review.