[R] Regulatory Compliance and Validation Issues

[Cody Hamilton]

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