Integrating an AI Platform into Clinical IT: BPMN Processes for Clinical AI Model Development

Integrating an AI Platform into Clinical IT: BPMN Processes for Clinical AI Model Development | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Research Article Integrating an AI Platform into Clinical IT: BPMN Processes for Clinical AI Model Development Kfeel Arshad, Saman Ardalan, Björn Schreiweis, Björn Bergh This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-4004492/v1 This work is licensed under a CC BY 4.0 License Status: Published Journal Publication published 02 Jul, 2025 Read the published version in BMC Medical Informatics and Decision Making → Version 1 posted 10 You are reading this latest preprint version Abstract Background: There has been a resurgence of Artificial Intelligence (AI) on a global scale in recent times, resulting in the development of cutting-edge AI solutions within hospitals. However, this has also led to the creation of isolated AI solutions that are not integrated into clinical IT. To tackle this issue, a clinical Artificial Intelligence (AI) platform that handles the entire development cycle of clinical AI models and is integrated into clinical IT is required. This research investigates the integration of a clinical AI platform into the clinical IT infrastructure. This is demonstrated by outlining the stages of the AI model development cycle within the clinical IT infrastructure, illustrating the interaction between different IT system landscapes within the hospital with BPMN diagrams. Methods: Initially, a thorough analysis of the requirements is conducted to refine the necessary aspects of the clinical AI platform with consideration of the individual aspects of clinical IT. Subsequently, processes representing the entire development cycle of an AI model are identified. To facilitate the architecture of the AI platform, BPMN diagrams of all the identified processes are created. Clinical use cases are used to evaluate the processes using the FEDS framework. Results: Our BPMN process diagrams cover the entire development cycle of a clinical AI model within the clinical IT. The processes involved are Data Selection, Data Annotation, On-site Training/Testing, and Inference, with distinctions between (Semi-Automated) Batch Inference and Real-Time Inference. Three clinical use cases were assessed to evaluate the processes and demonstrate that this approach covers a wide range of clinical AI use cases. Conclusions: The evaluations were executed successfully, which indicate the comprehensive nature of our approach. The results have shown that different clinical AI use cases are covered by the BPMN diagrams. Our clinical AI platform is ideally suited for the local development of AI models within clinical IT. This approach provides a basis for further developments, e.g. enabling the training and deployment of an AI model across multiple sites or the integration of security- and privacy-related aspects. artificial intelligence machine learning AI platform healthcare BPMN process diagrams clinical IT Medical Data Integration Center Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Background In the past several years, we saw a reemergence of Artificial Intelligence (AI) around the world [ 1 , 2 ]. With the rise of AI, AI algorithms are used more frequently in many domains [ 3 , 4 ]. There is also a considerable development of AI-based systems in healthcare settings [ 5 , 6 ]. In several medical domains, such as radiology [ 7 ], cardiology [ 8 ], dermatology [ 9 ] or pathology [ 10 ], we already see progress in clinical decision support using AI systems in recent years. Despite extensive progress in the development of AI systems in many medical domains [ 11 ], translation into clinical routine is still in its early stages and holds many challenges [ 12 ]. One major challenge is, that in many clinical settings there are only isolated AI solutions which are not fully integrated into the existing clinical IT [ 13 ] or data need to be distributed across multiple IT systems to enable AI support in several domains. Initial approaches for integrating a clinical AI platform into the clinical IT were already highlighted, although they are intended for specific medical use cases or individual data types such as alphanumeric data [ 14 ] or imaging data [ 15 , 16 ]. A more comprehensive clinical AI platform solution that covers the entire spectrum of clinical IT landscapes is currently not available. One factor hampering this is the clinical source systems’ focus on documentation, billing and archiving clinical data [ 17 ]. Overcoming this important barrier, is the aim of approaches like medical data warehousing, clinical data repositories and knowledge management platforms. As part of the German Medical Informatics Initiative 1 , all German University Hospitals are currently rolling out so called (medical) data integration centers (MeDICs/DIZ) [ 18 , 19 ]. The main idea of these MeDICs is to integrate clinical routine data from the respective University Hospital’s electronic medical record (EMR) system, cleanse, harmonize and make them discoverable and useable for research purposes in particular, for secondary use in general. MeDICs are not only setting up IT infrastructures, but also an organizational structure including processes on how to request, access and use these data [ 18 , 19 ]. Due to the MeDICs, real world data are readily available and the secondary use of data is possible. Requested data from a MeDIC cannot only be used for retrospective biomedical research, but also for other purposes like training AI models and subsequently use them for inference. To enable broad clinical application of AI, it is necessary that a clinical AI platform is also integrated into the existing clinical IT landscapes for clinical decision support. Objectives To ensure the successful integration of a clinical AI platform, it is necessary to map out the processes involved in the development and application of clinical AI models. Therefore, it is important to define target processes that are relevant from the perspective of stakeholders in the clinical domain. The objective of this study is to describe these processes using Business Process Model and Notation (BPMN) diagrams, thus laying the foundation for developing the architecture of a clinical AI platform. [1] funded by the German Federal Ministry of Education and Research Methods In the following, we describe our setting, the requirements analysis methods, use case agnostic processes and the development process of the BMPN diagrams. Setting We performed our project at the University Hospital Schleswig-Holstein (UKSH), which is the second-largest hospital in Germany, the only university hospital and maximum care provider in the state of Schleswig-Holstein (northern Germany). Two IT system landscapes can be distinguished within UKSH. First, there are the primary systems, which are used to store all patient treatment-related data, for example the electronic medical record (EMR) system and the picture archiving and communication system (PACS). The EMR system contains all the medical documentation about patients treated within a healthcare organization [ 20 ]. A hospital, general practitioner, doctors’ offices, rehabilitation organizations or care organization is considered a healthcare organization. A PACS system is used to acquire, transmit, display and archive medical imaging data [ 21 ]. The second IT system landscape consists of the research IT systems. They include all kinds of research databases and registries, e.g. excel sheets, access databases. Furthermore, electronic data capture (EDC) systems for structured research documentation are part of the research IT landscape. Additionally, biomaterial information systems to manage biomaterial and their information exist. The UKSH MeDIC integrates the IT of patient treatment and research. Data from the EMR and subsystems like PACS, laboratory information system, but also research databases, study documentation and biomaterial information are integrated, harmonized and annotated within the MeDIC platform. Additional systems include a Master Patient Index to manage demographics data and a consent management system to process and enforce patient consents [ 18 , 19 ]. The KI-SIGS project aims at building an AI space for intelligent health systems, which consists of three components: (1) development of four platform projects (a-d) dealing with (a) collaboration, (b) technical aspects, (c) regulatory aspects and (d) responsible innovation, (2) development of nine clinical use cases and (3) improving the healthcare ecosystem in northern Germany [ 22 ]. This project is a collaboration of universities, university hospitals and companies in northern Germany. One of the four platform projects in KI-SIGS is the “Technical AI Platform” (b) which designs a clinical AI platform that can obtain and process data to train and subsequently deploy AI models. Additionally, the Clinical AI platform integrates into the existing IT system landscapes of UKSH. Furthermore, there are nine clinical use cases which are referred to as application and innovation (A&I) projects. Each of the A&I projects is working on applying state-of-the-art machine learning (ML) methods on a specific clinical use case. These use cases employ a broad variety of areas where ML can be utilized from analysis of patients’ alphanumerical data produced by medical devices at the ICU [ 23 ] to medical image analysis [ 24 ]. The output of the AI platform project includes the requirements analysis for identifying and documenting the needs as well as objectives for developing a clinical AI platform. The requirements analysis serves as the foundation for the subsequent steps of development. Subsequently, a system architecture of the AI platform is to be designed that maps the development cycle of an AI model derived from the BPMN diagrams. The architecture design ensures scalability, efficiency, and maintainability. Conclusively, a proof of concept will be developed based on the system architecture of the clinical AI platform, which specifies the main functionalities of the AI platform. This involves creating a functional prototype to validate its feasibility and demonstrate its core functionalities. The proof-of-concept provides valuable insights for further refinement and development of a productive clinical AI platform. Requirements Analysis Prior to the creation of the BPMN diagrams, we conducted a requirements analysis, which forms the basis of the BPMN processes. For our proposed AI platform, we extracted functional and non-functional requirements from different stakeholders in an iterative manner to reassure their consistency, completeness, and correctness. First, we conducted semi-structured interviews [ 25 ] by asking all stakeholders about functional and non-functional requirements. Accordingly, the focus was on the discovery of requirements relevant to the AI platform. Two stakeholder groups were identified that cover the entirety of the AI platform requirements. The first stakeholder group consists of computer scientists. In this case, both the computer scientists working in the AI platform project and the computer scientists working on the application (A&I) projects in KI-SIGS were interviewed. There were 7 computer scientists working on the AI platform and 28 computer scientists working on the application projects. Thus, a total of 35 stakeholders working in clinical computer science were interviewed. The second stakeholder group consists of clinical physicians. Within the AI platform, one clinical physician was interviewed. Within the A&I projects, a total of 7 clinical physicians were interviewed. Accordingly, a total of 8 clinical physicians were interviewed. Starting with the semi-structured interview, we performed the conventional steps for a requirements analysis [ 26 ]. First, the requirements were identified and gathered. We consequently extracted the main demands for an AI platform and current limitations. The requirements were initially gathered in a Mindmap for the collection process. Then the requirements were reviewed and categorized by the stakeholders, who are working on the AI platform. The review of the requirements mainly included targeting and plausibility checks. Subsequently, the requirements were further categorized within functional and non-functional requirements. The entire outlined process was performed in three iterations with all stakeholders involved in the development of the AI platform. Then the requirements were documented and are now managed in a cloud to which all project participants have access. The development and deployment of clinical AI models can be represented by consecutive processes [ 27 , 28 ]. Based on the processes outlined by Lu et al. [ 28 ], we have identified four overarching use case agnostic processes that cover the complete workflow for the development and deployment of clinical AI models. The main functional requirements that represent the necessary boundary conditions for our process flows are outlined in Table 1 . These requirements can be derived from the functional requirements for medical data integration into knowledge management environments [ 29 ]: Table 1 Main functional requirements for development of the use case agnostic processes. 1. Infrastructural conditions are provided such that the AI platform can run on-premises and thus no data leave the site. 2. The AI models should be stored together with associated descriptive information in the AI platform or in the knowledge management platform. 3. The AI platform should be able to store the data temporarily. 4. The AI platform should be linked to the medical data integration center and hospital information system. 5. The AI platform serves as a data mart and should process a subset of the data from the medical data integration center. 6. The AI platform should support alphanumeric and multimedia data. 7. The AI platform should be able to process anonymized, pseudonymized and non-pseudonymized data. 8. The AI platform should be designed to be able to be connected to other data platforms. 9. The AI platform should support all identified use case agnostic processes. FEDS-Framework We evaluated the BPMN diagrams using the Framework for Evaluation in Design Research (FEDS) framework [ 30 ]. The FEDS framework was developed to provide a strategy for the evaluation of Design Research Science (DSR) projects. DSR can be defined as: “a problem-solving paradigm that seeks to enhance human knowledge via the creation of innovative artifacts“ [ 31 ]. FEDS contains a two-dimensional characterization for the evaluation of DSR projects. One dimension includes the functional purpose of the evaluation, whether it is formative or summative. The second dimension identifies the paradigm of the evaluation, whether it is artificial or naturalistic. The FEDS evaluation consists of four steps: Stating the objectives of the evaluation, selecting the evaluation strategy, identifying the attributes to be evaluated and designing the evaluation episodes. First, the objective of the evaluation is determined. The goal for our evaluation is to minimize the technical uncertainties and risks in the future integration and development of the clinical AI platform. We then select the strategy for the evaluation based on the goal. Since we want to determine whether the technical aspects work as intended in our BPMN diagrams and it is a highly technically oriented design, we apply the Technical Risk & Efficacy strategy. We then check which attributes should be evaluated. Here, we choose the accuracy of the process representation as the main attribute. Accordingly, the evaluation should show the completeness of the development process of an AI model in our BPMN diagrams. Subsequently, we define three evaluation episodes to demonstrate the completeness of the BPMN diagrams. In the following, we introduce these evaluation episodes in the form of three use cases that represent a broad range of AI applications in the clinical domain. Use Cases We selected three clinical use cases for the evaluation of the BPMN diagrams. The first use case for our evaluation is from the KI-SIGS project and is referred to as “digital x-ray assistant”. This use case is about assessing the quality of upper ankle radiographs. In this use case radiographs of the upper ankle joint are rated from 1 to 3 by radiologists. 1 stands for excellent image quality, 2 stands for acceptable image quality, while 3 stands for non-acceptable image quality. The aim of this use case is to train an AI model that can perform this assessment. In this case, it is the training of a Convolutional Neural Network (CNN) [ 32 , 33 ]. The second use case for evaluation is the distinction between benign and malignant tumor in breast carcinoma. The Wisconsin Breast Cancer data set [ 34 ] can be used for this purpose. The data set consists of structured pathology reports (alphanumeric data) describing the cell nucleus from digitized images of a breast cancer. For example, the mean value of the distances from the center to the points on the perimeter is calculated and recorded as a numerical value. There are 10 features in total. In addition, for each data set, it is indicated whether the breast cancer is benign or malignant. Accordingly, the data are already annotated and do not require further annotation. The goal is to train an AI model that can predict whether it is a benign or malignant breast cancer using new input data. In this case, the AI algorithm is a decision tree model with non-correlated features as input parameters [ 35 ], which should distinguish whether the input data are indicative of a malignant or benign tumor. Therefore, the output can either represent benign or malign. The third use case for evaluation is also from the KI-SIGS project and is referred to as “Risk indicators for cardiopulmonary decompensation in intensive care units by monitoring vital signs” [ 23 ]. The risk assessment is achieved through a scoring system designed to rank and predict pulmonary and hemodynamic decompensation based on vital parameters. A Gated Recurrent Unit (GRU) network is used for the training. The vital parameters, such as heart rate or oxygen saturation, are used as input parameters. A complete list of the input parameters can be found in [ 23 ]. Results The BPMN diagrams include the processes of Data Selection, Data Annotation, On-Site Training/Testing and Inference, whereas for Inference a case distinction was made between (Semi-Automated) Batch Inference and Real-Time Inference. In the context of BPMN, we define three sub-pools within UKSH: EMR, MeDIC and the Clinical AI Platform. The MeDIC includes two lanes: Repository , which holds the entire medical data within MeDIC and Mart . A mart is a specific cohort data set. The Clinical AI Platform includes two lanes: Front-End and Application . The Application lane includes technical subcomponents such as a Data Broker , which acts as an API between the Clinical AI Platform and the other IT system landscapes; an AI Processing Unit , which is responsible for compiling the data cohort, performing data annotation and training, and orchestrating the associated processes; a Model Repository , which contains the trained models; and a Repository for Temporary Data , which serves as temporary data persistence for the cohort data. Data Selection The first process is Data Selection. This process focuses on selecting a suitable cohort and its corresponding data set for a specific AI use case, e.g. laboratory data or imaging data from radiology. In this case, it is important to note that we assume that the data cohort is already approved for use by the Use & Access Committee and then prepared by the MeDIC’s data transfer unit. The user can subsequently select an already pseudonymized cohort data set in the Front-End , which is made available as a mart in the MeDIC. The request is forwarded to the MeDIC via the Data Broker . During this process, both alphanumeric data and multimedia data can be made available from the MeDIC Repository in the MeDIC Mart . Then, the data are stored in the Repository for Temporary Data via the Data Broker . The user evaluates and verifies the pseudonymized data. Afterwards, the cohort data set is defined by selecting adequate data from the provided mart that meets the requirements of the specific AI use case. In the next step, the information about the defined cohort data set is forwarded by the Data Broker to the MeDIC Mart and the Repository for Temporary Data , while the initial cohort data set is deleted. In the Front-End , the user is shown that the storage of the defined cohort data set was successful and in addition, the user is asked whether the process should be continued. In the case of continuation, the user can either continue with the Data Annotation process or, if no annotation is required, continue with the On-site Training/Test process. Otherwise, the data are deleted from the Repository for Temporary Data. The BPMN diagram for Data Selection is illustrated in Fig. 1 . Data Annotation The second process describes the Data Annotation. The BPMN diagram for Data Annotation is illustrated in Fig. 2 . We assume, that the cohort data set is not available in the Repository for Temporary Data . The user sends a request from the Front-End for a specific, already reviewed and defined cohort data set to be annotated. The Data Broker forwards the request to the MeDIC Mart , which returns the pseudonymized medical data (PSN and MDAT). The retrieved cohort data are passed through the Data Broker to the Repository for Temporary Data . Once the cohort data are in the repository, they can be annotated by domain experts. When the annotation process is complete, the annotation information for the specific cohort data set is passed to MeDIC via the Data Broker and archived in the Mart . Once it is confirmed that the annotation process is completed, a decision is made by the User in the Front-End as to whether the cohort data can be further used in a timely manner or whether it can be deleted from the Repository for Temporary Data . If the process is to be continued in the near future, the next process would be On-Site Training and Testing. In such a case, the cohort data would remain in the Repository for Temporary Data . On-site Training and Testing The third process is On-site Training and Testing. Figure 3 illustrates the BPMN diagram for On-Site Training and Testing. We assume, that the cohort data set is not available in the Repository for Temporary Data. The user of the Front-End starts the process by retrieving the (annotated) cohort data set from the Mart via the Data Broker . The cohort data set is then reviewed by the user, whether any further annotation is required. If further annotation is required, the annotation process is run again. If no further annotation is required, the Data Broker transfers the (annotated) cohort data set to the Repository for Temporary Data . Then the training of the AI model is initialized and performed in the AI Processing Unit . Note that a seed must be initialized for traceability of the training process. After each training session, the AI model is created or updated. The AI model is then tested and tracked. Once the AI model has been tested, it is checked to see whether the results obtained are satisfactory from a technical point of view. If this is not the case, the hyperparameters are adjusted and the training loop is run again. In the course of training, the AI model is temporarily stored in the Model Repository . After completion of the technical evaluation, a medical evaluation is performed. This medical evaluation includes, firstly, the clinician's/user's view of medical usability and relevance, and secondly, the regulatory evaluation, such as the Medical Device Regulation (MDR) [ 36 ]. If the result of medical evaluation is negative, the training can be continued with adjusted parameters or the training can be stopped. If the medical evaluation is positive, the final AI model is either stored permanently in the Model Repository or, if other storage options exist (e.g. in the MeDIC), the AI model is stored elsewhere. This depends on the individual IT system design. Once the storage process of the AI model is completed, the data are deleted from the Repository for Temporary Data . Then a technical, medical and data definition documentation is created and stored in the Mart and Repository of the MeDIC. Inference The fourth process is inference. The inference process is responsible for assessments based on incoming data. In this context, we distinguish between (Semi-Automated) Batch Inference and Real-Time Inference. (Semi-Automated) Batch Inference The BPMN diagram for (Semi-Automated) Batch Inference is illustrated in Fig. 4 . In this case, we are dealing with the treatment setting, which means that clinicians want to calculate a prediction for a batch. If the AI model to be used is already known, this process can be referred to as Semi Automated Batch Inference. The purpose of (Semi-Automated) Batch Inference is that data can be processed individually per data subset, i.e. patient. For this purpose, the user accesses the Front-End via a connected EMR System. After the available models were queried from the Model Repository , the user can select a suitable AI model, if the AI model to be used is not yet known. The corresponding batch is then transferred from the EMR System to the Repository for Temporary Data of the Clinical AI Platform via the Data Broker , once preprocessing and a check of the data were successful. The selected model is loaded from the Model Repository into the AI Processing Unit . After the inference is performed successfully, the results are finalized for storage and visualization. The Data Broker transfers the results to the MeDIC Mart . Additionally, the results are transferred to the EMR. Finally, the results of the prediction are visualized in the EMR System. However, it is important to consider that the (Semi-Automated) Batch Inference can also be performed in a research setting. This scenario is shown in Fig. 5 . In this case, researchers want to calculate a prediction for a batch. The difference to the treatment setting is that the researcher starts the inference within the Clinical AI Platform. In addition, the data are provided from the MeDIC Mart and not from the EMR. In this case, the results are stored in the Mart and depending on whether permanent storage is intended, also in the Repository . The visualization takes place in the Clinical AI Platform’s Front-End . Real-Time Inference For the Real-Time Inference, it is also clear from the setting which model will be used. In this case, we assumed that only the treatment setting is relevant for the Real-Time Inference. A practical example is streaming data from the monitoring in the intensive care unit. Here, it is necessary to make real-time predictions from incoming streaming data. Apart from this, the process of providing the data and storing the results is similar to the inferences in the Figs. 4 and 5 . The BPMN diagram for Real-Time Inference is illustrated in Fig. 6 . Evaluation The first use case for evaluation is the “digital x-ray assistant” from the KI-SIGS project. Initially, we start with the Data Selection process. We assume that the radiographs are provided via a MeDIC Mart . Accordingly, the cohort can be accessed by an authorized clinician via the Front-End of the Clinical AI Platform. The cohort is stored in the Repository for Temporary Data . The clinician can then evaluate, review and subsequently define and configure the cohort in the Front-End of the Clinical AI Platform. This includes checking that the existing images are usable. The configured cohort is forwarded to the Repository for Temporary Data via the Data Broker and stored there, while the initial cohort is deleted. The information about the configured cohort is also stored in the MeDIC Mart . We assume that the process will not be continued in a timely manner in this case, so that the cohort with the images will be deleted from the Repository for Temporary Data . Subsequently, the Data Selection process ends. The next step is the Data Annotation process. Here, the user can query the already configured cohort via the Front-End of the Clinical AI Platform. The cohort is then loaded from the MeDIC Mart into the Repository for Temporary Data via the Data Broker . The cohort can afterwards be annotated using a linked data annotation tool. After the annotation is completed, the annotation information will be stored in the Repository for Temporary Data and also in the MeDIC Mart via the Data Broker . Since we assume in this case that there is a longer time delay after the annotation process, the annotation information is deleted from the Repository for Temporary Data . Then the On-Site Training/Testing process starts. Once again, the user can retrieve the cohort including the annotation from the MeDIC Mart in the Front-End of the Clinical AI Platform via the Data Broker . The user can check whether the cohort was already completely annotated or whether further annotation is necessary. Assuming that the annotation was already completed, the cohort is stored in the Repository for Temporary Data . Afterwards, the training can be initialized in the AI Processing Unit . A seed is defined, which is necessary for reproducibility. After the training is complete, an AI model is created, tested and then stored in the Model Repository . The AI model can then be checked with the help of various metrics. If, from a technical point of view, the results are not yet satisfactory or if further configurations to the CNN need to be evaluated, the training is started again. After the training is completed, the AI models can be compared to each other. If the technical evaluation of the AI model is successful, a medical evaluation can be performed to check the medical plausibility of the AI model. If this is successfully completed, the final AI model can be stored in the Model Repository . The temporarily stored data of the cohort in the Repository for Temporary Data are then deleted. Furthermore, the AI Processing Unit produces the technical, medical and data definition documentation. This documentation is stored in the MeDIC Mart and, if required, also in the MeDIC Repository for permanent storage. The On-site Training/Testing process is then completed. In the following, the inference takes place in a treatment setting. Batch inference is used here, i.e. the clinician has a batch of radiographs on which a quality assessment of the upper ankle joint is to be performed. For this, the clinician can make a request for the available AI models via the Front-End of the Clinical AI Platform. The matching AI models are then forwarded from the Model Repository to the Front-End of the Clinical AI Platform. The clinician can select the appropriate model and simultaneously transfer his batch from the EMR to the Clinical AI Platform. The AI Processing Unit then performs the inference. The process is recorded and the results are stored and displayed in the EMR. For permanent storage, results can also be stored in the MeDIC Repository . The second use case for the evaluation is the differentiation of benign from malignant tumors in breast cancer. We evaluate whether our BPMN diagrams are effective for Data Selection, On-Site Training/Testing and Semi-Automated Batch Inference within the research setting. In this case, we assume once again that the user is authorized by the responsible Use & Access Committee to receive the cohort data set with the Wisconsin Breast Cancer data set. Accordingly, the User sends a request from the Front-End through the Data Broker to retrieve the pseudonymized cohort data set, which is already made available via a MeDIC Mart . Subsequently, the cohort data set is stored in the Repository for Temporary Data . Once the cohort data set is available in the Clinical AI Platform, the user can evaluate, review and define the cohort in the Front-End . Afterwards, the information about the reviewed cohort data set is stored both in the Repository for Temporary Data and in the MeDIC Mart . In this case, the process is continued right away, so the data cohort can remain in the Repository for Temporary Data for now. As the data are already annotated, we continue with the On-Site Training/Testing process. We move to the initialization of training, as the cohort data set already exists in the Repository for Temporary Data . A seed is defined, which is necessary for reproducibility. Then the training is performed and tracked. The process of training and testing is performed similarly to the process of the first use case. Once the AI model has passed medical evaluation, the final AI model is stored in the Model Repository. Subsequently, the cohort data of the Wisconsin Breast Cancer data set can be deleted from the Repository for Temporary Data . At the same time, a technical and a medical documentation are generated and then stored in the MeDIC Mart and/or the MeDIC Repository via the Data Broker . In the following, the researchers want to apply inference based on a new cohort that contains parameters describing the cell nucleus from images. In this case, the Semi-Automated Batch Inference in the research setting is applied. The user activates the AI model for the given use case for the classification of benign and malignant breast tumors via the Front-End . The AI model is loaded into the AI Processing Unit . Simultaneously, the cohort data set for the inference will be retrieved from the MeDIC Mart and loaded to the Repository for Temporary Data via the Data Broker . After the decision tree model from the Model Repository and the new cohort from the MeDIC Mart are loaded into the AI Processing Unit , the inference is performed. The results are processed and stored in the MeDIC Mart and, if necessary, in the MeDIC Repository . The results are then visualized in the Front-End of the AI platform. The third use case is “Risk indicators for cardiopulmonary decompensation in intensive care units by monitoring vital signs”. Upon approval by the Use & Access Committee to use the cohort data set and its provision in the MeDIC Mart , the user can request the cohort data set in the Front-End via the Data Broker from the MeDIC Mart . The cohort is then stored in the Repository for Temporary Data . The user can evaluate, review and define the cohort in the Front-End once the cohort data set is available in the Clinical AI Platform. This involves evaluating whether the data are fit for purpose or if it is flawed or incomplete, and thus unusable. Afterwards, the configured cohort is stored via the Data Broker in the Repository for Temporary Data and in the MeDIC Mart . Since the cohort data set requires annotation, we proceed to the annotation process. The user can retrieve the cohort from the Repository for Temporary Data in the Front-End and annotate the data. The annotation consists of calculating Decompensation Scores (DEC scores), which provide information on the timing of the relevant occurrences. A distinction is made between no decompensation, beginning-moderate decompensation and severe decompensation. These classes should be predicted up to 24 hours before occurrence. As soon as the annotation is completed, the annotation information is stored in the Repository for Temporary Data and via Data Broker also in the MeDIC Mart . We assume that there is a longer time delay between the data annotation process and the On-site Training/Testing process. Therefore, the cohort is deleted from the Repository for Temporary Data . As soon as the On-site Training/Testing process is started, the user can retrieve the cohort in the Front-End from the MeDIC Mart via Data Broker . The process of training and testing is performed similarly to the process of the other two use cases. The On-site Training/Testing process ends with feedback to the Front-End, if the process has been executed successfully. In this use case, the continuous processing of vital signs is crucial for the early detection of cardiopulmonary decompensation. For this purpose, the EMR system continuously delivers the vital signs to the TKIP via the Data Broker . To ensure correct processing, the incoming data are pre-processed in the AI Processing Unit . This includes the selection of the required parameters with the correct unit. The data are temporarily stored in the Repository for Temporary Data and then the trained AI model is loaded from the Model Repository to the AI Processing Unit . There, the data are loaded from the Repository for Temporary Data and then Real-Time Inference is performed. The results are then processed for presentation, which includes the classification of the DEC score. The Data Broker forwards the results to the EMR and the MeDIC Repository , enabling the results to be displayed in the EMR. Optionally, the results can also be displayed in the Front-End of the Clinical AI Platform. The next data set from the EMR system is then prepared for Real-Time Inference, resulting in the recurrence of the procedure. Discussion Principal Results The aim of this work was to demonstrate the integration of a clinical AI platform into clinical IT, including the entire development cycle for an AI model using BPMN process diagrams. For this purpose, the requirements determined in the sub-project "Technical AI Platform" of KI-SIGS were used as a basis to define the boundary conditions for the development of the BPMN diagrams. The processes of the BPMN diagrams were determined on the basis of literature. The presented BPMN diagrams cover the entire development cycle of an AI model with the differentiated processes of Data Selection, Data Annotation, On-site Training/Testing, Batch Inference, Semi-Automated Batch Inference and Real-Time Inference. The three IT system landscapes at the UKSH are of particular importance for this purpose: EMR, MeDIC and the Clinical AI Platform. We identified two components of MeDIC that are relevant in our development context: Mart and Repository . The Clinical AI Platform consists of a Front-End and an Application part. The Application consists of a Data Broker , which is necessary for communication between the IT system landscapes, an AI Processing Unit , which processes all activities for which dedicated computing capacity is required. The application also includes a Model Repository for the AI models and a Repository for Temporary Data for the temporary storage of cohorts. Other tools can also be integrated into the Clinical AI Platform for data annotation. The BPMN diagram for Data Selection shows how the cohorts provided in the MeDIC Mart can be retrieved and defined by the user in the Clinical AI Platform. The BPMN diagram of Data Annotation demonstrates the process of how the cohort data set can be annotated in the Clinical AI Platform and can then be stored with the cohort itself. The BPMN diagram of On-site Training and Testing displays how an already defined and annotated cohort data set can be loaded and an already defined AI algorithm can be trained with this cohort. We distinguish between three different cases for inference to cover the spectrum of possible clinical use cases: Batch Inference, Semi-Automated Batch Inference and Real-Time Inference. The Batch Inference describes the case of Inference for single or multiple cohort data instances with manual AI model selection. Semi-Automated Batch Inference also describes inference with single or multiple cohort data instances, but with a pre-selected AI model that can automatically be retrieved. Real-Time Inference describes the inference of streaming data that can e.g. be observed in ICU use cases for monitoring patients’ vital parameters. We evaluated these processes with three clinical use cases that verify the completeness of the BPMN diagrams. We selected the FEDS framework for evaluating the BPMN diagrams to ensure a systematic analysis and assessment of our results. The FEDS framework also ensures a consistent and comparable evaluation [ 30 ]. With the aid of three independent clinical use cases, we were able to demonstrate for each individual process, as well as for the overall evaluation objective, that the AI development cycle can be successfully represented with the developed processes, thus minimizing technical uncertainty. Therefore, it can be determined that the processes represent the complete and comprehensive development cycle of an AI model within the clinical IT according to Lu et al [ 28 ]. Limitations Although our BPMN diagrams map a broad spectrum of AI development in a clinical context, there may be use cases that require a more specific process mapping. There may be individual use cases that require more human interaction, thus leading to multiple iterations. Accordingly, the processes and the corresponding BPMN diagrams can be considered as blueprints that are suitable for most clinical use cases. Furthermore, it is important to consider the depth of the process mapping. Many activities within the processes can certainly be displayed in more detail. Accordingly, we have chosen the trade-off in favor of generalizability rather than depth of detail in order to map the range of clinical use cases as accurately as possible. Another aspect is the consideration of security and privacy factors. This would be a useful extension of the BPMN process diagrams. Non-functional aspects such as security or privacy factors were implicitly considered in our elaborations because the priority was to consider and implement the functional aspects to demonstrate the functionalities of the Clinical AI Platform. In general, privacy by design should be ensured for the clinical AI platform. Further development of the BPMN diagrams could also include consideration of paradigms such as federated learning, which includes the aggregation of cohort data sets from multiple sites. In our paper, the training/testing scenario only referred to On-site Training/Testing. Comparison with Prior Work Previous publications have shown which processes exist within the development cycle of an AI model [ 27 , 28 ]. While Amershi et al. [ 27 ] show the development cycle of an AI model in nine small steps, Lu et al. [ 28 ] present a more summarized development cycle in six steps. In our approach, we have summarized the development cycle of Lu et al. [ 28 ] even further and presented the entire development cycle of an AI model in only four overarching steps. Our approach focuses on the technical development cycle and excludes preparatory processes that are usually not specific to the development of AI models. The main advantage of our approach is the comprehensibility of the technical development process while covering generic clinical AI use cases. Amershi et al. focus on AI model development without specific emphasis on any particular domain, while Lu et al. describe the processes they have identified in the clinical domain but rather generally. In contrast to this, we describe the processes that we have identified in detail with the help of BPMN diagrams, which is a novel approach in the field of clinical AI model development. Previous work also shows possible integrations of an AI platform clinical IT [ 14 – 16 ]. However, they are either limited to certain data types or to medical domains. While Gruendner et al. [ 14 ] only present the integration of alphanumeric data with FHIR, Scherer et al. [ 15 ] and Leiner et al. [ 16 ] only focus on imaging data. In our approach, there is no limitation in terms of data types. Our approach addresses the entirety of clinical data types. Besides, Gruendner et al., Scherer et al. and Leiner et al. [ 14 – 16 ] provide no description of the development of relevant AI processes in the hospital, which include the medical data integration centers and the primary systems. With our study, we show how the translation of requirements and the definition of processes into an architecture within clinical IT can be realized. The intermediate step of describing the defined processes can describe the interaction between the clinical IT system landscapes and thus validate the architecture. Conclusions With the BPMN diagrams presented in this paper, we laid the foundation to design the architecture of a clinical AI platform. The architecture and implementation of the AI platform in KI-SIGS will be based on the BPMN diagrams. In addition, the processes and interaction between the three clinical IT landscapes of the EMR, the MeDIC and the Clinical AI platform are shown for the first time. With the help of the use case agnostic processes presented, the entire workflow for creating and applying a clinical AI model can be illustrated. Our BPMN diagrams also provide a basis for similar projects to develop an AI platform. In many cases, clinical AI platforms can be realized that are based on an abstracted version of our BPMN diagrams. Abbreviations A&I Application & Innovation AI Artificial Intelligence API Application Programming Interface BPMN Business Process Model and Notation CNN Convolutional Neural Network DEC scores Decompensation scores DIZ Data Integration Center DSR Design Science Research EDC Electronic Data Capture EMR Electronic Medical Record FEDS Framework for Evaluation in Design Science FHIR Fast Healthcare Interoperability Resource GRU Gated Recurrent Unit ICU Intensive Care Unit IT Information Technology MDAT Medical Data MDR Medical Device Regulation MeDIC Medical Data Integration Center ML Machine Learning PACS Picture Archiving and Communication System PSN Pseudonym UKSH University Hospital Schleswig-Holstein Declarations Ethics approval and consent to participate In accordance with legal data protection requirements, only anonymous data has been used. In this context, based on §2 of the Statutes of the Ethics Committee of the Faculty of Medicine of Kiel University, no consultation of the Ethics Committee is required. Participants provided informed consent before starting the interviews. Consent for publication Not applicable. Availability of data and materials The data used in the current study are not publicly available but are available from the corresponding author upon reasonable request. Competing interests The authors declare that they have no competing interests. Funding This research was supported by Federal Ministry for Economic Affairs and Climate Action under Grant No. 01MK20012U. Authors' contributions KA and SA initiated this research. KA and SA designed the first drafts of BPMN diagrams. KA designed the advanced BPMN diagrams. KA wrote and structured the manuscript. KA evaluated the BPMN diagrams. BS and BB gave their input on the BPMN diagrams and supervised the research. BS and BB gave their input on the content and structure of the manuscript and reviewed the manuscript. Acknowledgements The authors wish to thank the project partners in KI-SIGS for their insightful comments and suggestions during the execution of this research. References Cheung C, Baker S, Maxwell T et al. Rapid expansion - Research on topics related to artificial intelligence and robotics is hitting new heights. Nature 610, S9 (2022). https://doi.org/10.1038/d41586-022-03210-9 . Accessed 23 Jan 2024. Morris KC, Schlenoff C, Srinivasan V. A Remarkable Resurgence of Artificial Intelligence and its Impact on Automation and Autonomy. IEEE Trans Autom Sci Eng. 2017;14(2):407–9. 10.1109/TASE.2016.2640778 . Toosi A, Bottino AG, Saboury B, et al. A Brief History of AI: How to Prevent Another Winter (A Critical Review). PET Clin. 2021;16(4):449–69. 10.1016/j.cpet.2021.07.001 . Schmidhuber J. Annotated History of Modern AI and Deep Learning. https://arxiv.org/pdf/2212.11279.pdf . Accessed 23 Jan 2024. Bohr A, Memarzadeh K. The rise of artificial intelligence in healthcare applications. Artif Intell Healthc. 2020;25–60. 10.1016/B978-0-12-818438-7.00002-2 . Kaul V, Enslin S, Gross SA. History of artificial intelligence in medicine. Gastrointest Endosc. 2020;92(4):807–12. 10.1016/j.gie.2020.06.040 . Waymel Q, Badr S, Demondion X, et al. Impact of the rise of artificial intelligence in radiology: What do radiologists think? Diagn Interv Imaging. 2019;100(6):327–36. 10.1016/j.diii.2019.03.015 . Koulaouzidis G, Jadczyk T, Iakovidis DK, et al. Artificial Intelligence in Cardiology-A Narrative Review of Current Status. J Clin Med. 2022;11(13):3910. 10.3390/jcm11133910 . Omiye JA, Gui H, Daneshjou R, et al. Principles, applications, and future of artificial intelligence in dermatology. Front Med. 2023;10. 10.3389/fmed.2023.1278232 . Cui M, Zhang DY. Artificial intelligence and computational pathology. Lab Invest. 2021;101(4):412–22. 10.1038/s41374-020-00514-0 . Busnatu Ș, Niculescu AG, Bolocan A, et al. Clinical Applications of Artificial Intelligence-An Updated Overview. J Clin Med. 2022;11(8):2265. 10.3390/jcm11082265 . Klumpp M, Hintze M, Immonen M, et al. Artificial Intelligence for Hospital Health Care: Application Cases and Answers to Challenges in European Hospitals. Healthc (Basel). 2021;9(8):961. 10.3390/healthcare9080961 . Davenport T, Kalakota R. The potential for artificial intelligence in healthcare. Future Healthc J. 2019;6(2):94–8. 10.7861/futurehosp.6-2-94 . Gruendner J, Schwachhofer T, Sippl P et al. KETOS: Clinical decision support and machine learning as a service - A training and deployment platform based on Docker, OMOP-CDM, and FHIR Web Services [published correction appears in PLoS One. 2019;14(11):e0225442]. PLoS One. 2019;14(10):e0223010. 10.1371/journal.pone.0223010 . Scherer J, Nolden M, Kleesiek J, et al. Joint Imaging Platform for Federated Clinical Data Analytics. JCO Clin Cancer Inf. 2020;4:1027–38. 10.1200/CCI.20.00045 . Leiner T, Bennink E, Mol CP, et al. Bringing AI to the clinic: blueprint for a vendor-neutral AI deployment infrastructure. Insights Imaging. 2021;12(1):11. 10.1186/s13244-020-00931-1 . Evans RS. Electronic Health Records: Then, Now, and in the Future. Yearb Med Inform. 2016;25(01):S48–61. 10.15265/IYS-2016-s006 . Schreiweis B, Ammon D, Sedlmayr M et al. the data integration centre - a hub for health data a hub for health data from patient care and from patient care and medical research medical research. gesundheit.de. 13th issue. Berlin; 2021. p. 84–87. Haarbrandt B, Schreiweis B, Rey S, et al. HiGHmed - An Open Platform Approach to Enhance Care and Research across Institutional Boundaries. Methods Inf Med. 2018;57(01):e66–81. 10.3414/ME18-02-0002 . HealthIT.gov. What are the differences between electronic medical records, electronic health records, and personal health records? | HealthIT.gov [Internet]. Healthit.gov. 2019. Available from: https://www.healthit.gov/faq/what-are-differences-between-electronic-medical-records-electronic-health-records-and-personal . Accessed 24 Feb 2024. Arenson RL, Andriole KP, Avrin DE, Gould RG. Computers in imaging and health care: now and in the future. J Digit Imaging. 2000;13(4):146. 10.1007/BF03168389 . Fischer S, Leucker M, Lüth C, et al. KI-SIGS: Artificial Intelligence for the Northern German Health Ecosystem. Digitale Welt. 2020;4(1):49–54. 10.1007/s42354-019-0232-5 . Mandel C, Stich K, Autexier S, et al. Using Gated Recurrent Unit Networks for the Prediction of Hemodynamic and Pulmonary Decompensation. Annu Int Conf IEEE Eng Med Biol Soc. 2022;2022:4584–89. 10.1109/EMBC48229.2022.9871500 . Santarossa M, Tatli A, von der Burchard C, et al. Chronological Registration of OCT and Autofluorescence Findings in CSCR: Two Distinct Patterns in Disease Course. Diagnostics. 2022;12(8):1780. https://doi.org/10.3390/diagnostics12081780 . Oates BJ, London. SAGE; 2006. 186–88. Rupp C, SOPHISTen D. Requirements–Engineering and –Management. 6th edition. Munich:Carl Hanser Verlag, 2014. p. 14. Amershi S, Begel A, Bird C et al. Software Engineering for Machine Learning: A Case Study. 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). p. 291–300. 10.1109/ICSE-SEIP.2019.00042 . Lu C, Strout J, Gauriau R et al. An Overview and Case Study of the Clinical AI Model Development Life Cycle for Healthcare Systems. ArXiv, abs/2003.07678. Kinast B, Ulrich H, Bergh B, et al. Functional Requirements for Medical Data Integration into Knowledge Management Environments: Requirements Elicitation Approach Based on Systematic Literature Analysis. J Med Internet Res. 2023;25:e41344. 10.2196/41344 . Venable J, Pries-Heje J, Baskerville R. FEDS: a Framework for Evaluation in Design Science Research. Eur J Inform Syst. 2016;25(1):77–89. https://doi.org/10.1057/ejis.2014.36 . vom Brocke J, Hevner A, Maedche A. Introduction to Design Science Research. Progress in IS. Published online 2020:1–13. https://doi.org/10.1007/978-3-030-46781-4_1 . Gerdes H, Mairhöfer D, Laufer M, et al. Automated quality assessment of radiographs of the upper ankle joint using artificial intelligence. RöFo Published online August. 2022;1. https://doi.org/10.1055/s-0042-1749773 . Mairhöfer D, Laufer M, Simon PM et al. An AI-based Framework for Diagnostic Quality Assessment of Ankle Radiographs. proceedings.mlr.press. Published August 25, 2021. Accessed November 21, 2023. https://proceedings.mlr.press/v143/mairhofer21a.html . Street WN, Wolberg WH, Mangasarian OL. Nuclear feature extraction for breast tumor diagnosis. Acharya RS, Goldgof DB, eds. Biomedical Image Processing and Biomedical Visualization. Published online July 29, 1993. https://doi.org/10.1117/12.148698 . Hazra R, Banerjee M, Badia L. Machine Learning for Breast Cancer Classification With ANN and Decision Tree, 2020 11th IEEE Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON), Vancouver, BC, Canada, 2020, pp. 0522–0527, 10.1109/IEMCON51383.2020.9284936 . Council E. EU Medical Device Regulation- Regulation (EU) 2017/745 of the European Parliament and of the Council. 2023. Additional Declarations No competing interests reported. Cite Share Download PDF Status: Published Journal Publication published 02 Jul, 2025 Read the published version in BMC Medical Informatics and Decision Making → Version 1 posted Editorial decision: Revision requested 06 Sep, 2024 Reviews received at journal 08 Jul, 2024 Reviews received at journal 10 Jun, 2024 Reviewers agreed at journal 31 May, 2024 Reviewers agreed at journal 29 May, 2024 Reviewers invited by journal 27 May, 2024 Editor invited by journal 18 Mar, 2024 Submission checks completed at journal 18 Mar, 2024 Editor assigned by journal 18 Mar, 2024 First submitted to journal 01 Mar, 2024 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-4004492","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Research Article","associatedPublications":[],"authors":[{"id":281210279,"identity":"bf1de10f-7868-4305-9962-5b53c14b4405","order_by":0,"name":"Kfeel Arshad","email":"","orcid":"","institution":"Kiel University and University Hospital Schleswig-Holstein","correspondingAuthor":false,"prefix":"","firstName":"Kfeel","middleName":"","lastName":"Arshad","suffix":""},{"id":281210280,"identity":"2a3b8a0b-3d3b-489d-ac5d-f64883762c27","order_by":1,"name":"Saman Ardalan","email":"","orcid":"","institution":"Kiel University and University Hospital Schleswig-Holstein","correspondingAuthor":false,"prefix":"","firstName":"Saman","middleName":"","lastName":"Ardalan","suffix":""},{"id":281210281,"identity":"001f99a3-a2cd-4c96-9f9b-2720134b832f","order_by":2,"name":"Björn Schreiweis","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABEUlEQVRIie2PMUsDMRTHXyjYJcetKVruK6QEehQO76tcOMjUzcntuqRT6XqHX6JQOLqZI6BL3As6WFxduvUWNVULBUl1dMiPBB4hv/d/D8Dj+YdQUN8VsTcDwNAtOoCK/fmzgtVvChwpX0V2WomRbl6uV5CGN7PN80YmF1H1ygbtCvpzhzIq7vLBgwFePt0zyqXA9HHM8sAAqxwxVJlhbyIho0ScEV5rTM/HTCMJfKGcStxaJbVKd8frdxxVhjWtVW7dyhBZBS1sCvBaYVhjlgX7lBO72MEIL9eiQ/hbjqkRVyyQhJWOlJjoZjuRSRqWAm135jKNpnrZa2XSnzvWB/LZi/x8d/y3hK5eHo/H4znwAZ9aXUuI/Yk3AAAAAElFTkSuQmCC","orcid":"","institution":"Kiel University and University Hospital Schleswig-Holstein","correspondingAuthor":true,"prefix":"","firstName":"Björn","middleName":"","lastName":"Schreiweis","suffix":""},{"id":281210282,"identity":"7eca73a7-e5a4-433a-89d3-402b0f16ef75","order_by":3,"name":"Björn Bergh","email":"","orcid":"","institution":"Kiel University and University Hospital Schleswig-Holstein","correspondingAuthor":false,"prefix":"","firstName":"Björn","middleName":"","lastName":"Bergh","suffix":""}],"badges":[],"createdAt":"2024-03-01 20:48:53","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-4004492/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-4004492/v1","draftVersion":[],"editorialEvents":[{"content":"https://doi.org/10.1186/s12911-025-03087-4","type":"published","date":"2025-07-02T15:57:43+00:00"}],"editorialNote":"","failedWorkflow":false,"files":[{"id":53183798,"identity":"8e12e443-5af3-47b6-8dca-4435501c0224","added_by":"auto","created_at":"2024-03-21 16:03:32","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":169272,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for Data Selection. Two IT system landscapes are illustrated here as sub-pools: the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the Mart and the lanes for the Front-End and Application of the Clinical AI Platform are shown here. The technical sub-components of Data Broker and the Repository for Temporary Data are relevant in the Application lane for this process.\u003c/p\u003e","description":"","filename":"image1.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/85d92df503a54ad5432220e2.png"},{"id":53183799,"identity":"69a95e29-9bb0-4471-8aab-ba0c4c27d197","added_by":"auto","created_at":"2024-03-21 16:03:32","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":145261,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for Data Annotation. Two IT system landscapes are illustrated here as sub-pools: the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the \u003cem\u003eMart\u003c/em\u003e and the lanes for the \u003cem\u003eFront-End\u003c/em\u003e and \u003cem\u003eApplication\u003c/em\u003eof the Clinical AI Platform are shown here. The technical sub-components of \u003cem\u003eData Broker\u003c/em\u003e, \u003cem\u003eData Annotation Tool\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are relevant in the \u003cem\u003eApplication \u003c/em\u003elane for this process.\u003c/p\u003e","description":"","filename":"image2.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/4e0124ca1d611d71f1164822.png"},{"id":53185648,"identity":"e9781924-143c-4daa-9cff-0be3ef5c0193","added_by":"auto","created_at":"2024-03-21 16:11:32","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":199722,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for on-site Training/Testing. Two IT system landscapes are illustrated here as sub-pools: the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the \u003cem\u003eMart\u003c/em\u003e and \u003cem\u003eRepository\u003c/em\u003e and the lanes for the \u003cem\u003eFront-End\u003c/em\u003eand \u003cem\u003eApplication\u003c/em\u003e of the Clinical AI Platform are shown here. The technical sub-components of \u003cem\u003eData Broker\u003c/em\u003e, \u003cem\u003eAI Processing Unit\u003c/em\u003e, \u003cem\u003eModel Repository\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are relevant in the \u003cem\u003eApplication \u003c/em\u003elane for this process.\u003c/p\u003e","description":"","filename":"image3.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/c23bc818544fa36bafc206f2.png"},{"id":53183802,"identity":"388e7f18-ca93-43c7-a9e7-0b41f68b0ea3","added_by":"auto","created_at":"2024-03-21 16:03:32","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":131399,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for (Semi-Automated) Batch Inference (treatment setting). Three IT system landscapes are illustrated here as sub-pools: the EMR, the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the \u003cem\u003eRepository\u003c/em\u003e and the lanes for the \u003cem\u003eFront-End\u003c/em\u003e and \u003cem\u003eApplication\u003c/em\u003e of the Clinical AI Platform are shown here. The technical sub-components of \u003cem\u003eData Broker\u003c/em\u003e, \u003cem\u003eAI Processing Unit\u003c/em\u003e, \u003cem\u003eModel Repository\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are relevant in the \u003cem\u003eApplication \u003c/em\u003elane for this process.\u003c/p\u003e","description":"","filename":"image4.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/d6daa69191fd8b7a27aa2615.png"},{"id":53183800,"identity":"1f3b100e-9b4d-4fa6-8e3f-ac984ed380b6","added_by":"auto","created_at":"2024-03-21 16:03:32","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":128144,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for (Semi-Automated) Batch Inference (research setting). Two IT system landscapes are illustrated here as sub-pools: the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the \u003cem\u003eMart\u003c/em\u003e and \u003cem\u003eRepository\u003c/em\u003e and the lanes for the \u003cem\u003eFront-End\u003c/em\u003e and \u003cem\u003eApplication\u003c/em\u003e of the Clinical AI Platform are shown here. The technical sub-components of \u003cem\u003eData Broker\u003c/em\u003e, \u003cem\u003eAI Processing Unit\u003c/em\u003e, \u003cem\u003eModel Repository\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are relevant in the \u003cem\u003eApplication \u003c/em\u003elane for this process.\u003c/p\u003e","description":"","filename":"image5.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/84eb2e8804ce57d1d78b30dc.png"},{"id":53183803,"identity":"124f021c-22f9-4eb4-9de0-8e7f3c654e0b","added_by":"auto","created_at":"2024-03-21 16:03:32","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":114081,"visible":true,"origin":"","legend":"\u003cp\u003eBPMN diagram for Real-Time Inference. Three IT system landscapes are illustrated here as sub-pools: the EMR, the MeDIC and the Clinical AI Platform. For the MeDIC, the lane for the \u003cem\u003eRepository\u003c/em\u003e and the lanes for the \u003cem\u003eFront-End\u003c/em\u003eand \u003cem\u003eApplication\u003c/em\u003e of the Clinical AI Platform are shown here. The technical sub-components of \u003cem\u003eData Broker\u003c/em\u003e, \u003cem\u003eAI Processing Unit\u003c/em\u003e, \u003cem\u003eModel Repository\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are relevant in the \u003cem\u003eApplication \u003c/em\u003elane for this process.\u003c/p\u003e","description":"","filename":"image6.png","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/34de48ccd3483e01662bf347.png"},{"id":86179044,"identity":"01daee96-1d8a-4cf0-b933-64be985d72e2","added_by":"auto","created_at":"2025-07-07 16:14:57","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":1307109,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-4004492/v1/e9c7871d-bb19-4eb5-bb05-6d4e270b779b.pdf"}],"financialInterests":"No competing interests reported.","formattedTitle":"Integrating an AI Platform into Clinical IT: BPMN Processes for Clinical AI Model Development","fulltext":[{"header":"Background","content":"\u003cp\u003eIn the past several years, we saw a reemergence of Artificial Intelligence (AI) around the world [\u003cspan class=\"CitationRef\"\u003e1\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e2\u003c/span\u003e]. With the rise of AI, AI algorithms are used more frequently in many domains [\u003cspan class=\"CitationRef\"\u003e3\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e4\u003c/span\u003e]. There is also a considerable development of AI-based systems in healthcare settings [\u003cspan class=\"CitationRef\"\u003e5\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e6\u003c/span\u003e]. In several medical domains, such as radiology [\u003cspan class=\"CitationRef\"\u003e7\u003c/span\u003e], cardiology [\u003cspan class=\"CitationRef\"\u003e8\u003c/span\u003e], dermatology [\u003cspan class=\"CitationRef\"\u003e9\u003c/span\u003e] or pathology [\u003cspan class=\"CitationRef\"\u003e10\u003c/span\u003e], we already see progress in clinical decision support using AI systems in recent years. Despite extensive progress in the development of AI systems in many medical domains [\u003cspan class=\"CitationRef\"\u003e11\u003c/span\u003e], translation into clinical routine is still in its early stages and holds many challenges [\u003cspan class=\"CitationRef\"\u003e12\u003c/span\u003e]. One major challenge is, that in many clinical settings there are only isolated AI solutions which are not fully integrated into the existing clinical IT [\u003cspan class=\"CitationRef\"\u003e13\u003c/span\u003e] or data need to be distributed across multiple IT systems to enable AI support in several domains. Initial approaches for integrating a clinical AI platform into the clinical IT were already highlighted, although they are intended for specific medical use cases or individual data types such as alphanumeric data [\u003cspan class=\"CitationRef\"\u003e14\u003c/span\u003e] or imaging data [\u003cspan class=\"CitationRef\"\u003e15\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e16\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eA more comprehensive clinical AI platform solution that covers the entire spectrum of clinical IT landscapes is currently not available. One factor hampering this is the clinical source systems\u0026rsquo; focus on documentation, billing and archiving clinical data [\u003cspan class=\"CitationRef\"\u003e17\u003c/span\u003e]. Overcoming this important barrier, is the aim of approaches like medical data warehousing, clinical data repositories and knowledge management platforms. As part of the German Medical Informatics Initiative\u003ca id=\"#FNLinkFn1\" class=\"FNLink\" href=\"#Fn1\"\u003e1\u003c/a\u003e, all German University Hospitals are currently rolling out so called (medical) data integration centers (MeDICs/DIZ) [\u003cspan class=\"CitationRef\"\u003e18\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e19\u003c/span\u003e]. The main idea of these MeDICs is to integrate clinical routine data from the respective University Hospital\u0026rsquo;s electronic medical record (EMR) system, cleanse, harmonize and make them discoverable and useable for research purposes in particular, for secondary use in general. MeDICs are not only setting up IT infrastructures, but also an organizational structure including processes on how to request, access and use these data [\u003cspan class=\"CitationRef\"\u003e18\u003c/span\u003e, \u003cspan class=\"CitationRef\"\u003e19\u003c/span\u003e].\u003c/p\u003e\n\u003cp\u003eDue to the MeDICs, real world data are readily available and the secondary use of data is possible. Requested data from a MeDIC cannot only be used for retrospective biomedical research, but also for other purposes like training AI models and subsequently use them for inference. To enable broad clinical application of AI, it is necessary that a clinical AI platform is also integrated into the existing clinical IT landscapes for clinical decision support.\u003c/p\u003e\n\u003cp\u003eObjectives\u003c/p\u003e\n\u003cp\u003eTo ensure the successful integration of a clinical AI platform, it is necessary to map out the processes involved in the development and application of clinical AI models. Therefore, it is important to define target processes that are relevant from the perspective of stakeholders in the clinical domain. The objective of this study is to describe these processes using Business Process Model and Notation (BPMN) diagrams, thus laying the foundation for developing the architecture of a clinical AI platform.\u003c/p\u003e\n\u003cp\u003e[1] funded by the German Federal Ministry of Education and Research\u003c/p\u003e"},{"header":"Methods","content":" \u003cp\u003eIn the following, we describe our setting, the requirements analysis methods, use case agnostic processes and the development process of the BMPN diagrams.\u003c/p\u003e \u003cp\u003eSetting\u003c/p\u003e \u003cp\u003e We performed our project at the University Hospital Schleswig-Holstein (UKSH), which is the second-largest hospital in Germany, the only university hospital and maximum care provider in the state of Schleswig-Holstein (northern Germany). Two IT system landscapes can be distinguished within UKSH. First, there are the primary systems, which are used to store all patient treatment-related data, for example the electronic medical record (EMR) system and the picture archiving and communication system (PACS). The EMR system contains all the medical documentation about patients treated within a healthcare organization [\u003cspan citationid=\"CR20\" class=\"CitationRef\"\u003e20\u003c/span\u003e]. A hospital, general practitioner, doctors\u0026rsquo; offices, rehabilitation organizations or care organization is considered a healthcare organization. A PACS system is used to acquire, transmit, display and archive medical imaging data [\u003cspan citationid=\"CR21\" class=\"CitationRef\"\u003e21\u003c/span\u003e]. The second IT system landscape consists of the research IT systems. They include all kinds of research databases and registries, e.g. excel sheets, access databases. Furthermore, electronic data capture (EDC) systems for structured research documentation are part of the research IT landscape. Additionally, biomaterial information systems to manage biomaterial and their information exist.\u003c/p\u003e \u003cp\u003eThe UKSH MeDIC integrates the IT of patient treatment and research. Data from the EMR and subsystems like PACS, laboratory information system, but also research databases, study documentation and biomaterial information are integrated, harmonized and annotated within the MeDIC platform. Additional systems include a Master Patient Index to manage demographics data and a consent management system to process and enforce patient consents [\u003cspan citationid=\"CR18\" class=\"CitationRef\"\u003e18\u003c/span\u003e, \u003cspan citationid=\"CR19\" class=\"CitationRef\"\u003e19\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eThe KI-SIGS project aims at building an AI space for intelligent health systems, which consists of three components: (1) development of four platform projects (a-d) dealing with (a) collaboration, (b) technical aspects, (c) regulatory aspects and (d) responsible innovation, (2) development of nine clinical use cases and (3) improving the healthcare ecosystem in northern Germany [\u003cspan citationid=\"CR22\" class=\"CitationRef\"\u003e22\u003c/span\u003e]. This project is a collaboration of universities, university hospitals and companies in northern Germany. One of the four platform projects in KI-SIGS is the \u0026ldquo;Technical AI Platform\u0026rdquo; (b) which designs a clinical AI platform that can obtain and process data to train and subsequently deploy AI models. Additionally, the Clinical AI platform integrates into the existing IT system landscapes of UKSH. Furthermore, there are nine clinical use cases which are referred to as application and innovation (A\u0026amp;I) projects. Each of the A\u0026amp;I projects is working on applying state-of-the-art machine learning (ML) methods on a specific clinical use case. These use cases employ a broad variety of areas where ML can be utilized from analysis of patients\u0026rsquo; alphanumerical data produced by medical devices at the ICU [\u003cspan citationid=\"CR23\" class=\"CitationRef\"\u003e23\u003c/span\u003e] to medical image analysis [\u003cspan citationid=\"CR24\" class=\"CitationRef\"\u003e24\u003c/span\u003e]. The output of the AI platform project includes the requirements analysis for identifying and documenting the needs as well as objectives for developing a clinical AI platform. The requirements analysis serves as the foundation for the subsequent steps of development. Subsequently, a system architecture of the AI platform is to be designed that maps the development cycle of an AI model derived from the BPMN diagrams. The architecture design ensures scalability, efficiency, and maintainability. Conclusively, a proof of concept will be developed based on the system architecture of the clinical AI platform, which specifies the main functionalities of the AI platform. This involves creating a functional prototype to validate its feasibility and demonstrate its core functionalities. The proof-of-concept provides valuable insights for further refinement and development of a productive clinical AI platform.\u003c/p\u003e \u003cp\u003eRequirements Analysis\u003c/p\u003e \u003cp\u003ePrior to the creation of the BPMN diagrams, we conducted a requirements analysis, which forms the basis of the BPMN processes.\u003c/p\u003e \u003cp\u003eFor our proposed AI platform, we extracted functional and non-functional requirements from different stakeholders in an iterative manner to reassure their consistency, completeness, and correctness. First, we conducted semi-structured interviews [\u003cspan citationid=\"CR25\" class=\"CitationRef\"\u003e25\u003c/span\u003e] by asking all stakeholders about functional and non-functional requirements. Accordingly, the focus was on the discovery of requirements relevant to the AI platform. Two stakeholder groups were identified that cover the entirety of the AI platform requirements. The first stakeholder group consists of computer scientists. In this case, both the computer scientists working in the AI platform project and the computer scientists working on the application (A\u0026amp;I) projects in KI-SIGS were interviewed. There were 7 computer scientists working on the AI platform and 28 computer scientists working on the application projects. Thus, a total of 35 stakeholders working in clinical computer science were interviewed. The second stakeholder group consists of clinical physicians. Within the AI platform, one clinical physician was interviewed. Within the A\u0026amp;I projects, a total of 7 clinical physicians were interviewed. Accordingly, a total of 8 clinical physicians were interviewed. Starting with the semi-structured interview, we performed the conventional steps for a requirements analysis [\u003cspan citationid=\"CR26\" class=\"CitationRef\"\u003e26\u003c/span\u003e]. First, the requirements were identified and gathered. We consequently extracted the main demands for an AI platform and current limitations. The requirements were initially gathered in a Mindmap for the collection process. Then the requirements were reviewed and categorized by the stakeholders, who are working on the AI platform. The review of the requirements mainly included targeting and plausibility checks. Subsequently, the requirements were further categorized within functional and non-functional requirements. The entire outlined process was performed in three iterations with all stakeholders involved in the development of the AI platform. Then the requirements were documented and are now managed in a cloud to which all project participants have access.\u003c/p\u003e \u003cp\u003eThe development and deployment of clinical AI models can be represented by consecutive processes [\u003cspan citationid=\"CR27\" class=\"CitationRef\"\u003e27\u003c/span\u003e, \u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e]. Based on the processes outlined by Lu et al. [\u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e], we have identified four overarching use case agnostic processes that cover the complete workflow for the development and deployment of clinical AI models.\u003c/p\u003e \u003cp\u003eThe main functional requirements that represent the necessary boundary conditions for our process flows are outlined in Table \u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e. These requirements can be derived from the functional requirements for medical data integration into knowledge management environments [\u003cspan citationid=\"CR29\" class=\"CitationRef\"\u003e29\u003c/span\u003e]:\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab1\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eMain functional requirements for development of the use case agnostic processes.\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"1\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003e1. Infrastructural conditions are provided such that the AI platform can run on-premises and thus no data leave the site.\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e2. The AI models should be stored together with associated descriptive information in the AI platform or in the knowledge management platform.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e3. The AI platform should be able to store the data temporarily.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e4. The AI platform should be linked to the medical data integration center and hospital information system.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e5. The AI platform serves as a data mart and should process a subset of the data from the medical data integration center.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e6. The AI platform should support alphanumeric and multimedia data.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e7. The AI platform should be able to process anonymized, pseudonymized and non-pseudonymized data.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e8. The AI platform should be designed to be able to be connected to other data platforms.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e9. The AI platform should support all identified use case agnostic processes.\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003ctfoot\u003e \u003ctr\u003e\u003ctd colspan=\"1\"\u003eFEDS-Framework\u003c/td\u003e\u003c/tr\u003e \u003c/tfoot\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eWe evaluated the BPMN diagrams using the Framework for Evaluation in Design Research (FEDS) framework [\u003cspan citationid=\"CR30\" class=\"CitationRef\"\u003e30\u003c/span\u003e]. The FEDS framework was developed to provide a strategy for the evaluation of Design Research Science (DSR) projects. DSR can be defined as: \u0026ldquo;a problem-solving paradigm that seeks to enhance human knowledge via the creation of innovative artifacts\u0026ldquo; [\u003cspan citationid=\"CR31\" class=\"CitationRef\"\u003e31\u003c/span\u003e]. FEDS contains a two-dimensional characterization for the evaluation of DSR projects. One dimension includes the functional purpose of the evaluation, whether it is formative or summative. The second dimension identifies the paradigm of the evaluation, whether it is artificial or naturalistic. The FEDS evaluation consists of four steps: Stating the objectives of the evaluation, selecting the evaluation strategy, identifying the attributes to be evaluated and designing the evaluation episodes.\u003c/p\u003e \u003cp\u003eFirst, the objective of the evaluation is determined. The goal for our evaluation is to minimize the technical uncertainties and risks in the future integration and development of the clinical AI platform. We then select the strategy for the evaluation based on the goal. Since we want to determine whether the technical aspects work as intended in our BPMN diagrams and it is a highly technically oriented design, we apply the Technical Risk \u0026amp; Efficacy strategy. We then check which attributes should be evaluated. Here, we choose the accuracy of the process representation as the main attribute. Accordingly, the evaluation should show the completeness of the development process of an AI model in our BPMN diagrams. Subsequently, we define three evaluation episodes to demonstrate the completeness of the BPMN diagrams. In the following, we introduce these evaluation episodes in the form of three use cases that represent a broad range of AI applications in the clinical domain.\u003c/p\u003e \u003cp\u003eUse Cases\u003c/p\u003e \u003cp\u003eWe selected three clinical use cases for the evaluation of the BPMN diagrams. The first use case for our evaluation is from the KI-SIGS project and is referred to as \u0026ldquo;digital x-ray assistant\u0026rdquo;. This use case is about assessing the quality of upper ankle radiographs. In this use case radiographs of the upper ankle joint are rated from 1 to 3 by radiologists. 1 stands for excellent image quality, 2 stands for acceptable image quality, while 3 stands for non-acceptable image quality. The aim of this use case is to train an AI model that can perform this assessment. In this case, it is the training of a Convolutional Neural Network (CNN) [\u003cspan citationid=\"CR32\" class=\"CitationRef\"\u003e32\u003c/span\u003e, \u003cspan citationid=\"CR33\" class=\"CitationRef\"\u003e33\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eThe second use case for evaluation is the distinction between benign and malignant tumor in breast carcinoma. The Wisconsin Breast Cancer data set [\u003cspan citationid=\"CR34\" class=\"CitationRef\"\u003e34\u003c/span\u003e] can be used for this purpose. The data set consists of structured pathology reports (alphanumeric data) describing the cell nucleus from digitized images of a breast cancer. For example, the mean value of the distances from the center to the points on the perimeter is calculated and recorded as a numerical value. There are 10 features in total. In addition, for each data set, it is indicated whether the breast cancer is benign or malignant. Accordingly, the data are already annotated and do not require further annotation. The goal is to train an AI model that can predict whether it is a benign or malignant breast cancer using new input data. In this case, the AI algorithm is a decision tree model with non-correlated features as input parameters [\u003cspan citationid=\"CR35\" class=\"CitationRef\"\u003e35\u003c/span\u003e], which should distinguish whether the input data are indicative of a malignant or benign tumor. Therefore, the output can either represent benign or malign.\u003c/p\u003e \u003cp\u003eThe third use case for evaluation is also from the KI-SIGS project and is referred to as \u0026ldquo;Risk indicators for cardiopulmonary decompensation in intensive care units by monitoring vital signs\u0026rdquo; [\u003cspan citationid=\"CR23\" class=\"CitationRef\"\u003e23\u003c/span\u003e]. The risk assessment is achieved through a scoring system designed to rank and predict pulmonary and hemodynamic decompensation based on vital parameters. A Gated Recurrent Unit (GRU) network is used for the training. The vital parameters, such as heart rate or oxygen saturation, are used as input parameters. A complete list of the input parameters can be found in [\u003cspan citationid=\"CR23\" class=\"CitationRef\"\u003e23\u003c/span\u003e].\u003c/p\u003e"},{"header":"Results","content":"\u003cp\u003eThe BPMN diagrams include the processes of Data Selection, Data Annotation, On-Site Training/Testing and Inference, whereas for Inference a case distinction was made between (Semi-Automated) Batch Inference and Real-Time Inference.\u003c/p\u003e \u003cp\u003eIn the context of BPMN, we define three sub-pools within UKSH: EMR, MeDIC and the Clinical AI Platform. The MeDIC includes two lanes: \u003cem\u003eRepository\u003c/em\u003e, which holds the entire medical data within MeDIC and \u003cem\u003eMart\u003c/em\u003e. A mart is a specific cohort data set. The Clinical AI Platform includes two lanes: \u003cem\u003eFront-End\u003c/em\u003e and \u003cem\u003eApplication\u003c/em\u003e. The \u003cem\u003eApplication\u003c/em\u003e lane includes technical subcomponents such as a \u003cem\u003eData Broker\u003c/em\u003e, which acts as an API between the Clinical AI Platform and the other IT system landscapes; an \u003cem\u003eAI Processing Unit\u003c/em\u003e, which is responsible for compiling the data cohort, performing data annotation and training, and orchestrating the associated processes; a \u003cem\u003eModel Repository\u003c/em\u003e, which contains the trained models; and a \u003cem\u003eRepository for Temporary Data\u003c/em\u003e, which serves as temporary data persistence for the cohort data.\u003c/p\u003e \u003cp\u003eData Selection\u003c/p\u003e \u003cp\u003eThe first process is Data Selection. This process focuses on selecting a suitable cohort and its corresponding data set for a specific AI use case, e.g. laboratory data or imaging data from radiology. In this case, it is important to note that we assume that the data cohort is already approved for use by the Use \u0026amp; Access Committee and then prepared by the MeDIC\u0026rsquo;s data transfer unit. The user can subsequently select an already pseudonymized cohort data set in the \u003cem\u003eFront-End\u003c/em\u003e, which is made available as a mart in the MeDIC. The request is forwarded to the MeDIC via the \u003cem\u003eData Broker\u003c/em\u003e. During this process, both alphanumeric data and multimedia data can be made available from the MeDIC \u003cem\u003eRepository\u003c/em\u003e in the MeDIC \u003cem\u003eMart\u003c/em\u003e. Then, the data are stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e. The user evaluates and verifies the pseudonymized data. Afterwards, the cohort data set is defined by selecting adequate data from the provided mart that meets the requirements of the specific AI use case. In the next step, the information about the defined cohort data set is forwarded by the \u003cem\u003eData Broker\u003c/em\u003e to the MeDIC \u003cem\u003eMart\u003c/em\u003e and the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e, while the initial cohort data set is deleted. In the \u003cem\u003eFront-End\u003c/em\u003e, the user is shown that the storage of the defined cohort data set was successful and in addition, the user is asked whether the process should be continued. In the case of continuation, the user can either continue with the Data Annotation process or, if no annotation is required, continue with the On-site Training/Test process. Otherwise, the data are deleted from the Repository for Temporary Data. The BPMN diagram for Data Selection is illustrated in Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eData Annotation\u003c/p\u003e \u003cp\u003eThe second process describes the Data Annotation. The BPMN diagram for Data Annotation is illustrated in Fig.\u0026nbsp;\u003cspan refid=\"Fig2\" class=\"InternalRef\"\u003e2\u003c/span\u003e. We assume, that the cohort data set is not available in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. The user sends a request from the \u003cem\u003eFront-End\u003c/em\u003e for a specific, already reviewed and defined cohort data set to be annotated. The \u003cem\u003eData Broker\u003c/em\u003e forwards the request to the MeDIC \u003cem\u003eMart\u003c/em\u003e, which returns the pseudonymized medical data (PSN and MDAT). The retrieved cohort data are passed through the \u003cem\u003eData Broker\u003c/em\u003e to the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Once the cohort data are in the repository, they can be annotated by domain experts. When the annotation process is complete, the annotation information for the specific cohort data set is passed to MeDIC via the \u003cem\u003eData Broker\u003c/em\u003e and archived in the \u003cem\u003eMart\u003c/em\u003e. Once it is confirmed that the annotation process is completed, a decision is made by the User in the \u003cem\u003eFront-End\u003c/em\u003e as to whether the cohort data can be further used in a timely manner or whether it can be deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. If the process is to be continued in the near future, the next process would be On-Site Training and Testing. In such a case, the cohort data would remain in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eOn-site Training and Testing\u003c/p\u003e \u003cp\u003eThe third process is On-site Training and Testing. Figure\u0026nbsp;\u003cspan refid=\"Fig3\" class=\"InternalRef\"\u003e3\u003c/span\u003e illustrates the BPMN diagram for On-Site Training and Testing. We assume, that the cohort data set is not available in the Repository for Temporary Data. The user of the \u003cem\u003eFront-End\u003c/em\u003e starts the process by retrieving the (annotated) cohort data set from the \u003cem\u003eMart\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e. The cohort data set is then reviewed by the user, whether any further annotation is required. If further annotation is required, the annotation process is run again. If no further annotation is required, the \u003cem\u003eData Broker\u003c/em\u003e transfers the (annotated) cohort data set to the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Then the training of the AI model is initialized and performed in the \u003cem\u003eAI Processing Unit\u003c/em\u003e. Note that a seed must be initialized for traceability of the training process. After each training session, the AI model is created or updated. The AI model is then tested and tracked. Once the AI model has been tested, it is checked to see whether the results obtained are satisfactory from a technical point of view. If this is not the case, the hyperparameters are adjusted and the training loop is run again. In the course of training, the AI model is temporarily stored in the \u003cem\u003eModel Repository\u003c/em\u003e. After completion of the technical evaluation, a medical evaluation is performed. This medical evaluation includes, firstly, the clinician's/user's view of medical usability and relevance, and secondly, the regulatory evaluation, such as the Medical Device Regulation (MDR) [\u003cspan citationid=\"CR36\" class=\"CitationRef\"\u003e36\u003c/span\u003e]. If the result of medical evaluation is negative, the training can be continued with adjusted parameters or the training can be stopped. If the medical evaluation is positive, the final AI model is either stored permanently in the \u003cem\u003eModel Repository\u003c/em\u003e or, if other storage options exist (e.g. in the MeDIC), the AI model is stored elsewhere. This depends on the individual IT system design. Once the storage process of the AI model is completed, the data are deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Then a technical, medical and data definition documentation is created and stored in the \u003cem\u003eMart\u003c/em\u003e and \u003cem\u003eRepository\u003c/em\u003e of the MeDIC.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eInference\u003c/p\u003e \u003cp\u003eThe fourth process is inference. The inference process is responsible for assessments based on incoming data. In this context, we distinguish between (Semi-Automated) Batch Inference and Real-Time Inference.\u003c/p\u003e \u003cp\u003e(Semi-Automated) Batch Inference\u003c/p\u003e \u003cp\u003eThe BPMN diagram for (Semi-Automated) Batch Inference is illustrated in Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003e. In this case, we are dealing with the treatment setting, which means that clinicians want to calculate a prediction for a batch. If the AI model to be used is already known, this process can be referred to as Semi Automated Batch Inference. The purpose of (Semi-Automated) Batch Inference is that data can be processed individually per data subset, i.e. patient. For this purpose, the user accesses the \u003cem\u003eFront-End\u003c/em\u003e via a connected EMR System. After the available models were queried from the \u003cem\u003eModel Repository\u003c/em\u003e, the user can select a suitable AI model, if the AI model to be used is not yet known. The corresponding batch is then transferred from the EMR System to the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e of the Clinical AI Platform via the \u003cem\u003eData Broker\u003c/em\u003e, once preprocessing and a check of the data were successful. The selected model is loaded from the \u003cem\u003eModel Repository\u003c/em\u003e into the \u003cem\u003eAI Processing Unit\u003c/em\u003e. After the inference is performed successfully, the results are finalized for storage and visualization. The \u003cem\u003eData Broker\u003c/em\u003e transfers the results to the MeDIC \u003cem\u003eMart\u003c/em\u003e. Additionally, the results are transferred to the EMR. Finally, the results of the prediction are visualized in the EMR System.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eHowever, it is important to consider that the (Semi-Automated) Batch Inference can also be performed in a research setting. This scenario is shown in Fig.\u0026nbsp;\u003cspan refid=\"Fig5\" class=\"InternalRef\"\u003e5\u003c/span\u003e. In this case, researchers want to calculate a prediction for a batch. The difference to the treatment setting is that the researcher starts the inference within the Clinical AI Platform. In addition, the data are provided from the MeDIC \u003cem\u003eMart\u003c/em\u003e and not from the EMR. In this case, the results are stored in the \u003cem\u003eMart\u003c/em\u003e and depending on whether permanent storage is intended, also in the \u003cem\u003eRepository\u003c/em\u003e. The visualization takes place in the Clinical AI Platform\u0026rsquo;s \u003cem\u003eFront-End\u003c/em\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eReal-Time Inference\u003c/p\u003e \u003cp\u003eFor the Real-Time Inference, it is also clear from the setting which model will be used. In this case, we assumed that only the treatment setting is relevant for the Real-Time Inference. A practical example is streaming data from the monitoring in the intensive care unit. Here, it is necessary to make real-time predictions from incoming streaming data. Apart from this, the process of providing the data and storing the results is similar to the inferences in the Figs.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003e and \u003cspan refid=\"Fig5\" class=\"InternalRef\"\u003e5\u003c/span\u003e. The BPMN diagram for Real-Time Inference is illustrated in Fig.\u0026nbsp;\u003cspan refid=\"Fig6\" class=\"InternalRef\"\u003e6\u003c/span\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eEvaluation\u003c/p\u003e \u003cp\u003eThe first use case for evaluation is the \u0026ldquo;digital x-ray assistant\u0026rdquo; from the KI-SIGS project. Initially, we start with the Data Selection process. We assume that the radiographs are provided via a MeDIC \u003cem\u003eMart\u003c/em\u003e. Accordingly, the cohort can be accessed by an authorized clinician via the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. The cohort is stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. The clinician can then evaluate, review and subsequently define and configure the cohort in the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. This includes checking that the existing images are usable. The configured cohort is forwarded to the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e and stored there, while the initial cohort is deleted. The information about the configured cohort is also stored in the MeDIC \u003cem\u003eMart\u003c/em\u003e. We assume that the process will not be continued in a timely manner in this case, so that the cohort with the images will be deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Subsequently, the Data Selection process ends.\u003c/p\u003e \u003cp\u003eThe next step is the Data Annotation process. Here, the user can query the already configured cohort via the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. The cohort is then loaded from the MeDIC \u003cem\u003eMart\u003c/em\u003e into the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e. The cohort can afterwards be annotated using a linked data annotation tool. After the annotation is completed, the annotation information will be stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and also in the MeDIC \u003cem\u003eMart\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e. Since we assume in this case that there is a longer time delay after the annotation process, the annotation information is deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e.\u003c/p\u003e \u003cp\u003eThen the On-Site Training/Testing process starts. Once again, the user can retrieve the cohort including the annotation from the MeDIC \u003cem\u003eMart\u003c/em\u003e in the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform via the \u003cem\u003eData Broker\u003c/em\u003e. The user can check whether the cohort was already completely annotated or whether further annotation is necessary. Assuming that the annotation was already completed, the cohort is stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Afterwards, the training can be initialized in the \u003cem\u003eAI Processing Unit\u003c/em\u003e. A seed is defined, which is necessary for reproducibility. After the training is complete, an AI model is created, tested and then stored in the \u003cem\u003eModel Repository\u003c/em\u003e. The AI model can then be checked with the help of various metrics. If, from a technical point of view, the results are not yet satisfactory or if further configurations to the CNN need to be evaluated, the training is started again. After the training is completed, the AI models can be compared to each other. If the technical evaluation of the AI model is successful, a medical evaluation can be performed to check the medical plausibility of the AI model. If this is successfully completed, the final AI model can be stored in the \u003cem\u003eModel Repository\u003c/em\u003e. The temporarily stored data of the cohort in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e are then deleted. Furthermore, the \u003cem\u003eAI Processing Unit\u003c/em\u003e produces the technical, medical and data definition documentation. This documentation is stored in the MeDIC \u003cem\u003eMart\u003c/em\u003e and, if required, also in the MeDIC \u003cem\u003eRepository\u003c/em\u003e for permanent storage. The On-site Training/Testing process is then completed.\u003c/p\u003e \u003cp\u003eIn the following, the inference takes place in a treatment setting. Batch inference is used here, i.e. the clinician has a batch of radiographs on which a quality assessment of the upper ankle joint is to be performed. For this, the clinician can make a request for the available AI models via the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. The matching AI models are then forwarded from the \u003cem\u003eModel Repository\u003c/em\u003e to the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. The clinician can select the appropriate model and simultaneously transfer his batch from the EMR to the Clinical AI Platform. The \u003cem\u003eAI Processing Unit\u003c/em\u003e then performs the inference. The process is recorded and the results are stored and displayed in the EMR. For permanent storage, results can also be stored in the MeDIC \u003cem\u003eRepository\u003c/em\u003e.\u003c/p\u003e \u003cp\u003eThe second use case for the evaluation is the differentiation of benign from malignant tumors in breast cancer. We evaluate whether our BPMN diagrams are effective for Data Selection, On-Site Training/Testing and Semi-Automated Batch Inference within the research setting. In this case, we assume once again that the user is authorized by the responsible Use \u0026amp; Access Committee to receive the cohort data set with the Wisconsin Breast Cancer data set. Accordingly, the User sends a request from the \u003cem\u003eFront-End\u003c/em\u003e through the \u003cem\u003eData Broker\u003c/em\u003e to retrieve the pseudonymized cohort data set, which is already made available via a MeDIC \u003cem\u003eMart\u003c/em\u003e. Subsequently, the cohort data set is stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. Once the cohort data set is available in the Clinical AI Platform, the user can evaluate, review and define the cohort in the \u003cem\u003eFront-End\u003c/em\u003e. Afterwards, the information about the reviewed cohort data set is stored both in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and in the MeDIC \u003cem\u003eMart\u003c/em\u003e. In this case, the process is continued right away, so the data cohort can remain in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e for now.\u003c/p\u003e \u003cp\u003eAs the data are already annotated, we continue with the On-Site Training/Testing process. We move to the initialization of training, as the cohort data set already exists in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. A seed is defined, which is necessary for reproducibility. Then the training is performed and tracked. The process of training and testing is performed similarly to the process of the first use case. Once the AI model has passed medical evaluation, the final AI model is stored in the Model Repository. Subsequently, the cohort data of the Wisconsin Breast Cancer data set can be deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. At the same time, a technical and a medical documentation are generated and then stored in the MeDIC \u003cem\u003eMart\u003c/em\u003e and/or the MeDIC \u003cem\u003eRepository\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e.\u003c/p\u003e \u003cp\u003eIn the following, the researchers want to apply inference based on a new cohort that contains parameters describing the cell nucleus from images. In this case, the Semi-Automated Batch Inference in the research setting is applied. The user activates the AI model for the given use case for the classification of benign and malignant breast tumors via the \u003cem\u003eFront-End\u003c/em\u003e. The AI model is loaded into the \u003cem\u003eAI Processing Unit\u003c/em\u003e. Simultaneously, the cohort data set for the inference will be retrieved from the MeDIC \u003cem\u003eMart\u003c/em\u003e and loaded to the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e. After the decision tree model from the \u003cem\u003eModel Repository\u003c/em\u003e and the new cohort from the MeDIC \u003cem\u003eMart\u003c/em\u003e are loaded into the \u003cem\u003eAI Processing Unit\u003c/em\u003e, the inference is performed. The results are processed and stored in the MeDIC \u003cem\u003eMart\u003c/em\u003e and, if necessary, in the MeDIC \u003cem\u003eRepository\u003c/em\u003e. The results are then visualized in the \u003cem\u003eFront-End\u003c/em\u003e of the AI platform.\u003c/p\u003e \u003cp\u003eThe third use case is \u0026ldquo;Risk indicators for cardiopulmonary decompensation in intensive care units by monitoring vital signs\u0026rdquo;. Upon approval by the Use \u0026amp; Access Committee to use the cohort data set and its provision in the MeDIC \u003cem\u003eMart\u003c/em\u003e, the user can request the cohort data set in the \u003cem\u003eFront-End\u003c/em\u003e via the \u003cem\u003eData Broker\u003c/em\u003e from the MeDIC \u003cem\u003eMart\u003c/em\u003e. The cohort is then stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e. The user can evaluate, review and define the cohort in the \u003cem\u003eFront-End\u003c/em\u003e once the cohort data set is available in the Clinical AI Platform. This involves evaluating whether the data are fit for purpose or if it is flawed or incomplete, and thus unusable. Afterwards, the configured cohort is stored via the \u003cem\u003eData Broker\u003c/em\u003e in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and in the MeDIC \u003cem\u003eMart\u003c/em\u003e. Since the cohort data set requires annotation, we proceed to the annotation process. The user can retrieve the cohort from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e in the \u003cem\u003eFront-End\u003c/em\u003e and annotate the data. The annotation consists of calculating Decompensation Scores (DEC scores), which provide information on the timing of the relevant occurrences. A distinction is made between no decompensation, beginning-moderate decompensation and severe decompensation. These classes should be predicted up to 24 hours before occurrence. As soon as the annotation is completed, the annotation information is stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and via \u003cem\u003eData Broker\u003c/em\u003e also in the MeDIC \u003cem\u003eMart\u003c/em\u003e. We assume that there is a longer time delay between the data annotation process and the On-site Training/Testing process. Therefore, the cohort is deleted from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e.\u003c/p\u003e \u003cp\u003eAs soon as the On-site Training/Testing process is started, the user can retrieve the cohort in the \u003cem\u003eFront-End\u003c/em\u003e from the MeDIC \u003cem\u003eMart\u003c/em\u003e via \u003cem\u003eData Broker\u003c/em\u003e. The process of training and testing is performed similarly to the process of the other two use cases. The On-site Training/Testing process ends with feedback to the Front-End, if the process has been executed successfully.\u003c/p\u003e \u003cp\u003eIn this use case, the continuous processing of vital signs is crucial for the early detection of cardiopulmonary decompensation. For this purpose, the EMR system continuously delivers the vital signs to the TKIP via the \u003cem\u003eData Broker\u003c/em\u003e. To ensure correct processing, the incoming data are pre-processed in the \u003cem\u003eAI Processing Unit\u003c/em\u003e. This includes the selection of the required parameters with the correct unit. The data are temporarily stored in the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and then the trained AI model is loaded from the \u003cem\u003eModel Repository\u003c/em\u003e to the \u003cem\u003eAI Processing Unit\u003c/em\u003e. There, the data are loaded from the \u003cem\u003eRepository for Temporary Data\u003c/em\u003e and then \u003cem\u003eReal-Time Inference\u003c/em\u003e is performed. The results are then processed for presentation, which includes the classification of the DEC score. The \u003cem\u003eData Broker\u003c/em\u003e forwards the results to the EMR and the MeDIC \u003cem\u003eRepository\u003c/em\u003e, enabling the results to be displayed in the EMR. Optionally, the results can also be displayed in the \u003cem\u003eFront-End\u003c/em\u003e of the Clinical AI Platform. The next data set from the EMR system is then prepared for Real-Time Inference, resulting in the recurrence of the procedure.\u003c/p\u003e"},{"header":"Discussion","content":"\u003cp\u003ePrincipal Results\u003c/p\u003e \u003cp\u003eThe aim of this work was to demonstrate the integration of a clinical AI platform into clinical IT, including the entire development cycle for an AI model using BPMN process diagrams. For this purpose, the requirements determined in the sub-project \"Technical AI Platform\" of KI-SIGS were used as a basis to define the boundary conditions for the development of the BPMN diagrams. The processes of the BPMN diagrams were determined on the basis of literature. The presented BPMN diagrams cover the entire development cycle of an AI model with the differentiated processes of Data Selection, Data Annotation, On-site Training/Testing, Batch Inference, Semi-Automated Batch Inference and Real-Time Inference. The three IT system landscapes at the UKSH are of particular importance for this purpose: EMR, MeDIC and the Clinical AI Platform. We identified two components of MeDIC that are relevant in our development context: \u003cem\u003eMart\u003c/em\u003e and \u003cem\u003eRepository\u003c/em\u003e. The Clinical AI Platform consists of a \u003cem\u003eFront-End\u003c/em\u003e and an \u003cem\u003eApplication\u003c/em\u003e part. The \u003cem\u003eApplication\u003c/em\u003e consists of a \u003cem\u003eData Broker\u003c/em\u003e, which is necessary for communication between the IT system landscapes, an \u003cem\u003eAI Processing Unit\u003c/em\u003e, which processes all activities for which dedicated computing capacity is required. The application also includes a \u003cem\u003eModel Repository\u003c/em\u003e for the AI models and a \u003cem\u003eRepository for Temporary Data\u003c/em\u003e for the temporary storage of cohorts. Other tools can also be integrated into the Clinical AI Platform for data annotation. The BPMN diagram for Data Selection shows how the cohorts provided in the MeDIC \u003cem\u003eMart\u003c/em\u003e can be retrieved and defined by the user in the Clinical AI Platform. The BPMN diagram of Data Annotation demonstrates the process of how the cohort data set can be annotated in the Clinical AI Platform and can then be stored with the cohort itself. The BPMN diagram of On-site Training and Testing displays how an already defined and annotated cohort data set can be loaded and an already defined AI algorithm can be trained with this cohort. We distinguish between three different cases for inference to cover the spectrum of possible clinical use cases: Batch Inference, Semi-Automated Batch Inference and Real-Time Inference. The Batch Inference describes the case of Inference for single or multiple cohort data instances with manual AI model selection. Semi-Automated Batch Inference also describes inference with single or multiple cohort data instances, but with a pre-selected AI model that can automatically be retrieved. Real-Time Inference describes the inference of streaming data that can e.g. be observed in ICU use cases for monitoring patients\u0026rsquo; vital parameters. We evaluated these processes with three clinical use cases that verify the completeness of the BPMN diagrams. We selected the FEDS framework for evaluating the BPMN diagrams to ensure a systematic analysis and assessment of our results. The FEDS framework also ensures a consistent and comparable evaluation [\u003cspan citationid=\"CR30\" class=\"CitationRef\"\u003e30\u003c/span\u003e]. With the aid of three independent clinical use cases, we were able to demonstrate for each individual process, as well as for the overall evaluation objective, that the AI development cycle can be successfully represented with the developed processes, thus minimizing technical uncertainty. Therefore, it can be determined that the processes represent the complete and comprehensive development cycle of an AI model within the clinical IT according to Lu et al [\u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eLimitations\u003c/p\u003e \u003cp\u003eAlthough our BPMN diagrams map a broad spectrum of AI development in a clinical context, there may be use cases that require a more specific process mapping. There may be individual use cases that require more human interaction, thus leading to multiple iterations. Accordingly, the processes and the corresponding BPMN diagrams can be considered as blueprints that are suitable for most clinical use cases. Furthermore, it is important to consider the depth of the process mapping. Many activities within the processes can certainly be displayed in more detail. Accordingly, we have chosen the trade-off in favor of generalizability rather than depth of detail in order to map the range of clinical use cases as accurately as possible. Another aspect is the consideration of security and privacy factors. This would be a useful extension of the BPMN process diagrams. Non-functional aspects such as security or privacy factors were implicitly considered in our elaborations because the priority was to consider and implement the functional aspects to demonstrate the functionalities of the Clinical AI Platform. In general, privacy by design should be ensured for the clinical AI platform. Further development of the BPMN diagrams could also include consideration of paradigms such as federated learning, which includes the aggregation of cohort data sets from multiple sites. In our paper, the training/testing scenario only referred to On-site Training/Testing.\u003c/p\u003e \u003cp\u003eComparison with Prior Work\u003c/p\u003e \u003cp\u003ePrevious publications have shown which processes exist within the development cycle of an AI model [\u003cspan citationid=\"CR27\" class=\"CitationRef\"\u003e27\u003c/span\u003e, \u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e]. While Amershi et al. [\u003cspan citationid=\"CR27\" class=\"CitationRef\"\u003e27\u003c/span\u003e] show the development cycle of an AI model in nine small steps, Lu et al. [\u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e] present a more summarized development cycle in six steps. In our approach, we have summarized the development cycle of Lu et al. [\u003cspan citationid=\"CR28\" class=\"CitationRef\"\u003e28\u003c/span\u003e] even further and presented the entire development cycle of an AI model in only four overarching steps. Our approach focuses on the technical development cycle and excludes preparatory processes that are usually not specific to the development of AI models. The main advantage of our approach is the comprehensibility of the technical development process while covering generic clinical AI use cases. Amershi et al. focus on AI model development without specific emphasis on any particular domain, while Lu et al. describe the processes they have identified in the clinical domain but rather generally. In contrast to this, we describe the processes that we have identified in detail with the help of BPMN diagrams, which is a novel approach in the field of clinical AI model development. Previous work also shows possible integrations of an AI platform clinical IT [\u003cspan additionalcitationids=\"CR15\" citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e]. However, they are either limited to certain data types or to medical domains. While Gruendner et al. [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e] only present the integration of alphanumeric data with FHIR, Scherer et al. [\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e] and Leiner et al. [\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e] only focus on imaging data. In our approach, there is no limitation in terms of data types. Our approach addresses the entirety of clinical data types. Besides, Gruendner et al., Scherer et al. and Leiner et al. [\u003cspan additionalcitationids=\"CR15\" citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR16\" class=\"CitationRef\"\u003e16\u003c/span\u003e] provide no description of the development of relevant AI processes in the hospital, which include the medical data integration centers and the primary systems. With our study, we show how the translation of requirements and the definition of processes into an architecture within clinical IT can be realized. The intermediate step of describing the defined processes can describe the interaction between the clinical IT system landscapes and thus validate the architecture.\u003c/p\u003e"},{"header":"Conclusions","content":"\u003cp\u003eWith the BPMN diagrams presented in this paper, we laid the foundation to design the architecture of a clinical AI platform. The architecture and implementation of the AI platform in KI-SIGS will be based on the BPMN diagrams. In addition, the processes and interaction between the three clinical IT landscapes of the EMR, the MeDIC and the Clinical AI platform are shown for the first time. With the help of the use case agnostic processes presented, the entire workflow for creating and applying a clinical AI model can be illustrated. Our BPMN diagrams also provide a basis for similar projects to develop an AI platform. In many cases, clinical AI platforms can be realized that are based on an abstracted version of our BPMN diagrams.\u003c/p\u003e"},{"header":"Abbreviations","content":"\u003cdiv class=\"DefinitionList\"\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eA\u0026amp;I\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eApplication \u0026amp; Innovation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eAI\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eArtificial Intelligence\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eAPI\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eApplication Programming Interface\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eBPMN\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eBusiness Process Model and Notation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eCNN\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eConvolutional Neural Network\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDEC scores\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eDecompensation scores\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDIZ\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eData Integration Center\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eDSR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eDesign Science Research\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eEDC\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eElectronic Data Capture\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eEMR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eElectronic Medical Record\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eFEDS\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eFramework for Evaluation in Design Science\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eFHIR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eFast Healthcare Interoperability Resource\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eGRU\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eGated Recurrent Unit\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eICU\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eIntensive Care Unit\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eIT\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eInformation Technology\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMDAT\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMedical Data\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMDR\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMedical Device Regulation\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eMeDIC\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMedical Data Integration Center\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eML\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eMachine Learning\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003ePACS\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003ePicture Archiving and Communication System\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003ePSN\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003ePseudonym\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003cdiv class=\"DefinitionListEntry\"\u003e \u003cdiv class=\"Term\"\u003eUKSH\u003c/div\u003e \u003cdiv class=\"Description\"\u003e \u003cp\u003eUniversity Hospital Schleswig-Holstein\u003c/p\u003e \u003c/div\u003e \u003c/div\u003e \u003c/div\u003e"},{"header":"Declarations","content":"\u003ch3\u003eEthics approval and consent to participate\u003c/h3\u003e\n\u003cp\u003eIn accordance with legal data protection requirements, only anonymous data has been used. In this context, based on \u0026sect;2 of the Statutes of the Ethics Committee of the Faculty of Medicine of Kiel University, no consultation of the Ethics Committee is required. Participants provided informed consent before starting the interviews.\u003c/p\u003e\n\u003ch3\u003eConsent for publication\u003c/h3\u003e\n\u003cp\u003eNot applicable.\u003c/p\u003e\n\u003ch3\u003eAvailability of data and materials\u003c/h3\u003e\n\u003cp\u003eThe data used in the current study are not publicly available but are available from the corresponding author upon reasonable request.\u003c/p\u003e\n\u003ch3\u003eCompeting interests\u003c/h3\u003e\n\u003cp\u003eThe authors declare that they have no competing interests.\u003c/p\u003e\n\u003ch3\u003eFunding\u003c/h3\u003e\n\u003cp\u003eThis research was supported by Federal Ministry for Economic Affairs and Climate Action under Grant No. 01MK20012U.\u003c/p\u003e\n\u003ch3\u003eAuthors\u0026apos; contributions\u003c/h3\u003e\n\u003cp\u003eKA and SA initiated this research. KA and SA designed the first drafts of BPMN diagrams. KA designed the advanced BPMN diagrams. KA wrote and structured the manuscript. KA evaluated the BPMN diagrams. BS and BB gave their input on the BPMN diagrams and supervised the research. BS and BB gave their input on the content and structure of the manuscript and reviewed the manuscript.\u003c/p\u003e\n\u003ch3\u003eAcknowledgements\u003c/h3\u003e\n\u003cp\u003eThe authors wish to thank the project partners in KI-SIGS for their insightful comments and suggestions during the execution of this research.\u0026nbsp;\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\u003cli\u003e\u003cspan\u003eCheung C, Baker S, Maxwell T et al. Rapid expansion - Research on topics related to artificial intelligence and robotics is hitting new heights. Nature 610, S9 (2022). \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1038/d41586-022-03210-9\u003c/span\u003e\u003cspan address=\"10.1038/d41586-022-03210-9\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. Accessed 23 Jan 2024.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMorris KC, Schlenoff C, Srinivasan V. A Remarkable Resurgence of Artificial Intelligence and its Impact on Automation and Autonomy. IEEE Trans Autom Sci Eng. 2017;14(2):407\u0026ndash;9. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/TASE.2016.2640778\u003c/span\u003e\u003cspan address=\"10.1109/TASE.2016.2640778\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eToosi A, Bottino AG, Saboury B, et al. A Brief History of AI: How to Prevent Another Winter (A Critical Review). PET Clin. 2021;16(4):449\u0026ndash;69. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1016/j.cpet.2021.07.001\u003c/span\u003e\u003cspan address=\"10.1016/j.cpet.2021.07.001\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSchmidhuber J. Annotated History of Modern AI and Deep Learning. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://arxiv.org/pdf/2212.11279.pdf\u003c/span\u003e\u003cspan address=\"https://arxiv.org/pdf/2212.11279.pdf\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. Accessed 23 Jan 2024.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBohr A, Memarzadeh K. The rise of artificial intelligence in healthcare applications. Artif Intell Healthc. 2020;25\u0026ndash;60. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1016/B978-0-12-818438-7.00002-2\u003c/span\u003e\u003cspan address=\"10.1016/B978-0-12-818438-7.00002-2\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKaul V, Enslin S, Gross SA. History of artificial intelligence in medicine. Gastrointest Endosc. 2020;92(4):807\u0026ndash;12. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1016/j.gie.2020.06.040\u003c/span\u003e\u003cspan address=\"10.1016/j.gie.2020.06.040\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eWaymel Q, Badr S, Demondion X, et al. Impact of the rise of artificial intelligence in radiology: What do radiologists think? Diagn Interv Imaging. 2019;100(6):327\u0026ndash;36. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1016/j.diii.2019.03.015\u003c/span\u003e\u003cspan address=\"10.1016/j.diii.2019.03.015\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKoulaouzidis G, Jadczyk T, Iakovidis DK, et al. Artificial Intelligence in Cardiology-A Narrative Review of Current Status. J Clin Med. 2022;11(13):3910. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.3390/jcm11133910\u003c/span\u003e\u003cspan address=\"10.3390/jcm11133910\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eOmiye JA, Gui H, Daneshjou R, et al. Principles, applications, and future of artificial intelligence in dermatology. Front Med. 2023;10. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.3389/fmed.2023.1278232\u003c/span\u003e\u003cspan address=\"10.3389/fmed.2023.1278232\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCui M, Zhang DY. Artificial intelligence and computational pathology. Lab Invest. 2021;101(4):412\u0026ndash;22. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1038/s41374-020-00514-0\u003c/span\u003e\u003cspan address=\"10.1038/s41374-020-00514-0\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eBusnatu Ș, Niculescu AG, Bolocan A, et al. Clinical Applications of Artificial Intelligence-An Updated Overview. J Clin Med. 2022;11(8):2265. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.3390/jcm11082265\u003c/span\u003e\u003cspan address=\"10.3390/jcm11082265\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKlumpp M, Hintze M, Immonen M, et al. Artificial Intelligence for Hospital Health Care: Application Cases and Answers to Challenges in European Hospitals. Healthc (Basel). 2021;9(8):961. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.3390/healthcare9080961\u003c/span\u003e\u003cspan address=\"10.3390/healthcare9080961\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eDavenport T, Kalakota R. The potential for artificial intelligence in healthcare. Future Healthc J. 2019;6(2):94\u0026ndash;8. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.7861/futurehosp.6-2-94\u003c/span\u003e\u003cspan address=\"10.7861/futurehosp.6-2-94\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eGruendner J, Schwachhofer T, Sippl P et al. KETOS: Clinical decision support and machine learning as a service - A training and deployment platform based on Docker, OMOP-CDM, and FHIR Web Services [published correction appears in PLoS One. 2019;14(11):e0225442]. PLoS One. 2019;14(10):e0223010. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1371/journal.pone.0223010\u003c/span\u003e\u003cspan address=\"10.1371/journal.pone.0223010\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eScherer J, Nolden M, Kleesiek J, et al. Joint Imaging Platform for Federated Clinical Data Analytics. JCO Clin Cancer Inf. 2020;4:1027\u0026ndash;38. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1200/CCI.20.00045\u003c/span\u003e\u003cspan address=\"10.1200/CCI.20.00045\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eLeiner T, Bennink E, Mol CP, et al. Bringing AI to the clinic: blueprint for a vendor-neutral AI deployment infrastructure. Insights Imaging. 2021;12(1):11. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1186/s13244-020-00931-1\u003c/span\u003e\u003cspan address=\"10.1186/s13244-020-00931-1\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eEvans RS. Electronic Health Records: Then, Now, and in the Future. Yearb Med Inform. 2016;25(01):S48\u0026ndash;61. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.15265/IYS-2016-s006\u003c/span\u003e\u003cspan address=\"10.15265/IYS-2016-s006\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSchreiweis B, Ammon D, Sedlmayr M et al. the data integration centre - a hub for health data a hub for health data from patient care and from patient care and medical research medical research. gesundheit.de. 13th issue. Berlin; 2021. p. 84\u0026ndash;87.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHaarbrandt B, Schreiweis B, Rey S, et al. HiGHmed - An Open Platform Approach to Enhance Care and Research across Institutional Boundaries. Methods Inf Med. 2018;57(01):e66\u0026ndash;81. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.3414/ME18-02-0002\u003c/span\u003e\u003cspan address=\"10.3414/ME18-02-0002\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHealthIT.gov. What are the differences between electronic medical records, electronic health records, and personal health records? | HealthIT.gov [Internet]. Healthit.gov. 2019. Available from: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.healthit.gov/faq/what-are-differences-between-electronic-medical-records-electronic-health-records-and-personal\u003c/span\u003e\u003cspan address=\"https://www.healthit.gov/faq/what-are-differences-between-electronic-medical-records-electronic-health-records-and-personal\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. Accessed 24 Feb 2024.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eArenson RL, Andriole KP, Avrin DE, Gould RG. Computers in imaging and health care: now and in the future. J Digit Imaging. 2000;13(4):146. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1007/BF03168389\u003c/span\u003e\u003cspan address=\"10.1007/BF03168389\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eFischer S, Leucker M, L\u0026uuml;th C, et al. KI-SIGS: Artificial Intelligence for the Northern German Health Ecosystem. Digitale Welt. 2020;4(1):49\u0026ndash;54. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1007/s42354-019-0232-5\u003c/span\u003e\u003cspan address=\"10.1007/s42354-019-0232-5\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMandel C, Stich K, Autexier S, et al. Using Gated Recurrent Unit Networks for the Prediction of Hemodynamic and Pulmonary Decompensation. Annu Int Conf IEEE Eng Med Biol Soc. 2022;2022:4584\u0026ndash;89. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/EMBC48229.2022.9871500\u003c/span\u003e\u003cspan address=\"10.1109/EMBC48229.2022.9871500\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eSantarossa M, Tatli A, von der Burchard C, et al. Chronological Registration of OCT and Autofluorescence Findings in CSCR: Two Distinct Patterns in Disease Course. Diagnostics. 2022;12(8):1780. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.3390/diagnostics12081780\u003c/span\u003e\u003cspan address=\"10.3390/diagnostics12081780\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eOates BJ, London. SAGE; 2006. 186\u0026ndash;88.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eRupp C, SOPHISTen D. Requirements\u0026ndash;Engineering and \u0026ndash;Management. 6th edition. Munich:Carl Hanser Verlag, 2014. p. 14.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eAmershi S, Begel A, Bird C et al. Software Engineering for Machine Learning: A Case Study. 2019 IEEE/ACM 41st International Conference on Software Engineering: Software Engineering in Practice (ICSE-SEIP). p. 291\u0026ndash;300. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/ICSE-SEIP.2019.00042\u003c/span\u003e\u003cspan address=\"10.1109/ICSE-SEIP.2019.00042\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eLu C, Strout J, Gauriau R et al. An Overview and Case Study of the Clinical AI Model Development Life Cycle for Healthcare Systems. ArXiv, abs/2003.07678.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eKinast B, Ulrich H, Bergh B, et al. Functional Requirements for Medical Data Integration into Knowledge Management Environments: Requirements Elicitation Approach Based on Systematic Literature Analysis. J Med Internet Res. 2023;25:e41344. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.2196/41344\u003c/span\u003e\u003cspan address=\"10.2196/41344\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eVenable J, Pries-Heje J, Baskerville R. FEDS: a Framework for Evaluation in Design Science Research. Eur J Inform Syst. 2016;25(1):77\u0026ndash;89. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1057/ejis.2014.36\u003c/span\u003e\u003cspan address=\"10.1057/ejis.2014.36\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003evom Brocke J, Hevner A, Maedche A. Introduction to Design Science Research. Progress in IS. Published online 2020:1\u0026ndash;13. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1007/978-3-030-46781-4_1\u003c/span\u003e\u003cspan address=\"10.1007/978-3-030-46781-4_1\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eGerdes H, Mairh\u0026ouml;fer D, Laufer M, et al. Automated quality assessment of radiographs of the upper ankle joint using artificial intelligence. R\u0026ouml;Fo Published online August. 2022;1. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1055/s-0042-1749773\u003c/span\u003e\u003cspan address=\"10.1055/s-0042-1749773\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eMairh\u0026ouml;fer D, Laufer M, Simon PM et al. An AI-based Framework for Diagnostic Quality Assessment of Ankle Radiographs. proceedings.mlr.press. Published August 25, 2021. Accessed November 21, 2023. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://proceedings.mlr.press/v143/mairhofer21a.html\u003c/span\u003e\u003cspan address=\"https://proceedings.mlr.press/v143/mairhofer21a.html\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eStreet WN, Wolberg WH, Mangasarian OL. Nuclear feature extraction for breast tumor diagnosis. Acharya RS, Goldgof DB, eds. Biomedical Image Processing and Biomedical Visualization. Published online July 29, 1993. \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://doi.org/10.1117/12.148698\u003c/span\u003e\u003cspan address=\"10.1117/12.148698\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eHazra R, Banerjee M, Badia L. Machine Learning for Breast Cancer Classification With ANN and Decision Tree, 2020 11th IEEE Annual Information Technology, Electronics and Mobile Communication Conference (IEMCON), Vancouver, BC, Canada, 2020, pp. 0522\u0026ndash;0527, \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e10.1109/IEMCON51383.2020.9284936\u003c/span\u003e\u003cspan address=\"10.1109/IEMCON51383.2020.9284936\" targettype=\"DOI\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e.\u003c/span\u003e\u003c/li\u003e \u003cli\u003e\u003cspan\u003eCouncil E. EU Medical Device Regulation- Regulation (EU) 2017/745 of the European Parliament and of the Council. 2023.\u003c/span\u003e\u003c/li\u003e\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":true,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"bmc-medical-informatics-and-decision-making","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"midm","sideBox":"Learn more about [BMC Medical Informatics and Decision Making](http://bmcmedinformdecismak.biomedcentral.com/)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/midm/default.aspx","title":"BMC Medical Informatics and Decision Making","twitterHandle":"BMC_series","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"em","reportingPortfolio":"BMC Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"artificial intelligence, machine learning, AI platform, healthcare, BPMN, process diagrams, clinical IT, Medical Data Integration Center","lastPublishedDoi":"10.21203/rs.3.rs-4004492/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-4004492/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003e\u003cstrong\u003eBackground: \u003c/strong\u003eThere has been a resurgence of Artificial Intelligence (AI) on a global scale in recent times, resulting in the development of cutting-edge AI solutions within hospitals. However, this has also led to the creation of isolated AI solutions that are not integrated into clinical IT. To tackle this issue, a clinical Artificial Intelligence (AI) platform that handles the entire development cycle of clinical AI models and is integrated into clinical IT is required.\u003c/p\u003e\n\u003cp\u003eThis research investigates the integration of a clinical AI platform into the clinical IT infrastructure. This is demonstrated by outlining the stages of the AI model development cycle within the clinical IT infrastructure, illustrating the interaction between different IT system landscapes within the hospital with BPMN diagrams.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMethods:\u003c/strong\u003e Initially, a thorough analysis of the requirements is conducted to refine the necessary aspects of the clinical AI platform with consideration of the individual aspects of clinical IT. Subsequently, processes representing the entire development cycle of an AI model are identified. To facilitate the architecture of the AI platform, BPMN diagrams of all the identified processes are created. Clinical use cases are used to evaluate the processes using the FEDS framework.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eResults: \u003c/strong\u003eOur BPMN process diagrams cover the entire development cycle of a clinical AI model within the clinical IT. The processes involved are Data Selection, Data Annotation, On-site Training/Testing, and Inference, with distinctions between (Semi-Automated) Batch Inference and Real-Time Inference. Three clinical use cases were assessed to evaluate the processes and demonstrate that this approach covers a wide range of clinical AI use cases.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eConclusions: \u003c/strong\u003eThe evaluations were executed successfully, which indicate the comprehensive nature of our approach. The results have shown that different clinical AI use cases are covered by the BPMN diagrams. Our clinical AI platform is ideally suited for the local development of AI models within clinical IT. This approach provides a basis for further developments, e.g. enabling the training and deployment of an AI model across multiple sites or the integration of security- and privacy-related aspects.\u003c/p\u003e","manuscriptTitle":"Integrating an AI Platform into Clinical IT: BPMN Processes for Clinical AI Model Development","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2024-03-21 16:03:26","doi":"10.21203/rs.3.rs-4004492/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"decision","content":"Revision requested","date":"2024-09-06T08:22:39+00:00","index":"","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2024-07-08T18:10:37+00:00","index":"hide","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2024-06-10T12:02:11+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"226641570706378000091357393807864537417","date":"2024-05-31T07:14:08+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"37128759290801734215816507161447802595","date":"2024-05-29T06:17:00+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2024-05-27T05:38:50+00:00","index":"","fulltext":""},{"type":"editorInvited","content":"","date":"2024-03-18T06:20:54+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2024-03-18T06:18:39+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2024-03-18T06:18:39+00:00","index":"","fulltext":""},{"type":"submitted","content":"BMC Medical Informatics and Decision Making","date":"2024-03-01T20:17:42+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"bmc-medical-informatics-and-decision-making","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"midm","sideBox":"Learn more about [BMC Medical Informatics and Decision Making](http://bmcmedinformdecismak.biomedcentral.com/)","snPcode":"","submissionUrl":"https://www.editorialmanager.com/midm/default.aspx","title":"BMC Medical Informatics and Decision Making","twitterHandle":"BMC_series","acdcEnabled":true,"dfaEnabled":false,"editorialSystem":"em","reportingPortfolio":"BMC Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"80288669-d217-46de-87ef-27d9555d20b6","owner":[],"postedDate":"March 21st, 2024","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"published-in-journal","subjectAreas":[],"tags":[],"updatedAt":"2025-07-07T16:03:31+00:00","versionOfRecord":{"articleIdentity":"rs-4004492","link":"https://doi.org/10.1186/s12911-025-03087-4","journal":{"identity":"bmc-medical-informatics-and-decision-making","isVorOnly":false,"title":"BMC Medical Informatics and Decision Making"},"publishedOn":"2025-07-02 15:57:43","publishedOnDateReadable":"July 2nd, 2025"},"versionCreatedAt":"2024-03-21 16:03:26","video":"","vorDoi":"10.1186/s12911-025-03087-4","vorDoiUrl":"https://doi.org/10.1186/s12911-025-03087-4","workflowStages":[]},"version":"v1","identity":"rs-4004492","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-4004492","identity":"rs-4004492","version":["v1"]},"buildId":"qtupq5eGEP_6zYnWcrvyt","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}