As mentioned previously, we at Geneuity Clinical Research Services are big fans of OpenClinica and are even more so now with the upcoming release of version 3.0 with its new web services capability. This article describes how we exploit this new feature to help automate entry of lab results, a particularly important topic given that we do lots of batch testing of specimens and oftentimes test the same specimen for many different analytes.
Prior to 3.0, you had three options when it came to CRF data entry. The first was to log into OpenClinica’s web interface and manually enter your data. This was no problem so long as you didn’t have lots and lots of data. But we did.
Alternatively, you could upload a flat file of your data as long as it was formatted in XML and associated with the appropriate subject id’s and visit descriptions. Assembling this file wasn’t trivial though and manually looking up each specimen’s subject and event nearly defeated the purpose of the procedure, which was to save time and effort.
Finally, you could do what we did: write custom code to automate the job. Lab data is amenable to this sort of approach because it is always tagged with something called an accession number that uniquely identifies it. When designing CRF’s, we always make sure to include a field for the event’s accession number, and when a specimen first arrives through our door the first thing we do is to log into OpenClinica and enter the specimen’s accession number in the appropriate event’s CRF. Because the number is unique to the study, this entry effectively tags the event and provides a ‘hook’ inside the database so that the event_crf_id of any data item subsequently annotated with the accession number can be easily looked up using a database query like so: ‘SELECT event_crf_id FROM item_data WHERE value = ‘<accession_number>’. This, in turn, gives you the requisite information to insert the lab data thusly: ‘INSERT INTO item_data VALUES (‘event_crf_id’, ‘value’ …’ provided you also know the item_id.
To implement this strategy, we wrote custom servlets that operated within the context of our OpenClinica installations. More recently, we configured MirthConnect channels to do the same. They worked well and data entry was greatly expedited, but the coding was complex and had to be refactored over and over again for each study and for every CRF change. While helpful, this strategy wasn’t sustainable in the long run.
Luckily, the latest version of OpenClinica provides a way out. It incorporates the Spring WS Framework which allows programmers to write something called a ‘web service.’ A web service digests and acts upon XML data sent to it on an on-demand basis over a network. The source need not be a human being uploading data on a web form, but, more usefully, it can be, say, a clinical testing platform automatically spitting out HL7 messages. This, of course, is ideal in our case. So we wrote a web service called ‘EventDataInsert’ that parses XML containing lab data values annotated with accession numbers and item names, looks up the corresponding event_crf_id’s and item_id’s, and inserts the data into item_data accordingly. The service is generic enough so that it doesn’t have to be refactored for each and every study, but it does make some critical assumptions. Namely, it assumes that both accession numbers and item names are unique. So care has to be taken to ensure both these preconditions are met.
The power of EventDataInsert doesn’t just lie in the fact that it handles inserts on an unattended basis, but also in that, like most web services, it requires only simple XML as input. The latter makes the source of the data irrelevant as long as it can be correctly mapped and transformed into XML. We often use MirthConnect to do this, using it’s easy-to-use graphical interface to configure channels between incoming raw data and OpenClinica’s web-service interfaces.
The figure below shows a typical deployment of OpenClinica at Geneuity. MirthConnect is used not only to get data into OpenClinica but also to generate canned PDF reports of the results. This scenario works for us and gets easier and easier to maintain as OpenClinica evolves new electronic data capture features and makes old ones ever more robust.