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!

Automatic Event Scheduling with OpenClinica 3.3

An exciting new feature that has been at the top of the request list is Event Scheduling. Using the flexible and powerful Rules Designer in version 3.3, you can now build rules to automatically schedule events.

There are several workflow methods which offer a customized way of handling your study calendar.

Method 1 – Manual Reschedule

In Method 1, a series of study events can be scheduled at once off a given event date.  Any subsequent changes to event dates will not be automatically rescheduled. You can use arithmetic to generate future event dates (e.g. Visit 2 date = Visit 1 + 7).  OpenClinica also supports use of static dates and the system’s “current date” variable.

MethodOne

Method 2 – Auto Reschedule

In Method 2, a given event date generates all future visits and any changes to an event date in the chain will automatically update subsequent event dates.

MethodTwo

Method 3 – Auto Reschedule Based on Event Status

OpenClinica also allows you to write EventAction rules using the event STATUS. This opens the door to more calendaring power! Here, you can schedule an Event based on the status of another Event. For example, if a critical visit is skipped the system can auto-schedule the End of Study visit. Or let’s say you only want the next event to be scheduled when the current event is “Completed” (or “Started”). This is all possible–it’s really up to you.

MethodThree

Rule Designer Example

See the following example of scheduling the next event with Rule Designer.

EventActions_Rules

If you haven’t heard, the OpenClinica Rule Designer is now freely available. See http://wp.me/p6ydw-rE for more details.
Learn more about Event Scheduling with Rule Designer HERE.

New! OpenClinica 3.1 “Gap” Training

We are excited to announce a new course designed to get you up to speed with the new changes in OpenClinica 3.1.  “OpenClinica 3.1 Gap Training” is a 4-hour course delivered via the web providing an in-depth overview of changes in existing functionality from OpenClinica v3.0 to v3.1 as well as formal instruction on the brand new features in 3.1.  Particular emphasis is placed on the new functionality for Dynamic logic and new Rules capabilities. Topics covered include:

  •     Dynamic Logic with Rules
  •     Simple Show/Hide in CRFs
  •     Additional Rules improvements
  •     Extract Data module changes
  •     Changes and enhancements to Notes & Discrepancies
  •     Changes in site level user to enhance access to “started” CRFs
  •     Rules Designer
  •     Data Mart
  •     Modularization

For course times, pricing, and registration, see https://www.openclinica.com/open-enrollment-training.

Course duration: approximately 4 hours
Delivery medium: online/web meeting

Note: While open to all, this course is intended for people who have received prior formal OpenClinica training and/or have significant experience with OpenClinica 3.0.

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.

OpenClinica 3.1 is Finally Here!

After nearly 20 months, OpenClinica 3.1 is finally ready to meet the world as a production ready application.  You may download OpenClinica 3.1 here.  It has been a long and arduous road, but the final incarnation of 3.1 is the most significant leap forward for the OpenClinica clinical trials software.

OpenClinica 3.1 further accelerates clinical productivity and enhances the clinical trial experience in a number of notable ways:

  • Improved data entry save time and increased performance for accessing large amounts of data.  The architecture around the data entry process in OpenClinica was re-factored to allow more concurrent users accessing the system while conducting more intensive simultaneous processes.  With this re-factoring, page turn times have seen a 10x (and sometimes better) speed improvement.  At the same time, large extracts which had to be broken into smaller subsets in the past can now be executed in a single batch.
  • Skip logic to ensure data entry users only see CRF fields and sections relevant to entering their data.  When a user accesses an eCRF to enter data for a patient or subject, they will only see the fields pertinent to be collected at that time.  Logic can be built in to the eCRF to show or hide additional fields based on the values provided in previous questions.
  • Streamlined discrepancy and query management infrastructure that allows issues around questionable data to be resolved more quickly.  A new interface for creating and responding to discrepancies, as well as new filters for query aging, to support faster resolution of data issues.  The number of clicks for filtering/sorting discrepancy notes, viewing the data responsible for the discrepancy note, and returned back to your filtered set of reports has been cut in half.
  • GUI-based creation, testing, and management of complex cross field/cross form multivariate edit checks.  A simple drag and drop interface has been implemented to facilitate the faster creation of complex edit checks.  This new interface interacts with authorized OpenClinica instances to speed up the study design process for OpenClinica Enterprise edition clients.
  • Plug-in architecture for exporting data collected in OpenClinica which supports the transformation of data into any output format.
  • OpenClinica Data Mart to easily report clinical trial results collected through OpenClinica.

These last two items have been covered extensively in previous blog posts.  Please see Plug-in Architecture for OpenClinica Data Extracts and Video Demo of New OpenClinica Data Mart.

We will be hosting an OpenClinica Community Virtual Forum shortly to demonstrate some of these new capabilities.  Also, keep this blog on your RSS feed or bookmarked in your browser, as future posts will dive into more details of the new features and functionality in OpenClinica 3.1.

– Paul Galvin

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

New Capabilities Added to OpenClinica Version 3.1

For the past 12 months, the OpenClinica development team has been working diligently on the next major OpenClinica release. In a prior blog post (OpenClinica 3.1 (project “Amethyst”) Preview), I discussed some of the new functionality and key improvements this forthcoming release will include. Since then, the development team has added some more pieces of functionality, most notably:

  • Re-factoring of Extract Data to enable custom data transformations
  • Discrepancy Note “Days Open” filter
  • Discrepancy Note “Days Since Updated” filter
  • CRF Header updates
  • Additional study parameter configuration options
    • Interviewer Name – not used
    • Interview Date – not used
    • Location – not used
  • OpenClinica Data Mart for ad hoc reporting*
  • GUI-based Rules designer*

Custom Data Transformations

From a development perspective, perhaps the most significant piece of functionality in the above list is the complete re-factoring of the Extract Data module. In prior versions of OpenClinica, the Extract Data module would natively export CDISC ODM 1.2, CDISC ODM 1.3, both ODM 1.2 and 1.3 with OpenClinica extensions, tab-delimited text, and an SPSS file format. While these formats will continue to be available in 3.1, OpenClinica will have the ability to process (via XSL style sheets) any CDISC ODM 1.3 data set into any other data format.

This new XSL method of extracting data from OpenClinica opens up a new world of formats in which data may be obtained from OpenClinica. To create a new extract format, all one has to do is configure a new XSL style sheet. Organizations can write their own XSL style sheets then configure a file called extract.properties that allows OpenClinica’s XSL transformation engine to convert the data in the ODM XML file into the organization’s desired format.

GUI-based Rules Designer*

The GUI-based Rules designer is a project currently underway that allows users to build cross-field/cross-form multivariate edit checks without having to interface directly with XML. Its intuitive, drag and drop interface hides much of the current complexity in creating and managing Rules, while retaining the system’s robust capabilities in this area. Users will be able to work directly with the Item Names as defined in a CRFs definition, eliminating the need to keep track of OIDs.

OpenClinica Data Mart*

The OpenClinica Data Mart presents clinical data from OpenClinica studies in a readily-accessible relational database for ad hoc reporting and analysis. The Data Mart enables data managers, project managers, and researchers to create reports and mine data using standard business intelligence software or SQL reporting tools

Beta Timeframe

We currently expect the first Beta of 3.1 to be available towards the end of November. This Beta will be feature complete, and blocking issues that prevent the testing of new features will have been resolved. Once the first Beta is released, we will begin the 3.1 Pilot Program. We currently have 10 organizations participating in the Pilot Program, but if your organization would like to volunteer as well please contact me.

Please be sure to check back the OpenClinica Blog often as I post future updates on the 3.1 timelines.

– Paul Galvin, OpenClinica Project Manager

_________________

*Both the GUI-based Rules designer and Data Mart will be Enterprise only applications and will not be part of the publicly released 3.1 Beta.

OpenClinica 2.5 Release

We are getting very near to the release version 2.5 of OpenClinica, representing a major milestone in the development of the popular open source software for electronic data capture (EDC) and clinical data management. The release contains a number of exciting improvements, including:

–    Rules engine for executing cross-field or cross-form edit checks and triggering notifications to users
–    Scoring calculations (derived values) in case report forms (CRFs)
–    New user roles for monitors and data managers
–    Improved monitoring/query management tools and discrepancy note reporting
–    Electronic signature capabilities
–    Ability to copy and edit previously created datasets
–    Improved auditing and logging capabilities
–    Simpler CRF upload
–    Improved support for CDISC ODM v1.3
–    Support for Oracle DB Backend out of the box.
–    Minor UI and application fixes from OpenClinica 2.2
–    Improved performance and scalability

Over the past 6 weeks the core development team has been putting OpenClinica through a rigorous, validated, QA and testing procedure. There are roughly another 3 weeks of documented testing ahead of us. If you would like to try the latest beta version of the application, please download it from http://svn.akazaresearch.com/OpenClinica-2.5-distros/.

Thanks to everyone in the community who has contributed to this release and provided feedback during the alpha and beta periods!

As we get closer and closer to the production release of OpenClinica 2.5, stayed tuned to this space for additional updates.