Synchronizing OpenClinica Instances: Another Option for Using OpenClinica in Disconnected Settings

While tablet software maker Mi-Co is showcasing an integration of their Mi-Forms tablet-based forms software with OpenClinica that can be used in “offline” settings, elsewhere within the OpenClinica community, Raymond Omollo and Michael Ochieng have developed a separate option for using OpenClinica in settings without internet connectivity. Their method synchronizes multiple locally deployed instances of OpenClinica with a central OpenClinica database. Michael and Raymond recently presented their work at the OC13 conference. You can access their presentation slides here to see how they address key issues such as synchronization, back-ups, encryption, and user training.

Synchronization Flow Chart
Synchronization Flow Chart

While working for Drugs for Neglected Diseases initiative (DNDi), Michael and Raymond devised this approach for a WHO study of Buruli ulcers in West Africa (Ghana and Benin). The study, which is ongoing as of the date of this post, is a randomized controlled trial comparing the efficacy of 8 weeks treatment with clarithromycin and rifampicin versus streptomycin and rifampicin. It involves 430 subjects across 5 sites. The participating sites have limited or unstable internet connectivity, so a solution is needed that provided timely, auditable, and quality data entry given this constraint. A positive byproduct is enhancing the capacity of these disconnected sites to utilize EDC.

As they say, necessity is the mother of invention. And open source makes it easier for people to believe that what is necessary can in fact be accomplished. Kudos to Raymond and Michael for devising a solution that works for them. Perhaps it may work for others as well.  If you’d like to access the source code and documentation for their work, you can download these from the OpenClinica Tools and Tips page (scroll to bottom).  You can reach Raymond and Michael on the OpenClinica Developers mailing list: developers@openclinica.org.

– Ben Bauman

More About DNDi

Headquarted in Geneva, DNDi is a global organization that develops safe, effective, and affordable treatments for neglected diseases. The neglected diseases that DNDi tackles afflict many of the world’s poorest people (Malaria, Leishmaniasis, Chagas disease, Sleeping Sickness, Paediatric HIV, Filaria). DNDi’s goal to develop 11 to 13 new treatments by 2018. More at www.dndi.org.

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

OpenClinica at Society for Clinical Trials Annual Meeting (May 20-23, Miami)

OpenClinica will be both exhibiting and presenting at this year’s Society for Clinical Trials Annual Meeting, May 20-23 in Miami. Come by the OpenClinica booth to introduce yourself and learn about the many exciting things happening within the OpenClinica software and community! On Wednesday, May 23, OpenClinica’s, CEO, Cal Collins, will lead a presentation showcasing an innovative new OpenClinica mobile data capture technology. The session is titled “Electronic Patient Reported Data for Risk Screening in Primary Care Clinics using OpenClinica and CDISC ODM.”

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.

OpenClinica 3.1 Release Update

We are in the final development stretch of the OpenClinica 3.1 project.  Over the course of alphas and betas some items have been inevitably been added, removed, and changed, so I thought it would be useful to provide an up-to-date list of features and bugs that are being addressed in this release.

Those of you attending the OpenClinica Global Conference May 8-9 here in Boston will get to experience numerous demonstrations of 3.1 functionality, and of course get to interact directly with members of our rockstar development team 🙂

First, here’s a quick review of some of the more popular new features:

  • Dynamic items in a CRF
    • Supports showing and hiding of items based on values provided in a separate field
    • Supports insertion of data across fields and CRFs based on values provided in a separate field.
  • Re-factoring of the Extract Data module to support custom data transformations allowing you to extract data in essentially any conceivable format.
  • Improved capabilities for sharing data entry duties among a given site’s users
  • Discrepancy Note “Days Open” filter to better monitor discrepancy aging
  • Discrepancy Note “Days Since Updated” filter to ensure productive discrepancy resolution
  • Audit log and discrepancy note data included in ODM exports
  • Improved CRF page turn time (in many cases over 10x faster)
  • CRF Header updates to provide a cleaner data entry experience
  • Ability to assign Failed Validation Checks (in addition to Queries)
  • Relative Paths for Item OIDs in Rules to enable portability and reusability of Rules
  • Discrepancy Note flag colors now appear in the CRF
  • Additional study parameter configuration options to opt out of using certain fields such as Interviewer Name, Interview Date, and Location
  • OpenClinica Datamart for ad-hoc reporting (Enterprise only)
  • GUI Based, drag-and-drop Rule Designer (Enterprise only)

More detailed descriptions of the above features can be found in the previous blog posts “OpenClinica 3.1 (project “Amethyst”) Preview” and “New Capabilities Added to OpenClinica Version 3.1.”

For those sufficiently ambitious, yes, you can see a complete list of ALL the 457 separate enhancements and bug fixes in 3.1 as of April 6, on the OpenClinica Amethyst Project Roadmap.

And finally, here’s the current release timeline:

  • Beta 4 released week of April 11th
  • Release Candidate 1 released week of April 18th
  • Production Release of OpenClinica 3.1 early May.

Many thanks to the dedicated team of folks who, for the past 19 months, have worked tirelessly to make this the most significant OpenClinica release ever.

– Paul

OpenClinica 3.1 Release Timelines; Call for Pilot Program Participants

Last week I wrote about a few new features that will be part of the forthcoming OpenClinica 3.1 release and promised some information about when we expect to make different phases of the application available. Here is the release timetable we are currently targeting:

  • Alpha Release – June 21st, 2010
  • Beta I – July 9th, 2010
  • Beta II – August 2nd, 2010 (OpenClinica 3.1 Pilot Program)
  • Beta III – September 1st, 2010
  • Production Release – End of September/Beginning of October

The first Alpha release will contain, among other items, the following features mentioned in my previous blog post:

  • Dynamics (Show/Hide/Insert Actions)
  • Relative paths for OIDs
  • Multiple site level users accessing a CRF before it is marked complete
  • Modularization
  • Audit Log and Discrepancy Note Data with ODM Export
  • Discrepancy Note Flag Colors

We will try to also provide some concrete instructions on how to use each of these features before the Alpha is released. Updates to these instructions and additional documentation will be generated after the Alpha has been made available for downloading.

3.1 Pilot Program

As in prior releases, we will be conducting a Pilot Program with selected interested organizations. If you are interested in participating in the OpenClinica 3.1 Pilot Program (or just want more information about it), please send an email to contact@akazaresearch.com.  The Pilot Program is designed to give organizations an opportunity to test out new features of OpenClinica and provide valuable feedback on how the features are working. It was very successful prior to releasing 3.0 where 10 participating organizations received help and support from Akaza while experiencing and learning the new product features firsthand.

– Paul Galvin

OpenClinica 3.1 (project “Amethyst”) Preview

The next major milestone for OpenClinica (project code-named “Amethyst”) will be OpenClinica version 3.1. While this release contains roughly 85 tweaks, fixes, and enhancements, this post describes some of the more significant enhancements that will be included (check out the Amethyst project roadmap page for a full list—note: openclinica.org login required).

New features in OpenClinica 3.1 will include:

  • Dynamic Items in CRFs
  • Audit Log and Discrepancy Note Data with ODM Exports
  • Assignment of Failed Validation Check Discrepancy Notes
  • Relative Paths for Item OIDs in Rules
  • Discrepancy Note Flag Colors in the CRF
  • Modularization
  • Multiple Site Level Users Allowed Access to an Event CRF
  • Simple Conditions

Dynamic Items in CRFs

OpenClinica 3.1 will support Showing and Hiding of CRF Items using both the CRF template and a Rules file. When a user enters data and saves a CRF section, data fields may be shown or hidden based on value(s) that user provided in one or more other fields on that form. This capability is also commonly referred to as “skip patterns.” A simple example would be a CRF question asking if the patient is male or female. If the value provided is female, a pregnancy related question could then be displayed to the user entering data and all questions associated with males could be hidden from view.

Audit Log and Discrepancy Note Data with ODM Exports

Audit Log data and Discrepancy Note data for a subject will be available in the ODM data extract format with OpenClinica extensions. This will allow the user to have all of the clinical data, audit log data, and discrepancy note data in a single data file.

Assignment of Failed Validation Check Discrepancy Notes

Currently, OpenClinica supports assignment and workflows around only the Query type of Discrepancy Note. OpenClinica’s “assignment” capability will be expanded to also include the Failed Validation Check type of Discrepancy Note. For Failed Validation Checks, the first note in the Discrepancy Note thread will not be assigned, but Data Managers, Study Directors and Monitors will be allowed to assign the thread to a user for review/resolution. OpenClinica will also restrict the Clinical Research Coordinators and Investigators (both site-level users) from setting the status of Failed Validation Checks to Closed.

Relative Paths for Item OIDs in Rules

A new enhancement to Rules authoring will allow the Rule creator to write one Rule Assignment for a particular CRF Item, and have the Rule execute wherever that Item’s OID is used throughout all of the study events. This increases the “portability” of rules, allowing the user to write one Rule, and have it apply multiple times rather than having to author multiple Rules and multiple Rule Assignments.

As an example, a Rule Assignment would need to contain the following path in OpenClinica 3.0.x:

SE_OBSERVAT[ALL].F_GROU.IG_GROU_GROUP_1[ALL].I_GROU_TC_ADV_PRIMARY_05

If the CRF was used in multiple events, the creator of the Rule file would have to specify the path to the other event as well.

In 3.1, all the user has to do is write:

I_GROU_TC_ADV_PRIMARY_05

and the Rules will be executed wherever that Item shows up in the study.

Discrepancy Note Flag Colors in the CRF

OpenClinica 3.1 will include additional Discrepancy Note flag colors that correspond to the various statuses of a particular thread. Currently in OpenClinica, if a Discrepancy Note thread exists, the flag will always display in a red color regardless of the Discrepancy Note status. In 3.1, the color of the flag will be reflect the “most severe” status of any thread that is on a particular item (more than one thread may exist for any item). For example, if there is a Closed thread and an Updated thread on one item, the color of the flag will be yellow representing the Updated status. If there is just a Closed thread, the color of the flag will be black. To support people who are color blind or shade blind (like myself) there will be a roll over when you put your mouse on the flag, showing you the number of threads and each of their statuses when Viewing a CRF.

Modularization & New Web Services

Modularization is defined as a software design technique that increases the extent to which software is composed from separate parts, called modules. Conceptually, modules represent a separation of concerns, and improve maintainability by enforcing logical boundaries between components.

What this means for OpenClinica is we have started to separate the application into multiple pieces. In version 3.1, we have modularized the web application from the web services functionality. This will allow new web services to be developed on separate release timelines from the main web application, facilitating the system’s extensibility.

In addition, we are release some web services with 3.1, (these were contributed by Colton Smith of Geneuity and openXdata):

  • CRF Data Import
  • Retrieve a list of studies
  • Retrieve a list of events and their CRFs
  • Retrieve a list of subjects and their events

Multiple Site Level Users Accessing an Event CRF

OpenClinica 3.1 will allow different site level users access to an Event CRF, even if they are not the conceptual “owner” of that CRF. In prior versions of OpenClinica, once a user began data entry in a CRF, the system prevented other users from adding information or data to the CRF until it had been marked complete. The new feature will allow a second user to continue entering data before the CRF is marked complete.

This change to OpenClinica will also help facilitate the ease of recording adverse events in a separate CRF. A user will not have to mark it complete in order for another user to provide additional adverse events that have occurred for a particular subject. In addition, this new functionality will prevent users from accessing an Event CRF if another user already has the form open. In this case, the second user will receive a message saying that the form is currently being accessed by another user.

Simple Conditions

In addition to the Dynamics capabilities that will be part of 3.1, we have added a feature called Simple Conditions. This feature is similar to Dynamics in many ways, but can be implemented through the CRF Template directly rather than writing a separately Rules XML document.

With Simple Conditions, a person creating an OpenClinica CRF will have the ability to designate Items as “hidden” from the data entry person’s view until a particular option is chosen for another CRF Item. The data entry person will not have to click “save” on the form–instead, as soon as the option is selected, this hidden field will be shown in real time.An example of the type of use case this feature targets, is a CRF question with two fields, one for “race” and the other for “comments” (which is hidden). If the data entry person selects the value of “other” for the race field, the hidden comments field will be display underneath.

Akaza Research is excited about bringing OpenClinica 3.1 to the community! Your comments and feedback are appreciated. Please check back in next week or so for an update on our timelines for Alphas, Betas and a Production release.

An Opportunity for Transformational Change in Clinical Trials

Life sciences research is recognized as one of the most technologically advanced, groundbreaking endeavors of modern times. Nevertheless until very recently the preferred technology for executing the most critical, costly stage of the R&D process – clinical trials – has been paper forms. Only in 2008 did adoption of electronic alternatives to paper forms take place in more than half of new trials. This recent uptick in adoption rates is encouraging, but further transformational change in the industry is necessary to fully realize the promise of Electronic Data Capture (EDC) and associated “eClinical” technologies. Two developments that could provide the framework for such change are adoption of open data standards and the use of Open Source Software.

Data standards provide uniform ways to represent information or processes within a specific frame of reference and according to a detailed specification. A standard is “open” when it is not encumbered by patent, cost, or usage restrictions. Open Source Software (OSS) is defined loosely as software that allows programmers to openly read, redistribute, and modify the source code of that software. The combination of OSS and open standards is a proven way to deliver improved flexibility, quality, and efficiency.

A community-driven open source offering that harnesses open standards can produce robust, innovative technology solutions for use in regulated clinical trial environments. Most Open Source Software is built using a collaborative development model. The OSS development and licensing model encourages experimentation, reduces ‘reinvention of the wheel’, and allows otherwise unaffiliated parties to build on the work of others. The result is that OSS can become a key driver of increased IT efficiency and a way to wring out unnecessary costs. In many cases, users can have the best of all worlds: the ability to adopt software rapidly and at low cost, the flexibility to develop and extend their systems as they choose, and the ability to reduce risk by obtaining paid commercial-grade support.

As clinical research struggles to become more automated and efficient, we need to rely on interoperable systems to meet challenges of flexibility, quality, and speed. The OSS development model also naturally leads to the adoption of well-documented, open standards. Because OSS product designers and developers tend to reuse successful components and models where available, OSS technologies are often leading implementers of standards. For example, the National Cancer Institute’s Cancer Bioinformatics Grid (caBIG) initiative is “designed to further medicine’s potential through an open source network” based on open data standards and infrastructure that support sharing of heterogeneous data. This remarkable effort aims to connect large networks of researchers in ways that enables efficient re-use of data, eliminates duplicate systems, and enables new types of translational research.

In industry-sponsored clinical trials, standards such as the CDISC Operational Data Model (ODM), Clinical Data Acquisition Standards Harmonization (CDASH), and Study Data Tabulation Model (SDTM) have gained adoption in both proprietary and OSS software platforms. In some cases, standards are mandated for regulatory submission and reporting (SDTM, clinicaltrials.gov) and obviously must be adopted. Other cases, such as use of ODM, CDASH, and general web standards such as web services and XForms tend to be adopted to the degree they have a compelling business case.

The business case for standards centers on increasing accuracy and repeatability, enabling reuse of data, and enhancing efficiency by use of a common toolset. A well-designed standard does not inhibit flexibility, but presupposes idiosyncrasies and allows extension to support ‘corner cases’. Leading industry voices share compelling arguments how to use standards such as ODM, CDASH, XForms, and Web Services to achieve these goals. Though the details are complicated, the approach offers orchestration of disparate applications and organization of metadata across multiple systems. There is change control support and a single ‘source of truth’ for each data point or study configuration parameter, so when study designs change (as they inevitably do) or a previously committed data point is rolled back, it is automatically shared and manual updates to systems are not necessary. Because the ODM, CDASH, and SDTM are used as a common “language”, the systems know the meaning and structure of data and can process transactions accordingly. Here’s a tangible example:

Lets imagine an IVR system wanted to check with an EDC system if a subject was current in a study (current meaning not dropped out, early terminated or a screen failure).  A Web Service could be offered by the EDC system to respond with a ‘True’ or ‘False’ to a call ‘IS_SUBJECT_CURRENT’ ?  Of course hand-shaking would need to occur before it hand [sic] for security and so on, but following this, the IVR system would simply need to make the call, provide a unique Subject identifier, and the EDC system web service would respond with either ‘True’ or ‘False.  With Web Services, this can potentially occur in less than a second.

Electronic Data Capture – Technology Blog, September 28, 2008

While this integration requirement could be satisfied by development of point-to-point, proprietary interfaces, this approach is brittle, costly, and does not scale well to support a third or fourth-party system participating in the transaction. It is critical that standards be open so that parties can adopt and implement them independently, and later interface their systems together when the business case calls for it. A leading industry blogger makes the case for the openness of standards within the ODM’s ‘Vendor Extension’ architecture: ”The ODM is an open standard, the spec is available for free and anyone can implement it. This encourages innovation and lowers the barriers to entry and therefore costs. Vendor Extensions are not open, the vendor is under no obligation to share them with the market and the effect is that meta-tools and inter-operability are held back.”

Having the software that implements these standards released as open source code only strengthens its benefits. Proprietary software can implement open standards, however given the proprietary vendor’s business interest to lock-in license revenue, might the vendor be tempted into tweaking or ‘extending’ the standard in a way that is encumbered to lock users into their platform? This strategy of “embrace, extend, extinguish” was made famous in the Microsoft anti-trust case of the 1990s, where it came to light that the company attempted to apply these principles to key Internet networking protocols, HTML and web browser standards, and the Java programming language. They hoped to marginalize competing platforms that did not support their “extended” versions of the standards. Thankfully, they had limited success in this effort, and the Internet has flourished into the open, constantly innovating, non-proprietary network that we know today. The eClinical technology field is at a similar crossroads. By embracing open standards, and working concertedly to provide business value in re-usable OSS technology, we can achieve a transformation in the productivity of our clinical technology investments.