WIXLIB

SEND Dataset QC Best PracticesRecommendationsfor SEND Dataset QCBest Practices1 PHUSE Deliverablesphuse.eu

SEND Dataset QC Best PracticesContents1.2.3.4.5.6.7.8.9.10.Overview: Purpose of this Document. . . . . . . . . . . . . . . . . . . . 1Scope. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Definitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1Recommendation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Disclaimer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3Appendices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Project Contact Information. . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Revision HistoryVersionDateSummary0.12021-Jun-30Initial draft of SENDdataset QC best practicesrecommendation whitepaper0.22021-Jul-26Review by NonclinicalTopics Working GroupLeads2 PHUSE Deliverables

SEND Dataset QC Best PracticesDoc ID: WP-047Version: 1.1Working Group: Optimizing the Use of Data StandardsDate: 12-Feb-20211. Overview: Purpose of this Document5. BackgroundThere are a wide variety of quality control (QC) checks forSEND datasets based on accepted practices across thepharmaceutical industry and regulatory environment. This iscurrently done without a commonly acknowledged scope andcompleteness of these checks and is based on each company’sown experience and approaches with SEND datasets. Forregulatory reviewers to be more confident that the quality ofthe SEND datasets across different stakeholders is checkedconsistently, this document seeks to define best practices forSEND dataset QC procedures. The aim is to promote moreconsistent checks across industry that will help reviewers bemore confident that the data submitted accurately represent thedata in the study report.This project team formed to address ongoing questions fromregulators as to what steps sponsors take to ensure SENDdatasets match data presented in the study report. To gaugecurrent practices, the team initiated a survey of Nonclinicalgroup members in the PHUSE network. There were 51 individualrespondents, with not everyone responding to every question.Please note, results and statements in this paper are condensedand summarised, thus might not include individual data. Mostrespondents were based in the United States. The resultsshowed that most QC checks are completed manually ratherthan utilising validators or other automated tools. Further, thereis wide variation across industry as to which variables, domainsand values are checked as part of a SEND dataset QC. Forexample, most of the respondents said they check specificdomains and variables in the SEND dataset as well as the SENDdatasets against the nSDRG and the study report. In additionto the team’s review, three members from the CDISC JapanUser Group (CJUG) SEND team reviewed and commented onthe survey results to provide more global industry inclusion.Generally, CJUG SEND team subgroup participants felt itimportant to share a common target quality goal across thedifferent stakeholders, implement QC processes during thecreation phase by SEND dataset creators, reduce manual QCprocesses and standardise the toxicology study processesacross more than just the SEND datasets (to include the studyprotocol, SAP and study reports).2. ScopeThe scope of this document is as follows: Explore the variety of QC procedures and tools amongdifferent stakeholders. Identify a practical amount of SEND dataset QC checks(including the QC checks for the comparison of SENDdatasets and the study report). Identify a suite of tools and procedures (e.g. visualisation,documentation) for QC. Develop recommendations for efficient and effective SENDQC practices with the long-term goal of establishing afoundation of commonly agreed upon QC procedures.3. Definitions CDER: Center for Drug Evaluation and ResearchCDISC: Clinical Data Interchange Standards ConsortiumnSDRG: nonclinical Study Data Reviewer’s GuideUS FDA: United States Food and Drug AdministrationSEND: Standard for Exchange of Nonclinical DataSENDIG: Standard for Exchange of Nonclinical DataImplementation GuideCJUG: CDISC Japan User GroupSAP: Statistical Analysis Plan4. Problem StatementThe QC procedures for SEND datasets vary widely acrossindustry. To collect information and quantify this variety, theSEND Dataset QC Best Practices project team preparedquestions and reached out to the Nonclinical Topics WorkingGroup members via a survey during late 2019. Because there isinterest at regulatory agencies to gain a better understandingof what QC checks sponsors complete on studies prior toregulatory submissions, this white paper proposes standardisedSEND dataset QC checks to ensure more uniform checksacross industry and to assure regulatory authorities that theSEND datasets accurately represent the information in the studyreport.1 PHUSE DeliverablesBased on the survey results, commercially available softwarewas the most common choice for SEND dataset production, withSEND-as-a-service representing a good alternative. Generally,commercially available tools with manual checks are used tovalidate and verify data. Organisations that receive completeor partial SEND datasets from third parties use mostly manualchecks. The most common areas that are checked are withinspecific domains or variables, but it is unclear which domainsor variables since the question was not asked in a specificenough way in the survey. While manual checks are mostlikely performed when errors and warnings are representedby automated validators, the results also implied that manualchecks are performed on all SEND datasets, including TrialDesign domains, regardless of the validator outcome. Manysponsor companies check SEND datasets manually againstsummary and individual data in the study report. The biggestchallenges faced by industry, surrounding QC checks, are 1)how resource intensive it is and 2) lack of clarity about what isconsidered a best practice for QC.The Working Group took this survey information and CJUGfeedback and broke out into smaller subgroups, with a goalto determine best practices for three groups of domain sets:Trial Design domains, CL/EX/LB, MA/MI/OM/RELREC/SUPP and CV/RE/VS/EG/BW/FW. Each group compiled theirrecommendations and presented them to the rest of the projectteam. Generally, it was determined that domains and variablesare reviewed for three primary quality measures: conformance tothe SEND standard, appropriate use of Controlled Terminology(CT) and accuracy with the study report. Additionally, generalrecord counts are performed across the CL/EX/LB domains fora study to ensure the appropriate number of records is availablealong with the variables being populated. Companies utilise

SEND Dataset QC Best Practicesvarying strategies to address QC goals, such as outsourcingQC checks, performing 100% manual checks and using anautomated tool to check all domains. The variation acrossproject team members’ companies echoed the survey resultsthroughout this exercise.Following the survey result analyses, the project team continuedto build recommendations for SEND QC best practice byreviewing questions posed by industry stakeholders withinthe team, including regulatory agency staff, SEND producers,sponsors, SEND consultants and software developers. The teamprovided feedback and opinions on those questions to furtherrefine recommendations. FDA CDER team participants providedgeneral feedback on the current SEND consumer experienceand areas where reliable QC practices could make a differencein the data review experience, such as 1) how participantscurrently populate different variables and associated clarity withcurrent standards 2) variation in what and how categories andscales are reported (if at all) in the nSDRG or Define-XML fileand 3) variability as to whether finding modifiers and expectedvariables are filled out as expected. A variety of other factorsappear to impact the consistency of the data, including multipletest facilities performing studies for a single application, datacollection in real time and timing of dataset creation, relativeto associated standards release. There is also variation in theamount of information included in the SEND datasets (e.g.minimum amount required based on the standard, or everything).The nSDRG does not always say what has been omittedfrom the SEND datasets, which would be helpful for datasetconsumers or reviewers to understand.As there might be differing characterisations of QC checkprocedures, the project team aimed to pinpoint specificdefinitions. Again, a subgroup was formed, and the outcomeof their work was presented and discussed during a full groupmeeting. In essence, here are general definitions of high-qualitySEND data packages:Complies with regulatory requirements and guidances: Any reasonable non-compliance (e.g. data warnings/errors)is fully explained in the Nonclinical Study Data Reviewer’sGuide (nSDRG).Conforms to the SENDIG: Conformance rules are followed, and study informationis reported in the correct variable based on the definitionof the variable. This also includes SEND ControlledTerminology (CT), where CT is required and expected bythe SENDIG.Correctly Represents the study: The datasets are consistent with the study report when theinformation is in the study report; they are also consistentwith information recorded in other study records notincluded in the study report, e.g. some --DTC information;any discrepancies between the datasets and the report aredescribed in the nSDRG.Consistent across datasets: The same data is represented in the same way acrossdomains (e.g. test article, vehicle).Understandable: There is enough information in the nSDRG and Define-XMLfile that the consumer can understand what was received.2 PHUSE DeliverablesFit for Use: Consumer requirements are met, which may be highlydependent on expected data use by the consumer.