Xcellerate Investigator Portal: A New Web-Based Tool for Online Delivery of Central Laboratory Data, Reports, and Communications to Clinical Sites (2024)

Build versus Buy Analysis

On the surface, the identified use cases and high-level requirements were similar to those frequently met by commercial off-the-shelf (COTS) document management, content management, and portal frameworks. Our detailed requirements and business logic, however, would require extensive customization to any such COTS platform and force us into a development paradigm that would limit our ability to achieve our product vision. Most commercial frameworks marketed for these purposes are Java-based, which is not our preferred development language. In addition, we had already developed extensive web-based visualization and analytic software assets that we could leverage to quickly bootstrap a custom product to meet our specific needs. Finally, from a strategic perspective, we estimated that a custom, fit-for-purpose solution would be cheaper and easier to maintain, enhance, and support in the long term.

User Interface

The design of the front end focused on building an easy-to-use, robust, and highly performant interface optimized for the site investigator role (including their supporting staff). We borrowed design patterns and ideas from popular internet and mobile applications that would be familiar to our diverse and global audience. Visualizations are also a key enabling feature in all of the Xcellerate applications; for the Xcellerate Investigator Portal (XIP), the primary focus was on assisting investigators in monitoring patient safety. The key application views are summarized below.

The application landing page uses a familiar card layout concept to provide easy access to all the studies accessible to that individual user (Fig. 1). Besides study identification information, each card also displays the counts of unread documents in the key document categories to facilitate the identification of new information. Simple search, sorting, and favorites features are also provided. The application toolbar, accessible from every page, provides links to general non-study information and also displays notifications for new, unread content.

Notification count indicators, similar to those displayed in mobile apps and on social networking sites, are used through the application to notify the user of new, unread content. All user content downloads are logged and may be reported to study sponsors for compliance purposes. Unread content indicators are used on the landing page, the application toolbar, and the individual study pages to assist the user with compliance. When content is required to be read by only a single user at a site for compliance purposes, a status indicator is provided to show if another user from the same trial site has downloaded that content.

As previously mentioned, the primary use cases of the application involve investigator and site staff receiving, reviewing, and possibly printing and/or saving trial test results and result alerts. We use the familiar pattern of a web-based email application inbox, specifically Gmail, as the interface for users to view and access new and historical content (Fig. 2). This is a friendly tabular format with information sorted in reverse chronological order by default and using bold font to indicate unread content. In addition, bulk action features are provided to assist users with repetitive tasks of downloading and printing reports. Simple search and common filters also allow easy retrieval of content. This common inbox pattern is consistently used in all views in which the user receives and accesses document-type content.

Prior to XIP, lab test results could be accessed by investigators only via legacy faxes or as PDF reports. XIP adds online viewing of these data to assist the investigator in identifying trends that may provide additional insights into patient safety. These data can be displayed either at the site level or for an individual subject. Both Excel-like tabular views and visualizations are used to provide convenient and insightful views of all data collected at the site.

The standard test results view (Fig. 3, top) displays all of a site’s test results in a user-friendly tabular view. The application’s tabular control provides several options to help find relevant results, including sortable columns, grouping, simple search, visual indicators, unit selection, field-level filtering, saved searches, and export to Excel or CSV (comma-separated values) files. Also provided is the ability to drill down to subject views. In addition to standard test results, some protocols require the presentation of microbiology test results. These data need to be viewed in a unique hierarchical layout, so a separate view was created for the data, as shown at the bottom of Figure 3.

To view test result trends for multiple subjects throughout visits, we added a standard test results trend view, as shown in Figure 4. This view allows plotting the results of a single lab test for a series of subjects among all visits, normalized in time by starting each patient curve at the initial screening visit. Chart symbols are color-coded by flag value, which usually indicates results that are higher or lower than the normal reference range. Hovering over a subject’s data point displays the specific subject’s reference range, and clicking a data point drills down to the subject’s lab results view.

The subject lab results view (Fig. 5, top) provides a way to view all of a subject’s test data in a convenient tabular form organized by visit and test types. Like other test views, many features are provided to help the user find relevant information, including simple search, flagged values, indicators, a flagged values filter, and export to Excel and CSV files. In addition, drill-up capabilities are provided to help compare test results from other patients.

The subject test trends view (Fig. 5, bottom) displays test trends for a single patient’s test results throughout all visits. The data are plotted as aligned small multiple charts, and data points are colored to indicate flagged values, aiding the investigator to view and correlate trends that may help monitor patient safety. Simple search, test group filtering, and a flagged test filter are provided to isolate relevant information.

Logical Architecture

As mentioned above, XIP leverages the proven web application architecture used for other dashboard and reporting applications in the Xcellerate informatics suite. This is a standard, three-tier architecture composed of a data layer, application layer, and presentation layer (Fig. 6). The data layer consists of the existing relational data warehouses for protocol information and laboratory test result information. A new application-specific database was created to store application-specific configuration data and materialized views for performance optimizations. The application layer consists of a monolithic RESTful web application programming interface (API) that provides endpoints to support reads and updates of the relevant underlying data. In addition, several independent back-end services for file upload, notifications, and user provisioning were retained from the legacy ESA application to provide continuity; the services for report delivery were completely rewritten to allow the system to perform at the required maximum capacity. Finally, the presentation layer consists of a browser-based, single-page application (SPA) that was designed to take advantage of the capabilities of modern browsers and primarily designed for desktop- or large tablet–sized devices.

Physical Architecture

The protocol data warehouse is an Oracle relational database¹⁴ composed of multiple physical schemas that separate data by function: security, protocol definition, and report metadata. The laboratory result data warehouse is an IBM Informix¹⁵ relational database. Both warehouses get frequent (mini-batch) updates via ETLs (extract, transform, and load procedures) from the Zavacor system. For the application-specific database, we chose to use the existing Oracle database for convenience and compatibility with the legacy applications and services which were not being replaced. In addition to creating new database tables to support new features in the application, we also implemented a view abstraction layer and materialized views to improve query performance on large datasets.

The RESTful API was built using ASP.NET.¹⁶ A Command Query Responsibility Segregation (CQRS) pattern¹⁷ was used to separate the read and update models with the primary purpose of optimizing read performance in the reporting modules of the application. The CQRS model was built on top of the Dapper simple object mapper for .Net¹⁸ instead of using a “heavy” object relational mapping (ORM)¹⁹ layer. We have found that the transparency and ease of query implementation improve maintainability and allow data engineers to more easily contribute to development efforts.

Other application-layer services were written in .Net as follows:

1. zReporting Services: Report-processing services that receive report messages in JavaScript Object Notation (JSON) format from Zavacor, convert them to HTML and PDF, save the files to a file share, and insert document metadata into the warehouse. The zReporting services are implemented as a set of .Net Web Services using the Hangfire.IO library²⁰ to ensure that all required tasks are queued and completed as expected.

2. Notification Service: A scheduled Windows service that sends out instant notifications and daily digests based on protocol and user preferences.

3. File Upload Service: A scheduled Windows service that provides semi-automated upload capabilities for lab manuals and training material documents.

4. Provisioning Services: A set of scheduled Windows services that allow authorized internal users to request access on behalf of site users and have those requests automatically fulfilled without further human intervention for each user provisioning event.

The presentation layer was designed as a JavaScript Single Page Application (SPA)²¹ and built using Angular,²² a TypeScript-based, open-source, front-end web application platform led by the Angular Team at Google and by a community of individuals and corporations. Other third-party open-source and commercial JavaScript libraries were also used: Material Design Lite²³ was used for the base component and layout framework, and ag-Grid²⁴ was used for all data grid implementations in the application. For visualizations, we used our proprietary D3.js-based²⁵ library that we originally developed for our Xcellerate Medical Review application.⁴ Finally, for identity management and authentication, we used Okta,²⁶ an OpenID Connect²⁷ compliant cloud-based identity provider. All connections to the system are strictly required to be secure, incorporating strong Transport Layer Security (TLS) encryption for all traffic to and from the user’s browser.

Performance Considerations

XIP is used by more than 240,000 investigator staff worldwide on more than 1,800 studies containing greater than 30 million lab report and result alert documents. In addition to study-generated content, all usage and change history are also tracked. With such large amounts of data, performance had to be designed into the system. We used a number of design elements to ensure that the visualizations and document lists load within the performance targets set for the application, including optimized database indexing; materialized views for common queries of slow-changing data; a high-performance micro-ORM data access layer; a CQRS pattern to optimize read queries; horizontally scalable, redundant application servers; a high-performance user interface data grid control; and stateless and asynchronous data flow by default in the application and presentation layers. The system as implemented has been considerably more responsive under load than its predecessor. At peak load, users are able to access the XIP application landing page 50% faster than the comparable ESA page. In addition, lab report access times are up to 80% faster, measuring consistently faster than 2 sec for typical usage scenarios. The fault-tolerant design allows for some system maintenance to be performed while the system remains active for end users, and reduced unplanned outages by more than 60% (comparing XIP availability in 2018 to ESA availability in 2017).

Declaration of Conflicting Interests: The authors, all of whom were employed by Covance when the system was built, confirm that there are no known conflicts of interest associated with this publication, and there has been no significant external financial support for this work that could have influenced its outcome. No study sponsor has been involved in the design of the system; the collection, analysis, and interpretation of the data presented herein; the writing of the manuscript; or the decision to submit the manuscript for publication.

Funding: The authors received no financial support for the research, authorship, and/or publication of this article.

ORCID iD: Dimitris K. Agrafiotis https://orcid.org/0000-0002-5604-5692

4. Agrafiotis D. K., Lobanov V. S., Farnum M. A.; et al. Risk-Based Monitoring of Clinical Trials: An Integrative Approach. Clin. Ther. 2018, 40, 1204–1212. [PubMed] [Google Scholar]

5. McCaffrey R. P., Tevelev B. M., Yang E.; et al. A Statistical Evaluation of Observed Risk Flux in RBM-Managed Clinical Trials. Submitted for publication. [Google Scholar]

6. Farnum M. A., Mohanty L., Ashok M.; et al. A Dimensional Warehouse for Integrating Operational Data from Clinical Trials. Database. 2019, 2019, baz039. [PMC free article] [PubMed] [Google Scholar]

7. Yang E., Scheff J. D., Shen S. C.; et al. A Late Binding, Distributed, NoSQL Warehouse for Integrating Patient Data from Clinical Trials. Database. 2019, 2019, baz032. [PMC free article] [PubMed] [Google Scholar]

8. Farnum M. A., Ashok M., Kowalski D.; et al. A Cross-Source, System-Agnostic Solution for Clinical Data Review. Database. 2019, 2019, baz017. [PMC free article] [PubMed] [Google Scholar]

9. Ciervo J., Shen S. C., Stallcup K.; et al. A New Risk and Issue Management System to Improve Productivity, Quality, and Compliance in Clinical Trials. JAMIA Open. 2019, 2, 216–221. [PMC free article] [PubMed] [Google Scholar]

10. Agrafiotis D. K., Simson A., Dai H.; et al. Advanced Biological and Chemical Discovery (ABCD): Centralizing Discovery Knowledge in an Inherently Decentralized World. J. Chem. Inf. Mod. 2007, 47, 1999–2014. [PubMed] [Google Scholar]

11. Farnum M., Lobanov V. S., Brennan M.; et al. Clinical Case: Enhancing Medical Monitoring with Visualization and Analytics. Presented at 2012 IEEE International Conference on Bioinformatics and Biomedicine, Philadelphia, PA, 2012. [Google Scholar]

12. Yang E., O’Donovan C., Phillips J.; et al. Quantifying and Visualizing Site Performance in Clinical Trials. Contemp. Clin. Trials Commun. 2018, 9, 108–114. [PMC free article] [PubMed] [Google Scholar]

13. Cepeda M. S., Lobanov V. S., Farnum M.; et al. Broadening Access to Electronic Health Care Databases. Nature Rev. Drug Discov. 2010, 9, 84. [PubMed] [Google Scholar]