NODE-RED Microservice Bedside System for Outcome Prediction of Patients with Suspected SEPSIS: Useful Study for the Coronavirus Outbreak and Beyond (Stage 1 of the Work)

This is a stage 1 of our ongoing research to build bedside machine learning predictors to identify septic shocks at early stages


INTRODUCTION
Sepsis is a major health crisis all over the world and one of the leading causes of death resulting as many as 5.3 million deaths per year globally [1].Despite the high incidence of sepsis and the professional critical care society's work in defining the clinical criteria that aid sepsis recognition, the fundamental need for early detection and treatment remains unmet [2].However, sepsis prediction is a difficult task as sepsis can be triggered by a variety of pathogen caused by variety of infections including viruses, bacteria, fungi or parasites as well as it is sensitive to many other factors like acute illness, underlying chronic diseases, and complications associated with infection.
Adjusting for these factors is essential for evaluation of new therapies.The purpose of the present study is to determine variables readily identifiable at the bedside that predict the outcome of patients in intensive care unit (ICU) with sepsis.Identifying those at risk for sepsis and initiating appropriate treatment, prior to any clinical manifestations, would have a significant impact on the overall mortality and cost burden of sepsis [3].Some medical researchers consider sepsis to have three stages.The first stage is the least severe and usually has symptoms of fever and an increased heart rate.The second stage is more severe and is characterized by symptoms of difficulty breathing and possible organ malfunctions, while the third is the most severe stage (septic shock or severe sepsis) with life-threatening low blood pressure.However, not all researchers agree with these stages.
Development of machine learning algorithms to predict severe sepsis and septic shock and evaluate the impact on clinical practice and patient outcomes are among the most important priorities of several researchers agenda [4,5].However, the current machine learning models aiming to predict sepsis from electronic health records (EHR) or datasets do not accurately predicts sepsis due to the heterogeneity of the sepsis conditions despite the emerging importance of machine learning in prognosis and treatment [6].However, looking at a recent systematic review performed in PubMed, Embase.com and Scopus on studies that uses retrospective sepsis data, individual machine learning models have shown the ability to accurately predict sepsis onset ahead of time [7].However, these models have not shown wider acceptance and remains as an alternative to traditional bedside sepsis scoring systems.According to [8], there is no clinically validated system exists for real-time prediction of sepsis onset especially those that can work at bedside.According to seminal article published at BMJ by Seneviratne [9] recently, very few of the machine learning algorithms ever make it to the bedside; and even the most technology-literate academic medical centers are not routinely using AI in clinical workflows.Commonly, however, at the emergency (IUC) departments they use pen and paper to a large extent when recording emergency care procedures and measurements.During treatment the patient is the main focus and because of this, recording of measurements done could be delayed or in worst case forgotten during stressful situations.The new face of healthcare needs to be defined by a confluence between technical complexity and the healthcare system workflow fabric in which the technical complexity is embedded [10].This new face should include an ecosystem that involve pragmatic interoperability that focus on workflows and their integration [11].The goal of this paper is to derive a classification to sepsis that can work at the bedside and be integrated with the dynamics of the clinical workflow of IUC departments using prospective datasets.

Emergency Department (Bedside) Ecosystem Care Planning
There are many demands placed on staff working in emergency departments such as the currently witnessed coronavirus outbreak, overcrowding, bed shortages and long waiting times for patients.Despite these demands clinical care needs to be carefully assessed, planned and documented [12].Although the emerging technologies provided variety of medical sensors to enable most of the work to be passive, still we need some active role to assess new cases and select the relevant care plan.The interoperability of between what is passive and what is active is another challenging issue that need to be solved.Among successful models that can enforce such interoperability is the goal that could be achieved by different approaches and among them the federated the Joint Directorate Laboratories (JDL) model which was researched in 1993 to deal with multilevel data fusion interoperability and integration, primarily was for military systems [13].The idea was that you could look at the state of the world considering different entities as "atomic units" of your "World View".Level 1 Fusion, for example, was called "Object Refinement" and was focused on fusing multiple heterogeneous data sources to obtain information about individual objects (e.g., people, vehicles, buildings, etc.).So-called Higher-Level Fusion dealt with Levels 2-4, which were named "Situation Refinement", "Threat Refinement", and "Process Refinement".Note, there is a big conceptual jump from Level 1 to Level 2. Level 1 consists of real, measurable objects that exist in time and space.The other levels are concepts and exist in "linguistic space" instead of physical space.In 1998, the JDL model was upgraded to more general, less militaristic language.There was also a "Level 0" added.So the levels now were "Sub-Object Assessment", "Object Assessment", "Situational Assessment", "Impact Assessment", and "Process Refinement".Sub-Object Assessment referred to using data to resolve things smaller than individual objects.So it could be an arm, or it could refer to integrating ("fusing") consecutive reflected pulses from a radar to form a signal [14].In 2015, a researcher [15], extended the four levels JDL model into five level one where Level 5: "User Refinement" involves humans to be "in the loop" affecting the products of all the lower levels.
However, the increasing amount of information available for business planning motivates the adoption of machine learning methods for addressing specific situation assessment or risk.A special focus needs to be placed on prognosis, namely, the capability to estimate and anticipate events of interest regarding assets and production processes.There lies indeed at the core challenge of business modeling and planning from a data science perspective: data-driven prognostic approaches aim at predicting when an abnormal behavior is likely to arise within the monitored process, providing further insights such as its severity and impact on the business performance.For this reason, it becomes particularly interesting to characterize normality properly towards unveiling degradation patterns or trends.Thus, adding a sixth level to JDL to include learning analytics response is one of the most important direction for business modeling and planning.The idea of having the sixth level (L6.2) is to characterize the business values (including user care values and workflows) through qualitative measures (aka sound care plans) as well as to identify behavioral patterns of interest on the basis of the data monitored from the application process by means of quantitative analytics and machine learning models.This acquired knowledge (valued and thick data as well as quantitative indicators) can be then used to tackle a wide variety of planning problems, including focused prediction, classification and anomaly detection, among others.Furthermore, since data and services are the most important asset that a business owns, and in today's climate of data security and stewardship it's more important than ever to trace how that data was produced and the journey it has undertaken through the workflow of services leading to its present state.What we need in this direction is a strong data and services governance platform.This platform represents another architectural layer (L6.1) to the JDL model where the layout of the system is developed as a suite of workflows of small services, each running in its own process and communicating with lightweight mechanisms using a special workflow server.The benefits of level 6.1 are many, ranging from an increase in development productivity, to better business-IT alignment, agility, scalability, and technology flexibility.Figure 1 illustrates our overall bedside care planning framework (BCP) that can be used for predicting outcomes of several of the frequent emergency department cases as defined by the chief complaints [16] to be the grouped into 11 categories: respiratory, gastrointestinal (GI), undifferentiated infection (UDI), influenza-like illness (ILI), lymphatic, skin, neurological, pain, dental, alcohol and musculoskeletal syndromes.These categories were used by other healthcare surveillance programs with slight modification.Chief complaints that could not be grouped into the above 11 syndromes should assigned to "unclassified".However, BCP defines the infrastructural layer (upper layer) of our architecture.The lower layer that deals with actual business implementation, this is the workflow DSL and the corresponding step implementations.The workflow layer is essentially a highly abstracted version of the decode -> handle -> interpret pipeline which defines the different microservices of the applications workflows.This architecture is inspired by the Helland's design [17].The workflow server takes this pipeline and separates concerns even further by drawing service boundaries between each of these operations  Workflow Triggers (decode) The execution pattern of a microservice application at the workflow server can be described as a time sequence of Web service invocations.Each web service is categorized into either a trigger or an action in WoT architecture [18].A trigger is either a publication of some information or a signal that an action (actuation) took place.An action is a task to be executed whenever a trigger is fired.In this approach, instead of producing Apps as a complete runtime artifact, developers can design intermediary artifacts, as accessible controls parts for typical transportation tasks.Using these controls, transporters are enabled to construct their own tasks autonomously by using resources of their own choice from across the WoT.The microservice based transportation system translates the time sequence of trigger and action executions to a time sequence of network flows.A network flow is a traffic information between two communicating endpoints.Zapier and IFTTT or many other alternatives makes this task easy.It lets transporters to integrate everyday apps (e.g.existing legacy app or a newly created workflow) and automate the transportation business processes.Figure 2 illustrates the idea behind using WoT Microservice platform.WoT platforms like IFTTT or Zapier, however, may represent decent workflow composition tool to get started on simple point-to-point integrations but what should you do when you want to tackle higher complexity that often arises when we are dealing with healthcare workflows?Fast-growing healthcare enterprises need to incorporate higher level frameworks to accommodate the various complex scenarios.In this direction we are experimenting with more sophisticated workflow wrappers like the Node-RED.With Node-Red, healthcare workers can produce fully customizable workflows with flexible connector operators such as loops, data storage, array mapping, branching, and if/then conditionals and many more.Node-RED2 is a programming tool used for wiring together hardware devices, APIs, functions and online services by representing them as nodes.
One can use his mobile device to hook to such services via creating a bucket through webhook relay 3 and installing node-red on the mobile phone (e.g.Android4 ). Figure 3 illustrates our overall microservice to classify new cases arriving at an emergency department as SEPSIS or not.All what we need after we define our workflow is to define the important functions that contributes to this microserviceSince the task of this paper is find best predictors for SEPSIS, we decided to use Python as our Node-Red functions programming.For this we will need to add a Python function node tour Node-Red dashboard.For this we will need to add a Python shell through the executing the following command: npm install node-red-contrib-pythonshell Figure 4   The overall architecture of our bedside predictive system based on the notion of Node-Red microservices can be represented in Figure 5.

Preparing for Developing Effective Predictors for SEPIS and SEPSIS Shocks:
Building effective predictors requires the availability of relevant datasets.In this direction, there are good number of SEPSIS datasets and machine learning classification models that can help in mission to build such models and incorporates them at our Node-Red bedside visual environment.Table 1 lists some of the notable SEPSIS datasets that we can use in stage 2 of this research.However, the roadmap for identifying the best sepsis predictors and integrating them with the Node-Red visual environment is described in Figure 6.

Conclusions
The incorporation of machine learning into clinical medicine holds promise for substantially improving healthcare delivery.With the use of bedside visual tools that incorporates machine learning has the potential to improve patient and caregiver Satisfaction..This stage 1 of the research illustrate how Node-Red and the notion of the visual workflow microservices can be imployed to integrate predictors for critical cases like the Septic Shocks.This research is an ongoing work in progress to develop innovative healthcare ecosystem that can work at the bedside.

Figure 2 :
Figure 2: The layout of Node-Red Microservice.Using the IFTTT platform, the "IF THIS" keyword is used to identify the triggers and "THEN THAT" is used to identify the execution and interpretation part.The trigger is activated by changes that occur within other web services such as Fitbit.Upon activation you may assign an action like pushing a notification to your iOS Health app:

Figure 3 :
Figure 3: Node-Red Microservice Workflow for Classifying New Cases for SEPSIS.All what we need after we define our workflow is to define the important functions that contributes to this microserviceSince the task of this paper is find best predictors for SEPSIS, we decided to use Python as our Node-Red functions programming.For this we will need to add a Python function node tour Node-Red dashboard.For this we will need to add a Python shell through the executing the following command:npm install node-red-contrib-pythonshell Figure4illustrate an example of the python function for reading one SEPSIS training data from the PhysioNet link.
Figure 3: Node-Red Microservice Workflow for Classifying New Cases for SEPSIS.All what we need after we define our workflow is to define the important functions that contributes to this microserviceSince the task of this paper is find best predictors for SEPSIS, we decided to use Python as our Node-Red functions programming.For this we will need to add a Python function node tour Node-Red dashboard.For this we will need to add a Python shell through the executing the following command:npm install node-red-contrib-pythonshell Figure4illustrate an example of the python function for reading one SEPSIS training data from the PhysioNet link.

Figure 4 :
Figure 4: A Python Function in Node-Red for Extracting Zipped Data.

Figure 6 :
Figure 6: Roadmap for Integrating Best Sepsis Predictors at the Node-Red Environment.

Table 1 :
List of Notable SEPSIS Datasets.However, for building a robust predictors we are suggesting to start training the various likely predictors on the PhysioNet 2019 challenge on Sepsis dataset as it is the most recent and comprehensive data extracted from patients at the bedside which include 1361672 patients' records with 41 attributes.Table 2 lists the PhysioNet Sepis dataset attributes.