The CDISC Protocol Representation Model

Download Report

Transcript The CDISC Protocol Representation Model

CDISC © 2010

The CDISC Protocol Representation Model and IHE’s RPE: A SHARP Solution SHARP Teleconference 16 August 2010 Rebecca Kush Landen Bain

Value of a Structured Protocol Representation

Structured core protocol information to facilitate re-use of (trial registries, study management/tracking, study design, reporting) • • Ensure compliance with IRB requirements Facilitate study team comprehension of study requirements • Automation of Case Report Form creation (based on study design) and/or EHR configuration to support clinical research NOTE: NOT intended to inhibit creativity or innovation in study designs/protocol content 2

• • • • •

PR Group Approach

Development should concentrate on content first and implementation second Elements must be protocol elements – defined in a glossary , since the industry uses multiple definitions for the majority of CDISC Glossary, Applied Clinical Trials, published yearly Flexible research enough to accommodate any protocol-based Identify core set of elements initially, expand with further details as needed Initially based on ICH, EudraCT/clinicaltrials.gov/WHO requirements 3

CDISC Protocol Representation Standard - Development Protocol Representation Excel Spreadsheet Clinical Trial Tracking, Study Summary (SDTM) Clinical Trial Registry BRIDG Mapping; Harmonization Registry PR V 1.0 Standard Documentation Eligibility Criteria 9most common) CDISC Trial Design Part I (aims, elements, visits) XML Schema Development CDISC Trial Design PART II Planned assessments and interventions (NCI Study Calendar) CDISC Statistical Analysis Plan Other Protocol Template Sections and Attachments Eligibility Criteria (most common) CDISC Trial Design Part I (arms, elements, visits) CDISC Trial Design Part II Planned assessments & interventions (NCI Study Calendar) CDISC Statistical Analysis Plan PR V 1.0

Q1 2010 Other Protocol Template Sections and Attachments PR V 1.x

(2011) Copyright CDISC 2009 4

The BRIDG Model*

A clinical research domain analysis model (UML) initiated by CDISC, BRIDGing

Organizations (CDISC, HL7, FDA, NCI)

– –

Standards Research and Healthcare Towards semantic interoperability; a Portal to Healthcare Open source ; Collaborative Project

See BRIDG Model on CDISC website or www.bridgmodel.org

*Biomedical Research Integrated Domain Group (BRIDG) Model

5

Global Biomedical Research Standards (Protocol

Reporting)

Integrated Standards (BRIDG Release 3) and Controlled Terminology/Vocabulary Protocol Case Report Forms Laboratory Data Tabulated CRF data (SDTM) Analysis Datasets

Integrated Standards (BRIDG Release 3) and

Harmonized w/NCI caBIG CRFs CDISC ODM and/or HL7 Transport BRIDG = Biomedical Research Integrated Domain Group Model FDA eSubmissions Analysis and Reporting Protocol •Study Design •Eligibility •Registration •Schedule Case Report Forms (CDASH) ** •Study Data Laboratory Data (LAB) Tabulated CRF data (SDTM) •Study Data •Lab Data •Study Design •Schedule Analysis Datasets (ADaM)

*

** Harmonized w/ NCI caBIG CRFs * CDISC ODM and/or HL7 Transport

BRIDG = Biomedical Research Integrated Domain Group Model

BRIDG Accomplishments

• Released BRIDG 3.0.1 January 2010 • ‘Balloted’ as CDISC Standard through the Joint Initiative Council (JIC) in 2009/2010 • Passed ISO and HL7 ballots in May 2010 7

Domain-friendly,

3 Layer Model

Subdomain-specific business models Layer 2 BRIDG Domain analysis model (DAM) Layer 3 RIM based GRIDG model 8

View PR Protocol Representation

View PR Protocol Representation 9

CDISC Protocol Representation Model V Version 1.0 Now Available Protocol Section

Info for Trial Registration and Tracking Eligibility Criteria Study Design: Arms, Epochs Study Design: Planned Events Statistical Analysis Plan Appendices, 10 etc.

CRF Development

CDASH

CRFs

Data Collection Data Analysis

Information Re-Use Improved Quality and Efficiency

PR Version 1.0

Data Collection

SDTM

Data Tabulation Data Analysis

Report or eSubmission

Study Summary Eligibility Criteria Study Design: Arms, Epochs Study Design: Planned Events SDTM Tabulated Data

ADaM

Analysis

Datasets Appendices, etc.

Clinical Trial Registration: CTRR Project

• The intent of the CTRR project is to create a comprehensive and generic interchange standard for Clinical Trial Registries that includes all required and optional elements of most external clinical trial registries; including, but not limited to, EudraCT, clinicaltrials.gov, PDQ, and WHO. • Health Level Seven (HL7) Regulated Clinical Research Information Management (RCRIM) Technical Committee Project • The CDISC/HL7 clinical trial registries working group includes representatives from several pharmaceutical companies (eg., Novartis, J&J PRD, GSK), technology solution providers, CROs, NIH, clinicaltrials.gov, and observers from the FDA. 11

Eligibility Criteria

• • Each criterion is an

Observation

about a subject.

The observation can be complex, based on multiple other activities or results of other observations; the model has the capability to deal with such complexity.

Eligibility Criteria – ‘pan-disease’

• • • • • • • • Minimum Age Maximum Age Gestational Age Subject Gender Pregnancy Nursing Current Population Disease Condition Past Population Disease Condition • • • • • • • • Prior and Concomitant Medication(s) Subject Ethnicity Subject Race(s) Special Populations Ethical Considerations (e.g. informed consent) BMI Lifestyle Choices Substance Use 13

Defined eligibility criteria

Deferred Observation Defined inclusion Criterion Defined exclusion criterion 14

Coded Core Set of Eligibility Criteria

Use Case: Joyce Niland, City of Hope

• Minimal dataset to support the following use cases: – Locate potential protocols for a given individual • Tailor the query by matching core protocol eligibility against the subject characteristics – Locate potential subjects for a given protocol • Based on coded EHR data, to then contact (with permission) and screen for full eligibility – Evaluate the utility and prevalence of common core eligibility criteria • Assist in the initial design or refinement of protocols

Sample Use Case:

City of Hope Breast Cancer-Specific Protocol Search Filter City of Hope Breast Cancer Specific Protocol Search Filter

Study Design: Two Views

The protocol includes two views of a study:

The experimental design

• Often represented in a study schema –

The schedule of activities

• Often represented as a time and events table Source: Diane Wold 17

Schedule of Activities from ICH E3 annex

Sample schedule of activities Source: Diane Wold 18

Experimental Design Example

Experimental design example to include screening, induction, continuation and follow Screening Epoch up Induction Epoch Induction Treatment Screen Induction Treatment

Chemotherapy & Radiation Arm

Continuation Epoch Follow-up Epoch Continuation Chemotherapy Follow-up Surgery Continuation Chemotherapy Follow-up

Chemotherapy, Radiation & Surgery Arm

Experimental Design in the Protocol Representation Model

An activity in a global library of activities An activity in a global library of activities A planned instance of an activity at a particular point in a study

CDISC Standards and Data Flow

BRIDG model to include healthcare standards and CDISC clinical research standards

CDISC Standards and Data Flow

BRIDG model to include healthcare standards and CDISC clinical research standards and where RPE fits in

RPE

What is Retrieve Process for Execution (RPE)?

• An IHE profile that leverages BPEL and BPM to automate collaborative workflow between healthcare and secondary use domains such as research.

23

How does RPE work?

• • • Externally defined processes, such as a research protocol, are consumed and executed by EHR systems.

Web service ‘actors’ provide methods to import business process definitions (activities, tasks) as executable BPEL code.

Execution of the process is recorded by a state manager.

24

Retrieve Process for Execution

Well-accepted IT standards do exist for business process management (BPM) architecture. EHR However, these are

ProcessActivityExecutor

primarily focused on InitiateActivity ReceiveProcessStateAlert within an organizational boundary. RPE defines a Subscribe set of transactions for Subscribe collaboration across IT

ProcessDefinitionManager

system boundaries ReceiveProcessDefinitions DeployProcessDefinition InitiateProcess RetrieveActivities UpdateActivity ReceiveProcessStateAlert

ProcessStateManager

EDC process definitions, the manager of runtime processes and the

RPE 2.0 Architecture

• Key Goals: – – – Support collaborative process management Be consistent with accepted BPM architecture BUT, Accommodate existing variety of process engine/task processor implementations – Support arbitrary process representation formats

Trial Design vs. Trial Execution

“The trial design model is just that – a model of the trial’s design. It is not a record of an individual patient’s route through the trial. An execution runtime would reference the design elements to decide how a patient should progress through the trial and record this path accordingly. The trial design incorporates aspects of:

– –

Structure: Arms, Cells, Activities, etc. Workflow: How a patient should progress through a trial – decision points, branches, etc.

Timing: When the activities should happen relative to other activities or decision points in the trial. Trial execution would need to capture at least the following:

– – – –

The path that a patient took through the trial design. The activities that were performed on that path. The planned times for when the activities should have happened for that patient. The actual times that the activities and decision points were performed.

References to the design elements for static information that is common. Trial execution is outside the scope of this initial proposal.”

BPEL/BPEL4People provides an IT standard execution runtime solution

What is needed?

• • Discussion and analysis of how high-throughput phenotyping fits into the protocol representation and RPE paradigm.

Hypothesis: phenotype definition is a ‘content specification’ that could be represented within Protocol Representation and executed in RPE.

28