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