Health event prediction

Abstract

A system includes processing circuitry configured to receive parameter data for a plurality of parameters of a patient. The parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices. The plurality of parameters includes an AF load. The processing circuitry is configured to derive one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load mode feature; applying the one or more features to the model; and determining a risk level of a health event for the patient based on applying the one or more features to the model.

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application Serial No. 63 / 384,879, filed on November 23, 2022, the entire content of which is incorporated herein by reference. Technical Field

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

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

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

[0005] Generally speaking, 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 including atrial fibrillation (AF) burden. In some examples, these techniques include applying AF burden pattern features to a model to determine the risk level. In some examples, the model is trained with a training set of parameter data classified with classification data automatically collected in response to a triggered detection.

[0006] In one example, a system includes processing circuitry configured to receive parameter data of a plurality of parameters of a patient. The parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices. The plurality of parameters includes an AF load. The processing circuitry is configured to: derive one or more features based on the parameter data of the plurality of parameters, wherein the one or more features includes at least one AF load pattern feature; apply the one or more features to a model; and determine a risk level of a health event of the patient based on applying the one or more features to the model.

[0007] In another example, a method includes receiving parameter data of a plurality of parameters of a patient. The parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices. The plurality of parameters includes an AF load. The method includes: derive one or more features based on the parameter data of the plurality of parameters, wherein the one or more features includes at least one AF load pattern feature; apply the one or more features to a model; and determine a risk level of a health event of the patient based on applying the one or more features to the model.

[0008] In another example, a system includes processing circuitry configured to receive parameter data of a plurality of parameters of a patient. The parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices. The processing circuitry is further configured to: determine a training set of parameter data for training a model based on the parameter data of the patient; classify the training set of parameter data based on classification data automatically collected in response to a detected trigger; and train the model with the classified training set of parameter data.

[0009] In another example, a method includes receiving parameter data of a plurality of parameters of a patient. The parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices. The method further includes: determine a training set of parameter data for training a model based on the parameter data of the patient; classify the training set of parameter data based on classification data automatically collected in response to a detected trigger; and train the model with the classified training set of parameter data.

[0010] In another example, a system includes processing circuitry configured to perform any of the methods described herein.

[0011] In another example, a non-transitory computer-readable storage medium includes program instructions configured to cause processing circuitry to perform any of the methods described herein.

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

[0013] Figure 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.

[0014] Figure 2 illustrates Figure 1 an example configuration of an IMD.

[0015] Figure 3 illustrates Figure 1 and Figure 2 a conceptual side view of an example configuration of an IMD.

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

[0017] Figure 5 is a block diagram illustrating an example computing system operating in accordance with one or more techniques of the present disclosure.

[0018] Figure 6 is a flowchart illustrating an example technique for training a machine learning model using a training set of parameter data classified using automatically collected classified data.

[0019] Figure 7 is a flowchart illustrating an example technique for automatically collecting classified data.

[0020] Figure 8 is a flowchart illustrating an example technique for predicting a health event and responding to a prediction of the health event.

[0021] Figure 9 is a graph illustrating parameter data of a plurality of patient parameters during a time period surrounding a stroke event.

[0022] Figure 10 is a graph illustrating time series values of a moving average of parameter data of patient parameters.

[0023] Figure 11 is a chart illustrating the statistical significance of a plurality of patient parameters in experimentally determined significance when predicting a stroke.

[0024] Figure 12Is a graph illustrating the statistical significance determined experimentally of multiple patient parameters in predicting stroke.

[0025] Figures 13A to 13D Is a graph illustrating the statistical significance determined experimentally of multiple patient parameters in predicting stroke in different patient populations.

[0026] Figures 14A to 14D Is a graph illustrating the statistical significance determined experimentally of multiple patient parameters in predicting hospitalization in different patient populations.

[0027] Figure 15 Is a graph illustrating the AF load pattern characteristics for predicting stroke and healthcare utilization.

[0028] Figure 16A And Figure 16B Are diagrams respectively illustrating the AF load patterns of patients who have experienced a stroke or a healthcare utilization event for different patient populations.

[0029] Figure 17 Is a graph showing the AT / AF time (load) detected during a monitoring period.

[0030] Figure 18 Presents a scatter plot of terminal nodes of the HCU rate and patient percentage according to the labeled balance training data.

[0031] Figure 19 Presents an example graphical illustration of the pattern in the AF load data mapped for a single HCU patient.

[0032] Figure 20 Presents a scatter plot of terminal nodes of the HCU rate and patient percentage score according to the labeled imbalance validation set.

[0033] Figure 21 Presents a Venn diagram of the AF load threshold counts of the validation set.

[0034] Figure 22 Illustrates the design of a study using machine learning techniques to evaluate the importance of AF load characteristics.

[0035] Figure 23A And Figure 23B Is a diagram including a 21-day simple moving average of the daily AT / AF load and a continuous moving average of the daily AT / AF load over several days.

[0036] Figure 24 Is a conceptual graph illustrating a machine learning analysis of the variable importance performed to identify AF load patterns.

[0037] Figure 25 It is a convergence curve graph illustrating the mean importance of each of multiple variables across bootstrap iterations.

[0038] Figure 26 It is a bar graph of mean variable importance scaled as a percentage of total variable importance and the pattern decoding association of each variable with stroke risk.

[0039] Figure 27 It includes a bar graph illustrating mean variable importance scaled as a percentage of total variable importance and the pattern decoding association with stroke risk stratified by device indication.

[0040] Figure 28 It is a bar graph illustrating the temporal relationship between AT / AF burden and ischemic stroke risk differing by device indication.

[0041] Figure 29 It is a bar graph of mean variable importance scaled as a percentage of total variable importance according to CHA2DS2-VASc score and other characteristics.

[0042] Figure 30 It is an error bar graph illustrating the mean AUC and 95% confidence intervals of 1,000 bootstrap, held-out validation samples from twelve different model structures.

[0043] Figure 31 It is a curve graph illustrating AT / AF burden data from a random sample of 16 patients with CHA2DS2-VASc score > 3 and ischemic stroke occurrence.

[0044] Throughout the figures and the specification, like reference numerals refer to like elements. Detailed Description

[0045] Multiple types of implantable and medical devices detect arrhythmia episodes and other health events based on sensed ECG and (in some cases) other physiological signals. External devices that can be used for non-invasive sensing and monitoring of ECG and other physiological signals include wearable devices having electrodes configured to contact a patient's skin, such as patches, watches, or necklaces. Such medical devices can facilitate relatively long-term monitoring of a patient's health during normal daily activities.

[0046] Implantable medical devices (IMDs) also sense and monitor ECG and other physiological signals and detect health events such as arrhythmia episodes and worsening heart failure. Example IMDs include: pacemakers and implantable cardioverter defibrillators that can be coupled to intravascular or extravascular leads; and pacemakers having a housing configured for implantation within the heart, which can be leadless. Some IMDs do not provide therapy, such as implantable patient monitors. An example of such an IMD is the Reveal LINQ available commercially from Medtronic plc TM Insertable cardiac monitors (ICMs) that can be inserted subcutaneously. Such IMDs can facilitate relatively long-term monitoring of a patient during normal daily activities and can periodically send the collected data, such as onset data of detected arrhythmia episodes, to a remote patient monitoring system, such as Medtronic Carelink TM Network.

[0047] Figure 1 is a block diagram illustrating an example medical device system 2 configured to predict health events of patient 4 and respond to such predictions. Example techniques can be used with IMD 10, which can communicate wirelessly with an external device 12. In some examples, IMD 10 is implanted outside the patient 4's chest (e.g., implanted subcutaneously Figure 1 in the illustrated chest location). IMD 10 can be positioned near the sternum at or just below the level of patient 4's heart, e.g., at least partially within the cardiac silhouette. IMD 10 includes a plurality of electrodes ( Figure 1 not shown in ) and is configured to sense ECG via the plurality of electrodes. In some examples, IMD 10 takes the form of a LINQ TM ICM. Although described primarily in the context of examples in which the IMD takes the form of an ICM, the techniques of the present disclosure can be implemented in systems including any one or more implantable or external medical devices, including monitors, pacemakers, or defibrillators.

[0048] The external device 12 is a computing device configured to communicate wirelessly with IMD 10. The external device 12 retrieves the onset and other physiological data collected and stored by IMD 10 from IMD10. In some examples, the external device takes the form of a personal computing device of the patient or caregiver, such as a smart phone.

[0049] In Figure 1In the example shown, system 2 also includes a sensor device 14 that communicates wirelessly with an external device 12. The sensor device 14 can include electrodes and other sensors to sense physiological signals of patient 4, and can collect and store physiological data and detect seizures based on such signals. In some examples, the sensor device 14 is an external device that can be worn by patient 4. The sensor device 14 can be incorporated into the clothing of patient 14, such as incorporated within clothing, shoes, glasses, watches or wristbands, hats, etc. In some examples, the sensor device 14 is a smartwatch or other accessory or peripheral device of the external device 12 such as a smart phone.

[0050] The external device 12 retrieves seizure and other physiological data collected and stored by the sensor device 14. The external device 12 can include a display and other user interface elements. In some examples, the external device 12 presents physiological data and / or its statistical representation retrieved from the IMD 10 and / or the sensor device 14 to patient 4 or another user. The external device 12 can communicate with the IMD 10 and / or the sensor device 14 according to, for example or a low power (BLE) protocol.

[0051] The external device 12 can be configured to communicate with a computing system 20 via a network 16. The external device 12 can be used to retrieve data from the IMD 10 and the sensor device 14 and can send the data to the computing system 20 via the network 16. The retrieved data can include values of physiological parameters measured by the IMD 10 and the sensor device 14, data regarding arrhythmia seizures 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 retrieved from the IMD 10 and the sensor device 14 can include values of various patient parameters, and / or can be used by the computing system 20 to determine values of patient parameters. Values of patient parameters can be referred to as patient parameter data. Patient parameter data can be retrieved and / or determined on a periodic basis to produce periodic values, such as daily values produced on a daily basis.

[0052] The computing system 20 can include computing devices configured to allow a user (e.g., a clinician treating patient 4 and other patients) to interact with data collected from their patients' IMD 10 and sensor device 14. In some examples, the computing system 20 includes one or more handheld computing devices, computer workstations, servers, or other networked computing devices. In some examples, the computing system 20 can include one or more devices implementing a monitoring system 222 including processing circuitry and storage means ( Figure 5)。The monitoring system 222 can present parameter data of the patient to the clinician to allow the clinician to remotely track and evaluate their patients. In some examples, the monitoring system 222 can analyze the data and prioritize the presentation of certain patients' data or alerts based on that analysis. In some examples, the computing system 20, the network 16, and the monitoring system 222 can be implemented via the Medtronic Carelink TM network.

[0053] The network 16 can 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 cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices. The network 16 can include one or more networks managed by a service provider and can thus form part of a large-scale public network infrastructure (e.g., the Internet). The network 16 can provide access to the Internet to computing devices (such as the computing system 20 and the external device 12) and can provide a communication framework that allows the computing devices to communicate with each other. In some examples, the network 16 can be a private network that provides a communication framework that allows the computing system 20 and the external device 12 to communicate with each other, but separates one or more of these devices or the data stream between these devices from devices external to the network 16 for security purposes. In some examples, the communication between the computing system 20 and the external device 12 is encrypted.

[0054] The computing system 20 can also retrieve data of the patient 4 from the electronic medical record (EMR) database 22. The EMR database 22 can store the electronic medical record (also referred to as electronic health record) of the patient 4, which can be generated by various healthcare providers, laboratories, clinicians, insurance companies, etc. Although Figure 1 illustrated as a single database, the EMR database 22 can include various databases managed by various entities.

[0055] As an example, the EMR database 22 may store, for example, 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 clinic visit history, one or more laboratory or other clinical test results of patient 14, a patient 14's cardiovascular history, or a patient 14's comorbidities (such as atrial fibrillation, heart failure, or diabetes). As a further example, the EMR database 22 may store medical images of patient 4, such as X-ray images, ultrasound images, echocardiograms, anatomical images, medical photographs, radiographic images, etc. The data stored in the EMR database 22 may include patient-specific records of patient 4 and many other patients. In some examples, the data stored by the EMR database 22 may include more extensive demographic information or group type information of multiple patients.

[0056] For example, a monitoring system 222 implemented by the processing circuitry of the computing system 20 may implement the techniques of the present disclosure, including developing an algorithm based on a training set of parameter data of a group of patients or subjects retrieved from the IMDs 10 and external devices 14 of the group, and applying the algorithm to the parameter data of an individual patient 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 to predict health events. The output of the ML model for a particular patient may be a risk level of a health event, the probability that the health event will occur within a particular time period, and / or whether the risk or probability meets a threshold.

[0057] Example health events that may be predicted using the techniques of the present disclosure include strokes, clinically significant AF that requires hospitalization or urgent care, and clinically significant episodes of symptomatic events such as syncope or dizziness. Parameter data that may be used to predict such health events may include cardiac rhythm data, such as heart rate data and data related to the onset of atrial fibrillation (AF) or other arrhythmias. AF data may include a quantification of AF (referred to as AF burden) and the pattern of AF burden over multiple time periods. Parameter data that may be used to predict such clinically significant health events may alternatively or additionally include patient activity data or any other patient data or signals described herein.

[0058] The monitoring system 222 may also utilize data from the EMR database 22 and / or data input by the patient or caregiver via the external device 12, along with parameter data from the IMD 10 or the sensor device 14. In some examples, data from the EMR database 22 and / or data input by the patient or caregiver may be used as input to an ML model or other health event prediction algorithms implemented by the monitoring system 222. In some examples, data from the EMR database 22 and / or data input by the patient or caregiver via the external device 12 may provide classification of a training set for the parameter data from the IMD 10 and the sensor device 14, for training one or more ML models to predict health events. For example, data from the EMR database 22 and / or data input by the patient or caregiver via the external device 12 may indicate whether the patient 4 has experienced a clinically significant health event, when the clinically significant health event occurred, and the severity of the clinically significant health event experienced. Such data may be associated with the parameter data to create a training set for the parameter data. After an initial training phase, such a training set may be used for reinforcement learning and, in some cases, for personalization of one or more ML models.

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

[0060] Figure 2 is an illustration Figure 1 of an example configuration of the IMD 10. As Figure 2 shown, the IMD 10 includes a processing circuit 50, a sensing circuit 52, a communication circuit 54, a memory 56, a sensor 58, a switching circuit 60, and electrodes 16A, 16B (hereinafter "electrodes 16"), one or more of which may be disposed on the housing of the IMD 10. In some examples, the memory 56 includes computer-readable instructions that, when executed by the processing circuit 50, cause the IMD 10 and the processing circuit 50 to perform the various functions attributed to the IMD 10 and the processing circuit 50 herein. The memory 56 may include any volatile, non-volatile, magnetic, optical, or dielectric, 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.

[0061] Processing circuit 50 may include fixed function circuitry and / or programmable processing circuitry. Processing circuit 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 circuit 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 circuit 50 herein may be embodied as software, firmware, hardware, or any combination thereof.

[0062] Sensing circuit 52 may be selectively coupled to electrodes 16A, 16B via a switching circuit 60 controlled by processing circuit 50. Sensing circuit 52 may monitor signals from electrodes 16A, 16B to monitor Figure 1 the electrical activity of the heart of patient 4 and generate ECG data of patient 4. In some examples, processing circuit 50 may identify features of the sensed ECG, such as heart rate, heart rate variability, in-beat intervals, and / or ECG morphological features, to detect an episode of arrhythmia in patient 4. Processing circuit 50 may store the digitized ECG and the features of the ECG for detecting an episode of arrhythmia as episode data of the detected episode of arrhythmia in memory 56. Processing circuit 50 may also store parameter data (including features of the ECG and data quantifying an episode of arrhythmia, such as AF burden data) in memory 56.

[0063] Sensing circuit 52 and / or processing circuit 50 may be configured to detect cardiac depolarization (e.g., the P wave of atrial depolarization or the R wave of ventricular depolarization) when the ECG amplitude crosses a sensing threshold. In some examples, for cardiac depolarization detection, sensing circuit 52 may 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 of 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 may use the indication to determine features of the ECG, including inter-depolarization intervals, heart rate, and heart rate variability. Sensing circuit 52 may also provide one or more digitized ECG signals to processing circuit 50 for analysis, such as for rhythm discrimination, and / or to identify and characterize features of the ECG, such as QRS amplitude and / or width, or other morphological features.

[0064] In some examples, the sensing circuit 52 measures, via electrodes 16, the impedance of tissue, such as tissue proximate to the IMD 10. The measured impedance may vary based on respiration and perfusion or degree of edema. The processing circuit 50 may determine parameter data related to respiration, perfusion, and / or edema based on the measured impedance.

[0065] In some examples, the 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, the sensing circuit 52 may include one or more filters and amplifiers for filtering and amplifying signals received from one or more of the electrodes 16A, 16B, and / or other sensors 58. In some examples, the sensing circuit 52 and / or the processing circuit 50 may include rectifiers, filters, and / or amplifiers, sense amplifiers, comparators, and / or analog-to-digital converters. The processing circuit 50 may determine parameter data (e.g., physiological parameter values of the patient 4) based on signals from the sensors 58, and these signals may be stored in the memory 56.

[0066] In some examples, the processing circuit 50 sends the parameter and episode data of the patient 4 to Figure 1 an external device 12 via the communication circuit 54, and the external device may send the data to the network 16 for processing by the monitoring system 222 of the computing system 20. The communication circuit 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 circuit 50, the communication circuit 54 may receive downlink telemetry from the external device 12 or another device by means of an internal antenna or an external antenna (e.g., antenna 26), and transmit uplink telemetry to the external device or another device.

[0067] Although described herein in the context of the example IMD 10, the techniques for arrhythmia detection disclosed herein may be used with other types of devices. For example, the techniques may be implemented with: an external cardiac defibrillator coupled to electrodes external to the cardiovascular system, a transcatheter pacemaker configured for implantation within the heart (such as the Micra TM transcatheter pacing system commercially available from Medtronic PLC of Dublin, Ireland), an insertable cardiac monitor (such as the Reveal LinQ TM ICM also commercially available from Medtronic), a nerve stimulator, or a drug delivery device.

[0068] As regarding Figure 1As discussed, the sensor device 14 can be an external device, such as a smartwatch, fitness tracker, patch, or other wearable device. The sensor device 14 can be configured similarly to the IMD 10, in the sense that it can include electrodes, sensors, sensing circuitry, processing circuitry, memory, and communication circuitry, and can be used similarly to collect parameter data and communicate with the external device 12. The sensors and the parameter data collected by the IMD 10 and the sensor device 14 can be different as described herein.

[0069] Figure 3 is a conceptual side view illustrating an example configuration of the IMD 10. In Figure 3 the example shown, the IMD 10 can include a leadless subcutaneously implantable monitoring device having a housing 18 and an insulating cover 74. Electrodes 16A and 16B can be formed or placed on the outer surface of the cover 74. The circuits 50 to 56 and 60 described above with respect to Figure 2 can be formed or placed on the inner surface of the cover 74 or within the housing 18. In the illustrated example, the antenna 26 is formed or placed on the inner surface of the cover 74, but in some examples, it can be formed or placed on the outer surface. In some examples, the sensor 58 can also be formed or placed on the inner or outer surface of the cover 74. In some examples, the insulating cover 74 can be positioned over the open housing 18 such that the housing 18 and the cover 74 enclose the antenna 26, the sensor 58, and the circuits 50 to 56 and 60 and protect the antenna and the circuits from fluids such as body fluids.

[0070] One or more of the antenna 26, the sensor 58, or the circuits 50 to 56 can be formed on the insulating cover 74, such as by using flip-chip technology. The insulating cover 74 can be flipped onto the housing 18. When flipped and placed on the housing 18, the components formed on the inner side of the insulating cover 74 of the IMD 10 can be positioned within the gap 76 defined by the housing 18. The electrodes 16 can 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 can be formed of sapphire (i.e., corundum), glass, parylene, and / or any other suitable insulating material. The housing 14 can be formed of titanium or any other suitable material (e.g., a biocompatible material). The electrodes 16 can be formed of any one of stainless steel, titanium, platinum, iridium, or their alloys. Additionally, the electrodes 16 can be coated with a material such as titanium nitride or fractal titanium nitride, but other suitable materials and coatings for such electrodes can be used.

[0071] Figure 4FIG. 0 is a block diagram illustrating an example configuration of an external device 12. In some examples, the external device 12 takes the form of a mobile device, such as a mobile phone, a “smart” phone, a laptop computer, a tablet computer, or a personal digital assistant (PDA). In some examples, the external device 12 is a computing device of a patient 4. As Figure 4 shown in the example of Figure 4 , the external device 12 includes a processing circuit 80, a storage device 82, a communication circuit 84, and a user interface 86. Although shown as a stand-alone device for purposes of example in Figure 4 , the external device 12 can be any component or system that includes a processing circuit or other suitable computing environment for executing software instructions and, for example, need not include

[0072] one or more of the elements shown in

[0073] (e.g., in some examples, components such as the storage device 82 may not be co-located with other components or may be in the same rack).

[0074] The external device 12 utilizes the communication circuit 84 to communicate with other devices, such as Figure 1communicate with the IMD 10, 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 that can transmit and receive information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radio components.

[0075] 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 receive input from the user through tactile, audio, or visual feedback. As an example, the user interface 86 may include a presence-sensitive display, a mouse, a keyboard, a voice response system, a camera, a microphone, or any other type of device for detecting commands from the user, a sound card, a video graphics adapter card, or any other type of device for converting signals into a suitable form understandable by humans or machines, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device for generating an understandable output to the user. In some examples, the presence-sensitive display includes a touch-sensitive screen.

[0076] Example applications 90 executable by the processing circuitry 80 of the 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 the processing circuitry 80 configures the external device 12 to interface with the IMD 10. For example, the IMD interface 92 configures the external device 12 to communicate with the IMD 10 via the communication circuitry 84. The processing circuitry 80 may retrieve IMD data 102 from the IMD 10 and store the IMD data 102 in the memory 82. The IMD interface 92 also configures the user interface 86 for the user to interact with the IMD 10 and / or the IMD data 102. For example, the IMD interface 92 configures the external device 12 to communicate with the IMD 10 via the communication circuitry 84. The processing circuitry 80 may retrieve IMD data 102 from the IMD 10 and store the IMD data 102 in the memory 82. The IMD interface 92 also configures the user interface 86 for the user to interact with the IMD 10 and / or the IMD data 102. Similarly, the sensor device interface 94 configures the external device 12 to: communicate with the sensor device 14 via the communication circuitry 84, retrieve sensor device data 104 from the sensor device 14; and store the sensor device data 104 in the memory 82. The sensor device interface 42 also configures the user interface 86 for the user to interact with the sensor device 14 and / or the sensor device data 104.

[0077] The health monitor 96 can be configured to facilitate a user, such as a patient or caregiver, in monitoring the health of patient 4. The health monitor 96 can 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 can 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 seeking the health data 106 from the user. The health monitor 96 can present the survey according to a schedule, in response to IMD data 102 and / or sensor device data 104 indicating that patient 4 has experienced a health event, and / or based on the location of patient 4 (e.g., in response to location services 98 indicating that patient 4 has entered a geofenced area defined by geofence data 108). Presenting the survey in response to a health event can facilitate timely capture of user-recorded health data 106 regarding the health event. In some examples, the geofenced area is defined around a clinic, hospital, etc., and entering such a geofenced area can similarly indicate that patient 4 has experienced a health event worthy of timely collection of user-recorded health data 106. The processing circuit 80 can also store the time and duration of the patient's entry into the geofenced area as geofence data 108.

[0078] The IMD data 102 and the sensor device data 104 can include patient parameter data derived from sensed physiological signals, as described herein. As an example, the IMD 102 can include periodic (e.g., daily) values of one or more of the following: heart rate, heart rate variability, one or more ECG morphological features or interbeat intervals, AF and / or other arrhythmia burdens (e.g., number, time, or percentage time per cycle), respiratory rate, perfusion, and activity level.

[0079] As an example, the sensor device data 104 can include one or more of the following: activity level, walking / running distance, resting energy, active energy, exercise minutes, quantification of standing, weight, body mass index, heart rate, low heart rate events, high heart rate events, and / or irregular heart rate events, heart rate variability, walking heart rate, heart beat series, digitized ECG, blood oxygen saturation, blood pressure (systolic and / or diastolic), respiratory rate, maximum oxygen volume, blood glucose, peripheral perfusion, and sleep pattern.

[0080] As an example, the health data 106 recorded by the user may include one or more of the following: exercise and activity data, sleep data, symptom data, medical history data, quality of life data, nutritional data, medication taking or compliance data, allergy data, demographic data, weight, and height. The symptom data may include the time when the patient experienced the symptom and the characteristics of the symptom, such as palpitations, atrial flutter, AF, atrial tachycardia, syncope, or dizziness. The 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 cardioversion), and healthcare utilization. The sensor device data 104 and / or the health data 106 recorded by the user may include one or more data types listed in Table 1 below.

[0081]

[0082]

[0083] Table 1 Figure 5 is a block diagram illustrating an example configuration of the computing system 20. In the illustrated example, the computing system 24 includes processing circuitry 202 for executing an application 220, which includes a monitoring system 222 or any other application described herein. The computing system 20 can be any component or system that includes processing circuitry or other suitable computing environment for executing software instructions, and need not include, for example, Figure 5 one or more of the elements shown (e.g., the user interface device 204, the communication circuitry 206; and in some examples, components such as the storage device 208 may not be co-located with other components or may be in the same rack). In some examples, the computing system 20 can be a cloud computing system distributed across multiple devices.

[0084] In Figure 5 the example of, the 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. In some examples, the computing system 20 further includes one or more applications 220 (such as the monitoring system 222) executable by the computing system 20.

[0085] In one example, the processing circuitry 202 is configured to implement functionality and / or process instructions for execution within the computing system 20. For example, the processing circuitry 202 can be capable of processing instructions stored in the storage device 208. Examples of the processing circuitry 202 may include any one or more of the following: 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.

[0086] One or more storage devices 208 may be configured to store information within computing device 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, which means that the primary purpose of storage device 208 is not long-term storage. In some examples, storage device 408 is described as volatile memory, which means that when the computer is turned off, storage device 408 does not maintain the stored content. 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 application 220 running on computing system 20 to temporarily store information during program execution.

[0087] Storage device 208 may also be configured for long-term storage of information, such as application 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 various forms of electrically programmable read-only memory (EPROM) or electrically erasable and programmable read-only memory (EEPROM).

[0088] In some examples, computing system 20 also includes communication circuitry 206 to communicate with other devices and systems, such as Figure 1 IMD 10 and external device 12. Communication 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 that can transmit and receive information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radio components.

[0089] In one example, computing system 20 also includes one or more user interface devices 204. In some examples, user interface device 204 may be configured to provide output to a user using tactile, audio, or visual stimuli and receive input from the user via tactile, audio, or visual feedback. User interface device 204 may include, for example, a presence-sensitive display, a mouse, a keyboard, a voice response system, a 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 form understandable by humans or machines, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device for generating an understandable output to a user.

[0090] Application 220 may also include program instructions and / or data executable by the processing circuitry 202 of computing system 20 to cause computing system 20 to provide the functionality attributed to it herein. Example applications 220 may include monitoring system 22. Optionally or additionally, other additional applications (not shown) may be included to provide other functionality described herein and are not depicted for simplicity.

[0091] In accordance with the techniques of the present 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 communication circuitry 206. Processing circuitry 202 stores this data as data 230 in storage device 208.

[0092] Computing system 20 may also receive EMR data 230 from EMR database 22 ( Figure 1 ) via communication circuitry 206 and store EMR data 230 in storage device 208. For each of a plurality of patients or subjects, EMR data 230 may include, for example, a medication history, a surgical procedure history, a hospitalization history, an emergency or urgent care visit history, a scheduled clinic visit history, one or more laboratory or other clinical test results, a procedure history, a cardiovascular history, or comorbidities 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, radiographic images, and the like.

[0093] Monitoring system 222, implemented, for example, by the processing circuitry of computing system 20, may implement the techniques of the present disclosure, including developing an algorithm based on a training set of parameter data, such as IMD data 102 and sensor device data 104 (and in some cases, user-recorded health data 106 and EMR data 230) from a population of patients or subjects, and applying the algorithm to the parameter data of an individual patient 4 to predict the occurrence of a clinically significant health event. In some examples, monitoring system 222 trains one or more machine learning (ML) models 224 to predict health events. The output of the ML model for a particular patient may be a risk level of a health event, such as the probability of a health event, the risk level or probability that the health event will occur within a particular predetermined time period, and / or whether the risk or probability meets a threshold.

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

[0095] One or more of these features can be an AF burden pattern feature. The AF burden pattern feature can quantify the AF burden pattern over a plurality of cycles including the current cycle for which the monitoring system 222 is determining a risk level. An AF burden pattern that includes a change in AF relative to an overall AF burden trend (e.g., a spike or increase) may be associated with an increased risk of a health event such as a stroke or other clinically significant episode related to cardiovascular health. In some examples, the monitoring system 222 determines the AF burden pattern feature by comparing a current AF burden value to an average (e.g., mean or median) of previous AF burden values (e.g., determining the difference or ratio between them). The current value can be a single value for the current cycle that is a shorter-term average of values including the current cycle and a plurality of previous cycles. The average can be a longer-term average of previous values (e.g., including more values and / or values from further in the past) that does not include the current cycle value. In some examples, these features include patient activity features such as daily activity level, diurnal or nocturnal activity level, or a change in such activity level relative to a baseline or trend of activity level.

[0096] Generally speaking, a health event can be any clinically significant health event. In some examples, a health event can be a cardiovascular event. A health event can be a stroke. In some examples, a health event is a healthcare utilization event such as hospitalization. In some examples, a health event includes a symptomatic event such as a clinically significant syncope or dizziness.

[0097] The monitoring system 222 can initially train the ML model 224 using parameter data collected, for example, from one or more patient populations during a clinical study. In a conventional clinical study, one or more human experts review the parameter data and collect additional information to classify each training set into an endpoint such as including or not including a health event. In contrast, the monitoring system 222 can classify a training set of parameter data based on classification data 232 automatically collected in response to a triggered detection, which can reduce the cost or human overhead associated with a clinical study.

[0098] In some examples, the processing circuit 202 that executes the monitoring system 222 collects the classification data 232. In some examples, the classification data is additionally or alternatively collected by other processing circuits of system 2( Figure 1 ) such as the processing circuit 80 of the external device 12( Figure 4 ) and received by the computing system 20 from the other processing circuits. The classification data 232 includes data indicating the endpoint of the training set of parameter data, e.g., data indicating whether a patient has experienced a health event. The classification data 232 can include data from the health data 106, geofence data 108, and / or EMR data 230 of the user record that indicates the endpoint of the patient.

[0099] Any one or more of the IMD 10, the sensor device 14, the external device 12, or the computing system 20 may detect a trigger for collecting the classified data 232. In some examples, the trigger is, for example, a geofence event detected by the external device 12, which indicates that the patient has traveled to a hospital or a clinic for a threshold amount of time. In such examples, the external device 12 or the computing system 20 may present a survey to the patient to collect information about the visit (e.g., confirm the visit and about the health problems addressed), as the health data 106 and the classified data 230 of the user record.

[0100] In some examples, the trigger includes that the characteristics of the patient's parameter data meet a criterion, such as indicating that the patient may have experienced a health event. For example, the trigger can be that the AF load reaches or exceeds a threshold. Other example triggers may include that the characteristics of any physiological parameter described herein reach a threshold. In some examples, the trigger characteristics may be within the training set of the characteristics used to train the ML model 224, for example, the monitoring system 222 may select input characteristics therefrom based on their prediction values for health events. In response to the detection of the trigger characteristics, the monitoring system 222 or other processing circuits of the system 2 may collect the classified data 230. The collection of the classified data 232 may be via a survey as discussed above, or by examining the geofence data 108 and / or the EMR data 230 to identify the time of approaching a hospital or clinic visit indicating the occurrence of a health event.

[0101] After training the ML model 224, the monitoring system 222 may apply the ML model to the parameter data (e.g., the IMD data 102 and the sensor device data 104) of a specific patient (such as patient 4) to determine the risk level of the patient experiencing a health event. In some examples, the monitoring system 222 may determine whether the risk level of the health event meets a criterion, such as reaching or exceeding a threshold risk level. The monitoring system 222 may take one or more actions based on determining that the risk level meets the criterion, such as as described with respect to Figure 8 described.

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

[0103] Figure 6 is a flowchart that illustrates example techniques for training a machine learning model using a training set of parameter data classified based on automatically collected classification data. According to Figure 6 the example shown, the 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 the parameter data (302). The monitoring system 222 classifies the training set of the parameter data based on the automatically collected classification data, as discussed above with reference to Figure 5 (304). The monitoring system 222 uses the classified training set of the parameter data to train the ML model 224 (306).

[0104] Figure 7 is a flowchart that illustrates example techniques for automatically collecting classification data. According to Figure 7 the example of, the monitoring system 222 collects parameter data for a patient among a plurality of patients, for example, during a clinical study and an ML model training phase (400). As discussed above with respect to Figure 5 the monitoring system determines whether a trigger has occurred (402). As discussed above with respect to Figure 5 the example triggers include a feature in the parameter data meeting a criterion or a geofence event. A geofence event may be an event in which a patient stays within a geofence area (e.g., an area near or around a hospital, an urgent care clinic, and / or a healthcare provider) for more than a threshold time. A patient staying within a geofence area for more than a threshold hold time may be evidence of unplanned or planned healthcare utilization. Examples of features in the parameter data that meet the criterion include an AF load or other features derived from an ECG, such as a heart rate or heart rate variability that exceeds a threshold, and / or a patient activity feature that drops below a threshold. If the trigger has not occurred (the "no" of 402), then the monitoring system 222 may continue to receive the patient's parameter data and monitor for the trigger (400, 402).

[0105] If a trigger occurs ("yes" at 402), the monitoring system 222 collects classified data 232 (404). As discussed above with respect to Figure 5 the example classified data 232 may include health data 106 from user records of a survey delivered to the patient in response to the trigger, or geofence data 108 indicating that the patient has gone to a hospital or clinic and in some cases indicating a time proximity of the occurrence of a health event (in the case of a parameter data feature trigger) or EMR data 230. The monitoring system 222 associates the classified data 232 with the parameter data for the final classification of the training set of the parameter data (406).

[0106] Figure 8 is a flowchart illustrating an example technique for predicting a health event and responding to a prediction of a health event. As discussed above, example health events include strokes, hospitalizations, or other healthcare utilization, or symptomatic events such as symptomatic AF or other cardiovascular events.

[0107] According to Figure 8 the example shown, the monitoring system 222 receives parameter data of patient 4, such as IMD data 102 and sensor device data 104 (500). The monitoring system 222 applies features derived from the parameter data to the ML model 224 (502). As discussed above, these features may include AF features, such as an AF load pattern feature, and in some cases, patient activity features or other features derived from another physiological signal. The monitoring system 222 determines a risk level of a health event based on applying these features to the ML model 224. For example, the ML model 224 outputs a probability of a health event occurring within a predetermined time period (e.g., several days). The monitoring system 222 determines whether the risk level of the health event meets a criterion, such as whether it reaches or exceeds a threshold (504). If the risk level does not meet the criterion ("no" at 504), the monitoring system 222 continues to receive parameter data and applies features to the ML model 224, for example, on a per-cycle basis (500, 502). Based on the risk level meeting the criterion ("yes" at 504), the monitoring system 222 may perform Figure 8 one or more of the optional actions shown (506 to 512).

[0108] The monitoring system 222 may change the sensing behavior of system 2 (506). For example, the monitoring system 222 may direct the IMD 10 and / or the sensing device 104 to adopt a more sensitive setting for the sensing circuit 52 or the sensor 58, sample the physiological signal at a higher rate, and / or perform periodic measurements at a higher frequency.

[0109] As another example, the monitoring system 222 can provide guidance (508) to the patient 4 to take a medication or modify the medication taking. The medication can be an anticoagulant. The guidance can be to take an on-demand dose of the medication or to change the dose of the medication.

[0110] As another example, the monitoring system 222 can prioritize the patient 4 or a portion of the parameter data associated with the risk level of a health event in a notification to a clinician treating the patient 4 (810). The monitoring system 222 implementing the techniques of the present disclosure can advantageously reduce the load of treating the patient by prioritizing the patient and / or patient data in a notification from system 2 based on a risk level meeting a criterion indicating a clinically significant risk of a health event. In some examples, the monitoring system 222 reduces the load by determining which rhythms (e.g., presenting clinically relevant patient reports of adjudication symptoms) should be sent or alerted to the patient and / or clinician.

[0111] As another example, the monitoring system 222 can determine a classification of parameter data associated with the risk level of a health event and create a training set of parameter data for enhanced training of the ML model 224 for the patient 4 and / or personalization of the ML model 224, e.g., to create a patient-specific version of the ML model 224 (512). The monitoring system 222 can utilize any of the techniques described herein, e.g., with reference to Figure 7 the classification data 232 collected for classifying the training set of parameter data.

[0112] The health monitor 96 implemented by the processing circuitry 80 of the external device can implement portions of the techniques Figures 6 to 8 described. For example, the health monitor 96 can present surveys and collect answers from the patient 4, present guidance to the patient 4 to take a medication, and implement messaging between the patient 4 and the clinician.

[0113] In some examples, to enable real-time patient management, the health monitor 96 may follow a predefined protocol to automatically prompt patient actions based on a particular, detected pattern of parameter data. For example, the health monitor 96 may see an AF burden of a predefined clinical significance and recommend modifying the patient's anticoagulant medication. As discussed above, actions may alternatively or additionally be prompted based on meeting criteria of a risk level of a health event. In some examples, the computing system 20 may provide an interface for a clinician via a network interface or a user interface device 204 to specify parameter data characteristics or risk level criteria (e.g., an AF duration lasting more than 1 hour or a stroke probability exceeding a threshold probability) that will trigger a clinical action, and the clinical action the patient will need to take (e.g., increasing the dose of an anticoagulant medication). In some examples, the health monitor 96 may provide a PRN (as needed) medication request. In some examples, the health monitor 96 may have a communication tab and a priority status that will require confirmation of an action before allowing the patient 4 to proceed to other features of the health monitor 96, such as viewing the patient 4's parameter data).

[0114] Figure 9 is a graph of parameter data that illustrates multiple patient parameters over a period of time surrounding a stroke event (time 0). In Figure 9 the example illustrated, the patient parameters include patient activity parameters (activities of daily living, related to patient movement amount exceeding a threshold during the day), heart rate variability (HRV), nighttime heart rate, daytime heart rate, and AF time (or AF burden). As can be seen in the illustrated example, in the days leading up to a stroke, both AF time and heart rate-related parameters increase, while patient activity decreases.

[0115] Figure 10 is a graph of time series values of a moving average of parameter data that illustrates patient parameters. In Figure 10 the example illustrated, the patient parameter is activities of daily living, although similar techniques may be applied to any other patient parameters described herein. Figure 10 illustrates techniques for quantifying features related to a patient parameter deviating from its baseline or trend, which deviation may indicate an increased risk of a health event. In some examples, the monitoring system 222 summarizes trends with at least two simple moving averages (SMA) and uses the comparison or offset of the two SMAs to capture clinically significant changes in patient parameters. One SMA may be a shorter-term SMA, while the other is a longer-term SMA. For example, the longer-term SMA includes fewer recent values of patient parameters compared to the shorter-term SMA. Patient parameter values occurring within a predefined number of days of a health event (e.g., a stroke) may be identified. Under sample control, the case may be 1:1, and all offsets and covariates may be evaluated in one model. The monitoring system 22 may compare the goodness of fit of each variable (patient parameter) to determine the relative importance of the variable.

[0116] Figure 11 is a chart that exemplifies the statistically significant significance determined experimentally of multiple patient parameters in predicting stroke. Figure 11 The patient parameters in the example of are AF burden (AFB), daytime heart rate (DHR), activities of daily living (ADL), nighttime heart rate (NHR), and heart rate variability (HRV). Figure 11 The exemplified statistical significance is determined based on parameter data collected from multiple patients including those with stroke. As Figure 11 exemplified, it was found that AF burden is a significantly better predictor of stroke than other patient parameters.

[0117] Experimental analysis shows that changes in AF burden occur within a long-term trend (21+ days) before a stroke event. In the long term, AF burden can be considered the main predictor. More specifically, the short-term trend of AF burden increases within the long-term trend, which may indicate a stroke. When acute, short-term changes are compared with the long-term trend, the predictive ability of AF burden may be 4 times higher.

[0118] Figure 12 is another chart that exemplifies the statistically significant significance determined experimentally of multiple patient parameters in predicting stroke. Figure 12 Similar to Figure 11 , but includes additional patient parameters. Specifically, Figure 12 includes AF history, CHADS-VASc score, prior oral anticoagulant (prior_oac), and history of chronic kidney disease. Although Figure 12 exemplifies that prior stroke is 13 times more important as a predictor of stroke than AF burden, AF burden is the main predictor after CHADS-VASc.

[0119] Figures 13A to 13D is a chart that exemplifies the statistically significant significance determined experimentally of multiple patient parameters in predicting stroke in different patient groups. Figure 13A Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior AF ablation. Figure 13B Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior AF management. Figure 13C Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior stroke. Figure 13D Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients in whom AF is suspected but not confirmed.

[0120] Figures 14A to 14DIt is a chart that exemplifies the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization (a subset of healthcare utilization) in different patient populations. Figure 14A Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior AF ablation. Figure 14B Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior AF management. Figure 14C Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients with prior stroke. Figure 14D Exemplifies the statistical significance of multiple patient parameters in predicting stroke in patients in whom AF is suspected but not confirmed.

[0121] Figure 15 It is a chart that exemplifies the analysis of AF burden pattern features for predicting stroke and healthcare utilization (HCU). This analysis shows that for both stroke and HCU, a surge in AF burden (accompanied in some cases by a lower patient activity level) predicts events occurring within a certain time frame.

[0122] Figure 16A and Figure 16B are diagrams that respectively exemplify the AF burden patterns of patients who experienced a stroke or a healthcare utilization event for different patient populations. AF burden patterns (such as Figure 16A and Figure 16B those shown) signal subclinical changes indicating elevated cycles of stroke and HCU risk.

[0123] A retrospective cohort study (including Reveal LINQ TM ICM) was conducted on ICM patients to determine whether rule-based algorithms can be used to stratify the risk of short-term HCU, which examine changes in baseline ICM parameters. The occurrence of HCU as the study endpoint was obtained from unrecognized claim data. A patient was marked as having an HCU if the patient's claim history included at least one encounter with a cardiovascular DRG or diagnostic code in an inpatient or outpatient hospital, emergency department, or outpatient surgery center. If a patient used HCU multiple times, the first occurrence of HCU was recorded.

[0124] The ICM-based diagnostic parameters evaluated in the study included total daily AT / AF burden (milliseconds / day), total patient activity (e.g., time of patient supra-threshold movement (minutes / day)), mean ventricular rate (night and day), and HRV. Patients with less than 21 days of daily follow-up after implantation or a follow-up interval greater than or equal to 30 days were excluded from the cohort. Missing data due to daily follow-up intervals were interpolated by forward-filling the last known value of each diagnostic parameter. The follow-up history was limited to two years, unless there was an HCU, in which case the follow-up ended on the day before the event. Patients with no AT / AF time detected by any device during the two-year follow-up period were excluded from the cohort.

[0125] To define the diagnostic time patterns of the study, at each patient follow-up date, each parameter was evaluated as a cumulative moving average (CMA) starting from the second day after implantation, and as a simple moving average (SMA) over different historical periods (1 day, 2 days, 3 days, 5 days, 8 days, 13 days, and 21 days) starting from 21 days after implantation. For this study, the offset SMA a b denotes the difference between the SMA a and the SMA b where the shorter-period SMA is subtracted from the longer-period SMA (i.e., a < b). The offset of a period p from its corresponding CMA is denoted as SMA p_c .

[0126] Figure 17 is a graph illustrating the AT / AF time (burden) detected during the monitoring period. The vertical lines illustrate the AF burden (AT / AF time) of the sub-periods (days in this example) during which the patient experienced AT / AF. Figure 17 The graph of also includes three trend lines, illustrating respectively the CMA 600 of the AF burden, the 21-day SMA 602 of the AF burden, and the difference 604 between the 21-day SMA and the CMA of the AF burden.

[0127] For this study, the occurrence of HCU was considered an imbalanced, binary classification problem. The recursive partitioning and regression tree algorithm (RPART) was used to predict which follow-up days HCU occurred using the diagnostic parameters and moving average offsets as predictors. A random sampling method for imbalanced learning was used within the bootstrap routine to facilitate algorithm convergence and improve the accuracy of the classifier. The HCU events were oversampled by marking the five days before occurrence as events. For patients who experienced HCU, the follow-up ended on the day before the event to prevent using device measurements taken on the day of the event, which would introduce look-ahead bias in the modeling. For each bootstrap iteration:

[0128] 1. The patients were randomly divided into a training set (70%) and a validation set (30%).

[0129] 2. For the training set, the number of days sampled for the unlabeled is insufficient and equal to the number of days labeled.

[0130] 3. Classification trees using 10-fold cross-validation are suitable for balancing the training set.

[0131] 4. Prune the model fit in step 3 to its minimum cross-validation error.

[0132] 5. The split information of the model fit in step 4 is saved.

[0133] 6. Classify the unbalanced validation set using the model fit in step 4.

[0134] 7. Save the classification statistics for each terminal node in step 6.

[0135] Each split of a terminal node is recorded as a 3-tuple [predictor name, comparison, index] along with its corresponding HCU rate and patient count for both the training set and the validation set. If a node has multiple splits, each split is saved as a separate entry. In this case, the utilization and patient count will be the same for all splits within each node.

[0136] A scatter plot of the decision tree terminal nodes shows the relationship between the labeled HCU rate and the patient percentage, used to identify patterns in the AF load classification tree structure that will stratify the risk of healthcare events. The algorithm for defining these patterns is:

[0137] 1. Visually identify the region of local maximum of the patient percentage in the scatter plot.

[0138] 2. If the region is unique for the AT / AF time, define the rectangular coordinates of the event risk and patient percentage enclosing the region.

[0139] 3. If the region is not unique for the AT / AF time, then

[0140] i. Set the upper and lower limits of the patient percentage to be equal to the local maximum

[0141] ii. Subtract 0.01 from the lower limit of the patient percentage.

[0142] iii. Set the lower and upper limits of the event rate to the corresponding positions where the scatter plot intersects the lower limit of the patient percentage defined in the previous step.

[0143] 4. Select the nodes within the rectangular region.

[0144] 5. Group by the pair [predictor name, comparison].

[0145] 6. Calculate the number of times each pair is selected, the number of times each pair is selected as a percentage of all the bootstrapped classification trees, and the mean of the [exponent] values.

[0146] 7. If the region is not unique for the AT / AF time, repeat steps 3.ii - 6 until the modal predictors are selected in at least 10% of all the classification trees.

[0147] 8. Sort the triples [predictor, comparison, mean exponent value] in descending order of the selection rate.

[0148] 9. Identify the elbow in the selection rate (i.e., the location where the selection rate drops by approximately 50%).

[0149] 10. Define the AF load pattern as the triples with a selection rate higher than the elbow point identified in the previous step.

[0150] Perform isometric descriptive analysis and testing to compare the odds ratio of the AF load pattern with clinically relevant thresholds for duration and quantity.

[0151] The bootstrap routine runs 3,000 times to create an equal number of classification trees. Figure 18 A scatter plot of the HCU rate and patient percentage for 50751 terminal nodes labeled according to the balanced training data is presented. The points on the graph represent unique terminal nodes. When the definition of a single node includes multiple splits and each split has different parameters (e.g., AT / AF time > 1 hour and daily activity < 100 minutes and nocturnal heart rate > 80 beats per minute), a single node can be represented across diagnostic parameters. Identify three local maxima and denote them as shaded regions A, B, and C. The absence (A and C) or infrequency (B) of the daily activity and heart rate parameters in the nodes indicates that these regions are mainly defined by the AT / AF time. Region D is derived from the analysis of regions A, B, and C and is defined later in the results.

[0152] Table 2: Top splits of the distribution of each terminal node for training data

[0153]

[0154]

[0155] Table 2 (above) presents a summary of the first five splits by region. Splits with selection rates higher than their corresponding elbow points are shown in bold. These highlighted splits together define the AF load pattern for a given region. Pattern A is defined by an AF load CMA of less than about 1 second. This pattern is present in all 3,000 decision trees and describes the follow-up period before the first detection of AT / AF (77% incidence) and the relative sinus rhythm recovery period after the device detects AT / AF (23% incidence). Pattern C is defined by an AF load CMA of greater than about 1 second and an AF load of a 21-day SMA that is approximately greater than its historical mean. This pattern is present in 25% of the decision trees and describes a relative spike or increasing trend in the daily AF load. Pattern B is defined by an AF load CMA of greater than about 1 second, but unlike Pattern C, it has a decreasing 21-day SMA of AF load that is less than its historical mean. An increase in the 1-day SMA (daily load) relative to the 21-day SMA indicates that Pattern C signals a period of sporadicity relative to the patient's below-average load, which can occur after a period of elevated load. Figure 19 An example graphical illustration of these patterns in the AF load data mapped for an individual HCU patient is presented.

[0156] The labeled HCU rates and patient percentages are calculated from the training data based on AF load quantity and duration thresholds. The quantity threshold is defined as a daily AF load greater than 5% (72 minutes); the duration threshold is defined as continuous AF greater than one hour. For the corresponding thresholds, the log-odds event rates are 0.369 and 0.386, respectively, and the patient percentages are 12.9% and 7.6%, respectively. Table 2, Region D presents a summary of the first five splits in the terminal node scatter plot where the log-odds event rate is greater than 0.369 and the patient percentage is greater than 12.9%. The first three splits define a partial substructure of Pattern C where the CMA of daily activity drops below 76 minutes. When applied to a balanced training set, Pattern D was selected 10.4% of the time with a log-odds ratio of 0.368, a value that was not statistically different from the other log-odds ratios (Poisson regression, p > 0.5 for all threshold coefficients).

[0157] Figure 20 A scatter plot of the terminal nodes scored by the labeled HCU rates and patient percentages from an unbalanced validation set is presented. The overall distribution is similar in shape to the training data ( Figure 18)。 Different color shadings indicate different threshold patterns, where the lightest shaded points represent nodes not covered by the pattern. The AF burden patterns (A - C) provide a broad coverage of the terminal node distribution, with a clear division of the 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). The inclusion of the daily activity threshold (D) provides a more specific coverage, with the highest risk of HCU in the AF burden pattern (D vs A, OR 11.66, 95% CI 10.63 - 12.79).

[0158] Figure 21 A Venn diagram of the AF burden threshold counts in the validation set is presented. Table 3 (below) gives the statistics for each threshold and its mutually exclusive subsets. Approximately 32% (6,594 / 20,858) of the pattern D threshold is mutually exclusive with the quantity and duration thresholds, and represents a 33% increase in the event capture rate (212 / 644). Tests of the difference in odds ratios using Poisson regression showed that the intersection coefficient for all three thresholds was statistically significant (p < 0.10); the remaining coefficients were not statistically different (for all coefficients, p > 0.10). Approximately 23% of patients experienced only the pattern D threshold, with an expected follow - up rate of 18.2%, or 66 days per year.

[0159] Table 3: AF load threshold statistics for validation data

[0160]

[0161] In Table 3, the count represents the number of times the threshold was met; the event, the number of labeled HCUs; the odds, the ratio of the event count to the threshold count divided by the group mean event rate in the validation set; the patient, the percentage of patients in the validation set who reached the threshold at least one day; the follow - up, the percentage of the total follow - up days that the days at the threshold represent for patients who had the threshold occur at least once. Note: The count for each follow - up day is mutually exclusive, not by patient. A patient may experience different thresholds during the follow - up period. Therefore, the sum of the patient and follow - up percentages does not reach 100%.

[0162] Analysis of the AF burden patterns in the study confirmed the correlation between increasing burden and risk, and more specifically, the trend of increasing AF burden (e.g., daily) over time is associated with a greater risk of HCU, particularly when accompanied by a decline in daily activity. Patterns with an AF burden of less than about 1 hour predict healthcare events comparable to those of the quantity and duration thresholds greater than 1 hour. The AF burden patterns demonstrate additional event capture that complements the quantity and duration thresholds. AF burden as a risk factor for HCU is related to the patient's historical burden.

[0163] The study represents values of AF burden and patient activity as parameter 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 the AF burden can include AF burden pattern features such as a change in the AF burden relative to the total AF burden trend (e.g., a spike or an increase). For example, an AF burden pattern feature can include one or more offsets between SMAs for different lookback periods and / or between an SMA and a CMA for a lookback period. As described herein, a model that applies such features can be machine learning-based or rule-based, e.g., involving decision trees and / or thresholds.

[0164] According to the techniques described herein, a medical system can include an ICM or other IMD configured to continuously (e.g., autonomously without interruption according to programming that can include periodic and / or triggered actions) monitor an ECG signal to detect AF and determine an AF burden, and determine the risk of a health event such as a stroke based on the AF burden (e.g., a temporal AF burden pattern).

[0165] Machine learning techniques (undersampling / oversampling, bootstrapping, classification trees) were used in a study to evaluate the importance of AF burden features for predicting the daily ischemic stroke risk in patients from a large retrospective cohort with ICMs. The study linked ICM data to administrative claims data including patient characteristics and clinical outcomes to examine the temporal pattern of AF and its association with stroke. Patients included in the study had an ICM with a corresponding device implantation indication for (1) AF management, (2) clinical concern for suspected AF, or (3) occurrence of cryptogenic stroke. Patients confirmed to have AF had an AF management indication for implanting their ICM to further monitor AF. Other patients may not have a confirmed AF, e.g., AF was not observed during an outpatient or Holter monitoring, but may have had an ICM implanted to monitor AF. Indications for such patients included clinical concern for suspected AF (where the clinician had reason to suspect AF) and cryptogenic stroke (where the patient had a stroke of unknown cause such that AF could not be excluded). As used herein, AF burden can refer to a measure of time in AF or time in AF and / or atrial tachycardia (AT) (e.g., AT / AF), and can also be referred to as atrial tachyarrhythmia burden.

[0166] Figure 22 Illustrates the design of the study. Based on the patient's claims history prior to the implant date, the patient's CHA2DS2-VASc score and other parameters were calculated. As Figure 22 Illustrated, a nominal index date was designated 21 days after ICM implant to initialize the time series of each ICM detection parameter.

[0167] The occurrence of post-implantation ischemic stroke was also determined based on claim data. In cases of multiple strokes in an individual, the first occurrence was recorded as the primary outcome. If a patient's stroke date occurred within 28 days of a previous hospitalization, that patient was excluded from the cohort to avoid confounding with a zero activity level due to hospitalization.

[0168] Device parameters for the primary ICM detections of interest included the daily total atrial tachycardia / atrial fibrillation (AT / AF) burden (hours / day), total patient activity (minutes / day), mean ventricular rate (bpm) measured from midnight to 4:00 AM ("night") and from 8:00 AM to 8:00 PM ("day"), and heart rate variability (measured as the standard deviation of the 5-minute RR median over a 24-hour period). The minimum detection required to register an AT / AF event was 2 minutes. To avoid bias from missed AT / AF events, patients with less than 21 days of daily follow-up or a follow-up interval greater than or equal to 30 days after implantation were excluded from the cohort. Missing data due to daily follow-up intervals were interpolated by forward-filling the last known value of each device parameter. Follow-up was limited to two years.

[0169] To incorporate diagnostic time patterns, each device parameter was evaluated as a cumulative moving average (CMA) starting from the day after implantation, and as simple moving averages (SMA) over different historical periods (1 day, 2 days, 3 days, 5 days, 8 days, 13 days, and 21 days) starting from 21 days after implantation. For a device parameter d at time t:

[0170]

[0171] where t represents the number of days after implantation, and p represents the SMA period.

[0172] Each moving average was compared to the other moving averages to produce a unique combination of 28 offset variables for each device parameter. Figure 23A and Figure 23B is a diagram showing plots of the 21-day SMA of the daily AT / AF burden and the CMA of the daily AT / AF burden over several days. A relative risk episode occurs when the SMA is higher than the CMA, the relative risk episode remains elevated when the SMA is greater than the CMA, and the relative risk episode ends when the SMA is lower than the CMA. This pattern is sensitive to a relative increase in the daily AT / AF burden ( Figure 23A ) as well as an increasing burden over a longer period ( Figure 23B ). The patients whose data are illustrated in Figure 23A and Figure 23B all experienced ischemic stroke on the last day of the indicated follow-up.

[0173] The processing circuitry of a medical system can use multiple novel features of a diagnostic timing pattern of an AF load (e.g., an AT / AF load) defined as an offset of two moving averages to determine the risk of a stroke or another health event. One example feature is a sharp change in AF, e.g., as Figure 23A illustrated by the example of Figure 23A when one moving average crosses the other. Figure 23B Figure 23B illustrates multiple instances where the SMA exceeds the CMA and identifies the period during which the SMA remains above the CMA in a "pattern". Another example feature is a persistent trend, e.g., as Figure 23B illustrated by the example of

[0174] Figure 24 when one moving average remains greater than the other. In a a , the SMA remains greater than the CMA over an extended period of time. The offset (e.g., the duration of the SMA) selected by model fitting training can provide insight into the temporal relationship between AF and stroke risk. Advantageously, the comparison of the moving averages describes the relative change in the daily AF load that may not be explained by traditional AF load risk thresholds. b a minus b a a minus b b a minus b

[0175] For the bootstrap method used for decision tree classification, a case-control design was used at the follow-up period level, allowing for case-crossover of ischemic stroke patients. The dependent variable (follow-up period of stroke) was compared to all other follow-up periods of the patient cases and control groups, resulting in an extremely rare event rate of 0.036%. To balance the data, ischemic stroke events were oversampled by flagging the five days prior to occurrence. Then, control follow-ups were randomly undersampled to match the number of oversampled follow-up cases. For patients who had experienced an ischemic stroke, the follow-up ended one day prior to the event to prevent the use of device measurements taken on the same day as the stroke event, which would introduce prospective bias in the modeling. In this way, the model was configured to predetermine the risk of stroke, e.g., five days in advance, using a random sample of all flagged follow-up cases and follow-up control groups.

[0176] Using baseline characteristics, CHA2DS2-VASc score, device parameters, and shift in the moving average (SMA a minus SMA b ) as predictors, the recursive partitioning and regression tree algorithm (RPART) was used to predict ischemic stroke on those follow-up days. Although oversampling / undersampling methods are well-proven for managing imbalanced data, including the prediction of incident AF, we recognized oversampling bias in our design and used a bootstrap routine with 1,000 repetitions to remove this bias and improve classifier accuracy. For each bootstrap iteration:

[0177] 1. Patients were randomly divided into a training set (70%) and a validation set (30%).

[0178] 2. The follow-up control group was randomly sampled without replacement up to the number of follow-up cases, resulting in a balanced training set.

[0179] 3. An exhaustive classification tree with a minimum terminal node size of 80, a maximum depth of 8, and a complexity parameter of 0 was fit to the balanced training set.

[0180] 4. 10-fold cross-validation was used to calculate the misclassification rate for each subtree in step 3. The exhaustive tree was then pruned back to the subtree with the lowest misclassification rate.

[0181] 5. The variable importance and split information from the model fit in step 4 were saved.

[0182] 6. The imbalanced validation set was classified using the model fit from step 4.

[0183] 7. The area under the curve (AUC) and classification statistics from step 6 were saved.

[0184] Among the 5,013 patients who met the inclusion criteria of the study, 2,871 (57.3%) patients had device-detected AF, 869 (17.3%) patients experienced an ischemic stroke, 276 (5.5%) patients who experienced a stroke had device-detected AF, and 593 (11.8%) patients who experienced a stroke did not have device-detected AF. The mean AF burden was 56 minutes (25th percentile, 75th percentile; 8 minutes, 534 minutes).

[0185] Patients who experienced an ischemic stroke had a higher mean CHA2DS2-VASc score (4.3 ± 1.9 vs. 3.5 ± 1.9, p < 0.001), and were more often affected by chronic kidney disease (20% vs. 16%, p < 0.001). Patients with an ischemic stroke more frequently had higher rates of previous stroke / TIA, hypertension, and diabetes. Patients with an ischemic stroke were less likely to have a previous diagnosis of AF (27% vs. 48%, p < 0.001), less likely to be on oral anticoagulants (18% vs. 29%, p < 0.001), and more likely to have their device implanted for monitoring after a cryptogenic stroke (81% vs. 36%, p < 0.001).

[0186] There were a total of 2,409,437 patient follow-up days, with an average follow-up of 150 days ± 166 days for patients with an ischemic stroke event and 550 days ± 199 days for patients without an ischemic stroke event. The number of patients with a follow-up interval was 1,016 (20%); the average interval size was 7.3 days ± 6.9 days. Patients with an ischemic stroke were less likely to have an interval during follow-up (6% vs. 23%, p < 0.001), and among ischemic stroke patients with an interval, their average interval size was shorter than that of patients without an ischemic stroke (5.6 days vs. 7.3 days, p < 0.001).

[0187] Figure 25 is a convergence curve graph showing the mean importance of each variable in the cross-validation iterative analysis. For ease of presentation, the device parameters show the overall or average variable importance across all their corresponding features. The points on the graph indicate when a feature was selected as a predictor by the classification algorithm; features that are frequently selected will have a greater point density. The convergence of the points to the line indicates how many cross-validations are needed to reliably estimate the variable importance of a given feature. 1,000 cross-validations are considered sufficient for a reliable estimate of the variable importance across features. AFB indicates AF burden; DA, daily activity; DHR, daytime heart rate; NHR, nighttime heart rate; HRV, heart rate variability; OAC, oral anticoagulants.

[0188] As Figure 25As shown, prior stroke / TIA, no history of AF, and device parameters were the most frequently selected predictors, accounting for more than 98% of all selections. All features other than ablation, sleep apnea, and valvular heart disease reached convergence within 1,000 iterations. Given the low variable importance and selection frequency of these three variables, 1,000 bootstraps were considered sufficient for the analysis.

[0189] Figure 26 It is a bar graph of the mean variable importance scaled as a percentage of the total variable importance and the pattern decoding association of each feature with stroke risk in the analysis. For ease of presentation, device parameters show the overall variable importance across all their corresponding features. The inset presents the top 30 individual features after stroke / TIA and history of atrial fibrillation, which were selected as predictors. AFB indicates AF burden; DA, daily activity; DHR, daytime heart rate; NHR, nighttime heart rate; HRV, heart rate variability; CMA, cumulative moving average; OAC, oral anticoagulant. All patterns are defined as p-day SMA offsets by their CMA.

[0190] As Figure 26 illustrated, prior stroke / TIA (13.13) was the first predictor of future stroke, followed by prior diagnosis without AF (7.35). The presence of AF at device implantation was partially correlated with prior stroke (Pearson, ρ = -0.18, p < 0.001), as a function of device indication; when controlling for the device indication for cryptogenic stroke, there was no significant correlation between prior diagnosis without AF and prior stroke (Pearson partial correlation, ρ = -0.02, p < 0.001). The next best predictor was the AF burden pattern (2.59).

[0191] Figure 26The illustrations in [study] present the top 30 individual characteristics after stroke / TIA and atrial fibrillation, which were selected as predictors. All temporal patterns in this group were defined as the p-day SMA offset of their CMA. Seven of the top 10 characteristics describe patterns of increasing AF burden duration without any clear preference for the time period of the trend. On the other hand, the next best set of characteristics (heart rate and daily activity parameters) shows patterns of increasing trends with preference for longer time periods (≥13 days). The cumulative mean of the daily AF burden (AFB CMA) is also one of the top 10 predictors and is negatively associated with stroke risk. To test this association, the maximum AF burden during follow-up was included in a principal component analysis together with demographic, baseline, and stroke event covariates. Prior diagnosis of AF (0.72), maximum AF burden (0.69), prior OAC use (0.63), prior stroke (-0.46), and future ischemic stroke (-0.45) were found to be the second component among four components, with 28% of the explained variance. Patients with more severe AF were more likely to have received OAC treatment before device implantation and less likely to experience future stroke. Thus, patients with a maximum AF burden of less than one hour during follow-up had a much higher stroke rate (23.2% vs. 7.3%, p<0.001) than control patients with a maximum AF burden of one hour or more at follow-up.

[0192] Figure 27 Including bar charts illustrating the mean variable importance scaled as a percentage of the total variable importance for characteristics selected as predictors at least 5% of the time and the pattern decoding association with stroke risk stratified by device indication. AFB indicates AF burden; DA, daily activity; DHR, daytime heart rate; NHR, nighttime heart rate; HRV, heart rate variability; CMA, cumulative moving average; OAC, oral anticoagulant. All temporal patterns were defined as the p-day SMA offset of their CMA.

[0193] Using the above techniques, the characteristics illustrated were selected as predictors at least 5% of the time. Figure 27 The patterns of prior history of stroke / TIA and increasing AF burden in elderly patients with lower levels of activity detected by ICM were most closely associated with stroke in those patients who received their ICM for AF management or were suspected of having AF. In patients with cryptogenic stroke, changes in heart rate and patterns of increasing activity detected by ICM and AF burden in younger patients were most likely to predict subsequent stroke.

[0194] Figure 28 Bar charts illustrating the temporal relationship between AT / AF burden and ischemic stroke risk differing by device indication. Figure 28Shows the percentage of time that AF burden increase is a positive predictor of stroke, arranged by device indication and cycle of AF burden time patterns. As Figure 28 illustrated, shorter risk durations (1 day to 5 days) more frequently and better predict AF management indications than longer durations, while longer risk durations (21 days) more frequently predict cryptogenic stroke than shorter durations. Although as Figure 26 and Figure 27 's inset illustrates, the 21-day simple moving average (offset by its cumulative moving average) is the most robust time pattern across device indications, but its selection frequency as a predictor varies by indication, being 94% for the time incidence of cryptogenic stroke and 11% for the time incidence of AF management.

[0195] Figure 29 Is a bar chart of the mean variable importance scaled as a percentage of the total variable importance according to the CHA2DS2-VASc score and all remaining features in the analysis. For ease of presentation, device parameters show the overall variable importance across all their corresponding features. The inset presents the top 30 individual features after the CHA2DS2-VASc score, which were selected as predictors at least 5% of the time. AFB indicates AF burden; DA, daily activity; DHR, daytime heart rate; NHR, nighttime heart rate; HRV, heart rate variability; CMA, cumulative moving average; OAC, oral anticoagulant. All time patterns are defined as p-day SMA offset by their CMA.

[0196] As Figure 29 illustrated, the CHA2DS2-VASc score (7.23) is the first predictor of future stroke, followed by the absence of a previous AF diagnosis (6.14) and the AF burden increase pattern (2.85). Previous stroke / TIA accounts for 64.0% of the CHA2DS2-VASc variable importance, followed by age (23.8%) and diabetes (4.3%). Figure 29 's inset presents the top 30 individual features after the CHA2DS2-VASc score and atrial fibrillation, which were selected as predictors at least 5% of the time. The AF burden pattern represents 7 of the top 10 predictors. However, the cycle priority rankings are different, where cycles 2 days to 21 days have similar variable importance (3.72 to 4.15). Additionally, after controlling for the CHA2DS2-VASc score, the decline in daily activity level ranks higher. In summary, within the CHA2DS2-VASc score and after previous stroke / TIA, age, and diabetes, this data chart more closely resembles the AF management and suspected AF variable importance data charts.

[0197] Figure 30Is an error bar graph showing the mean AUC and 95% confidence intervals of 1,000 bootstrapped, retained validation samples from twelve different model structures. Device values indicate raw device parameter data for AT / AF burden, patient activity, daytime heart rate, nighttime heart rate, and heart rate variability; device mode indicates the temporal mode of the device parameter data; CHA2DS2-Vasc, the eponymous score assessed via claims based on the patient's clinical history prior to device implantation; baseline characteristics, all co-morbidities assessed via claims based on the patient's clinical history prior to device implantation. Model 6a adds its corresponding features to the aforementioned model structure; Model 6b is the same model structure as Model 6a and is fit to a subset of patients identified as having an AT / AF burden greater than zero on at least one day during follow-up.

[0198] The area under the receiver operating characteristic curve (AUC) is used to evaluate how well different models can predict the occurrence of ischemic stroke within five days after follow-up. Figure 30 The error bar graph means the mean AUC performance of twelve different models. The ranked AUC values show five different groupings: Models 1a to 1e: traditional AF burden thresholds; Model 2: raw device parameter values for daily activity, time in AT / AF, daytime heart rate, nighttime heart rate, and heart rate variability; Models 3 to 6: CHA2DS2-VASc score, device temporal mode, and their corresponding raw parameter values, and baseline characteristics; Model 6a: baseline characteristics and device temporal mode; Model 6b: baseline characteristics and device temporal mode for patients with device-detected AF on at least one day during follow-up. The variation in the validation statistics for each model and grouping is shown in Table 4 below.

[0199]

[0200] Table 4: Discrimination and accuracy of prediction models

[0201] Statistical calculations were the corresponding mean or standard deviation for 1,000 bootstrapped, retained validation samples. The baseline event probability was 0.0018. AUC indicates the area under the receiver operating characteristic curve; P-value, the bootstrapped probability of testing the null hypothesis of equal mean AUC values for the continuous model; Sens, sensitivity; Spec, specificity; PPV, positive predictive value; NPV, negative predictive value; RR, relative risk defined as PPV / (1-NPV). Device values indicate the raw device parameter data for AT / AF burden, patient activity, daytime heart rate, nighttime heart rate, and heart rate variability. CHA2DS2-Vasc indicates the eponymous score of the patient's clinical history prior to device implantation as evaluated via claims. Device mode indicates the temporal mode of the device parameter data. Baseline characteristics indicate all comorbidities of the patient's clinical history prior to device implantation as evaluated via claims. Model 6a added its corresponding features to the aforementioned model structure. Model 6b was the same model structure as Model 6a and was fit to a subset of patients identified as having an AT / AF burden greater than zero on at least one day during follow-up.

[0202] Comparison of AUC between the models demonstrated three results. First, lower levels of AF burden had greater discriminatory ability than higher levels. Second, while device parameter values had greater discriminatory ability than traditional thresholds (0.557 vs 0.520, p<0.001), they did not provide additional discriminatory ability to the device temporal mode (0.616 vs 0.617, p = 0.655). And third, baseline characteristics (AUC 0.687) had greater discriminatory ability than any of the device-based characteristics (including traditional AF burden thresholds). However, when patient characteristics were combined with the device temporal mode, particularly for patients with device-detected AT / AF, there was an improvement in the model's AUC, specificity, and relative risk improvement (AUC 0.694 to 0.726, depending on the combination).

[0203] Figure 31 Is a graph illustrating the AT / AF burden data for a random sample of 16 patients with CHA2DS2-VASc score >3 and occurrence of ischemic stroke. The X-axis represents the number of follow-up days from the day after device implantation until the day before the stroke event. The risk indicated by the horizontal line is signaled after a relative increase in AT / AF burden and is turned off / on by the daily AT / AF burden 21-day simple moving average crossing below / above its cumulative moving average. Correct classification is shown when any of the last five follow-up days are signaled as having risk.

[0204] This analysis showed that adding AF diagnostic trends to baseline patient characteristics improved discrimination, reliability, and specificity for predicting ischemic stroke. In a cohort of 5,013 patients with data from ICM related to patient characteristics and outcomes, recursive partitioning and regression were used to identify factors associated with the occurrence of ischemic stroke. There were several important findings in this analysis. First, the daily AT / AF burden threshold, while sensitive to the occurrence of stroke, was not specific. Second, baseline patient characteristics were superior to the standard approach of CHA2DS2-VASc score and its weighted risk factors. Third, the combination of baseline characteristics and device-detected AF resulted in the best discrimination, with an AUC of 0.726. Finally, the optimal window for predicting future stroke AT / AF events varied according to treatment indication.

[0205] Patients with AF are at increased risk of cardiovascular events, including increased risk of hospitalization, new-onset heart failure, and ischemic events, including stroke and systemic embolism. Accurate prediction of these events is important for prevention strategies and personalized care. Predicting cardiovascular events in patients with AF has been challenging, especially predicting stroke, because competing mechanisms may be present in patients with multiple vascular risk factors.

[0206] Continuous monitoring data from ICM provided the possibility to evaluate the relationship between temporal patterns and AF burden and the occurrence of stroke. Using recursive partitioning and regression to identify factors associated with the occurrence of ischemic stroke demonstrated that the daily AT / AF burden threshold, while sensitive to the occurrence of stroke, was not specific. Although different durations of AF can be used as useful markers and thresholds in screening efforts, they have significant drawbacks for accurate prediction of individual stroke occurrence. In this analysis, AF temporal patterns were more closely associated with stroke. In the AF burden pattern, the pattern with the highest mean variable importance after a history of stroke or TIA was the simple moving average of AF burden offset by a cumulative moving average at 2, 3, 5, 8, 13, or 21 days. It was noted that the evaluation of oral anticoagulant use in this analysis reduced the incidence of stroke in individuals characterized as being at high stroke risk, thus providing the optimistic result that targeted application of oral anticoagulants using these moving averages could be used to guide personalized intervention strategies, such as the pocket pill approach for intermittent oral anticoagulants; however, key randomized trials are still needed in the future.

[0207] Notably, in different populations implanted with ICMs, the performance of individual AF measurements exhibits different risk predictions. The temporal relationship between AF burden and the risk of ischemic stroke also varies by device indication. In patients with known AF, AF burden patterns over shorter cycles (1 - 5 days) are more often prioritized over longer cycles. In contrast, in patients with cryptogenic stroke, longer cycles (21 days) are more often prioritized over shorter cycle AF burden patterns. This difference may be due to the higher cumulative AF burden in patients with known or established AF. Patients with less AF may require a "wider lens" for observation compared to those with a higher degree of AF, where a more focused window provides more information. It is important to emphasize that the 21 - day simple moving average (offset from its cumulative moving average) is the most robust temporal pattern across device indications.

[0208] Despite continuous rhythm monitoring data, clinical risk factors also achieve optimal discrimination of future stroke. The CHA2DS2 - VASc score alone has an AUC of 0.588, compared to an AUC of 0.503 to 0.520 for AF burden and an AUC of 0.557 for raw device parameter values. However, the combination of baseline characteristics and the mean change in AF above device detection results in optimal discrimination, with an AUC of 0.726. These results suggest that atrial arrhythmias and device data analysis can be combined with traditional risk factors for stroke risk prediction. The results of these analyses suggest that using CHA2DS2 - VASc where the 21 - day average of a patient's AF burden tracked is higher than its historical average would represent a significant improvement over standard risk estimates.

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

[0210] Example 1. A system, the system includes a processing circuit, the processing circuit is configured to: receive parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices, and wherein the plurality of parameters includes an AF load; derive one or more features based on the parameter data of the plurality of parameters, wherein the one or more features includes at least one AF load pattern feature; apply the one or more features to a model; and determine a risk level of a health event of the patient based on applying the one or more features to the model.

[0211] Example 2. The system according to Example 1, wherein the AF load pattern feature includes a comparison between a current AF load value and an average value of AF load values.

[0212] Example 3. The system according to Example 2, wherein the current AF load value includes a shorter-term average value of AF load values, and the average value of AF load values includes a longer-term average value of AF load values.

[0213] Example 4. The system according to any one of Examples 1 to 3, wherein the one or more features includes a patient activity feature.

[0214] Example 5. The system according to any one of Examples 1 to 4, wherein the health event includes a stroke.

[0215] Example 6. The system according to any one of Examples 1 to 4, wherein the health event includes a healthcare utilization event.

[0216] Example 7. The system according to any one of Examples 1 to 4, wherein the health event includes a symptomatic event.

[0217] Example 8. The system according to any one of Examples 1 to 7, wherein in order to determine the risk level of the health event, the processing circuit is configured to determine a probability of occurrence of the health event.

[0218] Example 9. The system according to any one of Examples 1 to 8, wherein the risk level includes a risk that the health event will occur within a predetermined time period.

[0219] Example 10. The system according to any one of Examples 1 to 9, wherein the processing circuit is configured to determine whether the risk level of the health event meets a criterion.

[0220] Example 11. The system according to Example 10, wherein the processing circuit is configured to change a sensing configuration of at least one of the one or more sensing devices based on the risk of the health event meeting the criterion.

[0221] Example 12. The system according to Example 10 or 11, wherein the processing circuit is configured to deliver medication guidance to the patient based on the risk of the health event meeting the criteria.

[0222] Example 13. The system according to Example 12, wherein the guidance includes on-demand dosage guidance for the medication.

[0223] Example 14. The system according to Example 12 or 13, wherein the medication includes an anticoagulant.

[0224] Example 15. The system according to any one of Examples 10 to 14, wherein the processing circuit is configured to deliver a notification to a clinician based on the risk of the health event meeting the criteria.

[0225] Example 16. The system according to any one of Examples 10 to 15, wherein the processing circuit is configured to: determine whether the health event has occurred after determining that the risk of the health event meets the criteria; determine a training set of parameter data for training the model based on the parameter data of the patient; classify the training set of parameter data based on whether the health event has occurred; and train the model with the classified training set of parameter data.

[0226] Example 17. The system according to Example 16, wherein in order to determine whether the health event has occurred, the processing circuit is configured to prompt the patient to complete a survey based on determining that the risk of the health event meets the criteria.

[0227] Example 18. The system according to Example 16 or 17, wherein in order to determine whether the health event has occurred, the processing circuit is configured to determine whether a geofence event has occurred at a time close to when the risk of the health event meets the criteria.

[0228] Example 19. The system according to any one of Examples 16 to 18, wherein in order to determine whether the health event has occurred, the processing circuit is configured to retrieve data from an electronic medical record database based on determining that the risk of the health event meets the criteria.

[0229] Example 20. The system according to any one of Examples 1 to 19, wherein the processing circuit includes a processing circuit of at least one of the following: a patient computing device configured to wirelessly communicate with the one or more sensing devices; and a computing system configured to network communicate with the patient computing device.

[0230] Example 21. The system according to any one of Examples 1 to 20, wherein the system includes one or more sensing devices, and the one or more sensing devices include an implantable medical device and an external sensing device that is a peripheral device of the patient computing device.

[0231] Example 22. A method, the method comprising: receiving parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices, and wherein the plurality of parameters includes an AF load; deriving one or more features based on the parameter data of the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to a model; and determining a risk level of a health event of the patient based on applying the one or more features to the model.

[0232] Example 23. The method according to Example 22, wherein the AF load pattern feature includes a comparison between a current AF load value and an average value of AF load values.

[0233] Example 24. The method according to Example 23, wherein the current AF load value includes a shorter-term average value of AF load values, and the average value of AF load values includes a longer-term average value of AF load values.

[0234] Example 25. The method according to any one of Examples 22 to 24, wherein the one or more features include patient activity features.

[0235] Example 26. The method according to any one of Examples 22 to 25, wherein the health event includes a stroke.

[0236] Example 27. The method according to any one of Examples 22 to 25, wherein the health event includes a healthcare utilization event.

[0237] Example 28. The method according to any one of Examples 22 to 25, wherein the health event includes a symptomatic event.

[0238] Example 29. The method according to any one of Examples 22 to 28, wherein determining the risk level of the health event includes determining the probability of occurrence of the health event.

[0239] Example 30. The method according to any one of Examples 22 to 29, wherein the risk level includes the risk that the health event will occur within a predetermined time period.

[0240] Example 31. The method according to any one of Examples 22 to 30, the method further comprising determining whether the risk level of the health event meets a criterion.

[0241] Example 32. The method according to Example 31, the method further comprising changing a sensing configuration of at least one of the one or more sensing devices based on the risk of the health event meeting the criteria.

[0242] Example 33. The method according to Example 31 or 32, the method further comprising delivering drug guidance to the patient based on the risk of the health event meeting the criteria.

[0243] Example 34. The method according to Example 33, wherein the guidance includes on-demand dosage guidance for the drug.

[0244] Example 35. The method according to Example 33 or 34, wherein the drug includes an anticoagulant.

[0245] Example 36. The method according to any one of Examples 31 to 35, the method further comprising delivering a notification to a clinician based on the risk of the health event meeting the criteria.

[0246] Example 37. The method according to any one of Examples 31 to 36, the method further comprising: determining whether the health event has occurred after determining that the risk of the health event meets the criteria; determining a training set of parameter data for training the model based on the parameter data of the patient; classifying the training set of parameter data based on whether the health event has occurred; and training the model with the classified training set of parameter data.

[0247] Example 38. The method according to Example 37, wherein determining whether the health event has occurred includes prompting the patient to complete a survey based on determining that the risk of the health event meets the criteria.

[0248] Example 39. The method according to Example 37 or 38, wherein determining whether the health event has occurred includes determining whether a geofencing event has occurred at a time close to when the risk of the health event meets the criteria.

[0249] Example 40. The method according to any one of Examples 37 to 39, wherein determining whether the health event has occurred includes retrieving data from an electronic medical record database based on determining that the risk of the health event meets the criteria.

[0250] Example 41. The method according to any one of Examples 22 to 40, wherein the one or more sensing devices include an implantable medical device and an external sensing device that is a peripheral device of a patient computing device.

[0251] Example 42. A system comprising processing circuitry configured to: receive parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices; determine a training set of parameter data for training a model based on the parameter data of the patient; classify the training set of parameter data based on classification data automatically collected in response to the detection of a trigger; and train the model with the classified training set of parameter data.

[0252] Example 43. The system according to Example 42, wherein the plurality of patient parameters includes an AF load.

[0253] Example 44. The system according to Example 42 or 43, wherein the plurality of patient parameters includes patient activity parameters.

[0254] Example 45. The system according to any one of Examples 42 to 44, wherein the processing circuitry is configured to: classify the training set of parameter data into a first category if a health event occurs in the patient, or classify the training set of parameter data into a second category if no health event occurs in the patient; and train the machine learning algorithm to determine the risk of the health event.

[0255] Example 46. The system according to Example 45, wherein the health event includes a stroke.

[0256] Example 47. The system according to Example 45, wherein the health event includes a healthcare utilization event.

[0257] Example 48. The system according to Example 45, wherein the health event includes a symptomatic event.

[0258] Example 49. The system according to any one of Examples 42 to 48, wherein the processing circuitry is configured to collect the classification data in response to the detection of the trigger.

[0259] Example 50. The system according to Example 49, wherein the trigger includes a geofence event.

[0260] Example 51. The system according to Example 49, wherein the trigger includes that a feature of the parameter data meets a criterion.

[0261] Example 52. The system according to Example 51, wherein the feature is included in a training set of features for training the model.

[0262] Example 53. The system according to Example 51 or 52, wherein the feature includes an AF load feature.

[0263] Example 54. The system according to any one of Examples 49 and 51 to 53, wherein, in order to collect the classification data, the processing circuit is configured to determine whether a geofence event occurs close to the time of the detected trigger.

[0264] Example 55. The system according to any one of Examples 49 to 54, wherein, in order to collect the classification data, the processing circuit is configured to retrieve data from an electronic medical record database.

[0265] Example 56. The system according to any one of Examples 49 to 55, wherein, in order to collect the classification data, the processing circuit is configured to prompt the patient to complete a survey.

[0266] Example 57. The system according to any one of Examples 42 to 56, wherein the processing circuit includes at least one of the following processing circuits: a patient computing device configured to wirelessly communicate with the one or more sensing devices; and a computing system configured to communicate with the patient computing device over a network.

[0267] Example 58. The system according to any one of Examples 42 to 57, wherein the system includes one or more sensing devices, and the one or more sensing devices include an implantable medical device and an external sensing device that is a peripheral device for the patient computing device.

[0268] Example 59. A method, the method comprising: receiving parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices; determining a training set of parameter data for training a model based on the parameter data of the patient; classifying the training set of the parameter data based on classification data automatically collected in response to the detection of a trigger; and training the model with the classified training set of the parameter data.

[0269] Example 60. The method according to Example 59, wherein the plurality of patient parameters includes an AF load.

[0270] Example 61. The method according to Example 59 or 60, wherein the plurality of patient parameters includes patient activity parameters.

[0271] Example 62. The method according to any one of Examples 59 to 61, wherein the processing circuit is configured to: classify the training set of the parameter data into a first category if the patient has a health event, or classify the training set of the parameter data into a second category if the patient does not have a health event; and train the machine learning algorithm to determine the risk of the health event.

[0272] Example 63. The method according to Example 62, wherein the health event includes a stroke.

[0273] Example 64. The method according to Example 62, wherein the health event includes a healthcare utilization event.

[0274] Example 65. The method according to Example 62, wherein the health event includes a symptomatic event.

[0275] Example 66. The method according to any one of Examples 59 to 65, wherein the processing circuit is configured to collect the classification data in response to the detection of the trigger.

[0276] Example 67. The method according to Example 66, wherein the trigger includes a geofence event.

[0277] Example 68. The method according to Example 66, wherein the trigger includes that a feature of the parameter data meets a criterion.

[0278] Example 69. The method according to Example 68, wherein the feature is included in a training set of features for training the model.

[0279] Example 70. The method according to Example 68 or 69, wherein the feature includes an AF load feature.

[0280] Example 71. The method according to Example 66 or any one of Examples 68 to 70, wherein collecting the classification data includes determining whether a geofence event occurs at a time close to the detection of the trigger.

[0281] Example 72. The method according to any one of Examples 66 to 71, wherein collecting the classification data includes retrieving data from an electronic medical record database.

[0282] Example 73. The method according to any one of Examples 66 to 72, wherein collecting the classification data includes prompting the patient to complete a survey.

[0283] Example 74. The method according to any one of Examples 66 to 73, wherein the one or more sensing devices include an implantable medical device and an external sensing device that is a peripheral device of a patient computing device.

[0284] Example 75. A method comprising any combination of the example methods described herein.

[0285] Example 76. A system includes a processing circuit configured to perform the method according to any one or more of Examples 22 to 41 and 59 to 75.

[0286] Example 77. A non-transitory computer-readable storage medium including program instructions configured to cause a processing circuit to perform the method according to any one or more of Examples 22 to 41 and 59 to 75.

[0287] Example 78. A system includes a processing circuit configured to: derive one or more features based on parameter data of a patient generated by one or more sensing devices of the patient based on one or more signals of the patient sensed by the one or more sensing devices, wherein the parameter data includes AF burden data, and wherein the one or more features include one or more offsets between moving averages of the AF burden data over different time periods; apply the one or more features to a rule-based model; and determine a risk level of a healthcare utilization event of the patient based on applying the one or more features to the rule-based model.

[0288] Example 79. The system according to Example 78, wherein the parameter data includes activity data of the patient.

[0289] Example 80. The system according to Example 78 or 79, wherein the parameter data includes heart rate data.

[0290] Example 81. An apparatus includes components for any one of the examples described herein.

[0291] Example 82. A system includes: an implantable medical device configured to continuously monitor an electrocardiogram via a plurality of electrodes and detect atrial tachyarrhythmia of a patient; and a processing circuit configured to: determine a risk of a health event of the patient using a plurality of atrial tachyarrhythmia burden values determined based on the atrial tachyarrhythmia detected by the implantable medical device.

[0292] Example 83. The system according to Example 82, wherein the processing circuit is configured to perform any one of the operations according to Examples 1 to 81.

[0293] Example 84. A system comprising: an implantable medical device configured to continuously monitor an electrocardiogram via a plurality of electrodes and detect atrial tachyarrhythmia in a patient; and a processing circuit configured to: determine a periodic atrial tachyarrhythmia burden value based on the atrial tachyarrhythmia detected by the implantable medical device; determine a first moving average and a second moving average of the atrial tachyarrhythmia burden value, wherein the second moving average is longer than the first moving average, and the processing circuit is configured to determine a window length of the first moving average based on one or more characteristics of the patient; compare the first moving average and the second moving average; determine a risk of a health event for the patient based on the comparison; and generate an indication of the risk of the health event for output.

[0294] Example 85. The system according to Example 1, wherein the system includes an insertable cardiac monitor, the insertable cardiac monitor including a housing configured for subcutaneous implantation in the patient, wherein the plurality of electrodes are located on the housing.

[0295] Example 86. The system according to Example 84 or 85, wherein the health event includes a stroke.

[0296] Example 87. The system according to any one or more of Examples 84 to 86, wherein, in order to determine the risk level of the health event, the processing circuit is configured to determine a probability of occurrence of the health event.

[0297] Example 88. The system according to any one or more of Examples 84 to 89, wherein the risk level includes a risk that the health event will occur within a predetermined time period.

[0298] Example 89. The system according to any one or more of Examples 84 to 89, wherein the processing circuit is configured to: determine whether the risk level of the health event meets a criterion; and based on determining that the risk level of the health event meets the criterion, generate the indication of the risk of the health event for output.

[0299] Example 90. The system according to any one or more of Examples 84 to 89, wherein the one or more characteristics of the patient include an indication received from a user for implantation of the implantable medical device in the patient.

[0300] Example 91. The system according to Example 90, wherein the indication includes a first indication associated with prior atrial fibrillation or a second indication associated with a prior stroke.

[0301] Example 92. The system according to Example 91, wherein the first indication includes atrial fibrillation management, and the second indication includes cryptogenic stroke.

[0302] Example 93. The system according to any one or more of Examples 84 to 92, wherein the one or more characteristics of the patient include the presence of comorbidities.

[0303] Example 94. The system according to Example 93, wherein the comorbidity includes cardiomyopathy.

[0304] Example 95. The system according to any one or more of Examples 84 to 94, wherein the one or more characteristics of the patient include the heart failure status of the patient.

[0305] Example 96. The system according to any one or more of Examples 84 to 95, wherein the one or more characteristics of the patient include the subcutaneous or thoracic impedance of the patient.

[0306] Example 97. The system according to any one or more of Examples 84 to 96, wherein the one or more characteristics of the patient include the level of atrial arrhythmia burden.

[0307] Example 98. The system according to any one or more of Examples 84 to 97, wherein the one or more characteristics of the patient include the CHA2DS2-VASc score of the patient.

[0308] Example 99. The system according to any one or more of Examples 84 to 98, wherein the one or more characteristics of the patient include the medications taken by the patient.

[0309] Example 100. The system according to Example 99, wherein the medication includes a medication configured to modify heart rate or rhythm.

[0310] Example 101. The system according to Example 99, wherein the medication includes one or more of beta blockers, calcium channel blockers, digoxin, sodium channel blockers, or potassium channel blockers.

[0311] Example 102. The system according to any one or more of Examples 84 to 101, wherein the processing circuit is configured to: identify a change in the one or more characteristics of the patient; and modify the window length of the first moving average based on the change in the one or more characteristics of the patient.

[0312] Example 103. The system according to any one or more of Examples 83 to 102, wherein the processing circuit is configured to retrieve the one or more characteristics of the patient from an electronic health record database.

[0313] Example 104. A method, the method comprising any one of the methods described herein.

[0314] Example 105. A system, the system comprising a processing circuit configured to perform any one of the methods described herein.

[0315] Example 106. A system, the system comprising means for performing any one of the methods described herein.

[0316] Example 107. A non-transitory computer-readable storage medium, the non-transitory computer-readable storage medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform any one of the methods described herein.

[0317] 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. The computer-readable medium may include a non-transitory computer-readable medium corresponding to a tangible medium, such as a data storage medium (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer).

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

[0319] Various embodiments have been described. These and other examples are within the scope of the appended claims.

Claims

1. A system, the system comprising: An implantable medical device configured to continuously monitor an electrocardiogram via a plurality of electrodes and detect atrial tachyarrhythmia in a patient; And A processing circuit configured to: Determine a periodic atrial tachyarrhythmia burden value based on the atrial tachyarrhythmia detected by the implantable medical device; Determine a first moving average and a second moving average of the atrial tachyarrhythmia burden value, wherein the second moving average is longer than the first moving average, and the processing circuit is configured to determine a window length of the first moving average based on one or more characteristics of the patient; Compare the first moving average and the second moving average; Determine a risk of a health event of the patient based on the comparison; Generate an indication of the risk of the health event for output.

2. The system according to claim 1, wherein the system includes an insertable cardiac monitor, the insertable cardiac monitor including a housing configured for subcutaneous implantation in the patient, wherein the plurality of electrodes are located on the housing.

3. The system according to claim 1 or 2, wherein the health event includes a stroke.

4. The system according to any one or more of claims 1 to 3, wherein, in order to determine a risk level of the health event, the processing circuit is configured to determine a probability of occurrence of the health event.

5. The system according to any one or more of claims 1 to 4, wherein the risk level includes a risk that the health event will occur within a predetermined time period.

6. The system according to any one or more of claims 1 to 5, wherein the processing circuit is configured to: Determine that the risk level of the health event meets a criterion; and Based on determining that the risk level of the health event meets the criterion, generate the indication of the risk of the health event for output.

7. The system according to any one or more of claims 1 to 6, wherein the one or more characteristics of the patient include an indication received from a user for implantation of the implantable medical device in the patient.

8. The system according to claim 7, wherein the indication includes a first indication associated with prior atrial fibrillation or a second indication associated with prior stroke.

9. The system according to claim 8, wherein the first indication includes atrial fibrillation management, and the second indication includes cryptogenic stroke.

10. The system according to any one or more of claims 1 to 9, wherein the one or more characteristics of the patient include the presence of comorbidities.

11. The system according to claim 10, wherein the comorbidities include cardiomyopathy.

12. The system according to any one or more of claims 1 to 11, wherein the one or more characteristics of the patient include the heart failure status of the patient.

13. The system according to any one or more of claims 1 to 12, wherein the one or more characteristics of the patient include the subcutaneous or thoracic impedance of the patient.

14. The system according to any one or more of claims 1 to 13, wherein the one or more characteristics of the patient include the level of atrial arrhythmia burden.

15. The system according to any one or more of claims 1 to 14, wherein the one or more characteristics of the patient include the CHA2DS2-VASc score of the patient.

Images