Date: Sun, 19 Oct 2008 13:39:18 -0600
Reply-To: Alan Churchill <savian001@GMAIL.COM>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Alan Churchill <savian001@GMAIL.COM>
Subject: Re: The Future of RTF for Clinical Reporting
Content-Type: text/plain; charset="us-ascii"
InfoPath allows someone to have a template of a document and then insert
content where appropriate.
Since everyone, it appears, has been using RTF, that is Microsoft centric so
using a Microsoft-centric approach seems ok if the industry has already
arrived at this point.
However, pick a vendor neutral format such as XML. Word 2007 is XML based so
it is open. InfoPath gives you the ability to have web services (or other
feeds) insert text, tables, graphs, etc. into a given section of Word on an
From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Lou
Sent: Sunday, October 19, 2008 11:05 AM
Subject: Re: The Future of RTF for Clinical Reporting
Hi Alan -
I've briefly perused the link you provided, but I'm not sure just what it is
that MS is selling here, and still less its general applicability to
The immediate task at hand is that various reports (in the industry, they're
called tables, listings, and graphs) are produced, almost always with SAS,
that need to be accessible to a variety of users, very few of whom are
programmers, many of whom are, by my standards, computer illiterate in that
they know nothing about how the machine or the software packages they use
work, and couldn't possibly care less.
The de facto standard for these reports at the moment is something that will
display, print, and be modifiable in MS Office, but not every organization
produces its output on the Windows platform. (The standard for data at the
moment is the SAS transport file format produced by the XPORT engine. The
present goal is to switch over to a "vendor neutral" format, some flavor of
XML, but it hasn't happened yet.) There are packages that are more or less
Office compatible that run on other platforms, but any Windows-centric
solution won't have general applicability.
SAS produces RTF output that's aimed at Microsoft's RTF specification as of,
I believe, 2003, no matter what platform it runs on. As such, it's a more
or less general solution that can be used industry-wide, provided recipients
have access to an RTF reader compatible with that standard, and such readers
I guess another limitation is that ultimately, a lot of this stuff ends up
being submitted to the FDA. Because the agency uses hardware and software
of various vintages, submission standards are subject to least common
denomator constraints. File sizes, data structures, naming conventions,
variable attributes, etc. lag a couple of decades or more behind the current
state of the art.
"Alan Churchill" <savian001@GMAIL.COM> wrote in message
> I was emailing a birdie today on this subject. I am a technician and not
> analyst so my take was simply on a programmatic way to address Pharma
> The birdie explained the problem:
> - Pharma folks need to include SAS output in a Word document
> - Currently, they find it easy to cut and paste RTF into Word or, manually
> enter the results.
> Here was my take:
> - Use Microsoft InfoPath which lays out a document in a user-friendly way
> - Have the SAS output to HTML, PDF, XML, whatever
> - Use tags for inclusion into the InfoPath document.
> I am not going into the ugly technical details but suffice it to say that
> creating Pharma documents that are standardized and require minimum
> intervention for results seems very doable to me. SAS 9.2 makes it even
> easier using web services but that will have to wait until 9.2's release.
> To simplify it for the day-to-day, perhaps there needs to be an simple
> add-in that copies a SAS dataset into a Word table? That is a trivial
> Alan Churchill
> -----Original Message-----
> From: SAS(r) Discussion [mailto:SAS-L@LISTSERV.UGA.EDU] On Behalf Of Lou
> Sent: Saturday, October 18, 2008 11:45 PM
> To: SAS-L@LISTSERV.UGA.EDU
> Subject: Re: The Future of RTF for Clinical Reporting
> "RolandRB" <firstname.lastname@example.org> wrote in message
> On Oct 18, 1:52 am, cye...@yahoo.co.uk wrote:
>> Hi All
>> About a year ago I asked for your opinion/experience whether Clinical
>> is moving forward to the RTF, PDF, XML, HTML formats etc.
>> My experience is that more and more statisticians and medical writers
>> are aware of the RTF
>> format and begining to ask for it. What are your thoughts and
>> experience on this?
> You must not go down the RTF route for clinical reporting until there
> is a clear change of policy by the SAS Institute. The last position
> they took on this that I am aware of is stated in clear terms in this
> In that document it makes it clear that RTF output is not supposed to
> be the final output and will need editing. This means that doing bulk
> reporting might never be practicable or advisable using RTF at any
> time in the future.
> PRINTER is for presentation-ready printable reports.
> RTF is designed to allow editing, not optimized for final output
> You need to give that PDF that is held on the SAS support site a
> careful read.
> Back before ODS, SAS produced print image files that perhaps weren't
> intended to be editable but nonetheless could be - all you needed was a
> editor. Today, for better or worse, the counterpart is something that
> anyone can look at and/or print using Word or some similiar application.
> What's needed is something that lets programmers control the vertical as
> well as the horizontal placement on the page, and is accessible to
> non-programmers, even near computer illiterates, using MS Office or
> software. And this is important - many of those who produce clinical
> output and almost all of those who use it ARE NOT PROGRAMMERS, and
> that don't take that into account end up being sub-optimal.
> At the moment, because a bunch of people at a big company were out of
> with their customers, we're stuck with half a solution in the form of ODS
> RTF (in spite of aiming at MS RTF which has been out there for a couple of
> decades, they don't appear to even implement the full tagset), one that
> seems to require almost as many work arounds and tricks to produce the end
> results as were needed before ODS was introduced.
> We're stuck with PROC REPORT (though it lacks the flexibility of the data
> step) and RTF not because they're good solutions, but because the
> alternatives presently on offer are even worse.