Patient triaging methods

Abstract

A computer-implemented method and associated computer-readable program code to support triaging a patient. The method comprises: receiving an input comprising patient data; processing the input in an encoder to generate an encoded state comprising a plurality of triage levels; supplying at least the encoded state and at least a subset of the input to a decoder; and processing the encoded state in the decoder to generate an output comprising contributing factors, thereby providing a human-understandable explanation of which patient data are contributing to a medical issue the patient is experiencing.

Description

[0001] Applicant: BIOTRONIK SE & Co. KG

[0002] Our Reference: 24.095P-WO

[0003] Date: 18.11.2025

[0004] PATIENT TRIAGING METHODS

[0005] The invention relates to computer-automated methods for patient triaging and computer program products bearing computer-readable program code for implementing the methods.

[0006] Triage is the method by which a patient is assessed based on available data to determine the urgency with which the patient’s medical issue should be dealt with and the severity of that medical issue. Available data that is used may include answers obtained from a question-and-answer session with the patient who has presented, identification of the patient's symptoms, and, if possible, reference to the patient record (i.e., medical history).

[0007] A typical triaging method is based on an on-site or an on-line interaction between a medical staff member and a patient that is initiated by the patient as a result of the patient experiencing a medical issue. Systematic triage methods, as used in a hospital emergency department, assign a patient to one of a plurality of discrete triage levels, which range from a level indicating that the patient has no identifiable medical need ("no issue") to a level indicating danger to life if no action is taken immediately ("urgent, life-threatening issue") with several intermediate levels in between that take account of severity and urgency.

[0008] After triage, the patient waits in a queue with a priority based on the determined triage level before being seen by a clinician or other medical staff member who conducts a more detailed examination of the patient for diagnosis and treatment.

[0009] Triaging enables efficient workload distribution by prioritizing patients who need to be treated urgently while deferring giving medical attention to patients with non-urgent and non-severe issues. Errors in triaging can cause various problems. Inaccurate assessment of the severity or urgency has an immediate consequence of inefficiency, i.e., the error must be identified, and the triage process repeated. Worse is failure to recognize urgency which can result in the medical issue deteriorating while the patient is waiting, causing unnecessary risk and danger to the patient as well as inefficiency in the treatment.

[0010] Triaging is not only applied by medical staff during interaction with a patient but is also applied by technicians for remote patient monitoring. In this scenario, medical devices such as implanted medical devices or wearable health-monitoring devices, supply a stream of patient data to a data center and trained technicians, who have access to the data center, monitor and assess the patient data of a patient cohort on an ongoing basis. An example of such remote patient monitoring is in spinal cord stimulation (SCS) in which an SCS device is implanted in a patient and stimulates the patient with electrical pulses via an implantable pulse generator (IPG).

[0011] The triaging performed in the context of remote patient monitoring involves a manual review of incoming patient data collected at the data center. Technicians are triggered to triage a particular patient by an alert which occurs whenever a data parameter, or combination thereof, contained in the patient data meets an alert criterion, for example exceeds a pre-set threshold. These alert criteria, for example parameter value thresholds, are typically defined during initial set-up of the patient with the medical device, e.g., shortly after implantation before the patient is discharged from hospital. A monitoring platform hosted at the data center automatically monitors the incoming patient data and raises an alert whenever an alert criterion is met. The alert then triggers a technician to perform a manual review of the patient condition, i.e., to undertake triaging, and on that basis decide upon an appropriate intervention. In performing the triaging, the technician determines which patients have a high probability of having a medical issue which needs to be resolved. The basis for their selection will also take account of any historical data for the patient which they have access to, i.e., the patient’s medical record.

[0012] A drawback of the current semi-manual process of automatically screening incoming patient data to determine if any alert criteria are met followed by manual triaging by a technician is that it is labor intensive and is subject to human errors.

[0013] 24.095P-WO / 18.11.2025 US2019139648A1 discloses a computer-implemented method for patient triaging based on a computer program. The computer program conducts a question-and-answer session with the patient to obtain information on patient symptoms. The computer program then generates a report based on the question-and-answer session which makes a diagnosis and a triage recommendation for the patient based on the diagnosed condition. The triaged recommendation instructs the patient to perform one of the following acts: review existing information in a medical knowledge database; ask a question to a network of healthcare professionals; initiate a text-based electronic message communication with a healthcare professional; initiate a video chat communication with the healthcare professional; seek advice of a referral healthcare professional; and seek emergency medical care. Conceptually, this computer program is therefore a communication platform which has communication between the patient and the computer program as a first phase and then provides for text or video communication between a patient and a clinician in a second phase. This known patient triaging method is not applicable to the remote patient monitoring scenario described above but rather replicates classic on-site triaging between medical staff and patient as performed in hospital emergency departments.

[0014] According to one aspect of the disclosure there is provided a computer program product to support triaging a patient, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code configured to:

[0015] receive input comprising patient data;

[0016] process the input in an encoder to generate an encoded state comprising a plurality of triage levels;

[0017] supply at least the encoded state and at least a subset of the input to a decoder; and process the encoded state in the decoder to generate an output comprising contributing factors.

[0018] According to a further aspect of the disclosure there is provided a computer-implemented method to support triaging a patient, comprising:

[0019] receiving input comprising patient data;

[0020] processing the input in an encoder to generate and output an encoded state comprising a plurality of triage levels;

[0021] 24.095P-WO / 18.11.2025 supplying at least the encoded state and at least a subset of the input to a decoder; and

[0022] processing the encoded state in the decoder to generate an output comprising contributing factors.

[0023] Patient data as referred to in the present document includes both data provided by the patient themselves, such as reported pain, mood, perception of wellbeing etc., referred to in the following as patient reported data, as well as data provided by devices associated with the patient such as implanted or worn medical devices, referred to in the following as patient device data. Patient device data is a rich source of information outside patient reported data, the latter being the focus of traditional triaging and the former the focus of the present invention.

[0024] Patient device data can be monitored continuously in real-time, even without any patient reported data, for example at a data center which receives patient device data from a large cohort of patients from their respective medical devices. The communication of the patent data can take place via mobile devices, telecommunications infrastructure and distributed data storage networks ("the cloud"), which communications and data storage infrastructure is collectively labeled a Medical Device Communication System (MDCS). Patients can then be actively triaged based on the patient device data without any human-to-human interaction with the patient, thereby enabling medical issues to be identified, whether they be a direct health issue for the patient, such as heart arrhythmia or diabetic shock, or an issue with a patient device, such as a fault with a medical device or a recognition of suboptimal usage of the medical device by the patient, such as poor charging practice of an implanted medical device that relies on a rechargeable battery.

[0025] The encoder transforms patient data to encoded states representing the triage levels, and the decoder transforms the encoded states back to explainable output defined in the input domain, referred to as contributing factors, thereby providing a human-understandable explanation of which patient data (i.e., input factors) are contributing to the issue the patient is experiencing.

[0026] 24.095P-WO / 18.11.2025 The encoder-decoder architecture enables the input to be transformed by the encoder into encoded states, which represent the patient status, for use by the decoder, in combination with decoder explainable output that is in a form that points back to the most probable contributor, the contributing factors. In one example, the encoder transforms patient and device data to encoded states representing triage classes, wherein the triage classes being chosen to represent severity and urgency of the patient issue, and the decoder transforms the triage classes back to the physical domain to provide an output that express in an explainable way the most likely factors that are contributing to the patient’s medical issue.

[0027] In certain embodiments, the decoder includes an explainable Al (xAI) algorithm. The xAI algorithm may be used to obtain triage levels and issue assessment that are presented in the same physically interpretable domain as the input. xAI is an artificial intelligence approach to describe an Al model’s purpose, rationale and decision-making process in a way that a human user can understand. The use of xAI thus helps human users understand what has happened inside complex machine learning (ML) algorithms, e.g., as embedded in the encoder, and this increases human trust in the outputs of the encoder. An xAI algorithm provides human-understandable insights by decomposing the model outputs to the input contributions to reveal important factors such as:

[0028] • The encoder model’s strengths and weaknesses.

[0029] • The specific criteria the encoder model has used to arrive at its decisions, i.e., its outputs.

[0030] • Why an encoder model has made a particular decision as opposed to other possible decisions.

[0031] • The degree to which the decisions can be trusted as being accurate.

[0032] • The types of errors to which the encoder model is prone.

[0033] • How errors can be corrected

[0034] In certain embodiments, the encoder-decoder architecture is applied with the decoder incorporating an xAI algorithm in order to improve triage case interpretation by a human recipient of the outputs of the encoder-decoder architecture, the outputs being the triage levels provided by the encoder and the contributing factors provided by the decoder through

[0035] 24.095P-WO / 18.11.2025 the use of xAI. The xAI may employ SHAP (SHapley Additive exPlanations) values as a way to explain the output of the decoder in terms of the physical domain, e.g., to express the output in terms of patient data, patient issue, etc.

[0036] The use of an encoder-decoder architecture permits the advantages of xAI to be gained by incorporating xAI in the decoder. As a stand-alone architecture, xAI is typically too computationally expensive to be used to monitor large volumes of incoming patent data from a large cohort of patients in a real-time basis. A cohort of patients might be all those with a particular kind of implanted device, such as an SCS device, from a particular manufacturer. Incorporating xAI into a decoder in an encoder-decoder architecture can reduce the computing resources needed sufficiently to enable much larger volumes of patient data to be monitored.

[0037] The use of xAI allows a patient alerts portfolio to be generated for each patient according to a personalized healthcare paradigm. It is also possible to generate a patient default alerts portfolio for the general patient population, or a subgroup thereof. The patient alerts portfolio may be specific to a particular device class, such as patients implanted with an implantable device, such as an SCS device or cardiac pulse generator, and / or patients carrying wearable devices for health monitoring (e.g., fitness watch), such as monitoring blood sugar level, heart rate, body temperature, or patient motion.

[0038] In certain embodiments, the decoder further includes a machine learning (ML) algorithm.

[0039] In certain embodiments, the decoder is additionally supplied with at least a subset of the input. In certain embodiments, the decoder is additionally supplied with data from a target domain. The input may be a subset of the target domain, or the input and the target domain may be separate sets with no common data.

[0040] In certain embodiments, the encoded state additionally comprises an inference which is a probability associated with each triage level, the inference being output together with the triage levels.

[0041] 24.095P-WO / 18.11.2025 In certain embodiments, the contributing factors are additionally associated with a predicted probability, and wherein the contributing factors are output as a list ranked by the predicted probability.

[0042] The computer-readable program code may be configured to: supply the input also to a classification model; process the input in the classification model to determine class and inference which are respectively issue type and a probability associated with each issue type; and supply the class and inference as additional input to the decoder.

[0043] The encoder-decoder architecture may, for example, be adapted from a Large Language Model (LLM).

[0044] The proposed method can provide for a more uniform detection, diagnosis and response process, as it does not depend upon manual assessment by a technician to create a diagnosis, which is an inherently subjective process that will produce variance in diagnosis from technician to technician. Further enhanced accuracy follows from the use of expert input to create the relationship between measured data and diagnosis.

[0045] The proposed method being automated rather than reliant on manual assessment by a technician is therefore inherently quicker. The latency inherent in a manual detection and diagnosis process is removed, since the expert system approach provided by the proposed method outputs effectively instantaneous guidance in real-time as to what intervention is recommended for any specific patient under any specific set of conditions. Real-time detection and intervention is particularly valuable for high triage levels where urgent intervention is needed. Real-time recordkeeping of encoded and decoded outputs is also possible.

[0046] The proposed method is automatic, low-latency and proactive. It can be applied to continuously monitor patient status via sensor data, usage data and patient data received from a medical device, such as a device implanted in the patient. It can also provide alerts to a care provider and / or a patient when a medical issue occurs, thereby improving quality of care for the patient.

[0047] 24.095P-WO / 18.11.2025 According to another aspect of the disclosure there is provided a computer program product to support triaging a patient, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code configured to:

[0048] receive input comprising patient data;

[0049] process the input in a classifier machine learning model to generate a class comprising a plurality of criticality levels;

[0050] supply at least the class and at least a subset of the input to an explainable artificial intelligence, xAI, algorithm; and

[0051] process the class in the xAI algorithm to generate an output comprising contributing factors.

[0052] According to a further aspect of the disclosure there is provided a computer-implemented method to support triaging a patient, comprising:

[0053] receiving input comprising patient data;

[0054] processing the input in a classifier machine learning model to generate a class comprising a plurality of criticality levels;

[0055] supplying at least the class and at least a subset of the input to an explainable artificial intelligence, xAI, algorithm; and

[0056] processing the class in the xAI algorithm to generate an output comprising contributing factors.

[0057] This invention will now be further described, by way of example only, with reference to the accompanying drawings.

[0058] Figure 1 is a schematic block diagram of a processing pipeline of a patient triaging method according to a first embodiment.

[0059] Figure 2 is a schematic block diagram of a processing pipeline of a patient triaging method according to a second embodiment.

[0060] 24.095P-WO / 18.11.2025 Figure 3 is a schematic block diagram of a processing pipeline of a patient triaging method according to a third embodiment.

[0061] Figure 4 is a schematic block diagram of a processing pipeline of a patient triaging method according to a fourth embodiment.

[0062] Figure 5 is a schematic block diagram of an example computer program product with encoder-decoder architecture for performing the patient triaging method of any of the first to fourth embodiments.

[0063] Figure 5A is an inset to Figure 5 showing example internal features of the decoder.

[0064] Figure 6 is a graphical representation of example SHAP values (numbers inside the bars) obtained from a decoder incorporating xAI.

[0065] Figure 7 is a block diagram illustrating an example computing apparatus that may be used to run computer-readable program code for implementing the processing pipeline of any of the first to fourth embodiments.

[0066] Figure 8 is a schematic block diagram of a patient triage method with encoder-decoder architecture which has a sequential logic flow analogous to a manual triaging method.

[0067] Figure 9 is a schematic block diagram of a processing pipeline for the patient triage method of Figure 8.

[0068] In the following detailed description, for purposes of explanation and not limitation, specific details are set forth in order to provide a better understanding of the present disclosure. It will be apparent to one skilled in the art that the present disclosure may be practiced in other embodiments that depart from these specific details.

[0069] 24.095P-WO / 18.11.2025 Figure 1 is a schematic block diagram of a processing pipeline of a patient triaging method according to a first embodiment with an encoder-decoder architecture. The encoder-decoder architecture comprises an input 10, an encoder 12 which outputs an encoded state 14, which is supplied as input to a decoder 16, which outputs and output 20. The encoder-decoder architecture provides a sequential model of encoding inputs, specifically patient data, into encoded state, specifically triage levels, followed by decoding the encoded states back to provide output, specifically contributing factors, expressed in terms of the physical input domain. The encoder-decoder architecture permits incorporation of xAI in the decoder (not shown). While the decoder as a whole is a pre-trained model, xAI is not a trained model but rather an algorithm which randomly varies its input variables.

[0070] Figure 2 is a schematic block diagram of a processing pipeline of a patient triaging method according to a second embodiment with an encoder-decoder architecture. The encoderdecoder architecture comprises an input 10, an encoder 12 which outputs an encoded state 14, which is supplied as input to a decoder 16, which outputs and output 20. The decoder 16 is supplied with additional information from the input 10, which may be all the input data or a subset of the input data. Knowledge about the input can provide another important constituent for the decoder, since it provides context for the encoded states to be translated into by the decoder. When the same set of patient data is provided to both inputs and decoder, it is particularly beneficial to employ xAI in the decoder.

[0071] Figure 3 is a schematic block diagram of a processing pipeline of a patient triaging method according to a third embodiment with an encoder-decoder architecture. The encoder-decoder architecture comprises an input 10, a target domain 22, an encoder 12 which outputs an encoded state 14, which is supplied as input to a decoder 16, which outputs and output 20. The decoder 16 is supplied with target domain data from the target domain 22. Target domain data is useful input for the decoder when the encoded states are interpretable outside the input space. The decoder may incorporate with xAI as previously mentioned or another kind of machine learning (ML) model or both. The data contained in the target domain can also be varied depending on the medical skill level of the recipient of the output to increase the comprehension of the recipient. For example, different target domain data can be used to tailor the output of the decoder for maximum intelligibility by the intended human recipient,

[0072] 24.095P-WO / 18.11.2025 e.g., a clinician, a nurse and a person with no medical training such as the patient or their caregiver. The target domain data may also include selected parts, or all, of the patient medical record. The target domain data may also include patient reported data.

[0073] Figure 4 is a schematic block diagram of a processing pipeline of a patient triaging method according to a fourth embodiment with an encoder-decoder architecture. The encoderdecoder architecture comprises an input 10, a target domain 22, an encoder 12 which outputs an encoded state 14, which is supplied as input to a decoder 16, which outputs and output 20. The decoder 16 is supplied with information about the target domain in the case that the input is a subset of the target domain. An example where the input is a subset of the target domain is when a part of the patient data is known to be relevant for interpretation but not diagnosis and is therefore excluded from the input provided to the encoder but is nevertheless relevant for expressing the diagnosis and hence is supplied to the decoder to enhance the explainability of its output.

[0074] An example set of triage levels on a scale 0 through 5 that can represent the encoded state in any of the embodiments of Figures 1 to 4 are as follows:

[0075] • Level 0 - non-issue: there is no issue

[0076] o Example: Patient data does not deviate from the “normal” pattern. For instance, patient’s medical device usage pattern and physiological measurements remain the same as usual.

[0077] • Level 1 - non-urgent: needs attention / intervention when time permits

[0078] o Example: patient occasionally forgets to recharge their implanted device (e.g., SCS device), leading to brief therapy drop-outs, so that the patient would benefit from a discussion with a technician regarding charging experience and methods of identifying a low battery.

[0079] • Level 2 - semi-urgent: not life threatening

[0080] o Example #1: new patient is unable to charge their device (e.g., implanted SCS device) with their charger, so that the patient would benefit from a discussion with a technician regarding how to perform charging.

[0081] 24.095P-WO / 18.11.2025 o Example #2; patient experiences discomfort when adjusting their stimulation level in an SCS device, so that the patient would benefit from a discussion with a technician regarding possible adjustment of stimulation limits.

[0082] • Level 3 - urgent: not life threatening.

[0083] o Example: patient with an implanted SCS device has lost therapy efficacy or developed a new pain area with strong levels of pain, impacting their function and autonomy, so that the patient would benefit from a discussion with a technician potentially leading to a recommendation to make an in-clinic visit.

[0084] • Level 4 - emergency: could become life threatening.

[0085] o Example: patient exhibits physiological signs of an infection and / or reports increasing discomfort (e.g., at the site of an implant such as an implanted SCS device), so that an emergency in-clinic visit is required.

[0086] • Level 5 - urgent: life threatening.

[0087] o Example: patient with an implanted SCS device reports symptoms such as severe electric shocks, severe side effects from therapy, open wound at surgical site, so that an immediate emergency in-clinic visit is required.

[0088] Example patient device data as can be used in any of the embodiments of Figures 1 to 4 are as follows, many of which are specific to SCS:

[0089] • Total percentage of SCS stimulation time

[0090] o Breakdown of the above by stimulation mode (e.g., standard, multiphase) • SCS stimulation amplitude

[0091] • SCS lead impedance

[0092] • SCS lead offset

[0093] • IPG charging coupling and uncoupling events

[0094] • Quantity or frequency of program change

[0095] • Completion of remote data transmission from implanted device

[0096] • Implanted device battery charge status (battery percentage)

[0097] • Therapy usage pattern consistency (based on time-of-day therapy is used)

[0098] • Therapy usage percentage time variability

[0099] • IPG error codes

[0100] 24.095P-WO / 18.11.2025 • Patient body temperature

[0101] • Device-collected and deduced patient biomechanical data

[0102] o patient gait

[0103] o patient posture

[0104] o breakdown by activity type: lying, sitting, standing, walking, running, swimming, cycling, etc.

[0105] It will be understood that patient device data will be supplied as a digital health stream over a Medical Device Communication System (MDCS) to a data center operated by the health care provider.

[0106] Example patient reported data as can be used in any of the embodiments of Figures 1 to 4 are as follows, many of which are subjective indicators reported by the patient:

[0107] • Pain areas

[0108] o Lower back, chest, implant site, joints

[0109] • Pain intensity

[0110] o patient self-assessment on the numerical rating scale for pain (NRS)

[0111] • Sleep disruption

[0112] • Mood

[0113] • SCS perception threshold

[0114] • SCS maximum comfort threshold

[0115] • Patient-reported activity type(s)

[0116] o standing, walking, running, swimming, cycling, etc.

[0117] The NRS for pain is collected by asking a patient to state their pain intensity level on a scale of 0 and 10, where zero represents no pain and ten the worst pain imaginable. According to an embodiment, contributing factors include mood, physiological conditions, changes in sleep and / or activity level, potential inflammation, non-pain-related illnesses, and accidents such as fall or slip.

[0118] 24.095P-WO / 18.11.2025 Figure 5 is a schematic block diagram of an example computer program product with encoder-decoder architecture for performing the patient triaging method of any of the first to fourth embodiments. The input 10, encoder 12 and encoded state 14 are contained within a triage level classification model 30. The decoder 16 and its contributing factors 20 as output are contained within an interpreter model 40. In the triage level classification model 30, the inputs are the patient data, the encoded states are the triage levels, and the encoded states are the triage levels accompanied by an inference, inference being the probability of belonging to each triage level. The decoder 16 forms part of the interpreter model 40 comprising the decoder 16 and its contributing factors 20 as output. The decoder 16 decomposes the encoded states to contributing factors taking account of knowledge of the inputs 10 and / or the target domain (not shown) to provide an interpretation of the encoded states in the physical domain that is understandable to a human. The contributing factors 20 output by the decoder 16 may be output as a ranked list, ranked by probability. An optional issue classification model 32, illustrated with dotted lines, may also be provided. As illustrated, the issue classification model 30 is not in the encoder-decoder pipeline but rather takes a parallel path, receiving the same inputs as the encoder 12, or a subset thereof. The issue classification model 30 processes the inputs with a classification model 34 which outputs class and inference 36, these respectively being issue type and issue type probability. The issue type and issue type probability are then output from the issue classification model 32 and supplied as additional input to the interpreter model 16, specifically to the decoder 16. The fact that the issue classification model 32 is arranged in a parallel processing pipeline to the encoder-decoder pipeline means that parallel computer processing can be used for the two pipelines, thereby increasing computational efficiency which may be important in case of large volumes of data.

[0119] The encoded state can be expressed as:

[0120] state = (s,p) where s ∈ 0,1,...,5 and p ∈ [0,1]

[0121] where

[0122] s is an integer indicator for the triage level, and

[0123] p is the probability.

[0124] The encoder model is based on single classification model of a plurality of multiclass classification models where

[0125] 24.095P-WO / 18.11.2025 p = f(x1,...,xm) and

[0126] s = argmax fk(x1,...,xm)

[0127] ke{0,...,5}

[0128] with m input variables (x).

[0129] Multiple classification models such as logistic regression and ensemble / single decision-tree models can be employed in the encoder. Depending on the dimensionality and the complexity of the input space, neural networks may also be used for classification.

[0130] For training the encoder-decoder model a training dataset is used in which the output labels are obtained from field experts (e.g., care technician, physicians), namely triage level (e.g., 0~5) and issue types for each intervention instance.

[0131] The decoder interprets the triage level within the context of the domain provided. The default domain is as defined by the inputs and optionally also the target domain (Figure 3) or the parts of the target domain that excludes the inputs (Figure 4).

[0132] Figure 5 A is an inset to Figure 5 showing example internal features for the decoder 16. In this example, the decoder comprises xAI 17 in order to calculate SHAP values for each variable and ML model 18, such as a classification or regression model or combined classification and regression model, to decompose the triage level (with inference) into contributing factors. For cases with lower triage levels displaying patterns with frequently occurring contributing factors and known resolution paths, ML models (e.g., classification and / or regression models) can be pre-trained and will provide reliable output in the form of contributing factors with associated predicted probabilities. For example, in the encoder, a regression model may be used to predict triage level in a range between 0 and N, e.g., 0~5 or 0-100. A gate 19 can be provided for selecting computation with either the xAI model 17 or the ML model 18, or in parallel to both the xAI model 17 and the ML model 18, or serially to the ML model 18 initially and then optionally to the xAI model depending on the results of the ML model 18. Specifically, one option for the gate selection is to select or use the ML path to screen for typical contributing factors and to select or use the xAI path in more complex cases for which the ML output is ambiguous (or expected to be ambiguous) and / or

[0133] 24.095P-WO / 18.11.2025 to use the xAI model 17 selectively for cases assigned a high triage level, e.g., above a triage level threshold.

[0134] Figure 6 shows results in a graph form as output from a decoder of the kind shown in Figure 5 A. The graph shows example SHAP values (illustrated as the numbers inside the bars). The decoder output is the ranked list of input variables associated with SHAP values (illustrated in the table). While xAI is computationally expensive, it is able to decompose the triage levels to input contributions for each patient data type. In particular, when a high triage level is diagnosed (e.g., 4 or 5) without using xAI, the program flow can be adapted to activate the xAI in order to output a full ranked list of contributing factors for these high triage levels as an aid for clinical staff responsible for taking further actions to assist the patient.

[0135] For common contributing factors, a classification model may be pre-trained for detection and calculating the probability pzof the factor contributing to the issue as follows:

[0136] When no additional target domain information is provided, then

[0137] Pz= / z(s’ P’xi> ■■■ >xm) with triage state (s, p) and m input variables (x).

[0138] When additional target domain data is provided, then

[0139] pz= fz(s, p, x1, ..., xm, x'1, ..., x't) with triage state (s, p), m input variables (x), and t target domain variables (x').

[0140] For a given factor

[0141] contribution = (z, pz)

[0142] where

[0143] z E 0,1 is a binary indicator for the factor contributing, and

[0144] pzE [0,1] is the probability.

[0145] Then the output would be the list of contributions with z = 1 ranked in the order of pz.

[0146] Regression models may be trained with labels created by xAI for forward contribution prediction. SHAP values from xAI in this case would be the output label vzto be used to train a regression model vz= Vz(s, p,

[0147]

[0148] x],...,xt'~) and to calculate the predictions. The output would then be the list of factors ranked in the order of predicted vz.

[0149] 24.095P-WO / 18.11.2025 A record database may be provided to record the classification stages and the output of the encoder-decoder system. Moreover, a communication unit may be provided to communicate a recommended course of action to a clinical staff member. Other parties, such as a local caregiver or the patient may also be informed. For lower-level alerts, depending on the inferred action needed, the communications unit is configured to direct communications to an appropriate party depending on their preferences and details of the arranged care. Reminders to recharge a battery unit may be directed to patients directly, whereas notifications for patient outreach to provide additional system use training or recommendations are directed to a device provider’s care team or automated communication agent. For higher-level alerts, a message in text form, e.g., by email or SMS (Short Message Service), is sent to the responsible physician or other clinical staff member, and optionally also to the patient or caregiver, the message notifying that a high-level alert was sent together with a hyperlink to a physician or provider dashboard where more information and personalized detail is to be found. For a group of patients assigned a high degree of concern which are assigned a particular physician or hospital department, the communication unit may be configured to aggregate the alerts for that patient group and send these together.

[0150] Figure 7 is a block diagram illustrating an example computing apparatus 100 that may be used in connection with various embodiments described herein. For example, computing apparatus 100 may be used as the remote computing resource at a remote data center as mentioned further above for implementing any of the processing pipelines discussed in connection with embodiments of the invention.

[0151] Computing apparatus 100 can be a server or any conventional personal computer, or any other processor-enabled device that is capable of wired or wireless data communication. Other computing apparatus, systems and / or architectures may be also used, including devices that are not capable of wired or wireless data communication, as will be clear to those skilled in the art.

[0152] Computing apparatus 100 preferably includes one or more processors, such as processor 110. The processor 110 may be for example a CPU, GPU, TPU or arrays or combinations

[0153] 24.095P-WO / 18.11.2025 thereof such as CPU and TPU combinations or CPU and GPU combinations. Additional processors may be provided, such as an auxiliary processor to manage input / output, an auxiliary processor to perform floating point mathematical operations (e.g. a TPU), a specialpurpose microprocessor having an architecture suitable for fast execution of signal processing algorithms (e.g., digital signal processor, image processor), a slave processor subordinate to the main processing system (e.g., back-end processor), an additional microprocessor or controller for dual or multiple processor systems, or a coprocessor. Such auxiliary processors may be discrete processors or may be integrated with the processor 110.

[0154] Processor 110 is connected to a communication bus 105. Communication bus 105 may include a data channel for facilitating information transfer between storage and other peripheral components of computing apparatus 100. Communication bus 105 further may provide a set of signals used for communication with processor 110, including a data bus, address bus, and control bus (not shown). Communication bus 105 may comprise any standard or non-standard bus architecture such as, for example, bus architectures compliant with industry standard architecture (ISA), extended industry standard architecture (EISA), Micro Channel Architecture (MCA), peripheral component interconnect (PCI) local bus, or standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE) including IEEE 488 general-purpose interface bus (GPIB), IEEE 696 / S-100, and the like.

[0155] Computing apparatus 100 preferably includes a main memory 115 and may also include a secondary memory 120. Main memory 115 provides storage of instructions and data for programs executing on processor 110, such as one or more of the functions and / or modules discussed above. It should be understood that computer readable program instructions stored in the memory and executed by processor 110 may be assembler instructions, instructionset-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in and / or compiled from any combination of one or more programming languages, including without limitation Smalltalk, C / C++, Java, JavaScript, Perl, Visual Basic,. NET, and the like. Main memory 115 is typically semiconductor-based memory such as dynamic random-access memory (DRAM) and / or static random-access memory (SRAM). Other semiconductor-based memory types

[0156] 24.095P-WO / 18.11.2025 include, for example, synchronous dynamic random-access memory (SDRAM), Rambus dynamic random-access memory (RDRAM), ferroelectric random-access memory (FRAM), and the like, including read only memory (ROM).

[0157] The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0158] Secondary memory 120 may optionally include an internal memory 125 and / or a removable medium 130. Removable medium 130 is read from and / or written to in any well-known manner. Removable storage medium 130 may be, for example, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, a flash memory drive, etc.

[0159] Removable storage medium 130 is a non-transitory computer-readable medium having stored thereon computer-executable code (i.e., software) and / or data. The computer software or data stored on removable storage medium 130 is read into computing apparatus 100 for execution by processor 110.

[0160] The secondary memory 120 may include other similar elements for allowing computer programs or other data or instructions to be loaded into computing apparatus 100. Such means may include, for example, an external storage medium 145 and a communication interface 140, which allows software and data to be transferred from external storage medium 145 to computing apparatus 100. Examples of external storage medium 145 may include an external hard disk drive, an external optical drive, an external magneto- optical drive, etc. Other examples of secondary memory 120 may include semiconductor- based memory such as programmable read-only memory (PROM), erasable programmable read-

[0161] 24.095P-WO / 18.11.2025 only memory (EPROM), electrically erasable read-only memory (EEPROM), or flash memory (block-oriented memory similar to EEPROM).

[0162] As mentioned above, computing apparatus 100 may include a communication interface 140. Communication interface 140 allows software and data to be transferred between computing apparatus 100 and external devices (e.g., printers), networks, or other information sources. For example, computer software or executable code may be transferred to computing apparatus 100 from a network server via communication interface 140. Examples of communication interface 140 include a built-in network adapter, network interface card (NIC), Personal Computer Memory Card International Association (PCMCIA) network card, card bus network adapter, wireless network adapter, Universal Serial Bus (USB) network adapter, modem, a network interface card (NIC), a wireless data card, a communications port, an infrared interface, an IEEE 1394 fire-wire, or any other device capable of interfacing system with a network or another computing device. Communication interface 140 preferably implements industry-promulgated protocol standards, such as Ethernet IEEE 802 standards, Fiber Channel, digital subscriber line (DSL), asynchronous digital subscriber line (ADSL), frame relay, asynchronous transfer mode (ATM), integrated digital services network (ISDN), personal communications services (PCS), transmission control protocol / Intemet protocol (TCP / IP), serial line Internet protocol / point to point protocol (SLIP / PPP), and so on, but may also implement customized or non-standard interface protocols as well.

[0163] Software and data transferred via communication interface 140 are generally in the form of electrical communication signals 155. These signals 155 may be provided to communication interface 140 via a communication channel 150. In an embodiment, communication channel 150 may be a wired or wireless network, or any variety of other communication links. Communication channel 150 carries signals 155 and can be implemented using a variety of wired or wireless communication means including wire or cable, fiber optics, conventional phone line, cellular phone link, wireless data communication link, radio frequency (" RF") link, or infrared link, just to name a few.

[0164] 24.095P-WO / 18.11.2025 Computer-executable code (i.e., computer programs or software) is stored in main memory 115 and / or the secondary memory 120. Computer programs can also be received via communication interface 140 and stored in main memory 115 and / or secondary memory 120. Such computer programs, when executed, enable computing apparatus 100 to perform the various functions of the disclosed embodiments as described elsewhere herein.

[0165] In this document, the term "computer-readable medium" is used to refer to any non-transitory computer-readable storage media used to provide computer-executable code (e.g., software and computer programs) to computing apparatus 100. Examples of such media include main memory 115, secondary memory 120 (including internal memory 125, removable medium 130, and external storage medium 145), and any peripheral device communicatively coupled with communication interface 140 (including a network information server or other network device). These non-transitory computer-readable media are means for providing executable code, programming instructions, and software to computing apparatus 100. In an embodiment that is implemented using software, the software may be stored on a computer-readable medium and loaded into computing apparatus 100 by way of removable medium 130, VO interface 135, or communication interface 140. In such an embodiment, the software is loaded into computing apparatus 100 in the form of electrical communication signals 155. The software, when executed by processor 110, preferably causes processor 110 to perform the features and functions described elsewhere herein.

[0166] VO interface 135 provides an interface between one or more components of computing apparatus 100 and one or more input and / or output devices. Example input devices include, without limitation, keyboards, touch screens or other touch-sensitive devices, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, and the like. Examples of output devices include, without limitation, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum florescent displays (VFDs), surface-conduction electron-emitter displays (SEDs), field emission displays (FEDs), and the like.

[0167] Computing apparatus 100 also includes optional wireless communication components that facilitate wireless communication over a voice network and / or a data network. The wireless

[0168] 24.095P-WO / 18.11.2025 communication components comprise an antenna system 170, a radio system 165, and a baseband system 160. In computing apparatus 100, radio frequency (RF) signals are transmitted and received over the air by antenna system 170 under the management of radio system 165.

[0169] Antenna system 170 may comprise one or more antennae and one or more multiplexors (not shown) that perform a switching function to provide antenna system 170 with transmit and receive signal paths. In the receive path, received RF signals can be coupled from a multiplexor to a low noise amplifier (not shown) that amplifies the received RF signal and sends the amplified signal to radio system 165.

[0170] Radio system 165 may comprise one or more radios that are configured to communicate over various frequencies. In an embodiment, radio system 165 may combine a demodulator (not shown) and modulator (not shown) in one integrated circuit (IC). The demodulator and modulator can also be separate components. In the incoming path, the demodulator strips away the RF carrier signal leaving a baseband receive audio signal, which is sent from radio system 165 to baseband system 160.

[0171] If the received signal contains audio information, then baseband system 160 decodes the signal and converts it to an analogue signal. Then the signal is amplified and sent to a speaker. Baseband system 160 also receives analogue audio signals from a microphone. These analogue audio signals are converted to digital signals and encoded by baseband system 160. Baseband system 160 also codes the digital signals for transmission and generates a baseband transmit audio signal that is routed to the modulator portion of radio system 165. The modulator mixes the baseband transmit audio signal with an RF carrier signal generating an RF transmit signal that is routed to antenna system 170 and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to antenna system 170 where the signal is switched to the antenna port for transmission.

[0172] Baseband system 160 is also communicatively coupled with processor 110, which may be a central processing unit (CPU). Processor 110 has access to data storage areas 115 and 120.

[0173] 24.095P-WO / 18.11.2025 Processor 110 is preferably configured to execute instructions (i.e., computer programs or software) that can be stored in main memory 115 or secondary memory 120. Computer programs can also be received from baseband processor 160 and stored in main memory 110 or in secondary memory 120 or executed upon receipt. Such computer programs, when executed, enable computing apparatus 100 to perform the various functions of the disclosed embodiments. For example, data storage areas 115 or 120 may include various software modules.

[0174] The computing apparatus further comprises a display 175 directly attached to the communication bus 105 which may be provided instead of or addition to any display connected to the I / O interface 135 referred to above.

[0175] Various embodiments may also be implemented primarily in hardware using, for example, components such as application specific integrated circuits (ASICs), programmable logic arrays (PLA), or field programmable gate arrays (FPGAs). Implementation of a hardware state machine capable of performing the functions described herein will also be apparent to those skilled in the relevant art. Various embodiments may also be implemented using a combination of both hardware and software.

[0176] Figure 8 is a schematic block diagram of a patient triage method according to another aspect of the disclosure which has a sequential logic flow analogous to a manual triaging method. The program architecture comprises an input 50, a ML algorithm 52 for classification, a class 54, a xAI algorithm 56 and an output 58 expressed in terms of input data. The xAI algorithm xAI computes input contributions to the classification model output (class).

[0177] Figure 9 is a schematic block diagram of an example computer program product with architecture for performing the patient triaging method of Figure 8.

[0178] An issue type classification model 60 classifies issue types based on the input 50. A collection of binary classification models 68 are used to determine the probability of indicating each issue type, as there may be multiple concurrent issues. Each issue type is associated with a different level of severity and urgency. When given inputs xlt..., xm, issue

[0179] 24.095P-WO / 18.11.2025 type classification predicts issue = (y Pyj) where y7E 0,1 is a binary indicator for jthissue and pyj- E [0,1] is the probability using the classifier pyj- = giSSUe(Xi,

[0180]

[0181] Class and inference for each issue type is then provided as the output 70.

[0182] A criticality type classification model 62 is used to predict criticality levels for the predicted issue types provided by the issue type classification model 60. The criticality type classification model 62 receives the class and inference output 70 from the issue type classification model 60. Inference for each issue type i.e., pyj is fed to a criticality level classification model 72 hcto provide output class and inference 74 in the form of predicted criticality levels (expressing severity and urgency) and associated probability levels according to:

[0183] criticality level = (Cj,pc)

[0184] where Cj E 0,1,..., C is an integer indicator for jthissue and pC J- E [0,1] is the probability using the classifier pC J- = hc(pyjThe weighted sum of either c s or pC J- is calculated to predict the triage level: p = f w c,..., WiCi)or f w p,..., WiPi) where I is the number of issue types. Then

[0185] s = argmax f

[0186]

[0187] ^w^, or argmax f^w^,..., WiPi)

[0188] ke{0,...,5} ke{0,...,5}

[0189] state = (s, ps) where s E 0,1,...,5 is and integer indicator for the triage level and psE [0,1] is the probability, with m input variables (x).

[0190] A triage level classification model 64 receives the predicted criticality levels and associated probability levels from the criticality type classification model 62. These are processed by a classification model 76 to determine as its output and inference 76 triage levels and their associated probabilities. The classification model 76 assigns different weights to the criticality levels. The classification model 76 outputs class and inference 78 in the form of predicted triage levels and associated probabilities.

[0191] An interpreter model 66 comprises xAI algorithm 56 and optionally also an ML model 57 such as a classification model and / or regression model to determine as its output class and inference 82 contributing factors which may be output as a list ranked by probability.

[0192] 24.095P-WO / 18.11.2025 For the training dataset, the output labels are obtained from field experts (e.g., care technicians, physicians, other expert medical staff) who provide issue type, issue-specific criticality level, and the total overall triage level (e.g., 0~5).

[0193] 24.095P-WO / 18.11.2025 REFERENCE NUMERALS

[0194] 10 input (patient data)

[0195] 12 encoder

[0196] 14 encoded state (triage levels)

[0197] 16 decoder

[0198] 17 decoder xAI algorithm

[0199] 18 decoder ML algorithm

[0200] 20 output (contributing factors)

[0201] 22 target domain

[0202] 30 triage level classification model

[0203] 32 issue classification model

[0204] 34 classification model

[0205] 36 classification model output

[0206] 40 interpreter model

[0207] 50 input

[0208] 52 classifier ML

[0209] 54 Class

[0210] 56 xAI algorithm

[0211] 57 ML algorithm

[0212] 58 output

[0213] 60 issue type classification model

[0214] 62 criticality type classification model

[0215] 64 triage level classification model

[0216] 66 interpreter model

[0217] 68 issue type classification model, binary classification model(s)

[0218] 70 issue type classification model, output class and inference (issue type)

[0219] 72 criticality type classification model, classification model

[0220] 74 criticality type classification model, output class and inference (criticality levels) 76 triage level classification model, classification model

[0221] 78 triage level classification model, output class and inference (triage levels) 80 interpreter model, xAI

[0222] 24.095P-WO / 18.11.2025 82 interpreter model, output class and inference (contributing factors) 100 computing apparatus

[0223] 105 communication bus

[0224] 110 processor

[0225] 115 main memory

[0226] 120 secondary memory

[0227] 125 internal memory

[0228] 130 removable medium

[0229] 135 I / O interface

[0230] 140 communication interface

[0231] 145 external storage medium

[0232] 150 communi cati on channel

[0233] 155 electrical communication signals

[0234] 160 baseband system

[0235] 165 radio system

[0236] 170 antenna system

[0237] 175 display

[0238] 24.095P-WO / 18.11.2025

Claims

Claims1. A computer program product to support triaging a patient, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code configured to:receive input (10) comprising patient data;process the input in an encoder (12) to generate an encoded state (14) comprising a plurality of triage levels;supply at least the encoded state (14) and at least a subset of the input to a decoder (16); andprocess the encoded state (14) in the decoder (16) to generate an output (20) comprising contributing factors,thereby providing a human-understandable explanation of which patient data are contributing to a medical issue the patient is experiencing.

2. The computer program product of claim 1, wherein the decoder includes an explainable artificial intelligence, xAI, algorithm (17).

3. The computer program product of claim 1 or 2, wherein the decoder includes a machine learning algorithm (18).

4. The computer program product of any one of the preceding claims, wherein the decoder is additionally supplied with data from a target domain (22).

5. The computer program product of claim 4, wherein the input is a subset of the target domain.

6. The computer program product of claim 4, wherein the input and the target domain are separate sets.24.095P-WO / 18.11.20257. The computer program product of any one of the preceding claims, wherein the encoded state additionally comprises an inference which is a probability associated with each triage level, the inference being output together with the triage levels.

8. The computer program product of any one of the preceding claims, wherein the contributing factors are additionally associated with a predicted probability, and wherein the contributing factors are output as a list ranked by the predicted probability.

9. The computer program product of any one of the preceding claims, the computer- readable program code configured to:supply the input also to a classification model (34);process the input in the classification model to determine class and inference which are respectively issue type and a probability associated with each issue type; andsupply the class and inference as additional input to the decoder (16).

10. The computer program product of any one of the preceding claims, wherein the patient data includes patient device data obtained from one or more devices associated with the patient.

11. A computer-implemented method to support triaging a patient, comprising:receiving input comprising patient data;processing the input in an encoder to generate and output an encoded state comprising a plurality of triage levels;supplying at least the encoded state and at least a subset of the input to a decoder; andprocessing the encoded state in the decoder to generate an output comprising contributing factors,thereby providing a human-understandable explanation of which patient data are contributing to a medical issue the patient is experiencing.24.095P-WO / 18.11.202512. A computer program product to support triaging a patient, the computer program product comprising a computer-readable storage medium having computer-readable program code embodied therewith, the computer-readable program code configured to:receive input (50) comprising patient data;process the input in a classifier machine learning model (52) to generate a class (54) comprising a plurality of criticality levels;supply at least the class (54) and at least a subset of the input to an explainable artificial intelligence, xAI, algorithm (56); andprocess the class (54) in the xAI algorithm (56) to generate an output (82) comprising contributing factors,thereby providing a human-understandable explanation of which patient data are contributing to a medical issue the patient is experiencing.

13. A computer-implemented method to support triaging a patient, comprising:receiving input (50) comprising patient data;processing the input in a classifier machine learning model (52) to generate a class (54) comprising a plurality of criticality levels;supplying at least the class (54) and at least a subset of the input to an explainable artificial intelligence, xAI, algorithm (56); andprocessing the class (54) in the xAI algorithm (56) to generate an output (82) comprising contributing factors,thereby providing a human-understandable explanation of which patient data are contributing to a medical issue the patient is experiencing.24.095P-WO / 18.11.2025

Images