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 3.0 Features Preview – Part II

Welcome to Part II of the OpenClinica 3.0 features! I previously wrote about three of the main features for 3.0, Source Data Verification, new User Interface for navigation in the system, and a new Home Page for each user.

This post is about three additional features: (i) the new Build Study module, (ii) setting the length and significant digits of items, and (iii) the improved performance of the Subject Matrix.

In 3.0,  all the study build tools will accessed from one main page following a task-based approach. There are five tasks available to the user at the outset. Once the user finishes these first five tasks, two more tasks will become available (see image). This allows the complete study from CRFs to event definitions to sites to assignment of users be done all from a single page. There is also a checklist to let the user easily see how many tasks have been completed so they know how much more configuration is needed before the study is ready to start enrolling subjects.

Build Study Page in OpenClinica

OpenClinica 3.0 also allows the creator of CRFs to set the allowable length of  text fields including the number of decimal places a REAL number should be rounded to. This parameter is set in the OpenClinica CRF Template in a new field called Width_Decimal. The user will specify the width and decimal for a particular field which will force the user to enter the most precise data as possible in a CRF. No longer will the system round to the 4th decimal place at all times and allow up to 255 characters in the field if the CRF creator does not want them to. For example, the creator could specify that a field should have no more than 5 digits total with a maximum of 1 decimal place by entering 5(1) in the Width_Decimal column of the OpenClinica template. If the data entry person tried to enter 3.4444 or 678913 they would told the value is invalid.

By providing this functionality, OpenClinica will help the users get their data into SAS and SPSS more easily.

One of the most important and information-rich pages in OpenClinica is Subject Matrix page, and OpenClinica 3.0 provides significant performance enhancements on this page for studies with large numbers of of subjects.  From the Subject Matrix page users can see a snapshot of where the subjects are in the study, schedule a new event, view a subject record, view a subject event, enter data in a CRF and sign a subject’s record without having to navigate to different pages in this system. A number of users were reporting sluggish performance with the Subject Matrix when they had 5000 or more subjects enrolled in a study.

OpenClinica 3.0 utilizes a new table structure that allows users to load the Subject Matrix containing over 10,000 subjects and 15 event definitions in fewer than 5 seconds (this process could take upwards of a minute in previous releases of OpenClinica).

Please feel free to download the Beta version of OpenClinica 3.0 at http://svn.akazaresearch.com/OpenClinica-3.0-distros/.

OpenClinica 3.0 Features Preview – Part I

We have been working hard on OpenClinica 3.0 for the last 9 months and are getting closer and closer to a production release ready for use in live clinical studies. In the meantime, I wanted to talk about some of the new features over the next few weeks to let folks know what is coming.

OpenClinica 3.0 is sure to bring a lot of excitement to all users of the rapidly growing open source electronic data capture system. A lot of focus in this release has been put on the way trial sponsors use an EDC system and I’d like to point out some of the new features that should enhance their user experiences.

OpenClinica 3.0 will provide a new home page to study-level users providing key information about the progress of a study. These users will be able to see a summary of the subjects enrolled at each site compared to their expected total enrollment as well as the overall subject enrollment for the complete study. Also, these study-level users will be shown a count of the number of study events that are in a particular status. A summary for the number of subject statuses will be displayed so the study-level user can easily see how many subjects are signed, source data verified etc.

OpenClinica 3.0 will provide monitors a workspace to source data verify subjects and their data. The workspace will allow users to source data verify information collected at each visit one-by-one, or verify the information in a bulk process. These two options allow the monitors to perform remote source data verification daily for subjects in the study. Or, if the monitor has to be on site to review and verify information, he/she can go back to their hotel room and check-off verification for many subjects and events at once so they do not have to go one-by-one through every subject and event CRF.

The top-level navigation in OpenClinica 3.0 has been streamlined so site users of the application understand exactly what they have to do after they login. A new home page for investigators and clinical research coordinator users will show the number of queries assigned to them with a link to see every Query assigned them. The home page will show the 5 most recent queries to give the user an idea of what they need to respond to that day.

The new navigation points to the 3 main actions the site users should take. The “Subject Matrix” link will bring them to the new and improved subject matrix in OpenClinica. This matrix will allow users to easily add subjects, schedule events and even enter data from a single, powerful screen. The “Add Subject” link will bring them to a page where they can add a new subject to the study. “Notes & Discrepancies” will bring them to a page where they can see all the queries for their site and allow them to provide a response.

Above is just a small sample of the new features in OpenClinica 3.0. Like I said, I will plan on posting additional features once a week so be sure to check back often. In the meantime, please feel free to download the alpha2 at http://svn.akazaresearch.com/OpenClinica-3.0-distros/.

– Paul Galvin

Validation Approach for OpenClinica

Lately there has been quite a bit of discussion in the OpenClinica community about validation. The following paragraphs provide a basic overview of the key pricipals and components of a validation approach for OpenClinica.

In 21 CFR Part 11, the FDA requires validation of all systems that store or manipulate data that will be part of a regulatory submission. However, the agency provides few hard-and-fast rules on what constitutes acceptable validation. Coming up with a validation plan without outside help can be a painful and inefficient process. Akaza Research facilitates the validation of the OpenClinica electronic data capture software by providing standardized documents that make the process of validating OpenClinica more efficient for our customers. Here’s a summary of what’s involved in validation OpenClinica, or any other computer system used in clinical trials, for that matter.

Because they are unsure what the FDA requires, sponsors tend to look for validation approaches that have been used successfully by others. Common validation practices in the industry are heavily influenced by a framework called GAMP, defined by the International Society of Pharmaceutical Engineers. (GAMP originally stood for Good Automated Manufacturing Processes, but has come to be used outside the realm of manufacturing equipment.)

A typical structure for validation under GAMP is to start with User Requirements Specifications, which drive Functional Specifications, which in turn inform the Design Specifications.  The vendor’s work has to follow the specifications and the vendor’s Systems Development Lifecycle (SDLC).

Appropriate testing must follow test scripts that map back to the requirements. The individual piece of equipment (such as an OpenClinica server) is tested with Installation Qualification (IQ) by the vendor or the customer. This is essentially acceptance testing of the hardware. The next test is Operational Qualification (OQ) of the system, carried out by the vendor or customer. Finally, the customer carries out Performance Qualification (PQ). PQ has to be related to the User Requirements Specifications.

When Akaza implements its OpenClinica Enterprise solution for a customer, we carry out the IQ and OQ testing, and provide the signed test scripts together with a detailed report on the setup and configuration of the software.

It is generally not practical for the users of off-the-shelf software to produce User Requirements Specifications and the PQ scripts themselves. For this reason, it is common for customers base their specifications and PQ scripts on documents they obtain from the vendor. Akaza’s enterprise validation package includes electronic copies of these documents, as well as a traceability matrix that ties the PQ scripts back to the requirements. The customer can modify them as needed.

The FDA expects the customer to run the PQ tests. You can probably also hire a third party to do this for you. While an experienced user can run through the OpenClinica PQ scripts in two or three days, it is reasonable to expect a novice to spend a week or so on it.

The other principal element of validation is to make sure that the software development process followed a defined SDLC (Systems Development Lifecycle). Akaza’s customers do this by auditing our procedures. At a minimum, they look at our Standard Operating Procedures, and our training records. They look at records of our internal test procedures. In addition they will sometimes look at our software defect tracking systems and source code configuration management systems.

Validation of electronic record keeping systems is a labor intensive process, but is an essential element of any submission to a regulatory body. Software vendors can make the process much more efficient for their customers. At Akaza Research, that’s one of the key things we do for users of OpenClinica to ensure they are compliant with regulations such as 21 CFR Part 11.

21 CFR Part 11, Electronic Signatures, & OpenClinica

Organizations that seek to submit their clinical trial results to the FDA must comply with 21 CFR Part 11: a key set of United States government regulations governing the use of electronic systems in clinical trials. Despite the fact that the government has issued guidance to try and clarify interpretation of these regulations, many people continue to have varying opinions on how software can/should best support 21 CFR Part 11 compliance.

Before I go any further I want to make sure readers understand that software itself can neither be compliant nor non-compliant. It is the implementation and use of software that determines actual compliance. Therefore, one could envision a system without a lot of native features designed to support 21 CFR Part 11 and achieve compliance through the application of Standard Operating Procedures (SOPs) and other controls. Conversely, one could conceive of a system that inherently better supports compliance through specific features.

As a member of the core OpenClinica development team, I have been involved in tackling one of the key pieces of 21 CFR Part 11 guidance that causes a considerable amount of confusion: electronic signatures. As a refresher, electronic signatures are a system feature used to ensure that actions taken by users of a system are attributable in a legally binding manner. 21 CFR Part 11 looks at System Controls, Signature Controls, and Password Controls as components of electronic signatures.

The forthcoming release of OpenClinica (version 2.5) will offer new ways of verifying that the data being provided for a subject is Attributable, Legible, Contemporaneous, Original, and Accurate (ALCOA).

Different users in the context of OpenClinica will need to verify the data they are providing are truly accurate and complete. One of the users may have a data entry role. In order to show the data being provided truly is ALCOA this user must enter their password before completing data entry. This will also ensure the user entering the information is in fact the same person that logged into the application in the first place.

An investigator in OpenClinica will need to verify all data are accurate and complete for a subject’s event, or the complete subject “case book.” OpenClinica will allow the user to sign event by event whereby the investigator is stating that all of the information in the CRFs for each event contains original and accurate data. Before signing for the subject’s event or case book, the investigator will be allowed to go through each one of the CRFs to make sure all discrepancies have been cleared up, and all the data are complete.

Every step a user takes to sign a CRF, an event, or the subject case book is being audited in the application so there will always be a record of when each action took place.

This has been a brief explanation of how OpenClinica 2.5 will further support clinical trials where the results will need to be provided to the FDA. The new electronic signatures feature allows users who are implementing and using the software to become more compliant with 21 CFR part 11 requirements.

eCTDs to get more important in 2008

In this past year, we worked hard to update the Electronic Data Capture facilities of OpenClinica; we also worked very hard to get OpenClinica internationalized, so that it could reach a wider audience in the OSS clinical research world.

One of the things that will be on the horizon for us now is improving data export.  And now is definitely the time for that; according to ClinPage, as of Jan 1st 2008 the FDA will accept electronic regulatory submissions in the form of the Electronic Common Technical Document (eCTD) only.

OpenClinica currently provides reports in several different formats, including the CDISC ODM format in XML, and we’ll be working to improve that over the coming months.  The change in the FDA’s standard is paving the way for all organizations, big and small, to find a way to submit documents electronically, and we hope OpenClinica will be able to play a part in providing a low-cost alternative to many organizations.  As the above ClinPage article points out:

….the major pharmas made the transition to electronic submissions years ago—in some cases, as early as the 1990s. They quickly earned a return on investments in better regulatory document systems, even though the technology was far more expensive then.

The situation is different for small pharmas and biotechs today, Perry says. They typically lack the manpower to attend to both routine regulatory work and manage the transition to a new system. He adds: “The purchase price of the system is not the obstacle. It is implementing. The smaller you are, the more desperately you need one of these, but the less people you have to implement them.”

Even as IT budgets may be getting smaller, as George Laszlo writes, the need to add the EDC system (and other systems) to an existing lab is getting bigger.  Through this blog, we hope to chart how health IT, and especially clinical research needs, can be met by implementing OpenClinica as a flexible, lower-cost solution.