Health event prediction and patient feedback system

Through a medical device system integrating memory and processing circuits, analyzing patient physiological parameter data to determine AF load and providing behavioral advice solves the problem of difficulty in monitoring and predicting AF load in the prior art, and improves the ability to identify and cope with healthy events in the onset of arrhythmia and worsening heart failure.

CN119677467APending Publication Date: 2025-03-21MEDTRONIC INC
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202380058207.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2022-08-08
Filing Date
2023-07-20
Publication Date
2025-03-21

AI Technical Summary

Technical Problem

Existing medical devices are difficult to effectively monitor and predict atrial fibrillation (AF) load, resulting in failure to identify and respond to health events that may lead to arrhythmia or worsening heart failure.

Method used

By integrating memory and processing circuits in a medical device system, collecting and analyzing multiple physiological parameter data of a patient, including ECG signals, to determine the patient's AF load and provide personalized patient behavior recommendations based on this to weaken or eliminate increased AF load patterns.

Benefits of technology

Accurate monitoring and prediction of patients' AF load is achieved, and early recognition and coping of healthy events in arrhythmia attacks and worsening heart failure is improved, helping patients to take appropriate behavioral adjustments to reduce health risks.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119677467A_ABST
    Figure CN119677467A_ABST
Patent Text Reader

Abstract

A medical device system includes: a memory; and processing circuitry in communication with the memory. The processing circuit is configured to receive parameter data of a plurality of parameters of a patient, determine an atrial fibrillation (AF) load of the patient over a period of time based on the parameter data, where the AF load of the patient over the period of time includes a pattern of increased AF load; outputting a request for display by a user device, the request to identify whether the patient participates in each patient behavior in the set of patient behaviors during the time period; and based on receiving a response indicating that the patient participates in one or more patient behaviors of the set of patient behaviors, determining a suggestion to change at least a subset of the one or more patient behaviors to attenuate a pattern of the increased AF load.
Need to check novelty before this filing date? Find Prior Art

Description

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

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

[0003] A variety of devices are configured to monitor the patient's physiological signals. Such devices include implantable or wearable medical devices, and a variety of wearable health or fitness tracking devices. Physiological signals sensed by such devices include, for example, electrocardiogram (ECG) signals, respiratory signals, perfusion signals, activity and / or posture signals, pressure signals, blood oxygen saturation signals, body composition, and blood sugar or other blood component signals. Generally speaking, using these signals, such devices are convenient for 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 arrhythmia attacks or worsening of heart failure based on physiological signals. Exemplary arrhythmia types include cardiac arrest, bradycardia, ventricular tachycardia, supraventricular tachycardia, wide QRS complex tachycardia, atrial fibrillation, atrial flutter, ventricular fibrillation, atrioventricular block, ventricular premature contraction, and atrial premature contraction. These devices can store ECG and other physiological signal data collected during the time period including the attack as attack data. These devices can also store attack data that quantifies the attack, such as the number and / or duration of the attack. The medical device can also store ECG and other physiological data for a certain time period as attack data in response to user input, such as from a patient or a caregiver. Summary of the invention

[0005] In general, the present disclosure describes techniques for determining a risk level for a health event based on parameter data for multiple parameters of a patient. The multiple parameters may include atrial fibrillation (AF) load. In some examples, the techniques include applying AF load 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 based on classification data automatically collected in response to a triggered detection. The techniques also include a patient interface system for presenting one or more inquiries to the patient. The patient interface system may also provide the patient with one or more recommendations for changing behavior.

[0006] The techniques of the present disclosure may provide one or more advantages. For example, by using a patient interface system to ask a patient to identify one or more patient behaviors, the system may more effectively identify behaviors that may lead to increased AF load than a system that does not ask the patient to identify the behaviors. Outputting recommendations to change patient behaviors that may lead to increased AF load may more effectively reduce or eliminate patterns of increased AF load than a system that does not output recommendations to the patient.

[0007] In one example, a medical device system includes a memory; and a processing circuit in communication with the memory, wherein the processing circuit is configured to: receive parameter data of multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine an atrial fibrillation (AF) load of the patient over a time period based on the parameter data, wherein the AF load of the patient over the time period includes a pattern of increased AF load; output a request for display by a user device operated by the patient, the request being used to identify whether the patient engages in each patient behavior in a set of patient behaviors during the time period; based on receiving a response indicating that the patient engages in one or more patient behaviors in the set of patient behaviors, determine a recommendation to change at least a subset of the one or more patient behaviors to reduce the pattern of increased AF load; and output the recommendation for display by the user device operated by the patient.

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

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

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

[0011] 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 this disclosure.

[0012] Figure 2 is a diagram showing one or more techniques according to the present disclosure Figure 1 A block diagram of an exemplary configuration of an IMD.

[0013] Figure 3 is a diagram showing one or more techniques according to the present disclosure Figure 1 and Figure 2 Conceptual side view of an exemplary configuration of an IMD.

[0014] Figure 4 is a block diagram illustrating an example configuration of an external device that operates according to one or more techniques of this disclosure.

[0015] Figure 5 is a block diagram illustrating an exemplary computing system operating in accordance with one or more techniques of this disclosure.

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

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

[0018] Figure 8 is a flow chart illustrating an example technique for predicting a health event and responding to the prediction of a health event, in accordance with one or more techniques of this disclosure.

[0019] Fig. 9 is a flow chart illustrating an example technique for outputting recommendations for changing patient behavior in accordance with one or more techniques of this disclosure.

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

[0021] Fig.11 is a flow chart illustrating an example technique for identifying a pattern of increased AF load in accordance with one or more techniques of this disclosure.

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

[0023] Fig.13 is a flow chart illustrating an example technique for determining risk level of a health event based on AF load variability, in accordance with one or more techniques of the present disclosure.

[0024] Fig.14 is a flow chart illustrating an exemplary technique for determining a risk level for a health event based on one or more conditions specific to a patient, in accordance with one or more techniques of the present disclosure.

[0025] Fig.15 is a conceptual diagram illustrating a patient behavior inquiry screen for display on a user interface of a device, in accordance with one or more techniques of this disclosure.

[0026] Fig.16 is a conceptual diagram illustrating a first suggestion screen for display on a user interface of a device according to one or more techniques of this disclosure.

[0027] Fig.17 is a conceptual diagram illustrating a second suggestion screen for display on a user interface of a device, according to one or more techniques of this disclosure.

[0028] Fig.18 is a graph showing parameter data for multiple patient parameters over a time period surrounding a stroke event, in accordance with one or more techniques of the present disclosure.

[0029] Fig.19 is a graph showing time series values ​​of moving averages of parameter data for a patient parameter in accordance with one or more techniques of the present disclosure.

[0030] Fig. 20 is a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke, in accordance with one or more techniques of the present disclosure.

[0031] Fig.21 is a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke, in accordance with one or more techniques of the present disclosure.

[0032] FIG. 22A to FIG. 22Dis a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke in different patient populations, according to one or more techniques of the present disclosure.

[0033] FIG. 23A to FIG. 23D is a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization for different patient populations, according to one or more techniques of the present disclosure.

[0034] Fig.24 is a graph illustrating AF load pattern characteristics for predicting stroke and healthcare utilization in accordance with one or more techniques of the present disclosure.

[0035] Fig.25A and Fig.25B are graphs respectively illustrating AF burden patterns for patients experiencing a stroke or healthcare utilization event for different patient populations, in accordance with one or more techniques of the present disclosure.

[0036] Fig.26 is a graph illustrating AT / AF time (load) detected during a monitoring period, in accordance with one or more techniques of this disclosure.

[0037] Fig. 27 Scatter plots of terminal nodes of labeled HCU rates and patient percentages from balanced training data in accordance with one or more techniques of the present disclosure are presented.

[0038] Fig.28 Example graphical illustrations of patterns in AF load data mapped for a single HCU patient in accordance with one or more techniques of the present disclosure are presented.

[0039] Fig.29 Scatter plots of terminal nodes of HCU rates and patient percentage scores according to labels of an unbalanced validation set according to one or more techniques of the present disclosure are presented.

[0040] Fig.30 A Venn diagram of AF load threshold counts for a validation set according to one or more techniques of the present disclosure is presented.

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

[0042] Various 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 to non-invasively sense and monitor ECG and other physiological signals include wearable devices such as patches, watches, or necklaces with electrodes configured to contact the patient's skin. Such medical devices can facilitate relatively long-term monitoring of patient health during normal daily activities.

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

[0044] Figure 1 1 is a block diagram illustrating an exemplary medical device system 2 configured to predict health events of a patient 4 and respond to such predictions in accordance with one or more techniques of the present disclosure. The exemplary techniques may be used with an IMD 10 that may communicate wirelessly with an external device 12. In some examples, the IMD 10 is implanted outside the chest of the patient 4 (e.g., subcutaneously). Figure 1 The IMD 10 may be positioned near the sternum at or just below the level of the patient's 4 heart, for example at least partially within the outline of the heart. The IMD 10 includes a plurality of electrodes ( Figure 1 ), and is configured to sense ECG via a plurality of electrodes. In some examples, the IMD 10 employs LINQ TM Form of ICM. Although described primarily in the context of examples in which an IMD takes the form of an ICM, the techniques of this disclosure may be implemented in a system that includes any one or more implanted or external medical devices, including a monitor, pacemaker, or defibrillator.

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

[0046] exist Figure 1 In the example shown, the system 2 also includes a sensor device 14 that wirelessly communicates with the external device 12. The sensor device 14 may include electrodes and other sensors to sense physiological signals of the patient 4, and may 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 the patient 4. The sensor device 14 can be incorporated into the patient's 4 clothing, such as in clothing, shoes, glasses, watches or wristbands, hats, etc. In some examples, the sensor device 14 is a smart watch or other accessory or peripheral device of the smart phone external device 12.

[0047] External device 12 retrieves seizure and other physiological data collected and stored by sensor device 14 from sensor device 14. External device 12 may include a display and other user interface elements. In some examples, external device 12 presents physiological data and / or statistical representations thereof retrieved from IMD 10 and / or sensor device 14 to patient 4 or another user. External device 12 may display physiological data retrieved from IMD 10 and / or sensor device 14 and / or statistical representations thereof to patient 4 or another user. External device 12 may display physiological data retrieved from IMD 10 and / or sensor device 14 based on, for example, or The Bluetooth Low Energy (BLE) protocol communicates with the IMD 10 and / or the sensor device 14 .

[0048] External device 12 may be configured to communicate with computing system 20 via network 15. External device 12 may be used to retrieve data from IMD 10 and sensor device 14 and may transmit the data to computing system 20 via network 15. The retrieved data may include values ​​of physiological parameters measured by IMD 10 and sensor device 14, data about arrhythmia episodes or other health events detected by IMD 10 and sensor device 14, and other physiological signals or data recorded by IMD 10 sensor device 14. The data retrieved from IMD 10 and sensor device 14 may include values ​​of various patient parameters and / or may be used by computing system 20 to determine values ​​of patient parameters. The values ​​of patient parameters may be referred to as patient parameter data. Patient parameter data may be retrieved and / or determined on a periodic basis to generate periodic values, such as generating daily values ​​on a daily basis.

[0049] The computing system 20 may include a computing device 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 may include one or more devices that implement a monitoring system, which includes processing circuitry and storage devices. The monitoring system may present the patient's parameter data to the clinician to allow the clinician to remotely track and evaluate their patients. In some examples, the monitoring system may analyze the data and prioritize the presentation of data or alerts for certain patients based on the analysis. In some examples, the computing system 20, network 15, and monitoring system may be communicated to the clinician through Medtronic Carelink. TM Network to implement.

[0050] The network 15 may include one or more computing devices (not shown), such as one or more non-edge switches, routers, hubs, gateways, security devices (such as firewalls), intrusion detection and / or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular phones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices. The network 15 may include one or more networks managed by a service provider, and thus may form part of a large-scale public network infrastructure (e.g., the Internet). The network 15 may provide access to the Internet to computing devices (such as the computing system 20 and the external device 12), and may provide a communication framework that allows computing devices to communicate with each other. In some examples, the network 15 may be a dedicated 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 data flows between these devices from devices outside the network 15 for security purposes. In some examples, the communication between the computing system 20 and the external device 12 is encrypted.

[0051] The computing system 20 may also retrieve data for the patient 4 from an electronic medical record (EMR) database 22. The EMR database 22 may store electronic medical records (also known as electronic health records) for the patient 4, which may be generated by various healthcare providers, laboratories, clinicians, insurance companies, etc. Figure 1 Although shown as a single database in FIG. 1 , the EMR database 22 may include various databases managed by various entities.

[0052] 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 appointment clinic visit history, one or more laboratory or other clinical test results of patient 4, a cardiovascular history of patient 4, or a comorbidity of patient 4 (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 for 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 for multiple patients.

[0053] For example, a monitoring system implemented by a processing circuit of a computing system 20 may implement the technology of the present disclosure, including developing an algorithm based on a training set of parameter data of a patient or subject population retrieved from a population of IMDs 10 and external devices, 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 the risk level of a health event, the probability of a health event occurring within a specific time, and / or whether the risk or probability meets a threshold. The computing system 20 is not limited to using an ML model. The computing system 20 may use any type of model to analyze parameter data.

[0054] Exemplary health events that may be predicted using the techniques of the present disclosure include stroke, clinically significant AF requiring hospitalization or emergency care, and clinically significant episodes of symptomatic events such as syncope or dizziness. Parameter data that may be used to predict such health events may include cardiac rhythm data, such as heart rate data and data associated with episodes of atrial fibrillation (AF) or other arrhythmias. AF data may include a quantification of AF (referred to as AF load) and patterns of AF load over multiple time periods. Parameter data that may be used to predict such clinically significant health events may alternatively or alternatively include patient activity data or any other patient data or signal described herein.

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

[0056] The computing system 20 may determine an atrial fibrillation (AF) burden of the patient over a time period based on the parameter data. In some cases, the time period may extend beyond a day (e.g., 7 days, 30 days, or any other duration). For example, the computing system 20 may determine an AF burden that varies over time based on the parameter data. In some examples, the AF burden of the patient 4 over the time period may indicate one or more patterns. For example, the AF burden of the patient 4 over the time period may indicate a pattern of increased AF burden. In some examples, the pattern of increased AF burden may include one or more occurrences of increased AF burden over the time period. In some cases, one or more occurrences of increased AF burden occur more frequently during certain times of the day, but this is not required. A pattern of increased AF burden represents any pattern that includes one or more occurrences of increased AF burden.

[0057] The computing system 20 may output a request for display by the external device 12 based on determining a pattern of increased AF load, the request being used to identify whether the patient 4 engaged in one or more behaviors during a time period. In some examples, the computing system 20 may select one or more behaviors based on the pattern of increased AF load. For example, if the pattern of increased AF load includes increased AF load occurring in the morning, the computing system 20 may output a request for the patient 4 to indicate whether they consumed caffeine in the morning. In any case, the computing system 20 may output a list of patient behaviors for display by the external device 12. Each patient behavior in the list of patient behaviors may be selected or deselected, such that the patient may not select any of the behaviors displayed by the external device 12, select one of the behaviors, or select a combination of more than one of the behaviors.

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

[0059] Computing system 20 may output a suggestion to change behavior for display by external device 12. In some examples, computing system 20 may receive a response indicating acceptance of the suggestion. Computing system 20 may determine the AF load of patient 4 over a period of time after accepting the suggestion to change behavior to determine whether the change in behavior eliminates or reduces the pattern of increased AF load. If the change in behavior does not eliminate or reduce the pattern of increased AF load, computing system 20 may output another suggestion to change behavior.

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

[0061] In some examples, the variability of AF load over time is a strong indicator of an increased risk of a health event. The computing system 20 can determine the AF load of the patient 4 over a time period based on the parameter data. The computing system 20 can calculate an AF load score corresponding to the time period. In some examples, the AF load score can represent the average AF load over a time period, the median AF load over a time period, or another score that quantifies the AF load. For example, the AF load score can represent the sum of the AF load data points over the time period. In some cases, the computing system 20 can divide the time period into a set of time intervals. For example, if the time period is two weeks, the computing system 20 can divide the two weeks into fourteen one-day time intervals. This allows the computing system 20 to analyze the AF load in each individual time interval against the AF load over the entire time period. The computing system 20 can calculate the AF load score for each time interval in a set of time intervals corresponding to the time period. The AF load score corresponding to each time interval can indicate a change in AF load. That is, when the AF load changes significantly throughout a set of time intervals, this can indicate a higher risk of a health event.

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

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

[0064] The monitoring system may also utilize data from the EMR database 22 and / or data input by the patient or caregiver via the external device 12 together with parameter data from the IMD 10 or the sensor device 14. In some examples, the data from the EMR database 22 and / or data input by the patient or caregiver may be used as input to the ML model or other health event prediction algorithms implemented by the monitoring system. In some examples, the data from the EMR database 22 and / or data input by the patient or caregiver via the external device 12 may provide a classification of a training set for parameter data from the IMD 10 and the sensor device 14 for training one or more models (e.g., 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 experiences a clinically significant health event, when the clinically significant health event is experienced, and the severity of the clinically significant health event experienced. Such data may be associated with parameter data to create a training set of parameter data. After the initial training phase, such training sets may be used for reinforcement learning, and in some cases, for personalization of one or more ML models.

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

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

[0067] The processing circuit 50 may include fixed function circuits and / or programmable processing circuits. The processing circuit 50 may include any one or more of 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 circuits. In some examples, the processing circuit 50 may include multiple components (such as any combination of one or more microprocessors, one or more controllers, one or more DSPs, one or more ASICs, or one or more FPGAs) and other discrete or integrated logic circuits. The functions attributed to the processing circuit 50 herein may be embodied as software, firmware, hardware, or any combination thereof.

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

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

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

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

[0072] In some examples, processing circuit 50 transmits parameter data and seizure data of patient 4 to Figure 1 The processing circuit 50 may be configured to communicate with an external device 12 that transmits data to the network 15 for processing by the monitoring system of the computing system 20. The computing system 20 may analyze the parameter data and / or the episode data to perform one or more actions, such as determining a risk of a health event, or determining one or more recommendations for output for display by the external device 12. 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.

[0073] Although described herein in the context of an exemplary 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 100 commercially available from Medtronic plc of Dublin, Ireland), or a transcatheter pacemaker configured for implantation within the heart. TM transcatheter pacing systems), insertable cardiac monitors (such as the Reveal LinQ also available from Medtronic TM ICM), neurostimulator, or drug delivery device.

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

[0075] Figure 3 is a conceptual side view illustrating an exemplary configuration of IMD 10 in accordance with one or more techniques of this disclosure. Figure 3 In the example shown, IMD 10 may include a leadless subcutaneously implantable monitoring device having housing 18 and insulating cover 74. Electrodes 16A and 16B may be formed or disposed on an outer surface of cover 74. Figure 2 The described circuits 50 to 56 and 60 can be formed or placed on the inner surface of the cover 74 or within the housing 18. In the example shown, 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 surface or the outer surface of the cover 74. In some examples, the insulating cover 74 can be positioned above the open housing 18 so 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 circuits from the effects of fluids (such as body fluids).

[0076] One or more of antenna 26, sensor 58, or circuits 50 to 56 may be formed on insulating cover 74, such as by using flip chip technology. Insulating cover 74 may be flipped onto housing 18. When flipped and placed onto housing 18, components of IMD 10 formed on the inner side of insulating cover 74 may be positioned in gap 76 defined by housing 18. Electrode 16 may be electrically connected to switching circuit 60 by one or more through holes (not shown) formed through insulating cover 74. Insulating cover 74 may be formed of sapphire (i.e., corundum), glass, poly-p-xylene, and / or any other suitable insulating material. Housing 18 may be formed of titanium or any other suitable material (e.g., biocompatible material). Electrode 16 may be formed of any one of stainless steel, titanium, platinum, iridium, or alloys thereof. In addition, electrode 16 may be coated with materials such as titanium nitride or fractal titanium nitride, but other suitable materials and coatings for such electrodes may be used.

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

[0078] Figure 4 is a block diagram illustrating an exemplary configuration of an external device 12 according to one or more techniques of the present disclosure. In some examples, the external device 12 takes the form of a mobile device, such as a mobile phone, a "smart" phone, a laptop computer, a tablet computer, or a personal digital assistant (PDA). In some examples, the sensor device 12 is a computing device of the patient 4. Figure 4 As shown in the example of FIG. 1 , the external device 12 includes processing circuitry 80, storage device 82, communication circuitry 84, and user interface 86. Although for purposes of illustration, Figure 4 1 is shown as a standalone device, but the external device 12 may be any component or system including a processing circuit or other suitable computing environment for executing software instructions, and does not necessarily include, for example Figure 4 82 may not be located in the same location or in the same rack as other components (eg, in some examples, components such as storage device 82 may not be located in the same location or in the same rack as other components).

[0079] In one example, processing circuitry 80 is configured to implement functionality and / or process instructions for execution within external device 12. For example, processing circuitry 80 may be capable of processing instructions (including application 90) stored in storage device 82. Examples of processing circuitry 80 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.

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

[0081] The external device 12 uses the communication circuit 84 to communicate with other devices such as Figure 1 The communication circuit 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 send and receive information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radios.

[0082] The external device 12 also includes a user interface 86. The user interface 86 can be configured to provide output to the user using tactile, audio or video stimulation, and receive input from the user through tactile, audio or video 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 a user, a sound card, a video graphics adapter card, or any other type of device for converting signals into an appropriate form that can be understood by humans or machines, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate understandable output to the user. In some examples, the presence-sensitive display includes a touch-sensitive screen.

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

[0084] The health monitor 96 may be configured to facilitate a user (such as a patient or a caregiver) to monitor the health of the patient 4. The health monitor 96 may present health information, such as at least a portion of the IMD data 102 and / or the sensor device data 104, via the user interface 86. The health monitor 96 may also collect information about the patient's health from the user via the user interface 86 and store the information as user-recorded health data 106. In some examples, the health monitor 96 presents a questionnaire or survey to the user seeking health data 106 from the user. The health monitor 96 may present the survey according to a schedule, in response to the IMD data 102 and / or the sensor device data 104 indicating that the patient 4 has experienced a health event, and / or based on the location of the patient 4 (e.g., in response to the location service 98 indicating that the patient 4 has entered a geo-fenced area defined by the geo-fence data 108). Presenting the survey in response to the health event may facilitate timely capture of the user-recorded health data 106 regarding the health event. In some examples, geo-fenced areas are defined around clinics, hospitals, etc., and entry into such geo-fenced areas may similarly indicate that patient 4 has experienced a health event worthy of timely collection of user-recorded health data 106. Processing circuitry 80 may also store the time and duration of the patient's entry into the geo-fenced area as geo-fence data 108.

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

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

[0087] IMD data 102 and sensor device data 104 may include patient parameter data derived from sensed physiological signals, as described herein. As an example, IMD 102 may include periodic (e.g., daily) values ​​of one or more of the following: heart rate, heart rate variability, one or more ECG morphology features or intra-beat intervals, AF and / or other arrhythmia load (e.g., number of times, time, or percentage time per cycle), respiratory rate, perfusion, and activity level. In some examples, external device 12 may output some or all of IMD data 102 and sensor device data 104 to computing system 20.

[0088] As an example, the sensor device data 104 may 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 patterns.

[0089] As an example, the user recorded health data 106 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. Symptom data may include the time when the patient experienced symptoms and the characteristics of their symptoms, such as palpitations, atrial flutter, AF, atrial tachycardia, syncope, or dizziness. Medical history data may involve 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 user recorded health data 106 may include one or more of the data types listed in Table 1 below.

[0090]

[0091]

[0092] Table 1

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

[0094] exist Figure 5In the example of FIG. 1 , 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, computing system 20 also includes one or more applications 220 (such as monitoring system 222) executable by computing system 20.

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

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

[0097] Storage device 208 may also be configured for long-term storage of information, such as application programs 220 and data 230. In some examples, storage device 208 includes a non-volatile storage element. Examples of such non-volatile storage elements include a magnetic hard disk, an optical disk, a floppy disk, flash memory, or various forms of electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM).

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

[0099] In one example, computing system 20 also includes one or more user interface devices 204. In some examples, user interface devices 204 may be configured to provide output to a user using tactile, audio, or video stimulation, and to receive input from a user through tactile, audio, or video feedback. User interface devices 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 to a human or machine, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate understandable output to a user.

[0100] Applications 220 may also include program instructions and / or data executable by processing circuitry 202 of computing system 20 to cause computing system 20 to provide the functionality attributed thereto herein. Exemplary applications 220 may include monitoring system 222. Other additional applications not shown may alternatively or additionally be included to provide other functionality described herein and are not depicted for simplicity.

[0101] According to the techniques of this disclosure, computing system 20 receives IMD data 102, sensor device data 104, user recorded health data 106, and geo-fence data 108 from external device 12 via communication circuitry 206. Processing circuitry 202 stores these data as data 230 in storage device 208.

[0102] The computing system 20 can also obtain information from the EMR database 22 ( Figure 1 ) receives EMR data 230 and stores the EMR data 230 in the storage device 208. For each of the plurality of patients or subjects, the EMR data 230 may include, for example, medication history, surgical procedure history, hospitalization history, emergency or urgent care visit history, clinic visit history, one or more laboratory or other clinical test results, procedure history, cardiovascular history, or comorbidities such as atrial fibrillation, heart failure, syncope, or diabetes. As a further example, the EMR data 230 may include medical images, such as x-ray images, ultrasound images, echocardiograms, anatomical images, medical photographs, radiographic images, and the like.

[0103] The monitoring system 222, implemented, for example, 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, 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 patient or subject population, 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 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 for a health event, such as a probability of a health event, a risk level or probability of a health event occurring within a specific predetermined time period, and / or whether the risk or probability meets a threshold.

[0104] The plurality of patient parameters may include AF load, 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 input to an algorithm (e.g., ML model 224) to determine a risk level. One or more of these features may be AF load features.

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

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

[0107] The monitoring system 222 may determine the AF load of the patient 4 in a period of time based on the parameter data. The AF load of the patient 4 in the period of time is a pattern of increased AF load in the AF load of the patient 4 in the period of time.

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

[0109] Based on the response, the patient interface system 226 may output one or more suggestions for changing the patient's behavior for display by the user interface 86 of the external device 12. If the patient interface system 226 receives a response from the external device 12 indicating that the patient 4 accepts the suggestion to change the behavior, the monitoring system 222 may determine whether the pattern of increased AF load is reduced or eliminated after the patient 4 accepts the suggestion. In the event that the pattern of increased AF load still exists, the patient interface system 226 may output another suggestion for changing the patient's behavior. In some examples, the patient interface system 226 may output the suggestion according to the degree of likelihood that the suggestion reduces or eliminates the pattern of increased AF load. That is, when the most likely cause of increased AF load is caffeine consumption, the second most likely cause is sodium consumption, and the third most likely cause is exercise, the patient interface system 226 may first output a suggestion to reduce caffeine consumption. If the suggestion to reduce caffeine consumption does not reduce or eliminate the pattern of increased AF load, the patient interface system 226 may output a suggestion to reduce sodium consumption. If the suggestion to reduce sodium consumption does not reduce or eliminate the pattern of increased AF load, the patient interface system 226 may output a suggestion to reduce exercise. In some examples, monitoring system 222 may determine the likelihood that each action will reduce AF load.

[0110] In some examples, the patient interface system 226 can allow the clinician to output one or more messages to the patient and / or allow the patient to output one or more messages to the clinician. For example, the clinician can output a message to the patient to take one or more medications via the patient interface system 226 based on the clinician's analysis of the parameter data. The patient interface system 226 can notify the clinician about one or more patient conditions (e.g., ablation history, beta block history, or other medical history). Based on the one or more patient conditions, the doctor can use the patient interface system 226 to output one or more suggestions to the patient. For example, the clinician can advise the patient not to exercise in the morning because it increases the risk of adverse health events.

[0111] 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 a hospitalization. In some examples, a health event includes a symptomatic event, such as a clinically significant syncope or dizziness.

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

[0113] In some examples, the processing circuit 202 executing the monitoring system 222 collects the classification data 232. In some examples, the classification data is additionally or alternatively provided by the system 2 ( Figure 1 ) other processing circuits (such as external device 12 ( Figure 4 ) and received by computing system 20 from other processing circuits. Classification data 232 includes data indicating an endpoint of a training set of parameter data, such as data indicating whether a patient experienced a health event. Classification data 232 may include data from user-recorded health data 106, geo-fence data 108, and / or EMR data 230 indicating an endpoint for a patient.

[0114] Any one or more of IMD 10, sensor device 14, external device 12, or computing system 20 may detect a trigger for collecting categorized data 232. In some examples, the trigger is, for example, a geo-fence event detected by external device 12 indicating that the patient traveled to a hospital or clinic for a threshold amount of time. In such examples, external device 12 or computing system 20 may present a survey to the patient to collect information about the visit (e.g., confirming the visit and about the health problem addressed) as health data 106 and categorized data 230 recorded by the user.

[0115] In some examples, the trigger includes a feature of the patient's parameter data meeting a criteria, such as indicating that the patient may have experienced a health event. For example, the trigger may be AF load reaching or exceeding a threshold. Other exemplary triggers may include a feature of any physiological parameter described herein reaching a threshold. In some examples, the trigger feature may be included in a training set of features used to train the ML model 224, such as a feature set from which the monitoring system 222 may select input features based on their predictive value for a health event. In response to the detection of the trigger feature, the monitoring system 222 or other processing circuitry of the system 2 may collect classification data 230. The collection of classification data 232 may be via a survey as discussed above, or by examining the geo-fence data 108 and / or EMR data 230 to identify times close to hospital or clinic visits that indicate the occurrence of a health event.

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

[0117] Although these techniques are described herein as being performed by the monitoring system 222, and therefore 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 trained based on population parameter data and, in some examples, personalized based on parameter data of the patient 4. The ML model 224 may include, for example, a neural network, a deep learning model, a convolutional neural network, or other type of predictive analysis system. In addition, 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, with different models or algorithms that do not necessarily require machine learning, such as linear regression, trend analysis, decision trees, or thresholds.

[0118] Figure 6 is a flow chart illustrating an exemplary technique for training a machine learning model using a training set of parameter data classified based on automatically collected classification data, in accordance with one or more techniques of the present disclosure. Figure 6 In the illustrated example, 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 parameter data (302). The monitoring system 222 classifies the training set of parameter data based on automatically collected classification data, as described above with reference to Figure 5 The monitoring system 222 trains the ML model 224 using the training set of classified parameter data (306).

[0119] Figure 7 is a flow chart illustrating an exemplary technique for automatically collecting categorized data in accordance with one or more techniques of this disclosure. Figure 7 In an example of, monitoring system 222 collects parameter data (400) of a patient in a plurality of patients, for example, during a clinical study and ML model training phase. Figure 5 As discussed above, the monitoring system determines whether a trigger has occurred (402). Figure 5As discussed, exemplary triggers include features in the parameter data satisfying criteria or geo-fence events. A geo-fence event may be an event in which a patient remains within a geo-fenced area (e.g., an area near or around a hospital, urgent care clinic, and / or healthcare provider) for more than a threshold time. A patient's stay within a geo-fenced area for more than a threshold stay time may be evidence of unplanned or planned healthcare utilization. Examples of features in the parameter data that meet criteria include AF burden or other features derived from an ECG, such as a heart rate or heart rate variability that exceeds a threshold, and / or patient activity features that fall below a threshold. If a trigger does not occur ("No" of 402), the monitoring system 222 may continue to receive parameter data for the patient and monitor for triggers (400, 402).

[0120] If the trigger occurs (“Yes” of 402 ), the monitoring system 222 collects the classification data 232 ( 404 ). Figure 5 As discussed, exemplary classification data 232 may include user-recorded health data 106 from a survey delivered to a patient in response to a trigger, or geo-fence data 108 (in the case of a parameter data feature trigger) indicating a patient visit to a hospital or clinic and, in some cases, indicating a proximity in time of a health event occurring, or EMR data 230. The monitoring system 222 associates the classification data 232 with the parameter data for final classification of the training set of the parameter data (406).

[0121] Figure 8 is a flow chart illustrating an exemplary technique for predicting a health event and responding to a prediction of a health event in accordance with one or more techniques of the present disclosure. As discussed above, exemplary health events include stroke, hospitalization or other healthcare utilization, or symptomatic events such as symptomatic AF or other cardiovascular events.

[0122] according to Figure 8In the example shown, the monitoring system 222 receives parameter data for the patient 4, such as the IMD data 102 and the 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 AF load pattern features, and in some cases, patient activity features or other features derived from another physiological signal. The monitoring system 222 determines a risk level for a health event based on the application of 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., a few days). The monitoring system 222 determines whether the risk level for the health event meets a criterion, such as whether a threshold is reached or exceeded (504). If the risk level does not meet the criterion ("No" of 504), the monitoring system 222 continues to receive parameter data and apply features to the ML model 224 (500, 502), for example on a cycle-by-cycle basis. Based on the risk level meeting the criterion ("Yes" of 504), the monitoring system 222 may perform Figure 8 One or more of the optional actions shown (506 to 512).

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

[0124] As another example, monitoring system 222 may provide patient 4 with instructions for taking a medication or modifying the taking of a medication (508). The medication may be an anticoagulant. The instructions may be to take an on-demand dose of the medication or to change the dosage of the medication.

[0125] As another example, monitoring system 222 may prioritize patient 4 or portions of parameter data associated with risk levels for health events in notifications to clinicians treating patient 4 (810). Monitoring systems 222 implementing the techniques of the present disclosure may advantageously reduce the burden of treating patients by prioritizing patients and / or patient data in notifications from system 2 based on risk levels meeting criteria indicating clinically significant risk for health events. In some examples, monitoring system 222 reduces the burden by determining which rhythms should be transmitted or alerted to patients and / or clinicians (e.g., clinically relevant patient reports presenting determined symptoms).

[0126] As another example, the monitoring system 222 can determine the classification of the parameter data associated with the risk level of the health event and create a training set of parameter data for enhanced training of the ML model 224 for the patient 4 and / or personalized training of the ML model 224, for example, to create a patient-specific version of the ML model 224 (512). The monitoring system 222 can utilize, for example, the information provided herein with reference to Figure 7 Any of the techniques described are used to collect classification data 232 for classifying a training set of parameter data.

[0127] The health monitor 96 executed by the processing circuit 80 of the external device may implement Figures 6 to 8 For example, health monitor 96 may present surveys and collect answers from patient 4, present instructions to patient 4 for taking medications, and provide enabled messaging between patient 4 and a clinician.

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

[0129] Fig. 9 is a flow chart illustrating an example technique for outputting recommendations for changing patient behavior in accordance with one or more techniques of this disclosure. Fig. 9 Relative to Figure 1 The medical device system 2 is described. However, Fig. 9 The techniques may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

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

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

[0132] Based on identifying the pattern of increased AF load, computing system 20 may output a request to identify a patient behavior (606). The patient behavior may be output for display by user interface 86 of external device 12. Computing system 20 may output a set of behaviors as a list. The list may present each behavior in the set of behaviors together with a user control that allows the user to select or deselect the corresponding behavior. In some examples, external device 12 may receive input not selecting any of the behaviors. In some examples, external device 12 may receive input selecting one of the behaviors. In some examples, external device 12 may receive input selecting a combination of more than one of the behaviors. In some examples, external device 12 may receive input selecting all of the behaviors.

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

[0134] Computing system 20 may determine a recommendation to change patient behavior to attenuate the pattern of increased AF load (608). For example, when computing system 20 receives user input indicating one or more behaviors, computing system 20 may output a recommendation to change at least one behavior to attenuate future patterns of increased AF load. For example, consuming caffeine represents a behavior that may cause increased AF load. If patient 4 indicates that they consumed caffeine during a time period corresponding to a pattern of increased AF load, computing system 20 may output a recommendation to reduce or eliminate caffeine consumption. Computing system 20 may output the recommendation for display by external device 12 (610).

[0135] Fig.10 is a flow chart illustrating an example technique for monitoring AF burden following a recommendation to change patient behavior, in accordance with one or more techniques of the present disclosure. Fig.10 Relative to Figure 1 The medical device system 2 is described. However, Fig.10 The techniques of can be performed by different components of medical device system 2 or by additional or alternative medical device systems. In some examples, medical device system 2 can be performed Fig. 9 After the technology is implemented Fig.10 The medical device system 2 may be independent of Fig. 9 Technical Execution Fig.10 technology.

[0136] Computing system 20 may receive a response indicating that patient 4 accepts the first suggestion to change patient behavior (612). In some examples, the first suggestion to change patient behavior indicates that Fig. 9The first suggestion may be output in the technology of the present invention for display by the external device 12, but this is not required. The first suggestion may represent any suggestion presented to the patient 4 and accepted by the patient 4. In some examples, when the computing system 20 outputs a suggestion to change the patient's behavior, the suggestion may use a user control on the user interface to accept the suggestion. By indicating that the suggestion is accepted, the patient 4 may indicate an intention to change the behavior according to the suggestion.

[0137] Based on receiving the response, computing system 20 may determine AF load of patient 4 over a period of time (614). In some examples, the period of time may occur after patient 4 accepts the first suggestion to change patient behavior. That is, computing system 20 may determine AF load of patient 4 after accepting the suggestion to determine whether the suggestion to change patient behavior effectively addresses the increased AF load.

[0138] Computing system 20 may determine whether a pattern of increased AF load exists during a time period (616). If a pattern of increased AF load does not exist during the time period ("NO" at block 616), computing system 20 may determine that the first suggestion successfully mitigates the increased AF load (617). In some examples, computing system 20 identifies the pattern of increased AF load before outputting the first suggestion to change behavior. Computing system 20 may determine that the first suggestion to change behavior is effective based on determining that the pattern of increased AF load is attenuated or absent after accepting the suggestion to change behavior.

[0139] If there is a pattern of increased AF load during the time period ("yes" at box 616), computing system 20 may determine a second suggestion to change one or more patient behaviors (618). When the patient indicates an intent to take the first suggestion, but the pattern of increased AF load persists after accepting the first suggestion, computing system 20 may determine that the first suggestion was unsuccessful in attenuating or eliminating the pattern of increased AF load. In some cases, computing system 20 may select the second suggestion based on the most likely cause of the pattern of increased AF load. The first suggestion may be the most likely cause, but based on determining that the first suggestion is effective, computing system 20 may select the second suggestion to include the next most likely cause in addition to the first suggestion. Computing system 20 may output the suggestion (620) for display by user interface 86 of external device 12 (620).

[0140] Fig.11 is a flow chart illustrating an example technique for identifying a pattern of increased AF load in accordance with one or more techniques of this disclosure. Fig.11 Relative to Figure 1 The medical device system 2 is described. However, Fig.11The techniques may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

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

[0142] Computing system 20 may determine a time of day corresponding to each of the one or more occurrences (632). In some examples, the one or more occurrences may occur more frequently at certain times of the day. For example, for a first patient, the one or more occurrences may occur more frequently in the morning hours, while for a second patient, the one or more occurrences may occur more frequently in the evening hours. The first patient may drink coffee in the morning, resulting in an increased AF load, while the second patient may exercise in the evening, resulting in an increased AF load. Computing system 20 may determine the time of day corresponding to the occurrence of increased AF load in order to obtain pattern information.

[0143] Additionally or alternatively, computing system 20 may determine a severity for each of the one or more occurrences of increased AF load (634). The severity of the occurrence of increased AF load may include a duration of the occurrence or a magnitude of the occurrence. The duration may represent an amount of time that the patient's AF load remains above an AF load threshold. The magnitude may include a maximum AF load for the occurrence, a sum of AF load values ​​greater than the AF load threshold, or another calculation reflecting the level of increased AF load. Computing system 20 may identify a pattern of increased AF load based on the time of day corresponding to each occurrence and the severity of each occurrence (636).

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

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

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

[0147] Fig.13 is a flow chart illustrating an example technique for determining risk level of a health event based on AF load variability, in accordance with one or more techniques of the present disclosure. Fig.13 Relative to Figure 1 The medical device system 2 is described. However, Fig.13 The techniques may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

[0148] The variability of a patient's AF load over a time period may be an indicator of an increased risk of a health event. In some examples, the variability of AF load is a stronger indicator of an increased risk of a health event than one or more other AF load parameters (e.g., duration of occurrence of increased AF load, magnitude of occurrence of increased AF load). Therefore, it may be beneficial for computing system 20 to determine the variability of increased AF load over a time period in order to assess the risk level of patient 4 that the patient 4 will experience a health event.

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

[0150] The computing system 20 may calculate an AF load score for each time interval in a set of time intervals corresponding to the time period (714). For example, the time period may be decomposed into the set of time intervals. A continuous set of time intervals may include the time period. In some examples, the AF load score may represent a median AF load or a median AF load within the corresponding time interval. In some examples, the AF load score may represent a sum of AF load values ​​within the corresponding time interval. The computing system 20 may determine an AF score for each time interval in the set of time intervals such that the AF score for each time interval is comparable to the AF score for the entire time period.

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

[0152] Computing system 20 may determine a risk level for the patient based on the comparison (718). For example, by comparing the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the time period, computing system 20 may determine the extent to which the AF load of patient 4 varies over time. A higher level of variability may correspond to a higher risk level. A lower level of variability may correspond to a lower risk level.

[0153] Fig.14 is a flow chart illustrating an exemplary technique for determining a risk level for a health event based on one or more conditions specific to a patient, in accordance with one or more techniques of the present disclosure. Fig.14 Relative to Figure 1 The medical device system 2 is described. However, Fig.14 The techniques may be performed by different components of medical device system 2 or by additional or alternative medical device systems.

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

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

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

[0157] Fig.15 1 is a conceptual diagram illustrating a patient behavior inquiry screen 1000 for display on a user interface of a device according to one or more techniques of the present disclosure. Fig.15 As seen in FIG. 1 , screen 1000 includes a guidance message 1010 stating “Please select any activity you participated in between 7 AM and 10 AM.” Screen 1000 includes a first patient behavior 1020, a first user control 1021, a second patient behavior 1022, a second user control 1023, a third patient behavior 1024, a third user control 1023, a fourth patient behavior 1026, a fourth user control 1027, a fifth patient behavior 1028, and a fifth user control 1029. Screen 1000 includes a user control 1030 for submitting the selected patient behavior.

[0158] Patient behaviors 1020, 1022, 1024, 1026, 1028 may represent behaviors that may lead to an increased AF burden. A first patient behavior 1020 may include "consume caffeinated beverages," a second patient behavior 1022 may include "consume foods or beverages that are high in sodium," a third patient behavior 1024 may include "consume foods or beverages that are high in added sugar," a fourth patient behavior 1026 may include "participate in exercise," and a fifth patient behavior 1028 may include "consume foods or beverages that are high in potassium." Fig.15 In the example of FIG. 1 , the user control 1021 corresponding to the first patient behavior 1020 and the user control 1029 corresponding to the fifth patient behavior 1028 are selected, and the other user controls 1023, 1025, 1027 are deselected. This means that if the user control 1030 is selected, the device will send information indicating that the patient indicated "consumption of caffeinated beverages" and "consumption of food or beverages containing high potassium content" between 7AM and 10AM.

[0159] Fig.16 1 is a conceptual diagram illustrating a first suggestion screen 1100 for display on a user interface of a device according to one or more techniques of this disclosure. Fig.16 As seen in the first suggestion screen 1100, the first suggestion screen 1100 includes a first message 1110 stating "Consider changing your morning routine in the following ways: " and a second message 1120 stating "Consume no more than 5 milligrams (mg) of caffeine". The first message 1110 and the second message 1120 may present a suggestion to the patient to limit caffeine consumption. If the patient accepts the suggestion by selecting an "Accept" user control 1130, the device may send a message to the computing system 20 that the patient accepts the suggestion.

[0160] Fig.171 is a conceptual diagram illustrating a second suggestion screen 1200 for display on a user interface of a device according to one or more techniques of this disclosure. Fig.17 As seen in the second suggestion screen 1200, the second suggestion screen 1200 includes a first message 1210 stating "Consider changing your morning routine in the following ways: " and a second message 1220 stating "Avoid potassium consumption". The first message 1210 and the second message 1220 may present a suggestion to the patient to limit potassium consumption. If the patient accepts the suggestion by selecting the "Accept" user control 1230, the device may send a message to the computing system 20 that the patient accepts the suggestion.

[0161] Fig.18 is a graph showing parameter data for multiple patient parameters over a period of time surrounding a stroke event (time 0) in accordance with one or more techniques of the present disclosure. Fig.18 In the example shown, the patient parameters include patient activity parameters (daily living activities, related to the amount of patient movement exceeding a threshold during daytime hours), heart rate variability (HRV), nighttime heart rate, daytime heart rate, and AF time (or AF load). As can be seen in the example shown, in the days before the stroke, AF time and heart rate related parameters both increase while patient activity decreases.

[0162] Fig.19 is a graph showing time series values ​​of moving averages of parameter data of patient parameters according to one or more techniques of the present disclosure. Fig.19 In the example shown, the patient parameter is daily living activities, although similar techniques may be applied to any other patient parameter described herein. Fig.19 A technique for quantifying features associated with deviations of patient parameters from their baseline or trend is shown, which 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 (SMAs), and uses a 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 than the shorter-term SMA. Patient parameter values ​​that occur within a predetermined number of days of a health event (e.g., a stroke) may be identified. Under sample control, cases may be 1:1, and all offsets and covariates may be evaluated in one model. The monitoring system 222 may compare the goodness of fit of each variable (patient parameter) to determine the relative importance of the variable.

[0163] Fig. 20 is a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke, in accordance with one or more techniques of the present disclosure. Fig. 20The patient parameters in the example of are AF burden (AFB), daytime heart rate (DHR), daily living activities (ADL), nighttime heart rate (NHR) and heart rate variability (HRV). Fig. 20 The statistical significance shown is based on parameter data collected from multiple patients, including patients suffering from stroke. Fig. 20 As shown, AF burden was found to be a significantly better predictor of stroke than other patient parameters.

[0164] Experimental analysis showed that changes in AF burden occurred within the long-term trend (21+ days) before the stroke event. In the long term, AF burden can be considered a major predictor. More specifically, short-term trends in AF burden that are increasing within the long-term trend may indicate stroke. When acute, short-term changes are compared to the long-term trend, the predictive power of AF burden may be 4 times higher.

[0165] Fig.21 is another graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke, in accordance with one or more techniques of the present disclosure. Fig.21 Similar to Fig. 20 , but includes additional patient parameters. Specifically, Fig.21 These included history of AF, CHADS-VASc score, previous oral anticoagulant (prior_oac), and history of chronic kidney disease. Fig.21 Previous stroke was shown to be 13 times more important as a predictor of stroke than AF burden, but AF burden was the main predictor after CHADSVASc.

[0166] FIG. 22A to FIG. 22D is a graph illustrating the experimentally determined statistical significance of multiple patient parameters in predicting stroke in different patient populations, according to one or more techniques of the present disclosure. Fig.22A The statistical significance of multiple patient parameters in predicting stroke in patients with prior AF ablation is shown. Fig. 22B Statistical significance of multiple patient parameters in predicting stroke in patients with previous AF management is shown. Fig. 22C The statistical significance of multiple patient parameters in predicting stroke in patients with previous stroke is shown. Fig.22D The statistical significance of multiple patient parameters in predicting stroke in patients in whom AF was suspected but not confirmed was shown.

[0167] FIG. 23A to FIG. 23D is a graph showing the experimentally determined statistical significance of multiple patient parameters in predicting hospitalization (a subset of healthcare utilization) for different patient populations, in accordance with one or more techniques of the present disclosure. Fig.23AThe statistical significance of multiple patient parameters in predicting stroke in patients with prior AF ablation is shown. Fig. 23B Statistical significance of multiple patient parameters in predicting stroke in patients with previous AF management is shown. Fig.23C The statistical significance of multiple patient parameters in predicting stroke in patients with previous stroke is shown. Fig.23D The statistical significance of multiple patient parameters in predicting stroke in patients in whom AF was suspected but not confirmed was shown.

[0168] Fig.24 is a graph showing an analysis of AF load pattern characteristics for predicting stroke and healthcare utilization (HCU) in accordance with one or more techniques of the present disclosure. The analysis shows that for both stroke and HCU, a surge in AF load (in some cases accompanied by lower patient activity levels) predicts events occurring within a certain time frame.

[0169] Fig.25A and Fig.25B 1 are graphs that respectively illustrate AF load patterns for patients experiencing a stroke or healthcare utilization event for different patient groups, according to one or more techniques of the present disclosure. Fig.25A and Fig.25B Those shown) signal subclinical changes indicative of a period of elevated risk for stroke and HCU.

[0170] A retrospective cohort study of patients with ICM was conducted (including Reveal LINQ TM The authors evaluated the incidence of HCU in the presence of cardiovascular disease (CVD) and cardiovascular syndrome (ICM) to determine whether rule-based algorithms that examined changes in baseline ICM parameters could be used to stratify the risk of short-term HCU. The occurrence of HCU as the study endpoint was obtained from de-identified claims data. Patients were flagged as having an HCU if their claims history included at least one encounter with a cardiovascular DRG or diagnosis code in an inpatient or outpatient hospital, emergency department, or ambulatory surgery center. If a patient had multiple HCU encounters, the first HCU occurrence was recorded.

[0171] The ICM-based diagnostic parameters evaluated in the study included the daily total AT / AF burden (milliseconds / day), total patient activity (e.g., time of patient supra-threshold exercise (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 prior to the event. Patients with no AT / AF time detected by any device during the two-year follow-up period were excluded from the cohort.

[0172] 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 the study, the offset SMA a_b denotes the SMA a and the difference between 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 .

[0173] Fig.26 is a graph showing the AT / AF time (burden) detected during the course of a monitoring period according to one or more techniques of the present disclosure. The vertical lines show the AF burden (AT / AF time) of the sub-periods (days in this example) during which the patient experienced AT / AF. Fig.26 The graph of also includes three trend lines showing 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, respectively.

[0174] For the study, the occurrence of HCU was treated as 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 event was oversampled by labeling the five days prior to occurrence as events. For patients who experienced HCU, the follow-up ended on the day prior to the event to prevent the use of device measurements taken on the day of the event, which would introduce look-ahead bias in the modeling. For each bootstrap iteration:

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

[0176] 2. For the training set, undersample the number of unlabeled days to be equal to the number of labeled days.

[0177] 3. Classification trees using 10-fold cross validation were fit to a balanced training set.

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

[0179] 5. The split information of the model fit in step 4 has been saved.

[0180] 6. Classify the imbalanced validation set using the model fit in step 4.

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

[0182] 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 and validation sets. If a node has multiple splits, each split is saved as a separate entry. In this case, the utilization rate and patient count will be the same for all splits in each node.

[0183] Scatter plots of the decision tree terminal nodes showing the relationship between labeled HCU rates and percentage of patients were used to identify patterns in the AF burden classification tree structure that will stratify the risk of healthcare events. The algorithm to define these patterns is:

[0184] 1. Visually identify areas of local maxima in the percentage of patients in the scatter plot.

[0185] 2. If the region is unique for AT / AF events, define the rectangular coordinates of the event risk and percentage of patients that enclose the region.

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

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

[0188] ii. Subtract 0.01 from the lower limit of the percentage of patients.

[0189] iii. Set the lower and upper bounds of the event rate to the corresponding positions where the scatter plot intersects the lower bound of the percentage of patients defined in the previous step.

[0190] 4. Select the nodes within the rectangular area.

[0191] 5. Group by pairs [predictor name, comparison].

[0192] 6. Calculate the number of times each pair was selected, the number of times each pair was selected as a percentage of all bootstrapped classification trees, and the mean of the [index] values.

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

[0194] 8. Sort the 3-tuples [predictor, comparison, mean index value] in descending order by selection rate.

[0195] 9. Identify the elbow in the selectivity (ie, where the selectivity drops by approximately 50%).

[0196] 10. Define the AF load pattern as the 3-tuple with a selectivity higher than the elbow point identified in the previous step.

[0197] Descriptive analyses and tests of equal proportions were performed to compare odds ratios of AF burden patterns with clinically relevant thresholds for duration and number.

[0198] The bootstrap routine was run 3,000 times to create an equal number of classification trees. Fig. 27 A scatter plot of 50,751 terminal nodes of labeled HCU rates and percentage of patients according to balanced training data according to one or more techniques of the present disclosure 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 nighttime heart rate>80 beats / minute), a single node can be represented across diagnostic parameters. Three local maxima are identified and represented as shaded areas A, B, and C. Missing (A and C) or infrequent (B) nodes for daily activity and heart rate parameters indicate that these areas are primarily defined by AT / AF time.

[0199] Region D is derived from the analysis of regions A, B, and C and is defined later in the Results.

[0200]

[0201]

[0202] Table 2 (above) presents a summary of the top five splits by region. Splits with selection rates above their corresponding elbow points are shown in bold. These highlighted splits collectively 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 greater than about 1 second and an AF load of about 21 days SMA greater than its historical average. This pattern is present in 25% of the decision trees and describes a relative spike or increasing trend in daily AF load. Pattern B is defined by an AF load CMA greater than about 1 second, but unlike pattern C, it has a reduced AF load 21-day SMA less than its historical average. The increased 1-day SMA (daily load) relative to the 21-day SMA indicates that pattern C signals a sporadic period of below-average load relative to the patient, which may occur after a period of elevated load.

[0203] Fig.28 An exemplary graphical illustration of these patterns in AF load data mapped for a single HCU patient according to one or more techniques of the present disclosure is presented. Labeled HCU rates and patient percentages were calculated based on training data for AF load amount and duration thresholds. The amount threshold was defined as a daily AF load greater than 5% (72 minutes); the duration threshold was defined as continuous AF greater than one hour. For the corresponding thresholds, the log odds event rates were 0.369 and 0.386, respectively, and the patient percentages were 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 was greater than 0.369 and the patient percentage was 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, which was not statistically different from the other log odds ratios (Poisson regression, p>0.5 for all threshold coefficients).

[0204] Atrial fibrillation (AF) may be associated with an increased risk of healthcare utilization (HCU), which may be triggered by an episode of AF or a change in AF burden. Changes from baseline in AF burden or other parameters measured by an insertable cardiac monitor (ICM) may be used to predict near-term HCU. One or more ICM parameters may be used to estimate the risk of near-term HCU.

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

[0206] AF load patterns revealed distinct groups: (A) no history of AF (reference); (B) below average load; (C) above average load; (D) above average load with low levels of daily activity detected by ICM. The advantage of HCU increased in all groups relative to reference (B vs AOR 3.82; C vs AOR 8.25; D vs AOR 11.66), including a 33% (212 / 644) increase in HCU detections at both nominal duration and number thresholds.

[0207]

[0208] Table 3

[0209] Table 3 includes the AF burden thresholds for groups A, B, C, and D. Analysis of baseline changes in ICM-detected AF and ICM-detected daily activity may be strongly associated with recent HCU, especially high burden combined with low activity.

[0210] Fig.29 A scatter plot of terminal nodes of HCU rates and patient percentage scores according to labels of an unbalanced validation set according to one or more techniques of the present disclosure is presented. The overall distribution is similar in shape to the training data ( Fig. 27 ). Different color shading shows different threshold patterns, where the lightest shaded points represent nodes not covered by the pattern. The AF load pattern (AC) provided broad coverage of the terminal node distribution, with clear demarcation of event risk (B vs. A, odds ratio (OR) 3.82, 95% CI 3.59-4.07; C vs. A, OR 8.25, 95% CI 7.84-8.69). Including a daily activity threshold (D) provided more specific coverage, with HCU at greatest risk in the AF load pattern (D vs. A, OR 11.66, 95% CI 10.63-12.79).

[0211] Fig.30A Venn diagram of AF burden threshold counts for the validation set is presented. Table 4 (below) presents statistics for each threshold and mutually exclusive subsets thereof according to one or more techniques of the present disclosure. Approximately 32% (6,594 / 20,858) of the Mode D threshold were mutually exclusive with the number and duration thresholds and represented a 33% (212 / 644) increase in event capture rate. Testing for differences in odds ratios using Poisson regression showed that the intersection coefficients for all three thresholds were statistically significant (p<0.10); the remaining coefficients were not statistically different (p>0.10 for all coefficients). Approximately 23% of patients experienced only the Mode D threshold, with an expected follow-up rate of 18.2%, or 66 days per year.

[0212]

[0213] In Table 4, counts represent the number of times the threshold was met; events, the number of labeled HCUs; odds, the ratio of event counts to threshold counts divided by the group mean event rate of the validation set; patients, the number of patients who met the threshold on at least one day as a percentage of the total number of patients in the validation set; and follow-ups, the number of days that met the threshold as a percentage of the total number of follow-up days for patients who experienced the threshold at least once. Note: Counts for each follow-up day are mutually exclusive, not counts by patient. Patients may experience different thresholds during follow-up. Therefore, patient and follow-up percentages will not sum to 100%.

[0214] Analysis of AF load patterns in the study confirmed a correlation between increasing load and risk, and more specifically, an increasing trend in AF load (e.g., daily) over time was associated with a greater risk of HCU, especially when accompanied by a decrease in daily activity. Patterns with AF load amounts less than about 1 hour predicted health care events comparable to number and duration thresholds greater than 1 hour. AF load patterns demonstrated additional event capture that supplemented number and duration thresholds. AF load as a risk factor for HCU was related to the patient's historical load.

[0215] The study shows values ​​of AF load 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 AF load may include AF load pattern features, such as changes (e.g., spikes or increases) in AF load relative to the trend of total AF load. For example, AF load pattern features may include one or more offsets between SMAs for different look-back periods and / or between SMA and CMA for a look-back period. As described herein, models to which such features are applied may be machine learning or rule-based, for example, involving decision trees and / or thresholds.

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

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

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

[0219] The following examples are a non-limiting list of clauses in accordance with one or more techniques of the present disclosure.

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

[0221] Embodiment 1. A medical device system, the medical device system comprising: a memory; and a processing circuit in communication with the memory, wherein 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 based on physiological signals of the patient sensed by the one or more sensing devices; determine an atrial fibrillation (AF) load of the patient within a time period based on the parameter data, wherein the AF load of the patient within the time period includes a pattern of increased AF load; output a request for display by a user device operated by the patient, the request being used to identify whether the patient engages in each patient behavior in a set of patient behaviors during the time period; based on receiving a response indicating that the patient engages in one or more patient behaviors in the set of patient behaviors,

[0222] determining a recommendation for changing at least a subset of the one or more patient behaviors to attenuate the pattern of increased AF load; and outputting the recommendation for display by the user device operated by the patient.

[0223] Embodiment 2. A medical device system according to embodiment 1, wherein the time period is a first time period, wherein the suggestion is a first suggestion, and wherein the processing circuit is further configured to: receive a response from the user device indicating that the patient accepts the suggestion to change at least the subset of the one or more patient behaviors; determine the AF load of the patient in a second time period based on the parameter data, wherein the second time period occurs after the response indicating that the patient accepts the suggestion to change; analyze the AF load of the patient in the second time period to determine whether there is a pattern of increased AF load during the second time period; based on determining that there is a pattern of increased AF load during the second time period, determine a second suggestion to change at least the subset of the one or more patient behaviors; and output the second suggestion for display by the user device operated by the patient.

[0224] Example 3. A medical device system according to any one of Examples 1 to 2, wherein in order to output the request to identify whether the patient engaged in each patient behavior in the set of patient behaviors during the time period, the processing circuit is configured to output a list of the set of patient behaviors, wherein each patient behavior in the set of patient behaviors is associated with a user control configured to select or deselect the corresponding patient behavior.

[0225] Example 4. A medical device system according to any one of Examples 1 to 3, wherein in order to determine the recommendation to change at least the subset of the one or more patient behaviors, the processing circuit is configured to: identify the likelihood that each of the one or more patient behaviors results in a pattern of increased AF load; and determine the recommendation to change at least the subset of the one or more patient behaviors based on the likelihood that each of the one or more patient behaviors results in a pattern of increased AF load.

[0226] Embodiment 5. A medical device system according to any one of Embodiments 1 to 4, wherein the patient behavior set includes one or more of the following: consumption of one or more foods, consumption of one or more beverages, and one or more patient motor activities.

[0227] Embodiment 6. A medical device system according to any one of embodiments 1 to 5, wherein the processing circuit is further configured to identify in the parameter data a pattern of the increased AF load within the time period, wherein in order to identify the pattern of the increased AF load, the processing circuit is configured to: identify one or more occurrences of the increased AF load within the time period, wherein each of the one or more occurrences includes an event in which the AF load of the patient exceeds an AF load threshold for greater than a threshold duration; determine a time of day corresponding to each of the one or more occurrences;

[0228] And determining that one or more occurrences of the increased AF load occur at one or more times of the day.

[0229] Example 7. A medical device system according to Example 6, wherein the processing circuit is further configured to select the patient behavior set for output to the user device based on one or more times of the day when one or more occurrences of the increased AF load may occur.

[0230] Embodiment 8. A medical device system, comprising: a memory; and a processing circuit that communicates with the memory, wherein the processing circuit is configured to: receive parameter data of multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine an atrial fibrillation (AF) load of the patient within a time period based on the parameter data; apply the AF load of the patient within the time period to a model; and determine the risk level of a health event of the patient based on the application of the model to the AF load of the patient within the time period.

[0231] Example 9. A medical device system according to Example 8, wherein in order to apply the AF load of the patient within the time period to the model, the processing circuit is configured to: calculate an AF load score corresponding to the time period; calculate an AF load score corresponding to each time interval in a set of time intervals within the time period; and compare the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the time period, and wherein the processing circuit is configured to determine the risk level of the health event of the patient based on comparing the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the time period.

[0232] Example 10. A medical device system according to Example 9, wherein in order to compare the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the time period, the processing circuit is configured to: determine the difference between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the time period; and based on the difference between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the time period, determine an AF load deviation score indicating the degree to which the AF load of the patient deviates from the baseline AF load.

[0233] Embodiment 11. A medical device system according to embodiment 10, wherein in order to determine the AF load deviation score, the processing circuit is configured to calculate the sum of each difference between the AF load score corresponding to each time interval in the set of time intervals and the AF load score corresponding to the time period.

[0234] Embodiment 12. The medical device of any one of Embodiments 9 to 11, wherein the duration of each time interval in the set of time intervals is 24 hours.

[0235] Embodiment 13. A medical device system according to any one of embodiments 8 to 12, wherein

[0236] In order to apply the AF load of the patient during the time period to the model, the processing circuit is configured to: identify a set of time intervals within the time period; and determine the amount of time of each time interval during the set of time intervals when the AF load of the patient is greater than an AF load threshold, and wherein the processing circuit is configured to determine the risk level of the health event of the patient based on the amount of time of each time interval during the set of time intervals when the AF load of the patient is greater than the AF load threshold.

[0237] Example 14. A medical device system according to any one of Examples 8 to 13, wherein in order to apply the AF load of the patient during the time period to the model, the processing circuit is configured to: identify one or more occurrences in which the AF load of the patient is greater than an AF load threshold during the time period; and determine the duration of each of the one or more occurrences, and wherein the processing circuit is configured to determine the risk level of the health event of the patient based on the amount of time of each time interval in which the AF load of the patient is greater than the AF load threshold during the set of time intervals.

[0238] Embodiment 15. A medical device system according to any one of Embodiments 8 to 14, 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.

[0239] Embodiment 16. The medical device system of any one of Embodiments 8 to 15, wherein the risk level comprises a risk that the health event will occur within a predetermined time period.

[0240] Embodiment 17. A medical device system, comprising: a memory; and

[0241] A processing circuit in communication with the memory, wherein the processing circuit is configured to: receive parameter data of multiple parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determine a set of parameters for the patient over a time period based on the parameter data; receive information indicating one or more conditions specific to the patient; set a weight corresponding to each parameter in the set of parameters based on the one or more conditions specific to the patient; apply the set of parameters for the patient over the time period to a model; and determine a risk level for a health event for the patient based on the application of the model to the set of parameters over the time period.

[0242] Embodiment 18. The medical device system of Embodiment 17, wherein the one or more conditions specific to the patient include prior medical procedures performed on the patient.

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

[0244] Embodiment 20. A medical device system according to any one of embodiments 17 to 18, wherein

[0245] The one or more conditions specific to the patient include one or more medications taken by the patient.

Claims

1. A medical device system, comprising: Memory; and a processing circuit in communication with the memory, wherein the processing circuit is configured to: receiving parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determining an atrial fibrillation (AF) burden of the patient over a time period based on the parameter data, wherein the AF burden of the patient over the time period includes a pattern of increased AF burden; outputting a request for display by a user device operated by the patient, the request for identifying whether the patient engaged in each patient behavior in a set of patient behaviors during the time period; determining, based on receiving a response indicating that the patient engages in one or more patient behaviors of the set of patient behaviors, a recommendation to change at least a subset of the one or more patient behaviors to attenuate the pattern of increased AF load; as well as The recommendation is output for display by the user device operated by the patient.

2. The medical device system of claim 1 , wherein the time period is a first time period, wherein the recommendation is a first recommendation, and wherein the processing circuit is further configured to: receiving a response from the user device indicating that the patient accepts the recommendation to change at least the subset of the one or more patient behaviors; determining an AF burden of the patient over a second time period based on the parameter data, wherein the second time period occurs after the response indicating that the patient accepts the recommendation for change; analyzing the AF burden of the patient during the second time period to determine whether a pattern of increased AF burden exists during the second time period; determining a second recommendation to change at least the subset of the one or more patient behaviors based on determining that the pattern of increased AF load exists during the second time period; as well as The second suggestion is output for display by the user device operated by the patient.

3. A medical device system according to any one of claims 1 to 2, wherein in order to output the request to identify whether the patient engaged in each patient behavior in the set of patient behaviors during the time period, the processing circuit is configured to output a list of the set of patient behaviors, wherein each patient behavior in the set of patient behaviors is associated with a user control configured to select or deselect the corresponding patient behavior.

4. The medical device system of any one of claims 1 to 3, wherein to determine the recommendation to change at least the subset of the one or more patient behaviors, the processing circuit is configured to: identifying a likelihood that each of the one or more patient behaviors results in a pattern of increased AF burden; and The recommendation to change at least the subset of the one or more patient behaviors is determined based on the likelihood that each of the one or more patient behaviors results in the pattern of increased AF burden.

5. The medical device system of any one of claims 1 to 4, wherein the patient behavior set comprises one or more of: consumption of one or more foods, consumption of one or more beverages, and one or more patient motor activities.

6. The medical device system of any one of claims 1 to 5, wherein the processing circuit is further configured to identify in the parameter data a pattern of the increased AF load over the time period, wherein to identify the pattern of the increased AF load, the processing circuit is configured to: identifying one or more occurrences of increased AF load during the time period, wherein each of the one or more occurrences comprises an event in which the AF load of the patient exceeds an AF load threshold for greater than a threshold duration; determining a time of day corresponding to each of the one or more occurrences; as well as It is determined that the one or more occurrences of increased AF load occur at one or more times of the day.

7. A medical device system according to claim 6, wherein the processing circuit is further configured to select the patient behavior set for output to the user device based on one or more times of the day when one or more occurrences of the increased AF load may occur.

8. A medical device system, comprising: Memory; and a processing circuit in communication with the memory, wherein the processing circuit is configured to: receiving parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determining an atrial fibrillation (AF) burden of the patient over a period of time based on the parameter data; applying the AF burden of the patient during the time period to a model; as well as A risk level for a health event for the patient is determined based on the application of the model to the patient's AF burden over the time period.

9. The medical device system according to claim 8, Wherein, in order to apply the AF burden of the patient during the time period to the model, the processing circuit is configured to: calculating an AF load score corresponding to the time period; calculating an AF load score corresponding to each time interval in a set of time intervals within the time period; and The AF load score corresponding to each time interval in the set of time intervals is compared with the AF load score corresponding to the time period, and wherein the processing circuit is configured to determine the risk level of the health event of the patient based on comparing the AF load score corresponding to each time interval in the set of time intervals with the AF load score corresponding to the time period.

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

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

12. The medical device according to any one of claims 9 to 11, wherein the duration of each time interval in the set of time intervals is 24 hours.

13. The medical device system according to any one of claims 8 to 12, Wherein, in order to apply the AF burden of the patient during the time period to the model, the processing circuit is configured to: identifying a set of time intervals within the time period; and determining an amount of time during each time interval during which the AF burden of the patient is greater than an AF burden threshold, and Wherein the processing circuit is configured to determine the risk level of the health event of the patient based on the amount of time of each time interval during the set of time intervals that the AF load of the patient is greater than the AF load threshold.

14. A medical device system, comprising: Memory; and a processing circuit in communication with the memory, wherein the processing circuit is configured to: receiving parameter data of a plurality of parameters of a patient, wherein the parameter data is generated by one or more sensing devices based on physiological signals of the patient sensed by the one or more sensing devices; determining a set of parameters for the patient over a period of time based on the parameter data; receiving information indicative of one or more conditions specific to the patient; setting a weight corresponding to each parameter in the set of parameters based on the one or more conditions specific to the patient; applying the set of parameters for the patient during the time period to a model; and A risk level for a health event for the patient is determined based on the application of the model to the set of parameters over the time period.