RPEMeetingNotesArchive
- 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
- ProtocolDocument – aka ProtocolDoc
- ProtocolDesign – aka ProtocolDesign
- 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
- Agenda
