Re: Validation Strategy for NONMEM
Mark and all,
In today's regulatory climate, software qualification programs are expected to be guided by risk analysis (RA). The RA can be used to advantage in the case of NONMEM in that it can serve to define true impact (i.e., who are the NONMEM result end-users), and provide a rationale for the extent of qualification required. The RA itself is usually SOP driven and helps to get QA agreement early in the process.
As for QA, pharma company QA requirements for software qualification are well-known. The value of the QA process, as it is applied to NONMEM, is arguable, but the requirement to address the QA process remains. So one has to decide what makes sense and what can be done.
Since it may not be possible to prove the correctness of a result, a NONMEM qualification plan can be built around a strategy for developing confidence in the performance of a NONMEM installation and, by extension, confidence in the results obtained. How that case is built is going to vary between users and sites, but here are some points to consider: Is the NONMEM installation well-characterized (version, compiler)? Are bug fixes and changes to the NONMEM source code being managed by a change control process? Can you link a well- characterized NONMEM installation with a given analysis? Are performance and robustness adequately tested? Does the NONMEM installation run as part of a larger, formally qualified IS infrastructure? Are there QC processes in place that put checks on data integrity and scientific validity? Is there training in place to qualify system users? Questions like these are useful in forming a basis for user requirements, usually a first step in software qualification. The R-FDA white-paper is also instructive in outlining general software qualification considerations.
Jeff
---
Jeffrey Hane, PhD, COO and CIO, Metrum Research Group LLC [www.metrumrg.com ] Email: [EMAIL PROTECTED] Direct: +1.201.926.8612 Main: +1.860.735.7043
Quoted reply history
On Oct 17, 2008, at 4:08 PM, Vilicich, Mark wrote:
> Dear All,
>
> I am interested in perspectives on strategies for "validating" NONMEM. Also, experiences from or with the FDA since the FDA is: a key user, customer of analysis and auditor of NONMEM use in the industry. Without a large nonmem staff here, the challenge I see is in scaling the validation strategy to provide the most efficient environment for doing analysis that is defensible to both internal and external audits based on the associated GxP risk level.
>
> Below are the concepts I've cobbled together, though instead of my reinventing the wheel I appreciate anything you could share. Any and all gems of insight you can share whether it regard the big picture or some detailed specifics, IT centric or business process related. You may send them back to the listserver or me directly as you feel appropriate.
>
> Details:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> From searching the archives and other random bits of knowledge on NONMEM, part of the validation strategy is to recognize that NONMEM is not to be literally validated. NONMEM may be considered more of a development environment, optimized for developing specialized forms of complex analysis and modeling. As a development platform, an approach could be that NONMEM itself is qualified and each specific analysis is validated individually.
>
> To support establishing a defensible NONMEM environment, I've also read discussions on integrating common software development best practices such as version control of the "programming" of nonmem, NMQual and other commercial and custom tools for capturing all the metadata related to running a specific NONMEM job. These themes support defining the state of the NONMEM environment and ability to reproduce the outcomes.
>
> Also, reading in the archives about the differences in the numeric outcomes of NONMEM analyses based on the hardware platform, etc. are helpful to know up front and to consider in the validation strategy so it is not destined to failure if the target environment is multiplatform or otherwise complex.
>
> Gaps noticed/topics not discussed:
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Is there opportunity in looking at the risk based approached sanctioned by the FDA a few years ago that would make the total validation deliverable, including both the application and the model development process, more lean and targeted at the primary risk targets?
>
> Does this scientific software environment lend itself to use of modern agile software development methodologies that go far beyond basic iterative approaches. These methodologies are being used in software development for the regulated/GxP industry.
>
> I've seen the excellent presentation from 2004 that Joga Gobburu from the FDA gave, seems like there has been some progression of thought or actions on the proposals included there. Any references to follow-up information on it would be helpful?
>
> Regards ,
>
> Mark Vilicich
> Early Development
> [EMAIL PROTECTED]