[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sas-l
Subject:    Re: SAS DSP license agreement
From:       "A.J. Rossini" <blindglobe () GMAIL ! COM>
Date:       2008-04-30 9:54:31
Message-ID: 1abe3fa90804300254v1093047ncfcaff7764837856 () mail ! gmail ! com
[Download RAW message or body]

If you happen to be using R, and if you happen to be using Linux
(though that would be ptional), you could just create a custom
CD-based distribution for re-running the code and deliver the CD to
the pharma.

Or as one other person mentioned, create a "server appliance" for a
virtual machine such as for running on VMWare.

There should be no problems with R in pharma, I know at least one very
large pharma using it in development for submissible work, and know
that nearly all others use it for exploratory work.  There's a nice
paper on the R WWW site about this (caveat: I ghost-wrote some of it)
which people at the FDA have informally agreed to in principle).

However, this is a SAS group, and to bring this back to target, I will
point out that the next verrsion of that particular document (R in a
regulated computing environment), has a nice description of Health
Authority regulations, describing how and what GxP/21CFR Part 11 play
in computer systems validatin for data analysis.   Its part of the
response Roland was asking about while back, regarding validation for
reporting systems.

The document just needs to be approved by the R Foundation for plaing
on the WWW site, but ignoring the R content, it's a nice exposition of
the issues in CSV.  I expect it to be put up in the next 3-4 weeks, as
we have been waiting for reviews to finish.  (the current version is
unclear in a number of respects, the new verrsion is dated 2008).

best,
-tony

On Thu, Apr 24, 2008 at 2:09 AM, kmcital <kylemcbride@gmail.com> wrote:
> Thanks Phil, I will definitely take a look at your product.  The one
> positive from this experience with SAS is that it has caused me to
> reflect on our business process and how we can avoid being so
> dependent and almost servant to SAS.  Many of our customers expect us
> to use SAS, but that is even loosening up these days.  The real
> interest is that they receive SAS datasets in the end (since FDA
> requires that for submissions), with a way to reproduce the results on
> their end.  That second part is the tricky piece, if we use R how do
> they use our code to reproduce the results or rerun with a newer
> dataset?  Can we send back to the sponsor a stand-alone "application"
> of R and project code bundled together?  Perhaps WPS is a more
> practical solution...the first question for me would be, "will WPS
> support all the statistical methods needed on our projects?"
> Interesting stuff, I'll be checking it out.
> 
> Cheers.
> 
> 
> On Apr 23, 4:45 pm, PhilR...@MINEQUEST.COM (Phil Rack) wrote:
> > If you are not tied to SAS for the analytics portion, then you may want to
> > look at WPS for the data manipulation side. I have a WPS2R Bridge that I
> > wrote that can help you tremendously and it's free. You can view it \
> > at:http://www.minequest.com/downloads/WPS2R_Bridge.html 
> > As soon as WP releases and ODBC driver, I'll put that into the bridge so
> > accessing data is fairly seamless.  The other thing to consider is that you
> > can also deliver your data back to the client in SAS Data Set form using
> > WPS.
> > 
> > Good luck on your negotiations!
> > 
> > Philip Rack
> > MineQuest, LLC
> > SAS & WPS Consulting and Software Development
> > Tel: (614) 457-3714
> > 
> > -----Original Message-----
> 
> > From: SAS(r) Discussion [mailto:SA...@LISTSERV.UGA.EDU] On Behalf Of kmcital
> > Sent: 04/23/2008 7:32 PM
> 
> 
> > To: SA...@LISTSERV.UGA.EDU
> > Subject: Re: SAS DSP license agreement
> > 
> > Thank you all for very thoughtful points and especially to Don for
> > sharing his past experience - we will take those arguments into
> > consideration.
> > 
> > In fact, we are not tied to SAS to deliver our analytical services at
> > all.  I am using R and latex / Sweave to produce thousands of graph
> > reports to a client right now.  I also agree that the Sponsor
> > typically reruns the results once we deliver the end product to them,
> > so no one is getting out of licensing SAS here, they just want our
> > consulting services and don't care how we do it.
> > 
> > What surprises me is that SI is trying to apply this to our company of
> > 6 employees.  They're not really going to get much more revenue from
> > us, but then again, maybe the thinking is that we don't have the
> > knowledge or resources to be able to push back on them.
> > 
> > I have been able to verify with another CRO that they do not have
> > these additional fees applied to them.  Any others out there?
> > 
> > I just hope our legal fees don't surpass the additional license fees
> > SAS wanted to collect...but then again, it is the principle of it that
> > is wrong.
> 



--
best,
-tony

blindglobe@gmail.com
Muttenz, Switzerland.
"Commit early,commit often, and commit in a repository from which we
can easily roll-back your mistakes" (AJR, 4Jan05).

Drink Coffee: Do stupid things faster with more energy!


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic