Evolution of Gynecologic Oncology Group Use of caDSR

Evolution of Gynecologic Oncology Group Use of caDSR
Bill Elgie Director of IT NRG – Buffalo Office GOG Statistical & Data Management Center Roswell Park Cancer Institute Buffalo, New York

Agenda Background Legacy Data Entry System
eCRF Standardization and RAVE Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data Thank you for joining today. Very quickly the agenda for today’s discussion will be a little bit on my background and the organizations I am currently working for. An introduction to our legacy EDC, Electronic Data Capture System, and its use of CDE compliant forms. The move to standard eCRF and the use of RAVE to collect data with CDE compliant forms across all the NCTN’s LPOs. Now NCTN is the National Cancer Trials Network and an LPO is a Lead Protocol Organization formerly known as Cooperative Groups. The problem we are addressing and the solution using the CDE Browser, RAVE and the ultimate solution. I will finish up with the use of a Web Services within RAVE.

Background Roswell Park Cancer Institute
Gynecologic Oncology Group (GOG) 2000 – present NRG Oncology 2014 – present Frontier Science Research & Technology Foundation 1984 – 2000 AACTG (Adult Aids Cooperative Group) PACTG (Pediatric Aids Cooperative Group) CALGB (Cancer & Leukemia Group B) LUDWIG, INTERG

GOG’s The Gynecologic Oncology Group (GOG) organized in 1970.
as a non-profit international organization with the purpose of promoting excellence in the quality and integrity of clinical and basic scientific research in the field of Gynecologic malignancies. Since the 11 original member institutions grew to over 75 principal centers and over 200 affiliate institutions. Approximately 45 individual clinical trials were active at any one time for patients with a variety of gynecologic malignancies. Over 3,300 patients were registered each year to GOG trials. GOG completed well over 300 clinical trials and contributed over 550 manuscripts to peer reviewed medical literature.

NRG Oncology NRG Oncology brings together the unique and complementary research areas of the National Surgical Adjuvant Breast and Bowel Project (NSABP), Radiation Therapy Oncology Group (RTOG) Gynecologic Oncology Group (GOG). NRG Oncology builds upon our more than 150 years of cumulative research experience to conduct practice defining, multi-institutional clinical trials resulting in the improved survival and quality of life of patients with cancer.

eCRF Standardization and RAVE Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data

TELEForm Designer Cardiff Software TELEForms TELEForm PDF Designer
Internet Server Use TELEForms to design and create PDF, user friendly data entry screens with embedded data checks. Consistent look and feel to out eCRFs and interface with database.

Addition of In-line Logic
ActivePDF’s PDFToolkit We use this product to increase the number and complexity of data checking within a PDF eCRF.

Additional Information
Relational Database Management System Microsoft and Actian (Computer Associates) SQL Server Ingres RDBMS Permissions Username/password challenge, CTEP-IAM accounts User mapped to specific patients based on institution Role based permissions Electronic Audit Trail All transactions are logged Staging table holds all submissions All submitted transactions have a corresponding image file Just a couple of notes/thoughts to relay to you about our legacy system. We use two databases, SQL Server and Ingres. All of our systems use a username/password challenge to access our systems, we employ CTEP-IAM credentialling and users are assigned roles which provides them with permission to access the system. Users are assigned to institutions and only those institutions where the user has the proper role will be displayed to the user. Our electronic audit trail consists of logging transactions, staging tables and ever lasting images of submissions.

Patient Registration To get a patient into the system they must first be initiated via either CTSU’s OPEN system or our legacy registration/randomization system. A patient is assigned a patient identifier and that is used to initiate that patient into the system. This is true for our legacy system as well as within our RAVE instance.

Key Features Color coded patient calendar
Hyperlinks to Forms Images, Instructions, Uploads,.. Forms Due/Received Dates Patient Initiated from Registration System Once the patient is initiated into our system a calendar of events/visits becomes generated. The calendar is also the users link for accessing the forms via hyperlinks. On the calendar you will see patient information, a color coded set of dates and the ability to view previous submissions and access to forms instructions

CDE-compliant eCRF Pre-loaded with dates and user names
Pre-loaded drug names by protocol This is the end result of our legacy EDC, a CDE-compliant eCRF. Range checks for valid values and data checks

eCRF Standardization and RAVE Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data Now its time to discuss a common, standard EDC across all of the LPOs (Lead Protocol Organizations) within the NCTN (National Cancer Trials Network)

CRF Harmonization Process
The CRF Harmonization and Standardization initiative has undertaken the task of harmonizing and standardizing case report forms for cancer clinical trials by first dissecting the CRF into modules and tackling smaller sections of the CRF 5 areas at a time. The general process includes collecting an inventory of forms related to the information generally captured in that module, for example, On-Study Forms are collected to gather Agent information. The group then goes through all the forms and identifies those fields that are relevant to that module (area), partitions the fields as either Mandatory, Conditional or Optional, and then identifies appropriate Common Data Elements (CDEs) or creates new CDEs to accurately capture the metadata for the harmonized fields. Once the group identifies all the fields and CDEs to be collected in that module, these are sent to the Clinical Trials Community for review and comment, the comments are addressed, and the final list of fields are presented to the Clinical & Translational Research Operating Committee (CTROC) for final approval. After CTROC approval, the CDEs are brought to the Vocabularies & Common Data Elements (VCDE) Workspace for review as caBIG Standards. Once the CDEs are made standard, the module is officially available for use on cancer clinical trials. In October of 2009, the need for an Expanded Committee Review was identified. A change in the community review process was instituted in the Spring of The revised process is as follows:

NCI CRF Initiative Status
Round 1: Demography Round 2: - Adverse Events Enrollment Participant Identifier Protocol Deviation Registration Medical History Physical Examination Round 3: Study Agent/Compliance Pre/Post Treatment Agents Concomitant Agents Lab Tests/Results Staging/Extent of Disease Header/Footer/End of Form Round 4: Consent, Eligibility Criteria, Screening Surgery Radiation Therapy Diagnosis/Pathology – Administrative and Intervention Equipment Off Treatment/Off Study PET/Imaging (5 modules) Round 5: Diagnosis/Pathology – completion of Round 4 work Procedures/Procedure Results Response/RECIST Imaging Transmission, Acquisition, and Results Survival, Death, Follow-up The CRF Harmonization & Standardization project was initiated to provide a harmonized and standardized set of variables to be collected for oncology clinical trials that could be implemented to facilitate data entry, and study aggregation, comparison and analysis. The CRF collection process for Rounds 1-3 only collected Case Report Forms specific for that module. However, prior to Round 4, the Workgroup Leads recommended collecting CRFs for all areas and doing a single CRF inventory for all remaining modules, current and future Rounds.

NCI Standardized eCRFS
Implement across all groups Little standardization across LPOs in regards to caDSR content and usage Data capture processes Data cleaning processes LPO implementation of Medidata Rave® Continued use of LPO specific content non-caDSR content Mixed with caDSR content The forms that come from the NCI CRF Initiative will be implemented across all LPOs. Initially there was little standardization amongst the LPOs in regards to collection processes and use of caDSR/CDE compliance. RAVE will allow the LPOs to come together with a single EDC, the system continues to have the flexibility to provide for the use of LPO specific content.

Licensing of Medidata Rave®
The National Cancer Institute (NCI) Cancer Therapy and Evaluation Program (CTEP) purchased licensing rights from Medidata Solutions (Medidata) to use and distribute Medidata Rave®, to facilitate the conduct of clinical research throughout the NCI-supported clinical research enterprise. NCI CTEP identified the Cancer Trials Support Unit (CTSU) as the CDMS Cancer Support Center (CSC) to coordinate this endeavor. The CTSU established several CSC CDMS Working Groups to solidify requirements, processes and standards: CDMS Working Groups Data Elements Rave Mentorship Data Quality Rave Validation DCP Rave Adoption Study Build Integrations Study Conduct Leadership User Administration Metrics Working Group Leaders The National Cancer Institute (NCI) Cancer Therapy and Evaluation Program (CTEP) purchased licensing rights from Medidata Solutions (Medidata) to use and distribute Medidata Rave®, to facilitate the conduct of clinical research throughout the NCI-supported clinical research enterprise. Working with CTSU (CLICK)

Working Groups The Data Elements Working Group (DEWG):
Provide recommendations to facilitate CDMS study startup activities as related to the caDSR. Charged with the identification and resolution of barriers to implementation. The Study Build Working Group (SBWG): Define a standard workflow for building studies in Medidata Rave® and develop a standard approach for configuring studies, forms, edit checks, validations, and data loads. The Study Conduct Working Group (SCWG): Identify processes across groups which will benefit from standardization resulting in improved clinical trial efficiency while maintaining trial integrity.

Options Modify the caDSR Database structure
Modify the Medidata RAVE Software Come up with a LPO solution

Option#1 Modify the caDSR Database
The amount of effort required is too great. The data that exists is used by other entities other than the LPOs that would be adversely impacted. The funding for this effort does not exist.

Option #2 Modify Medidata RAVE Software
Simply not feasible Medidata’s existing customer base Not within the contract

Option #3 LPOs designed solution(s)
LPOs identified two options: Use only the NCI eCRF standard module content in Rave, and then convert the data into local codes/permissible values outside of Rave, OR Capture local codes/permissible values in Rave: Provided that the standard caDSR values are captured in Rave “as is”. Either standard values or local values may be “derived”, provided both are captured and stored in Rave. Data reported back to CTEP will be in the form of standard caDSR values.

LPO Solution Take the current caDSR structure +
Functionality that exists in RAVE LPO data within the data dictionaries NCI data within the data dictionaries LPO designed custom functions

eCRF Standardization and RAVE Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data I am going to briefly go through the use of the CDE browser, what is a CDE, and what is the end product in both our legacy and RAVE systems.

eCRFs Built From CDE Browser
Protocol Team meets to discuss protocol Curator and Clinical Data Coordinator Decision on forms Decision on fields CDE (Common Data Element) Browser what exists and what is missing Within our organization we have the protocol team assigned which consists of various members from the statistical staff, clinical data coordinators, IT, Translational Research Scientists, Quality of Life, Randomization,… Once the requirements of the protocol are determined, forms and schedules decided upon the CDE Formbuilder/curator, clinical data coordinator and IT begin to prepare the forms. The curator will use the CDE Browser to begin the process of pulling all of the data elements required and begin the process if new CDEs are required.

What is a CDE? A meta-data element conforming to the ISO/IEC Metadata registry standard Describes the meaning and representation characteristics of Data (A question and the answer) What question does this data value answer? What are the permitted values? What is its datatype? Information (metadata) is recorded in a Repository (catalog), that is independent of application programs or database descriptions and therefore reusable across different projects.

NCI CDEs Linked to controlled terminology to define:
the meaning/context of the data The question being asked. the meaning of each value in the value set The answer to the question asked. Developed by end user for specific projects (real data) Available in human and computer friendly formats Excel download XML download Java API Rest API Web Browser tools Wiki pages

Example of a SEDES Form EXAMPLE OF SEDES D2M form
By drilling down into the CDE browser you go down to the level of expected valid values for a particular field. In this example I am working my way down to a Patient Performance data item.

CDE Browser – Data Details
Within the CDE browser you can reach the Data Element and gain information on that particular data element

CDE Browser – Value Domain
The Value

Values and Meanings

CDE-compliant eCRF The resulting process of going through the CDE Browser is also the starting point for creating a form in RAVE.

eCRF Standardization and RAVE across LPOs Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data At this point it is worth taking a quick look at Medidata’s RAVE product. The amount of time

RAVE Introduction Architect Folders Forms Fields Data Dictionaries
Custom Functions The Architect of RAVE is where you build your protocol. This is where you define how you will collect you data.

RAVE Navigation Patient Fields Protocol Form Folder Home Institution
When you have a protocol, the navigation within RAVE is broken down into this navigation through a patient’s data.

Architect Screen These are the modules of RAVE, with Architect where we will focus.

Architect Screen With Architect, you have all of the items used to build a protocol within RAVE.

Folders The folders within RAVE hold the collection of Forms to complete

Forms Within the Forms Data Item you will find all of the forms available for that protocol. Remember we are just in the building process, this is not have the data appears to the user.

Fields Within the forms, the fields are located. This is where the CDE Element is located with the valid questions as the label for the field and the field being the actual data item.

Individual Field Data Dictionary within RAVE
For the fields within RAVE, there can be an associated Data Dictionary used to define the valid values for the field. And only those valid values are permitted. Data Dictionary within RAVE

eCRF Standardization and RAVE across LPOs Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data We are now ready to address the problem where an LPO has a (or multiple) LPO specific questions and asso

Deriving Values Capture data with one dictionary
Map that data with a different dictionary Store that data on a new form Or same form or multiple forms With the ability to store this in a new folder Custom Functions do the heavy lifting Staff maintain the data dictionary mappings Data within RAVE can have a data dictionary behind a field that dictates the valid values to capture. With the approach that we have developed we can map that data to another field with a different dictionary. This is accomplished through the use of a Custom Function written in C#, stored in RAVE and executed at run-time. <CLICK> this data can be stored on a completely different form, it can be on the same form (hidden or not) and the data from one form can populate multiple forms or multiple forms can populate a single form. The process developed also has the ability to copy the data to a completely different folder.<CLICK>The Custom Functions which drive the process do all of the work, with the Study Builder staff, not IT staff, maintaining the driving data within the dictionaries. Once the dictionaries are created, these are readily copied from protocol to applicable protocol.

Data Dictionary Solution
Within RAVE, the Study Builder will define two forms, each capturing the same data but with different dictionaries. The Performance Status is located on both the Cycle Patient Information form and the NCI Registration Form. Remember, these are fictitious examples, where the names have been changed to protect the innocent. The NCI registration forms has a NCI_ECOG_TEST as a data dictionary. Performance Status field with a different dictionary.

Data Dictionary LPO Dictionary (ECOG_SCALE_PID2015172_V6_1 )
Mapping Dictionary The LPO Dictionary and the NCI Dictionary are linked by a Study Builder maintained data dictionary which links the values. NCI Dictionary (NCI_ECOG_TEST )

Identify LPO forms to satisfy Standard form
The LPO, with this process, has the ability to take fields from many forms and place those values onto a single NCI form. There is a data dictionary that is used to “number” or “tag” the forms involved in this process.

Data Dictionaries store table and field destinations
Field mapping dictionary set to copy fields from one form to multiple destinations Form mapping dictionary set to copy fields from one form to multiple destinations The mapping dictionaries are used to map the source and destination fields and the destination forms involved.<CLICK>The 0 indicates that the two destination fields located on the REG_NCI form and <CLICK> 1 indicates the destination fields to be placed on the PH_NCI form.

Folder Option Create a corresponding NCI Folder
Place standardized forms in NCI Folder Automate replication to these forms The last example of the process is where a NCI folder is activated or “appears” upon the submission of a specific entry and the data is copied to that folder.

PROCESS – Prior to submission
In this example we see that with the patient’s root level there is a Baseline folder and no NCI folder. Within the Baseline folder, there exists a Registration form with the Performance Status field.<CLICK>

PROCESS – during submission
Once the user completes and submits this form, the Custom Function is called to drive the process. User completes the LPO form

PROCESS – After Submission
One LPO form captures data and populates multiple Standard forms The NCI folder is created and within that folder the Baseline folder is created and the appropriate forms are copied to the NCI folder’s new Baseline folder..

PROCESS – NCI Folder created
A new folder was created at the patient level The placing of a folder within a folder is not a recommended approach but during our research of trial and error, we found that this solution is a possibility. And worth further exploration. The folder structure is copied automatically under the “NCI root”

Basic of one-to-one solution
Data Dictionary Defines LPO values Data Dictionary Defines the linkage Edit Check on the LPO form calls the Custom Function Data Dictionary Defines NCI values To quickly summarize Custom Function (C#) populates the fields

Build edit check to call custom function
Resulting Edit Check should look as follows The call to the Custom Function is rather bland but is worth showing

Summary of Proposals One form collects all information
LPO and NCI on same form One form populates multiple forms LPO questions from one to multiple NCI Multiple forms populate one form Multiple LPO forms to one NCI form Copying folder structures is worth exploring

Caveats for this Process
Custom Function requires the following conventions to make this portable across RAVE instances: NCI folder name Driving Data Dictionary names Use of Data within the Data Dictionary Study Builders will maintain the Mapping Dictionaries and not IT staff. Once built, these are portable across an LPO’s protocols within RAVE. The Custom Function does require a few standards to be followed, the name of the NCI folder, the actual names of the driving data dictionaries and the use of the data within the dictionaries must obviously remain consistent across all those using the process. <CLICK> This will not require IT staff to reprogram, but Study Builders to maintain the data. A positive point with this approach is that this will reuse of a set of standard variables and will not be a new collection with each trial.

eCRF Standardization and RAVE across LPOs Using CDE Browser RAVE folders, forms and fields Mapping Solution One to One, many to one and across folders PDF Creation and population with RAVE data To finish up the meeting, I want to discuss another solution of using Web Services when data is entered using the electronic data capture system RAVE, to place that data on a PDF and actually push that PDF back into RAVE.

Web Service to populate a PDF
Institution Staff logins to RAVE Keys data onto RAVE screens Web Services pushes data to Data Center The workflow is fairly simple. The Institution staff used RAVE to enter the data, at submission a Custom Function is fired to call a web service, which brings the data back to the data center. A process at the data center takes the data, populates a pdf and pushes that back to RAVE. There is a field on the RAVE form where the link to the PDF appears and the user now has access to the PDF. What follows is our implementation of this process with a transmittal form, manifest, for a specimen transmittal form that is shipped with a patient’s specimen going to the Tissue Bank. Web Service pushes PDF back into RAVE Data is populated on PDF

Translation Research Form

Specimen Consent Click the Baseline Folder icon
Answer questions and hit Save Within the Baseline folder for this particular protocol, we have a form that we call our Specimen Consent form. This acknowledges the patient’s willingness and permission to provide specimens per the protocol. Once the form is submitted the process will continue by <CLICK>

Patient Root – Before & After
Translational Research Folder Click the Translational Research Folder to generate the TR forms for shipping Mandatory TR Forms Due Adding to the patient’s collection of folders a new folder called Translation Research. Within this folder are a few forms that are used to drive the process and collect the shipping information for the submitted specimens <CLICK>

TR Driver Form There is a form in this folder that we refer to as the “Driver” form, this form indicates which specimens for the protocol were collected. There are mandatory specimens and optional specimens. For each of the specimens collected, the user will indicate using the Radio buttons if the specimen was in fact collected and once the Save button is selected data is pushed onto the forms. <CLICK>

Complete the TR form For each specimen the institution user will complete a TR form that goes with the specimen being shipped.

Enter Data Enter the data and hit save The institution staff completes the form and hits save to submit the data

Save data, hyperlink created
Hyper link to the transmittal form At this point, without the link, the institution staff would use the printable view within RAVE, but that would yield a three page printout. But with the PDF being populated with data and pushed into RAVE, you now have a transmittal form that looks like…..

Click, print and ship Completed manifest that is to be printed and shipped with the specimen. The alternative to this print out is a multi-page print out from the RAVE system. And that concludes my presentation.

Thank you for your time

Evolution of Gynecologic Oncology Group Use of caDSR

Similar presentations

Presentation on theme: "Evolution of Gynecologic Oncology Group Use of caDSR"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Evolution of Gynecologic Oncology Group Use of caDSR

Similar presentations

Presentation on theme: "Evolution of Gynecologic Oncology Group Use of caDSR"— Presentation transcript:

Similar presentations

About project

Feedback