Page History

...

• Cohort and Stratum are being populated in OPEN through a group lookup window that is being populated with the Cohort and stratum that was assigned to the patient at screening.
• No curation activities are required or should be managed for the Cohort & Stratum CDEs/ fields. These are non-enumerated fields that should be used as already specified on the PMI EC Template.

Why are prior treatment fields included for this trial when these are all treatment naive patients? Are you expecting them to enter prior treatment for other cancers if they’ve had any?

• On Tier 1, all participants must be treatment naïve. There are even in protocols for Tier 1, patients can have taken some therapy as long as it’s a minimal dose.

ComboMATCH Questions

...

• NCI still currently working on re-registration requirements.

MeyloMATCH Questions

Why are the topography, morphology, and grade fields all required? They are mostly not applicable to the disease for this trial, especially grade. Seems like that would be “N/A” for all patients. If they must enter topography and morphology, can we at least narrow down the lists to the few things that are applicable?​

• SWOG can decide if they want to collect these questions on their MM Screening Protocol EC form in the caDSR II during form build activities. This field will be marked as optional in OPEN:  If data is present, it will be pushed.​
• The 'Morphology' field is required for the MyeloMATCH protocols, specifically "9860/3"; SWOG can default the value for this field in OPEN.​

OPEN/Rave Questions

It seems none of us at SWOG have the right Rave roles to upload the central study ALS. It says we can’t create a new Project in Architect without creating them in iMedidata first, like we do when we build a new study. Can you find out what RAVE role CTSU uses to upload central study ALS?

• Going forward Central Study xGlobal CFs-Matchbox will be used for PMI trials, and if it is created in iMedidata it will allow you to invite users and restrict access for PMI central study via iMedidata. SAE integration central study is also in iMedidata
• Regarding your question about permission to create Project directly in Rave, the user should be assigned a Security Role that has ‘Create’ Action flag checked for Architect Project in Core Configuration.

How will the screening ID, cohort, and stratum fields be validated on the treatment trial OPEN forms to ensure the correct responses were entered? Will these be auto filled on the form in some way, or will there be an edit check that needs to be configured for these fields?

• Configured group look up windows based on the screening patient ID that was entered.
• For crossover – Step 2. In OPEN they would need to create a step 2 enrollment or enter patient ID of step 1 of the treatment protocol.

We also wanted to verify which form these fields (Screening protocol ID, Screening participant ID, Cohort, Stratum) were expected to be populated in Rave. Alliance does not currently use the Eligibility Checklist form in Rave so we want to make sure we understand where these fields are expected. I believe Shauna Hillman has been working with others regarding some Rave questions, but I wanted to note we still need this information from the OPEN form processing side as well. We need to make a code change on our end to send this information to Rave so we need this information as soon as possible to be ready by the OEWG deadline.

• Groups are expected to populate the screening protocol ID, screening participant ID cohort and stratum fields in Rave.

 Will we be receiving an ALS for the Rave Eligibility Checklist Form?  This is a new form for Alliance. 

• There is no ALS for the Rave EC Template. We are using our normal EC template process. The form is built in caDSR II based on our template and that will provide you the form OID.
• The four fields you will need for that form are:
  • Screening Protocol ID
  • Screening Participant ID
  • Cohort
  • Stratum