IRB Computer Systems

In line with the purpose of this blog, which is to share my experience, I thought I'd discuss IRB computer systems. Let me make a couple of points up front. First of all, I am not going to talk about specific products or make product recommendations. As a consultant I will make recommendations regarding IRB computer systems to my clients, but I don't think I should do this on a public forum. Second, I do have a lot of expertise in this area. I developed my first IRB computer system in 1984! Yes, back in the dinosaur era of computers. The system I developed started in a program called Enable (probably one of the best computer systems ever), then in FoxPro and then in Access. I am in the process of developing a system in Access now for a client. I have also worked with a number of clients who have implemented or tried to implement some of the commercial systems on the market now. So, I do know something about IRB computer systems.

The first thing you need to keep in mind when considering IRB computer systems is the difference between IRB systems and most database systems. Most database systems are record-tracking and reporting systems. IRB systems are primarily communication systems. Although IRBs need to track protocols and occasionally produce reports, the most important function of an IRB system is to automate communcations - producing agendas, minutes, letters and other communications between the IRB and IRB members and investigators. These communication functions should be at the heart of any good IRB computer system and should be as automated and user-friendly as possible.

The second thing to keep in mind is that the system should be as customizable as possible. No two IRBs are the same and each one does things differently. The IRB should be able to tailor the system to meet its business practices. Customization should be easy and not require reprogramming the system. Ideally, the users should be able to customize the system themselves. IRB processes often change in response to new standards or best practices. If a computer system needs to be reprogrammed in order to incorporate minor changes, then it wil not meet the needs of an IRB.

Ideally, an IRB computer system, in addition to providing easily customizable administrative functions, should also provide for electronic submission and review of IRB protocols. Most investigators would be eager to submit their protocols electronically, but getting IRB members to electronically review protocols is a more difficult task. In addition to electronic protocol submission, a good system should also allow investigators to check on the status of their protocols themselves. This saves a lot of time for IRB staff.

I want to make two final points about IRB computer systems. First, I think a system you develop yourself is always better than purchasing a commercial system. As I said, no two IRBs are the same and no commercial system can do exactly what you want it to do. However, developing your own system take a long time and considerable expertise. The key to developing your own system is finding a computer person who understands or can be made to understand exactly what the IRB does and its needs. Second, I don't believe that "integrated systems" where Grants & Contracts, Tech Transfer, the IRB and IACUC are all in one system are necessary or desirable. These offices have very different functions and computer needs and making one system do it all often results in forcing square pegs in round holes. An integrated system is not necessary. These offices only need to share a limited amount of information and that information can be exported and imported between different system very easily these days.

A good IRB computer system that automates most of the clerical functions of the IRB can be the equivalent of .5 to 1 fte in IRB staff. By automating clerical functions, a good system can free up IRB staff to do less paper pushing and devote more time to working with investigators and doing administrative pre-review. This will result in expediting the review process and happier investigators. Note, however, that I said a "good system". A bad system can suck up IRB resources, both financial and human. There are good commercial systems out there, but you need take care in selecting a system that meets the needs of the IRB. It is also possible to develop a good system yourself, but it takes time and the appropriate expertise.

Apology

I don't know how many people actually read this blog, other than those who have commented on it, but I owe you all an apology. A blog is not very useful if it is not updated regularly and I have been very lax in adding posts to this blog. One of the problems in being a consultant is that work goes in spurts and the last few weeks have been very busy for me. I'll try and make it a point to enter posts on a more regular basis from now on. If I don't, feel free to nag me about it. As many who know me well, I need a lot of nagging.