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 versi!
 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

As always, I am speaking for myself and not necessarily for Edwards 
Lifesciences.

-----Original Message-----
From: Thomas Lumley [mailto:[EMAIL PROTECTED]
Sent: Sunday, August 19, 2007 8:50 AM
To: Cody Hamilton
Cc: r-help@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@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.

Reply via email to