Date:         Wed, 22 Oct 2008 10:23:03 -0700
Reply-To:     RolandRB <rolandberry@HOTMAIL.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         RolandRB <rolandberry@HOTMAIL.COM>
Organization: http://groups.google.com
Subject:      Re: The Future of RTF for Clinical Reporting
Comments: To: sas-l@uga.edu
Content-Type: text/plain; charset=windows-1252

On Oct 22, 7:15 pm, cye...@yahoo.co.uk wrote:
> On 22 Oct, 04:47, RolandRB <rolandbe...@hotmail.com> wrote:
>
> > On Oct 22, 1:37 am, cye...@yahoo.co.uk wrote:
>
> > > On 21 Oct, 22:57, RolandRB <rolandbe...@hotmail.com> wrote:
>
> > > > On Oct 21, 6:28 pm, cye...@yahoo.co.uk wrote:
>
> > > > > On 19 Oct, 20:39, savian...@GMAIL.COM (Alan Churchill) wrote:
>
> > > > > > Lou,
>
> > > > > > 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
> > > > > > automated basis.
>
> > > > > > Alan
>
> > > > > > Alan Churchill
> > > > > > Savianwww.savian.net
>
> > > > > > -----Original Message-----
> > > > > > From: SAS(r) Discussion [mailto:SA...@LISTSERV.UGA.EDU] On Behalf Of Lou
> > > > > > Sent: Sunday, October 19, 2008 11:05 AM
> > > > > > To: SA...@LISTSERV.UGA.EDU
> > > > > > 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
> > > > > > clinical reporting.
>
> > > > > > 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
> > > > > > abound.
>
> > > > > > 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.
>
> > > > > > Lou
>
> > > > > > "Alan Churchill" <savian...@GMAIL.COM> wrote in messagenews:001901c931b2$c1950b80$44bf2280$@com...
> > > > > > > Lou,
>
> > > > > > > I was emailing a birdie today on this subject. I am a technician and not
> > > > > > > an
> > > > > > > analyst so my take was simply on a programmatic way to address Pharma
> > > > > > > needs.
> > > > > > > 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
> > > > > > > (http://office.microsoft.com/en-us/infopath/HA101656341033.aspx)
> > > > > > > - 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
> > > > > > > Word
> > > > > > > add-in that copies a SAS dataset into a Word table? That is a trivial
> > > > > > > exercise.
>
> > > > > > > Alan
>
> > > > > > > Alan Churchill
> > > > > > > Savian
> > > > > > >www.savian.net
>
> > > > > > > -----Original Message-----
> > > > > > > From: SAS(r) Discussion [mailto:SA...@LISTSERV.UGA.EDU] On Behalf Of Lou
> > > > > > > Sent: Saturday, October 18, 2008 11:45 PM
> > > > > > > To: SA...@LISTSERV.UGA.EDU
> > > > > > > Subject: Re: The Future of RTF for Clinical Reporting
>
> > > > > > > "RolandRB" <rolandbe...@hotmail.com> wrote in message
> > > > > > >news:63e4d7e2-f798-457b-a3db-3692f9b554d2@k13g2000hse.googlegroups.com...
> > > > > > > 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
> > > > > > >> Reporting
> > > > > > >> is moving forward to the RTF, PDF, XML, HTML formats etc.
>
> > > > > > >> see
>
> > > > > > linkhttp://groups.google.co.uk/group/comp.soft-sys.sas/browse_thread/thre...
>
> > > > > > >> 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?
>
> > > > > > >> Regards
> > > > > > >> Chen
>
> > > > > > > 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
> > > > > > > document.
>
> > > > > > >http://support.sas.com/techsup/technote/ts749.pdf
>
> > > > > > > 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
> > > > > > > text
> > > > > > > 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
> > > > > > > similar
> > > > > > > software.    And this is important - many of those who produce clinical
> > > > > > > output and almost all of those who use it ARE NOT PROGRAMMERS, and
> > > > > > > solutions
> > > > > > > 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
> > > > > > > touch
> > > > > > > with their customers, we're stuck with half a solution in the form of ODS
> > > > > > > to
> > > > > > > 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.- Hide quoted text -
>
> > > > > > - Show quoted text -
>
> > > > > ===========================================================================­­­­=======
>
> > > > > Hi all
> > > > > First of all thanks to those who response.
>
> > > > > Roland’s comments on the RTF is based on a document which is very old
> > > > > (SAS v8.1) we are now in v9.2. We now have the RTF tagset in v9.2 so
> > > > > SI is committed to support RTF.http://support.sas.com/techsup/technote/ts749.pdf
>
> > > > > Lou mentioned the vertical control of the RTF.
> > > > > This paper will deals with this issue. It is simple but very
> > > > > practical. Read their conclusions!http://www.lexjansen.com/pharmasug/2006/technicaltechniques/tt12.pdf
>
> > > > > These people seems to have found their solutions with the RTF. Read
> > > > > their conclusion!http://www.lexjansen.com/phuse/2005/ts/ts06.pdfhttp://www.lexjansen.c...
>
> > > > > Then there is also %print by Paul Wehrhttp://informationsoftworks.com/print.php
>
> > > > > BUT SI has come out with a version of this. This paper is fairly old
> > > > > but I believe in v9.2 it is much improved.http://www2.sas.com/proceedings/sugi28/022-28.pdf
>
> > > > > [About this point -
> > > > > 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. ]
>
> > > > > This is one of the KEY advantages of the RTF format in my opinion and
> > > > > Roland's
> > > > > I believe you have miss understood this. The point is that with the
> > > > > output
> > > > > generated from ODS RTF the results are in a table (ie the values are
> > > > > in cells)
> > > > > This make it very easy for Medical Writers / Statisticians edit
> > > > > because they can just paste the table in their report and resize the
> > > > > columns etc.
>
> > > > > Regards
> > > > > Chen
>
> > > > There are easier ways of creating a Word table. You could get your
> > > > reporting procedure to create a semicolon-delimited list of figures
> > > > and then it is a simple matter to highlight it and turn it into a
> > > > natural Word table.
>
> > > Hi Roland
>
> > > With regard to your response:
>
> > > > There are easier ways of creating a Word table. You could get your
> > > > reporting procedure to create a semicolon-delimited list of figures
> > > > and then it is a simple matter to highlight it and turn it into a
> > > > natural Word table.
>
> > > WHY WOULD PEOPLE WANT TO DO THIS WHEN WE HAVE ODS RTF !!!???
> > > The method you mentioned is very old and anyhow how would you get
> > > different style of fonts,sizes,colour,subscripts,special characters
> > > etc ???
>
> > Have you tried ODS HTML with Word? It worked better than ODS RTF when
> > I last tried it. Word can save output as HTML so it understands HTML
> > well and works better with it.
>
> > > AND WHY WOULD YOU THINK GOING THROUH AND HIGHLIGHT EACH
> > > OUTPUT TO TURN THEM INTO WORD TABLE IS EASIER THAN NOT HAVING
> > > TO DO THIS AT ALL???
>
> > A WORD TABLE THUS CREATED COULD BE DONE IN THE BLINK OF AN EYE AND
> > WOULD ENFORCE THE STANDARD WORD TEMPLATES ON THE OUTPUT AND SO WOULD
> > HELP WITH CONSISTENCY.> Regards
> > > Chen
>
> ==========================================================================
> Hi Roland
>
> With Regard to your responses about:
>
> 1) ODS HTML – Why would you do this when RTF is native to Word. We
> have all experienced issues when bringing
>     formats that are not native to the application.
>
>   “ODS HTML then bring it into WORD is better than just ODS RTF?” How
> so
>    when RTF is as close to the WORD .doc format as you can get!!
>
>     I have not come across anybody who has gone with your route.
>
> 2) About your comment on consistency – Why would think that using ODS
> do not help
> with consistency. In fact this another point that reporting to .rtf
> has the advantage over the .lst – That is you can set the Styles,
> Margins with proc template(hence consistency).
>
> Regards
> Chen

Hi Chen,

I am talking about in-text tables here. That's the tables in the front
part of the clinical submission. The clinical writers have free reign
here. No matter if you say they must not, they *will* make up their
own tables with figures picked from other tables. They will insert
those tables. They do not use ODS -- they use Word. So their tables
will be one of the supplied Word styles. These will be different from
the RTF tables in some way. In order to have consistency it is better
if these in-text tables are imported into Word as cell tables and then
a style applied. I believe there is one large pharmaceutical company
in Switzerland that insists ti is done that way.

As for HTML importing into Word documents better than RTF then I think
Word has changed to give a lot of support for the HTML format and that
it has overtaken the RTF format in terms of the quality of the
rendering. That situation might have changed.