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
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]
