Reporting adverse events on e-form saves time

Pilot program already garnering praise

A pilot program of a web-based system for reporting adverse events in clinical trials already has shown itself to be a timesaver for study staff at the Dana Farber/Harvard Cancer Center.

The program allows investigators to submit adverse events on a web-based form and IRB staff to view up-to-the minute information on submissions with the click of a mouse button, says Deborah Barnard, MS, CIP, assistant director of quality assurance and education at Partners Human Research Committee.

Barnard helped develop the e-form in use at the cancer center, which is a collaboration among the Dana Farber Cancer Institute, Harvard Medical School, Harvard School of Public Health, Beth Israel Deaconess Medical Center, Brigham and Women’s Hospital, Children’s Hospital Boston, and Massachusetts General Hospital (Partners Health Care is made up of Brigham and Women’s Hospital and Massachusetts General).

For an organization such as Dana Farber — five Boston-area hospitals participating together in a "virtual" cancer center — the time saved taking adverse event submissions to the IRB has been a real boon, Barnard says.

"We do know that since we’ve been able to implement just these very modest e-submission tools, we estimated we’re saving people five to eight hours a week, in just walking back and forth time," she says. "Not to mention all the stuff that was just getting lost.

"That’s a lot of time out of someone’s week, when you know they’re already overscheduled."

Real-time information available

The e-submission form looks like the center’s paper form for reporting adverse events. Currently, it’s only in use for adverse events from clinical trials, but Barnard says it later could be used to report other unanticipated problems in studies.

An investigator can key in a five-number ID code and call up basic information about the study in real time — the study title, the name of the investigator, its current status, etc.

He or she then goes through the e-form, answering all of the questions. Many of the questions are required; when the investigator reviews the form, the program will highlight any omissions, as well as raising a red flag if information submitted conflicts with existing policies, Barnard explains.

Once the investigator submits the e-form, an e-mail is generated to confirm the submission. The investigator also can print a copy for his or her paper records.

Back in the IRB office, the staffer who is responsible for handling adverse events reports is notified by e-mail that a report has been submitted, Barnard says. The program also links to the IRB’s database and updates the numbers of adverse events for the study.

"She would print off a paper copy for the IRB, because the IRB still reviews the hard copy," she says. "Then she’ll go into the database and mark that [the report] is pending, and it would start through the process, with it ultimately getting scheduled for full review or just ending up with an expedited review."

The IRB still is developing a tool to use to analyze the data submitted through the e-forms. "But the basics are such already that we can say, It seems like we’ve been seeing this particular event in this drug a lot.’" Barnard says, making it a useful tool to spot trends early.

Because of the automatic updating of the database, the IRB always has access to the most current data on adverse events.

"When pulled up, it’s up-to-date as of that moment," she says. "It’s all live, real data."

Barnard credits much of the success of the project to two key factors:

Seeking lots of input. At the beginning, the developers of the e-form sought opinions from those who would be using the information — the IRB committee that reviews adverse events.

"We wanted to find out what was really important to them, both in terms of what they received on the form and what information they would like to have access to, literally at a moment’s notice and how they would make use of that information," Barnard says. "That was our first step."

The developers later went back to the committee as well as to IRB chairs and study staff, to show them the prototype and elicit feedback."

"They could have a look and tell us what they thought — actually use it and say, That doesn’t work, or this doesn’t make sense,’" Barnard says. "We were able to create help texts, and make adjustments immediately, based on actual user feedback."

Among the changes: Adding more required fields because of feedback from study staff. Because they dealt with different sponsors and other outside groups, they had a better idea of some of the information those groups were looking for, she reports.

"It’s important to really think those steps out and be open to both criticism and people’s desire to help," she says.

Finding the right technical help. Barnard says the developers hired a programmer who was familiar with the architecture of the existing database, having served as a consultant when it was created in-house.

He was also, she says, a good listener — able to understand their goals, and the necessity of making the form user-friendly for investigators and study teams as well as IRB staff and the IRB chairs.

"It’s really an interesting combination of somebody who has those amazing technical skills but that real people skill to listen and understand and appreciate what you’re doing," she says. "He ended up spending months and months with us and learning more and more about every aspect of this one particular piece, which was a very complicated process."

Finding that combination of technical skills and user sensitivity can be difficult, Barnard says. Often technical staff want to change the process of how an organization works to fit the technology.

"This project had actually been discussed three years before, and the reason it never went forward was because the computer guys decided how it was going to be done, and all the IRB staff said, You’re crazy, that’s not how we work,’" she says. "It literally didn’t go anywhere until we were able to get the funds and engage this programmer."

The e-form pilot project at Dana Farber launched last June; developers still are tweaking it to get it ready to make it the required submission form for all adverse events. But so far, Barnard adds, response has been positive, primarily because of the time it saves.

"We did focus groups all along the way and we got some really good feedback," she says. "It saves so much time from printing and hand-carrying or printing and having to rely on our interoffice mail, which isn’t that great."

There have been a few kinks along the way. During development of the e-form, the National Cancer Institute updated its Common Terminology Criteria for Adverse Events. The e-form was based on the old version; Barnard says that changing to include the new version is one factor holding up making the e-form a required submission form.

For IRBs interested in tackling a similar project, Barnard has this advice: Don’t give up.

"It’s really disheartening when it takes longer than you think," she says. "I think we’re all were feeling kind of embarrassed that we weren’t able to make our own deadlines. But stuff happens that you don’t anticipate, and that’s really beyond your control. Just keep plugging ahead, because you want it to be a quality product.

"We really believe it’s going to enhance every aspect of our program," Barnard says.