Latest revision as of 10:27, 20 April 2018

Introduction

NOTE: This profile has been renamed. You can find the most up-to-date information on it over at the main RPE Wiki:

Retrieve Process for Execution (RPE)

RPE Team

Vendor Participation
- Sponsors: Pfizer, Lilly, Novartis, Genzyme
- EHRs: Greenway, Cerner, Allscripts, Epic, GE Healthcare
- eClinical: Outcome Sciences, Nextrials, Phoenix Data Systems
Proposal Editor
- Landen Bain (CDISC)
Profile Editors*
- Daemon Whittenburg (Greenway Medical Technologies)
- Diane Wold (Glaxo Smith Klein - Chair of CDISC’s Trial Design Team )
Dan Levy (Outcome Sciences)
Robert Barr (NexTrials)
Chris Connor (Phoenix Data Systems / Bio-Imaging Technologies)
Jane Griffin (Cerner)
Jaime Lucove (AllScripts)
Lisa Chatterjee (DIFZ, chair of CDISC’s Protocol Representation team)
David Handelsman (SAS)
Mark Arratoon (GE Healthcare)
Jan Kratky (SAS)
Josh Painter (Intel)
Gary Walker (Quintiles)
Jason Rock
Jozef Aerts (XML4Pharma)

Meeting Agenda/Notes

  Upcoming meeting dates (every Friday starting on 4/10)
  Meeting time 1-2pm (est)

  For webex information visit ihe.webex.com and find the date of the meeting

Important Dates
May 29th 12pm noon	Need to have the RPE Supplement Document 05/20/2009 (No Tracking) completed for public comment
June 1st - July 1st	T-Con to approve documents for public comment. Public Comment period on IHE Profiles. (RPE Supplement Document 05/20/2009 (No Tracking))

6/19/09

(Daemon Whittenburg, Dan Levy, Donna Pritchet, Diane Wold, Gary Walker, Jaime Lucove, Mark Arratoon, Jeff James)

Discussed the prototype of the EnrollPatientRequest transaction between Greenway and Nextrials.
- This allows an EHR to auto-enroll a patient into a study of an EDC and receive back the subjectID of the subject in the study.
Briefly discussed the EHRCR Functional Profile Project
- Defines that an EHR must do these things
- How does the HL7 Study Design, Subject Participation work relate to the EHRCR?

7/10/09

Goal for this meeting is to discuss the messages in more detail and tie those messages in with the RPE schemas. We need to get an understanding of what type of data is needed for each transaction.

Open Issues

[Putting this off until more work is done on the document] - Discuss changes to the QRPH Supplement Document (RPE)
- Need to use the IHE Actions/Transactions standard diagram
- Pre-requisites are mentioend in Volume 1, but need to be incorporated into Volume 2, as well.
- Error-handling needs to be added.
Discuss PIX/PDQ to be used for all associated IDs to represent the patient
ProtocolStateManager needs RetrieveProtocolDef transaction from ProtocolDefManager
How will RFD work in conjunction with RPE?
- Supply context information of RFD forms to be used?
- Should there be a separate actor to manage the relationship between an RFD formID and a study visit?
- Are there extensions to the standards to place the RFD context information (FormManagerURL, FormID)?
Add additional use cases, such as the Cancer Registry's use case?
- Get Cancer Registry's Use Case
Similar issues are addressed in the Performance Measurement Data Element Structured for EHR Extraction white paper. What relation does RPE have with quality initiatives?
HL7v3 Clinical Research Filtered Query Service (possibly used later for querying)

Closed Issues

Profile Abstract

The Problem

Research protocols are complex instruction sets that guide the conduct of trials. A subset of the protocol pertains to the activities of the healthcare provider site that participates in the trial. This instruction set specifies the data to be captured, tests to be ordered, inclusion and exclusion criteria for subjects, number and type of visits, etc. These instructions currently reside in hard copy binders which provide guidance for study coordinators at research sites. What is desired is a way to insert protocol instructions into an EHR for automatic completion.

Need

The Retrieve Protocol for Execution Profile (RPE) provides an automated mechanism for an Electronic Health Record (EHR) to retrieve a complex set of clinical research instructions (Protocol Definition) from an Electronic Data Capture (EDC) system to execute within the EHR.

Summary

Many health care sites supplement their core patient care activities by participating in clinical trials. Currently, the tasks required for clinical research participation are served by systems entirely separate from the site's EHR. The ITI profile Retrieve Form for Data-capture (RFD), along with its complementary content profile Clinical Research Data-capture, have set a path towards integrating site-based clinical research work flow into the task manager of an electronic health record. This new profile, Retrieve Protocol for Execution, expands the scope of work flow integration between clinical research and EHR systems.

CDISC's Protocol Representation team intends to develop a standard protocol document, derived from the BRIDG, a RIM-linked data model. This protocol representation includes the Trial Design Model a standard structure for representing the planned sequence of events and the treatment plan of a trial. This planned sequence of events includes many tasks that could be executed by an EHR's work flow engine. The 'schedule of activities' section of the trial design includes clinical trial activities such as interventions (e.g., administering drug, surgery) and study administrative activities (e.g,. obtaining informed consent, distributing clinical trial material & diaries, randomization) as well as assessments. The time is ripe to insert these executable work flow tasks into the EHR for execution within the site's normal way of doing business.

State of systems before RPE

State of systems after RPE

Risks

Cross-system work flow integration is a relatively new area for IHE.
The EHR's risk encountering the clinical research regulatory environment 21 CFR part 11.
Coming up with a way for the EHR to be able to handle and manage changes to the Protocol Definition

Volume I - Integration Profiles

Glossary

Clinical Trial Protocol: The ICH (International Conference on Harmonization) GCP (Good Clinical Practice) defines a Clinical Trail Protocol to be "a document that describes the objective(s), design, methodology, statistical considerations, and organization of a clinical trial. The protocol usually also gives the background and reason the trial is being conducted, but these could be provided in other documents referenced in the protocol (such as an Investigator's Brochure)."
ProtocolDef: The protocol documentation created by an eClinical Research sponsor that describes a clinical research study. The ProtocolDef will be maintained by the ProtocolManager.
ProtocolState: The protocol state at the point in which a patient is involved in a clinical study.

Dependencies

patient inclusion/exclusion criteria
patient signed inform consent
labs
documented signed inform consent
screening

RPE Integration Profile

One paragraph description/ overview of Integration Profile

Detailed Proposal

Use Case - Investigational New Drug Clinical Trial

In the uses cases below, we describe the before and after effects of implementing the Retrieve Protocol for Execution profile.

The setting for the clinical trial use case is a physicians’ practice where patient care is delivered side-by-side with clinical research.
The site, Holbin Medical Group, is a multi-site physician practice, employing over 100 physicians in a variety of specialties.
Holbin’s CEO encourages the physicians to participate as site investigators for pharmaceutical-sponsored clinical trials.

Before Retrieve Protocol for Execution

Preconditions

A Clinical Research Protocol is defined by a clinical trials expert.
Holbin provides support for clinical research activities in the form of a Research Department of twelve dedicated study coordinators, mostly RNs, along with clerical and data-entry support personnel.
Holbin Medical Group uses an Electronic Health Record (EHR) and a number of sponsor-provided Electronic Data Capture (EDC) systems for documenting clinical trial activities.

Use Case

Clinical Research Site's Involvement
1. Holbin’s involvement in a clinical study begins when the Research Department receives a request for proposal (RFP) from PharmaGen, a biopharma research sponsor.
2. A Study Coordinator, Patricia Zone, RN, evaluates the RFP for business viability and clinical appropriateness, provides the requested documentation back to the sponsor, and agrees to participate
Approved as a site for PharmaGen #1234 trial
1. After being approved as a site for the PharmaGen #1234 trial, the site Holbin Medical Group provides the required regulatory documentation to the sponsor
2. The physician identified as the Principal Investigator and other study personnel receive protocol-specific training from the sponsor, including training in use of the SynerGen EDC system.
During the trial set-up period, Patricia takes a number of steps that require interaction with the EHR. At this juncture, searches are at an aggregate level
1. Ensures that the appropriate system security is in place for this protocol;
2. Recruits patients to participate as subjects according to inclusion and exclusion criteria described in the study protocol;
3. Creates a visit type for 1234 patient visits;
4. Reviews CRFs for data capture and data entry;
5. Pre-orders labs and other assessments;
6. Performs all the attendant financial tasks.
Following set up, Patricia contacts Corey Jones, a patient at Holbin, about participating in the trial, and Corey agrees to participate as a subject. A number of tasks deal with this individual patient
1. Register Corey in the EHR as a subject in trial #1234, using the EHR’s patient index.
2. She also registers Corey as a subject in the EDC system.
3. She schedules Corey’s study visits using the EHR scheduling module, and flags the visits as pertaining to the trial #1234.
4. Initiates clinical trial care and trial-specific documentation.

Postconditions: Holbin Medical Group uses an Electronic Health Record (EHR) and the SynerGen EDC Electronic Data Capture (EDC) system to document the PharmaGen #1234 trial activities.

After Retrieve Protocol for Execution

Precondition

A Clinical Research Protocol is defined by a clinical trials expert.

Use Case

Clinical Research Site's Involvement
1. ProtocolExecutor uses the RetrieveProtocolList transaction to obtain a list of protocols from the Protocol Manager
2. ProtocolExecutor uses the AgreesToParticipate transaction to notify ProtocolManager that the site agrees to participate in the study
3. ProtocolExecutor uses the RetrieveProtocol transaction to obtain the specific protocol from the ProtocolManager
Approved as a site for PharmaGen #1234 trial
1. ProtocolManager uses the SubmitProtocolApproval transaction to the ProtocolExecutor for a specific protocol
2. ProtocolExecutor uses the SubmitRegulatoryDocumentation transaction to submit required regulatory documentation to the ProtocolManager
Trial Setup
1. ProtocolExecutor uses the UpdateProtocolManager (patient identified) transaction to let the ProtocolManager know that patients have been identified
Patient Involvement
1. ProtocolExecutro uses the UpdateProtocolManager (request enroll patient) transaction to attempt to enroll the patient into the study
2. ProtocolExecutor uses the UpdateProtocolManager (schedule patient study visits) transaction to update the ProtocolManager that the study visits have been scheduled

Postcondition: Holbin Medical Group uses an Electronic Health Record (EHR) to document the PharmaGen #1234 trial activities using RFD.

Process/Flow

The flow of transactions between the Actors (ProtocolDefManager, ProtocolExecutor and ProtocolStateManager

Actors/Transaction

Figure 1.1-1 shows the actors directly involved in the <RPE> Integration Profile and the relevant transactions between them. Other actors that may be indirectly involved due to their participation in <RFD>, etc. are not necessarily shown.

Figure 1.1-1: RPE Actor Diagram

Table 1.1-1 lists the transactions for each actor directly involved in the <RPE> Profile. In order to claim support of this Integration Profile, an implementation must perform the required transactions (labeled “R”). Transactions labeled “O” are optional. A complete list of options defined by this Integration Profile and that implementations may choose to support is listed in Volume I, Section 1.2.

RPE Integration Profile - Actors and Transactions

Actor	Transaction	Option	Section
ProtocolDefManager	RetrieveProtocolDef	R	QRPH TF-2:3.Y1
ProtocolDefManager	AmendProtocolDef	R	QRPH TF-2:3.Y8
ProtocolExecutor	RetrieveProtocolDef	R	QRPH TF-2:3.Y1
	EnterPatientRequest	R	QRPH TF-2:3.Y2
	PatientScreeningVisitsScheduled	R	QRPH TF-2:3.Y3
	RecordPatientScreeningVisit	R	QRPH TF-2:3.Y4
	EnrollPatientRequest	R	QRPH TF-2:3.Y5
	PatientStudyVisitsScheduled	R	QRPH TF-2:3.Y6
	RecordPatientStudyVisit	R	QRPH TF-2:3.Y7
	AmendProtocolDef	R	QRPH TF-2:3.Y8
	AlertProtocolState	R	QRPH TF-2:3.Y9
ProtocolStateManager	EnterPatientRequest	R	QRPH TF-2:3.Y2
	PatientScreeningVisitsScheduled	R	QRPH TF-2:3.Y3
	RecordPatientScreeningVisit	R	QRPH TF-2:3.Y4
	EnrollPatientRequest	R	QRPH TF-2:3.Y5
	PatientStudyVisitsScheduled	R	QRPH TF-2:3.Y6
	RecordPatientStudyVisit	R	QRPH TF-2:3.Y7
	AlertProtocolState	R	QRPH TF-2:3.Y9

<Appendix A> Actor Summary Definitions

Protocol Definition Manager
- An entity that manages clinical research protocol definitions.
- An example would be an EDC vendor that wishes to allow access to the list of clinical research protocol definitions contained within the EDC system.
Protocol Executor
- An entity wanting to access clinical research protocol definitions from an entity that manages clinical research protocol definitions.
- An example would be an EHR vendor that wants to participate in clinical studies by accessing clinical research protocol definitions.
Protocol State Manager
- An entity wanting to receive clinical research data from a supplying entity
- An example would be an EDC vendor wanting to consume data from an EHR

<Appendix B> Transaction Summary Definitions

RetreiveProtocolDef
- Used to allow a ProtocolExecutor to retrieve an instance of a ProtocolDef for a particular study from a ProtocolDefManager
- Can be used by a site attempting to pull down a ProtocolDef once they have finalized all Prerequisites/Dependencies to execute this transaction

EnterPatientRequest
- prereq: patient has signed consent, meets pre-screening eligibility criteria before consent
- parameters: a structure to allow for multiple patients to be entered
PatientSCreeningVisitsScheduled
- prereq: patient entered
RecordPatientScreeningVisit
- prereq: patient entered
EnrollPatientRequest
- prereq: screening complete, meets screening eligibility criteria
- reasons for failure: screen failed, study put on hold, enrollment complete
PatientStudyVisitisScheduled
RecordPatientStudyVisit
- usage:
  - ProtocolExecutor needs to alert ProtocolManager that patient doesn't want to be a part of the study from ProtocolExecutor
  - An RFD form to withdraw the patient from study can also be used

AmendProtocolDef
- Allows a ProtocolDefManager to update the ProtocolExecutor when the ProtocolDef changes
AlertProtocolState
- Allows the ProtocolStateManager to update the ProtocolExecutor when something needs to change with the state of the subject-sepecifif Protocol information
- Examples are (ScreenFailed, FreezePatient, Unfreeze/Thaw, LockPatient/SignOffPatient/PatientComplete, Unlock [big issue...more auditable]

Volume II - Transactions

Retrieve Protocol for Execution Content

Standards

HL7v3 Study Design
- Study Design Explanation.pptx
HL7v3 Study Participation
HL7v3 Subject Data
CDISC ODM Study Design Extension (rename to .zip)

Resources

QRPH Framework Supplement Document
- RPE Supplement Document OLD
- RPE Supplement Document 05/20/2009 (No Tracking)
Schemas (.xsd)
WSDLs (.wsdl)
BPEL (.bpel)
- ProtocolStateManager.bpel
Use Case Material
- Public Health Use Case
Sample files
Miscellaneous

Return to Quality, Research and Public Health Domain Main Page
Return to Quality, Research and Public Health Planning Committee
Return to Quality, Research and Public Health Technical Committee

Difference between revisions of "Retrieve Protocol for Execution"