[R] Regulatory Compliance and Validation Issues

[Cody Hamilton]

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 versions 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: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