Method and apparatus for managing processing activity patterns
By introducing a task processing characteristic monitoring circuit into the IMD, the CPU's task processing characteristics are monitored and compared with the baseline pattern, and unwanted changes are identified and managed. This solves the problems of increased CPU workload and premature battery wear in the IMD, and achieves extended battery life and early detection of failure modes.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- 先导者股份有限公司
- Filing Date
- 2021-04-06
- Publication Date
- 2026-05-12
AI Technical Summary
Existing implantable medical devices (IMDs) are prone to increased CPU workload and premature battery depletion due to unexpected or new failure modes when performing tasks. Traditional failure mode detection methods cannot effectively detect these new or unexpected failure modes.
By introducing task processing characteristic monitoring (TH) circuitry into the IMD, the CPU's task processing characteristics are monitored and compared with a baseline pattern to identify unwanted changes and implement corrective actions, such as providing alerts, terminating tasks, or restarting tasks, in order to manage the CPU's activity patterns.
It effectively detects and manages unwanted CPU activity patterns in IMD, reduces unexpected energy consumption, extends battery life, and provides early warnings to improve patient safety by promptly identifying potential firmware, hardware, or cybersecurity failures.
Smart Images

Figure CN113539463B_ABST
Abstract
Description
Technical Field
[0001] Embodiments of this disclosure generally relate to methods and apparatus for managing processing activity patterns of implantable medical devices. Background Technology
[0002] Modern implantable medical devices (IMDs) (e.g., implantable cardioverter defibrillators (ICDs)) are complex battery-powered systems with numerous components. IMDs must perform many complex tasks that may occur at any given time. Such tasks typically need to be completed within a limited timeframe. Examples of tasks requiring time-limited completion include performing sensing, pacing, recording and analyzing rhythms, diagnosing seizures and providing life-saving therapies based on the diagnosis, performing self-tests, and handling remote and short-range communications. Accordingly, IMDs require a central processing unit (CPU) capable of handling these tasks. To optimize task processing for real-time performance, IMD tasks are typically interrupt-based. For example, more time-critical tasks are processed within an interrupt context, while less time-critical tasks are queued as events to be executed outside the interrupt context when no further pending interrupts exist. Task processing within and outside the interrupt context are typically referred to as foreground processing and background processing, respectively.
[0003] An IMD's CPU consumes energy based on the amount of foreground and background processing tasks that need to be executed, thus affecting the IMD's battery life. Ideally, the battery should last for several years. To conserve energy, the CPU enters a "sleep mode" after completing queued tasks. The ratio of CPU runtime (e.g., time to complete all queued tasks) to total time (e.g., CPU runtime + CPU sleep time) represents the CPU's duty cycle. In IMD design, it is desirable to keep the average CPU duty cycle as low as possible (e.g., 10% or lower). Unintended and / or undesirable increases in duty cycle and / or task processing time consume additional energy, leading to premature battery depletion.
[0004] Furthermore, IMD employs detection capabilities specifically designed for known failure modes experienced by firmware, hardware, and network security. However, there is always a chance that IMD will experience unexpected or new failure modes that would otherwise be missed by traditional failure mode detection controls. During unexpected or new failure modes, due to unexpected code defects, hardware component failures, network security attacks, etc., the CPU is prone to operating at abnormally high duty cycles and / or with increased task processing times.
[0005] There is still a need for methods and devices to detect and manage the unexpected increase in IMD workload and task processing characteristics in order to mitigate potential firmware, hardware, or cybersecurity failures and / or premature battery drain. Summary of the Invention
[0006] According to embodiments herein, an implantable medical device (IMD) is provided. The IMD includes memory storing baseline task processing (TH) patterns and TH circuitry including one or more processors. The TH circuitry is configured to perform tasks associated with collecting one or more CA signals or environmental event signals. The TH circuitry analyzes one or more CA signals or environmental event signals, delivers therapy, detects communication requests, or maintains a communication session with an external device. The IMD monitors TH characteristics in conjunction with task performance, compares these TH characteristics to a baseline TH pattern, and implements corrective actions in response to the comparison between the TH characteristics and the baseline TH pattern.
[0007] Optionally, a corrective action may be implemented in response to the comparison indicating that the TH characteristic has deviated from the baseline TH pattern by more than a predetermined margin. The TH characteristic may represent at least one of the following: CPU TH time characteristic, CPU continuous active duration, CPU continuous sleep duration, workload measurement for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
[0008] Optionally, the TH characteristic may represent the CPU TH time characteristic for at least one of the following: i) the time to complete a type of sensing event analysis; ii) the time to complete a type of external input processing; iii) the time to prepare and deliver therapy; iv) the time to perform measurements; v) the time to collect and update diagnoses based on CA signals; vi) the time to complete housekeeping tasks; vii) the time to analyze incoming data packets; and viiii) the time to send outgoing data packets.
[0009] Optionally, the monitoring operation may include identifying the CPU duty cycle as part of the TH characteristic, and the comparison operation may include determining whether the CPU duty cycle indicates that the CPU is continuously active for at least a predetermined period of time. The CPU duty cycle may be determined as the average duty cycle over a first time period periodically over a longer second time period.
[0010] Optionally, the monitoring operations may include maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of selected critical tasks. The implemented operations may include at least one of the following: providing an alert, terminating an ongoing task or process, restarting a task or process, or restarting part or all of the process implemented by the IMD.
[0011] In another embodiment, a method is provided for managing processing activity patterns of an implantable medical device (IMD). The method stores a baseline task processing (TH) pattern and performs tasks associated with collecting one or more CA signals or environmental event signals. The method analyzes the one or more CA signals or environmental event signals, delivers therapy, detects communication requests, or maintains a communication session with an external device. The method monitors TH characteristics in conjunction with task execution, compares the TH characteristics to a baseline TH pattern, and implements corrective actions in response to the comparison between the TH characteristics and the baseline TH pattern.
[0012] Optionally, a corrective action may be implemented in response to the comparison indicating that the TH characteristic has deviated from the baseline TH pattern by more than a predetermined margin. The TH characteristic may represent at least one of the following: CPU TH time characteristic, CPU continuous active duration, CPU continuous sleep duration, duty ratio measurement of a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
[0013] Optionally, the TH characteristic may represent the CPU TH time characteristic for at least one of the following: i) the time to complete a type of sensing event analysis; ii) the time to complete a type of external input processing; iii) the time to prepare and deliver therapy; iv) the time to perform measurements; v) the time to collect and update diagnoses based on CA signals; vi) the time to complete housekeeping tasks; vii) the time to analyze incoming data packets; and viiii) the time to send outgoing data packets.
[0014] Optionally, the method may monitor operations including identifying the CPU's duty cycle as part of the TH characteristic, and the comparison operation may include determining whether the CPU's duty cycle indicates that the CPU is continuously active for at least a predetermined amount of time. The CPU's duty cycle may be determined as the average duty cycle over a first time period periodically over a longer second time period.
[0015] Optionally, the monitoring operations may include maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of selected critical tasks. The implemented operations may include at least one of the following: providing an alert, terminating an ongoing task or process, restarting a task or process, or restarting part or all of the process implemented by the IMD.
[0016] According to embodiments herein, a computer program product is provided. This computer program product includes a non-transitory computer-readable storage medium containing computer-executable code to perform tasks associated with one or more of the following: collecting CA signals, analyzing CA signals, delivering therapy, detecting communication requests, and maintaining a communication session with an external device. The computer program product combines the performance of these tasks to monitor TH characteristics, compare TH characteristics with a baseline TH pattern, and implement corrective actions in response to the comparison between the TH characteristics and the baseline TH pattern.
[0017] Optionally, a corrective action may be implemented in response to the comparison indicating that the TH characteristic has deviated from the baseline TH pattern by more than a predetermined margin. The TH characteristic may represent at least one of the following: CPU task processing time characteristics, CPU continuous active duration, CPU continuous sleep duration, workload measurement for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
[0018] Optionally, the TH characteristic may represent the CPU TH time characteristic for at least one of the following: i) the time to complete a type of sensing event analysis; ii) the time to complete a type of external input processing; iii) the time to prepare and deliver therapy; iv) the time to perform measurements; v) the time to collect and update diagnoses based on CA signals; vi) the time to complete housekeeping tasks; vii) the time to analyze incoming data packets; and viiii) the time to send outgoing data packets. Attached Figure Description
[0019] Figure 1 An IMD and external device coupled to and implemented in a patient’s heart according to an embodiment of this document are shown.
[0020] Figure 2 An embodiment according to this article is shown. Figure 1 A block diagram of the IMD.
[0021] Figure 3 An architectural block diagram illustrating examples of various features, services, and frameworks that can be implemented by the IMD hardware platform according to embodiments herein is shown.
[0022] Figure 4 The characteristicization process for determining and storing TH characteristics according to embodiments herein is illustrated.
[0023] Figure 5 The process for managing IMD processing activity modes according to embodiments herein is illustrated.
[0024] Figure 6An example of a process for monitoring CPU behavior to identify unwanted changes in TH mode, according to embodiments of this document, is shown. Detailed Implementation
[0025] It will be readily understood that, in addition to the exemplary embodiments described herein, the components of the embodiments generally described and illustrated in the accompanying drawings can be arranged and designed in a wide variety of different configurations. Therefore, the following more detailed description of the exemplary embodiments illustrated in the figures is not intended to limit the scope of the claimed embodiments, but merely to represent exemplary embodiments.
[0026] Throughout this specification, the reference to "an embodiment" or "an embodiment" (etc.) means that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment. Therefore, the appearance of phrases such as "in one embodiment" or "in an embodiment" throughout various places in this specification does not necessarily refer to the same embodiment.
[0027] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of the embodiments. However, those skilled in the art will recognize that various embodiments can be practiced without one or more of the specific details, or using other methods, components, materials, etc. In other instances, well-known structures, materials, or operations have not been shown or described in detail to avoid confusion. The following description is intended merely by way of example and simply illustrates certain exemplary embodiments.
[0028] The methods described herein may take the structure or aspects of various embodiments (e.g., systems and / or methods) discussed herein. In various embodiments, certain operations may be omitted or added, certain operations may be combined, certain operations may be performed simultaneously, certain operations may be performed in parallel, certain operations may be split into multiple operations, certain operations may be performed in different orders, or certain operations or a series of operations may be re-executed iteratively. It should be noted that other methods may be used according to the embodiments herein. Furthermore, as indicated, these methods may be implemented wholly or partially by one or more processors in one or more devices or systems. While the operation of some methods may be described as being performed by one or more processors of a device(s), additionally, some or all of such operations may be performed by one or more processors of another device(s) described herein.
[0029] the term
[0030] The term "task" should be understood as a predefined operation to be performed by the medical device during its lifetime. Predefined operations can be combined with therapies, signal monitoring, signal analysis, communication with other devices, self-diagnostics, internal maintenance, etc. Non-limiting examples of tasks include reforming capacitors, delivering shocks or other therapies, performing telemetry operations, sending and receiving RF communications, and performing anticipated self-discharge (approximately 1% per year), etc.
[0031] The terms “task processing characteristics” and “TH characteristics” should refer to attributes of a medical device that can be measured in conjunction with the performance of one or more tasks. Non-limiting examples of TH characteristics include CPU TH time characteristics, CPU continuous active duration (e.g., the duration during which the CPU is continuously active and executing tasks in a queue), CPU continuous sleep duration (e.g., the duration during which the CPU is continuously inactive / in sleep mode and not performing any tasks), workload measurement for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, execution time of task groups, and so on. Additionally or alternatively, TH time characteristics may include one or more of the following: i) the time to complete a type of sensor event analysis; ii) the time to complete a type of external input processing; iii) the time to prepare and deliver a therapy (e.g., V-pulse); iv) the time to perform measurements (e.g., impedance measurements, battery charging measurements, etc.); v) the time to collect and update diagnoses based on cardiac activity (CA) signals; vi) the time to complete housekeeping tasks; viii) the time to analyze incoming data packets; and ix) the time to send outgoing data packets; and so on.
[0032] The terms “processing activity pattern,” “task processing pattern,” and “TH pattern” should refer to a pattern of one or more TH characteristics associated with one or more completed tasks over a period of time. A TH pattern may include trends of one or more TH characteristics measured over a period of time. For example, a TH pattern may include histograms of one or more TH characteristics associated with one or more tasks (e.g., histograms of wait times and / or execution times associated with tasks).
[0033] The term "work ratio" should refer to the amount / percentage of time the CPU is active and / or running tasks within a time period of interest. For example, a work ratio of 50% would indicate that half of the total time (e.g., CPU active time plus CPU inactive / sleeping time) within the corresponding time period of interest is active (e.g., running one or more tasks). The CPU's work ratio can be determined as the average work ratio over a first time period periodically over a longer second time period. For example, the average work ratio can be determined as the average of the work ratios for each 30-minute interval over a 23-hour period.
[0034] The term "foreground process" should be understood as a process handled by the CPU in an interrupt context. Processes handled in an interrupt context can be executed on a priority-ordered basis, prior to the completion of processes with lower priority. Processes specified for handling in an interrupt context include time-critical tasks and / or tasks that need to be completed with limited latency. Examples of foreground processes include those implemented in conjunction with the delivery of therapeutic drugs, communication with other devices, signal analysis, etc.
[0035] The term "background process" should be understood as a process that is processed outside of an interrupt context. Processes processed outside of an interrupt context may / can be executed on a non-priority basis, and / or may be executed when no foreground processes remain to be executed. Processes specified for processing outside of an interrupt context include non-time-critical tasks and / or tasks that do not require completion with limited latency. Examples of background processes include those that are performed in conjunction with monitoring signals, self-diagnostics, internal maintenance, etc.
[0036] System Overview
[0037] The embodiments described herein depict novel methods and systems for monitoring and / or detecting unwanted CPU activity patterns. These methods and systems can terminate and / or restart tasks and / or processes and / or provide alerts to users, thereby enabling appropriate actions to be taken to manage IMDs based on the detection of unwanted CPU activity patterns. The methods and systems described herein offer significant value by monitoring CPU activity patterns as a general yet powerful complementary detection strategy to indirectly identify potential faults in the firmware, hardware, or cybersecurity of IMDs.
[0038] Furthermore, embodiments of this document provide methods and systems for monitoring and / or detecting unwanted CPU activity patterns (e.g., by monitoring CPU duty cycle) to provide early detection of rare and / or unexpected events. For example, the early stages of lead breakage or insulation failure may not cause an impedance change that triggers alarm generation. However, the early stages of lead breakage or insulation failure can generate low-level noise on the sensing channel. This low-level noise can repeatedly activate noise detection features without reaching the threshold required to trigger an actual noise response. In such cases, the methods and systems of this document enable the detection of an increase in duty cycle due to repeated activation of noise detection features caused by low-level noise, thereby providing a valuable early warning of deteriorating lead conditions. In another example, a fault in the firmware may repeatedly insert the same task into the task queue (e.g., based on a communication session ending prematurely due to a patient leaving an external device during the session), creating spurious tasks that do not interrupt other tasks but do cause an unwanted increase in CPU activity patterns. In response to the detection of an increased CPU activity pattern, the systems and methods of this document provide detection and termination of spurious or recurring tasks. In another example, a hacker might repeatedly attempt to break into the IMD after failing. Since all attack attempts have failed, traditional network security controls implemented in the IMD may not raise an alarm. However, such repeated hacking attempts may cause undesirable CPU activity patterns (e.g., an abnormal increase in workload) due to the detectable attempts to wake up / ping the IMD by this method and system. Additionally or alternatively, such repeated hacking attempts may cause the device to attempt to process communications detectable by this method and system. In response to the detection of unwanted CPU activity patterns, this method and system can detect the hacking attempts and provide corresponding alarms.
[0039] This document also provides innovative methods and systems for detecting undesirable changes in TH characteristics. Non-limiting examples of TH characteristics include TH time characteristics, increased workload ratio, etc. In response, the methods and systems can provide alerts to users, terminate ongoing tasks or processes, restart tasks or processes, restart all or part of processes implemented by the device, etc. For example, during product development, developers can measure various task processing time characteristics (such as queue waiting time, execution time and execution frequency, and overall CPU workload ratio). These results can be stored for the device to use as reference or baseline TH characteristics. During post-implantation IMD operation, the IMD can continuously, periodically, or in response to a certain criterion when it encounters and / or responds to various types of events and provides information about therapy. Event types can include cardiac input, environmental events, communication tasks, etc. When it is determined that the TH characteristic deviates from the baseline TH characteristic by more than a predetermined margin, the IMD determines that the CPU is experiencing an undesirable change in task processing. In response, the IMD can then generate an alert and send it to local external devices and / or remote monitoring devices or servers to draw the attention of care providers. During subsequent clinical sessions, the IMD can provide a detailed description of the TH characteristics of task processing changes. This information can be reviewed along with other diagnostic data (e.g., pacing event histograms, environmental events, etc.) to help care providers identify potential problems to improve patient safety. Additionally or alternatively, in response to the determination that non-critical tasks are causing an undesirable and / or unacceptable increase in workload ratio, the methods and systems described herein provide a workload monitoring task manager that can terminate and / or reset non-critical tasks.
[0040] Embodiments may be implemented in conjunction with one or more implantable medical devices (IMDs). Non-limiting examples of IMDs include one or more of neurostimulator devices, implantable leadless monitoring and / or treatment devices, and / or alternative implantable medical devices. For example, an IMD may represent a cardiac monitoring device, pacemaker, cardioverter-defibrillator, rhythm management device, defibrillator, neurostimulator, leadless monitoring device, leadless pacemaker, etc. For example, an IMD may include one or more structural and / or functional aspects of the devices described in U.S. Patent 9,333,351 entitled "Neurostimulation Method and System To Treat Apnea" and U.S. Patent 9,044,610 entitled "System and Methods For Providing A Distributed Virtual StimulationCathode For Use With An Implantable Neurostimulation System," which are incorporated herein by reference in their entirety. Additionally or alternatively, an IMD may include one or more structural and / or functional aspects of the devices described in U.S. Patent 9,216,285 entitled "Leadless Implantable Medical Device Having Removable and Fixed Components" and U.S. Patent 8,831,747 entitled "Leadless Neurostimulation Device And Method Including The Same," which are incorporated herein by reference in their entirety. Additionally or alternatively, an IMD may include one or more structural and / or functional aspects of the devices described in U.S. Patent 8,391,980 entitled "Method And System For Identifying A Potential Lead Failure In An Implantable Medical Device" and U.S. Patent 9,232,485 entitled "System And Method For Selectively Communicating With An Implantable Medical Device," which are incorporated herein by reference in their entirety.
[0041] Additionally or alternatively, an IMD may be a subcutaneous IMD, including one or more structural and / or functional aspects of the devices described in U.S. Application Serial No. 15 / 973,195, filed May 7, 2018, entitled “Subcutaneous Implantation Medical Device With Multiple Parasternal-Anterior Electrodes”, U.S. Application Serial No. 15 / 973,219, filed May 7, 2018, entitled “Implantable Medical Systems And Methods Including Pulse Generators And Leads”, and U.S. Application Serial No. 15 / 973,249, filed May 7, 2018, entitled “Single Site Implantation Methods For Medical Devices Having Multiple Leads”, which are incorporated herein by reference in their entirety.
[0042] Additionally or alternatively, the IMD may be a leadless cardiac monitor (ICM), including U.S. Patent Application No. 15 / 084,373, filed March 29, 2016, entitled "Method And System To Discriminate Rhythm Patterns In Cardiac Activity," U.S. Patent Application No. 15 / 973,126, entitled "Method And System To Detect R-Wave In Cardiac Arrhythmic Patterns," U.S. Patent Application No. 15 / 973,351, entitled "Method And System To Detect Post Ventricular Contractions In Cardiac Arrhythmic Patterns," U.S. Patent Application No. 15 / 973,307, entitled "Method And System To Detect Noise In Cardiac Arrhythmic Patterns," and U.S. Patent Application No. 15 / 973,307, entitled "Method And System To Detect Noise In Cardiac Arrhythmic Patterns." One or more structural and / or functional aspects of the device described in U.S. Patent Application No. 16 / 399,813, entitled “Patterns,” are incorporated herein by reference in their entirety.
[0043] Furthermore, according to the embodiments described herein, one or more combinations of IMDs from the aforementioned incorporated patents and applications may be utilized.
[0044] Figure 1An IMD 100 and an external device 104, coupled to and implemented in a patient's heart according to embodiments herein, are illustrated. The external device 104 may be a programmer, external defibrillator, workstation, portable computer, personal digital assistant, mobile phone, bedside monitor, etc. The IMD 100 may represent a cardiac monitoring device, pacemaker, cardioreverter, rhythm management device, defibrillator, neurostimulator, leadless monitoring device, leadless pacemaker, etc., implemented according to an embodiment of the invention. The IMD 100 may be a dual-chamber stimulation device capable of treating rapid and slow arrhythmias using stimulation therapy (including cardioreversion, defibrillation, antitachycardia pacing, and pacing stimulation), and capable of detecting heart failure, assessing its severity, tracking its progression, and controlling the delivery of therapy and warnings in response. The IMD 100 may be controlled to sense waveforms of interest in the atria and ventricles, distinguish between waveforms of interest in two or more ventricles, deliver stimulation pulses or impulses, and suppress the application of stimulation pulses to the heart based on the distinction between waveforms of interest, etc. An exemplary structure of the IMD100 is discussed and illustrated in this figure.
[0045] The IMD 100 includes a housing 101 that connects to a head assembly 109, which houses socket connectors that connect to a right ventricular lead 110, a right atrial lead 112, and a coronary sinus lead 114, respectively. Leads 112, 114, and 110 measure cardiac signals from the heart. The right atrial lead 112 includes an atrial tip electrode 118 and an atrial loop electrode 120. The coronary sinus lead 114 includes a left atrial loop electrode 128, a left atrial coil electrode 130, and one or more left ventricular electrodes 132-138 (e.g., also referred to as P1, M1, M2, and D1) to form a multipolar LV electrode combination. The right ventricular lead 110 includes an RV tip electrode 126, an RV loop electrode 124, an RV coil electrode 122, and an SVC coil electrode 116. Leads 112, 114, and 110 detect IEMG signals that are processed and analyzed as described herein. Leads 112, 114, and 110 also deliver the therapy as described herein.
[0046] During implantation, external device 104 is connected to one or more of leads 112, 114, and 110 via temporary input 103. Input 103 of external device 104 receives IEGM signals from leads 112, 114, and 110 during implantation and displays these signals on a monitor for the physician. Alternatively, external device 104 may not be directly connected to leads 112, 114, and 110. Instead, IEGM ECG signals sensed by leads 112, 114, and 110 can be collected by IMD 100 and then wirelessly transmitted to external device 104. Thus, external device 104 receives IEGM ECG signals via telemetry circuitry input. The physician or another user controls the operation of external device 104 via a user interface.
[0047] Implantable medical devices
[0048] Figure 2 An embodiment according to this article is shown. Figure 1 A block diagram of the IMD 100 is provided. The IMD 100 can be implemented as a full-function biventricular pacemaker equipped with sensing and pacing circuitry for both the atria and ventricles for four-chamber sensing and stimulation therapy (including both pacing and pulse therapy). Optionally, the IMD 100 can provide full-function cardiac resynchronization therapy. Alternatively, the IMD 100 can be implemented with a reduced set of functions and components. For example, the IMD can be implemented without ventricular sensing and pacing.
[0049] The IMD 100 has a housing 101 for accommodating electronic / computing components. The housing 101 (which is generally referred to as a “can,” “shell,” “package,” or “shell electrode”) can be programmably selected as a return electrode for certain stimulation modes. The housing 101 also includes connectors (not shown) having multiple terminals 102, 105, 106, 108, and 111. These terminals can be connected to electrodes located at various locations within or around the heart. For example, the terminals may include: terminal 102 for coupling to a first electrode (e.g., a tip electrode) located in a first chamber; terminal 105 for coupling to a second electrode (e.g., a tip electrode) located in a second chamber; terminal 106 for coupling to an electrode (e.g., a loop electrode) located in the first chamber; terminal 108 for coupling to an electrode (e.g., a loop electrode) located in the second chamber; and terminal 111 for coupling to an electrode (e.g., a coil electrode) located in the SVC. The type and location of each electrode can vary. For example, the electrodes may include various combinations of loop, tip, coil, and impact electrodes.
[0050] The IMD 100 includes a programmable microcontroller 164 that controls various operations of the IMD 100, including cardiac monitoring and stimulation therapy. The microcontroller 164 includes one or more microprocessors or CPUs (or equivalent control circuitry), RAM and / or ROM memory, logic and timing circuitry, state machine circuitry, and I / O circuitry.
[0051] The IMD 100 also includes a first chamber pulse generator 174 that generates stimulation pulses for delivery by one or more electrodes coupled thereto. The pulse generator 174 can deliver pacing pulses and / or anti-tachycardia pacing therapy. The pulse generator 174 is controlled by a microcontroller 164 via a control signal 176. The pulse generator 174 is coupled to one or more select electrodes via an electrode configuration switch 192, which includes multiple switches for connecting the desired electrode to appropriate I / O circuitry, thereby facilitating electrode programmability. The switch 192 is controlled by a control signal 186 from the microcontroller 164. Figure 2 In the example, a single pulse generator 174 is shown. Alternatively, the IMD 100 may include multiple pulse generators similar to pulse generator 174, wherein each pulse generator is coupled to one or more electrodes and controlled by microcontroller 164 to deliver one or more selected stimulation pulses to the corresponding one or more electrodes.
[0052] Microcontroller 164 is shown to include timing control circuitry 166 for controlling the timing of stimulation pulses (e.g., pacing rate, atrioventricular (AV) delay, atrial (AA) delay, or ventricular (VV) delay, etc.). Timing control circuitry 166 can also be used for timing refractory periods, blanking intervals, noise detection windows, evoked response windows, alarm intervals, marker channel timing, etc. Microcontroller 164 also includes: an activation mode management (APM) process 182 for monitoring CPU behavior, an arrhythmia detector 168 for detecting arrhythmic conditions, and a morphology detector 170 for reviewing and analyzing one or more features of the morphology of cardiac signals. The APM process 182 or any other process implemented on microcontroller 164 can be implemented as firmware, software, and / or circuitry. Although not shown, microcontroller 164 may also include other dedicated circuitry and / or firmware / software components to assist in monitoring various conditions of the patient's heart and managing pacing therapy.
[0053] APM process 182 manages the processing activity modes of IMD 100. APM process 182 manages processing activity modes by monitoring CPU behavior to identify undesirable changes in TH patterns. APM process 182 stores one or more baseline TH patterns in a baseline TH pattern library. Based on the IMD performing one or more tasks (e.g., collecting CA signals, analyzing CA signals, delivering therapy, detecting communication requests, maintaining communication sessions with external devices, etc.), APM process 182 monitors TH characteristics in conjunction with these tasks. When IMD 100 encounters and / or responds to various types of events (e.g., cardiac input, environmental events, communication tasks, etc.) and delivers relevant therapy, APM process 182 can monitor TH characteristics continuously, periodically, or in response to a certain condition. APM process 182 compares the TH characteristics to the baseline TH patterns. APM process 182 determines that the CPU is experiencing undesirable changes in task processing based on determining that one or more TH characteristics deviate from the baseline TH patterns by more than a predetermined margin. APM process 182 continues to monitor TH characteristics in conjunction with one or more tasks, based on the determination that the TH characteristics have not deviated from the baseline TH pattern by more than a predetermined margin.
[0054] In response to determining that IMD 100 exhibits undesirable changes in TH mode, APM process 182 implements corrective actions. In one example, APM process 182 may implement corrective actions by providing an alert to the user. For example, APM process 182 may generate an alert and send it to local external devices and / or remote monitoring devices or servers, or it may activate a patient notification device in special circumstances to draw the user's attention. During subsequent sessions (e.g., clinical sessions, diagnostic sessions, communication sessions, etc.), APM process 182 may provide a detailed description of the TH characteristics of the changes in task processing. Such information may be reviewed along with other diagnostic data (e.g., pacing event histograms, environmental event logs, etc.) to help care providers identify potential problems to improve patient safety. Additionally or alternatively, the APM process may implement corrective actions by terminating the ongoing task or process. Additionally or alternatively, the APM process may implement corrective actions by restarting the ongoing task or process once or multiple times before its complete termination. For example, in response to determining that a non-critical task is causing an undesirable and / or unacceptable increase in the workload ratio, APM process 182 may terminate the non-critical task.
[0055] The IMD 100 is also equipped with a communication modem (modulator / demodulator) 172 to enable wireless communication with other devices, implanted devices, and / or external devices. In one embodiment, the communication modem 172 can use high-frequency modulation of the signal transmitted between electrode pairs. In one embodiment, the communication modem 172 uses high-frequency modulation, such as using RF (e.g., the MICS band, etc.), Bluetooth, or Bluetooth Low Energy telemetry protocol. The signal is transmitted in the high-frequency range and will pass through body tissue in fluids without stimulating the heart or being felt by the patient. The communication modem can be implemented in hardware as part of the microcontroller 164, or can be programmed into and executed by the microcontroller 164 as software / firmware instructions. Alternatively, the communication modem 172 can reside separately from the microcontroller as a standalone component. The communication modem 172 facilitates data retrieval from a remote monitoring network. The communication modem 172 enables timely and accurate data transmission directly from the patient to electronic devices used by the physician.
[0056] The IMD 100 includes a sensing circuit 180 that is selectively coupled via a switch 192 to one or more electrodes performing a sensing operation to detect the presence of a central heartbeat in the right ventricle. The sensing circuit 180 may include a dedicated sensing amplifier, a multiplexed amplifier, or a shared amplifier. It may also employ one or more low-power precision amplifiers with programmable gain and / or automatic gain control, bandpass filtering, and threshold detection circuitry to selectively sense the cardiac signal of interest. The output of the sensing circuit 180 is connected to a microcontroller 164, which in turn triggers or inhibits a pulse generator 174 in response to the absence or presence of a heartbeat. The sensing circuit 180 receives a control signal 178 from the microcontroller 164 for timing the gain, threshold, polarization charge removal circuitry (not shown), and any blocking circuitry (not shown) coupled to the input of the sensing circuit.
[0057] exist Figure 2 In the example, a single sensing circuit 180 is shown. Alternatively, the IMD 100 may include multiple sensing circuits similar to sensing circuit 180, wherein each sensing circuit is coupled to one or more electrodes and controlled by microcontroller 164 to sense electrical activity detected at the corresponding one or more electrodes. Sensing circuit 180 may operate in a unipolar sensing configuration or a bipolar sensing configuration.
[0058] The IMD 100 also includes an analog-to-digital (A / D) data acquisition system (DAS) 190 coupled to one or more electrodes via a switch 192 to sample cardiac signals on any desired electrode pair. The data acquisition system 190 is configured to acquire intracardiac electrocardiogram signals, convert raw analog data into digital data, and store the digital data for later processing and / or telemetry transmission to an external device 104 (e.g., a programmer, local transceiver, or diagnostic system analyzer). The data acquisition system 190 is controlled by control signals 188 from a microcontroller 164.
[0059] Microcontroller 164 is coupled to memory 152 via a suitable data / address bus 162. Programmable operating parameters used by microcontroller 164 are stored in memory 152 and used to customize the operation of IMD 100 to suit the needs of a specific patient. For example, such operating parameters define pacing pulse amplitude, pulse duration, electrode polarity, rate, sensitivity, auto-signals, arrhythmia detection criteria, and the amplitude, waveform, and vector of each impulse pulse to be delivered to the patient's heart within each corresponding level of therapy. Furthermore, baseline TH patterns are stored in a baseline TH pattern library in memory 152 and are used during APM to determine whether IMD 100 exhibits undesirable changes in the TH patterns.
[0060] During telemetry communication with external device 104 via communication link 150, the operating parameters of IMD 100 can be non-invasively programmed into memory 152 via telemetry circuit 154. Telemetry circuit 154 allows the transmission of intracardiac electrocardiogram and status information related to the operation of IMD 100 (such as that contained in microcontroller 164 or memory 152) to external device 104 via established communication link 150.
[0061] IMD 100 may also include a magnet detection circuit (not shown) coupled to microcontroller 164 to detect the time a magnet is placed on the unit. Clinicians can use the magnet to perform various test functions of unit 100 and / or signal microcontroller 164 that an external programmer is in place to receive or send data to microcontroller 164 via telemetry circuitry 154.
[0062] IMD 100 may also include one or more physiological sensors 156. Such sensors are often referred to as “rate-responsive” sensors because they are typically used to adjust the pacing stimulation rate according to the patient’s activity status. However, physiological sensors 156 can also be used to detect changes in cardiac output, changes in cardiac physiological conditions, or diurnal variations in activity (e.g., detecting sleep and wakefulness). The signals generated by physiological sensors 156 are passed to microcontroller 164 for analysis. Microcontroller 164 responds by adjusting various pacing parameters (e.g., rate, AV delay, VV delay, etc.) used to manage atrial and ventricular pacing pulses. Although shown as being included within unit 100, physiological sensors(s) 156 may be external to unit 100 or may still be implanted in the patient or carried by the patient. Examples of physiological sensors may include, for example, sensors that sense respiratory rate, blood pH, ventricular gradient, activity, position / posture, minute ventilation (MV), etc.
[0063] Battery 158 provides operating power to all components in IMD 100. Battery 158 is capable of operating at low current consumption for extended periods and can provide high current pulses (for capacitor charging) when the patient requests a pulse burst (e.g., exceeding 2A, voltage above 2V, for a period of 10 seconds or longer). Battery 158 is also expected to have predictable discharge characteristics, allowing for the detection of selective replacement times. As an example, cell 100 employs a lithium / silver vanadium oxide battery.
[0064] Optionally, the IMD 100 also includes an impedance measurement circuit 160, which can be used for a variety of purposes, including: monitoring lead impedance during acute and chronic phases to obtain proper lead positioning or displacement; detecting operable electrodes and automatically switching to an operable electrode pair if displacement occurs; measuring respiratory rate or minute ventilation; measuring thoracic impedance to determine the impact threshold; detecting when the device is implanted; measuring stroke volume; and detecting the opening of heart valves, etc. The impedance measurement circuit 160 is coupled to a switch 192, allowing the use of any desired electrode. Optionally, the microcontroller 164 also controls the impact circuit 184 via a control signal 186. The impact circuit 184, under the control of the microcontroller 164, generates impact pulses of low energy (e.g., up to 0.5 joules), medium energy (e.g., 0.5–10 joules), or high energy (e.g., 111–40 joules).
[0065] The IMD 100 can operate as an implantable cardioverter-defibrillator (ICD) device that detects the occurrence of arrhythmias and automatically applies an appropriate electrical impulse therapy to the heart to terminate the detected arrhythmia. For this purpose, the microcontroller 164 also controls the impulse circuit 184 via control signal 186. The impulse circuit 184, under the control of the microcontroller 164, generates impulse pulses of low energy (e.g., up to 0.5 joules), medium energy (e.g., 0.5–10 joules), or high energy (e.g., 11–40 joules). Such impulse pulses are applied to the patient's heart via impulse electrodes. It should be noted that the impulse therapy circuitry is optional and may not be implemented in the IMD, as the various driven pacing units described below are typically not configured to deliver high-voltage impulse pulses. On the other hand, it should be recognized that driven pacing units can be used within systems that include backup impulse capabilities; therefore, such impulse therapy circuitry can be included in the IMD 100.
[0066] CPU activation mode management
[0067] Figure 3An architectural block diagram illustrating examples of various features, services, and frameworks that can be implemented by an IMD hardware platform according to embodiments herein is shown. For example, various features, services, and frameworks can be implemented on one or more microcontrollers 164 of the IMD 100 in conjunction with APM process 182 and other IMD functions. The IMD hardware platform 302 can invoke the operation of an interrupt processor 304, which is part of the embedded device software 306, based on the detection of a triggering event (e.g., detecting noise on a sensing channel, attempting to communicate with the IMD 100, etc.). The interrupt processor 304 may include one or more service routines corresponding to one or more of a pacing engine, system watchdog, interrupt management, etc. The interrupt processor 304 can detect and facilitate the execution of any critical task (e.g., pacing) in an interrupt context. The IMD hardware platform 302 can also invoke the operation of an architectural framework 306. The architectural framework 306 may include one or more service routines corresponding to one or more of software error handling, code crawling, hardware access, main loop, and / or event queue, etc. The architectural framework 306 can call one or more startup routines (e.g., initialization routines) of the architectural startup 308. The architecture framework 306 can also invoke one or more architecture services 310 during task execution. Architecture services 310 may include one or more services corresponding to one or more of the following: waveform buffering service, tagging, data collection, system event dispatch, diagnostic data, feature interaction, programming, pruning service, interval extraction, pacing timing arbitration, pacing mode arbitration, sensing service, sense control, timer service, DIM / EIP, BLE, etc. Subsequently, architecture services 310 can combine with APM process 182 and / or other IMD functions to induce one or more features 312 of IMD 100. Examples of features 312 may include one or more of primary sensing algorithms, secondary verification algorithms, therapeutic algorithms, diagnostic algorithms, maintenance algorithms, communication algorithms, etc.
[0068] Figure 4 The characteristicization process for determining and storing TH characteristics according to embodiments herein is illustrated. Figure 4 All or part of the operation can be performed by one or more processors of the IMD 100 configured with executable instructions. Figure 4 Part of the operation can also be implemented by one or more processors from one or more local external devices and / or remote servers. Although described at least in a partially serial manner... Figure 4 The operation is understood, but it is recognized that at least part of the operation is executed in parallel. Furthermore, Figure 4 The operation can be performed in parallel with other operations of IMD 100.
[0069] At 402, one or more processors of the IMD 100 determine the time required to complete one or more tasks in the queue. The time to complete a given task may include TH characteristics, such as the waiting time during which the task remains in the queue and / or the execution time of a critical task (e.g., pacing). Examples of task completion times may include one or more of the following: i) the time to complete a type of sensing event analysis (e.g., Brady R) after receiving an interrupt; iii) the time to prepare and deliver a therapy (e.g., V-pulse); iv) the time to perform measurements (e.g., impedance measurements, battery charging measurements); v) the time to collect and update diagnostics based on CA signals; vi) the time to complete housekeeping tasks (e.g., cleanup tasks at the end of a communication session); viiii) the time to analyze incoming data packets; ix) the time to send outgoing data packets; and so on. The time to complete a given task may include the overhead of multiple tasks being executed. Based on determining the time to complete one or more tasks in the queue, the process moves to 404.
[0070] At 404, one or more processors of IMD 100 record the time to complete one or more tasks. One or more TH characteristics associated with a given task can be recorded and used to build a histogram. For example, the process can build and / or maintain histograms of wait times and / or execution times associated with a task or group of tasks. Histograms of the distribution of wait times and execution times for tasks can be measured on a periodic basis (e.g., daily or weekly), and the measurements are included in the corresponding histograms. The histograms of wait times and / or execution times can be used to compare the currently measured wait times and / or execution times of one or more tasks with corresponding trends and / or patterns in the wait times and / or execution times of those one or more tasks. Operations at 402 and 404 can be performed iteratively until no more tasks remain in the queue. Based on the recorded time to complete one or more tasks, the process moves to 406.
[0071] At 406, one or more processors of IMD 100 determine CPU activity during the sleep mode of IMD 100. IMD 100 enters sleep mode based on the absence of tasks in the queue. A process may insert sleep response tasks into the queue to monitor CPU activity during the sleep mode of IMD 100. For example, the process may monitor the wake-to-sleep time as CPU activity during sleep mode. The wake-to-sleep time may be the difference between the time the queue becomes empty and the time the CPU enters sleep mode. Additionally or alternatively, the process may monitor the duration of the time between the time the CPU enters sleep mode and the time an interrupt terminates the sleep mode. Based on the determination of CPU activity during sleep mode, and the recording of CPU activity during the sleep mode of IMD 100 by one or more processors of IMD 100, the flow moves to 408.
[0072] At 410, one or more processors of the IMD 100 store the TH characteristics of each task as a baseline TH pattern in the reference matrix.
[0073] Figure 5 A process for managing IMD processing activity modes according to embodiments herein is illustrated. This management includes monitoring CPU behavior to identify unwanted changes in TH modes. Figure 5 All or part of the operation can be performed by one or more processors of the IMD 100 configured with executable instructions. Figure 5 Part of the operation can also be implemented by one or more processors from one or more local external devices and / or remote servers. Although described at least in a partially serial manner... Figure 5 The operations involve parallel execution, but it should be recognized that at least a portion of these operations are performed in parallel. Furthermore, Figure 5 The operation can be performed in parallel with other operations of IMD 100.
[0074] At 502, one or more processors of IMD 100 store baseline TH patterns. In a non-limiting example, during product development, developers can measure various TH time characteristics (e.g., queue wait times, execution times, execution frequency, overall and / or average CPU workload, etc.). The measurements of various TH time characteristics can be stored as one or more TH baseline patterns in a TH baseline pattern library. Additionally or alternatively, one or more TH baseline patterns can be identified as part of the monitoring operation at 506, and one or more TH baseline patterns can be periodically stored in the TH baseline pattern library. Additionally or alternatively, TH baseline patterns can be updated periodically or on demand. For example, TH baseline patterns can be updated based on changes to one or more programming parameters of the IMD that can affect TH time characteristics. After storing the baseline TH patterns, the process moves to 504.
[0075] At 504, one or more processors of the IMD perform tasks associated with one or more of the following: collecting CA signals and / or environmental event signals, analyzing CA signals and / or environmental event signals, delivering therapy, detecting communication requests, and maintaining communication sessions with external devices. Tasks may include time-critical tasks implemented in conjunction with foreground processes (e.g., delivering therapy, communicating with external devices, analyzing signals, etc.). Additionally, tasks may include non-time-critical tasks associated with background processes (e.g., self-diagnosis, internal maintenance, monitoring signals, etc.). Based on the task execution, the process moves to 506.
[0076] At 506, one or more processors of the IMD 100 combine to monitor TH characteristics for task execution. TH characteristics can represent at least one of the following: CPU TH time characteristics (e.g., CPU time for various tasks), CPU continuous active duration, CPU continuous sleep duration, duty ratio measurement for a selected time period, task queue waiting time, execution time of a critical task (e.g., pacing), queue waiting time of a task group, or execution time of a task group. CPU continuous active duration can represent the duration during which the CPU is continuously active and executing tasks in the queue. CPU continuous sleep duration can represent the duration during which the CPU is continuously inactive / in sleep mode and not executing any tasks. TH characteristics can include at least one of the following: i) time to complete a type of sensing event analysis; ii) time to complete a type of external input processing; iii) time to prepare and deliver therapy (e.g., V-pulse); iv) time to perform measurements (e.g., impedance measurement, battery charge measurement); v) time to collect and update diagnostics based on CA signals; vi) time to complete housekeeping tasks; viii) time to analyze incoming data packets; and ix) time to send outgoing data packets; etc. For example, the time to complete a type of sensing event analysis (e.g., Brady R) can be measured. In another example, the time to complete a type of external input processing (e.g., related to magnets, activity, etc.) after input is received can be measured. Additionally or alternatively, monitoring can be temporarily paused during clinical sessions, communication sessions with remote monitoring devices and / or servers, etc. (e.g., to prevent monitoring and / or recording from being due to TH characteristics not of normal IMD 100 operation).
[0077] Additionally or alternatively, monitoring TH characteristics may include identifying the CPU workload as part of the TH characteristics. For example, the CPU workload could be the percentage of time the CPU is active and running tasks over the total time period of interest. Additionally or alternatively, the CPU workload could be determined as the average workload over a first time period periodically over a longer second time period. For example, the average workload could be determined as the average workload over each 30-minute interval within a 23-hour time period.
[0078] Additionally or alternatively, monitoring the TH characteristic may include maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of selected critical tasks. Based on monitoring the TH characteristic, the process moves to 508.
[0079] Additionally or alternatively, monitoring TH characteristics may include maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of tasks (e.g., all tasks or selected critical tasks). A histogram of the distribution of task waiting time and execution time may be measured on a periodic basis (e.g., daily or weekly), and the measurements are included in the corresponding histogram. Histograms of task waiting time and / or execution time may be used post-implantation to continuously, periodically, or in response to certain conditions of IMD 100 to establish and update baseline TH patterns in the baseline TH pattern library.
[0080] At 508, one or more processors of the IMD 100 compare the TH characteristics to a baseline TH pattern. Comparing one or more TH characteristics to the corresponding baseline TH pattern facilitates the detection of potential faults in the IMD 100's firmware, hardware, or network security. Comparing the TH characteristics to the baseline TH pattern includes determining whether the TH characteristics have deviated from the baseline TH pattern beyond a predetermined margin. TH characteristics may deviate from the baseline TH pattern based on events such as (e.g., but not limited to) the following: a low-level impedance change on the sensing channel due to an early stage of lead breakage and / or insulation failure; the creation of dummy tasks that do not further interrupt other tasks (e.g., tasks incorrectly and repeatedly inserted into the queue); firmware faults (e.g., premature termination of the IMD 100 communication session); repeated and / or unsuccessful attempts by hackers to wake up / end-to-end connectivity and / or communicate with the IMD 100, etc. The process explains that the IMD's processing activity pattern (e.g., CPU behavior) exhibits an unexpected change in TH pattern based on a comparison indicating that the TH characteristic has indeed deviated from the baseline TH pattern by more than a predetermined margin, and the process moves to 510. Alternatively, the process explains that the IMD's processing activity pattern (e.g., CPU behavior) does not exhibit an unexpected change in TH pattern based on a comparison indicating that the TH characteristic has not deviated from the baseline TH pattern by more than a predetermined margin, and the process returns to 504.
[0081] In one example, the CPU TH time characteristics correspond to one or more baseline TH patterns in a baseline TH pattern library. The one or more baseline TH patterns may be based at least in part on various TH time characteristics measured by the developer and stored in memory prior to the implantation of IMD 100. Additionally or alternatively, the one or more baseline TH patterns may be based at least in part on moving averages or trends of the waiting time in which tasks remain in the queue and / or the execution time of selected critical tasks. The moving averages and / or trends of the waiting time in the queue and / or the execution time of selected critical tasks may be based at least in part on corresponding histograms maintained during monitoring at operation 506. Additionally or alternatively, the moving averages and / or trends of the waiting time in the queue and / or the execution time of selected critical tasks may be periodically stored as baseline task processing patterns at operation 502.
[0082] Additionally or alternatively, based on the CPU duty cycle identified as part of the TH characteristic, this comparison includes determining whether the CPU duty cycle indicates that the CPU is continuously active for at least a predetermined amount of time. The baseline TH pattern of the CPU duty cycle can be identified as a duration threshold (e.g., 3 hours) or a percentage (e.g., 25%) of the CPU's uptime or sleep time within a selected time period (e.g., one day or one week). Optionally, the baseline TH pattern of the CPU duty cycle can also be identified as the number of times (e.g., 3 times) the duration threshold is reached during the selected time period. When monitoring the duration of continuous CPU activity (e.g., no sleep), the baseline TH pattern of the duty cycle can be selected to prevent the risk of CPU over-running.
[0083] Additionally or alternatively, based on the average workload ratio over the first time period, which is periodically expressed over a longer second time period, the comparison includes determining whether the CPU workload ratio exceeds a baseline TH pattern. Many tasks performed on the IMD 100 are related to cardiac events that are substantially periodic (e.g., occurring every 1 second), and monitoring the daily average workload ratio may only be an aspect of the methods and systems described herein. The baseline TH pattern of the average workload ratio over the first time period, which is periodically expressed over a longer second time period, may be a daily average of the workload ratio over several consecutive (e.g., 3) 24-hour periods (e.g., 30 minutes) (e.g., within each 24-hour period).
[0084] At point 510, one or more processors of the IMD 100 implement corrective actions in response to a comparison of the TH characteristic and a baseline TH pattern. Corrective actions may be implemented in response to the comparison indicating that the TH characteristic has deviated from the baseline TH pattern by more than a predetermined margin. A TH characteristic deviating from the baseline pattern by more than a predetermined margin indicates that the processing activity pattern of the IMD (e.g., CPU behavior) is exhibiting an undesirable change in the TH pattern. As part of implementing corrective actions, one or more processors of the IMD 100 may provide an alert to the user, terminate an ongoing task or process, restart a task or process, restart all or part of a process implemented in the IMD 100, etc. For example, the process may implement corrective actions by generating and sending an alert to local external devices and / or remote monitoring devices or servers, or by activating a patient notification device to draw the user's attention. During subsequent sessions (e.g., clinical sessions, diagnostic sessions, communication sessions, etc.), the APM process 182 may provide a detailed description of the TH characteristic of the changed task processing. This information can be reviewed along with other diagnostic data (e.g., pacemaker event histograms, environmental event logs, etc.) to help care providers identify potential problems (e.g., early stages of lead breakage or insulation failure) to improve patient safety. In additional or alternative examples, the process can implement corrective actions by terminating an ongoing task or process (e.g., a task involving repeated firmware insertion due to premature termination of a communication session, a task related to a hacker's communication attempt that breaches the physical communication layer, etc.). For example, in response to determining that a non-critical task is causing an undesirable and / or unacceptable increase in workload, APM process 182 can terminate the non-critical task, and optionally, restart the non-critical task once or multiple times before termination.
[0085] Figure 6 It shows that according to Figure 4 and Figure 5 This is an example of a process used to monitor CPU behavior to identify unwanted changes in TH mode. Figure 6 All or part of the operation can be performed by one or more processors of the IMD 100 configured with executable instructions. Figure 6 Part of the operation can also be implemented by one or more processors from one or more local external devices and / or remote servers. Although described at least in a partially serial manner... Figure 6 The operation is understood, but it is recognized that at least part of the operation is executed in parallel. Furthermore, Figure 6 The operation can be performed in parallel with other operations of IMD 100.
[0086] At position 602, one or more processors of the IMD 100 set a measurement matrix for task execution and CPU workload ratio. This measurement matrix may be at least partially based on... Figure 4 The operation is performed on the reference matrix stored at position 410, and according to... Figure 5 Operation 502. Based on the set measurement matrix, the process moves to 604. At 604, one or more processors of the IMD 100 determine whether a task exists in the queue. Based on the determination that no task exists in the queue, the process moves to 606, and one or more processors of the IMD 100 enter the IMD's sleep state. One or more processors of the IMD 100 may periodically execute interrupts and determine whether any task exists in the queue during the sleep state. Returning to 604, based on the determination that one or more tasks exist in the queue, the process moves to 608. At 608, one or more processors of the IMD 100, based on the task position in the queue and according to... Figure 5 Operation 504 assigns a priority to a task to execute one or more tasks. Based on the execution of one or more tasks, the process moves to 608. At 608, one or more processors of the IMD 100 update the measurement matrix associated with the one or more tasks. Updating the measurement matrix may include, based on... Figure 5 Operation 506 combines task execution to monitor one or more TH characteristics. The process returns to 604, where one or more processors of IMD 100 determine whether a task exists in the queue based on the updated measurement matrix.
[0087] Independently and on a periodic basis, one or more processors of the IMD 100 perform operations to monitor CPU behavior on a periodic basis (e.g., daily, hourly, etc.) to identify unwanted changes in the TH mode. Additionally or alternatively, the monitoring of CPU behavior can be performed on an interrupt-based basis. At 612, one or more processors of the IMD 100 initiate monitoring of CPU behavior, and the flow moves to 614. At 614, one or more processors of the IMD 100 determine the measurement matrix of the task being performed and compare the measurement matrix (e.g., the current measurement matrix stored at operation 610) with a baseline measurement matrix. At 616, one or more processors of the IMD 100 compare the current measurement matrix with the baseline measurement matrix. Figure 4 The operation compares the reference matrix stored at position 410 with the operation based on... Figure 5Operation 508 determines whether one or more TH characteristics have deviated from the corresponding baseline TH mode by more than a predetermined margin. The process moves to 626, and terminates based on the determination that no TH characteristic has deviated from the corresponding baseline TH mode by more than a predetermined margin. The process moves to 618, based on the determination that one or more TH characteristics have indeed deviated from the corresponding baseline TH mode by more than a predetermined margin. At 618, one or more processors of IMD 100 generate an alarm. After generating the alarm, the process moves to 620.
[0088] At 620, one or more processors of the IMD 100 identify one or more tasks that cause undesirable changes in the TH mode. For example, the process may identify one or more tasks involving repetitive activation of noise detection features that have fallen below a threshold used to trigger a noise response. Repetitive activation of noise detection features below the noise response threshold can be used alone or with other diagnostic data to indicate an early stage of lead breakage or insulation failure. In another example, the process may identify one or more tasks that are being repeatedly inserted into the queue by firmware and correspond to a cleanup task implemented based on a patient prematurely ending a communication session with the IMD 100 (e.g., by walking away from an external device). In yet another example, the process may identify one or more tasks involving repetitive attempts to wake up / end-to-end connect to the IMD 100, different from periodic interruptions caused by cardiac events, or communications that breach the physical communication layer but never actually control the IMD 100. Repetitive attempts to wake up / end-to-end connect to the IMD 100 and / or communications that only breach the external communication layer can indicate hacking attempts and / or cybersecurity breaches. This process can be generated by repeated activation of noise detection features, repeated attempts to connect / wake up the IMD 100 end-to-end, unsuccessful communication, or repeated insertion of tasks into the queue by the firmware, and the sending of alarms and / or reports to local external devices and / or remote monitoring devices or servers. Based on the identification of one or more tasks that cause unwanted changes in TH mode, the process moves to 622.
[0089] At 622, one or more processors of the IMD 100 determine whether one or more tasks causing undesirable changes in TH mode are non-critical tasks that can be terminated according to predefined criteria. For example, the process determines that tasks involving foreground processes (e.g., delivery of therapy, communication with external devices, signal analysis, etc.) are critical tasks that cannot be terminated according to predefined criteria. Based on the determination that the tasks cannot be terminated, the process ends at 626. Additionally or alternatively, the process determines that tasks involving background processes (e.g., monitoring signals, self-diagnostics, internal maintenance, etc.) are non-critical tasks that can be terminated according to predefined criteria. Based on the determination that one or more tasks are non-critical tasks that can be terminated, the process moves to 624. At 624, one or more processors of the IMD 100 terminate one or more non-critical tasks, and the process ends at 626. The process can terminate one or more non-critical tasks by resetting the functions and / or processes associated with one or more tasks (e.g., restarting the communication chip or process), clearing the queue, restarting the IMD 100, etc. For example, the process can implement a job monitoring task manager capable of terminating one or more non-critical tasks. Optionally, the process may restart one or more non-critical tasks once or multiple times before terminating them. Additionally or alternatively, the process may be implemented to mask repeated attempts to connect / wake up the IMD 100 to the end (e.g., by masking communication attempts during periods when no communication attempts are expected, by unmasking interruptions only every 1-2 minutes to check for valid communication, etc.). Operations 618-626 may be adapted to... Figure 5 Operation 510 is executed.
[0090] Therefore, the methods and systems described herein enable the monitoring and detection of undesirable changes in TH characteristics, thereby facilitating the identification and mitigation of potential failures and / or faults in firmware, hardware, or network security. Additionally or alternatively, based on the detection that non-critical tasks are causing undesirable increases in TH characteristics, the methods and systems described herein can manage (e.g., terminate, restart, etc.) non-critical tasks, thereby preserving battery life.
[0091] Conclusion
[0092] It should be clearly understood that the various arrangements and processes extensively described and illustrated in the accompanying drawings, and / or one or more individual components or elements of such arrangements and / or one or more process operations associated with such processes, may be employed independently of or in conjunction with one or more other components, elements, and / or process operations described and illustrated herein. Therefore, while various arrangements and processes are broadly conceived, described, and illustrated herein, it should be understood that they are provided merely in an illustrative and non-limiting manner and may also be considered only as examples of possible working environments in which one or more of these arrangements or processes may be operated.
[0093] As those skilled in the art will understand, various aspects can be embodied as systems, methods, or computer (device) program products. Accordingly, aspects can take the form of entirely hardware embodiments or embodiments including hardware and software that may be generally referred to herein as "circuit," "module," or "system." Furthermore, aspects can take the form of computer (device) program products embodied in one or more computer (device) readable storage media having computer (device) readable program code embodied thereon.
[0094] Any combination of one or more non-transitory computer-readable media can be used. This non-transitory medium can be a storage medium. The storage medium can be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system or device; or any suitable combination of the foregoing. More specific examples of storage media will include: portable computer floppy disks, hard disks, random access memory (RAM), dynamic random access memory (DRAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.
[0095] Program code for performing operations can be written using any combination of one or more programming languages. The program code can execute entirely on a single device, partially on a single device, as a standalone software package, partially on a single device, partially on another device, or entirely on another device. In some cases, devices can be connected via any type of network (including local area networks (LANs) or wide area networks (WANs), or via other devices (e.g., the Internet through an Internet service provider) or via hardwired connections (such as via USB). For example, a server having a first processor, a network interface, and a storage device for storing code can store program code for performing operations and provide that code via its network interface over a network to a second device having a second processor for execution on the second device.
[0096] This document describes aspects with reference to the accompanying drawings, which illustrate exemplary methods, apparatus, and program products according to various exemplary embodiments. These program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus or information processing apparatus to produce a machine, such that the instructions, which execute via the processor of the apparatus, perform a specified function / behavior. The program instructions can also be stored in a device-readable medium that can instruct the apparatus to operate in a particular manner, such that the instructions stored in the device-readable medium produce a manufactured article including instructions to perform the specified function / behavior. The program instructions can also be loaded onto the apparatus to cause a series of operational steps to be performed on the apparatus to produce a process implemented by the apparatus, such that the instructions executing on the apparatus provide a process for performing the specified function / behavior.
[0097] The units / modules / applications described herein can include any processor-based or microprocessor-based system, including systems using microcontrollers, simplified instruction set computers (RISC), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), logic circuits, and any other circuitry or processor capable of performing the functions described herein. Additionally or alternatively, a module / controller as described herein can refer to a circuit module of hardware that can be implemented as associated with instructions for performing the operations described herein (e.g., software stored on a tangible and non-transitory computer-readable storage medium such as a computer hard drive, ROM, RAM, or similar media). The examples above are merely illustrative and are therefore not intended to limit the definition and / or meaning of the term "controller" in any way. Units / modules / applications as described herein can execute a set of instructions stored in one or more storage elements to process data. Storage elements can also store data or other information as desired or required. Storage elements can be in the form of information sources or physical memory elements within modules / controllers as described herein. The instruction set can include various commands that instruct the modules / applications herein to perform specific operations, such as methods and processes of various embodiments of the subject matter described herein. The instruction set can be in the form of a software program. The software can be in various forms such as system software or application software. Furthermore, the software can take the form of a collection of independent programs or modules, a program module within a larger program, or a portion of a program module. The software may also include modular programming in the form of object-oriented programming. Processing of input data by the processor can be in response to user commands, the results of previous processing, or a request made by another processor.
[0098] It should be understood that the subject matter described herein is not limited in its application to the structural details and component arrangements set forth in the description or shown in the accompanying drawings. The subject matter described herein can have other embodiments and can be practiced or implemented in various ways. Furthermore, it should be understood that the phrases and terms used herein are for descriptive purposes and should not be considered limiting. The use of “comprising,” “including,” or “having,” and variations thereof herein is intended to include the items listed thereafter and their equivalents, as well as additional items.
[0099] It should be understood that the description above is intended to be illustrative and not restrictive. For example, the embodiments (and / or aspects thereof) described above can be used in combination with each other. Furthermore, many modifications can be made to adapt a particular situation or material to the teachings herein without departing from its scope. While the dimensions, types of materials, and coatings described herein are intended to define various parameters, they are by no means restrictive but are substantially illustrative. Many other embodiments will be apparent to those skilled in the art upon review of the above description. Therefore, the scope of this embodiment should be determined by reference to the appended claims and the full scope of their equivalents. In the appended claims, the terms “comprising” and “wherein” are used as plain Chinese equivalents of the respective terms “including” and “in which”. Furthermore, in the claims, the terms “first,” “second,” and “third,” etc., are used merely as labels and not to impose numerical requirements on their objects or on their actions in any order of execution.
[0100] All references cited in this article, including publications, patent applications and patents, are incorporated herein by reference to the same extent that each reference was individually and specifically indicated to be incorporated by reference, and are listed in full herein.
Claims
1. An implantable medical device comprising: A memory storing baseline task processing patterns, wherein the baseline task processing pattern refers to a pattern of one or more task processing characteristics associated with one or more completed tasks over a period of time; and A task processing circuit including one or more processors, the task processing circuit being configured to: Perform one or more tasks associated with one or more of the following: collect one or more cardiac signals or environmental event signals, analyze one or more cardiac signals or environmental event signals, deliver therapy, detect communication requests, or maintain communication sessions with external devices; In conjunction with the execution of the one or more tasks, monitor task processing characteristics to obtain at least one of a processing activity pattern or task execution time; Compare the task processing characteristics with the baseline task processing pattern; and In response to a comparison operation between the task processing characteristics and the baseline task processing mode, a corrective action is performed.
2. The implantable medical device as described in claim 1, wherein, In response to the comparison operation indicating that the task processing characteristics have deviated from the baseline task processing mode by more than a predetermined margin, the corrective action is performed.
3. The implantable medical device of claim 1, wherein the task processing characteristic represents at least one of the following: central processing unit task processing time characteristic, central processing unit continuous active duration, central processing unit continuous dormant duration, central processing unit workload ratio for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
4. The implantable medical device as described in claim 3, wherein, The task processing characteristics refer to the task processing time characteristics of a central processing unit for at least one of the following: i) The time required to complete the analysis of a type of sensing event; ii) The time required to complete a type of external input processing; iii) The time it takes to send outgoing data packets; iv) The time taken to perform the measurement; v) The time for collecting and updating the diagnosis based on the cardiac signal; vi) The time required to complete internal affairs management tasks; and vii) Analyze the time of incoming data packets.
5. The implantable medical device as described in claim 1, wherein, The monitoring operation includes identifying the central processing unit's workload as part of the task processing characteristics, and the comparison operation includes determining whether the central processing unit's workload indicates that the central processing unit is continuously active for at least a predetermined amount of time.
6. The implantable medical device as described in claim 1, wherein, The task processing characteristics indicate the task execution time of the central processing unit, and the monitoring operation includes maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of selected key tasks, and implementing the corrective action based on the histogram.
7. The implantable medical device as described in claim 1, wherein, The operations performed include at least one of the following: terminating an ongoing task or process, restarting a task or process, or restarting part or all of a process performed by the implantable medical device.
8. A method for managing the behavior of a central processing unit of an implantable medical device, the method comprising: Store a baseline task processing pattern, wherein the baseline task processing pattern refers to a pattern of one or more task processing characteristics associated with one or more completed tasks over a period of time. Perform one or more tasks associated with one or more of the following: collect one or more cardiac signals or environmental event signals, analyze one or more cardiac signals or environmental event signals, deliver therapy, detect communication requests, and maintain communication sessions with external devices; In conjunction with the execution of the one or more tasks, monitor task processing characteristics to obtain at least one of a processing activity pattern or task execution time; Compare the task processing characteristics with the baseline task processing pattern; and In response to a comparison operation between the task processing characteristics and the baseline task processing mode, a corrective action is performed.
9. The method of claim 8, wherein, In response to the comparison operation indicating that the task processing characteristics have deviated from the baseline task processing mode by more than a predetermined margin, the corrective action is performed.
10. The method of claim 8, wherein, The task processing characteristics represent at least one of the following: central processing unit task processing time characteristics, central processing unit continuous active duration, central processing unit continuous dormant duration, central processing unit workload ratio for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
11. The method of claim 10, wherein, The task processing characteristics refer to the task processing time characteristics of a central processing unit for at least one of the following: i) The time required to complete the analysis of a type of sensing event; ii) The time required to complete a type of external input processing; iii) The time it takes to send outgoing data packets; iv) The time taken to perform the measurement; v) The time for collecting and updating the diagnosis based on the cardiac signal; vi) The time required to complete internal affairs management tasks; and vii) Analyze the time of incoming data packets.
12. The method of claim 8, wherein, The monitoring operation includes identifying the workload ratio of the central processing unit as a task processing characteristic indicating the processing activity pattern of the central processing unit, and the comparison operation includes determining whether the workload ratio of the central processing unit indicates that the central processing unit is continuously active for at least a predetermined amount of time.
13. The method of claim 8, wherein, The task processing characteristics indicate the task execution time of the central processing unit, and the monitoring operation includes maintaining at least one of the following: a histogram of the waiting time of tasks remaining in the queue or a histogram of the execution time of selected key tasks, and implementing the corrective action based on the histogram.
14. The method of claim 8, wherein, The operations performed include at least one of the following: terminating an ongoing task or process, restarting a task or process, or restarting part or all of a process performed by an implantable medical device.
15. A computer program product comprising a non-transitory computer-readable storage medium, said non-transitory computer-readable storage medium comprising computer-executable code for performing the following operations: Perform one or more tasks associated with one or more of the following: collect heartbeat signals, analyze heartbeat signals, deliver therapy, detect communication requests, and maintain communication sessions with external devices; In conjunction with the execution of the one or more tasks, monitor task processing characteristics to obtain at least one of a processing activity pattern or task execution time; The task processing characteristics are compared with a baseline task processing pattern, wherein the baseline task processing pattern refers to a pattern of one or more task processing characteristics associated with one or more completed tasks over a period of time; and In response to a comparison operation between the task processing characteristics and the baseline task processing mode, a corrective action is performed.
16. The computer program product of claim 15, wherein, In response to the comparison operation indicating that the task processing characteristics have deviated from the baseline task processing mode by more than a predetermined margin, the corrective action is performed.
17. The computer program product of claim 15, wherein, The task processing characteristics represent at least one of the following: central processing unit task processing time characteristics, central processing unit continuous active duration, central processing unit continuous dormant duration, central processing unit workload ratio for a selected time period, task queue waiting time, execution time of critical tasks, queue waiting time of task groups, or execution time of task groups.
18. The computer program product of claim 15, wherein, The task processing characteristics refer to the task processing time characteristics of a central processing unit for at least one of the following: i) The time required to complete the analysis of a type of sensing event; ii) The time required to complete a type of external input processing; iii) The time it takes to send outgoing data packets; iv) The time taken to perform the measurement; v) The time for collecting and updating the diagnosis based on the cardiac signal; vi) The time required to complete internal affairs management tasks; and vii) Analyze the time of incoming data packets.