Retrieve Protocol for Execution

From IHE Wiki
Jump to navigation Jump to search

Introduction

This is a draft of the Retrieve Protocol for Execution Profile (RPE) supplement to the Quality, Research, and Public Health (QRPH) Technical Framework. This draft is a work in progress, not the official supplement or profile.

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

Meeting Agenda/Notes

RPE Meeting Notes Archive 

  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 18th Need to have the RPE Supplement Document completed for public comment (May 18th deadline)
June 1st - July 1st Public Comment on RPE Supplement Document


5/22/09

  • Discuss supplement document due date
  • Discuss items brought up by Mark Arratoon
    • Regards the current transactions and schema definition exercise: I wanted to step back and clarify the intent of each operation and then look at the related models out there:
    • RetrieveProtocolDef
      • The current query argument "may" be able to reuse the HL7(v3) Query type that I saw but wouldn't we be returning a SET of possible protocol definitions?
        • We do need the ability to return a SET. This transaction has a lot of work needed and would probably be an hour discussion one Friday. We may have to keep it simple for now and expand later. Simple being, pass a ProtocolDef identifier in the request and get a ProtocolDef as a response.
      • And what should be used for the protocol definition type itself? CDISC or HL7 related study definition types?
        • Since we have only received schemas for the HL7 flavor, for now we should reference the HL7v3 Study Design. We can expand this with options in the profile later if needed.
    • EnterPatientRequest
      • Also looks like we could just use a (unique) study ID vs. the full study type here
        • I agree, the PE and PSM should be able to identify the protocolDef base on the studyID
      • Currently we only have 1 patient/study combination - do we need to modify per supplement to allow a list of patients to be implemented per study? (This presumes we are entering against the 1 study at a time.)
        • The first cut was just to provide a mechanism (for understanding), but yes I agree that we should provide the ability for multiple patient’s to be entered into a given study in a batch mode.
        • I’m not sure about doing multiple studies. This would be interesting, I’m just not sure practical.
      • And if we do latter should we modify the workflow to loop for the N patients in the study?
        • Yes, we should loop if we have multiples.
    • PatientScreeningVisitsScheduled
      • What does the ProctolStateManager (PSM) need to know here? I.e., does the PSM (EDC) need to know the actual schedule? Or is it just interested in the fact that the visits have been scheduled?
        • From previous discussions, I believe it needs to know the actual schedule. This way the EDC system can monitor progress of a given study. If some information didn’t come in on a set visit, then the PSM may need to send an alert to the PE that the state needs to change (possibly start over the study or remove subject from study). Once again, just my understand and others may have better answers.
      • Is there any validation or checking of this visit schedule against protocol defn requirements?
        • We do not have or require this in the RPE Profile, however, I’m sure this is an activity that the PSM would need to do. I’m not sure how we represent this?
      • What provision is there in the HL7 (or CDISC) study types for attribution of (time-related) schedule data?
        • This would be a Jason Rock (HL7) or Diane Wold (CDISC) question.
    • RecordPatientScreeningVisit
      • I presume this just records the data captured at the screening visit, but again what checking does the PSM do if any against protocol requirements? Should rejection or warnings be possible?
        • We need more discussion about what takes place during recording a patient’s screening/study visit. The idea here was to use RFD to retrieve a form and submit some extra information that was not recorded within the EHR. However, because of the asynchronous and cross browser behavior of RFD, we left a transaction to allow the PE to submit a message stating what was being done. I’m still unsure exactly what this is, but see the need. This needs more discussion as well.
        • Another related subject to discuss here, is how the PE gets the “Interface” information related to RFD based on the ProtocolDef. This (RFD Interface Link) information is neither contained within the HL7v3 schemas nor the TDM. This is possibly going to require another actor for retrieve RFD Interface specs for a study. Still more discussions required.
    • EnrollPatientRequest
      • Again maybe we could use just the study ID here as per EnterPatientRequest?
        • Same as EnterPatientRequest
      • If we support a patient list for latter I presume we may still want to enroll one at a time withina big outer loop?
        • I could see batch enrollment. However, I’d prefer that the group agree on this.
    • PatientStudyVisitsScheduled
      • Similar comments to PatientScreeningVisitsScheduled
        • Same as PatientScreeningVisitsScheduled
    • RecordPatientStudyVisit
      • Similar comments to RecordPatientScreeningVisit
        • Same as RecordPatientScreeningVisit
  • Walk through the RPE schema and the HL7v3 StudyDesignParticipationSchemas.zip schemas and discuss each Type that is being referenced for each transaction
  • Some open questions
    • Why in PORT_MT100001UV.Study is there only 2 subjects and 2 performers and not N?
    • Why is PORT_MT100001UV.Subject1 not represented PORT_MT100001UV.Study in which appears to be the only subject type having a natural Person?
      • PORT_MT100001UV.Subject1 may not refer to the subject that we were thinking of in RPE
    • Visit is represented by an encounter

5/29/09

  • [Putting this off until Daemon does more work on the document] - Discuss changes to the QRPH Supplement Document (RPE)
  • TODOs
    • 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.

Open Issues

  • 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
  1. A Clinical Research Protocol is defined by a clinical trials expert.
  2. 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.
  3. 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
  1. 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
  2. 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.
  3. 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.
  4. 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
  1. A Clinical Research Protocol is defined by a clinical trials expert.
Use Case
  1. 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
  2. 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
  3. Trial Setup
    1. ProtocolExecutor uses the UpdateProtocolManager (patient identified) transaction to let the ProtocolManager know that patients have been identified
  4. 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
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

Resources



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

Retrieved from "http://wiki.ihe.net/index.php?title=Retrieve_Protocol_for_Execution&oldid=33096"