Adaptive user authentication of acute health events

Abstract

The invention discloses a computing device, comprising: a communication circuit configured to wirelessly communicate with a sensor device on a patient or implanted in the patient; one or more output devices; and processing circuitry. The processing circuitry is configured to: receive, via the communication circuitry, seizure data of an acute health event detected by the sensor device, the seizure data sent by the sensor device in response to detecting the acute health event; determining an alarm context in response to receiving the seizure data; configuring an alert for the acute health event based on the alert context; and controlling the one or more output devices to output the alarm based on the alarm context configuration.

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 375,657, filed on September 14, 2022, the entire contents of which are incorporated herein by reference. Technical Field

[0002] The present disclosure relates generally to systems including medical devices, and more particularly to using such systems to monitor patient health. Background Art

[0003] A variety of devices are configured to monitor physiological signals of patients. Such devices include implantable or wearable medical devices, and a variety of wearable health or fitness tracking devices. Physiological signals sensed by such devices include, for example, electrocardiogram (ECG) signals, respiration signals, perfusion signals, activity and / or posture signals, pressure signals, blood oxygen saturation signals, body composition, and blood glucose or other blood component signals. In general, using these signals, such devices facilitate monitoring and evaluating patient health outside of a clinic environment over months or years.

[0004] In some cases, such devices are configured to detect acute health events based on physiological signals, such as the onset of arrhythmia, myocardial infarction, stroke, or epilepsy. Exemplary arrhythmia types include cardiac arrest (e.g., cardiac arrest), ventricular tachycardia (VT), and ventricular fibrillation (VF). These devices may store ECG and other physiological signal data collected during a time period including the onset as episode data. Such acute health events are associated with significant mortality, particularly if not treated quickly.

[0005] For example, VF and other malignant tachyarrhythmias are the most commonly identified arrhythmias in patients with sudden cardiac arrest (SCA). If such arrhythmias persist for more than a few seconds, cardiogenic shock and cessation of effective blood circulation may result. For every minute a patient waits for defibrillation, the survival rate from SCA decreases by 7% to 10%. Therefore, sudden cardiac death (SCD) may occur within minutes. Summary of the invention

[0006] In general, the present disclosure describes techniques for detecting acute health events (such as SCA) by monitoring patient parameter data (such as ECG data). More specifically, the present disclosure describes techniques that include providing a responsive, cancelable alert as a health check to determine whether the patient is responsive or an acute health event is occurring. If not canceled within a period of time, an action can be taken in response to the acute health event.

[0007] In some examples, a computing device providing such an alarm determines an alarm context and configures the alarm based on the alarm context. In this way, the duration and / or intensity of the alarm can be relatively greater when the patient is less likely to be warned or otherwise able to quickly cancel the alarm and / or when the acute health event is less severe and / or less likely to actually occur. The duration of the alarm can be relatively shorter when the patient is more likely to be warned or otherwise able to quickly cancel the alarm and / or when the type of acute health event is more severe and / or more likely to actually occur. Adaptive alarms according to the techniques of the present disclosure can advantageously improve the user's ability to override the alarm when appropriate, while shortening the alarm period when the acute health event is severe and / or may be, for example, a lethal tachyarrhythmia with a high probability of causing SCA.

[0008] In an example, a computing device includes: a communication circuit configured to wirelessly communicate with a sensor device on a patient or implanted in the patient's body; one or more output devices; and a processing circuit configured to: receive, via the communication circuit, onset data of an acute health event detected by the sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determine an alarm context in response to receiving the onset data; configure an alarm for the acute health event based on the alarm context; and control the one or more output devices to output the alarm configured based on the alarm context.

[0009] In another example, a system includes a sensor device and a computing device as described above.

[0010] In another example, a method of operating a computing device includes: receiving, via a communication circuit of the computing device, onset data of an acute health event detected by a sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determining, by a processing circuit of the computing device in response to receiving the onset data, an alarm context; configuring, by the processing circuit, an alarm for the acute health event based on the alarm context; and controlling, by the processing circuit, one or more output devices of the computing device to output the alarm configured based on the alarm context.

[0011] In another example, a non-transitory computer-readable storage medium includes instructions that cause a processing circuit to: receive onset data of an acute health event detected by a sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determine an alarm context in response to receiving the onset data; configure an alarm for the acute health event based on the alarm context; and output the alarm configured based on the alarm context.

[0012] The present disclosure is intended to provide an overview of the subject matter described in the present disclosure. It is not intended to provide an exclusive or exhaustive explanation of the devices and methods described in detail in the following figures and descriptions. Further details of one or more examples are set forth in the following figures and descriptions. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is a block diagram illustrating an example system configured to detect health events of a patient and respond to such detections, in accordance with one or more techniques of this disclosure.

[0014] Figure 2 is a block diagram illustrating an example configuration of a patient sensing device operating in accordance with one or more techniques of this disclosure.

[0015] Figure 3 is a block diagram illustrating an example configuration of a computing device that operates in accordance with one or more techniques of this disclosure.

[0016] Figure 4 is a block diagram illustrating an example configuration of a health monitoring system that operates in accordance with one or more techniques of this disclosure.

[0017] Figure 5 is a flow chart illustrating example operations for applying rules to patient parameter data to determine whether an acute health event is detected.

[0018] Figure 6 is a flow chart illustrating another example operation for applying rules to patient parameter data to determine whether an acute health event is detected.

[0019] Figure 7 is a flow diagram illustrating example operations for configuring rules that are applied to patient parameter data to determine whether an acute health event is detected for a patient.

[0020] Figure 8 is a flow diagram illustrating another example operation for configuring a rule that is applied to patient parameter data to determine whether an acute health event is detected for a patient.

[0021] Fig. 9 is a block diagram illustrating an example of a collection of neural networks configured to classify ventricular tachyarrhythmias.

[0022] Fig.10 is a block diagram illustrating an example of a single classifier utilizing raw signals and derived features.

[0023] Fig.11 is a block diagram illustrating a staged approach for classifying ventricular tachyarrhythmia episodes.

[0024] Fig. 12A and Fig. 12B The frequency decomposition of monomorphic ventricular tachycardia episodes and supraventricular tachycardia episodes are illustrated separately.

[0025] Fig.13 is a flow diagram illustrating example operations for configuring an acute health event alert based on an alert context.

[0026] Fig.14 is a conceptual diagram illustrating an exemplary machine learning model configured to determine the extent to which a patient's data indicates an acute health event.

[0027] Fig.15 is a conceptual diagram illustrating an exemplary training process for a machine learning model according to an example of the present disclosure.

[0028] Fig.16A is a perspective view illustrating an insertable cardiac monitor.

[0029] Fig. 16B is a perspective view illustrating another insertable cardiac monitor.

[0030] Like reference numerals refer to like elements throughout the drawings and the specification. DETAILED DESCRIPTION

[0031] Various types of implantable devices and external devices detect arrhythmia attacks and other acute health events based on sensed ECG and (in some cases) other physiological signals. External devices that can be used for non-invasive sensing and monitoring of ECG and other physiological signals include wearable devices such as patches, watches, rings, necklaces, hearing aids, wearable heart monitors or automatic external defibrillators (AEDs), clothing, car seats, or bed sheets with electrodes configured to contact the patient's skin. Such medical devices can facilitate relatively long-term monitoring of patient health during normal daily activities.

[0032] Implantable medical devices (IMDs) also sense and monitor ECG and other physiological signals, and detect acute health events, such as arrhythmias, cardiac arrest, myocardial infarction, stroke, and seizures. Exemplary IMDs include pacemakers and implantable cardioverter-defibrillators, which can be coupled to intravascular or extravascular leads; and pacemakers having a housing configured for implantation in the heart, which can be leadless. Some IMDs do not provide therapy, such as implantable patient monitors. An example of such an IMD is the Reveal LINQ II available from Medtronic, Inc. TM and LINQ II TMInsertable cardiac monitors (ICMs), which can be inserted subcutaneously. Such IMDs can facilitate relatively long-term monitoring of patients during normal daily activities and can periodically send collected data, such as detected arrhythmia episodes, to a remote patient monitoring system, such as the Medtronic Carelink TM network.

[0033] Figure 1 is a block diagram illustrating an exemplary system 2 configured to detect health events for patient 4 and to respond to such detections in accordance with one or more techniques of the present disclosure. As used herein, the terms "detection" and the like may refer to detection of an acute health event that patient 4 is currently experiencing (at the time data is collected), as well as detection of data that, based on patient 4's condition, gives them a supra-threshold likelihood of experiencing an event within a particular time frame, e.g., a prediction of an acute health event. The exemplary techniques may be used with one or more patient sensing devices, e.g., IMD 10, that may wirelessly communicate with one or more patient computing devices, e.g., patient computing devices 12A and 12B (collectively, "computing devices 12"). Although in Figure 1 Not illustrated in FIG. 4 , IMD 10 includes electrodes and other sensors to sense physiological signals of patient 4 , and may collect and store sensed physiological data based on the signals and detect an attack based on the data.

[0034] IMD 10 may be implanted outside the chest of patient 4 (e.g., subcutaneously). Figure 1 pectoralis position as illustrated). The IMD 10 can be positioned near the sternum near or just below the level of the heart of the patient 4, for example, at least partially within the outline of the heart. In some examples, the IMD 10 takes the form of a LINQ ICM. Although primarily described in the context of an example in which the IMD 10 takes the form of an ICM, the technology of the present disclosure can be implemented in a system including any one or more implanted or external medical devices, including a monitor, a pacemaker, a defibrillator (e.g., subcutaneous or substernal), a wearable external defibrillator (WAED), a neurostimulator, or a drug pump. In addition, although primarily described in the context of an example including a single implanted patient sensing device, in some examples, the system includes one or more patient sensing devices that can be implanted in the patient 4 or external to the patient 4 (e.g., worn by the patient). For example, a system with two IMDs 10 can capture different values ​​of a common patient parameter with different resolutions / accuracies based on the respective positions of the two IMDs. In some examples, as an alternative or in addition to the two IMDs 10, the system 2 can include a ventricular assist device or WAED in addition to the IMD 10.

[0035] Patient computing device 12 is configured for wireless communication with IMD 10. Computing device 12 retrieves event data and other sensed physiological data collected and stored by IMD 10 from IMD 10. In some examples, computing device 12 takes the form of a personal computing device of patient 4. For example, computing device 12A may take the form of a smartphone of patient 4, and computing device 12B may take the form of a smartwatch or other smart garment of patient 4. In some examples, computing device 12 may be any computing device configured for wireless communication with IMD 10, such as a desktop computer, laptop computer, or tablet computer. Computing device 12 may be configured to communicate with IMD 10 based on, for example, or The Bluetooth Low Energy (BLE) protocol communicates with IMD 10 and each other. In some examples, only one of computing devices 12, such as computing device 12A, is configured to communicate with IMD 10, such as due to executing software capable of communicating and interacting with the IMD (e.g., as part of a health monitoring application as described herein).

[0036] In some examples, computing device 12, such as Figure 1 Wearable computing device 12B in the illustrated example may include electrodes and other sensors to sense physiological signals of patient 4, and may collect and store physiological data and detect seizures based on such signals. Computing device 12B may be incorporated into patient 14's attire, such as within clothing, shoes, glasses, a watch or wristband, a hat, etc. In some examples, computing device 12B is a smartwatch or other accessory or peripheral to smartphone computing device 12A.

[0037] One or more of computing devices 12 may be configured to communicate with various other devices or systems via network 16. For example, one or more of computing devices 12 may be configured to communicate with one or more computing systems (e.g., computing systems 20A and 20B (collectively, “computing systems 20”)) via network 16. Computing systems 20A and 20B may be managed by the manufacturers of IMD 10 and computing device 12, respectively, to provide, for example, cloud storage and analysis of collected data, maintenance and software services, or other networking functionality for their respective devices and their users. In some examples, computing system 20A may include the Medtronic Carelink TM Online or through Medtronic Carelink TM Network to implement. Figure 1In the illustrated example, computing system 20A implements health monitoring system (HMS) 22, but in other examples, either or both of computing systems 20 may implement HMS 22. As will be described in more detail below, HMS 22 facilitates detection of acute health events of patient 4 by system 2 and response of system 2 to such acute health events by system 2.

[0038] The computing device 12 may send data to the computing system 20 via the network 16, including data retrieved from the IMD 10. The data may include: sensory data, such as values ​​of physiological parameters measured by the IMD 10 and, in some cases, one or more computing devices in the computing device 12; data about arrhythmia attacks or other health events detected by the IMD 10 and the computing device 12; and other physiological signals or data recorded by the IMD 10 and / or the computing device 12. The HMS 22 may also retrieve data about the patient 4 from one or more electronic health records (EHR) 24 sources via the network. The EHR 24 may include data about historical (e.g., baseline) physiological parameter values, previous health events and treatments, disease states, comorbidities, demographics, height, weight, and body mass index (BMI) of patients (including the patient 4). The HMS 22 may use data from the EHR 24 to configure algorithms implemented by the IMD 10 and / or the computing device 12 to detect acute health events of the patient 4. In some examples, HMS 22 provides data from EHR 24 to computing device 12 and / or IMD 10 for storage therein and use as part of its algorithms for detecting acute health events.

[0039] Network 16 may include one or more computing devices, such as one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls), intrusion detection, and / or intrusion prevention devices, servers, cellular base stations and nodes, wireless access points, bridges, cable modems, application accelerators, or other network devices. Network 16 may include one or more networks managed by a service provider and may thus form part of a larger public network infrastructure such as the Internet. Network 16 may provide computing devices and systems such as Figure 1 ) provides access to the Internet and may provide a communication framework that allows computing devices and systems to communicate with each other. In some examples, network 16 may include a dedicated network that provides a communication framework that allows Figure 1 The computing devices and systems illustrated in the example communicate with each other, but some of the data flows are isolated from devices outside the private network for security purposes. In some examples, Figure 1 Communications between the computing device and the system illustrated in are encrypted.

[0040] As will be described herein, the IMD 10 may be configured to detect an acute health event, such as SCA, of the patient 4 based on data sensed by the IMD 10 and in some cases based on other data (such as data sensed by the computing devices 12A and / or 12B) and data from the EHR 24. To detect an acute health event, the IMD 10 may apply rules to the data, which may be referred to as patient parameter data. In response to the detection of an acute health event, the IMD 10 may wirelessly send a message to one or both of the computing devices 12A and 12B. The message may indicate that the IMD 10 detected an acute health event of the patient. The message may indicate the time at which the IMD 10 detected the acute health event. The message may include physiological data collected by the IMD 10, such as data causing the detection of the acute health event, data before the detection of the acute health event, and / or real-time or more recent data collected after the detection of the acute health event. The physiological data may include values ​​of one or more physiological parameters and / or digitized physiological signals. Examples of acute health events are SCA, ventricular fibrillation, ventricular tachycardia, myocardial infarction, cardiac arrest (asystole) or pulseless electrical activity (PEA), acute respiratory distress syndrome (ARDS), stroke, seizure, or fall.

[0041] In some examples, detection of an acute health event by IMD 10 may include multiple stages. For example, IMD 10 may complete an initial detection of an acute health event (e.g., SCA or tachyarrhythmia) and initiate wireless communication with computing device 12 in response to the initial detection (e.g., or ). For example, initial detection may occur five to ten seconds after the onset of an acute health event. IMD 10 may continue monitoring to determine whether the acute health event persists, such as continued detection of SCA or tachyarrhythmia. In some examples, IMD 10 may use more patient parameters and / or different rules to determine whether the event persists or otherwise confirm detection.

[0042] Initiating communication with computing device 12 in response to initial detection can help establish communication when an acute health event is confirmed to be ongoing. In order to save power of IMD 10 and computing device 12, IMD 10 can wait to send a message, for example, including sensed data associated with the acute health event, until the acute health event is confirmed to be ongoing, which can be determined approximately thirty seconds after the onset of the event, or after a longer period of time. Less urgent events can have a longer confirmation phase and can be alerted less urgently, such as being alerted as a health care event rather than an acute health event. However, initiating communication after initial detection can still be beneficial for less urgent events. Saving power in the case of a non-rechargeable IMD may be important to extend the life of the IMD before surgical replacement is required, and saving power may be important for a rechargeable IMD or external device to reduce the frequency of recharging.

[0043] Based on the message from IMD 10, computing device 12 may output an alarm, which may be visual and / or audible and configured to immediately attract the attention of patient 4 or anyone accompanying patient 4 in environment 28 (e.g., bystander 26). Additionally or alternatively, computing device 12 may send a warning or alarm message to devices and users outside the visible / audio range of computing device 12 (e.g., to IoT device 30, bystander computing device 42, or HMS 22). As an example, environment 28 may be a home, office, or business premises, or a public place. Warning or alarm messages sent to HMS 22 via network 16, or other messages sent by computing device 12, may include data received from IMD 10 and, in some cases, additional data collected by computing device 12 or other devices in response to detection of an acute health event by IMD 10. For example, a message may include the location of patient 4 determined by computing device 12. In some examples, computing device 12 may further configure or change the content of the warning or alarm message based on the location of patient 4, e.g., different messages may be sent depending on whether patient 4 is at home, another residence, an office or business, a public place, or in a health care facility. The health care required by the patient, and therefore the messaging of system 2, may vary depending on the location of patient 4.

[0044] Other devices in the patient's 4 environment 28 may also be configured to output alarms or take other actions to attract the attention of the patient 4 and possible bystanders 26, or to otherwise facilitate the delivery of care to the patient 4. For example, the environment 28 may include one or more Internet of Things (IoT) devices, such as Figure 1IoT devices 30A to 30D (collectively referred to as "IoT devices 30") are illustrated in the example of FIG. IoT devices 30 may include, for example, so-called "smart" speakers, cameras, televisions, lights, locks, thermostats, appliances, actuators, controllers, or any other smart home (or building) devices. Figure 1 In an example, IoT device 30C is a smart speaker and / or controller, which may include a display. IoT device 30 may provide an audible and / or visual alarm when configured with an output device to do so. As other examples, IoT device 30 may flash or blink smart lights throughout environment 28 and unlock doors. In some examples, IoT device 30 including a camera, microphone, or other sensor may activate those sensors to collect data about patient 4, for example, for use in assessing the condition of patient 4.

[0045] The computing device 12 may be configured to communicate wirelessly with the IoT device 30 to cause the IoT device 30 to take the actions described herein. In some examples, the HMS 22 communicates with the IoT device 30 via the network 16 to cause the IoT device 30 to take the actions described herein, for example, in response to receiving a warning message from the computing device 12 as described above. In some examples, the IMD 10 is configured to communicate wirelessly with one or more of the IoT devices 30, for example, in response to detecting an acute health event when communication with the computing device 12 is unavailable. In such examples, the IoT device 30 may be configured to provide some or all of the functionality attributed to the computing device 12 herein.

[0046] The environment 28 includes a computing facility (e.g., a local network 32), through which the computing device 12, the IoT device 30, and other devices within the environment 28 can communicate with the HMS 22 via the network 16, for example. For example, the environment 28 can be configured with wireless technologies, such as IEEE 802.11 wireless networks, IEEE 802.15 ZigBee networks, ultra-wideband protocols, near-field communications, etc. The environment 28 may include one or more wireless access points, such as wireless access points 34A and 34B (collectively referred to as "wireless access points 34"), to provide support for wireless communications throughout the environment 28. Additionally or alternatively, for example, when the local network is not available, the computing device 12, the IoT device 30, and other devices within the environment 28 can be configured to communicate with the network 16, such as with the HMS 22, via a cellular base station 36 and a cellular network.

[0047] The computing device 12 and, in some examples, the IoT device 30 may include an input device and an interface to allow a user to override the alarm if the IMD 10 detects a false acute health event. In some examples, one or more of the IoT devices in the computing device 12 and the IoT device 30 may implement an event assistant. The event assistant may provide a conversational interface for the patient 4 and / or the bystander 26 to exchange information with the computing device or the IoT device. In response to receiving a warning message from the IMD 10, the event assistant may ask the user about the condition of the patient 4. The response from the user may be used to confirm or override the detection of the acute health event by the IMD 10, or more generally provide additional information about the acute health event or the condition of the patient 4, which may improve the treatment efficacy of the patient 4. For example, the information received by the event assistant may be used to provide an indication of the severity or type (differential diagnosis) of the acute health event. The event assistant may use natural language processing and contextual data to interpret the user's utterances. In some examples, in addition to receiving responses to queries raised by the assistant, the event assistant may be configured to respond to queries raised by the user. For example, Patient 4 may indicate that they feel dizzy and ask the Event Assistant "What should I do?".

[0048] In some examples, computing device 12 and / or HMS 22 may implement one or more techniques to evaluate sensed physiological data received from IMD 10, and in some cases additional physiological or other patient parameter data sensed or otherwise collected by computing device or IoT device 30, to confirm or override detection of an acute health event by IMD 10. In some examples, computing device 12 and / or computing system 20 may have greater processing power than IMD 10, enabling more complex analysis of the data. In some examples, computing device 12 and / or HMS 22 may apply the data to one or more machine learning models or other artificial intelligence developed algorithms, for example, to determine whether the data is sufficient to indicate an acute health event.

[0049] In an example where the computing device 12 is configured to perform an acute health event confirmation analysis, the computing device 12 may output a warning message or send a warning message to the HMS 22 and / or IoT device 30 in response to confirming the acute health event. In some examples, the computing device 12 may be configured to output / send a warning message before completing the confirmation analysis, and output / send a cancellation message in response to overriding the IMD 10's analysis of the detection of the acute health event. The HMS 22 may be configured to perform several operations in response to receiving a warning message from the computing device 12 and / or IoT device 30. The HMS 22 may be configured to cancel such operations in response to receiving a cancellation message from the computing device 12 and / or IoT device 30.

[0050] For example, HMS22 can be configured to send a warning message to one or more computing devices 38 associated with one or more care providers 40 via network 16. Care providers may include emergency medical systems (EMS) and hospitals, and may include specific departments within the hospital, such as emergency departments, catheterization laboratories, or stroke response departments. Computing devices 38 may include smart phones, desktop computers, laptop computers, or tablet computers, or workstations associated with such systems or entities, or employees of such systems or entities. The warning message may include any data collected by IMD 10, computing devices 12, and IoT devices 30, including sensed physiological data, the time of acute health events, the location of the patient 4, and the results analyzed by IMD 10, computing devices 12, IoT devices 30, and / or HMS22. Information sent from HMS22 to care providers 40 can improve the timeliness and effectiveness of the care provider 40's treatment of acute health events of patients 4. In some examples, instead of or in addition to HMS 22 providing a warning message to one or more computing devices 38 associated with EMS care providers 40, computing device 12 and / or IoT device 30 may be configured to automatically contact EMS in response to receiving a warning message from IMD 10, e.g., automatically dialing 911. Again, such an operation may be overridden by patient 4, bystander 26, or another user via a user interface of computing device 12 or IoT device 30, or automatically overridden by computing device 12 based on confirmatory analysis performed by the computing device that overrides IMD 10's detection of an acute health event.

[0051] Similarly, HMS22 can be configured to send a warning message to a computing device 42 of a bystander 26, which can improve the timeliness and effectiveness of the bystander 26's treatment of an acute health event of a patient 4. The computing device 42 can be similar to the computing device 12 and the computing device 38, such as a smart phone. In some examples, the HMS22 can determine that the bystander 26 is close to the patient 4 based on, for example, the location of the patient 4 received from the computing device 12 and the location of the computing device 42 reported to the HMS22 by, for example, an application implemented on the computing device 42. In some examples, the HMS22 can send a warning message to any computing device 42 in a warning area determined based on the location of the patient 4, for example, by sending a warning message to all computing devices in communication with the base station 36 using any networking method described herein.

[0052] In some examples, the warning message to bystander 26 can be configured to assist a layperson in treating a patient. For example, the warning message to bystander 26 can include the location of patient 4 (and in some cases a description), the general nature of the acute health event, instructions for providing care to patient 4 (such as instructions for providing cardiopulmonary resuscitation (CPR)), the location of nearby medical equipment for treating patient 4 (such as an automated external defibrillator (AED) 44 or a life jacket), and instructions for use of the equipment. In some examples, computing device 12, IoT device 30, and / or computing device 42 can implement an event assistant that is configured to use natural language processing and / or contextual data to provide a conversational interface for bystander 42. The assistant can provide instructions to bystander 26 for providing care to patient 4 and respond to inquiries from bystander 26 about how to provide care to patient 4.

[0053] In some examples, HMS 22 can mediate two-way audio (and in some cases video) communications between a care provider 40 and a patient 4 or bystander 26. Such communications can allow the care provider 40 to assess the condition of the patient 4 before the care provider will begin caring for the patient, for example, by communicating with the patient 4 or bystander 26 or by using a camera or other sensor of a computing device or IoT device, which can improve the efficacy of the care delivered to the patient. Such communications can also allow the care provider to instruct a bystander 42 about first responder treatment of the patient 4.

[0054] In some examples, HMS22 can control the dispatching of drone 46 to environment 28, or to a location near environment 28 or patient 4. Drone 46 can be a robot and / or unmanned aerial vehicle (UAV). Drone 46 can be equipped with multiple sensors and / or actuators to perform multiple operations. For example, drone 46 can include a camera or other sensor to navigate to its expected location, identify patient 4 and in some cases identify bystander 26, and assess the patient's condition. In some examples, drone 46 may include a user interface device that communicates with patient 4 and / or bystander 26. In some examples, drone 46 can provide instructions to bystander 26, to the location of patient 4, and can provide instructions on how to provide first responder care (such as CPR) to patient 4. In some examples, drone 46 can carry medical equipment (e.g., AED 44) and / or medicine to the location of patient 4.

[0055] Any of the IMD 10, computing device 12, IoT device 30, computing devices 38 and 42, AED 44, drone 46, or HMS 22 may perform the operations described herein for detecting acute health events (such as SCA) individually or in any combination by applying rules that may include one or more machine learning models to patient parameter data to detect acute health events. For example, one of these devices or more than one of these devices in collaboration may apply a first set of rules to patient parameter data for making a first determination of whether an acute health event is detected, and determine whether to apply a second set of rules to the patient parameter data to determine whether an acute health event is detected based on whether one or more contextual criteria associated with the first determination are met.

[0056] Figure 2 is an example Figure 1 A block diagram of an exemplary configuration of an IMD 10 is shown. Figure 2 As shown, IMD 10 includes processing circuitry 50 , memory 52 , sensing circuitry 54 coupled to electrodes 56A and 56B (hereinafter “electrodes 56 ”) and one or more sensors 58 , and communication circuitry 60 .

[0057] The processing circuit 50 may include fixed function circuits and / or programmable processing circuits. The processing circuit 50 may include any one or more of the following: a microprocessor, a controller, a graphics processing unit (GPU), a tensor processing unit (TPU), a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or an equivalent discrete or analog logic circuit. In some examples, the processing circuit 50 may include multiple components (such as any combination of one or more microprocessors, one or more controllers, one or more GPUs, one or more TPUs, one or more DSPs, one or more ASICs, or one or more FPGAs), as well as other discrete or integrated logic circuits. The functions attributed to the processing circuit 50 herein may be embodied as software, firmware, hardware, or any combination thereof. In some examples, the memory 53 includes computer readable instructions that, when executed by the processing circuit 50, cause the IMD 10 and the processing circuit 50 to perform various functions attributed to the IMD 10 and the processing circuit 50 herein. Memory 53 may include any volatile, nonvolatile, magnetic, optical, or electrical media, such as random access memory (RAM), read-only memory (ROM), nonvolatile RAM (NVRAM), electrically erasable programmable ROM (EEPROM), flash memory, or any other digital media.

[0058] Sensing circuitry 54 may monitor signals from electrodes 56 to, for example, monitor electrical activity of the heart of patient 4 and generate ECG data of patient 4. In some examples, processing circuitry 50 may identify features of the sensed ECG, such as heart rate, heart rate variability, T wave alternans, intra-heartbeat intervals (e.g., QT intervals), and / or ECG morphology features, to detect an onset of an arrhythmia in patient 4. Exemplary processing circuitry 50 may store the digitized ECG and features of the ECG used to detect an arrhythmia onset in memory 52 as onset data of a detected arrhythmia onset.

[0059] In some examples, sensing circuitry 54 measures, for example, impedance of tissue proximate to IMD 10 via electrodes 56. The measured impedance may vary based on respiration, cardiac pulse or flow, and the degree of perfusion or edema. Processing circuitry 50 may determine physiological data related to respiration, cardiac pulse or flow, perfusion, and / or edema based on the measured impedance.

[0060] In some examples, the IMD 10 includes one or more sensors 58, such as one or more accelerometers, gyroscopes, microphones, optical sensors, temperature sensors, pressure sensors, and / or chemical sensors. In some examples, the sensing circuit 52 may include one or more filters and amplifiers for filtering and amplifying signals received from one or more of the electrodes 56 and / or sensors 58. In some examples, the sensing circuit 54 and / or the processing circuit 50 may include a rectifier, a filter and / or an amplifier, a sensing amplifier, a comparator, and / or an analog-to-digital converter. The processing circuit 50 may determine physiological data (e.g., physiological parameter values ​​of the patient 4) based on signals from the sensors 58, which may be stored in the memory 52. ​​Patient parameters determined based on signals from the sensors 58 may include oxygen saturation, glucose levels, stress hormone levels, heart sounds, body movements, body posture, or blood pressure.

[0061] The memory 52 may store applications 70 and data 80 that may be executed by the processing circuit 50. The application 70 may include an acute health event monitoring application 72. The processing circuit 50 may execute the event monitoring application 72 to detect acute health events of the patient 4 based on a combination of one or more types of physiological data described herein, which may be stored as sensed data 82. In some examples, the sensed data 82 may additionally include patient parameter data sensed by other devices (e.g., a computing device 12 or an IoT device 30) and received via the communication circuit 60. The event monitoring application 72 may be configured with a rule engine 74. The rule engine 74 may apply rules 84 to the sensed data 82. The rule 84 may include one or more models, algorithms, decision trees, and / or thresholds. In some cases, the rule 84 may be developed based on machine learning, for example, may include one or more machine learning models.

[0062] As an example, the event monitoring application 72 can detect SCA, ventricular fibrillation, ventricular tachycardia, supraventricular tachycardia (e.g., conducted atrial fibrillation), ventricular arrest, or myocardial infarction based on ECG and / or other patient parameter data indicating electrical or mechanical activity of the heart of the patient 4. In some examples, the event monitoring application 72 can detect a stroke based on such cardiac activity data. In some examples, the sensing circuit 54 can detect brain activity data, such as an electroencephalogram (EEG), via electrodes 56, and the event monitoring application 72 can detect a stroke or epilepsy based solely on brain activity or in combination with cardiac activity data or other physiological data. In some examples, the event monitoring application 72 detects whether the patient has fallen based solely on data from an accelerometer or in combination with other physiological data. When the event monitoring application 72 detects an acute health event, the event monitoring application 72 can store the sensing data 82 that caused the detection (and in some cases, the data window before and / or after the detection) as event data 86 (also referred to herein as seizure data).

[0063] In some examples, in response to detection of an acute health event, processing circuitry 50 sends a signal to computing device 12 ( Figure 1 ) sends event data 86 of the event. The transmission may be included in a message indicating an acute health event, as described herein. The transmission of the message may occur on an ad hoc basis and as quickly as possible. The communication circuitry 60 may include any suitable hardware, firmware, software, or any combination thereof for wirelessly communicating with another device, such as the design device 12 and / or the IoT device 30.

[0064] Figure 3 is a block diagram illustrating an exemplary configuration of a computing device 12 of a patient 4, which may correspond to Figure 1Any one of the illustrated computing devices 12A and 12B (or both computing devices operating in coordination). In some examples, computing device 12 takes the form of a smartphone, laptop, tablet, personal digital assistant (PDA), smart watch, or other wearable computing device. In some examples, IoT device 30, computing devices 38 and 42, AED 44, and / or drone 46 may be similar to Figure 3 The configuration of the computing device 12 illustrated in FIG.

[0065] like Figure 3 As shown in the example of , the computing device 12 can be logically divided into a user space 102, a kernel space 104, and hardware 106. The hardware 106 may include one or more hardware components that provide an operating environment for components executed in the user space 102 and the kernel space 104. The user space 102 and the kernel space 104 may represent different sections or segments of memory, wherein the kernel space 104 provides higher privileges to processes and threads than the user space 102. For example, the kernel space 104 may include an operating system 120 that operates with higher privileges than components executed in the user space 102.

[0066] like Figure 3 As shown, hardware 106 includes processing circuitry 130, memory 132, one or more input devices 134, one or more output devices 136, one or more sensors 138, and communication circuitry 140. Although for purposes of illustration, Figure 3 1 is shown as a standalone device, but the computing device 12 may be any component or system including a processing circuit or other suitable computing environment for executing software instructions, and does not necessarily include, for example, Figure 3 One or more elements shown.

[0067] Processing circuitry 130 is configured to implement functions and / or processing instructions for execution within computing device 12. For example, processing circuitry 130 may be configured to receive and process instructions stored in memory 132 that provide functionality for components included in kernel space 104 and user space 102 to perform one or more operations in accordance with the techniques of this disclosure. Examples of processing circuitry 130 may include any one or more microprocessors, controllers, GPUs, TPUs, DSPs, ASICs, FPGAs, or equivalent discrete or integrated logic circuits.

[0068] Memory 132 may be configured to store information within computing device 12 for processing during operation of computing device 12. In some examples, memory 132 is described as a computer-readable storage medium. In some examples, memory 132 includes temporary memory or volatile memory. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, memory 132 also includes one or more memories configured for long-term storage of information, such as non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or electrically erasable and programmable (EEPROM) memory. In some examples, memory 132 includes a storage device associated with a cloud.

[0069] One or more input devices 134 of computing device 12 may receive input, for example, from patient 4 or another user. Examples of input are tactile, audio, dynamic, and optical input. As examples, input device 134 may include a mouse, keyboard, voice response system, camera, button, control pad, microphone, presence-sensitive or touch-sensitive component (e.g., screen), or any other device for detecting input from a user or machine.

[0070] One or more output devices 136 of computing device 12 may generate output, for example, to patient 4 or another user. Examples of output are tactile output, haptic output, audio output, and visual output. Output devices 134 of computing device 12 may include a presence-sensitive screen, a sound card, a video graphics adapter card, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), a light emitting diode (LED), or any type of device for generating tactile, audio, and / or visual output.

[0071] One or more sensors 138 of computing device 12 may sense physiological parameters or signals of patient 4. Sensors 138 may include electrodes, axis accelerometers (e.g., 3-axis accelerometers), optical sensors, impedance sensors, temperature sensors, pressure sensors, heart sound sensors (e.g., microphones), and other sensors, as well as sensing circuits (e.g., including ADCs), similar to those described above with respect to IMD 10 and Figure 2 Those described.

[0072] The communication circuitry 140 of the computing device 12 may communicate with other devices by sending and receiving data. The communication circuitry 140 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that can send and receive information. For example, the communication circuitry 140 may include a radio transceiver configured for use in accordance with a wireless communication protocol such as 3G, 4G, 5G, WiFi (e.g., 802.11 or 802.15 ZigBee), or Low Energy (BLE) and other standards or protocols.

[0073] like Figure 3 As shown, the health monitoring application 150 is executed in the user space 102 of the computing device 12. The health monitoring application 150 can be logically divided into a presentation layer 152, an application layer 154, and a data layer 156. The presentation layer 152 can include a user interface (UI) component 160 that generates and presents a user interface of the health monitoring application 150.

[0074] The application layer 154 may include, but is not limited to, an event engine 170, a rule engine 172, a rule configuration component 174, an event assistant 176, and a location service 178. The event engine 172 may be responsive to receiving an alert transmission from the IMD 10 indicating that the IMD 10 has detected an acute health event. The event engine 172 may control the performance of any operations in response to detecting an acute health event attributed herein to the computing device 12, such as initiating an alarm, sending an alert message to the HMS 22, controlling the IoT device 30, and analyzing data to confirm or override the IMD 10's detection of an acute health event.

[0075] Rules engine 174 analyzes sensed data 190, and in some examples, patient input 192 and / or EHR data 194, to determine if there is a sufficient likelihood that patient 4 is experiencing an acute health event detected by IMD 10. Sensed data 190 may include data received from IMD 10 as part of an alert transmission, additional data sent from IMD 10 (e.g., in "real time"), and physiological and other data related to the condition of patient 4 collected by, for example, computing device 12 and / or IoT device 30. As an example, sensed data 190 from computing device 12 may include one or more of the following: activity level, walking / running distance, resting energy, active energy, exercise minutes, quantification of standing, physical fitness, body mass index, heart rate, low heart rate events, high heart rate events and / or irregular heart rate events, heart rate variability, walking heart rate, heart beat series, digitized ECG, blood oxygen saturation, blood pressure (systolic and / or diastolic), respiratory rate, maximum oxygen volume, blood glucose, peripheral perfusion, and sleep patterns.

[0076] Patient input 192 may include responses to inquiries posed by health monitoring application 150 regarding the condition of patient 4, input by patient 4 or another user, such as bystander 26. Inquiries and responses may occur in response to detection of an event by IMD 10, or may have occurred prior to detection, such as as part of long-term monitoring of the health of patient 4. User-recorded health data may include one or more of the following: exercise and activity data, sleep data, symptom data, medical history data, quality of life data, nutritional data, medication taking or compliance data, allergy data, demographic data, weight, and height. EHR data 194 may include any of the information about the patient's 4 historical condition or treatment described above. The EHR data 194 may relate to SCA, tachyarrhythmia, myocardial infarction, stroke, seizure, one or more conditions (such as heart failure chronic obstructive pulmonary disease (COPD), renal dysfunction or hypertension), aspects of the condition (such as ECG characteristics, cardiac ischemia, oxygen saturation, lung fluid, activity or metabolic levels), genetic conditions, congenital malformations, history of surgery (such as ablation or cardioversion), and history of healthcare utilization. The EHR data 194 may also include cardiac indicators such as ejection fraction and left ventricular wall thickness. The EHR data 194 may also include demographic and other information of the patient 4, such as age, gender, race, height, weight, and BMI.

[0077] Rules engine 172 may apply rules 196 to the data. Rules 196 may include one or more models, algorithms, decision trees, and / or thresholds. In some cases, rules 196 may be developed based on machine learning, for example, may include one or more machine learning models. In some examples, operation of rules 196 and rules engine 172 may provide a more complex analysis of patient parameter data (e.g., data received from IMD 10) than provided by rules engine 74 and rules 84. In examples where rules 196 include one or more machine learning models, rules engine 172 may apply feature vectors derived from the data to the model.

[0078] Rules configuration component 174 may be configured to modify rules 196 (and in some examples, rules 84) based on feedback indicating whether the detection and confirmation of acute health events by IMD 10 and computing device 12 are accurate. Feedback may be received from patient 4 or from care provider 40 and / or EHR 24 via HMS 22. In some examples, rules configuration component 174 may utilize a data set from true and false detection and confirmation for supervised machine learning to further train a model included as part of rules 196.

[0079] The rule configuration component 174, or another component executed by the processing circuitry of the system 2, can select a configuration of the rules 196 based on the etiology data of the patient (e.g., any combination of one or more of the examples of sensory data 190, patient input 192, and EHR data 194 discussed above). In some examples, different rule groups 196 customized for different groups of patients can be used to select for the patient 4 based on such etiology data.

[0080] As described above, event assistant 176 can provide a conversational interface for patient 4 and / or bystander 26 to exchange information with computing device 12. In response to receiving a warning message from IMD 10, event assistant 176 can ask the user about the condition of patient 4. The response from the user can be included as patient input 192. Event assistant 176 can use natural language processing and contextual data to interpret the user's words. In some examples, in addition to receiving responses to queries raised by the assistant, event assistant 176 can be configured to respond to queries raised by the user. In some examples, event assistant 176 can provide instructions to and respond to inquiries from patient 4 or bystander 26 about the treatment of patient 4.

[0081] Location service 178 may determine the location of computing device 12, and thereby determine the estimated location of patient 4. Location service 178 may use Global Positioning System (GPS) data, multilateration, and / or any other known technique for locating a computing device.

[0082] Figure 4 is a block diagram illustrating an operational perspective of HMS 22. HMS 22 may be implemented in computing system 20, which may include hardware components embodied in one or more physical devices, such as hardware components of computing device 12, eg, processing circuitry, memory, and communication circuitry. Figure 4 Provides an operational perspective of the HMS 22 when hosted as a cloud-based platform. Figure 4 In the example of FIG. 1 , the components of HMS 22 are arranged according to multiple logical layers that implement the technology of the present disclosure. Each layer can be implemented by one or more modules including hardware, software, or a combination of hardware and software.

[0083] Computing devices such as computing device 12, IoT device 30, computing device 38, and computing device 42 operate as clients that communicate with HMS 22 via interface layer 200. Computing devices typically execute client software applications, such as desktop applications, mobile applications, and web applications. Interface layer 200 represents a set of application programming interfaces (APIs) or protocol interfaces provided and supported by HMS 22 for client software applications. Interface layer 200 can be implemented with one or more web servers.

[0084] like Figure 4 As shown, HMS22 also includes an application layer 202, which represents a collection of services 210 for implementing the functionality attributed to HMS in this article. The application layer 202 receives information from client applications, for example, receives warnings of acute health events from computing devices 12 or IoT devices 30, and further processes the information according to one or more services in the service 210 to respond to the information. The application layer 202 can be implemented as one or more discrete software services 210 executed on one or more application servers (e.g., physical or virtual machines). That is, the application server provides a runtime environment for executing the service 210. In some examples, the functionality of the functional interface layer 200 and the application layer 202 as described above can be implemented at the same server. The service 210 can communicate via a logical service bus 212. The service bus 212 generally represents a logical interconnection or a set of interfaces that allow different services 210 to send messages to other services such as through a publish / subscribe communication model.

[0085] The data layer 204 of the HMS 22 provides persistence for information in the PPEMS 6 using one or more data repositories 220. The data repository 220 can generally be any data structure or software that stores and / or manages data. Examples of data repositories 220 include, but are not limited to, relational databases, multidimensional databases, maps, and hash tables, to name a few.

[0086] like Figure 4 As shown, each of services 230 to 238 is implemented in a module form within HMS22. Although shown as a separate module for each service, in some examples, the functionality of two or more services can be combined into a single module or component. Each of services 230 to 238 can be implemented in software, hardware, or a combination of hardware and software. In addition, services 230 to 238 can be implemented as independent devices, separate virtual machines or containers, processes, threads, or software instructions generally for execution on one or more physical processors.

[0087] The event processor service 230 can be responsive to receiving an alert transmission from the computing device 12 and / or IoT device 30 indicating that the IMD 10 detected an acute health event for the patient and, in some examples, indicating that the sending device confirms the detection. The event processor service 230 can initiate the performance of any operations in response to the detection of an acute health event attributed herein to the HMS 22, such as communicating with the patient 4, bystanders 26, and care providers 40, launching the drone 46, and in some cases analyzing data to confirm or override the IMD 10's detection of the acute health event.

[0088] Record management service 238 may store patient data included in received alert messages within event record 252. Alert service 232 may package some or all of the data from the event record (in some cases with additional information as described herein) into one or more alert messages for transmission to bystanders 26 and / or care providers 40. Caregiver data 256 may store data used by alert service 232 to identify to whom to send alerts based on the location of potential bystanders 26 and caregivers 40 relative to the location of patient 4 and / or the suitability of the care provided by caregiver 40 to the acute health event experienced by patient 4.

[0089] In an example where HMS 22 performs analysis to confirm or override IMD 10's detection of an acute health event, event processor service 230 may apply one or more rules 250 to data received in a warning message, such as a feature vector derived from the data by event processor service 230, or raw data, such as a digitized ECG or other waveform. Rule 250 may include one or more models, algorithms, decision trees, and / or thresholds that may be developed by rule configuration service 234 based on machine learning. Exemplary machine learning techniques that may be used to generate rule 250 (as well as rule 84 and / or 196) may include various learning styles, such as supervised learning, unsupervised learning, and semi-supervised learning. Exemplary types of algorithms include Bayesian algorithms, clustering algorithms, decision tree algorithms, regularization algorithms, regression algorithms, example-based algorithms, artificial neural network algorithms, deep learning algorithms, dimensionality reduction algorithms, and the like. Various examples of specific algorithms include Bayesian linear regression, boosted decision tree regression and neural network regression, back-propagation neural network, convolutional neural network (CNN), long short-term network (LSTM), prior algorithm, K-means clustering, K-nearest neighbors (kNN), learning vector quantization (LVQ), self-organizing map (SOM), locally weighted learning (LWL), ridge regression, least absolute shrinkage and selection operator (LASSO), elastic net and least angle regression (LARS), principal component analysis (PCA), and principal component regression (PCR).

[0090] In some examples, in addition to the rules used by HMS22 to confirm the detection of acute health events (or in examples where HMS22 does not confirm the detection of events), the rules 250 maintained by HMS22 may include the rules 196 utilized by the computing device 12 and the rules 84 used by IMD 10. In such examples, the rule configuration service 250 may be configured to develop and maintain the rules 196 and the rules 84. The rule configuration service 234 may be configured to develop different rule groups 84, 196, 250 for different patient groups, such as different machine learning models. The rule configuration service 234 may be configured to modify these rules based on event feedback data 254 indicating whether the detection and confirmation of acute health events by IMD10, computing device 12 and / or HMS22 are accurate. The event feedback 254 may be received from the patient 4, for example, via the computing device 12, or from the care provider 40 and / or EHR 24. In some examples, rule configuration service 234 can utilize event records from true and false detection (as indicated by event feedback data 254) and confirmation of supervised machine learning to further train a model included as part of rules 250.

[0091] like Figure 4 As illustrated in the example of , the service 210 may also include an assistant configuration service 236 for configuring and interacting with an event assistant 176 implemented in the computing device 12 or other computing devices. For example, the assistant configuration service 236 may provide updates to the event assistant to its natural language processing and contextual analysis to improve its operation over time. In some examples, the assistant configuration service 236 may apply machine learning techniques to analyze the sensed data and event assistant interactions stored in the event record 252 and the final disposition of the event, such as indicated by the EHR 24, to modify the operation of the event assistant, such as for the patient 4, a class of patients, all patients, or for a specific user or device (e.g., a caregiver, bystander, etc.).

[0092] Figure 5 is a flow chart illustrating example operations for applying rules to patient parameter data to determine whether an acute health event is detected. Figure 5 The exemplary operations may be performed by processing circuitry of any of the IMD 10, computing device 12, 38, 42, IoT device 30, AED 44, drone 46, or HMS 22 (e.g., by processing circuitry 50 or 130 that implements the rule engine 74 or 172 and applies rules 84 or 196), or by processing circuitry of two or more of these devices that separately perform portions of the exemplary operations.

[0093] according to Figure 5In an example of, processing circuitry applies a first set of rules to first patient parameter data for a first determination (300) of whether an acute health event (e.g., SCA) is detected. The processing circuitry determines whether one or more contextual criteria associated with the first determination are satisfied (302). If the one or more contextual criteria are not satisfied (“No” of 302), the processing circuitry may determine, based on the first determination, whether an acute health event is detected (304). If an acute health event is detected (“Yes” of 304), the processing circuitry may generate an alert, such as a message to another device and / or a user-perceivable alert as described herein (306). If no acute health event is detected (“No” of 304) or an alert has been generated, then Figure 5 The exemplary operation of can end. If one or more contextual criteria are satisfied ("yes" of 302), the processing circuit can apply a second set of rules to the second patient parameter data for a second determination of whether an acute health event (e.g., SCA) is detected (308), and determine whether an acute health event is detected based on the second determination (304).

[0094] The first set of rules and the second set of rules are different in at least one aspect. In some examples, the second set of rules includes at least one machine learning model. In some examples, both the first set of rules and the second set of rules include at least one machine learning model.

[0095] In some examples, the processing circuit determines a risk score for an acute health event (e.g., SCA) based on applying the first set of rules to the first patient parameter data, and compares the risk score to a threshold to determine whether one or more contextual criteria are met. In some examples, the context indicating that the second set of rules should be applied to the second patient parameter data can be that the risk score resulting from the first determination does not meet a threshold with sufficient certainty that an acute health event is occurring. The risk score can be a percentage likelihood of the acute health event.

[0096] In some examples, the processing circuit determines a confidence level of a first determination of whether an acute health event is detected, and compares the confidence level to a threshold. In some examples, one or more contextual criteria may be satisfied where the first determination does not have a threshold confidence level, or where the first determination is associated with a likelihood of being a false positive that exceeds a threshold. In such examples, when the first determination is not credible, applying the second set of rules to the second patient parameter data may act as a “tiebreaker.” In some examples, when input from a user (e.g., a patient) contradicts the first determination (e.g., an acute health event is detected or not detected), the processing circuit determines that one or more contextual criteria are satisfied, thereby indicating that the likelihood that the first determination is false may be relatively high.

[0097] The processing circuitry may determine a first determined confidence level of whether an acute health event exists using a variety of techniques. For example, applying a first set of rules to the first patient parameter data may produce a confidence level through its output (e.g., a risk score). In such examples, a higher output indicating a higher likelihood of an acute health event may indicate a higher level of confidence. Examples of rules that may produce such outputs include machine learning models and time-domain signal processing algorithms.

[0098] In some examples, the processing circuit may determine the noise level of one or more signals (based on which the first patient parameter data is determined). In such examples, the processing circuit may determine a first determined confidence level of whether an acute health event exists based on the noise level. Typically, the confidence level and the noise level may be inversely related. In some examples, the processing circuit may determine the confidence level based on the health record data of the patient 4. For example, if a clinician has indicated in the health record or via programming the IMD 10 that the patient 4 has experienced a myocardial infarction or has heart failure, the confidence level may be increased and / or the threshold value included in the rule applied to the first patient parameter data may be lowered.

[0099] In some examples, the contextual criteria may be satisfied when a component of system 2 (e.g., IMD 10 or computing device 12) has sufficient power to enable application of the second set of rules to the second patient parameter data. In some examples, to determine whether one or more contextual criteria are satisfied, processing may determine a power level of system 2 (e.g., an associated device) and compare a power level threshold. In some examples, the second patient parameter data includes data for at least one patient parameter that is not included in the first patient parameter data. In some examples, the processing circuit activates a sensor to sense the patient parameter, e.g., when the device including the sensor has sufficient power for measurement.

[0100] In some examples, both the first patient parameter data and the second patient parameter data are sensed by an implantable medical device. In some examples, at least one patient parameter included in the second patient parameter data but not included in the first patient parameter data is sensed by an external device. In some examples, the processing circuit 50 of the IMD 10 or the processing circuit 130 of the computing device 12 (or the IoT device 30 or other devices discussed herein) performs each of the sub-operations 300-308. In other examples, the processing circuit 50 of the IMD 10 performs a first determination (300) of whether an acute health event (e.g., SCA) is detected, and the processing circuit 130 of the computing device 12 (or the IoT device 30 or other devices discussed herein) performs each of the sub-operations 302-308.

[0101] In some examples, the first patient parameter data includes at least one patient parameter determined from ECG data, and the at least one patient parameter includes a patient parameter determined from at least one of the patient's heart sounds, the patient's impedance, the patient's movement (e.g., whether a fall has occurred or is suspected), the patient's breathing, the patient's posture, the patient's blood pressure, a chemical detected in the patient's body, or an optical signal from the patient. In some examples, the first patient parameter data and the second patient parameter data can be determined using different combinations of sensors (e.g., internal sensors and / or external sensors). The first determination and the second determination can be considered as different layers, where the second determination utilizes additional sensors, data, and / or power if the context suggests that it would be desirable to supplement the first determination.

[0102] In some examples, the processing circuit selects at least one of the second set of rules or parameters for the second patient parameter data based on at least one of the user (e.g., patient or caregiver or bystander) input or the patient's medical record information. In some examples, the user input and / or medical history information may include information entered by a clinician when programming the IMD 10. For example, the processing circuit may select at least one of the second set of rules or parameters for the second patient parameter data based on user input or medical record information indicating a particular symptom or condition of the patient. In some examples, the first patient parameter data includes data for the first set of patient parameters, and the processing circuit may select at least one of the second set of rules or second patient parameters for the second patient parameter data based on the level. The level of a specific parameter that is clinically significant but opposite to the first determination (detection or non-detection) may suggest that a second determination should be performed, and a specific parallel (but different) or orthogonal patient parameter is applied to perform the second determination to resolve uncertainty about whether an acute health event is detected.

[0103] In some examples, the first patient parameter data includes at least one patient parameter determined from the patient's ECG data, and the second patient parameter data includes at least one of a morphological change or a frequency shift in the ECG data over time. The processing circuit can analyze the timing or morphological changes in the ECG data. For example, the morphological or frequency changes when ventricular fibrillation persists can indicate an increased lethality of ventricular fibrillation. In some examples, the processing circuit applying the rules can determine a higher likelihood of an acute health event (e.g., lethal ventricular fibrillation or SCA), the presence of such a morphological or frequency shift.

[0104] Figure 5The exemplary operations may produce a hierarchy of rules or even sensor measurements. In some examples, one or more sensors may be activated in certain contexts, and the first determination of whether an acute health event is detected may be inactive, for example to save power to the IMD 10. For example, if in the first determination, the ECG data indicates ventricular fibrillation and the other sensor data indicates no pulse and no heart sounds, then the second determination may not be needed. However, if the level of evidence is not high, for example, it is uncertain whether ventricular fibrillation is clear, such as a weak heart sound, a weak pulse, a fall, or a change in gait, then the second determination may be used.

[0105] In addition, the rules and sensors used in either or both of the first determination and the second determination can be configured / personalized for each patient based on the patient's medical history from the EMR or the patient's history of prior events, or by the patient's physician / caregiver as appropriate. For example, if the caregiver must leave town for a few days, the processing circuitry can, for example, automatically configure rules to be satisfied by lower levels of evidence, which can advantageously customize the monitoring provided by the system 2 to the context of the patient 4 and the patient's caregiver.

[0106] Figure 6 is a flow chart illustrating another example operation for applying rules to patient parameter data to determine whether an acute health event is detected. Figure 6 The example operations may be performed by processing circuitry of any of the IMD 10, computing device 12, 38, 42, IoT device 30, AED 44, drone 46, or HMS 22 (e.g., by processing circuitry 50 or 130 that implements the rule engine 74 or 172 and applies rules 84 or 196), or by processing circuitry of two or more of these devices that respectively perform portions of the example operations.

[0107] according to Figure 6 In an example of, processing circuitry applies a set of rules to patient parameter data to determine whether an acute health event, such as SCA, is detected (320). The processing circuitry determines whether one or more contextual criteria associated with the determination are satisfied (322). If one or more contextual criteria are not satisfied (“No” of 322), the processing circuitry may determine, based on the determination, whether an acute health event is detected (324). If an acute health event is detected (“Yes” of 324), the processing circuitry may generate an alert, such as a message to another device and / or a user-perceivable alert as described herein (326). If no acute health event is detected (“No” of 324) or an alert has been generated, then Figure 6The exemplary operation can end. If one or more contextual criteria are met ("yes" of 322), the processing circuit can apply to modify the rule set (328), apply the second patient parameter data to the second set of rules (330), and determine whether an acute health event is detected based on applying the second patient parameter data to the second set of rules (324).

[0108] The processing circuit can refer to Figure 5 The processing circuitry may determine whether one or more contextual criteria are satisfied in a manner described herein. In some examples, the first patient parameter data and the second patient parameter data may be determined from the same patient parameter or different patient parameters (with respect to at least one parameter). In some examples, the first patient parameter data and the second patient parameter data include at least one common patient parameter, and the processing circuitry may change the mode sensing for the common patient parameter between the first patient parameter data and the second patient parameter data in response to satisfaction of the one or more contextual criteria. For example, the processing circuitry may change the sampling frequency for the common patient parameter.

[0109] In some examples in which the IMD 10 senses a patient parameter for determining first patient parameter data, the processing circuitry may determine that the contextual criteria are satisfied by detecting that the IMD 10 has been flipped over or otherwise migrated within the patient 4. Such migration may result in significant changes in patient parameter data (e.g., ECG data, impedance data, or heart sound data). Changing the mode employed by the IMD 10 to sense one or more patient parameters, or changing the rules to account for changes in patient parameter data caused by device migration, may help improve device migration and maintain effective acute health event detection. In addition to sensing modes and / or rules, the processing circuitry may also adjust other aspects of the system, such as wireless communication modes between the IMD and other devices. Techniques for detecting and mitigating IMD 10 migration are described in commonly assigned U.S. patent application Ser. No. 17 / 101,945, filed by Anderson et al. on November 23, 2020, entitled “DETECTION AND MITIGATION OF ACCURACY SENSING BY AN IMPLANTED SENSOR OF A MEDICAL SYSTEM,” the entire contents of which are incorporated herein by reference.

[0110] In some examples, the processing circuitry determines that one or more contextual criteria are satisfied when the processing circuitry determines that an acute health event (e.g., ventricular tachyarrhythmia or SCA) is detected but the patient or another user cancels the alarm or otherwise provides user input that contradicts the determination. In such examples, the processing circuitry may modify one or both of the sensed patient parameters or the rules applied to the patient parameter data.

[0111] For example, a patient may have tolerated a rapid ventricular tachycardia that lasts for a duration (e.g., a programmed 10 or 20 seconds), but may soon experience another arrhythmia, such as syncope, even though the patient thinks they are fine. Modifications can include adjusting the rules based on the rhythm. Sometimes prolonged episodes accelerate ventricular fibrillation or faster ventricular tachycardia. Sometimes ventricular fibrillation slows down. In either case, modifications can include changing the heart rate threshold, for example, applying hysteresis to the heart rate threshold. In some examples, ventricular fibrillation becomes difficult to sense. In such examples, modifications can include changing the ventricular depolarization detection threshold to allow for a lower degree of sensing of depolarization.

[0112] In some examples, the processing circuit determines that one or more contextual criteria are met based on a recent history of high arrhythmia load. Some patients suffer from electrical storms. Their electrolytes may be unbalanced, and they may experience a series of ventricular arrhythmias, but the patient parameter data may not meet the rules for detecting acute health events. In such cases, the processing circuit can adjust the tachyarrhythmia duration threshold, can alert the patient and caregiver and notify them to seek care ASAP, and / or can alert the clinician and send the patient parameter data, such as ECG data, so the clinician can review it.

[0113] Figure 7 is a flow diagram illustrating example operations for configuring rules that are applied to patient parameter data to determine whether an acute health event is detected for a patient. Figure 7 The exemplary operations of may be performed by a processing circuit implementing HMS 22 (e.g., implementing rule configuration service 234). In some examples, Figure 7 The operations may be performed by processing circuitry (e.g., an implementation rule configuration module) of any one of the IMD 10, computing device 12, 38, 42, IoT device 30, AED 44, drone 46, or HMS 22, or by processing circuitry of two or more of these devices that respectively perform portions of the exemplary operations.

[0114] according to Figure 7In an exemplary operation of the present invention, the processing circuit determines whether an acute health event, such as an SCA, is detected (340). The processing circuit receives feedback for the event (342). The feedback indicates whether the detection is a true positive or a false positive, or whether the non-detection is a true negative or a false negative. The processing circuit can receive feedback from the patient 4, the caregiver 40, the bystander 26, or the EHR 24. The processing circuit updates the rules (e.g., rules 84, rules 196, and / or rules 250) based on the feedback and the event data (e.g., event data 86 or event record 252). In some examples, the event data is used as a training set for one or more machine learning models based on the feedback.

[0115] The operation of the system for providing warnings for SCA can be improved through predictive and "self-learning" techniques. Treatment time (CPR or shock from AED 44) can be improved by providing timely warnings to bystanders 26 or EMS caregivers 40. Information used to improve execution can include physiological sensor data that can indicate the possibility of an SCA event (QT prolongation, T wave alternations, changes in respiratory rate or chest impedance, history of PVC or non-sustained VT, reduction in O2 saturation and / or perfusion, etc.). Information used to improve execution can include information indicating whether previous SCA events were appropriately and accurately warned, clinical or physiological characteristics of the patient (disease state, weight, sex, etc.), data from EHR 24, and data input from the patient (e.g., symptom records, confirmation that he / she is fine and has not suffered from SCA, etc.).

[0116] Implementation Figure 7 , the processing circuitry may personalize the rules for patient 4 over time. If patient 4 suffers from many false positives, then Figure 7 The exemplary operation of can modify the rules to be less sensitive, conversely, if patient 4 suffers from many false negatives, the rules can be modified to be more sensitive. In some examples, the processing circuit can use feedback and event data to update rules (e.g., machine learning models) for other patients (such as all patients whose IMDs are served by EMS22) or for specific groups or groups of patients. In some examples, the processing circuit can use data from multiple sources (e.g., computing device 12, IoT device 30, AED 44, or drone 46) to modify the rules or a collection of patient parameter data. The data used by the processing circuit to update the rules may include data indicating the duration of CPR (e.g., input from a user) or data collected using an accelerometer, speaker, light detector, or camera on a computing device or IoT device.

[0117] Figure 8 is a flow diagram illustrating another example operation for configuring a rule that is applied to patient parameter data to determine whether an acute health event is detected for a patient. Figure 7 The exemplary operations of may be performed by a processing circuit implementing HMS 22 (e.g., implementing rule configuration service 234). In some examples, Figure 8 The operations may be performed by processing circuitry (e.g., an implementation rule configuration module) of any one of the IMD 10, computing device 12, 38, 42, IoT device 30, AED 44, drone 46, or HMS 22, or by processing circuitry of two or more of these devices that respectively perform portions of the exemplary operations.

[0118] according to Figure 8 In an exemplary operation, processing circuitry determines an etiology or risk stratification of patient 4 (360). Processing circuitry selects a set of rules (e.g., a set of rules 84, rules 196, and / or rules 250) for acute health event (e.g., SCA) detection for patient 4 based on the patient etiology, which set of rules may be a first set of rules and / or a second set of rules (362). In some examples, rules 250 include different rule groups for different patient groups with different etiologies, and processing circuitry may select different rule groups for a given patient based on the etiology to be implemented for that patient as rules 84 in IMD 10 and rules 196 in computing device 12. Processing circuitry may apply the selected set of rules to the patient parameter data to determine whether an acute health event (364) is detected using any of the techniques described herein.

[0119] Detection of SCA can be achieved by observing many possible markers that appear before and during the event. The best markers for detecting an impending or ongoing event may be different based on the patient's etiology. An SCA detection algorithm using a general algorithm designed for a wide population may not achieve satisfactory sensitivity and specificity. The etiology of patient 4 may include baseline characteristics, medical history, or disease state. The etiology of patient 4 may include any EHR data 194 described herein, as well as patient activity levels or metabolite levels. Using such possible inputs, the rules can look for certain markers to show certain trends or threshold crossings to detect an impending or ongoing acute health event, such as SCA.

[0120] In some examples, selection of a set of rules may include modifying the general rule set to enable or disable certain rules (or markers of acute health events), or to change the weights of certain rules or markers. In some examples, a class of devices may be designed so that each model has sensors or computations only for a limited set of inputs motivated by the need to reduce manufacturing costs or energy consumption.

[0121] Although SCA is typically detected by heart rate / rhythm, rules related to other patient parameter data may be set as enhanced warnings based on the patient etiology. For example, a patient who previously had a myocardial infarction may have rules that weight ischemic factors (such as ST segment elevation) more heavily than a patient who lacks such an etiology. As another example, a patient with long QT syndrome may have rules that weight QT interval and activity more heavily. As another example, rules for heart failure patients may have rules that apply greater weights to patient parameter data related to lung fluid and QRS duration.

[0122] In some examples, the processing circuitry of system 2 can use the patient etiology to "personalize" other aspects of the operation of system 2 for patient 4 or a group including patient 4. For example, the processing circuitry can provide warnings and user interfaces that guide caregivers 40, bystanders 26, patients 4, or others based on the etiology. The processing circuitry can provide patient-specific care recommendations (e.g., AEDs or potential drug therapies for preventing or treating SCA). The system's ability to detect acute health events with sufficient sensitivity and specificity can, for example, guide EMS caregivers 40 to what to expect when they arrive at the scene and how to best treat the presenting rhythm, such as patient hypoxia, hypovolemia, hypothermia, tension pneumothorax, cardiac tamponade (H and T of advanced cardiac life support). The etiology can indicate that patient 4 is more at risk for pulseless electrical activity than ventricular fibrillation / ventricular tachycardia. The processing circuitry of system 2 can provide caregiver information based on the current patient parameter data of the etiology of patient 4, such as recommendations for providing CPR or defibrillation, providing medication, or inducing hypothermia. The processing circuitry of system 2 may recommend patient-specific care actions based on the etiology, such as purchasing an AED or chest compression system (LUCAS).

[0123] Although primarily described in the context of SCA detection, the system 2 can be used to detect any of a number of acute health events in the patient 4. For example, the system 2 can be used to detect a stroke. A stroke can often present itself in the form of a facial droop. This facial tone change can be identified using facial image processing on a computing device 12 (e.g., a smartphone or IoT 30). Such image processing can be a primary indicator of a possible stroke, or part of a confirmation after another device indicates a change associated with a stroke.

[0124] Some computing devices 12 (e.g., smartphones) include facial processing for access (e.g., Face ID) and are frequently accessed throughout the day in this manner. For example, processing circuitry of the computing device may analyze facial images to detect subtle changes in facial tone over time. The processing circuitry may detect a possible stroke, and various devices of system 2 may provide warnings as described herein.

[0125] In some examples, in response to detection based on the camera image, the device can output a series of prompts (audible and / or visual) to access the current state of patient 4. Patient 4 can be prompted to repeat phrases or answer audible questions to assess cognitive ability. The device can use additional motion processing, such as using an accelerometer of computing device 12A and / or 12B, to further verify the state of patient 4. Changes in body movement and changes in asymmetry of facial and / or body movement, for example, are indicative of a stroke. In some examples, the device can ask patient 4 questions. The processing circuit can analyze the response to detect speech difficulties associated with a stroke. In some examples, the warning can include information about where the facial tone has changed, which can help the diagnosis by guiding the caregiver 40 to the possible primary scanning position (e.g.: left droop = right clot).

[0126] As described herein, processing circuitry of one or more devices of system 2 (e.g., IMD 10, an edge device such as computing device 12 or IoT device 30, and / or HMS 22 (or other cloud service)) may be configured to analyze episode data associated with an acute health event (such as a ventricular tachyarrhythmia or SCA) detected by IMD 10. The episode data may include ECG and other physiological parameter data collected by IMD 10 for the event (e.g., occurring before, during, and / or after the event). As described herein, the analysis may include applying a second set of rules (as opposed to the first set applied by IMD 10), such as a machine learning model or other artificial intelligence algorithm, a decision tree, and / or thresholds, to the episode data and, in some cases, to various patient data collected by the devices of system 2.

[0127] The initial detection of ventricular tachyarrhythmia attacks by IMD 10 can be based on a first set of rules related to the rate and regularity of the RR intervals and the morphological features of the ECG (e.g., R waves). These rules may lead to inappropriate detection due to over-sensing of the R wave. In addition, true ventricular tachyarrhythmias may be of supraventricular origin, such as SVT, or of ventricular origin, such as VF and VT. VT may be monomorphic or polymorphic. In general, polymorphic VT (PVT) and VF are life-threatening, while monomorphic VT (MVT) is life-threatening if it lasts for a duration of about a few minutes, and SVT is generally not life-threatening unless it lasts for more than 1 hour. The technology disclosed herein may include the use of a second set of rules, which includes a machine learning model or other AI algorithm to improve the accuracy of classification of these different forms of ventricular tachyarrhythmias that may be detected by the IMD.

[0128] In some examples, the second set of rules may include an ensemble of deep learning neural networks configured to distinguish or classify these rhythms. Technology for configuring an ensemble of deep learning neural networks for classifying cardiac rhythms is described in U.S. Provisional Application Serial No. 63 / 194,451, filed on May 28, 2021, and entitled “DYNAMIC AND MODULAR CARDIAC EVENT DETECTION,” the entire contents of which are incorporated herein by reference. In some examples, the second set of rules may include a single classifier that receives raw ECG data or specific features derived from raw ECG data as input.

[0129] In some examples, the collection of neural networks may include CNNs and / or recursive neural networks. One or more neural networks of the collection may be trained to distinguish or classify based on raw ECG data collected as input by IMD 10. One or more networks of the collection may be trained to distinguish or classify based on customized features determined by IMD 10 from ECG or other signals sensed by IMD 10 or customized features determined by a processing circuit implementing a second set of rules (e.g., any one of the devices of system 2 or any combination of processing circuits). The collection of neural networks can improve the sensitivity and specificity of the overall analysis by allowing corresponding networks with different forms for different inputs, for example, one can use a recursive neural network for one or more specific inputs and a CNN for one or more other inputs. In some examples, the output of each network may be cascaded and flattened, and then fed as input to the last level of the collection network, which may have a fully connected layer and a classification layer.

[0130] Fig. 9 is a block diagram illustrating an example of a collection 400 of neural networks configured to classify ventricular tachyarrhythmias. Processing circuitry (e.g., processing circuitry 130 of computing device 12 or IoT device 30) may apply multiple inputs 402 to multiple neural networks 404 of collection 400. Inputs 402 include raw signal inputs 406A or other raw parameter data of patient 4 (e.g., from IMD 10 or other devices as described herein), and inputs 406B including features derived from the raw data. Inputs 406A may include raw ECG segments sensed by IMD 10, including ventricular tachyarrhythmia onsets detected by IMD 10 based on the ECG, and raw ECG segments sensed by IMD 10, including portions of the ECG from which IMD 10 determined that the ventricular tachyarrhythmia was sustained.

[0131] Input 406B may include features derived from the raw ECG sensed by IMD 10, and data indicating the timing of R waves detected by IMD 10 and the intervals between these waves during (and in some cases before and / or after) the ventricular tachyarrhythmia episode sensed by IMD 10. These features may include a sequence of RR intervals during (and in some cases before) the ventricular tachyarrhythmia detected by IMD 10, overlap of the raw ECG data and R sensing timing information, autocorrelation, cross-correlation and / or wavelet transform of the ECG signal data, a histogram of RR intervals, and a time history of previous ventricular tachyarrhythmia episodes detected by IMD 10 and determination of these episodes by the processing circuitry of application collection 400. Input 402 may also include any other sensed parameters of patient 4, such as parameters sensed by IMD 10 or other devices as described above. In some examples, input 406B may include features determined by the processing circuitry based on the time history of other sensed parameters of patient 4.

[0132] In some examples, one or more inputs 402, or portions thereof, may be fed into separate neural networks 404, which may include 1-dimensional or 2-dimensional CNNs, RNNs, or long short-term memory (LSTM) memory networks (which may be a type of RNN). Processing circuitry may flatten 408 and concatenate 410 the outputs from the multiple neural networks providing the collection 400. The processing circuitry may apply the flattened and concatenated outputs to a fully connected layer 412, and apply the outputs of the fully connected layer to one or more SoftMax functions 414. The output of the one or more SoftMax functions 414 is a probability 416, for example, a corresponding probability for different classifications of data of ventricular tachyarrhythmia episodes detected by the IMD 10. In Fig. 9 In the illustrated example, the classifications are different classifications as PVT, MVT, SVT, noise, and over-sensing.

[0133] Processing circuitry (e.g., processing circuitry 130 of computing device 12 or IoT device 30) may determine a classification of the episode based on probability 416. In this manner, processing circuitry may confirm or override detection of a ventricular tachyarrhythmia by IMD 10. Collection 400 may be an example of a second set of rules as described above.

[0134] However, in some examples, processing circuitry may combine the raw signals and derived features (to form an input collection) in a 2D array format for a single CNN or other neural network. Fig.10 is a block diagram illustrating an example of a single classifier 430 utilizing the original signal and derived features as input 432 . Fig.10 The input 432 may be substantially similar to Fig. 9 Input 406B.

[0135] Processing circuitry (e.g., processing circuitry 130 of computing device 12 or IoT device 30) may cascade 434 input 432. Fig.10 In the example of , the processing circuit may cascade 434 inputs 432 to form a cascaded 2D array 436 of input values ​​to be applied to a neural network 438, the neural network comprising one or more of an LSTM / RNN, a rectifier function, and / or a multiplexed pooling layer. The processing circuit may cascade 440 the output of the neural network 438 to be applied to a fully connected layer 442 and a SoftMax function 444, thereby Fig. 9 The described manner generates probability 446. Classifier 430 may be an example of the second set of rules as described above.

[0136] In some examples, the processing circuit uses different segments of the ECG (such as a segment from a time period when the arrhythmia starts, another segment when the episode reaches sustained detection, and multiple ongoing segments thereafter) as corresponding inputs to one or more neural networks, such as ensemble classifier 400 or classifier 430. In some examples, the processing circuit uses features derived from different segments of the ECG in the episode data as corresponding inputs to one or more neural networks, such as RR intervals during and before the onset of an episode, RR interval stability or variability, or short-term HRV before the onset of an episode. In general, these segments can be by time, for example, corresponding cycles of the ECG. The segments can be consecutive, separated by time, and / or overlapping.

[0137] In some examples, the processing circuit uses data from other sensors, such as the IMD 10, the computing device 12, and / or the IoT device 30. Additional data may include, for example, patient motion (e.g., gait) or posture from an accelerometer, which may indicate activity level during an arrhythmia or gait / posture during an arrhythmia, or whether the patient 4 fell during a detected episode. In some examples, other data (e.g., historical data) may be obtained from the IMD 10, the computing device 12, the HMS 22, and / or the EHR 24. As examples, other data may include a history of ventricular tachyarrhythmia episode detection, an AI-based episode classification history, an AF load history, or a clinical history. The processing circuit may use signal processing techniques such as autocorrelation, short-time Fourier transform, continuous wavelet transform, principal component analysis, independent component analysis, and the like to derive features from the sensor signals.

[0138] In some examples, processing circuitry may use a staged approach to classify episodes detected by IMD 10 . Fig.11 is a block diagram illustrating a staged classifier 460 for classifying ventricular tachyarrhythmia episodes. For example, a processing circuit (e.g., processing circuit 130 of computing device 12 or IoT device 30) may first apply a 5-class classifier 462 (e.g., similar to ensemble classifier 400 or classifier 430) and remove the most dominant classes (e.g., episodes of inappropriate detection, noise, and oversensing). The processing circuit then uses a 3-class classifier 464 to classify episodes classified as appropriate tachycardias (PVT, MVT, and SVT). The next dominant class (SVT) is then removed. The processing circuit then classifies the remaining episodes using a 2-class classifier 466 to classify PVT vs. MVT episodes.

[0139] In some examples, the processing circuit can distinguish SVT from other ventricular tachyarrhythmia classifications based on a comparison of the onset ECG data with historical ECG segments. As described herein, the onset ECG data can be received from the IMD 10, and the historical ECG segments can be retrieved from the HMS22. The historical ECG segments can come from previous transmissions from the IMD 10 to the HMS22, such as daily transmissions, such as the most recent transmissions. The historical ECG segments can be segments that precede (e.g., most recently before) a rapid heart rate associated with a detected ventricular tachyarrhythmia, or ECGs that were recently collected on a regular basis (e.g., every hour). The historical ECG segments can be segments of a normal sinus rhythm ECG collected when the device is currently detecting neither any cardiac event nor an arrhythmia, or can be segments that have been previously verified as SVT, for example based on a user or an algorithmic analysis of the segments.

[0140] In such examples, the processing circuitry may apply a convolution filter and / or a convolution filter bank to the ECG data of the episode to distinguish SVT from other classifications. The processing circuitry may generate a convolution filter based on a historical ECG segmentation, which may be about 8 seconds in length. The processing circuitry may generate a convolution filter bank based on a wavelet or other decomposition of the historical ECG segmentation. The processing circuitry may classify the episode as SVT based on a suprathreshold output of the convolution filter. In some examples, an additional classifier may further classify SVT as one of sinus tachycardia, atrial arrhythmia, SVT with abnormalities, junctional rhythm, atrioventricular nodal reentrant tachycardia, or others.

[0141] In some examples, processing circuitry (e.g., processing circuitry 130 of computing device 12 or IoT device 30, or any processing circuitry of any device of system 2 described herein) can distinguish SVT from other ventricular tachyarrhythmia classifications based on features indicating the presence or absence of high-frequency harmonics in the episode ECG data. Fig. 12A and Fig. 12B The frequency decompositions 470 and 480 of MVT episodes and SVT episodes are illustrated, respectively. Fig. 12A and Fig. 12B As illustrated, the amplitudes at certain higher frequency harmonics are shown in the decomposed ECG 480 ( Fig. 12B ) than in the decomposed ECG 470( Fig. 12A ) is greater. In some examples, the processing circuit applies a set of complex exponential functions as a convolution filter to the ECG data of the episode. The frequency range of the set can be configured to span frequencies of interest, which can be integer multiples of the lowest frequency in the decomposed ECG data of the episode. For example, the lowest frequency can be approximately 60 Hertz (Hz), and the set can span a range from 100 Hz to 500 Hz, spanning the range continuously or via frequency bands centered around corresponding integer multiples of 60 Hz. The processing circuit can classify the episode as an SVT based on a supra-threshold output of the convolution filter.

[0142] In some examples, a processing circuit (e.g., processing circuit 130 of computing device 12 or IoT device 30, or any processing circuit of any device of system 2 described herein) may apply a beat-wise morphology comparator to distinguish PVT from MVT. In such examples, the processing circuit may generate a convolution filter from a selected heartbeat (e.g., a first heartbeat) in an ECG stored by IMD 10 for an episode. The processing circuit may generate multiple convolution filters based on a decomposition (e.g., Walsh, Fourier, or wavelet) of the selected heartbeat. The processing circuit may apply the filter (e.g., sequentially) to some or all other heartbeats in an ECG stored by IMD 10 for an episode. The processing circuit may classify an episode as PVT based on suprathreshold variability of the output of the convolution filter.

[0143] As discussed herein, computing device 12 may output a warning or alarm (e.g., audible / visual / tactile) via one or more output devices 136 based on receipt of episode (event) data sent by IMD 10 in response to IMD 10 detecting an acute health event (e.g., a rapid and sustained tachyarrhythmia). The alarm may be intended to facilitate a health check of patient 4, such as checking patient 4 to see if they are responsive. If patient 4 is responsive and not experiencing an acute health event, they may cancel the alarm via one or more input devices 134 of computing device 12.

[0144] In some examples, IMD 10 uses one or more rules of the first set to detect acute health events, and processing circuit 130 of external device 12 applies one or more rules of the second set to the episode data to confirm the acute health event, for example, based on the classification of the episode data. In such examples, processing circuit 130 may cause one or more output devices 136 to output an alarm based on the confirmation. Because IMD 10 may falsely detect an acute health event, the use of an alarm can advantageously allow patient 4, bystander (caregiver) 26, or other user of computing device 12 to cancel false alarms and other actions (e.g., alerting EMS) in response to false detection of an acute health event.

[0145] According to the technology of the present disclosure, the processing circuit 130 determines the alarm context and configures the alarm based on the alarm context. The alarm context can vary based on the likelihood that the patient will be warned and able to respond to the alarm and / or the severity / likelihood of the acute health event. In this way, when the patient is less likely to be warned or less likely to be able to quickly cancel the alarm and / or when the acute health event is less serious and / or less likely to actually occur, the duration and / or intensity of the alarm can be relatively greater. When the patient is more likely to be warned or otherwise able to quickly cancel the alarm and / or when the type of acute health event is more serious and / or more likely to actually occur, the duration of the alarm can be relatively shorter.

[0146] In some examples, processing circuit 130 selects the duration, intensity, or modality of the alarm based on the alarm context. As an example, the intensity may include the volume of an audible alarm, the brightness of a visual alarm, the amplitude of a tactile alarm, or the flash / flash / pulse rate of an audible, visual, or tactile alarm. Selecting the modality of the alarm may include selecting which one or more of the audible, visual, and / or tactile alarms are used as the alarm, and / or selecting which of the one or more output devices 136 of computing device 12 provides the alarm. In some examples, processing circuit 130 is configured to send a communication to another device based on the alarm context to cause the other device to output the alarm alone or in combination with computing device 12. The other device may be a smart speaker or other IoT device 30.

[0147] In some examples, processing circuitry 130 is configured to determine the alarm context based on the location of patient 4 and / or the time of day, both of which may affect the speed at which patient 4 may respond to the alarm. Processing circuitry 130 may be configured to determine the alarm context based on the patient's recent interactions with computing device 12, which may indicate how likely it is that patient 4 is near computing device 12.

[0148] The episode data received from IMD 10 may be first patient parameter data, and processing circuit 130 may be configured to determine an alarm context based on second patient parameter data. The second patient parameter data may be received from IMD 10, another computing device 12 (e.g., a smartwatch), or IoT device 30, or determined based on signals from one or more sensors 138 of computing device 12. Processing circuit 130 may determine the alarm context based on the second patient parameter data.

[0149] The second patient parameter data may include respiratory data, fluid data, posture data, activity data, heart state data, electrocardiogram data, heart rate variability data, oxygen saturation data, blood pressure data, or sleep stage data. Posture data, respiratory data, and sleep stage data may indicate the alertness of patient 4 or whether the patient may fall ill or lose consciousness due to an acute health event. The processing circuit 130 may be configured to increase at least one of the duration or intensity of the alarm based on such data that meets one or more low alertness criteria. In some examples, the computing device 12 may include at least one of a camera configured to generate video data or a microphone configured to generate audio data, and the processing circuit 130 may be configured to determine the alarm context based on the video data or the audio data. In some examples, the computing device 12 may receive at least one of the video data or the audio data from another device (e.g., an IoT device 30 or a smart watch).

[0150] In some examples, the processing circuit 130 is configured to determine an alarm context based on the type or severity of the acute health event (e.g., the type of tachyarrhythmia, such as SVT, MVT, PVT, or VF). In some examples, the processing circuit 130 is configured to determine a classification of the acute health event based on the episode data, for example using one or more ML models as described herein, and to determine an alarm context based on the classification. In some examples, the processing circuit 130 is configured to determine at least one of a probability or a confidence level of the classification based on the application of the episode data to one or more ML models. In some examples, the processing circuit 130 accordingly analyzes time-based segmentation of the episode data, such as M-second segmentation of N-second episode data sent by the IMD 10, to determine corresponding segmentation classifications and probabilities, and determines an alarm context based on the segmentation classifications and / or probabilities.

[0151] As an example, based on a relatively high probability of a relatively severe acute health event (e.g., a probability score of 0.999917 for VF) or one or more of terminal agonal breathing indicated by the impedance and audio signals, the processing circuit 130 can reduce the duration of the alarm (e.g., from 30 seconds to 15 seconds) and increase the intensity of the alarm (e.g., a high-pitched warning on the phone, flashing room lights, and vibration of the smart bed).

[0152] As another example, based on one or more of a relatively low probability of a relatively severe acute health event (e.g., a probability score of 0.6 for VF), a second patient parameter indicating that patient 4 is in deep sleep, or the time of day is night, processing circuitry 130 may increase the duration of the alarm (e.g., to one minute or more) and reduce the intensity of the alarm at least during an initial portion of the duration. As another example, based on a classification of MVT that patient 4 can tolerate, processing circuitry 130 may determine the alarm context based primarily on second patient parameter data, audio / video data, etc.

[0153] In some examples, processing circuitry 130 determines the alarm context based on feedback from patient 4 (e.g., patient 4's response to a previous alarm or question). In some examples, the response may be verbal and made via an event assistant as described herein. For example, if patient 4 responds that they are well but feeling symptoms, the duration of subsequent alarms may be shorter and the intensity of the alarm may be greater. If patient 4 responds that they are well and not feeling symptoms, the duration of the alarm may be extended.

[0154] Fig.13 is a flow diagram illustrating example operations for configuring an acute health event alert based on an alert context. Fig.13 The exemplary operations of are described with respect to computing device 12, but may additionally or alternatively be performed by any device described herein, such as IoT device 30.

[0155] according to Fig.13 In an example of, processing circuitry (e.g., processing circuitry 130 of computing device 12) receives episode data (also referred to as event data) from IMD 10 (400). IMD 10 may send the episode data to computing device 12 in response to detecting a tachyarrhythmia or other health event based on the application of a first set of rules as described herein. Processing circuitry 130 may determine an alarm context (402) in response to receiving the episode data and configure an alarm for an acute health event based on the alarm context (404). Processing circuitry 130 may control one or more output devices 136 to output an alarm configured based on the alarm context (406).

[0156] Fig.14 is a conceptual diagram illustrating an exemplary machine learning model 600 configured to determine the extent to which patient parameter data indicates an acute health event, such as a ventricular tachyarrhythmia or SCA. The machine learning model 600 is about Fig. 9 and Fig.10The neural networks 404 and 438 described herein are examples of any set of rules implemented by any rule engine described herein, any of which may be implemented by the processing circuitry 130 and / or the rule engine 172 of the computing device 12 in wireless communication with the IMD 10 as discussed above. The machine learning model 600 is an example of a deep learning model or deep learning algorithm that is trained to determine whether a particular set of patient parameter data indicates the presence of an acute health event, e.g., whether a particular segment of ECG signal data indicates SCA or a particular classification associated with a ventricular tachyarrhythmia, as described herein.

[0157] One or more of the IMD 10, computing device 12, IoT device 30, or computing system 20 may train, store, and / or utilize the machine learning model 600, but in other examples, other devices may apply inputs associated with a particular patient to the machine learning model 600. As discussed above, other types of machine learning and deep learning models or algorithms may be utilized in other examples. For example, a CNN model of ResNet-18 may be used. Some non-limiting examples of models that can be used for transfer learning include AlexNet, VGGNet, GoogleNet, ResNet50, or DenseNet, among others. Some non-limiting examples of machine learning techniques include support vector machines, K nearest neighbor algorithms, and multilayer perceptrons.

[0158] As shown in the example of Figure 21, the machine learning model 600 may include three layers. The three layers include an input layer 602, a hidden layer 604, and an output layer 606. The output layer 606 includes the output of the transfer function 605 from the output layer 606. The input layer 602 represents each of the input values ​​X1 to X4 provided to the machine learning model 600. The number of inputs may be equal to, less than, or greater than 4, including much greater than 4, such as hundreds or thousands. In some examples, as described above, the input values ​​may include any value input to the machine learning model. In some examples, the input values ​​may include samples of ECG signals. In addition, in some examples, as described herein, the input values ​​of the machine learning model 600 may include additional data, such as R wave data, RR interval data, or other data associated with one or more additional parameters of the patient 4.

[0159] Each of the input values ​​of each node in the input layer 602 is provided to each node in the hidden layer 604. Fig.14In the example of , hidden layer 604 includes two layers, one layer having four nodes and the other layer having three nodes, but fewer or greater numbers of nodes may be used in other examples. Each input from input layer 602 is multiplied by a weight and then added at each node of hidden layer 604. During training of machine learning model 600, the weight of each input is adjusted to establish a relationship between inputs (e.g., input ECG segments) to determine whether a particular set of inputs represents an acute health event and / or to determine a score indicating whether a set of inputs can represent SCA, MVT, PVT, VR, or another acute health event. In some examples, one hidden layer may be incorporated into machine learning model 600, or three or more hidden layers may be incorporated into machine learning model 600, where each layer includes the same or different number of nodes.

[0160] The result of each node within the hidden layer 604 is applied to the transfer function of the output layer 606. The transfer function can be linear or nonlinear, depending on the number of layers within the machine learning model 600. An exemplary nonlinear transfer function can be a sigmoid function or a rectifier function. The output 607 of the transfer function can be a classification indicating whether a particular ECG segment or other input set represents an acute health event (e.g., ventricular tachyarrhythmia), and / or a score indicating the extent to which the input data set represents an acute health event. In some examples, for example, as described herein with respect to Figures 9 to 11 As discussed, output 607 may include corresponding probabilities for a plurality of classifications.

[0161] By applying ECG signal data and / or other patient parameter data to a machine learning model such as machine learning model 600, processing circuitry such as processing circuitry 130 of computing device 12 can determine with high accuracy, specificity, and sensitivity that a patient is experiencing or will soon experience an acute health event. This can facilitate determination of sudden cardiac death risk and can result in warnings and other interventions as described herein. Machine learning model 600 can correspond to any one or more of rules 84, rules 196, and rules 250 described herein.

[0162] Fig.15is an example of training a machine learning model 600 using supervised and / or enhanced learning techniques. The machine learning model 600 can be implemented using any number of models for supervised and / or enhanced learning, such as, but not limited to, an artificial neural network, a decision tree, a naive Bayesian network, a support vector machine, or a k-nearest neighbor model, to name just a few examples discussed above. In some examples, the processing circuitry (e.g., rule configuration module 174 and / or 234) of one or more of the IMD 10, computing device 12, IoT device 30, and / or computing system 20 initially trains the machine learning model 600 based on a training set data 700, which includes numerous instances of input data corresponding to acute health events and non-acute health events (e.g., as annotated by an expert). The prediction or classification of the machine learning model 600 can be compared 704 with, for example, a target output 703 as determined based on a label. Based on an error signal representing the comparison, a processing circuit implementing a learning / training function 705 can send or apply a modification to the weights of the machine learning model 600, or otherwise modify / update the machine learning model 600. For example, one or more of the IMD 10, computing device 12, IoT device 30, and / or computing system 20 may modify the machine learning model 600 to change a score generated by the machine learning model 600 for each training instance in the training set 700 in response to data applied to the machine learning model 600.

[0163] Fig.16A is a perspective view of an exemplary IMD 10A, which may be an ICM Figure 1 and Figure 2 10. Fig.16A In the example shown, IMD 10A can be embodied as a monitoring device having a housing 812, a proximal electrode 816A, and a distal electrode 816B. Housing 812 can also include a first major surface 814, a second major surface 818, a proximal end 820, and a distal end 822. Housing 812 encloses the electronic circuitry located inside IMD 10A and protects the circuitry contained therein from body fluids. Housing 812 can be hermetically sealed and configured for subcutaneous implantation. Electrical feedthroughs provide electrical connections for electrodes 816A and 816B.

[0164] exist Fig.16A In the example shown, IMD 10A is defined by a length L, a width W, and a thickness or depth D, and is in the form of an elongated rectangular prism, where the length L is much greater than the width W, which in turn is greater than the depth D. In one example, the geometry of IMD 10A—particularly the width W being greater than the depth D—is selected to allow IMD 10A to be inserted beneath the patient's skin using a minimally invasive procedure and maintained in a desired orientation during insertion. For example, Fig.16AThe device shown includes radial asymmetry (particularly rectangular shape) along the longitudinal axis, which maintains the device in the correct orientation after insertion. For example, the spacing between the proximal electrode 816A and the distal electrode 816B can be in the range of 5 millimeters (mm) to 55mm, 30mm to 55mm, 35mm to 55mm, and 40mm to 55mm, and can be any range or single spacing of 5mm to 60mm. In addition, the length L of the IMD 10A can be in the range of 30mm to about 70mm. In other examples, the length L can be in the range of 5mm to 60mm, 40mm to 60mm, 45mm to 60mm, and can be any length or length range between about 30mm and about 70mm. In addition, the width W of the main surface 814 can be in the range of 3mm to 15mm, 3mm to 10mm, or 5mm to 15mm, and can be any single width or width range between 3mm to 15mm. The thickness of the depth D of the IMD 10A can be in the range of 2 mm to 15 mm, 2 mm to 9 mm, 2 mm to 5 mm, 5 mm to 15 mm, and can be any single depth or depth range between 2 mm and 15 mm. In addition, the IMD 10A according to the examples of the present disclosure has a geometry and size designed for ease of implantation and patient comfort. The examples of the IMD 10A described in the present disclosure can have a volume of three cubic centimeters (cm) or less, 1.5 cubic centimeters or less, or any volume between three cubic centimeters and 1.5 cubic centimeters.

[0165] exist Fig.16A In the example shown, once inserted into the patient, the first major surface 814 faces outward, toward the patient's skin, and the second major surface 818 is located opposite the first major surface 814. Fig.16A In the example shown, proximal end 820 and distal end 822 are rounded to reduce discomfort and irritation to surrounding tissue once inserted beneath the patient's skin. IMD 10A, including instruments and methods for inserting IMD 10A, is described, for example, in U.S. Patent Publication No. 2014 / 0276928, which is incorporated herein by reference in its entirety.

[0166] The proximal electrode 816A is located at or near the proximal end 820, and the distal electrode 816B is located at or near the distal end 822. The proximal electrode 816A and the distal electrode 816B are used to sense cardiac EGM signals (e.g., ECG signals) outside the thorax, through the thorax, which may be submuscular or subcutaneous. The cardiac signals may be stored in a memory of the IMD 10A, and the data may be sent to another device, which may be another implantable device or an external device such as the external device 812, via the integrated antenna 830A. In some examples, the electrodes 816A and 816B may be used additionally or alternatively to sense any biopotential signal of interest (which may be, for example, an EGM, EEG, EMG, or neural signal) from any implant location, or to measure impedance.

[0167] exist Fig.16A In the example shown, the proximal electrode 816A is located at or proximate to the proximal end 820, and the distal electrode 816B is located at or proximate to the distal end 822. In this example, the distal electrode 816B is not limited to a flat, outwardly facing surface, but can extend from the first major surface 814 around the rounded edge 824 and / or the end surface 826 to the second major surface 818, so that the electrode 816B has a three-dimensional curved configuration. In some examples, the electrode 816B is a non-insulated portion of the metal (e.g., titanium) portion of the housing 812.

[0168] In the example shown in FIG. 23A , the proximal electrode 816A is located on the first major surface 814 and is substantially flat and outward facing. However, in other examples, the proximal electrode 816A can utilize a three-dimensional curved configuration of the distal electrode 816B, thereby providing a three-dimensional proximal electrode (not shown in this example). Similarly, in other examples, the distal electrode 816B can utilize a substantially flat outward facing electrode located on the first major surface 814, similar to the electrode shown with respect to the proximal electrode 816A. Various electrode configurations allow for configurations in which the proximal electrode 816A and the distal electrode 816B are located on both the first major surface 814 and the second major surface 818. In other configurations, such as Fig.16AIn the configuration shown, only one of the proximal electrode 816A and the distal electrode 816B is located on both major surfaces 814 and 818, while in other configurations, both the proximal electrode 816A and the distal electrode 816B are located on one of the first major surface 814 or the second major surface 818 (i.e., the proximal electrode 816A is located on the first major surface 814, and the distal electrode 816B is located on the second major surface 818). In another example, the IMD 10A can include electrodes on both major surfaces 814 and 818 at or near the proximal and distal ends of the device, such that a total of four electrodes are included on the IMD 10A. The electrodes 816A and 816B can be formed of a variety of different types of biocompatible conductive materials (e.g., stainless steel, titanium, platinum, iridium, or alloys thereof), and can utilize one or more coatings, such as titanium nitride or fractal titanium nitride.

[0169] exist Fig.16A In the example shown, the proximal end 820 includes a head assembly 828 that includes one or more of a proximal electrode 816A, an integrated antenna 830A, an anti-migration protrusion 882, and / or a suture hole 834. The integrated antenna 830A is located on the same major surface (e.g., the first major surface 814) as the proximal electrode 816A and is also included as part of the head assembly 828. The integrated antenna 830A allows the IMD 10A to send and / or receive data. In other examples, the integrated antenna 830A can be formed on a major surface opposite the proximal electrode 816A, or can be incorporated within the housing 812 of the IMD 10A. Fig.16A In the example shown, the anti-migration protrusion 832 is located adjacent to the integrated antenna 830A and protrudes away from the first major surface 814 to prevent longitudinal movement of the device. Fig.16A In the example shown, the anti-migration protrusion 832 includes a plurality (e.g., nine) small bumps or protrusions extending away from the first major surface 814. As discussed above, in other examples, the anti-migration protrusion 832 can be located on the major surface opposite the proximal electrode 816A and / or the integrated antenna 830A. Fig.16A In the example shown, head assembly 828 includes suture holes 834 that provide another means of securing IMD 10A to the patient to prevent movement after insertion. In the example shown, suture holes 834 are located adjacent to proximal electrode 816A. In one example, head assembly 828 is a molded head assembly made of a polymer or plastic material that can be integrated with or separate from the main portion of IMD 10A.

[0170] Fig. 16B is a perspective view illustrating another IMD 10B, which may be an ICM from Figure 1 and Figure 2Another exemplary configuration of IMD 10 is shown. Fig. 16B The IMD 10B can be basically similar to Fig.16A The IMD 10A is configured and the differences between them are discussed in this article.

[0171] IMD 10B may include a leadless, subcutaneously implantable monitoring device, such as an ICM. IMD 10B includes a housing having a base 840 and an insulating cover 842. Proximal electrode 816C and distal electrode 816D may be formed or placed on an outer surface of cover 842. For example, as described above with respect to Figure 2 The various circuits and components of the described IMD 10B can be formed or placed on an inner surface of the cover 842 or within the base 840. In some examples, a battery or other power source for the IMD 10B can be included within the base 840. In the illustrated example, the antenna 830B is formed or placed on an outer surface of the cover 842, but in some examples, it can be formed or placed on an inner surface. In some examples, the insulating cover 842 can be positioned above the open base 840 so that the base 840 and the cover 842 enclose the circuits and other components and protect these circuits and other components from fluids such as body fluids. The housing including the base 840 and the insulating cover 842 can be hermetically sealed and configured for subcutaneous implantation.

[0172] Circuits and components can be formed on the inner side of the insulating cover 842, such as by using flip chip technology. The insulating cover 842 can be flipped onto the base 840. When flipped and placed onto the base 840, the components of the IMD 10B formed on the inner side of the insulating cover 842 can be positioned in the gap 844 defined by the base 840. Electrodes 816C and 816D and antenna 830B can be electrically connected to the circuit formed on the inner side of the insulating cover 842 through one or more through holes (not shown) formed through the insulating cover 842. The insulating cover 842 can be formed of sapphire (i.e., corundum), glass, poly-p-xylene and / or any other suitable insulating material. The base 840 can be formed of titanium or any other suitable material (e.g., biocompatible material). Electrodes 816C and 846D can be formed of any one of stainless steel, titanium, platinum, iridium or their alloys. Additionally, electrodes 846C and 846D may be coated with a material such as titanium nitride or fractal titanium nitride, although other suitable materials and coatings for such electrodes may also be used.

[0173] exist Fig. 16B In the example shown, the housing of the IMD 10B defines a length L, a width W, and a thickness or depth D, and is in the form of an elongated rectangular prism, wherein the length L is much greater than the width W, which in turn is greater than the depth D, similar to Fig.16A816A. For example, the spacing between the proximal electrode 816C and the distal electrode 816D can be in the range of 5 mm to 50 mm, 30 mm to 50 mm, 35 mm to 45 mm, and can be any single spacing or spacing range from 5 mm to 50 mm, such as about 40 mm. In addition, the IMD 10B can have a length L ranging from 5 mm to about 70 mm. In other examples, the length L can be in the range of 30 mm to 70 mm, 40 mm to 60 mm, 45 mm to 55 mm, and can be any single length or length range from 5 mm to 50 mm, such as about 45 mm. In addition, the width W can be in the range of 3 mm to 15 mm, 5 mm to 15 mm, 5 mm to 10 mm, and can be any single width or width range from 3 mm to 15 mm, such as about 8 mm. The thickness or depth D of the IMD 10B can be in the range of 2 mm to 15 mm, 5 mm to 15 mm, or 3 mm to 5 mm, and can be any single depth or depth range between 2 mm and 15 mm, such as about 4 mm. The IMD 10B can have a volume of three cubic centimeters (cm) or less, or 1.5 cubic centimeters or less (such as about 1.4 cubic centimeters).

[0174] exist Fig. 16B In the example shown, once inserted subcutaneously into the patient's body, the outer surface of the cover 842 faces outward, toward the patient's skin. Fig. 16B As shown, proximal end 846 and distal end 848 are rounded to reduce discomfort and irritation to surrounding tissue once inserted beneath the patient's skin. Additionally, the edges of IMD 10B can be rounded.

[0175] It should be understood that the various aspects disclosed herein may be combined in combinations different from those specifically presented in the specification and drawings. It should also be understood that, depending on the example, certain actions or events of any of the processes or methods described herein may be performed in a different order, may be added, merged, or omitted entirely (e.g., not all described actions or events may be required to perform these techniques). In addition, although certain aspects of the present disclosure are described as being performed by a single module, unit, or circuit for clarity, it should be understood that the techniques of the present disclosure may be performed by a combination of units, modules, or circuits associated with, for example, a medical device.

[0176] In one or more examples, the described techniques can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or codes on a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium may include a non-transitory computer-readable medium that corresponds to a tangible medium, such as a data storage medium (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and can be accessed by a computer).

[0177] Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Thus, the terms "processor" or "processing circuitry" as used herein may refer to any of the foregoing structures or any other physical structure suitable for implementing the described techniques. Additionally, these techniques may be fully implemented in one or more circuits or logic elements.

[0178] The following examples are illustrative of the techniques described herein.

[0179] Embodiment 1. A computing device, comprising: a communication circuit configured to wirelessly communicate with a sensor device on a patient or implanted in the patient's body; one or more output devices; and a processing circuit configured to: receive, via the communication circuit, onset data of an acute health event detected by the sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determine an alarm context in response to receiving the onset data; configure an alarm for the acute health event based on the alarm context; and control the one or more output devices to output the alarm configured based on the alarm context.

[0180] Embodiment 2. The computing device of embodiment 1, wherein to configure the alarm, the processing circuit is configured to select a duration of the alarm based on the alarm context.

[0181] Embodiment 3. The computing device of embodiment 1 or embodiment 2, wherein, to configure the alarm, the processing circuit is configured to select an intensity of the alarm based on the alarm context.

[0182] Embodiment 4. The computing device of embodiment 3, wherein the intensity comprises a volume of an audible alarm.

[0183] Embodiment 5. The computing device of any one or more of embodiments 1 to 4, wherein, to configure the alarm, the processing circuit is configured to select a modality of the alarm based on the alarm context.

[0184] Embodiment 6. A computing device according to any one or more of embodiments 1 to 5, wherein, to configure the alarm, the processing circuit is configured to transmit a communication to another device via the communication circuit, and the other device is configured to cause the other device to output at least a portion of the alarm.

[0185] Embodiment 7. A computing device according to embodiment 6, wherein the other device comprises an Internet of Things device.

[0186] Embodiment 8. A computing device according to embodiment 7, wherein the IoT device includes a smart speaker.

[0187] Embodiment 9. A computing device according to any one or more of embodiments 1 to 8, wherein the processing circuit is configured to determine the alarm context based on the type of the acute health event.

[0188] Embodiment 10. The computing device of any one or more of Embodiments 1 to 9, wherein the processing circuit is configured to determine the alarm context based on the location of the patient.

[0189] Embodiment 11. The computing device of any one or more of Embodiments 1 to 10, wherein the processing circuit is configured to determine the alarm context based on a time of day.

[0190] Embodiment 12. A computing device according to any one or more of embodiments 1 to 11, wherein the attack data includes first patient parameter data, wherein the processing circuit is configured to: receive second patient parameter data from the sensor device; and determine the alarm context based on the second patient parameter data.

[0191] Embodiment 13. A computing device according to any one or more of Embodiments 1 to 11, the computing device also including one or more sensors separate from the sensor device, the one or more sensors being configured to sense one or more physiological signals of the patient, wherein the attack data includes first patient parameter data, wherein the processing circuit is configured to: determine second patient parameter data based on the one or more physiological signals; and determine the alarm context based on the second patient parameter data.

[0192] Embodiment 14. A computing device according to embodiment 12 or 13, wherein the second patient parameter data includes one or more of respiratory data, fluid data, posture data, activity data, heart state data, electrocardiogram data, heart rate variability data, oxygen saturation data, blood pressure data or sleep stage data.

[0193] Embodiment 15. A computing device according to embodiments 3 and 14, wherein the processing circuit is configured to increase at least one of the duration or intensity of the alarm based on at least one of posture data, breathing data, or sleep stage data that meets one or more low alertness criteria.

[0194] Embodiment 16. A computing device according to any one or more of Embodiments 1 to 15, the computing device also including at least one of a camera configured to generate video data or a microphone configured to generate audio data, wherein the processing circuit is configured to determine the alarm context in response to receiving the attack data and based on the video data or the audio data.

[0195] Embodiment 17. A computing device according to any one or more of embodiments 1 to 15, wherein the processing circuit is configured to: receive at least one of video data or audio data from another device via the communication circuit; and determine the alarm context in response to receiving the attack data and based on the video data or the audio data.

[0196] Embodiment 18. The computing device of embodiment 17, wherein the other device comprises one of a smart watch or an Internet of Things device.

[0197] Embodiment 19. A computing device according to any one or more of embodiments 1 to 18, wherein the processing circuit is configured to: determine a classification of the acute health event based on the episode data; and determine the alarm context based on the classification.

[0198] Embodiment 20. A computing device according to embodiment 19, wherein the processing circuit is configured to apply the seizure data to one or more machine learning models to determine the classification.

[0199] Embodiment 21. A computing device according to embodiment 20, wherein the processing circuit is configured to: determine at least one of the probability or confidence level of the classification based on the application of the episode data to one or more machine learning models; and determine the alarm context based on the probability or the confidence level.

[0200] Embodiment 22. A computing device according to any one or more of embodiments 1 to 21, wherein the computing device comprises a smartphone.

[0201] Embodiment 23. A computing device according to any one or more of embodiments 1 to 21, wherein the computing device comprises an Internet of Things device.

[0202] Embodiment 24. The computing device of any one or more of Embodiments 1 to 23, wherein the processing circuit is configured to determine the alarm context based on patient feedback.

[0203] Embodiment 25. A system comprising: a sensor device; and a computing device according to any one or more of embodiments 1 to 24.

[0204] Embodiment 26. A system according to Embodiment 25, wherein the sensor device comprises an implantable medical device.

[0205] Embodiment 27. A system according to Embodiment 26, wherein the implantable medical device comprises an insertable cardiac monitor.

[0206] Embodiment 28. A system according to embodiment 27, wherein the episode data includes electrocardiogram data, and the insertable cardiac monitor includes: a shell configured for subcutaneous implantation in a patient, the shell having a length between 40 millimeters (mm) and 60 mm between a first end and a second end, a width less than the length, and a depth less than the width; a first electrode, the first electrode located at or near the first end; a second electrode, the second electrode located at or near the second end; and a circuit, the circuit being located within the shell and configured to sense an electrocardiogram corresponding to the electrocardiogram data via the first electrode and the second electrode, and to detect the acute health event based on the electrocardiogram.

[0207] Embodiment 29. A method for operating a computing device, the method comprising: receiving, via a communication circuit of the computing device, onset data of an acute health event detected by a sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determining, by a processing circuit of the computing device in response to receiving the onset data, an alarm context; configuring, by the processing circuit, an alarm for the acute health event based on the alarm context; and controlling, by the processing circuit, one or more output devices of the computing device to output the alarm configured based on the alarm context.

[0208] Embodiment 30. A non-transitory computer-readable storage medium, comprising instructions that cause a processing circuit to: receive onset data of an acute health event detected by a sensor device, the onset data being sent by the sensor device in response to detecting the acute health event; determine an alarm context in response to receiving the onset data; configure an alarm for the acute health event based on the alarm context; and output the alarm configured based on the alarm context.

[0209] Various embodiments have been described. These and other embodiments are within the scope of the following claims.

Claims

1. A computing device, comprising: a communication circuit configured to wirelessly communicate with a sensor device on or implanted in a patient; one or more output devices; and A processing circuit, the processing circuit being configured to: receiving, via the communication circuit, episode data of an acute health event detected by the sensor device, the episode data being sent by the sensor device in response to detecting the acute health event; determining an alert context in response to receiving the episode data; configuring an alert for the acute health event based on the alert context; as well as The one or more output devices are controlled to output the alert configured based on the alert context.

2. The computing device according to claim 1, wherein: To configure the alarm, the processing circuit is configured to select at least one of a duration, an intensity, or a modality of the alarm based on the alarm context.

3. The computing device of claim 2, wherein the intensity comprises a volume of an audible alarm.

4. A computing device according to any one or more of claims 1 to 3, wherein: To configure the alert, the processing circuit is configured to send a communication via the communication circuit to another device, the other device being configured to cause the other device to output at least a portion of the alert.

5. The computing device of claim 4, wherein the other devices include Internet of Things devices.

6. The computing device of claim 5, wherein the IoT device comprises a smart speaker.

7. A computing device according to any one or more of claims 1 to 6, wherein the processing circuit is configured to determine the alert context based on a type of the acute health event.

8. The computing device of any one or more of claims 1 to 7, wherein the processing circuit is configured to determine the alarm context based on at least one of a location of the patient or a time of day.

9. The computing device of any one or more of claims 1 to 8, wherein the episode data comprises first patient parameter data, wherein the processing circuit is configured to: receiving second patient parameter data from the sensor device; and The alarm context is determined based on the second patient parameter data.

10. The computing device of any one or more of claims 1 to 9, further comprising one or more sensors separate from the sensor device, the one or more sensors configured to sense one or more physiological signals of the patient, wherein the episode data comprises first patient parameter data, wherein the processing circuit is configured to: determining second patient parameter data based on the one or more physiological signals; and The alarm context is determined based on the second patient parameter data.

11. A computing device according to claim 9 or 10, wherein the second patient parameter data includes one or more of respiratory data, fluid data, posture data, activity data, heart state data, electrocardiogram data, heart rate variability data, oxygen saturation data, blood pressure data or sleep stage data.

12. A computing device according to claims 2 and 11, wherein the processing circuit is configured to increase at least one of the duration or intensity of the alarm based on at least one of posture data, breathing data, or sleep stage data that meets one or more low alertness criteria.

13. The computing device of any one or more of claims 1 to 12, wherein the processing circuit is configured to: determining a classification of the acute health event based on the episode data; and The alert context is determined based on the classification.

14. The computing device of claim 13, wherein the processing circuit is configured to apply the seizure data to one or more machine learning models to determine the classification.

15. The computing device of claim 14, wherein the processing circuit is configured to: determining at least one of a probability or a confidence level of the classification based on applying the episode data to the one or more machine learning models; and The alert context is determined based on the probability or the confidence level.

Images