Why Standardizing Common Data Elements is Not Enough

Using the same element for multiple purposes isn't always wise!

The fashion these days is to standardize at the individual common data element (CDE) level. Thus, when standards are developed, they tend to focus more on characteristics of the CDE alone and less on its relationship with other CDEs. While this may initially seem to be the simplest and most logical approach, it risks omitting information that later users may need to interpret the data correctly, especially when the data are pooled for meta-analyses or data mining. If “quality data” are defined as “data that are fit for their intended uses,”1 then this threatens the quality of the data and the conclusions drawn from them.

The Case for CDEs

Many organizations are developing CDE libraries, from CDISC2 to many parts of the US National Institutes of Health3 to medical associations such as the American Heart Association4. They differ in their uses of the data, e.g., for patient care vs. clinical research, but there are some basic characteristics that most include in their definitions, which can be found in Table 1. Some even standardize categories of elements, e.g., generic yes/no question, or generic start and end dates. Many standards are robust and resolve many issues, such as different variable names in different databases, different code lists, conflicting types (e.g., character vs. numeric) and so on, making data-sharing easier and more reliable. It makes sense to organize standards by CDE; from a data collection point of view, it is the smallest independent unit that cannot be further subdivided, and it can be grouped in different ways to form case report forms, health care charts, etc.

The Challenges with CDEs

There are drawbacks to this approach. Many CDEs are not independent, and either need or are supportive of other CDEs, without which they lose their meaning. Some of these relationships may seem self-evident, and many think they do not need to be defined, but other relationships are less so. Where and how to define these relationships is a challenge, as they reasonably belong in the definitions of all members of the relationship. It is not considered good practice, however, to duplicate information, and some relationships may not hold for all studies. Also, data have many lives, from capture, e.g., on a case report form (CRF) for a clinical study, to inclusion in a regulatory submission, to data repositories, to supporting clinical care, and much else that cannot even be envisioned yet. Even supposedly self-evident relationships may not be so obvious in other contexts.

Because the data will outlive their initial purpose, it is important for users to understand the assumptions and constraints that influenced the data elements’ definitions, or they may use  the data inappropriately. Even if the data elements library accompanies the data and the elements were used exactly as defined, the libraries often do not define these relationships.

Examples of Challenges

1. Measurements and Units of Measure

This is the most obvious example. Measurements have no meaning if the unit of measure is not defined. For example, a weight of 25 is not useful unless we know if it is in kilos or pounds. Both are reasonable pediatric values, but can have different implications depending upon the age or condition of the subject. Many organizations preprint or “paint” the units on the CRF because the form filler either just knows to use one unit or the other, or the protocol defines it.  When the data are entered into a database or electronic CRF (eCRF), the units may be placed in the label of the measurement (perhaps to minimize the number of variables required) or may not be captured electronically at all, under the premise that the protocol defined the unit so it can only have one value and therefore does not have to be “databased.” If the data without units from one organization are later pooled with data from another, one can no longer assume that the units are the same and weights become unusable.

2. Adverse Event and Severity of Event

There are two potential challenges here. The first is that Severity of Event has no meaning by itself, but only in relationship to the adverse event (AE). This may seem obvious, but when specific AEs are assessed they may be pre-printed on the CRF, and because the focus is on the study, it is assumed that everyone knows what the AE was. If the AE term is not included in the database, all the AE data become unusable, and not just the severity. The more general point here is that any element that describes or modifies another element may not be usable unless the modified element is included. The second challenge, while not directly about combinations of elements, is also a potential quality issue.

There are typically 2 code lists (or sets of controlled terminology) used with the severity field: Mild, Moderate and Severe (for most AEs) and the same three plus Life-Threatening and Fatal. It should be very clear which one is used in each study, and this information should remain with the data throughout its lifecycle. This is because if only Mild, Moderate and Severe are present in the database, it is unknown if Life-Threatening and Fatal were not on the CRF or were not observed in the study. This is true for all cases where subsets of code lists are used.


3. Reference Ranges (aka Normal Ranges)

Reference ranges are elements that define the highest and lowest expected values of a specific response. The most common reference ranges are the upper and lower limits associated with laboratory tests. For example, the expected minimum and maximum values of urine glucose for healthy individuals might be 0 mg/dL and 15 mg/dL respectively. A value of 20 mg/dL is not interpretable in the absence of the reference range. Although it requires more storage space, it is best to include the relevant reference range on every record in a lab dataset as this helps to prevent ambiguity. While ranges for many tests can be found in textbooks or online, these may not be applicable to the subject population in the study, which can influence the interpretation of the data and affect the reliability of the conclusions. This requirement should be specified in the standard data element library.

4. Image Quality

A recent set of CRFs captured information about images, and the following question was seen:

Indicate the quality of the image:

• Adequate quality
• Exemplary quality
• Limited quality
• Not adequate quality

The quality of the image affects its interpretability and the confidence in the result, and in this case it is clear that the quality of the image is judged in the context of the study’s requirements, i.e., “Is it good enough for its current purpose?” In the case of 3-D images, such as MRIs, images consist of a series of “slices,” each of which is a 2-D image that is stacked with other slices to build a 3-D picture. It is possible for one part of a 3-D image to be good quality and another to be poor quality, or some slices to be fine and others to be unusable for a given purpose. A single question asking about the quality of the image does not provide enough information to distinguish if it refers to the entire image or just one or a few slices. Whether this is an issue depends upon how the question is used. If the quality question in one study assessed the entire 3-D image while in a second study it assessed sets of at least 15 slices, then if these studies are pooled and all Exemplary images are identified, these will not be consistent or comparable. On the other hand, if the quality question is used only to determine if there should be an interpretation of the image present in the database, then there is no issue. This assumes, however, that the intent of the question is clear to users later in the data lifecycle, and today this is an unsolved challenge.


5. Overlapping Elements

In a data elements library reviewed recently, the following three CDEs were present:

1. Reason test was not completed

• Equipment failure/error
• Medical reason
• Other
• Participant death
• Participant refusal
• Participant withdrew
• Scheduling problem
• Unknown

     2. Other reason test was not completed (open text field)
     3. Medical reason test was not completed

• Abnormal laboratory level
• Adverse Event
• Claustrophobia
• Injection complication
• Progressive disease

Each question by itself is fine, but as is often the case, there was no indication of what fields were intended to be used or not used together on the same CRF.

• Question 1 asks for a general reason why the test was not completed, and one of the responses is Medical Reason. 
• Question 2 provides a place to specify a reason if it was not included in the list. 
• Question 3 asks for the specific medical reason. 

If all three are used together, they provide two places to capture that there was a medical reason, which would need to be cross-checked for consistency. If the reason was not medical, Question 3 would have to be left blank as there is no way to indicate that it was not a medical reason. If the reason was a medical one, but not listed in Question 3, it is quite likely that a form filler might check Medical Reason for Question 1, specify the reason in Question 2, and leave Question 3 blank.
This issue could be resolved either by not using the three elements together, or by laying out the CRF such that the Medical Reason list from Question 3 was next to the Medical Reason response in Question 1, although this works better for paper CRFs than it does for electronic ones. For electronic ones, it might be managed using cursor controls where the list of medical reasons is only accessible if Medical Reason is checked for Question 1.
In any case, the issue remains that this kind of information is not typically included in the CDE library and thus may not be apparent to users, leading to the same data being captured inconsistently.

Conclusions

For data to be high quality, current and future users must understand how to use the data appropriately. These examples show that having standard CDEs is not enough to ensure high quality data, and that users must also understand, among many other things, the relationships that elements have to each other and how to use them together. This may seem obvious, and perhaps people who do not understand it should not be designing clinical trials data. This may or may not be true, but what is obvious to one person is not necessarily as obvious to another, especially when the uses are very different. Including these relationships in CDE libraries may be appropriate, but in other cases it may not be, for example, because they are very study- or institution-specific. In addition, CDE libraries are not typically stored with the data, and may not be available to later users. What is really needed is a mechanism for ensuring that these design and handling rules and assumptions are associated with the data as they progress through their lifecycle, and that data are defined in a way that is easy to review and apply. There is no such structure currently available, but in order to ensure that the data repositories of the future are robust and their data are used in appropriate ways, this issue will have to be addressed.

Table 1. Data Element Characteristics that are Commonly Standardized



End Notes
1 Institute of Medicine. Assuring Data Quality and Validity in Clinical Trials for Regulatory Decision Making. Jonathan R. Davis, Vivian P. Nolan, Janet Woodcock, and Ronald W. Estabrook, Editors. National Academy Press, c. 1999
2 Clinical Data Interchange Standards Consortium. www.cdisc.org
3 National Institutes of Health: These are some institutes that have published CDE information: National Cancer Institute Data Standards caBIG: https://caBIG.nci.nih.gov
National Institute of Neurological Disorders and Stroke:
http://www.ninds.nih.gov/research/clinical_research/toolkit/common_data_elements.htm
Office of Rare Diseases Research: http://www.grdr.info/index.php/common-data-elements
4 American Heart Association: http://circ.ahajournals.org/content/112/12/1888.full

© Kit Howard, Kestrel Consultants, Inc.
Originally Appeared in K-News, Feb 2012.

We Don't Know What We Don't Know: Judging Data Fitness for Use in Submissions

Poster Presented Mar 2013 at CSS/PhUSE conference, Silver Spring MD

Converging Data Challenges: How to Help the FDA

The FDA and DIA collaborated on a meeting in March on the data challenges faced by the FDA, and the role that, among other things, industry and standards play in making their actions more efficient. Kit wrote an article on the meeting and its implications for industry and standards, which was published in ClinPage. You can find it here:


http://www.clinpage.com/article/how_to_help_fda/C9

EDC Help Text or No EDC Help Text: That is the Question

Should EDC applications should contain completion instructions and/or help texts associated with individual fields or eCRFs?

Some believe that if the questions are worded clearly, the cursor control is logical and helpful, the layout is clear and uncluttered, and appropriate data capture structures are used (e.g., radio buttons, dropdown lists), then there should be no need for additional instructions or help as the form should stand on its own. To address differences between sponsors in layout, cursor control and question wording, a study conventions document can be prepared that contains general information regarding entering data and the like.


I believe that this is only part of the picture. Without question, EDC prompts should be very clear, use appropriate field structure, and so forth. These characteristics are tightly linked to defining and capturing high quality data. It is also not necessary to create help texts that only restate the prompts, e.g., a help text of “Please enter the subject’s weight” on a field with the prompt “Weight.” Finally, a study conventions document can provide valuable information about navigation, handling individual fields with missing data (e.g., put a note in the pop-up query window), and the like.

On the other hand, such a document does not educate the sites with respect to many of the sponsor’s other expectations for data quality and consistency, which can be thought of as the scientific or business rules, and this can be quite a thorny issue. For example, the study conventions document does not provide specific information on the edit check ranges used on the fields, nor why those ranges were chosen. It doesn’t usually alert the site to data relationships the sponsor expects to see, such as AEs corresponding to each new concomitant therapy started during the study. In fact, virtually everything that the sponsor expects check and that could result in a query should be communicated to the site in some way. Otherwise, how is the site supposed to know how the data should be captured and recorded? It is like requiring them to take a test on material that they have never been taught!

Some of the information mentioned above could be drawn from the protocol, but many protocols do not go to this level of detail, and given that study coordinators often run many studies with different sets of rules, it would seem safer to add the rules to the tool they use to prompt them for those data. The information is also in the Data Management Plan, but most sites do not see that. Given the amount of disagreement there is on chat forums such as LinkedIn, it is clear that there is no consensus on many of these practices, so how can we expect the sites to “just know” what to do? Here are some more examples of scientific or business rules that I have seen vary either on discussion forums or between clients:

• When in a study to start capturing AEs and SAEs?
• How far from the protocol-defined visit day can a visit occur and still be “compliant”?
• Over how many days can a visit occur and still be “compliant”? E.g., bloods one day, physical exam the next, ECG the following.
• How should open AEs and concomitant therapies be handled if the subject dies during the study (i.e., should they be closed out with date of death as the end date, or left open)?
• What conditions should be recorded on the medical history screen? I.e., starting at what time point, or “clinically significant” ones only (though that definition is not always clear)?
• Should symptoms or diagnoses be recorded on AE eCRFs?

If these questions and many more like them are not defined for the sites in a way that is clear, accessible and user-friendly, then we will generate ever more queries and worse, the data will be less comparable and uniform (i.e., lower quality), and we may not even know it.

New FDA Guidance Requires More Data for Every Trial

In July 2009, the FDA issued a new final guidance defining clinical trial design, data and analysis requirements for drug-induced liver injury, or DILI, cases in all drug and biologic agent clinical trials.

DILI occurs in of 1 in 10,000 patients or less, and currently there is no way to predict what drugs may cause the condition, nor which subjects will be affected.

The guidance lists some specific data points that must be collected for subjects who experience DILI that go well beyond the data that is usually collected for most subjects in most trials.

This will require some considerable rethinking of how we capture and store some types of data. If you’d like to learn more, please see the lead article in the January 2010 edition of K-News, available on the News page at www.kestrelconsultants.com.

Complexities in Reporting SAEs: What Do the Regs Really Say?

“If a patient is randomized to the study but never receives study drug, must site staff report serious adverse events (SAEs) for this patient?”

This excellent question was recently asked in the CDM group on LinkedIn. The responses ranged from assertions that regulations require that either serious or all AEs must be reported starting at informed consent (IC), to suggestions that, in the absence of any internal company guidance, they should be captured as they can be eliminated from the analysis based on the “definitely not related” assessment.

I think the answer is probably “it depends”! As with most aspects of clinical research, deciding what to collect and to report requires understanding the risks associated with the different choices. That requires understanding, among other things, the context of the question, where and when the research occurred, and who intends to use the data and for what. Below you will find my thoughts on some of these factors.

(Incidentally, if anyone can point me to a place in a regulation where it defines “on study” as beginning with signing IC, and/or where it clearly states that SAEs must be captured beginning at IC, I’d be grateful. I was unable to locate any such statement, but my sources are primarily US regulation and guidances, ICH guidances, ISO standards, and some European regulations and guidances.)

The Question

The original question was whether SAEs occurring after randomization but before treatment must be reported. Because of the range of responses in the Group, I have also expanded the question to “Must all AEs and/or SAEs occurring on study be reported?”

There are two elements to consider here.

• The first is the meaning of “reported.” Does it mean that AE/SAEs must be reported on a CRF? Or does it mean that AEs/SAEs must be reported to regulatory authorities under the expedited reporting rules? Or does it mean that AEs/SAEs must be reported in the study report? Each of these is a valid question, and the answers depend upon a number of factors, some of which are discussed below.
  
• The second is the meaning of “on study.” Is it when IC is signed, or at randomization, or the beginning of baseline, or something else? One could use the term “enrolled” instead, but it turns out that neither term is clearly defined. It does imply that timing plays a role, and this is explored later in this article.
  

What Do the Regulations/Guidances/etc. Say?

As mentioned above, I did not find any regulations or guidances that defined when to start capturing AEs/SAEs beyond those potentially associated with study treatment. Here is what I did find that relates to this discussion.

ICH E2A Clinical Safety Data Management: Definitions and Standards for Expedited Reporting

• Focuses on the requirements for expedited reporting, rather than on determining the timing of what should be captured
  
• Lists the minimal information necessary to send a report, which includes a treatment having a plausible causal relationship with the event
  
• States that there are circumstances where certain SAEs may be exempt from routine reporting, such as when the SAE may be the primary outcome and expected. (KH: This indicates that there is no absolute rule that all SAEs must follow expedited reporting, although this does not speak to whether they are captured.)
  

Definition: Adverse Event (from ICH E2A):

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. An adverse event (AE) can therefore be any unfavourable and unintended sign (including an abnormal laboratory finding, for example), symptom, or disease temporally associated with the use of a medicinal product, whether or not considered related to the medicinal product. (emphasis mine)

Different regulations/guidances have slightly different wording, but all require a potential association with treatment, so if the event occurred prior to treatment it cannot, by definition, be an AE. Thus, a sponsor could capture only those AEs beginning with study treatment and be technically completely compliant.

Definition: Serious Adverse Event (from ICH E2A):

During clinical investigations, adverse events may occur which, if suspected to be medicinal product-related (adverse drug reactions), might be significant enough to lead to important changes in the way the medicinal product is developed (e.g., change in dose, population, needed monitoring, consent forms). This is particularly true for reactions which, in their most severe forms, threaten life or function.

This is part of the definition of an SAE, and indicates some reasons why expedited reported should happen for SAEs. As SAEs are, by definition, a kind of AE, they too cannot occur prior to treatment initiation. In reality, there are times when treatment may not be the only factor to consider, especially with respect to SAEs.

ICH E3 Structure and Content of a Clinical Study Report

• 5.3 PATIENT INFORMATION AND CONSENT: How and when informed consent was obtained in relation to patient enrolment, (e.g., at allocation, pre-screening) should be described.
  
• 10.1 DISPOSITION OF PATIENTS: (…) It may also be relevant to provide the number of patients screened for inclusion and a breakdown of the reasons for excluding patients during screening, (…)
  

Item 5.3 suggests that IC and enrollment are not necessarily the same time point, and 10.1 reminds us that subjects can be excluded during screening, prior to treatment.

ICH E6 Consolidated Good Clinical Practices

• In section 6.9.2, it states that the clinical trial protocol should include The number of subjects planned to be enrolled. In multicentre trials, the numbers of enrolled subjects projected for each trial site should be specified. Reason for choice of sample size, including reflections on (or calculations of) the power of the trial and clinical justification.
  

This implies that enrollment refers to the subjects needed for analysis, not those screened.

21 CFR Part 312.62

(b)Case histories. An investigator is required to prepare and maintain adequate and accurate case histories that record all observations and other data pertinent to the investigation on each individual administered the investigational drug or employed as a control in the investigation. (…) The case history for each individual shall document that informed consent was obtained prior to participation in the study.

The regulation does not define what “participation” means, but since signing IC means agreeing to participate in the study, anything that happens after IC is, by definition, participating in the study. It’s a bit circular, but there it is!

ISO 14155.2 Clinical Investigation of Medical Devices for Human Subject – Good Clinical Practice

Definition 3.32: Point of Enrollment - time at which, following recruitment, a subject signs and dates the informed consent form

This brings up an interesting point:

1. Patients sign IC prior to participating in the study, meaning prior to any study procedures being performed (including those for screening)
   
2. Screening procedures are performed both to determine eligibility and, when appropriate, establish baseline values
   
3. If eligible, the subject continues. It is only at this point that the subject can be considered to be “on study.” Prior to this, eligibility has not been established, and so the subject must not be in the study, as GCP does state that ineligible subjects should not be included! (ICH E6 4.5.1 & 6.5.1)
   
4. Randomization may or may not occur at this point, depending upon the study design (there may be washout, baseline observation or other periods prior to randomization).
5. All of which means that the ISO definition of enrolment does not follow the same logic as the other regulations and guidances.
   

Even here it’s not completely clear, because later in the same standard, the Monitoring requirements state that the monitor should verify that:

f) signed and dated informed consent forms have been obtained from each subject at the point of enrollment and/or before any clinical investigation-related procedures are undertaken,
g) only eligible subjects as defined in the CIP are enrolled in the clinical investigation,

If only eligible subjects are enrolled, and enrollment happens at the time of IC, then all subjects who provided IC must be eligible, which cannot be true because screening procedures have not yet begun!

FDA’s Detailed guidance on the collection, verification and presentation of adverse reaction reports arising from clinical trials on medicinal products for human use, April 2006

5.1.1.2 Other safety issues requiring expedited reporting Other safety issues also qualify for expedited reporting where they might materially alter the current benefit-risk assessment of an investigational medicinal product or that would be sufficient to consider changes in the investigational medicinal products administration or in the overall conduct of the trial, for instance: (…)
c) new events related to the conduct of the trial or the development of the investigational medicinal products and likely to affect the safety of the subjects, such as: - a serious adverse event which could be associated with the trial procedures and which could modify the conduct of the trial, - a significant hazard to the subject population such as lack of efficacy of an investigational medicinal products used for the treatment of a life-threatening disease, (…)
5.1.2 What should not be reported? Expedited reporting is not usually required: - for reactions which are serious but expected, - for non-serious adverse reactions whether expected or not. It is generally not necessary to report events that are considered unrelated to the investigational medicinal product.

This last part speaks particularly to the distinction between capturing the SAEs and doing the expedited reporting. Section c. above brings in the point that study procedures may also cause SAEs, and although SAEs by definition must occur during treatment, study procedures happening during pre-treatment periods may also be important.

The take-home message is that one has to think about the context of the definitions, the spirit of the regulations/guidances/etc., and the specifics of the trial in order to determine the best course.

The Importance of Context

Why do we capture AEs and SAEs in a trial? We are trying to determine if the treatment causes undesirable effects that outweigh its benefits. We want to tease out the relevant events from the “background noise.” If randomization has happened appropriately, and there are no other sources of treatment assignment bias, and the investigators understand how to identify treatment emergent AEs, then the incidence of any given non-treatment-related AE in each treatment group should be the same, as should the incidence of the AE in the pre- and during-treatment periods. This suggests that, absent any additional risk factors or protocol design requirements, it should be unnecessary to capture AEs prior to treatment.

The question then becomes what to capture and/or what should follow expedited reporting rules. The following are other factors to consider.

• Screening procedures: if the screening procedures are invasive or otherwise risky, capturing AEs/SAEs prior to randomization may be desirable, as it may influence the conduct of the trial, and/or the requirements for patient monitoring after the product is approved. Whether they should be subject to expedited reporting would depend upon an assessment of the other factors below.
  
• Indication/population: how severe is the indication? If the subject population is quite ill, and SAEs are expected, then it may be appropriate to capture the SAEs, but not do expedited reporting. This should be defined a priori in the protocol after discussion with regulatory authorities, the company’s regulatory affairs and clinical colleagues.
  
• Time frame: If the decision is to capture SAEs for subjects who were randomized but never receive treatment, what time frame should be used? Should they be captured only for subjects who didn’t receive treatment because of the SAE? Should the subjects be monitored for the same follow-up duration as treated subjects? Should the SAEs be subject to expedited reporting, considering that it is known the subject was not on treatment?
  
• How much is known? If very little is known about the indication, treatment, study population and/or expected SAEs, then it would be appropriate to capture and report more information, as it is more likely that an event would be unexpected. As noted above in the FDA’s AE reporting guidance Section 5.1.2, if certain SAEs are already known to occur and this is documented in the Investigator’s Brochure, expedited reporting may be unnecessary, even if they are still “reported” on the CRF.
  
• Geographic location: where is the study being conducted? The regulatory authorities in different regions may have different requirements or preferences for how much should be captured/reported.
  
• Study design: randomization does not necessarily happen when the subject is enrolled, meaning that IC is signed and all eligibility criteria are met, and the subject is cleared to continue in the study. There can be washout periods, baseline observation periods, or other epochs that occur prior to randomization, and collecting AEs and/or SAEs may or may not be necessary. Much depends on the procedures performed and whether there is interest in comparing AE/SAE incidence before and after treatment.
  

Consequences of Reporting and Not Reporting

There are other, perhaps less obvious, consequences to these decisions.

• Capturing SAEs: capturing SAEs requires providing considerably more information than is necessary for AEs. This is an additional burden on the site. It can also be a burden and expense for the sponsor, as it requires additional attention at each stage from data entry to data management to analysis and report writing.
  
• Reporting SAEs: The burden is even greater when the expedited reporting processes are followed, as this requires completing additional forms, informing the sponsor and also the Institutional Review Board (IRB)/Ethics Committee (EC). The IRB/EC can be swamped with reports of routine events, which reduces their effectiveness. Finally, the receiving regulatory authorities have to distinguish between important events and those that are reported because the site/sponsor/etc. is being ultra conservative. This impairs their ability to respond to the critical events.
  
• Analyzing the data: analysis and study reporting happen using the data that are captured. Whether SAES from randomized-but-not-treated subjects are included in the general intent-to- treat analyses or are put in a separate table is the choice of the biostatisticians, medical writers and clinicians responsible for the study report.
  

Bottom Line

I don't think it's possible to answer the overall question with an absolute statement of yes or no.

• It is usually appropriate to capture SAEs for subjects who have been randomized but not treated, but they generally don’t need to follow expedited reporting.
  
• It’s also usually unnecessary to follow expedited reporting for SAEs for subjects who have signed IC but have not been randomized (assuming randomization is when they are enrolled), but whether to capture them is more ambiguous.
• Generally, it’s not required to capture AEs for subjects who signed IC but weren’t randomized.
  

The caveat is that there are exceptions to every one of these cases, as suggested by the earlier discussions. Like so much of what we do, the decision requires judgement. Regardless of your decision, it is good practice to define clearly in the protocol what is meant by “enrolled,” “on study” and any other similarly unclear term.

In order to make the right decision,

• Educate yourself on the variables involved, and read the regulations
  
• Gather the relevant questions and information
  
• Talk to the other functional areas – this decision cannot (MUST NOT!) be made in a silo, because other perspectives and knowledge bases are required to ensure that all angles are covered
  

Your Regulatory Affairs group may have already spoken with the regulatory agencies about this; a good time to bring it up is at the early Phase 2 or end of Phase 2 meeting with the regulators. Whatever decision is made, be sure that it is documented fully, including the rationale for each element, because you may need that documentation later to justify the decision. There are few absolutes in our business, and nowhere is that more true than when dealing with regulations.

Many thanks to those who posed and responded to the question on LinkedIn. The thread was accessed on 6 December 2009 at http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=10132121&gid=7 7402&commentID=8843270&goback=.anh_77402&trk=NUS_DISC_Q-subject#commentID_8843270

Disclaimer: The author does not work for a regulatory authority, and the material in this article is based on reading the regulations/guidances and applying her own experience and observations. Each company should confer with their internal experts and the appropriate authorities to determine the best approach for their situation.

Structuring Clinical Data: AE Seriousness Fields

Even in a world with data standards, clinical data can be structured in different ways and still be standards-compliant. This is especially true when the standards define what to collect, but not how, or when, or in what combination. This article takes one example, the serious adverse event (SAE) fields, and explores several designs and the circumstances in which they could be appropriate. All examples are CDISC-compliant, but are not necessarily compatible with each other, emphasizing the need for careful thought in implementation.

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.

Following are some different options and the circumstances in which they would be appropriate.

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.