Questions about data manipulation [GxP / QC / QA]

posted by ElMaestro  – Denmark, 2024-05-01 09:10 (225 d 22:43 ago) – Posting: # 23972
Views: 6,245

Hi all,

lots of good info here but also a few details that deserve commenting, in my opinion.

There have now been several cases where an authority directly requested -in a DCP- the outcome of Buster and SaToWIB (or similar software) along with its assessment. In the cases I know of and was involved in, the dossier sailed through to approval after a subjective assessment was sent along with B&S analyses.

❝ Well, what you will "prove" is that either:

❝    1. there was no manipulation, or

❝    2. the CRO was smart enough to do it in a way that will fool the software, or

❝    3. they manipulated the study in a totally different manner, which the software cannot detect...

❝ My concern is that by using the software, bad CROs will just learn how not to get caught. You will not uproot cheating, only change the way cheaters operate.


Well, look what happens if we do nothing. We've had hundreds upon hundreds of retracted MAs from various CROs. Can someone tell me how that is a preferable scenario to one where we use software routinely?
If we look at some of the concern through the years in the area of BE, then some of ships on the regulatory waters were somehow set afloat on basis of somewhat hypothetical fear. It starts with "what if…?" and then the ball starts rolling. Dose dumping comes to mind. It found its way into guidance even though noone actually had good proof for it.
The Tmax worry for select APIs… "What if…?"…And then we suddenly had Tmax requirements without clinical proof. All that existed was indicator of Tmax differing between formulations but not an absence of efficacy/safety similarity. And then we got guidance that was – as Helmut Schütz showed very elegantly – solving a hypothetical problem in such a way that it was all but impractical for an applicant to plan and dimension a study.
So, now the "what if…?" for the use of software. Are we hypothetically worried or are we concretely worried? Show me the concrete worry and I will deal with it. Possibly with software :-)

The next (or a new) frontier is when CROs are taking an aliquot of, say, x mL S13P2 and y mL S25P1 and mixing them. Then extracting and injecting. You will get a new profile that does not resemble any other profile much and you can completely steer the T/R in the direction you want. Software can detect it, though. In a study with 36 subjects Subj 31, 32, 33, 34, 35, 36 came out at the top of the sorted list, that is, they were apparently constructed from profile combinations of subjects 1–30 without T and R switched.

If we want the trouble to continue, then out of hypothetical fear we can just decide to do nothing and we will be blessed with a continuation of the current mess.

If the software is not so appropriate then why are regulators using it? How is that "something else" in reality? The regulatory use of Dabers is no issue, but applicant's or CRO' use of SaToWIB & Buster & & Effiou is?

If the subjective aspect is the issue then why don't we collaborate towards finding a way to make it all less subjective and more objective? Wouldn't that be a solution?


My own experience from being a regulator: Solution based on actual problem and facts are good solutions. Solutions that are founded solely in fear, "what if…?" and hypothetical scenarios tend to be not so good solutions.

Finally, FDA's new data integrity guidance calls for a proactive approach without being specific. Someone, please tell me how the use of software that has the potential to detect bioinequivalent products prior to submission is not a proactive approach. I am dying to hear it. :-)

Pass or fail!
ElMaestro

Complete thread:

UA Flag
Activity
 Admin contact
23,336 posts in 4,902 threads, 1,698 registered users;
48 visitors (0 registered, 48 guests [including 12 identified bots]).
Forum time: 06:53 CET (Europe/Vienna)

Only dead fish go with the current.    Scuba divers' proverb

The Bioequivalence and Bioavailability Forum is hosted by
BEBAC Ing. Helmut Schütz
HTML5