If you have read my tips you will see there is a lot on data _null_ reporting.
It still remains on this web site but I regard it as historical now. I
developed the pages due to the insistence, at the time, of the FDA to have
12 point font tables. This was causing new "table shells" to be designed
around the time that "proc report" would not be able to easily cope with
- what I called "stacked" reports, so I thought there would be a swing
back to data _null_ reporting. It never happened, however, as the FDA relaxed
their rules on the font point size for tables, though they still expect
in-text tables to have a 12 point font (but I would have to check on the
latest guidelines to confirm).
Patient Profile reporting
Patient profile reports can be of a very complex structure involving data
from multiple datasets sometimes displayed side by side. Long lines might
flow for the patient in some places and this needs to be allowed for in
the report. I have written such reports and it is perhaps the most challenging
reporting task I have ever done. It is here that data _null_ reporting
comes into its own and is why I keep the data _null_ tips pages on this
web site. The tips are valuable for these sorts of reports and the good
techniques to do this come from experience. To work them out from first
principles would be difficult and prone to dead ends. So data _null_ reporting
still has a role in clinical reporting in the form of patient profiles
but for other sorts of programming - i.e. tables and listings, I feel data
_null_ no longer has a role and should be dropped in favour of "proc report"
reporting. This is due to the emergence of ODS, which can greatly improve
the look of tables, that is much easier to apply to output from procedures,
such as "proc report", than it is to apply to data _null_ reports.
ODS and proc report
I feel that plain text reports should no longer be considered as the fixed
standard for clinical reporting. For me, it is a style that belonged to
the last century. It should be an option, but not the rule. ODS support
was introduced into version 7 of SAS software in 1999. It has continued
to improve since then and with the release of version 9.1.3 in 2005 and
its improved support for ODS I feel it is the time for change. There are
still minor problems with it, such as pagination, but I expect these problems
to be solved soon. In 2007, I was of the opinion that data _null_ reporting
had largely been dropped by the clinical reporting functions, but I find
more and more that this is not the case. I feel it should be an option
to have tabular output in a more attractive form so that it is suitable
for use as "in-text tables", and by that I mean tables that can be included
in the text part of documents and fit the style for that document in the
sense of looking like natural word-processor tables. So not only do I feel
that data _null_ reporting no longer has a place but that any standard
reporting software that works with "proc report" at the core should have
pass-through facilities for ODS statements to take effect at the "proc
report" stage so that more attractive reports can be produced by the standard
reporting software. This is easy to do and there is another tips page on
the web site that shows you how to do this.
%unistats and %npcttab
If you think that moving away from data _null_ reporting would be a time-consuming
and costly affair then there is no need to worry. I have two macros on
this web site that can handle most of the safety reporting done within
the pharmaceutical industry. The two macros are very flexible and have
ODS support built into them. The usage of them is explained in detail on
the Spectre (Clinical) e-book that you can download from this web site.
The download page can be linked to at the bottom of the main page. If you
want to see the code of these two macros then link to their names as follows:
%unistats and %npcttab.