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.