We are currently working on the forum. For the short-term, all forum content will be in read-only format. We apologize for the interruption and look forward to collaborating with you shortly. All the best in your research!

Print(able) Subject Casebook function improvements

I see that OpenClinica is putting important and very appreciated efforts in strengthening the Print(able) Subject Casebook features (e.g. advancements in RESTful access to print all subject casebooks to JSON/ODM XML for whole Study/Site) so I would like to provide some comments and suggestions based on my recent experiences.

I have had the opportunity to extend testing of the Printable Casebook feature on some Study CRFs that we have in place and would suggest to consider the following aspects to ameliorate this very critical function:

1) CRF sections should not go in different pages.
Many CRFs may be designed with a first section containing some trigger questions and subsequent sections to collect details as needed. For CRFs with this structure a full page is "wasted" just to report the few trigger questions. This breaks the logical relationship between sections part of the same CRF and also produces an unneeded growth of the number of pages (impact that becomes well evident when the CRF is printed, not browsed as html page).

2) For all Items for which a list of possible values is allowed, only the selected values should be reported.
Cases occur where the list of possible values is very long.  For all these cases a lot of space is currently wasted to show the full list while only the selected value (or set of selected values) is pertinent to specific Subject/CRF occurrence.
It is to be noted that
 a) the full list of possible values is documented as part of CRF Metadata (so that the reference list from which the selected value has been taken may be known);
 b) the combination of the fact that bullets are in color, not all printers render appropriately gray shades for colors and the printout may be resized due to "large" contents results many times in casebook printouts rendered with a font size so small that it's really difficult to spot out what values are marked by a checked bullet with respect to those not checked.
For these seasons it would be really necessary that only selected values are included in the printable subject casebook.

2.1) Comment: presentation of the full list of values should be meaningfully retained, instead, when the empty CRF is printed for CRF layout documentation purposes.

3) Presentation of values part of repeating Item Groups with many columns should be done vertically instead of horizontally.
When CRFs include repeating Item Groups with many items, the tabular presentation may result to be very large.
In order to have this CRFs printed, the "shrink to fit" option must thus be selected when printing so that no parts of the table fall out of the page boundaries.
However, when a complete Subject casebook is printed with the "shrink to fit" option and a CRFs with a large repeating item group table is included, the overall Subject casebook is rendered with a font size so small that the obtained printout may result to be very hardly readable.
Simple existence of a single CRF with a large table of data can compromise the legibility of a full Subject casebook.
The vertical (single column) presentation of values part of repeating Item Groups with many columns (e.g. > 5 columns) might be an acceptable workaround to obtain that CRFs designed to be used on screen (usually with a landscape size format) and using the typically available horizontal scrolling features are reasonably rendered on paper (usually with a portrait size format).

4)  "sterilize" added JavaScript modules when generating a Subject Casebook.
Use of JavaScript is not supported by OpenClinica but, considering the threads found in the User's blog, is widely adopted in the community to ameliorate interactive use and presentation of CRFs.
Execution in CRFs of JavaScript scripts, and especially recall of external JavaScript procedures, often results in Subject Casebook presentation failing to complete (sometimes you can overcome the problem acknowledging a "Unresponsive script" error; sometimes the presentation seems completing but then hangs with an empty page).
A possibility to avoid this type of problems would be to "sterilize" added javascript modules, e.g. skip interpretation of JavaScript modules in CRF components (and especially the recall of external JavaScript procedures) when the printable Subject Casebook is generated.
This would be of utmost importance with the server-side preparation of a PDF Subject Casebook that is being developed to meet regulatory requirements about trust-ability of Subject Casebook printout.
In this case presence of JavaScript in even one CRF would prevent the overall printable casebook package for a Study being created.


The above described aspects are very important.
The lack of an appropriate resolution has the potential to make a fundamental feature like the Subject Printable Casebook (especially extended at Site and Study level) practically unusable with many "real life" Study CRFs. 

This discussion has been closed.