Previous Message | Next Message Previous in Topic | Next in Topic Previous by Same Author | Next by Same Author Previous Page (September 2005) | Back to Main CABIG_CTMS_AESIG-L Page
	Reply | Post a New Message | Join or Leave CABIG_CTMS_AESIG-L, or Change Options | Search
	Chronologically | Most Recent First | Wrap Text (Proportional Font) | Don't Wrap Text (Non-proportional Font)

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
Thread-Topic: Reportable AE vs. non reportable AE events
Thread-Index: AcWNh2wDLatqX1b7RdaEtzdmHq7iOwxa4BcQAAJa1YAAJ1TOEA==
Message-ID:  <[log in to unmask]>
Date:         Thu, 22 Sep 2005 14:42:52 -0400
Reply-To:     Bob Morrell/Cancer Center <[log in to unmask]>
Sender:       "caBIG(TM) CTMS Adverse Events Reporting SIG listserv"
              <[log in to unmask]>
From:         Bob Morrell/Cancer Center <[log in to unmask]>
Subject:      Reportable AE vs. non reportable AE events
Comments: To: "Pannoni, Susan" <[log in to unmask]>

I want to put forward (again, but in a more coherent fashion I hope) my concern about the idea of using the AE reporting tool to collect routinely not reported toxicities.
 
As I have noted, I believe the tool should focus on the task that was requested of it on the first day when the centers devised the list of things they wanted from caBIG: a tool to facilitate the reporting SAE to external bodies. While we might all agree that having a single repository of reportable events and unreported analytical data is a good idea, it goes beyond the request, and some very clear disfunctionalities occur when you try to make a tool do these two very different things. 
 
Event reporting is event driven. No event, no reporting, no use of the tool.
 
Analytical toxicity data include three different kinds of data: Reported AE's Unreported AE's, and normal values (that is, AE's ruled out)  The data is typically gathered in batch, when the patient completes an analytical period (some of our protocols use cycle, most use the whole treatment period), and the protocol may specify a large batch of expected/worried about toxicities that must be recorded, even if they did not occur. That is, our CRA's pull up a toxicity form for the patient that may contain 27 things that are defined by the protocol as things to watch for, and enter values and or grades, even if the grade is zero (normal). Sometimes, if the test or observation was not done (someone dropped the tube in the lab) they must denote "not done". I do not see for example, how this last kind of less than non event data would be entered using the tool as described today. After they do the pre-loaded list, the CRA then adds any additional toxicities that occurred.
 
This tool, as constructed, is a single event entry tool (one use generates one record). if it attempts to be used for the entry of both reportable adverse events AND a place to enter toxicities for analysis,  the lack of a protocol defined preloaded batch entry make it very inefficient and, and would thus greatly increase the amount of time it would take to gather this data. Use of this tool for both purposes would more than negate its intended efficiency: assisting the filing of reports to exeternal and interal groups. Furthermore, inconsistant use, (those of us who use the exit ramp when we see that it is not a reportable event, and those who enter everything) would make the data inconsistant and unusable for cross center analysis.
 
What might make this usable is a branching point on the first screen that asks the question:
 
Do you believe this is a:
 
1) Reportable Adverse Event
2) Analytical data entry
3) Help me decide
 
#1 and and # 3 would send you into the entry screens discussed at the last teleconference.
#2 would send you to a batch entry screen, loaded with a protocol defined template. Any events entered previously in #1 and #3 would already be there. The rule base could be applied to routine analytical entries to see if they qualify for reporting, (that is, the CRA was mistaken in their assumption)
 
I cannot emphasize enough how important this is for the operational success of the tool. We have suffered mission creep here, and I know from personal programming experience (yes, it was bitter) that a tool that does one thing well that someone does occasionally but does another thing horribly that someone does every day will not be a tool that gains acceptance. 
 
¤ø,¸¸,ø¤º°`°º¤ø,¸¸ Bob Morrell
¤ø,¸¸,ø¤º°`°º¤ø,¸¸ Cancer Center
¤ø,¸¸,ø¤º°`°º¤ø,¸¸http://home.triad.rr.com/bmorrell/ 

[text/html]

Center for Information Technology National Institutes of Health Bethesda, Maryland 20892 301 594 6248 (v) 301 496 8294 (TDD) Comments and Assistance Accessibility