• "Musings on open source and open standards in clinical trial software and healthcare IT"

  • Top Posts

  • Blog Post Categories

OpenClinica to be Used for European Commission Project “beta-JUDO”

Posted on February 22, 2012 by kristiakk

As part of the European Union 7th Framework for Health, the “Beta-JUDO” project will involve hundreds of juveniles with obesity and type 2 diabetes. Pharmacology-based treatment strategies are limited for this growing patient group and the aim of the project is to identify novel strategies reducing insulin hyper secretion, which has so far not been considered a target for intervention in young obese individuals. The project will also involve beta-cell biology, brown adipocyte imaging, transcript and protein profiling, genetics, epidemiology and bioinformatics. A number of European institutions with expertise in these areas are thus involved. A kick-off for the project was recently held at Uppsala University, where about 30 expert scientists form several European countries attended. The project will continue until 2016 and has a total budget of €8 million.

OpenClinica will be used for data collection and data management across several European countries. The project is led by Professor Peter Bergsten Department of Medical Cell Biology at Uppsala University and two firms, Scandinavian CRO and e-Source Technology EMR, will be responsible for the management of the clinical part of the project.

We are proud to be involved in this prestigious project and to be able to demonstrate the abilities of OpenClinica and its powerful web services, which will facilitate the integration of external data from many sources across Europe.

- Dr. Krister Kristianson
e-Source Technology EMR

Filed under: Case Studies, Uncategorized | Tagged: , , , , | Leave a Comment »

OpenClinica in an Academic Environment

Posted on October 6, 2010 by cricrss

Here at the Women & Children’s Health Research Institute, Edmonton, Alberta, we have been using OpenClinica since version 1. In that time the product has evolved significantly, providing more functionality and tighter focus on support for regulatory clinical trials. Our objective in this institute is to support our researchers regardless of the type of study they are undertaking. However, in the last two years, we have not been involved in any studies that needed to conform to regulatory standards. How then does OpenClinica perform in a purely academic environment?

Because OpenClinica is designed to support rigorous clinical trials it has many features that are of value to academic researchers. In our environment we stress the following features to our researchers, many of whom are used to managing their data in Excel or Access:

  • OpenClinica is hosted within a secure data centre provided by the University’s Faculty of Medicine and the servers are supported by the Faculty’s IT team.
  • Access to data is controlled through individual logins and user roles. The system is web based, using 128 bit encryption between the browser and the server. Studies implemented in OpenClinica are compliant with provincial privacy requirements.
  • Data entry rules and validations allow input to be validated at the point of entry. This greatly reduces the opportunity for user error, reducing the need for double data entry and reducing the cost of the data entry and cleaning effort.
  • CRF versioning enables changes to the data entry tools during the course of a study whilst maintaining the integrity of existing data.
  • Collaborative, multi-site studies are well supported in OpenClinica.
  • Discrepancy management and monitoring workflow allow annotation of the data and facilitate quality management whilst the study is ongoing. This reduces the cost of end of study data cleaning. It also minimizes the interval between end of study and analysis leading to reduced time to publication.

Many of the studies we have implemented in OpenClinica have been unregulated clinical trials, and these are clearly a good fit for the product. Many though have not fitted into this category but OpenClinica has still proved to be good for the job. The following two examples demonstrate our approach to some research projects that were not clinical trials.

Example 1 – Retrospective Chart Review (Double Data Collection)

We were approached by an investigator who asked us to perform double data entry for a project involving a retrospective review of 50 patient charts. However, when detailed requirements were established it became apparent that the charts had been independently reviewed by two separate investigators (double data collection). As a result traditional double data entry was not appropriate as the data entry staff were not qualified to adjudicate between data collected by two medically qualified reviewers.  What was actually required was single data entry and comparison of two separate sets of forms.

For this study we entered the two sets of data into two separate sites in OpenClinica. This allowed the data to be easily subset (into two separate libraries) once we’d imported it into SAS. We then wrote a SAS macro which used PROC COMPARE to compare the two libraries, and generate a difference report.

The final stage of the process was for the Principle Investigator to review the difference report and adjudicate the discrepancies. In over 90% of cases the discrepancies were due to different styles of documentation between the two investigators and were not significant. However approximately 10% of the differences required the subject’s chart to be checked before the discrepancy could be resolved. As the discrepancies were resolved the PI annotated the report and a final round of data entry was performed to apply the corrections in one of the OpenClinica sites. This site was designated the ‘primary’ data and was extracted for analysis.

The combination of OpenClinica and SAS performed well for a chart review where traditional double data entry was not practical. Discrepancies between the two separate reviews were identified by data management staff, which resulted in significant time savings for the two investigators.

Scenario 2 – Research Data Warehouse

Staff at Edmonton’s Pediatric Centre for Weight and Health (PCWH) required a database to collect physical examination, demographic, exercise and diet information from their patients and their patients care givers. The intention was to proactively build a research data warehouse from which future studies could perform retrospective analysis. Budgetary constraints meant that bespoke database development was out of the question, so we suggested they try collecting their data with OpenClinica. After four hours of training and with support from the informatics team the PCWH research coordinator built CRFs reflecting the content of every data collection form used in the clinic.

In order to facilitate our data extraction and analysis needs, a SAS database was created to reflect the contents of OpenClinica, but in a more analysis friendly form. Data is extracted overnight using a Java application that we developed to simplify and automate data extraction into SAS.

As the project evolved, the research teams’ understanding of their data improved and modifications were made to OpenClinica CRFs. As a result, data structures increased in complexity and additional SAS code was written in order to consolidate data structures for the end user.

It also became apparent that the database was required to manage complex relationships between the clinic’s patients and their care givers. For instance:

  • Data was required for all the care givers who attended a clinic visit with the patient
  • Care givers could be parents, other family members, foster parents, etc.
  • Un-related patients could have common care givers. A woman could be the mother of patient A, aunt of patient B and foster mother to patient C.

To handle these relationships, the team created separate numbering conventions for the subjects and their care givers. When a care giver attends the clinic for the first time, they are entered as a new subject. OpenClinica’s ‘secondary identifier’ field is used to enter a comma separated list of ‘relationship codes’ representing patients to whom the individual is a care giver and also their relationship to that patient. The data in this field is used by SAS to create a relationships table that defines all the caregivers for a patient and the relationship. It allows the researcher to subset the data based on these relationships and facilitates research involving complex multi-family structures.

Inventive use of subject numbers and the secondary identifier field in OpenClinica allowed the PCWH to model complex relationships that OpenClinica isn’t primarily designed to handle. The SAS data warehouse facilitates rapid querying of retrospective clinic data by investigators and their trainees, facilitating studies that would otherwise have been performed by chart reviews.

Conclusion

OpenClinica performs well in an academic environment where low cost, flexibility and study implementation speed are critical factors. We are able to extend OpenClinica with additional tools (notably SAS based data manipulations) in order to provide a tailored solution.

It should also be noted that as is the case with any research a deep understanding of the study and its data collection requirements is critical to the success of the project.

Rick Watts B.Sc, FICR, CSci

Team Lead, Clinical Research Informatics Core

Women & Children’s Health Research Institute

University of Alberta

Rick.watts@ualberta.ca

Filed under: Case Studies | Tagged: , , , , , , , , | Leave a Comment »

The Open Source Effect: Akaza Research Provides Insight into Rapid Growth of OpenClinica

Posted on September 24, 2010 by bbaumann

OpenClinica has seen a surge in usage over the past year, according to recent survey conducted by Akaza Research.

“Our annual survey of the OpenClinica community showed strong expansion in all key measurements of system usage,” said Cal Collins, Chief Executive Officer at Akaza. “In the past year we have seen doubling in the number of OpenClinica users and subjects, and a nearly 10-fold increase in regulatory submissions.”

The company reports that a reported 168,989 subjects have been involved in OpenClinica-powered clinical trials, a 224 percent increase from the prior year. In tandem, the company identified a 246 percent increase in the number of OpenClinica software users. The figure measures users working at the sponsor or CRO level and does not include users at clinical trial sites.

“Since these figures are based on a voluntary survey of the OpenClinica community, they are likely underestimates,” said Collins. “While it can be difficult to precisely measure the usage of freely distributed open source software, they provide a clear indication of the growth in OpenClinica adoption around the world,” he added.

The Professional Open Source Model

OpenClinica stands in stark contrast against the landscape of other EDC products that are provided under a closed source license. Akaza Research’s “professional open source” business model makes OpenClinica available in two editions. The OpenClinica Community Edition is freely available to use and modify, and may be downloaded form http://www.openclinica.org. The OpenClinica Enterprise Edition is a certified build of the open source technology commercially supported by Akaza Research. In many respects, the company’s business model is similar to that of RedHat (Linux), MySQL (database software), and other open source companies.

The OpenClinica rapidly growing open source community currently comprises over 10,500 users and developers, many of whom help review and adapt the open source software. Roughly 33 percent of OpenClinica users are located in North America, 30 percent in Europe, 14 percent in Asia, 9 percent in Africa, 7 percent in South America, and 7 percent in Australia. OpenClinica community members drive much of the product’s evolution, and in recent years have helped to usher the technology into a wide variety of clinical trial settings.

Worldwide Acceptance in Regulated Trials

The composition of the OpenClinica community is changing over time, with an increasing number of OpenClinica users representing commercial clinical trials. Currently, 55 percent of the OpenClinica community members identifies themselves as working in industry, with the remainder in academic or government settings.

According to Collins, “the robust overall growth is highlighted by an increasing proportion of OpenClinica users representing pharmaceutical, biotech, device, and other companies. We saw a 975 percent increase in OpenClinica-powered trials used in regulatory submissions in the past year, and in the next 12 months OpenClinica adopters expect to increase this number by another 200 percent. This is consistent with our OpenClinica Enterprise Edition customer growth, where a majority of new customers are from industry.”

For more information about OpenClinica see the OpenClinica website.

Filed under: Case Studies | Tagged: , , , , , , , , , , | 1 Comment »

XForms and OpenClinica

Posted on May 15, 2010 by csmith531

Here at Geneuity, we do a lot of contract research work for sponsors of clinical trials.  That sometimes means developing and validating custom assays that aren’t available off the shelf. And this, in turn, often means developing special interfaces for data capture that can’t be configured inside OpenClinica (as yet).

Does that mean we jettison OpenClinica?

No, absolutely not!

Since OpenClinica is open source and dedicated to interoperability, it can be easily extended.  This article describes the specifics of one such case involving XForms.

A while back, Geneuity was developing an ELISA to measure the abundance of a specific protein in plasma.  We needed a single web form with a spreadsheet-like feel and functionality in which lab technicians could enter data, interpolate unknowns, send the resulting interpolated values for insertion into OpenClinica and then perform source data verification.  Additionally, the form needed to be pre-populated with the accession numbers of specimens requiring testing.  The form had to work on any browser and not be dependent on any browser plugins.  And we had to have it fast.

Impossible? No, not with XForms and the open source XForms renderer betterFORM.

XForms have several advantages.  First of all, you author the forms in relatively simple XML while the complicated AJAX that makes the spreadsheet-like feel and functionality is rendered by the renderer and presented to the client browser for you.  Secondly, XForms allows you to easily call upon webservices to populate data items in the form.  In our case, we developed three such services: one to return a list of accession numbers corresponding to specimens yet to be tested along with corresponding hyperlinks directed inside OpenClinica for rapid source data verification (SDV); another to calculate and graph a standard curve and to interpolate the specimen unknowns; and still another to insert the interpolated values into OpenClinica.  The data flow is diagrammed in Figure 1.  Although a great deal is going on behind the scenes, the user experience is seamless as a single form is being used while data retrieval and refreshment are being done without interrupting the display (thanks to AJAX as automatically implemented by betterFORM). The form itself is pictured in Figure 2.

And there you have it.  The bottom-line: no matter how complicated your data capture requirements are, you can count of the interoperability of OpenClinica.

Figure 1. First, the lab tech initially summons the XForm which calls upon OpenClinica via a webservice for the list of specimens for which there are no test results. The tech enters the data and clicks on the appropriate button to call for data interpolation and calculation. After review of the results, the tech then submits the data for insertion into OpenClinica (for more on this see here). Finally, the tech performs source data verification using the hyperlinks populated in the XForm as the result of step 1.

Figure 2. This is a snapshot of the XForm as it exists after interpolation and calculation. Only two specimens are shown, but usually there are many more in a batch.

Filed under: Case Studies, Standards & Systems Integration | Tagged: , , , , , , , , , , , , , | 2 Comments »

Trial Sponsors and Their Contract Labs: Better Collaboration via OpenClinica

Posted on April 15, 2010 by csmith531

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.

Filed under: Case Studies, OpenClinica Features, Standards & Systems Integration | Tagged: , , , , , , , , , , , , , , , , , , , , , | Leave a Comment »

OpenClinica and the Paper Chase: A Case Study

Posted on September 21, 2009 by csmith531

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.

Filed under: Case Studies | Tagged: , , , , , , , , , | 2 Comments »

Facilitated Data Entry of Lab Results Using OpenClinica’s New Web Services Feature

Posted on August 19, 2009 by csmith531

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.

Diagram of OpenClinica at Genuity Clinical Research Services

Diagram of OpenClinica at Genuity Clinical Research Services

Filed under: Case Studies, OpenClinica Features, Uncategorized | Tagged: , , , , , , , , , , , , , , , , | 10 Comments »

How a Busy Research Clinical Laboratory Deploys OpenClinica as a Laboratory Information System (LIS)

Posted on December 8, 2008 by csmith531

Here at Geneuity Research Services, we do laboratory tests for clients
conducting clinical trials. We are a one-­stop shop, handling everything
from routine clinical assays to esoteric molecular analyses. We use
OpenClinica as an in-­house LIS to keep track of work­flow and to help
with administrative tasks like billing and specimen archiving. This isn’t
exactly what the developers of OpenClinica had in mind originally. The
application was designed from the point of view of trial sponsors, not their
subcontractors. But it works very well for us nonetheless. In this article,
we briefly describe how we do it.

As everybody who uses OpenClinica knows, defining your event x
CRF matrix is the most important step in configuring a trial. When a
client comes to us with a new trial, we do just that. We are careful
to reproduce the anticipated flow of events and patient groupings
just as designated by the trial’s specifications. “Why bother?”
you’re probably asking. “You’re just a subcontractor. That’s not your
concern.” But it is. Invariably, specimens get mislabeled and
inappropriate tests get ordered, and we’re able to detect many such
mistakes by doing a quick visual inspection of OpenClinica’s patient
x event dashboard with its easy-­to-­take-­in iconification. We feel
that this double-checking is part of our service to the sponsor.

CRF design is our next consideration. In this case, we don’t
try to reproduce everything required from the sponsor’s point of
view. Instead, we design a set of CRF’s that reflects just our role
as a contract clinical laboratory. This means that our CRF’s are far
more narrowly focused and less complicated. But it also means we
include some unique types of fields for pricing, specimen archiving
and the like, items that a trial sponsor usually doesn’t need to
address in their CRF’s but which are very helpful to us.

We are very careful how we name our items when crafting our
CRF’s. Specifically, we use the same terminology across our trials
whenever possible. For instance, the field for a specimen’s accession
number is always named ‘accession_number‘. Likewise, we consistently
use the names ‘freezer‘, ‘received_date‘, ‘price‘, ‘shipping_deviation‘
and ‘%assay_date‘ (where % is the wildcard string).

Using such a controlled vocabulary is vital in our case because
we use a separate installation of OpenClinica for each study and
employ the postgresql contrib module ‘dblink’ to federate their
attendant databases for querying. A helter­skeleter vocabulary would
render the latter problematic, to say the very least.

For example, we wrote a federated database procedure we call
accessions(). When executed, it consults the accession_number field
in all our installations and returns the number of accessioned
specimens broken down by trial name. This table lists some of the
federated procedures we’ve developed and their functionality.
Collectively, they provide us with a real­time, global snap­shot of
our work­flow and freezer contents.

Because OpenClinica is web­-based and has finely grained user
roles, our clients can remotely log into their respective
installations at our site with read­-only privileges and see the
status of their specimens whenever they want. Conversely, when we
think a specimen has been mislabeled or have some other issue, we can
call a client and direct them to a particular URL displaying the
pertinent information and seek clarification. OpenClinica thus
becomes a shareable laboratory notebook between us and our clients.

The bottom­line: OpenClinica works for Geneuity. Because
OpenClinica is open source, elegantly designed and well documented,
we are able to tailor the application to our needs. In the spirit of
mutual collaboration and aid fostered by OpenClinica’s lead
developers at Akaza Research, we’re making our federated procedures
freely available. They can be downloaded here.

Filed under: Case Studies | Tagged: , , , , , , , , , , , , , | 3 Comments »

Using OpenClinica for ICF-Based Data Acquisition

Posted on December 3, 2008 by cdaffara

The use of electronic data capture (EDC) systems in health care, and especially in clinical trials, has been the object of significant research given the potential advantages like improved data quality, reduced cost, and increased trial repeatability. Despite significant interest and promised benefits, real adoption has been somewhat limited to date with most successful implementations performed in the field of pharmaceutical clinical trials. This can be attributed in part to the lack of underlying consistent and reusable internal data models and the high cost and complexity in customizing most EDC systems.

A potential alternative to traditional EDC software is the use of Open Source Software (OSS), broadly defined as software that is distributed as a freely available and freely modifiable system. This freedom gives the user the opportunity to perform structural modifications and adaptations to better integrate the software with pre-existing IT infrastructures, or to adapt it to local needs and requirements. There are many examples of large scale open source software (OSS) systems in health care, including the VISTA electronic health record system, used in the US Department of Defense and in several hundred installations across the world, the Care2X system, Indivo health, and the OpenClinica EDC system. The use of open source software facilitates the harmonization of a coherent and comprehensive data model that can be reused across different systems. In our work, ICF (the WHO classification for functioning and disability) has been selected as the underlying representational model, and implemented in the OpenClinica EDC software. The experimentation involved more than 10 Italian regions, with multiple hospitals and care centers. The EDC system was designed to test the effectiveness of ICF as a basis for data collection on disability and functioning in a wide spectrum of pathologies.

The complete WHO-ICF classification was imported from the CLAmL XML representation into the LexGrid editor, a tool created by Mayo Clinic for the purpose of editing and maintaining ontologies and classifications. Starting from this intermediate representation, the classification was first translated into the Italian language and then exported back into the CLAmL representation; this form was also used as the basis for the creation of the internal EDC data model, later imported into the OpenClinica platform. From this visual representation, a group of experts designed the set of forms that comprise the web application; later, the database structure and the final application templates were fixed and published on a public web site. The joint use of ICF as a representational model for an Electronic Data Capture system, coupled with the choice of open source software, yielded a significant reduction in the cost and implementation time of a multiregional EDC system. The ease of use of the web interface also facilitated interactions with medical experts to quickly implement alternative data representations and to create a stable and fast platform that is currently being used in an actual trial. OpenClinica demonstrates that open source is stable and ready to be used even in the strictest clinical trials, and that by using open source it is possible to create clinical research applications in a faster and more cost effective way.

- Carlo Daffara, Connecta

Filed under: Case Studies | Tagged: , , , , , , , , , , , , , , | Leave a Comment »

Adventures in Web-Based Electronic Data Capture (EDC) – An OpenClinica Case Study

Posted on September 17, 2008 by bbaumann

A recent issue of Applied Clinical Trials Online features a case study of OpenClinica Electronic Data Capture (EDC) adoption by German device company, Retina Implant, AG. Here’s a short excerpt:

“Last summer, Retina Implant started using OpenClinica for its latest trial, which is comprised of 11 studies. Currently, five of those studies have acquired subjects and are up and running with the OpenClinica CRF process. Randomization of study subjects are done outside OpenClinica, as it doesn’t have this feature. So far, Hekmat is appreciative of the flexibility of the platform, its ease of use among the global site staff, and the ability to view data in real-time via the Web browser.”

Click here for the full article.

Filed under: Case Studies | Tagged: , , , , , , , | Leave a Comment »

Follow

Get every new post delivered to your Inbox.

Join 1,590 other followers