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

Back to RPE Profile