My experience on CDM Setup

My Experience on Clinical Data Management Set up process

Protocol: Data Manager start up activities will start as soon as they received approved Protocol from Sponsor. As per GCP A protocol is a document that describes the following clinical trial elements–Objective(s), Plan, Design, Procedures and methodology, Statistical considerations and Organization of a clinical trial.

Data manager must refer Efficacy data/endpoints, Plan (visit plan, treatment plan), Inclusion and exclusion criteria, Safety data, Treatment details, Blinding details if applicable, Assessments (QoLs, psychiatric tests, ratings and scores etc.) Labs (central and local) in protocol to create effective CRF’s. Capture all required/important information from Protocol. If Not, it may lead to

-?Multiple revisions (RRF’s/PPC’s) post go live

-?Extra cost/ rework

-?Impact customer satisfaction rating

-Timeline Extension

-?Delay Medication to subject.

CRF’s identification: As per GCP, Case Report Form (CRF) a is printed, optical, or electronic document designed to record all of the protocol required information to be reported to the sponsor on each trial subject.

Schedule of events/ Trial flow chart is the key section in protocol which we need to refer to identify the CRF’s. Along with schedule of events,

-?Foot notes- We must refer in detail. Most of the critical information you will get in foot notes section. Every Protocol, foot notes information will be available below schedule of events table.

-?Standards- Take confirmation with the Sponsor whether we need to use Sponsor specific library if available or CDASH standards (www.cdisc.org ). Most of the Sponsors have their own library of CRFs to capture data.

?- Sister studies: Another important thing which we always check, whether any Sister studies available. If Yes, Fifty percent of your work done. Because, you can get CRF’s, guidelines/instructions, checks (Dynamics/Derivations/Edit checks/Listing details/Email Alerts etc).

Therapeutic Area: TA always help you in the design of CRF. You can refer the study in same therapeutic area, to design your study specific CRFs. Most of the cases same therapeutic area have same assessments criteria. For example, for solid tumors oncology studies RESICT Criteria or FDG-PET criteria is used to evaluate efficacy. For Neurology/Epilepsy studies, different scales are assessments.

Guidelines: As per ICH-GCP, ?no data should be deleted once recorded. As part of post-production changes in Protocol due to additional cohort added or new drug added as a combination therapy and If any of the CRF is not required and new CRF is created to capture the data. Old CRF will be retained for the all the enrolled subjects. For new subject, new form will be used. For all the future visit, new form will be used for all the subjects.

The CRF must collect the data required to answer the question posed by the clinical trial and Elements of the protocol must be accurately reflected in the CRF.

-?Below are some examples which can be extracted from Protocol while creating CRF’s.

?

·??????Whether subjects will be randomized and number of arms (CRF design)

·??????Whether trial is blinded or open label.

·??????Formulation, dosage, frequency and duration of study treatment

·??????Different type of reconciliations to be performed.

·??????Visit schedule.

·??????If we have multiple arms, what type of CRF’s to be collected in each arm.

·??????Therapy details (Monotherapy, combination therapy)

·??????Unscheduled details/Telephonic contacts/ Survival follow up details

·??????Whether integration required.

·??????Eligibility criteria section

·??????Demography/ Vital signs to be collected.

·??????Whether Genetic sampling consent is required.

Visit Schedule and Visit Matrix creation: Another important thing is visit schedule creation as per Schedule of events. Ideally will create visit schedule in excel document and include, Number of visits to be included, Unscheduled visits details, how many survival follow up visits to be included, days difference between each scheduled visit, which assessment or form to be included in each visits, what all are forms to be in included in unscheduled visits. If there are multiple cohorts in the study, multiple visit schedules to be created.

Dynamics creation: ?All CRF’s will not be available in each visit. As per Protocol requirement, we will create dynamic functionality to create or trigger required forms in each visit. There are two type of Forms present in the clinical trial. One is Static form and second one is Dynamic form. As soon as subject entered in to the data base few forms will auto populate, those forms we can call it as Static form. Example: Screening visit date, Informed consent etc. Dynamic foms will be triggered based on dynamic functionality (As per visit shedule). Example: If Gender selected as Female, Pregnancy form will trigger.

Again we have 3 types of Dynamics. Dynamic forms, Dynamic Visits and Dynamic Items.

Dynamic forms: Form will trigger based on logic. Form can be triggered with in visit or across other visits.

Dynamic Visits: Visit will trigger based on Logic

Dynamic Item: Field can be triggered with in CRF.

Derivations or calculations: Derivations or Calculations are nothing but derived fields. Calculated data will be derived to respective field. Example: If DOB enter age will be derived, height and weight enters BMI will be derived, in questionaries, overall score will be derived, blood pressure or ECG measurements, average measurements can be derived if we collect data multiple times. In Rave database we can call it as derivations and Inform platform we will call them as calculations.

Internal Kick off meeting: As soon as eCRF’s, Visit schedule, Dynamics and Derivations are ready. We will share all these details with study Database programmer. They will create study Architect URL and will add All CRF’s (Fields, Options, Date format, Float, Integer, drop downs, radio buttons etc ) and will program Dynamics and derivations accordingly as per visit schedule. Once done with Programming, DM need to perform quick user acceptance testing whether they programmed as per specification shared. Specification template can be different from Organization to organization and plat form to plat forms. Few People will create in excel and few in word documents.

Ideally in Rave Platform we can call it as eCRF specification and for Inform we can call as Mock CRF. Once Programmed, Programmer will extract eCRF’s (Rave- Architect loader specification (ALS), Inform-Annotated CRF) from Database and share with Data manager for Quick QC. Along with this programmer will create Testing environment and push all programmed CRFs to testing environment and will share credentials with Data Manager.

Data Manager will perform, user acceptance testing before internal Kick off meeting. If no findings we can go head for Kick off meeting. In Internal Kick-off meeting Clinical, Medical, Programming, Stats and Biostats teams will join. Data manager should explain study design to different stake holders. If they suggest any changes, DM has to note down everything and need to share with Programmer and programming team will do necessary changes before going to Client.

Note: As soon as DM start CRF’s creation, DM can shedule call with client along with Project manager and ask client about expectations, standards to follow, Timeline and were there any sister studies available if it is first study for the respective client. Based on client suggestions, DM have to plan things accordingly.

Suggested changes update: Data management team has to maintain log for internal suggested changes. Once done with the changes, need to notify to the internal team. If internal team don’t have any further concerns you can shedule call with client for Sponsor meeting. If changes are more again you need to schedule call with internal team.

Meeting with Client or Sponsor: ?Before proceeding with client meeting take internal team confirmation that they don’t have any further corrections. In client meeting, Data Manager need to explain how to enter subject, number of characters used for subject and site creation. Below things should explain to the sponsor.

·??????What all are the static forms and Dynamic forms.

·??????How Dynamic form and visit functionality will work

·??????Hidden forms, role specific permissions if any

·??????Coding procure (AE, CM and MH etc)

Once done with the sponsor meeting based on suggestions DM team and programming team will do the required changes and unique CRF’s will send for sponsor approval.

User Acceptance Testing (UAT) As soon as sponsor approved the CRF’s, programming team will send All CRF’s for Screen UAT in UAT environment. DM team will perform Screen UAT based on steps mentioned in CRF entry test script. In Test script, all details will be present to perform each and every step. Once all steps performed and there were no errors we can confirm?same thing to Sponsor and DM team will start creation Validation specification and CRF completion guidelines creation.

Steps to check in Screen UAT 1)CRF Type (Repeating and Common), 2)CRF Order, 3)CRF name, 4)Item text, 5)Date Type, 6)Data Options, 7)Length/Code list, 8) Enters data and submit to check whether data is fully displayed in the fields and is NOT truncated, 9)Per the specification, I will check fields that require SDV contain an SDV tick box or not (Login with CRA role), 10)Per the specification, I will check fields that do NOT require SDV do not contain an SDV tick box , 11) Spelling & Grammar, 12)Date/Time-?If UNK is allowed per spec, enters both a whole and partial date with UNK on separate CRFs or rows. 13)Check boxes- for Multiple choices, 14) Radio button - for One choice only, 15)Text box- String or Number as per specification and 16) Dynamics).

What is Split and Full go live: ?Most of the sponsors will prefer full go live and few were prefer Split go live.

·??????In full go live, we will release eCRFs along with system checks and Listings.

·??????Split go live: In split go live, Programming team release only CRF’s in production database and will give access to the sites. This will prefer when timelines are stringent, and subjects are available to perform screening visit. At least 1.5 to 2 months time will take to create edit checks, send to programmer, test case creation, programming, Technical QC, UAT multiple rounds. Due to this few sponsors will release only Screens first and all remaining things will add in Database revision request.

Validation document creation: Validation document creation is most critical part in CDM set up, if you create good document it will be very easy at conduct and closeout part and it will start as soon as CRF’s approved by the Sponsor. In part of Screen testing we have already created and executed Dynamics and derivations. Now, DM need team will focus on Edit checks, PD checks, email alerts, DM offline listings, Medical listings once liaise with Medical Monitor, PD listings once liaise with Biostatistician, Vendor listings based on different type of vendors and variable to reconcile and SAE listings.

Points to be considered before creating checks: Mainly below 7 points to be remember while creating the checks.

1.????First thing, Need to understand the Type of Form.

·??????Log

·??????Dynamic

·??????Static

·??????Mixed form

2.????Second important thing, Need to understand the type of field.

·??????Whether field is derived

·??????Whether field is integrated

·??????Whether field is Dynamic

·??????Type of options present for the field (Float, integer, Code list, Radio button, multiple options can be selected )

·??????View and Entry restrictions.

·??????Date and Time (Partial dates/Unknow dates)

·??????Units (MM/hg, KG/LB, F/C, Beats/Min)

·??????Free text fields

·??????Other specify fields.

·??????Alpha Numeric (Kit/ Accession number)

3.????Field level checks (Missing, Non-Conformant, Future date, Range checks- Systolic/Diastolic, Pulse etc).

4.????Whether checks are adding with in CRF or cross form checks with other fields

5.????Comparison checks with Other CRF’s.

6.????Custom function requirements

7.????Coded fields.

Note: Don’t directly create the offline listings, Create all checks as Edit checks. If Database programmer confirms, this check can not be created as Edit check then DM can move check to offline listing. All these offline listings can be shared with Stats programmer. They will create output and will share, else we can use any tool to execute offline listing or other listings.

PD specification creation: PD specification creation is important and critical activity in the study. Data Manager will create this document as per Protocol. Mainly 8 categories will consider in Protocol to create PD specification. Once done with the creation, Data Manager will share for stake holders review. Mainly Biostats lead review is important. In PD review meeting, if any protocol violation happened for any subject, it may exclude respective subject from Analysis. So sites should be more vigilant and they have to educate procedures well in advance to the subject. PD definition “Any failure to comply with study protocol as approved by the IRB whether planned or unplanned.”

Types: Critical and Non-Critical

Critical- Deviation which affects the rights, safety and wellbeing of patient and validity of data for analysis.

Unreported serious adverse events

Improper breaking of the blind

Use of prohibited medication

Ex: Double blind studies instead of assigning bottle different bottle has been dispensed.

Non-Critical- A deviation that does not affect the safety of subjects is considered as a Non- Critical protocol deviation.

PD categories:

1. Informed Consent

2. Inclusion/ exclusion

3. Withdrawal criteria

4. Adverse event

5. Visit schedule

6. Prohibited/Disallowed medication

7. Procedures/Tests not performed

8. IP dosing errors

Programmable PD's- Programmed from data in database and managed by DM. Via programmed edit checks or offline listings. eg. Treatment deviation, IE/EX criteria (Age, BP or other assessments), prohibited medications, Visit and Procedures OOW/not performed.

Observable PD's- Identified only by Clinical team or other team members that cannot be programmed. Ex. Informed Consent, IE/EX criteria, AE/SAE, IP storage log maintenance, SAE's not reported to ethics committee.

Stake holders review: Once done with the Validation document creation. We need to share with all stake holders (Stats, Biostats, Clinical, Medical team and programming team). They will review and will share their inputs. Then we can share with sponsor for his approval.

DMP creation: Data Management plan (DMP) Which details how the data to be handled according to how the study is anticipated to be run. A DMP describes the CDM activities to be followed in the trial, including trial master file maintenance, CRF specification, database design, data collection, CRF tracking, data entry, data storage and privacy, medical coding, data reconciliation (eg, serious adverse events and central laboratory data), data review, discrepancy management, data extraction, and database lock. The DMP is intended to standardize procedures and ensure that all CDM personnel understand the plan.

CRF completion instructions creation: Another important thing in CDM is CRF completion guidelines creation. In this document, will clearly explain how to fill the each CRF’s, dynamic functionality, forms present in varies visits. Though this document create for site users, it will also help to understand other stake holders. Effective guidelines will always reduce query count drastically. Once site coordinator understands this document, there will be no data entry errors.

Integrated spec creation: This document is applicable only data coming through IVRS/IWRS/IXRS and this will be created by programmer ad DM based on study requirements. Based on study design Varies fields (Subject number, Gender, Visit date, Year of Birth, Kit number, Screen failure date, Randomization date etc..) will come though Integration. As soon as site inform to IVRS vendor through designed function respective data will automatically populate to production Database. Manly this will use on Blinded studies. To perform Integrated user acceptance testing, we need 2 databases and once we enter data in to one database data will auto flow in to the other database. Based on study design we will enter respective fields in one database and if everything populated/modifications appeared DM team will declare as integration fixed for the study and programmer will push in to production database.

tSDV spec creation if applicable: Targeted Source Data verification (TSDV) document is applicable only if sponsor don’t want to perform complete source data verification. Based on Biostatistician suggestion, Critical variable document will be created and SDV will enable only critical fields as per Sponsor decision. In this case, CRA’s will get SDV option only for those fields. If we use tSDV, it will reduce cost and time of the study. Again it depends up on client requirement.

Configuration Specification creation: Configuration specification will not be applicable for all studies. If we are performing first time for the respective URL and first study for the respective client, DM team or programming team will perform configuration ?testing. Once it is performed testing and there will be no configure modifications for new studies then no testing is required. If there will be any minor change in the configuration, we must perform UAT. Mainly will perform, user credentials, reports, training assignment etc.

Test Scripts creation: Test scripts play vital role while performing testing (UAT). In each and every test script (Example: Screens test, validation test script, Integration test script, configuration test script, Coding test script etc) explained detailed steps to be performed while doing UAT. Every user must perform testing based on steps mentioned in the test script. Once done with testing will be document in TMF/eTMF with all testers and approval details.

Test cases creation: Test cases are nothing but steps to follow while executing programmed checks (Edit checks, Dynamics, derivations, email alerts etc). For each check we must create clean scenario as well as dirty scenario. Both scenarios we need to enter UAT database and check should fire only on dirty scenario and Clean scenario checks should not fire. Ideally each check we need to write 3-4 test cases but few scenarios We must check more than 100 cases. Example: RECIST- Over form- Overall tumour response rate. In this case we need to select multiple available option under Target tumour response, non-Target tumour response and were there any new lessons. So total 3 fields should considered. If we miss any scenario, particular check can fail in production and PPC needed to fix the checks, hence Data management team should more vigilant.

Checks user acceptance testing: All checks should be executed as per test cases and test case author and UAT performed member, Programmer and Technical QC (TQC) performed person details should be documented. If checks fails, it will help while doing RC-CAPA.

Listings creation: If any checks that are not able to be created as edit checks, those will be moved to offline or Manual listings. These listings will be programmed by Statistical team based on DM suggestions. There were total 5 types (DM, MM, PD, Vendor and SAE listings) of offline listings present in any study. Count of the check may change based on different type of fields and vendors from study to study and TA to TA. These will be ideally reviewed monthly. SAS team generate listings with Datasets every month.

Data transfer specification (DTS): DTS is agreement between Vendor and Sponsor about the format of files (Excel spreadsheet, ASCII, SAS dataset, text file, etc), frequency of data transfer, File naming conventions, Encryption and method of transfer (password encrypted email attachment, secure FTP, etc), Type of transfer, Sender details, recipients details, reconciliation variable details, transfer confirmation agreement details.

?

Go- Live: To complete all above steps it will take 3-4 months. If we do robust setup and all required checks added to the study, then you won’t get many issues in conduct. So good setup process is very very crucial in Clinical Data Management. ??

?

References: Experience in CDM