That's what I suspected. A risk-averse industry turned reasonable
guidance into a de facto standard. That sort of skittishness has its
own logic. From the standpoint of the CRO's data portability is much
less of an issue than uniform computer code within the firm. Without
the latter quality checks are expensive and unreliable. When you look
for a software standard you might as well go with the biggest
provider. You can be reasonably sure that they will be around for a
while, and that everybody else will pick them for the same reason. I
wouldn't be surprised if institutional investors thought that way
about everything.
It would also bet that the origin of every CRO's decision to use SAS
could be traced to the same white paper that had nothing to do with
either drug development or statistical analysis. Some slick-talking
risk management consulting outfit must have reasoned that the higher
upfront license fees and training costs would be offset over time by
cheaper rates on liability insurance and lower recruiting costs from a
larger pool of programmers.
Gabi
On Jan 4, 2008 11:48 AM, Lachenbruch, Peter
<[email protected]> wrote:
> I worked at FDA for 12 years and any statistical program was acceptable
> for use. The only requirement was that data sets had to be submitted in
> SAS Transport version 5 format (XPORT). We had some occasions in which
> some clever programmer submitted the data in CPORT which was not
> readable. The idea was that since the data and report would be archived
> it had to be retrievable in the future. XPORT creates ASCII files and
> FDA was comfortable about that. The reports were in pdf files.
>
> At any rate, the bottom line is that any validated statistical program
> can be used. If the FDA requested proof of validation, they wanted to
> see the PROCESS by which the programs were validated, not the validation
> runs themselves. For example, Stata has many (say S) scripts that
> generate k*S pages of output. FDA wants the S scripts (probably only a
> sample - talk with them if it's an issue).
>
> Other programs that have been used include SAS (obviously), R, SPlus,
> SPSS (occasionally), StatXact.
>
> The bottom line is that you can talk to FDA about this. If they insist
> on SAS, they are out of line.
>
> Tony
>
> Peter A. Lachenbruch
> Department of Public Health
> Oregon State University
> Corvallis, OR 97330
> Phone: 541-737-3832
> FAX: 541-737-4001
>
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Jeph Herrin
> Sent: Thursday, January 03, 2008 6:52 PM
> To: [email protected]
> Subject: Re: st: clinical trials
>
>
> I've published a few RCTs that I analyzed using Stata,
> and have a few more in the hopper. These are, however,
> in the area of Health Services Research, where the FDA
> has no presence.
>
>
>
> David Airey wrote:
> > .
> >
> > Does anyone on the list use Stata for clinical trials analysis? I get
> > the impression companies that specialize in this field use SAS almost
> > exclusively. From what I know of Stata's feature set, I don't think
> this
> > is because Stata cannot be use to perform analysis of clinical trials
> > data. SAS certainly pushes this area of use with SAS, and they have
> > several SAS published how-to texts.
> >
> > -Dave
> > *
> > * For searches and help try:
> > * http://www.stata.com/support/faqs/res/findit.html
> > * http://www.stata.com/support/statalist/faq
> > * http://www.ats.ucla.edu/stat/stata/
> >
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
> *
> * For searches and help try:
> * http://www.stata.com/support/faqs/res/findit.html
> * http://www.stata.com/support/statalist/faq
> * http://www.ats.ucla.edu/stat/stata/
>
*
* For searches and help try:
* http://www.stata.com/support/faqs/res/findit.html
* http://www.stata.com/support/statalist/faq
* http://www.ats.ucla.edu/stat/stata/
