Supplementary Material to the Conference Paper "Towards Certifiable AI in Medicine: Illustrated for Multi-label ECG Classification Performance Metrics"

1 Towards Cer+fiable AI in Medicine: Illustrated for Mul+-label ECG Classifica+on Performance Metrics This repository contains comprehensive informa2on complemen2ng the corresponding paper Towards Cer+fiable AI in Medicine: Illustrated for Mul+-label ECG Classifica+on Performance Metrics (link will be added as soon as it is published). The folder “Results_Metrics_Selec2on” contains the evalua2on of our experimental results regarding reliable performance evalua2on metrics for mul2label electrocardiogram (ECG) classifica2on. The folder “QG_Process_Structure” and its subfolders illustrate the lifecycle integra2on of the introduced and empirically extracted approach for machine learning (ML) design decision making as part of the exemplary documenta2on centered around our generic and customizable methodology based on Quality Gates towards cer2fiable AI in medicine.1 This setup intends to define at what stage, which design decisions are relevant, and when they should be revisited, while providing a structure for (automatable) documenta2on to achieve a comprehensive risk management. Our proposed generic and customizable methodology is intended to be extended in a prac2cal way based on (groups of) medical use cases with further research. First, our experimental results (1) as well as their basic setup (2) are briefly introduced. Next, the accompanying folder structure (3) is embedded within the context of our methodology and finally, the empirically extracted method towards ML design decision making (4) is outlined. 1. Experiments – Results The experiments are intended to derive applicable guidelines for a trustworthy metrics selec2on illustrated for ECG mul2-label classifica2on. Their results and evalua2on are included in the accompanying folder “Results_Metrics_Selec2on”. On a process-level, the experimental structure is embedded within our methodology, as explained in the following sec2on. Since the experiments are based on the open-source Physionet data2 – a ready-to-use ML data set with a well-known distribu2on, the data is not explored further in a prac2cal manner – except for the label structure. The empirical results are explained in more detail in the respec2ve files that are introduced in more detail in the corresponding paper, where the overall approach and medical seYng are explained, as well. Overall, a use case-adapted compila2on of mul2ple metrics is necessary for a comprehensive evalua2on. We present a metrics compila2on that consists of the most known and widely used classifica2on metrics, which we believe can be applied as founda2on or point of reference for other use cases and based on the tuning objec2ve and medical seYng other/new metrics can be added analogously. Regarding binary-based mul2-label classifica2on performance metrics combined with high data imbalance and a ‘meaningless’ nega2ve class (absence of a label), the following generalizable tendencies can be deducted based on our experiments: • Macro-averaged metrics are most reliable, they treat all labels equally and are not influenced by label support in the data set • Receiver Opera2ng Characteris2c Area under the Curve (ROC AUC) should be referenced with cau2on since it behaves very op2mis2c compared to the predic2on vs. groundtruth label distribu2on and appears to not accurately mirror the model’s confidence • Precision Recall Area under the Curve (PR AUC) appears to mirror the model’s confidence more realis2cally 1 M. Elia et al., A methodology based on quality gates for cer:fiable AI in medicine: towards a reliable applica:on of metrics in machine learning, ICSOFT, 2023. 2 hHps://github.com/physionetchallenges/evalua:on2021/blob/main/dx_mapping_unscored.csv 2 • Addressing label correla2ons that exist in the real world is crucial for binary based mul2-label classifica2on. We adapted a domain-embedded approach3 to integrate label correla2ons based on a benefit matrix to our use case that can be op2mized further The hypothesis that should be tested next, is whether our findings are applicable to any binary based mul2-label use case that is characterized by a high data imbalance and the nega2ve class of the averaged binary case has no prac2cal meaning4 as with our use case situated in emergency medical care. Further, based on our tuning objec2ve, F1-Score is the metric that should be monitored during training to op2mize the desired results even though its impact amounts to only a few percentage points. It balances Precision and Recall, the two metrics that mirror most our real-world objec2ve based on the predicted label distribu2on. Supplementary metrics that project similar perspec2ves are Specificity and False-Posi2ve-Rate (FPR). Addi2onal metrics to analyze the label distribu2on in more detail include Jaccard-Score and Machews-Correla2on Coefficient (MCC), as well as PR AUC to analyze the model’s confidence. Finally, more data, especially for rare labels is necessary, since as our experiments have shown, some labels are not sufficiently represented in the data to achieve a reasonable measurement. However, based on the real-world distribu2on, luckily healthy people outweigh and other means to address data imbalance should be considered in parallel. For instance, regarding performance metrics, imbalance can be addressed through threshold post-processing when calcula2ng confusion matrix-based metrics, as in the present research. This method necessitates to be updated in line with the data set’s dynamic distribu2on. The following research ques2ons were focus of our experiments centered around performance metrics and more comprehensive informa2on on our results is contained in the complementary folders. 1. Label support in data set a. Propor3onal split > mirrors Physionet data distribu3on b. Comparison of 20 more fine-grained and 8 more compact labels c. Introduc3on of container-labels to elevate support and mirror the medical use case 2. Metrics Compila3on a. Selec3on b. Domain-embedded interpreta3on 3. ROC AUC vs. PR AUC a. Expressiveness and applicability 4. Mul3-label averaging a. Expressiveness and applicability 5. Metric-to-monitor during training a. Focus on F1vs. Fbeta-Score (macro-averaged) 6. Post-processing thresholding methods a. Comparison of FIXED (0.5) vs. CIST3 vs. PR vs. ROC Thresholding 2. Experiments – Setup We applied a basic setup for our experiments, since the focus lies on process extrac2on and analysis of interrelated tendencies concerning ML performance metrics, rather than a profound performance op2miza2on. Our experiments are implemented based on the open-source framework LIFEDATA5 and our model architecture is adapted from Xu et al.6 It consists of a combina2on of bidirec2onal Long Short-Term Memory and Convolu2onal Neural Networks. The experiments are run based on a propor2onal, stra2fied split into 70% train, 10% valida2on and 20% test data. This guarantees an equal 3 Y. L i u e t a l . , A u t o m a : c M u l : -Label ECG Classifica:on with Category Imbalance and Cost-Sensi:ve Thresholding, Biosensors, 2021. 4 An excep:on is the label norm that refers to a healthy pa:ent. The nega:ve label signifies that something is wrong with the pa:ent. However, due to :me-sensi:vity of some abnormali:es, this informa:on is not enough in an emergency seTng. 5 F. S:eler et a l., LIFEDATA - a framework for traceable ac:ve learning projects, IEEE (REW), 2023. 6 X. Xu et al., Interpreta:on of Electrocardiogram (ECG) Rhythm by Combined CNN and biLSTM, IEEE Access, 2020. 3 label distribu2on among the different subsets, which ensures that rare labels are represented in each set. Further, this approach incorporates the underlying data set's distribu2on, in our case the Physionet data, which impacts the model's performance depending on the rela2on between the known data during development and the new data it encounters amer deployment in the real world. However, based on our fic2onal seYng, the evalua2on of such considera2ons is beyond the scope of this part of the AI lifecycle flow. During training, early stopping was integrated and dura2on limited to maximum 50 epochs with a batch size of 32. Other hyperparameters were adapted to Liu et al.,3 i.e. the ini2al learning rate of 0.001 with Exponen2al Decay, Adam Op2mizer and Binary Cross Entropy Loss. 3. Folder structure – Quality Gates along the lifecycle Among others, a thorough documentation of AI lifecycle design decisions and their definition is mandatory for audits of intelligent systems in medicine. With the objective of achieving long-term (semi-)automation, documentation can be structured in alignment with the generic lifecycle flow.7 This is mirrored by the accompanying folder “QG_Process_Structure” and its subfolders in an exemplary manner. Overall, the presented setup intends to define at what stage, which design decisions are relevant, and when they should be revisited in accordance with other design decisions from a horizontal and vertical perspective. Our methodology is intended to serve as a foundation for the research community and the industry to structure information on (groups of) medical use cases and result in concrete guidelines that are intended to be continuously extended and tested by the research community. We aim to propose a generic and customizable concept to collect and create concrete approaches for trustworthy AI lifecycle management in form of QGs, since the outlined project is enormous to complete for every existing medical use case and data type. Consequently, the proposed folder structure aims to illustrate the global QG organization along the AI lifecycle flow processes, while providing an option to include the system’s evolution,8 since AI models can continuously learn and evolve. The presented setup provides a structure for (automatable) documentation to achieve a comprehensive and continuous risk management, which is a fundamental part of our proposed methodology. It is illustrated in detail on GitHub. Especially, the Lifecycle – Development – Evaluation section contains related QGs that are based on this contribution. https://github.com/miriamelia/MQG4AI Concretely, the introduced planning structure mirrors the AI lifecycle flow star2ng with the generic high-level QGs. Their defini2on is based on the development of comprehensive concepts for AI lifecycle processes under considera2on of regulatory requirements tailored to specific use cases with individual tuning objec2ves, data, and medical knowledge, for instance. The iden2fied procedures propagate relevant informa2on towards low-level QGs and use case-specific low-level QGs are defined in accordance with high-level QGs. For instance, the chosen model architecture depends on the intended use, which impacts other design decisions, as well. Further, the development of an overall concept for QG Model of mul2-label ECG classifica2on under considera2on which design decisions can be generalized and to what extent is part of our proposed methodology. In the present research, we focus on the low-level QG Performance Evalua+on Metrics that contributes to the required risk mi2ga2on in the grand scheme of QG Model through reliable performance metrics, specifically for mul2-label (ECG) classifica2on. An incorrect ML model evalua2on can harm the pa2ent and poses a risk which is analyzed in further detail from a medical perspec2ve for the design of our emergency seYng adjusted label structure and benefit matrix. The proposed method for QG 7 Interna:onal Standards Organiza:on, ISO/IEC FDIS 5338:2023(E) on AI system lifecycle processes, 2023. 8 Different deployed versions are described as a next evolu:on of the intelligent system, comparable with an update for a specific sobware, for instance. 4 Performance Evalua+on Metrics crea2on will be explained in the next sec2on in more detail. It consists of the three stages pre-, intra-, and post-selec2on and is referenced as part of the proposed folder structure. Finally, lifecycle inherent interdependencies between QGs are intended to be included, as illustrated in an exemplary manner for QG Performance Evalua+on Metrics (QG Metrics) regarding QG Data as well as QG Deployment and QG Maintenance. The presented setup is not complete but rather illustrates the overall idea how to realize QGs and their documentation along the AI lifecycle flow for a specific use case. For instance, interdependencies with other QG Model Development specific design decisions are not highlighted explicitly and methods for their integration are beyond the scope of the present research. 4. Low-level QG creaEon – pre-, intra-, and post-SelecEon (Template versions) In general, empirical method development is an essential component of QG creation as part of our proposed methodology, aiming to extract standardizable approaches. Especially so, since currently certifiable AI is in its infancy and the concrete realization of design decisions depends heavily on the respective use case. Once more standardized methods for concrete design decisions are established for (groups of) use cases, method creation becomes more organized, and depending on the project and process stage, a fitting method can be selected from the pool of identified approaches. Our generalizable method towards AI design decision making can be generalized as follows: The derived approach structured into dynamic pre-, intra-, and post-selec2on stages is intended to be adapted to other QG Model related design decisions such as QG Loss Func2on or QG Model Architecture. Its applicability to other low-level QGs that are assigned to different high-level QGs needs to be evaluated in further detail. 5 Pre-Selec)on builds on previous findings, and possibly other as relevant iden2fied QGs. It aims to implement the first setup (or select different candidate approaches to be tested in parallel) for the respec2ve design decision as a baseline for further internal op2miza2on throughout the lifecycle. Above all, this includes a profound understanding of the respec2ve use case, which is crucial for a reliable concre2za2on of design decisions. This informa2on is provided by the high-level QG Data and QG Model and relevant for mul2ple low-level QGs along the lifecycle. Regarding QG Metrics, informa2on on the use case, stakeholder and medical domain are relevant not only for metrics selec2on and interpreta2on, but for data and thus model overall quality assessment, as well. Consequently, as relevant iden2fied informa2on is shared across QGs. Context-embedding includes medical evalua2ons, such as clinical informa2on on label correla2ons, as well as considera2ons regarding imbalanced data sets, and other use case specific challenges and possible solu2ons from a technical and clinical perspec2ve. From a management perspec2ve, it is desirable to consider preselec2on steps before the debut of the implementa2on. Intra-Selec)on aims to reassess previous design decisions and evaluate the chosen methods for suitability under considera2on of the iden2fied domain knowledge and based on concrete results of the first prototype. For QG Metrics, this includes the comparison of the metrics’ performance against addi2onal material such as predic2on vs. true label distribu2on, for instance to gain a more comprehensive understanding of the selected metrics' performance. For the mul2-label case, class probabili2es offer important insights and should be considered from the start of designing the implementa2on. Possibly, with advancing research, different approaches than the previously selected baseline can appear reasonable and should be documented and analyzed further. Also, the defini2on of a bench-marking strategy, as well as long-term usability and stakeholder assessment should already be considered during this phase, in alignment with the most promising solu2on for the respec2ve design decision. Post-Selec)on is meant to op2mize the selected approach and func2ons as a founda2on for monitoring of the previous design decisions under considera2on of stakeholder view-adapted representa2ons of relevant informa2on. In our case, we analyzed the metric-to-monitor in more detail and tuned the classifica2on thresholds. The empirically extracted and generalizable approach for design decision defini2on is characterized by inherent dynamics that are necessary for AI quality management. All stages are intended to result in documenta2on that builds the founda2on for the next cycle, while especially intraand post-selec2on are to be considered alternately un2l a sa2sfying performance and setup for audi2ng is achieved. Also, with respect to a long-term monitoring strategy, a crucial part of QG crea2on. Use case-specific informa2on from pre-selec2on is expected to be less fluctuate, since it is based on the intended use of the system. Changes of which, result in a re-assessment from an official audit point of view according to the MDR.9 Our experiments partly concre2ze the process based on our previously introduced research ques2ons towards reliable performance metrics for mul2-label (ECG) classifica2on and can be refined further. For instance, through the inclusion of fairness metrics as described by ISO on Bias in AI Systems and AI aided decision making as part of QG Metrics. Our empirically extracted method for mul2-label (ECG) classifica2on is illustrated in accordance with our proposed decision process and summarized on the following page. 9 Prinz, et al, Market access of con:nuous learning AI systems in medicine, p.7, VDE DGBMT, 2023 6 a. Data (Inter-dependency: Founda)on) – Focus: Label State 1. Label distribu2on 2. Label structure 3. Label transforma2on 4. … b. Pre-Selec)on (Design Decision: Baseline) – Focus: Performance Metrics 1. Domain Embedding: use case analysis; disease prevalence; benefit matrix 2. Metrics analysis: mul2-label; confusion-matrix; ROC/PR AUC 3. … c. Intra-Selec)on (Design Decision: Reassessment) – Focus: Performance Metrics 1. Addi2onal material 2. Class probabili2es 3. Domain knowledge: … 4. … d. Post-Selec)on (Design Decision: Op)miza)on) – Focus: Performance Metrics 1. Metric-to-monitor 2. Threshold op2miza2on 3. … e. Deployment, Maintenance (Inter-dependency: Outlook) – Stakeholder Views b-d illustrate the generalizable method for design decision-making: pre-, intra-, and post-selec2on steps consis2ng of research ques2on related design decisions, as well as use case adapted considera2ons. Within the context of the presented folder structure, our results are in “QG_Process_Structure/1_QG Model/1_Evolu2on/2_QG Model Training/3_QG Metrics”. Higher level QGs, as a and e are referenced in the context of lower level QGs with respect to design decision-specific interdependencies that influence b-d. Regarding QG Data, the label state is iden2fied as adjustable for our experiments. Other necessary informa2on on the data set is extracted from literature on Physionet, the u2lized open-source ML data set. Regarding the lifecycle embedding of QG Metrics, performance metrics are consulted during mul2ple stages and referenced from several other QGs on the lower levels, which needs to be iden2fied for referencing. For instance, performance metrics are a crucial part of hyper-parameter tuning and system monitoring which makes them a central element of the AI lifecycle flow. Intraand post-selec2on are strongly correlated and should be reassessed and adapted accordingly during different cycles of the intelligent system’s evolu2on while in alignment with pre-selec2on results. Finally, guiding ques2ons are a fundamental part of QG realiza2on in general and are meant to support a comprehensive assessment in favor of overall risk mi2ga2on. Examples along the process stages include the following and are concre2zed in further detail in the corresponding paper. • What is the intended clinical use and what suitable metrics and methods exist? • How can metrics be interpreted correctly? Which addi2onal informa2on is necessary? As of now, our approach is con2nuously being refined and aims to one day support the implementa2on of reliable AI through comprehensive lifecycle management that allows for generic and prac2cal guidelines while considering use case and stakeholder specific requirements.