Risk management systems, devices, and related methods

Abstract

The present disclosure is directed to risk management systems, devices, and methods for analyzing and identifying operational deviations of client devices, medical devices, and applications thereon. The systems and methods may receive operational data for an application of a medical device or client device. The systems and methods may analyze operational data to identify one or more deviations from an expected operation of the medical device or application. The systems and methods may generate a notification indicative of the one or more deviations in response to identifying the one or more deviations. The systems and methods may also provide notifications to one or more of a medical device or a client device.

Description

[0001] Priority claim

[0002] This application claims the benefit of the filing date of U.S. Provisional Patent Application Serial No. 63 / 366,523, filed on June 16, 2022, entitled “RISK MANAGEMENT SYSTEM, DEVICE, AND RELATED METHODS,” the disclosure of which is hereby incorporated by reference in its entirety. Technical Field

[0003] Embodiments discussed herein generally relate to risk management systems. More specifically, embodiments relate to systems, devices, and methods for analyzing and identifying operational deviations of client devices, medical devices, and applications thereon. Background Art

[0004] Many people suffer from medical conditions that require regular care and attention. For example, diabetes is a chronic metabolic disorder caused by the inability of a person's pancreas to produce sufficient amounts of the hormone insulin, making it impossible for a person's metabolism to provide for the proper absorption of sugars and starches. This failure leads to hyperglycemia, i.e., the presence of excessive amounts of analytes, such as glucose, in the plasma. Persistent hyperglycemia is associated with a variety of severe symptoms and life-threatening long-term complications, such as dehydration, ketoacidosis, diabetic coma, cardiovascular disease, chronic renal failure, retinal damage, and nerve damage, with the risk of amputation. Self-monitoring of blood sugar and self-injection of insulin are typical methods for treating diabetes. People with type I, type II, or gestational diabetes typically track their blood sugar levels and administer self-treatment to maintain appropriate blood sugar levels. Certain medical devices, such as blood glucose meters, continuous glucose monitors (CGMs), infusion pumps, and injection pens, have been developed to assist in monitoring and treating medical conditions such as diabetes. In order to facilitate easy monitoring and maintenance, many medical devices designed for medical conditions that require continuous attention are also configured to interact with client devices by using, for example, applications that can be installed on client devices. Medical devices and associated applications may also provide a series of notifications, such as warnings and alarms, intended to draw the user's attention to situations related to the user's medical condition, system conditions, and / or other potential problems - and more generally reduce the cognitive load associated with self-monitoring and self-treatment. These notifications may lead to alarm fatigue, which may cause the user to ignore warnings or alarms or cease use of their medical device, thereby reducing the quality of their treatment. Summary of the invention

[0005] Various embodiments of the present disclosure provide benefits and / or solve one or more of the foregoing or other problems in the art through systems and methods for creating websites. Various embodiments of the present disclosure include a method. The method may include receiving operational data of an application of a medical device or client device at a cloud computing platform, the application being associated with the medical device. The method may additionally include analyzing the operational data to identify one or more deviations from the expected operation of the medical device or application. The method may also include generating a notification indicating one or more deviations in response to identifying one or more deviations. The method may also include providing a notification to one or more of the medical device or client devices.

[0006] One or more embodiments of the present disclosure include a method for determining the operational performance of an application. The method may include receiving, at a cloud computing platform, operational data of an application of a client device that communicates with a medical device. The method may also include analyzing the operational data at the cloud computing platform. Analyzing the operational data may include identifying one or more trigger conditions, and may also include identifying that one or more response actions to the one or more trigger conditions are not correctly executed. The method may also include generating a notification indicating a deviation from the expected operation of the application of the client device or the medical device in response to identifying that one or more response actions are not correctly executed. The method may additionally include providing a notification to the client device.

[0007] Various embodiments of the present disclosure include systems and devices, such as a cloud computing platform. The cloud computing platform may include a processor and a memory. Instructions may be stored on the memory, which, when executed by the processor, cause the cloud computing platform to perform one or more actions, including receiving operational data, analyzing operational data, generating notifications, and providing notifications. The cloud computing platform may receive operational data of a medical device or an application of the mobile device from a mobile device. The cloud computing platform may analyze the operational data to identify one or more deviations from the expected operation of the medical device or application. In response to identifying one or more deviations, the cloud computing platform may generate a notification indicating the one or more deviations. The cloud computing platform may also provide one or more notifications to the mobile device according to a determined frequency. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which the element is first introduced.

[0009] Figure 1 illustrates a schematic representation of an environment in which a risk management system according to one or more embodiments of the present disclosure may operate;

[0010] Figure 2 A flowchart illustrating a sequence that a risk management system may use to provide alert notifications according to one or more embodiments of the present disclosure;

[0011] Figure 3 illustrates a flow chart that a risk management system may use to create one or more response actions according to one or more embodiments of the present disclosure;

[0012] Figure 4 illustrates another flow chart that a risk management system may use to create one or more response actions in accordance with one or more embodiments of the present disclosure;

[0013] Figure 5 illustrates a block diagram of an example computing device according to one or more embodiments of the present disclosure;

[0014] Figure 6 A diagram illustrating an example flow of a system that maintains a catalog of platform-related features, settings, and uses configurable values ​​and log tags therefor.

[0015] Figure 7 A diagram illustrating an example flow of a system for analyzing archived operational logs in a DataLake according to one or more examples. DETAILED DESCRIPTION

[0016] 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 example embodiments in which the present disclosure may be practiced. These embodiments are described in sufficient detail to enable one of ordinary skill in the art to practice the present disclosure. However, other embodiments may be used, and structural, material, and process changes may be made without departing from the scope of the present disclosure.

[0017] As used herein, any relational terms, such as "first", "second", "front", "back", etc., are used for clarity and convenience in understanding the present disclosure and the drawings, and do not imply or rely on any particular preference or order, unless the context clearly indicates otherwise.

[0018] 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, and also include the more restrictive terms "consisting of," "consisting essentially of," and their grammatical equivalents.

[0019] As used herein, the term "may" with respect to a material, structure, feature, or method act indicates that the term is considered for use in implementing an embodiment of the present disclosure and that the term takes precedence over the more restrictive term "is" to avoid any suggestion that other compatible materials, structures, features, and methods that may be used in conjunction therewith should or must be excluded.

[0020] As used herein, the term "configuration" refers to the size, shape, material composition, and arrangement of one or more of at least one structure and at least one device to facilitate one or more of the structure and device to operate in a predetermined manner.

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

[0022] As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed items.

[0023] As used herein, the term "substantially" with reference to a given parameter, characteristic, or condition means and includes to some extent that a person of ordinary skill in the art would understand that the given parameter, characteristic, or condition is met to a certain degree of variation, such as within an acceptable tolerance range. For example, depending on the particular parameter, characteristic, or condition that is substantially met, the parameter, characteristic, or condition may be met by at least 90.0 percent, at least 95.0 percent, at least 99.0 percent, at least 99.9 percent, or even 100.0 percent.

[0024] As used herein, "about" or "approximately" with reference to a numerical value of a particular parameter includes that numerical value and a degree of variation of the numerical value within an acceptable tolerance for that particular parameter as would be understood by one of ordinary skill in the art. For example, when referring to a numerical value, "about" or "approximately" may include other numerical values ​​within the range of 90.0 percent to 110.0 percent of that numerical value, such as within the range of 95.0 percent to 105.0 percent of that numerical value, within the range of 97.5 percent to 102.5 percent of that numerical value, within the range of 99.0 percent to 101.0 percent of that numerical value, within the range of 99.5 percent to 100.5 percent of that numerical value, or within the range of 99.9 percent to 100.1 percent of that numerical value.

[0025] The following description may include examples to help those of ordinary skill in the art practice the disclosed embodiments. The use of the term "such as" means that the related description is illustrative, and while the scope of the present disclosure is intended to cover the examples and their legal equivalents, 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.

[0026] It will be readily appreciated that the components of the embodiments generally described herein and illustrated in the figures may be arranged and designed in a variety of different configurations. Therefore, 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 various aspects of the embodiments may be presented in the figures, the figures are not necessarily drawn to scale unless otherwise indicated.

[0027] Embodiments of the present disclosure may be described in terms of processes depicted as flow charts, flow diagrams, structure diagrams, or block diagrams. Although flow charts may describe operational actions as sequential processing, many of the actions may be performed in another order, in parallel, or substantially concurrently. In addition, the order of the actions may be rearranged. Processing may correspond to methods, threads, functions, procedures, subroutines, subprograms, other structures, or combinations thereof. In addition, the methods disclosed herein may be implemented in hardware, software, or both. If implemented in software, the functions may be stored or transmitted on a computer-readable medium as one or more instructions or codes. Computer-readable media include both computer storage media and communication media, including any media that facilitates the transfer of a computer program from one place to another.

[0028] Figure 1 A schematic diagram of an environment 100 in which a risk management system 101 according to one or more embodiments of the present disclosure may operate is illustrated. As shown, the environment 100 includes a client device 110, a cloud computing platform 130, a network 150, and a medical device 170. The client device 110, the cloud computing platform 130, and the medical device 170 may communicate via 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., Ethernet, Bluetooth, Bluetooth low energy, cellular, WiFi, near field communication (NFC), but not limited thereto). Although Figure 1 A specific arrangement of client device 110, cloud computing platform 130, medical device 170, and network 150 is illustrated, but various additional arrangements are possible. Figure 1 As shown in , client device 110 can communicate directly with medical device 170, bypassing network 150.

[0029] In one or more embodiments, a user 102 (e.g., an individual, but not limited thereto) may interact directly with a medical device 170. For example, the 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 a combination of any of the foregoing devices. In various embodiments, the user 102 may interact with a client device 110, for example, to communicate with the medical device 170 and / or the cloud computing platform 130. The client device 110 may include an application 112 installed thereon. The application 112 may be associated with the medical device 170 and / or the cloud computing platform 130. For example, the application 112 may support and / or enable the client device 110 to interact directly or indirectly with the medical device 170 and / or the cloud computing platform 130. The application 112 may also collect operational data related to the operation of the medical device 170, the application 112, and / or the client device 110. The client device 110, the application 112, and / or the medical device 170 may be associated with a specific individual user.

[0030] Application 112 can be a computer program that performs specific functions discussed herein. Application 112 is associated with medical device 170. For example, medical device 170 can be communicatively connected to client device 110 and / or application 112 thereon. In one or more embodiments, medical device 170 can be communicatively connected to client device 110 and / or application 112 by physical connection (e.g., by wire or cable) or logical connection (e.g., via Ethernet, but not limited thereto) with client device 110. In addition to or as an alternative to physical connection, medical device 170 can be communicatively connected to client device 110 and / or application 112 by wireless connection (e.g., via Bluetooth®, Wi-Fi, NFC, but not limited thereto). In one or more examples, when application 112 is associated with medical device 170, it may not be associated with another medical device. Application 112 can track the operation of a specific medical device (e.g., medical device 170), such as by monitoring and collecting operation data of medical device 170, as described in further detail below. In addition, the application 112 may or may be used to at least partially operate the medical device 170. As a non-limiting example, the application 112 may or may be used to control the medical device 170 to administer, adjust, reschedule and / or cancel a therapy (e.g., a dose of a medication (e.g., insulin, but not limited thereto), but not limited thereto).

[0031] In various embodiments, the cloud computing platform 130 can include a risk management system 101. In one or more embodiments, the risk management system 101 can be associated with the medical device 170, the manufacturer of the medical device 170, and / or a healthcare provider. In various embodiments, one or more of the manufacturer of the medical device 170 or the healthcare provider can provide information and / or guidance related to the proper operation (e.g., intended operation) of the medical device 170 and / or the application 112. For example, 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, one or more of the manufacturer of the medical device 170 or the healthcare provider can provide information related to the intended operation of the medical device 170 and / or the application 112 to the cloud computing platform 130. In various embodiments, the risk management system 101 can analyze data representing 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 below with respect to Figure 2-5 described in further detail.

[0032] Client device 110 and cloud computing platform 130 may represent various types of computing devices with which a user may interact. For example, client device 110 and / or cloud computing platform 130 may be a mobile device (e.g., a cellular phone, a smart phone, a personal data assistant (PDA), a tablet computer, a laptop computer, a desktop computer, a wearable computer or device (e.g., a smart watch, but not limited thereto), 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., a desktop computer or a server, but not limited thereto).

[0033] Figure 2 A sequence flow chart 200 is illustrated that a risk management system may implement to analyze the operation of an application and / or a medical device and notify a user of deviations from the expected operation of the application and / or the medical device. As described herein, the sequence flow chart 200 may involve Figure 1 The systems and / or one or more devices shown in , include, 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 .

[0034] Referring to the sequence flow chart 200, the client device 110 or the application 112 may track (eg, collect and / or record) the medical device 170 ( Figure 1 ) and / or with medical equipment 170 ( Figure 1) operation data related to the operation of the associated application 112. For example, the client device 110 can directly (eg, via the medical device 170 ( Figure 1 ) or indirectly (e.g., via application 112) to collect medical device 170 ( Figure 1 ). In various embodiments, the client device 110 may track the operational data via an operational log and / or other data packets within a database or memory. For example, the operational data may include time-varying data collected via synchronization events at periodic intervals (e.g., at least once per hour, at least once per minute, at least once per second, at least once per fraction of a second, etc.). The time-varying operational data may, for example, provide an indication of any changes that have occurred in the operation of the client device 110, the application 112, and / or the medical device 170.

[0035] like Figure 2 As shown in FIG. 1 , the client device 110 and / or the application 112 may provide (eg, send, transmit) the medical device 170 ( Figure 1 ), as shown in action 202. For example, the client device 110 and / or the application 112 may provide the risk management system 101 of the cloud computing platform 130 with the operation log and / or data packet including the operation data. In one or more embodiments, providing the operation data to the cloud computing platform 130 may include providing the setting data (e.g., current settings, changes to settings, etc.) of the medical device 170, the application 112, and / or the client device 110, as shown in action 202. Figure 2 As shown in optional action 203 of . For example, the setting data may include current notification settings, network connection settings, and current software versions (e.g., versions of operating systems and / or applications, but not limited to). In addition, but not limited to, the setting data may include whether the medical device 170 and / or the client device 110 is in a certain mode that may affect notifications, such as airplane mode, sleep mode, do not disturb mode, and / or silent mode. The setting data may also include, but is 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 occur, for example, in response to user interaction and / or automatically in response to a software update.

[0036] When client device 110 is connected to a network (e.g., network 150 ( Figure 1), the client device 110 may provide the operational data to the cloud computing platform 130 via the application 112 when the client device 110 is connected to a network (e.g., Wi-Fi). In one or more embodiments, the client device 110 and / or the application 112 may automatically (i.e., in response to a pre-specified trigger without further user oversight or approval) provide the operational data and / or settings data to the risk management system 101 and the cloud computing platform 130 when the client device 110 is connected to a network (e.g., Wi-Fi). For example, in various embodiments, the client device 110 and / or the application 112 may provide the operational data to the cloud computing platform 130 at periodic intervals (e.g., at least once a day, at least once an hour, at least once a minute, at least once a second, at least once every fraction of a second, but not limited thereto) and / or under predefined conditions (e.g., if the client device 110 is connected to a certain type of network, such as Wi-Fi, but not limited thereto). That is, application 112 and / or client device 110 may be configured to synchronize operational data and other data based thereon at risk management system 101 and / or cloud computing platform 130 at least in part with new operational data at periodic intervals and / or under predefined conditions.

[0037] In one or more embodiments, cloud computing platform 130 may receive data (eg, operational data and / or configuration data), such as Figure 2 As shown in action 204. For example, the cloud computing platform 130 can be connected via the network 150 ( Figure 1 ) receiving the operation data. The receiving the operation data in action 204 may include storing the operation data, such as Figure 2 The storage operation data in action 205 may, for example, enable the risk management system 101 to generate a local operation log, which includes the client device 110, the application 112 and / or the medical device 170 ( Figure 1 In addition, the local operation log generated by the risk management system 101 may describe instances in which operation data is expected to be received and indicate whether the operation data is received.

[0038] In response to receiving the medical device 170 ( Figure 1 ) and / or the operational data of the application 112, the risk management system 101 of the cloud computing platform 130 can analyze the operational data, such as Figure 2 The risk management system 101 may use rule-based logic, machine learning, and / or algorithms to analyze the operational data in action 206, such as Figure 2 As shown in optional action 208.

[0039] In various embodiments, the risk management system 101 may 1) analyze the operational data in the local operational log in act 206 to identify the warning triggering condition manifested therein and to identify the timing of the response action relative to the identified warning triggering condition. In other words, the risk management system 101 may analyze the operational data recorded in the local operational log to identify the response action that is predetermined to require an action from the medical device 170 ( Figure 1 ), application 112, client device 110 and / or user 102 ( Figure 1 ) to identify an event (i.e., an alert trigger condition) that may require a response (i.e., a response action) of one or more of the following: 1) an alert trigger condition (i.e., an alert trigger condition). In further embodiments, the risk management system 101 may 2) analyze the operational data to identify patterns (e.g., historical trends) of alert trigger conditions and / or critical events within the log. In various embodiments, the risk management system 101 may 3) analyze the operational data to identify user attributes that may require a response action.

[0040] In particular, the risk management system 101 may analyze the operation data recorded in the local operation log to identify the operation and / or data associated with the warning triggering condition. For example, the risk management system 101 may identify certain operation and / or status data of the client device 110 (e.g., battery life, battery health, and / or errors, etc.), certain operation and / or status data of the application 112 (e.g., crashes, errors, etc.), and / or certain operation and / or status data of the medical device 170 (e.g., battery life, battery health, and / or errors, etc.) associated with the warning triggering condition according to predetermined criteria. Other examples of warning triggering conditions include the medical device 170 ( Figure 1 ), the amount of medication remaining in the device (e.g., the amount of insulin, but not limited to this), the medication administration time, a missed administration action, an incorrectly administered dose, an upcoming administration action, but not limited to this. Additional examples of warning trigger conditions include the user's physiological condition, such as, for example, the user's blood sugar level, body temperature, heart rate, oxygen level and / or blood pressure.

[0041] In one or more examples, risk management system 101 can analyze operational data to identify Figure 1 ) of a medication therapy. For example, a critical event may include a client device 110, an application 112, and / or a medical device 170 ( Figure 1 ) and / or become inoperable for a non-negligible period of time. As another example, a critical event may include user 102 ( Figure 1 )’s physiological condition deviates greatly from normal levels (e.g., very high blood sugar levels, very low blood sugar levels, etc.).

[0042] In some cases, alert trigger conditions and / or critical events may be predetermined to require client device 110, application 112, user 102, and / or medical device 170 ( Figure 1 ) perform one or more response actions. For example, the response action may include performing one or more response actions via the client device 110, the application 112, and / or the medical device 170 ( Figure 1 ), and requires confirmation of the prompt via user interaction to clear the prompt. Additional examples of responsive actions may include administration of a recommended medication dose, connecting one or more of the client device 110 and the medical device 170 to an external power source, and / or adjusting settings (e.g., volume) of one or more of the client device 110, the application 112, and the medical device 170. Further examples of responsive actions may include sending a message to the user (email, phone call, text message, etc.), the user sending a message, and / or sending a message to a healthcare provider.

[0043] Still refer to Figure 2 , based at least in part on the operational data, the risk management system 101 can determine whether an appropriate response action was performed in response to one or more identified warning trigger conditions and / or critical events. In addition, in various embodiments, the risk management system 101 can determine whether an associated warning action was performed within a given time frame (e.g., within a predetermined time period, but not limited to) after one or more identified warning trigger conditions and / or critical events occurred. As discussed in further detail below, if the risk management system 101 determines that a response action was not performed, or that a response action was delayed, then the risk management system 101 can determine that a deviation from expected operation has occurred. In various embodiments, the risk management system 101 can determine whether an appropriate response action was performed in response to one or more identified warning trigger conditions and / or critical events. Figure 1 ) settings may be preventing the response action.

[0044] In one or more embodiments, the risk management system 101 can analyze the operational data to identify patterns (e.g., historical trends) associated with the warning trigger conditions and / or critical events represented by the operational logs. For example, the risk management system 101 can identify patterns such as the frequency of occurrence of the warning trigger conditions and / or critical events, the repeated causes of each warning trigger condition and / or critical event, and / or the origin of each warning trigger condition and / or critical event (e.g., the medical device 170 ( Figure 1), application 112 and / or client device 110). The risk management system 101 can identify patterns associated with warning trigger conditions and / or critical events for which warning actions are repeatedly not performed. The risk management system 101 can identify patterns associated with the time elapsed from the identification of warning trigger conditions and / or critical events to the execution of response actions.

[0045] As also mentioned above, the risk management system 101 may also analyze the operation log to determine the user attributes reflected in the operation log. For example, the risk management system 101 may determine one or more of the user's experience level, the severity of the user's disease, and the user's responsiveness to the warning, but not limited thereto (e.g., determine values ​​or descriptions representing these, but not limited thereto). In various embodiments, the user attribute may be an attribute that affects whether a response action is required in response to the warning trigger condition and / or the key event. For example, the user 102 ( Figure 1 ) using the application 112, the client device 110 and / or the medical device 170 ( Figure 1 ) can affect whether a warning action is required in response to a warning trigger condition and / or a critical event or the number of response actions required in response to a warning trigger condition and / or a critical event. For example, for an inexperienced (e.g., less experienced) user, more response actions may be required. Conversely, for an experienced (e.g., more experienced) user, fewer response actions may be required. The user's overall health status can affect whether a warning action is required in response to a warning trigger condition and / or a critical event. For example, for a user with multiple pre-existing health conditions or a degree of diabetes that is considered severe, more warning conditions may be required, while for a user without pre-existing health conditions or a less severe degree of diabetes, fewer warning conditions may be required.

[0046] In response to identifying one or more patterns (e.g., historical trends) associated with warning trigger conditions or critical events, the risk management system 101 can identify a sensitivity factor that can influence the determination and delivery of a final alert or warning (described below) to the user. In various embodiments, the sensitivity factor can reflect the frequency with which warning trigger conditions and critical events occur for a given user. For example, a user who experiences multiple or more frequent critical events or warning trigger conditions, as reflected in the operation log, can be assigned a high sensitivity factor. Conversely, a user who experiences relatively few critical events or warning trigger conditions, as reflected in the operation log, can be assigned a high sensitivity factor. As discussed in further detail below, a user assigned a high sensitivity factor may be more sensitive to an application 112 or a medical device 170 ( Figure 1 ) disruptions to the ability to perform critical tasks are more sensitive and may require more frequent notifications of eventual alerts or warnings.

[0047] In addition, based on the user attributes, the risk management system 101 can determine an experience factor, which is a factor that can affect the determination and delivery of a final alert or warning (described below) to the user. For example, the determined experience factor can be based at least in part on the user's experience in using the application 112, the client device 110, and / or the medical device 170 ( Figure 1 ), as reflected in the local operation log (i.e., operation data). In various embodiments, the experience level of the user using each of the application 112, the client device 110, and / or the medical device 170 is considered when determining the user's experience factor. As discussed below, a user with a high experience factor may require fewer or less frequent notifications about eventual alerts or warnings than a user with a low experience factor.

[0048] Still refer to Figure 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 use machine learning and / or artificial intelligence techniques to analyze the operational data, such as Figure 2 As shown in optional action 210.

[0049] In various embodiments, the risk management system 101 may analyze operational data using 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 phenomenon model. In addition, the machine learning model may include quadratic regression analysis, logistic regression analysis, support vector machine, Gaussian process regression, ensemble model, or any other regression analysis. In addition, in yet other embodiments, the machine learning model may include decision tree learning, regression tree, boosted tree, gradient boosted tree, multilayer perceptron, one-to-many, naive Bayes, k-nearest neighbor, association rule learning, neural network, deep learning, pattern recognition, or any other type of machine learning.

[0050] continue Figure 2 In response to analyzing the operational data and identifying the alert triggering condition, the risk management system 101 may identify a medical device 170 ( Figure 1 ) and / or one or more deviations from the intended operation of the application 112, such as Figure 2as shown in action 212 of . For example, the risk management system 101 can identify one or more deviations based on any identified warning trigger conditions and / or critical events that were not properly resolved (e.g., not properly resolved by one or more response actions). As briefly mentioned above, for the identified warning trigger conditions and / or critical events, identifying one or more deviations from expected operation can include identifying a lack of response actions from the user, a delay in response actions relative to an expected response time, too many response actions, too few response actions, etc. In addition, patterns (e.g., historical trends) in the warning trigger conditions, critical events, and / or response actions identified by the risk management system 101 can indicate that there are one or more deviations from expected operation. As a non-limiting example, the risk management system 101 can identify an increase in the frequency of warning trigger conditions and / or critical events, repetitions of the same type of warning trigger conditions and / or critical events, and / or from the same source (e.g., medical device 170 ( Figure 1 ), application 112 or client device 110) to identify one or more deviations.

[0051] In various embodiments, the risk management system 101 of the cloud computing platform 130 may determine that the medical device 170 ( Figure 1 ) and / or current (e.g., present, ongoing, unresolved, but not limited to) deviations from the intended operation of the application 112, such as Figure 2 In various embodiments, the risk management system 101 determines that the medical device 170 ( Figure 1 ) and / or past (eg, previous, resolved, etc.) deviations from the intended operation of the application 112, such as Figure 2 In one or more embodiments, the risk management system 101 predicts that the medical device 170 ( Figure 1 ) and / or one or more future deviations (e.g., expected, predicted, etc.) from the intended operation of the application 112, such as Figure 2 , as shown in optional action 218 of . For example, the risk management system 101 can identify current and / or past deviations, identify patterns (e.g., historical trends) based at least in part on analysis of operational data, determine a predictive model based on the identified patterns and current and / or past deviations, and use the model to predict future deviations. Additionally or alternatively, the risk management system 101 can identify current and / or past deviations, identify patterns (e.g., historical trends) based at least in part on analysis of operational data, and detect when a pattern in current operational data matches the identified pattern.

[0052] In one or more embodiments, the risk management system 101 can identify a cause of a given deviation based at least in part on the operational log data and / or the setup data. For example, the risk management system 101 can determine that the deviation was caused by the medical device 170 ( Figure 1 ), application 112, client device 110. In addition, in one or more embodiments, risk management system 101 can determine that the deviation is caused by the operating system of client device 110, medical device 170 ( Figure 1 )'s operating system and / or one or more settings of the client device 110's application 112. The risk management system 101 can analyze various factors to identify that the deviation is caused by incorrect device settings. As non-limiting examples, these factors can include: client device 110, application 112, and / or medical device 170 ( Figure 1 ) for the client device 110, application 112, and / or medical device 170 ( Figure 1 ) whether there have been any recent changes to the device settings of the current device settings of the client device 110 and / or the medical device 170 ( Figure 1 ) whether there is a recent operating system software update, whether the client device 110 receives a notification provided to the client device 110, the time delay between identifying the alert trigger condition and providing the notification to the client device 110, the number of notifications provided to the client device 110, and the like.

[0053] In various embodiments, in response to determining the cause of the one or more deviations, the risk management system 101 of the cloud computing platform 130 may optionally determine that the user 102 ( Figure 1 ) requires a specific response action to correct one or more deviations, and / or causes the medical device 170 ( Figure 1 ) and / or the application 112 returns to its intended operation. As described below, the specific response action may be indicated in a notification generated to the user, which includes instructions for performing the specific response (e.g., adjusting the operating system of the client device 110, the medical device 170 ( Figure 1 )'s operating system and / or one or more improperly configured settings of the application 112 of the client device 110 ).

[0054] In response to identifying a medical device 170 ( Figure 1 ) and / or one or more deviations from the expected operation of the application 112, the risk management system 101 can determine and generate a notification indicating the one or more deviations, such as Figure 2 As shown in act 220. As described above, in various embodiments, the generated notification may include an indicated responsive action to correct the deviation.

[0055] In various embodiments, determining and generating a notification may include determining (eg, via risk management system 101 ) a level of urgency (eg, severity) assigned to the notification, such as Figure 2 In various embodiments, the level of urgency of the notification may be specific to the user 102 ( Figure 1 ) and may be based on various factors, including user factors (e.g., the user's experience level), sensitivity factors (e.g., sensitivity to interruptions), the significance of the deviation (e.g., minor deviations that have little or no effect on device or system operation, major deviations that have a significant effect on device or system operation and / or indicate a malfunction of the device or system), the user's health status (e.g., physiological health (e.g., blood pressure, heart rate, cardiac output, oxygen levels, body temperature, etc.), whether the user uses tobacco products, how often the user exercises, etc.), user condition (e.g., whether the user is a smoker, how often the user exercises, etc.), information specific to the user's medical condition (e.g., blood glucose levels, when the last meal was consumed, etc.), the severity of the deviation (e.g., minimal and can be resolved by the user, moderate and may require assistance from a healthcare provider, potentially life-threatening and requiring immediate assistance from a healthcare provider, etc.).

[0056] 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 required to indicate that a software update was not properly installed or to alert the user 102 ( Figure 1 ) an impending insulin delivery that was not properly indicated by one or more of the application 112 or the medical device 170; a medium urgency notification may be required to alert the user 102 ( Figure 1 ) Medical equipment 170 ( Figure 1 ) is low on insulin and this information is not properly communicated to the user, the device (e.g., client device 110) previously communicated with medical device 170 ( Figure 1 ) loses network connectivity or user 102 ( Figure 1 ) missed a scheduled insulin dose; and a high urgency notification may be required to indicate that the user's blood glucose level is very high or very low and that this information was not previously properly indicated to the user, or to indicate that if ignored, it would be harmful to the user 102 ( Figure 1 ) Other conditions with serious health consequences.

[0057] In one or more embodiments, determining and generating a notification may include determining a notification type for the notification, such as Figure 2, as shown in optional action 224 of . For example, the risk management system 101 of the cloud computing platform 130 can determine the notification type of the notification. For example, the risk management system 101 can determine the type of network to be used to transmit the notification (e.g., cellular data network, voice network, Wi-Fi, etc.) and / or how the notification will be transmitted to the client device 110 and / or provided by the client device 110. For example, the type of notification can include a visual notification (e.g., a text message, an email, a push notification, a light, etc.), an audible notification (e.g., a sound, a phone call, etc.), and / or a tactile notification (e.g., a vibration, etc.). The notification type can also depend on the type of the client device so that the notification type is compatible with the type of the client device. In addition, the notification type can also depend on the urgency of the notification. For example, for a notification of high urgency, a phone call may be required, while for a notification of low urgency, a text message may be sufficient.

[0058] In various embodiments, the risk management system 101 may generate more than one notification and / or more than one type of notification. Furthermore, the number of notifications may also depend on the level of urgency of the notification. For example, a low urgency notification may require a single notification of one type (e.g., a single email). A medium urgency notification may require multiple notifications, which may be of the same type or different types. For example, a medium urgency notification may require a text message and a phone call. Furthermore, a high urgency notification may require multiple notifications and multiple types of notifications. For example, a high urgency notification may require multiple of a text message, a phone call, an email, a sound, and / or a vibration. Still referring to action 220, the risk management system 101 may generate notifications in the manner described above.

[0059] In one or more embodiments, the risk management system 101 may also generate a Figure 1 ) of your healthcare provider, such as Figure 2 In various embodiments, the notification may include information about the one or more deviations. Figure 1 ) of the healthcare provider may result in the healthcare provider communicating with the user 102 ( Figure 1 ) to check for one or more deviations and can improve the safety and effectiveness of the risk management system 101.

[0060] The risk management system 101 of the cloud computing platform 130 can provide the client device 110 and / or the medical device 170 ( Figure 1 ) provide notices such as Figure 2 As shown in action 226. For example, the risk management system 101 of the cloud computing platform 130 can be connected to the network 150 ( Figure 1 ) to the client device 110 and / or the medical device 170 ( Figure 1 ) provides a notification. In addition, the notification may optionally include an indication of the urgency level of the notification determined above, such as Figure 2 As shown in action 228.

[0061] The client device 110 may receive notifications from the risk management system 101 of the cloud computing platform 130, such as Figure 2 As shown in action 230. For example, client device 110 can access network 150 ( Figure 1 ) receives notifications from the risk management system 101 of the cloud computing platform 130. The client device 110 may receive notifications via the application 112 and / or via a method other than the application 112.

[0062] Client device 110 and / or application 112 may output a notification, such as Figure 2 As shown in action 232 of . For example, client device 110 may output a notification to notify the user by providing a sensory (e.g., tactile, audio, and / or visual) indication of the notification. The notification may be output on a visual display and / or speaker on client device 110, and may cause client device 110 to vibrate to prompt the user to take action in response to the notification. In various embodiments, outputting notifications on client device 110 may include outputting multiple notifications based on the urgency level of the notifications determined above.

[0063] In various embodiments, client device 110 may detect user actions in response to a notification, such as Figure 2 For example, the client device 110 may detect that the user 102 ( Figure 1 ) has taken action to acknowledge the notification and / or performed a responsive action in response to the notification and / or the identified deviation. In various embodiments, the user action may include user 102 ( Figure 1 ) and a medical device 170 that displays a notification ( Figure 1 ), a graphical user interface interaction of the client device 110 and / or application 112 (e.g., selecting a confirmation button or sending a reply text). In other embodiments, the user action may include the user delivering medication, adjusting settings, initiating charging of a battery, or any other responsive action described herein.

[0064] The client device 110 may provide a data packet to the risk management system 101 of the cloud computing platform 130, such as Figure 2 The data packet may indicate information related to the user action. The application 112 may also transmit the data packet to the client device 110 and / or the network 150 ( Figure 1 ) provides a data package to the risk management system 101 of the cloud computing platform 130.

[0065] The risk management system 101 of the cloud computing platform 130 may receive a data packet from the client device 110, such as Figure 2 as shown in optional action 238.

[0066] Based on the data packet, the risk management system 101 of the cloud computing platform 130 can determine whether appropriate response actions have been taken with respect to the deviation indicated in the notification (action 220), such as Figure 2 As shown in optional action 240.

[0067] In response to detecting whether an appropriate response action has been performed, risk management system 101 may terminate operations associated with the identified deviation.

[0068] Conversely, in response to determining that the recommended response action has not been correctly executed, the risk management system 101 of the cloud computing platform 130 may determine and generate another notification indicating one or more deviations in any manner described above with respect to action 220, such as Figure 2 In addition, the risk management system 101 can determine the urgency (eg, severity) level of another notification via any of the methods described above with respect to action 222, such as Figure 2 In various embodiments, it may be determined that the other notification has a different urgency level than the notification. For example, the notification may have a first urgency level, while the other notification may have a second urgency level. Additionally, the urgency level of the other notification (e.g., the second urgency level) may be higher or more urgent than the urgency level of the notification (e.g., the first urgency level). For example, if the notification has a low urgency level, then the other notification may have a medium or high urgency level.

[0069] In one or more embodiments, risk management system 101 may determine the notification type of another notification via any of the methods described above with respect to action 224, such as Figure 2 In various embodiments, if the type of notification previously provided (eg, the first notification) does not result in a response within a given time frame, the risk management system 101 can change the type of another notification relative to the previously provided notification.

[0070] In one or more embodiments, risk management system 101 may provide user 102 ( Figure 1 ) generates another notification, such as Figure 2 As shown in the optional action 247 of the embodiment. For user 102 ( Figure 1 ) may include information about one or more deviations and the user 102 ( Figure 1) information that the recommended response action was not taken and may result in a health care provider and user 102 ( Figure 1 ) is checked for one or more deviations. When user 102 ( Figure 1 ) appears to generate another notification for the user's healthcare provider when there is no response to the notification can improve the user's safety and risk management system 101 ( Figure 1 )’s effectiveness.

[0071] The risk management system 101 of the cloud computing platform 130 can provide the client device 110 and / or the medical device 170 ( Figure 1 ) provides another notification, such as Figure 2 In addition, another notification may indicate a determined urgency level of the other notification, such as Figure 2 As shown in action 250.

[0072] In one or more embodiments, client device 110 can access the network 150 ( Figure 1 ) receives another notification from the risk management system 101 of the cloud computing platform 130, such as Figure 2 As shown in optional action 252.

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

[0074] Figure 3 The method 300 is illustrated, according to one or more embodiments of the present disclosure, which a risk management system can utilize to analyze the operation of an application and / or a medical device and notify a user of deviations from the expected operation of the application and / or the medical device. As described herein, the method 300 can be Figure 1 The system and / or one or more devices shown in (including, for example, cloud computing platform 130, risk management system 101, client device 110, application 112, medical device 170, network 150 and / or user 102) are executed.

[0075] Method 300 may involve, for example, receiving, at a cloud computing platform, operational data of an application of a medical device or client device, as shown at act 302. Receiving operational data may include the above-mentioned Figure 2 Any actions described by actions 204 and 205.

[0076] The operational data may be analyzed (e.g., by a risk management system of the cloud computing platform) to identify one or more deviations of the medical device and / or the application of the client device from the expected operation of the medical device and / or the application, as shown at action 304. Analyzing the operational data may include the above-mentioned Figure 2 Any of the actions described in actions 206 to 218.

[0077] In response to identifying one or more deviations, a notification indicating the one or more deviations may be generated (eg, generated by the cloud computing platform), as shown at action 306. Generating the notification may include the above-described Figure 2 Any of the actions described in actions 220 to 225.

[0078] The notification may be provided to one or more of the medical device or the client device, as shown at action 308. Providing notifications to the medical device and / or the client device may include the above-described Figure 2 Action 226 and any action described by 226.

[0079] Figure 4 The method 400 is illustrated, according to one or more embodiments of the present disclosure, by which a risk management system can analyze the operation of an application and / or a medical device and can notify a user of deviations from the expected operation of the application and / or the medical device. As described herein, the method 400 can be Figure 1 The system and / or one or more devices shown in (including, for example, cloud computing platform 130, risk management system 101, client device 110, application 112, medical device 170, network 150 and / or user 102) are executed.

[0080] Method 400 may involve, for example, receiving, at a cloud computing platform, operational data of an application of a client device that communicates with a medical device, as shown at action 402. Receiving the operational data may include the above-mentioned Figure 2 Any actions described by actions 204 and 205.

[0081] The operational data may be analyzed at the cloud computing platform (e.g., by a risk management system), as shown at action 404. Analyzing the operational data at the cloud computing platform may include identifying one or more trigger conditions, as shown at optional action 410. Analyzing the operational data at the cloud computing platform may also include identifying that one or more responsive actions to the one or more trigger conditions were not properly performed, as shown at optional action 412. Analyzing the operational data may include the above-mentioned information regarding Figure 2 Any of the actions described in actions 206 to 218.

[0082] In response to identifying that one or more response actions were not correctly performed, a notification indicating a deviation from the expected operation of the application of the client device or the medical device can be generated (e.g., generated by the cloud computing platform), as shown at action 406. Generating the notification can include the above-mentioned Figure 2 Any of the actions described in actions 220 to 225.

[0083] The notification may be provided to the client device, as shown at action 408. Providing notifications to the medical device and / or the client device may include the above-described Figure 2 Action 226 and any action described by 226.

[0084] Figure 5 A block diagram of an example computing device 500 is illustrated, which may be configured to perform one or more of the above-described processes and may be included in the risk management system 101 ( Figure 1 ). It will be appreciated that one or more computing devices (such as computing device 500) may also be included in the cloud computing platform 130 ( Figure 1 )、client device 110( Figure 1 ) and / or medical devices 170 ( Figure 1 ). Figure 5 As shown, computing device 500 may include processor 502, memory 504, storage device 506, I / O interface 508, and communication interface 510, which may be communicatively coupled via a communication infrastructure. Figure 5 An example computing device 500 is shown in FIG. Figure 5 The components shown in are not intended to be limiting. Additional or alternative components may be used in other embodiments. Furthermore, in some embodiments, computing device 500 may include more Figure 5 The fewer components shown in FIG. will now be described in more detail Figure 5 Components of computing device 500 are shown in .

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

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

[0087] The computing device 500 includes a storage device 506, which includes a storage device for storing data or instructions. As an example and not as a limitation, the storage device 506 may include the above-mentioned non-transitory storage medium. The storage device 506 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a tape, or a universal serial bus (USB) drive, or a combination of two or more thereof. The storage device 506 may appropriately include a removable or non-removable (or fixed) medium. The storage device 506 may be located inside or outside the computing device 500. In one or more embodiments, the storage device 506 is a non-volatile solid-state memory. In other embodiments, the storage device 506 includes a read-only memory (ROM). Where appropriate, this ROM may be a mask-programmed ROM, a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), an electrically alterable ROM (EAROM), or a flash memory, or a combination of two or more thereof.

[0088] Computing device 500 also includes one or more input or output ("I / O") devices / interfaces 508 that allow a user to provide input to, receive output from, and otherwise transfer data to and 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. A touch screen may be activated with a stylus or finger.

[0089] 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, a display (e.g., a display screen), one or more output drivers (e.g., a 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 the display for presentation to the user. The graphical data may represent one or more graphical user interfaces and / or any other graphical content that may be used for a particular implementation.

[0090] The computing device 500 may also 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 between the computing device 500 and one or more other computing devices or networks (such as, for example, packet-based communication). As an example and not by way of limitation, the communication interface 510 may include a network interface controller (NIC) or network adapter for communicating with an Ethernet or other wired network, or a wireless NIC (WNIC) or wireless adapter for communicating with a wireless network (such as WI-FI). The computing device 500 may also include a bus 512. The bus 512 may include hardware, software, or both that couples the components of the computing device 500 to each other.

[0091] Figure 6 A diagram illustrating an example flow of a system that maintains a catalog of platform-related features, settings, and uses configurable values ​​and log tags therefor.

[0092] Platform-related features, feature settings and other configurations, and user configuration values ​​for them are compiled and maintained in the electronic catalog. In some cases, one or more of the features, settings, configurations, or values ​​can be assigned an importance level, and only those elements above 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. A trace tag is a name or other unique alphanumeric identifier used to identify an element in an operation log. Elements in the electronic catalog can be searched in the electronic catalog using a trace tag as a search term. When the operation logs are uploaded to the data lake via a web service, they are archived there and the data therein can be processed for analysis.

[0093] Figure 6 The process shown in is a non-limiting example of uploading, archiving and analyzing. A physiological (physiotherapy) measurement of a user is captured by a sensor (e.g., a physiological sensor, but not limited thereto). The value(s) of the physiological measurement are read by an application (e.g., a software application, but not limited thereto) executed on a client device (e.g., a mobile device such as a smartphone, but not limited thereto). The processing performed by the application of reading the value of the physiological measurement detects, triggers, initiates or causes an alert condition, and generates a log of the alert condition.

[0094] The application either automatically or upon instruction of the user issues a notification (e.g., requesting that a visual, audio, or tactile warning or alert be delivered to the user, but not limited to) to the client device platform (e.g., a mobile operating system of a smartphone, such as Android or iOS, but not limited to). Delivery of the notification is delayed for a non-instantaneous duration. After the non-instantaneous duration, the platform delivers the notification to the user.

[0095] The expected delivery time can be preset in the application or via the platform service that the application uses to issue the notification. The expected delivery time can be used by the application as a threshold for detecting a delay condition. Logs about platform behavior, configuration, conditions, and status are created automatically by the platform, by the platform in response to a request from the application, or by the application (for example, using trace data generated by the platform and requested by the application, but not limited to this). In one or more examples, the log is generated when a delay condition is detected and can represent a snapshot of the platform at that moment. Additionally or alternatively, the trace is continuously generated and is captured within a time period generally corresponding to the issuance of the notification and the detection of the delay condition. The boundaries of the time range for compiling traces for the log can be preset and vary depending on the conditions. For example, traces can be collected 1 to 5 minutes before the delay condition is detected and 1 to 5 minutes after the delay condition is detected. In one or more examples, the operation log includes at least some of the trace tags added to the electronic catalog.

[0096] The log is sent (e.g., uploaded via the Internet, but not limited to) to the web service using, for example, the platform's native communication service. The log can be sent automatically, upon request by the web service, or the next time the application synchronizes with the web service. The web service archives the operation log for analysis and action with the DataLake. Trace tags in the operation log can be used to search the electronic catalog to identify the element that is the subject of the trace and assist in analysis and action (if any).

[0097] Figure 7 A diagram illustrating an example process of a system for analyzing operation logs archived in a DataLake according to one or more examples. As a non-limiting example, regarding Figure 7 The example shown discusses an operation log that can be Figure 6 The operation log uploaded in the process shown in .

[0098] The analytics engine analyzes archived log data, identifies relevant alert events, and analyzes the relationship between application and platform events. For example, if the logs show that the application detected an alert trigger condition at a given point in time, but the alert action delivered by the platform was delayed, then performance impairment can be inferred.

[0099] The Alarm Manager tracks platform configurations and events. For a given configuration, relevant trace events are compared to the platform directory entries associated with the configuration. The results of this passive compatibility analysis can be used to infer key feature compatibility for a given configuration. The Alarm Manager can notify any system or party of such events (e.g., customer care systems, field service systems, clinical application expert systems, support entity systems, other support systems, but not limited to these).

[0100] The alert manager may use in-application messaging (eg, an in-application messaging service of an application on the client device, but not limited thereto) or other communication means to notify the user of the problem and optionally indicate corrective action.

[0101] App users who identify such issues can take immediate action to remedy the situation if needed. But this is after the fact – and some notifications sent via in-app messaging can be preemptive or educational, to educate and alert users to the potential for such issues, which the app cannot detect before they occur.

[0102] Extensions to the Alert Manager can issue "smart alerts" that are displayed intermittently based on cloud-based logic to customize the delivery of important reminders while reducing annoyance and warning fatigue. The cloud-based functionality can continuously monitor each operation log and detect smart alert conditions represented in one or more operation logs using predetermined criteria. Conditions that meet the alert criteria will result in the creation of a record specific to that user (a "trigger record"). When the user's application next synchronizes with the web service, it will receive the trigger record. The application will deliver messaging to the user. The Alert Manager can also provide messages with customized information and reinforcement during the next synchronization for new users of the system or users who encounter more warning conditions. This customized information can be provided to the user via in-application messaging.

[0103] The analysis engine may detect patterns of warning triggers or other critical events. Individuals who experience more critical events may be more sensitive to interruptions in the application's ability to perform critical tasks. It may be appropriate to issue more frequent alerts to the user. New users of the application may be reminded more frequently than experienced users. The alert manager may send one or more messages including such alerts and reminders to the user via the in-app messaging service in response to receiving notification of such a pattern.

[0104] The foregoing description is described with reference to specific example embodiments thereof. Various embodiments and aspects of the present disclosure are described with reference to the details discussed herein, and the accompanying drawings illustrate various embodiments. The foregoing description and drawings are illustrative and should not be construed as limiting. Many specific details are described to provide a thorough understanding of the various embodiments.

[0105] Additional or alternative embodiments may be implemented in other specific forms without departing from its spirit or essential characteristics. The described embodiments should be considered in all respects as illustrative only and not restrictive. Therefore, the scope of the present invention is indicated by the appended claims rather than the foregoing description. All changes in the equivalent meaning and scope of the claims should be included within their scope.

Claims

1. A method comprising: receiving, at the cloud computing platform, operational data of an application of a medical device or a client device, the application being associated with the medical device and at least partially used to operate the medical device; analyzing the operational data to identify one or more deviations from the intended operation of the medical device or application; responsive to identifying the one or more deviations, generating a notification indicative of the one or more deviations; as well as A notification is provided to one or more of the medical device or the client device.

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

3. The method of claim 1, further comprising: Determining that response actions have not yet been taken; In response to determining that a responsive action has not been taken according to the selected criteria, generating another notification indicating the one or more deviations; as well as The other notification is provided to one or more of the medical device or the client device.

4. The method of claim 3, wherein providing the notification comprises providing the notification having a first urgency level, and wherein providing the another notification comprises providing the another notification having a second urgency level. The method of claim 4 , wherein providing the another notification comprises providing a notification that is more urgent than providing the notification.

6. The method of claim 1, wherein analyzing the operational data to determine one or more deviations comprises identifying historical trends in the operational data and predicting one or more future deviations from expected operation of the medical device or application based on the identified historical trends.

7. The method of claim 1, wherein analyzing the operational data to determine one or more deviations comprises analyzing the operational data to determine one or more of past or current deviations from an expected operation of the medical device or application.

8. The method of claim 1, wherein providing a notification to one or more of the medical device or the client device comprises providing one or more of a push notification or an audible notification.

9. The method of claim 1, wherein analyzing the operational data comprises identifying that the one or more deviations originate from one or more of an operating system of the client device, an operating system of the medical device, or an improper setting of an application of the client device.

10. The method of claim 9, further comprising generating one or more instructions to adjust settings of one or more of an operating system of the client device, an operating system of the medical device, or an inappropriate setting of an application of the client device.

11. The method of claim 1 , wherein generating a notification comprises generating a notification to indicate a severity of the one or more deviations from expected operation.

12. A method for determining operational performance of an application, the method comprising: receiving, at the cloud computing platform, operational data of an application of a client device in communication with the medical device; Analyze operational data at the cloud computing platform, including: identifying one or more triggering conditions; and identifying that one or more responsive actions to the one or more triggering conditions were not properly performed; In response to identifying that the one or more response actions were not properly performed, generating a notification indicating a deviation from an expected operation of an application of the client device or the medical device; and Provide notifications to client devices.

13. The method of claim 12, wherein identifying that one or more response actions to the one or more triggering conditions were not properly executed comprises identifying one or more response actions that were delayed before being executed.

14. The method of claim 12, wherein identifying that one or more response actions to the one or more triggering conditions were not correctly executed comprises identifying one or more response actions that were not executed at all or were only partially executed. The method of claim 12 , wherein analyzing the operational data comprises analyzing an operational log.

16. The method of claim 12, wherein analyzing the operational data comprises analyzing the operational data via one or more machine learning techniques.

17. The method of claim 12, wherein the operational data is received via a synchronization event between an application of the client device and the cloud computing platform.

18. The method of claim 12, wherein analyzing the operational data further comprises identifying patterns of triggering conditions.

19. The method of claim 12, further comprising determining a frequency at which notifications regarding improper operation are provided to the client device.

20. The method of claim 19, wherein determining a frequency for providing notifications to the client device regarding improper operation comprises providing more frequent notifications in response to the client device being associated with a less experienced user and providing less frequent notifications in response to the client device being associated with a more experienced user.

21. A cloud computing platform, comprising: processor; as well as A memory storing instructions, which, when executed by the processor, cause the cloud computing platform to perform: receiving operational data of a medical device or an application of the mobile device from a mobile device; analyzing the operational data to identify one or more deviations from the intended operation of the medical device or application; In response to identifying the one or more deviations, generating a notification indicating the one or more deviations; and One or more notifications are provided to the mobile device according to the determined frequency.

22. The cloud computing platform of claim 21, wherein the memory includes additional instructions thereon that, when executed by the processor, cause the cloud computing platform to provide more frequent notifications in response to the mobile device being associated with a less experienced user, and to provide less frequent notifications in response to the mobile device being associated with a more experienced user.

23. The cloud computing platform of claim 21, wherein the memory includes additional instructions thereon that, when executed by the processor, cause the cloud computing platform to analyze operational data via one or more machine learning techniques.

Images