Recording Adverse Events and GeneratingQuality Data

35
Seeing Chickens at Window Recording Adverse Events and GeneratingQuality Data Margaret Band, Clinical Trial Manager, TCTU

Transcript of Recording Adverse Events and GeneratingQuality Data

Page 1: Recording Adverse Events and GeneratingQuality Data

Seeing Chickens at Window – Recording Adverse Events and

GeneratingQuality Data

Margaret Band,

Clinical Trial Manager, TCTU

Page 2: Recording Adverse Events and GeneratingQuality Data

Adverse Event Reporting

Monitoring of adverse events (AEs) is critical to the patient’s safety and

data integrity & a legal requirement The Medicines for Human Use (Clinical Trials)

Regulations 2004

Page 3: Recording Adverse Events and GeneratingQuality Data

Introduction

• Definition of AEs • Purpose of recording AEs • Documenting AEs • Completing and AE form – description, severity,

causality and outcome • Reporting AEs – briefly! • AE SOP

Page 4: Recording Adverse Events and GeneratingQuality Data

Definition of Adverse Events

AE - Adverse Event • Any untoward medical occurrence or the deterioration of a pre-

existing medical condition in a subject in a clinical trial • An AE does not necessarily have to have a causal relationship with

the study treatment / procedure • An AE can therefore be any unfavourable and unintended sign (eg.

tachycardia) including laboratory findings which are clinically significant, symptom (eg. nausea, chest pain) or a disease

• The term AE is used to include both serious and non-serious AEs • Elective hospitalisations for pre-treatment conditions are not AEs

Page 5: Recording Adverse Events and GeneratingQuality Data

Definition of Adverse Events

AR - Adverse Reaction • An adverse reaction (AR) is where it is suspected that an AE has

been caused by a reaction to a trial drug • The reaction may be a known side effect of the medication (AR) or

it may be a new previously unrecognized adverse reaction (UAR) UAR - Unexpected Adverse Reaction • An AR wich is not described in Investigator´s Brochure (IB) or

Summery of Product Characteristics (SmPC) Not all AEs are ARs but all ARs are AEs

Page 6: Recording Adverse Events and GeneratingQuality Data

Serious Adverse Events

• All SAEs are AEs not all AEs are SAEs • Usually any AE, AR or UAR that at any dose:

– results in death; – is life threatening (i.e. the subject was at risk of death at the time of the event;

it does not refer to an event which hypothetically might have caused death if it were more severe);

– requires hospitalisation or prolongation of existing hospitalisation; – results in persistent or significant disability or incapacity; – is a congenital anomaly or birth defect.

is considered a SAE. • However…

Page 7: Recording Adverse Events and GeneratingQuality Data

Serious Adverse Events

• The reporting of SAEs can be excluded if documented in the study protocol.

• The exclusion of reporting some SAEs may be due to their expected occurrence in the population and disease under investigation

• These should be recorded in the AE log but no SAE form required.

Page 8: Recording Adverse Events and GeneratingQuality Data

Purpose of recording Adverse Events

Legal requirement - The Medicines for Human Use (Clinical Trials) Regulations 2004 Safety Signals • Informs Data Monitoring Committee

– safeguard the interests of trial participants – assess the safety and efficacy of the interventions during the trial – monitor the overall conduct of the clinical trial

• Accuracy in diagnosis is important for detection and evaluation of safety signals

Page 9: Recording Adverse Events and GeneratingQuality Data

Purpose of recording Adverse Events

• Regulatory authorities want to see if a drug trial follows reported side effect profiles as reported in the Investigators Brochure and Summary of Product Characteristics

• New drugs have to build up this profile in clinical trials • AE analysis must count side effects for each treatment

arm • Companies must keep track of the side effect profile of

their drugs

Page 10: Recording Adverse Events and GeneratingQuality Data

Coding of Clinical Trial Data

• Most data entered on Case Report Forms are “coded” in some form • Some coding is performed by investigators at point of data entry

– For example, numeric codes for severity of adverse event: 1= mild, 2= moderate, etc.

• Coding of free text data, as provided in an AE Log, is performed after data collection, free text is otherwise not analyzable

• Coding AEs allows free text to be grouped into meaningful categories for analysis to quantify AEs for a particular study

• Most research organisations will use a specific coding mechanism to ensure consistency of coding

• TCTU uses MedDRA - Medical Dictionary for Regulatory Activities • Accuracy of coding determines accuracy of analysis

Page 11: Recording Adverse Events and GeneratingQuality Data

Coding Challenges

• Some reported AEs! Not from TCTU! – Went to hell – Recurrent fatal stroke – Hears New Age music when the furnace turns on – LK RTCTL UNSP XTRNDL – Charcoal-like, gritty granules in his underwear – Can’t control patient during menses – His nodule is sticking out – Normally normal after drinking coffee – Died of cancer of the placebo – Superior members fornication – Barely visible posterior – Seeing people in room, seeing chickens at window – Seeing stars and chicken farting – Patient recently began new job where he works around chicken wings and barbecue sauce

Page 12: Recording Adverse Events and GeneratingQuality Data

Documenting Adverse Events

• AE log

• Medical notes

Page 13: Recording Adverse Events and GeneratingQuality Data

The Adverse Event Log

Includes: • Date of onset • Description • Severity • Causality • Action • Outcome • End date

Page 14: Recording Adverse Events and GeneratingQuality Data

Adverse Event Log

Page 15: Recording Adverse Events and GeneratingQuality Data

Date of Onset

• Date event started – not date first reported to investigator.

Page 16: Recording Adverse Events and GeneratingQuality Data

Description of AE

• Benefits of Quality Data

• Generating Quality Data

• Coding of Clinical Trial Data

• Symptom vs Syndrome

• Problems with Coding Data

Page 17: Recording Adverse Events and GeneratingQuality Data

Benefits of Quality Data

• Accurate and timely information on issues that affect conduct of clinical trial and affect patient safety

• Improved communication among sponsors, investigators, and regulatory agencies about medicinal products – Aids in safety signal detection and evaluation – Ensures accuracy of information about the product including

investigators’ brochures and prescribing information – Benefits medical professionals – Benefits patients

Page 18: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Clear • Concise • Complete • Accurate • Be specific if possible -

– Headache - more than 50 types, including cluster, sinus, migraine, lumbar puncture headache

– Organisms - down to species level e.g. Staphylococcus aureus

Page 19: Recording Adverse Events and GeneratingQuality Data

Symptom vs Diagnosis

• Where possible, report the most important medical event or specific diagnosis rather than individual signs and symptoms

• Can provide provisional diagnosis e.g. “possible”, “presumed”, “rule out” • Diagnosis should not be assumed by Research Nurse • Accuracy is important in preventing dilution of safety signals or generating

false signals

• E.g. Report AE as Myocardial Infarction

Signs and symptoms Diagnosis

chest pain, breathlessness, sweating, ECG changes

Myocardial infarction

Page 20: Recording Adverse Events and GeneratingQuality Data

Problems with coding data

• Appropriate coding requires clear initial data

• What is clear to the investigator at the point of data entry may be unclear to the coder at the point of data coding

• Sponsor must only code reported verbatim term; not permitted to interpret or draw information from other sources

Page 21: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

Avoid: Ambiguous information

• Congestion (nasal, liver, sinus, pulmonary?) • Cramp (muscle, menstrual, abdominal?) • Pain (where?)

Ambiguous abbreviations • MI (myocardial infarction or mitral incompetence?) • GU pain (gastric ulcer pain or genito-urinary pain?) • Decreased BS (breath sounds, bowel sounds or blood sugar?) • Exercise caution with abbreviations that could be misinterpreted

Vague information • Patient felt “fuzzy”, “weird”, “experienced every adverse event”

Page 22: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Try to use accepted medical terminology

• Give specific information – Non-specific information

• “Oedema” (coded as oedema)

• “Left wrist oedema” (coded as Peripheral oedema)

• More specific - “Injection site oedema left wrist” (coded as Injection site oedema)

Page 23: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Death, hospitalization, investigations and disability are outcomes and are not usually considered to be adverse events

• Provide details of the underlying event, if known – Examples:

• “Death due to myocardial infarction” (Coded as Myocardial infarction with death captured as the outcome)

• “Hospitalization due to congestive heart failure” (Coded as Congestive heart failure with hospitalization captured as the outcome)

Page 24: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Recording laboratory data – Ambiguous laboratory data

• “Glucose of 40” (Source of specimen - blood, urine, CSF? What units?) • Would have to code as Glucose abnormal if additional clarification is not

obtained

– Conflicting laboratory data • “Hyperkalemia with serum potassium of 1.6 mEq/L” • Would have to code as Serum potassium abnormal

– If using numeric values, provide units and reference range. – Be specific about specimen source and diagnostic result/clinical

diagnosis.

Page 25: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Try to avoid combination terms - these will have to be split into individual terms

• Combination terms – Diarrhoea, nausea and vomiting – Should be recorded as:

• Diarrhoea • Nausea • Vomiting

Page 26: Recording Adverse Events and GeneratingQuality Data

Generating Quality Data

• Falls: a fall in it’s self is not an AE however,

– If a patient hurts themselves record any injury as AE

• Fractured right wrist due to fall

– If an underlying cause is present record cause as AE

• Postural hypotension resulting in fall

Page 27: Recording Adverse Events and GeneratingQuality Data

Assessing severity

MUST be assessed by medically qualified person on delegation log (legal requirement) • Mild- awareness of sign or symptom, but easily tolerated • Moderate- discomfort sufficient to cause interference with

normal activities • Severe- incapacitating with inability to perform normal

activities • Severe is not the same as serious!

Page 28: Recording Adverse Events and GeneratingQuality Data

Assessing Causality

MUST be assessed by medically qualified person on delegation log (legal requirement) • Unrelated - not considered to be related to study drug/intervention, other

cause is more probable. • Possibly – although a relationship to study drug/intervention cannot be

completely ruled out other explanations are more likely • Probably - good reason and evidence for relationship to study

drug/intervention and absence of a more likely explanation • Definitely – the known effects of the study drug/intervention or challenge

testing suggest the study drug/intervention is the most likely cause.

Page 29: Recording Adverse Events and GeneratingQuality Data

Action taken

• Action to the study drug/intervention e.g. stopped, dose reduced • Other medication started/stopped/dose change • Other treatment required e.g. physio • Hospitalisation • Remember:

– if study drug/intervention stopped or reduced this should be recorded in the CRF

– any action to other medication, started/stopped/dose change, should also be recorded in the Concomitant Medications Log

Page 30: Recording Adverse Events and GeneratingQuality Data

Outcome

• Resolved – date

• Ongoing - all AEs should be followed up to resolution or end of study

• Resolved with seaquelae – disability or incapacity

• Death – date

Page 31: Recording Adverse Events and GeneratingQuality Data

Up Dating AE Logs

• All AEs should be followed up until resolution or end of study • Unless resolved every AE should be reviewed at each visit

– Assess if still ongoing or now resolved – Assess if action taken has been changed – Assess if diagnosis has been made/changed

• Correct AE if necessary – E.g. Chest pain now been diagnosed as angina: change AE to angina (remember to sign and date changes on

paper CRF and update OpenClinica/data management system) – If several AEs now have one diagnosis change first AE to new diagnosis and score through additional AEs

(update data management system) – E.g. Separate AEs of diarrhoea and vomiting now diagnosed as Gastroenteritis : change diarrhoea to

Gastroenteritis score through vomiting AE. The patient now has only one AE – Gastroenteritis.

• At end of study ensure all AEs are either resolved (give end date) or ticked as ongoing (e.g new diagnosis of diabetes)

Page 32: Recording Adverse Events and GeneratingQuality Data

Up Dating AE Logs example

Page 33: Recording Adverse Events and GeneratingQuality Data

Medical Notes

• All AEs reported by the patient should be documented in the patient’s medical notes

• If any action has been taken by the study team this should be recorded

• GP should be informed if it is felt necessary, ask the patient’s permission

• Medical notes can be used as source data for AEs

Page 34: Recording Adverse Events and GeneratingQuality Data

Reporting AEs to Sponsor

• Complete CRF and enter in OpenClinica/data management system – in timely manner

• Data used to inform Data Monitoring Committee

Page 35: Recording Adverse Events and GeneratingQuality Data

AE SOP

• TASC SOP 11: Identifying, Recording and Reporting Adverse Events for Clinical Trials of Investigational Medicinal Products

http://www.tasc-research.org.uk/cms/files/sop11/sop_11_v_7.0.pdf