CyclOps: Cyclical development towards Operationalizing ML models for health

4.1 Query API

The first stage of any machine learning pipeline is data extraction. Data scientists often refer to this process as Extract, Transform, Load (ETL), where data in a raw format is extracted from a database, transformed to a more clean and structured format, and loaded into a new database. Health data, and especially EHR data, is often stored in relational databases, where programs written in the Structured Query Language (SQL) are typically used to perform ETL on said databases. However, SQL code can be hard to understand and maintain, serving as a distraction and limiting the extensibility of data pipelines.

To address this problem, we introduce a query API implemented in Python. As shown in figure 2, the query API consists of low-level functions that can be used to perform common operations on the database. These functions use the SQLAlchemy toolkit which implements an Object Relational Mapper (ORM), that can be used to query relational databases. The output of the query API are Pandas DataFrames, a common representation used for static and temporal (time-series) data.

• Download figure
• Open in new tab

Figure 2:

The Query API can be used to query EHR databases. The querying operations are modules implemented using the functional API, which in turn uses the SQLAlchemy toolkit. These modules can be combined sequentially to create the set of operations to apply on the database.

Operations such as casting columns to specific data types, adding a new column, joins, re-ordering, and so forth, can now be used as modules and combined sequentially. Hence, we can use these modules to create a set of high-level API functions to query EHR databases. As an example shown in code snippet 1, we can create functions that accept various arguments used to perform operations on the database. To process these arguments, we use a Query Argument Placeholder (QAP) class, which wraps around the provided arguments, which is then used to optionally apply querying operations provided the necessary arguments are specified.

The query API enables the creation of easy-to-use API functions to query EHR databases. We provide API functions to query the popular MIMIC-IV [6] database, with plans to support other popular research datasets. As shown in example code snippet 2, we can use these functions to easily extract a cohort of interest towards a use case.

We also provide high-level API functions to query datasets that are available in the OMOP Common Data Model (CDM) [13]. The adoption of a common data model for EHR data has several advantages, and several health institutions have successfully converted their data to OMOP or are in the process of doing so. Hence, our default support extends to OMOP databases. We do provide support for developers working on arbitrary databases, where the query API can still be applied after writing some wrapper code - for which there are tutorials and examples.

• Download figure
• Open in new tab

Listing 1:

An example of a high-level API function to query a dataset. In this example, the table consists of patient administrative data, and hence arguments to the function can be used to filter the data based on admission timestamps, hospital and gender.

• Download figure
• Open in new tab

Listing 2:

An example of the usage of the query API to extract data from the popular MIMIC-IV database. In this example, we filter patient encounters from the year 2015, and further filter those that had a diagnoses associated with delirium.

4.2 Process API

Once data is extracted to create a subset of interest, it needs to be processed towards creating useful representations for ML models. These features are structured for use in machine learning, for example through vectorization. NumPy arrays and PyTorch tensors are examples of vectorized data containers that are used as input to ML model implementations. Transforming raw health data into these vector representations is a multi-step process, and we provide a process API which supports:

• Cleaning: Formatting values, adjusting data types, unit conversion, checking and fixing issues with raw data.

• Aggregation: Grouping infrequent and unevenly spaced temporal measures into buckets, e.g., for aggregating lab measurements into fixed time-interval buckets, or grouping values by patient ID.

• Normalization: Normalizing values into standard ranges or using statistics of the data.

• Imputation: Handling missing values in the data. For time-series clinical data, ‘missingness’ contains valuable contextual information about the patient’s health and needs to be handled carefully. The imputing step fills missing values using various configurable approaches including mean, median and forward, and/or backward filling for time-series data.

• Slicing: Filtering the data based on conditions applied to columns. For example, slice the data by a column that contains age information to obtain a subset with all patients above the age of 50.

• Dataset splitting: Splitting the data into different subsets, for example, training, validation and testing subsets, as well as supporting cross-validation procedures.

• Vectorization: Converting patient representations into vectors which are ready to be used as inputs to ML models. This format typically consists of multi-dimensional arrays over which operations are more efficient.

• Health-specific processing: Processing steps specific to health data, such as grouping diagnosis codes (ICD-10 codes) into disease trajectories to create features. ICD-10 codes tend to be sparse and granular, and hence grouping them offers more useful representations for modelling.

As shown in Figure 3, the process API provides functionality to parse a raw DataFrame into an intermediate format to represent features, using data containers for them. These intermediate containers hold the data as Pandas DataFrames, while providing useful methods to create feature sets for analysis and modelling. There are two containers TabularFeatures and TemporalFeatures, which inherit a base Features class. These containers hold the extracted data, the features of interest as specified by the user and metadata information about the features, such as the type and whether it may be a target variable. If the feature is an indicator variable, the metadata also has information about its parent variable. The container automatically attempts to detect feature types which can be string, numeric, binary, or categorical indicators (dummy variables).

• Download figure
• Open in new tab

Figure 3:

The Process API supports various processing steps towards transforming raw EHR data into features for ML models. The Features and Vectorized data containers are primarily used to featurize and vectorize the data respectively.

The user can also force a feature to be of a certain type, thus allowing flexibility. Furthermore, the containers support useful methods to normalize, slice, split and vectorize the features data. The TemporalFeatures container has an additional aggregate method that aggregates the time-series data. We provide an additional Vectorized data container for storing vectorized data. This container holds the data as NumPy arrays, and also contains useful methods to normalize and split the data. Example code snippets 3 and 4 show how to instantiate the feature containers and call methods to aggregate and vectorize the data.

Model implementations that use the scikit-learn [15] and PyTorch [14] frameworks interface well with NumPy arrays. We provide a models library that contains reference implementations of several commonly used ML models for clinical data, and showcase examples that ingest data from the Vectorized data containers.

4.3 Monitor API

As the barrier to scaling clinical AI systems, shifts from model development to deployment, there is a growing need for continuous monitoring and updating in order to understand when a model is likely to output erroneous predictions due to distributional shifts. The monitor API allows for the detection of data drift prior to model failure in order to inform end-users and trigger retraining and updating procedures. It provides support for rigorous ML model monitoring across time, patient cohorts, location, and custom data splits to enable the safe deployment of clinical ML models. The methods use state-of-the art drift detection methods [21] and are designed to work with high dimensional data by performing dimensionality reduction followed by a two-sample or classifier-based test to identify and characterize whether there is a statistically significant distribution shift between the source and target domain [17]. In this regard, the API provides the following:

• Download figure
• Open in new tab

Listing 3:

Processing of static features, using the TabularFeatures class.

• Download figure
• Open in new tab

Listing 4:

Processing of temporal features, using the TemporalFeatures class.

• Clinical Shift Applicator: Enables real clinical experiments for drift detection through splitting the data into different subsets across time, patients’ cohorts, locations, seasons, or unprecedented events such as COVID.

• Synthetic Shift Applicator: Perturbs a subset of data synthetically using a variety of covariates and label shifts with varying magnitudes and proportions.

• Rolling Window Analyzer: Evaluates the model stability and potential drift over time using discrete buckets of time.

• Reductor: Performs various linear and non-linear dimensionality reduction techniques to produce lower dimensional latent representations for downstream testing. The Reductor also supports dimensionality reduction using Black Box Shift Estimators (BBSE) [9] across various deep learning algorithms for EHR and imaging data.

• Domain Classifier Tester: Implements domain classifiers to identify if a shift in the distribution has occurred between the latent representation of source and target domains.

• Two-Sample Tester: Implements univariate and multivariate two-sample statistical tests to identify if a shift in the distribution has occurred between the latent representation of source and target domains.

The monitoring API can be implemented using three main steps: (1) shift application, (2) experiment selection, and (3) drift detection. As previously mentioned, the primary goal is to detect distribution shifts in clinical data.

Shift Application

The first step is shift application which involves the creation of source and target datasets based on criteria and conditional logic defined by the user. Given the nature of the intended shift, the user can choose to leverage the SyntheticShiftApplicator or the ClinicalShiftApplicator. The SyntheticShiftApplicator adds synthetic perturbations that span a variety of covariate and label shifts with varying magnitudes and fractions of affected data to the target subset of the dataset. The ClinicalShiftApplicator includes conditional logic to select subsets of data based on hospital, time, patient population, and other sensitive attributes (e.g. age, race, gender) to enable real-life drift detection experiments.

• Download figure
• Open in new tab

Listing 5:

Shift Application using the ClinicalShiftApplicator class.

• Download figure
• Open in new tab

Listing 6:

Shift Application using the SyntheticShiftApplicator class.

Drift Detection

The final step is drift detection using the Detector which consists of two components: Reductor and Tester. The Reductor supports various techniques to reduce the dimensionality of source and targets datasets. The dimensionality reduction technique is fit using the source dataset and is subsequently used to transform the target dataset into a lower dimensional space. Following reduction, the Tester performs the two sample statistical test to detect distribution shift between the source and target datasets in the lower dimensional space. For the statistical test, users can choose between TSTester to perform two-sample statistical tests or DCTester for domain classifier-based tests. Depending on the type of experiment selected by the user, the final output of the pipeline would be either a p-value sensitivity test plot or a rolling-window plot. The p-value plot indicates the p-value for each test with increasing number of target samples along with mean and standard deviation of the p-value across multiple runs. The rolling window plot yields an array of p-values for each test across time for the rolling window scheme specified along with an array that specifies whether the p-value fell below the threshold for each time-step.

• Download figure
• Open in new tab

Listing 7:

Initialize Detector with Reductor and TSTester and conduct sensitivity test.

• Download figure
• Open in new tab

Listing 8:

Rolling window drift experiment, using the RollingWindow class initialized with the Detector.

5.1 General Internal Medicine Unit - GEMINI

GEMINI is a multi-center database comprising information related to patients admitted to general internal medicine units at 7 large hospitals in the Greater Toronto Area from 2010-2020. GEMINI is a relational database which includes 13 tables and 156 variables comprising administrative and clinical information. We used the GEMINI database ?? to indicate the usability of the CyclOps framework for three real-life clinical tasks: (1) in-hospital mortality risk prediction, (2) mortality decompensation prediction, and (3) length of stay in the ER. We showcase three clinical use cases that leverage different combinations of input data, ML modeling, clinical outcomes, and drift detection experiments to build robust clinical AI systems using CyclOps.

5.1.1 In-hospital mortality risk prediction

We used the data and drift detection pipelines of the CyclOps framework for the task of in-hospital mortality risk prediction. The data pipeline as shown in Table 1, was used to create vectorized data to be used by the ML classifier which is a Gradient Boosted Tree (GBT) to predict in hospital mortality. Given the non-temporal nature of the GBT model, the input data to the model is the combination of vectorized static data and temporal features aggregated over the first six days of patients’ stay in the GIM unit in the hospital. Only patients’ data whose length of stay (LOS) in the hospital was more than 24 hours were included in this clinical task. In total 17,365 data records were created by the data pipeline where a subset was used for GBT training and the rest for model evaluation and drift detection analysis.

View this table:

• View inline
• View popup
• Download powerpoint

Table 1:

Data pipeline summary for the example use cases. The dataset sizes and parameters can be configured by researchers.

The framework’s drift detection pipeline was then leveraged to evaluate the GBT’s robustness across changing season, location, and the COVID-19 outbreak as shown in Table 2. For each drift detection experiment, the GBT model was built on source data and evaluated on out-of-distribution target data. The source and target data splits were created by the ClinicalShiftApplicator under the Shift Applicator module in the pipeline 4. As the results in Table 2 indicate, the performance of the model trained on community hospitals deteriorated when used to predict in-patient mortality in academic hospitals. To statistically measure data drift in a label-agnostic manner we used the CyclOps Detector module with a trained BBSE as the Reductor and MMD as the TSTester. Figure 5 depicts the p-value sensitivity test plot produced by the drift detection pipeline.

View this table:

• View inline
• View popup
• Download powerpoint

Table 2:

Gradient Boosted Tree (GBT) model performance across dataset shift experiments.

• Download figure
• Open in new tab

Figure 4:

The Monitor API supports shift application, experiment selection and drift detection.

• Download figure
• Open in new tab

Figure 5:

Drift detection experiments using the Detector for a GBT model trained on community hospitals evaluated on in-distribution data from community hospitals (blue) and out-of-distribution data from academic hospitals (red). Sensitivity across increasing number of samples from test data for a) drift p-values and b) performance (AUROC)

5.1.2 Mortality Decompensation Prediction

We used CyclOps framework to build a dynamic model for predicting patient’s functional health deterioration over time. To predict functional deterioration which is risk of mortality in our case, we stepped forward through each patient’s longitudinal data, and made predictions every 24 hours for the risk of mortality within the next two weeks starting 24 hours after admission. Patient’s longitudinal data included temporal clinical measures for six consecutive days at (a) the GIM unit. For the classification task, we used varying length LSTM model using the target replication approach [10] to predict mortality at every time step (24 hours). In addition to patient’s longitudinal clinical measures, baseline demographics as static variables are also used at every time step for the prediction task.

CyclOps data pipeline as detailed in Table 1 was used to create patients data for the prediction task. Out of 88,496 vectorized records generated by the pipeline, 46,975 was used for model development which was captured up to January (pre-COVID-19) and the rest was used for comprehensive evaluation and drift detection. The LSTM model was trained on 46,975 observations and tested on 29,738 observations with an AUROC score of 0.793 on pre-COVID-19 test data.

Following the model development, drift detection pipeline was used for rigorous evaluation of the model across time and mainly during the COVID19 time through rolling window analysis. Figure 6 illustrates the rolling window plots generated by the framework which includes trajectories across 15 months for drift: distance and p-value, and model performance: sensitivity, PPV, AUROC, and AUPRC. The p-values are produced by the Detector module in the drift detection pipeline using a BBSE (trained LSTM model) for the Reductor and MMD test for the Tester.

• Download figure
• Open in new tab

Figure 6:

Monitoring data shifts in mortality decompensation prediction from 03/2019 to 07/2020 using a 30-day RollingWindow. It can be seen that drift is detected in 03/2020 (red), which corresponds to when Ontario declared the COVID-19 pandemic a state of emergency and entered a province-wide lockdown.

5.2 Medical Information Mart for Intensive Care (MIMIC)-IV

MIMIC-IV is a single-center database comprising information relating to a diverse and very large population of ICU patients between 2001 and 2012. The database includes static (e.g., demographics and baseline measures) and temporal information (e.g.,vitals, medications, and interventions) extracted from several sources including archives from critical care information systems, hospital EMR, and Social Security Administration Death Master File. MIMIC-IV is a relational database consisting of 26 tables and is freely available to researchers worldwide.

5.3 NIH Chest X-Ray Dataset

We utilized the chest X-ray dataset from NIH [23] to demonstrate the usability of CyclOps framework for detecting distribution shift in medical imaging data. The dataset contains 112,120 frontal-view X-ray images of 30,805 unique patients with fourteen disease image labels extracted from the corresponding text-based radiology reports. The creators of the dataset have already split the data into a training set of 80,000 images, a validation set of 10,000 images, and a test set of 10,000 images. Using the drift detection pipeline, we performed two synthetic shift experiments where the images in the test set were synthetically perturbed using the SyntheticShiftApplicator. In our first experiment, we corrupted the samples in the test set with varying levels of Gaussian noise which formed our target dataset. In our second experiment, we performed categorical shifts by sub-sampling the target dataset based on patients’ demographics information (age, gender, or ethnicity). This would artificially change the distribution of patients’ demographics across observed classes. For both experiments, we initialized the Reductor with a pre-trained autoencoder from the TorchXrayVision library [1] to reduce the dimensions of the images, and MMD as for the Tester. Using the Detector we configured with the Reductor and TSTester, we performed sensitivity tests and obtained the p-values shown in Figure 7.

• Download figure
• Open in new tab

Figure 7:

Drift Detection experiments on NIH Chest X-Ray data. a) Gaussian noise injection experiments for an increasing amount of Gaussian noise. b) Categorical shift experiment to simulate population shifts based on categorical metadata.