XForms and OpenClinica

Here at Geneuity, we do a lot of contract research work for sponsors of clinical trials.  That sometimes means developing and validating custom assays that aren’t available off the shelf. And this, in turn, often means developing special interfaces for data capture that can’t be configured inside OpenClinica (as yet).

Does that mean we jettison OpenClinica?

No, absolutely not!

Since OpenClinica is open source and dedicated to interoperability, it can be easily extended.  This article describes the specifics of one such case involving XForms.

A while back, Geneuity was developing an ELISA to measure the abundance of a specific protein in plasma.  We needed a single web form with a spreadsheet-like feel and functionality in which lab technicians could enter data, interpolate unknowns, send the resulting interpolated values for insertion into OpenClinica and then perform source data verification.  Additionally, the form needed to be pre-populated with the accession numbers of specimens requiring testing.  The form had to work on any browser and not be dependent on any browser plugins.  And we had to have it fast.

Impossible? No, not with XForms and the open source XForms renderer betterFORM.

XForms have several advantages.  First of all, you author the forms in relatively simple XML while the complicated AJAX that makes the spreadsheet-like feel and functionality is rendered by the renderer and presented to the client browser for you.  Secondly, XForms allows you to easily call upon webservices to populate data items in the form.  In our case, we developed three such services: one to return a list of accession numbers corresponding to specimens yet to be tested along with corresponding hyperlinks directed inside OpenClinica for rapid source data verification (SDV); another to calculate and graph a standard curve and to interpolate the specimen unknowns; and still another to insert the interpolated values into OpenClinica.  The data flow is diagrammed in Figure 1.  Although a great deal is going on behind the scenes, the user experience is seamless as a single form is being used while data retrieval and refreshment are being done without interrupting the display (thanks to AJAX as automatically implemented by betterFORM). The form itself is pictured in Figure 2.

And there you have it.  The bottom-line: no matter how complicated your data capture requirements are, you can count of the interoperability of OpenClinica.

Figure 1. First, the lab tech initially summons the XForm which calls upon OpenClinica via a webservice for the list of specimens for which there are no test results. The tech enters the data and clicks on the appropriate button to call for data interpolation and calculation. After review of the results, the tech then submits the data for insertion into OpenClinica (for more on this see here). Finally, the tech performs source data verification using the hyperlinks populated in the XForm as the result of step 1.
Figure 2. This is a snapshot of the XForm as it exists after interpolation and calculation. Only two specimens are shown, but usually there are many more in a batch.

How a Busy Research Clinical Laboratory Deploys OpenClinica as a Laboratory Information System (LIS)

Here at Geneuity Research Services, we do laboratory tests for clients
conducting clinical trials. We are a one-­stop shop, handling everything
from routine clinical assays to esoteric molecular analyses. We use
OpenClinica as an in-­house LIS to keep track of work­flow and to help
with administrative tasks like billing and specimen archiving. This isn’t
exactly what the developers of OpenClinica had in mind originally. The
application was designed from the point of view of trial sponsors, not their
subcontractors. But it works very well for us nonetheless. In this article,
we briefly describe how we do it.

As everybody who uses OpenClinica knows, defining your event x
CRF matrix is the most important step in configuring a trial. When a
client comes to us with a new trial, we do just that. We are careful
to reproduce the anticipated flow of events and patient groupings
just as designated by the trial’s specifications. “Why bother?”
you’re probably asking. “You’re just a subcontractor. That’s not your
concern.” But it is. Invariably, specimens get mislabeled and
inappropriate tests get ordered, and we’re able to detect many such
mistakes by doing a quick visual inspection of OpenClinica’s patient
x event dashboard with its easy-­to-­take-­in iconification. We feel
that this double-checking is part of our service to the sponsor.

CRF design is our next consideration. In this case, we don’t
try to reproduce everything required from the sponsor’s point of
view. Instead, we design a set of CRF’s that reflects just our role
as a contract clinical laboratory. This means that our CRF’s are far
more narrowly focused and less complicated. But it also means we
include some unique types of fields for pricing, specimen archiving
and the like, items that a trial sponsor usually doesn’t need to
address in their CRF’s but which are very helpful to us.

We are very careful how we name our items when crafting our
CRF’s. Specifically, we use the same terminology across our trials
whenever possible. For instance, the field for a specimen’s accession
number is always named ‘accession_number‘. Likewise, we consistently
use the names ‘freezer‘, ‘received_date‘, ‘price‘, ‘shipping_deviation
and ‘%assay_date‘ (where % is the wildcard string).

Using such a controlled vocabulary is vital in our case because
we use a separate installation of OpenClinica for each study and
employ the postgresql contrib module ‘dblink’ to federate their
attendant databases for querying. A helter­skeleter vocabulary would
render the latter problematic, to say the very least.

For example, we wrote a federated database procedure we call
accessions(). When executed, it consults the accession_number field
in all our installations and returns the number of accessioned
specimens broken down by trial name. This table lists some of the
federated procedures we’ve developed and their functionality.
Collectively, they provide us with a real­time, global snap­shot of
our work­flow and freezer contents.

Because OpenClinica is web­-based and has finely grained user
roles, our clients can remotely log into their respective
installations at our site with read­-only privileges and see the
status of their specimens whenever they want. Conversely, when we
think a specimen has been mislabeled or have some other issue, we can
call a client and direct them to a particular URL displaying the
pertinent information and seek clarification. OpenClinica thus
becomes a shareable laboratory notebook between us and our clients.

The bottom­line: OpenClinica works for Geneuity. Because
OpenClinica is open source, elegantly designed and well documented,
we are able to tailor the application to our needs. In the spirit of
mutual collaboration and aid fostered by OpenClinica’s lead
developers at Akaza Research, we’re making our federated procedures
freely available. They can be downloaded here.