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!

The Evolution of Electronic Data Capture

OpenClinica was recently featured in an article in Genetic Engineering and Biotechnology News titled “Commandeering Data with EDC Systems,” written by Dr. James Netterwald. The article briefly recounts the early days of clinical trial Electronic Data Capture (EDC). But how far have we come? Dr. Netterwald’s title (perhaps unintentionally) conjures up images of struggle and strife, which may be perhaps more a more apropos description of the journey of Electronic Data Capture than it may first appear.

As an industry, it’s taken us a good 20 years to get to where we are, and to be plain, it’s been a slow start. (In my own defense, I, and my company Akaza Research, have only been a party to the industry for the last 5 of those 20 years.) Climbing the evolutionary ladder from shipping laptops to sites to keying data into electronic case report forms is certainly progress by any measure. However, while the days of mailing tapes and disks are over, the days of real electronic data capture are yet to come. Today, most experts agree that somewhere between only one-half and two-thirds of all new clinical trials use EDC software, an of this only a very small fraction are “e-source,” defined as collecting data in electronic form at its source as opposed to keying it in from some other source. In some ways it is ironic that cutting-edge biopharmaceutical technologies are developed themselves with technologies that are, relatively speaking, much further down the technology food chain.

Notwithstanding, there are some enterprising few who have pushed the pace towards true EDC. Spaulding Clinical, a large phase 1 unit in West Bend, Wisconsin has developed a system that automatically captures ECG data from their facility’s patients and directly populates the clinical trial database with these data. A patient wears the ECG device and the data are transmitted wirelessly to the EDC system. However, this slick and highly productive solution was not developed by either the ECG vendor or the EDC vendor. It was developed by hand by one of Spaulding’s own software developers.

Why isn’t this type of solution more commonplace in clinical trials? What prevents the industry from making the most of today’s information technology? With the strong incentives currently in place to make research more efficient, our field could certainly benefit from some more forward thinking.

– Ben Baumann

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.

Trial Sponsors and Their Contract Labs: Better Collaboration via OpenClinica

At Geneuity Clinical Research Services, we do lab tests for trial sponsors. As readers of this blog know, we use OpenClinica internally as an LIS (laboratory information system), but as more and more drug companies and CRO’s adopt OpenClinica we foresee the day when we will be using their installations as our LIS, not ours.  A common platform will eliminate lots of duplicated effort and will allow for real-time transparency and better collaboration.  But it will also require sponsors to design their CRF’s with their contracting laboratories in mind.  In this article, we describe how this could be done.

First, consider specimen collection and tracking.  Normally, trial sponsors don’t consider doing this within the context of OpenClinica.  But they should.  Let’s say a specimen accidentally thaws in transit between the collection site and the contract lab.  Shouldn’t that fact be summarily recorded in the same context as the resulting lab test whose value may ultimately be reported to the FDA?  I should say so.

So, can OpenClinica be configured to do this? Yes and easily. A separate CRF dedicated to specimen collection could be designed and assigned to each event.  Alternatively, a specimen section could be added to already existing CRF’s.  Either way, fields for such things like accession number and specimen type could then be included.  These would be filled in by site personnel responsible for specimen collection.  Additional fields like ‘shipping deviations’ and ‘laboratory receipt date’ could also be included and would be filled in by lab personnel upon specimen delivery to the testing lab.  When it comes time for data analysis, the sponsor can use OpenClinica’s data export capabilities to exclude or include those lab results with shipping deviations and to investigate the consequences.

Other important aspects of specimen collection include printing labels to barcode samples and generating an attendant paper manifest (know as a requisition) against which labs can check incoming shipments of specimens.  OpenClinica can’t do such things currently.  It would require a whole new software module, but lots of added value could be achieved if one were written.  For instance, one can envision that after accessioning a specimen, site personnel could print a corresponding requisition from the same application window.  Also, imagine the time savings if lab personnel could conveniently print barcode labels after receiving a specimen and recording its receipt date and shipping deviations (if any).  And because the paper requisitions would be generated within the context of OpenClinica, subsequent source data verification by lab personnel could be expedited using QR-encoded URL’s that drill-down into the patient-event matrix. For more on this, see here.

Specimen tracking is just part of the story when it comes to sponsors and their contract labs.  Getting lab data from the laboratory testing platform into OpenClinica is another.  Recently during OpenClinica’s March 22 Global Conference in Bethesda, Akaza Research and Geneuity did a live demonstration of how this can be achieved using a set of MirthConnect channels. A batch of raw lab data keyed only to accession numbers was sent from Geneuity’s corporate headquarters in Maryville, TN to a remote OpenClinica installation hosted at Akaza’s Waltham, MA facility where it was inserted into the database programmatically via an awaiting web service. The insertion was streamlined, secure and seamless.  When setting up a trial, sponsors should think about the lessons this demo provides and consider distributing already configured and validated MirthConnect channels to their contract labs.  In this way, sponsors can control how their data is treated and understand every detail of its electronic provenance. And because MirthConnect can be configured to store its history, the trial’s audit trail can be extended upstream to the data’s very source.
Finally, consider invoicing.  Contract labs have to be paid when they do a test.  Monthly invoicing reports could be generated from OpenClinica by configuring an appropriate ‘data set’ and having it execute at the end of each month using the application’s new built-in quartz scheduler.  In this way, billing would be a snap and everybody would be on the same page.

In summary, how can trial sponsors configure OpenClinica to collaborate better with their contract labs? Do the following, keeping the workflow shown in Figure 1 in mind:

1.    Include a specimen accessioning CRF for each event.  Educate your collection-site people and your lab people as to who is responsible for which fields.  Use OpenClinica’s internal messaging system to remind people of their roles when the study is actually underway.
2.    Exploit OpenClinica’s web services framework to enable batch uploads of laboratory data.
3.    Configure and validate MirthConnect channels to get the lab results from the source data files to your OpenClinica installation.
4.    Distribute these channels to your lab contractors and educate them on their use.
5.    Configure OpenClinica to automatically generate monthly data sets for billing purposes.

The bottom-line: OpenClinica is infinitely configurable and sponsors should start doing so with their lab contractors in mind.  The result will mean both better collaboration and lower costs.

Figure 1: A specimen is collected from a subject on site. The on-site data manager logs into OpenClinica and accessions the sample and prints an accompanying hard-copy requisition. The sample is then shipped to the contracting laboratory where lab personnel log into OpenClinica and indicate they have received the sample. Specimens are then tested in batch and the results are then uploaded en masse into the sponsor's installation of OpenClinica using a thoroughly vetted, validated and auditable MirthConnect channeling system.

OpenClinica CRF Library

UPDATE (03-May-2010): The CRF Library is now live at library.openclinica.org.

Our vision at Akaza Research is to accelerate clinical research through open technology infrastructure. We do this through an open source software license, supporting a participatory community, and adhering to published open standards.

We are nearing another milestone that will further this vision. The OpenClinica CRF Library, currently in the final stages of development, will allow users to find, share, and re-use case report forms (CRFs) for OpenClinica. By utilizing the OpenClinica CRF Library, users will be able to:

  • Enable faster study startup by accessing a well organized, searchable database of OpenClinica CRF templates
  • Promote data standardization within their organization through re-use of CRFs that adhere to open industry standards
  • Derive customized versions from standardized CRF templates simply by editing the OpenClinica CRF Templates
  • Minimize time and cost spent on study training, testing, and validation by accessing value-added resources and documentation (including implementation guides, CRF Completion Guidelines, and test scripts) associated with the CRF templates in the library.

The library will be searchable by keyword and browsable by CRF type. Most CRFs are derived from authoritative, public standards sources such as the CDISC Clinical Data Acquisition Standards Harmonization (CDASH) initiative and the National Cancer Institute’s Cancer Data Standards Repository (caDSR).

In keeping with our vision, the CRF Library is the product of a participatory community and is based on open source software. Last April, we assembled a volunteer Steering Committee to guide development of the library. Committee members Liz Watts of Starfire Research, Lori Brix of Silent Partners, Derek Wimmer of Wimmer Clinical, and Elisa Priest of Baylor Research Institute have worked scrupulously to identify content, develop supporting materials for the CRFs, and implement workflows that will ensure quality resources. Their substantial knowledge of the CDASH standard and data management expertise has been invaluable. The broader community has also had a hand in building out this resource, through the user mailing list and at meetings of the OpenClinica Community Virtual Forum.

Content & Quality

One of the first questions the Steering Committee asked was, ‘How do we manage quality of content and metadata?’ There are many community-driven, peer-review, and commercial validation models that could work, from a loose ‘wikipedia’-style structure to more rigid frameworks for curation and standardization. We needed to adopt the right mix for our content and our community. The Committee emphasized the need for a high-quality ‘core’ set of CRFs that have broad applicability across studies, align to leading standards, and are accompanied by detailed resources which aid in implementation. At the same time, a larger, more diverse repository of CRF content would make the library useful to many in the OpenClinica community.

The result of this has been to create two broad classes of CRFs in the library, Curated CRFs and and Non-Curated CRFs.

Curated CRFs have gone through a rigorous peer review, testing, and annotation process. They include enhanced metadata, detailed specifications, validation test scripts, enhanced edit checks, and reference documentation such as an Implementation Guide and CRF Completion Guidelines. The initial collection of Curated CRFs in the library will be aligned with the CDASH Domains. The intent is to make it as easy as possible to implement these CRFs into a study, in ‘as-is’ or customized form, with confidence in the quality and accuracy of the CRF.

Non-Curated CRFs will be contributed by members of the community who wish to share their CRFs with others, or will be derived from existing non-proprietary electronic sources such as the National Cancer Institute’s Cancer Data Standards Repository (caDSR). These CRFs undergo less formal review and testing and have fewer supporting materials, instead will rely more heavily on community feedback and annotations.

Because of the significant investment made in annotation, review, and testing, full access to Curated CRFs and all the associated metadata, documentation, and associated resources will be available only to OpenClinica Enterprise Edition Subscribers. Non-Curated CRFs, and limited versions of Curated CRFs without detailed metadata or documentation will be freely available to all members of the OpenClinica community.

Contribution

Based on past discussions on the OpenClinica mailing lists and the Community Virtual Forum, we see substantial interest among community members in contributing and sharing CRFs. This is a very exciting prospect, and we will need community members to contribute enough quality CRF content to make the approach viable. Many community members have expressed interest in sharing their CRFs for others’ benefit, but also identified it as a way to get feedback and improve the forms for their own purposes. To provide a foundation for such contributions, the CRF Library will adhere to the following principles:

1) Contributors will be appropriately attributed and recognized for their contributions. Creative Commons (http://creativecommons.org/) provides widely used guidelines and license agreements to enable this type of sharing. CRFs in the library or derived therefrom will be made available under the Creative Commons Attribution 3.0 License. Contributors must represent that they (or their organization) have the legal right to contribute a CRF, and are not infringing on someone else’s copyright. When featuring the most popular or most highly rated CRFs, the CRF Library will highlight the identity of the contributor (at least by screen name).

2) Members of the community will be empowered to build on and improve others’ contributions for the benefit of all. All community-contributed CRFs will also be freely available to community members, and we will put into place popularity, versioning, and annotation features to allow users of a CRF to provide feedback and/or modifications to the original author.

Next Steps

As I mentioned at the start of the post, we are approaching roll-out of the CRF Library within initial CDASH-based content, and starting acceptance of community contributions. The roll-out will be aligned with the OpenClinica Global Conference (March 22nd in Bethesda, MD USA) and the CRF Library will be a featured topic at the event. It’s been a long time in development and we are excited to be nearing this milestone!

OpenClinica 3.0.1 Features Improved CRF Save Times

Akaza Research will be releasing a maintenance update of OpenClinica 3.0, which by itself probably does not illicit much excitement.  Usually maintenance releases only fix small bugs and offer little noticeable improvements to a user’s overall experience.  However,  3.0.1 will offer a dramatic improvement for a user’s experience with regards to the amount of time it takes Rules to run on a CRF.

Users of previous versions of OpenClinica would reach pain points when trying to save data entered onto certain CRFs if the study build had applied very complex Rules on a particular CRF section. For example, if the system had to check more than 10 variables to ensure one particular field had accurate data, the user might experience a save time of 2 or even 3 minutes in some circumstances.  In a test environment, we were actually able to create a scenario where the CRF save time took 19 minutes!

As part of 3.0.1, among other things, we have dramatically improved the save time of a CRF with complex Rules.  For instance, in the extreme scenario utilized in our test environment, we were able to cut the save time from 19 minutes down to 10 seconds.  That is about a 11,400% improvement!  For more typical users who were experiencing 2 or 3 minute save times, this has been cut to 3-5 seconds.

We are committed to improving the performance of OpenClinica, and can even offer faster experiences to the users of the OpenClinica Enterprise Edition.  Please see our website for the differences between the Enterprise and Community versions of OpenClinica.

OpenClinica 3.0.1 will be out next week!

OpenClinica and the Paper Chase: A Case Study

The developers of OpenClinica like to say they are ‘powering the electronic data capture (EDC) revolution’ in clinical data management and indeed that’s the case.  However, sometimes there’s no substitute for paper, especially when it comes to tracking and handling laboratory specimens.  We at Geneuity should know: testing lab specimens for clinical trials is our business.  This article shows how OpenClinica and paper records can augment one another through the use of URL-encoding barcodes.

Readers of this blog probably already know the drill:  a specimen is collected, a paper requisition is attached and the whole kit and kaboodle is mailed to a laboratory for testing.  When a specimen arrives at Geneuity, we log into OpenClinica’s web interface, look up the patient and event pairing in the subject matrix as specified by the requisition and then finally type in the values for items like accession number, receipt date, shipping deviations, freezer location and the like.  When one or two specimens arrive, this process (called ‘accessioning’) is no problem; when 20 to 60 arrive, it rapidly becomes tedious.

In a more perfect world, things would be easier and more automated.  Here’s one potential scenario to help achieve this.  In addition to all the necessary information in human-readable form, also print on the requisition a QR barcode that encodes the URL corresponding to the appropriate event case report form (CRF) in the study’s OpenClinica installation.  For instance, consider the example shown in Figure 1.

It encodes: “https://myOpenClinicaInstall.com/InitialDataEntry?eventCRFId=1” (for illustration only, not intended to link anywhere for real).  Upon being scanned with an appropriate hand-held reader (or smart-phone even), this would automatically direct the lab technician’s browser to the correct screen to input the attendant accessioning information for study event number one.  This would eliminate the manual look-up step described above and would reduce tedium and errors as a consequence.

Implementing this idea would require enabling OpenClinica to print out requisitions.  While challenging, this would not be impossible.  Indeed, middle-ware like MirthConnect may make it relatively easy.

Here’s another example of paper and OpenClinica working together, one that Geneuity actually implements currently to facilitate quality control.  Prior to testing a batch of specimens, lab technicians here use a custom Mirth channel to print out details of the samples to be tested.  A dummy example is shown in Figure 2.  As shown, it includes a simple linear barcode of the accession number, the principle means of tracking specimens in a clinical lab.  Scanning this saves the technician from having to type it into the testing platform during set-up.  It also contains a QR barcode specifying the event-specific URL that directs the technician where to go to review the data upon automatic upload into OpenClinica.  Having this URL handy means the technician doesn’t have to look it up in the subject matrix table which oftentimes has hundreds or even thousands of entries.

URL-encoding barcodes are a cheap and reliable way of linking physical objects with on-line databases, and nowhere is this link more critical than when tracking clinical specimens.  Thanks to Akaza’s commitment to open source, it’s easy to incorporate this technology into OpenClinica and to realize the myriad of benefits.

Figure 1: a QR barcode encoding an event-specific URL in a mock OpenClinica installation
Figure 1: a QR barcode encoding an event-specific URL in a mock OpenClinica installation
Figure 2: A list of specimens to be tested reported by a Mirth channel extracting from a mock OpenClinica installation.  The linear barcode helps with data entry at the testing platform while the 2D QR barcode is used to direct the lab tech's browser to the appropriate URL in OpenClinica for subsequent data review after testing is complete.
Figure 2: A list of specimens to be tested reported by a Mirth channel extracting from a mock OpenClinica installation. The linear barcode helps with data entry at the testing platform while the 2D QR barcode is used to direct the lab tech's browser to the appropriate URL in OpenClinica for subsequent data review after testing is complete.