RPEMeetingNotesArchive

From IHE Wiki
Jump to navigation Jump to search

Back to RPE Profile


Decemeber 2008

12/12/08

12/19/08

January 2009

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?

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


February 2008

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

March 2008

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


April 2008

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)

  • 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
  • We will remove the following three transactions for now so that we can concentrate on the intent of the profile?
    • AgreeToParticipateInProtocolDef
    • SubmitProtocolDefApproval
    • SubmitProtocolDefRegulatoryDocumentation

04/24/09

Attendees (Daemon Whittenburg, Jason Rock, Gary Walker, Robert Barr, Jeff James, Dan Levy, Jamie Lucove, Mark Arratoon)

  • We are working on transitioning meetings from GSK to IHE...(Continue to use GSK numbers above until I confirm the IHE webex being set up)
  • Briefly go over the items that we have left to complete before the face-to-face.
  • QRPH Tech May 4-6 Face to Face Agenda
  • Discuss standards to be used for the messages being passed between actors
    • Jason Rock - HL7v3 Study Design, Study Participation, Subject Data discussion update
    • The HL7v3 messages are in draft standard
    • HL7v3 Study Design(would be used within ProtocolDefManager)
      • Directly overlapped with ODM
      • Contains eligibility criteria
      • Contains workflow
      • Can handle "if in treatmentA here are activities for treatmentA"
      • Contains what will happen in a clinical trial
    • HL7v3 Study Participation(would be used within ProtocolStateManager)
      • Contains elements for Subject
      • Contains elements for Investigators
      • Contains elements for Sites
      • Handles subjects in which sites
      • Handles IRB approval
      • Describes who are the patients in the study
    • HL7v3 Subject Data (would be used within ProtocolStateManager)
      • Contains the data within study
      • Contains data elements for scheduling
      • The Care Record from the HL7 Care Provision was used
      • Contains the target of activities
      • The difference with Care Record is
        • In a Care Record message the role is patient
        • In Subject Data is subject
      • Regulatory Submissions
    • TDM experts to discuss the benefits of using TDM and how it relates to the HL7 Study Design message
      • How will using TDM be affected by the FDA using HL7v3 by 2012?
      • TDM can be used for ProtocolDef, but not state management...
        • At minimum will need to look at using HL7v3 Study Participation and Subject Data for the state messages...
      • TDM inclusion/exclusion defined by using ODM condition definition construct


May 2008

5/1/09

  • We are working on transitioning meetings from GSK to IHE...(Continue to use GSK numbers above until I confirm the IHE webex being set up)
  • Discuss the RPE Supplement Document
  • Notes
    • Attendees (I may not have caught all): Diane Wold, Daemon Whittenberg, Mark Arratoon, Dan Levy, Gary Walker, Chris Connor, Dave Gemzik, Jeff James, Robert Barr)
    • Since Diane had difficulties with the document (though others didn't), Mark acted as presenter in the web meeting. The document was not updated in the meeting, but these minutes document updates that will be needed. Main message of this meeting: Daemon needs your help in reviewing and completing this document. Please e-mail suggestions and comments to him.
    • The QRPH F2F is May 4-6, and the agenda includes RPE at 1:00-3:15 on May 4. Contact information was not included in the agenda as of the meeting on Friday. For the webex, it should be possible to go to the general IHE webex site (the one used for this meeting), and find the QRPH meeting in the calendar there.
    • The document is divided into Volume 1, which is text-based, and Volume 2, which includes more technical detail. It includes comments in red, which indicate material that will be needed by the May 18 deadline for submission. Some of this material will be filled in at the F2F meeting session, or on the advice of people Daemon will talk to at the meeting.
    • The Glossary in Volume 1 probably needs to be beefed up; Jamie volunteered to help with this, but other input is welcome. We clarified that the only terms needed are those that are particular to the RPE profile.
    • Daemon explained that the X in "Section X" will be replaced with a number issued by QRPH. Similarly, the Y placeholder will be replaced.
    • The document currently contains the Actions/Transactions diagram developed at these meetings. There is a standard format for these diagrams used by IHE, and that will be added to the document. The currrent diagram may also be retained.
    • Currently, all rows in the Actions/Transactions table are marked as R (required). At the meeting, these will probably be questioned, and some parts may be downgraded to R2 (required if available) or O (optional).
    • Pre-requisites are mentioend in Volume 1, but need to be incorporated into Volume 2, as well.
    • Error-handling needs to be added.


5/8/09

(Attendees - Daemon Whittenburg, Diane Wold, Ilya Sterin, Jason Rock, Jeff James, Landen, Mark Arratoon, Matt Riley, Robert Barr, Sara Taillon)

  • We will be using the ihe.webex.com for future meetings
  • Discuss the RPE.xsd schema
    • Will re-organize an have a step-by-step process for walking through the RPE schema on May 22nd
  • Why in PORT_MT100001UV.Study is there only 2 subjects and 2 performers and not N?
  • Why is PORT_MT100001UV.Subject1 not represented PORT_MT100001UV.Study in which appears to be the only subject type having a natural Person?
    • PORT_MT100001UV.Subject1 may not refer to the subject that we were thinking of in RPE
  • TODO from 5/1/09 meeting
    • Daemon explained that the X in "Section X" will be replaced with a number issued by QRPH. Similarly, the Y placeholder will be replaced.
    • The document currently contains the Actions/Transactions diagram developed at these meetings. There is a standard format for these diagrams used by IHE, and that will be added to the document. The currrent diagram may also be retained.
      • Need to use the IHE diagram
    • Currently, all rows in the Actions/Transactions table are marked as R (required). At the meeting, these will probably be questioned, and some parts may be downgraded to R2 (required if available) or O (optional).
      • Allow public comment to handle this
    • Pre-requisites are mentioend in Volume 1, but need to be incorporated into Volume 2, as well.
    • Error-handling needs to be added.


5/15/09

  • Is the RPE team confortable with the supplement going to public comment in 2009?
    • Jason Colquitt (co-chair QRPH) to be on the call discuss options
      • Do we want to push it in for this round of public comment (June 1st - July 1st)
      • Possibility to post-pone public comment a month. Jason wants to know expectations of the RPE group
        • Chose this option, with follow-up call to determine actual date
      • Do we want to work on it more for the next year and take it to public comment then?
        • Effects?
          • Will not be released for trial implementation in 2009
          • Will not be tested at Connectathon 2010
  • Need to discuss issues brought up by Mark Arratoon
    • Made it through the first issue, with a length discussion of where BPEL would fit in
    • Determined that BPEL would be the focus of the next phase of the RPE work

5/22/09

  • Discuss supplement document due date
    • We will submit what we have in the supplement document for public comment.
      • Need to add technical references (WSDL, XSD). E-mail sent out for where they go within the document.
    • We will continue to add to the supplement document and also submit those changes as public comments.
    • The comments will be reviewed by IHE-QRPH in July
    • The supplement document will go out for trial implementattion
  • Discuss items brought up by Mark Arratoon
    • Regards the current transactions and schema definition exercise: I wanted to step back and clarify the intent of each operation and then look at the related models out there:
    • RetrieveProtocolDef
      • The current query argument "may" be able to reuse the HL7(v3) Query type that I saw but wouldn't we be returning a SET of possible protocol definitions?
        • We do need the ability to return a SET. This transaction has a lot of work needed and would probably be an hour discussion one Friday. We may have to keep it simple for now and expand later. Simple being, pass a ProtocolDef identifier in the request and get a ProtocolDef as a response.
      • And what should be used for the protocol definition type itself? CDISC or HL7 related study definition types?
        • Since we have only received schemas for the HL7 flavor, for now we should reference the HL7v3 Study Design. We can expand this with options in the profile later if needed.
    • EnterPatientRequest
      • Also looks like we could just use a (unique) study ID vs. the full study type here
        • I agree, the PE and PSM should be able to identify the protocolDef base on the studyID
      • Currently we only have 1 patient/study combination - do we need to modify per supplement to allow a list of patients to be implemented per study? (This presumes we are entering against the 1 study at a time.)
        • The first cut was just to provide a mechanism (for understanding), but yes I agree that we should provide the ability for multiple patient’s to be entered into a given study in a batch mode.
        • I’m not sure about doing multiple studies. This would be interesting, I’m just not sure practical.
      • And if we do latter should we modify the workflow to loop for the N patients in the study?
        • Yes, we should loop if we have multiples.
    • PatientScreeningVisitsScheduled
      • What does the ProctolStateManager (PSM) need to know here? I.e., does the PSM (EDC) need to know the actual schedule? Or is it just interested in the fact that the visits have been scheduled?
        • From previous discussions, I believe it needs to know the actual schedule. This way the EDC system can monitor progress of a given study. If some information didn’t come in on a set visit, then the PSM may need to send an alert to the PE that the state needs to change (possibly start over the study or remove subject from study). Once again, just my understand and others may have better answers.
      • Is there any validation or checking of this visit schedule against protocol defn requirements?
        • We do not have or require this in the RPE Profile, however, I’m sure this is an activity that the PSM would need to do. I’m not sure how we represent this?
      • What provision is there in the HL7 (or CDISC) study types for attribution of (time-related) schedule data?
        • This would be a Jason Rock (HL7) or Diane Wold (CDISC) question.
    • RecordPatientScreeningVisit
      • I presume this just records the data captured at the screening visit, but again what checking does the PSM do if any against protocol requirements? Should rejection or warnings be possible?
        • We need more discussion about what takes place during recording a patient’s screening/study visit. The idea here was to use RFD to retrieve a form and submit some extra information that was not recorded within the EHR. However, because of the asynchronous and cross browser behavior of RFD, we left a transaction to allow the PE to submit a message stating what was being done. I’m still unsure exactly what this is, but see the need. This needs more discussion as well.
        • Another related subject to discuss here, is how the PE gets the “Interface” information related to RFD based on the ProtocolDef. This (RFD Interface Link) information is neither contained within the HL7v3 schemas nor the TDM. This is possibly going to require another actor for retrieve RFD Interface specs for a study. Still more discussions required.
    • EnrollPatientRequest
      • Again maybe we could use just the study ID here as per EnterPatientRequest?
        • Same as EnterPatientRequest
      • If we support a patient list for latter I presume we may still want to enroll one at a time withina big outer loop?
        • I could see batch enrollment. However, I’d prefer that the group agree on this.
    • PatientStudyVisitsScheduled
      • Similar comments to PatientScreeningVisitsScheduled
        • Same as PatientScreeningVisitsScheduled
    • RecordPatientStudyVisit
      • Similar comments to RecordPatientScreeningVisit
        • Same as RecordPatientScreeningVisit
  • Walk through the RPE schema and the HL7v3 StudyDesignParticipationSchemas.zip schemas and discuss each Type that is being referenced for each transaction
  • Some open questions
    • Why in PORT_MT100001UV.Study is there only 2 subjects and 2 performers and not N?
    • Why is PORT_MT100001UV.Subject1 not represented PORT_MT100001UV.Study in which appears to be the only subject type having a natural Person?
      • PORT_MT100001UV.Subject1 may not refer to the subject that we were thinking of in RPE
    • Visit is represented by an encounter

June 2008

6/5/09

(Robert Barr, Chris Connor, Daemon Whittenburg, Diane Wold, Jeff James, Mark Arratoon)

  • Discussed Study Design schemas

Back to RPE Profile

Retrieved from "http://wiki.ihe.net/index.php?title=RPEMeetingNotesArchive&oldid=34071"