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

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.

Why Pharmaceutical Companies Now Have a Reason to Choose Open Source

On October 27th, Bio-IT World published an article on the newly released OpenClinica 2.5. In a somewhat bold statement the article’s author stated that “Akaza Research has given pharmaceutical companies reason to take heed of the open source movement.” Akaza Research, of course, is the primary commercial force behind OpenClinica, the world’s most popular open source electronic data capture software.

What the author fails to explain, in my opinion, is why this is the case. For instance, I personally do not believe that the larger pharmaceutical companies would choose an open source EDC system for open source’s sake. In other words, the cost and flexibility benefits of open source, while significant, may not offer the same degree of value to Big Pharma as it would to myriad smaller companies. The industry’s largest firms have the financial resources and technical expertise to obtain and utilize essentially any solution in the marketplace and will therefore need a stronger motivation in order to move to open source. And I think that this motivation has to come from the quality of the technology and the overall solution through which it is implemented.

I do not believe OpenClinica would be making such a strong impact in such a short period of time if it weren’t for the robust open source community behind it. It is this community that provides fundamental value to the software. The decentralized efforts of users around the globe fuel OpenClinica’s evolution in a way that is both rapid and driven by true market demand from the trenches. The result is a product containing features that real-world users want and that work in the way these real world users want them to.

The open source community also helps to self-police the quality of OpenClinica distributions. There is a diverse group of users and developers who experiment with beta releases and continuously scour the system source code. From their unbridled vantage points within the community, these people report issues in a frank, public, and uncompromising manner. This transparency and candid public discourse about the software makes it difficult, if not impossible, to cut corners or sweep defects under the rug.

In a sense, with proprietary software you never really know what you’re getting. With open source software you know it all—both the good and the bad. It is the open source community that drives OpenClinica’s success, and this, in my opinion, is why pharmaceutical companies have reason to take heed of OpenClinica.

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.