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

Recording Adverse Events and GeneratingQuality Data

  • Upload
    lekiet

  • View
    221

  • Download
    1

Embed Size (px)

Citation preview

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