Trial Sponsors and Their Contract Labs: Better Collaboration via OpenClinica

At Geneuity Clinical Research Services, we do lab tests for trial sponsors. As readers of this blog know, we use OpenClinica internally as an LIS (laboratory information system), but as more and more drug companies and CRO’s adopt OpenClinica we foresee the day when we will be using their installations as our LIS, not ours.  A common platform will eliminate lots of duplicated effort and will allow for real-time transparency and better collaboration.  But it will also require sponsors to design their CRF’s with their contracting laboratories in mind.  In this article, we describe how this could be done.

First, consider specimen collection and tracking.  Normally, trial sponsors don’t consider doing this within the context of OpenClinica.  But they should.  Let’s say a specimen accidentally thaws in transit between the collection site and the contract lab.  Shouldn’t that fact be summarily recorded in the same context as the resulting lab test whose value may ultimately be reported to the FDA?  I should say so.

So, can OpenClinica be configured to do this? Yes and easily. A separate CRF dedicated to specimen collection could be designed and assigned to each event.  Alternatively, a specimen section could be added to already existing CRF’s.  Either way, fields for such things like accession number and specimen type could then be included.  These would be filled in by site personnel responsible for specimen collection.  Additional fields like ‘shipping deviations’ and ‘laboratory receipt date’ could also be included and would be filled in by lab personnel upon specimen delivery to the testing lab.  When it comes time for data analysis, the sponsor can use OpenClinica’s data export capabilities to exclude or include those lab results with shipping deviations and to investigate the consequences.

Other important aspects of specimen collection include printing labels to barcode samples and generating an attendant paper manifest (know as a requisition) against which labs can check incoming shipments of specimens.  OpenClinica can’t do such things currently.  It would require a whole new software module, but lots of added value could be achieved if one were written.  For instance, one can envision that after accessioning a specimen, site personnel could print a corresponding requisition from the same application window.  Also, imagine the time savings if lab personnel could conveniently print barcode labels after receiving a specimen and recording its receipt date and shipping deviations (if any).  And because the paper requisitions would be generated within the context of OpenClinica, subsequent source data verification by lab personnel could be expedited using QR-encoded URL’s that drill-down into the patient-event matrix. For more on this, see here.

Specimen tracking is just part of the story when it comes to sponsors and their contract labs.  Getting lab data from the laboratory testing platform into OpenClinica is another.  Recently during OpenClinica’s March 22 Global Conference in Bethesda, Akaza Research and Geneuity did a live demonstration of how this can be achieved using a set of MirthConnect channels. A batch of raw lab data keyed only to accession numbers was sent from Geneuity’s corporate headquarters in Maryville, TN to a remote OpenClinica installation hosted at Akaza’s Waltham, MA facility where it was inserted into the database programmatically via an awaiting web service. The insertion was streamlined, secure and seamless.  When setting up a trial, sponsors should think about the lessons this demo provides and consider distributing already configured and validated MirthConnect channels to their contract labs.  In this way, sponsors can control how their data is treated and understand every detail of its electronic provenance. And because MirthConnect can be configured to store its history, the trial’s audit trail can be extended upstream to the data’s very source.
Finally, consider invoicing.  Contract labs have to be paid when they do a test.  Monthly invoicing reports could be generated from OpenClinica by configuring an appropriate ‘data set’ and having it execute at the end of each month using the application’s new built-in quartz scheduler.  In this way, billing would be a snap and everybody would be on the same page.

In summary, how can trial sponsors configure OpenClinica to collaborate better with their contract labs? Do the following, keeping the workflow shown in Figure 1 in mind:

1.    Include a specimen accessioning CRF for each event.  Educate your collection-site people and your lab people as to who is responsible for which fields.  Use OpenClinica’s internal messaging system to remind people of their roles when the study is actually underway.
2.    Exploit OpenClinica’s web services framework to enable batch uploads of laboratory data.
3.    Configure and validate MirthConnect channels to get the lab results from the source data files to your OpenClinica installation.
4.    Distribute these channels to your lab contractors and educate them on their use.
5.    Configure OpenClinica to automatically generate monthly data sets for billing purposes.

The bottom-line: OpenClinica is infinitely configurable and sponsors should start doing so with their lab contractors in mind.  The result will mean both better collaboration and lower costs.

Figure 1: A specimen is collected from a subject on site. The on-site data manager logs into OpenClinica and accessions the sample and prints an accompanying hard-copy requisition. The sample is then shipped to the contracting laboratory where lab personnel log into OpenClinica and indicate they have received the sample. Specimens are then tested in batch and the results are then uploaded en masse into the sponsor's installation of OpenClinica using a thoroughly vetted, validated and auditable MirthConnect channeling system.

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.