Getting reluctant clinical research sites to embrace technology such as electronic data capture (EDC) software can be difficult. This is a recipe for troubled relationships between the sponsor/CRO and sites. However, just as it is possible for a poor EDC implementation to erode sponsor-site relations, it is also possible for the EDC software to help cultivate improved relationships. Take a look at the new whitepaper, “Improving Site Relationships through EDC” to learn about some important considerations when thinking about site relations in the context of EDC.
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!
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)
Yet another conference! Representatives from Akaza Research will be exhibiting and demonstrating OpenClinica at the MAGI Clinical Research Conference, May 23-26 at the Boston Sheraton hotel. If you’ll be attending be sure to drop into the exhibit hall and say hello to the nice people at the OpenClinica booth 🙂
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 firstname.lastname@example.org. For more information about the OpenClinica Virtual Forum, see https://www.openclinica.org/dokuwiki/doku.php?id=publicwiki:virtualforum:start.
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.
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.
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.
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.
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.
Welcome to Part II of the OpenClinica 3.0 features! I previously wrote about three of the main features for 3.0, Source Data Verification, new User Interface for navigation in the system, and a new Home Page for each user.
This post is about three additional features: (i) the new Build Study module, (ii) setting the length and significant digits of items, and (iii) the improved performance of the Subject Matrix.
In 3.0, all the study build tools will accessed from one main page following a task-based approach. There are five tasks available to the user at the outset. Once the user finishes these first five tasks, two more tasks will become available (see image). This allows the complete study from CRFs to event definitions to sites to assignment of users be done all from a single page. There is also a checklist to let the user easily see how many tasks have been completed so they know how much more configuration is needed before the study is ready to start enrolling subjects.
OpenClinica 3.0 also allows the creator of CRFs to set the allowable length of text fields including the number of decimal places a REAL number should be rounded to. This parameter is set in the OpenClinica CRF Template in a new field called Width_Decimal. The user will specify the width and decimal for a particular field which will force the user to enter the most precise data as possible in a CRF. No longer will the system round to the 4th decimal place at all times and allow up to 255 characters in the field if the CRF creator does not want them to. For example, the creator could specify that a field should have no more than 5 digits total with a maximum of 1 decimal place by entering 5(1) in the Width_Decimal column of the OpenClinica template. If the data entry person tried to enter 3.4444 or 678913 they would told the value is invalid.
By providing this functionality, OpenClinica will help the users get their data into SAS and SPSS more easily.
One of the most important and information-rich pages in OpenClinica is Subject Matrix page, and OpenClinica 3.0 provides significant performance enhancements on this page for studies with large numbers of of subjects. From the Subject Matrix page users can see a snapshot of where the subjects are in the study, schedule a new event, view a subject record, view a subject event, enter data in a CRF and sign a subject’s record without having to navigate to different pages in this system. A number of users were reporting sluggish performance with the Subject Matrix when they had 5000 or more subjects enrolled in a study.
OpenClinica 3.0 utilizes a new table structure that allows users to load the Subject Matrix containing over 10,000 subjects and 15 event definitions in fewer than 5 seconds (this process could take upwards of a minute in previous releases of OpenClinica).
Please feel free to download the Beta version of OpenClinica 3.0 at http://svn.akazaresearch.com/OpenClinica-3.0-distros/.
We have been working hard on OpenClinica 3.0 for the last 9 months and are getting closer and closer to a production release ready for use in live clinical studies. In the meantime, I wanted to talk about some of the new features over the next few weeks to let folks know what is coming.
OpenClinica 3.0 is sure to bring a lot of excitement to all users of the rapidly growing open source electronic data capture system. A lot of focus in this release has been put on the way trial sponsors use an EDC system and I’d like to point out some of the new features that should enhance their user experiences.
OpenClinica 3.0 will provide a new home page to study-level users providing key information about the progress of a study. These users will be able to see a summary of the subjects enrolled at each site compared to their expected total enrollment as well as the overall subject enrollment for the complete study. Also, these study-level users will be shown a count of the number of study events that are in a particular status. A summary for the number of subject statuses will be displayed so the study-level user can easily see how many subjects are signed, source data verified etc.
OpenClinica 3.0 will provide monitors a workspace to source data verify subjects and their data. The workspace will allow users to source data verify information collected at each visit one-by-one, or verify the information in a bulk process. These two options allow the monitors to perform remote source data verification daily for subjects in the study. Or, if the monitor has to be on site to review and verify information, he/she can go back to their hotel room and check-off verification for many subjects and events at once so they do not have to go one-by-one through every subject and event CRF.
The top-level navigation in OpenClinica 3.0 has been streamlined so site users of the application understand exactly what they have to do after they login. A new home page for investigators and clinical research coordinator users will show the number of queries assigned to them with a link to see every Query assigned them. The home page will show the 5 most recent queries to give the user an idea of what they need to respond to that day.
The new navigation points to the 3 main actions the site users should take. The “Subject Matrix” link will bring them to the new and improved subject matrix in OpenClinica. This matrix will allow users to easily add subjects, schedule events and even enter data from a single, powerful screen. The “Add Subject” link will bring them to a page where they can add a new subject to the study. “Notes & Discrepancies” will bring them to a page where they can see all the queries for their site and allow them to provide a response.
Above is just a small sample of the new features in OpenClinica 3.0. Like I said, I will plan on posting additional features once a week so be sure to check back often. In the meantime, please feel free to download the alpha2 at http://svn.akazaresearch.com/OpenClinica-3.0-distros/.
– Paul Galvin