Institutional review board software: 10 Checks for Traceable Study Reviews

Choosing institutional review board software means deciding how a research office will collect submissions, route reviews, record decisions, and preserve study history. The system should make the current status clear without losing the documents and judgments behind it. A shared folder rarely provides that whole view.

This article covers ten selection checks, a realistic demonstration script, and a rollout plan. It explains where IRB management software supports the process and where trained staff and the board must make decisions. Configure the workflow around your institution’s procedures and the rules that apply to its research.

What should the system manage?

An IRB system usually connects study records, submissions, review assignments, correspondence, meeting work, and decisions. A study can have several submissions over time, including initial review, amendments, reports, and closure. Keep those records linked while preserving each submission’s own state.

For example, an approved study may have an amendment under review. One label saying “approved” should not imply that the proposed amendment has approval. The system needs to distinguish the current approved materials from the pending change.

The OHRP guidance on IRB written procedures describes functions that institutions and IRBs need to address under the applicable regulations. Software should implement the institution’s approved procedures rather than substitute a vendor’s default workflow for them.

1. Separate study status from submission status

Use a stable study identifier with linked submissions. Each submission should show its type, version, owner, stage, and outcome. The study view should then summarize the current approved state and open work.

Next, test a study with an initial approval, a pending amendment, and an outstanding report. Staff should be able to see all three without treating them as one queue item. The investigator view should be equally clear.

Also define what “active,” “closed,” and similar labels mean locally. A label may describe administrative status, research activity, or review state. Avoid using the same term for different concepts in reports.

2. Make intake forms complete but manageable

Forms should ask for the information relevant to the submission. Conditional questions can reduce clutter, provided they do not hide required information. Show clear guidance beside fields that commonly cause confusion.

For example, a form can request extra information when a study includes a particular activity. However, staff should test the branching with realistic cases. A missed branch can leave the reviewer without context.

Next, distinguish a saved draft from a submitted record. The office should know when the investigator has formally sent the package. A file upload or autosave should not silently start the review clock.

3. Route reviews through approved roles

Map who screens a submission, who assigns reviewers, and who records the decision. Some actions may require specific authority or expertise. Configure permissions around those roles, then test what each user can and cannot do.

In addition, account for absence and reassignment. A reviewer may leave, decline, or become unavailable. The office needs to transfer work without losing the original assignment and response history.

Our article on a clinical trial management system covers wider study operations. Keep the IRB review record distinct from trial tasks that another system owns.

4. Handle conflicts of interest in the workflow

The software should support your process for identifying and managing reviewer or member conflicts. A declaration field alone is not enough if the person can still take an action that the procedure excludes.

Ask the vendor to show a reviewer declaring a conflict after assignment. Check who receives notice, how reassignment occurs, and what remains in the audit history. Then test the meeting workflow for the same case.

Also confirm how the institution records attendance, participation, and any relevant decision context. Qualified research governance staff should define those rules and required records. The system’s role is to capture and enforce the approved process where appropriate.

5. Keep meeting materials and decisions connected

A meeting agenda should link to the exact submission and documents members need. Version changes after agenda preparation require a clear update process. Otherwise, members may discuss different copies of the same protocol.

Next, review how the product records decisions, conditions, and correspondence. Staff should be able to trace a decision to the reviewed package and meeting record. Avoid a workflow that stores the outcome only in an email.

For example, if approval requires changes, the investigator should see the required actions separately from optional advice. The office should then record how it reviews the response and confirms the final outcome.

6. Control protocol and consent document versions

Version control needs more than a filename ending in “final.” Keep draft, submitted, reviewed, and approved materials distinct. Record the relevant date, version, status, and relationship to the submission.

Our guide to a document management system explains general file controls. For IRB work, those controls need to connect to study decisions so staff can identify the approved set at a given time.

Next, test a replacement document during review. Can the reviewer compare versions? Does the office know which earlier comments remain open? Preserve the superseded file and the reason for replacement rather than overwriting it.

7. Design amendments and other follow-up submissions

An amendment should identify the proposed changes and their reasons. The review package should show how the new material differs from the current approved state. Copying an old form without clear version links can hide that comparison.

For a real institutional example, NMDP’s IRBManager guidance lists electronic forms for new studies, continuing reviews, amendments, reportable events, and other study documents. Use that range to test the submission types your own office needs.

However, do not assume every study requires the same follow-up schedule. The applicable rules and institutional decisions determine the review needs. Your research governance team should configure reminders and due dates accordingly.

8. Make correspondence clear and auditable

Investigators need to know what the office is asking, who must respond, and when the item is due. Link each request to the relevant submission and document. Keep important correspondence in the record even when the system also sends an email.

Next, test a returned submission. The investigator should see the open issues and know whether they can edit the whole form or only selected parts. The office should receive a clear signal when the response is ready.

Also review templates. Standard letters save time, but they need controlled wording, current references, and the correct study details. Require staff to check the final letter before issue where the procedure calls for review.

9. Protect access across study teams and institutions

Researchers, coordinators, reviewers, board members, and administrators need different permissions. A person may work on one study while reviewing another. Test that the system handles those roles without exposing unrelated records.

In addition, confirm how external users join and leave. An institutional account may end while a record still needs retention. Define who owns the record and how authorized access continues under your policy.

Ask about audit logs, secure file transfer, backups, and recovery. Also review what information the system actually needs to hold. Do not collect participant-level data simply because an attachment field allows it.

10. Report time and workload with defined clocks

“Days to approval” can mix office review time with time waiting for an investigator. Define the start, pause, and stop events before comparing teams or periods. Show the counts and exclusions behind an average.

For example, a submission may spend two days in screening and three weeks awaiting a response. Reporting the whole period as reviewer time gives a misleading picture. Keep stage history so staff can explain the result.

Next, use reports to find practical problems. Repeated missing documents may suggest form changes or better training. A growing unassigned queue may need staffing review. Metrics should point to action rather than rank people without context.

A demonstration script built around one study

Give each vendor the same fictional study and follow it through several submissions. Use made-up documents and no real participant information. Ask office staff and investigators to run the tasks from their own roles.

1. Create and save an initial draft with conditional questions.
2. Submit it and return one item for correction.
3. Assign a reviewer, record a conflict, and reassign.
4. Prepare meeting materials from the correct version.
5. Record a decision and issue the appropriate letter.
6. Submit an amendment while preserving the approved set.
7. Record a follow-up report and close the study under the test procedure.
8. Export the full history, documents, and correspondence.

Score each task as native, configurable, integration-dependent, or manual. Also note whether the institution can change forms and rules itself. A small policy change should not require an unclear custom project every time.

Plan migration around active work

First, choose a cutover date and identify active studies, pending submissions, and open correspondence. Map current status labels to the new system carefully. A bulk import that marks every record active can erase important distinctions.

Next, reconcile a sample against the old record. Check identifiers, investigator roles, approved documents, dates, and outstanding tasks. Our data migration framework outlines a controlled approach to that work.

Then decide how staff will access historical files. Keep them readable and linked to the new study identifier where appropriate. Do not assume an export preserves attachments and version relationships until you test it.

Finally, train by task and role. Investigators need draft and response workflows; reviewers need assignments and comments; office staff need routing, decisions, and record retrieval. Pilot a full cycle before the wider launch.

Compare the ongoing cost of change

Include implementation, forms, migration, storage, single sign-on, reporting, and support in the proposal. Ask about fees for external users, multiple boards, and test environments. Compare vendors using the same study and user assumptions.

Also review upgrade control. Changes to forms, templates, and permissions need testing before they reach live work. Ask how the vendor supports validation evidence and how the institution approves a release.

Choose forms that the institution can maintain

Forms and guidance change as the institution improves its procedures. Ask who can edit questions, branching, help text, and validation. Test those changes in a separate environment before they reach investigators.

For example, a new question should not make an old approved submission appear incomplete. The system should preserve the form version used for that record while allowing future submissions to follow the revised process.

Next, inspect what happens to an in-progress draft when a form changes. Staff need a defined rule for continuing the old version, moving to the new one, or requesting extra information. A silent change can confuse investigators and reviewers.

Also check the approval and release process for letter templates. A small wording change can affect many future communications. Keep the old version, effective date, reviewer, and test evidence.

Finally, budget time for ongoing ownership. Even a configurable product needs someone who understands the institution’s workflow and can test a change. Make that role explicit so the system remains aligned with approved practice after launch.

Choose a system that preserves the review story

Institutional review board software should show what the institution received, who reviewed it, which version informed the decision, and what remains open. Test that whole path before buying. Then configure and launch the system around approved procedures and clear record ownership.