Regarding the clinical reporting process, this is one of the most recurring questions asked to AdClin. A big part of the industry is used to produce RTF outputs, which is a Microsoft proprietary format. So here is a brief explanation of our design philosophy regarding this. By the bye notice that our system also provides native ASCII outputs, and an HTML to RTF converter.
The AdClin Reporting System™ (ARS) has been designed to match the usual Clinical Reporting Process, depicted below.
The key concept in designing the solution was to streamline the reporting process, that in effect comprises three phases:
- Producing the results
- Arranging the results in tabular format
- Including these tables in paginated documents
Streamlining meant offloading as much as possible the mundane formatting workload from the table producers (programmers and statisticians) and, at the same time, also reducing the workload of table consumers (medical writing). The solution was found by establishing HTML as the pivotal interchange format:
- It allows producing in-text quality tables with a simple technology (readable ASCII files), easily produced by base SAS®
- Its tables follow a simple logic, and the rendering agents (browsers, word processing applications) handle much of the formatting otherwise done in SAS® (e.g., wrapping text inside a column)
- An important part of formatting (fonts, borders, etc.) can be controlled from a cascading style sheet (CSS) file, separate from the output file itself, that can therefore be reformatted without re-running the program that created it. It also makes it simple to define centrally-controlled corporate standards that all outputs will follow
- The HTML standard is definitely stable (4.01 is the final specification), non-proprietary, universally known and accepted, and allows streamlining the review of results using intranets
- All modern word processing and document management systems handle it extremely well (e.g., Microsoft changed its table model in Word 2000 to match the HTML one)
The experience of our customers shows that streamlining is effective: on the production side, programmers and statisticians type much reduced amounts of code, and can concentrate on tasks otherwise set aside, such as producing tables closer to the end user requests, or better commenting their programs. On the consumer side, medical writers that had to manually copy, paste, reformat or even retype results for hundreds of tables can now spend much more time on document content.