阅读说明：本技术 用于医疗警告管理的系统 (System for medical alert management ) 是由 大卫·L·佩什巴赫 苏尼帕·萨哈 乔安娜·特拉普·辛普森 基思·马特森 于 2018-05-01 设计创作，主要内容包括：本文中描述了用于管理从一个或多个患者检测到的生理事件相关联的机器产生的医疗警告的系统和方法。警告管理系统可以接收从患者检测到的医疗事件和与患者历史医疗警告相关联的生理数据。所述系统包括警告优先级排序器电路,该电路使用检测到的医疗事件和与患者历史医疗警告相关联的生理数据之间的比较来产生事件优先级指示符。所述系统可以使用关于历史医疗警告的信息来识别多警告患者。警告优先级排序器电路可以调整检测到的医疗事件的优先级,输出电路可以使用事件优先级指示符和多警告患者的识别来向用户或处理呈现优先级。(Systems and methods for managing machine-generated medical alerts associated with physiological events detected from one or more patients are described herein. An alert management system may receive a medical event detected from a patient and physiological data associated with a historical medical alert for the patient. The system includes an alert prioritizer circuit that uses a comparison between a detected medical event and physiological data associated with a patient historical medical alert to generate an event priority indicator. The system may use information about historical medical alerts to identify multi-alert patients. The alert prioritizer circuit may adjust the priority of the detected medical events and the output circuit may use the event priority indicators and the identification of multiple alert patients to present the priority to a user or process.)

1. A system for managing machine-generated medical alerts, the system comprising:

a receiver circuit configured to receive information of a medical event detected from a patient and a historical medical alert associated with the patient;

an alert prioritizer circuit configured to generate event priority indicators for detected medical events using information of the detected medical events and historical medical alerts; and

an output circuit configured to output a priority of the detected medical event using the event priority indicator.

2. The system of claim 1, wherein the alert prioritizer circuit is configured to adjust the priority of the detected medical event by lowering the priority of the detected medical event when the detected medical event is similar to an event in the information of the historical medical alert.

3. The system of claim 1 or 2, wherein the alert prioritizer circuit is configured to adjust the priority of the detected medical event by increasing the priority of the detected medical event when the detected medical event is not similar to an event in the information of the historical medical alert.

4. The system of any of claims 1-3, wherein the information of the historical medical alert comprises an existing alert stored in memory.

5. The system of any of claims 1-4, further comprising a patient identifier circuit configured to identify a multi-alert patient having an amount of historical medical alerts exceeding a threshold during a specified time period,

wherein the alert prioritizer circuit is configured to further use the identification of the multiple alert patient to adjust the priority of the detected medical event.

6. The system of any of claims 1-5, further comprising:

a sensor circuit configured to sense a physiological signal from the patient; and a detector circuit configured to detect the medical event using the sensed physiological signal;

wherein the alert prioritizer circuit is configured to generate an event priority indicator using a comparison between information of the detected medical event and the historical medical alerts.

7. The system of claim 6, wherein the information of the historical medical alert includes a plurality of physiological signal characteristics corresponding to the historical medical alert, and the alert prioritizer circuit is configured to:

extracting a signal characteristic from the sensed physiological signal in response to detecting the medical event;

calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and is

Generating the event priority indicator using the similarity metric.

8. The system of claim 7, wherein the alert prioritizer circuit is configured to:

generating a representative historical signal characteristic from the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and is

A similarity measure is calculated between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the representative historical signal characteristics.

9. The system of claim 7, wherein the historical medical alert comprises one or more alert clusters, each alert cluster comprising a respective plurality of historical physiological signal characteristics, and wherein the alert prioritizer circuit is configured to:

calculating one or more similarity measures between the extracted signal characteristics corresponding to the detected medical event and a respective plurality of historical physiological signal characteristics of the one or more clusters; and is

Generating the event priority indicator using the one or more similarity metrics and a cluster priority.

10. The system of claim 9, wherein the one or more clusters comprise at least one of:

a true positive alert cluster comprising historical physiological signal characteristics corresponding to true positive detections of historical medical events; or

A false positive alarm cluster comprising historical physiological signal characteristics corresponding to false positive detections of historical medical events.

11. The system of claim 9, wherein the one or more clusters comprise one or more medical event types.

12. The system of claim 9, wherein the one or more clusters comprise one or more ranges of values of a physiological parameter.

13. The system of any of claims 1-12, wherein the output circuitry is configured to use the adjusted priority to schedule human-perceptible notifications of detected medical events.

14. The system of claim 13, wherein:

the alert prioritizer circuit is configured to generate respective event priority indicators for a plurality of detected medical events; and is

The alert prioritizer circuit is configured to: the method further includes adjusting the priority of the plurality of detected medical events using the respective event priority indicators and scheduling a human-perceptible notification that includes the presentation of the plurality of medical events arranged in descending order of the adjusted priority.

15. The system of any of claims 1-14, further comprising a memory circuit configured to:

storing information of the historical medical alerts; and is

Updating information of the historical medical alert by storing the detected medical event in the memory circuit.

Technical Field

This document relates generally to automated patient management and, more particularly, to systems, devices, and methods for managing alert notifications in automated patient management systems.

Background

Implantable Medical Devices (IMDs) have been used to monitor patient health or disease states and deliver therapy. For example, implantable cardioverter-defibrillators (ICDs) are used to monitor certain abnormal heart rhythms. Some IMDs may be used to monitor the progression of chronic diseases, such as worsening of cardiac performance due to Congestive Heart Failure (CHF). In addition to diagnostic capabilities, IMDs may also provide therapies to treat or alleviate certain medical conditions, such as cardiac electrical stimulation therapies to treat cardiac arrhythmias or to correct cardiac dyssynchrony in CFH patients.

The IMD may generate an alert notification when the occurrence of the alert condition triggers a notification scheme. The alert condition may include detection of a particular health condition or medical event, such as an arrhythmia or worsening heart failure. Alert notifications may be provided to the care provider to signal the patient's health condition. When notified, the care provider may review the patient medical records or the device recorded physiological data, determine the presence or cause of a medical event, or assess whether the prescribed treatment has resulted in the desired treatment outcome.

A patient management system may monitor a patient with an IMD interconnected to patient management via a data communication network, such as the internet. Such patient management systems have enabled care providers to remotely follow up with the patient or periodically assess device functionality.

Disclosure of Invention

The patient management system may manage a number of alert notifications corresponding to physiological events detected from Ambulatory Medical Devices (AMDs). For example, when managing a population of AMD patients in a clinic, the patient management system may frequently receive alert notifications regarding various arrhythmia onset or Worsening Heart Failure (WHF) events detected by an implantable cardiac device, such as a cardiac monitor, pacemaker, implantable defibrillator, or cardiac resynchronization therapy device. The implantable cardiac device may sense physiological data associated with the alert and store the physiological data in the implantable cardiac device. The implantable cardiac device may be queried and the physiological data may be retrieved and sent to the patient management system. The clinician may review the warnings and physiological data and take further action, such as deciding on the onset of an arrhythmia detected by the device, scheduling a patient follow-up, or reprogramming the implantable cardiac device.

With a large number of AMDs connected to a patient management system, reviewing alerts from all patients requires a significant amount of time and resources, and may be expensive or otherwise time consuming for a care facility. The present inventors have recognized significant challenges in efficient medical alert management, particularly the need for a method of providing automated remote patient management through configurable evaluation, prioritization and presentation of alert notifications. Such systems and methods may help improve timely medical attention to patients with alerts associated with critical medical conditions.

This document discusses, among other things, systems, devices, and methods for managing machine-generated medical alerts associated with events detected by non-stationary devices (such as AMDs). The patient management system may include a detector circuit that detects a medical event in a patient. The alert prioritizer circuit may generate an event priority indicator for the detected medical event using a comparison between the detected medical event and information regarding historical medical alerts for the patient. The system may additionally include a patient identifier circuit that identifies a multiple alert patient (PAP) using information that manages historical medical alerts. The output circuit may be configured to adjust the priority of the detected medical event using the event priority indicator and the identification of the PAP. The output circuitry may use the adjusted priority to schedule presentation of the detected medical event to the user or process.

Example 1 is a system for managing machine-generated medical alerts. The system comprises: a receiver circuit configured to receive information of a medical event detected from a patient and a historical medical alert associated with the patient; an alert prioritizer circuit configured to generate event priority indicators for detected medical events using information of the detected medical events and historical medical alerts; and output circuitry configured to output a priority of the detected medical event using the event priority indicator, such as for presenting the detected medical event to a user or process.

In example 2, the subject matter of example 1 optionally includes an alert prioritizer circuit that can be configured to adjust the priority of the detected medical event by lowering the priority of the detected medical event when the detected medical event is similar to an event in the information of the historical medical alert.

In example 3, the subject matter of any one or more of examples 1-2 optionally includes the alert prioritizer circuit that can adjust the priority of the detected medical event by increasing the priority of the detected medical event when the detected medical event is not similar to an event in the information of the historical medical alert.

In example 4, the subject matter of any one or more of examples 1-3 optionally includes information of the historical medical alert, which may include an existing alert stored in memory.

In example 5, the subject matter of any one or more of examples 1-4 optionally includes a patient identifier circuit configured to identify a multi-alert patient having an amount of historical medical alerts that exceed a threshold (e.g., a threshold magnitude) during a specified time period. The output circuit may be configured to adjust the priority of the detected medical event using the identification of the multiple alert patient. The output circuitry may be configured to schedule presentation of the detected medical event using the identification of the multiple alert patient.

In example 6, the subject matter of any one or more of examples 1-5 optionally includes a sensor circuit configured to sense a physiological signal from the patient and a detector circuit configured to detect the medical event using the sensed physiological signal. The alert prioritizer circuit may be configured to generate an event priority indicator using a comparison between information of the detected medical event and the historical medical alerts.

In example 7, the subject matter of example 6 optionally includes information of the historical medical alert, which may include a plurality of historical physiological signal characteristics corresponding to the historical medical alert. The alert prioritizer circuit may be configured to: extracting a signal characteristic from the sensed physiological signal in response to detecting the medical event; calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and using the similarity measure to generate an event priority indicator.

In example 8, the subject matter of example 7 optionally includes an alert prioritizer circuit that can be configured to: generating a representative historical signal characteristic from the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the representative historical signal characteristics.

In example 9, the subject matter of example 7 optionally includes a historical medical alert, which may include one or more alert clusters, each alert cluster including a respective plurality of historical physiological signal characteristics. The alert prioritizer circuit may be configured to: calculating one or more similarity measures between the extracted signal characteristics corresponding to the detected medical event and a respective plurality of historical physiological signal characteristics of the one or more clusters; and generating an event priority indicator using the one or more similarity metrics and the cluster priority.

In example 10, the subject matter of example 9 can optionally include the one or more clusters, which can include at least one of: a true positive alert cluster comprising historical physiological signal characteristics corresponding to true positive detections of historical medical events; or a false positive alarm cluster comprising historical physiological signal characteristics corresponding to false positive detections of historical medical events.

In example 11, the subject matter of example 9 can optionally include the one or more clusters, which can include one or more medical event types.

In example 12, the subject matter of example 9 can optionally include the one or more clusters, which can include one or more ranges of values for the physiological parameter.

In example 13, the subject matter of any one or more of examples 1-12 optionally includes output circuitry that may be configured to schedule a human-perceptible notification of the detected medical event using the adjusted priority.

In example 14, the subject matter of example 13 can optionally include that the alert prioritizer circuit can be configured to generate respective event priority indicators for a plurality of detected medical events. The alert prioritizer circuit may be configured to: the method further includes adjusting the priority of the plurality of detected medical events using the respective event priority indicators and scheduling a human-perceptible notification that includes the presentation of the plurality of medical events arranged in descending order of the adjusted priority.

In example 15, the subject matter of any one or more of examples 1-14 optionally includes memory circuitry configured to: information of the historical medical alert is stored, and the information of the historical medical alert is updated by storing the detected medical event in the memory circuit.

Example 16 is a machine-readable storage medium comprising a plurality of instructions that in response to being executed by processor circuitry of a computing device, cause the computing device to: receiving information of a detected medical event from a patient and a historical medical alert associated with the patient; generating an event priority indicator for the detected medical event using the information of the detected medical event and the historical medical alert; and adjust the priority of the detected medical event using the event priority indicator, such as for presenting the detected medical event to a user or process.

In example 17, the subject matter of example 16 optionally includes instructions that cause the computing device to identify a multi-alert patient having an amount of historical medical alerts that exceeds a threshold magnitude during a specified time period. The instructions to adjust the priority of the detected medical event include further using the identification of multiple alert patients.

In example 18, the subject matter of example 16 optionally includes information of the historical medical alert, which may include a plurality of historical physiological signal characteristics corresponding to the historical medical alert. The machine-readable storage medium further comprises instructions that cause the computing device to: receiving a physiological signal sensed during a detected medical event; extracting signal characteristics from the received physiological signal; and calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and generating an event priority indicator negatively correlated with the similarity measure.

In example 19, the subject matter of example 16 optionally includes instructions to generate an event priority indicator, which may include instructions to cause the computing device to: generating a representative historical signal characteristic from the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the representative historical signal characteristics.

Example 20 is a method for managing machine-generated medical alerts via a medical system. The method comprises the following steps: receiving information of a detected medical event from a patient and a historical medical alert associated with the patient; generating an event priority indicator for the detected medical event using the information of the detected medical event and the historical medical alert; and adjusting the priority of the detected medical event using the event priority indicator.

In example 21, the subject matter of example 20 can optionally include adjusting the priority, which can include one or more of: reducing the priority of the detected medical event when the detected medical event is similar to an event in the information of the historical medical alert; or increasing the priority of the detected medical event when the detected medical event is not similar to an event in the information of the historical medical alert.

In example 22, the subject matter of example 20 optionally includes identifying a multi-alert patient. The multi-alert patient may have an amount of historical medical alerts that exceed a threshold magnitude during a specified time period. The scheduling of presentation of the detected medical event may include further using the identification of multiple alert patients.

In example 23, the subject matter of example 20 optionally includes information of the historical medical alert, which may include a plurality of physiological signal characteristics corresponding to the historical medical alert. The subject matter optionally includes the steps of: receiving a physiological signal from the patient during the detected medical event; extracting signal characteristics from the received physiological signal; calculating a similarity measure between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the plurality of historical physiological signal characteristics corresponding to the historical medical alerts; and generating an event priority indicator negatively correlated with the similarity measure.

In example 24, the subject matter of example 23 optionally includes the step of generating a representative historical signal characteristic from the plurality of historical physiological signal characteristics corresponding to the historical medical alert. The similarity metric may be calculated as a distance between (1) the extracted signal characteristics corresponding to the detected medical event and (2) the representative historical signal characteristics.

In example 25, the subject matter of example 23 optionally includes a historical medical alert, which may include one or more alert clusters, each alert cluster including a respective plurality of historical physiological signal characteristics. The similarity measures may include one or more similarity measures between the extracted signal characteristics corresponding to the detected medical event and a respective plurality of historical physiological signal characteristics of the one or more clusters. The one or more similarity metrics and the cluster priority may be used to generate an event priority indicator.

The systems, apparatuses, and methods discussed in this document may improve techniques for automatic alert management. One of the challenges in medical alert management is that clinicians need to be aware of the vast number of alert notifications from patients. This document provides a technical solution to this technical challenge by exploring and utilizing, among other things, information about intra-patient and inter-patient variations of a patient's alert notifications, thereby helping clinicians prioritize their large number of alert notifications. In one aspect, the present inventors have recognized that alerts associated with device-detected physiological events (e.g., cardiac arrhythmia or heart failure worsening event) from a patient may represent varying degrees of severity. Alerts may be prioritized according to their severity before being presented to the clinician for evaluation. For example, an AMD patient may have arrhythmic events detected by the device in his/her medical history. Arrhythmia events detected by the device may be designated as True Positive (TP) detection or False Positive (FP) detection. TP detection is the detected arrhythmia episode that is truly the target arrhythmia type, FP detection is the detected arrhythmia episode that is actually a non-arrhythmic event or that belongs to another type of arrhythmia than the target arrhythmia. If the arrhythmia episode detected by the device is similar to historical TP detections, the detected arrhythmia episode is more likely to be a true target arrhythmia. As such, a higher severity is indicated, and a higher priority is assigned. However, if the arrhythmia episode detected by the device is similar to historical FP detection, it is unlikely to be a true target arrhythmia event. As such, a lower severity is indicated, and a lower priority is assigned. Prioritization of arrhythmic events detected by the device, such as by using comparisons with patient history TP or FP detections discussed in this document, may improve the performance of the alert management system to recognize high severity physiological events with higher accuracy (i.e., lower false alert rates) and alert clinicians of such events in a timely manner, yet with little additional cost or system complexity, as compared to conventional alert systems that provide clinicians with a large number of alerts associated with events having mixed severities.

In addition to the variation in severity among alerts within a patient, alerts from multiple patients may also exhibit inter-patient variation in alert severity. The present inventors have recognized that the amount or frequency of alert notifications presented to a patient management system may have a skewed distribution across the patient being monitored. For example, most alert notifications may come from a small percentage of patients. These patients, hereinafter referred to as multiple alert patients (PAP), may have alerts associated with medical events having substantially similar characteristics. Some PAPs may have frequent warnings corresponding to events that the patient manually activates. The alert prioritization discussed in this document may timely direct medical attention to patients who may have more serious events than those that may have frequent false positive detections. This may help to better line up medical resources to serve the needs of more patients, and may also help to save operating costs in a care facility. For example, by identifying patients with lower priority alerts (such as PAP), such patients may be scheduled, prescribed, or provided with fewer unnecessary medical interventions, such as medications, surgery, or device treatments. As a result, overall system cost savings may be realized.

Alert notification evaluation and prioritization as discussed in this document may also improve the functionality of the patient management system. Alert prioritization as discussed herein may be configured to evaluate and prioritize events detected by various physiological event detectors or AMDs. The alert prioritization may be implemented in and performed by the AMD or an external system, such as a communicator, a mobile monitor, a programmer, or a remote patient management system in communication with the patient AMD. As such, in some cases, improved alert management may be achieved without modifying existing patient AMD or physiologic event detectors. Additionally, system memory may be more efficient by storing a small number of alerts associated with medical events of higher severity and/or physiological information that is clinically more relevant to medical diagnosis (e.g., for diagnosing the type of arrhythmia suffered by a patient).

The discussion of alert prioritization in this document focuses on alerts of AMD detected arrhythmias. However, this is intended to be exemplary only, and not limiting. The systems, devices, and methods discussed herein are also used to assess and prioritize patient alerts for other medical conditions, such as the detection of worsening of chronic disease (such as suction failure, respiratory disease, or renal insufficiency, among others), within the contemplation of the inventors and within the scope of this document. In addition, although the systems and methods are described as being operated or employed by a clinician, the entire discussion herein applies equally to organizations including hospitals, clinics, and laboratories, as well as other individuals or interested parties seeking access to patient data (such as research institutes, scientists, universities, and institutions).

This summary is an overview of some of the teachings of the present application and is not intended to be an exclusive or exhaustive treatment of the present subject matter. Further details regarding the present subject matter are found in the detailed description and appended claims. Other aspects of the disclosure will become apparent to those skilled in the art upon reading and understanding the following detailed description and viewing the drawings that form a part hereof, each of which is not to be taken in a limiting sense. The scope of the invention is defined by the appended claims and their legal equivalents.

Drawings

Various embodiments are illustrated by way of example in the figures of the accompanying drawings. Such embodiments are illustrative, and are not intended to be exhaustive or exclusive embodiments of the present subject matter.

FIG. 1 generally illustrates an example of a patient management system and portions of an environment in which the system may operate.

FIG. 2 generally illustrates an example of an alert management system configured to evaluate and prioritize alerts for medical events associated with one or more patients.

Fig. 3A-3B generally illustrate block diagrams of event analyzer circuits, each configured to determine a similarity metric between a detected medical event and a historical medical alert.

FIG. 4 generally illustrates a block diagram of an alert management system configured to prioritize detection of medical events using clusters of historical medical alerts.

FIG. 5 generally illustrates an example of a method for managing machine-generated medical alerts.

Fig. 6 generally illustrates an example of a method for prioritizing medical events detected by the device for presentation to a user or processing.

Fig. 7 generally illustrates a block diagram of an example machine on which any one or more of the techniques (e.g., methods) discussed herein may execute.

Detailed Description

Disclosed herein are systems, apparatuses, and methods for managing machine-generated medical alerts associated with physiological events detected from one or more patients. The patient management system may receive a detected medical event from a patient and generate an event priority indicator for the detected medical event using a comparison between the detected medical event and a historical medical alert. The system may additionally use information about historical medical alerts to identify multiple alert patients (PAP). The system may use the event priority indicator and identification of the PAP to adjust the priority of the detected medical event for presentation of the event to the user or process.

Fig. 1 generally illustrates an example of a patient management system 100 and portions of an environment in which the system 100 may operate. The patient management system 100 may perform a range of activities including remote patient monitoring and diagnosis of disease conditions. Such activities may be performed by a centralized server (such as in a hospital, clinic, or doctor's office) or by a remote workstation (such as a secure wireless mobile computing device) in the vicinity of the patient, such as in the patient's home or office.

The patient management system 100 may include an ambulatory system 105 associated with the patient 102, an external system 125, and a telemetry link 115, the telemetry link 115 providing communication between the ambulatory system 105 and the external system 125.

Ambulatory system 105 may include an Ambulatory Medical Device (AMD) 110. In an example, the AMDs 110 may be implantable devices that are implanted subcutaneously in the chest, abdomen, or other portion of the patient 102. Examples of implantable devices may include, but are not limited to, pacemakers/defibrillators, Cardiac Resynchronization Therapy (CRT) devices, cardiac Remodeling Control Therapy (RCT) devices, neurostimulators, drug delivery devices, biological therapy devices, diagnostic devices (such as a heart monitor or cycle recorder), or patient monitors, among others. The AMDs 110 may alternatively or additionally include subcutaneous medical devices (such as subcutaneous monitors or diagnostic devices), external monitoring or therapeutic medical devices (such as Automated External Defibrillators (AEDs) or Holter monitors), or wearable medical devices (such as patch-based devices, smart phones, or smart accessories).

For example, the AMDs 110 may be coupled to the lead wire system 108. The lead system 108 may include one or more intravenously, subcutaneously, or non-invasively placed leads or catheters. Each lead or catheter may include one or more electrodes. The patient needs and the capabilities of the AMDs 110 may be used to determine the placement and use of the lead system 108 and associated electrodes. Associated electrodes on the lead system 108 may be positioned at the chest or abdomen of the patient to sense physiological signals indicative of cardiac activity, or physiological responses to diagnostic or therapeutic stimuli to the target tissue. By way of example, and not limitation, as shown in fig. 1, lead system 108 may be configured to be surgically inserted into heart 101 or positioned on a surface of heart 101. Electrodes on lead system 108 may be positioned on a portion of heart 101, such as the Right Atrium (RA), Right Ventricle (RV), Left Atrium (LA), or Left Ventricle (LV), or any tissue between or near portions of the heart. In some examples, lead system 108 and associated electrodes may alternatively be positioned on other parts of the body to sense physiological signals containing information about the patient's heart rate or pulse rate. In an example, the ambulatory system 105 may include one or more leadless sensors that are not tethered to the AMDs 110 via the lead system 108. The leadless ambulatory sensor may be configured to sense physiological signals and wirelessly communicate with the AMDs 110.

The AMDs 110 may be configured as monitoring and diagnostic devices. The AMDs 110 may include hermetically sealed canisters containing one or more of the following: sensing circuitry, control circuitry, communication circuitry, and a battery, among other components. The sensing circuit may sense a physiological signal, such as by using a physiological sensor or an electrode associated with the lead system 108. Examples of physiological signals may include one or more of the following: an electrocardiogram, intracardiac electrogram, arrhythmia, heart rate variability, intrathoracic impedance, intracardiac impedance, arterial pressure, pulmonary arterial pressure, left atrial pressure, Right Ventricular (RV) pressure, Left Ventricular (LV) coronary arterial pressure, coronary blood temperature, blood oxygen saturation, one or more heart sounds, intracardiac acceleration, physical activity or exercise level, physiological response to activity, posture, respiration rate, tidal volume, respiratory sounds, body weight, or body temperature, among others.

In an example, the AMD110 may include a detector circuit 160, the detector circuit 160 for detecting a medical event from a sensed physiological signal. In an example, the medical event includes a particular arrhythmia. Examples of arrhythmias may include atrial or ventricular slow or fast arrhythmias such as atrial fibrillation, atrial flutter, atrial tachycardia, supraventricular tachycardia, ventricular tachycardia, or ventricular fibrillation, among others. In an example, the arrhythmia detection circuit 160 is configured to detect a worsening of a chronic medical condition (such as heart failure). In another example, the medical event may include a patient-triggered event.

The AMD110 may alternatively be configured as a therapeutic device to treat arrhythmias or other cardiac diseases. The AMD110 may additionally include a therapy unit that may generate and deliver one or more therapies. Therapy may be delivered to the patient 102 via the lead system 108 and associated electrodes. The treatment may include electrical treatment, magnetic treatment, or other types of treatment. The therapy may include anti-arrhythmia therapy to treat the arrhythmia or to treat or control one or more complications from the arrhythmia (such as syncope, congestive heart failure, or stroke, among others). Examples of anti-arrhythmic therapies may include pacing, cardioversion, defibrillation, neuromodulation, drug therapy, or biologic therapy, among other types of therapy. In an example, the therapy may include Cardiac Resynchronization Therapy (CRT) for correcting dyssynchrony and improving cardiac function in a CHF patient. In some examples, the AMD110 may include a drug delivery system, such as a drug infusion pump that delivers drugs to a patient for management of arrhythmias or complications from arrhythmias.

The external system 125 may include a dedicated hardware/software system such as a programmer, a remote server-based patient management system, or alternatively a system defined primarily by software running on a standard personal computer. The external system 125 may manage the patient 102 through the AMDs 110 connected to the external system 125 via the communication link 115. This may include, for example, programming the AMDs 110 to perform one or more of the following operations: acquiring physiological data, performing at least one self-diagnostic test (such as for device operating status), analyzing the physiological data to detect arrhythmias, or alternatively delivering therapy to the patient 102 or adjusting therapy to the patient 102. Additionally, the external system 125 may receive device data from the AMDs 110 via the communication link 115. Examples of device data received by the external system 125 may include real-time or stored physiological data from the patient 102, diagnostic data (such as detection of an arrhythmia or heart failure worsening event), response to therapy delivered to the patient 102, or device operating states of the AMDs 110 (e.g., battery state and lead impedance). Telemetry link 115 may be an inductive telemetry link, a capacitive telemetry link, or a Radio Frequency (RF) telemetry link, or wireless telemetry based on, for example, "strong" bluetooth or IEEE 802.11 wireless fidelity "WiFi" interface standards. Other configurations and combinations of patient data source interfaces are possible.

By way of example, and not limitation, the external system 125 may include an external device 120 proximate to the AMDs 110 and a remote device 124, the remote device 124 being in relatively remote location from the AMDs 110, communicating with the external device 120 via the telecommunications network 122. Examples of external device 120 may include a programmer device.

The remote device 114 may be configured to, among other possible functions, evaluate the collected patient data and provide alert notifications. In an example, the remote device 124 may include a centralized server that acts as a central hub for storing and analyzing the collected patient data. The server may be configured as a single computing and processing system, a multiple computing and processing system, or a distributed computing and processing system. The remote device 124 may receive patient data from a plurality of patients, including, for example, the patient 102. Patient data may be collected by the AMDs 110, among other data acquisition sensors or devices associated with the patient 102. The server may include a memory device that stores patient data in a patient database. The server may include an alert analyzer circuit that evaluates the collected patient data to determine whether a particular alert condition is satisfied. Satisfaction of the alert condition may trigger generation of an alert notification. In some examples, the warning condition may alternatively or additionally be evaluated by the AMDs 110. By way of example, the alert notification may include a web page update, a telephone or pager call, an email, an SMS, a text or "instant" message, as well as a message to the patient and a simultaneous direct notification to emergency services and clinicians. Other alert notifications are possible. The server may include an alert prioritizer circuit configured to prioritize alert notifications. For example, alerts for a detected medical event may be prioritized using a similarity metric between physiological data associated with the detected medical event and physiological data associated with historical alerts. Examples of alert analyzer circuits and prioritizer circuits are discussed below, such as with reference to fig. 4-5.

The remote device 124 may additionally include one or more locally configured clients or remote clients securely connected to the server over the network 122. Examples of clients may include personal desktops, notebook computers, mobile devices, or other computing devices. A system user (such as a clinician or other qualified medical professional) may use the client to securely access stored patient data assembled in a database in the server, and select and prioritize patients and alerts for care orders. Example systems are described in the following patent applications: commonly assigned U.S. patent application No. 11/121,593 entitled "System and Method for Managing information in an Automated Payment Management System", filed on 3.5.2005; and U.S. patent application No. 11/121,594 entitled "System and method for Managing A paper document Management System" filed on 3.5.2005, the disclosure of which is incorporated by reference. In addition to generating alert notifications, the remote device 124 (including the server and interconnected clients) may also execute a follow-up protocol by sending a follow-up request to the AMDs 110, or by sending a message or other communication as a compliance notification to the patient 102, the clinician, or an authorized third party.

The network 122 may provide wired or wireless interconnection. In an example, the network 122 may be based on a transmission control protocol/internet protocol (TCP/IP) network communication specification, although other types or combinations of networking implementations are possible. Similarly, other network topologies and arrangements are possible.

One or more of the external device 120 or the remote device 124 may output the detected medical event to a system user (such as a patient or clinician) or process (including, for example, an instance of a computer program executable in a microprocessor). In an example, the processing may include automatic generation of a recommendation for anti-arrhythmic therapy or a recommendation for further diagnostic testing or treatment. In an example, the external device 120 or the remote device 124 may include a corresponding display unit for displaying a physiological signal or a functional signal, or an alert, alarm, emergency call, or other form of alert signaling detection of an arrhythmia. In some examples, the external system 125 may include an external data processor configured to analyze physiological or functional signals received by the AMD110 and confirm or deny detection of an arrhythmia. A computationally intensive algorithm, such as a machine learning algorithm, may be implemented in the external data processor to retroactively process the data to detect arrhythmias.

Portions of the AMDs 110 or external systems 125 may be implemented using hardware, firmware, or a combination thereof. The AMDs 110 or portions of the external system 125 may be implemented using application specific integrated circuits that may be constructed or configured to perform one or more particular functions, or may be implemented using general purpose circuits that may be programmed or otherwise configured to perform one or more particular functions. Such general-purpose circuitry may include a microprocessor or portion thereof, a microcontroller or portion thereof, or programmable logic circuitry, memory circuitry, a network interface, and various components for interconnecting these components. For example, a "comparator" may include, among other things, an electronic circuit comparator that may be configured to perform a particular function of a comparison between two signals, or a comparator may be implemented as part of a general purpose circuit that may be driven by code that instructs a portion of the general purpose circuit to perform a comparison between two signals.

FIG. 2 generally illustrates an example of an alert management system 200, which alert management system 200 may be configured to evaluate and prioritize alerts for medical events associated with one or more patients. At least a portion of the alert management system 200 may be implemented in the AMDs 110, the external systems 125 (such as one or more of the external devices 120 or the remote devices 124), or distributed between the AMDs 110 and the external systems 125. As shown in FIG. 2, alert management system 200 may include one or more of the following: sensor circuit 210, detector circuit 220, processor circuit 230, and user interface unit 250. Alert management system 200 may additionally be configured as a therapy system including an optional therapy circuit 260, therapy circuit 260 for delivering a therapy to treat a disease or to alleviate a medical condition.

The sensor circuit 210 may include a sense amplifier circuit that senses physiological signals sensed from a patient via one or more implantable, wearable, or otherwise ambulatory sensors or electrodes associated with the patient. The sensors may be incorporated into or otherwise associated with an ambulatory device, such as the AMDs 110. Examples of physiological signals may include, among others, a surface Electrocardiogram (ECG) sensed from electrodes placed on a body surface, a subcutaneous ECG sensed from electrodes placed under the skin, an intracardiac Electrogram (EGM) sensed from one or more electrodes on lead system 108, a thoracic or cardiac impedance signal, an arterial pressure signal, a pulmonary artery pressure signal, a left atrial pressure signal, an RV pressure signal, an LV coronary pressure signal, a coronary blood temperature signal, a blood oxygen saturation signal, a cardiac sound signal (such as sensed by an ambulatory accelerometer or acoustic sensor), a physiological response to activity, a sleep apnea hypopnea index, one or more respiratory signals (such as a respiratory rate signal or a tidal volume signal), Brain Natriuretic Peptide (BNP), a blood sample plate, sodium and potassium levels, glucose levels, and other biomarkers and biochemical markers. The sensor circuit 210 may include one or more sub-circuits that digitize, filter, or perform other signal conditioning operations on the received physiological signal.

The detector circuit 220 may be coupled to the sensor circuit 210 to detect a target medical event from the sensed physiological signal. In some examples, the physiological signals sensed from the patient may be stored in a storage device, such as an Electronic Medical Record (EMR) system. The detector circuit 220 may be configured to: in response to a user input or triggered by a particular event, a physiological signal is received from a storage device, and a target medical event is detected from the received physiological signal. In an example, the target medical event may include an arrhythmia episode. The detector circuit 220 may use heart rate, heart rate statistics (such as heart rate stability or variability), atrioventricular activation patterns (e.g., timing relationships between atrial activation and ventricular activation within a cardiac cycle), morphology of cardiac electrical or mechanical signals, or hemodynamic parameters to detect arrhythmias. In an example, the detector circuit 220 may be configured to detect ATRIAL FIBRILLATION (AF) using a Heart Rate Density Index (HRDI), which represents the percentage of heartbeats that fall within a histogram interval that includes heart rate patterns, such as those disclosed in commonly assigned U.S. provisional patent application No. 62/142,184 entitled "oral tissue DETECTION," filed on day 4/2 2015 by Mahajan et al, which is hereby incorporated by reference in its entirety, including its disclosure regarding HRDI and AF DETECTION using at least HRDI. In another example, the detector circuit 220 may be configured to detect AF using a characterization of the heartbeat as a stable heartbeat, an unstable heartbeat, or a random heartbeat, such as those disclosed in commonly assigned U.S. provisional patent application No. 61/109,963 entitled "PHYSIOLOGIC EVENT DETECTION AND DATA STORAGE," filed 2015 on 30.1.2015 by Mahajan et al, which is hereby incorporated by reference in its entirety (including its disclosure regarding the class of heartbeats AND at least AF DETECTION using the class of heartbeats). In another example, the target medical event may include a worsening chronic medical condition, such as Worsening Heart Failure (WHF). The detector circuit 220 may detect WHF by detecting trends in the physiological signal metric, such as one or more of: a decrease in thoracic impedance, an increase in breathing rate or Rapid Shallow Breathing Index (RSBI) calculated as a ratio of breathing rate measurement to tidal volume measurement, an increase in the strength or timing of the heart sound component, among others. In some examples, the detector circuit 220 may detect a patient-triggered event. This may include, for example, the AMDs 110, buttons or other actuator components on the handheld device, or through the user interface 250 when the patient experiences symptoms of the onset or precursor of the targeted medical event.

In some examples, the detector circuit 220 may receive contextual data, such as time of day, temperature, or other environmental parameters, in addition to sensed physiological data from the patient. The detector circuit 220 may also receive user inputs, such as patient medical information (e.g., answers to health questions) entered by the patient or care provider (such as via the user interface unit 250). The detector circuit 220 may use the sensed physiological signals, optionally along with contextual or environmental information or user input data, to detect the target medical event.

The processor circuit 230 coupled to the detector circuit 220 and the sensor circuit 210 may be configured to generate an event priority indicator for a detected medical event. The processor circuit 230 may be implemented as part of a microprocessor circuit, which may be a special-purpose processor such as a digital signal processor, an Application Specific Integrated Circuit (ASIC), a microprocessor, or other type of processor for processing information including physical activity information. Alternatively, the microprocessor circuit may be a general purpose processor that can receive and execute a set of instructions for the functions, methods, or techniques described herein.

The processor circuit 230 may include a circuit set that includes one or more other circuits or sub-circuits, such as an event analyzer circuit 232, an alert prioritizer circuit 234, and an optional patient identifier circuit 236. These circuits may perform the functions, methods, or techniques described herein, either individually or in combination. In an example, the hardware of the circuit group may be designed to perform certain operations unchanged (e.g., hardwired). In an example, the hardware of the circuit set may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a computer-readable medium physically modified (e.g., magnetically, electrically movable placement of particles of constant mass, etc.) to encode instructions for a particular operation. When physical components are connected, the basic electrical properties of the hardware composition change, for example, from an insulator to a conductor, or vice versa. The instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to create, with the hardware, via the variable connection, a means for the portion of the circuit group that performs a particular operation while in operation. Thus, when the apparatus is operating, the computer readable medium is communicatively coupled to other components of the circuit set means. In an example, any of the physical components may be used in more than one component of more than one circuit group. For example, in operation, an execution unit may be used in a first circuit of a first circuit group at one point in time and reused by a second circuit in the first circuit group or a third circuit in the second circuit group at a different time.

The event analyzer circuit 232 may be coupled to the sensor circuit 210 and the detector circuit 220. In response to the detector circuit 220 detecting the target medical event, the event analyzer circuit 232 may receive physiological data from the sensor circuit 210 for detecting the target medical event. The event analyzer circuit 232 may also be coupled to a memory circuit 240, the memory circuit 240 storing and maintaining a database containing information about patient historical medical alerts 242. Information about historical medical alerts 242 may include physiological data associated with existing medical alerts or medical alerts in a patient's medical history. The physiological data in the database may be of the same type as the physiological data associated with the detected medical event. For example, if the detector circuit 220 detects a target arrhythmia (e.g., AF) using an electrocardiogram sensed from a particular sensing vector including one or more electrodes from the lead system 108, the stored physiological data corresponding to the historical medical alerts 242 may also include an electrocardiogram of the heart sensed from the same sensing vector.

Event analyzer circuit 232 may evaluate the detected medical event against stored information regarding historical medical alerts 242. In some examples, the system 200 may include a receiver circuit in place of the sensor circuit 210 and the detector circuit 220. The receiver circuit may be configured to receive information of a medical event detected from a patient and a historical medical alert associated with the patient. Event analyzer circuit 232 may be coupled to the receiver circuit to evaluate the detected medical event against stored information regarding historical medical alerts 242. In an example, in response to detecting the target medical event, the event analyzer circuit 232 may compare physiological data associated with the detected medical event to stored physiological data associated with the historical medical alerts 242. In an example, a similarity metric may be calculated between physiological data associated with the detected medical event and stored physiological data associated with the historical medical alert. Examples of alert evaluation and similarity calculation are discussed below, such as with reference to fig. 3A-3B.

The alert prioritizer circuit 234 may use a similarity metric between physiological data associated with the detected medical event and stored physiological data associated with historical medical alerts to generate an event priority indicator for the detected medical event. The alert prioritizer circuit 234 may include a comparator circuit that compares the similarity metric to one or more thresholds or value ranges to classify the detected medical event as one of a plurality of predetermined degrees of priority, such as high, medium, or low priority. In an example, the classification may be such that a degree of priority is negatively correlated with the similarity metric, such that a lower priority may be assigned to detected medical events that are more similar to the historical alert and a higher priority may be assigned to detected medical events that are less similar to the historical alert. The present inventors have recognized that detected medical events that are not similar to historical alerts may represent medical conditions that were not seen in the patient's medical history, or a large change or progression of historical medical events that may require immediate medical attention. Assigning a higher priority to such medical events having unprecedented characteristics may alert the care provider to timely review the detected event, assess the patient's status, or provide prompt intervention or treatment accordingly. Additionally, as will be discussed below, such event prioritization may facilitate timely integration of newly detected medical events (optionally along with user decisions and annotations) into the database of historical medical alerts 242.

In some examples, the information about historical medical alerts 242 may include an indicator of the severity or clinical significance of the medical event associated with the historical medical alert. The severity indicator may be provided by a clinician. In an example, a historical medical event that results in a physician intervention or hospitalization may be designated as a severe historical medical alert. The alert prioritizer circuit 234 may compare the detected medical event to severe historical medical alerts and other non-severe historical medical alerts, such as alerts annotated by clinicians or those that do not result in hospitalization or intervention. The alert prioritizer circuit 234 may assign a higher priority to detected medical events that are similar to severe historical medical alerts or that are not similar to severe or non-severe historical alerts and a lower priority to detected medical events that are similar to non-severe historical alerts. Medical events with characteristics similar to severe medical events in a patient's medical history are likely to be clinically significant. Assigning a higher priority to such events may ensure immediate medical attention and intervention when needed. In some examples, alert prioritizer circuit 234 may assign a highest priority to detected medical events that are similar to severe historical alerts, followed by detected medical events that are not similar to severe or non-severe historical alerts, and assign a lowest priority to detected medical events that are similar to non-severe historical alerts.

The processor circuit 230 may include an optional patient identifier circuit 236 coupled to a memory circuit 240. The patient identifier circuit 236 may be configured to identify at least one multiple alert patient (PAP) from the plurality of patients using the stored information regarding patient historical medical alerts 242. PAP is a patient who has a large number of medical alerts (e.g., alerts of the onset of atrial fibrillation) of the same type over a particular period of time. The inventors have recognized that, among the alert notifications presented to the patient management system, most alert notifications may come from a small percentage of PAP. Frequent warnings may reflect a patient's underlying medical condition. For example, some PAPs may experience frequent recurrences of the same type of medical condition, such as ventricular arrhythmia bursts, post-operative (e.g., cardioversion) repetitive atrial fibrillation, or pressure-related instability of the medical condition. Frequent alerts may also be caused by event detection and alert reporting systems. For example, the arrhythmia detection system may repeatedly generate false positive detections of arrhythmias in the patient. In some patients, the detection system may intermittently detect a basic sustained medical condition in the patient, resulting in a plurality of individual alerts, each alert having a relatively short duration, also referred to as a broken alert. In the case of WHF detection, a fragmentation alert may result from repeated detection and loss of detection of a single basic WHF event, and is more likely to occur when the patient's response to a basic WHF event fluctuates. Frequent alerts may also include patient-triggered events. As previously discussed, the alert may be activated by the patient when the patient experiences the onset of a medical event, such as by pressing a button on an implantable device or otherwise non-stationary device or handheld device. It has been noted that some PAPs are more prone to frequent activation of triggers (such as due to heightened anxiety), which results in frequent and extensive warning notifications.

The patient identifier circuit 236 may designate the patient as PAP if the total count of historical medical alerts 242 for the patient exceeds a threshold, or if the frequency of historical medical alerts 242, which is calculated as the amount of historical medical alerts over a specified period of time (e.g., one week or one month), exceeds a threshold. Frequent alerts from PAP may be repeated alerts, repeated false positive detections, or frequent patient-triggered events associated with medical events of substantially similar characteristics. As such, a large number of alerts from PAP may be less meaningful than alerts from non-PAP when the alerts are prioritized, such as for evaluation and decision by a care provider. The patient identifier circuit 236 may assign a lower subject priority to an identified PAP and a high subject priority to a non-PAP.

In an example, the system 200 may monitor, evaluate, and prioritize medical events from multiple patients in a clinic that interconnect their AMDs to the system 200. Each of these patients may have one or more detected medical events. The alert prioritizer circuit 234 may use both a similarity metric between the detected medical event and the historical medical alerts provided by the event analyzer circuit 232, and the identification of the PAP provided by the patient identifier circuit 236 to prioritize the medical events of the plurality of patients. In an example, the prioritization may include object prioritization and event prioritization. The subject prioritization may include identifying at least one PAP and assigning a lower subject priority to him. Within each patient or each PAP, the event prioritization may be by using a similarity metric between the detected medical event and the historical medical alert such that lower event priorities are assigned to medical events that are more similar to the historical medical alert and higher priorities are assigned to medical events that are less similar to the historical medical alert.

The user interface unit 250 may include an input unit 252 and an output unit 254. In an example, at least a portion of the user interface unit 250 may be implemented in the external system 125. The input unit 252 may receive user input for programming the detector circuit 220, such as, among other things, parameters and thresholds for detecting arrhythmias or WHF events. The input unit 252 may include an input device such as a keyboard, an on-screen keyboard, a mouse, a trackball, a touch pad, a touch screen, or other pointing device or navigation device. The input unit 252 may receive user inputs via input devices for programming the processor circuit 230, such as parameters and thresholds for calculating a similarity measure between a detected medical event and a historical medical alert, identifying a PAP, and generating a priority indicator. In some examples, via input unit 252 and output unit 254, a system user may interactively annotate or mark on a presentation of detected medical events, such as by deciding on detected arrhythmia episodes (e.g., annotating with an explanatory note such as arrhythmia type, or marking arrhythmia episodes as true positive or false positive detection). The plurality of detected medical events may be decided in descending order of priority indicators of arrhythmia episodes. The memory circuit 240 may be configured to update the database by integrating the detected medical event and associated physiological data, optionally along with annotations, decisions, or other user feedback, into the stored historical medical alerts.

The output unit 254 may include circuitry configured to adjust a priority of the detected medical event and use the adjusted priority to schedule human-perceptible notifications of the detected medical event. The adjustment of the priority may include reorganizing or collating detected medical events according to their event priority indicators. In an example, a plurality of medical events detected from a patient may each have their respective priority indicators. The output unit 254 may arrange presentation of the plurality of medical events in a particular order, such as a descending order of adjusted priorities. In some examples, the adjustment of the priorities and the scheduling of the presentation may include reorganizing or organizing the patients based on information about the object priorities. For example, medical events detected from multiple patients may be prioritized according to subject priority, such that PAP may generally have a lower priority than non-PAP. The output unit 254 may schedule the presentation of medical events associated with non-PAP prior to presenting medical events associated with PAP. In some examples, medical events detected from multiple patients may be prioritized according to both subject priority and event priority. Within each patient (e.g., PAP), detected medical events that are more similar to the historical medical alerts of the same patient are assigned a lower event priority than detected medical events that are less similar to the historical medical alerts and are presented to the care provider after the detected medical events that are less similar to the historical medical alerts.

The output unit 254 may include a display for displaying, among other things, patient physiological data associated with the detected medical event, intermediate measurements or calculations (such as signal characteristics, similarity metrics, alert priority indicators), or one or more historical medical alerts deemed similar to the detected medical event from the event analyzer circuit 232. In some examples, the output unit 254 may display the detected medical events, along with their respective priority indicators and PAP or non-PAP identifiers. non-PAP or high priority medical events may be color coded, highlighted, or otherwise indicated on the display to distinguish them from PAP or low priority detected medical events. Output unit 254 may include a printer for printing a hard copy of the detected information. The information may be presented in a table, chart, diagram, or any other type of text format, tabular format, or graphical presentation format. The presentation of the output information may include audio or other media formats. In an example, the output unit 254 may generate an alert, alarm, emergency call, or other form of alert to signal a medical event detected by a system user.

Optional therapy circuitry 260 may be configured to deliver therapy to the patient in response to detecting the medical event. Examples of therapy may include electrical stimulation therapy delivered to the heart, neural tissue, other target tissue, cardioversion therapy, defibrillation therapy, or drug delivery including delivery of drugs to tissues or organs. In some examples, the therapy circuit 260 may modify existing therapies, such as adjusting stimulation parameters or drug dosage.

Fig. 3A-3B generally illustrate block diagrams of event analyzer circuits 300A and 300B, the event analyzer circuits 300A and 300B each being configured to determine a similarity metric between a detected medical event and a historical medical alert 242. Event analyzer circuits 300A and 300B may each be an embodiment of event analyzer circuit 232 of alert management system 200.

As shown in fig. 3A, the event analyzer circuit 300A may include a signal feature extractor 310, a similarity calculator 320, and a fusion circuit 330. The signal feature extractor 310 may extract signal characteristics from the physiological data Y sensed by the sensor circuit 210. Signal feature extractor 310 may additionally extract signal characteristics from physiological data associated with historical medical alerts 242, historical medical alerts 242 being labeled { X }₁,X₂,...,X_NDenotes, where N indicates the number of historical alerts, X_iIndicating stored information corresponding to the ith historical alert.

The signal feature extractor 310 may use the extracted signal characteristics to construct a set of features, which is denoted by Y ═ { Y (1), Y (2),.., Y (M) }, where M indicates the number of signal characteristics, and Y (j) denotes a measurement of the jth signal characteristic. The signal characteristics may be generated from multiple data sources, such as signals from multiple sensors. Alternatively or additionally, the signal characteristics may represent different statistical or morphological measurements from the same sensor signal. Signal feature extractor 310 may similarly extract from each X_i(for i ═ 1,2, …, N) extracting the corresponding feature set, which is shared by X_i＝[X_i(1),X_i(2),…,X_i(M)]Is represented by the formula, wherein X_i(j) Indicating historical warning X_iOf the signal characteristic (j). In an example, physiological data Y and stored historical physiological data X_iMay have different feature dimensions (e.g., Y includes M signal characteristics or features, X_iIncluding K signal characteristics and K ≠ M), Y, and X_iIncluding at least one signal characteristic of the same type.

In an example, the detector circuit 220 detects a target medical event, such as a Worsening Heart Failure (WHF) event, using a plurality of sensors, e.g., a thoracic impedance sensor, a heart sound sensor, a respiration sensor, among othersA heart electrical activity sensor or a body activity sensor. The feature set Y ═ Y (1), Y (2), Y (m) of the detected medical event includes signal characteristics extracted from different sensors or from the same sensor. Similarly, feature set X for ith historical WHF event (among N historical alerts)_i＝[X_i(1),X_i(2),…,X_i(M)]Signal characteristics corresponding to the M signal characteristics in Y may be included. For example, if Y (j) represents a thoracic impedance (Z) trend measurement, and Y (k) represents a third heart sound (S3) intensity trend measurement corresponding to the detected medical event, then X_i(j) Denotes Z trend measurement, X_i(k) Representing the S3 intensity trend measure corresponding to the ith historical WHF event.

Similarity calculator 320 may calculate the detected medical event and historical medical alerts X₁,X₂,...,X_NA similarity measure between each of them. The similarity measure may comprise a distance measure between signal characteristics extracted from physiological data associated with the detected medical event and signal characteristics extracted from physiological data associated with the ith alert, the distance measure being expressed in d (Y, X)_i) And (4) showing. When Y and X_iIs a multi-dimensional feature set (where Y ═ { Y (1), Y (2), Y (m) }, X_i＝[X_i(1),X_i(2),…,X_i(M)]) Then d (Y, X) can be calculated in the multi-dimensional feature space_i). Examples of such distances may include, among others, Euclidean distances, Mahalanobis distances, correlation coefficients, or L1, L2, or infinite norms.

In some examples, the similarity metric and event prioritization may further be determined by using a quality of physiological data, such as a signal-to-noise ratio (SNR), of one or more physiological signals used to detect the target medical event. When the similarity measure is Y and X_iThe Euclidean distance d (Y, X) therebetween_i) In examples of (2), the squared difference of individual signal characteristics, such as (Y (j) -X_i(j))²Each may be weighted with the corresponding SNR associated with the signal characteristic, that is:

wherein the weight factor is { α_jCan be proportional to the SNR of the physiological signal from which the signal characteristic y (j) is extracted. A sensor signal with a higher SNR may dominate the determination of the similarity measure than a sensor signal with a lower SNR. For example, the detector circuit 220 uses a plurality of sensors (including a thoracic impedance signal and a heart sound signal) to detect the target medical event. The physiological data corresponding to the detected medical event, Y, represented by a multi-dimensional feature vector, Y ═ Y (1), Y (2), Y (m) }, includes Y (j) representing a thoracic impedance trend measurement and Y (k) representing an S3 intensity trend measurement. If the impedance signal has a higher SNR than the heart sound signal, then Y and X are calculated_iIn some examples, predicted power or historical performance of physiological signals or signal features used to detect the target medical event may be used to determine a weighting factor { α_j}. in some other examples, the weighting factor { α_jIt may be user programmable.

The fusion circuit 330 may use the resulting N similarity metrics (such as distance measure d (Y, X)₁),d(Y,X₂)},…,d(Y,X_N) To compute a composite similarity measure representing the similarity between the detected medical event and the stored historical alerts. The synthetic similarity measure may be computed as a weighted combination of distance measures, that is:

in an example, the weighting factor w may be determined according to the temporal proximity of the historical medical alert to the detected medical event_i}. Recent historical alerts (such as X)_i(temporally proximate detected medical events)) may correspond to historical alerts that are further away (such as X)_j(temporally distant from detected medical events)) large weighting factor w_i. In some instances, only the use ofThe composite similarity measure D is calculated as part of a historical medical alert that occurs during a specified period of time, such as within a week, month, or year prior to the detected medical event. The alert prioritizer circuit 234 may use the composite similarity measure D to prioritize the detected medical events.

Fig. 3B illustrates an event analyzer circuit 300B, which event analyzer circuit 300B may include a signal feature extractor 310, a similarity calculator 320, and a corresponding historical alert generator 340. Signal feature extractor 310 may extract signal characteristics Y from physiological data associated with the detected medical event and signal characteristics { X from physiological data associated with the N stored historical medical alerts₁,X₂,...,X_N}. A representative historical alert generator 340 coupled to the signal feature extractor 310 may derive the historical signal characteristics { X } from₁,X₂,...,X_NGenerating a representative signal property rX. In an example, rX may be calculated as N alerts { X₁,X₂,...,X_NCentral trend of signal characteristics of. In another example, rX may be calculated as N alerts { X₁,X₂,...,X_NCentral trends in signal characteristics of selected portions of (such as those alerts that occur within a specified time period prior to a detected medical event). An example of a central trend may include from stored physiological data { X }₁,X₂,...,X_NThe statistical distribution of the means, median, mode or measure of acquisition. In an example, the representative historical signal characteristic rX is stored physiological data { X₁,X₂,...,X_NThe centroid of the array. The centroid measure represents the signal characteristics of the most common historical medical alerts. When representing historical medical alerts X with a multi-dimensional feature set_iIn time, event analyzer circuit 232 may calculate historical alerts { X }₁,X₂,...,X_NAlong each feature dimension. The resulting representative historical signal characteristic, rX, may represent { X in a multi-dimensional feature space₁,X₂,...,X_NThe centroid of the array.

The similarity calculator 320 may calculate a similarity measure between the signal characteristic of the physiological data Y and the representative historical signal characteristic rX, that is, D ═ D (rX, Y). The alert prioritizer circuit 234 may use the composite similarity measure D to prioritize the detected medical events.

FIG. 4 generally illustrates a block diagram of an alert management system 400, the alert management system 400 configured to prioritize detection of medical events using clusters of historical medical alerts. Alert management system 400, an embodiment of alert management system 200, may include a processor circuit 430. The processor circuit 430 may include an event analyzer circuit 432 and an alert prioritizer 434. An embodiment of the event analyzer circuit 432, the event analyzer circuit 232, may receive physiological data for detecting a target medical event from the sensor circuit 210 and information regarding historical medical alerts for a patient from the memory circuit 240.

The stored information regarding historical medical alerts may include historical alert clusters 244 in the patient medical history. Alerts within the same cluster may have similar signal characteristics such that the distance between signal feature vectors associated with any two medical alerts within the alert cluster falls below a threshold. For example, if d (X)_i,X_j)<T, then X_iAnd X_jBelong to the same warning cluster, where T represents a threshold.

An unsupervised learning algorithm that utilizes a distance measure between alerts may be used to group historical medical alerts into one or more alert clusters. In an example, the clustering algorithm may include K-means clustering that minimizes an objective function, such as a total squared distance between physiological data associated with a single warning and a cluster center. The cluster center of each cluster represents the centroid of the alerts within that cluster. In another example, the clustering algorithm may include fuzzy C-means clustering that minimizes an objective function (such as a total weighted squared distance between physiological data associated with individual alerts and cluster centers), where the weight represents the degree of membership of a particular alert within a cluster. Fuzzy segmentation of medical alerts is performed through iterative optimization of objective functions in which membership and cluster centers are updated. Other examples of clustering algorithms may include, among others, hierarchical clustering using iterative updating of clusters that incorporate alerts using similarity measures, or a mixture of gaussian or other model-based clustering algorithms.

In addition to or instead of unsupervised clustering, supervised learning algorithms (such as clustering according to user-specified criteria or clustering characteristics) may be used to aggregate historical medical alerts. In an example, the alert cluster may be formed from one or a subset of signal characteristics (such as one or more value ranges of a physiological parameter). For example, the alert cluster may include historical arrhythmia clusters defined by a heart rate range, such as clusters of 100-. Historical arrhythmia clusters may be defined using ranges of other parameters, such as heart rate stability ranges, signal amplitude or intensity ranges (such as the intensity measured by an electrocardiogram or physiological sensor), atrioventricular timing ranges, arrhythmia duration ranges, physical activity intensity ranges, or duration ranges, among others. The physiological parameters used to define the clusters may be specific to a particular arrhythmia type. For example, in detecting atrial tachyarrhythmia such as atrial fibrillation, a cluster may be defined as one or more of: a range of heart rate variability, a range of relative counts (e.g., ratios) of stable versus unstable heartbeats over a specified period of time, a range of Heart Rate Density Indices (HRDI) representing percentages of heartbeats that fall within a histogram interval of patterns that include heart rate, a range of Wenkebach scores that indicate frequencies of abnormal atrioventricular conduction, or a range of cardiac morphology statistics, among others.

A cluster may be defined as one or more user-specified event types. In an example, historical medical alerts may be aggregated based on one or more specified types of arrhythmias (such as bradycardia, ventricular tachycardia, ventricular fibrillation, atrial tachycardia, atrial fibrillation, atrial flutter, supraventricular tachycardia, electrical pause, among others).

In some examples, at least some of the stored historical medical alerts may have been reviewed, rated, or annotated by the care provider. For example, historical medical alerts associated with an arrhythmia episode may be determined to be a particular arrhythmia type, or to be one of: a True Positive (TP) detection, a False Positive (FP) detection, a True Negative (TN) detection, or a False Negative (FN) detection. The stored historical medical alerts may be aggregated according to a decision (such as TP cluster, FP cluster, TN cluster, or FN cluster).

Each cluster may have a cluster center with representative historical signal characteristics. The cluster center may be determined and updated iteratively during the clustering process. The cluster center may represent the centroid of the member alerts within the cluster, or the mean feature vector of a gaussian or other statistical model of the cluster. By way of example, and not limitation, historical medical alerts may be aggregated to have a common { C }₁,C₂,...,C_KDenotes K clusters of cluster centers. Each cluster center may be represented by a number such as C_i＝[C_i(1),C_i(2),…,C_i(M)]Where M indicates the total number of signal characteristics. Event analyzer circuitry 432 may calculate a feature vector Y ═ Y (1), Y (2),. Y (m) } and a cluster center C associated with the detected medical event_i(for i ═ 1,2, …, K) similarity measures between each. The similarity measure may be computed as a distance measure in a multi-dimensional feature space using d (Y, C)_i) And (4) showing.

The alert prioritizer 434 (which may be an embodiment of alert prioritizer 234) may use a similarity metric d (Y, C)₁),d(Y,C₂),…,d(Y,C_K) To generate an event priority indicator for the detected medical event. In an example, the warning prioritizer 434 may be coupled to the memory circuit 240 to receive the cluster priorities 246. The cluster priority 246 may be a predetermined or user-specified quantity indicating the relative significance of one cluster over another. The alert prioritizer 434 can further use the cluster priority 246 to generate event priority indicators for detected medical events. For example, such asFruit C₁Is the center of cluster #1, C₂Is the center of cluster #2 and cluster priority 246 provides that cluster #1 has a higher cluster priority than cluster #2, then if d (Y, C)₁)<d(Y,C₂) Then a higher priority is assigned to Y because Y is similar to the historical alert (i.e., cluster #1) with the higher assigned priority.

In an example, historical medical alerts are clustered by an aggregated TP (which has a cluster center C)_TP) And FP (which has a cluster center C_FP) Of the above, a higher priority may be assigned to TP clusters than FP clusters at least because TP clusters represent alerts associated with true occurrences of target medical events (such as arrhythmias or WHFs), while FP clusters represent false alerts associated with non-occurrences of target medical events. If the similarity of the detected medical event Y to the TP cluster is higher than the similarity to the FP cluster (e.g., d (Y, C)_TP) Ratio d (Y, C)_FP) Short certain margin), the alert prioritizer 434 can assign a higher priority to the detected medical event Y if the detected medical event Y has a higher similarity to the FP cluster (e.g., d (Y, C)_TP) Ratio d (Y, C)_FP) A large particular margin), the warning prioritizer 434 may assign a lower priority to Y. This may ensure that detected medical events that are more likely to be true arrhythmia episodes receive immediate review by the care provider than other detected medical events that are more likely to be FP detection.

The detected medical events, once reviewed and decided upon by the care provider, may be integrated into a database in the memory circuit 240 and become part of the historical medical alerts. Decisions, annotations, or other user-provided feedback may also be associated with the detected medical event and integrated into the database. In an example, using the decision, the detected medical event may be classified into one of the existing clusters, such as a TP or FP cluster, a particular medical event type cluster (e.g., a particular arrhythmia cluster), or a signal characteristic value range cluster. Alternatively, a new cluster may be formed if the detected medical event is not similar to any of the existing clusters, such as when a distance measure between the set of multi-dimensional features of the detected medical event and each cluster center of the existing clusters exceeds a threshold.

FIG. 5 generally illustrates an example of a method 500 for managing machine-generated medical alerts. The method 500 may be implemented and performed in an ambulatory medical device, such as an implantable or wearable medical device, or in a remote patient management system. In an example, the method 500 may be implemented in and performed by the AMDs 110, one or more devices in the external systems 125, or the alert management system 200 or 400.

The method 500 begins at 510, and at 510, physiological data associated with a medical event detected in a patient may be received. The physiological data may include one or more physiological signals, such as physiological signals sensed by the sensor circuit 210. Examples of physiological signals may include, among others, cardiac electrical signals (e.g., Electrocardiogram (ECG) or intracardiac Electrogram (EGM)), thoracic or cardiac impedance signals, arterial pressure signals, pulmonary artery pressure signals, left atrial pressure signals, RV pressure signals, LV coronary pressure signals, heart sounds or endocardial acceleration signals, physiological responses to activity, sleep apnea hypopnea index, one or more respiratory signals (such as a respiratory rate signal or a tidal volume signal). The sensed physiological signals may be pre-processed, including one or more of signal amplification, digitization, filtering, or other signal conditioning operations. In some examples, a signal metric, such as a timing parameter, or a statistical or morphological parameter, may be detected from the sensed physiological signal. The physiological data received at 510 may additionally include contextual data such as time of day, temperature, environmental parameters, or patient medical record information.

The physiological data received at 510 may be associated with a medical event such as an arrhythmic episode, a worsening of a chronic medical condition, such as Worsening Heart Failure (WHF). A medical event may be detected from one or more physiological signals, such as by using the detector circuit 220. The detected medical event may additionally or alternatively include a patient-triggered event, such as the patient experiencing a targeted medical event.

At 520, information regarding a patient's historical medical alert may be received. Such information may include a database of physiological data associated with medical alerts in a patient's medical history. The stored physiological data may be of the same type as the physiological data associated with the target medical event. For example, if the medical event is an arrhythmia episode detected from an electrocardiogram sensed from a particular sensing vector including an anode and a cathode, the physiological data associated with the historical medical alert may include an electrocardiogram sensed from the same sensing vector.

At 530, the detected medical event may be compared to the patient historical medical alerts. A similarity metric may be calculated between physiological data associated with the detected medical event and stored physiological data associated with the historical medical alert. The similarity measure may include a distance measure such as, among others, a Euclidean distance, a Mahalanobis distance, a correlation coefficient, or L1, L2, or an infinite norm.

In an example, signal characteristics may be extracted from physiological data associated with a detected medical event. A detected medical event may thus be represented by a multi-dimensional feature vector Y ═ { Y (1), Y (2),.., Y (m) }. Similarly, signal characteristics may be extracted from physiological data associated with historical medical alerts. For example, in { X₁,X₂,...,X_NN historical medical alerts (where X is_iRepresenting stored information corresponding to the ith historical alert), each historical medical alert may be represented by a corresponding multi-dimensional feature vector (such as X)_i＝[X_i(1),X_i(2),…,X_i(M)]) To indicate. A similarity measure may be calculated between the feature vector associated with the detected medical event and the feature vector of each of the historical medical alerts. In an example, the similarity measure may include a distance d (Y, X) in the multi-dimensional feature space_i). The resulting similarity measure may then be used to compute a composite similarity measure, such as N distance measures { d (Y, X)₁),d(Y,X₂)},…,d(Y,X_N). Can use the eventThe analyzer circuit 300A calculates a composite similarity measure. In an example, the synthetic similarity measure may be computed as a distance measure { d (Y, X)₁),d(Y,X₂)},…,d(Y,X_N) Weighted combination of (3). As discussed previously with reference to fig. 3A, the weighting factor may be determined based on a temporal proximity to the detected medical event.

At 540, an event priority indicator may be generated for the detected medical event. The similarity metric may be compared to one or more thresholds or value ranges, and the detected medical event may be classified as one of a plurality of predetermined degrees of priority, such as high, medium, or low priority. The degree of priority may be inversely related to the similarity metric such that a lower priority may be assigned to detected medical events that are similar to the historical alert and a higher priority may be assigned to detected medical times that are dissimilar to the historical alert. A detected medical event that is not similar to the historical alert may indicate a new medical condition that was not seen in the patient's medical history, or a change or progression of a historical medical event. Such medical events may require immediate attention by the care provider.

In some examples, the information received at 520 regarding the historical medical alert may include an indicator of the severity or clinical significance of the medical event associated with the historical medical alert. The severity indicator may be provided by a clinician. In an example, a historical medical event that results in a physician intervention or hospitalization may be designated as a serious medical alert. At 530, the detected medical event may be compared to the severe historical medical alert and other non-severe historical medical alerts to calculate a similarity measure between the detected medical event and the historical severe medical alert, and a similarity measure between the detected medical event and the historical non-severe medical alert. At 540, if the detected medical event is similar to a severe historical medical alert, or if it is not similar to a severe or non-severe historical alert, a higher priority may be assigned to it. If the detected medical event is similar to a less severe historical alert, a lower priority may be assigned. Medical events with characteristics similar to severe medical events in a patient's medical history are likely to be of clinical significance. The higher priority assigned to such events may ensure immediate medical attention and intervention when needed. In some examples, at 540, the highest priority may be assigned to medical events detected that are similar to a severe historical alert, followed by medical events detected that are not similar to a severe or non-severe historical alert, and the lowest priority may be assigned to medical events that are similar to a non-severe historical alert.

At 550, the detected medical event may be scheduled for presentation to a user or processing, such as via the output unit 254 of the alert management system 200. The event priority indicator may be used to adjust the priority of the detected medical event, such as for presentation to a user or treatment. In an example, a plurality of medical events detected from a patient may each have their respective priority indicators. The schedule of presentation may include a timing of presenting the medical events, or an order in which the plurality of medical events are presented using their respective event priorities. In an example, medical events detected from a particular patient may be sorted according to a descending order of event priority indicators.

The prioritized medical events may then be used in one or more of processes 552, 554, or 556. At 552, the detected medical event may be output to a user, such as via the output unit 254 as shown in fig. 2. Information may be displayed on the display including, among other things, patient physiological data associated with the detected medical event, intermediate measurements or calculations (such as signal characteristics, similarity metrics, alert priority indicators), or one or more historical medical alerts deemed similar to the detected medical event. Additionally or alternatively, a hard copy of the detected information may be generated. A system user (such as a care provider) may interactively annotate, mark, or comment on a detected medical event, such as via input unit 252. In an example, a system user may decide on detected arrhythmia episodes in an order according to their priority indicators. The detected medical event and associated physiological data, optionally along with annotations, decisions, and other user feedback, may be integrated into a database of historical medical alerts.

At 554, a recommendation can be generated and provided to the user. The recommendation may include one or more of further diagnostic tests to be performed or treatment for the administrator. The recommendations may also include system programming recommendations, such as adjustments of one or more parameters, such as detection parameters that may be used to improve the sensitivity or specificity of detecting the target medical event.

Method 500 may include an optional step 556, step 556 delivering therapy to the patient in response to detecting the medical event, such as via optional therapy circuitry 260 as shown in fig. 2. Examples of therapy may include electrical stimulation therapy delivered to the heart, neural tissue, other target tissue, cardioversion therapy, defibrillation therapy, or drug delivery including delivery of drugs to tissues or organs. In some examples, existing treatments may be modified, such as by adjusting stimulation parameters or drug dosage.

Fig. 6 generally illustrates an example of a method 600 for prioritizing medical events detected by a device for presentation to a user or processing. Method 600 may be an embodiment of at least a portion of method 500, including some or all of steps 520 through 540. In an example, method 600 may be implemented in and performed by alert management system 200 in FIG. 2 or alert management system 400 in FIG. 4.

Method 600 includes receiving information of a patient historical medical alert at 520. As discussed with reference to method 500, such information may include a database of physiological data associated with medical alerts in a patient's medical history. The patient historical medical alerts may be processed in one or more ways to generate statistics for prioritizing detected medical events. At 622, a plurality { X of historical signal characteristics corresponding to the N historical medical alerts may be determined from the plurality of historical signal characteristics₁,X₂,...,X_NGet a representative calendarThe history signal characteristic rX, such as through the use of the event analyzer circuit 300B. The representative historical signal characteristic rX may be calculated as stored physiological data { X₁,X₂,...,X_NCentral trend of signal characteristics of. rX may alternatively be calculated as { X }₁,X₂,...,X_NCentral trends in signal characteristics of selected portions of (such as those corresponding to warnings occurring during specified time periods). In an example, rX may be stored physiological data { X₁,X₂,...,X_NA centroid representing the signal characteristics of the most common historical medical alerts.

Information for the patient's historical medical alerts may additionally or alternatively be processed at 624, and one or more alert clusters may be formed at 624. An unsupervised learning algorithm that utilizes a distance measure between alerts may be used to group historical medical alerts or subsets of historical medical alerts into one or more alert clusters. Examples of unsupervised clustering algorithms may include K-means, fuzzy C-means, hierarchical clustering, or model-based clustering (such as high-minded hybrids), among others. Supervised learning algorithms may additionally or alternatively be used to aggregate historical medical alerts, or subsets thereof, such as according to user-specified criteria or clustering characteristics. In an example, clusters may be formed from signal characteristics (such as one or more ranges of values of a physiological parameter). In another example, a cluster may be defined as one or more user-specified event types, such as one or more specified arrhythmia types. In yet another example, at least some of the stored historical medical alerts may have been reviewed, rated, or annotated by a care professional. The stored historical medical alerts may be aggregated based on a decision, such as a True Positive (TP) cluster or a False Positive (FP) cluster, among others.

Each cluster may have a cluster center representative of historical signal characteristics. Each cluster center may be represented by a multi-dimensional feature vector. The cluster center may be iteratively updated and determined in the clustering process. The cluster center may represent the centroid of the member alerts within the cluster, or the mean feature vector of a gaussian or other statistical model of the cluster.

At 630, a similarity metric between the detected medical event and the patient's historical medical alert may be calculated. In an example, the similarity metric may be calculated as the distance in the multi-dimensional feature space between the signal characteristic Y associated with the detected medical event and the representative historical signal characteristic rX generated at 622, that is, D ═ D (rX, Y). Similarities between the detected medical event and one or more alert clusters may alternatively be calculated. In an example, signal characteristics Y and K cluster centers C associated with a detected medical event may be calculated_i＝[C_i(1),C_i(2),…,C_i(M)](for the distance between each of i ═ 1,2, …, K), K similarity measures { d (Y, C) corresponding to K clusters are derived₁),d(Y,C₂),…,d(Y,C_K)}. Distance d (Y, C)_i) Can be calculated as Euclidean distance, Mahalanobis distance, correlation coefficient, or L1, L2, or infinite norm in the multi-dimensional feature space.

At 640, an event priority indicator for the detected medical event may be generated. In an example, the composite similarity measure D may be compared to one or more thresholds or ranges of values and classified into a plurality of priority levels. In another example, K similarity measures { d (Y, C) are used₁),d(Y,C₂),…,d(Y,C_K) And cluster priority to prioritize detected medical events. The cluster priority may be a predetermined or user-specified amount indicating the relative significance of one cluster over another. For example, a higher priority may be assigned to a True Positive (TP) cluster that includes historical alerts of decisions that represent true event detections, and a lower priority may be assigned to a False Positive (FP) cluster that includes historical alerts of decisions that represent false event detections. If the detected medical event is similar to a TP cluster, a high priority may be assigned. Otherwise, if the detected medical event is more similar to the FP cluster, a low priority may be assigned. The prioritized medical events may then be scheduled for presentation to the user at 550Or processed.

The detected medical events, once reviewed and decided upon by the care provider, can be integrated into an alert database, such as stored in the memory circuit 240 and maintained, and become part of the historical medical alerts. The updated medical alerts in the database (including the detected medical events) may be re-aggregated to form a new set of alert clusters, each alert cluster including updated alert members. In examples where multiple alert clusters are maintained in the database, the detected medical event may be assigned to one of the existing alert clusters, such as a TP or FP cluster, a particular medical event type cluster (e.g., a particular arrhythmia cluster), or a signal characteristic value range cluster. Alternatively, if the detected medical event is not similar to any of the existing clusters, a new cluster may be formed.

The information of the patient historical medical alerts received at 520 may additionally be used to identify one or more multi-alert patients at 626, such as by using the patient identifier circuit 236. PAP is a patient who has a large number of medical warnings (e.g., warnings of the onset of atrial fibrillation) of the same type over a brief period of time. Most alert notifications may come from a small percentage of PAP. Frequent alerts from PAP may be repeated alerts, repeated false positive detections, or frequent patient-triggered events corresponding to medical events of substantially similar characteristics. As such, a large number of alerts from a PAP may not be as meaningful as alerts from a non-PAP when prioritizing alerts, such as for evaluation and decision by a care provider. If the total count of historical medical alerts associated with the patient exceeds a threshold, or if the frequency of historical medical alerts within a specified time period exceeds a threshold, a PAP may be identified at 626.

Identification of the PAP may be used to prioritize medical events at 640. In an example, medical events detected from multiple patients may be prioritized by a process that includes object prioritization and event prioritization. Subject prioritization may use identification of PAP that is designated as having a lower subject priority than non-PAP. Within each patient, event prioritization may use a similarity metric between a detected medical event and a historical medical alert for the same patient. A lower event priority is assigned to detected medical events that are more similar to the historical medical alerts and a higher event priority is assigned if the detected medical events are not similar to the historical medical alerts. The scheduling of presentation of the detected medical events at 550 may determine the timing or order of presentation of the detected medical events from the plurality of patients to a system user or process according to both the object prioritization and the event prioritization. In an example, PAP is presented after non-PAP, and within each patient, high priority events are presented before low priority events.

Fig. 7 generally illustrates a block diagram of an example machine 700 on which any one or more of the techniques (e.g., methods) discussed herein may execute. Portions of this description may be applicable to computing frameworks of various portions of LCP devices, AMDs, or external programmers.

In alternative embodiments, the machine 700 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 700 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 700 may operate as a peer machine in a peer-to-peer (P2P) (or other distributed) network environment. The machine 700 may be a Personal Computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.

Examples as described herein may include, or may operate with, logic or several components or mechanisms. A circuit group is a collection of circuits implemented in a tangible entity that includes hardware (e.g., simple circuits, gates, logic, etc.). Circuit group component qualification may be flexible over time and have underlying hardware variability. The circuit group includes members that can perform specified operations individually or in combination at the time of operation. In an example, the hardware of the circuit group may be designed to perform certain operations unchanged (e.g., hardwired). In an example, the hardware of the circuit set may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a computer-readable medium physically modified (e.g., magnetically, electrically, movably placement of a constant mass of particles, etc.) to encode instructions for a particular operation. When connecting physical components, the underlying electrical properties of the hardware components are changed, for example, from an insulator to a conductor, or vice versa. The instructions enable embedded hardware (e.g., an execution unit or loading mechanism) to create, via a variable connection, with the hardware, a means for performing a portion of a particular operation of a circuit group while in operation. Thus, when the apparatus is operating, the computer readable medium is communicatively coupled to other components of the circuit group means. In an example, any of the physical components may be used in more than one component of more than one circuit group. For example, in operation, an execution unit may be used in a first circuit of a first circuit group at one point in time and reused by a second circuit in the first circuit group or a third circuit in the second circuit group at a different time.

The machine (e.g., computer system) 700 may include a hardware processor 702 (e.g., a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), a hardware processor core, or any combination thereof), a main memory 704 and a static memory 706, some or all of which may communicate with each other via an intermediate link (e.g., bus) 708. The machine 700 may further include a display unit 710 (e.g., a raster display, a vector display, a holographic display, etc.), an alphanumeric input device 712 (e.g., a keyboard), and a User Interface (UI) navigation device 714 (e.g., a mouse). In an example, the display unit 710, the input device 712, and the UI navigation device 714 may be a touch screen display. The machine 700 may additionally include a storage device (e.g., drive unit) 716, a signal generation device 718 (e.g., a speaker), a network interface device 720, and one or more sensors 721, such as a Global Positioning System (GPS) sensor, compass, accelerometer, or other sensor. The machine 700 may include an output controller 728 such as a serial connection (e.g., Universal Serial Bus (USB)), a parallel connection, or other wired or wireless (e.g., Infrared (IR), Near Field Communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).

The storage 716 may include a machine-readable medium 722 on which is stored one or more sets of data structures or instructions 724 embodying or utilized by any one or more of the techniques or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, within the static memory 706, or within the hardware processor 702 during execution of the instructions 724 by the machine 700. In an example, one or any combination of hardware processor 702, main memory 704, static memory 706, or storage 716 may constitute a machine-readable medium.

While the machine-readable medium 722 is illustrated as a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 724.

The term "machine-readable medium" may include any medium that is capable of storing, encoding or carrying instructions for execution by the machine 700 and that cause the machine 700 to perform any one or more of the techniques of this disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting examples of machine-readable media may include solid-state memory, optical media, and magnetic media. In an example, the high capacity machine readable medium includes a machine readable medium having a plurality of particles that are constant in mass (e.g., stationary). Thus, a mass machine-readable medium is not a transitory propagating signal. Specific examples of a mass machine-readable medium may include: non-volatile memories, such as semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices); magnetic disks such as internal hard disks and removable disks; magneto-optical disks; as well as CD-ROM discs and DVD-ROM discs.

The instructions 724 may further be transmitted or received over a communication network 726 using a transmission medium via the network interface device 720, the network interface device 720 utilizing any one or more of a number of transfer protocols (e.g., frame relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a Local Area Network (LAN), a Wide Area Network (WAN), a packet data network (e.g., the internet), a mobile telephone network (e.g., a cellular network), a Plain Old Telephone (POTS) network, and a wireless data network (e.g., referred to as a "cellular network"), among others

Is known as the Institute of Electrical and Electronics Engineers (IEEE)802.11 family of standards

IEEE 802.16 family of standards), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks. In an example, the network interface device 720 may include one or more physical jacks (e.g., ethernet jacks, coaxial jacks, or telephone jacks) or one or more antennas connected to the communication network 726. In an example, network interface device 720 may include multiple antennas for wireless communication using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term "transmission medium" shall be taken to include any medium that is capable of storing, encoding or carrying information for use in connection withAny tangible medium of instructions that the machine 700 executes, and includes digital or analog communications signals or other tangible media that facilitate communication of such software.

Various embodiments are illustrated in the above-identified figures. One or more features from one or more of these embodiments may be combined to form further embodiments.

The method examples described herein may be machine or computer implemented at least in part. Some examples may include a computer-readable medium or machine-readable medium encoded with instructions operable to configure an electronic device or system to perform a method as described in the above examples. Implementations of such methods may include code, such as microcode, assembly language code, higher level language code, and the like. Such code may include computer readable instructions for performing various methods. The code may form part of a computer program product. Further, the code may be tangibly stored on one or more volatile or non-volatile computer-readable media during execution or at other times.

The above detailed description is intended to be illustrative, and not restrictive. The scope of the disclosure should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.