Free Webinar, Aug 27: Successful Part 11 Compliance in a Universe of Electronic Data

Regulatory compliance may not always be the life of the party, but understanding its basics and being prepared for some of its hoops is becoming increasingly important. With that in mind you may find this upcoming webinar on successful compliance quite helpful if you’re new to 21 CFR Part 11 or if you’re looking to learn what’s new in the clinical research data landscape.

Hosted by our friends at Bio-Optronics and presented by OpenClinica CEO Cal Collins (@CalCollins1) the webinar will:

  • Review the basics of 21 CFR Part 11 and related regulations.
  • Examine what data and systems are within the scope of Part 11 and which are tangential.
  • Discuss how both good tools and good processes are necessary to succeed in a Part 11-compliant environment.
  • Briefly explore the changing landscape of electronic data in healthcare, and what it means for research.

The webinar will feature a 45-minute presentation and 15 minutes of Q&A, so make sure to send your questions or tune in for additional compliance intel.

Update: This webinar is now available for download.

Successful Part 11 Compliance in a Universe of Electronic Data

Presenter: Cal Collins, CEO OpenClinica
Wednesday,  Aug 27, 2014
3:00 PM – 4:00 PM EDT

Webinar hosted by:

clinical_conductor

Preview of the March 22nd OpenClinica Global Conference

With just a week to go, the OpenClinica Global Conference is shaping up to be an excellent event for learning about OpenClinica and networking with members of the OpenClinica community.

This is the first ever Global Conference and we are thrilled to have as a keynote speaker Mark Adams, Project Manager for the National Cancer Institute’s Cancer Biomedical Informatics Grid (caBIG). As a fellow pioneer working to bring open source to clinical research domain, caBIG has developed a set of interoperable, open source clinical informatics tools which address functions such as adverse event reporting, patient registries, study calendaring, clinical trial management, imaging, and tissue banking. The caBIG project and OpenClinica together illustrate the broad impact open source is having on clinical trials.

The conference program extends along three tracks with case studies, panel discussions, tutorials, and presentations from clinical trial sponsors, CROs, academic groups, and IT services companies. Content is oriented towards both technical and non-technical audiences. Selected topics include:

  • An unveiling of the new OpenClinica CRF Library, a curated repository of standards-based eCRFs for OpenClinica
  • Case studies from sponsors and CROs showing how they have used OpenClinica
  • Presentations of tools and extensions developed around OpenClinica
  • Tutorial for installing OpenClinica
  • Tools, tips, and techniques for using OpenClinica data in SAS
  • Live demonstration of automated data interchange with OpenClinica
  • Automating the data import process
  • Validating OpenClinica for 21 CFR Part 11 compliance
  • Generating ad hoc reports
  • Modularization of the OpenClinica source code and introduction to the OpenClinica Developer Network

A full suite of training classes for data managers, biostatisticans, project managers, system administrators, and developers are also being offered immediately preceding and following the conference.

There is still time to register for this event. See www.openclinicaconference.org for more program information and registration details.

We look forward to seeing you next week!

OpenClinica 3.0 Completes Functional Testing; Enters Deployment Testing

OpenClinica 3.0 is almost here! The quality team has successfully completed functional testing and has moved onto the phase of software quality assurance called deployment testing.  Deployment tests cover 8 different target “platforms” that range from a clean installation of OpenClinica 3.0 on a Windows server using Postgres, to upgrades of OpenClinica 2.5 to 3.0 on a Linux machine using an Oracle Database. Of course, we also test on all combinations in between.

Before the production version of the application can be released, it must successfully pass through our Quality System. For those of you familiar with such a thing, all of the testing and documentation that OpenClinica 3.0 is going through will end up generating thousands of pages of “paper” that include user requirements, traceability matrix, and a large set of screenshots which prove the expected results of the test cases did in fact happen.

In addition to the team at Akaza that has invested thousands of hours testing the application, this release has also undergone road testing in our first OpenClinica Pilot Program.  I would like to warmly thank the participants of the program for committing their time and effort in making sure OpenClinica 3.0 is our most well vetted release to date.

Please look for an announcement from me in the coming days of when OpenClinica 3.0 is available for download.

– Paul Galvin, Project Manager

An Opportunity for Transformational Change in Clinical Trials

Life sciences research is recognized as one of the most technologically advanced, groundbreaking endeavors of modern times. Nevertheless until very recently the preferred technology for executing the most critical, costly stage of the R&D process – clinical trials – has been paper forms. Only in 2008 did adoption of electronic alternatives to paper forms take place in more than half of new trials. This recent uptick in adoption rates is encouraging, but further transformational change in the industry is necessary to fully realize the promise of Electronic Data Capture (EDC) and associated “eClinical” technologies. Two developments that could provide the framework for such change are adoption of open data standards and the use of Open Source Software.

Data standards provide uniform ways to represent information or processes within a specific frame of reference and according to a detailed specification. A standard is “open” when it is not encumbered by patent, cost, or usage restrictions. Open Source Software (OSS) is defined loosely as software that allows programmers to openly read, redistribute, and modify the source code of that software. The combination of OSS and open standards is a proven way to deliver improved flexibility, quality, and efficiency.

A community-driven open source offering that harnesses open standards can produce robust, innovative technology solutions for use in regulated clinical trial environments. Most Open Source Software is built using a collaborative development model. The OSS development and licensing model encourages experimentation, reduces ‘reinvention of the wheel’, and allows otherwise unaffiliated parties to build on the work of others. The result is that OSS can become a key driver of increased IT efficiency and a way to wring out unnecessary costs. In many cases, users can have the best of all worlds: the ability to adopt software rapidly and at low cost, the flexibility to develop and extend their systems as they choose, and the ability to reduce risk by obtaining paid commercial-grade support.

As clinical research struggles to become more automated and efficient, we need to rely on interoperable systems to meet challenges of flexibility, quality, and speed. The OSS development model also naturally leads to the adoption of well-documented, open standards. Because OSS product designers and developers tend to reuse successful components and models where available, OSS technologies are often leading implementers of standards. For example, the National Cancer Institute’s Cancer Bioinformatics Grid (caBIG) initiative is “designed to further medicine’s potential through an open source network” based on open data standards and infrastructure that support sharing of heterogeneous data. This remarkable effort aims to connect large networks of researchers in ways that enables efficient re-use of data, eliminates duplicate systems, and enables new types of translational research.

In industry-sponsored clinical trials, standards such as the CDISC Operational Data Model (ODM), Clinical Data Acquisition Standards Harmonization (CDASH), and Study Data Tabulation Model (SDTM) have gained adoption in both proprietary and OSS software platforms. In some cases, standards are mandated for regulatory submission and reporting (SDTM, clinicaltrials.gov) and obviously must be adopted. Other cases, such as use of ODM, CDASH, and general web standards such as web services and XForms tend to be adopted to the degree they have a compelling business case.

The business case for standards centers on increasing accuracy and repeatability, enabling reuse of data, and enhancing efficiency by use of a common toolset. A well-designed standard does not inhibit flexibility, but presupposes idiosyncrasies and allows extension to support ‘corner cases’. Leading industry voices share compelling arguments how to use standards such as ODM, CDASH, XForms, and Web Services to achieve these goals. Though the details are complicated, the approach offers orchestration of disparate applications and organization of metadata across multiple systems. There is change control support and a single ‘source of truth’ for each data point or study configuration parameter, so when study designs change (as they inevitably do) or a previously committed data point is rolled back, it is automatically shared and manual updates to systems are not necessary. Because the ODM, CDASH, and SDTM are used as a common “language”, the systems know the meaning and structure of data and can process transactions accordingly. Here’s a tangible example:

Lets imagine an IVR system wanted to check with an EDC system if a subject was current in a study (current meaning not dropped out, early terminated or a screen failure).  A Web Service could be offered by the EDC system to respond with a ‘True’ or ‘False’ to a call ‘IS_SUBJECT_CURRENT’ ?  Of course hand-shaking would need to occur before it hand [sic] for security and so on, but following this, the IVR system would simply need to make the call, provide a unique Subject identifier, and the EDC system web service would respond with either ‘True’ or ‘False.  With Web Services, this can potentially occur in less than a second.

Electronic Data Capture – Technology Blog, September 28, 2008

While this integration requirement could be satisfied by development of point-to-point, proprietary interfaces, this approach is brittle, costly, and does not scale well to support a third or fourth-party system participating in the transaction. It is critical that standards be open so that parties can adopt and implement them independently, and later interface their systems together when the business case calls for it. A leading industry blogger makes the case for the openness of standards within the ODM’s ‘Vendor Extension’ architecture: ”The ODM is an open standard, the spec is available for free and anyone can implement it. This encourages innovation and lowers the barriers to entry and therefore costs. Vendor Extensions are not open, the vendor is under no obligation to share them with the market and the effect is that meta-tools and inter-operability are held back.”

Having the software that implements these standards released as open source code only strengthens its benefits. Proprietary software can implement open standards, however given the proprietary vendor’s business interest to lock-in license revenue, might the vendor be tempted into tweaking or ‘extending’ the standard in a way that is encumbered to lock users into their platform? This strategy of “embrace, extend, extinguish” was made famous in the Microsoft anti-trust case of the 1990s, where it came to light that the company attempted to apply these principles to key Internet networking protocols, HTML and web browser standards, and the Java programming language. They hoped to marginalize competing platforms that did not support their “extended” versions of the standards. Thankfully, they had limited success in this effort, and the Internet has flourished into the open, constantly innovating, non-proprietary network that we know today. The eClinical technology field is at a similar crossroads. By embracing open standards, and working concertedly to provide business value in re-usable OSS technology, we can achieve a transformation in the productivity of our clinical technology investments.

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.

Validation and Compliance with Open Source Clinical Trial Software

We are often asked, “if your clinical trial software is open source, how can it be validated”? The answer is that, like with many other things open source, you have multiple options.

If you choose, you can validate the product yourself from the ground up. This involves defining your requirements, generating and executing test cases that are traceable to those requirements, and doing all this within the framework of well-defined change control and quality management systems. Since you have access to the source code, you might include design and code reviews as part of this process, especially if you are modifying the core distribution or applying patches. If your requirements are highly specialized or your implementation has been extensively customized to integrate with home-grown and legacy solutions, this might be an attractive option. Be warned however – this approach is time consuming and requires the generation of extensive documentation.

As an alternative, we offer a Validation Support Package to our OpenClinica Enterprise customers comparable to what you would expect from a proprietary software vendor. The validation support package provides access to documentation on the Akaza quality system and the OpenClinica Enterprise solution. For example, Akaza maintains a comprehensive SDLC (Software Development Lifecycle) controlled by Standard Operating Procedures, and each release undergoes comprehensive system testing and deployment testing according to a detailed test procedure and a controlled, documented testing methodology. Quality System and testing artifacts are available for auditing and inspection by customers. Customers receive access to test scripts and system requirements specifications, and may tailor these test scripts to their own needs, making them traceable to their business requirements, and executing performance qualification of their OpenClinica systems. A document specifying how OpenClinica complies with 21 CFR Part 11 requirements is included in the package as well.

At last year’s DIA Annual Meeting I hosted a panel that included two very knowledgeable colleagues on this topic, entitled “Utilizing Open Source Software in GCP-Compliant Environments”. We’re doing an updated, slightly broader version of the session at this year’s meeting in Boston in June: Utilizing Open-source Software in Clinical Research Environments. I’ll be sure to post the slides here after the meeting, and if you’re at the event please come by.