phuse – Iris

Crafting Explanations for Clinical Data Validation Issues – Tips and Resources

Ever get that deer in the headlights look when it is time to explain why you still have clinical data validation issues?

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:

SI and Conventional Units?

For clinical studies, FDA says “please submit two domains for lab results.” They are asking for both the previously expected SI units and now the conventional units.

Lab results in International System of Units (SI) have been the requirement for FDA data submissions. However, FDA has sometimes requested data in conventional units for labeling purposes. The last FDA Study Data TCG has changed a “may require” to a “please submit” for conventional units. This topic has made its rounds through CDISC Sub-teams and PHUSE working groups. Seems FDA has sorted it out with providing the additional instruction to submit in a custom domain. Has anybody out there added the lc.xpt dataset to their eSubmission data packages yet?

Let me know what you’ve learned.

Lisa

Automation in Electronic Data Submission Readiness for Drug, Biologic and Device Development. Don’t Forget the Deliverable Goes to a Human Reviewer

This article emphasizes the crucial role of human review of electronic data submissions in an era of increasing automation.

Introduction:
In the ever-evolving landscape of clinical research and drug development, the intersection of standards and automation has paved the way for remarkable advancements. Since its inception in 2007, Iris has been at the forefront of the rise of data standards and witnessed the subsequent surge in automation initiatives. This article emphasizes the crucial role of human review of electronic data submissions in an era of increasing automation.

The Power of Standards and Automation:
Data standards have heralded a new era in the field of clinical research, opening doors to unprecedented automation opportunities. The streamlined data lifecycle, from collection to eSubmission preparation, has revolutionized how the industry approaches data management and programming. As health authorities, including the FDA, integrate these standards into their toolkits, the burden on new drug and biologic evaluations is considerably reduced. Notably, the FDA’s exploration of artificial intelligence (AI) further underscores the potential for enhanced streamlining.

AI in Digital Health Technologies:
The intersection of AI and clinical research is a burgeoning field that holds immense promise. The #PHUSE working group, AI in Digital Health Technologies, is dedicated to exploring the potential of AI. A quick search of the PHUSE archives for “AI” reveals several papers can be found on this topic including the use of AI in handling unstructured data, case report form (CRF) design, and validation.

The Human Element in Drug Evaluation:
While the prospect of AI-driven drug evaluations may not be too distant, the current responsibility of assessing the safety and efficacy of new medicines rests in the hands of human reviewers. Despite the industry’s best efforts mistakes happen. Crafting a flawless marketing application remains an aspiration rather than a reality.

Elevating the Burden of Deliverables:
The surge in automation does not diminish the responsibility of sponsors to deliver data packages that are not only machine-readable but also comprehensible to human reviewers. In fact, automation amplifies this responsibility. Clear data definition, meticulously formatted documentation, and information consistency is imperative. Seemingly minor errors, such as incorrect page numbers, document titles, or references, can consume hours of a reviewer’s time. Transparency regarding hard coded data values, dosing mistakes, and validation issues in reviewer’s guides can save a lot of work and time spent responding to information requests. The value of a well-constructed data traceability diagram cannot be overstated. A double check by a human of these elements and more is imperative.

Iris: Nurturing Human-Ready Submissions:
As a pioneer in the field, Iris has emerged as a beacon of expertise in Electronic Data Submission Package Evaluation. With a wealth of experience evaluating numerous data packages for studies and marketing applications, Iris plays a pivotal role in ensuring that they are ready for the human review process. This final step, prior to pressing the proverbial button to submit data, instills sponsors with the confidence that their submissions are primed for the rigors of health authority review.

Conclusion:
The synergy between standards and automation has undeniably revolutionized drug, biologic, and device development. As the industry continues to evolve and AI’s role becomes more pronounced, it’s crucial to remember that the ultimate arbiter of a new medicine’s safety and efficacy remains the human reviewer. The imperative for sponsors to deliver human-readable data packages that reflect clarity, consistency, and transparency has never been more paramount. In this dynamic landscape, Iris stands as a testament to the harmonious blend of technology and human expertise, ensuring that data submissions are poised for a successful human review.

A shout-out to ChatGPT for my second draft of this article. It was the first time I used generative AI, I was not disappointed. Author: Lisa K Brooks and #ChatGPT