CN117015336A - Acute health event monitoring and guidance - Google Patents

Abstract

Example devices, systems, and techniques for providing guidance for treatment of a patient are disclosed. The example apparatus includes processing circuitry and memory containing instructions that, when executed by the processing circuitry, cause the processing circuitry to: the determining means detects an acute health event of the patient or delivers cardiopulmonary resuscitation to the patient and analyzes the sensed patient data in response to the determination. The instructions cause the processing circuitry to provide information for guiding treatment of the patient based on the analysis.

Description

Acute health event monitoring and guidance

Technical Field

The present disclosure relates generally to systems including medical devices, and more particularly to monitoring patient health using such systems.

Background

A variety of devices are configured to monitor physiological signals of a patient. Such devices include implantable or wearable medical devices, as well as 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 pose signals, pressure signals, blood oxygen saturation signals, body components, and blood glucose or other blood component signals. Generally, using these signals, such devices facilitate monitoring and assessment of patient health over months or years outside of the clinical setting.

In some cases, such devices are configured to detect an acute health event, such as a seizure of arrhythmia, myocardial infarction, stroke, or epilepsy, based on physiological signals. Exemplary arrhythmia types include cardiac arrest (e.g., asystole), ventricular Tachycardia (VT), and Ventricular Fibrillation (VF). These devices may store ECG and other physiological signal data collected during a time period that includes a seizure as seizure data. Such acute health events are associated with significant mortality, particularly if not treated rapidly.

For example, VF and other malignant tachyarrhythmias are the most commonly identified arrhythmias in patients with Sudden Cardiac Arrest (SCA). If such arrhythmia lasts for more than a few seconds, cardiogenic shock and effective blood circulation may be caused to stop. Survival from SCA decreases by 7% to 10% for every minute that the patient waits for defibrillation. Thus, sudden Cardiac Death (SCD) may occur within minutes.

Disclosure of Invention

In general, this disclosure describes techniques for providing information to a computing device in response to an indication of a sensed acute health event. This information indicates guidance for treatment of patients experiencing an acute health event. In some examples, information may be provided to bystander computing devices, automated cardiopulmonary resuscitation (CPR) machines, and/or care provider computing devices.

In one example, an apparatus includes processing circuitry and memory containing instructions that, when executed by the processing circuitry, cause the processing circuitry to: determining that the device detects an acute health event of the patient or delivers cardiopulmonary resuscitation (CPR) to the patient; analyzing the sensed patient data in response to the determination; and providing information for guiding the treatment of the patient based on the analysis.

In another example, a method includes: determining, by the processing circuitry, that the device detects an acute health event of the patient or delivers cardiopulmonary resuscitation (CPR) to the patient; in response to the determination, analyzing, by the processing circuit, the sensed patient data; and providing, by the processing circuit, information for guiding the treatment of the patient based on the analysis.

In another example, a non-transitory computer-readable storage medium storing instructions that, when executed, cause processing circuitry to: determining that the device detects an acute health event of the patient or delivers cardiopulmonary resuscitation (CPR) to the patient; analyzing the sensed patient data in response to the determination; and providing information for guiding the treatment of the patient based on the analysis.

This summary is intended to provide an overview of the subject matter described in this disclosure. It is not intended to provide an exclusive or exhaustive explanation of the apparatus and methods described in detail in the following figures and description. Further details of one or more examples are set forth in the accompanying drawings and the description below.

Drawings

Fig. 1 is a block diagram showing an exemplary system configured to detect health events of a patient and respond to such detection in accordance with one or more techniques of the present disclosure.

Fig. 2 is a block diagram showing an exemplary configuration of a patient sensing device operating in accordance with one or more techniques of the present disclosure.

Fig. 3 is a block diagram showing an exemplary configuration of a computing device operating in accordance with one or more techniques of this disclosure.

Fig. 4 is a block diagram showing an exemplary configuration of a health monitoring system operating in accordance with one or more techniques of the present disclosure.

Fig. 5 is a flow chart illustrating an exemplary guidance technique of the present disclosure.

Like reference numerals refer to like elements throughout the drawings and description.

Detailed Description

Patients suffering from an acute health event, such as cardiac arrest (SCA), may require robust cardiopulmonary resuscitation (CPR) and/or early defibrillation, which may double the chance of survival more than one time and reduce damage that may be caused by the acute health event. However, bystanders often cannot deliver CPR correctly at the correct cadence and intensity, because many bystanders are not trained in how to deliver CPR. In addition, emergency Medical Services (EMS) typically have little knowledge of the patient and his medical condition. The various devices may include sensors that may be used to determine and provide guidance to bystanders or automated CPR devices regarding the proper delivery of CPR. Such devices may also be used to determine and provide guidance to the EMS and/or medical facility regarding automatic diagnosis or machine diagnosis of an acute health event, which may enable EMS personnel or medical facility personnel to better prepare to provide treatment to the patient when the EMS personnel reach the patient's location or when the patient reaches the medical facility.

Furthermore, the amount of time it takes to provide the appropriate medication or surgical intervention is critical to save as much of the patient's brain function (e.g., brain cells) as possible when the patient experiences stroke. It may be desirable to route stroke patients to an integrated stroke agency rather than the nearest medical agency to save valuable time in the event that the nearest agency does not have the proper equipment or protocols to provide optimal care to the patient.

Various types of implantable devices and computing devices detect arrhythmia episodes and other acute health events based on sensed ECG and, in some cases, other physiological signals. Computing devices that may be used for non-invasive sensing and monitoring of ECG and other physiological signals include wearable devices such as patches, watches, rings or necklaces with electrodes configured to contact the patient's skin, and other non-contact monitoring devices such as devices configured to monitor sound, radar, light, images, etc. Such computing devices may facilitate relatively long-term monitoring of patient health during normal daily activities.

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. An exemplary IMD includes: pacemakers and implantable cardioverter-defibrillators, which may be coupled to intravascular or extravascular leads; and a pacemaker having a housing configured for implantation within the heart, the pacemaker may be leadless. Some IMDs do not provide therapy, such as implantable patient monitors. One example of such an IMD is the real LINQ commercially available from Medun force company (Medtronic plc) ^TM Pluggable cardiac monitor (ICM) or LINQ II ^TM ICM, which can be inserted subcutaneously. Such IMDs may facilitate relatively long-term monitoring of patients during normal daily activities, and may periodically transmit collected data, such as episode data for detected arrhythmia episodes, to a remote patient monitoring system, such as the meiton force CarelinkA network.

Fig. 1 is a block diagram illustrating an exemplary system 2 configured to detect health events of a patient 4 and respond to such detection in accordance with one or more techniques of the present disclosure. As used herein, the terms "detect", "detection" and the like may refer to the detection of an acute health event that the patient 4 is currently experiencing (while collecting data), as well as the detection of data based on the condition of the patient 4 such that they have a threshold likelihood of experiencing an event within a particular time frame, e.g., the prediction of an acute health event. Exemplary techniques may be used with one or more patient sensing devices, e.g., IMD 10, which may communicate wirelessly with one or more patient computing devices, e.g., patient computing devices 12A and 12B (collectively, "computing devices 12"). Although not shown in fig. 1, 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 events based on the data.

IMD 10 may be implanted outside of the chest of patient 4 (e.g., subcutaneously in the pectoral muscle position illustrated in fig. 1). IMD 10 may be positioned near a sternum near or just below a heart level of patient 4, e.g., at least partially within a heart outline. In some examples, IMD 10 employs LINQ ^TM Form of ICM. Although primarily described in the context of an example in which IMD 10 takes the form of an ICM, the techniques of this disclosure may be implemented in a system including any one or more implantable or external medical devices including monitors, pacemakers, defibrillators, wearable external defibrillators, neurostimulators, or drug pumps. Furthermore, while described primarily 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 may be implanted within the patient 4 or external to the patient 4 (e.g., worn by the 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. 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 Such as a desktop, laptop or tablet computer. Computing device 12 may be in accordance with, for exampleOr->A low power consumption (BLE) protocol communicates with IMD 10 and each other. In some examples, only one of computing devices 12, e.g., computing device 12A, is configured to communicate with IMD 10, e.g., due to execution of software capable of communicating and interacting with the IMD (e.g., part of a health monitoring application as described herein).

In some examples, a computing device 12, such as wearable computing device 12B in the example illustrated in fig. 1A, may include electrodes and other sensors to sense physiological signals of patient 4, and may collect and store physiological data and detect episodes based on such signals. The computing device 12B may be incorporated into the clothing of the patient 14, such as within clothing, shoes, glasses, watches or bracelets, hats, rings, necklaces, and the like. In some examples, computing device 12B is a smart watch or other accessory or peripheral device to smart phone computing device 12A.

One or more of the computing devices 12 may be configured to communicate with various other devices or systems via the 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 manufacturers of IMD 10 and computing device 12, respectively, to provide cloud storage and analysis, maintenance and software services of collected data, or other networking functions, for example, for their respective devices and users thereof. In some examples, computing system 20A may include a meiton force Carelink ^TM Networks or may pass through the Medun force Carelink ^TM A network. In the example illustrated in FIG. 1, computing system 20A implements a Health Monitoring System (HMS) 22, but in other examples, computing system 20A is in the form of a computer systemEither or both may implement the HMS22. As will be described in greater detail below, the HMS22 facilitates the detection of acute health events by the system 2 for the patient 4 and the response of the system 2 to such acute health events.

Computing device 12 may transmit data, including data retrieved from IMD 10, to computing system 20 via network 16. The data may include: sensing data, such as values of physiological parameters measured by IMD 10 and, in some cases, one or more of computing devices 12; data regarding arrhythmia episodes or other health events detected by IMD 10 and computing device 12; as well as other physiological signals or data recorded by IMD 10 and/or computing device 12. The HMS22 may also retrieve data about the patient 4 from one or more Electronic Health Record (EHR) 24 sources via a network. EHR 24 may include data regarding historical (e.g., baseline) physiological parameter values, previous health events and treatments, disease states, co-morbidities, demographics, height, weight, and Body Mass Index (BMI) of patients, including patient 4. HMS22 may use data from EHR 24 to configure algorithms implemented by IMD 10 and/or computing device 12 to detect acute health events of patient 4. In some examples, HMS22 provides data from EHR 24 to computing device 12 and/or IMD 10 for storage therein and use as part of its algorithm for detecting acute health events.

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 protection devices, servers, cellular base stations and nodes, wireless access points, bridges, cable modems, application accelerators, or other network devices. The network 16 may comprise one or more networks managed by a service provider and may thus form part of a large-scale public network infrastructure (e.g., the internet). The network 16 may provide access to the internet to computing devices and systems such as those shown in fig. 1, and may provide a communication framework that allows the computing devices and systems to communicate with one another. In some examples, network 16 may include a private network that provides a communication framework that allows the computing devices and systems illustrated in fig. 1 to communicate with each other, but isolates some of the data streams from devices external to the private network for security purposes. In some examples, communications between the computing device and the system shown in fig. 1 are encrypted.

As will be described herein, IMD 10 may be configured to detect acute health events for patient 4 based on data sensed by IMD 10 and, in some cases, other data (such as data sensed by computing devices 12A and/or 12B) and data from EHR 24. In response to detection of the acute health event, IMD 10 may wirelessly transmit a message to one or both of computing devices 12A and 12B. The message may indicate that IMD 10 detected an acute health event for the patient. The message may indicate a time at which IMD 10 detected an acute health event. The message may include physiological data collected by IMD 10, such as data that caused the detection of an acute health event, data prior to the detection of an acute health event, and/or real-time or more recent data collected after the detection of an acute health event. The physiological data may include values of one or more physiological parameters and/or digitized physiological signals. Some examples of acute health events are cardiac arrest, ventricular fibrillation, ventricular tachycardia, myocardial infarction, thermal rhythm pauses (cardiac arrest), pulseless Electrical Activity (PEA), acute Respiratory Distress Syndrome (ARDS), stroke, seizure, fall, anaphylactic shock or respiratory failure.

In response to the message from IMD 10, computing device 12 may output an alert, which may be visual and/or audible, and configured to immediately draw the attention of patient 4 or any person accompanying patient 4 in environment 28 (e.g., bystanders 26). By way of example, the environment 28 may be a home, office, or business location or public location. The computing device 12 may also transmit a message to the HMS22 via the network 16. The message 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, the message may include the location of patient 4 as determined by computing device 12.

Other devices in the environment 28 of the patient 4 may also be configured to output an alarm or take other action to draw the attention of the patient 4 and possibly bystanders 26 or otherwise facilitate delivery of care to the patient 4. For example, the environment 28 may include one or more internet of things (IoT) devices, such as IoT devices 30A-30D (collectively, "IoT devices 30") illustrated in the example of fig. 1. IoT devices 30 may include, for example, so-called "smart" speakers, cameras, lights, locks, thermostats, appliances, actuators, controllers, or any other smart home (or building) device. In the example of fig. 1, ioT device 30C is a smart speaker and/or controller, which may include a display. The IoT device 30 may provide audible and/or visual alerts when configured with an output device to do so. As other examples, the IoT device 30 may flash or blink a smart light throughout the environment 28 and unlock the door. In some examples, ioT devices 30 including cameras or other sensors may activate those sensors to collect data about the patient 4, e.g., for assessing the condition of the patient 4.

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

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

The computing device 12, and in some examples the IoT device 30, may include an input device and interface to allow a user to override an alert if the detection of an acute health event by the IMD 10 is false. In some examples, one or more of the computing device 12 and IoT device 30 may implement an event assistant. The event assistant may provide a conversational interface for the patient 4 and/or spectator 26 to exchange information with the computing device or IoT device. In response to receiving the alert message from IMD 10, the event assistant may query the user regarding the condition of patient 4. The response from the user may be used to confirm or override detection of an acute health event by IMD 10, or more generally to provide additional information regarding the acute health event or the condition of patient 4, which may improve the efficacy of treatment of patient 4. For example, 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 context data to interpret the user's utterance. In some examples, in addition to receiving a response to a query posed by the assistant, the event assistant may be configured to respond to a query posed by the user. For example, patient 4 may indicate that he feels dizzy and ask the event assistant "how do i do? ".

In some examples, computing device 12 and/or HMS22 may implement one or more algorithms to evaluate sensed physiological data received from IMD 10, and in some cases, additional physiological or other data sensed or otherwise collected by computing device or IoT device 30, to confirm or deny 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 data. In some examples, the computing device 12 and/or the HMS22 may apply the data to a machine learning model or other artificial intelligence developed algorithm, for example, to determine whether the data is sufficient to indicate an acute health event.

In examples where the computing device 12 is configured to perform acute health event validation analysis, the computing device 12 may transmit an alert message to the HMS22 and/or IoT device 30 in response to validating the acute health event. In some examples, computing device 12 may be configured to transmit an alert message before completing the confirmation analysis and to transmit a cancellation message in response to the analysis denying detection of the acute health event by IMD 10. The HMS22 may be configured to perform several operations in response to receiving the alert message from the computing device 12 and/or IoT device 30. The HMS22 may be configured to cancel such operations in response to receiving a cancel message from the computing device 12 and/or IoT device 30. In some examples, the acute health event validation analysis may include an automatic diagnosis or a machine diagnosis that determines an acute health event. For example, IMD 10, computing device 12, ioT device 30, and/or HMS22 may utilize sensed physiological data to determine an automatic diagnosis or machine diagnosis of an acute health event.

For example, the HMS22 may be configured to transmit an alert message to one or more computing devices 38 associated with one or more care providers 40 via the network 16. The care provider may include an Emergency Medical System (EMS) and a hospital, and may include a specific department within the hospital, such as an emergency department, catheterization laboratory, or stroke response department. Computing device 38 may comprise a smart phone, desktop computer, laptop computer, or tablet computer, or a workstation associated with such a system or entity, or an employee of such a system or entity. The alert message may include any of the data collected by IMD 10, computing device 12, and IoT device 30, including sensed physiological data, time of the acute health event, location of patient 4, and results of analysis by IMD 10, computing device 12, ioT device 30, and/or HMS 22. In some examples, the analysis results may include an automatic diagnosis or a machine diagnosis of the acute health event. The information transmitted from the HMS22 to the care provider 40 may improve the timeliness and effectiveness of the care provider 40's treatment of the acute health event of the patient 4. In some examples, instead of or in addition to the HMS22 providing alert messages to one or more computing devices 38 associated with the EMS care provider 40, the computing device 12 and/or IoT device 30 may be configured to automatically contact the EMS in response to receiving alert messages from the IMD 10, such as automatically dial 911 (e.g., using a telephone system to contact a 911 call center in the united states or north america). Again, such operations may be canceled by patient 4, bystander 26, or another user via a user interface of computing device 12 or IoT device 30, or automatically canceled by computing device 12 based on a confirmatory analysis performed by the computing device that denies detection of the acute health event by IMD 10.

Similarly, the HMS22 may be configured to transmit alert messages to the computing device 42 of the bystander 26, which may improve the timeliness and effectiveness of the bystander 26's treatment of the acute health event of the patient 4. Computing device 42 may be similar to computing device 12 and computing device 38, such as a smart phone. In some examples, the HMS22 may determine that the bystander 26 is approaching 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 may transmit an alert message to any computing device 42 in the alert area determined based on the location of the patient 4, for example, by transmitting an alert message to all computing devices in communication with the base station 36.

In some examples, an alert message to bystanders 26 (whether from HMS22, IMD 10, or computing device 12) may be configured to assist a layperson in treating the patient. For example, the alert message to the bystander 26 may include the location of the patient 4 (and in some cases a description), the general nature of the acute health event, an indication to provide care to the patient 4, such as an indication to provide cardiopulmonary resuscitation (CPR), the location of a nearby medical device, such as an Automated External Defibrillator (AED) 44 or life jacket, for treating the patient 4, and instructions for use of the equipment. In some examples, the computing device 12, ioT device 30, and/or computing device 42 may implement an event assistant configured to provide a conversational interface for spectators 26 using video, natural language processing, and/or contextual data. The assistant can provide instructions to the bystander 26 for providing care to the patient 4, such as instructions on how to provide CPR, and respond to queries from the bystander 26 on how to provide care to the patient 4.

For example, IMD 10 may sense an indication of an acute health event of patient 4. In response to sensing the indication of the acute health event, IMD 10 may be communicatively connected to computing device 12, computing device 42, and/or IoT device 30. In some examples, IMD 10 may provide information to computing device 12, computing device 42, and/or IoT device 30 for guiding treatment of patient 4, which in turn may provide guidance to bystanders 26 or EMS personnel in environment 28. In other examples, IMD 10 may provide computing device 12, computing device 42, and/or IoT device 30 with an indication of an acute health event and/or other sensed patient data, and processing circuitry of computing device 12, computing device 42, and/or IoT device 30 may analyze the sensed patient data (e.g., from IMD 10, ioT device 30, and/or drone 46) in response to the determination, and provide spectator 26 with information to direct the treatment of the patient. In some examples, the guidance may be audio and/or visual guidance.

In some examples, this information includes an indication of an acute health event and potentially other data sensed by IMD 10. In some examples, based on the information, the computing device 12, the computing device 42, and/or the IoT device 30 may determine the guidance and provide the guidance to the spectator 26. In some examples, to determine the guidance, the computing device 12, the computing device 42, and/or the IoT device 30 may communicate with the HMS, and the HMS may determine the guidance and provide the guidance to the computing device 12, the computing device 42, and/or the IoT device 30. In some examples, the information includes directions, and the computing device 12, the computing device 42, and/or the IoT device 30 may provide the directions to the spectator 26.

However, after instruction, the bystander 26 may not be able to administer CPR to the patient 4 properly, especially if the bystander 26 is not trained to administer CPR. IMD 10 may include an accelerometer (not shown in fig. 1). IMD 10 may use the accelerometer signal to sense CPR delivery and whether CPR delivery is being performed correctly. For example, the accelerometer signal may indicate the intensity and/or frequency of chest compressions.

In some examples, the accelerometer signal may be used to determine a guide to change the intensity and/or frequency of chest compressions. For example, IMD 10 may provide information to computing device 12, computing device 42, and/or IoT device 30 to direct therapy changes for patient 4. In some examples, the information includes guidance for treatment changes. In other examples, the computing device 12, the computing device 42, and/or the IoT device 30 may use this information to determine guidance for treatment changes. In some examples, the computing device 12, the computing device 42, and/or the IoT device 30 may communicate with the HMS22, and the HMS22 may determine and provide directions to the computing device 12, the computing device 42, and/or the IoT device 30 for the treatment change, which in turn may provide directions to the bystander 26 for the treatment change. In this way, the computing device 12, the computing device 42, and/or the IoT device 30 may provide real-time guidance to the bystander 26 regarding treatment of the patient 4. Because IMD 10 is positioned near or below the level of the heart of patient 4 near the sternum and is relatively stable within that location, information from accelerometer signals of accelerometers in IMD 10 may be relatively accurate for determining CPR guidance and diagnosing the heart rhythm of patient 4 when compared to accelerometers in other devices, such as computing device 12 or computing device 42.

In some examples, combinations of sensors of IMD 10 or external information may be synthesized using algorithms to determine and provide robust guidance. The algorithm may reside in memory IMD 10, computing device 12, computing device 42, ioT device 30, and/or HMS 22. The processing circuitry may utilize the algorithm to determine useful guidance based on the sensor data. Such guidance may be used by bystanders 26 to deliver higher quality CPR. For example, any of the computing device 12, computing device 42, and/or IoT device 30 may output a pace that is used by the spectator 26 in providing CPR and provide feedback regarding how well the spectator 26 is providing CPR or what the spectator 26 should make to improve the quality of the CPR that the spectator 26 is providing to the patient 4.

In some examples, the HMS22 may mediate two-way audio (and in some cases video) communication between the care provider 40 and the patient 4 or bystanders 26. Such communication may allow care provider 40 to assess the condition of patient 4 before the time they will begin nursing the patient, e.g., by communicating with patient 4 or bystanders 26 or by using a camera or other sensor of IMD 10, computing device 12, or IoT device 30, which may improve the efficacy of the care delivered to the patient. Such communication may also allow the care provider to instruct bystanders 26 about the first responder treatment of patient 4.

In some examples, the computing device 12, computing device 42, ioT device 30, drone 46, HMS22, or care provider 40 may instruct the bystander 26 to retrieve the automated CPR device 48 and place the automated CPR device on the patient 4 instead of instructing the bystander 26 to administer CPR. In some examples, the automated CPR device may be configured to deliver CPR to the patient 4. In some examples, IMD 10 may sense the administration of CPR via automated CPR device 48. IMD 10 may be communicatively connected to an automated CPR device 48 and provide information to automated CPR device 48 (which may be an example of a computing device) for guiding the treatment (e.g., CPR) of a patient. For example, IMD 10 may determine that automated CPR device 48 does not provide optimal CPR and may control the administration of CPR by automated CPR device 48. For example, IMD 10 may close-loop control automated CPR device 48 to provide better CPR based on the accelerometer and possibly other data sensed by IMD 10. In other examples, rather than controlling the administration of CPR by the automated CPR device 48, the IMD 10 may provide accelerometer data to the automated CPR device 48, and the automated CPR device 48 may determine that the automated CPR device 48 does not provide optimal CPR and alter the administration of CPR based on the accelerometer data. In another example, IMD 10 may provide accelerometer data to computing device 12 or computing device 42, and computing device 12 or computing device 42 may determine that automated CPR device 48 does not provide optimal CPR. In this example, the computing device 12 or the computing device 42 can control the automated CPR device 48 to change the administration of CPR based on the acceleration data.

In some examples, any of the computing devices 12, 42, and/or IoT devices 30 may be further communicatively connected with any of the computing devices 38, or any of the computing devices 38 may be further communicatively connected with any of the computing devices 12, 42, and/or IoT devices 30. In this way, care provider 40 may further provide instructions or guidance regarding the treatment of patient 4 to bystanders 26, such as through a live streaming session or telephone call.

In some examples, IMD 10 may detect that a shock or care has been delivered or is being delivered and may change the guidelines based on the detected shock or care. In some examples, the guidance may include a list of things that should not be done associated with treating a patient experiencing an acute health event (such as cardiac arrest). In some examples, if patient 4 is a hemorrhagic stroke patient, or if the accelerometer signal indicates a large impact, the guidance may include instructions not to administer to patient 4 tissue plasminogen activator or intravenous therapy. In some examples, the instruction may include not administering care, for example, if the patient has a "do not administer resuscitation" command known to care provider 40.

In some examples, the HMS22 may control the scheduling of the drone 46 to the environment 28, or to a location near the environment 28 or the patient 4. The drone 46 may be a robot and/or an Unmanned Aerial Vehicle (UAV). The drone 46 may be equipped with a plurality of sensors and/or actuators to perform a plurality of operations. For example, the drone 46 may include a camera or other sensor to navigate to its intended location, identify the patient 4, and in some cases, identify the bystander 26, and evaluate the condition of the patient, such as acquiring an ECG or measuring a pulse. In some examples, the drone 46 may act as an AED by contacting two portions of the body of the patient 4 with extendable arms having electrodes. In some examples, the drone 46 may include a user interface device that communicates with the patient 4 and/or the bystander 26. In some examples, the drone 46 may provide an indication to the bystander 26, to the location of the patient 4, and may provide an indication of how to provide first responder care (such as CPR) to the patient 4. In some examples, the drone 46 may carry a medical device (e.g., the AED 44) and/or medication to the location of the patient 4.

In some examples, data sensed by IMD 10 may be used to provide information to EMS computing device 38 for guiding therapy when an EMS person travels to the location of patient 4 or to an emergency room person at a medical facility. This may facilitate faster medical intervention by the EMS personnel when they reach the location of the patient 4, as well as when the patient 4 reaches a medical facility, as the EMS personnel and emergency room personnel may better understand which therapy was used when they first seen the patient 4. For example, IMD 10 may sense an indication of an acute health event of patient 4. IMD 10 may automatically record the ECG of patient 4 based on the sensing of the indication of the cardiac event. IMD 10 may provide information to computing device 38 or HMS22 for guiding the treatment of patient 4. The information may include an ECG. In some examples, the computing device 38 or HMS22 may employ algorithms that may be based on machine learning to analyze the information and determine an automatic diagnosis or machine diagnosis. For example, IMD 10 may sense cardiac arrest. The information may include an indication of sensed cardiac arrest. The computing device 38 or HMS22 may analyze this information to determine whether the cardiac arrest is truly a long-duration cardiac arrest. In some examples, IMD 10, computing device 38, or HMS22 may classify the sensed cardiac arrest as a true long-duration cardiac arrest. In some examples, ECG diagnostics, classification diagnostics, or automated diagnostics, or machine diagnostics may be provided to EMS personnel and/or emergency room personnel via computing device 38 so that EMS personnel may prepare the patient 4 for proper therapy when they reach the location of the patient 4, and emergency room personnel may prepare the patient 4 for proper therapy when the patient 4 reaches a medical facility. For example, the patient 4 may require as fast CPR and epinephrine as possible, and if the EMS personnel do not have ECG diagnostics, class diagnostics, or automated or machine diagnostics, the EMS personnel will lose valuable time assessing the condition of the patient 4 after reaching the location of the patient 4. Conversely, if IMD 10 detects a tachyarrhythmia and IMD 10, computing device 38, or HMS22 determines that the rhythm is a rapid, sustained, true ventricular arrhythmia, then the therapy should be to shock the patient using AED 44 to restore the heart to a sinus rhythm. EMS personnel can manage faster treatments by understanding the health of the patient 4 before they reach the location of the patient 4.

In some examples, the computing devices 38 associated with the EMS personnel and/or emergency room personnel may include smart phones, smart watches, tablet computers, laptop computers, desktop computers, and the like. Guidance may be provided to EMS personnel and/or emergency room personnel via the computing device 38. For example, the guidance may include an indication of what has occurred with the patient 4 and facilitate appropriate treatment of the patient 4 for the health condition of the patient 4.

For example, any one or combination of IMD 10, computing device 38, or HMS22 may be configured to detect differences between ischemic or hemorrhagic strokes and provide automated or machine diagnostics to EMS personnel and/or emergency room personnel. Such automatic or machine diagnostics may speed up the time of the intervention and/or speed up the changes in the treatment, as the EMS personnel and emergency room personnel will have a better understanding of the health of the patient 4 than they would otherwise be. Most diagnostic tools (e.g., computerized tomography machines, magnetic resonance imaging machines, blood testing laboratories) are located in medical institutions, and diagnosis using such diagnostic tools takes time. The techniques of the present disclosure may inform care providers to prepare for the required treatment, which may speed up the care provided to patient 4 and improve the chances of the best possible outcome for patient 4. For example, if the automated or machine diagnosis is ischemic stroke, the care provider may treat patient 4 with intravenous injection of tissue plasminogen activator, and if the automated or machine diagnosis is hemorrhagic stroke, the care provider may implant a stent.

In some examples, IMD 10 may be configured to sense data that may be utilized to determine automatic diagnosis or machine diagnosis of various acute health events, such as acute myocardial infarction, lethal arrhythmias, stroke, respiratory failure, and other emergency medical conditions. IMD 10, computing device 12, ioT device 30, and/or HMS22 may also be configured to provide relevant information to care provider 40 regarding the medical status of patient 4, diagnosis of patient 4, and relevant post-decision information (e.g., links to acute care guidelines) in an effort to better inform patient 4 (whether ambulatory or in a medical institution) of the needed care.

Certain acute health events, such as strokes, may require a thorough examination to enable the care provider to identify problems with the patient 4 and provide proper care in a timely manner. Not all medical institutions have the equipment necessary to perform these tasks. When time is of paramount importance, it is necessary to find the "best" match of a hospital, not the nearest one. For example, IMD 10 may sense an indication of an acute health event of patient 4. Upon sensing an indication of an acute health event or an automatic diagnosis or machine diagnosis of an acute health event (such as a stroke), a computing device (such as one of computing devices 38) or HMS22 may use the location of patient 4 and a database of layered medical facilities (which may be stored in computing device 38 or HMS 22) to determine a best match for patient 4 based on the indication or automatic diagnosis or machine diagnosis of the acute health event. When or before the EMS personnel arrives at the location of the patient 4, the computing device 38 may notify the EMS personnel of the likely condition of the patient 4 and the need for a particular healthcare facility route (e.g., a route to a best match). In some examples, the computing device 38 or HMS22 may send an alert to the selected medical facility that includes information related to an indication of the sensed acute health event and/or automatic diagnosis or machine diagnosis to facilitate preparing the patient 4 for reaching equipment, personnel, or facilities at the selected medical facility so that treatment may begin as soon as possible upon reaching the selected medical facility.

In the case of a stroke, the identification of the "last known healthy" time may be important information that the EMS may use to determine whether a critical medication may be delivered. In some examples, IMD 10 may be configured to determine a last known health time for patient 4 and provide the last known health time to computing device 38. In other examples, computing device 38 or HMS22 may be configured to determine a last known time of health for patient 4 based on information provided from IMD 10. In the event that the HMS22 determines the last known time of health of the patient 4, the HMS22 may be configured to provide the last known time of health to the computing device 38.

IMD 10, computing device 38, and/or HMS22 may be configured to determine an automatic diagnosis or a machine diagnosis using different sensor data based on the type of indication of the acute health event sensed by IMD 10. For example, if an indication of an acute health event is associated with the heart of patient 4, IMD 10, computing device 38, and/or HMS22 may use the ECG to determine an automatic diagnosis or a machine diagnosis, if the indication is associated with brain activity, IMD 10, computing device 38, and/or HMS22 may use the EEG to determine an automatic diagnosis or a machine diagnosis, if the indication is associated with respiratory distress, IMD 10, computing device 38, and/or HMS22 may use the accelerometer, ECG, and/or impedance measurements to determine an automatic diagnosis or a machine diagnosis, or if the indication is associated with a pre-fusion problem, IMD 10, computing device 38, and/or HMS22 may use oxygen saturation to determine an automatic diagnosis or a machine diagnosis.

Fig. 2 is a block diagram showing an exemplary configuration of IMD 10 of fig. 1. As shown in fig. 2, 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.

The processing circuitry 50 may include fixed function circuitry and/or programmable processing circuitry. The processing circuitry 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 equivalent discrete or analog logic circuit. In some examples, processing circuitry 50 may include multiple components (such as 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 any combinations of one or more FPGAs), as well as other discrete or integrated logic circuitry. The functions attributed to processing circuitry 50 herein may be embodied as software, firmware, hardware or any combination thereof. In some examples, memory 52 includes computer readable instructions that, when executed by processing circuitry 50, cause IMD 10 and processing circuitry 50 to perform various functions attributed to IMD 10 and processing circuitry 50 herein. Memory 52 may include any volatile, non-volatile, magnetic, optical, or electrical media, such as Random Access Memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), electrically Erasable Programmable ROM (EEPROM), flash memory, or any other digital media.

The sensing circuit 54 may monitor signals from the electrodes 56, for example, to monitor the electrical activity of the heart of the patient 4 and generate ECG data of the patient 4. In some examples, processing circuitry 50 may identify sensed characteristics of the ECG, such as heart rate, heart rate variability, intra-beat intervals, and/or ECG morphology characteristics, to detect arrhythmia episodes for patient 4. The processing circuit 50 may store characteristics of the digitized ECG and the ECG for detecting an arrhythmia episode in the memory 52 as episode data for the detected arrhythmia episode.

In some examples, sensing circuitry 54 measures, for example, impedance of tissue in the vicinity of IMD 10 via electrode 56. The measured impedance may vary based on the degree of respiration and perfusion or oedema. The processing circuit 50 may determine physiological data related to respiration, perfusion, and/or edema based on the measured impedance.

In some examples, IMD 10 includes sensing circuitry 54, such as one or more accelerometers, microphones, optical sensors, temperature sensors, and/or pressure sensors. In some examples, the sensing circuit 54 may include one or more filters and amplifiers for filtering and amplifying signals received from one or more of the electrodes 56 and/or the sensors 58. In some examples, the sensing circuit 54 and/or the processing circuit 50 may include rectifiers, filters and/or amplifiers, sense amplifiers, comparators, and/or analog-to-digital converters. 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.

Memory 52 may store applications 70, executable by processing circuitry 50, and data 80. The applications 70 may include an acute health event monitoring application 72. The processing circuitry 50 may execute the event monitoring application 72 to detect an acute health event 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 data sensed by other devices (e.g., computing device 12) and received via the communication circuit 60. The event monitoring application 72 may be configured with a rules engine 74. The rules engine 74 may apply rules 84 to the sensed data 82. Rules 84 may include one or more models, algorithms, decision trees, and/or thresholds. In some cases, rules 84 may be developed based on machine learning.

For example, the event monitoring application 72 may detect cardiac arrest, ventricular fibrillation, ventricular tachycardia, cardiac arrest, pulse-free electrical activity (PEA) or myocardial infarction based on the ECG and/or other physiological data indicative of electrical or mechanical activity of the heart 6 of the patient 4 (fig. 1). In some examples, event monitoring application 72 may detect a stroke based on such cardiac activity data. In some examples, the sensing circuit 54 may detect brain activity data, such as an electroencephalogram (EEG), via the electrodes 56, and the event monitoring application 72 may detect 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 the accelerometer or in combination with other physiological data. When the event monitoring application 72 detects an acute health event, the event monitoring application 72 may store the sensed data 82 (and in some cases, the window of data before and/or after the detection) that resulted in the detection as event data 86.

In some examples, in response to detection of an acute health event, processing circuitry 50 transmits event data 86 for the event to computing device 12 (fig. 1) via communication circuitry 60. The transmission may be included in a message indicating an acute health event, as described herein. The transmission of this 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.

Fig. 3 is a block diagram showing an exemplary configuration of computing device 12 of patient 4, which may correspond to either (or both) of computing devices 12A and 12B shown in fig. 1. In some examples, computing device 12 takes the form of a smart phone, laptop computer, tablet computer, personal Digital Assistant (PDA), smart watch, or other wearable computing device. In some examples, the computing device 42, ioT device 30, and automated CPR device 48 may be configured similar to the configuration of the computing device 12 illustrated in fig. 3.

As shown in the example of fig. 3, computing device 12 may be logically divided into user space 102, kernel space 104, and hardware 106. The hardware 106 may include one or more hardware components that provide an operating environment for components executing 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 processes and threads with higher rights than the user space 102. For example, kernel space 104 may include an operating system 120 that operates at a higher authority than components executing in user space 102.

As shown in fig. 3, hardware 106 includes processing circuitry 130, memory 132, one or more input devices 134, one or more output devices 136, sensing circuitry 138, and communication circuitry 140. Although shown as a stand-alone device in fig. 3 for purposes of illustration, computing device 12 may be any component or system that includes processing circuitry or other suitable computing environment for executing software instructions, and need not include, for example, one or more of the elements shown in fig. 3.

The processing circuitry 130 is configured to implement functions and/or processing instructions for execution within the 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, GPU, TPU, DSP, ASIC, FPGA, or equivalent discrete or integrated logic circuits.

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, including for example 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.

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

One or more output devices 136 of computing device 12 may generate output, for example, to patient 4 or another user. Examples of outputs are tactile output, audio output, and visual output. The output device 136 of the computing device 12 may include a presence-sensitive screen, sound card, video graphics adapter card, speaker, cathode Ray Tube (CRT) monitor, liquid Crystal Display (LCD), light Emitting Diode (LED), or any type of device for generating tactile, audio, and/or visual output.

The sensing circuitry 138 of the computing device 12 may sense a physiological parameter or signal of the patient 4. Sensor 138 may include electrodes, 3-axis accelerometers, optical sensors, impedance sensors, temperature sensors, pressure sensors, heart sound sensors, and other sensors, as well as sensing circuitry (e.g., including ADCs), similar to those described above with respect to IMD 10 and fig. 2.

The communication circuitry 140 of the computing device 12 may communicate with other devices by transmitting and receiving data. 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 may send and receive information. For example, the communication circuit 140 may include a radio transceiver configured to transmit data in accordance with a protocol such as 3G, 4G, 5G, wiFi (e.g., 802.11 or 802.15 ZigBee),Or->Low Energy (BLE) and the like.

As shown in fig. 3, the health monitoring application 150 executes in the user space 102 of the computing device 12. Health monitoring application 150 may be logically divided into a presentation layer 152, an application layer 154, and a data layer 156. The presentation layer 152 may include a User Interface (UI) component 160 that generates and presents a user interface of the health monitoring application 150.

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

Rules engine 172 analyzes sensed data 190 and, in some examples, patient input 192 and/or EHR data 194 to determine whether there is a sufficient likelihood that patient 4 is experiencing an acute health event detected by IMD 10. Sensing data 190 may include data received from IMD 10 as part of alert transmission, additional data transmitted from IMD 10 (e.g., in "real-time") and physiological and other data collected by computing device 12 and/or IoT device 30 regarding the condition of patient 4. As an example, the sensed data 190 from the 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, constitution, 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), respiration rate, maximum oxygen volume, blood glucose, peripheral perfusion, and sleep mode.

Patient input 192 may include a response to a query entered by health monitoring application 150 regarding the condition of patient 4, by patient 4, or by another user, such as bystanders 26. The interrogation and response may occur in response to detection of an event by IMD 10, or may have occurred prior to detection, e.g., as part of long-term monitoring of the health of patient 4. The health data recorded by the user 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 or compliance data, allergy data, demographic data, weight, and height. EHR data 194 may include any of the information regarding the historical condition or treatment of patient 4 described above. EHR data 194 may relate to cardiac arrest, tachyarrhythmia, myocardial infarction, stroke, epilepsy, chronic Obstructive Pulmonary Disease (COPD), a history of renal dysfunction or hypertension, a history of a procedure such as ablation or cardioversion, and healthcare utilization. EHR data 194 may also include demographic and other information of patient 4, such as age, gender, height, weight, and BMI.

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. In some examples, operation of rules 196 and rules engine 172 may provide a more complex analysis of sensed data received from IMD 10 than provided by rules engine 74 and rules 84. In some examples, rules 196 include one or more models developed through machine learning, and rules engine 172 applies feature vectors derived from the data to the models.

Rule configuration component 174 may be configured to modify rules 196 (and in some examples, rules 84) based on feedback indicating whether IMD 10 and computing device 12 detect and confirm an acute health event is accurate. Feedback may be received from the patient 4 or from the care provider 40 and/or the EHR 24 via the HMS 22. In some examples, rule configuration component 174 may utilize data sets from true-false detection and validation for supervised machine learning to further train models included as part of rules 196.

As described above, the event assistant 176 may provide a conversational interface for the patient 4 and/or spectator 26 to exchange information with the computing device 12. In response to receiving the alert message from IMD 10, event assistant 176 may query the user regarding the condition of patient 4. The response from the user may be included as patient input 192. The event assistant 176 may use natural language processing and context data to interpret the user's utterance. In some examples, in addition to receiving a response to a query posed by the assistant, the event assistant 176 may be configured to respond to a query posed by the user. In some examples, the event assistant 176 may provide an indication of and respond to a query from the patient 4 or bystander 26 regarding the treatment of the patient 4.

The location service 178 may determine the location of the computing device 12 and thereby determine the presumed location of the patient 4. The location services 178 may use Global Positioning System (GPS) data, multi-point location, and/or any other known technique for locating a computing device. In some examples, the location service 178 may utilize information from other devices in the environment 28 to determine the location of the patient 4. For example, location service 178 may use information from any of IMD 10, ioT device 30, or drone 46 to determine the location of patient 4.

Fig. 4 is a block diagram showing an operational perspective view of the HMS 22. The HMS22 may be implemented in a computing system 20 that may include hardware components embodied in one or more physical devices, such as hardware components of the computing device 12. Fig. 4 provides an operational perspective view of the HMS22 when hosted as a cloud-based platform. In the example of fig. 4, the components of HMS22 are arranged in accordance with a plurality of logical layers that implement the techniques of this disclosure. Each layer may be implemented by one or more modules including hardware, software, or a combination of hardware and software.

Computing devices, such as computing device 12, ioT device 30, computing device 38, and computing device 42, operate as clients in communication with HMS22 via interface layer 200. Computing devices typically execute client software applications such as desktop applications, mobile applications, and web applications. The interface layer 200 represents a set of Application Programming Interfaces (APIs) or protocol interfaces provided and supported by the HMS22 for client software applications. The interface layer 200 may be implemented with one or more web servers.

As shown in FIG. 4, the HMS22 also includes an application layer 202 that represents a collection of services 210 for implementing the functionality attributed to the HMS herein. The application layer 202 receives information from client applications, e.g., alerts for acute health events from the computing device 12 or IoT devices 30, and further processes the information according to one or more of the services 210 to respond to the information. The application layer 202 may be implemented as one or more discrete software services 210 executing 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 functions of the functional interface layer 200 and the application layer 202 as described above may be implemented at the same server. Service 210 may communicate via logical service bus 212. Service bus 212 generally represents a logical interconnect or set of interfaces that allow different services 210 to send messages to other services, such as through a publish/subscribe communication model.

Data layer 204 of HMS22 provides persistence for information in PPEMS 6 using one or more data repositories 220. Data repository 220 may generally be any data structure or software that stores and/or manages data. Examples of data repository 220 include, but are not limited to, relational databases, multidimensional databases, mappings, and hash tables, to name a few.

As shown in FIG. 4, each of the services 230-238 are implemented in a modular form within the HMS 22. Although shown as separate modules for each service, in some examples, the functionality of two or more services may be combined into a single module or component. Each of the services 230-238 may be implemented in software, hardware, or a combination of hardware and software. Further, the services 230-238 may be implemented as stand-alone devices, separate virtual machines or containers, processes, threads, or software instructions that are typically executed on one or more physical processors.

The event processor service 230 may, in response 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 of the patient and, in some examples, indicating that the transmitting device acknowledges the detection. The event processor service 230 may initiate performance of any operation in response to detection of an acute health event attributed herein to the HMS22, such as communicating with the patient 4, the bystander 26, and the care provider 40, initiating the drone 46, and in some cases, analyzing the data to confirm or override detection of the acute health event by the IMD 10.

The record management service 238 may store patient data included in the received alert message within the event record 252. The alert service 232 may package some or all of the data from the event records (with additional information as described herein in some cases) into one or more alert messages for transmission to the spectator 26 and/or the care provider 40. The care provider data 256 may store data used by the alert service 232 to identify to whom an alert is sent based on the location of the potential bystanders 26 and care provider 40 relative to the location of the patient 4 and/or the suitability of the care provided by the care provider 40 for the acute health event experienced by the patient 4.

In examples where HMS22 performs an analysis to confirm or override detection of an acute health event by IMD 10, event processor service 230 may apply one or more rules 250 to data received in the alert message, such as to feature vectors derived from the data by event processor service 230. Rules 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. Example machine learning techniques that may be used to generate rules 250 may include various learning styles, such as supervised learning, unsupervised learning, and semi-supervised learning. Example 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, dimension reduction algorithms, and the like. Various examples of specific algorithms include bayesian linear regression, enhanced 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), local Weighted Learning (LWL), ridge regression, least Absolute Shrinkage and Selection Operator (LASSO), elastic network and Least Angle Regression (LARS), principal Component Analysis (PCA), principal Component Regression (PCR).

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

As illustrated in the example of FIG. 4, the service 210 may also include an assistant configuration service 236 for configuring and interacting with event assistant 176 implemented in the computing device 12 or other computing devices.

Fig. 5 is a flow chart illustrating an example guidance technique of the present disclosure. The processing circuit 50 or processing circuit 130 may determine that the device detected an acute health event for the patient 4 or delivered CPR to the patient 4 (300). For example, IMD 10 may sense physiological data that may be indicative of an acute health event or delivery of CPR. Processing circuitry 50 or processing circuitry 130 may determine that IMD 10 detected an acute health event or delivered CPR based on the sensed physiological data.

The processing circuit 50 or the processing circuit 130 may analyze the sensed patient data in response to the determination (302). For example, processing circuitry 50 or processing circuitry 130 may analyze sensed patient data from IMD 10, ioT device 30, or drone 46.

The processing circuit 50 or the processing circuit 130 may provide information for guiding the treatment of the patient 4 based on the analysis (304). For example, the processing circuitry 50 or 130 may provide information to the spectator 26, to any of the IoT devices 30 (e.g., to the spectator 26 or EMS personnel in the environment 28), to the computing device 42 (e.g., to the spectator 26), to any of the computing devices 38 (e.g., to the various care providers 40), or to the automated CPR device 48 for guiding the treatment of the patient 4.

In some examples, the method of fig. 5 is performed by IMD 10, a smart phone, a wearable device (e.g., a smart watch), a tablet computer, a smart TV, a smart speaker, a smart camera, or an IoT device. In some examples, the acute health event is a cardiac event. For example, the acute health event may be cardiac arrest, acute myocardial infarction, lethal arrhythmia, or other cardiac event. In some examples, the acute health event may be a non-cardiac event. For example, the acute health event may be a stroke, fall, respiratory failure, or other non-cardiac event.

In some examples, the information for guiding the treatment of the patient 4 includes first instructions to the user regarding performing CPR. In some examples, processing circuitry 50 or processing circuitry 130 may determine that IMD 10 detects delivery of CPR to patient 4, analyze delivery of CPR to patient 4, and provide second instructions indicating a change to be made to the delivery of CPR based on the analysis of the delivered CPR. In some examples, the second instruction includes one of: user instructions for a user (e.g., bystander 26) to change at least one of the intensity or frequency of chest compressions of CPR, or control instructions configured to control the automated CPR device 48 to change at least one of the intensity or frequency of chest compressions of CPR.

In some examples, analyzing the delivery of CPR to the patient 4 includes analyzing at least one accelerometer signal or ECG signal (e.g., analyzing motion artifacts in the ECG signal). In some examples, at least one of the first instruction or the second instruction includes at least one of an audio instruction or a visual instruction. In some examples, the information includes an ECG, and wherein the ECG is automatically recorded by the implantable medical device in response to detecting an acute health event of the patient 4. In some examples, processing circuit 50 or processing circuit 130 may classify the ECG, where the information includes a classification of the ECG. For example, the processing circuit 50 or the processing circuit 130 may analyze artifacts in the ECG to determine whether the bystander 26 should change the CPR, e.g., to change the depth of the CPR faster or slower. In some examples, IMD 10, computing device 12, ioT device 30, or computing device 42 may communicate instructions to bystanders 26 (e.g., visually or audibly) on how to change delivery of CPR. In some examples, processing circuitry 50 or processing circuitry 130 may determine that delivery of CPR is not necessary, and IMD 10, computing device 12, ioT device 30, or computing device 42 may communicate instructions to bystanders 26 to pause the delivery of CPR.

In some examples, providing information for guiding treatment of patient 4 includes providing guidance to care provider 40. In some examples, the guidance includes automatic diagnostics. In some examples, the acute health event includes at least one of cardiac arrest, acute myocardial infarction, fatal arrhythmia, stroke, or respiratory failure (e.g., drowning, choking, smoke inhalation, etc.).

In some examples, the guidance includes an automated medical diagnosis, and the processing circuit 50 or the processing circuit 130 may determine the location of the patient 4 and determine a medical facility for treating the patient 4 from a plurality of medical facilities based on the location of the patient 4 and the automated medical diagnosis. In some examples, processing circuit 50 or processing circuit 130 may determine a time of a last known state of health of patient 4, wherein the determination of the medical facility is further based on the time of the last known state of health. In some examples, the determination of the medical facility is further based on equipment located at the medical facility.

Embodiment 1. A method comprising: determining, by the processing circuitry, that an acute health event of the patient or cardiopulmonary resuscitation (CPR) on the patient is detected by the device; in response to the determination, analyzing, by the processing circuit, the sensed patient data; and providing, by the processing circuit, information for guiding the treatment of the patient based on the analysis.

Embodiment 2. The method of embodiment 1, wherein the method is performed by an implantable medical device, a smart phone, a wearable device, a tablet computer, a smart TV, a smart speaker, a smart camera, or an internet of things device.

Embodiment 3. The method of embodiment 1 or embodiment 2, wherein the acute health event is a cardiac event.

Embodiment 4. The method of embodiment 1 or embodiment 2, wherein the acute health event is a non-cardiac event.

Embodiment 5. The method of embodiment 3 or embodiment 4 wherein the information for guiding the treatment of the patient comprises a first instruction to the user regarding performing CPR or delivering a drug.

Embodiment 6. The method of any of embodiments 3 to 5, further comprising: determining, by the processing circuit, that the device detects delivery of CPR to the patient; delivering CPR to the patient by the processing circuit analysis; and providing, by the processing circuit, a second instruction indicating a change to the delivered CPR based on the analysis of the delivered CPR.

Embodiment 7. The method of embodiment 6 wherein the second instruction comprises one of: user instructions for a user to change at least one of intensity or frequency of chest compressions of the CPR; or control instructions configured to control the automated CPR device to change at least one of the intensity or frequency of chest compressions of the CPR.

Embodiment 8. The method of embodiment 6 or embodiment 7 wherein analyzing the delivery of CPR to the patient comprises analyzing at least one accelerometer signal or electrocardiogram.

Embodiment 9. The method of any combination of embodiments 5-8, wherein at least one of the first instruction or the second instructions comprises at least one of an audio instruction or a visual instruction.

Embodiment 10. The method of any combination of embodiments 5-9, wherein the information comprises an Electrocardiogram (ECG), and wherein the ECG is automatically recorded by the device in response to detecting an acute health event of the patient.

Embodiment 11. The method of embodiment 10, further comprising: the ECG is classified by the processing circuitry, wherein the information includes a classification of the ECG.

Embodiment 12. The method of any combination of embodiments 5-11, wherein providing information that directs treatment of the patient comprises providing guidance to a care provider.

Embodiment 13. The method of embodiment 12 wherein the guidance comprises an automated diagnosis.

Embodiment 14. The method of any combination of embodiments 5-13, wherein the acute health event comprises at least one of cardiac arrest, acute myocardial infarction, lethal arrhythmia, stroke, or respiratory failure.

Embodiment 15. The method of any combination of embodiments 5-14, wherein the guidance comprises an automated medical diagnosis, the method further comprising: determining, by the processing circuit, a location of the patient; a medical facility for treating the patient is determined from a plurality of medical facilities by the processing circuit based on the location of the patient and the automated medical diagnosis.

Embodiment 16. The method of embodiment 15, further comprising: the time of the last known state of health of the patient is determined by the processing circuit, wherein the determination of the medical facility is further based on the time of the last known state of health.

Embodiment 17. The method of embodiment 15 or embodiment 16, wherein the determination of the medical facility is further based on equipment located at the medical facility.

Embodiment 18. An apparatus, the apparatus comprising a processing circuit; and a memory containing instructions that, when executed by the processing circuitry, cause the processing circuitry to perform: determining that the device detects an acute health event of the patient or delivers cardiopulmonary resuscitation (CPR) to the patient; analyzing the sensed patient data in response to the determination; and providing information for guiding the treatment of the patient based on the analysis.

Embodiment 19. The device of embodiment 18, wherein the device comprises an implantable medical device, a smart phone, a wearable device, a tablet computer, a smart TV, a smart speaker, a smart camera, or an internet of things device.

Embodiment 20. The device of embodiment 18 or embodiment 19, wherein the acute health event is a cardiac event.

Embodiment 21. The device of embodiment 18 or embodiment 19 wherein the acute health event is a non-cardiac event.

Embodiment 22 the device of embodiment 20 or embodiment 21 wherein the information for guiding the treatment of the patient comprises first instructions to the user regarding performing CPR or delivering a drug.

Embodiment 23 the apparatus of any one of embodiments 20 to 22, wherein the instructions further cause the processing circuit to: determining that the device detects delivery of CPR to the patient; analyzing delivery of CPR to the patient; and providing a second instruction indicating a change to the delivered CPR based on the analysis of the delivered CPR.

Embodiment 24. The apparatus of embodiment 23, wherein the second instruction comprises one of: user instructions for a user to change at least one of intensity or frequency of chest compressions of the CPR; or control instructions configured to control the automated CPR device to change at least one of the intensity or frequency of chest compressions of the CPR.

Embodiment 25 the device of embodiment 23 or embodiment 24 wherein the instructions cause the processing circuit to analyze at least one accelerometer signal or electrocardiogram as part of analyzing the delivery of CPR to the patient.

Embodiment 26. The device of any combination of embodiments 22-25, wherein at least one of the first instruction or the second instruction comprises at least one of an audio instruction or a visual instruction.

Embodiment 27. The device of any combination of embodiments 22-26, wherein the information comprises an Electrocardiogram (ECG), and wherein the ECG is automatically recorded by the device in response to detecting an acute health event of the patient.

Embodiment 28. The apparatus of embodiment 27, wherein the instructions further cause the processing circuit to: the ECG is classified, wherein the information includes a classification of the ECG.

Embodiment 29 the apparatus of any combination of embodiments 22-28, wherein the instructions cause the processing circuitry to provide guidance to a care provider as part of providing information for guiding treatment of the patient.

Embodiment 30. The device of embodiment 29, wherein the guidance comprises an automated diagnosis.

Embodiment 31 the device of any combination of embodiments 22-30, wherein the acute health event comprises at least one of cardiac arrest, acute myocardial infarction, lethal arrhythmia, stroke, or respiratory failure.

Embodiment 32 the apparatus of any combination of embodiments 22-31, wherein the guidance comprises an automated medical diagnosis, and wherein the instructions further cause the processing circuit to: determining a location of the patient; and determining a medical facility for treating the patient from a plurality of medical facilities based on the location of the patient and the automated medical diagnosis.

Embodiment 33. The method of embodiment 32 wherein the instructions further cause the processing circuit to: a time of a last known state of health of the patient is determined, wherein the determination of the medical facility is further based on the time of the last known state of health.

Embodiment 34 the apparatus of embodiment 32 or embodiment 33, wherein the determination of the medical facility is further based on equipment located at the medical facility.

Embodiment 35. A non-transitory computer-readable storage medium storing instructions that, when executed, cause processing circuitry to: determining that the device detects an acute health event of the patient or delivers cardiopulmonary resuscitation (CPR) to the patient; analyzing the sensed patient data in response to the determination; and providing information for guiding the treatment of the patient based on the analysis.

It should be understood that the various aspects disclosed herein may be combined in different combinations than specifically presented in the specification and drawings. It should also be appreciated that, depending on the example, certain acts or events of any of the processes or methods described herein can be performed in a different order, may be added, combined, or omitted entirely (e.g., not all of the described acts or events may be required to perform the techniques). Additionally, 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.

In one or more examples, the techniques described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include non-transitory computer-readable media corresponding to tangible media, such as data storage media (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 that can be accessed by a computer).

The 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 circuitry. Thus, the term "processor" or "processing circuit" as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. In addition, the present technology may be fully implemented in one or more circuits or logic elements.

Various examples have been described. These and other examples are within the scope of the following claims.

Claims (15)

1. A method, comprising:

determining, by a processing circuit, that an acute health event of a patient or cardiopulmonary resuscitation (CPR) on the patient is detected by a device;

in response to the determination, analyzing, by the processing circuitry, the sensed patient data; and

information for guiding treatment of the patient is provided by the processing circuitry based on the analysis.

2. The method of claim 1, wherein the method is performed by an implantable medical device, a smart phone, a wearable device, a tablet computer, a smart TV, a smart speaker, a smart camera, or an internet of things device.

3. The method of claim 1, wherein the acute health event is a cardiac event.

4. The method of claim 1, wherein the acute health event is a non-cardiac event.

5. A method according to claim 3, wherein the information for guiding treatment of the patient comprises a first instruction to a user regarding performing CPR or delivering a medicament.

6. A method according to claim 3, further comprising:

determining, by the processing circuit, that the device detects delivery of CPR to the patient;

analyzing, by the processing circuit, delivery of the CPR to the patient; and

A second instruction is provided by the processing circuit indicating a change to the delivery of the CPR based on the analysis of the delivery of the CPR.

7. The method of claim 6, wherein the second instruction comprises one of:

user instructions for a user to change at least one of intensity or frequency of chest compressions of the CPR; or (b)

Control instructions configured to control an automated CPR device to change at least one of intensity or frequency of chest compressions of the CPR.

8. The method of claim 6, wherein analyzing delivery of the CPR to the patient comprises analyzing at least one accelerometer signal or electrocardiogram.

9. The method of claim 5, wherein at least one of the first instruction or the second instruction comprises at least one of an audio instruction or a visual instruction.

10. The method of claim 5, wherein the information comprises an Electrocardiogram (ECG), and wherein the ECG is automatically recorded by the device in response to the detection of the acute health event of the patient.

11. The method of claim 10, further comprising:

Classifying the ECG by the processing circuitry,

wherein the information includes the classification of the ECG.

12. The method of claim 5, wherein providing information that directs treatment of the patient comprises providing guidance to a care provider.

13. The method of claim 12, wherein the guidance comprises an automatic diagnosis.

14. An apparatus, comprising:

a processing circuit; and

a memory containing instructions that, when executed by the processing circuitry, cause the processing circuitry to:

determining that a device detects an acute health event of a patient or delivers cardiopulmonary resuscitation (CPR) to the patient;

analyzing the sensed patient data in response to the determination; and

information is provided for guiding treatment of the patient based on the analysis.

15. A non-transitory computer-readable storage medium storing instructions that, when executed, cause a processing circuit to:

determining that a device detects an acute health event of a patient or delivers cardiopulmonary resuscitation (CPR) to the patient;

analyzing the sensed patient data in response to the determination; and

information is provided for guiding treatment of the patient based on the analysis.