New OpenClinica Developer Release: Revamped Print Module

A new developer release is available for OpenClinica. While it contains a number of significant improvements, one of the more fundamental changes is a reconstruction of OpenClinica’s print CRF functionality. To date, all printable screens resembled the existing web form interface for the eCRF, whereas now, this engine has been completely redesigned to more closely follow industry standard for printable views of web forms.

Why This Matters To Developers

Ok, I get it. You are a developer, so what’s the big deal about being able to send CRFs to the printer?  It is the technology behind this improvement that will hopefully catch your attention. Important changes have been occurring in the sphere of web apps, and I don’t mean just a sprinkling of AJAX here and there along with a UI that looks like Facebook. The real revolution goes much deeper.

Setting a precedent for OpenClinica: Completely Decoupled Client Technology using Web Services

The notion is simple. Create a browser-based client with the same decoupled technology that a iOS or Android mobile client requires. In plain English, this means that only data is sent back and forth between the client and the server. Just as is expected with a native OS mobile client, the browser-based client never relies on the server to generate or send any part of itself except when the URL is first accessed and loaded into the browser. The client is therefore completely decoupled and can be in complete control of their own state. This results in a more reliable, speedier, feature-packed, and easier to maintain platform for both the client and server. Another way to put it … in the not too distant future, our 400 or so JSP pages will be replaced by one or two main HTML templates and about a dozen small (less than 100 lines each) HTML component files.  But for now, take a look at our printable CRF design as an example of the way forward.

Getting to the Point: REST, JSON, JQuery, HTML, and CSS

What follows is a description of the processing path that starts with a REST URL and ends with a printable CRF.

1. A user will click on a print icon that is part of many of the CRF view forms. The RESTful URL referenced in the link will be in the form of rest/metadata/html/print/{StudyOID}/{StudyEventOID}/{FormDefOID}. Using this combination, a wildcard asterisk character (*) can be placed as a specifier for all studies, all study events, and all CRFs, respectively.
2. The first path element in the URL named “rest,” indicates that this is handled by our implementation of org.akaza.openclinica.web.restful.ODMMetadataRestResource, our Jersey JAX-WS controller servlet. The “metadata” in the second path element indicates that is for metadata only and no clinical data will be transmitted. The “html” in the third path element indicates that this will result in a rather simple JSP page at /WEB-INF/jsp/printcrf.jsp. This JSP page is the container for the JQuery code that will make a second REST call to the back-end to retrieve the CDISC ODM in JSON form and is also the container for the Javascript and JQuery code that converts the information contained in the ODM JSON into an HTML DIV element with the rendered printable CRF.
3. The AJAX call that the Javascript method getPrintableContent() in js/app.js references is a URL in the form of rest/metadata/json/view/{StudyOID}/{StudyEventOID}/{FormDefOID}. It is the 3rd path element of “json” which indicates that the same ODMMetadataRestResource servlet will now fetch the relevant ODM XML metadata, convert it to JSON, and send it back to the callback portion of getPrintableContent(). In the callback portion, a call to app_odmRenderer.renderPrintableStudy() kicks off the process by which JavaScript inspects the JSON ODM object returned by the server and builds a DOM element that represents the portion of the metadata that is meant to be displayed as one or more CRFs.
4. The DOM HTML is rendered with the help of JQuery Templates. This allows HTML fragments such as template/print_item_def.html, which are initially loaded in memory, to be combined with certain extracted key/value pairs to render an individual or list of components.

What’s on the Horizon

This first release extends to printing blank CRFs. Then, we will work to extend this to handle printing CRFs containing clinical data and very large printable form sets. The process described above will be similar, with the exception that all large documents, typically over 100 pages long, will be rendered using a Java rendering class that builds off of Velocity templates. The resulting server-side HTML page will be converted to a downloadable PDF.

– Nick Sophinos, Senior Developer