Presentation on theme: "Evolution of Gynecologic Oncology Group Use of caDSR"— Presentation transcript:
1Evolution 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
2Agenda Background Legacy Data Entry System eCRF Standardization and RAVEUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataThank 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.
3Background Roswell Park Cancer Institute Gynecologic Oncology Group (GOG)2000 – presentNRG Oncology2014 – presentFrontier Science Research & Technology Foundation1984 – 2000AACTG (Adult Aids Cooperative Group)PACTG (Pediatric Aids Cooperative Group)CALGB (Cancer & Leukemia Group B)LUDWIG, INTERG
4GOG’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.
5NRG OncologyNRG Oncology brings together the unique and complementary research areas of theNational 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.
6Agenda Background Legacy Data Entry System eCRF Standardization and RAVEUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE data
7TELEForm Designer Cardiff Software TELEForms TELEForm PDF Designer Internet ServerUse 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.
8Addition of In-line Logic ActivePDF’s PDFToolkitWe use this product to increase the number and complexity of data checking within a PDF eCRF.
9Additional Information Relational Database Management SystemMicrosoft and Actian (Computer Associates)SQL ServerIngres RDBMSPermissionsUsername/password challenge, CTEP-IAM accountsUser mapped to specific patients based on institutionRole based permissionsElectronic Audit TrailAll transactions are loggedStaging table holds all submissionsAll submitted transactions have a corresponding image fileJust 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.
10Patient RegistrationTo 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.
11Key Features Color coded patient calendar Hyperlinks to FormsImages, Instructions, Uploads,..Forms Due/Received DatesPatient Initiated from Registration SystemOnce 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
12CDE-compliant eCRF Pre-loaded with dates and user names Pre-loaded drug names by protocolThis is the end result of our legacy EDC, a CDE-compliant eCRF.Range checks for valid values and data checks
13Agenda Background Legacy Data Entry System eCRF Standardization and RAVEUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataNow its time to discuss a common, standard EDC across all of the LPOs (Lead Protocol Organizations) within the NCTN (National Cancer Trials Network)
14CRF 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:https://wiki.nci.nih.gov/download/attachments/ /CRF_Harmonization_Process.jpg?version=1&modificationDate=
15NCI CRF Initiative Status Round 1: DemographyRound 2: - Adverse EventsEnrollmentParticipant IdentifierProtocol DeviationRegistrationMedical HistoryPhysical ExaminationRound 3: Study Agent/CompliancePre/Post Treatment AgentsConcomitant AgentsLab Tests/ResultsStaging/Extent of DiseaseHeader/Footer/End of FormRound 4:Consent, Eligibility Criteria, ScreeningSurgeryRadiation TherapyDiagnosis/Pathology – Administrative and InterventionEquipmentOff Treatment/Off StudyPET/Imaging (5 modules)Round 5:Diagnosis/Pathology – completion of Round 4 workProcedures/Procedure ResultsResponse/RECISTImaging Transmission, Acquisition, and ResultsSurvival, Death, Follow-upThe 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.
16NCI Standardized eCRFS Implement across all groupsLittle standardization across LPOs in regards tocaDSR content and usageData capture processesData cleaning processesLPO implementation of Medidata Rave®Continued use of LPO specific contentnon-caDSR contentMixed with caDSR contentThe 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.
17Licensing 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 GroupsData ElementsRave MentorshipData QualityRave ValidationDCP Rave AdoptionStudy BuildIntegrationsStudy ConductLeadershipUser AdministrationMetricsWorking Group LeadersThe 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)
18Working 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.
19Options Modify the caDSR Database structure Modify the Medidata RAVE SoftwareCome up with a LPO solution
20Option#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.
21Option #2 Modify Medidata RAVE Software Simply not feasibleMedidata’s existing customer baseNot within the contract
22Option #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,ORCapture 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.
23LPO Solution Take the current caDSR structure + Functionality that exists in RAVELPO data within the data dictionariesNCI data within the data dictionariesLPO designed custom functions
24Agenda Background Legacy Data Entry System eCRF Standardization and RAVEUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataI 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.
25eCRFs Built From CDE Browser Protocol Team meets to discuss protocolCurator and Clinical Data CoordinatorDecision on formsDecision on fieldsCDE (Common Data Element) Browserwhat exists and what is missingWithin 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.
26What is a CDE?A meta-data element conforming to the ISO/IEC Metadata registry standardDescribes 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.
27NCI CDEs Linked to controlled terminology to define: the meaning/context of the dataThe question being asked.the meaning of each value in the value setThe answer to the question asked.Developed by end user for specific projects (real data)Available in human and computer friendly formatsExcel downloadXML downloadJava APIRest APIWeb Browser toolsWiki pages
28Example 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.
29CDE Browser – Data Details Within the CDE browser you can reach the Data Element and gain information on that particular data element
32CDE-compliant eCRFThe resulting process of going through the CDE Browser is also the starting point for creating a form in RAVE.
33Agenda Background Legacy Data Entry System eCRF Standardization and RAVE across LPOsUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataAt this point it is worth taking a quick look at Medidata’s RAVE product. The amount of time
34RAVE Introduction Architect Folders Forms Fields Data Dictionaries Custom FunctionsThe Architect of RAVE is where you build your protocol. This is where you define how you will collect you data.
35RAVE 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.
36Architect ScreenThese are the modules of RAVE, with Architect where we will focus.
37Architect ScreenWith Architect, you have all of the items used to build a protocol within RAVE.
38FoldersThe folders within RAVE hold the collection of Forms to complete
39FormsWithin 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.
40FieldsWithin 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.
41Individual 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
42Agenda Background Legacy Data Entry System eCRF Standardization and RAVE across LPOsUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataWe are now ready to address the problem where an LPO has a (or multiple) LPO specific questions and asso
43Deriving Values Capture data with one dictionary Map that data with a different dictionaryStore that data on a new formOr same form or multiple formsWith the ability to store this in a new folderCustom Functions do the heavy liftingStaff maintain the data dictionary mappingsData 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.
44Data 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.
45Data Dictionary LPO Dictionary (ECOG_SCALE_PID2015172_V6_1 ) Mapping DictionaryThe LPO Dictionary and the NCI Dictionary are linked by a Study Builder maintained data dictionary which links the values.NCI Dictionary (NCI_ECOG_TEST )
46Identify 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.
47Data Dictionaries store table and field destinations Field mapping dictionary set to copy fields from one form to multiple destinationsForm mapping dictionary set to copy fields from one form to multiple destinationsThe 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.
48Folder Option Create a corresponding NCI Folder Place standardized forms in NCI FolderAutomate replication to these formsThe 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.
49PROCESS – 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>
50PROCESS – during submission Once the user completes and submits this form, the Custom Function is called to drive the process.User completes the LPO form
51PROCESS – After Submission One LPO form captures data and populates multiple Standard formsThe 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..
52PROCESS – NCI Folder created A new folder was created at the patient levelThe 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”
53Basic of one-to-one solution Data DictionaryDefines LPO valuesData DictionaryDefines the linkageEdit Check on the LPO form calls the Custom FunctionData DictionaryDefines NCI valuesTo quickly summarizeCustom Function (C#) populates the fields
54Build edit check to call custom function Resulting Edit Check should look as followsThe call to the Custom Function is rather bland but is worth showing
55Summary of Proposals One form collects all information LPO and NCI on same formOne form populates multiple formsLPO questions from one to multiple NCIMultiple forms populate one formMultiple LPO forms to one NCI formCopying folder structures is worth exploring
56Caveats for this Process Custom Function requires the following conventions to make this portable across RAVE instances:NCI folder nameDriving Data Dictionary namesUse of Data within the Data DictionaryStudy 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.
57Agenda Background Legacy Data Entry System eCRF Standardization and RAVE across LPOsUsing CDE BrowserRAVE folders, forms and fieldsMapping SolutionOne to One, many to one and across foldersPDF Creation and population with RAVE dataTo 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.
58Web Service to populate a PDF Institution Staff logins to RAVEKeys data onto RAVE screensWeb Services pushes data to Data CenterThe 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 RAVEData is populated on PDF
60Specimen Consent Click the Baseline Folder icon Answer questions and hit SaveWithin 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>
61Patient Root – Before & After Translational Research FolderClick the Translational Research Folder to generate the TR forms for shippingMandatory TR Forms DueAdding 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>
62TR Driver FormThere 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>
63Complete the TR formFor each specimen the institution user will complete a TR form that goes with the specimen being shipped.
64Enter DataEnter the data and hit saveThe institution staff completes the form and hits save to submit the data
65Save data, hyperlink created Hyper link to the transmittal formAt 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…..
66Click, print and shipCompleted 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.