Summarize with:
Research universities manage IACUC protocols using dedicated IACUC protocol management software, a category of research compliance software that handles protocol submission, committee review, approval, amendments, and post-approval monitoring across the protocol lifecycle.
Research institutions survey what is available and choose the shape that fits the research they actually run. Some build standalone IACUC systems, scoped to animal care and use committee review. Some began in research administration, where grants and financial administration is the primary product, and have since added compliance modules including IACUC. Some offer a range of individual compliance modules that are licensed and run separately from one another. And some provide a research compliance and administration platform in which the committees and the administrative functions are integrated from the outset.
This article explains what the software does, how these approaches differ in practice, and what determines which one fits a given institution.
What IACUC protocol management software does
Under the Animal Welfare Regulations and the PHS Policy, an Institutional Animal Care and Use Committee is required to review proposed animal use, approve or withhold approval, and evaluate the institution's animal care and use program at least once every six months. IACUC protocol management software carries the work between the people involved and gives the institution a current picture of where each protocol stands. Investigators prepare and submit protocols without rebuilding information they have already provided.
IACUC coordinators see what is incomplete before it reaches the committee, which protects the agenda. Reviewers and the chair work from the version under review, with earlier versions and prior determinations available to them. The attending veterinarian and the compliance office see training status and approval limits as they conduct their own oversight. For the institution, the result is a program that can maintain compliance as protocol volume grows.
A protocol management system covers five stages:
Submission: Investigators prepare the protocol following the institution’s current requirements and all applicable regulations, and submit it to the IACUC for review. The application covers the proposed animal use, the personnel who will carry it out, and their training. The system can be configured to identify an incomplete application before it reaches the IACUC office.
Pre-review and routing: The office confirms the submission is ready, and the protocol routes to the appropriate review pathway, whether designated member review or full committee review, based on the institution's own thresholds.
Committee review: Reviewer assignments, comments, requested modifications, and recusals stay attached to the protocol version they relate to, rather than accumulating in email.
Approval and communication: The determination, any conditions, the approval period, and the expiration date are recorded against the protocol, and the investigator can see current status without contacting the IACUC research compliance department.
Post-approval activity: Amendments create a new version without overwriting the approved one. Annual review, continuing obligations, reported events, and post-approval monitoring findings stay connected to the protocol history.
The committee still decides. The system records what was decided, by whom, and when, which is what an institution needs when USDA, OLAW, or an AAALAC site visitor asks.
How these approaches differ in practice
Standalone IACUC systems
Built specifically for animal care and use committee review.
Where this approach fits: Institutions where animal research is the dominant compliance workload, other committees are small or already served, and few studies cross a committee boundary. The review interface is usually mature, and the vendor's roadmap is dedicated to IACUC work.
Where it falls short: At the boundary with other systems. A protocol approved for 400 mice has to be entered again in the facility system before any animals can be ordered against it, and when an amendment raises that number to 600, someone has to remember to update it in both places. A study using a recombinant vector needs IBC approval, so the investigator describes the same procedures twice, in two applications, with no link between the two approvals. When a grant progress report requires current protocol status, the sponsored programs office requests it from the IACUC office by email rather than finding it. While these may be minor issues individually, when combined, they create a standing reconciliation task that grows with the portfolio.
Research administration suites with a compliance module
Grants and financial administration is the primary product, with compliance supported through an additional module.
Where this approach fits: This is a practical choice for institutions where animal research is a secondary activity rather than a central one. A program running perhaps twenty to sixty active protocols through a single committee, with one or two species and few surgical procedures, does not generate the committee workload that justifies a dedicated system. Primarily undergraduate institutions, smaller colleges of agriculture or veterinary medicine, and hospitals whose research is predominantly human subjects commonly fall into this group. The same pattern applies to institutions standing up an animal program for the first time, where protocol volume is low and uncertain, and the sponsored programs office is already running the suite. In both cases, the compliance module meets the obligation at a marginal cost, and the institution avoids a second vendor relationship, a second implementation and a second security review for a program that may never need them.
Where it falls short: The depth of IACUC-specific functionality varies by vendor. Features that a dedicated system treats as standard, such as recording recusals against a specific protocol version or configuring designated member review thresholds by species and pain category, may require configuration work during implementation or may not be available. As protocol volume grows, the committee workload the module was never designed for becomes the constraint.
Individual compliance modules licensed separately
Several compliance committees served by one vendor, with each module licensed, implemented, and run independently.
Where this approach fits: Institutions that have added committees over time rather than all at once, and institutions phasing purchases across budget years. A program that buys an IACUC module this year and an IBC module in two years keeps one vendor relationship, one contract, and one support channel, and staff meet a broadly familiar interface when the second module arrives. For institutions where cross-committee studies are uncommon, this covers each committee properly without committing to a platform implementation.
Where it falls short: The modules are sold together but do not share data, so the reconciliation work stays with the institution. An investigator whose study needs IACUC and IBC approval enters personnel, funding, and procedures in both modules, from the same vendor, with no link between the resulting approvals. When the compliance office is asked how many protocols are open across committees, it runs a report in each module and merges them in a spreadsheet. Modules implemented years apart are often configured by different people to different conventions, so the same investigator or department may be recorded differently in each. Each module also carries its own implementation, its own configuration, and its own upgrade cycle.
Integrated research compliance platforms
Several committees on one platform with shared protocol data.
Where this approach fits: Institutions running several committees at volume, where a meaningful share of the portfolio crosses more than one. Once a few hundred active protocols are spread across IACUC, IRB, IBC, and the safety committees, coordinating between them stops being incidental work and becomes a job someone holds.
An integrated platform changes what that person spends their time on. A compliance director can see which protocols are open, which are approaching expiration, and where a study’s IACUC and IBC approvals are out of step, without requesting a status update from anyone. An investigator running a study that needs both committees describes personnel, funding and procedures once and references the related protocol rather than restating it. Investigators, coordinators and reviewers work in the same interface whatever the committee, so staff are trained once rather than once per system, and a coordinator covering another committee’s workload does not start from nothing.
Where facility operations are on the same platform, animals are ordered against the approved number on the protocol rather than checked against it afterwards, so an overage is identified at the point of ordering, and the census driving per diem billing reconciles to the protocol itself rather than to a copy of it. Semiannual program review and the annual report to OLAW draw on data the institution is already maintaining.
Where it falls short: Breadth is only valuable if the institution runs those committees. A broader platform usually means a longer implementation and more internal coordination to configure.
If your institution runs a single high-volume IACUC and nothing else, a focused standalone system may serve you better than a platform.
Four questions that determine the right fit
Four questions separate institutions more reliably than any feature comparison.
How varied is your research? A study involving genetically modified animals usually needs both IACUC and IBC approval. One that also involves human tissue may need the IRB. If that describes a meaningful share of your portfolio, the cost of running separate systems is the duplicate entry and the manual tracking between them.
Does facility activity need to stay tied to protocol limits? Animals are housed under an approved protocol, and protocols specify the number of animals approved for use. If your census, ordering, and per diem billing sit in a different system from your protocols, reconciling them is recurring manual work, and discrepancies tend to surface during an inspection.
Who owns configuration after go-live? When institutional policy changes, can your administrators adjust required questions, review pathways, and notification rules? Or does every change become a vendor services request? This single answer determines how the platform feels in year three more than any feature does.
What does your semiannual and annual reporting currently cost you? The IACUC reviews the program and inspects facilities at least once every six months, and Institutions holding a PHS assurance report annually to the Office of Laboratory Animal Welfare (OLAW). If that reporting is assembled each time manually, the system is not supporting the obligation it should support.
Where Key Solutions fits
Key Solutions eProtocol is an integrated research compliance and administrative platform.
For animal research, Animal Subjects (IACUC) handles protocol submission, review and approval. Lab Animal Resources Software (LARS) manages census, ordering, housing and per diem billing. Lab Animal Health Software (LAHS) holds clinical observations, treatments, and animal health records for the veterinary staff. IACUC-PAM supports post-approval monitoring, scheduling inspections and record reviews, recording findings against the protocol they relate to, and tracking corrective actions to closure.
Because these are integrated and not interfaced, the approved protocol governs what happens downstream of it. Animals are ordered against the number the committee approved. Per diem charges reconcile to the protocol rather than to a copy of it. A veterinarian recording a treatment is working against the procedures that protocol permits. When an amendment changes any of this, the change takes effect across all of it.
The same platform carries the institution’s other committees and its grants and conflict of interest functions, each with its own submission form and review workflow because each operates under a different regulatory framework. What is shared is the institutional data underneath and the interface people work in, which is what gives the compliance office visibility across committees without assembling it.
