PhUSE Working Group RGvD - Meeting Minutes 2015-06-23

From PHUSE Wiki
Jump to: navigation, search

Present:

  • Sandy (Astra Zeneca)
  • Kiran (Roche)
  • Wei (Gilead)
  • Cathy (Novartis)


Agenda:

  • Admin/Updates
  • Finish SDRG template section 3 and discuss section 4 and appendices


Admin/Updates:

  • Sandy was asked to submit a new project request for this topic. It is currently with DJ (head of Optimizing Data Standards group) for review and will be submitted through the PhUSE site once approved. The PhUSE leadership team will review and determine where this best fits (under Best Practices or possibly up a level).
  • Discussed changing the name of the working group to be less wordy. Sandy suggested “Best Practices for Metadata Documentation” which is what she used in the new project request form. All were in agreement.
  • We are holding off on the Wiki site until we are an officially sanctioned group and know where we fit within the teams.
  • Sandy attended the PhUSE webinar held after our last meeting and there was a very relevant presentation from the FDA on the reviewer’s guide. We reviewed some of the slides/notes to keep in mind during our discussions. Sandy will distribute the slides for everyone to review in more detail.


SDRG discussion:

  • Section 3.1/Overview:
  • In light of the FDA presentation at the PhUSE webinar, we recommend to include descriptions of how treatment-emergent period is defined (if included in SDTM) and all reference start dates and how they are used (particularly for efficacy analysis) in the additional content of interest and in the specific related domain summary sections 3.3.x.
  • No other items for Section 3.
  • Section 4.1/Conformance Inputs:
  • Within the 1st question, note if there were any datasets which were not evaluated in OpenCDISC and why (e.g. datasets which were not intended to be CDISC-compliant due to using legacy standards or containing reference data only).
  • For version information, include whether using Community or Enterprise if using newer versions of OpenCDISC as the extent of checks may differ. If using Enterprise, should include the quality fit score and provide any explanation related to it.
  • For sponsor-defined validation rules, if a list is provided, suggest to include as an appendix and hyperlink to it.
  • Section 4.2/Issue Summary:
  • Most companies only include the Errors and Warnings.
  • OpenCDISC bugs may be documented individually or in a general summary, depending on extent of occurrence.
  • Explanations should be detailed and data-specific according to FDA presentation. Include examples of ‘good’ and ‘bad’ from the FDA presentation.
  • If there are issues caused by data issues that were not fixed, this should be documented accordingly. Note what the data should be, why it was not fixed, and any impact assessment that was done.
  • Does Count column need to be included in table? Counts can differ from FDA or due to typos. Not every company includes it. Can we check with FDA to see if this is important information?
  • Section 4.3/Additional Conformance Details:
  • Only include this if the information is meaningful. If sponsor checks identified some items but were deemed low impact/unimportant and decided not to change the data, this may not be information needed by the FDA.
  • Appendix 1 is straightforward and typically included.
  • Appendix 2 is not typically included.
  • No other standard appendices suggested.
  • Other question: do companies submit define.pdf along with define.xml?
  • Yes, most do. It seems to be ‘encouraged’ by the FDA, but is not required.
  • When included, typically don’t include bookmarks/hyperlinks as it is intended to be used for printing purposes.


Next meeting: 2015-07-07