Rapid Deployment of New Functionality in OpenClinica Using MirthConnect

In a previous article, we describe how we at Geneuity Clinical Research Services exploit OpenClinica’s new web services feature to automate the entry of lab data keyed to accession numbers.  Here, we describe more fully how and why we use MirthConnect.

Started in 2006, MirthConnect is an open source project sponsored by the Mirth Corporation of Irvine, CA.  It is middleware designed to transform, route and deliver data.  It supports HL7, X12, XML, DICOM, EDI, NCPDP and plain old delimited text.  It can route via MLLP, TCP/IP, HTTP, files, databases, S/FTP, Email, JMS, Web Services, PDF/RTF Documents and custom Java/JavaScript.  MirthConnect has been likened to a Swiss army knife and justifiably so.

Channels are the heart and soul of a MirthConnect installation.  A channel is user defined and has a source and a destination.  A source may be a flat file residing on a remote server or a web service call or a database query or even another channel—whatever you like, it doesn’t matter. A destination may be to write a PDF document, email somebody an attachment or enter data into a database.  Again, whatever!

To illustrate, say you want to poll a database and generate a weekly report.  No sweat! Using MirthConnect’s easy-to-use drag-and-drop template-based editor, define a channel with a database reader as a source, and a document writer as a destination, fill in details like user names, passwords and machine names, define which database fields you want to retrieve and how you want to display the data, and you’re done!  MirthConnect’s daemon handles the rest based on your channel’s configuration.

Once defined, a channel can be exported as XML for later import into another MirthConnect installation.  This is all done with the point and a click of a mouse.

At Geneuity, we use MirthConnect to get data in and out of OpenClinica.  Originally, we used custom JAVA code to do this.  But once we found MirthConnect, we quickly realized we were reinventing the wheel.  Why do that?

Here’s a concrete example.  Consider the very simple CRF from a mock OpenClinica installation shown in Figure 1.  It has three groups of items: accessioning, results and reportage.  When a specimen arrives at Geneuity, the lab tech looks up the patient and event pairing in the subject matrix as specified by the requisition and types into the CRF the accession number, the receipt date and any shipping deviations.  This is done by hand and is indicated as step 1 of Figure 2.

Then, as shown in step 2 of Figure 2, the tech tests the specimen at the testing platform.  In step 3, the platform spits out the data whereupon a collection of MirthConnect channels operating in tandem parses the results, transforms them into SOAP messages and sends them to the EventDataInsertEndpoint web service feature of OpenClinica for upload into the CRF fields designated ‘Assay date’ and ‘Analyte concentration’.

After the tech reviews the data and marks it complete, another collection of channels polls the database for results newly marked complete, generates and delivers PDF reports of the corresponding data (step 4) and then reports back to OpenClinica (step 5) via EventDataInsert the details of the reportage, including status, time and any errors (see the third and last item grouping labeled ‘REPORTAGE’ in Figure 1).

The scenario outlined above requires NO CUSTOM CODE beyond the channel configurations and these are encapsulated and standardized by design.  As such, you don’t need an army of coders on staff to develop and maintain them.

Both OpenClinica and MirthConnect are great as standalone products.  Linked together, however, they really sizzle.

Figure 1: A simple CRF from a mock OpenClinica installation
Figure 1: A simple CRF from a mock OpenClinica installation
Figure 2: This shows how the different item groupings in the CRF depicted in Figure 1 are populated.  Values for items under ACCESSIONING are entered manually by the lab tech.  Values for items under RESULTS are populated by the Mirth channels continuously listening for in-coming data from the clinical testing platform.  Values for items under REPORTAGE are populated by a distinct set of  Mirth channels responsible for polling and reporting newly completed results.
Figure 2: This shows how the different item groupings in the CRF depicted in Figure 1 are populated. Values for items under ACCESSIONING are entered manually by the lab tech. Values for items under RESULTS are populated by the Mirth channels continuously listening for in-coming data from the clinical testing platform. Values for items under REPORTAGE are populated by a distinct set of Mirth channels responsible for polling and reporting newly completed results.

OpenClinica and the Paper Chase: A Case Study

The developers of OpenClinica like to say they are ‘powering the electronic data capture (EDC) revolution’ in clinical data management and indeed that’s the case.  However, sometimes there’s no substitute for paper, especially when it comes to tracking and handling laboratory specimens.  We at Geneuity should know: testing lab specimens for clinical trials is our business.  This article shows how OpenClinica and paper records can augment one another through the use of URL-encoding barcodes.

Readers of this blog probably already know the drill:  a specimen is collected, a paper requisition is attached and the whole kit and kaboodle is mailed to a laboratory for testing.  When a specimen arrives at Geneuity, we log into OpenClinica’s web interface, look up the patient and event pairing in the subject matrix as specified by the requisition and then finally type in the values for items like accession number, receipt date, shipping deviations, freezer location and the like.  When one or two specimens arrive, this process (called ‘accessioning’) is no problem; when 20 to 60 arrive, it rapidly becomes tedious.

In a more perfect world, things would be easier and more automated.  Here’s one potential scenario to help achieve this.  In addition to all the necessary information in human-readable form, also print on the requisition a QR barcode that encodes the URL corresponding to the appropriate event case report form (CRF) in the study’s OpenClinica installation.  For instance, consider the example shown in Figure 1.

It encodes: “https://myOpenClinicaInstall.com/InitialDataEntry?eventCRFId=1” (for illustration only, not intended to link anywhere for real).  Upon being scanned with an appropriate hand-held reader (or smart-phone even), this would automatically direct the lab technician’s browser to the correct screen to input the attendant accessioning information for study event number one.  This would eliminate the manual look-up step described above and would reduce tedium and errors as a consequence.

Implementing this idea would require enabling OpenClinica to print out requisitions.  While challenging, this would not be impossible.  Indeed, middle-ware like MirthConnect may make it relatively easy.

Here’s another example of paper and OpenClinica working together, one that Geneuity actually implements currently to facilitate quality control.  Prior to testing a batch of specimens, lab technicians here use a custom Mirth channel to print out details of the samples to be tested.  A dummy example is shown in Figure 2.  As shown, it includes a simple linear barcode of the accession number, the principle means of tracking specimens in a clinical lab.  Scanning this saves the technician from having to type it into the testing platform during set-up.  It also contains a QR barcode specifying the event-specific URL that directs the technician where to go to review the data upon automatic upload into OpenClinica.  Having this URL handy means the technician doesn’t have to look it up in the subject matrix table which oftentimes has hundreds or even thousands of entries.

URL-encoding barcodes are a cheap and reliable way of linking physical objects with on-line databases, and nowhere is this link more critical than when tracking clinical specimens.  Thanks to Akaza’s commitment to open source, it’s easy to incorporate this technology into OpenClinica and to realize the myriad of benefits.

Figure 1: a QR barcode encoding an event-specific URL in a mock OpenClinica installation
Figure 1: a QR barcode encoding an event-specific URL in a mock OpenClinica installation
Figure 2: A list of specimens to be tested reported by a Mirth channel extracting from a mock OpenClinica installation.  The linear barcode helps with data entry at the testing platform while the 2D QR barcode is used to direct the lab tech's browser to the appropriate URL in OpenClinica for subsequent data review after testing is complete.
Figure 2: A list of specimens to be tested reported by a Mirth channel extracting from a mock OpenClinica installation. The linear barcode helps with data entry at the testing platform while the 2D QR barcode is used to direct the lab tech's browser to the appropriate URL in OpenClinica for subsequent data review after testing is complete.