As I work as a biostatistician in the medical devices industry, I have been 
very happy to take part in several conversations on this list regarding the use 
of R in a regulated environment.  It was with great interest, therefore, that I 
read the new guidance document for the use of R in regulated clinical trial 
environments now available on the R website.  The purpose of the document is 
"provide a reasonable consensus position on the part of the R Foundation for 
Statistical Computing ... relative to the use of R within ... regulated 
environments and to provide a common foundation for end users to meet their own 
internal standard operating procedures, documentation requirements and 
regulatory obligations."  I believe this work will be a gold mine for those who 
are seeking to convince their organizations that R is a viable everyday 
statistical tool for use in a regulated environment.  I would like to offer 
personal thanks to (in alphabetical order) Frank Harrell, Tony Rossini, and 
Marc Schwartz for all their efforts on this document.

After an initial discussion introducing the relevant regulatory documents, 
section 2 presents the scope of the R guidance document.  I was grateful for 
this section as it spells out for the readers (not all of whom may be 
statisticians or R users) which packages are considered by the document (those 
that bear the copyright of the R foundation).  This is important as it gives 
software quality departments a limit on which packages are under consideration 
- I think some software quality people fear that approving R for use implies 
'opening the flood gates' to any user-created package that might be available.  
I believe that additional packages could perhaps be validated separately if a 
company so chooses (there are several I would be loathe to part with), but the 
packages considered under the guidance document are clearly defined as those 
bearing the R foundation copyright.

Sections 3 and 4 introduce both the R foundation and the R software for those 
who are unfamiliar with both.  Again, I am glad these materials are included as 
they may potentially increase the comfort level amongst those who are 
suspicious of open source software.  The document presents the R foundation as 
the stable organization that it is and provides a good overview of the purpose 
of the R software - this latter item will be particularly useful to me as the 
first questions I receive from software quality are 'what is it for' and 'why 
do you need it?'

Sections 5-7 contain the heart of the document (in my opinion).  They cover 
qualification/validation of sytems for 21 CFR 11 compliance, software 
development life cycle, and 21 CFR 11 compliance functionality.  These sections 
deserve special attention, and I for one will need some time to fully digest 
all the information in these sections.

I have a few specific comments/questions that I would like to present to the R 
help list.

1. The document in no way absolves users from the usual IQ/OQ/PQ required for 
any software to be used in a regulated setting.  I am very glad that this point 
is clearly made in the document (and I believe it was made by presenters at the 
useR meeting as well).

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?

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)?

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

Regards,
   -Cody Hamilton

______________________________________________
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