Category Archives: Best Practices

Want to become an {EDC} Developer? Take this test

I have been contacted on multiple occasions in recent years about how to become an {EDC} Developer or clinical programmer.

If you are currently working in the industry, the transition should be swift.  But for those working outside the pharmaceutical/biotechnology industry, I recommend you take a SAS programming course or data analytics/ visualization course since {EDC} training only is available for those already in the industry and for those sponsored by your employer.  There is no official public training for a specific {EDC} tool. Your company must be a user (Customer) of the tool for you to gain some knowledge.

Here are some examples of custom programs. Test your readiness.

Example 1:

Comparing two (2) strings a and b:

string dbtool=”Rave”;

if (dbtool == “Rave”)

if (dbtool.Equals(“Rave”))

OR how about…

String strA;

String strB;

If (strA == strB)

{

System.console.writeline (“StringA’s value is same as StringB’s value.”);

}

 

Example 2:

Switch case:  to store a value in int x if the value of n is “RAVE”, 2 if y is “INFORM”, 3 if y is “OCRDC”, and 0 otherwise.

switch (n)

{

case “1”:

Console.WriteLine(“You choosed RAVE”);

intVarEDC ==1;  break;

case “2”:

Console.WriteLine(“You choosed INFORM”);

intVarEDC ==2; break;

case “3”:

Console.WriteLine(“You choosed OCRDC”);

intVarEDC==3;  break;

default:

Console.WriteLine(“Invalid selection {0}”, n);

Console.WriteLine(“Please input 1, 2, or 3”);

intVarEDC == 0; break;

}

Example 3: Arrays

Can you guess the output to this program?

public static void printf(params object[] args)

{

for (int i = 0; i < args.Length; i++)

{

Console.WriteLine(“args[{0}] = {1}”, i args[i]);

}

}

public static void Main()

{

printf(“Thank you”, 4, “visiting”, “EDC Developer.”, “Says”);

}

Some tips or best practices when working with Rave Edit checks and custom fuctions:

  • Always put record position 0 in Edit Check Steps and Actions for standard DataPoints
    • Note: In the recent release of Rave, this is mandatory.
  • Use ChangeCount Property wherever possible to execute only for the submitted datapoints.
    • ex: If (dpAETERM != null && dpAETERM.Active && dpAETERM.ChangeCount  > 0)
  • Avoid using “true” parameter in the FetchAllDataPointsForOIDPath for Log forms.
    • Bad example: datapoints dpAE = CustomFunction.FetchAllDataPointsForOIDPath(“AESEV”, “AE”, “AE”, subject, true)
    • Good example: datapoints dpAE = CustomFunction.FetchAllDataPointsForOIDPath(“AESEV”, “AE”, “AE”, subject)

If you wrote similar programs or are comfortable writing these types of programs then you are ready for your next challenge. But if you do not know anything about C sharp programming or {EDC} in general, don’t despair. We are here to help.

Subscribe to my blog’s RSS feed and email newsletter to get immediate updates on the latest news, articles, and tips. I am available on LinkedIn or my personal webpages: EDC Developer or Clinical Programmer. Or contact me to discuss any projects or contracts you may have and need support with.

Advertisements

CTCAE: Common Terminology Criteria for Adverse Events

The National Cancer Institute issued the Common Terminology Criteria for Adverse Events (CTCAE) version 5.0 on November 27, 2017.

So what is CTCAE and what is it used for?

The terminology NCI CTCAE is a descriptive terminology that can be used for the declaration of adverse events (AEs). A grade scale (or severity) is provided for each term.

The oncology community has a standard classification and severity grading scale for adverse events in cancer therapy clinical trials and this is what it is described in the CTCAE reference.

The SOC (System Organ Class or Organ Class) is the highest level of the hierarchy of the
MedDRA dictionary. It is identified by a physiological or anatomical classification, etiological or a result (ex: SOC investigations for laboratory results). The terms of the CTCAE are grouped together according to the MedDRA primary SOCs. Within each SOC, the terms are listed and accompanied a description of the severity (grade).






An adverse event is an unexpected sign, symptom or disease, unexpected (this includes
biological results), associated chronologically with the use of a treatment, a procedure,
to be connected to this treatment or procedure. An IE is a unique term representing an event
specifically used for the medical report and the scientific analyzes. Each term of the CTCAE is a
MedDRA LLT level term (Low Level Term, lowest level of the hierarchy).
Grades refer to the severity of AEs. The CTCAE is divided into 5 grades, each with
unique medical description for each term, based on the following main lines:
Grade 1: Light; asymptomatic or mild symptoms; diagnosis on clinical examination only; born
not requiring treatment
Grade 2: Moderate; requiring minimal, local or non-invasive treatment; interfering with activities instrumentalities of everyday life
Grade 3: Severe or medically significant but without immediate life-threatening;
indication of hospitalization or prolongation of hospitalization; invalidating; interfering with activities elementary of everyday life
Grade 4: Life-threatening; requiring emergency care
Grade 5: Death related to AE and it is not appropriate for some AEs and therefore is not an option.
MedDRA code CTCAE v5.0 Term Grade 1 Grade 2 Grade 3 Grade 4 Grade 5 Definition
10007515 Cardiac arrest Life-threatening
consequences; urgent
intervention indicated<
Death A disorder characterized by cessation of the pumping function of the heart.

CTCAE is still the formal reporting for AEs and grading dependent upon clinician judgement of medical significance.

A copy is located here: CTCAE version 5.0.

Sources:

https://ctep.cancer.gov/protocolDevelopment/electronic_applications/docs/CTCAE_v5_Quick_Reference_8.5×11.pdf

Feature image: CTCAE-4 by Stefano Peruzzi (apple app)

Fair Use Notice: Images/logos/graphics on this page contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law).

Got Medrio? The Next Best EDC…

Medrio is a low cost solution that offers easy mid-study                changes and intuitive phase I workflows.

Medrio

One of my favorite features of Medrio is the Skip logic functionality. So what is Skip logic?

Let’s demonstrate this feature by using the Demography form / Race field:

In many EDC systems that I am currently using or used in the past, we have to create separate fields for each option and write a custom edit check to flag when data has been entered under the specify field. This scenario request data on the specify field if the OTHER race option is checked but with skip logic, no other option will be allowed to enter data (e.g. White or Black or Indian) if the user did not select OTHER as an option and the required field ‘Specify’ is made visible and available (mandatory) for data entry.

Medrio

eCRF – DEMO – Medrio

 

 

 

 

 

 

 

 

DM form – Skip Logic

 

 

 

 

 

 

 

In the above screenshot,  the query resulting from the skip logic configuration if OTHER specify is not completed. In other words, when Race other than ‘OTHER’ is checked, the specify field will be skipped (not enterable). To make this work and as a best practice, you will need to make the ‘OTHER’ field required during data entry.

If you are looking for a study builder or clinical programmer to support your clinical trials and data management department, please use the contact form.

Source: medrio.com

Disclaimer: The EDC Developer blog is “one man’s opinion”. Anything that is said on the report is either opinion, criticism, information or commentary, If making any type of investment or legal decision it would be wise to contact or consult a professional before making that decision.

-FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching,SCHOLARSHIP, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Understanding Audit Trail Requirements in Electronic GxP Systems

Computerized systems are used throughout the life sciences industry to support various regulated activities, which in turn generate many types of electronic records.  These electronic records must be maintained according to regulatory requirements contained within FDA’s 21 CFR Part 11 for US jurisdictions and Eudralex Volume 4 Annex 11 for EU jurisdictions.  Therefore, we must ensure the GxP system which maintains the electronic record(s) is capable of meeting these regulatory requirements.

What to look for in Audit Trail?

  • Is the audit trail activated? SOP?
  • Record of reviews? (most companies trust the electronic systems audit trail and generates electronic paper version of it without a full review)
  • How to prevent or detect any deletion or modification
    of audit trail data? Training of staff?
  • Filter of audit trail

Can you prove data manipulation did not occur?

Persons must still comply with all applicable predicate rule requirements related to documentation of, for example, date (e.g. 58.130(e)), time, or sequencing of events, as well as any requirements for ensuring that changes to records do not obscure previous entries.

Consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated “audit trail”).

Audit trail content:

Audit trail content and reason it is required:
Identification of the User making the entry This is needed to ensure traceability.  This could be a user’s unique ID, however there should be a way of correlating this ID to the person.
Date and Time Stamp This is a critical element in documenting a sequence of events and vital to establishing an electronic record’s trustworthiness and reliability.  It can also be effective deterrent to records falsification.
Link to Record This is needed to ensure traceability.  This could be the record’s unique ID.
Original Value  

This is needed in order to be able to have a complete history and to be able reconstruct the sequence of events

New Value
Reason for Change This is only required if stipulated by the regulations pertaining to the audit trailed record.  (See below)

FDA / Regulators findings and complaints during Inspection of Audit Trail Data:

  • Audit User sometimes is hard to describe (e.g. user123 instead use full names of each user IDs thus requirement additional mapping)
  • Field IDs or Variables names are used instead of SAS labels or Field Labels (map field names with respective field text (e.g.  AETERM displayed instead use Reported Term for the Adverse Event)
  • Default values should be easily explained or meaningful (see annotated CRF)
  • Limited access to audit trail files (many systems with different reporting tools or extraction tool. Data is not fully integrated. Too many files and cannot be easily integrated).
  • No audit trail review process. Be prepared to update SOPs or current working practices to add review time of audit trails. It is expected that at least, every 90 days, qualified staff performed a review of the audit trail for their trials. Proper documentation, filing and signature should be in place.
  • Avoid using Excel or CSV files. Auditors are now asking for SAS datasets of the audit trails. Auditors are getting trained to generate their own output based on pre-defined set of parameters to allow auditors to summarize data and produce graphs.
  • Formatting issues when exporting into Excel, for example.  Numbers and dates fields change it to text fields.
Audit Trail Review

What data must be “audit trailed”?

When it comes to determining on which data the audit trail must be applied, the regulatory agencies (i.e. FDA and EMA) recommend following a risk based approach.

Following a “risk based approach”

In 2003, the FDA issued recommendations for compliance with 21 CFR Part 11 in the “Guidance for Industry – Part 11, Electronic Records; Electronic Signatures — Scope and Application” (see reference: Ref. [04]).  This guidance narrowed the scope of 21 CFR Part 11 and identified portions of the regulations where the agency would apply enforcement discretion, including audit trails. The agency recommends considering the following when deciding whether to apply audit trails:

  • Need to comply with predicate rule requirements
  • Justified and documented risk assessment to determine the potential effect on product quality
  • product safety
  • record integrity

With respect to predicate rule requirements, the agency states, “Persons must still comply with all applicable predicate rule requirements related to documentation of, for example, date (e.g., § 58.130(e)), time, or sequencing of events, as well as any requirements for ensuring that changes to records do not obscure previous entries.”  In the docket concerning the 21 CFR Part 11 Final Rule, the FDA states, “in general, the kinds of operator actions that need to be covered by an audit trail are those important enough to memorialize in the electronic record itself.” These are actions which would typically be recorded in corresponding paper records according to existing recordkeeping requirements.

The European regulatory agency also recommends following a risk based approach.  The Eudralex Annex 11 regulations state, “consideration should be given, based on a risk assessment, to building into the system the creation of a record of all GMP-relevant changes and deletions (a system generated “audit trail”).”

MHRA Audit

When does the Audit Trail begin?

The question of when to begin capturing audit trail information comes up quite often, as audit trail initiation requirements differ for data and document records.

For data records:

If the data is recorded directly to electronic storage by a person, the audit trail begins the instant the data hits the durable media.  It should be noted, that the audit trail does not need to capture every keystroke that is made before the data is committed to permanent storage. This can be illustrated in the following example involving a system that manages information related to the manufacturing of active pharmaceutical ingredients.  If during the process, an operator makes an error while typing the lot number of an ingredient, the audit trail does not need record every time the operator may have pressed the backspace key or the subsequent keystrokes to correct the typing error prior to pressing the ‘‘return key’’ (where pressing the return key would cause the information to be saved to a disk file).  However, any subsequent ‘‘saved’’ corrections made after the data is committed to permanent storage, must be part of the audit trail.

For document records:

If the document is subject to review and approval, the audit trail begins upon approval and issuing the document.  A document record undergoing routine modifications, must be version controlled and be managed via a controlled change process. However, the interim changes which are performed in a controlled manner, i.e. during drafting or review comments collection do not need to be audit trailed.  Once the new version of a document record is issued, it will supersede all previous versions.

Questions from Auditors: Got Answers?

When was data locked? Can you find this information easily on your audit trail files?

When was the database/system released for the trial? Again, how easily can you run a query and find this information?

When did data entry by investigator (site personnel) commence?

When was access given to site staff?

Source:

Part of this article was taking, with permission, from Montrium – Understanding Audit Trail Requirements in Electronic GXP Systems

Fair Use Notice: Images/logos/graphics on this page contains some copyrighted material whose use has not been authorized by the copyright owners. We believe that this not-for-profit, educational, and/or criticism or commentary use on the Web constitutes a fair use of the copyrighted material (as provided for in section 107 of the US Copyright Law).

Good Clinical Practice – The Bible

Good Clinical Practice (GCP) is an international ethical and scientific quality standard for
designing, conducting, recording and reporting trials that involve the participation of
human subjects. Compliance with this standard provides public assurance that the rights,
safety and well-being of trial subjects are protected, consistent with the principles that have
their origin in the Declaration of Helsinki, and that the clinical trial data are credible.

Below is the link to the most common terms used in clinical trials (for reference). Use it as your leisure, during work hours and day-to-day work as a clinical researcher.

Good Clinical Practice Bible – Terminologies

Top 3 Posts at (EDC Developer)

Fist, I would like to thank everyone who has read articles posted at {EDC} Developer. Especially, my colegas and friends from India. The highest reading and hits have come from people living in India.

New to the industry? Want to get in as clinical data manager or clinical programmer? Looking for a particular topic or an answer to a question? check the contact me section.

Here are the top most searched articles this past few months:

1- Data Management: Queries in Clinical Trials

2- How to document the testing done on the edit checks?

3- Why use JReview for your Clinical Trials?

Others most read articles:

Role of Project Management and the Project Manager in Clinical Data Management

4 Programming Languages You Should Learn Right Now (eClinical Speaking)

Data Management Plan in Clinical Trials

For the search term used to find {EDC} Developer:

1-types of edit checks in clinical data management

2-Rave programming

3- pharmaceutical terminology list

4-seeking rave training (better source is mdsol.com)

5- edc programmer

6-central design tips and tricks

Thank you for reading!

How to document the testing done on the edit checks?

Since the introduction of the Electronic Data Capture (EDC) in clinical trials where data is entered directly into the electronic system, it is estimated that the errors (e.g. transcription error) have been reduced by 70% [ Clinical Data Interchange Standards Consortium – Electronic Source Data Interchange 2005].

The Data Management Plan (DMP) defines the validation test to be performed to ensure data entered into the clinical database is complete, correct, allowable, valid and consistent.

Within the DMP, we find the Data Validation Plan. Some companies call it ‘DVS’ others ‘DVP’.  The Good practices for computerized systems in regulated GxP environments defines validation as a system that assures the formal assessment and reporting of quality and performance measures for all the life-cycle stages of software and system development, its implementation, qualification and acceptance, operation, modification, qualification, maintenance, and retirement.

As an {EDC} Developer or Clinical Programmer, you will be asked to:

  • Develop test scripts and execution logs for User Acceptance Testing (UAT).
  • Coordinate of UAT of eCRF build with clinical ops team members and data management and validating documents, included but not limited to: edit check document, issue logs, UAT summary report and preparation and testing of test cases.

Remember not every EDC system is alike. Some systems allow you to perform testing on the edit checks programmed; others allow you to enter test data on a separate instance than production (PROD).

Data Validation and UAT Module.png

For example, some EDC systems facilitate re-usability:

  1. There is a built-in test section for each study – where data can be entered and are stored completely separate from production data. This allows you to keep the test data for as long as needed to serve as proof of testing.
  2. The copy function allows for a library of existing checks (together with their associated CRF pages) to be copied into a new study. If there are no changes to the standard checks or pages then reference can be made back to the original set of test data in a standards study, thus reducing the study level overhead.
  3. The fact that many of the required checks (missing data, range checks, partial dates etc.) do not require the programming of an edit check at all. Each of these and many others are already there as part of the question definition itself and therefore do not need any additional testing or documentation for each study.

If you have not documented, you have not done it-FDA

The “ideal world” scenario would be to reduce the actual edit check testing by the system generating a more “human readable” format of the edit checks. The testers that way would not have to test each boundary conditions of the edit checks once the system is validated. All they would have to do is inspect the “human readable” edit checks vs the alerts and would also be easy for the clients to read and sign off.

You can leverage the EDC systems audit trail under certain conditions. First of all – the system you are testing with must be validated in itself. Some EDC products are only ‘validated’ once a study is built on top of them – they are effectively further developed as part of a study implementation process – in this situation, I would doubt you could safely use the audit trail.

Secondly, you need to come up with a mechanism whereby you can assure that each edit check has been specifically tested – traceability.

Finally, you need to secure the test evidence. The test data inside the EDC tool must be retained for as long as the archive as part of the evidence of testing.

The worst methods in my view are paper / screenshot based. They take too long, and are largely non-reusable. My past experience has been creating test cases using MS Word then performing each step as per test case and take a screenshot, where indicated. Then attached to the final documentation and validation summary. This obviously a manual and tedious process. Some companies create test cases using HPQC or similar tool. This is a bit more automated and traceable yet, it is still prone for errors. It is better than documenting using MS Word or Excel but it is still a manual process.

Re-usability is what it is all about, but, you need to ensure you have methods for assuring the test evidence produced for edit checks you are reusing is usable as part of the re-use exercise.

Edit Check Design, Development and Testing is the largest part of any typical EDC implementation. Applying methods to maximize quality and minimize time spent is one of the areas I have spent considerable time on over the last couple of years.

For additional tips on writing effective edit checks please go here -Effective edit checks eCRFs.

To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn

Source images: provided courtesy of Google images.

-FAIR USE-
“Copyright Disclaimer Under Section 107 of the Copyright Act 1976, allowance is made for “fair use” for purposes such as criticism, comment, news reporting, teaching, scholarship, and research. Fair use is a use permitted by copyright statute that might otherwise be infringing. Non-profit, educational or personal use tips the balance in favor of fair use.”

Case Study 4: A Full Data Management Solution

Working in a Collaborative Environment

The Scenario:

A phase II study was being managed by a CRO that had non-dedicated teams, escalating costs, with project timelines slipping on almost every deliverable.
RA eClinica Solution:

    • RA eClinica assumed responsibility for entire data management activities consisting of Data Management, Study Build / EDC Development, and Statistics and Programming.
    • RA eClinica preferred Data Management systems utilized with Sponsor’s Safety Surveillance system and Clinical Trial Management System, CTMS

Ra eClinica Results:

    • Study ongoing – All deadlines to date have been met or exceeded
    • Cost savings of approximately 35% in comparison to traditional CRO models
    • No turnover since study start

Anayansi Gamboa- Virtual DM Service from RA eClinica

RA eClinica is a established consultancy company for all essential aspects of statistics, clinical data management and EDC solutions. Our services are targeted to clients in the pharmaceutical and biotech sector, health insurers and medical devices.

The company is headquarter in Panama City and representation offices with business partners in the United States, India and the European Union. For discussion about our services and how you can benefit from our SMEs and cost-effective implementation CDISC SDTM clinical data click here.

To hire me for services, you may contact me via Contact Me OR Join me on LinkedIn

Case Study 3: Out-of-Box Solution

The Scenario:

The Sponsor required a solution to effectively manage and control users (internal and external).
RA eClinica Solution:

    • RA eClinica collaborated with the Sponsor to develop and implement a user management system that involved training tracking record (LMS), user access request, Role-based access control
    • Develop, deploy and host the clinical documentation service and provide customer support.

Ra eClinica Results:

    • Development of an electronic tool to manage the program and provide ongoing operational management support..
    • Reports are made accessible based on permission on a web browser CFR-Part 11 compliance is maintained on security and privacy of data.
    • Reports are XML-tagged for further integration with in-house systems and third party service providers,
    • Integrated Help desk support system

Anayansi gamboa - Out of the box solutions by RA eClinica

RA eClinica is a established consultancy company for all essential aspects of statistics, clinical data management and EDC solutions. Our services are targeted to clients in the pharmaceutical and biotech sector, health insurers and medical devices.

For discussion about our services and how you can benefit from our SMEs and cost-effective implementation CDISC SDTM clinical data click here.

Case Study 2: Supporting the Sponsor with Database Transfer Solution

Assisting the Sponsor with Database Transfer Solution

Anayansi gamboa - Data Management Support @RAeClinica

 

 
The Scenario:

The Sponsor required a large safety and data management team to assist for a submission deadline requiring the transfer of data to a new safety database for clinical trials and post-marketed products.
RA eClinica Solution:

    • RA eClinica responsible for AE/SAE reporting, safety coding, NDA submission support
    • RA eClinica collaborated with the Sponsor’s safety team to develop a functional safety alliance consisting of over 10+ team members inclusive of management, safety and data management resources
    • Ra eClinica team is responsible for managing over 5+ compounds

Ra eClinica Results:

    • RA eClinica project team exceeded the timelines, completing the tasks approximately 30-days ahead of schedule
    • RA eClinica management collaborate with the Sponsor to redefine operational workflow and processes in order to increase efficiencies across several departments (Quality Control, Pharmacovigilance)

RA eClinica is a established consultancy company for all essential aspects of statistics, clinical data management and EDC solutions. Our services are targeted to clients in the pharmaceutical and biotech sector, health insurers and medical devices.

The company is headquarter in Panama City and representation offices with business partners in the United States, India and the European Union. For discussion about our services and how you can benefit from our SMEs and cost-effective implementation CDISC SDTM clinical data click here.