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 defined in a glossary, since the
industry uses multiple definitions for the majority of
protocol elements
– CDISC Glossary, Applied Clinical Trials, published yearly
• Flexible enough to accommodate any protocol-based
research
• 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
XML Schema
BRIDG Mapping;
PR V Study
1.0 Standard
Clinical Trial Tracking
Summary (STDM) Clinical Trial
Development
Harmonization
Registry Documentation
Eligibility Criteria 9most common)
CDISC Trial Design Part I (aims, elements, visits)
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)
PR
V 1.0
Q1 2010
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.x
(2011)
Other Protocol
Template Sections
and Attachments
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
FDA eSubmissions Analysis and Reporting
Harmonized w/NCI caBIG CRFs
CDISC ODM and/or HL7 Transport
BRIDG = Biomedical Research Integrated Domain Group Model
Integrated Standards
(BRIDG Release 3) and
Controlled Terminology/Vocabulary
Protocol
•Study
Design
•Eligibility
•Registration
•Schedule
Case
Report
Forms
(CDASH)**
•Study
Data
FDA eSubmissions
Analysis and Reporting
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, Subdomain-specific Business Model
Layer 1
Domain-friendly,
Subdomain-specific
business models
Layer 2
BRIDG Domain analysis
model (DAM)
Layer 3
RIM based GRIDG model
3 Layer 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
CRF
Data
Development Collection
Data
Analysis
Report or
eSubmission
Study
Summary
Information Re-Use
Improved Quality and Efficiency
PR Version 1.0
SDTM
Eligibility
Criteria
Study Design:
Arms, Epochs
Study Design:
Study Design:
Planned Events
Planned Events
CDASH
CRFs
Statistical
Analysis Plan
Data
Collection
Data
Tabulation
SDTM
Tabulated
Data
Data Analysis
ADaM
Analysis
Datasets
Appendices,
10
etc.
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 CancerSpecific 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 followScreening Epoch Induction Epoch
up
Chemotherapy & Radiation Arm
Continuation Epoch
Induction
Treatment
Continuation
Chemotherapy
Induction
Treatment
Surgery
Follow-up
Epoch
Follow-up
Screen
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
RPE
healthcare standards and
CDISC clinical research
standards and where
RPE fits in
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
EHR
(BPM) architecture.
However, these areProcessActivityExecutor
primarily focused on
InitiateActivity
ReceiveProcessStateAlert
processes ReceiveProcessDefinitions
managed
InitiateProcess
within an organizational
RetrieveActivities
RetrieveProcessDefinitions
UpdateActivity
boundary. RPE defines a
Subscribe
ReceiveProcessStateAlert
RetrieveProcessDefinitions
set of transactions for
Subscribe
collaboration
acrossReceiveProcessDefinitions
IT
ProcessDefinitionManager
ProcessStateManager
DeployProcessDefinition
system boundaries
involving three main
Research
EDC
Sponsor
actors: the manager of
process definitions, the
manager of runtime
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