Date: Fri, 25 Sep 2009 09:19:26 -0400
Reply-To: Lou <lpogoda@HOTMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Lou <lpogoda@HOTMAIL.COM>
Organization: A noiseless patient Spider
Subject: Re: Who has got a clinical reporting system that runs from a
>"RolandRB" <firstname.lastname@example.org> wrote in message
>On 24 Sep., 19:06, "Lou" <lpog...@hotmail.com> wrote:
>> More or less.
>> The spreadsheet contains the output id, the program name, titles and
>> footnotes, among other things. SAS reads the spreadsheet and runs the
>> programs in the order listed. Individual programs read the spreadsheet
>> titles and footnotes. All projects use a standard directory structure, so
>> having a program locate inputs and outputs is automatic. The "correct
>> order" for outputs is determined by the file name for the output - table
>> 14.1.1 is generated in a file called Table 14.1.1.rtf, and Windows
>> sorts the file names correctly.
>> I guess the biggest difference from what you describe is using templates
>> a.k.a. macros, to generate the tables or whatever. I worked at one CRO
>> generated tables using macros, but the things were so complicated by
>> parameters to handle different requirements for different sponsors that
>> was pretty near learning a new language to use them.
>> Another reason is that our sponsors generally expect that they'll get a
>> working copy of all programs that were used to produce the deliverables,
>> cleansed of anything proprietary.
>> So we use programs. Each program knows where it lives, and can find the
>> spreadsheet, inputs, and outputs automatically. So getting a standard AE
>> table, for instance, can be a matter of copying the program into the
>> standard subdirectory for table programs for that project and making the
>> appropriate entry on the spreadsheet. And if it requires a little
>> because a particular sponsor has peculiar requirements, so be it.
>> "RolandRB" <rolandbe...@hotmail.com> wrote in message
>> > Has anyone got a clinical reporting system that runs from a
>> > spreadsheet in the following way or close to it? I will explain.......
>> > The spreadsheet contains, for each table and listing, the template id,
>> > the population (aka "report set"), any conditionals, whether it is a
>> > table or listing, the table or listing number, the required titles and
>> > footnotes (i.e. not those automatically generated), perhaps the layout
>> > and anything else required. Then this spreadsheet gets read in by SAS
>> > and it generates all the code to create the outputs (the template id
>> > is in effect the macro name and the population and conditionals get
>> > applied to this macro) and it runs all the code to create all the
>> > reports, and then afterwards gathers the outputs up in the correct
>> > order and converts, if need be, to another format such as a PDF. This
>> > is done without programmer intervention.
>> > I came close to creating such a system but the company I was working
>> > for got taken over and the project was dropped before it could reach
>> > that stage. I think this is the best and most efficient way to do
>> > clinical reporting. Has anyone already done this?- Zitierten Text
>> > ausblenden -
>> - Zitierten Text anzeigen -
>Thanks for that. By "template" I mean what the table or listing looks
>like. The "look" or "layout" in other words. But what creates that
>table I intend will also be a macro and since each template would have
>a unique id than that might as well be the macro name as well. My
>preference would be to keep these macros client specific as I don't
>see one macro being good for multiple clients and having parameters
>that handle different client requirements would likely lead to a mess.
If you're going to have client specific macros for tables, then I see little
or no reason to have them be macros - they may as well be straightforward
>But what could be done is to have "core" macros that calculate the
>descriptive statistics and category counts with percentages and
>another to do the unique patient counts and percentages and these core
>macros could be called by client-specific macros and could deliver
>output datasets that could then be formatted in the various client
Maybe that would fit some definitions of elegance - my personal opinion is
that it's over complicated, hard to maintain and difficult to debug.
Suppose you have something like the following to calculate "big n", the
number of subjects in a treatment arm:
select count(usubjid) into :col1
where trtpn = 1;
Therre's little to be gained by putting that code into a macro. And if,
heaven forbid, the macro for some reason is changed, you've just rewritten
an unknown number of tlfs.
>And then these client-specific macros might be quite short and
>simple code that pass their requests to the core macros and output the
>results using "proc report". I have generated all the tables for one
>study using such macro calls and each macro call was limited to a
>single line of code by design so that the macros are forced to be
>simple to call. I never got to the spreadsheet stage, however. It
>would have been interesting to see if it could work smoothly from a
>spreadsheet. Ultimately it should be possible for the statisticians to
>fill out the spreadsheet and so long as the templates they had did all
>what they needed then it should be possible for them to generate the
>study outputs themselves without programmer intervention.
Good luck with that. In a previous life, not in the clinical trials
industry, A company I worked at had a system that, by filling out a bunch of
parameters, a manager or accountant or clerk could define and get just about
any financial report they might like. None of those people, the end users,
would touch it. They wouldn't fill out the paramets themselves, though
they'd use the result. I'd bet most statisticians would be the same.