Tag Archives: Case Report Form

OpenClinica: Printing subject casebooks, blank casebooks and blank CRFs

Wanna print subject casebooks using OpenClinica? This article is an extract from a video demo from the OpenClinica blog website. Click the link below now.

Source: http://blog.openclinica.com/2014/10/06/video-demos-printing-subject-casebooks-blank-casebooks-and-blank-crfs/

Happy Printing!!!

 

Fair Use Notice: This video 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. If you wish to use this copyrighted material for purposes that go beyond fair use, you must obtain permission from the copyright owner. Fair Use notwithstanding we will immediately comply with any copyright owner who wants their material removed or modified, wants us to link to their website or wants us to add their photo.

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.

Disclaimer:De inhoud van deze columns weerspiegelen niet per definitie de mening van {EDC Developer}.

Advertisements

Before Your Trial Goes Live – InForm FastStart

When EDC is used in a clinical trial, electronic case report form (e-CRF) data are defined to be the data that are manually entered into a computer by the patient or by the investigator’s staff.

CDISC defines e-CRF as a CRF in which related data items and their associated comments, notes, and signatures are linked electronically.

e-CRFs may include special display elements, electronic edit checks and other special properties or functions used for both capture and display of the linked data.

Prior to submitting a request – FastStart, you should throughly test your trial.

Technically speaking, FastStart requests ensures base is cooked when sending all UAT versions of the trial, Training and Production versions of the trial to Oracle implementation team. This will vary on the type of contract your company / sponsor has with them.

Your company or sponsor may have a setup of ‘Implementation’ instructions that will be provided to Oracle HSG (formerly PhaseForward) that includes all files, summary and instructions for each implementation. Some of these required files or special files are listed below.

Special Files:

Filename Contents
Customresources.XML Collects references to any html files that will be use to override standard InForm functionality within the trial. Includes the visit calculator (VISITCALCULATOR.HTML) and confirmation of enrollment message (ENROLLMENTCONFIRM.HTML).
InsertUsers.XML User details
InsertSites.XML Site details
InsertSiteGroups.XML Links users with specific sites
InsertGroups.XML Defines the properties and contents of groups e.g. queries, items
InsertRightsGroups.XML Groups multiple access rights, with details of specific users that are assigned those rights.Also contains details of any overrides to default levels of access at item level
InsertSignCRF.XML Defines form to be signed and group who have access to sign
Crbaffadavit.TXT Affadavit text which appears when signing the eCRF (used at eCRF level). The text is standard, but protocol number must be amended for each trial. NOTE: This file will be used for any trials using casebook level signatures.
logo.jpg Your company logo
EnrollmentOverride.htmlHomedefault.html Here you can modify your trial name

The eSignature is a replacement for the Investigator’s physical signature (paper form). This file captures confirmtion from the Investigator that he has reviewed and confirmed the information on each eCRF is accurate. This Affidavit text contains something like ‘I, Principal Investigator, for study 9999999, confirm I have reviewed this CRF form….’

Investigator– 21 CFR 50.3(d) defines the investigator as “The individual who actually conducts a clinical investigation – i.e., under whose immediate direction the test article is administered.”

Some recomendations about eSignature can be further research on Secure Access For Everyone (SAFE) standards. The goal is that once the investigator is credentialed by SAFE, his/her identity and electronic signature can be used by all SAFE compliant sponsors.

InsertUsers File

Training must be provided to sponsors users prior to granting access to an InForm trial. For example, CRAs will need to be well trained on all aspects of the EDC system in order to provide coaching for the investigator. This file documents all sponsors and site staff users within each clinical trial.

Easy, wasn’t it? Again, build your trial and test to make sure all files were cooked and working as expected. Log into your trial and ensure that the special files appear correctly. Enroll a subject to ensure the enrollment confirmation screen appears and, if used in the trial, the visit calculator appears.

Reference:

Electronic Clinical Data Capture, Position Paper Revision 1, May 1, 2005

How to manage Sites and Users in InForm Trial

Your comments and questions are valued and encouraged.
Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica, Open Source and Oracle Clinical.

A New Way to Collect Data – CDASH

There is a general consensus that the old paper-based data management tools and processes were inefficient and should be optimized. Electronic Data Capture has transformed the process of clinical trials data collection from a paper-based Case Report Form (CRF) process (paper-based) to an electronic-based CRF process (edc process).

In an attempt to optimize the process of collecting and cleaning clinical data, the Clinical Data Interchange Standards Consortium (CDISC), has developed standards that span the research spectrum from preclinical through postmarketing studies, including regulatory submission. These standards primarily focus on definitions of electronic data, the mechanisms for transmitting them, and, to a limited degree, related documents, such as the protocol.

Clinical Data Acquisition Standards Harmonization (CDASH)

The newest CDISC standard, and the one that will have the most visible impact on investigative sites and data managers, is Clinical Data Acquisition Standards Harmonization (CDASH).

As its name suggests, CDASH defines the data in paper and electronic CRFs.

Although it is compatible with CDISC’s standard for regulatory submission (SDTM), CDASH is optimized for data captured from subject visits, so some mapping between the standards is required. In addition to standardizing questions, CDASH also references CDISC’s Controlled Terminology standard, a compilation of code lists that allows answers to be standardized as well.

Example: Demographics (DM)

Description/definition variable name Format
Date of Birth* BRTHDTC dd MMM yyyy
Sex** SEX $2
Race RACE 2
Country COUNTRY $3

*CDASH recommends collecting the complete date of birth, but recognizes that in some cases only BIRTHYR and BIRTHMO are feasible.

* *This document lists four options for the collection of Sex: Male, Female, Unknown and Undifferentiated (M|F|U|UN). CDASH allows for a subset of these codelists to be used, and it is typical to only add the options for Male or Female.

The common variables: STUDYID, SITEID or SITENO, SUBJID, USUBJID, and INVID that are all SDTM variables with the exception of SITEID which can be used to collect a Site ID for a particular study, then mapped to SITEID for SDTM.

Common timing variables are VISIT, VISITNUM, VISDAT and VISTIM where VISDAT and VISTIM are mapped to the SDTM –DTM variable.

Note: Certain variables are populated using the Controlled Terminology approach. The COUNTRY codes are populated using ISO3166 standards codes from country code list. This is typically not collected but populated using controlled terminology.

Each variable is defined as:

  • Highly Recommended: A data collection field that should be on the CRF (e.g., a regulatory requirement).
  • Recommended/Conditional: A data collection field that should be collected on the CRF for specific cases or to address TA requirements (may be recorded elsewhere in the CRF or from other data collection sources).
  • Optional: A data collection field that is available for use if needed

The CDASH and CDICS specifications are available on the CDICS website free of charge. There are several tool available to help you during the mapping process from CDASH to SDTM. For example, you could use Base SAS, SDTM-ETL or CDISC Express to easily map clinical data to SDTM.

In general you need to know CDISC standards and have a good knowledge of data collection, processing and analysis.

With the shift in focus of data entry, getting everyone comfortable with using a particular EDC system is a critical task for study sponsors looking to help improve the inefficiencies of the clinical trial data collection process. Certainly the tools are available that can be used to help clinical trial personnel adapt to new processes and enjoy better productivity.


Anayansi Gamboa has an extensive background in clinical data management as well as experience with different EDC systems including Oracle InForm, InForm Architect, Central Designer, CIS, Clintrial, Medidata Rave, Central Coding, OpenClinica Open Source and Oracle Clinical.