Risk management system, device, and related method

Abstract

The present disclosure relates to a risk management system, device, and method for analyzing and identifying deviations in the operation of client devices, medical devices, and applications thereon. The system and method may receive operation data of an application of a medical device or a client device. The system and method may analyze the operation data to identify one or more deviations from the intended operation of the medical device or application. The system and method may generate a notification indicating the one or more deviations in response to identifying the one or more deviations. The system and method may provide the notification to one or more of the medical device or the client device.

Description

Technical Field

[0001] The embodiments discussed in this specification generally relate to risk management systems. More particularly, the embodiments relate to systems, devices, and methods for analyzing and identifying deviations in the operation of client devices, medical devices, and applications thereon.

Background Art

[0002] Many people have medical conditions that require regular care and attention. For example, diabetes is a chronic metabolic disorder caused by the inability of the human pancreas to produce sufficient amounts of the hormone insulin and the inability of human metabolism to provide proper absorption of sugars and starches. This deficiency results in hyperglycemia, i.e., the presence of excessive amounts of analytes such as glucose in the plasma. Persistent hyperglycemia is associated with various severe symptoms and life-threatening long-term complications such as dehydration, ketoacidosis, diabetic coma, cardiovascular disease, chronic renal failure, retinal damage, and nerve damage that poses a risk of limb amputation. Self-monitoring of blood glucose and self-administration of insulin are typical methods for treating diabetes. People with type I, type II, or gestational diabetes typically self-treat by tracking their own blood glucose levels and maintaining appropriate blood glucose levels. To assist in the monitoring and treatment of medical conditions such as diabetes, certain medical devices have been developed, such as blood glucose meters, continuous glucose monitors (CGMs), infusion pumps, and injection pens. Many medical devices designed for medical conditions that require constant attention are also configured to interface with a client device, for example, through the use of an application that can be installed on the client device, to enable easy monitoring and maintenance. The medical device and associated application may also provide a series of notifications, such as alarms and alerts, intended to draw the user's attention to situations related to the user's medical condition, system status, and / or other potential problems, and more generally, may reduce the cognitive burden associated with self-monitoring and self-treatment. These notifications can lead to the user ignoring an alarm or alert or discontinuing the use of the user's medical device, and thus, can lead to alerts against fatigue that degrade the quality of the user's treatment. SUMMARY OF THE INVENTION

[0003] Various embodiments of the present disclosure relate to systems and methods for creating websites, providing benefits, and / or solving one or more of the above-mentioned problems or other problems in the art. Various embodiments of the present disclosure include methods. The method may comprise receiving, in a cloud computing platform, operation data of an application of a medical device or a client device, wherein the application is associated with the medical device. The method may further comprise analyzing the operation data to identify one or more deviations from the intended operation of the medical device or the application. The method may also comprise generating a notification indicating the one or more deviations in response to identifying the one or more deviations. The method may further comprise providing the notification to one or more of the medical device or the client device.

[0004] One or more embodiments of the present disclosure include a method for determining the operation performance of an application. The method may comprise receiving, in a cloud computing platform, operation data of an application of a client device communicating with a medical device. The method may further comprise analyzing the operation data in the cloud computing platform. The step of analyzing the operation data may include identifying one or more trigger conditions and identifying that one or more response actions for the one or more trigger conditions were not properly executed. The method may further comprise generating a notification indicating a deviation from the intended operation of the application of the client device or the medical device in response to identifying that one or more response actions were not properly executed. The method may further comprise providing the notification to the client device.

[0005] Various embodiments of the present disclosure include systems and devices such as cloud computing platforms. The cloud computing platform may include a processor and a memory. The memory stores instructions thereon, which, when executed by the processor, cause the cloud computing platform to perform one or more operations including receiving operational data, analyzing the operational data, generating a notification, and providing the notification. The cloud computing platform may receive operational data from a mobile device or an application of a medical device. The cloud computing platform may analyze the operational data to identify one or more deviations from the intended operation of the medical device or application. The cloud computing platform may generate a notification indicating the one or more deviations in response to identifying the one or more deviations. The cloud computing platform may provide the notification to the mobile device one or more times according to a determined frequency.

[0006] To easily identify the description of any particular element or operation, the most significant digit in the reference number refers to the figure number in which the element is first introduced.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0008] In the following detailed description, reference is made to the accompanying drawings which form a part hereof and in which are shown, by way of illustration, specific exemplary embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the present disclosure. However, other embodiments may be utilized and changes may be made in structure, materials, and processes without departing from the scope of the present disclosure.

[0009] As used herein, any relative terms such as “first,” “second,” “front,” “rear,” etc. are used for clarity and convenience in understanding the present disclosure and the accompanying drawings and do not imply or depend on any specific preference or order, except where the context clearly indicates otherwise.

[0010] As used herein, the terms "comprising", "including", "containing", "characterized by", and their grammatical equivalents are inclusive or open-ended terms that do not exclude additional unrecited elements or method steps, but also include the more limiting terms "consisting of", "consisting essentially of", and their grammatical equivalents.

[0011] As used herein, the term "may" with respect to a material, structure, feature, or method act indicates that such is contemplated for use in the implementation of embodiments of the present disclosure, and such term is used in preference to the more limiting term "is" so as to avoid any implication that other compatible materials, structures, features, and methods that may be used in combination therewith should or must be excluded.

[0012] As used herein, the term "configured" refers to the size, shape, material composition, and arrangement of one or more structures and one or more devices that perform one or more operations of a structure and a device by a predetermined method.

[0013] As used herein, the singular forms following "a", "an", and "the" are intended to include the plural form as well, unless the context clearly indicates otherwise.

[0014] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items. As used herein, the term "substantially" when referring to a given parameter, characteristic, or condition means that the given parameter, characteristic, or condition is met with some degree of variation, such as within an acceptable tolerance, and includes that the parameter, characteristic, or condition may be met to 90.0 percent or more, 95.0 percent or more, 99.0 percent or more, 99.9 percent or more, or even 100.0 percent, depending on the particular parameter, characteristic, or condition being substantially met.

[0015] As used herein, the terms "about" or "approximately" when referring to a numerical value for a particular parameter include that numerical value and the degree of variation from that numerical value that is understood by one of ordinary skill in the art is within an acceptable variance for that particular parameter. For example, the terms "about" or "approximately" when referring to a numerical value may include additional numerical values within the range of 90.0 percent to 110.0 percent of the numerical value, 95.0 percent to 105.0 percent of the numerical value, 97.5 percent to 102.5 percent of the numerical value, 99.0 percent to 101.0 percent of the numerical value, 99.5 percent to 100.5 percent of the numerical value, or 99.9 percent to 100.1 percent of the numerical value.

[0016] The following description may include examples to help enable one of ordinary skill in the art to practice the disclosed embodiments. The use of the term "for example" means that the associated description is illustrative, and the scope of the present disclosure is intended to include the examples and their legal equivalents, but the use of such terms is not intended to limit the embodiments or the scope of the present disclosure to the specified components, steps, features, functions, etc.

[0017] It will be readily understood that the components of the embodiments generally described herein and shown in the drawings can be arranged and designed in a wide variety of different configurations. Accordingly, the following description of the various embodiments is not intended to limit the scope of the present disclosure, but is merely representative of the various embodiments. Although the various aspects of the embodiments can be presented in the drawings, the drawings are not necessarily drawn to scale unless otherwise indicated.

[0018] Embodiments of the present disclosure can be described from the perspective of processes shown as flowcharts, flow diagrams, structural diagrams, or block diagrams. A flowchart can describe operational actions as sequential processes, but many of these actions may be executed in a different order, in parallel, or substantially simultaneously. In addition to this, the order of the actions may be rearranged. The processes may correspond to methods, threads, functions, procedures, subroutines, subprograms, other structures, or combinations thereof. Further, the methods disclosed herein may be implemented in hardware, software, or both. When implemented in software, the functions may be stored or transmitted as one or more instructions or codes on a computer-readable medium. The computer-readable medium comprises both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another.

[0019] FIG. 1 shows a schematic diagram of an environment 100 in which a risk management system 101 can operate in accordance with one or more embodiments of the present disclosure. As shown, environment 100 includes client devices 110, a cloud computing platform 130, a network 150, and a medical device 170. The client devices 110, the cloud computing platform 130, and the medical device 170 can communicate through the network 150. The network 150 may include one or more wired or wireless communication networks, including but not limited to the Internet, and may use one or more communication platforms or technologies suitable for transmitting data and / or communication signals (e.g., but not limited to, Ethernet®, Bluetooth®, Bluetooth Low Energy, cellular, Wi-Fi, near field communication (NFC)). FIG. 1 shows a particular arrangement of the client devices 110, the cloud computing platform 130, the medical device 170, and the network 150, but various additional arrangements are possible. For example, as shown in FIG. 1, the client devices 110 may bypass the network 150 and communicate directly with the medical device 170.

[0020] In one or more embodiments, user 102 (e.g., without limitation, an individual) may interact directly with medical device 170. For example, medical device 170 may include a CGM, a drug delivery device such as an infusion pump or an injection pen, a pen cap associated with a pen, a physiological sensor for temperature or heart rate, or any combination of the foregoing devices. In various embodiments, user 102 may interact with client device 110 to communicate, for example, with medical device 170 and / or cloud computing platform 130. Client device 110 may include an application 112 installed thereon. Application 112 may be associated with medical device 170 and / or cloud computing platform 130. For example, application 112 may support and / or enable client device 110 to interact directly or indirectly with medical device 170 and / or cloud computing platform 130. Application 112 may collect operational data related to the operation of medical device 170, application 112, and / or client device 110. Client device 110, application 112, and / or medical device 170 may be associated with a particular individual user.

[0021] Application 112 may be a computer program that executes the specific functions discussed herein. Application 112 is associated with medical device 170. For example, medical device 170 may be communicatively connected to client device 110 and / or application 112 on client device 110. In one or more embodiments, medical device 170 may be communicatively connected to client device 110 and / or application 112 by a physical connection (e.g., by wire or cable) or a logical connection (e.g., but not limited to, via an Ethernet® network) to client device 110. In addition to, or instead of, a physical connection, medical device 170 may be communicatively connected to client device 110 and / or application 112 by a wireless connection (e.g., but not limited to, via Bluetooth®, Wi-Fi, NFC). In one or more examples, application 112 need not be associated with additional medical devices when it is associated with medical device 170. Application 112 may track the operation of a specific medical device (e.g., medical device 170) by, for example, monitoring and collecting the operational data of medical device 170 as described in further detail below. In addition to this, application 112 may at least partially operate medical device 170, or be utilized to operate it. As a non-limiting example, application 112 may control medical device 170 to perform, adjust, reschedule, and / or cancel a treatment (e.g., but not limited to, a dosage of a drug (e.g., insulin)), or be utilized for that purpose.

[0022] In various embodiments, the cloud computing platform 130 may comprise a risk management system 101. In one or more embodiments, the risk management system 101 may be associated with the medical device 170, the manufacturer of the medical device 170, and / or the healthcare provider. In various embodiments, one or more of the manufacturer of the medical device 170 or the healthcare provider may provide information and / or guidelines related to the proper operation (e.g., the intended operation) of the medical device 170 and / or the application 112. For example, one or more of the manufacturer of the medical device 170 or the healthcare provider may provide information related to the intended operation of the medical device 170 and / or the application 112 to the cloud computing platform 130, in addition to information related to the intended communication protocol between the risk management system 101, the medical device 170, the application 112, the client device 110, the network 150, and / or the cloud computing platform 130. In various embodiments, the risk management system 101 may analyze data representative of the operation of the medical device 170 and / or the application 112 to identify deviations from the intended operation of the medical device 170 and / or the application 112, as described in further detail below with respect to FIGS. 2-5.

[0023] Client device 110 and cloud computing platform 130 may represent various types of computing devices with which a user can interact. For example, client device 110 and / or cloud computing platform 130 may be a mobile device (e.g., a mobile phone, smartphone, personal digital assistant (PDA), tablet computer, laptop computer, desktop computer, wearable computer or device (e.g., but not limited to, a smartwatch), etc.). However, in various embodiments, client device 110 and / or cloud computing platform 130 may include one or more non-mobile computer systems (e.g., but not limited to, a desktop or server).

[0024] FIG. 2 shows a sequence flow diagram 200 in which a risk management system can be implemented to analyze the operation of an application and / or a medical device and notify a user of a deviation from the intended operation of the application and / or the medical device. As described herein, sequence flow diagram 200 may include, for example, the system shown in FIG. 1 including cloud computing platform 130, risk management system 101, client device 110, application 112, medical device 170, network 150, and / or user 102 and / or one or more devices.

[0025] Referring to the sequence flow diagram 200, the client device 110 or the application 112 may track (e.g., collect and / or record) operation data regarding the operation of the medical device 170 (FIG. 1) and / or the application 112 (FIG. 1) associated with the medical device 170. For example, the client device 110 may collect the operation data of the medical device 170 (FIG. 1) directly (e.g., via the medical device 170 (FIG. 1)) or indirectly (e.g., via the application 112). In various embodiments, the client device 110 may track the operation data via an operation log and / or other data packages in a database or memory. For example, the operation data may include time-varying data collected by synchronizing events at periodic intervals (e.g., more than once per hour, more than once per minute, more than once per second, more than once per fraction of a second, etc.). The time-varying operation data may provide an indication of any changes that occur, for example, in the operation of the client device 110, the application 112, and / or the medical device 170.

[0026] As shown in FIG. 2, client device 110 and / or application 112 may provide (e.g., send, transmit) the operation data of medical device 170 (FIG. 1) to cloud computing platform 130, as shown in operation 202. For example, client device 110 and / or application 112 may provide an operation log and / or data package including the operation data to the risk management system 101 of cloud computing platform 130. In one or more embodiments, providing the operation data to cloud computing platform 130 may include providing the configuration data (e.g., current configuration, changes to the configuration, etc.) of medical device 170, application 112, and / or client device 110, as shown in optional operation 203 of FIG. 2. For example, the configuration data may include current notification settings, network connection settings, and current software versions (e.g., but not limited to, the version of the operating system and / or application). In addition to this, the configuration data may include, but not limited to, whether medical device 170 and / or client device 110 are in certain modes such as in-flight mode, sleep mode, do-not-disturb mode, and / or silent mode that may affect notifications. The configuration data may further include, but not limited to, changes to notification settings, network connection settings, and / or software versions (e.g., software updates). Changes to notification settings and / or network connection settings may be made automatically, for example, in response to user interaction and / or in response to software updates.

[0027] Client device 110 may provide operation data to cloud computing platform 130 via application 112 when client device 110 is connected to a network (e.g., network 150 (FIG. 1)). In one or more embodiments, client device 110 and / or application 112 may automatically (i.e., in response to a pre-specified trigger without further user supervision or approval) provide operation data and / or configuration data to risk management system 101 and cloud computing platform 130 while client device 110 is connected to a network (e.g., Wi-Fi). For example, in various embodiments, client device 110 and / or application 112 may provide operation data to cloud computing platform 130 at periodic intervals (e.g., but not limited to, more than once a day, more than once an hour, more than once a minute, more than once a second, more than once a fraction of a second) and / or under certain conditions (e.g., but not limited to, when client device 110 is connected to a particular type of network such as Wi-Fi). That is, application 112 and / or client device 110 may be configured to at least partially synchronize operation data and other data based thereon in risk management system 101 and / or cloud computing platform 130 with new operation data at periodic intervals and / or under certain conditions.

[0028] In one or more embodiments, the cloud computing platform 130 may receive data (e.g., operation data and / or configuration data), as shown in operation 204 of FIG. 2. For example, the cloud computing platform 130 may receive operation data through the network 150 (FIG. 1). Receiving operation data in operation 204 may include storing the operation data, as shown in optional operation 205 of FIG. 2. Storing the operation data in operation 205 may enable, for example, the risk management system 101 to generate a local operation log including historical operation data of the client device 110, the application 112, and / or the medical device 170 (FIG. 1). In addition, the local operation log generated by the risk management system 101 may describe an instance in which operation data was expected to be received and indicate whether the operation data was received.

[0029] In response to receiving the operation data of the medical device 170 (FIG. 1) and / or the application 112 in operation 204, the risk management system 101 of the cloud computing platform 130 may analyze the operation data, as shown in operation 206 of FIG. 2. The risk management system 101 may analyze the operation data in operation 206 using rule-based logic, machine learning, and / or algorithms, as shown in optional operation 208 of FIG. 2.

[0030] In various embodiments, the risk management system 101 may analyze the operation data in the local operation log in operation 206 to identify the alarm trigger conditions shown therein and identify the timing of the response actions for the identified alarm trigger conditions. In other words, the risk management system 101 may analyze the operation data recorded in the local operation log to identify the events (i.e., alarm trigger conditions) that are pre-determined to guarantee a response (i.e., response action) from one or more of the medical device 170 (FIG. 1), the application 112, the client device 110, and / or the user 102 (FIG. 1). In further embodiments, the risk management system 101 may 2) analyze the operation data to identify the patterns (e.g., historical trends) of alarm trigger conditions and / or critical events in the log. In various embodiments, the risk management system 101 may 3) analyze the operation data to identify user attributes that may guarantee response actions.

[0031] In particular, the risk management system 101 may analyze the operation data recorded in the local operation log to identify the operations and / or data associated with the alarm trigger conditions. For example, the risk management system 101 may identify specific operations and / or status data of the client device 110 (e.g., battery life, battery health, and / or errors, etc.), the application 112 (e.g., crashes, errors, etc.), and / or the medical device 170 (e.g., battery life, battery health, and / or errors, etc.) associated with the alarm trigger conditions according to a predetermined criterion. Other examples of alarm trigger conditions include, but are not limited to, the amount of drug remaining in the medical device 170 (FIG. 1) (e.g., the amount of insulin, without limitation), the drug dosing time, missed dosing operations, inaccurately administered dosages, and the next dosing operation. Further examples of alarm trigger conditions include, for example, the physiological conditions of the user such as the user's blood glucose level, body temperature, heart rate, oxygen level, and / or blood pressure.

[0032] In one or more examples, the risk management system 101 may analyze operational data to identify critical events that may be associated with the drug therapy of user 102 (FIG. 1). For example, a critical event may include one or more of client device 110, application 112, and / or medical device 170 (FIG. 1) malfunctioning and / or being inoperable for a non - negligible period of time. As a further example, a critical event may include a situation where the physiological state of user 102 (FIG. 1) deviates significantly from normal levels (e.g., very high blood glucose levels, very low blood glucose levels, etc.).

[0033] In some cases, alarm trigger conditions and / or critical events may be pre - determined to ensure one or more response actions performed by one or more of client device 110, application 112, user 102, and / or medical device 170 (FIG. 1). For example, response actions may include providing a prompt (e.g., auditory (e.g., but not limited to, a unique sound), visual (e.g., but not limited to, a flashing light, a flashing icon, a message, or other visually unique effect), or physical (e.g., but not limited to, a tactile prompt)) to user 102 via one or more of client device 110, application 112, and / or medical device 170, and requiring a positive response to the prompt via user interaction to clear the prompt. Additional examples of response actions may include administering a recommended drug dosage, connecting one or more of client device 110 and medical device 170 to external power, and / or adjusting the settings (e.g., volume) of one or more of client device 110, application 112, and medical device 170. Further examples of response actions may include sending a communication (e.g., email, phone, text message, etc.) to the user, having the user send a communication, and / or sending a communication for healthcare delivery.

[0034] Referring further to FIG. 2, based at least in part on the operational data, risk management system 101 may determine whether appropriate response actions have been executed in response to one or more identified alarm trigger conditions and / or critical events. Further, in various embodiments, risk management system 101 may determine whether an associated alarm action has been executed within a given time frame (e.g., but not limited to, within a predetermined period) after the occurrence of one or more identified alarm trigger conditions and / or critical events. As will be described in more detail below, if risk management system 101 determines that a response action has not been executed or that a response action has been delayed, risk management system 101 may determine that a deviation from the intended operation has occurred. In various embodiments, risk management system 101 may determine that settings of client device 110, application, and / or medical device 170 (FIG. 1) may have blocked the response action.

[0035] In one or more embodiments, risk management system 101 may analyze the operational data to identify patterns (e.g., historical trends) associated with alarm trigger conditions and / or critical events indicated by the operation log. For example, risk management system 101 may identify patterns such as the frequency of occurrence of alarm trigger conditions and / or critical events, the recurring causes of each alarm trigger condition and / or critical event, and / or the location where each alarm trigger condition and / or critical event occurred (e.g., medical device 170 (FIG. 1), application 112, and / or client device 110). Risk management system 101 may identify patterns associated with alarm trigger conditions and / or critical events for which the alarm action has not been repeatedly executed. Risk management system 101 may identify patterns associated with the time elapsed from when an alarm trigger condition and / or critical event is identified until a response action is executed.

[0036] Also, as described above, the risk management system 101 may analyze the operation log and determine user attributes reflected in the operation log. For example, the risk management system 101 may determine, without limitation, one or more of the user's experience level, the severity of the user's disease, and the user's responsiveness to an alarm (e.g., determine values or descriptions representing them). In various embodiments, the user attribute may be an attribute that affects whether a response action is guaranteed in response to an alarm trigger condition and / or a critical event. For example, the experience level of the user 102 (FIG. 1) regarding the use of the application 112, the client device 110, and / or the medical device 170 (FIG. 1) may affect whether an alarm action is required in response to an alarm trigger condition and / or a critical event, or the number of response actions required in response to an alarm trigger condition and / or a critical event. For example, more response actions may be guaranteed for a less experienced (e.g., having less experience) user. Conversely, fewer response actions may be guaranteed for a more experienced (e.g., having more experience) user. The overall health of the user may affect whether an alarm action is guaranteed in response to an alarm trigger condition and / or a critical event. For example, more alarm states may be guaranteed for users having some existing health conditions or whose diabetes level is considered severe, and fewer alarm conditions may be guaranteed for users having no existing health conditions or having a less severe diabetes case.

[0037] In response to identifying one or more patterns (e.g., historical trends) associated with an alarm trigger condition or a critical event, risk management system 101 may identify a sensitivity factor that can affect the determination and delivery of a final warning or alarm to the user (described below). In various embodiments, the sensitivity factor may reflect the frequency with which alarm trigger conditions and critical events occur for a given user. For example, a high sensitivity factor may be assigned to users who experience a plurality of, or more frequent, critical events or alarm trigger conditions, as reflected in the operation log. Conversely, a high sensitivity factor may be assigned to users who experience a relatively small number of critical events or alarm trigger conditions, as reflected in the operation log. As will be described in more detail below, users assigned a high sensitivity factor may be more sensitive to disruptions in the ability of application 112 or medical device 170 (FIG. 1) to perform critical tasks, and may warrant more frequent notifications regarding the final warning or alarm as compared to users assigned a low sensitivity factor.

[0038] In addition to this, based on user attributes, risk management system 101 may determine an experience factor, which is a factor that can affect the determination and delivery of a final warning or alarm to the user (described below). For example, the determined experience factor may be at least partially based on the user's level of experience in using one or more of application 112, client device 110, and / or medical device 170, as reflected in the local operation log (i.e., operation data). In various embodiments, the level of experience of the user in using each of application 112, client device 110, and / or medical device 170 is considered when determining the user's experience factor. As will be described below, users with a high experience factor may warrant fewer or less frequent notifications regarding the final warning or alarm as compared to users with a low experience factor.

[0039] Referring further to FIG. 2, in one or more embodiments, analyzing the operational data may include analyzing the operational data via one or more machine learning or artificial intelligence techniques. For example, the risk management system 101 of the cloud computing platform 130 may analyze the operational data using machine learning and / or artificial intelligence techniques as shown in the optional operation 210 of FIG. 2.

[0040] In various embodiments, the risk management system 101 may utilize one or more of a regression model (e.g., a set of statistical processes for estimating relationships between variables), a classification model, and / or a phenomenological model to analyze the operational data. In addition to this, the machine learning model may include quadratic regression analysis, logistic regression analysis, support vector machines, Gaussian process regression, ensemble models, or any other regression analysis. Further, in additional embodiments, the machine learning model may include decision tree learning, regression trees, boosted trees, gradient boosted trees, multi-layer perceptrons, one-vs-rest, naive Bayes, k-nearest neighbors, association rule learning, neural networks, deep learning, pattern recognition, or any other type of machine learning.

[0041] Continuing with FIG. 2, in response to analyzing the operational data and identifying alarm trigger conditions, the risk management system 101 may identify one or more deviations from the intended operation of the medical device 170 (FIG. 1) and / or the intended operation of the application 112, as shown in operation 212 of FIG. 2. For example, the risk management system 101 may identify one or more deviations based on any identified alarm trigger conditions and / or critical events that have not been appropriately addressed (e.g., not appropriately addressed via one or more response actions). As briefly described above, identifying one or more deviations from the intended operation may include identifying the lack of a response action from the user, a delay in the response action relative to the intended response time, too many response actions, too few response actions, etc., for the identified alarm trigger conditions and / or critical events. In addition to this, the alarm trigger conditions, critical events, and / or patterns (e.g., historical trends) in the response actions identified by the risk management system 101 may indicate one or more deviations from the intended operation. As a non-limiting example, the risk management system 101 may identify one or more deviations by determining an increase in the frequency of alarm trigger conditions and / or critical events, a repetition of the same type of alarm trigger condition and / or critical event, and / or alarm trigger conditions and / or critical events originating from the same source (e.g., the medical device 170 (FIG. 1), the application 112, or the client device 110).

[0042] In various embodiments, the risk management system 101 of the cloud computing platform 130 may determine current (e.g., but not limited to, current, ongoing, unresolved) deviations from the intended operation of the medical device 170 (FIG. 1) and / or the application 112, as shown in the optional action 214 of FIG. 2. In various embodiments, the risk management system 101 may determine past (e.g., previous, resolved, etc.) deviations from the intended operation of the medical device 170 (FIG. 1) and / or the application 112, as shown in the optional action 216 of FIG. 2. In one or more embodiments, the risk management system 101 may predict one or more future deviations (e.g., expected, anticipated, etc.) from the intended operation of the medical device 170 (FIG. 1) and / or the application 112, as shown in the optional action 218 of FIG. 2. For example, the risk management system 101 may identify current and / or past deviations, identify patterns (e.g., historical trends) based at least in part on the analysis of the operation data, determine a prediction model based on the identified patterns and the current and / or past deviations, and use the model to predict future deviations. In addition to or alternatively to this, the risk management system 101 may identify current and / or past deviations, identify patterns (e.g., historical trends) based at least in part on the analysis of the operation data, and detect when the patterns in the current operation data match the identified patterns.

[0043] In one or more embodiments, the risk management system 101 may identify the cause of a given deviation based at least in part on operation log data and / or configuration data. For example, the risk management system 101 may determine that a deviation was caused by the medical device 170 (FIG. 1), the application 112, or the client device 110 based on operation data (e.g., operation logs and data) and / or identified patterns from the operation data. Additionally, in one or more embodiments, the risk management system 101 may determine that the deviation was caused by one or more configurations of the operating system of the client device 110, the operating system of the medical device 170 (FIG. 1), and / or the application 112 of the client device 110. The risk management system 101 may analyze various factors to identify that the deviation was caused by an inappropriate device configuration. By way of non-limiting example, the factors may include the current device configuration of the client device 110, the application 112, and / or the medical device 170 (FIG. 1); whether there have been any recent changes to the device configuration of the current device configuration of the client device 110, the application 112, and / or the medical device 170 (FIG. 1); whether the client device 110 and / or the medical device 170 (FIG. 1) had a recent operating system software update; whether the client device 110 received a notification provided to the client device 110; the time delay between identifying an alarm trigger condition and providing a notification to the client device 110; the amount of notifications provided to the client device 110, etc.

[0044] In various embodiments, in response to determining one or more causes of deviation, the risk management system 101 of the cloud computing platform 130 may optionally determine specific response actions that need to be taken by the user 102 (FIG. 1) to correct one or more deviations and / or to return the medical device 170 (FIG. 1) and / or the application 112 to its intended operation. As described below, the specific response actions may be indicated in a generated notification to the user that includes instructions for performing the specific response (e.g., instructions for adjusting one or more inappropriately configured settings of the operating system of the client device 110, the operating system of the medical device 170 (FIG. 1), and / or the application 112 of the client device 110).

[0045] In response to identifying one or more deviations from the intended operation of the medical device 170 (FIG. 1) and / or the application 112, the risk management system 101 may determine and generate a notification indicating the one or more deviations, as shown in operation 220 of FIG. 2. As described above, in various embodiments, the generated notification may include the indicated response actions for correcting the deviation.

[0046] In various embodiments, determining and generating a notification may include determining (e.g., via risk management system 101) a level of urgency (e.g., severity) to assign to the notification, as shown in any of the operations 222 of FIG. 2. In various embodiments, the level of urgency of the notification may be specific to user 102 (FIG. 1) and may be based on various factors including user factors (e.g., the user's level of experience), sensitivity factors (e.g., sensitivity to confusion), significance of deviation (e.g., minor deviation that has a minor impact on device or system operation or no impact, major deviation that has a major impact on device or system operation and / or indicates device or system malfunction), user health (e.g., physiological health (e.g., blood pressure, heart rate, cardiac output, oxygen level, body temperature, etc.), whether the user uses tobacco products, how frequently the user exercises, etc.), user status (e.g., whether the user is a smoker, how frequently the user exercises, etc.), information specific to the user's medical condition (e.g., blood glucose level, time of last meal, etc.), severity of deviation (e.g., minimal, which can be resolved by the user, moderate, which may require assistance from a healthcare provider, life-threatening, which requires immediate assistance from a healthcare provider, etc.).

[0047] In various embodiments, the risk management system 101 may assign a level of urgency, including low, medium, or high. In various embodiments, a low urgency notification may be guaranteed to indicate that a software update was not properly installed or to remind the user 102 (FIG. 1) of the next insulin delivery not being properly prompted by one or more of the application 112 or the medical device 170, a small amount of insulin remaining in the medical device 170 (FIG. 1) not properly communicated to the user, the device (e.g., the client device 110) having previously lost network connection to the medical device 170 (FIG. 1), or the user 102 (FIG. 1) having missed a scheduled insulin dosage. A medium urgency notification may be guaranteed to warn the user 102 (FIG. 1) of a very high or very low blood glucose level of the user and that it was not previously properly indicated to the user or, if ignored, other conditions that may have a serious health impact on the user 102 (FIG. 1). A high urgency notification may be guaranteed to indicate a very high or very low blood glucose level of the user and that it was not previously properly indicated to the user or, if ignored, other conditions that may have a serious health impact on the user 102 (FIG. 1).

[0048] In one or more embodiments, determining and generating a notification may include determining a notification type of the notification, as shown in optional operation 224 of FIG. 2. For example, the risk management system 101 of the cloud computing platform 130 may determine the notification type of the notification. For example, the risk management system 101 may determine the type of network used to send the notification (e.g., cellular data network, voice network, Wi-Fi, etc.), and / or how the notification is sent to the client device 110, and / or how it is provided by the client device 102. For example, the types of notifications may include visual notifications (e.g., text messages, emails, push notifications, light, etc.), auditory notifications (e.g., sound, phone calls, etc.), and / or tactile notifications (e.g., vibration, etc.). The notification type may also depend on the type of client device so that the notification type is compatible with the type of client device. Further, the notification type may also depend on the urgency of the notification. For example, a high-urgency notification may be guaranteed a phone call, and a low-urgency notification may be sufficient with a text message.

[0049] In various embodiments, the risk management system 101 may generate two or more notifications and / or two or more types of notifications. Further, the amount of notifications may depend on the level of urgency of the notification. For example, a low-urgency notification may guarantee a single notification of one type (e.g., a single email). A medium-urgency notification may guarantee multiple notifications that may be of the same type or different types. For example, a moderately urgent notification may guarantee a text message and a phone call. In addition to this, a high-urgency notification may guarantee multiple notifications and multiple types of notifications. For example, a high-urgency notification may guarantee multiple text messages, phone calls, emails, sounds, and / or vibrations. Referring further to operation 220, the risk management system 101 may generate notifications according to the above method.

[0050] In one or more embodiments, the risk management system 101 may further generate a notification to the healthcare provider of the user 102 (FIG. 1), as shown in the optional action 225 of FIG. 2. In various embodiments, the notification may include information regarding one or more deviations. Generating a notification to the healthcare provider of the user 102 (FIG. 1) may result in the healthcare provider checking in with the user 102 (FIG. 1) regarding one or more deviations, and may enhance the safety and effectiveness of the risk management system 101.

[0051] The risk management system 101 of the cloud computing platform 130 may provide a notification to the client device 110 and / or the medical device 170 (FIG. 1), as shown in the operation 226 of FIG. 2. For example, the risk management system 101 of the cloud computing platform 130 may provide a notification to the client device 110 and / or the medical device 170 (FIG. 1) via the network 150 (FIG. 1). In addition to this, the notification may optionally include an indication of the determined level of urgency of the notification, as shown in the operation 228 of FIG. 2.

[0052] The client device 110 may receive a notification from the risk management system 101 of the cloud computing platform 130, as shown in the action 230 of FIG. 2. For example, the client device 110 may receive a notification from the risk management system 101 of the cloud computing platform 130 through the network 150 (FIG. 1). The client device 110 may receive the notification via the application 112 and / or via a means outside of the application 112.

[0053] The client device 110 and / or the application 112 may output a notification, as shown in operation 232 of FIG. 2. For example, the client device 110 may output a notification by providing a sensory (e.g., tactile, auditory, and / or visual) indication of the notification to notify the user. The notification may be output on a visual display and / or speaker on the client device 110, and the client device 110 may be vibrated to prompt the user to take an action in response to the notification. In various embodiments, outputting a notification on the client device 110 may include outputting multiple notifications according to the determined level of urgency of the notification described above.

[0054] In various embodiments, the client device 110 may detect a user action in response to a notification, as shown in optional operation 234 of FIG. 2. For example, the client device 110 may detect that the user 102 (FIG. 1) has taken an action to acknowledge the notification and / or has performed a response action in response to the notification and / or the identified deviation. In various embodiments, the user action may include the user 102 (FIG. 1) interacting with the graphical user interface of the medical device 170 (FIG. 1), the client device 110, and / or the application 112 to display the notification (e.g., selecting an affirmative response button or sending a reply text). In other embodiments, the user action may include the user delivering a drug, adjusting a setting, starting a battery charge, or any other response action described herein.

[0055] The client device 110 may provide a data package to the risk management system 101 of the cloud computing platform 130, as shown in the optional operation 236 of FIG. 2. The data package may indicate information related to user actions. The application 112 may also provide a data package to the risk management system 101 of the cloud computing platform 130 via the client device 110 and / or the network 150 (FIG. 1).

[0056] The risk management system 101 of the cloud computing platform 130 may receive a data package from the client device 110, as shown in the optional operation 238 of FIG. 2.

[0057] Based on the data package, the risk management system 101 of the cloud computing platform 130 may determine whether appropriate response actions have been taken for the deviations indicated in the notification, as shown in the optional operation 240 of FIG. 2 (operation 220).

[0058] In response to detecting that appropriate response actions have been executed, the risk management system 101 may terminate the operations related to the identified deviations. Conversely, in response to determining that the recommended response action has not yet been properly executed, the risk management system 101 of the cloud computing platform 130 may determine and generate another notification indicating one or more deviations according to any of the above-described techniques with respect to the action 220, as shown in the optional action 242 of FIG. 2. In addition to this, the risk management system 101 may determine the level of urgency (e.g., severity) of another notification via any of the techniques described above with respect to the action 222, as shown in the optional action 244 of FIG. 2. In various embodiments, another notification may be determined to have a different level of urgency than the notification. For example, the notification may have a first level of urgency, and another notification may have a second level of urgency. In addition to this, the level of urgency of another notification (e.g., the second level of urgency) may be higher or more urgent than the level of urgency of the notification (e.g., the first level of urgency). For example, if the notification has a low level of urgency, another notification may have a medium or high level of urgency.

[0059] In one or more embodiments, the risk management system 101 may determine the type of another notification via any of the techniques described above with respect to the action 224, as shown in the optional action 246 of FIG. 2. In various embodiments, the risk management system 101 may change the type of another notification with respect to a previously provided notification (e.g., the first notification) if the type of the previously provided notification has not resulted in a response within a given time frame.

[0060] In one or more embodiments, the risk management system 101 may generate another notification to the healthcare provider of the user 102 (FIG. 1) via any of the techniques described above with respect to operation 240, as shown in optional operation 247 of FIG. 2. The notification to the healthcare provider of the user 102 (FIG. 1) may include information regarding one or more deviations and information that the user 102 (FIG. 1) has not taken the recommended response action, and may also result in the healthcare provider checking in with the user 102 (FIG. 1) regarding one or more deviations. Generating another notification to the user's healthcare provider when the user 102 (FIG. 1) is thought not to respond to the notification may enhance the user's safety and the effectiveness of the risk management system 101 (FIG. 1).

[0061] The risk management system 101 of the cloud computing platform 130 may provide another notification to the client device 110 and / or the medical device 170 (FIG. 1), as shown in optional operation 248 of FIG. 2. In addition to this, another notification may indicate the determined level of urgency of the other notification, as shown in operation 250 of FIG. 2.

[0062] In one or more embodiments, the client device 110 may receive another notification from the cloud computing platform 130 of the risk management system 101 via the network 150 (FIG. 1), as shown in optional operation 252 of FIG. 2.

[0063] In various embodiments, the risk management system 101 of the cloud computing platform 130 and / or the client device 110 may repeat one or more of the operations 232-252 of FIG. 2 until an appropriate response action is taken (e.g., by the user or the user's healthcare provider).

[0064] Figure 3 shows a method 300 that can be utilized by a risk management system to analyze the operation of an application and / or a medical device according to one or more embodiments of the present disclosure and to notify a user of a deviation from the intended operation of the application and / or the medical device. As described herein, method 300 may be performed by the system and / or one or more devices shown in FIG. 1, including, for example, a cloud computing platform 130, a risk management system 101, a client device 110, an application 112, a medical device 170, a network 150, and / or a user 102.

[0065] Method 300 may include, for example, as shown in action 302, receiving operation data of an application of a medical device or a client device in a cloud computing platform. Receiving the operation data may include any of the actions described above with respect to operations 204 and 205 of FIG. 2.

[0066] The operation data may be analyzed (e.g., by a risk management system of the cloud computing platform) to identify one or more deviations of the application of the medical device and / or the client device from the intended operation of the medical device and / or the application, as shown in action 304. Analyzing the operation data may include any of the actions described above with respect to actions 206-218 of FIG. 2.

[0067] In response to identifying one or more deviations, a notification indicating the one or more deviations may be generated (e.g., by the cloud computing platform), as shown in action 306. Generating the notification may include any of the actions described above with respect to operations 220-225 of FIG. 2.

[0068] As shown in operation 308, the notification may be provided to one or more of the medical device or the client device. Providing the notification to the medical device and / or the client device may include any of the actions described above with respect to operations 226 and 226 of FIG. 2.

[0069] FIG. 4 shows a method 400 according to one or more embodiments of the present disclosure, in which a risk management system may be utilized to analyze the operation of an application and / or a medical device, and may notify a user of a deviation from the intended operation of the application and / or the medical device. As described herein, method 400 may be performed by a system and / or one or more devices shown in FIG. 1, including, for example, a cloud computing platform 130, a risk management system 101, a client device 110, an application 112, a medical device 170, a network 150, and / or a user 102.

[0070] Method 400 may include, for example, receiving operation data of an application of a client device communicating with a medical device in a cloud computing platform, as shown in operation 402. Receiving the operation data may include any of the actions described above with respect to operations 204 and 205 of FIG. 2.

[0071] As shown in operation 404, the operation data may be analyzed in a cloud computing platform (e.g., by a risk management system). Analyzing the operation data in a cloud computing platform may include identifying one or more trigger conditions, as shown in optional operation 410. Analyzing the operation data in a cloud computing platform may also include identifying that one or more response actions for one or more trigger conditions were not properly executed, as shown in optional operation 412. Analyzing the operation data may include any of the operations described above with respect to operations 206-218 of FIG. 2.

[0072] In response to identifying that one or more response actions were not properly executed, a notification indicating a deviation from the intended operation of the application of the client device or medical device may be generated (e.g., by the cloud computing platform), as shown in operation 406. Generating the notification may include any of the actions described above with respect to operations 220-225 of FIG. 2.

[0073] As shown in operation 408, the notification may be provided to the client device. Providing the notification to the medical device and / or the client device may include any of the actions described above with respect to operations 226 and 226 of FIG. 2.

[0074] FIG. 5 shows a block diagram of an exemplary computing device 500 that may be configured to execute one or more of the above-described processes and may be included in a risk management system 101 (FIG. 1). It is understood that one or more computing devices, such as computing device 500, may also be included within a cloud computing platform 130 (FIG. 1), a client device 110 (FIG. 1), and / or a medical device 170 (FIG. 1). As shown by FIG. 5, computing device 500 may comprise a processor 502, a memory 504, a storage device 506, an I / O interface 508, and a communication interface 510, which may be communicatively coupled via a communication infrastructure. Although an exemplary computing device 500 is shown in FIG. 5, the components shown in FIG. 5 are not intended to be limiting. In other embodiments, additional or alternative components may be used. Further, in some embodiments, computing device 500 may include fewer components than those shown in FIG. 5. More details of the components of computing device 500 shown in FIG. 5 are described below.

[0075] In one or more embodiments, processor 502 includes hardware for executing instructions, such as instructions that make up a computer program. By way of example and not limitation, to execute instructions, processor 502 may retrieve (or fetch) instructions from an internal register, internal cache, memory 504, or storage device 506, decode and execute the instructions. In one or more embodiments, processor 502 may include one or more internal caches for data, instructions, or addresses. By way of example and not limitation, processor 502 may include one or more instruction caches, one or more data caches, and one or more translation lookaside buffers (TLBs). Instructions in the instruction cache may be copies of instructions in memory 504 or storage 506.

[0076] Computing device 500 includes a memory 504 coupled to a processor 502. Memory 504 may be used to store data, metadata, and programs for execution by the processor. Memory 504 may include one or more of volatile memory and non-volatile memory, such as random access memory ("RAM"), read-only memory ("ROM"), solid state disk ("SSD"), flash, phase change memory ("PCM"), or other types of data storage. Memory 504 may be internal memory or distributed memory.

[0077] Computing device 500 includes a storage device 506 that provides storage for storing data or instructions. By way of example and not limitation, storage device 506 may include the non-transitory storage media described above. Storage device 506 may include a hard disk drive (HDD), floppy (registered trademark) disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or universal serial bus (USB) drive, or a combination of two or more of these. Storage device 506 may include removable or non-removable (or fixed) media, as desired. Storage device 506 may be internal or external to computing device 500. In one or more embodiments, storage device 506 is non-volatile solid state memory. In other embodiments, storage device 506 includes read-only memory (ROM). Optionally, this ROM may be mask-programmed ROM, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), electrically alterable ROM (EAROM), or flash memory, or a combination of two or more of these.

[0078] Computing device 500 also includes one or more input or output (“I / O”) devices / interfaces 508, which are provided to enable a user to provide input to, receive output from, transfer data to, or receive data from computing device 500. I / O devices / interfaces 508 may include a mouse, keypad or keyboard, touch screen, camera, optical scanner, network interface, modem, other known I / O devices, or combinations of such I / O devices / interfaces. The touch screen may be actuated by a stylus or finger.

[0079] I / O devices / interfaces 508 may include one or more devices for presenting output to a user, including but not limited to a graphics engine, display (e.g., display screen), one or more output drivers (e.g., display driver), one or more audio speakers, and one or more audio drivers. In some embodiments, I / O interface 508 is configured to provide graphical data to a display for presentation to a user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content that may be useful for a particular implementation.

[0080] Computing device 500 may further include a communication interface 510. The communication interface 510 may include hardware, software, or both. The communication interface 510 may provide one or more interfaces for communication (e.g., packet-based communication, etc.) between the computing device 500 and one or more other computing devices or networks. By way of example and not limitation, the communication interface 510 may include a network interface controller (NIC) or network adapter for communicating with Ethernet or other wired-based networks, or a wireless NIC (WNIC) or wireless adapter for communicating with wireless networks such as WI-FI. Computing device 500 may further include a bus 512. The bus 512 may comprise hardware, software, or both that couples components of the computing device 500 to each other.

[0081] FIG. 6 shows an exemplary flow diagram for a system that maintains a catalog of platform-dependent features, settings, uses configurable values, and log tags therefor. Platform-dependent features, settings and other configurations for the features, and user-configurable values of the functions are compiled and maintained in an electronic catalog. In some cases, an importance rating may be assigned to one or more of the features, settings, configurations, or values, and only those that exceed a threshold importance are included as elements of the electronic catalog. For each element of the catalog, a trace tag is added to the electronic catalog. The trace tag is a name or other unique alphanumeric identifier that is used to identify the element in the operation log. Elements in the electronic catalog are searchable within the electronic catalog using the trace tag as a search term. When the operation log is uploaded to the data lake via a web service, it is archived in the data lake and the data in the data lake can be processed for analysis.

[0082] The flow shown by FIG. 6 is a non-limiting example of upload, archive, and analysis. Physiological (physio) measurements regarding a user are captured by a sensor (e.g., but not limited to, a physiological sensor). The values of the physiological measurements are read by an application (e.g., but not limited to, a software application) running on a client device (e.g., but not limited to, a mobile device such as a smartphone). The process executed by the application that reads the values of the physiological measurements detects, triggers, initiates, or causes an alarm condition, and a log regarding the alarm condition is generated.

[0083] The application issues a notification (e.g., but not limited to, requiring that a visual, auditory, or tactile alarm or alert be delivered to the user) to the client device platform (e.g., but not limited to, the mobile operating system of a smartphone such as Android™ or iOS) automatically or at the user's instruction. The delivery of the notification is delayed for a non-instantaneous duration. After the non-instantaneous duration, the platform delivers the notification to the user.

[0084] The desired delivery time may be set in advance in the application or via a platform service by which the application is notified. The desired delivery time may be used as a threshold by the application to detect a delay state. Logs regarding platform behavior, configuration, conditions, and states are created automatically by the platform, in response to a request by the application to the platform, or by the application (e.g., using trace data generated by the platform and requested by the application). In one or more examples, the logs may be generated upon detection of a delay state and represent a snapshot of the platform at that instant. In addition to or instead of this, traces are generated continuously and captured over a period substantially corresponding to when the notification was issued and when the delay state was detected. The boundaries of the time range during which the traces are compiled against the logs are preset and may vary according to conditions. For example, traces may be collected for 1 to 5 minutes before the delay state is detected and for 1 to 5 minutes after the delay state is detected. In one or more examples, the operational logs include at least some of the trace tags added to the electronic catalog.

[0085] The logs are sent to a web service (e.g., uploaded via the Internet) using, for example, the platform's local communication service. The logs may be sent automatically in response to a request by the web service or when the application next synchronizes with the web service. The web service archives the operational logs for analysis and action using a data lake. The trace tags in the operational logs may be used to search the electronic catalog to identify the elements that are the subject of the traces and, if any, to assist in analysis and action.

[0086] FIG. 7 shows an exemplary flow diagram of a system for analyzing operation logs archived in a data lake according to one or more examples. By way of non-limiting example, the operation logs described with respect to the example shown in FIG. 7 may be those uploaded in the flow shown in FIG. 6.

[0087] The analysis engine analyzes the archived log data, identifies relevant alert events, and analyzes the relationships between application events and platform events. For example, if the log indicates that an alarm trigger condition was detected by an application at a given point in time, but the platform delivery alarm action was delayed, a compromised performance can be inferred.

[0088] The alert manager tracks platform configurations and events. For a given configuration, relevant trace events are compared to the platform catalog entries associated with that configuration. The results from this passive compatibility analysis may be used to infer the compatibility of important features for a given configuration. The alert manager may notify any system or party (e.g., but not limited to, a customer care system, a field service system, a clinical application specialty system, a support entity system, other support systems) of such events.

[0089] The alert manager may notify the user of the problem using in-app messaging (e.g., but not limited to, the in-app messaging service of an application on a client device) or other communication means, and optionally, indicate a corrective action.

[0090] Application users who have had such problems identified may, if necessary, take prompt action to correct them. However, this is after the fact, and some notifications sent via in-app messaging may be proactive or educational in order to educate and remind the user of the possibility of such problems that cannot be detected by the application before they occur.

[0091] An extension to the alert manager may issue "smart warnings" that are displayed intermittently based on cloud-based logic, adapting the delivery of important reminders while reducing nuisance and alert fatigue. The cloud-based functionality may continuously monitor each operation log and use predetermined criteria to detect smart warning states represented in one or more operation logs. Conditions that meet the warning criteria result in the creation of a record specific to that user ("trigger record"). When the user's application next synchronizes with the web service, it receives the trigger record. The application delivers the messaging to the user. The alert manager may also provide messages with adapted information and reinforcement for new users to the system or users experiencing more alarm states during the next synchronization. This adapted information may be provided to the user via in-app messaging.

[0092] The analytics engine may detect patterns of alarm triggers or other critical events. Individuals experiencing more critical events become more sensitive to disruptions in the ability of the application to perform critical tasks. More frequent warnings may be appropriate for the user. New users of the application may be reminded more frequently than more experienced users. The alert manager may, in response to such patterns being notified, send one or more messages, including such warnings and reminders, to the user via the in-app messaging service.

[0093] The foregoing specification has been described with reference to its specific exemplary embodiments. The various embodiments and aspects of the present disclosure are described with reference to the details set forth herein, and the accompanying drawings illustrate the various embodiments. The above description and drawings are exemplary and should not be construed as limiting. Numerous specific details are set forth in order to provide a complete understanding of the various embodiments.

[0094] Additional or alternative embodiments may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The described embodiments are illustrative only and not considered to be limiting in any way. Accordingly, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All changes that come within the meaning and range of equivalency of the claims are embraced within their scope.

Claims

1. A method comprising: In a cloud computing platform, receiving operation data of an application of a medical device or a client device, wherein the application is associated with the medical device and is used to operate the medical device at least partially; An operation data analysis step of analyzing the operation data to identify one or more deviations from the intended operation of the medical device or the application; A notification generation step of generating a notification indicating the one or more deviations in response to identifying the one or more deviations; A notification providing step of providing the notification to one or more of the medical device or the client device.

2. The method according to claim 1, further comprising, in the cloud computing platform, receiving a response action in response to the notification from the client device.

3. Determining that no response action has been taken; Generating another notification indicating the one or more deviations in response to determining that no response action has been taken according to a selected criterion; A further notification providing step of providing the another notification to one or more of the medical device or the client device.

4. The notification providing step includes providing the notification having a first level of urgency; The method according to claim 3, wherein the further notification providing step includes providing the another notification having a second level of urgency.

5. The method according to claim 4, wherein the further notification providing step includes providing more urgent notifications than the notification providing step.

6. The step of analyzing the operation data to determine one or more deviations includes identifying a historical trend of the operation data and predicting one or more future deviations from the intended operation of the medical device or the application based on the identified historical trend.

7. The step of analyzing the operation data to determine one or more deviations includes analyzing the operation data to determine one or more of the past and current deviations from the intended operation of the medical device or the application, the method according to claim 1.

8. The notification providing step includes providing one or more of push notifications and audible notifications, the method according to claim 1.

9. The operation data analysis step includes identifying that one or more of the one or more deviations have occurred from one or more of an inappropriate setting of the operating system of the client device, the operating system of the medical device, and the application of the client device, the method according to claim 1.

10. The method according to claim 9, further comprising generating one or more instructions for adjusting one or more of the one or more inappropriate settings of the operating system of the client device, the operating system of the medical device, and the application of the client device.

11. The notification generating step includes generating a notification for indicating the severity of the one or more deviations from the intended operation, the method according to claim 1.

12. A method for determining the operating performance of an application, comprising: receiving, in a cloud computing platform, operation data of an application of a client device communicating with a medical device; in the cloud computing platform, an operation data analysis step, comprising: identifying one or more trigger conditions; a response action non-execution identification step of identifying that one or more response actions for the one or more trigger conditions have not been properly executed; generating a notification indicating a deviation from the intended operation of the application of the client device or the medical device in response to identifying that the one or more response actions have not been properly executed; providing the notification to the client device.

13. The method according to claim 12, wherein the unexecuted response action identification step includes a step of identifying one or more response actions that were delayed before execution.

14. The method according to claim 12, wherein the unexecuted response action identification step includes a step of identifying one or more response actions that were not executed at all or were only partially executed.

15. The method according to claim 12, wherein the operation data analysis step includes a step of analyzing an operation log.

16. The method according to claim 12, wherein the operation data analysis step includes a step of analyzing the operation data by one or more machine learning techniques.

17. The method according to claim 12, wherein the operation data is received by synchronizing events between the application of the client device and the cloud computing platform.

18. The method according to claim 12, wherein the operation data analysis step further includes a step of identifying a pattern of trigger conditions.

19. The method according to claim 12, further comprising a notification frequency determination step of determining a frequency of providing a notification regarding an incorrect operation to the client device.

20. The method according to claim 19, wherein the notification frequency determination step includes a step of providing a notification more frequently in response to the client device being associated with a user with less experience, and a step of providing a notification less frequently in response to the client device being associated with a user with more experience.

21. A cloud computing platform, comprising a processor and a memory for storing instructions thereon, wherein when executed by the processor, the instructions cause the cloud computing platform to receive operation data from a mobile device, a medical device or an application of the mobile device, analyze the operation data to identify one or more deviations from an intended operation of the medical device or the application, and generate a notification indicating the one or more deviations in response to identifying the one or more deviations. A cloud computing platform that causes the mobile device to provide the notification one or more times according to the determined frequency. **Claim 22** The memory comprises additional instructions on the memory, and when the instructions are executed by the processor, the cloud computing platform is caused to provide notifications at a higher frequency in response to the mobile device being associated with a user with less experience; The cloud computing platform according to claim 21, which causes the mobile device to provide notifications at a lower frequency in response to the mobile device being associated with a user with more experience. **Claim 23** The cloud computing platform according to claim 21, wherein the memory comprises additional instructions on the memory, and when the instructions are executed by the processor, the cloud computing platform is caused to analyze the operation data by one or more machine learning techniques.

Images