RPEMeetingNotesArchive

Back to RPE Profile

12/12/08

Discussed Detailed Proposal

12/19/08

Discussed RPE Use Case Graphic

01/09/09

Discussed RPE Flow Diagram
Transactions from Protocol Manager to Protocol Executor when the study changes
- AmendProtocolDefinition
Studies should be versioned
- Added to Flow Diagram
Check study version transaction
- Is there a todo here?
Add enter patient in study transaction (responses: ACK ENTER, ACK ENROLL, ACK INFORM CONSENT). This would happen before the patient is enrolled into a study.
- Added to Flow Diagram: UpdateProtocolState (XML Message to EnterPatientRequest/ScreenPatientRequest?)
Add Prerequisites/Dependencies
- (patient ran through inclusion/exclusion criteria, patient signed inform consent, labs, documented signed inform consent, screening etc.)
- Need to define these in more detail
Patients get “screen failed” may or may not be entered into EDC
- This will be a response from the UpdateProtocolState(EnrollPatientRequest) transaction with instructions on next steps (define next steps)
List before/after of enroll
- No idea what i was trying to accomplish here
Changed Enroll Patient to EnrollPatientRequest
- Added to Flow Diagram
Determined that only the "UpdateProtocolManager(EnrollProtocolRequest)" Transaction would be worked for the next publication of RPE.
Currently the focus as well as documenting the other items involved in the RPE use case

01/16/09

Agenda
- Review RPE wiki
- Define input/output data elements needed for the UpdateProtocolManager(EnrollPatientRequest) transaction
  - Work will be needed form the EDC side in order to define these data elements
- Discuss XML standards to be used for message parameter supplied in the UpdateProtocolManager transaction
  - Choosing an XML standard cannot happen until we have defined the data elements needed for the transaction
  - Need to also think about other data elements needed for the other options for this "UpdateProtocolManager" transaction
Define the difference between Protocol and Protocol State.
- ProtocolDefinition
- ProtocolInstance/ProtocolState
- From the Trial Design Model (TDM) - 1.2 Separation of Concerns: Trial Design vs. Trial Execution?
- Three have been proposed...will add to agenda for next meeting
  1. ProtocolDocument – aka ProtocolDoc
  2. ProtocolDesign – aka ProtocolDesign
  3. ProtocolDefinition – aka ProtocolDef
- New name for UpdateProtocolManager based on this decision?
Add AmendProtocol transaction from ProtocolManager to ProtocolExecutor
- Added an AmendProtocolDefinition transaction to the RPE Flow Diagram
Add EnterPatient/PatientInScreening transaction
- Added an UpdateProtocolState(EnterPatientRequest/ScreenPatientRequest) transaction to the RPE Flow Diagram
Add FreezePatient transaction
- Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram
Add LockPatient/SignOffOnPatient transaction
- patient is done
- Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram
Add Unfreeze/Thaw transaction
- Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram
Add UnLock transaction
- big issue...more auditable
- Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram
Discussed the need to clarify why we chose to do the one transaction "UpdateProtocolManager(EnrollProtocolRequest)"
- Seems to be one of the most needed?
- The content used for the ProtocolDef will come from the Trial Design Model (TDM), which is not complete
- The "UpdateProtocolManager(EnrollProtocolRequest)" transaction doesn't need the entire ProtocolDef to be functional, just an identifier for the ProtocolDef

01/23/09

RPE wiki changes?
- Reviewed changes from last meeting
Add Prerequisites/Dependencies
- (patient ran through inclusion/exclusion criteria, patient signed inform consent, labs, documented signed inform consent, screening etc.)
- Need to define these in more detail
- Looked good, Robert to look them over
Define the difference between Protocol and Protocol State
- ProtocolDefinition
- ProtocolInstance/ProtocolState
- From the Trial Design Model (TDM) - 1.2 Separation of Concerns: Trial Design vs. Trial Execution?
- Three have been proposed
  1. ProtocolDocument – aka ProtocolDoc
  2. ProtocolDesign – aka ProtocolDesign
  3. ProtocolDefinition – aka ProtocolDef
- New name for UpdateProtocolManager based on this decision?
- Will use ProtocolDef to define the Protocol Document being created by eClinical and maintained by the ProtocolManager (Updated the RPE Flow Diagram)
- Will use UpdateProtocolExeStep to define the transaction that allows the ProtocolExecutor to update the ProtocolManager when the Execution Step has taken place (Updated the RPE Flow Diagram)
- Added ProtocolDef and ProtocolState to the Glossary
Glossary needs some attention
- Added ProtocolDef and ProtocolState to the Glossary
Update transactions to reflect new transactions from 01/16 meeting
- Updated the transactions to reflect previous discussions and the RPE Flow Diagram
- Is it alright to put a link to the Trial Design Model document on the wiki?
- Uploaded the TDM document per Diane Wold
Open/Closed issues needs work?
- Cleaned it up a little...Open/Closed issues will mostly work from the meeting notes
Review input/output data elements needed for the UpdateProtocolManager(EnrollPatientRequest) transaction
- Work will be needed form the eClinical side in order to define these data elements
- What data is needed from the EHR to successfully Enroll a subject into EDC for a study
- What data is available from the EDC to store within the EHR
[To be done after the input/output data elements are defined] Discuss XML standards to be used for message parameter supplied in the UpdateProtocolManager transaction
- Choosing an XML standard cannot happen until we have defined the data elements needed for the transaction
- Need to also think about other data elements needed for the other options for this "UpdateProtocolManager" transaction
Add UpdateProtocolState(SubjectComplete) transaction
Introduce BRIDG (Biomedical Research Integrated Domain Group) as a standard to use with RPE
- Think of it in the same way as a content profile (CRD) for the transmission mechanism (RFD)
- caBIG
What needs to be done before 01/26/09-01/27/09 face-to-face?
- Discuss the wiki and Supplement Template-V7.1.doc IHE Supplement Template
- per Jason Colquitt: As a reminder the Word Template Supplement Template-V7.1.doc IHE Supplement Template is expected to be the document by which all profiles are working toward. If you could have your partially complete profile in this format for next week, this would make a consistent presentation, and would make review of the profiles easier.

01/26/09 QRPH Technical Committe Face-to-Face

Agenda
Discussed confusion of RetrieveProtocolDefList naming
- Is it a retrieve mechanism or a query mechanism?
- Beginnning of RPE would be the RetreiveProtocolDef transaction
- Remove and just leave one RetreiveProtocolDef
- Remove AgreeToParticipate transaction
- Daemon to provide a proposal at next meeting 02/05/2009
Remove EDC and EHR from RPE Flow Diagram
- Come up with more appropriate terms to use for real world entities. eClinical Research?
- Removed the names from the diagram
Split scheduling UpdateProtocolExeStep transaction into two different transactions
- UpdateProtocolExeStep(PatientScheduled) - Patient visits are scheduled
- UpdateProtocolExeStep(RecordPatientVisit) - Patient has came in for visit[n]
- Added to the diagram
Need a transaction for 'Study has been shutdown, what needs to take place as far as patient's state and protocolDef within EHR?'

01/27/09 QRPH Technical Committe Face-to-Face

Agenda
(quick list of notes, in case i forget to come back and add them)
- Define the possibilities of getting back a NACK from UpdateProtocolExeStep...(screen failed)
- Add prerequisite to UpdateProtocolExeStep for Enter (consent)
- Batch enter patientIDs into study?
- define transactions between enter and enroll (screening?) (RFD?)
- UPES(PatientIdentified) take out?
- screen failed message both ways?
- candidateID for EnterPatientRequest?
- ability for EHR to submit the SubjectID (Psuedonemized)?
- change name of UpdateProtocolExeStep to ExecuteProtocolStep?
- Research BPEL as the standard to use for the Workflow Management transactions
  - re-use workflow standards
  - resource - Karen (IBM)
- Does the profile need to be more generic so that it can be used for other workflows than just clinical research?
  - ProtocolManager to WorkflowManager?
  - UpdateProtocolExeStep to UpdateWorkflowStep/ExecuteWorkflowStep?
- Is every Friday at 1pm (est) a good time to meet or should we stretch it out to every 2 weeks for a couple of months...lots of work to do...
- Add additional use cases, such as the Cancer Registry's use case

01/30/09

Agenda
Review input/output data elements needed for the UpdateProtocolExeStep(EnrollPatientRequest) transaction
- Work will be needed from the eClinical side in order to define these data elements
- What data is needed from the EHR to successfully Enroll a subject into EDC for a study
- What data is available from the EDC to store within the EHR
[To be done after the input/output data elements are defined] Discuss XML standards to be used for message parameter supplied in the UpdateProtocolManager transaction
- Choosing an XML standard cannot happen until we have defined the data elements needed for the transaction
- Need to also think about other data elements needed for the other options for this "UpdateProtocolManager" transaction
- Introduce BRIDG (Biomedical Research Integrated Domain Group) as a standard to use with RPE
  - Think of it in the same way as a content profile (CRD) for the transmission mechanism (RFD)
  - caBIG
Go over Prerequisites/Dependencies
- How to handle this section? Dependency for the RPE profile or Dependency for each transaction?
- I think we need a dependency for each transaction
Open/Closed issues needs work?
Discuss additional transaction or use of current ones that may need to be needed in the flow diagram
- Add UpdateProtocolState(SubjectComplete) transaction
Landen updated the group on information about CRD CP discussion and RFD changes
Make RFD and RPE abstract patterns for workflow management
Use BPEL
- Landen to follow up with leads
- Possibly set up call with someone to discuss with the group
Removed a few meeting dates for the upcoming month. We will meet on 2/6, 2/20 and 3/6

02/06/09

Discussed confusion of RetrieveProtocolDefList as a transaction
- Is it a retrieve mechanism or a query mechanism?
  - It is a query mechanism
- Need to have a defined starting point for the RPE profile
  - That starting point will be the RetreiveProtocolDef transaction
- Discuss Proposal for the issue involving the RetrieveProtocolDefList transaction
  - Combine the RetrieveProtocolDefList transaction into the RetrieveProtocolDef transaction
  - The parameter passed for the RetrieveProtocolDef would be an XML structure for querying the ProtocolManager
    - For the use of retrieving a protocolDef from the ProtocolManager the query would be for a specific protocolDef
    - In the future this could be expanded to provide the ability to query on multiple parameters
      - Those mutliple parameters being anything included in the TDM
      - Including a way to request a list of protocolDefs
    - For now the protocolDefID needed for the RetreiveProtocolDef transaction would be supplied similar to how the formIDs are provided via RFD
  - This allows us to focus on the transactions from UpdateProtocolExeStep(EnterPatientRequest) to UpdateProtocolExeStep(EnrollPatientRequest)
- The RetreiveProtocolDefList transaction will be removed
- The parameter passed into RetrieveProtocolDef transaction will be an XML query structure
- For the use of retrieving a protocolDef from the ProtocolManager the query would be for a specific protocolDef
- In the future this could be expanded to provide the ability to query on multiple parameters (anything contained within the TDM)
- Including a way to request a list of protocolDefs
Removed EDC and EHR from RPE Flow Diagram
Split scheduling UpdateProtocolExeStep transaction into two different transactions
- UpdateProtocolExeStep(PatientScheduled) - Patient visits are scheduled
- UpdateProtocolExeStep(RecordPatientVisit) - Patient has came in for visit[n]
Items discussed at the 01/27/2009 IHE face-to-face meeting
- What are the reasons why UpdateProtocolExeStep(EnrollPatientRequest) would fail...(screen failed? any others?)
  - screen failed, study put on hold, enrollment complete
- Add prerequisite to UpdateProtocolExeStep
  - EnterPatientRequest - consent, meets pre-screening eligibility criteria before consent
  - ScreenPatientRequest - patient entered
  - EnterPatientRequest - screening complete, meets screening eligibility criteria
  - Need to alert ProtocolManager that patient doesn't want to be a part of the study from ProtocolExecutor
    - This will be handled with the RecordPatientVisit transaction and an RFD form to withdraw the patient from study
- Do we need the ability to batch enter patientIDs into study?
  - Can this be handled with the UpdateProtocolExeStep(EnterPatientRequest) transaction?
  - Not for now…but allow structure in the future...will add to the EnterPatientRequest transaction
- Define transactions between enter and enroll (new screening transactions vs RFD)
  - Have added the UpdateProtocolExeStep(ScreenPatientRequest) transaction.
    - Keep generic
  - Can RFD be used for these transactions instead of the extra transaction?
    - Advised to use RFD in these scenarios. Very similar to doing clinical study care
    - Added to RPE Flow Diagram
- UpdateProtocolExeStep(PatientIdentified) take out?
  - Is there a need to let the ProtocolManager know that a set of patients have been identified against the inclusion/exclusion criteria before that ProtocolExecutor attempts the EnterPatientRequest?
  - Leave in diagram, but take out the UpdateProtocolExeStep to ProtocolManager

02/20/09

Items discussed at the 01/27/2009 IHE face-to-face meeting
- Change ScreenPatientRequest to
  - PatientScreeningVisitsScheduled
  - RecordPatientScreeningVisit
  - Added to RPE Flow Diagram
- How will screen failed message be handled
  - Will the ProtocolExecutor know that the patient failed screening or only the ProtocolManager?
  - Is there a need to handle both ways from ProtocolManager and from ProtocolExecutor?
    - The logic for screenFail is done by the ProtocolManager
    - ProtocolManager transaction to ProtocolExecutor to say that screenFailed
      - Use AlertProtocolState transaction
      - The ProtocolExecutor will also get this response from the EnrollPatient transaction
- Changed PatientScheduled to PatientStudyVisitsScheduled in the Flow Diagram
- What should be the Identifier be called returned from EnterPatientRequest?
  - CandidateID/ScreeningID
  - Will use CandidateID
- Discuss the way Identifiers will be handled from the Enter transaction to the Enroll transaction
  - Is there a need for the ability of an EHR to submit the SubjectID (Psuedonemized) in the EnrollPatientRequest execution step?
    - This can be handled as part of the submission data in the EnrollPatientRequest execution step
    - EnrollPatientRequest should allow for a CandidateID and SubjectID to be sent from the ProtocolExecutor to the ProtocolManager
  - Need a way to relate the CandidateID to the SubjectID
    - ProtocolExecutor can send the CandidateID as part of the EnrollPatientReqest
  - ProtocolExecutor needs to get subjectID from a randomization system which is separate from the ProtoocolManager
  - ProtocolManager provides subjectID as return of EnrollPatientRequest
Download from Diane Wold involving the different standards
- Complete Trial Design work
  - add to it other protocol information
  - UML model
- BRIDG
  - Information model
  - Domain analysis model
  - Bridgmodel.org
    - Download releases of the model
    - Enterprise architect
    - Free reader - to browse
  - Stakeholders
    - CDISC
    - HL7.RCRIM
    - NCI - caBIG
  - Scope
    - regulated clinical research
    - Protocol driven research
    - Any trial that has to be reported to FDA
  - Any group from stakeholders that has a need for domain model
- Relation between BRIDG and TDM
  - TDM developed within CDISC SDTM standard
    - Information represented in tables (Inadequate)
  - TDM moved into UML modeling
    - Pete Villers working on XML model
- HL7v3.Study Design (FDA wanted HL7)
  - Going to ballot for draft standard for trial use in April/May
- HL7v3.Study Participation (FDA wanted HL7)
  - Who is in the trial
    - Investigators
    - Sites
    - Subjects (not individual level)
    - Labs
    - IRB
  - Some relation to TDM, not a lot
  - Possibly used for Enter and Enroll?
- HL7v3.Subject Data (FDA wanted HL7)
  - Clinical Trial for the results
  - Built in such a way to relate back to planned activity
  - Possibly used for Enter and Enroll?
- Study Design related to TDM
  - HL7 and TDM are 2 different implementations of the same thing
- Clinical Research Filtered Query Service
  - Subject looking for a clinical trial would want to see a repository for registry to see appropriate trials
    - RetrieveProtocolDef transaction?
  - Trial looking for subjects
  - Interested mostly in elligibility criteria

03/06/09

(Daemon, Landen, Dan Levy, Diane Wold, Robert Barr, Chris Connor)

Should we make RPE an abstract pattern for workflow management rather than specific to clinical research
- ProtocolManager to WorkflowManager?
- UpdateProtocolExeStep to UpdateWorkflowStep/ExecuteWorkflowStep?
- Do not make abstract at this time
Should we address all transactions and not just the Enter through Enroll transactions?
- We will get to as many transactions as possible. Attempting them all.
- As much as possible by the time Vol II is due...and implement and do the rest next year
Are there only two actors?
- Should there be a ProtocolDefManager and ProtocolStateManager(The receiver of the UpdateProtocolExeStep)
- Would there be separate systems that manage the ProtocolDef and the ProtocolState?
- The ProtocolManager actor will be split into two seperate actors...The ProtocolDefManager and the ProtocolStateManager
  - ProtocolDefManager
    - Site Involvement
    - Approved as site for a study
    - AmendProtocolDef
  - ProtocolStateManager
    - Just Patient Involvement transactions
    - AlertProtocolState
    - Add RetrieveProtocolDef transaction to ProtocolDefManager

03/20/09

(Daemon, Landen, Dan Levy, Mark Arratoon)

Discuss Upcoming meeting dates
- We will skip 3/27 and 4/3 meeting to prepare for HIMMS
- We will resume on 4/10 with the Agenda below
Ana Esterich (co-chair QRPH planning committee)
- Needs 4 slides for new profiles for HIMMS
  - Landen to formulate a plan and pass along to Daemon to add any additional details and then forward to the RPE group
Come up with simple data definitions for Mark for the transactions...will not be any standard...

HIMMS is 4/3 - 4/8...we will not meet on these dates

04/10/09

Many were not able to be on the call. So we have decided to re-focus on 04/17/09.
We will try to set up a web-ex so that Mark Arratoon may go over what he has done relating to how BPEL could be used within RPE
Mark Arratoon
- demo using oracle BPEL engine
change transactions to be specialized rather than the generic UpdateProtocolExeStep
show a grouping of the transactions for the "Patient Involvement" workflow of RPE
webex has been set up. If you haven't received invite, I need to know.

04/17/09

'Attendees - (Daemon Whittenburg, Chris Connor, Dan Levy, Ed Seguine, Gary Walker, Jaime Lucove, Jane Griffin, Jeff James, Landen Bain)'

Mark Arratoon to discuss what he has done with BPEL
- Mark has been using the RPE Flow Diagram to build a sample BPEL message
- Mark will review and discuss BPEL and how it can be used in the RPE Profile
  - Does the ProtocolExecutor need to know about the steps or can the steps just be executed based on type?
    - The ProtocolExecutor will handle the workflow based on a .bpel workflow file
  - Does the ProtocolManager know about the steps and the ProtocolExecutor learn about the steps?
    - The steps will be defined by the .xsd and .wsdl which both the ProtocolManager and ProtocolExecutor will reference
Should we remove the following three transactions for now so that we can concentrate on the intent of the profile?
- AgreeToParticipateInProtocolDef
- SubmitProtocolDefApproval
- SubmitProtocolDefRegulatoryDocumentation
Discuss XML Schema Definitions (xsd) for each actor
- Defines objects to be used in the interactions between the actors.
- ProtocolStateManager Schema

Back to RPE Profile

RPEMeetingNotesArchive

03/20/09

04/10/09

04/17/09

Navigation menu

Search