
Iris has reviewed a LOT of clinical data packages that have been sent to FDA over the years. We’ve seen all sorts of explanations written into data reviewer’s guides for failure to meet data validation rules. Sometimes, the data packages are not able to be modified before submission except for tweaks to the reviewer’s guide which always means making the explanation of validation issues more robust.
This article is about steps to take to make explanations better, not to disrespect good intentioned programmers who did their best to write an explanation. But there are a few that I’m going to point out that really should not be used.
- ‘Pinnacle 21 bug’ – In recent years I am dubious about this explanation. I investigate the heck out of this claim. P21 validation is quite mature here in the year 2023 and this type of explanation is unexpected. It is most likely that the programmer who wrote it does not understand the nature of the issue and my job is to elucidate the root cause of the issue to be corrected. I really like Kristin Kelly‘s discussion of ‘false positive’ in her PHUSE presentation on explanations.
- ‘As client instructed’ or ‘As sponsor instructed’ – This explanation would not make any sense to the target audience, an FDA reviewer. Regardless of who wrote the reviewer’s guide, the author is always the sponsor! With a little investigation a more reasonable explanation can be constructed.
- ‘True duplicate’ – Why are there duplicates in SDTM? I bet the programmer just needs to figure out the keys and put them in the define file appropriately.
- ‘No codelist’ – Ummmm, why didn’t you make a custom codelist?
- ‘As collected’ – This does not provide enough information to the FDA reviewer. Provide in the explanation what data was not collected or describe the way it was collected. An explanation should include a rationale for the reason the data could not be collected as expected.
- ‘Extensible codelist’ – provide the values added to the codelist. This little bit of additional information is meaningful to an FDA reviewer.
Pinnacle 21 has some great tools to help, including Issue Management. However, not everyone has access. Particularly for my small Biotech and Pharma clients who have a Biometrics team of 1 or 2 people and use the free Pinnacle 21 Community version. However, there are some things to consider as you are writing or editing explanations.
- Research! Use resources on the internet to better understand the validation issue. Understanding the issue can help determine the root cause, which can better help you craft an explanation. You can start with the additional resources at the bottom of this article. But usually a good search engine can help you find an answer.
- Collaborate! Constructing an explanation may need the help from specific subject matter experts. For data or data collection issues, reach out to the data manager. If it is a controlled terminology or dictionary issue, reach out to the person in charge of data standards. The statistician or the programmer may need to look at the specification if the issue is in the define generation. Clinical may need to provide some input into the trial summary domain if the developer of that dataset is not certain about all the options or the best terminology to use. It never hurts to ask!
- Be specific! Once you’ve done your research to understand the issue and the data, you can include details that provide a rationale or justification for why the issue exists. At a minimum, the explanation can explain the root cause of the issue.
- Write well! Explanations should be past tense, well formed, and using proper grammar and punctuation.
- Don’t blame! If your explanation is blaming a person or a department then it needs some wordsmithing. For example, “Data Management said this is how it was entered into the EDC.”
- Don’t give excuses! Just like when you are saying sorry, don’t make your explanation into an excuse. If you read it and it sounds whiny, then it needs rewritten. For example, “The database is locked and we can’t change it.”
- Use the right configuration! Whether you are using Pinnacle 21 or some other validation software, make sure you are using the right configuration. This includes the latest available version of the software with the latest rules. Also make sure you are referencing the correct standards and controlled terminology in the configuration. And don’t forget to be consistent. See my article on this topic here.
- Use the latest report! Nothing is more confusing than comparing explanations in a reviewer’s guide that doesn’t match a re-run of the validation report.
Let me know if you have other tips or resources that I can add to this article.
Author: Lisa Brooks, Iris Statistical Computing
Additional resources:
- PHUSE US Connect 2022 – Explanations in the Study Data Reviewer’s Guide: How is it going? Kristin Kelly, Pinnacle 21 – see the video
- PharmaSUG 2022 – Paper SS-152 Explanations in the Study Data Reviewer’s Guide: How’s It Going? Kristin Kelly, Pinnacle 21
- PharmaSUG NC SDE 2022 – An Expeditious Approach for Handling Pinnacle 21 Messages. Malini Narreddy, Sanofi
- PharmaSUG 2019 – Common Pinnacle 21 Report Issues: Shall we Document or Fix? Ajay Gupta during his time at PPD
- PharmaSUG 2019 – Seven Habits of Highly Effective Issue Managers. Amy Garrett, Pinnacle 21
- PharmaSUG 2015 – The Most Common Issues in Submission Data. Sergiy Sirichenko and Max Kanevsky, Pinnacle 21 (now Certara)