FWIW: The few companies with which I'm familiar have significance resources -- i.e. software QC departments -- devoted to validating that internally developed code (e.g. SAS macros) used in submissions does what its claims to do. Extensive documentation of the code and the validation processs is required. All changes to such code must of course be documented and validated. I believe this is all part of CFR Part 11 requirements.
Bert Gunter Genentech Nonclinical Statistics -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank E Harrell Jr Sent: Monday, August 20, 2007 12:17 PM To: Cody Hamilton Cc: Thomas Lumley; r-help@stat.math.ethz.ch Subject: Re: [R] Regulatory Compliance and Validation Issues Cody Hamilton wrote: > 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 vers i! > 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 Cody, I think of this issue as not unlike an organization using its own code written by its own analysts or SAS programmers. Code is reused all the time. Frank > > 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. > -- Frank E Harrell Jr Professor and Chair School of Medicine Department of Biostatistics Vanderbilt University ______________________________________________ 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. ______________________________________________ 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.
