Premise
Most people, when designing an adverse event (AE) case report form (CRF), believe they know the right way to capture AE Seriousness data. A random selection of 10 people would produce at least 3 different opinions, each of which can be best practice in a specific situation. Implement a design based on one set of assumptions in another environment, however, and best practice can become seriously flawed. This article explores different data capture designs for AE Seriousness and discusses where they would be appropriate.
Defining “AE Seriousness”
The US regulations and the ICH guidances are uncharacteristically clear about what constitutes a serious adverse event, and they are consistent with each other. The ICH definition of “Adverse Event” is
Any untoward medical occurrence in a patient or clinical investigation subject administered a pharmaceutical product and which does not necessarily have to have a causal relationship with this treatment.
A serious AE is a one that meets the above definition and additionally has one or more of the following characteristics:
Fatal Life-threatening
Requires in-patient hospitalization or prolongs hospitalization
Results in significant or persistent disability/incapacity
Congenital anomaly/birth defect
“Overdose” was originally on the list but was removed some years ago. Medical device guidance adds “serious injury/serious illness”, which is defined as “necessitates medical or surgical intervention to preclude permanent impairment of a body function or permanent damage to a body structure.” There can also be additional AEs that are serious for a given trial based on requests from the regulatory authorities. SAEs must be reported promptly to the regulators, and the reports include many details that are not entered into the clinical database. These may include hospitalization, the circumstances of death, autopsy reports, and a full written narrative of the case. The clinical database generally treats SAEs and AEs the same, other than SAEs bring flagged to indicate that they are serious.
Storing Serious AE Data
Historically, while non-serious AE data were stored only in the clinical database and managed by the clinical data managers, SAEs were often handled by the sponsor’s regulatory or drug safety group. As CRFs were often not completed for weeks or months after the subject’s visit, this enabled the required expedited regulatory reporting and supported ongoing safety monitoring. Although electronic data capture and reporting systems are more available, and there are a few integrated solutions, CRF data are still generally not entered real-time, and most organizations still store this information in two different systems, each of which may contain partial data. While it must all be included in the AE domain for an SDTM-compliant submission, that merely means that it must be available, not that it must be stored in one place.
Some Considerations
Current industry standards (such as CDISC’s CDASH and SDTM) provide two approaches to recording in the clinical database whether the AE is serious – a single yes/no field, and a list of fields defining the serious criteria that are each marked either with a yes/no question or a “check all that apply” structure, as shown here.
Recommendations
- The standards do not specify how to use the fields or how they should interact. Here are some things to consider when making this decision.
- Flagging AEs as serious in the clinical database is necessary. It allows the AEs to be summarized separately in the study report, and identifies those that must be reconciled with the safety database. Generally, CDASH discourages capturing the same information twice, which implies that the form should either ask if the AE was serious, or capture the list of criteria.
- CRFs, whether paper or electronic, are usually not completed during or promptly after the subject’s visit, making them a poor trigger for the SAE reporting activities, and suggesting that the individual criteria list should not be used for that purpose.
- Generally, especially for shorter lists, individual yes/no questions are preferable to “check all that apply,” especially when it is critical to evaluate each item. This is consistent with the CDASH recommendations. Although there is no firm cutoff number above which “check all that apply” is acceptable, the decision should be driven by the importance of evaluating each item and how much additional CRF completion work would be created by individual questions.
| Situation | Field inclusion |
| The safety database captures the serious AE information including the serious criteria and The seriousness criteria are readily available to the summary programmers | Clinical database should contain just the one yes/no field |
| Paper CRFs are used | The clinical database should contain either the one yes/no field (if the criteria are available from the safety database) or the individual criteria fields, but not both |
| The safety database does not contain the individual criteria or The data are not readily available to the summary table programmers | Clinical database should contain just the individual criteria fields |
| The clinical and safety databases are integrated so that data capture is performed only once | Clinical database should contain the individual criteria fields |
| The EDC system uses the one yes/no question to determine whether to bring up the individual criteria questions | Clinical database can contain both sets of fields as long as entry checks ensure data consistency |
| The EDC system asks the individual criteria questions and if any is “yes”, the one yes/no question is derived to “yes”. This may be used to trigger access to the safety database, but this approach should only be used if there are system requirements or some other compelling reason to do it. | Clinical database can contain both sets of fields, but only the individual criteria fields should be entered |
Conclusion
As suggested at the beginning of this article, there isn’t one correct answer to the question of what fields to include. That decision needs to be made in consultation with multiple functional areas to ensure all needs are met, and requires the application of judgment. Like so much of clinical data design, the more thought and collaboration there is, the higher the quality the result.
