[R] Regulatory Compliance and Validation Issues

[Bert Gunter]

FWIW:

The few companies with which I'm familiar have significance resources --
i.e. software QC departments --  devoted to validating that internally
developed code (e.g. SAS macros) used in submissions does what its claims to
do. Extensive documentation of the code and the validation processs is
required. All changes to such code must of course be documented and
validated. I believe this is all part of CFR Part 11 requirements.


Bert Gunter
Genentech Nonclinical Statistics


-----Original Message-----
From: r-help-bounces at stat.math.ethz.ch
[mailto:r-help-bounces at stat.math.ethz.ch] On Behalf Of Frank E Harrell Jr
Sent: Monday, August 20, 2007 12:17 PM
To: Cody Hamilton
Cc: Thomas Lumley; r-help at stat.math.ethz.ch
Subject: Re: [R] Regulatory Compliance and Validation Issues

Cody Hamilton wrote:
> Dear Thomas,
> 
> Thank you for your reply.  You are of course quite right - the R
Foundation couldn't be responsible for any individually contributed package.
> 
> I am curious as to how an orgainization operating in a regulated
environment could safely use a contributed package.  What if the
author/maintainer retires or loses interest in maintaining the package?  The
organization would then find itself in the awkward position of being reliant
on software for which there is no technical support and which may not be
compatible with future versions of the base R software.  I suppose the
organization could take responsibility for maintaining the individual
functions within a package on its own (one option made possible by the open
source nature of R), but this would require outstanding programming
resources which the company may not have (Thomas Lumleys are sadly rare).
In addition, as the organization is claiming the functions as their own (and
not as out-of-the-box software), the level of required validation would be
truly extraordinary.  I also wonder if an everyone-maintain-their-own-copy
approach could lead to multiple mutated vers
i!
>  ons of a package's functions across the R universe (e.g. Edwards' version
of sas.get() vs. Company X's version of sas.get(), etc.).
> 
> Regards,
>    -Cody

Cody,

I think of this issue as not unlike an organization using its own code 
written by its own analysts or SAS programmers.  Code is reused all the 
time.

Frank

> 
> As always, I am speaking for myself and not necessarily for Edwards
Lifesciences.
> 
> -----Original Message-----
> From: Thomas Lumley [mailto:tlumley at u.washington.edu]
> Sent: Sunday, August 19, 2007 8:50 AM
> To: Cody Hamilton
> Cc: r-help at stat.math.ethz.ch
> Subject: Re: [R] Regulatory Compliance and Validation Issues
> 
> On Fri, 17 Aug 2007, Cody Hamilton wrote:
> 
> <snip>
>> I have a few specific comments/questions that I would like to present to
>> the R help list.
> <snip>
>> 2. While the document's scope is limited to base R plus recommended
>> packages, I believe most companies will need access to functionalities
>> provided by packages not included in the base or recommended packages.
>> (For example, I don't think I could survive without the sas.get()
>> function from the Design library.)  How can a company address the issues
>> covered in the document for packages outside its scope?  For example,
>> what if a package's author does not maintain historical archive versions
>> of the package?  What if the author no longer maintains the package?
>> Is the solution to add more packages to the recommended list (I'm fairly
>> certain that this would not be a simple process) or is there another
>> solution?
> 
> This will have to be taken up with the package maintainer.  The R
> Foundation doesn't have any definitive knowledge about, eg, Frank
> Harrell's development practices and I don't think the FDA would regard our
> opinions as relevant.
> 
> Archiving, at least, is addressed by CRAN: all the previously released
> versions of packages are available
> 
>> 3. At least at my company, each new version must undergo basically the
>> same IQ/OQ/PQ as the first installation.  As new versions of R seem to
>> come at least once a year, the ongoing validation effort would be
>> painful if the most up-to-date version of R is to be maintained within
>> the company.  Is there any danger it delaying the updates (say updating
>> R within the company every two years or so)?
> 
> It's worse than that: there are typically 4 releases of R per year (the
> document you are commenting on actually gives dates).  The ongoing
> validation effort may indeed be painful, and this was mentioned as an
> issue in the talk by David James & Tony Rossini.
> 
> The question of what is missed by delaying updates can be answered by
> looking at the NEWS file. The question of whether it is dangerous is
> really an internal risk management issue for you.
> 
>         -thomas
> 
> ______________________________________________
> R-help at stat.math.ethz.ch mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
> 


-- 
Frank E Harrell Jr   Professor and Chair           School of Medicine
                      Department of Biostatistics   Vanderbilt University

______________________________________________
R-help at stat.math.ethz.ch mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.