RPEMeetingNotesArchive: Difference between revisions
Jump to navigation
Jump to search
Dwhittenburg (talk | contribs) No edit summary |
Dwhittenburg (talk | contribs) No edit summary |
||
| Line 26: | Line 26: | ||
**Determined that only the "UpdateProtocolManager(EnrollProtocolRequest)" Transaction would be worked for the next publication of RPE. | **Determined that only the "UpdateProtocolManager(EnrollProtocolRequest)" Transaction would be worked for the next publication of RPE. | ||
***<font color='green'>Currently the focus as well as documenting the other items involved in the RPE use case</font> | ***<font color='green'>Currently the focus as well as documenting the other items involved in the RPE use case</font> | ||
*'''01/16/09''' | |||
**<font color='darkred'>Agenda</font> | |||
***<font color='darkred'>Review RPE wiki</font> | |||
***<font color='darkred'>Define input/output data elements needed for the UpdateProtocolManager(EnrollPatientRequest) transaction</font> | |||
****<font color='darkred'>Work will be needed form the EDC side in order to define these data elements</font> | |||
***<font color='darkred'>Discuss XML standards to be used for message parameter supplied in the UpdateProtocolManager transaction</font> | |||
****<font color='darkred'>Choosing an XML standard cannot happen until we have defined the data elements needed for the transaction</font> | |||
****<font color='darkred'>Need to also think about other data elements needed for the other options for this "UpdateProtocolManager" transaction</font> | |||
**Define the difference between Protocol and Protocol State. | |||
***ProtocolDefinition | |||
***ProtocolInstance/ProtocolState | |||
***<font color='darkred'>From the Trial Design Model (TDM) - 1.2 Separation of Concerns: Trial Design vs. Trial Execution?</font> | |||
***<font color='darkred'>Three have been proposed...will add to agenda for next meeting</font> | |||
***#<font color='darkred'>ProtocolDocument – aka ProtocolDoc</font> | |||
***#<font color='darkred'>ProtocolDesign – aka ProtocolDesign</font> | |||
***#<font color='darkred'>ProtocolDefinition – aka ProtocolDef</font> | |||
***New name for UpdateProtocolManager based on this decision? | |||
**Add AmendProtocol transaction from ProtocolManager to ProtocolExecutor | |||
***<font color='green'>Added an AmendProtocolDefinition transaction to the RPE Flow Diagram</font> | |||
**Add EnterPatient/PatientInScreening transaction | |||
***<font color='green'>Added an UpdateProtocolState(EnterPatientRequest/ScreenPatientRequest) transaction to the RPE Flow Diagram</font> | |||
**Add FreezePatient transaction | |||
***<font color='green'>Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram</font> | |||
**Add LockPatient/SignOffOnPatient transaction | |||
***patient is done | |||
***<font color='green'>Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram</font> | |||
**Add Unfreeze/Thaw transaction | |||
***<font color='green'>Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram</font> | |||
**Add UnLock transaction | |||
***big issue...more auditable | |||
***<font color='green'>Added an AlertProtocolState(FreezePatient, Unfreeze/Thaw, LockPatient/SignOffOnPatient, Unlock) transaction to the RPE Flow Diagram</font> | |||
**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 | |||
[[Retrieve_Protocol_for_Execution|Back to RPE Profile]] | [[Retrieve_Protocol_for_Execution|Back to RPE Profile]] | ||
Revision as of 14:04, 23 January 2009
- 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