IRB and Human Subjects Compliance Software: Protocol Review That Does Not Depend on One Coordinator's Calendar

Why an IRB system failure is the one that stops the whole campus

A study coordinator enrols a participant on a Tuesday. The protocol's approval expired the previous Friday. Nobody noticed because the continuing review reminder went to a principal investigator who had it filtered into a folder, the coordinator assumed approval was current because the study was still listed in the system, and the IRB office had 40 expirations that month across a staff of three. That single enrolment is now unapproved human subjects research. It has to be reported, the study goes on hold, and if the study is federally funded and the pattern looks systemic rather than isolated, the exposure is not one protocol. A determination against a human research protection program can suspend research across an entire institution.

The tools in this space are Huron IRB, IRBNet, Cayuse IRB and Advarra. Advarra is strong on the clinical and commercial side, Huron is the most capable in an academic medical centre context, and IRBNet is the workhorse for smaller programs. All of them are configurable and all of them are configured, at length, by consultants. The recurring complaint we hear from HRPP directors is not that the products are bad. It is that a configuration project to make a packaged system reflect local policy routinely runs longer and costs more than building the thing outright, and ends with a system nobody at the institution can change without a change request.

Problem 1: the smart form is your policy, and that is why configuration keeps failing

An IRB submission form is not a form. It is a decision tree encoding your institution's policy: which questions appear when the study involves children, prisoners, pregnant women or people with impaired consent capacity, when a HIPAA authorisation or a waiver is required, when the study is FDA regulated and therefore carries different obligations, when a device is significant risk, what your local policy adds on top of the federal floor. Change one answer and half the remaining questions change.

What a custom build does: model the form as a versioned decision graph with the branching held as data and the version stamped onto every submission, so a study submitted in 2026 can still be viewed under the form it was submitted against. Ask only what the answers so far make relevant. Then run completeness validation before submission rather than after, which is the single change that most reduces IRB staff workload, because the administrative pre review that consumes your coordinators becomes something the form did on its own. Investigators notice this within a week and it is the reason adoption goes smoothly.

Problem 2: the review pathway determination is judgement, and the system should show its work

Exempt, expedited or full board. That determination drives everything downstream and is made by a person applying the categories in the regulations to a specific study. The revised Common Rule changed the exempt categories and introduced limited IRB review for some of them, and FDA regulated research follows a different set of requirements, so a study can be exempt under one framework and not the other.

What a custom build does: evaluate the submitted answers against the category definitions and propose a pathway with the specific criteria that matched, which the analyst confirms or overrides with a recorded reason. The determination is never automatic, and any developer who offers to automate it does not understand the liability. What automation gives you is consistency and an artefact: every determination carries the criteria and the reviewer's reasoning, so a pattern review across a year is a query rather than a file pull. Where the study is FDA regulated, the system carries both frameworks in parallel rather than forcing one answer, because that dual status is where mistakes concentrate.

Problem 3: convened meetings run on quorum, recusal and a document nobody can assemble

A full board meeting requires quorum including at least one member whose primary concerns are in a nonscientific area, and a member with a conflicting interest may not participate in the vote. Losing quorum mid meeting invalidates subsequent actions. The agenda has to be assembled, packets distributed to members with the right documents, votes recorded per study with counts, and minutes produced that reflect the discussion including the required elements for approvals under the regulations.

Most IRB offices do this with a mix of the system's meeting module, a shared drive, a Word template for minutes and one coordinator who knows how it all fits. Minutes are frequently written from handwritten notes days later, and the required documentation of controverted issues and their resolution is the piece most often found thin during an audit.

What a custom build does: track membership with roles and expertise categories, compute quorum live during the meeting including the nonscientific member requirement, and warn the chair the moment a departure or a recusal breaks it. Conflicts are declared against studies in advance and the member is automatically excluded from that vote with the recusal recorded. Minutes assemble from structured actions taken during the meeting, with the discussion captured as it happens rather than reconstructed, and the required elements for each approval prompted rather than remembered. The output is a document that stands up when OHRP or a sponsor's auditor reads it two years later.

Problem 4: reliance agreements mean outsiders need real access to one study and nothing else

Single IRB review for multi site research is now the default for NIH funded domestic studies and is embedded in the cooperative research provision of the revised Common Rule. That means your IRB is either reviewing for institutions you do not control, or relying on someone else's and needing to track local context, local investigator credentials and local reporting obligations for sites that are not yours.

What a custom build does: external institutions get scoped accounts that see exactly one study and the documents for their site. Local context forms, local investigator training verification and site specific consent language live as site records under the parent study, so the approved version per site is unambiguous. Reliance agreements themselves are tracked as objects with an execution date, a scope and an expiry, and the SMART IRB style workflow is modelled rather than lived in email. When a reportable event happens at site seven, the system knows which sites are affected and what each one's institution requires.

Problem 5: expirations, modifications and reportable events are three clocks running at once

The revised Common Rule removed the continuing review requirement for many minimal risk studies, which sounds like relief until you realise your portfolio now has studies on three different regimes at once: those still requiring annual continuing review because they are FDA regulated or the IRB determined it necessary, those requiring only a status check, and those requiring nothing. Meanwhile modifications arrive and must be approved before implementation, and reportable new information including unanticipated problems has its own timeline.

The failure mode is always the same: a person is the clock. When that person is on leave, expirations slip.

What a custom build does: every study carries its own review regime derived from its determination, so the system knows which clock applies to which study without a coordinator remembering. Escalation is layered rather than a single reminder, moving from the coordinator to the principal investigator to the department chair on a schedule you define, and finally to an automatic administrative hold that prevents further approvals against a lapsed study. Modifications are versioned against the approved protocol so the currently approved document set is never ambiguous, which matters enormously when a monitor visits and asks which consent form was in use in March. Reportable new information gets a triage path with severity, a required assessment of whether the event meets the unanticipated problem definition, and the reporting obligations to sponsors and to federal agencies generated as dated tasks rather than remembered.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, this is the honest shape for an IRB and human subjects platform. A first release covering the versioned smart form with pre submission validation, pathway determination with recorded reasoning, convened meeting management with live quorum, and the expiration and modification engine runs $80,000 to $160,000 and ships in 12 to 18 weeks. A full platform adding reliance agreements with scoped external access, reportable new information workflows, conflict of interest integration, and links to grants, the animal care committee and clinical trial billing runs $200,000 to $500,000 phased over 8 to 14 months.

What drives price up specifically: an FDA regulated portfolio, because dual framework tracking and device risk determinations add real logic. Reliance volume, since external access and site level records are a substantial subsystem. Integration with an electronic health record or a clinical trial management system if you are an academic medical centre, which is usually the largest single line. Part 11 considerations if your electronic signatures need to support FDA regulated records, which is a design decision made at the start and not retrofitted. And the number of local policies that exist as practice rather than as written policy, because writing them down is discovery work and it is where the schedule actually goes.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you review under about 200 protocols a year, almost all minimal risk social and behavioural research, with no FDA regulated studies and no reliance relationships. IRBNet is inexpensive, adequate and the right answer at that scale. Configuring anything more ambitious will cost more than the risk it removes.

Build when two or more of these are true. First, your configuration project for a packaged system has already exceeded its timeline, which is the single most common trigger we see. Second, you carry FDA regulated research alongside Common Rule research and your system forces one framework. Third, you are the reviewing IRB for multi site studies and external sites currently reach you by email. Fourth, your submission form asks everyone everything because the conditional logic could not be expressed. Fifth, expiration management depends on one person's reminders.

Our position, stated plainly: this is one of the few categories where building can genuinely be cheaper and faster than buying, and the reason is that the product you are buying is mostly a configuration shell. When the configuration is the project, you are already paying for a build. You are just paying for one you will not own and cannot change without a change request. If your consultant's configuration estimate is over about $250,000, get a build quote before you sign it.

How to choose a developer for IRB and research compliance software

Ask them to explain the difference between exempt with limited IRB review and expedited review, and how the same study can be exempt under the Common Rule while remaining FDA regulated. If they cannot, they will learn 45 CFR 46 during your build and the mistakes will be in your determinations.

Ask how they will version the smart form and whether an old submission can still be rendered under the form version it was submitted against. If the answer is no, your historical record becomes unreadable the first time policy changes, which for a compliance system is disqualifying.

Ask who owns the code and get it in writing before kickoff. You should own the repository, the infrastructure accounts and the right to hire anyone else. At Digital Heroes the code is yours from the first commit. Your IRB records are the evidence in any future federal inspection, and they should never be inside a system you cannot access or modify on your own authority.