PhUSE Conference March 19th and 20th

Standards Implementation Issues with the CDISC Data Models Meeting Minutes

Topic / Discussions
Kick off Presentation / Review of Working Group 4 kickoff presentation (see wiki for presentation) http://www.phusewiki.org/wiki/index.php?title=Standards_Implementation_Issues_with_the_CDISC_Data_Models)
PhUSE Wiki / The PhUSE wiki website contains information on each working group. Please refer to the folder for Working Group 4 for information about this group. If you are new to the wiki you can use the link on the home page “ If you are new to wikis you might want to check out the help section”
www.phusewiki.org
Listbox / Each working group will have their own mailing list through Listbox (an online service). This will provide an automated way for people to subscribe/unsubscribe and receive information from the group leads instead of trying to manage this through spreadsheets and e-mails. The link to subscribe to the mailing list along with instructions is on the PhUSE Wiki website. Please remember to check your Spam folder for emails as each company may have different computer system protections which may put the emails from Listbox in Spam.
Structure for the meeting / ·  Discuss 2 topics. One for today and one for tomorrow. Break into two groups for discussions.
·  Will open up parking lot to collect issues from group. If you raise an issue it is important that you following the issue through to work on that issue for resolution.
Review of Issues List (List is on the PhUSE wiki) / ·  Participant question: REV-050 – why didn’t this go to the validation group?
Ø  Answer: Some issues did get dropped off per other working groups however validation is an implementation issue so will stay in this group.
·  Participant question: It seems all of the Issues List is regarding SDTM. I thought this group was for all CDISC standard implementation issues?
Ø  Answer: Working Group 4 decided to focus on SDTM as SDTM is more advanced than others (ADAM, SEND) so implementation issues are known. We do need ADAM and other standard issues identified in this group. There is no other group discussing implementation issues so this is the right working group to raise issues and come up with ideas for resolution. Please bring forward all issues. We’re looking at documentation so this links in to all SDTM, ADAM, SEND etc. We could have separate working groups for ADAM, SEND etc. to focus on these areas of interest.
·  Participant Question: How was high/med/low defined?
Ø  Answer: Per co-leads decision.
This group cannot dictate to policy or speak to CDISC. FDA is interested in technical issues with technical solutions. This is what Working Group 4 will focus on.
·  Participant Comment: IND 020 Stats programmer vs. clinical programmer amount of knowledge of SDTM isn’t true for all companies. Some companies can have good education to both.
Additional Comments from the group after review of Issues List / REV-030: Issues with some of the points on the list stems from SDTM. Determining what is extra data comes down to what is the definition of SDTM. Is it everything that was collected (tabulated data) or is it data that was used in analysis data?
Ø  Answer: There are certain data which FDA does not need to see (example, patient initials as stated in a presentation from FDA earlier in the day).
Fred Wood – A lot of issues are going to be addressed by the SDS team. Which will stay with SDS and which will stay with Working Group 4?
Ø  Answer: The co-leads will keep in contact with the SDS team as well as the CDISC and ADAM teams to ensure there are no overlaps. However, remember Working Group 4 will focus on known issues and how to address these issues either on FDA side or Industry side. This working group will come up with proposals to be discussed with FDA before being implemented.
·  Comment: SDTM was meant for tabulation data. There are some standard related issues, some communication related issues, some data management related issues based on the issues list. Communication of efforts is going to be the biggest to work on this year.
Working Group 4’s focus moving forward / The work products this working group will focus on are: White Papers, Use Cases, Data Guide.
Ø  Fred Wood - SDS will make a comment tool to comment on SDTM instead of completing an excel sheet. This group could help for SDS to send comments to for feedback.
v  Participant Comment – Maybe good for this working group to do a white paper to identify the issues for sponsors to know how to get around them.
v  Participant Comment – I like the idea of data guide. Not just for SDTM but for ADAM. To make decisions of what should be included.
Additional Comments from FDA sponsors / Ø  Steve Wilson: When we started down this path we looked to see what is holistic. 2004 was victory for FDA accepting CDISC. When you do a protocol you think of standards.
Ø  Bob O’Neil: Statistics Advisor FDA – you have people who review data for submission and those who get data ready for review. The culture of the sponsor has to be to have all the right people in the room (not just data managers). You may not have reviewers see the actual patient data. We all need a game plan for studies going outwards. Every study needs a a safety and efficacy analysis. You may have a product that is approved and FDA has a question where sponsor will need to go back and look at the data for last x amount of years. It all comes down to how is the industry going to use the data and how is the FDA going to use the data. This (standards) isn’t just a data management issue. This is a bigger issue and Working Group 4 will need to communicate with the other working groups. Medra can hide data depending on how it is grouped/split. We need to focus on how to design studies and come up with standards over the next 10, 20 years etc. Diabetes area FDA says need to rule out cardiovascular risk of x amount of patients. Industry can do this with a large trial or smaller trials which pick this up and can analyze for this. Modern drug development needs to be where companies think ahead of what is needed from the early phase studies all the way to the later phase studies. There is a demand to repurpose the data. Collect data so it can be reused for further analysis.
FDA – We don’t want to call it reviewer’s guide since there is a reviewer’s guide out there already.
Definitions / Ø  SDTM:
-  CRF
-  Tabulation
-  Hybrid
Ø  WG4 Work products:
-  White papers
-  Use Cases
-  Best Practices
Ø  Data Lifecycle
Ø  Data Guide
Day 1 Breakout Session
Data Guide/Reviewer Guide: What should be included?
Scope: Errors between defined.xml and SDTM are documented in a guide for FDA. Why not have a fuller label? Why not have a comment line? Custom name, why was it created? It might be better in a data guide vs. define xml.
·  Suggestion to create one guide document for SDTM and one for ADAM. SDTM has descriptions of domains explaining where data is in the domains. Would be good to add to a guide document details for variables where they are located for traceability. This is also important to do for Adam.
·  Good to alert CDER/CBER reviewer on known issues in a guide document (example, start date greater than end date).
·  Should data guide include what version of SDTM was used? Similar to documenting version of Medra? Will this be duplicate data as version numbers are documented but could be hard to find for reviewer?
·  What format will the guide we create be in? Recommend pdf. Xml so it’s machine readable.
·  There is a need to lay out what the Data Guide will contain and everything else is source.
·  Would need to define what is in define xml and what is in the data guide.
·  When should a Data guide be created? At beginning of study when SDTM is created? At end of study when closed as all protocol changed have been incorporated in the eCRF and there is no going back? Group feels it is better to create at the beginning of the study. Many times there are changes in staff working on studies and information regarding decisions made is lost. Better to document this on an ongoing basis to eliminate missed information or trying to put the pieces together. It is important to set expectations.
·  FDA – if you give a visual of the study design then give the history of the study (we used this version, study started in ….). This background information is useful. If include a lot of tabulation data then this may not be reviewed fully by FDA. If the guide document is too long it’s less valuable. If too much tabular data this is a turn off to the FDA reviewer.
·  CDISC validation tool is helpful to FDA reviewer. In a paragraph or less if Industry can indicate importance of validations which failed this is appreciated by the FDA reviewer.
·  Comment that companies put effort in reviewer’s guide during submission which is detailed however FDA reviewer may not fully review the data guide. FDA reviewer may ask company questions which the answers are captured in the data guide. Need to show importance / raise awareness to FDA of the data guide.
·  Need trust. Many CDISC errors fire incorrectly. What should be included of errors in the data guide? Can this be in a table or in a data guide.
·  Trail design duplication – consistency can become an issue.
·  If only submitting partial datasets should include reasoning in data guide
·  Case report form completion guidelines explained in data guide by one company. Is this something which should be included?
·  Maybe it would make sense to submit CRF guidelines with annotated CRF.
·  FDA – a piece not documented well is adjudication – something that is changing or altering the data that is not explained anywhere. How data was derived for analysis etc.
·  Explanation of flags on the database
·  Should screen failures be included in guide.
·  EX – how you define exposure included in data guide.Rel rec / sub qual – is this documented in data guide? For one company it is in the annotated CRF. FDA said it would be nice to explain the related relationships between domains. FDA would be good to have.
·  Data not coming from the CRF – something coming from exterior try to explain where it’s coming from (ex. Lab data).
·  Need to define what is too much and what is too little to include
·  Should permissible data not used (or used by not needed for analysis therefore not included in SDTM) be documented?
·  Mapping for controlled terminology? Maybe it would be good to share how each other handle this and come up with a prefer way to handle this in SDTM.
·  TLF – ask CROs to annotate the shells with variables they used.
·  Include in guide an explanation of any problems with internet explorer etc. and if there are any known technical issues.
Day 2 Breakout Session
Collection of data – what shouldn’t be included in SDTM submissions?
Important Note: The goal of this session was to offer suggestions for clinical database content that might be acceptable to omit from a submission-ready database. None of these suggestions has been reviewed or approved by FDA!
Scope: Make a list of what data elements could potentially not be included in SDTM submissions and present to FDA for approval.
·  Prompts whose only function is to prompt further questions. Example: If yes… etc.
·  “Not Done” is a bigger topic but would be good not to submit if wasn’t done.
·  EDC forms whose function is to trigger additional forms
·  Exposure data where dose = 0 but reason not given is on the CRF. Shouldn’t this be submitted? This is currently not submitted but feeling from the group is it should be submitted.
SDS group is working on this.
·  PI signature.
·  If form is blank
·  Screen failure data, Pre exposure AEs?
·  Data that has redundancy. Example, central lab data. This is for records for labs where there are no results (lab lost sample etc. or the opposite). Should this go in BS or BE domains? Do we only submit what we have?
·  Automatic system variables such as data entry date should not be submitted
·  Thread of queries are not submitted
·  List of randomization numbers is not submitted all the time. Unless you have the key you wouldn’t know what is what. Also screening or rescreening numbers etc.
·  Redundant information from the CRF – if information is duplicated then only one instance would be included as only one can be included in domain.
·  eCRF Audit trail not submitted
·  FDA comment – system function of date sample not valuable. Data change and level of data change (two dates and unsure which is the accurate date). This is not needed.
·  Notes function in the EDC system – if comment is not important for review/analysis then not included. However if it is important then this would need to be included.
·  SAE data on a SAE report may have additional information (identifier information) than the eCRF AE form but the additional information is not included in the SDTM. SAE report form has data that is redundant with data from the AE CRF.
·  Was autopsy performed indicator not included
·  Re-consents for amendments – Should re-consent information be included? Do they go in DS?
·  Removing items from submission may impact the validation process.
·  How much information is needed on Investigators? Do we need to list address or is name and site number acceptable?