Preview of the March 22nd OpenClinica Global Conference

With just a week to go, the OpenClinica Global Conference is shaping up to be an excellent event for learning about OpenClinica and networking with members of the OpenClinica community.

This is the first ever Global Conference and we are thrilled to have as a keynote speaker Mark Adams, Project Manager for the National Cancer Institute’s Cancer Biomedical Informatics Grid (caBIG). As a fellow pioneer working to bring open source to clinical research domain, caBIG has developed a set of interoperable, open source clinical informatics tools which address functions such as adverse event reporting, patient registries, study calendaring, clinical trial management, imaging, and tissue banking. The caBIG project and OpenClinica together illustrate the broad impact open source is having on clinical trials.

The conference program extends along three tracks with case studies, panel discussions, tutorials, and presentations from clinical trial sponsors, CROs, academic groups, and IT services companies. Content is oriented towards both technical and non-technical audiences. Selected topics include:

  • An unveiling of the new OpenClinica CRF Library, a curated repository of standards-based eCRFs for OpenClinica
  • Case studies from sponsors and CROs showing how they have used OpenClinica
  • Presentations of tools and extensions developed around OpenClinica
  • Tutorial for installing OpenClinica
  • Tools, tips, and techniques for using OpenClinica data in SAS
  • Live demonstration of automated data interchange with OpenClinica
  • Automating the data import process
  • Validating OpenClinica for 21 CFR Part 11 compliance
  • Generating ad hoc reports
  • Modularization of the OpenClinica source code and introduction to the OpenClinica Developer Network

A full suite of training classes for data managers, biostatisticans, project managers, system administrators, and developers are also being offered immediately preceding and following the conference.

There is still time to register for this event. See www.openclinicaconference.org for more program information and registration details.

We look forward to seeing you next week!

OpenClinica CRF Library

UPDATE (03-May-2010): The CRF Library is now live at library.openclinica.org.

Our vision at Akaza Research is to accelerate clinical research through open technology infrastructure. We do this through an open source software license, supporting a participatory community, and adhering to published open standards.

We are nearing another milestone that will further this vision. The OpenClinica CRF Library, currently in the final stages of development, will allow users to find, share, and re-use case report forms (CRFs) for OpenClinica. By utilizing the OpenClinica CRF Library, users will be able to:

  • Enable faster study startup by accessing a well organized, searchable database of OpenClinica CRF templates
  • Promote data standardization within their organization through re-use of CRFs that adhere to open industry standards
  • Derive customized versions from standardized CRF templates simply by editing the OpenClinica CRF Templates
  • Minimize time and cost spent on study training, testing, and validation by accessing value-added resources and documentation (including implementation guides, CRF Completion Guidelines, and test scripts) associated with the CRF templates in the library.

The library will be searchable by keyword and browsable by CRF type. Most CRFs are derived from authoritative, public standards sources such as the CDISC Clinical Data Acquisition Standards Harmonization (CDASH) initiative and the National Cancer Institute’s Cancer Data Standards Repository (caDSR).

In keeping with our vision, the CRF Library is the product of a participatory community and is based on open source software. Last April, we assembled a volunteer Steering Committee to guide development of the library. Committee members Liz Watts of Starfire Research, Lori Brix of Silent Partners, Derek Wimmer of Wimmer Clinical, and Elisa Priest of Baylor Research Institute have worked scrupulously to identify content, develop supporting materials for the CRFs, and implement workflows that will ensure quality resources. Their substantial knowledge of the CDASH standard and data management expertise has been invaluable. The broader community has also had a hand in building out this resource, through the user mailing list and at meetings of the OpenClinica Community Virtual Forum.

Content & Quality

One of the first questions the Steering Committee asked was, ‘How do we manage quality of content and metadata?’ There are many community-driven, peer-review, and commercial validation models that could work, from a loose ‘wikipedia’-style structure to more rigid frameworks for curation and standardization. We needed to adopt the right mix for our content and our community. The Committee emphasized the need for a high-quality ‘core’ set of CRFs that have broad applicability across studies, align to leading standards, and are accompanied by detailed resources which aid in implementation. At the same time, a larger, more diverse repository of CRF content would make the library useful to many in the OpenClinica community.

The result of this has been to create two broad classes of CRFs in the library, Curated CRFs and and Non-Curated CRFs.

Curated CRFs have gone through a rigorous peer review, testing, and annotation process. They include enhanced metadata, detailed specifications, validation test scripts, enhanced edit checks, and reference documentation such as an Implementation Guide and CRF Completion Guidelines. The initial collection of Curated CRFs in the library will be aligned with the CDASH Domains. The intent is to make it as easy as possible to implement these CRFs into a study, in ‘as-is’ or customized form, with confidence in the quality and accuracy of the CRF.

Non-Curated CRFs will be contributed by members of the community who wish to share their CRFs with others, or will be derived from existing non-proprietary electronic sources such as the National Cancer Institute’s Cancer Data Standards Repository (caDSR). These CRFs undergo less formal review and testing and have fewer supporting materials, instead will rely more heavily on community feedback and annotations.

Because of the significant investment made in annotation, review, and testing, full access to Curated CRFs and all the associated metadata, documentation, and associated resources will be available only to OpenClinica Enterprise Edition Subscribers. Non-Curated CRFs, and limited versions of Curated CRFs without detailed metadata or documentation will be freely available to all members of the OpenClinica community.

Contribution

Based on past discussions on the OpenClinica mailing lists and the Community Virtual Forum, we see substantial interest among community members in contributing and sharing CRFs. This is a very exciting prospect, and we will need community members to contribute enough quality CRF content to make the approach viable. Many community members have expressed interest in sharing their CRFs for others’ benefit, but also identified it as a way to get feedback and improve the forms for their own purposes. To provide a foundation for such contributions, the CRF Library will adhere to the following principles:

1) Contributors will be appropriately attributed and recognized for their contributions. Creative Commons (http://creativecommons.org/) provides widely used guidelines and license agreements to enable this type of sharing. CRFs in the library or derived therefrom will be made available under the Creative Commons Attribution 3.0 License. Contributors must represent that they (or their organization) have the legal right to contribute a CRF, and are not infringing on someone else’s copyright. When featuring the most popular or most highly rated CRFs, the CRF Library will highlight the identity of the contributor (at least by screen name).

2) Members of the community will be empowered to build on and improve others’ contributions for the benefit of all. All community-contributed CRFs will also be freely available to community members, and we will put into place popularity, versioning, and annotation features to allow users of a CRF to provide feedback and/or modifications to the original author.

Next Steps

As I mentioned at the start of the post, we are approaching roll-out of the CRF Library within initial CDASH-based content, and starting acceptance of community contributions. The roll-out will be aligned with the OpenClinica Global Conference (March 22nd in Bethesda, MD USA) and the CRF Library will be a featured topic at the event. It’s been a long time in development and we are excited to be nearing this milestone!

OpenClinica Community Virtual Forum

With over 8,000 members worldwide, OpenClinica is leading the charge on bringing professional quality open source software to the world of clinical trials. Many people within the OpenClinica community are interested in ways to influence the development of the electronic data capture and clinical data management system for their own purposes as well as for the greater benefit of the community. I want to briefly point out a little known, but powerful way to contribute by participating in the OpenClinica Community Virtual Forum.

The OpenClinica Community Virtual Forum is a bi-monthly web meeting of OpenClinica users who get together to provide input on new OpenClinica features and functionality and detail their experiences in working with the system. Meetings are kept small and intimate, and topics to the point. The Virtual Forum is oriented towards users of the system, not software programmers. Participants include data managers, study programmers, biostatisticians, and other users from a variety of organizations representing both the industry and academic worlds.

The exchange of ideas and feedback that has occurred in past Virtual Forums has significantly helped to refine the way functionality has been implemented and influence OpenClinica’s short and long term roadmap. In our most recent meeting last November, we discussed Dynamic Logic and received early feedback on the newly released OpenClinica 3.0.

The next Virtual Forum is scheduled for January 19th, 2010. If you would like to potentially participate in future Forum meetings, please send an email to community-forum@akazaresearch.com. For more information about the OpenClinica Virtual Forum, see https://www.openclinica.org/dokuwiki/doku.php?id=publicwiki:virtualforum:start.

OpenClinica 3.0.1 Features Improved CRF Save Times

Akaza Research will be releasing a maintenance update of OpenClinica 3.0, which by itself probably does not illicit much excitement.  Usually maintenance releases only fix small bugs and offer little noticeable improvements to a user’s overall experience.  However,  3.0.1 will offer a dramatic improvement for a user’s experience with regards to the amount of time it takes Rules to run on a CRF.

Users of previous versions of OpenClinica would reach pain points when trying to save data entered onto certain CRFs if the study build had applied very complex Rules on a particular CRF section. For example, if the system had to check more than 10 variables to ensure one particular field had accurate data, the user might experience a save time of 2 or even 3 minutes in some circumstances.  In a test environment, we were actually able to create a scenario where the CRF save time took 19 minutes!

As part of 3.0.1, among other things, we have dramatically improved the save time of a CRF with complex Rules.  For instance, in the extreme scenario utilized in our test environment, we were able to cut the save time from 19 minutes down to 10 seconds.  That is about a 11,400% improvement!  For more typical users who were experiencing 2 or 3 minute save times, this has been cut to 3-5 seconds.

We are committed to improving the performance of OpenClinica, and can even offer faster experiences to the users of the OpenClinica Enterprise Edition.  Please see our website for the differences between the Enterprise and Community versions of OpenClinica.

OpenClinica 3.0.1 will be out next week!

OpenClinica Community and Enterprise Editions

Dear OpenClinica Community,

We are only hours away now from the general release of OpenClinica 3.0. There is a ton of excitement here at Akaza as we get ready to see many months of hard work come to fruition.

In advance of this milestone I’d like to describe a few changes we’re making to how OpenClinica is organized and how the name and logo can be used.

A brief background: As a founding member of the OpenClinica® open source community, I constantly strive to ensure that our technology has a reputation for meeting the highest standards of quality. The growth of OpenClinica® over the past few years is a testament to some success in that area. In my role as CEO at Akaza Research, a business that has invested millions of dollars into development of this open source technology, I recognize that the same reputation of quality is critical to our ongoing success. Part of how we maintain this reputation is to provide quality control over solutions that bear the OpenClinica® name. To enable this, Akaza Research owns the registered trademarks for OpenClinica® and Akaza and reserves the rights to their use.

With the release of 3.0, we are publishing a trademark policy on our website (also summarized below) that defines how the OpenClinica® and Akaza Research® trademarks may be used by members of the OpenClinica community. Our goal is to protect the quality of the OpenClinica® and Akaza brands without inhibiting the freedom that comes with the open source software model. These trademark terms complement the flexibility of open source licensing, by clarifying and creating confidence in the quality and reliability of solutions that bear the OpenClinica® name.

The most visible way the policy will be manifested is by separating the Community and Enterprise editions of the software. The default software download from OpenClinica.org is the Community Edition, pre-configured in a way that complies with the requirements of the trademark policy. The policy itself covers allowed uses of the trademarks for commercial and non-commercial purposes, both for modified (derivative) works and for unmodified versions of the software.

Akaza’s OpenClinica Enterprise customers and partners will be granted separate licenses that include additional permissions on how they may use the trademark in their marketing, operations, and services activities. Their installations will be distinguished as “OpenClinica Enterprise Edition” via the label in the footer of their OpenClinica pages.

I want to stress that 100% of the core OpenClinica source code remains free and under an open source software license. It is our promise that this will always be the case. Over time Akaza will offer additional proprietary services and technology offerings as part of the OpenClinica Enterprise Edition to complement this core, but it is our goal to ensure that the Community Edition always stands on its own as a fully-functioning, 100% open source EDC/CDMS platform.

I hope you share my view that this new policy will provide the clarity and confidence that allow OpenClinica to continue to thrive, without imposing undue restrictions on members of the community.

With that (too lengthy) introduction, here is a summary of the policy. Click here for the detailed, legal version:

Category Description Terms and Conditions
OpenClinica Community Edition You download and install the software on your own, and are not commercially supported by Akaza. You may not use the OpenClinica brand for marketing or sales purposes, and must include the community edition disclaimer.
OpenClinica Enterprise Edition You are an OpenClinica Enterprise System Level Support subscribers. Other Akaza customers/partners and OpenClinica code contributors may meet the requirements of this category. Contact sales for more detail. Includes limited use of the OpenClinica brand for marketing and sales purposes, ongoing support, and display of “OpenClinica Enterprise Edition” in footer.
OpenClinica Community Edition – Derivative Work You download and install the software on your own, make modifications to the code, and are not commercially supported by Akaza. You want to keep the OpenClinica name/logo in the modified version. You may not use the OpenClinica brand for marketing or sales purposes, and must include the community edition disclaimer.. You must also clearly state the software has been modified and the modifications are not supported by Akaza.
Other Derivative Works You choose to strip out the references to the OpenClinica and Akaza names and logos from your modified version of the software. The trademark policy does not apply. The OpenClinica source code is licensed under the GNU Lesser General Public License (LGPL). You still must follow the terms of the LGPL, including copyright attribution and requirements for redistribution of source code. Of course, if you choose to follow this course, we hope you’ll also let us know about your software modifications and will contribute these back to the core repositories, both for the benefit of the community and to help ensuring future compatibility of your flavor of the software.

If you are a community user of a prior version of OpenClinica and do not intend to upgrade to the latest release, please contact us if you have questions about how the new policy may affect you.

Best Regards,

Cal Collins

CEO, Akaza Research

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 3.0 Completes Functional Testing; Enters Deployment Testing

OpenClinica 3.0 is almost here! The quality team has successfully completed functional testing and has moved onto the phase of software quality assurance called deployment testing.  Deployment tests cover 8 different target “platforms” that range from a clean installation of OpenClinica 3.0 on a Windows server using Postgres, to upgrades of OpenClinica 2.5 to 3.0 on a Linux machine using an Oracle Database. Of course, we also test on all combinations in between.

Before the production version of the application can be released, it must successfully pass through our Quality System. For those of you familiar with such a thing, all of the testing and documentation that OpenClinica 3.0 is going through will end up generating thousands of pages of “paper” that include user requirements, traceability matrix, and a large set of screenshots which prove the expected results of the test cases did in fact happen.

In addition to the team at Akaza that has invested thousands of hours testing the application, this release has also undergone road testing in our first OpenClinica Pilot Program.  I would like to warmly thank the participants of the program for committing their time and effort in making sure OpenClinica 3.0 is our most well vetted release to date.

Please look for an announcement from me in the coming days of when OpenClinica 3.0 is available for download.

– Paul Galvin, Project Manager

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.

OpenClinica 3.0 Features Preview: Part III

Welcome to the 3rd and final installment of the OpenClinica 3.0 features preview!  This post covers the new Web Services interface that is part of 3.0 and the job scheduler that can be used to automate Data Import and Data Export jobs.

OpenClinica 3.0 allows for programmatic interaction with external applications to reduce manual data entry and facilitate real-time data interchange with other systems.  The OpenClinica web services interface uses a SOAP-based API to allow the registering of a subject and scheduling of an event for a study subject.

OpenClinica provides a WSDL (Web Service Definition Language) that defines a structured format which allows OpenClinica to accept “messages” from an external system. For example, an EHR system could register subjects for a study in OpenClinica without direct human intervention. At the same time, the EHR could also be programmatically scheduling study events for these subjects. More information about the OpenClinica API can be found on the OpenClinica developer wiki.

An early reference implementation conducted by clinical lab Geneuity used the API to create a web service which inserts data programmatically into OpenClinica CRFs directly from laboratory devices. See the post by Geneuity’s Colton Smith below.

Another major productivity tool in 3.0 is the introduction of a Job Scheduler for automating bulk data import and export.  With this feature users can define a job that will generate an export at a specified time interval.  The Jobs Scheduler can also be configured to regularly scan a specific location for CDISC ODM files and run data imports when a new file is available. This feature can be particularly helpful in automating routing functions, such as the incorporation of lab data into OpenClinica from an external system.  The lab data does need to be in a valid CDISC ODM format (this can be accomplished via another great open source tool called Mirth), but it does save a person from entering data in two applications separately.

At time of this post, OpenClinica 3.0 is currently released as a beta3, but the production ready application is soon to follow. The application is passing through the highly rigorous strictures of our quality system (think Navy Seals training for software) and the output will be fully validated and ready of use in roughly a month. Needless to say, I, and everyone else here at Akaza is very excited to be so close to releasing 3.0. It is already quite clear that this release will have a momentous, positive impact on the community.

Facilitated Data Entry of Lab Results Using OpenClinica’s New Web Services Feature

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.

Diagram of OpenClinica at Genuity Clinical Research Services
Diagram of OpenClinica at Genuity Clinical Research Services