OpenClinica CRF Features – Everything But the Kitchen Sink

Whenever I teach case report form (CRF) design in the OpenClinica Central User Training class, the thought that always comes to mind is, “so many features, so little time.”  OpenClinica has so many features available for building your CRFs, that there is no way to cover every possibility within the limited timeframe of a training class. Fortunately, there are other ways of getting information out to users, so here I am to introduce you to additional features you may want to incorporate into your CRFs.

Some of these features use JQuery, a cross-platform JavaScript library designed to simplify scripting HTML. The JQuery code in the attached CRF template was tested on Firefox 35.0.1; it may function differently in different browsers or different languages. As with anything you set up for your study, if you decide to use any of the features presented here, be sure to test them in your test environment prior to using them in production.

Click to download: Kitchen Sink CRF and Associated Rules (zip file)

The attached CRF has 10 sections, and each section focuses on different feature sets. To see a list of all the Sections, click the drop-down arrow in the “Jump” box and then click the appropriate Section topic to see the features included within that topic.

CRF tabs

Throughout the CRF, each feature is labeled so you can easily recognize it and locate it in the CRF template. For example, “Left Item Text” is not a prompt you would ever include on your CRF, but it is the feature being demonstrated and is labeled as such so you can easily see where Left Item Text appears on any CRF you design. Each  Section of the CRF is listed below with a brief description as well as a screenshot so you can see how the features are represented.

1. Text

The Text Section illustrates various text features such as bold, italics, colors, and displaying images or a URL.  This section also covers the positioning of left item text, right item text, header, subheader, title, subtitle, and instruction text. The Instruction area of this section includes many text options that you can apply. If you would like to include blue text on your CRF, simply reference “Text color can be changed” in the Instructions cell of the Section worksheet of the attached CRF template and copy the formatting into your CRF.

CRF Text Tab
Click to enlarge

2. Response Options

This Section illustrates the various means of displaying responses on your CRF. It also provides additional features such as the “undo” button for deselecting a radio button, and an example of how to include a Visual Analog Scale. Again, simply reference the associated items in the Response Options section of the attached CRF template and copy the features you’d like into your CRF.

CRF Response Options
Click to enlarge

3. Layouts

The Layouts Section features different layout options such as column positions, horizontal vs. vertical checkboxes, and grid displays.

CRF Layouts
Click to enlarge

4. Required Items, Show/Hide, Decimals

This section demonstrates show and hide functionality, shows how real numbers (decimals) are displayed, and illustrates how required items are represented.

CRF Required Items
Click to enlarge

5. Validations This section demonstrates the various simple validations that are possible within the CRF template (less than, greater than, ranges, etc.). It also includes examples of some regular expressions.

CRF Validations
Click to enlarge

6. Calculations I

This is the first of two calculation sections. In this section, you’ll see examples of calculations and group calculations. You’ll have to upload the CRF, associate it with an event, and enter data to see the calculations in action.

CRF Calculations1
Click to enlarge

7. Calculations II

This second calculation section shows additional calculations and includes JQuery code for including a “calculate” button and for doing instant calculations. As above, you’ll have to upload the CRF, associate it with an event, and  enter data to see the calculations in action.

CRF Calculations2
Click to enlarge

8. Discrepancy Note*

The Discrepancy Note Section illustrates the effect of a Discrepancy Note Action Rule.

CRF Discrepancy Note
Click to enlarge

9. Show and Insert Actions*

This Section illustrates the effect of  Show and Insert Action Rules.

Before the rule is fired:                                            After the rule is fired:

CRF Action1                                CRF Action2
Click to enlarge

10. Email Action*

This Section illustrates the effect of an Email Action Rule.

CRF Email Action
Click to enlarge

*These last three Sections listed have Rules associated with them, and the Rules must be uploaded in order to experience the full functionality of these Sections. The Rules are also attached to this post.  If you want to use these Rules in your Study, be aware that you’ll have to edit them to reference the correct Object IDs for your Study.

So there you have it – one CRF, with everything but the kitchen sink. Check out the features and use them as you like. Just keep in mind that when designing CRFs, keeping it simple is always the best approach. There are times, however, when adding a little style to a form can help clarify things for data entry and may even help reduce discrepancies.

Happy designing!

Laura

Acknowledgements: Special thanks to Gerben Rienk Visser of Trial Data Solutions for many of these ideas, and to OpenClinica Application Support Engineer Jessica Gosselin for creating the Kitchen Sink CRF – we hope you find it useful!

OpenClinica Web Services Tutorial Videos

OpenClinica’s web services layer provides a powerful mechanism for programmatic data interchange between OpenClinica and other systems. Below are the first two videos in a series of tutorials on working with web services. The videos are created by Hiro Honshuku, including the background music! Thanks Hiro!





The OpenClinica Platform – Developer Round Table Discussions

OpenClinica is a clinical trial software platform that aims to provide data capture, data management, and operations management functionality to support human subjects-based research. It can be used for traditional clinical trials as well as a wide variety of other types of human subjects-based research.

Our vision for the product is to provide data capture, data management, and operations management functionality out-of-the-box, in an easily configurable, usable, and highly reliable manner. The underlying platform should be interoperable, modular, extensible, and familiar – so users can solve specific problems, in a generalizable way.

This past spring, the development team here at OpenClinica, LLC held a series of round table discussions about how this vision is reflected in the product. Our goals were to learn critical standards and information models needed for our technology to truly reflect this vision, to develop a consistent, shared vocabulary for the problem domain and the OpenClinica technology, and identify the most urgent opportunities to put these lessons into practice in the product and the community. In particular, we spent a lot of the time in these discussions about how OpenClinica’s use of the CDISC Operational Data Model helps enable this vision.

The discussions were invigorating and thought-provoking. We’ve recorded them to share with the greater community of OpenClinica developers, integrators, and others who want to better understand how the technology works, the design philosophy behind it, and where we’re going in the future. The videos are embedded below.

But before getting to the videos, here’s a bit more background on how we think about OpenClinica as a product and a platform.

First, OpenClinica functionality should be ready out-of-the-box, easily configurable and highly usable. Some of the most important features include:

  • Data definition and instrument/form design with no or minimal programming
  • Sophisticated data structures such as repeating items and item groups
  • Support for a wide variety of response types and data types (single select, multiple choice, free text, image)
  • Data management and review capabilities (including discrepancy management and clinical monitoring) with flexible workflows
  • ALCOA-compliant controls and audit history over all data and metadata, including electronic signature capabilities
  • Patient visit calendar design with management of multiple patient encounters and multi-form support
  • Reporting and data extract to a wide variety of formats (tab, SPSS, CDISC ODM)
  • Ability to combine electronic patient reported outcome (ePRO) data with clinically reported data using common form definitions (write once, run anywhere)
  • Deployment via multiple media, mobile or standard web browser

Many of these things have already been implemented, and more are under development.

The core concept around which OpenClinica is organized is the electronic case report form (CRF). In OpenClinica, a CRF is a resource that is essentially a bunch of metadata modeled in CDISC ODM with OpenClinica extensions. It doesn’t (necessarily) have to correspond to a physical or virtual form; it may represent a lab data set or something similar. An OpenClinica Event CRF is that same bunch of metadata populated with actual data about a particular study participant. Thus, it combines the metadata with the corresponding item (field) data, with references to the study subject, event definition, CRF version, and event ordinal that it pertains to. In this conceptual view of the world, CRFs (as well as CRF items, studies, study events, etc.) are resources with core, intrinsic properties and then some other metadata that has to do with how they are presented in a particular representation. Built around these core resources are all the workflow, reporting, API, security, and other mechanisms that allow OpenClinica to actually save you time and increase accuracy in your research.

Second, OpenClinica should be interoperable. The ultimate measure of interoperability is having shared, machine readable study protocol definitions, and robust, real-time, ALCOA-compliant exchange of clinical data and metadata that aligns with user’s business processes. It should be easy to plug in and pull out or mix-and-match different features, such as forms, rules, study definitions, report/export formats, and modules, to transport them across OpenClinica instances or interact with other applications. Establishing well defined methods and approaches for integration into existing health data environments is a key goal of interoperability.

Third, OpenClinica should be modular and extensible. OpenClinica already provides some of the most common data capture and data management components and aims to have a very broad selection of input types, rules, reports, data extracts, and workflows. However OpenClinica developers should also have the freedom to come up with their own twist on a workflow, module, or data review workflow and have it work easily and relatively seamlessly with the rest of OpenClinica. User identification, authentication, and authorization should be highly configurable and support commonly used general purpose technologies for user credentialing and single-sign-on (such as LDAP & OAuth).

The CRF-centric model allows us a great deal of flexibility and extensibility. We can support multiple modalities, with different representation metadata for rendering the same form, or perhaps the shared representation metadata but applied in a different way (i.e. web browser vs. mobile vs. import job). We can address any part of the CRF in an atomic, computable manner. This approach has been successfully applied in the Rule Designer, which takes the ODM study metadata and allows browsing of the study CRFs and items, with the ability to drag and drop those resources to form rule expressions. Features such as rules and report/export formats are represented as XML documents. These documents define how the features behave in standardized ways so that one rule can, say, be easily replaced with another rule without having to modify all the code that makes use of the rule.

Finally, OpenClinica aims to be familiar in the sense of allowing data managers, developers, statisticians to work in a design/configuration/programming environment that they already know. Programmers don’t all have the same experience, and it would be somewhat limiting to force OpenClinica developers to all use the same language (Java) that OpenClinica was written in. We are constantly looking at ways to make it possible (not to mention reliable and easy!) for users and developers to interact with and extend OpenClinica in a programmatic way. This can mean anything from data loading to more meaningful integrations of applications common to the clinical research environment. As proponents of open, standards-based interoperability, our starting point is always to develop interfaces for these interactions based on the most successful, open, and proven methods in the history of technology – namely the protocols that power the World Wide Web (such as HTTP, SSL, XML, OAuth 2.0). They are relatively simple, extensively documented, widely understood, and well-supported out of the box in a large number of programming and IT environments. On top of this foundation, we rely heavily on the wonderful work of CDISC and the CDISC ODM to model and represent the clinical research protocol and clinical data.

Session 1:  from 30-March-2012 (start at the 5 min 20 sec mark)

Session 2:  from 06-April-2012 (start at the 1 min 25 sec mark)

Session 2a:  from 20-April-2012

Session 3:  from 27-April-2012

Session 4:  from 11-May-2012

eClinical Integration

Increasingly I am seeing real momentum for reducing the costs and barriers to integration of eclinical applications and data in a way that benefits users.

A great example is a recent LinkedIn discussion (you may need to join the group to read it).  Several software vendors and industry experts engaged in a dialogue about the pros and cons of different integration approaches. There is an emerging consensus that integration approaches should adopt open, web standards and harnesses the elegance and flexibility of the CDISC Operational Data Model. This consensus may signal a sea change in attitudes to standards-based integration that makes it the norm rather than the exception.

This is not new to members of the OpenClinica community. Over the years we’ve had many examples of such integration efforts described on this blog and at OpenClinica conferences. To make such efforts more powerful, reusable, and robust, the OpenClinica team has invested a great deal over the past year to create a meaningful, CDISC ODM-based model for interacting with OpenClinica. We have incorporated open web standards (RESTful APIs for transport and OAuth for security) to make the interfaces easily accessible with commonly used software tools.  This is part of a newly published resource for OpenClinica development and integration, the OpenClinica 3.1 Technical Documentation Guide. The first version of the specification can be viewed at https://docs.openclinica.com/3.1/technical-documents/rest-api-specifications. I’ve reproduced the introduction here:

Overview

We are constantly looking at ways to make it possible (not to mention reliable and easy!) for users and developers to interact with and extend OpenClinica in a programmatic way. This can mean anything from data loading to more meaningful integrations of applications common to the clinical research environment.

As proponents of open, standards-based interoperability here at OpenClinica, our starting point is always to develop interfaces for these interactions based on the most successful, open, and proven methods in the history of technology – namely the protocols that power the World Wide Web (such as HTTP, SSL, XML, OAuth 2.0). They are relatively simple, extensively documented, widely understood, and well-supported out of the box in a large number of programming and IT environments. On top of this foundation, we rely heavily on the wonderful work of CDISC and the CDISC ODM to model and represent the clinical research protocol and clinical data.

This chapter describes a CDISC ODM-based way to interact with OpenClinica using RESTful APIs and OAuth. The REST web services API relies on HTTP, SSL, XML, OAuth 2.0. This architecture makes the ODM study protocol representation for an OpenClinica study available and supports other interactions for study design.

Why REST?

The OpenClinica RESTful architecture was developed to (initially) support one particular use case, but with the intention of becoming more broadly applicable over time. This use case is based on a frequent request of end users: for OpenClinica to support a visual method for designing, editing, and testing “rules” which define edit checks, email notifications, skip pattern definitions, and the like to be used in OpenClinica CRFs. Users have had to learn how to write rules in XML, which can be confusing and have a big learning curve for non-technical individuals. The OpenClinica Rule Designer is an application that allows end users to build cross field edit checks and dynamics within a GUI based application. It is centrally hosted Software as a Service (SaaS) based application available for OpenClinica Enterprise customers at https://designer.openclinica.com.

To support interaction of the centrally hosted rule designer with any instance of OpenClinica Enterprise installed anywhere in the world, we needed to implement a secure protocol and set of API methods to allow exchange of study information between the two systems, and do so in a way where the user experience was as integrated as if these applications were part of the same integrated code base. In doing so, and by adopting the aforementioned web and clinical standards to achieve this, we have built an architecture that can be extended and adapted for a much more diverse set of uses.

This chapter specifies how 3rd party applications can interact with an OpenClinica instance via the REST API and OAuth security, and details the currently supported REST API methods. The currently supported API methods are not comprehensive, and you may get better coverage from our SOAP API. However the OpenClinica team is continuing to expand this API and since it is open source anyone may extend it to add new methods to meet their own purposes. If you do use the API in a meaningful way or if you extend the API with new methods, please let others know on the OpenClinica developers list (developers@openclinica.org), and submit your contributions for inclusion back into the codebase – you’ll get better support, increased QA, and compatibility with future OpenClinica releases.

RESTful Representation, based on ODM

“REST”, an acronym for REpresentational State Transfer, describes an architectural style that allows definition and addressing of resources in a stateless manner, primarily through the use of Uniform Resource Identifiers (URIs) and HTTP.

From Wikipedia: A RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. It is a collection of resources, with three defined aspects:

  • the base URI for the web service, such as http://example.com/resources/
  • the Internet media type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid Internet media type.
  • the set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE).

REST is also a way of looking at the world, as eloquently articulated by Ryan Tomayko.

In the context of REST for clinical research using OpenClinica, we can conceptually think of an electronic case report form (CRF) as a resource that is essentially a bunch of metadata modeled in CDISC ODM with OpenClinica extensions:

  • Some of this metadata (data type, item name, response set, etc) is intrinsic metadata – i.e. tied to the definition of the CRF and its items and mostly unchangeable after it is initially defined.
  • Some of this metadata is representation metadata and used only when the CRF is represented as a web-based HTML form (in the OpenClinica database schema we call this form_metadata, but it also can include other things like CRF version information and rules).

An OpenClinica Event CRF is that same bunch of metadata with the corresponding item data, plus references to the study subject, event definition, CRF version, event ordinal, etc that it pertains to.

  • The notion of a CRF version pertains to the representation of the CRF. It is not intrinsic to the event CRF (this is debatable but it is how OpenClinica models CRFs). Theoretically you should be able to address and view any Event CRF in any available version of the CRF (i.e. http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v1/edit and http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v2/edit both show you the same data represented in different versions of the CRF). Of course the audit history needs to clearly show which version/representation of the CRF was used for key events such as data capture, signature, etc.
  • Rules are also part of the representation metadata as opposed to intrinsic metadata, even though you don’t need to specify them on a version-by-version basis.
  • Anything attached to the actual event CRF object or its item data – discrepancy notes, audit trails, signatures, SDV performance, etc is part of that event data and should be addressable in the same manner (e.g. http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v1/GROUPOID/ORDINAL/ITEM…)

In this conceptual view of the world, CRFs (as well as CRF items, studies, study events, etc.) are RESTful resources with core, intrinsic properties and then some other metadata that has to do with how they are presented in a particular representation. We now have a model that allows us a great deal of flexibility and adaptability. We can support multiple modalities, with different representation metadata for rendering the same form, or perhaps the shared representation metadata but applied in a different way. We can address any part of the CRF in an atomic manner. This approach has been successfully applied in the Rule Designer, which takes the ODM study metadata and allows browse of the study CRFs and items, with the ability to drag and drop those resources into rule expressions. Here are some examples of additional future capabilities that could be easily realized on top of this architecture:

  • Multiple data entry modalities – a user may need to deploy patient based data entry via web, a tablet, a thick client, or even paper/OCR, each with a very different presentation. Each of these may be part of OpenClinica-web or a separate application altogether, but all will rely on the same resource metadata to represent the CRF (according to the UI + logic appropriate for that modality), and use the same REST-based URL and method for submitting/validating the data.
  • Apply a custom view (an XSL or HTML/CSS) to a patient event CRF or full casebook – some uses of this could be to represent as a PDF casebook, show with all audit trails/DNs embedded in line with the CRF data, show a listing of data for that subject, provide (via an XSL mapping) as an XForm or HL7 CCD document for use by another application) – http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v1/view?renderer=somemap…
  • The same path used in the URLs, eg http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v1/GROUPOID/ORDINAL/ITEMOID could be used as the basis for XPath expressions operating on ODM XML representations of CRFs and of event CRF data
  • Internationalization – OpenClinica ought to allow our CRF representation metadata to have an additional sub-layer to render the form in different languages, and then automatically show the appropriate language based on client/server HTTP negotiation (like we do with the rest of the app). Currently internationalization of CRFs requires versioning the CRF.
  • View CRF & Print CRF – use the same representation metadata (form metadata) but apply slightly different rules on how the presentation works (text values instead of form fields, no buttons, turn drop down lists into text values)
  • Discrepancy manager popup – one requested use case would allow a user to update a single event CRF item data value directly from the discrepancy note UI point of view. In this case you could think of just updating that one item as addressing the resource http://oc/RESTpath/StudyA/Subj1234/VisitA/FormB/v1/GROUPOID/ORDINAL/ITEM…. In this model, whatever rules and presentation metadata need to get applied at presentation and save time happen automatically.
  • Import of CDISC ODM XML files – imported data would be processed through the same model, but only use the metadata that’s relevant to the data import modality. Same for data coming in as raw ODM XML via a REST web service. A lot of times the import only populates one part of a CRF and the other parts are expected to be finished via data entry. This model would help us manage that process better that the current implementation of ODM data import.

There are many considerations related to user roles and permissions, workflows, and event CRF/item data status attributes that need to be overlaid on top of this REST model, but the model itself is a conceptually useful way to think about clinical trials and the information represented therein. When implemented using CDISC ODM XML syntax it becomes even more powerful. As widespread support for ODM becomes the norm, the barriers to true interoperability – shared, machine readable study protocol definitions, and robust, real-time, ALCOA-compliant exchange of clinical data and metadata that aligns with user’s business processes – get eviscerated.

* This chapter frequently refers to ODM-based representations of study metadata and clinical data in OpenClinica. We strive as much as possible to implement ODM-based representations of OpenClinica metadata and data according to the generic ODM specifications (currently using ODM version 1.3). However, to ensure our representations support the full richness of information used in OpenClinica we often have to rely on ODM’s vendor extensions capability. We have not always made distinctions in this chapter as to where we are using ‘generic’ ODM versus OpenClinica extensions, but that is documented here. It is our goal as ODM matures and supports richer representations of study information to migrate our extensions back into the generic ODM formats.

** Also note the RESTful URL patterns referred to above are conceptual. Refer to the technical subchapters of this REST API specification for the actual URLs.

The spec (like much of the code that implements it) is open source. I’m looking forward to hearing comments and feedback, and sharing thoughts on how we can encourage broader adoption across different types of eclinical applications.

Thoughts on Code: OpenClinica and Open Standards with CDISC

One of the strengths of open source is the ability to open up the code base and learn by reading and doing, that is, the transparency of the code base allows everyone to get involved. However, the barrier to entry can be the complexity of the code itself; without a qualified guide, you can get ‘lost in the code jungle’ pretty quickly.

Welcome to our code

With that in mind, we are starting today to author blog posts about the OpenClinica code base, including topics like how the code is organized, what the code does, and so on. A lot more detail on this can be found on the OpenClinica Developer Wiki, but these posts, viewed as a whole, can be seen as a gentle introduction, before interested parties start to dive deeper.

When we began to design OpenClinica, we had very few requirements, but the desire  to create a fully-featured database for clinical data, aligned with open standards, making use of the best technology available. Call it the ‘tyranny of the blank page’, if you will. Every start-up faces it. Where do you start? What’s the plan? How do you build it, and what do you build first?

Luckily for us, we could use an open standard to base our schema, and our code, on top of; the CDISC ODM.

What’s a CDISC ODM?

The Operational Data Model, or ODM for short, is a standard published by the Clinical Data Interchange Standards Consortium (CDISC), and is “designed to facilitate the archive and interchange of the metadata and data for clinical research”, as it states in their website. This is a standard which is designed to a) hold metadata about a Study and all Events contained within a given Study, and b) hold Clinical Data which has been collected for a given Study. All of this information is held in XML, which is a very useful format for exchanging between sites, labs and institutions.

Figure 1: Study Metadata and OpenClinica

In the above image, you can see an XML file on one side using CDISC ODM and on the other side, an OpenClinica database. Inside the database are tables that map directly to different objects described in the XML. You’ll notice that the tables associated with study metadata also have a column called ‘oc_oid’, which are the Object Identifiers we use in all aspects of the OpenClinica application.

Figure 2: ODM Clinical Data and OpenClinica

In the second image, you see that the latter half of the XML file (the part  contained in the <ClinicalData> tags) also links to specific tables in the OpenClinica database. Since we link back to the Study metadata through those OIDs, we don’t use OIDs in those tables, but instead the conventional methods of primary keys and foreign keys in the database is good enough.

OK, so they map. But where’s the beef?

Of course, the ODM XML in the images is rather simple, and does not capture the full capability of the metadata that can be passed back and forth between different ODM data sources. For a longer example, you can take a look at the following XML, which defines the Rules governing a single Item:

Sample ItemDef in CDISC ODM XML

As you start to piece together the XML in the above example, you’ll see that not only can you define the Question in multiple languages, but you can specify which measurement it is using and what kinds of values you can accept.  The XML standard is extensible enough to add other pieces of information as well, including coded lists, data types, and so on.  More information can be found at XML4Pharma’s page entitled, ‘Using CDISC-ODM in EDC.’

In future posts, we hope to describe more about the code base, and show how it all comes together as a full-featured application. If there are topics that are of specific interest, we hope you’ll comment below and let us know what you’d like to see here in the coming months.

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.

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

eCTDs to get more important in 2008

In this past year, we worked hard to update the Electronic Data Capture facilities of OpenClinica; we also worked very hard to get OpenClinica internationalized, so that it could reach a wider audience in the OSS clinical research world.

One of the things that will be on the horizon for us now is improving data export.  And now is definitely the time for that; according to ClinPage, as of Jan 1st 2008 the FDA will accept electronic regulatory submissions in the form of the Electronic Common Technical Document (eCTD) only.

OpenClinica currently provides reports in several different formats, including the CDISC ODM format in XML, and we’ll be working to improve that over the coming months.  The change in the FDA’s standard is paving the way for all organizations, big and small, to find a way to submit documents electronically, and we hope OpenClinica will be able to play a part in providing a low-cost alternative to many organizations.  As the above ClinPage article points out:

….the major pharmas made the transition to electronic submissions years ago—in some cases, as early as the 1990s. They quickly earned a return on investments in better regulatory document systems, even though the technology was far more expensive then.

The situation is different for small pharmas and biotechs today, Perry says. They typically lack the manpower to attend to both routine regulatory work and manage the transition to a new system. He adds: “The purchase price of the system is not the obstacle. It is implementing. The smaller you are, the more desperately you need one of these, but the less people you have to implement them.”

Even as IT budgets may be getting smaller, as George Laszlo writes, the need to add the EDC system (and other systems) to an existing lab is getting bigger.  Through this blog, we hope to chart how health IT, and especially clinical research needs, can be met by implementing OpenClinica as a flexible, lower-cost solution.