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

Back to RPE Profile