“Whenever you want to achieve something, keep your eyes open, concentrate and make sure you know exactly what it is you want. No one can hit their target with their eyes closed.” Paulo Coelho
Since the FDA mandated that sponsors with studies starting after December 17, 2016 should submit data in FDA-supported formats, familiarity with the requirements for CDISC compliance has undoubtedly increased. However, it can still be a daunting matter to know how to tackle a regulatory submission project from a data standpoint. Timelines are often tight, and the risks can be significant on high profile, strategic projects. However, there are ways to make life easier by working with focus and taking a risk-based, targeted approach to the activity. In this blog, I will share a few tips and insights based on Veramed’s experience to help smooth the path to submission success.
Use the right resources to prepare
Ultimately, when we are working towards CDISC compliance, our goal is to make sure that our studies are ready for submission and that we don’t receive negative feedback or technical rejections from the regulators. So, unsurprisingly, the regulators’ own resources are often the best first port of call for information. Specifically, the FDA’s Study Data Technical Conformance and Providing Regulatory Submissions in Electronic Format guidances should be the cornerstones of your research and preparation when it comes to planning for an FDA data submission. In addition to this invaluable regulatory guidance, CDISC’s website also has a wealth of knowledge and resources available to help you prepare. A word of warning, though- the sheer volume of documents and information available can be overwhelming. From the CDISC materials, I recommend focusing on the SDTM and ADaM implementation guides and the metadata submission guidelines as the essential resources. Even just taking into account only these technical documents and the FDA guidance is already a substantial undertaking in itself for a programmer to work through. However, by at least narrowing your efforts here, you can avoid getting overwhelmed and wasting time in unnecessary research- instead of getting your important project underway!
Hone in on Traceability
Traceability is an essential aspect of any regulatory submission, to enable understanding of the full trail of the presented data. Traceability is very closely linked to transparency and in that it provides reassurance in the results.
Define.xml of course plays a crucial role in establishing traceability by serving as a data dictionary that describes the structure and contents of the data collected during the clinical trial. For the FDA, this is a vital element of the electronic submission -providing traceability all the way back to the annotated CRF, with details of derivations for certain variables.
Unfortunately, FDA reviewers have identified the define.XML as a common deficiency that sponsors and CROs alike tend to insufficiently document within the e-submission. Typically, this failing occurs when the define.xml is created retrospectively. Naturally, when you generate documentation after the event, it is often difficult to precisely recall what you did, and so you may miss vital detail and information. Therefore I recommend that you create the define.xml either prospectively or as you go along to avoid this situation.
Be specific and targeted with your oversight.
Whether implementing CDISC compliance yourself or providing oversight on a CDISC submission, timelines are often extremely tight. It is therefore essential to be focused and targeted on the areas of the highest risk for your project. At Veramed, we have worked on several large CDISC projects involving numerous studies, and where a Study Data Standardization Plan (SDSP) has not been readily available. One simple action that helps direct the team’s work and increase both quality and productivity is to produce a retrospective SDSP at the outset of the project, assembling the details of all the relevant studies for each submission. As a case in point, the simple document we prepared for one very large project took only a few hours to pull together. It listed out all the studies in the submission and noted the type of trial, its phase, and the versions of SDTM and ADaM used as well as indicating whether the particular study features in the ISS/ISE. Once all this information collated, it is far easier to review and efficiently identify any anomalies and any areas for exploration. Then, some useful questions to ask yourself when considering this document include:
- Are the versions of SDTM ADaM and define.xml consistent?
- Is all the data in SDTM and ADaM, or is there some unconverted legacy data?
- Are all the artefacts available for the SDTM and the ADaM data sets? This includes the trial design domains and Reviewer’s guides.
The same targeted approach can be used for other aspects of the submission, including the essential define.xml. Clearly, define.xml can be a little unwieldy given that just one document can comprise of over 200 pages- so how do we review it most efficiently?
I would suggest that for a risk-based approach, you take the time to drill down into some of the essential information that you need. So, beginning with SDTM look carefully at CRF page mappings and check on some of the basics. Do the mappings link to the right page? Do the derivations make sense in terms of the study design and treatment information? Look particularly carefully at exposure and death information since errors frequently appear there. From the ADaM side, do take the time to review the ADSL in detail, check key date consistency and confirm that the subgroups and the treatment groups make sense for your trial. In line with this, take care that your primary efficacy, secondary efficacy, and your crucial safety endpoint data are compatible with your statistical analysis plan. If, having reviewed some of these integral elements you find few or no anomalies, it can give you far greater confidence that you are working with a quality product from the outset. If on the other hand there are issues here, you will at least be forewarned that there is further work to do, and additional resource may be needed to get the package in shape.
Working on a CDISC project can seem like a mountain to climb. However, by using the best resources available, taking advice from the regulators and working in a smart, targeted way, you can do a great deal to ease the process and set yourself up for success.
Would you like to learn more on this topic? Check out our on-demand webinar ‘Completing the CDISC Compliance Jigsaw’ for a deeper dive.
