Health Event Prediction and Patient Feedback System

Abstract

The medical device system includes a memory and a processing circuit in communication with the memory, the processing circuit being configured to: receive parameter data related to a plurality of parameters of the patient; determine, based on the parameter data, an atrial fibrillation (AF) burden of the patient over a period of time, the patient's AF burden over the period of time including a pattern of increased AF burden; output, for display by the user device, a request to identify whether the patient engaged in each patient behavior of a set of patient behaviors during the period of time; and determine, based on receiving a response indicating that the patient engaged in one or more patient behaviors of the set of patient behaviors, a suggestion for modifying at least a subset of the one or more patient behaviors to attenuate the pattern of increased AF burden.

Description

[Technical Field]

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 370,738, filed August 8, 2022, the entire contents of which are incorporated herein by reference.

[0002] FIELD OF THE INVENTION FIELD OF THE DISCLOSURE The present disclosure relates generally to systems including medical devices, and more particularly to monitoring patient health using such systems. [Background technology]

[0003] Various devices are configured to monitor a patient's physiological signals. Such devices include implantable or wearable medical devices, as well as various wearable health or fitness tracking devices. Physiological signals sensed by such devices include, by way of example, electrocardiogram (ECG) signals, respiration signals, perfusion signals, activity and / or posture signals, compression signals, blood oxygen saturation signals, body composition, and blood glucose or other blood constituent signals. Generally, using these signals, such devices facilitate monitoring and assessment of a patient's health over months or years outside of a clinic environment.

[0004] In some cases, such devices are configured to detect health events, such as episodes of cardiac arrhythmia or worsening heart failure, based on physiological signals. Examples of arrhythmia types include asystole, bradycardia, ventricular tachycardia, supraventricular tachycardia, wide complex tachycardia, atrial fibrillation, atrial flutter, ventricular fibrillation, atrioventricular block, premature ventricular contractions, and premature atrial contractions. The device may store ECG and other physiological signal data collected during a period of time that includes an episode as episode data. The device may further store episode data quantifying the episode, such as the number and / or duration of episodes. The medical device may store ECG and other physiological data for a period of time as episode data in response to user input, such as from a patient or caregiver. Summary of the Invention

[0005] Generally, the present disclosure describes techniques for determining a risk level of a health event based on parameter data of a plurality of parameters of a patient. The plurality of parameters may include atrial fibrillation (AF) burden. In some examples, the techniques include applying AF burden pattern features to a model to determine the risk level. In some examples, the model is trained using a training set of parameter data that is classified based on classification data automatically collected in response to detection of a trigger. The techniques further include a patient interface system for presenting one or more queries to the patient. The patient interface system may further provide one or more suggestions for the patient to modify their behavior.

[0006] The techniques of the present disclosure may provide one or more advantages. For example, by using a patient interface system to ask a patient to identify one or more patient behaviors, the system may more effectively identify behaviors that may contribute to increased AF burden compared to a system that does not ask the patient to identify a behavior. Outputting suggestions for changing patient behaviors that are likely to contribute to increased AF burden may more effectively attenuate or eliminate patterns of increased AF burden compared to a system that does not output suggestions to the patient.

[0007] In one example, a medical device system includes a memory and a processing circuit in communication with the memory, the processing circuit being configured to: receive parameter data for a plurality of parameters of the patient, the parameter data generated by one or more sensing devices based on the patient's physiological signals sensed by the one or more sensing devices; determine, based on the parameter data, an atrial fibrillation (AF) burden of the patient over a period of time, the patient's AF burden over the period of time including a pattern of increased AF burden; output, for display by a user device operated by the patient, a request identifying whether the patient engaged in each patient behavior of a set of patient behaviors during the period of time; and, based on receiving a response indicating that the patient engaged in one or more patient behaviors of the set of patient behaviors, determine suggestions for modifying at least a subset of the one or more patient behaviors to attenuate the pattern of increased AF burden, and output the suggestions for display by the user device operated by the patient.

[0008] In another example, a medical device system includes a memory and a processing circuit in communication with the memory, the processing circuit configured to: receive parameter data for a plurality of parameters of a patient, the parameter data being generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine an atrial fibrillation (AF) burden of the patient over a period of time based on the parameter data; apply the AF burden of the patient over the period of time to a model; and determine a risk level of a health event for the patient based on the application of the AF burden of the patient over the period of time to the model.

[0009] In another example, a medical device system includes a memory and a processing circuit in communication with the memory, the processing circuit being configured to: receive parameter data for a plurality of parameters of a patient, the parameter data being generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine a set of parameters for the patient over a period of time based on the parameter data; receive information indicative of one or more conditions specific to the patient; set a weight corresponding to each parameter of the set of parameters based on the one or more conditions specific to the patient; apply the set of parameters of the patient over the period of time to a model; and determine a risk level of a health event for the patient based on application of the set of parameters over the period of time to the model.

[0010] This summary is intended to provide an overview of the subject matter described in this disclosure. It is not intended to provide an exclusive or comprehensive description of the devices and methods described in detail in the accompanying drawings and the following description. Further details of one or more embodiments are set forth in the accompanying drawings and the following description. [Brief explanation of the drawings]

[0011] [Figure 1]FIG. 1 is a block diagram illustrating an example medical device system configured to predict health events and respond to such predictions, in accordance with one or more techniques of the present disclosure.

[0012] [Figure 2] 2 is a block diagram illustrating an example configuration of the IMD of FIG. 1 in accordance with one or more techniques of the present disclosure.

[0013] [Figure 3] FIG. 3 is a conceptual side view illustrating an example configuration of the IMD of FIGS. 1 and 2 in accordance with one or more techniques of the present disclosure.

[0014] [Figure 4] 1 is a block diagram illustrating an example configuration of an external device that operates in accordance with one or more techniques of the present disclosure.

[0015] [Figure 5] FIG. 1 is a block diagram illustrating an example of a computing system that operates in accordance with one or more techniques of the present disclosure.

[0016] [Figure 6] 1 is a flow diagram illustrating an example technique for training a machine learning model using a training set of parameter data classified based on automatically collected classification data, in accordance with one or more techniques of this disclosure.

[0017] [Figure 7] 1 is a flow diagram illustrating an example technique for automatically collecting classification data, in accordance with one or more techniques of this disclosure.

[0018] [Figure 8] 1 is a flow diagram illustrating an example technique for predicting a health event and responding to a prediction of a health event, according to one or more techniques of this disclosure.

[0019] [Figure 9]1 is a flow diagram illustrating an example technique for outputting suggestions for modifying patient behavior, according to one or more techniques of the present disclosure.

[0020] [Figure 10] 1 is a flow chart illustrating an example technique for monitoring AF burden following suggestions to modify patient behavior, in accordance with one or more techniques of the present disclosure.

[0021] [Figure 11] 1 is a flow chart illustrating an exemplary technique for identifying patterns of increased AF burden, in accordance with one or more techniques of the present disclosure.

[0022] [Figure 12] 1 is a flow chart illustrating an example technique for determining a risk level of a health event based on a patient's AF burden over a period of time, according to one or more techniques of the present disclosure.

[0023] [Figure 13] 1 is a flow chart illustrating an example technique for determining a risk level of a health event based on AF load variation, according to one or more techniques of the present disclosure.

[0024] [Figure 14] 1 is a flow diagram illustrating an example technique for determining a risk level of a health event based on one or more conditions specific to a patient, according to one or more techniques of the present disclosure.

[0025] [Figure 15] FIG. 10 is a conceptual diagram illustrating a patient behavior query screen for display on a user interface of a device, in accordance with one or more techniques of the present disclosure.

[0026] [Figure 16] FIG. 10 is a conceptual diagram illustrating a first suggestions screen for display on a user interface of a device in accordance with one or more techniques of this disclosure.

[0027] [Figure 17]FIG. 10 is a conceptual diagram illustrating a second suggestions screen for display on a user interface of a device in accordance with one or more techniques of this disclosure.

[0028] [Figure 18] 1 is a graph showing parameter data for multiple patient parameters over a period before and after a stroke event, in accordance with one or more techniques of the present disclosure.

[0029] [Figure 19] 10 is a graph illustrating a time series of moving average parameter data for a patient parameter in accordance with one or more techniques of the present disclosure.

[0030] [Figure 20] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke, according to one or more techniques of the present disclosure.

[0031] [Figure 21] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke, according to one or more techniques of the present disclosure.

[0032] [Figure 22A] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke for different patient populations, according to one or more techniques of the present disclosure. [Figure 22B] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke for different patient populations, according to one or more techniques of the present disclosure. [Figure 22C] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke for different patient populations, according to one or more techniques of the present disclosure. [Figure 22D] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke for different patient populations, according to one or more techniques of the present disclosure.

[0033] [Figure 23A] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization for different patient populations, according to one or more techniques of the present disclosure. [Figure 23B] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization for different patient populations, according to one or more techniques of the present disclosure. [Figure 23C] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization for different patient populations, according to one or more techniques of the present disclosure. [Figure 23D] 1 is a chart showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization for different patient populations, according to one or more techniques of the present disclosure.

[0034] [Figure 24] 1 is a chart illustrating AF burden pattern characteristics for predicting stroke and medical utilization, according to one or more techniques of the present disclosure.

[0035] [Figure 25A] 1A-1C are schematic diagrams illustrating AF burden patterns in patients experiencing a stroke or medical utilization event, respectively, for various patient populations, according to one or more techniques of the present disclosure. [Figure 25B] 1A-1C are schematic diagrams illustrating AF burden patterns in patients experiencing a stroke or medical utilization event, respectively, for various patient populations, according to one or more techniques of the present disclosure.

[0036] [Figure 26] 10 is a graph illustrating detected AT / AF time (load) over the course of a monitoring period, in accordance with one or more techniques of the present disclosure.

[0037] [Figure 27]10 presents a scatter plot of terminal nodes by labeled HCU rate and percent of patients for balanced training data, according to one or more techniques of this disclosure.

[0038] [Figure 28] 1 presents an exemplary graphical illustration of patterns in AF burden data mapped for a single HCU patient, according to one or more techniques of the present disclosure.

[0039] [Figure 29] 10 presents a scatter plot of terminal nodes scored by labeled HCU rate and patient percentage for an unbalanced validation set according to one or more techniques of the present disclosure.

[0040] [Figure 30] 1 presents a Venn diagram of AF load threshold counts for a validation set according to one or more techniques of this disclosure.

[0041] Like reference characters refer to like elements throughout the figures and description. DETAILED DESCRIPTION OF THE INVENTION

[0042] Various types of implantable and medical devices detect arrhythmia episodes and other health events based on sensed ECGs, and possibly other physiological signals. External devices that can be used to noninvasively sense and monitor ECGs and other physiological signals include wearable devices, such as patches, watches, or necklaces, with electrodes configured to contact a patient's skin. Such external devices can facilitate relatively long-term monitoring of a patient's health during normal daily activities.

[0043] Implantable medical devices (IMDs) also sense and monitor ECGs and other physiological signals to detect health problems, such as arrhythmia episodes and worsening heart failure. Examples of IMDs include pacemakers and implantable cardioverter-defibrillators, which may be coupled to intravascular or extravascular leads, as well as pacemakers with a housing configured for implantation within the heart, which may be leadless. Some IMDs, such as implantable patient monitors, do not provide therapy. One example of such an IMD is the Reveal LINQ™ Insertable Cardiac Monitor (ICM), available from Medtronic plc, which may be inserted subcutaneously. Such IMDs facilitate relatively long-term monitoring of patients during normal daily activities and may periodically transmit collected data, e.g., episode data of detected arrhythmia episodes, to a remote patient monitoring system, such as the Medtronic Carelink™ network.

[0044] FIG. 1 is a block diagram illustrating an example medical device system 2 configured to predict health status events in a patient 4 and respond to such predictions according to one or more techniques of the present disclosure. The example techniques can be used with an IMD 10 capable of wirelessly communicating with an external device 12. In some examples, the IMD 10 is implanted outside the patient 4's chest cavity (e.g., subcutaneously in the chest location shown in FIG. 1). The IMD 10 can be positioned near the patient 4's sternum near or just below the level of the patient's 4 heart, e.g., at least partially within the contours of the heart. The IMD 10 includes multiple electrodes (not shown in FIG. 1) and is configured to sense an ECG via the multiple electrodes. In some examples, the IMD 10 takes the form of a LINQ™ ICM. While primarily described in the context of an example in which the IMD takes the form of an ICM, the techniques of the present disclosure can be implemented in a system including any one or more implantable or external medical devices, including a monitor, pacemaker, or defibrillator.

[0045] The external device 12 is a computing device configured for wireless communication with the IMD 10. The external device 12 obtains episode and other physiological data from the IMD 10 that is collected and stored by the IMD 10. In some examples, the external device takes the form of a patient's or caregiver's personal computing device, such as a smartphone.

[0046] 1 , system 2 further includes a sensor device 14 that wirelessly communicates with external device 12. Sensor device 14 may include electrodes and other sensors for sensing physiological signals of patient 4, collect and store physiological data, and detect episodes based on such signals. In some examples, sensor device 14 is an external device wearable by patient 4. Sensor device 14 can be incorporated into clothing of patient 4, such as clothing, shoes, glasses, a watch or wristband, a hat, etc. In some examples, sensor device 14 is a smartwatch or other accessory or peripheral of smartphone-external device 12.

[0047] The external device 12 obtains episodes and other physiological data collected and stored by the sensor device 14 from the sensor device 14. The external device 12 may include a display and other user interface elements. In some examples, the external device 12 presents the physiological data obtained from the IMD 10 and / or the sensor device 14, and / or statistical representations thereof, to the patient 4 or another user. The external device 12 may communicate with the IMD 10 and / or the sensor device 14 according to, for example, Bluetooth® or Bluetooth® Low Energy (BLE) protocols.

[0048] The external device 12 may be configured to communicate with the computing system 20 via a network 15. The external device 12 may be used to acquire data from the IMD 10 and the sensor device 14 and transmit the data to the computing system 20 via the network 15. The acquired data may include values of physiological parameters measured by the IMD 10 and the sensor device 14, data related to arrhythmia episodes or other health events detected by the IMD 10 and the sensor device 14, and other physiological signals or data recorded by the IMD 10 and the sensor device 14. The data acquired from the IMD 10 and the sensor device 14 may include values of various patient parameters and / or may be used by the computing system 20 to determine values of the patient parameters. The values of the patient parameters may be referred to as patient parameter data. The patient parameter data may be acquired and / or determined periodically to generate periodic values, e.g., daily to generate daily values.

[0049] Computing system 20 may include a computing device configured to allow users, such as clinicians treating patient 4 and other patients, to interact with data collected from their patients' IMDs 10 and sensor devices 14. In some examples, computing system 20 includes one or more handheld computing devices, computer workstations, servers, or other networked computing devices. In some examples, computing system 20 may include one or more devices, including processing circuitry and storage devices, that implement a monitoring system. The monitoring system may present patient parameter data to clinicians, allowing them to remotely track and evaluate patients. In some examples, the monitoring system may analyze the data and prioritize the presentation of data or alerts for certain patients based on the analysis. Computing system 20, network 15, and monitoring system may, in some examples, be implemented by the Medtronic CareLink™ network.

[0050] The network 15 may include one or more computing devices (not shown), such as one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection and / or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cell phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices. The network 15 may include one or more networks managed by a service provider and thus form part of a larger public network infrastructure, such as the Internet. The network 15 may provide computing devices, such as the computing system 20 and medical device 12, with access to the Internet and may provide a communications framework that allows the computing devices to communicate with each other. In some examples, the network 15 may be a private network that provides a communications framework that allows the computing system 20 and the external device 12 to communicate with each other, but for security purposes, isolates one or more of these devices, or the data flow between these devices, from devices outside the network 15. In some examples, communications between the computing system 20 and the external device 12 are encrypted.

[0051] Computing system 20 may also retrieve patient 4's data from an electronic medical record (EMR) database 22. EMR database 22 may store patient 4's electronic medical record (also referred to as an electronic health record). This electronic medical record may be generated by various healthcare providers, laboratories, clinicians, insurance companies, etc. Although shown as a single database in FIG. 1, EMR database 22 may include various databases managed by various entities.

[0052] By way of example, EMR database 22 may store a patient's medication history, a patient's surgical procedure history, a patient's hospitalization history, a patient's emergency or urgent care visit history, a patient's scheduled medical appointments, one or more test results or other lab test results for patient 4, a cardiovascular history for patient 4, or a co-morbid condition for patient 4, such as atrial fibrillation, heart failure, or diabetes. As a further example, EMR database 22 may store medical images of patient 4, such as x-rays, ultrasound images, echocardiograms, anatomical images, medical photographs, radiology images, etc. The data stored in EMR database 22 may include patient-specific records for patient 4 and numerous other patients. In some examples, the data stored by EMR database 22 may include broader demographic or population-type information about multiple patients.

[0053] For example, a monitoring system implemented by the processing circuitry of computing system 20 can implement the techniques of the present disclosure, including developing an algorithm based on a training set of parameter data for a population of patients or subjects obtained from the IMD 10 and the population's external devices, and applying the algorithm to the parameter data for individual patients 4 to predict the occurrence of a clinically significant health event. In some examples, the monitoring system trains one or more machine learning (ML) models for predicting health events. The output of the ML model for a particular patient can be a level of risk of the health event, a probability of the health event occurring within a particular time, and / or whether the risk or probability meets a threshold. Computing system 20 is not limited to using ML models. Computing system 20 can use any type of model to analyze the parameter data.

[0054] Exemplary health events that may be predicted using the techniques of the present disclosure include stroke, clinically significant AF requiring hospitalization or emergency care, and clinically significant episodes of symptomatic events such as syncope or dizziness. Parameter data that may be useful for predicting such health events may include heart rate data and cardiac rhythm data, such as data related to atrial fibrillation (AF) or other arrhythmia episodes. AF data may include a quantification of AF, referred to as AF burden, as well as patterns of AF burden over multiple time periods. Parameter data that may be useful for predicting such clinically significant health events may additionally or alternatively include patient activity data or any other patient data or signals described herein.

[0055] The computing system 20 may, in some cases, identify a pattern of increased AF burden and provide one or more suggestions for the patient 4 to modify their behavior to eliminate or attenuate the pattern of increased AF burden. For example, the computing system 20 may receive parameter data regarding multiple parameters of the patient 4. The parameter data may be generated by one or more sensing devices (e.g., the IMD 10 and / or the sensor device 14) based on physiological signals of the patient 4 sensed by the one or more sensing devices. In some examples, the computing system 20 may receive the parameter data in real time from the IMD 10 and / or the sensors and / or sensor device 14. In some examples, the computing system 20 may receive a set of parameter data when the external device 12 acquires the parameter data from the IMD 10 and / or the sensor device 14.

[0056] The computing system 20 can determine the patient's atrial fibrillation (AF) burden over a period of time based on the parameter data. The period of time may, in some cases, extend beyond one day (e.g., 7 days, 30 days, or any other duration). For example, the computing system 20 can determine the AF burden as a function of time based on the parameter data. In some examples, the patient's AF burden over a period of time may exhibit one or more patterns. For example, the patient's AF burden over a period of time may exhibit a pattern of increased AF burden. A pattern of increased AF burden may, in some examples, include one or more occurrences of increased AF burden over a period of time. In some cases, the one or more occurrences of increased AF burden occur more frequently during a particular time of day, although this is not required. A pattern of increased AF burden may represent any pattern including one or more occurrences of increased AF burden.

[0057] Based on determining the pattern of increased AF burden, the computing system 20 can output a request identifying whether the patient 4 engaged in one or more behaviors during the period for display by the external device 12. In some examples, the computing system 20 can select one or more behaviors based on the pattern of increased AF burden. For example, if the pattern of increased AF burden includes occurrence of increased AF burden in the morning, the computing system 20 can output a request for the patient 4 to indicate whether the patient 4 consumes caffeine in the morning. In either case, the computing system 20 can output a list of patient behaviors for display by the external device 12. Each patient behavior in the list of patient behaviors may be selected or deselected such that the patient can select none of the behaviors, one of the behaviors, or a combination of one or more of the behaviors for display by the external device 12.

[0058] The computing system 20 may determine a suggestion for the patient 4 to change their behavior based on receiving a response indicating that the patient engaged in one or more patient behaviors of the set of patient behaviors. In some examples, the computing system 20 may identify a possible cause of a pattern of increased AF burden based on the response. For example, if the response indicates that the patient 4 consumes caffeine in the morning, the computing system 20 may determine that caffeine consumption likely contributes to a pattern of increased AF burden. The computing system 20 may output a suggestion to reduce or eliminate caffeine consumption to eliminate or attenuate a future pattern of increased AF burden. Consumption of one or more chemicals or minerals (e.g., caffeine, sodium, potassium) may contribute to an increased AF burden. Additionally or alternatively, exercise or other increased activity may contribute to an increased AF burden. When the computing system 20 outputs the list of behaviors to the external device 12, the computing system 20 may select the list of behaviors to include behaviors likely to contribute to an increased AF burden, such as activity and consumption of specific chemicals and minerals. This may improve the ability of computing system 20 to identify causes of increased AF burden compared to systems that do not require the patient to select from a list of behaviors likely to cause increased AF burden.

[0059] The computing system 20 may output a behavior change suggestion for display by the external device 12. In some examples, the computing system 20 may receive a response indicating acceptance of the suggestion. The computing system 20 may determine the AF burden of the patient 4 over a period of time following acceptance of the behavior change suggestion to determine whether the behavior change eliminated or attenuated the pattern of increased AF burden. If the behavior change did not eliminate or attenuate the pattern of increased AF burden, the computing system 20 may output another behavior change suggestion.

[0060] The AF burden data may indicate a level of risk for patient 4 of experiencing a health event (e.g., heart failure). In some examples, computing system 20 may apply a model to patient 4's AF burden over time to determine patient 4's risk level of the health event. One or more aspects of the AF burden signal may indicate an increased risk of a health event. These risks may include longer episodes of increased AF burden, higher mean or median levels of increased AF burden, variability in AF burden over time, or any combination thereof.

[0061] In some examples, variability in AF burden over time is a strong indicator of an increased risk of a health event. The computing system 20 can determine the AF burden of the patient 4 over a period of time based on the parameter data. The computing system 20 can calculate an AF burden score corresponding to the period of time. In some examples, the AF burden score may represent the average AF burden over the period of time, the median AF burden over the period of time, or another score quantifying the AF burden. For example, the AF burden score may represent the sum of the AF burden data points over the period of time. The computing system 20 can, in some cases, divide the period of time into a set of time intervals. For example, if the period of time is two weeks, the computing system 20 can divide the two weeks into fourteen one-day time intervals. This allows the computing system 20 to analyze the AF burden within each individual time interval relative to the AF burden over the entire period of time. The computing system 20 can calculate an AF burden score corresponding to each time interval of the set of time intervals within the period of time. The AF burden score corresponding to each time interval may indicate the distribution of the AF burden. That is, when the AF burden varies by a large margin across a set of time intervals, this may indicate a higher risk of a health event.

[0062] One or more occurrences of increased AF burden may further indicate a risk level of a health event. Computing system 20 may identify one or more occurrences over a period of time in which patient 4's AF burden increases above a threshold AF burden and determine the duration of each occurrence in which the AF burden remains above the threshold AF burden. Multiple occurrences of increased AF burden and / or longer occurrences of increased AF burden may indicate an increased risk of a health event.

[0063] The computing system 20 may identify one or more parameters based on the parameter data. For example, the computing system 20 may determine AF burden (AFB), diurnal heart rate (DHR), activities of daily living (ADL), nocturnal heart rate (NHR), heart rate variability (HRV), or any combination thereof, based on the parameter data collected by the IMD 10 and / or the sensor device 14. The computing system 20 may additionally or alternatively receive patient data corresponding to the patient 4. For example, the computing system 20 may receive a history of AF, a history of COPD, a CHADS-VASc score, a previous oral anticoagulant (prior_oac), a history of chronic kidney disease, a history of ablation, a history of sleep apnea, a history of coronary artery disease, a history of valvular disease, or any combination thereof, corresponding to the patient 4. The computing system 20 assigns a weight value to each parameter and / or patient data to determine a risk level of a health event.

[0064] The monitoring system may further utilize data from the EMR database 22 and / or data entered by the patient or caregiver via the external device 12 in conjunction with the parameter data from the IMD 10 or the sensor device 14. In some examples, the data from the EMR database 22 and / or data entered by the patient or caregiver via the external device 12 can be used as input to an ML model or other health event prediction algorithm implemented by the monitoring system. In some examples, the data from the EMR database 22 and / or data entered by the patient or caregiver via the external device 12 can provide a classification of a training set of parameter data from the IMD 10 and the sensor device 14 used to train one or more models (e.g., ML models) to predict health events. For example, the data from the EMR database 22 and / or data entered by the patient or caregiver via the external device 12 can indicate whether, when, and to what severity the patient 4 experienced a clinically significant health event. Such data can be correlated with the parameter data to create a training set of parameter data. After the initial training phase, such training set can be used for reinforcement learning and, in some cases, personalization of one or more ML models.

[0065] Although the techniques are described herein as being performed by the monitoring system, and thus by processing circuitry of computing system 20, the techniques may be performed by processing circuitry of any one or more devices or systems of the medical device system, such as computing system 20, external device 12, or IMD 10. The ML model may include, by way of example, a neural network, a deep learning model, a convolutional neural network, or other type of predictive analytics system.

[0066] 2 is a block diagram illustrating an example configuration of the IMD 10 of FIG. 1 in accordance with one or more techniques of the present disclosure. As shown in FIG. 2, the IMD 10 includes a processing circuit 50, a sensing circuit 52, a communication circuit 54, a storage device 56, a sensor 58, a switching circuit 60, and electrodes 16A, 16B (hereinafter, “electrodes 16”), one or more of which may be disposed on a housing of the IMD 10. In some examples, the storage device 56 includes computer-readable instructions that, when executed by the processing circuit 50, cause the IMD 10 and the processing circuit 50 to perform various functions attributed to the IMD 10 and the processing circuit 50 herein. The storage device 56 may include any volatile, non-volatile, magnetic, optical, or electrical medium, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), electrically erasable programmable ROM (EEPROM), flash memory, or any other digital medium.

[0067] Processing circuitry 50 may include fixed-function circuitry and / or programmable processing circuitry. Processing circuitry 50 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or analog logic circuitry. In some examples, processing circuitry 50 may include multiple components, such as any combination of one or more microprocessors, one or more controllers, one or more DSPs, one or more ASICs, or one or more FPGAs, and other discrete or integrated logic circuitry. The functionality attributed to processing circuitry 50 herein may be embodied as software, firmware, hardware, or any combination thereof.

[0068] Sensing circuit 52 may be selectively coupled to electrodes 16A, 16B via switching circuit 60 as controlled by processing circuit 50. Sensing circuit 52 may monitor signals from electrodes 16A, 16B to monitor cardiac electrical activity of patient 4 of FIG. 1 and generate ECG data for patient 4. In some examples, processing circuit 50 may identify sensed ECG features, such as heart rate, heart rate variability, beat intervals, and / or ECG morphological features, to detect cardiac arrhythmia episodes in patient 4. Processing circuit 50 may store the digitized ECG and the ECG features used to detect arrhythmia episodes in storage device 56 as episode data for the detected arrhythmia episodes. Processing circuit 50 may also store parameter data in storage device 56, including ECG features and data quantifying arrhythmia episodes, such as AF stress data.

[0069] Sensing circuit 52 and / or processing circuit 50 may be configured to detect cardiac depolarizations (e.g., P waves of atrial depolarizations or R waves of ventricular depolarizations) when the ECG amplitude exceeds a sensing threshold. For cardiac depolarization detection, sensing circuit 52 may, in some examples, include a rectifier, a filter, an amplifier, a comparator, and / or an analog-to-digital converter. In some examples, sensing circuit 52 may output an indication to processing circuit 50 in response to sensing a cardiac depolarization. In this manner, processing circuit 50 may receive detected cardiac depolarization indicators corresponding to the occurrence of detected R waves and P waves. Processing circuit 50 can use the indicators to determine ECG characteristics, including inter-depolarization intervals, heart rate, and heart rate variability. Sensing circuit 52 may further provide one or more digitized ECG signals to processing circuit 50 for analysis, e.g., for use in cardiac rhythm discrimination and / or to identify and delineate ECG features, such as QRS amplitude and / or width, or other morphological features.

[0070] In some embodiments, sensing circuitry 52 measures the impedance of tissue, for example, proximate IMD 10, via electrodes 16. The measured impedance may vary based on respiration and the degree of perfusion or edema. Processing circuitry 50 may determine parameter data related to respiration, perfusion, and / or edema based on the measured impedance.

[0071] In some examples, IMD 10 includes one or more sensors 58, such as one or more accelerometers, microphones, optical sensors, temperature sensors, and / or pressure sensors. In some examples, sensing circuitry 52 may include one or more filters and amplifiers for filtering and amplifying signals received from one or more of electrodes 16A, 16B and / or other sensors 58. In some examples, sensing circuitry 52 and / or processing circuitry 50 may include a rectifier, filters and / or amplifiers, sense amplifiers, comparators, and / or analog-to-digital converters. Processing circuitry 50 may determine parameter data, e.g., values of physiological parameters of patient 4, based on signals from sensors 58, which may be stored in storage device 56.

[0072] 1 to the external device 12, which in turn may transmit the data to the network 15 for processing by the monitoring system of the computing system 20. The computing system 20 may analyze the parameter data and / or episode data to perform one or more actions, such as determining a risk of a health event or determining one or more suggestions to output for display by the external device 12. The communications circuitry 54 may include any suitable hardware, firmware, software, or any combination thereof, for communicating with another device, such as the external device 12. Under the control of the processing circuitry 50, the communications circuitry 54 may receive downlink telemetry and transmit uplink telemetry from the external device 12 or another device with the aid of an internal or external antenna, such as the antenna 26.

[0073] Although described herein in the context of an exemplary IMD 10, the techniques for detecting cardiac arrhythmias disclosed herein may be used with other types of devices. For example, these techniques may be implemented using an extracardiac defibrillator coupled to electrodes outside the cardiovascular system, a transcatheter pacemaker configured for implantation within the heart (such as the Micra™ transcatheter pacing system commercially available from Medtronic, Dublin, Ireland), an insertable cardiac monitor (such as the Reveal LINQ™ ICM, also commercially available from Medtronic), a neurostimulator, or a drug delivery device.

[0074] 1 , the sensor device 14 may be an external device such as a smart watch, fitness tracker, patch, or other wearable device. The sensor device 14 may be configured similarly to the IMD 10 in that it may include electrodes, sensors, sensing circuitry, processing circuitry, memory, and communication circuitry and may similarly function to collect parameter data and communicate with the external device 12. The sensor and parameter data collected by the IMD 10 and the sensor device 14 may differ as described herein. The sensor device 14 may transmit the parameter data for analysis by the computing system 20. The computing system 20 may analyze the parameter data from the sensor device 14 and / or analyze the parameter data from the IMD 10.

[0075] FIG. 3 is a conceptual side view illustrating an example configuration of an IMD 10 in accordance with one or more techniques of the present disclosure. In the example shown in FIG. 3, the IMD 10 may comprise a leadless, subcutaneously implantable monitoring device having a housing 18 and an insulating cover 74. Electrodes 16A and 16B may be formed or disposed on an outer surface of the cover 74. The circuits 50-56 and 60 described above with respect to FIG. 2 may be formed or disposed on an inner surface of the cover 74 or within the housing 18. In the illustrated example, the antenna 26 is formed or disposed on the inner surface of the cover 74, but in some examples, it may be formed or disposed on the outer surface. The sensor 58 may also be formed or disposed on the inner or outer surface of the cover 74 in some examples. In some examples, the insulating cover 74 may be disposed over the open housing 18 such that the housing 18 and cover 74 enclose the antenna 26, the sensor 58, and the circuits 50-56 and 60 and protect the antenna and circuits from fluids, such as bodily fluids.

[0076] One or more of the antenna 26, the sensor 58, or the circuits 50-56 may be formed on the insulating cover 74, for example, by using flip-chip technology. The insulating cover 74 may be flipped over onto the housing 18. When flipped over and placed on the housing 18, the components of the IMD 10 formed on the inside of the insulating cover 74 may be disposed within a gap 76 defined by the housing 18. The electrode 16 may be electrically connected to the switching circuit 60 through one or more vias (not shown) formed through the insulating cover 74. The insulating cover 74 may be formed of sapphire (i.e., corundum), glass, parylene, and / or any other suitable insulating material. The housing 18 may be formed from titanium or any other suitable material (e.g., a biocompatible material). The electrode 16 may be formed from stainless steel, titanium, platinum, iridium, or any of their alloys. Additionally, the electrode 16 may be coated with a material such as titanium nitride or fractal titanium nitride, although other suitable materials and coatings may be used for such electrodes.

[0077] Sensor 58 may include any sensor configured to be disposed on or within housing 18 of IMD 10. Sensor 58 may include an accelerometer, a microphone, a light sensor, a temperature sensor, or any combination thereof. Sensing circuit 52 may receive one or more signals from sensor 58. Additionally, or alternatively, sensing circuit 52 may receive one or more signals from electrodes 16. The one or more signals received by sensing circuit 52 from electrodes 16 and / or sensor 58 may represent parameter data indicative of one or more parameters of patient 4.

[0078] FIG. 4 is a block diagram illustrating an example configuration of an external device 12 in accordance with one or more techniques of the present disclosure. In some examples, the external device 12 takes the form of a mobile device, such as a mobile phone, a “smart” phone, a laptop, a tablet computer, or a personal digital assistant (PDA). In some examples, the external device 12 is a computing device of the patient 4. As shown in the example of FIG. 4, the external device 12 includes processing circuitry 80, a storage device 82, communication circuitry 84, and a user interface 86. While shown in FIG. 4 as a standalone device for illustrative purposes, the external device 12 may be any component or system that includes processing circuitry or other suitable computing environment for executing software instructions, and does not necessarily need to include one or more elements illustrated in FIG. 4 (e.g., in some examples, components such as the storage device 82 may not be located in the same location or within the same housing as other components).

[0079] In one example, processing circuitry 80 is configured to implement functions and / or processing instructions for execution within external device 12. For example, processing circuitry 80 may be capable of processing instructions comprising an application 90 stored on storage device 82. Examples of processing circuitry 80 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

[0080] The storage device 82 may be configured to store information, including applications 90 and data 100, within the external device 12. In some examples, the storage device 82 is described as a computer-readable storage medium. In some examples, the storage device 82 includes temporary or volatile memory. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In one example, the storage device 82 is used by the applications 90 executing on the external device 12 to temporarily store information during program execution. The storage device 82 also includes one or more memories configured for long-term storage of information, including, for example, non-volatile storage elements, in some examples. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable memories (EEPROM).

[0081] 1, the sensor device 14, and the computing system 20. The communication circuitry 84 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device capable of sending and receiving information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radios.

[0082] The external device 12 further includes a user interface 86. The user interface 86 may be configured to provide output to the user using tactile, audio, or visual stimuli and to receive input from the user through tactile, audio, or visual feedback. The user interface 86 may include, by way of example, a presence-sensitive display, a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting commands from a user, a sound card, a video graphics adapter card, or any other type of device for converting signals into an appropriate human- or machine-understandable format, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device capable of generating user-understandable output. In some examples, the presence-sensitive display includes a touch-sensitive screen.

[0083] Examples of applications 90 executable by processing circuitry 80 of external device 12 include an IMD interface application 92, a sensor device interface application 94, a health monitor application 96, and a location service 98. Execution of the IMD interface 92 by processing circuitry 80 configures external device 12 to interface with IMD 10. For example, IMD interface 92 configures external device 12 to communicate with IMD 10 via communications circuitry 84. Processing circuitry 80 may retrieve IMD data 102 from IMD 10 and store the IMD data 102 in storage device 82. IMD interface 92 further configures user interface 86 for a user to interact with IMD 10 and / or IMD data 102. For example, IMD interface 92 configures external device 12 to communicate with IMD 10 via communications circuitry 84. Processing circuitry 80 may retrieve IMD data 102 from IMD 10 and store the IMD data 102 in storage device 82. IMD interface 92 further configures user interface 86 for a user to interact with IMD 10 and / or IMD data 102. Similarly, sensor device interface 94 configures external device 12 to communicate with sensor device 14 via communications circuitry 84, retrieve sensor device data 104 from sensor device 14, and store sensor device data 104 in storage device 82. Sensor device interface 42 also configures user interface 86 for a user to interact with sensor device 14 and / or sensor device data 104.

[0084] The health monitor 96 may be configured to facilitate monitoring of the health of the patient 4 by a user, such as the patient or a caregiver. The health monitor 96 may present health information, such as at least a portion of the IMD data 102 and / or the sensor device data 104, via the user interface 86. The health monitor 96 may also collect information about the patient's health from the user via the user interface 86 and store the information as user-recorded health data 106. In some examples, the health monitor 96 presents a questionnaire or survey to the user requesting health data 106 from the user. The health monitor 96 may present the survey according to a schedule, in response to IMD data 102 and / or sensor device data 104 indicating that the patient 4 has experienced a health event, and / or based on the location of the patient 4, for example, in response to location services 98 indicating that the patient 4 has entered a geofenced area defined by geofence data 108. Presenting the survey in response to a health event may facilitate timely capture of user-recorded health data 106 related to the health event. In some examples, a geofenced region may be defined around a clinic, hospital, etc., and entry into such a geofenced region may similarly indicate that patient 4 has experienced a health event meriting timely collection of user-recorded health data 106. Processing circuitry 80 may further store the time and duration of the patient's entry into the geofenced region as geofence data 108.

[0085] The processing circuitry 80 may execute the health monitor 96 to display one or more messages on the user interface 86 requesting feedback from the patient 4. For example, the external device 12 may receive instructions from the computing system 20 to display a request that the patient 4 exhibit one or more behaviors. The processing circuitry 80 may execute the health monitor 96 to control the user interface 86 to display a prompt to select one or more behaviors from the set of behaviors. For example, the prompt may ask the patient 4 whether the patient has engaged in any of the listed behaviors within a period of time. The user interface 85 may display the set of behaviors such that each behavior in the set is associated with a user control that allows the patient 4 to select or deselect the respective behavior. The user interface 85 may further display a submit button that allows the patient 4 to submit the selected behavior. When the processing circuitry 80 receives a selection of one or more behaviors, the processing circuitry 80 may output the selection to the computing system 20 via the communication circuitry 84.

[0086] In some examples, the external device 12 can receive instructions from the computing system 20 to display one or more messages on the user interface 86 representing suggestions for the patient 4 to take one or more actions. For example, the suggestions may include suggestions for modifying one or more patient behaviors. The computing system 20 can determine the one or more suggestions based on parameter data collected by the IMD 10 and / or the sensor device 14 and one or more patient responses to prompts displayed on the user interface 86. For example, if the external device 12 receives a reception indicating that the patient 4 drinks a caffeinated beverage in the morning and the parameter data indicates an increased AF burden in the morning, the computing system 20 can output instructions for the external device 12 to display on the user interface 86 a suggestion for the patient to reduce or eliminate caffeine consumption.

[0087] The IMD data 102 and sensor device data 104 may include patient parameter data derived from sensed physiological signals, as described herein. By way of example, the IMD data 102 may include periodic (e.g., daily) values of one or more of heart rate, heart rate variability, one or more ECG morphological features or beat-to-beat intervals, AF and / or other arrhythmia burden (e.g., number, time, or percent time per period), respiratory rate, perfusion, and activity level. The external device 12, in some examples, can output some or all of the IMD data 102 and sensor device data 104 to the computing system 20.

[0088] By way of example, the sensor device data 104 may include one or more of activity level, distance walked / run, resting energy, active energy, exercise time, quantification of standing, weight, body mass index, heart rate, low, high, and / or irregular heart rate events, heart rate variability, ambulatory heart rate, continuous heart rate, digitized ECG, blood oxygen saturation, blood pressure (systolic and / or diastolic), respiratory rate, maximum oxygen capacity, blood glucose level, peripheral perfusion, and sleep patterns.

[0089] By way of example, user-recorded health data 106 may include one or more of exercise and activity data, sleep data, symptom data, medical history data, quality of life data, nutritional data, medication or compliance data, allergy data, demographic data, weight, and height. Symptom data may include the time the patient experienced the symptom and a characterization of the symptom, such as palpitations, atrial flutter, AF, atrial tachycardia, syncope, or dizziness. Medical history data may relate to a history of AF, stroke, chronic obstructive pulmonary disease (COPD), renal dysfunction, or hypertension, a history of procedures such as ablation or defibrillation, and medical utilization. Sensor device data 104 and / or user-recorded health data 106 may include one or more of the types of data listed in Table 1 below. [Table 1-1] [Table 1-2]

[0090] 5 is a block diagram illustrating an example configuration of a computing system 20 in accordance with one or more techniques of the present disclosure. In the illustrated example, computing system 24 includes processing circuitry 202 for executing applications 220, including a monitoring system 222, a machine learning model 224, a patient interface system 226, or other applications described herein. Computing system 20 may be any component or system including processing circuitry for executing software instructions or other suitable computing environment, and need not necessarily include one or more elements illustrated in FIG. 5 (e.g., components such as user interface device 204, communications circuitry 206, and, in some examples, storage device(s) 208 may not be located in the same location or within the same enclosure as other components). In some examples, computing system 20 may be a cloud computing system distributed across multiple devices.

[0091] 5, computing system 24 includes processing circuitry 202, one or more user interface (UI) devices 204, communication circuitry 206, and one or more storage devices 208. Computing system 20 further includes one or more applications 220, such as a monitoring system 222, that may be executed by computing system 20 in some examples.

[0092] In one example, processing circuitry 202 is configured to implement functions and / or processing instructions for execution within computing system 20. For example, processing circuitry 202 may be capable of processing instructions stored in storage device 208. Examples of processing circuitry 202 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.

[0093] One or more storage devices 208 can be configured to store information within computing system 20 during operation. In some examples, storage device 208 is described as a computer-readable storage medium. In some examples, storage device 208 is temporary memory, meaning that the primary purpose of storage device 208 is not long-term storage. In some examples, storage device 408 is described as volatile memory, meaning that storage device 408 does not retain its stored contents when the computer is turned off. Examples of volatile memory include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage device 208 is used by software or applications 220 running on computing system 20 to temporarily store information during program execution.

[0094] Storage device 208 may further be configured for long-term storage of information such as applications 220 and data 230. In some examples, storage device 208 includes non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or forms of electrically programmable memory (EPROM) or electrically erasable programmable (EEPROM) memory.

[0095] Computing system 20 also includes, in some examples, communications circuitry 206 for communicating with other devices and systems, such as IMD 10 and external device 12 of FIG. 1. Communications circuitry 206 may include a network interface card, such as an Ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device capable of sending and receiving information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radios.

[0096] In one example, computing system 20 also includes one or more user interface devices 204. User interface devices 204, in some examples, may be configured to provide output to a user using tactile, audio, or visual stimuli and receive input from a user through tactile, audio, or visual feedback. User interface devices 204 may include, by way of example, a presence-sensitive display, a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting commands from a user, a sound card, a video graphics adapter card, or any other type of device for converting signals into an appropriate human- or machine-understandable format, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device capable of generating understandable output to a user.

[0097] Application 220 may further include program instructions and / or data executable by processing circuitry 202 of computing system 20 to cause computing system 20 to provide the functionality attributed to the processing circuitry herein. Exemplary application(s) 220 may include a monitoring system 222. Other additional applications not shown may alternatively or additionally be included to provide other functionality described herein, but are not shown for simplicity.

[0098] In accordance with the techniques of this disclosure, computing system 20 receives IMD data 102, sensor device data 104, user recorded health data 106, and geofence data 108 from external device 12 via communications circuitry 206. Processing circuitry 202 stores this as data 230 in storage device 208.

[0099] Computing system 20 may also receive EMR data 230 from EMR database 22 (FIG. 1) via communications circuitry 206 and store EMR data 230 in storage device 208. EMR data 230 may include, for each of a plurality of patients or subjects, by way of example, medication history, surgical procedure history, hospitalization history, emergency or urgent care visit history, scheduled clinic visit history, one or more laboratory or other lab test results, treatment history, cardiovascular history, or co-morbidities such as atrial fibrillation, heart failure, syncope, or diabetes. As a further example, EMR data 230 may include medical images, such as x-ray images, ultrasound images, echocardiograms, anatomical images, medical photographs, radiology images, etc.

[0100] For example, a monitoring system 222 implemented by processing circuitry of computing system 20 can implement techniques of the present disclosure, including developing an algorithm based on a training set of parametric data, e.g., from IMD data 102 and sensor device data 104 of a patient or subject population, and possibly user-recorded health data 106 and EMR data 230, and applying the algorithm to the parametric data of an individual patient 4 to predict the occurrence of a clinically significant health event. In some examples, the monitoring system 222 trains one or more machine learning (ML) models 224 for predicting health events. The output of the ML model for a particular patient can be a level of risk of the health event, e.g., a probability of the health event, a level of risk or probability of the health event occurring within a predetermined time period, and / or whether the risk or probability meets a threshold.

[0101] The plurality of patient parameters may include AF burden, one or more activity parameters, and / or any of the physiological parameters described herein. In some examples, the monitoring system 222 can derive features from the parameter data and apply the features as inputs to an algorithm, such as the ML model 224, to determine the risk level. One or more of the features may be an AF burden feature.

[0102] One or more of the features may be AF stress pattern features. AF stress pattern features may quantify patterns of AF stress over multiple time periods, including the current time period for which the monitoring system 222 is determining the risk level. An AF stress pattern, including changes (e.g., spikes or increases) in AF stress relative to the overall AF stress trend, may be associated with an increased risk of health events, such as stroke or other clinically significant episodes related to cardiovascular health. In some examples, the monitoring system 222 determines the AF stress pattern feature by comparing, e.g., determining the difference or ratio between the current AF stress value and an average, e.g., mean or median, of previous AF stress values. The current value may be a single value for the current time period or a short-term average of values including the current time period and several preceding time periods. The average value may be a long-term average of previous values, e.g., including more values and / or values from further in the past that may not include the current time period value. In some examples, the feature includes patient activity features, such as daily activity levels, daytime or nighttime activity levels, or changes in such activity levels relative to a baseline or trend in activity levels.

[0103] In some examples, AF burden variability may indicate an increased risk of a health event. For example, the monitoring system 222 may calculate an AF burden score corresponding to a time period and an AF burden score corresponding to each time interval of a set of time intervals within the time period. The monitoring system 222 may compare the AF burden score corresponding to each time interval of the set of time intervals with the AF burden score corresponding to the time period. In some cases, the monitoring system 222 may determine how much the AF burden score for each time interval differs from the AF burden score for the entire time period. This may indicate a level of AF burden variability. Higher AF burden variability may indicate an increased risk of a health event occurring.

[0104] Based on the parameter data, the monitoring system 222 can determine the AF burden of the patient 4 over time. The AF burden of the patient 4 over time is a pattern of increasing AF burden in the AF burden of the patient 4 over time.

[0105] The processing circuit 202 is configured to execute the patient interface system 226 to output one or more instructions for displaying information on the user interface 86 of the external device 12 and receiving information from the external device 12. In some examples, the patient interface system 226 may be part of the monitoring system 222 of the application 220. In some examples, the patient interface system 226 and the monitoring system 222 may be separate applications within the application 220. The patient interface system 226 can output instructions for the external device 12 to display information on the user interface 86 in response to the monitoring system 222 detecting a pattern of increased AF burden. The instructions may cause the external device 12 to display a set of patient behaviors on the user interface 86. In some examples, the set of behaviors is likely to contribute to the pattern of increased AF burden. The patient interface system 226 may receive a response indicating a selection of one or more behaviors from the set of behaviors.

[0106] Based on the response, the patient interface system 226 may output one or more suggestions for modifying patient behavior for display by the user interface 86 of the external device 12. If the patient interface system 226 receives a response from the external device 12 indicating that the patient 4 accepts the suggestion to modify behavior, the monitoring system 222 may determine whether the pattern of increased AF burden has attenuated or eliminated after the patient 4 accepted the suggestion. If the pattern of increased AF burden remains, the patient interface system 226 may output another suggestion for modifying patient behavior. In some examples, the patient interface system 226 may output the suggestions in order of how likely the suggestion is to attenuate or eliminate the pattern of increased AF burden. That is, if the most likely cause of the increased AF burden is caffeine consumption, the second most likely cause is sodium consumption, and the third most likely cause is exercise, the patient interface system 226 may first output a suggestion to reduce caffeine consumption. If the suggestion to reduce caffeine consumption does not attenuate or eliminate the pattern of increased AF burden, the patient interface system 226 may output a suggestion to reduce sodium consumption. If suggestions to reduce sodium consumption do not attenuate or eliminate the pattern of increased AF burden, the patient interface system 226 may output suggestions to reduce exercise. In some examples, the monitoring system 222 can determine the likelihood that each action will reduce AF burden.

[0107] The patient interface system 226 may, in some examples, enable a clinician to output one or more messages to the patient and / or enable the patient to output one or more messages to the clinician. For example, the clinician may output a message to the patient via the patient interface system 226 to take one or more medications based on the clinician's analysis of the parameter data. The patient interface system 226 may also notify the clinician about one or more patient conditions (e.g., ablation history, beta block history, or other medical history). Based on the one or more patient conditions, the physician may use the patient interface system 226 to output one or more suggestions to the patient. For example, the clinician may advise the patient not to go out in the morning because doing so increases the patient's risk of an adverse health event.

[0108] In general, the health event can be any clinically significant health event. In some examples, the health event can be a cardiovascular event. The health event can be a stroke. In some examples, the health event is a healthcare utilization event, such as hospitalization. In some examples, the health event includes a clinically significant symptomatic event, such as syncope or dizziness.

[0109] The monitoring system 222 may initially train the ML model 224 using parameter data collected from one or more populations of patients, for example, during a clinical study. In traditional clinical studies, one or more human experts review the parameter data and gather other information to classify each of the training sets by an endpoint, for example, as either including a health event or not. In contrast, the monitoring system 222 can classify the training set of parameter data based on classification data 232 collected automatically in response to the detection of a trigger, which can reduce the cost or labor overhead associated with clinical studies.

[0110] In some examples, the processing circuit 202 executing the monitoring system 222 collects the classification data 232. In some examples, the classification data is additionally or alternatively collected by and received by computing system 20 from other processing circuitry in system 2 (FIG. 1), such as processing circuit 80 of external device 12 (FIG. 4). The classification data 232 includes data indicative of endpoints of a training set of parameter data, for example, indicating whether a patient experienced a health event. The classification data 232 may include data from user-recorded health data 106, geofence data 108, and / or EMR data 230 indicative of patient endpoints.

[0111] Any one or more of the IMD 10, sensor device 14, external device 12, or computing system 20 can detect a trigger for collection of the classified data 232. In some examples, the trigger is a geofence event detected by the external device 12 indicating, for example, that the patient has been to a hospital or clinic for a threshold amount of time. In such examples, the external device 12 or computing system 20 can present a survey to the patient to collect information about the visit, for example, confirming the visit and collecting information about the health issues addressed as user-recorded health data 106 and classified data 230.

[0112] In some examples, the trigger may include, for example, a feature of the patient's parameter data that meets criteria indicating the patient may have experienced a health event. For example, the trigger may be AF burden meeting or exceeding a threshold. Other exemplary triggers may include any physiological parameter feature described herein meeting a threshold. In some examples, the trigger feature may be included in a training set of features used to train the ML model 224, e.g., a set of features that the monitoring system 222 may select to be input features based on their predictive value for a health event. In response to detecting the trigger feature, the monitoring system 222 or other processing circuitry of system 2 may collect classification data 230. Collection of classification data 232 may be via an investigation as described above or by checking the geofence data 108 and / or EMR data 230 to identify times near a hospital or clinic visit that indicate the occurrence of a health event.

[0113] After training the ML model 224, the monitoring system 222 can apply the ML model to parameter data, e.g., IMD data 102 and sensor device data 104, of a particular patient, such as patient 4, to determine a risk level for the patient of experiencing a health event. In some examples, the monitoring system 222 may determine whether the risk level of the health event meets a criterion, e.g., whether it meets or exceeds a threshold risk level. The monitoring system 222 can take one or more actions based on determining that the risk level meets the criterion, for example, as described with respect to FIG. 8 .

[0114] Although these techniques are described herein as being performed by monitoring system 222, and thus by processing circuitry 202 of computing system 20, these techniques may be performed by processing circuitry of any one or more devices or systems of system 2. In some examples, external device 12 may additionally or alternatively implement monitoring system 222 using ML models 224 that are trained, for example, based on population parameter data and, in some examples, personalized based on parameter data of patient 4. ML models 224 may include, by way of example, neural networks, deep learning models, convolutional neural networks, or other types of predictive analytics systems. Furthermore, while the techniques of this disclosure are described primarily with respect to examples including ML models 224, in some examples, the techniques may be implemented using different models or algorithms that do not necessarily require machine learning, such as, by way of example, linear regression, trend analysis, decision trees, or thresholds.

[0115] 6 is a flow diagram illustrating an exemplary technique for training a machine learning model using a training set of parameter data classified based on automatically collected classification data, according to one or more techniques of this disclosure. According to the example illustrated by FIG. 6, a monitoring system 222 receives parameter data, such as IMD data 102 and sensor device data 104, for a plurality of patients (300). The monitoring system 222 determines a training set of parameter data (302). The monitoring system 222 classifies the training set of parameter data based on the automatically collected classification data (304), as described above with reference to FIG. 5. The monitoring system 222 trains an ML model 224 using the training set of classified parameter data (306).

[0116] FIG. 7 is a flow diagram illustrating an exemplary technique for automatically collecting classification data according to one or more techniques of the present disclosure. According to the example of FIG. 7, the monitoring system 222 collects 400 parameter data for a patient, e.g., from among a plurality of patients in a clinical study and ML model training phase. As described above with respect to FIG. 5, the monitoring system determines 402 whether a trigger has occurred. As described above with respect to FIG. 5, an exemplary trigger includes a feature in the parameter data that meets a criterion or geofence event. A geofence event may be an event in which a patient is within a geofenced area (e.g., an area near or surrounding a hospital, urgent care clinic, and / or healthcare provider) for longer than a threshold time. A patient having a geofenced area for longer than a threshold retention time may be evidence of unplanned or planned healthcare utilization. Examples of features in the parameter data that meet the criterion include AF burden or other features derived from an ECG, e.g., heart rate or heart rate variability above a threshold and / or patient activity features below a threshold. If no trigger has occurred (No at 402), the monitoring system 222 may continue to receive patient parameter data and monitor for triggers (400, 402).

[0117] If the trigger occurs (402 - Yes), the monitoring system 222 collects (404) classification data 232. As described above with respect to FIG. 5, exemplary classification data 232 may include user-recorded health data 106 from a survey delivered to the patient in response to the trigger, or temporal proximity geofence data 108 (in the case of a parametric data feature trigger), or EMR data 230 indicating that the patient visited a hospital or clinic and, possibly, that a health event occurred. The monitoring system 222 associates (406) the classification data 232 with the parametric data for final classification of the training set of parametric data.

[0118] 8 is a flow diagram illustrating an example technique for predicting a health event and responding to a prediction of a health event, according to one or more techniques of this disclosure. As mentioned above, example health events include symptomatic events such as stroke, hospitalization or other medical utilization, or symptomatic AF or other cardiovascular events.

[0119] According to the example illustrated by FIG. 8 , the monitoring system 222 receives parameter data, e.g., IMD data 102 and sensor device data 104, for the patient 4 (500). The monitoring system 222 applies features derived from the parameter data to the ML model 224 (502). As described above, the features may include AF features, such as AF burden pattern features, and possibly other features derived from patient activity features or other physiological signals. The monitoring system 222 determines a risk level of a health event based on the application of the features to the ML model 224; for example, the ML model 224 outputs a probability of the health event occurring in a predetermined time period, such as a number of days. The monitoring system 222 determines whether the risk level of the health event meets a criterion, e.g., whether it meets or exceeds a threshold (504). If the risk level does not meet the criterion (No in 504), the monitoring system 222 continues to receive parameter data and apply the features to the ML model 224, e.g., for each time period (500, 502). Based on the risk level meeting the criteria (YES at 504), the monitoring system 222 may perform one or more of the optional actions illustrated by FIG. 8 (506-512).

[0120] The monitoring system 222 may modify (506) the sensing behavior of the system 2. For example, the monitoring system 222 may instruct the IMD 10 and / or the sensing device 104 to employ more sensitive settings for the sensing circuitry 52 or sensor 58, to sample the physiological signal at a higher rate, and / or to take periodic measurements at a higher frequency.

[0121] As another example, the monitoring system 222 may provide 508 instructions to the patient 4 to take or modify a medication. The medication may be an anticoagulant. The instructions may be to take a required dose of the medication or to change the dosage of the medication.

[0122] As another example, the monitoring system 222 may prioritize (810) portions of the parameter data associated with the patient 4 or risk level of a health event in notifications to clinicians treating the patient 4. A monitoring system 222 implementing the techniques of the present disclosure may advantageously reduce the burden of treating patients by prioritizing patients and / or patient data in notifications from the system 2 based on risk levels that meet criteria indicating a clinically significant risk of a health event. In some examples, the monitoring system 222 reduces the burden by determining which rhythms should be sent or alerted to the patient and / or clinician, for example, to present clinically relevant patient reports that determine symptoms.

[0123] As another example, monitoring system 222 may determine a classification of the parameter data associated with a risk level of the health event and create 512 a training set of parameter data for enhanced training of ML model 224 for patient 4 and / or personalization of ML model 224, e.g., to create a patient-specific version of ML model 224. Monitoring system 222 may utilize any of the techniques described herein, e.g., with respect to FIG. 7, to collect classification data 232 for classifying the training set of parameter data.

[0124] The health monitor 96 executed by the processing circuitry 80 of the external device may implement some of the techniques described with respect to Figures 6-8. For example, the health monitor 96 may present surveys and collect responses from the patient 4, present instructions to the patient 4 for taking medications, and enable messaging between the patient 4 and a clinician.

[0125] In some examples, to enable real-time patient management, the health monitor 96 can follow a predetermined protocol to automatically push patient actions based on certain detected patterns in parameter data. For example, the health monitor 96 can see a predetermined clinically significant degree of AF burden and recommend a modification to the patient's anticoagulant medication. As described above, actions can additionally or alternatively be pushed based on the risk level of a health event that meets the criteria. In some examples, the computing system 20 can provide an interface to a clinician via a web interface or user interface device 204 to specify parameter data characteristics or risk level criteria that trigger clinical actions that the patient needs to take, such as AF duration lasting longer than one hour or a probability of stroke exceeding a threshold probability, and anticoagulant uptitration. In some examples, the health monitor 96 can provide required (PRN) medication requests. In some examples, the health monitor 96 can have a communications tab and a priority status that requires actions to be acknowledged before allowing the patient 4 to move on to other functions of the health monitor 96, such as viewing the patient's parameter data.

[0126] 9 is a flow diagram illustrating an example technique for outputting suggestions for modifying patient behavior, according to one or more techniques of the present disclosure. FIG. 9 is described with respect to medical device system 2 of FIG. 1. However, the technique of FIG. 9 may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0127] The computing system 20 may receive parameter data for the patient 4 (602). In some examples, the parameter data is generated by one or more sensing devices (e.g., the IMD 10 and / or the sensor device 14) based on physiological signals of the patient 4 sensed by the one or more sensing devices. In some cases, the computing system 20 may identify one or more parameters based on the parameter data. For example, the computing system 20 may determine AF burden (AFB), diurnal heart rate (DHR), activities of daily living (ADL), nocturnal heart rate (NHR), heart rate variability (HRV), or any combination thereof based on the parameter data collected by the IMD 10 and / or the sensor device 14. The computing system 20 is not limited to determining AFB, DHR, ADL, NHR, and HRV based on the parameter data. The computing system 20 may determine one or more other parameters based on the parameter data.

[0128] Once computing system 20 receives the parameter data, computing system 20 can determine the AF burden of patient 4 over a period of time (604). In some examples, the AF burden of patient 4 over a period of time can represent a time signal indicative of the AF burden of patient 4 at a series of times over the period of time. In some examples, the AF burden of patient 4 over a period of time includes a pattern of increased AF burden. Computing system 20 can identify the pattern of increased AF burden. The pattern may, in some cases, include one or more occurrences of increased AF burden. An occurrence of increased AF burden can represent an event in which the AF burden increases above a threshold AF burden value. In some examples, an occurrence of increased AF burden can represent an event in which the AF burden increases above a threshold AF burden value for more than a threshold amount of time.

[0129] Based on identifying a pattern of increased AF burden, the computing system 20 can output a request to identify patient behaviors (606). The patient behaviors can be output for display by the user interface 86 of the external device 12. The computing system 20 can output the set of behaviors as a list. The list can present each behavior of the set of behaviors along with user controls that allow the user to select or deselect each behavior. In some examples, the external device 12 can receive an input that selects none of the behaviors. In some examples, the external device 12 can receive an input that selects one of the behaviors. In some examples, the external device 12 can receive an input that selects one or a combination of the behaviors. In some examples, the external device 12 can receive an input that selects all of the behaviors.

[0130] The set of behaviors output for display on the external device 12 may represent behaviors that are likely to contribute to an increased AF burden. These behaviors may include consuming foods and beverages containing one or more substances (e.g., caffeine, sodium, and potassium). The behaviors may also include activity (e.g., exercise or another type of physical exertion). In some examples, the computing system 20 may select the set of behaviors based on the time of day when the occurrence of increased AF burden in patient 4 is more likely to occur. For example, if a pattern of increased AF burden corresponding to patient 4 indicates that increased AF burden occurs more frequently in the morning, the computing system 20 may select drinking a caffeinated beverage as one of the set of behaviors. The computing system 20 may, in some cases, output the same set of behaviors regardless of the time of the increased AF burden.

[0131] The computing system 20 can determine suggestions to modify patient behavior to attenuate the pattern of increased AF burden (608). For example, when the computing system 20 receives user input indicating one or more behaviors, the computing system 20 can output suggestions to modify at least one behavior to attenuate the pattern of future increased AF burden. For example, consuming caffeine represents a behavior that may contribute to increased AF burden. If the computing system 20 indicates that the patient 4 consumed caffeine during a time period corresponding to the pattern of increased AF burden, the computing system 20 can output a suggestion to reduce or eliminate caffeine consumption. The computing system 20 can output the suggestions for display by the external device 12 (610).

[0132] FIG. 10 is a flow diagram illustrating an exemplary technique for monitoring AF burden following suggestions to modify patient behavior, according to one or more techniques of the present disclosure. FIG. 10 is described with respect to medical device system 2 of FIG. 1. However, the technique of FIG. 10 may be performed by different components of medical device system 2 or by additional or alternative medical device systems. In some examples, medical device system 2 may perform the technique of FIG. 10 after performing the technique of FIG. 9, although this is not required. Medical device system 2 may also perform the technique of FIG. 10 independently of the technique of FIG. 9.

[0133] The computing system 20 may receive a response indicating that the patient 4 accepts the first suggestion to change the patient behavior (612). In some examples, the first suggestion to change the patient behavior represents a suggestion output for display by the external device 12 in the technique of FIG. 9 , although this is not required. The first suggestion may represent any suggestion presented to and accepted by the patient 4. In some examples, when the computing system 20 outputs a suggestion to change the patient behavior, the suggestion may be on a user interface with user controls for accepting the suggestion. By indicating that the suggestion has been accepted, the patient 4 may indicate an intention to change their behavior in accordance with the suggestion.

[0134] Based on receiving the response, computing system 20 may determine 614 the AF burden of patient 4 over a period of time. In some examples, this period may occur after patient 4 accepts the first suggestion to change patient behavior. That is, computing system 20 may determine the AF burden of patient 4 after accepting the suggestion and determine whether the suggestion to change patient behavior effectively addressed the increase in AF burden.

[0135] The computing system 20 may determine whether a pattern of increased AF burden exists during the time period (616). If a pattern of increased AF burden does not exist during the time period ("No" at block 616), the computing system 20 may determine that the first suggestion successfully attenuated the increased AF burden (617). In some examples, the computing system 20 identifies a pattern of increased AF burden before outputting the first suggestion to change behavior. The computing system 20 may determine that the first suggestion to change behavior was effective based on determining that the pattern of increased AF burden is attenuated or does not exist following acceptance of the suggestion to change behavior.

[0136] If a pattern of increased AF burden is present during the period (“Yes” at block 616), the computing system 20 may determine a second suggestion for modifying one or more patient behaviors (618). The computing system 20 may determine that the first suggestion failed to attenuate or eliminate the pattern of increased AF burden when the patient indicated an intent to adopt the first suggestion but the pattern of increased AF burden still exists after acceptance of the first suggestion. In some cases, the computing system 20 may select a second suggestion based on the most likely cause of the pattern of increased AF burden. While the first suggestion may have been the most likely cause, based on determining that the first suggestion was effective, the computing system 20 may select a second suggestion to include the next most likely cause other than the first suggestion. The computing system 20 may output a suggestion (620) for display by the user interface 86 of the external device 12.

[0137] Figure 11 is a flow diagram illustrating an exemplary technique for identifying a pattern of increased AF burden, according to one or more techniques of the present disclosure. Figure 11 is described with respect to medical device system 2 of Figure 1. However, the technique of Figure 11 may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0138] The computing system 20 can determine the AF burden of the patient 4 over a period of time based on the parameter data. The computing system 20 can analyze the AF burden of the patient 4 over a period of time to determine whether there is a pattern of increased AF burden. The pattern of increased AF burden can, in some cases, be time-dependent. For example, increased AF burden may be more likely to occur for the patient at certain times of day due to one or more behaviors of the patient. The increase in AF burden can indicate an increased likelihood of a health event for the patient 4. The computing system 20 can identify one or more occurrences of increased AF burden over a period of time (630). In some examples, an occurrence of increased AF burden represents an event in which the AF burden of the patient 4 increases above a threshold AF burden value. In some examples, an occurrence of increased AF burden represents an event in which the AF burden of the patient 4 increases above a threshold AF burden value for more than a threshold amount of time.

[0139] The computing system 20 can determine 632 a time corresponding to each occurrence of the one or more occurrences. In some examples, the one or more occurrences may occur more frequently at certain times of day. For example, for a first patient, the one or more occurrences may occur more frequently in the morning, and for a second patient, the one or more occurrences may occur more frequently in the evening. The first patient may drink coffee in the morning, causing an increase in AF burden, and the second patient may exercise in the evening, causing an increase in AF burden. The computing system 20 can determine 632 a time corresponding to the occurrence of the increased AF burden to obtain pattern information.

[0140] Additionally, or alternatively, computing system 20 can determine the severity of each of the one or more episodes of increased AF burden (634). The severity of an episode of increased AF burden can include the duration of the episode or the magnitude of the episode. The duration can represent the amount of time the patient's AF burden remains above the AF burden threshold. The magnitude can include the maximum AF burden of the episode, the sum of AF burden values greater than the AF burden threshold, or another calculation reflecting the level of increased AF burden. Computing system 20 can identify a pattern of increased AF burden based on the time corresponding to each episode and the severity of each episode (636).

[0141] 12 is a flow chart illustrating an exemplary technique for determining a risk level of a health event based on a patient's AF burden over a period of time, in accordance with one or more techniques of the present disclosure. FIG. 12 is described with respect to medical device system 2 of FIG. 1. However, the technique of FIG. 12 may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0142] The computing system 20 may receive (702) parameter data for the patient 4. In some examples, the parameter data may be indicative of multiple parameters of the patient 4. The parameter data may be generated by one or more sensing devices (e.g., the IMD 10 and / or the sensor device 14) based on physiological signals of the patient sensed by the one or more sensing devices. In some examples, the parameter data may be indicative of AF burden, diurnal heart rate, activities of daily living, nighttime heart rate, heart rate variability, or any combination thereof.

[0143] The computing system 20 can determine the AF burden of the patient 4 over a period of time based on the parameter data (704). The computing system 20 can apply the AF burden of the patient 4 over a period of time to a model (706). In some examples, the model can output a risk level based on the AF burden of the patient 4. The model can evaluate the AF burden data to determine whether the AF burden data indicates an increased risk of a health event. For example, the computing system 20 can determine a risk level of the health event for the patient 4 based on application of the AF burden to the model (708). In some examples, the model can determine the risk level based on the variability of the AF burden, the magnitude of one or more episodes of increased AF burden, the duration of one or more episodes of increased AF burden, or any combination thereof.

[0144] 13 is a flow diagram illustrating an example technique for determining a risk level of a health event based on AF load variation, according to one or more techniques of the present disclosure. FIG. 13 is described with respect to medical device system 2 of FIG. 1. However, the technique of FIG. 13 may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0145] The variability of a patient's AF burden over time may be an indicator of an increased risk of a health event. In some instances, the variability of AF burden is a stronger indicator of an increased risk of a health event than one or more other AF burden parameters (e.g., the duration of an increased AF burden episode, the magnitude of an increased AF burden episode). As a result, it may be beneficial for computing system 20 to determine the variability of increased AF burden over time to assess the risk level of patient 4 experiencing a health event.

[0146] The computing system 20 may receive 710 the AF burden for the patient 4 over the time period. The computing system 20 may calculate 712 an AF burden score corresponding to the time period. In some examples, the AF burden score may represent the median AF burden or the median AF burden over the time period. In some examples, the AF burden score may represent the sum of the AF burden values over the time period. The AF burden score corresponding to the time period may quantify the AF burden over the entire time period. For example, the AF burden score may be greater when there is a greater amount of AF burden over the time period, and the AF burden score may be lower when there is a lesser amount of AF burden over the time period.

[0147] Computing system 20 may calculate 714 an AF stress score corresponding to each time interval of the set of time intervals within the time period. For example, the time period may be divided into a set of time intervals. The set of contiguous time intervals may comprise a time period. In some examples, the AF stress score may represent the median AF stress or the median AF stress over each time interval. In some examples, the AF stress score may represent the sum of the AF stress values over each time interval. Computing system 20 may determine an AF score corresponding to each time interval of the set of time intervals such that the AF score for each time interval is comparable to the AF score for the entire time period.

[0148] For example, computing system 20 may compare the AF stress score corresponding to each time interval of the set of time intervals with the AF stress score corresponding to the time period (716). In some examples, computing system 20 may determine, for each time interval of the set of time intervals, the difference between the AF stress score for the time period and the AF score for the respective time interval. Computing system 20 may calculate a sum of the differences to determine the extent to which the AF stress score for the time interval differs from the baseline AF score for the time period.

[0149] Computing system 20 can determine a risk level for the patient based on the comparison (718). For example, by comparing the AF burden score corresponding to each time interval of the set of time intervals with the AF burden score corresponding to the time period, computing system 20 can determine the degree to which patient 4's AF burden changes over time. A higher level of variability can correspond to a higher risk level. A lower level of variability can correspond to a lower risk level.

[0150] 14 is a flow diagram illustrating an example technique for determining a risk level of a health event based on one or more conditions specific to a patient, according to one or more techniques of the present disclosure. FIG. 14 is described with respect to medical device system 2 of FIG. 1. However, the technique of FIG. 14 may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0151] The computing system 20 may receive parameter data for the patient 4 (802). In some examples, the parameter data is generated by one or more sensing devices based on physiological signals of the patient 4 sensed by the one or more sensing devices (e.g., the IMD 10 and / or the sensor device 14). The computing system 20 may determine a set of parameters for the patient 4 based on the parameter data (804). These parameters may, in some examples, include AF burden, diurnal heart rate, activities of daily living, nighttime heart rate, heart rate variability, or any combination thereof, although these are not the only parameters that the computing system 20 is configured to determine based on the parameter data. The computing system 20 may, in some cases, determine one or more parameters in addition to or instead of the AF burden, diurnal heart rate, activities of daily living, nighttime heart rate, and heart rate variability.

[0152] In some examples, computing system 20 may receive information indicative of one or more conditions specific to the patient (806). For example, computing system 20 may receive a history of AF, a history of COPD, a CHADS-VASc score, a previous oral anticoagulant (prior_oac), a history of chronic kidney disease, a history of ablation, a history of sleep apnea, a history of coronary artery disease, a history of valvular disease, or any combination thereof, corresponding to patient 4. In some examples, computing system 20 may receive one or more conditions of patient 4 in addition to or in place of the history of AF, a history of COPD, a CHADS-VASc score, a previous oral anticoagulant (prior_oac), a history of chronic kidney disease, a history of ablation, a history of sleep apnea, a history of coronary artery disease, and a history of valvular disease.

[0153] The computing system 20 may apply the set of parameters to the model based on one or more conditions (808). In some examples, to apply the set of parameters to the model, the computing system 20 may assign a weight to each parameter in the set of parameters. Each parameter in the set of parameters may have a different amount of impact on the risk level of the health event. For example, AF burden may have a greater impact on the risk level than nighttime heart rate. In this example, the computing system 20 may set the weight of AF burden to be higher than the weight of nighttime heart rate. One or more patient conditions may affect the weights applied to one or more parameters. For example, if the patient has a history of ablation, this may affect the weight placed on one or more parameters. In some examples, if the patient has a history of beta blockade, this may change the weight placed on heart rate variability. The computing system 20 may determine the risk level of the health event for patient 4 (810). The weights applied to the parameters may affect the risk level determined by the computing system 20.

[0154] 15 is a conceptual diagram illustrating a patient behavior query screen 1000 for display on a device's user interface in accordance with one or more techniques of the present disclosure. As seen in FIG. 15, the screen 1000 includes an introductory message 1010 that reads, "Please select any activity you will be involved in between 7:00 AM and 10:00 AM." The screen 1000 includes a first patient behavior 1020, a first user control 1021, a second patient behavior 1022, a second user control 1023, a third patient behavior 1024, a third user control 1025, a fourth patient behavior 1026, a fourth user control 1027, a fifth patient behavior 1028, and a fifth user control 1029. The screen 1000 includes a user control 1030 for presenting the selected patient behavior.

[0155] Patient behaviors 1020, 1022, 1024, 1026, and 1028 may represent behaviors likely contributing to increased AF burden. The first patient behavior 1020 may include "consuming caffeinated beverages," the second patient behavior 1022 may include "consuming foods or beverages containing high levels of sodium," the third patient behavior 1024 may include "consuming foods or beverages containing high levels of added sugars," the fourth patient behavior 1026 may include "engaging in exercise," and the fifth patient behavior 1028 may include "consuming foods or beverages containing high levels of potassium." In the example of FIG. 15 , the user control 1021 corresponding to the first patient behavior 1020 and the user control 1029 corresponding to the fifth patient behavior 1028 are selected, while the other user controls 1023, 1025, and 1027 are deselected. This means that if user control 1030 is selected, the device will transmit information indicating that the patient indicated that they "consume caffeinated beverages" and "consume foods or beverages containing high levels of potassium" between the hours of 7:00 AM and 10:00 AM.

[0156] 16 is a conceptual diagram illustrating a first suggestion screen 1100 for display on a user interface of a device in accordance with one or more techniques of the present disclosure. As seen in FIG. 16, the first suggestion screen 1100 includes a first message 1110 stating, "Consider changing your morning routine in the following ways," and a second message 1120 stating, "Consume 5 milligrams (mg) or less of caffeine." The first message 1110 and the second message 1120 may present suggestions for the patient to limit their caffeine consumption. If the patient accepts the suggestion by selecting an "accept" user control 1130, the device may send a message to the computing system 20 that the patient has accepted the suggestion.

[0157] 17 is a conceptual diagram illustrating a second suggestion screen 1200 for display on a user interface of a device in accordance with one or more techniques of the present disclosure. As shown in FIG. 17, the second suggestion screen 1200 includes a first message 1210 that reads, "Consider making the following changes to your morning routine," and a second message 1220 that reads, "Avoid consuming potassium." The first message 1210 and the second message 1220 may present suggestions for the patient to limit potassium consumption. If the patient accepts the suggestions by selecting an "accept" user control 1230, the device may send a message to the computing system 20 that the patient has accepted the suggestions.

[0158] 18 is a graph showing parameter data for multiple patient parameters over a period before and after a stroke event (time 0), in accordance with one or more techniques of the present disclosure. In the example of FIG. 18, the patient parameters include a patient activity parameter (an activity of daily living related to the amount of patient movement above a threshold during daytime hours), heart rate variability (HRV), nighttime heart rate, diurnal heart rate, and time in AF (or AF burden). As can be seen in the illustrated example, in the days leading up to the stroke, time in AF and heart rate-related parameters all increase, while patient activity decreases.

[0159] FIG. 19 is a graph showing a time series of moving averages of parameter data for a patient parameter according to one or more techniques of the present disclosure. In the example shown by FIG. 19, the patient parameter is activities of daily living, but similar techniques may be applied to any other patient parameter described herein. FIG. 19 illustrates a technique for quantifying features associated with deviations of a patient parameter from its baseline or trend, which may indicate an increased risk of a health event. In some embodiments, the monitoring system 222 summarizes trends using at least two simple moving averages (SMAs) and uses a comparison or offset of the two SMAs to capture clinically significant changes in the patient parameter. One SMA may be a short-term SMA, and the other may be a long-term SMA, for example, that includes less recent values of the patient parameter than the short-term SMA. Patient parameter values occurring within a predetermined number of days of a health event, such as a stroke, may be identified. Undersampled controls may be matched 1:1 with cases, and all offsets and covariates may be evaluated in a single model. The monitoring system 222 may compare the fit of each variable (patient parameter) to determine the relative importance of the variables.

[0160] 20 is a chart illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke according to one or more techniques of the present disclosure. The patient parameters in the example of FIG. 20 are AF burden (AFB), diurnal heart rate (DHR), activities of daily living (ADL), nocturnal heart rate (NHR), and heart rate variability (HRV). The statistical significance shown in FIG. 20 was determined based on parameter data collected from multiple patients, including patients who have suffered a stroke. As shown in FIG. 20, AF burden was found to be a significantly better predictor of stroke than other patient parameters.

[0161] Experimental analysis suggested that changes in AF burden occur within the long-term trend (21+ days) before a stroke event. AF burden can be considered a key predictor in the long term. More specifically, an increase in the short-term trend of AF burden within the long-term trend may predict stroke. The predictive ability of AF burden may be four times greater when acute short-term changes are compared with the long-term trend.

[0162] Figure 21 is another chart showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke, according to one or more techniques of the present disclosure. Figure 21 is similar to Figure 20 but includes additional patient parameters. In particular, Figure 21 includes history of AF, CHADS-VASc score, prior oral anticoagulant (prior_oac), and history of chronic kidney disease. Figure 21 shows that prior stroke is 13 times more significant as a predictor of stroke than AF burden, while AF burden is the primary predictor after CHADS-VASc.

[0163] 22A-22D are charts showing the experimentally determined statistical significance of multiple patient parameters in predicting stroke for different patient populations, according to one or more techniques of the present disclosure. FIG. 22A shows the statistical significance of multiple patient parameters in predicting stroke for patients who have previously undergone AF ablation. FIG. 22B shows the statistical significance of multiple patient parameters in predicting stroke for patients with previously managed AF. FIG. 22C shows the statistical significance of multiple patient parameters in predicting stroke for patients who have previously had a stroke. FIG. 22D shows the statistical significance of multiple patient parameters in predicting stroke for patients suspected of having unconfirmed AF.

[0164] 23A-23D are charts showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization (a subset of healthcare utilization) for different patient populations, according to one or more techniques of the present disclosure. FIG. 23A shows the statistical significance of multiple patient parameters in predicting stroke for patients who have previously undergone AF ablation. FIG. 23B shows the statistical significance of multiple patient parameters in predicting stroke for patients with previously managed AF. FIG. 23C shows the statistical significance of multiple patient parameters in predicting stroke for patients who have previously had a stroke. FIG. 23D shows the statistical significance of multiple patient parameters in predicting stroke for patients with suspected but not confirmed AF.

[0165] 24 is a chart showing an analysis of AF burden pattern features to predict stroke and healthcare utilization (HCU) according to one or more techniques of the present disclosure. The analysis shows that for both stroke and HCU, spikes in AF burden, possibly paired with low patient activity levels, predict events occurring within a time frame.

[0166] 25A and 25B are schematic diagrams illustrating AF burden patterns in patients experiencing stroke or medical utilization events, respectively, for various patient populations, in accordance with one or more techniques of the present disclosure. AF burden patterns such as those shown in FIGS. 25A and 25B show asymptomatic changes indicative of periods of increased risk for stroke and HCU.

[0167] A retrospective cohort study of patients with ICM, including the RevealLINQ™ ICM, was conducted to determine whether a rules-based algorithm examining changes from baseline ICM-based parameters could be used to stratify short-term HCU risk. Incidence of HCU as the study endpoint was derived from de-identified claims data. Patients were labeled as having incident HCU if their claims history included at least one inpatient or outpatient hospital, emergency room, or ambulatory surgery center visit with a cardiovascular DRG or diagnosis code. If a patient utilized multiple visits, the first incident of HCU was recorded.

[0168] The ICM-based diagnostic parameters evaluated in the study included the daily total AT / AF burden (milliseconds per day), total patient activity, e.g., time with patient movement above a threshold (minutes per day), mean ventricular rate (night and day), and HRV. Patients with daily follow-up less than 21 days after transplantation or with a follow-up gap of more than 30 days were excluded from the cohort. Missing data resulting from gaps in daily follow-up were interpolated by forward-filling the last known value for each diagnostic parameter. The follow-up history was limited to 2 years unless an HCU was present, and if an HCU was present, the follow-up ended on the day prior to the event. Patients with no device detection time of AT / AF within the 2-year follow-up period were excluded from the cohort.

[0169] To define the diagnostic time patterns for the study, each parameter on the follow-up days of each patient was evaluated as the cumulative moving average (CMA) from the day after transplantation and as the SMA over different history periods (1, 2, 3, 5, 8, 13, and 21 days) starting from 21 days after transplantation. For the study, the offset SMA a_b is the difference between the SMA a and the SMA b , where the SMA of the longer period is subtracted from the SMA of the shorter period (i.e., a < b). The offset for period p with its respective CMA is shown as the SMA p_c .

[0170] FIG. 26 is a graph showing the detected AT / AF time (burden) over the course of the monitoring period according to one or more techniques of the present disclosure. The vertical bars indicate sub-periods during which the patient experienced AT / AF, in this case the AF burden (AT / AF time) over several days. The graph of FIG. 26 further includes three trend lines showing the CMA of the AF burden 600, the 21-day SMA of the AF burden 602, and the difference between the 21-day SMA and the CMA of the AF burden 604, respectively.

[0171] For the study, the occurrence of HCU was treated as an imbalanced binary classification problem. A recursive partitioning and regression tree algorithm (RPART) was used to predict which follow-up days had an HCU occurrence, using diagnostic parameters and moving average offsets as predictors. A random sampling method for imbalanced learning was used within the bootstrapping routine to promote algorithm convergence and improve classifier accuracy. HCU events were oversampled by labeling the 5 days prior to the occurrence as an event. For patients who experienced an HCU, follow-up was terminated the day before the occurrence to prevent the use of device measurements obtained on the same day the event occurred, a situation that would introduce look-ahead bias into the modeling. For each bootstrap iteration, 1. Patients were randomly divided into a training set (70%) and a validation set (30%). 2. In the training set, the number of unlabeled days was sampled equal to the number of labeled days. 3. Classification trees using 10-fold cross-validation were fitted to the balanced training set. 4. The model fit in step 3 was pruned to its minimum cross-validation error. 5. The split information from the model fitting in step 4 was saved. 6. The imbalanced validation set was classified using the model fit from step 4. 7. Classification statistics for each terminal node from step 6 were saved.

[0172] Each split for a terminal node was recorded as a 3-tuple [predictor name, comparison, index] along with its respective HCU rate and patient count for both the training and validation sets. If a node had multiple splits, each split was saved as a separate entry. In such cases, the utilization rate and patient count are the same for all splits within each node.

[0173] Scatterplots of the decision tree terminal nodes showing the relationship between labeled HCU rates and percentage of patients were used to identify patterns in the AF burden classification tree structure that stratify healthcare event risk. The algorithm for defining these patterns is as follows: 1. Visually identify areas in the scatter plot that have local maxima in patient percentage. 2. If the region is specific to time in AT / AF, define Cartesian coordinates for event risk and patient percentage surrounding the region. 3. If the area is not specific to time in AT / AF i. Set the upper and lower patient percentage limits equal to the local maximum. ii. Subtract 0.01 from the lower limit of the patient percent. iii. Set lower and upper event rate bounds at each location where the scatter plot intersects with the patient percentage lower bound defined in the previous step. 4. Select the nodes within the rectangular area. 5. Group by pair [predictor name, comparison]. 6. Calculate the number of times each pair is selected, the number of times each pair is selected as a percentage of all bootstrapped classification trees, and the mean of the [index] values. 7. If the region is not specific to time in AT / AF, repeat steps 3.ii-6 until a modal predictor is selected in at least 10% of all classification trees. 8. Rank order 3-tuple [predictor, comparison, average index value] in descending order by selectivity. 9. Identify elbows by selectivity (i.e., selectivity drops by approximately 50%). 10. Define an AF loading pattern as a 3-tuple with selectivity above the elbow point identified in the preceding step.

[0174] Descriptive analyses and equal proportion tests were performed to compare odds ratios for AF burden patterns with clinically relevant thresholds for duration and volume.

[0175] The bootstrapping routine was run 3,000 times to generate an equal number of classification trees. Figure 27 presents a scatterplot of 50,751 terminal nodes by labeled HCU rate and percent of patients for balanced training data according to one or more techniques of the present disclosure. Points on the plot represent unique terminal nodes. A single node can be represented across diagnostic parameters if its definition includes multiple partitions with different parameters per partition (e.g., time in AT / AF > 1 hour & daily activity < 100 minutes & nighttime heart rate > 80 beats / min). Three local maxima were identified and shown as shaded regions A, B, and C. Missing (A & C) or low frequency (B) nodes for daily activity and heart rate parameters suggest that the region is primarily defined by time in AT / AF. Region D is derived from the analysis of regions A, B, and C and is defined later in the results. [Table 2]

[0176] Table 2 (above) outlines the top five segmentations by region. Segments with selectivity above their respective elbow points are in bold. Combining these highlighted segmentations defines the AF burden pattern for a given region. Pattern A is defined by an AF burden CMA of less than approximately 1 second. The pattern is present in all 3,000 decision trees and describes the follow-up period before the initial detection of AT / AF (77% of occurrences) and the relative period of sinus rhythm restoration after the device detects AT / AF (23% of occurrences). Pattern C is defined by an AF burden CMA of greater than approximately 1 second and an AF burden 21-day SMA that is approximately greater than its historical average. This pattern is present in 25% of all decision trees and describes a relative spike or trend increase in daily AF burden. Pattern B is defined by an AF burden CMA of greater than approximately 1 second, but unlike pattern C, it has a decreasing AF burden 21-day SMA that is less than its historical average. The increase in the SMA on day 1 (daily load) relative to the SMA on day 21 suggests that pattern C may represent sporadic periods of below-average load for patients, possibly following periods of high load.

[0177] Figure 28 presents an exemplary graphical illustration of these patterns in AF burden data mapped for a single HCU patient, according to one or more techniques of the present disclosure. Labeled HCU rates and patient percentages were calculated based on training data for AF burden volume and duration thresholds. The volume threshold was defined as a daily AF burden exceeding 5% (72 minutes). The duration threshold was defined as continuous AF for more than 1 hour. For each threshold, the log-odds event rates were 0.369 and 0.386, and the patient percentages were 12.9% and 7.6%. Region D of Table 2 summarizes the top five partitions in the terminal node scatterplot where the log-odds event rate exceeded 0.369 and the patient percentage exceeded 12.9%. The top three partitions define a partial substructure of Pattern C, where the CMA of daily activities falls below 76 minutes. When applied to the balanced training set, pattern D was selected 10.4% of the time and had a log-odds ratio of 0.368, a value not statistically different from the other log-odds ratios (Poisson regression, p>0.5 for all threshold factors).

[0178] Atrial fibrillation (AF) can be associated with an increased risk of healthcare utilization (HCU), which can be caused by the onset of AF or changes in AF burden. Changes from baseline in AF burden or other parameters measured by an insertable cardiac monitor (ICM) can be useful for predicting short-term HCU. One or more ICM parameters can be used to estimate the risk of short-term HCU.

[0179] AF burden (total hours of AT / AF per day) can be converted to a simple moving average (SMA) for different periods (1, 2, 3, 5, 8, 13, 21 days) per follow-up (FU). The cumulative SMA can be calculated for the time between ICM implantation and FU. AF pattern can be defined as a comparison of SMA duration with its cumulative average. The same process can be applied to daily activities recorded by the ICM. HCU can be defined as any encounter from a hospital, emergency room, or ambulatory surgery center with a cardiovascular DRG or diagnosis code.

[0180] AF burden patterns may reveal distinct groups: (A) no history of AF (reference); (B) below average burden; (C) above average burden; and (D) above average burden with low levels of ICM detected daily activity. The odds of HCU were increased in all groups versus reference (B vs. A OR 3.82; C vs. A OR 8.25; D vs. A OR 11.66), including a 33% (212 / 644) increase in HCU detection relative to nominal duration and volume thresholds. [Table 3]

[0181] Table 3 includes the AF burden thresholds for Groups A, B, C, and D. Analysis of changes from baseline in ICM-detected AF and ICM-detected daily activity can be strongly associated with short-term HCU, especially high burden combined with low activity.

[0182] Figure 29 presents a scatterplot of terminal nodes scored by labeled HCU rate and patient percentile for an unbalanced validation set, according to one or more techniques of the present disclosure. The overall distribution is similar in shape to the training data (Figure 27). Different shaded colors indicate different threshold patterns, with the lightest shaded points representing nodes not covered by the pattern. AF burden patterns (A-C) provide broad coverage of terminal node distribution with clear segmentation of event risk (B vs. A, odds ratio (OR) 3.82, 95% CI 3.59-4.07; C vs. A, OR 8.25, 95% CI 7.84-8.69). Inclusion of a daily activity threshold (D) provides more specific coverage of the AF burden pattern with the greatest risk of HCU (D vs. A, OR 11.66, 95% CI 10.63-12.79).

[0183] Figure 30 shows a Venn diagram of AF burden threshold counts for the validation set. Table 4 (below) presents statistics for each threshold and their mutually exclusive subsets according to one or more techniques of the present disclosure. Approximately 32% (6594 / 20858) of the Pattern D thresholds were mutually exclusive with the volume and duration thresholds, representing a 33% (212 / 644) increase in event capture rate. Tests for differences in odds ratios using Poisson regression showed statistically significant agreement for all three threshold crossings (p<0.10). The remaining coefficients were not statistically different (p>0.10 for all coefficients). Approximately 23% of patients experienced only Pattern D thresholds, a predicted rate of 18.2%, or 66 days per year of follow-up. [Table 4]

[0184] In Table 4, count indicates the number of times the threshold was met. Event, number of labeled HCUs; Odds, ratio of event count to threshold count divided by group mean event rate for the validation set. Patient, number of patients with at least one day meeting the threshold as a percentage of all patients in the validation set; Follow-up, days meeting the threshold as a percentage of total follow-up days for patients with at least one occurrence of the threshold. Note: Counts are mutually exclusive per follow-up day, not per patient. Patients may experience different thresholds across follow-up days. Therefore, patient and follow-up percentages do not sum to 100%.

[0185] Analysis of AF burden patterns in the study confirmed the correlation between increased burden and risk, and more specifically, confirmed that an increasing trend in AF burden (e.g., daily) over time is associated with a greater risk of HCU, especially when accompanied by a decline in daily activity. AF burden patterns less than approximately 1 hour predict medical events comparable to volume and duration thresholds greater than 1 hour. AF burden patterns demonstrated additional event capture complementary to volume and duration thresholds. AF burden as a risk factor for HCU is related to a patient's historical burden.

[0186] This study presents AF burden and patient activity values as parametric data from which features can be derived and then applied to an algorithm or model to determine the likelihood of an event, such as an HCU event, as described herein. Features derived from AF burden may include AF burden pattern features, such as changes in AF burden relative to the overall AF burden trend, e.g., spikes or increases. For example, AF burden pattern features may include one or more offsets between SMAs for different lookback periods and / or between SMAs and CMAs for lookback periods. As described herein, the models to which such features are applied may be machine-learned or rule-based, including, for example, decision trees and / or thresholds.

[0187] It should be understood that the various aspects disclosed herein may be combined in different combinations than those specifically presented in the description and accompanying drawings. It should also be understood that, depending on the embodiment, certain acts or events of any process or method described herein may be performed in a different order, added, combined, or omitted entirely (e.g., not all described acts or events may be required to implement the techniques). Furthermore, while certain aspects of the present disclosure are described for clarity as being performed by a single module, unit, or circuit, it should be understood that the techniques of the present disclosure may be implemented by a combination of units, modules, or circuits associated with, for example, a medical device.

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

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

[0190] The following examples are a non-limiting list of clauses according to one or more techniques of the present disclosure.

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

[0192] Example 1. A medical device system comprising: a memory; and a processing circuit in communication with the memory, the processing circuit being configured to: receive parameter data for a plurality of parameters of a patient, the parameter data generated by one or more sensing devices based on the patient's physiological signals sensed by the one or more sensing devices; determine, based on the parameter data, an atrial fibrillation (AF) burden of the patient over a period of time, the patient's AF burden over the period of time including a pattern of increased AF burden; output, for display by a user device operated by the patient, a request identifying whether the patient engaged in each patient behavior of a set of patient behaviors during the period of time; and determine, based on receiving a response indicating that the patient engaged in one or more patient behaviors of the set of patient behaviors, suggestions for modifying at least a subset of the one or more patient behaviors to attenuate the pattern of increased AF burden, and output the suggestions for display by the user device operated by the patient.

[0193] Example 2. The medical device system of Example 1, wherein the time period is a first time period and the proposal is a first proposal, and wherein the processing circuit is further configured to: receive from the user device a response indicating that the patient accepts the proposal to modify at least a subset of the one or more patient behaviors; determine, based on the parameter data, an AF burden of the patient over a second time period, the second time period occurring after the response indicating that the patient accepts the proposal to modify; analyze the AF burden of the patient over the second time period to determine whether a pattern of increased AF burden exists during the second time period; and based on determining that a pattern of increased AF burden exists during the second time period, determine a second proposal to modify at least a subset of the one or more patient behaviors; and output the second proposal for display by a user device operated by the patient.

[0194] Example 3. A medical device system as described in any of Examples 1-2, wherein the processing circuitry is configured to output a list of the set of patient behaviors, and each patient behavior in the set of patient behaviors is associated with a user control configured to select or deselect the respective patient behavior, in order to output a request to identify whether the patient engaged in each patient behavior in the set of patient behaviors during the period of time.

[0195] Example 4. The medical device system of any of Examples 1-3, wherein, to determine the proposal to modify at least a subset of the one or more patient behaviors, the processing circuitry is configured to: identify a likelihood that each patient behavior of the one or more patient behaviors contributed to a pattern of increased AF burden; and determine the proposal to modify at least a subset of the one or more patient behaviors based on the likelihood that each patient behavior of the one or more patient behaviors contributed to the pattern of increased AF burden.

[0196] Example 5. A medical device system as described in any of Examples 1 to 4, wherein the set of patient behaviors includes one or more of: consumption of one or more foods, consumption of one or more beverages, and one or more patient exercise activities.

[0197] Example 6. The medical device system of any of Examples 1-5, wherein the processing circuitry is further configured to identify, in the parameter data, a pattern of increased AF burden over a period of time, wherein to identify the pattern of increased AF burden, the processing circuitry is configured to: identify one or more occurrences of increased AF burden over a period of time, wherein each occurrence of the one or more occurrences includes an event in which the patient's AF burden exceeds an AF burden threshold for more than a threshold duration; determine a time corresponding to each occurrence of the one or more occurrences; and determine that the one or more occurrences of increased AF burden occur at one or more times of day.

[0198] Example 7. The medical device system of Example 6, wherein the processing circuitry is further configured to select a set of patient behaviors for output to the user device based on one or more times of day during which one or more occurrences of increased AF burden are likely to occur.

[0199] Example 8. A memory,

[0200] 1. A medical device system comprising: a processing circuit in communication with a memory, the processing circuit configured to: receive parameter data for a plurality of parameters of a patient, the parameter data being generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine an atrial fibrillation (AF) burden of the patient over a period of time based on the parameter data; apply the patient's AF burden over the period of time to a model; and determine a risk level of a health event for the patient based on the application of the patient's AF burden over the period of time to the model.

[0201] Example 9. The medical device system of Example 8, wherein, to apply the patient's AF burden over a time period to the model, the processing circuitry is configured to: calculate an AF burden score corresponding to the time period; calculate an AF burden score corresponding to each time interval of a set of time intervals within the time period; and compare the AF burden score corresponding to each time interval of the set of time intervals to the AF burden score corresponding to the time period; and determine a health event risk level for the patient based on comparing the AF burden score corresponding to each time interval of the set of time intervals to the AF burden score corresponding to the time period.

[0202] Example 10. The medical device system of Example 9, wherein to compare the AF stress score corresponding to each time interval of the set of time intervals with the AF stress score corresponding to the time period, the processing circuit is configured to: determine a difference between the AF stress score corresponding to each time interval of the set of time intervals and the AF stress score corresponding to the time period; and determine an AF stress deviation score indicative of the degree to which the patient's AF stress deviates from their baseline AF stress based on the difference between the AF stress score corresponding to each time interval of the set of time intervals and the AF stress score corresponding to the time period.

[0203] Example 11. The medical device system of Example 10, wherein to determine the AF burden deviation score, the processing circuitry is configured to calculate a sum of each difference between the AF burden score corresponding to each time interval of the set of time intervals and the AF burden score corresponding to the time period.

[0204] Example 12 The medical device of any of Examples 9-11, wherein the duration of each time interval of the set of time intervals is 24 hours.

[0205] Example 13. The medical device system of any of Examples 8-12, wherein to apply the patient's AF burden over the time period to the model, the processing circuitry is configured to identify a set of time intervals within the time period and determine an amount of time for each time interval of the set of time intervals during which the patient's AF burden is greater than an AF burden threshold, and the processing circuitry is configured to determine the patient's risk level of a health event based on the amount of time for each time interval of the set of time intervals during which the patient's AF burden is greater than the AF burden threshold.

[0206] Example 14. The medical device system of any of Examples 8-13, wherein to apply the patient's AF burden over the time period to the model, the processing circuitry is configured to identify one or more occurrences over the time period in which the patient's AF burden is greater than an AF burden threshold and determine a duration of each occurrence of the one or more occurrences, and the processing circuitry is configured to determine the patient's risk level of a health event based on the amount of time for each time interval of a set of time intervals in which the patient's AF burden is greater than the AF burden threshold.

[0207] Example 15. A medical device system described in any of Examples 8 to 14, wherein, in order to determine the risk level of the health event, the processing circuitry is configured to determine a probability of the occurrence of the health event.

[0208] Example 16. A medical device system according to any of Examples 8 to 15, wherein the risk level comprises the risk of a health event occurring within a predetermined period of time.

[0209] Example 17. A medical device system comprising: a memory; and a processing circuit in communication with the memory, the processing circuit configured to: receive parameter data for a plurality of parameters of a patient, the parameter data being generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine a set of parameters for the patient over a period of time based on the parameter data; receive information indicative of one or more conditions specific to the patient; set a weight corresponding to each parameter of the set of parameters based on the one or more conditions specific to the patient; apply the set of parameters of the patient over the period of time to a model; and determine a risk level of a health event for the patient based on the application of the set of parameters over the period of time to the model.

[0210] Example 18 The medical device system of Example 17, wherein the one or more conditions specific to the patient include a previous medical procedure performed on the patient.

[0211] Example 19. The medical device system of Example 18, wherein the one or more previous medical procedures include ablation.

[0212] Example 20. The medical device system of any of Examples 17-18, wherein the one or more conditions specific to the patient include one or more medications taken by the patient.

Claims

1. A medical device system, Memory and A processing circuit that communicates with the memory, wherein the processing circuit is Receiving parameter data for multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on the patient's physiological signals sensed by one or more sensing devices. Based on the parameter data, determine the atrial fibrillation (AF) load of the patient over a period of time, wherein the AF load of the patient over the period of time includes a pattern of increased AF load. For display on a user device operated by the patient, output a request to identify whether the patient engaged in each of the set of patient behaviors during the period, Based on receiving a response indicating that the patient was involved in one or more of the set of patient behaviors, a proposal is made to modify at least a subset of the one or more patient behaviors in order to attenuate the pattern of increased AF load. A medical device system comprising a processing circuit configured to output the proposal for display by the user device operated by the patient.

2. The aforementioned period is the first period, the aforementioned proposal is the first proposal, and the aforementioned processing circuit is Receiving a response from the user device indicating that the patient accepts the proposal to modify at least the subset of the one or more patient behaviors, Based on the parameter data, determine the AF load of the patient over a second period, the second period occurring after the patient's response indicating acceptance of the proposed changes. Analyze the AF load of the patient over the second period to determine whether the increased AF load pattern exists during the second period, Based on the determination that the aforementioned increased AF load pattern exists during the second period, a second proposal is made to modify at least the subset of the one or more patient behaviors. The medical device system according to claim 1, further configured to output the second proposal for display on the user device operated by the patient.

3. The medical device system according to claim 1, wherein the processing circuit is configured to output a list of the set of patient behaviors in order to output the request for identifying whether the patient engaged in each of the set of patient behaviors during the period, and each of the set of patient behaviors is associated with a user control configured to select or deselect the respective patient behavior.

4. To determine the proposal to modify at least the subset of the one or more patient behaviors, the processing circuit: To identify the possibility that each of the one or more patient behaviors described above contributed to the pattern of increased AF load, The medical device system according to claim 1, configured to determine the proposal to modify at least the subset of the one or more patient behaviors, based on the possibility that each of the one or more patient behaviors contributed to the pattern of increased AF load.

5. The medical device system according to claim 1, wherein the set of patient behaviors includes one or more of the following: consumption of one or more foods, consumption of one or more beverages, and one or more exercise activities of the patient.

6. The processing circuit is further configured to identify the pattern of the increased AF load over the period in the parameter data, and in order to identify the pattern of the increased AF load, the processing circuit is configured Identifying one or more occurrences of increased AF load over the aforementioned period, wherein each occurrence of the one or more occurrences includes an event in which the patient's AF load exceeds the AF load threshold for a longer duration than the threshold duration. Determining the time corresponding to each of the one or more occurrences, A medical device system according to any one of claims 1 to 5, configured to determine that one or more occurrences of increased AF load occur at one or more times of day.

7. The medical device system according to claim 6, wherein the processing circuit is further configured to select a set of patient behaviors to output to the user device based on the one or more times during which the one or more occurrences of the increased AF load are likely to occur.

8. A medical device system, Memory and A processing circuit that communicates with the memory, wherein the processing circuit is Receiving parameter data for multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on the patient's physiological signals sensed by one or more sensing devices. Based on the parameter data, the atrial fibrillation (AF) load of the patient over the period is determined, Applying the AF load of the patient over the aforementioned period to the model, A medical device system comprising: a processing circuit configured to determine the risk level of health events for the patient based on the application of the patient’s AF load to the model over the aforementioned period.

9. To apply the AF load of the patient over the aforementioned period to the model, the processing circuit is: To calculate the AF load score corresponding to the aforementioned period, Calculate the AF load score corresponding to each time interval in the set of time intervals within the aforementioned period, The system is configured to compare the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the period, The medical device system according to claim 8, wherein the processing circuit is configured to determine the risk level of the health event for the patient based on comparing the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the period.

10. In order to compare the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the period, the processing circuit: The difference between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the period is determined. The medical device system according to claim 9, configured to determine an AF load deviation score indicating the degree to which the patient's AF load deviates from a baseline AF load, based on the difference between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the period.

11. The medical device system according to claim 10, wherein the processing circuit is configured to calculate the sum of the differences between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the period, in order to determine the AF load deviation score.

12. The medical device system according to claim 9, wherein the duration of each time interval in the set of time intervals is 24 hours.

13. To apply the AF load of the patient over the aforementioned period to the model, the processing circuit is: Identifying a set of time intervals within the aforementioned period, The system is configured to determine the time duration for each time interval in the set of time intervals in which the AF load of the patient is greater than the AF load threshold, The medical device system according to any one of claims 8 to 12, wherein the processing circuit is configured to determine the risk level of the health event for the patient based on the amount of time for each time interval in the set of time intervals in which the patient's AF load is greater than the AF load threshold.

14. A medical device system, Memory and A processing circuit that communicates with the memory, wherein the processing circuit is Receiving parameter data for multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on the patient's physiological signals sensed by one or more sensing devices. Based on the aforementioned parameter data, determine a set of patient parameters over a period of time, Receiving information indicating one or more conditions specific to the aforementioned patient, Based on the one or more conditions specific to the patient, a weight is set corresponding to each parameter in the set of parameters. Applying the set of parameters of the patient over the aforementioned period to the model, A medical device system configured to determine the risk level of a health event for a patient based on the application of the set of parameters over the aforementioned period to the model.

Images