Implementing a Clinical Research Management System: One Institution's Successful Approach Following Previous Failures.

Clinical research management systems (CRMSs) can facilitate research billing compliance and clinician awareness of study activities when integrated with practice management and electronic health record systems. However, adoption of CRMSs remains low, and optimal approaches to implementation are unknown. This case report describes one institution's successful approach to organization, technology, and workflow for CRMS implementation following previous failures. Critical factors for CRMS success included organizational commitment to clinical research, a dedicated research information technology unit, integration of research data across disparate systems, and centralized system usage workflows. In contrast, previous failed approaches at the institution lacked a mandate and mechanism for change, received support as a business rather than research activity, maintained data in separate systems, and relied on inconsistent distributed system usage workflows. To our knowledge, this case report is the first to describe CRMS implementation success and failures, which can assist practitioners and academic evaluators.

Introduction

Institutions increasingly rely on electronic systems for the conduct and administration of clinical care and research. For clinical care, electronic health record (EHR) systems enable documenting the practice of medicine, nursing, and ancillary services while practice management (PM) systems facilitate patient registration, scheduling, and billing. For clinical research, clinical data warehouses and electronic data capture tools enable reuse of EHR data and prospective data collection while electronic institutional review board (eIRB) and clinical research management systems (CRMSs), also known as clinical trial management systems (CTMSs), facilitate administrative functions such as human subjects protection and clinical research billing compliance.

Clinical research billing compliance involves determining which items and services in a study protocol reflect conventional care and are therefore billable to insurers versus those that are specific to a research study and are only billable to a research sponsor1. Accurate clinical research billing is necessary to ensure reimbursement for research procedures and also to prevent overbilling to, and overpayment from, insurers. Billing compliance failure, particularly with Medicare in the United States, can result in considerable financial penalties and negative publicity.

CRMSs facilitate billing compliance by enabling clinical researchers to define research protocols with basic characteristics such as title and sponsor, perform prospective reimbursement analysis of procedures in a protocol, generate protocol budgets for internal analysis and negotiation with sponsors, and manage enrollment of subjects in protocols. Shared with PM and EHR systems, CRMS data enables institutions to schedule and identify patient visits with research services, distinguish research charges from standard of care, and make clinicians aware that patients are receiving experimental care.

Adoption of EHR and PM systems continues to increase2 along with systems for the conduct of clinical research such as i2b23 and REDCap4. However, adoption of systems for the administration of clinical research, particularly CRMSs, lags in comparison5. Although adoption of eIRB systems is relatively common, adoption of CRMSs is low within and across institutions. Specifically, one institution reported 25% voluntary adoption of a CRMS6 while a recent survey showed 35% adoption by academic health centers, the lowest percentage for any system surveyed for the administration and conduct of research5.

CRMS use can streamline administrative workflows for clinical research, and understanding best practices for implementation, especially those related to people and organizational issues7, are vital to ensure adoption and continued use of systems8. To our knowledge, literature describing CRMS implementation is limited to one solution at one institution9. Additional description of successful and failed CRMS activities can inform practitioners at other institutions as well as academic evaluation efforts. The goal of this case report is to describe a successful approach to CRMS implementation in the context of previous failures at one institution. We consider a CRMS as a tool that facilitates research administration workflows rather than research conduct workflows such as data capture in an electronic case report form10.

Background

Institutional environment

Weill Cornell Medical College of Cornell University (WCMC), located in New York City on the Upper East Side of Manhattan, serves a tripartite mission of clinical care, education, and research. Clinical faculty members practice in the Weill Cornell Physician Organization, an 883 physician group practice providing outpatient primary and specialty care at 22 locations citywide, and have admitting privileges at NewYork-Presbyterian Hospital (NYPH), a 2,409-bed six-facility teaching hospital. WCMC trains more than 950 resident physicians and fellows as well as over 400 medical students. To assist researchers, WCMC offers specialized services through 25 core facilities. Recent clinical and translational research initiatives include formation of a Cancer Center, Institute for Precision Medicine, and federally-funded Clinical and Translation Science Center. To support WCMC’s tripartite mission, the Information Technologies and Services Department (ITS) provides comprehensive electronic infrastructure including network connectivity, software hosting, and user support among other activities. Physician Organization Information Services (POIS) works closely with ITS to leverage institutional architecture for providing clinical information systems.

WCMC and NYPH, longtime clinical affiliates and separate legal entities, increasingly collaborate for clinical and translational research. In January 2013, WCMC and NYPH established the Joint Clinical Trials Office (JCTO) to grow clinical research activities across both institutions by sharing infrastructure. With the goal of advancing patient care, basic research, and education, the JCTO streamlines the administration and conduct of clinical research through master agreements with funding sources, scientific and feasibility review of study protocols, financial management, regulatory compliance including human subjects protection, and information technology (IT).

Both WCMC and NYPH have extensive EHR, practice management, clinical data warehouse, and electronic data capture solutions. Notably, the WCMC Physician Organization has used Epic Ambulatory as its EHR since 2000 while NYPH has installed Allscripts Sunrise Clinical Manager in inpatient and emergency settings. The two institutions share electronic patient data through multiple interfaces.

Institutional CRMS requirements

WCMC’s requirements for a CRMS include the ability to create and maintain protocol definitions, subject enrollments, prospective reimbursement analyses, and budgets as well as share data with PM and EHR systems. A protocol definition includes elements such as a short version of a study title, IRB protocol number, principal investigator name, fee schedule determined by the combination of protocol initiator (sponsor or investigator) and funding type (federal or non-federal), college fund account number (if applicable), and hospital research identifier (if applicable). A subject enrollment includes an IRB protocol number, patient medical record number, and enrollment status (e.g. enrolled, completed, ineligible). Prospective reimbursement analysis involves creation of a billing grid detailing the payer (e.g. standard of care, research sponsor) of each procedure for each visit in a protocol. A budget leverages a billing grid to identify costs and charges for each research procedure and other fees in a protocol. Sharing these data between CRMS and PM and EHR systems automates patient care research workflows.

Institutional CRMS failures

From 2007 to 2011, the WCMC Physician Organization Business Office (POBO), which managed the General Electric (GE) Centricity Business practice management system, pursued multiple approaches to CRMS implementation. During this time period, Epic Systems indicated it had no plans to develop a CRMS but would add functionality to existing modules as necessary to support research.

As a first step in in 2007, the POBO adapted existing GE Centricity Business functionality for clinicians managing patients with occupational health cases that were billable to corporations so that researchers could manage subjects enrolled in protocols with services billable to sponsors. This workflow required POBO analysts to manually create protocol definitions in the system and investigator teams institution-wide to access the system to update the enrollment status of subjects in protocols. A custom interface between GE and Epic informed clinicians of research patient visits. Additionally, the WCMC Office of Billing Compliance (OBC) began requiring all investigators to submit a spreadsheet template-based prospective reimbursement analysis for all protocols submitted to the IRB regardless of the protocol having clinical procedures.

The case-based subject enrollment approach was intended to be temporary, as in March 2008 the institution began deploying GE Patient Protocol Manager (PPM) after years of development in partnership with the vendor and two other academic medical centers. PPM featured dedicated protocol definition, subject enrollment, and billing grid creation for prospective reimbursement analysis and budgeting as well as direct integration with GE billing and a custom interface to Epic informing clinicians of research activities. To implement PPM, a dedicated CRMS team conducted customized training and workflow development in individual departments for investigators and their teams. However, after system go-live in seven of 22 clinical areas, WCMC halted PPM implementation in November 2010 due to user dissatisfaction with inflexible system features, including adding procedures to billing grids and adjusting incorrectly specified procedures in downstream billing. At this point, all departments reverted to the previous case- and spreadsheet-based legacy approach, and the CRMS team began hosting vendor product demonstrations to identify a replacement system.

In March 2011, internal audit revealed that investigators were inconsistently using the legacy system for subject enrollment. Investigators cited frequent turnover of research coordinators, who often worked on protocols during their “gap year” before attending medical school, as a point of failure in the subject enrollment process. Audit findings resulted in a policy change that required investigators and their teams to use the Jira bug tracker system to inform central administration staff to create and update subject enrollment data in GE Centricity Business. Multiple attempts at CRMS implementation by the WCMC POBO failed over the course of almost four years.

Methods

In response to previous implementation failures, WCMC adjusted its approach to organization, technology, and workflow for CRMS.

Organization

In April 2011, management reassigned the CRMS team, technology, and business processes from the POBO to ITS, the college-wide IT department, because CRMS was considered a research activity rather than a practice management activity. In May 2011, WCMC licensed StudyManager Reveal, now known as Merge CTMS Investigator, for use as the college-wide CRMS. In addition to providing a solution within budget, the vendor agreed to partner with WCMC in developing a CRMS tailored to the needs of academic medical centers. Shortly thereafter, WCMC PO announced plans to migrate from GE Centricity Business to Epic Practice Management—specifically Prelude for registration, Cadence for scheduling, and Resolute for billing—to more closely integrate PM and EHR activities.

Expanded systems portfolio

After the restructuring of WCMC central research administration in March 2012, the CRMS’s team portfolio expanded to include systems for managing animal protection, laboratory, human subjects protection, funding awards, and conflicts of interest. Recognizing the need for dedicated research IT resources, WCMC established Research Administration Computing (RAC) within ITS to consolidate more than twenty systems and processes for the administration of basic and clinical research. RAC consisted of the existing CRMS manager and team plus personnel responsible for other administrative systems. Notably, the reporting staff for CRMS inherited reporting responsibilities for eIRB, broadening the RAC team’s understanding of available administrative data for research.

Process owner and data steward

In January 2013, the WCMC-NYPH Joint Clinical Trials Office commenced operations and assumed control of business processes for the CRMS and other research administration systems while RAC took the role of data steward. This change followed more than a year of the CRMS implementation team attempting to establish business processes for system use at the institution without a clear mandate for change or mechanism of enforcement. At about the same time, POIS established June 2013 as the go-live date for the new practice management system, which necessitated simultaneous institution-wide CRMS go-live to maintain subject enrollments linked to research visits for scheduling and billing. In preparation for go-live, JCTO and RAC established weekly meetings to create and operationalize policy for CRMS implementation and ongoing use that are described below.

Technology

The CRMS vendor delivered a slightly customized version of its software while the RAC team addressed data quality issues prior to migrating records from the legacy application and developed middleware services for transmitting data across systems.

CRMS vendor system

Standard system configuration enabled creation of protocol definitions, subject enrollments, and billing grids. Per terms of the contract, the CRMS vendor developed custom interfaces between its product and WCMC’s existing LDAP authentication service for user login and Epic patient index for management of study subject demographics. Additionally, the vendor delivered custom formatting of reports for budgets and prospective reimbursement analysis.

Legacy system migration

In preparing to migrate protocol and subject enrollment data from GE to the new CRMS, RAC encountered inconsistent and incomplete records. For example, the legacy application identified each protocol’s principal investigator with free text such as “Smith, John,” “SMITH MD, JOHN,” “6SMITH MD, JOHN” or “SMITH PHD, JOHN” rather than with a unique value or username. To reliably determine the principal investigator of each study for importing into the new system required cross-referencing the IRB protocol number for the study from the GE database with the eIRB system. Additionally, some protocol records lacked a fee schedule, college account number, or hospital study identifier when at least two of the fields should have had values. Resolving such differences required cross-referencing a database of clinical trial agreements under RAC’s authority. Furthermore, medical record numbers of some patients had been deactivated or merged, complicating efforts to identify subjects for properly associating them with protocols. Updating subject identifiers required manual chart review. In response to the data quality issues, JCTO and RAC pursued a two-part strategy: 1) merge study and subject data from the legacy system with other institutional sources to form a complete data set prior to a one-time import into the new CRMS and 2) develop automated interfaces between CRMS and trusted electronic systems as well as workflows to ensure future data quality.

RAC middleware services

Based on recent expansion of reporting responsibility, the RAC team recognized an opportunity to automate transfer of data to CRMS from eIRB for each study—title, IRB protocol number, status, approval date, expiration date, department, study personnel usernames—along with dictionaries of protocol status types, sponsors, sponsor types, and departments—to maintain synchronization across systems and prevent duplicate data entry. Motivating this decision was JCTO’s acknowledgement of IRB approval, and thus eIRB system records, as an authoritative marker of clinical research activity at the institution. RAC also explored using protocol funding sources and initiators entered by investigators in eIRB to determine fee schedules, but data were captured without sufficient consistency in eIRB for automatic transfer to CRMS. This led to capturing these data in a new separate electronic workflow tool for supporting evaluation of studies for scientific merit and financial feasibility, which RAC interfaced to CRMS. Additionally, to ensure appropriate and consistent formatting of study personnel names, RAC developed an automated interface to WCMC’s user security warehouse, the historical record of usernames and actual names of personnel at the institution, for mapping to usernames imported from eIRB. RAC also cross-referenced usernames of principal investigators against an index of Epic users to determine if the user had an Epic SER record, a requirement for users specified as principal investigators for protocols imported into Epic. Data transfers occurred at five-minute intervals during business hours and once nightly for personnel data.

For sending protocol and subject data from CRMS to Epic 2012, RAC and POIS created an automated service compliant with Epic’s text file-based import specification. RAC and POIS used the import specification rather than the interface specification based on the Institute for Healthcare Enterprise (IHE) Retrieve Process for Execution (RPE) profile to be compatible with the local Epic installation’s multiple service areas and fee schedules. Once per minute, a RAC-created service checked CRMS for new or updated protocols and subject enrollments meeting certain criteria, and saved protocol and subject data to separate files on a network volume. POIS’s Microsoft Biztalk integration engine processed files on the network volume every five minutes to import data into Epic for the creation and updating of Epic’s internal RSH records for protocols and LAR records for subject enrollments.

Workflow

To ensure quality of protocol and subject enrollment information, JCTO opted to centralize CRMS workflow. JCTO elected to store all protocol definitions in CRMS via automated transfer from eIRB to enable a comprehensive view of the clinical research enterprise. In contrast, the legacy system, which was manually maintained by an analyst, contained only protocols with billable clinical services. JCTO instructed RAC to configure services to send data from CRMS to Epic only for protocols with clinical services. Additionally, through eIRB and CRMS integration, JCTO tightly coupled IRB protocol status, the institutional designation of whether a study was active and protecting human subjects, with the ability of study personnel to perform research services. If a protocol expired or was closed by the IRB, CRMS automatically received the data, creating a hard stop for subject enrollment and updating Epic.

For subject enrollment, JCTO maintained the existing Jira-based process and disabled the ability of EHR users to enroll subjects in studies using standard functionality in Epic. Although POIS disabled the ability of all users to create protocols and most users to enroll subjects in protocols in Epic, no option existed in the EHR to restrict principal investigators from creating or modifying subject enrollments for protocols in Epic.

To create prospective reimbursement analyses and budgets for each protocol using CRMS, JCTO planned a new process and hiring of new analysts with a start date in 2014. In the interim, JCTO instructed central administrative staff to transcribe clinical service status, college account number, and hospital study identifier to CRMS from spreadsheets submitted by investigators for each protocol rather than to a standalone form as in the legacy approach.

Results

As of October 2014, CRMS contained 7,843 total protocols and had sent 776 (9.8%) protocols with active status and clinical services to Epic. For protocols sent to Epic, CRMS had processed 7,624 subject enrollment statuses for 6,829 unique subjects. Additionally, five principal investigators used Epic to enroll 32 subjects in protocols in violation of institutional policy and CRMS-Epic data integrity. For 118 protocols that lacked clinical services and were not sent to Epic, CRMS contained 6,617 subject enrollment statuses for 5,693 unique subjects.

Discussion

To our knowledge, this case report is the first to describe CRMS implementation success and failures. At our institution, the formation of an organizational unit with ownership of clinical research processes and an information technology group focused on research administration enabled implementation of a CRMS integrated with disparate systems to support centralized workflow processes. In contrast, previous failed approaches at the institution addressed CRMS implementation as an add-on to the administration of clinical care rather than as a comprehensive change to the administration of clinical research.

Integration of data across disparate systems has facilitated adoption and ongoing use of systems for the conduct of clinical care.11 Similarly, data integration for systems involved in the administration of clinical research may assist institutions in overcoming barriers to CRMS adoption and use. At our institution, data entered by investigators and research coordinators into electronic systems for the evaluation of a study’s scientific merit, financial feasibility, and ethics now have downstream effects in EHR and PM systems for clinical research awareness and billing. Reuse of administrative protocol data heighten the need for data quality assurance, source system data capture design, and user training.

While the approach we describe has to date replaced a legacy system’s protocol definition and subject enrollment functionality, our institution lacks CRMS-based billing grid creation at the time of this writing. However, through CTMS implementation, JCTO and RAC have created the organizational and technological infrastructure necessary to support research billing compliance, and plan to implement a new process and staffing model for centralized billing grid creation. Future study will evaluate the effect of CRMS billing grid creation and integration with the EHR and PM systems on measures of research billing compliance such as gross collection rates12.

As institutions increasingly adopt commercial EHR systems, they are beholden to vendors for clinical research features. At the time of our CRMS implementation, Epic EHR did not permit us to restrict the ability of principal investigators to enroll subjects into protocols within Epic, which resulted in rogue subject enrollments. Although the subject enrollment process at our institution is centralized, it remains voluntary, and auditing compliance requires record of every subject’s informed consent form. At present we lack a system for electronic consent, and our installation of Epic stores consent forms as scanned documents with limited metadata. We urge industry to address clinical research needs in upcoming EHR releases.

This case report addresses the paucity of literature on CRMS implementation success and failure. Other institutions may find the centralized clinical research management approach described in this report valuable for implementations while researchers may use the illustration of organization, technology, and workflow for CRMS to inform evaluation efforts.