Systems and methods for remote programming of implantable medical devices

Abstract

A communication system is provided that includes a remote electronic device configured to communicate with a medical device of a patient via a locally programmed electronic device. The remote electronic device may include one or more processors configured to control operation of the local programming electronic device to program the medical device during the dynamic session. The one or more processors may also be configured to terminate the dynamic session in response to 1) a persistent action of a user of the remote electronic device exceeding a static persistent state threshold and 2) a monitored event exceeding a dynamic threshold.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. Provisional Patent Application No. 63 / 569,010, filed on March 22, 2024, entitled “SYSTEMS AND METHOD FORIMPLANTABLE MEDICAL DEVICE REMOTE PROGRAMMING,” the subject matter of which is incorporated herein by reference in its entirety. Technical Field

[0003] Embodiments of the present disclosure relate to methods, systems, and devices for updating the operational configuration of a medical device via remote communications and providing medical care from a remote location. Background Art

[0004] Medical devices can be used to monitor, treat, and more. Some medical devices are external to the patient, such as heart monitors, cardiac assist devices, neuromodulation devices, blood glucose monitors, ketone monitors, lactate and alcohol monitors, heart pumps, infusion pumps, deep brain stimulation devices, and smart wearables (such as smartwatches, rings, and patches) that monitor health-related characteristics. Other medical devices are implanted inside the patient.

[0005] An implantable medical device (IMD) is a medical device that is configured to be implanted within a patient's anatomy and typically employs one or more electrodes to receive voltage, current, or other electromagnetic pulses from an organ or tissue, or to deliver voltage, current, or other electromagnetic pulses to an organ or tissue for diagnostic or therapeutic purposes. Typically, an IMD may include a battery, electronic circuitry, a pulse generator, a transceiver, a microprocessor, etc. The microprocessor is configured to manage communications with external devices or instruments and to control patient treatment. The components of the IMD are hermetically sealed within the housing. The IMD is completely enclosed within the human body. Therefore, there is no means of direct interaction between the IMD and remote electronic devices except through wireless communication.

[0006] Advances in technology have opened up new ways to provide medical care to patients, including those with IMDs. Telehealth care between patients and clinicians is becoming increasingly common, with advancements in communications, where patients communicate with their clinicians via web conferencing. Furthermore, remote communication and programming of patients' medical devices can also occur remotely.

[0007] For example, an IMD may require programming updates over time to adjust the behavior and operation of the IMD. Programming updates are transmitted wirelessly from local programming electronics outside the patient's body to the IMD inside the patient's body. When updating an IMD, care must be taken to ensure that the software, firmware, applications, programs, etc. that are being updated are the updated software, firmware, applications, programs, etc. For example, when a patient experiences a health problem with their IMD and goes to the hospital, the clinician at the hospital may change the treatment, update the software, firmware, applications, programs, etc. of the IMD. If the patient then goes to their regular clinician, and the regular clinician has a different treatment or update that they wish to implement, it is important that the regular clinician be informed of the current treatment and the update to the software, firmware, applications, programs, etc. before making such a change. Otherwise, errors related to the update may occur, potentially harming the patient.

[0008] However, there remains a need for greater remote control. By remotely controlling an IMD or other medical device local to the patient, the burden can be removed from the field team. Field representatives can reduce travel and expenses by using remote communication and programming, freeing these field representatives for more complex situations. Field representatives can include anyone with the appropriate knowledge and training to perform programming of the medical device. Such field representatives can include clinicians (including clinicians at the location of the medical device or remotely), vendor technical support, etc. In addition, by remotely controlling healthcare (including IMDs), necessary care can be provided in a timely manner without the patient having to wait for a field representative to appear at the patient's location.

[0009] Furthermore, there is a greater demand for telemedicine care. Clinicians and clinician support representatives desire to communicate with each other to diagnose conditions, provide treatment, etc. for local patients while the clinician support representative is at a remote location.

[0010] When using telehealth care, a remote user can read or modify the state of a patient's medical device or interact with any external system or device connected to a programmer while supporting a local user (e.g., a nurse, equipment technician, physician, or other individual who is adequately trained to use and support such a system). In some cases, local user training may limit what such a user can or is willing to do using a programmer. Therefore, the remote control system benefits from being able to operate independently with minimal support from the local user. This allows the patient to receive the best possible care during their clinical consultation. In the method and system, the local user always has immediate control at all times to ensure safe operation of the system as the patient's condition changes. The remote user can also disable certain functions if the safety of performing them remotely is a concern.

[0011] In summary, there remains a need for improved methods, devices, and systems for performing remote communications, including communications to update programming of medical devices. Summary of the Invention

[0012] According to an embodiment, a communication system is provided that includes a remote electronic device configured to communicate with a patient's medical device via a local programming electronic device. The remote electronic device may include one or more processors configured to control the operation of the local programming electronic device to program the medical device during a dynamic session. The one or more processors may also be configured to terminate the dynamic session in response to 1) a persistent action by a user of the remote electronic device exceeding a static persistence state threshold and 2) a monitored event exceeding a dynamic threshold.

[0013] Optionally, the one or more processors may be further configured to provide a timer during the dynamic session, and determine whether the duration of the persistence action determined by the timer exceeds a static persistence state threshold.

[0014] In an example, the one or more processors may be further configured to adjust the timer based on manual input from a user of the remote electronic device.

[0015] In one example, one or more processors may also be configured to obtain patient characteristics, clinician characteristics, medical device characteristics, or monitoring characteristics, determine a static persistent state threshold based on the obtained patient characteristics, clinician characteristics, medical device characteristics, or monitoring characteristics, and update the static persistent state threshold based on the determination.

[0016] Optionally, the one or more processors may be further configured to obtain patient characteristics, medical device characteristics, or monitoring characteristics, and determine the dynamic threshold based on the obtained patient characteristics, medical device characteristics, or monitoring characteristics.

[0017] In one example, the monitoring characteristic may relate to connectivity between the remote electronic device and the locally programmed electronic device.

[0018] In one example, the dynamic session is a programming session.

[0019] In one example, the static persistence state threshold may be less than five seconds.

[0020] In an example, the one or more processors may be further configured to restore the medical device to a previous configuration via the local programming electronic device in response to termination of the dynamic session.

[0021] According to an embodiment, a communication system is provided that may include a remote electronic device comprising one or more processors configured to communicate with a local programming electronic device. The one or more processors of the remote electronic device may also be configured to control the local programming electronic device to program a patient's medical device. The local programming electronic device may include one or more processors configured to program the medical device during a dynamic session, monitor persistent actions of the remote electronic device during the dynamic session, and monitor at least one of a patient characteristic, a medical device characteristic, or a monitoring characteristic during the dynamic session. The one or more processors of the local programming electronic device may also be configured to determine a dynamic threshold based on the patient characteristic, the medical device characteristic, or the monitoring characteristic, determine whether the dynamic threshold is exceeded during the dynamic session, and determine whether a persistent action in the persistent actions during the dynamic session exceeds a static persistent state threshold. The one or more processors of the local programming electronic device may also be configured to terminate the dynamic session when 1) the dynamic threshold is exceeded, or 2) when the persistent action exceeds the static persistent state threshold.

[0022] In an example, the one or more processors of the remote electronic device are configured to terminate the dynamic session in response to a persistent action by a user of the remote electronic device exceeding a static persistent state threshold. In another example, the one or more processors of the remote electronic device are configured to terminate the dynamic session in response to a monitored event exceeding a dynamic threshold. In another example, the one or more processors of the remote electronic device are configured to terminate the dynamic session in response to a persistent action by a user of the remote electronic device exceeding a static persistent state threshold and a monitored event exceeding a dynamic threshold.

[0023] Optionally, the one or more processors of the local programming electronic device may be further configured to provide a timer during the dynamic session and determine whether the duration of the persistent action determined by the timer exceeds a static persistent state threshold.

[0024] In an example, the one or more processors of the remote electronic device may be further configured to adjust the timer based on manual input from a user of the remote electronic device.

[0025] In one example, the one or more processors of the locally programmed electronic device may also be configured to determine a static persistent state threshold based on the obtained clinician characteristics, patient characteristics, medical device characteristics, or monitoring characteristics, and update the static persistent state threshold based on the determination.

[0026] In one example, the monitoring characteristic may relate to connectivity between the remote electronic device and the locally programmed electronic device.

[0027] In one example, the persistent action may include pressing an enter button.

[0028] In an example, the dynamic session may be a programming session.

[0029] In an example, the one or more processors of the locally programmed electronic device may also be configured to restore the medical device to a previous configuration in response to termination of the dynamic session so that the medical device can provide treatment to the patient.

[0030] According to an embodiment, a communication method is provided that may include controlling a local programming electronic device using a remote electronic device to program a medical device of a patient during a dynamic session, and monitoring persistent actions of the remote electronic device during the dynamic session. The method may also include determining whether a persistent action among the persistent actions during the dynamic session exceeds a static persistent state threshold, terminating the dynamic session when the persistent action exceeds the static persistent state threshold, and, in response to terminating the dynamic session, restoring the medical device to a previous configuration to treat the patient.

[0031] Optionally, the method may further include monitoring at least one of a patient characteristic, a medical device characteristic, or a monitoring characteristic during the dynamic session, and determining a dynamic threshold based on the patient characteristic, the medical device characteristic, or the monitoring characteristic. The method may further include determining whether the dynamic threshold is exceeded during the dynamic session, and terminating the dynamic session when the dynamic threshold is exceeded.

[0032] In one example, determining the static persistent state threshold may include at least one of: 1) receiving manual input from a remote user of the remote electronic device, or 2) determining the static persistent state threshold based on patient characteristics, clinician characteristics, medical device characteristics, or monitoring characteristics. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 is a schematic block flow diagram of a system operating according to an embodiment.

[0034] Figure 2 is a schematic block diagram of an electronic device according to an embodiment.

[0035] Figure 3 is a schematic diagram of a system according to an embodiment.

[0036] Figure 4 is a simplified block diagram of a system operating in accordance with embodiments herein.

[0037] Figure 5 is a block diagram of a medical device according to an embodiment.

[0038] Figure 6 is a block flow diagram of a method for providing input to an IMD from a remote electronic device, according to an embodiment.

[0039] Figure 7is a diagram of an input screen used during a device session according to an embodiment.

[0040] Figure 8 is a diagram of an input screen used during a device session according to an embodiment. DETAILED DESCRIPTION

[0041] Embodiments herein provide methods, devices, and communication systems designed to enhance the integrity and authenticity of wireless programming communications between one or more remote electronic devices and medical devices, such as IMDs. Embodiments facilitate secure termination of temporary actions due to a remote user's persistent actions exceeding a static persistence state threshold, or due to a dynamically monitored event.

[0042] During a communication session (also referred to as a remote session) between a remote electronic device used by a remote user at a remote location and a local programming electronic device located at a patient's medical device and used to program the medical device, a dynamic session can occur, in which the remote electronic device controls the local programming electronic device to program the local medical device (such as an IMD). During this dynamic session, many modes of remote user input can be provided. Modes of user input to the system vary and include, but are not limited to, button presses or swipe gestures, touchscreen controls or virtual reality peripherals, hand or motion gestures (detected optically, electrically, or otherwise), voice commands and / or sounds, facial recognition, or any similar form of human-device interaction. Some user inputs can be single and instantaneous events, while others can involve a series of actions over an extended period of time. An example of an extended action includes a remote user pressing and holding the console touchscreen (or holding a mouse button pressed) to initiate an action, then releasing the touchscreen (or mouse button) at a later time to end the action. Thus, non-instantaneous user input can be used to control sequential actions, or actions whose duration is intended to be user-controlled and temporally limited (such as the actions in the examples provided above). These extended actions, having a start and end defined based on user input, are referred to herein as persistent actions.

[0043] The ability for a remote user to initiate a persistent event can take many forms. A persistent event can include temporarily changing the device state or initiating a sequence of events (i.e., a test), where the duration of such an event is inherently variable and should only persist as directed by the remote user and / or when the status of various interactive systems is satisfactory. An example of such an event and condition is a manual decrement capture test of an implantable cardiac rhythm monitoring device, where, if the system's temporary condition persists after a loss of pace capture, or the patient's condition otherwise changes for any reason, the loss of pace may result in an inability to deliver necessary pacing therapy, leading to insufficient cardiac output. Input from the operator of the local programming electronic device (e.g., the local user and / or the remote user) is essential to ensure that the temporary condition does not persist longer than necessary. The provided system terminates the persistent action upon any change in any state monitored by the system, including, but not limited to, the condition (state) of a component in the system, the patient's physical condition, or the communication channel between any component of the system (i.e., the remote electronic device and the local programming electronic device). The persistent action may or may not be associated with a temporary change in the operating condition of the system by the local or remote user.

[0044] As described above, there are two means of safely terminating persistent actions: static thresholds and dynamic monitoring, which can be used independently or together as needed. Static thresholds terminate any persistent action after a preprogrammed time limit or event count, such as independently managed within the medical device or within the local programming electronic device used to program the medical device. The termination of an action performed by a remote electronic device due to loss of communication with the remote electronic device can be limited to actions initiated by a remote user. Static thresholds can be fixed or configurable to extend the utility of the local programming electronic device so that the threshold can adapt to the different needs and applications it is used for. For example, the timing required to safely self-terminate an action may vary depending on the action or the patient, etc. A remote user action button or similar interface can also be provided to configure the system so that the fixed threshold for subsequent persistent actions can be varied. Such a design can take into account the safety level required for a given action, the training level of the remote user or local user, the patient's physiology, or any other factors.

[0045] The locally programmed electronic device independently enforces the termination of persistent events using either static threshold defaults or user-provided thresholds. Following an action initiated (such as by a remote user), the event is terminated based on a locally implemented counter or timer, regardless of the state of the system (or the state of connectivity between systems or any other attribute). The advantage of this design is that it provides independent security controls with flexibility. This flexibility is provided to address practicality, as some persistent actions are not associated with security concerns, or where system security can tolerate longer communication interruptions or greater variability in system or patient conditions. Shorter durations are used by default and where appropriate. By implementing these controls in independent layers of the system, such as between the remote and locally programmed electronic devices and in communication with other connected devices and systems, the security mechanism operates independently and applies to any aspect of the locally programmed electronic device's operation.

[0046] The challenge with static designs (with or without configuration) is that for more critical features or in situations where training of a local or remote user cannot be ensured, the required fixed short thresholds may not be sufficient for the wider set of tasks supported by locally programmed electronics, which also use persistent user input to control the system. In this context, persistent means a single but extended duration of action, such as the simple case of pressing and holding a button without releasing it. Variations in the design (such as allowing configurable thresholds) are possible but increase complexity and the potential for usage errors. Features to reinitialize or restore the thresholds to their safest values ​​become necessary and must account for a wide range of factors, making use and maintenance more difficult. For these reasons, dynamic monitoring of system state to terminate persistent actions is also considered.

[0047] Dynamic monitoring can independently utilize or extend the utility of static persistent state thresholds. Dynamic monitoring can terminate a persistent (local or remote user) action only upon detecting a change in system state (such as due to a loss of communication between the remote electronic device and the locally programmed electronic device, a change in the state of the locally programmed electronic device or a connected system of a medical device such as an IMD, user input from a local user, a change in the state or condition of the patient or the patient's implanted device detected through any channel such as an external cardiac monitor or alarm, etc.). If a change in state cannot be detected directly and instantaneously, a fixed static persistent state threshold can be used in addition to periodic monitoring of dynamic inputs. For example, the start of the static time evaluation can be reset periodically, such as each time the dynamic state is successfully reevaluated. Thus, a persistent action will automatically terminate only after a combination of predefined static persistent state thresholds has been reached since the last dynamic state event was reevaluated. While some dynamic state events can be monitored completely independently within the locally programmed electronic device, other state events may involve the periodic transmission of information between systems. For example, the remote electronic device (or other externally monitored input source) may periodically (such as once every 100 milliseconds (ms), once per second, once per minute, etc.) send status updates to the local programming electronic device to confirm that communication between the two devices exists, that the communication delay is sufficient to perform such an action, or that some other criteria essential to the safety or performance of the system are met. If the aforementioned static persistence state threshold is reached (i.e., the timer expires) after the local programming electronic device receives the most recent periodic status update, this may be interpreted as a loss of communication, requiring automatic termination of the persistence action, because remote user input cannot be sent to the local programming electronic device when the communication channel is unavailable.

[0048] It will be readily understood that, in addition to the described example embodiments, the components of the embodiments as generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations. Accordingly, the following more detailed description of the example embodiments as represented in the figures is not intended to limit the scope of the claimed embodiments, but is merely representative of example embodiments.

[0049] Reference throughout this specification to "one embodiment" or "an embodiment" (etc.) means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearances of the phrases "in one embodiment" or "in an embodiment" etc. in various places throughout this specification are not necessarily all referring to the same embodiment.

[0050] In addition, the described features, structures or features may be combined in any suitable manner in one or more embodiments. In the following description, many specific details are provided to provide a thorough understanding of the embodiments. However, those skilled in the relevant art will recognize that various embodiments may be practiced without one or more specific details or using other methods, components, materials, etc. In other instances, well-known structures, materials or operations are not shown or described in detail to avoid confusion. The following description is intended to be illustrative only and simply illustrates certain example embodiments.

[0051] The methods described herein may employ structures or aspects of various embodiments (e.g., systems, devices, and / or methods) discussed herein. In various embodiments, certain operations may be omitted or added, combined, performed simultaneously, performed concurrently, split into multiple operations, performed in a different order, or re-executed in an iterative manner. It should be noted that other methods may be used depending on the embodiments described herein. Furthermore, where indicated, the methods may be implemented in whole or in part by one or more processors of one or more devices or systems. While some method operations may be described as being performed by a processor of one device, some or all of such operations may alternatively be performed by a processor of another device as described herein.

[0052] As used herein, the term "local programming electronic device" refers to any and all electronic devices used by nurses, caregivers, equipment technicians, physicians, other individuals adequately trained to use and support such systems, or similar personnel, that are local to or in close proximity to a patient and are used to program a medical device associated with the patient. A local programming electronic device can be a central processing unit (CPU), desktop computer, laptop computer, smartphone, smartwatch, monitor, handheld device, portable or industrial device such as an activator, tablet computer, console including a monitor console, etc., that interacts with the medical device to retrieve or update any information or settings during a communication session with a remote user. In one example, the local programming device can be within the patient's IMD. For this purpose, an IMD that includes the functionality of a local programming electronic device as described herein is considered an IMD with a local programming electronic device, regardless of whether the device is physically separate from the IMD. The local programming electronic device includes one or more processors configured to follow instructions and a transceiver configured to communicate via a network, in the cloud, via Bluetooth Low Energy (BLE), wirelessly, over the air, via a cable, etc. In one example, the local programming electronic device communicates with the patient's device. In another example, the local programming electronic device is local to the patient and can communicate with medical devices (including the patient's IMD). In this manner, the local programming electronic device can be local to the patient and communicate with the patient's medical devices. Furthermore, while the term "programming" is used as part of the term "local programming electronic device," a local electronic device that performs programming, such as a local electronic device that causes a dynamic event (such as interrogation of a medical device), can be considered a local programming electronic device.

[0053] As used herein, the term "remote electronic device" refers to any and all electronic devices that are not located near the patient. The remote electronic device must communicate with an electronic device (such as a programming device or other type of local programming electronic device) at the patient's location via a network, mesh network, wirelessly, wired, or the like. In one example, the remote electronic device communicates with a local programming electronic device, which may be local to the patient and communicates with the remote electronic device. In an example, the local programming electronic device is configured to be operated by a nurse, caregiver, equipment technician, physician, other individual who is fully trained to use and support such a system, or the like, while the remote electronic device may be operated by a clinician, clinician support representative, or the like. In particular, the remote electronic device communicates with the local programming electronic device via a network, an engine, or the like.

[0054] As used herein, the term "communication session" is any period of time dedicated to communicating between a remote electronic device and a locally programmed electronic device over a network, a mesh network, wirelessly, by wire, etc., to provide information and data between a patient and medical personnel (e.g., a clinician) or between two or more medical personnel (e.g., a clinician and a clinician support representative). In an example, the communication session between the locally programmed electronic device and the remote electronic device can be conducted via a network, an engine within the network at a cloud location, etc.

[0055] As used herein, the term "device session" refers to any period of time during which a local programming electronic device communicates with a local medical device. In one example, the medical device may be an IMD. A device session can and often does occur during a communication session between a remote electronic device and a local programming electronic device. In such an example, the remote electronic device can control the local programming electronic device to communicate with and program the medical device.

[0056] As used herein, the term "dynamic session" refers to a period of time during which a medical device communicates with another electronic device and during which changes are made to the medical device. In examples, the changes include updates, modifications, alterations, queries, etc., to the medical device's software or hardware. In examples, the changes may include changes to parameters used by the medical device for its intended purpose. For example, the parameters may be thresholds used to determine whether to indicate a diagnosis, provide pacing or other therapy, etc. In examples, the electronic device may be a locally programmed electronic device, a remote electronic device communicating with the medical device via the locally programmed electronic device, etc. In examples, a dynamic session may occur during both a communication session and a device session. In one example, a dynamic session is a period of time during which an electronic device (such as a locally programmed electronic device and / or a remote electronic device) operates to program the medical device. In an example, a dynamic session occurs during a device session when the locally programmed electronic device communicates with the medical device. When the locally programmed electronic device engages in a communication session with a remote electronic device, the remote electronic device may provide input to the medical device via the locally programmed electronic device during the dynamic session. In another example, during a dynamic session, the electronic device (such as the locally programmed electronic device and / or the remote electronic device) operates to query the medical device to obtain medical device data and information to ensure proper operation of the medical device, etc.

[0057] As used herein, the term "programming" refers to any and all updates, changes, modifications, alterations, etc., made directly to software or hardware. In example embodiments, this "programming" is accomplished by a remote electronic device to a medical device or local programming electronic device, or indirectly, where a remote user updates the settings or configuration of the medical device or local programming electronic device via a connection from the remote electronic device. For example, there are some device tests that are run as a group. The selection of which tests to run and their configurations is controlled by the local programming electronic device (programmer) software. The local user can set all the parameters to be used for all the tests in question and then run them in a batch / group. While the local user does not participate in some persistent action, such as holding down a mouse button throughout such a test flow, a similar concept applies. Furthermore, designs can be provided where the remote user can now remotely set all the same test parameters. If the remote electronic device loses remote connectivity or a change in the patient's condition is required, it would be appropriate to abort the entire series of tests. In yet another embodiment, "resetting" the state of the IMD and programmer would be appropriate to terminate the batch task series.

[0058] As used interchangeably herein, the terms "persistent event" and "persistent action" refer to events or actions that continue or persist over an extended period of time. Examples of persistent events and persistent actions include any human-machine interaction, input, physical presses, or depressions performed by a user of an electronic device during a dynamic session. In one example, a persistent event or persistent action is pressing an input button on a keyboard of an electronic device during a dynamic session. In another example, input on a touch-sensitive input screen is a persistent event or persistent action during a dynamic session. In another example, an auditory instruction that can be implemented by the electronic device is a persistent event or persistent action. In each example, the action occurs over an extended or prolonged period of time. For this purpose, an extended action (e.g., a persistent action) can also include a remote user pressing and holding a console touchscreen (or holding a mouse button in a depressed state) to initiate the action, and then releasing the touchscreen (or mouse button) at a later time to end the action. In one example, the extended period of time can be any time equal to or greater than two seconds.

[0059] As used herein, the term "static persistent state threshold" indicates a determined amount of time for a persistent event or persistent action to occur. In one example, the static persistent state can be measured in seconds, while in other examples, it can be measured in milliseconds, minutes, other time increments, etc. To this end, the static persistent state threshold can be 2 seconds, 3.5 seconds, 5 seconds, 10.932 seconds, etc. It can also be configured to be indefinite in duration, effectively bypassing the functionality (if appropriate). The static persistent state threshold can be determined by the electronic device based on features, manual input into the electronic device, etc. Nevertheless, once a dynamic session begins, the static persistent state threshold can only be changed or updated during the dynamic session by manual input, such as if the user cancels a programming operation.

[0060] As used herein, the term "monitored event" refers to any occurrence of a process detected by a sensor. In an example, the process may be an amount of time to reach a threshold, a sensed voltage to reach a threshold, a detected oxygen level to reach a threshold, a determined amount of time during a determined time period, etc. In a specific example, a monitored event represents the amount of time that a monitored parameter reaches a threshold. An example of a sensor may be any sensor of an electronic device that detects a function of the electronic device. An example of a sensor may also be a physiological sensor configured to sense respiratory rate, blood pH, ventricular gradient, activity, body movement, positioning / posture, minute ventilation (MV), etc. In an example, a monitored event may be the amount of time that a key on a keyboard of an electronic device is pressed.

[0061] As used herein, the term "dynamic threshold" refers to a threshold value, such as a limit, maximum, minimum, baseline, etc., that is continuously and repeatedly determined, calculated, or obtained in real time based on characteristics (including data and information continuously and repeatedly obtained in real time). Characteristics may include patient characteristics, clinician characteristics, monitoring characteristics, medical device characteristics, IMD characteristics, etc. Dynamic thresholds may be measured in terms of time, oxygen level or volume, pressure, temperature, pulse rate, electrical value, voltage, current, velocity, etc., and may be measured, determined, calculated, obtained, etc.

[0062] As used herein, the term "real-time" refers to a time that occurs at the same time or substantially simultaneously with the occurrence of another event or action. For the avoidance of doubt, as an example, when a dynamic threshold is dynamically determined, changed, updated, etc. in real-time, the dynamic threshold is determined, changed, updated, etc. every few milliseconds, every few seconds, etc.

[0063] As used herein, the term "monitored event" refers to any condition, state, measurement, determination, calculation, etc., that is related to a dynamic threshold. For example, when the dynamic threshold is based on the patient's measured blood pressure, obtaining the blood pressure is a monitored event. In another example, when the dynamic threshold is a risk score associated with the patient's health risk determined via calculation, modeling, a decision tree, a lookup table, etc., determining the risk score is a monitored event. For this purpose, a monitored event can be, but need not be, a direct measurement obtained, but can be determined, calculated, etc. based on more than one factor, feature, parameter, etc.

[0064] As used herein, the terms "obtain" and "obtaining" in connection with data, signals, information, etc., include at least one of: i) accessing a memory of an electronic device, including a remote server storing data, signals, information, etc., ii) receiving data, signals, information, etc. via a wireless communication link between a medical device and a locally programmed electronic device, iii) receiving data, signals, information, etc. via a wired or wireless communication link and transceiver between a sensor, peripheral device, diagnostic device, or other system connected to the locally programmed electronic device, and / or iv) receiving data, signals, information, etc. at a remote server via a network connection. When viewed from the perspective of an IMD, an "obtain" operation may include sensing new signals in real time and / or accessing memory to read stored data, signals, information, etc. from memory within the IMD. When viewed from the perspective of a locally programmed electronic device, an "obtain" operation may include receiving data, signals, information, etc. at a transceiver of the locally programmed electronic device, where the data, signals, information, etc. is transmitted from a medical device, diagnostic sensor or system, and / or a remote server. The "obtain" operation can be from the perspective of the remote server, such as when receiving data, signals, information, etc. from a local programming electronic device and / or directly from a medical device at a network interface. The remote server can also obtain data, signals, information, etc. from local memory and / or from other memory (such as within a cloud storage environment) and / or from a workstation or memory of a clinician programming device.

[0065] As used herein, the term "engine" refers to any processor, electronic device having a processor, server, or similar device configured to communicate with an electronic device via a network, mesh network, wirelessly, wired, or the like, within a cloud, network, or the like, that can make a determination. In one example, the engine can be a remote programming engine (RPE) that communicates with a local programming electronic device. In another example, the RPE communicates between the local programming electronic device and the remote electronic device.

[0066] Figures 1 to 2An embodiment of a communication system for providing remote medical care is presented. In this embodiment, the Medical Device Remote Control System (MDRC system) provides a reliable, secure, end-to-end process for programming medical devices via remote electronic devices and local programming devices. All communications and operations between remote and local users over supported connectivity protocols (including cloud networks and Bluetooth) are securely signed and encrypted. To this end, all such communication sessions can optionally be logged, and all operations can be documented.

[0067] Figure 1 MDRC system 100 is shown and includes an engine 102, a medical database 103, a programming application 104 accessible within a local programming electronic device 106 for a local user 108 (e.g., a nurse, paramedic, equipment technician, physician, other individual sufficiently trained to use and support such a system, etc.), a remote control (RC) application 110 at a remote electronic device 116 for a clinical support representative 112 (e.g., a clinician, clinical support representative, etc.), and at least one medical device 114. By providing MDRC system 100, communication sessions, device sessions, and dynamic sessions can all be provided.

[0068] The engine 102 may include one or more processors for executing instructions to perform the processes and methods described herein. The engine 102 may also include memory or storage devices for storing information, including patient information, medical device information, treatment information, and the like. In an example, the engine 102 resides in a cloud environment that can be accessed by a number of electronic devices in addition to the locally programmed electronic device 106 and the remote electronic device 116. In one example, the engine 102 is coupled to a medical database 103, which includes medical device information, electronic device information (including electronic device information related to the locally programmed electronic device 106 and the remote electronic device 116), active or historical remote sessions, and the like. The stored information may relate to an individual patient, a plurality of patients, patient medical devices, generic medical devices, studies, tests, other patient information, and the like. In short, the medical database 103 and the engine 102 may be coupled within a network (including a mesh network, a cloud network, a Bluetooth network, and the like) and communicate with multiple locally programmed electronic devices, multiple remote electronic devices, and the like to obtain information related to multiple patients, medical devices, treatments, and the like. In this manner, the medical database 103 may include algorithms, including artificial intelligence algorithms, for analyzing information obtained from multiple patients, medical devices, treatments, etc., to program, provide recommendations, modify, update, change, etc. the medical devices, treatments, etc. accordingly.

[0069] Locally programmed electronic device 106 is an electronic device located at the location of the patient and / or medical device 114. Locally programmed electronic device 106 is considered local because the patient and / or medical device 114 is at the location of local programming electronic device 106 and is not remotely located from the patient and / or medical device 114. In one example, medical device 114 is an IMD. In another example, medical device 114 may be an insertable cardiac monitor (ICM), a neurostimulation device, a heart pump, a sensor, a clothing accessory, an external patient monitor, etc. Therefore, medical device 114, as used throughout this document, refers to any such type of medical device or sensor, regardless of whether the device is held by the patient, inserted, implanted, or worn externally and temporarily. Locally programmed electronic device 106 may be an industrial medical device, a laptop computer, a desktop computer, a mobile device, a server, a tablet computer (i.e., an iPad), etc.

[0070] The local programming electronic device 106 may include one or more processors for executing instructions to perform the processes and methods described herein. The local programming electronic device 106 may also include memory or storage devices for storing information, including patient information, medical device information, treatment information, and the like. The local programming electronic device 106 may also include an interface so that a local user 108 (such as a nurse, caregiver, device technician, physician, or other individual sufficiently trained to use and support such a system) can input information into the local programming electronic device 106. In one example, the interface is an input device, which may include a touch screen, keyboard, mouse, microphone, or the like, for providing information, commands, and the like to the local programming electronic device 106. Furthermore, the local programming electronic device 106 may include an output device, such as a screen, display, speaker, or the like, for providing information and data to the local user 108. The local programming electronic device 106 can thus be used by the local user 108 to obtain information directly from the medical device 114 and / or the patient having the medical device 114.

[0071] When the local user requests and approves support from the remote user, upon powering on the local programming electronic device 106 or the like, according to a design embodiment, the local programming electronic device 106 detects network connectivity and automatically performs an analysis to ensure that the engine 102 is operational and connected. Connectivity is defined and determined by an identifier, name, serial number, etc. associated with the local programming electronic device 106, a version of the software, firmware, etc. of the clinician application 104, an operating system, etc. of the local programming electronic device 106, a location or region of the local programming electronic device 106, or the like. This information can be used to confirm compatibility of system components, enhance performance or resources used by the system, or configure various aspects of the system as needed to meet local geographic and / or legal requirements.

[0072] The remote electronic device 116 is located remotely or away from the patient and / or medical device 114. The remote electronic device 116 may typically be located in a physically remote location such as a hospital, a clinician's office, a clinician's home, or away from the patient and / or medical device 114, but it may also be used in the vicinity of, but not adjacent to, the patient and / or medical device 114. The remote electronic device 116 may be a laptop, desktop computer, mobile device, server, tablet (i.e., iPad), etc., that includes an interface such as a browser window or application that allows a clinical support representative 112, such as a clinician, clinician support representative, etc., to enter information into the remote electronic device 116. In one example, the remote electronic device 116 is a networked electronic device.

[0073] The remote electronic device 116 may include one or more processors and a memory for running instructions and storing information, such as the local programming electronic device 106 and the engine 102. In addition, similar to the local programming electronic device 106, the remote electronic device 116 may include an interface that is both an input device and an output device. The remote electronic device 116 also includes an RC application 110, which includes program instructions for obtaining patient information from the medical database 103 via the engine 102. The RC application 110 may also communicate with the clinician application 104 to obtain physiological information related to the patient obtained from the medical device 114 via the engine 102. The user interface of the local programming electronic device 106 can be shared directly with the clinical support representative 112 through the remote electronic device 116 and the RC application 110, thereby allowing remote users to interact with the local programming electronic device 106 as if they were standing next to the device 106 and the patient.

[0074] When the clinical support representative 112 turns on the remote electronic device 116, the remote electronic device 116 authenticates and registers the user. Upon power on and / or approval by the local user to initiate a communication session that is considered a remote session using the locally programmed electronic device 106, the remote electronic device 116 automatically performs an analysis to ensure that the engine 102 is operable with the locally programmed electronic device 106 based on an identifier, name, serial number, etc. associated with the locally programmed electronic device 106, a version of software, firmware, etc. of the RC application 110, an operating system, etc. of the remote electronic device 116, a location or region of the remote electronic device 116, etc. Alternatively, in other embodiments, the local user initiates the remote session.

[0075] Figure 2 1 shows a schematic block diagram of an electronic device 200. In one example, the electronic device 200 is Figure 1 In another example, the electronic device 200 may be a local programming electronic device 106. Figure 1The remote electronic device 116. The electronic device 200 can be an industrial medical device, a laptop computer, a desktop computer, a mobile device, a server, a tablet computer (ie, iPad), etc.

[0076] The electronic device 200 may include one or more processors 202, a storage device or memory 204, and a transceiver 206. The transceiver 206 is configured to communicate with other electronic devices via a network 210. To this end, the transceiver may communicate with a server, an engine, etc. located in the cloud via Bluetooth or the like. In addition, the transceiver may communicate with a medical device 212 (such as Figure 1 114) communication with the medical device.

[0077] Medical device 212 can be similar to the IMDs described herein or any of the figures herein. Transceiver 206 can communicate with medical device 212 remotely or directly via network 210. In another example, transceiver 206 can communicate with auxiliary electronic device 213a, remote electronic device 213b, or remote auxiliary electronic device 213c. In an example embodiment, auxiliary electronic device 213a can be a smartphone, tablet (e.g., iPad®), or the like that can receive text messages (such as Short Message Service (SMS) messages) via the network. Remote auxiliary electronic device 213c can similarly be a smartphone, tablet (e.g., iPad®), or the like that can also receive text or SMS messages. In this manner, electronic device 200 can receive identification information from a clinician, clinician support representative, or the like, and the text or SMS message can be provided by electronic device 200 to auxiliary electronic devices 213a and / or 213c to verify that the clinician or clinician support representative has indeed provided the identification information. The identification information can include a username, password, login name, or the like. Additional security is provided by using communication signals between the auxiliary electronic device 213a and the remote auxiliary device 213c. The text messages mentioned above, such as Short Message Service (SMS) messages, can be replaced with any secure and encrypted form of communication that supports authentication and authorization of users and information exchanged over the network 210. This can include additional layers to meet the security requirements of the system including the electronic devices described herein (e.g., electronic device 200 and auxiliary or remote electronic devices 213a to 213c), including but not limited to: two-factor authentication, verbal challenge and authentication, non-repudiation checks, integrity checks, and any additional functionality to ensure the confidentiality, availability, and integrity of communications.

[0078] In one example, the electronic device 200, or any of the auxiliary or remote electronic devices 213a, 213b, 213c, can provide a communication channel between a remote user and a medical device 212 (such as an IMD). The communication channel can be directly to the medical device 212, or alternatively, can be provided as a communication channel via a local programming electronic device (such as Figure 1 Regardless of whether the communication channel is a direct or indirect connection, each of the electronic devices 200, 213a, 213b, 213c can be used to provide a communication path to the medical device 212 to the remote user so that the remote user can have control of the dynamic session, as described herein.

[0079] The electronic device 200 may also include an interface 214, which may include an input 216, such as a touch screen, a keyboard, a mouse, a microphone, and the like. To this end, the input 216 may include a button of a keyboard or mouse that can be pressed temporarily or held down for a period of time. The input 216 may also include a sliding action widget, a touch screen control, or a virtual reality peripheral device. In another example, the input 216 may be a device that can detect hand or motion gestures (optically, electrically, or otherwise), voice commands and / or sounds, facial recognition, any similar form of human-device interaction, and the like. Therefore, the input may be a camera, a microphone, and / or other sensor for receiving data and / or information and / or commands and / or instructions from a user.

[0080] The electronic device 200 may further include an output 218, which may further include a touch screen, a display, a speaker, etc. To this end, the input 216 and the output 218 may include the same interface, display, etc. The electronic device 200 also includes a power supply module 220 for powering the electronic device 200. The electronic device 200 may also include a timer 222, which may be used to determine whether a persistent action has exceeded a persistent state threshold during the time that the electronic device 200 is being used to program, update, change, etc. the IMD.

[0081] A persistent action is one in which the activity is prolonged or persists, such as when a button, touchscreen, etc. is actuated (e.g., held down) for a period of time before being released or ending actuation. This period of time can be one second, two seconds, five seconds, etc. Alternatively, the action can be prolonged by repeatedly providing user input in some form (such as pressing the user input multiple times during a time interval or period). Continuous gestures, voice input, mechanical input, etc. can also be used to prolong user input actions. For example, a button may need to be pressed three or more times within a five-second interval. Therefore, any form of repeated user input (such as repeatedly pressing a button during a time interval) can also be considered a persistent action or persistent event.

[0082] Figure 3 is a schematic diagram of a communication system 300 according to an embodiment. In one example, the communication system 300 is Figure 1 The communication system 300 is sent to Figure 3 The communication system 300 provides secure communication with a medical device represented by IMD 302. In addition to IMD 302, the communication system 300 also includes one or more external devices. In the illustrated embodiment, the external devices include a remote electronic device 304 and a local programming electronic device 306, but in other embodiments, the communication system 300 may include more than two external devices. The remote electronic device 304 may be Figure 1 The remote electronic device 116 in the Figure 2 The implementation shown, and the local programming electronic device 306 can be Figure 1 The local programming electronic device 106 in the Figure 2 Implementation shown.

[0083] In one example, remote electronic device 304 may be remote from IMD 302 and communicate with local programming electronic device 306 to program IMD 302. In such an embodiment, a remote user (such as a clinician) can utilize remote electronic device 304 to control the operation of local programming electronic device 306, including gaining access to all information and functionality of local programming electronic device 306. To this end, remote electronic device 304 can control the operation of local programming electronic device 306 to provide user input, such as programming input, to IMD 302. In such an embodiment, local programming electronic device 306 may be local to IMD 302 and operated and / or monitored by a nurse, caregiver, device technician, physician, or other individual adequately trained to use and support such a system. Thus, the local user supervises the patient during such updates to IMD 302's programming. The local user can periodically assess the functionality of communication system 300 to identify potential interruptions in communication that could interfere with the ability of remote electronic device 304 to control local programming electronic device 306.

[0084] In this embodiment, the mode of user input from remote electronic device 304 to IMD 302 can vary and include, but are not limited to: button presses or swipe gestures, touchscreen controls or virtual reality peripherals, hand or motion gestures (detected optically, electrically, or otherwise), voice commands and / or sounds, facial recognition, any similar form of human-device interaction, and the like. Some user inputs can be single and instantaneous (momentary) events, while other user inputs can involve a series of actions over an extended period of time. An example of an extended action includes a remote user pressing and holding the console touchscreen (or holding a mouse button in a depressed state) to initiate an action, then releasing the touchscreen (or mouse button) at a later time to end the action. Thus, non-instantaneous user input can be used to control sequential actions, or actions whose duration is intended to be controlled by the user and is temporally limited (such as the actions in the examples provided above).

[0085] The ability for a remote user at remote electronic device 304 to initiate a persistent event using local programming electronic device 306 acting as a programming device can take many forms. Persistent events can include temporarily changing device state or initiating a sequence of events (i.e., a test), where the duration of such events is inherently variable and should only continue as directed by the remote user and / or while the status of various interactive systems is satisfactory. For example, a manual decremental capture test for an implantable cardiac rhythm monitoring device can be provided, where continuing the test beyond an initial loss of capture results in a loss of pacing therapy. Continuing such a test after a loss of capture is detected, or after a change in the patient's condition or for any other reason, could result in an inability to deliver necessary pacing therapy to the patient, thereby resulting in inadequate cardiac output. Consequently, communication system 300 allows the user to input a static persistent state threshold to limit the time the user must complete the test before restoring IMD 302 to its previous state, ensuring that IMD 302 functionality is not compromised if the threshold is exceeded. Thus, if a connection loss causes the test to not complete before the static persistent state threshold, by having a static persistent state threshold, IMD 302 automatically reverts to its previous state, preventing the negative effects of untimely testing. This improves upon the manual monitoring of the communication system 300 described above and eliminates the need for manual intervention to ensure safety.

[0086] In another example, part of testing, programming, etc., may be resetting a function. To reset the function, a user input, such as a key, spacebar, back button, mouse, touchscreen position, etc., must be pressed and held for an extended period, such as 5 seconds, to cause the reset. A static persistence state threshold of 10 seconds can then be set for this action. In this manner, if a disconnection or other event occurs that causes the press or hold state to be considered to have continued for more than the 10-second static persistence state threshold, the IMD 302 function is automatically restored accordingly.

[0087] In addition to static persistent state thresholds, dynamic thresholds can also be determined based on IMD characteristics, patient characteristics, monitoring characteristics, and the like, each of which is considered a monitored event. Patient characteristics include any and all data and information related to the patient. Example patient characteristics include patient age, health status, number of surgeries, medications currently taken, current pulse rate, current blood pressure, and the like. Patient characteristics can be obtained from the memory of the remote electronic device 304, the locally programmed electronic device 306, a cloud-based device, another electronic device, input into the remote electronic device 304 or the locally programmed electronic device 306, received from local sensors, and the like. Clinician characteristics can include any and all data and information related to the clinician and / or their management of the patient. This information can include manual input provided by the clinician regarding the clinician's preferences for how long an action, test, or programming duration should last. Clinician characteristics can also be determined, calculated, and the like based on historical data related to other clinicians, physicians, standards of care, and the like who are performing the same or similar persistent actions. In one example, a clinician may have a profile that includes clinician characteristics. IMD characteristics include all information and data related to the IMD 302. This may include information that may be entered or obtained from memory, such as IMD type, model, age, usage, programming, etc. IMD characteristics may also include data and information obtained from sensors related to the current operation of the IMD 302. Meanwhile, monitoring characteristics may include any and all information that may be obtained by sensors of the communication system 300 or obtained by the communication system 300. This includes connectivity data related to communications between the remote electronic device 304 and the local programming electronic device 306, communication signal strength, ambient electrical noise, etc. Additionally, monitoring characteristics may include information and data related to cardiac signals, pulse rate, oxygen levels, etc. that may be monitored. For this purpose, some patient characteristics may also be considered monitoring characteristics.

[0088] These characteristics can be monitored so that if a monitored event occurs that exceeds a dynamic threshold, IMD 302 automatically reverts to its initial state in real time. In one example, the dynamic threshold can extend or replace the static persistent state threshold, such that the dynamic threshold can provide additional time for testing to complete before restoring IMD 302 functionality. In another example, the dynamic threshold can depend on the state of the communication channel between remote electronic device 304 and local programming electronic device 306. Thus, if a disconnection occurs or a loss of connection is detected and immediately reported, the threshold can be deemed automatically reached or achieved, causing IMD 302 to revert to its previous operating state without waiting for a threshold timer (or counter) to be reached.

[0089] The remote electronic device 304 and the local programming electronic device 306 include corresponding controller circuits (e.g., controllers 316, 322) and communication circuits 318, 320. Each controller includes one or more processors. In the above process, the controller 316 of the remote electronic device 304 generates a programming package 308. The communication circuit 318 of the remote electronic device 304 transmits the programming package 308 to the local programming electronic device 306 via the network 310. The communication circuit 320 of the local programming electronic device 306 receives the programming package 308 and passes the package 308 to the IMD 302. The communication circuit 320 may include an antenna 324 that wirelessly transmits the programming package 308 via an RF signal such as Bluetooth. The signal representing the programming package 308 penetrates the patient's body 326 and reaches the receiver of the IMD 302. The receiver may be Figure 5 , which passes the received data packets to one or more processors of controller 316 for analysis. In this way, IMD 302 is advantageously able to receive programming package 308 without requiring a network connection or proximity sensor.

[0090] In another example, local programming electronics 306 processes payload 314 and updates the programming of IMD 302 accordingly, as if instructed by a local user. This request can be a single input (such as a button press) or an input packet as previously described. Network security controls exist to ensure that payload 314 within packet 308 is valid before local programming electronics 306 operates on it and before the update is transmitted to IMD 302.

[0091] In instances as described above where communication of programming package 308 from the source to IMD 302 is delayed and / or indirect, there is a risk that the contents of programming package 308 may be tampered with or corrupted after generation and before receipt by IMD 302. Communication system 300 and methods described herein may perform cryptographic operations to ensure that configuration change request or payload 314 is unalterable and that the source of package 308 is authenticated before execution by IMD 302.

[0092] In yet another example, a hybrid option can be provided, where security credentials and features apply to both the higher-level message or package 308 and the inner message or payload 314, but only the inner message or payload 314 is forwarded to IMD 302. In other words, the locally programmed electronic device 306 only forwards the payload 314 to IMD 302. The locally programmed electronic device 306 verifies that the contents of the package 308 are valid before allowing the payload 314 to be sent to IMD 302. In one example, verification can be based on similar but different security features used with the request (e.g., a key), the payload 314 still being verified by IMD 302, or controls present when communication is established between the locally programmed electronic device 306 and IMD 302. For example, the message in package 308 can be signed with a key known only to the locally programmed electronic device 306. If the locally programmed electronic device 306 determines that the package 308 is valid, the payload 314 is extracted and processed by the locally programmed electronic device 306. A secure connection with IMD 302 is established using appropriate network controls (independent of the system). Once connected, the result of the operation contained within the message or payload 314 causes the controller 322 within the local programming electronic device 306 to send the desired configuration update to the IMD 302. Optionally, the message of package 308 is signed with a key known only to the local programming electronic device 306. If the local programming electronic device 306 determines that the package 308 is valid, the payload 314 is extracted and sent to the IMD 302. The message of payload 314 itself is signed with a key known only to the IMD 302, which can then be verified as previously described.

[0093] Figure 4 A system 410 is shown that includes an IMD 412 , which may be coupled to one or more external devices or instruments 414 . Figure 4 4. A single external device 414 is shown in FIG. In an example embodiment, the external device 414 may be a remote electronic device, a remote server, etc. The IMD 412 and the external device 414 are configured to wirelessly communicate with each other over a wireless communication link 416 via local programming electronics.

[0094] IMD 412 is implanted in patient 408 at a location near heart 409. IMD 412 can be a pacemaker, an implantable cardiac monitor (ICM), a defibrillator, an ICM coupled to a pacemaker, or the like. IMD 412 is intended to be implanted in a subcutaneous pocket of patient 408. IMD 412 can be configured to sense cardiac signals to monitor cardiac activity over time. Optionally, IMD 412 can also be configured to deliver stimulation therapy to heart 409. For example, IMD 412 can be a dual-chamber stimulation device that can treat both fast and slow arrhythmias with stimulation therapy (including cardioversion, defibrillation, and pacing stimulation), as well as detect heart failure, assess its severity, track its progression, and control the delivery of therapy and warnings in response thereto.

[0095] The IMD 412 in the illustrated embodiment includes a body or housing 418 connected to at least one lead 419 . Figure 4 409 , the IMD 412 may include multiple leads. Lead 419 extends from housing 418 to heart 409 so that the distal end contacts the patient's tissue surrounding heart 409. Lead 419 includes one or more electrodes that can measure cardiac signals from heart 409 and deliver stimulation therapy to heart 409. In an embodiment, a single electrode can transmit a stimulation pulse in a stimulation mode and then can be quickly switched to a monitoring mode to detect cardiac signals following the stimulation pulse. For devices not used to manage cardiac rhythm, the role of the heart can be replaced or represented by appropriate anatomical structures, including the brain, spine, venous system, lungs, etc.

[0096] Although the IMD 412 in the illustrated embodiment includes leads 419, one or more embodiments described herein utilize a leadless IMD that does not include any leads. For example, the IMD 412 can be a leadless pacemaker, a leadless cardiac monitoring device (ICM), etc. In general, the IMD 412 can represent a cardiac monitoring device, a pacemaker, a cardioverter, a cardiac rhythm management device, a defibrillator, a neurostimulator, a leadless monitoring device, a leadless pacemaker, etc. For example, IMD 412 can include one or more structural and / or functional aspects of devices described in the following patents: U.S. Patent 9,333,351, “Neurostimulation Method And System To Treat Apnea”; U.S. Patent 9,044,610, “System And Methods For Providing A Distributed Virtual Stimulation Cathode For Use With An Implantable Neurostimulation System”; U.S. Patent No. 10,765,860, filed on May 7, 2018, entitled “SUBCUTANEOUS IMPLANTATION MEDICAL DEVICE WITH MULTIPLE PARASTERNEL-ANTER ELECTRODES”; U.S. Patent No. 10,722,704, filed on May 7, 2018, entitled “Implantable Medical Systems And Methods Including Pulse Generators And Leads”; and U.S. Patent No. 10,722,704, filed on May 7, 2018, entitled “Single Site Implantation Methods For Medical Devices Having Multiple No. 11,045,643, “Leads,” the entire contents of which are incorporated herein by reference. Additionally or alternatively, the IMD may be a leadless implantable medical device (LIMD) that includes one or more structural and / or functional aspects of the devices described in U.S. Patent 9,216,285, “Leadless Implantable Medical Device Having Removable And Fixed Components,” and U.S. Patent 8,831,747, “Leadless Neurostimulation Device And Method Including The Same,” which are incorporated herein by reference.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, “Method And System For Identifying A Potential Lead Failure In An Implantable Medical Device,” and U.S. Patent 9,232,485, “System And Method For Selectively Communicating With An Implantable Medical Device,” which are incorporated herein by reference. Additionally or alternatively, embodiments may be implemented using all or part of the methods and systems described in U.S. Patent Application Publication No. 2021 / 0020294, filed on July 16, 2020, entitled “Methods, Devices And Systems For Holistic Integrated Healthcare Patient Management.”

[0097] In another example, IMD 412 can be an ICM that includes one or more structural and / or functional aspects of the device described in U.S. Patent Publication No. 20210020294A1, entitled “Method And System To Discriminate Rhythm Patterns In Cardiac Activity,” filed on March 29, 2016, which is expressly incorporated herein by reference. All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0098] Housing 418 may contain a battery, pulse generation circuitry, communication circuitry, data storage (e.g., memory), and / or control circuitry including one or more processors. The control circuitry may be configured to receive and analyze biometric data, such as electrocardiogram (ECG) signals from electrodes, heart rate, infusion pump values, and the like. The control circuitry may include at least one processor, which, in this exemplary embodiment, may process the IEGM signals according to an algorithm to determine the state of heart 409. The memory used in this embodiment provides storage for cardiac signals and programming instructions for the control circuitry, which provides communication sessions, including device sessions during which dynamic conversations occur. The battery provides power to the circuitry comprising housing 418. For example, the battery powers the pulse generation circuitry to generate stimulation pulses and the communication circuitry to communicate with external device 414. The control circuitry may generate messages to be transmitted to external device 414 via the communication circuitry. The messages may include IEGM signals and / or data generated based on the IEGM signals. The control circuitry is also configured to analyze messages received from external device 414 via the communication circuitry, including programming packets for updating the operational configuration (including settings, parameters, behavior, etc.) of IMD 412. The following combination Figure 5 An exemplary structure of IMD 412 is discussed and illustrated. Although illustrated as IMD 412 being a cardiac monitor, in other embodiments, other medical devices providing other biometric data may be utilized.

[0099] External device 414 may represent a computing device accessible to or possessed by a patient or clinician, such as a tablet computer, smartphone, wearable device, laptop computer, desktop computer, bedside monitor installed in a patient's home, and the like. Alternatively, external device 414 may be a local programming electronic device used by a clinician, nurse, technician, and the like. External device 414 may be one of the devices listed above, communicatively connected to the local programming electronic device, representing the source of programming packages intended to program the operational configuration of IMD 412. For example, the local programming electronic device may be a remote server or another computing device communicatively connected to the remote electronic device via a network connection (e.g., the Internet). Typically, external device 414 facilitates physician access to patient data and allows the physician to view real-time electrocardiogram (ECG) signals and, as described in greater detail herein, program the operational configuration of IMD 412 without the clinician being physically present in the vicinity of patient 408.

[0100] Figure 5A block diagram of an IMD 412 is shown. A housing 418 or casing of the IMD 412 holds the electronic and / or computing components. The housing 418 also includes a connector (not shown) having at least one terminal 452 and optional additional terminals 454, 456, 458, 460. The terminals 452, 454, 456, 458 can be connected to electrodes located in various locations in and around the heart, such as on leads 419 ( Figure 4 ). Electrodes can include various combinations of ring electrodes, tip electrodes, coil electrodes, shock electrodes, etc.

[0101] IMD 412 includes a programmable microcontroller 420 that controls various operations of IMD 412, including cardiac monitoring and stimulation therapy. Microcontroller 420 includes one or more processors (e.g., a microprocessor or equivalent control circuitry), RAM and / or ROM memory, logic and timing circuitry, state machine circuitry, and I / O circuitry. Microcontroller 420 may include an arrhythmia detector 434 configured to detect cardiac activity data to identify potential episodes of atrial fibrillation (AF) and other cardiac arrhythmias (e.g., tachycardia, bradycardia, asystole, etc.).

[0102] An electrode configuration switch 426 is optionally provided to allow selection of different electrode configurations under the control of the microcontroller 420. The electrode configuration switch 426 may include multiple switches for connecting the desired electrodes to the appropriate I / O circuitry, thereby facilitating electrode programmability. The switch 426 is controlled by a control signal 428 from the microcontroller 420. Alternatively, the switch 426 may be omitted and the I / O circuitry connected directly to the housing electrodes.

[0103] IMD 412 may include a chamber pulse generator 422 that generates stimulation pulses for connecting desired electrodes to appropriate I / O circuitry, thereby facilitating electrode programmability. Pulse generator 422 is controlled by microcontroller 420 via control signals 424. IMD 412 includes sensing circuitry 444 that selectively couples to one or more electrodes via switches 426 to perform sensing operations to detect cardiac activity. Sensing circuitry 444 may include dedicated sense amplifiers, multiplexed amplifiers, or shared amplifiers. Sensing circuitry 444 may operate in a unipolar sensing configuration or a bipolar sensing configuration. The output of sensing circuitry 444 is connected to microcontroller 420, which in turn activates or deactivates pulse generator 422 in response to the absence or presence of cardiac activity. Sensing circuitry 444 receives control signals 446 from microcontroller 420 for controlling the gain, threshold, polarization, and timing of any blocking circuitry (not shown) coupled to the sensing circuitry.

[0104] IMD 412 further includes an analog-to-digital A / D data acquisition system (DAS) 484 coupled to one or more electrodes via switch 426 to sample cardiac signals across any desired electrode pair. A / D DAS 484 is controlled by a control signal 486 from microcontroller 420 .

[0105] IMD 412 is also equipped with a communication modem (modulator / demodulator) or circuitry 440 to enable wireless communication. Modem 440 enables timely and accurate data transfer directly from the patient to external device 414, and vice versa. For example, communication modem 440 is configured to establish a communication link 416 with external device 414. In an embodiment, communication modem 440 receives programming packages from external device 414 and passes the programming packages, used to update, modify, change, etc., IMD 412 during a dynamic session, to microcontroller 420 for verification before executing configuration change requests and / or command execution requests contained in the programming packages. In addition to remote programming of IMD 412, wireless communication link 416 with external device 414 facilitates physician and / or patient access to patient data generated by IMD 412.

[0106] Communication modem 440 can utilize radio frequency (RF), inductive, conductive, Bluetooth, or Bluetooth Low Energy (BLE) telemetry protocols. Signals are sent in the high-frequency range and will travel through body tissues and fluids without stimulating the heart or being felt by the patient. Communication modem 440 can be implemented in hardware as part of microcontroller 420, or as software / firmware instructions programmed into and executed by microcontroller 420. Alternatively, modem 440 can exist as a separate hardware component from microcontroller 420.

[0107] The microcontroller 420 is coupled to a non-transitory data storage device, referred to herein as a memory device 488, via a suitable data / address bus 462. The memory device 488 stores programmable operating parameters used by the microcontroller 420 and / or data associated with the detection and determination of cardiac arrhythmias. In embodiments, the memory device 488 also stores the current device session and / or dynamic session, as well as any and all changes, modifications, updates, etc. previously made during the device session and / or dynamic session.

[0108] IMD 412 optionally includes one or more physiological sensors 470 that adjust the pacing stimulation rate, detect changes in cardiac output, changes in the physiological condition of the heart, and / or diurnal variations in activity (e.g., detecting sleep and wake states). Examples of physiological sensors 470 may include, for example, sensors that sense respiratory rate, blood pH, ventricular gradient, activity, body movement, position / posture, minute ventilation (MV), etc.

[0109] Battery 472 provides operating power to all components in IMD 412. Battery 472 is capable of operating at low current draw for extended periods of time and is capable of providing high current pulses (for charging capacitors) when a shock pulse is required by the patient (e.g., in excess of 2 A at voltages greater than 2 V for periods of 10 seconds or longer).

[0110] IMD 412 optionally includes impedance measurement circuitry 474, which can be used for a number of things, including sensing respiratory phase. IMD 412 can further be equipped with telemetry circuitry 464, which can selectively communicate with an external device (such as device 414) when connected via a physical (e.g., wired) communication link. IMD 412 optionally includes a shock circuit 480 controlled by a control signal 482 generated by microcontroller 420. Shock circuit 480 generates low-energy (e.g., up to 0.5 joules), medium-energy (e.g., 0.5 joules to 10 joules), or high-energy (e.g., 11 joules to 40 joules) shock pulses controlled by microcontroller 420. In an alternative embodiment in which IMD 412 senses and monitors cardiac activity without administering stimulation therapy, IMD 412 can lack pulse generator 422 and shock circuit 480.

[0111] The microcontroller 420 may include other dedicated circuits and / or firmware / software components, such as a timing control (module) 432 and a morphology detector (module) 436. The timing control 432 is used to control various timing parameters, such as the timing of stimulation pulses (e.g., pacing rate, atrial-ventricular (AV) delay, interatrial conduction (AA) delay, interventricular conduction (VV) delay, etc.), as well as tracking the timing of RR intervals, refractory periods, blanking intervals, noise detection windows, evoked response windows, alarm intervals, marker channel timing, etc. The morphology detector 436 is configured to view and analyze one or more features of the morphology of the cardiac activity signal (such as the morphology of a detected R wave) to determine whether to include or exclude one or more beats from further analysis.

[0112] Figure 6 A method 600 for providing user input to a medical device from a remote location is shown. In an example embodiment, Figures 1 to 5The systems and devices shown in are used to perform at least some, if not all, of the steps or functions of method 600. For this purpose, when reference is made to one or more processors, the one or more processors may be one or more processors of a remote electronic device remote from the patient, one or more processors of a locally programmed electronic device local to the patient, or one or more processors of a medical device including an IMD within the patient. For this purpose, the one or more processors may monitor, determine, and perform any of the actions by transmitting signals that cause other processors of other devices to perform the functions described.

[0113] Method 600 presents a method for providing a dynamic session for updating, changing, modifying, altering, interrogating, etc. a medical device. In one example, a dynamic session can be considered a programming session, wherein dynamic events (e.g., updates, changes, modifications, alterations, interrogations, etc.) on the medical device involve software, including updates, changes, modifications, alterations, etc. Furthermore, during such a programming session, the dynamic events can be programming parameters such as intervals, thresholds, etc. In another example, the dynamic session can be a time period during which the medical device is interrogated. In one example, the dynamic session can occur during a communication session between a remote electronic device and a local programming device, which is implemented to program the medical device at the location of the local programming device. In one example, the remote electronic device can be operated by a clinician, a clinician's assistant, a programming specialist, etc. In one embodiment, the local programming electronic device can be utilized by a local clinician (such as a nurse, equipment technician, physician, or other individual sufficiently trained to use and support such a system in the same room or environment as the patient), and the local programming electronic device can monitor the patient on-site during remote programming of the medical device. In an alternative embodiment, the remote programming device, in addition to communicating with the local electronic device, can also communicate directly with the medical device during a communication session and a dynamic session without using the local programming electronic device. In yet another alternative embodiment, a local electronic device is provided; however, the local electronic device does not monitor the medical device or make determinations related to the communication session, device session, or dynamic session. In addition, the local electronic device is provided in the communication path between the remote electronic device and the medical device.

[0114] At 602, one or more processors of the remote programming electronic device and / or the local programming electronic device initiate a communication session between the remote programming electronic device and the local programming electronic device. In one example, the local programming electronic device may initiate the communication session, while in another example, the remote electronic device may initiate the communication session. In one embodiment, the local programming electronic device initiates the communication session, and then the local user transfers control of the local programming electronic device to the user of the remote electronic device. In an example embodiment, during this process, security measures (such as passwords, key exchanges, randomly generated number exchanges, etc.) may be implemented to ensure the security of the communication session and dynamic transactions occurring during the communication session. In an example embodiment, a third-party electronic device may provide keys, random numbers, etc. to initiate the communication session. As a result of the communication session, the remote user of the remote electronic device is able to control the local programming electronic device. In this manner, input provided at the remote electronic device can be transmitted to and executed by the local programming electronic device.

[0115] At 604, one or more processors of the locally programmed electronic device initiate a device session with the local medical device. In one example, the medical device is an IMD. During the initiation of the device session between the locally programmed electronic device and the medical device, the remote electronic device maintains communication with the locally programmed electronic device and controls the locally programmed electronic device, thereby controlling the device session with the medical device. Again, security measures (including key exchange, passwords, etc.) may be employed during the initiation of the device session. In an alternative embodiment, one or more processors of the remote electronic device directly initiate a device session with the medical device. In particular, in an example embodiment, the locally programmed electronic device may be eliminated, so that only the transceiver within the medical device communicates with the remote electronic device. In yet another example, the locally programmed electronic device may simply be a local electronic device that serves solely as a communication conduit between the remote electronic device and the medical device. In this manner, the communication session may include both the remote electronic device and the local electronic device, or both the remote electronic device, the local electronic device, and the medical device.

[0116] At 606, one or more processors of the remote electronic device, the local programming electronic device, and / or the medical device determine whether to terminate the device session. During the device session and before the dynamic session begins, any device in the communication session (e.g., the remote electronic device, the local programming device, and the medical device) can cause the device session to be terminated. In one example, manual input at the remote electronic device or the local programming electronic device can cause termination. Thus, the device session can be terminated if the remote user is dissatisfied with the programming update that is about to occur, if the local user determines that the patient is not in a condition to receive the programming update, etc. Similarly, the device session can be automatically terminated if a connectivity issue occurs on the network, the electronic device runs out of battery, the communication session is accidentally terminated by the user, etc.

[0117] If the device session is not terminated at 606, then at 608, a determination may be made as to whether a dynamic session is ready to be initiated during the device session. For example, a user of the remote electronic device may determine whether all programming updates / changes are present or whether additional programming updates / changes need to be downloaded or obtained. In another example, thresholds associated with the dynamic session may be set, modified, changed, updated, etc. For example, a persistent state threshold may be set, modified, changed, updated, etc. Figure 7 and Figure 8 An example input screen 700 is shown relating to programming, changes, variations, and modifications of a medical device that may be observed during a device session prior to initiating a dynamic session. As shown, the input screen may include patient health information 702, such as heart-related signals, cardiac information such as beats per minute, and the like. The input screen 700 may also include input buttons 704 to allow a user to navigate programming, and the input buttons 704 may function on communication sessions, device sessions, dynamic sessions, and information related to the patient and each session. Additionally, the input screen may include a persistent state threshold input 706. The persistent state threshold input 706 indicates a specified period of time that a persistent state is allowed to continue during a dynamic session before the local programming electronic device terminates the dynamic session with the medical device, thereby restoring the medical device and / or the local programming electronic device to its pre-programmed state.

[0118] The persistent state threshold input 706 may start as a default amount, such as 2 seconds ( Figure 7 ), which may then be changed or varied to a second determined amount, such as 5 seconds, for a particular dynamic session ( Figure 8 In one example, the persistent state threshold input 706 can be manually changed by a clinician at a remote electronic device via an input button or key. The change can be based on the clinician's preference, a determination based on ongoing programming, etc.

[0119] Alternatively, one or more processors can automatically change the persistent state threshold based on patient characteristics, clinician characteristics, medical device characteristics, monitoring characteristics, etc. For example, clinician characteristics can be used. The clinician using the remote electronic device can be identified by the one or more processors based on a login name, sensor information (e.g., camera information), etc. (e.g., clinician characteristics), and the change is based on the preferences of the identified clinician. To this end, the clinician can have a profile so that whenever a specific clinician is a user of the remote electronic device, the persistent state threshold input is automatically set to the clinician's desired value.

[0120] In another example, patient characteristics can be used to determine a persistent state threshold. Patient characteristics can include age, health status, health status, weight, previous health events, etc. (e.g., risk). These patient characteristics can be used in conjunction with algorithms, models, mathematical functions, artificial intelligence, lookup tables, decision trees, etc. to determine a persistent state threshold based on the patient's risk.

[0121] In yet another example, the one or more processors may determine the persistent state threshold based on medical device characteristics. The medical device characteristics may be determined based on the type, age, brand, status, battery capacity, programming update itself, etc. of the medical device.

[0122] In another example, monitoring features may be used to determine a persistent state threshold. Monitoring features include any features that can be obtained using sensors of a locally programmed electronic device or medical device. Example monitoring features include connectivity status, communication signal strength, measurements related to the current electrical environment, electrical noise levels, etc. In addition, such monitoring features may include sensor information related to the patient, including patient characteristics. To this end, some features may be considered to be more than one type of feature. Additional sensor information may include features related to the local user, such as camera or image features. In particular, such image data is considered to be a monitoring feature if the local user leaves the environment where the communication session is occurring, the patient's health changes, etc.

[0123] Regardless of the type of features obtained, based on the features, the persistent states that may occur during a dynamic session and the predicted amount of time each persistent state should be maintained can be determined. In other examples, a combination of these features and the provided method can be utilized to determine a persistent state threshold.

[0124] Return Reference Figure 6In method 600, if the dynamic session is not ready to initiate at 608, the device session continues, allowing for additional changes and modifications before the dynamic session is initiated. In particular, it is desirable to have all programs, changes, thresholds, settings, etc. in place and configured before starting the dynamic session. In this way, once the dynamic session begins, the minimum amount of time spent during the dynamic session can be minimized. This results in reduced risk and enhanced patient safety.

[0125] If the dynamic session is ready to begin at 608, then at 610, one or more processors of the local programming electronic device initiate the dynamic session. During the dynamic session, the remote electronic device user can provide input via the local programming electronic device to modify, update, change, etc., one or more programs of the medical device, run tests on the medical device, etc. Such modifications, updates, changes, etc. can change the settings or programming configuration of the medical device, or alternatively can include adding new programs and / or deleting old programs. These modifications, updates, changes, etc. can be caused by extended, persistent actions by the remote user, including pressing an input key or input device for a determined period of time, or until the set of tests, modifications, and / or updates that initiated the action has been completed.

[0126] At 612, one or more processors of the local programming electronic device determine whether to terminate the dynamic session. In one example, if the persistence action exceeds a persistence state threshold, the dynamic session can be automatically terminated. In this way, if a connectivity issue, system error, or other issues occur that could negatively impact the dynamic session and, therefore, the patient, the dynamic session can be automatically terminated, and at 614, the one or more processors of the local programming electronic device can restore the medical device to its previous programming. If the local user detects a change in the patient's condition, or if the remote user observes any other unexpected software, system, or patient response (e.g., a stuck input key), the local user can manually terminate the dynamic session, whereupon at 614, the one or more processors of the local programming electronic device restore the medical device to its previous programming. This reduces risk to the patient and enhances patient safety. Furthermore, termination of the dynamic session does not automatically terminate the communication session between the remote electronic device and the local programming electronic device, or the device session between the local programming electronic device and the medical device. Therefore, if the issue that caused the dynamic session termination can be resolved (e.g., connectivity restored, the remote user releases an input key, etc.), another attempt at the dynamic session can be immediately made. Thus, patient safety is ensured, with minimal disruption to medical device updates, modifications, and changes.

[0127] In addition, at 612, during the dynamic session, dynamic changes associated with the dynamic session may be monitored to determine whether the dynamic session should be terminated for different reasons other than a persistent action. For example, the patient's health characteristics may be continuously and repeatedly monitored to ensure that the function of the medical device is not required during the dynamic session. Health characteristics may include changes in heart beats per minute, changes in heart signals, changes in patient consciousness, changes in temperature, etc., which may indicate that the patient may need immediate use of the medical device. Other dynamic changes may include those input by a user of a locally programmed electronic device. The user (e.g., a nurse, technician, etc.) observes the patient during the dynamic session and may provide input that the dynamic session should be terminated. In yet another example, the Internet connection may be monitored to determine whether or when the communication connection has been lost.

[0128] Furthermore, after initiating the remote programming update at 610 or 612, the remote or local user or system may terminate the communication session at any time. Doing so causes the local programming electronics to detect a loss of communication upon reaching a persistent state threshold that results in termination. At 614, in response to the termination, the local programming electronics restores the programming or state of the medical device to its original state prior to the initiation of the dynamic session. The process then returns to step 604, where the device session remains active, but the communication system is inactive, thereby preventing further remote programming actions and concluding the method 600.

[0129] Dynamic monitoring can be used independently or extend the utility of static thresholds. Dynamic monitoring will end a persistent action only when a change in system state is detected (such as due to loss of communication between the remote electronic device and the local programming electronic device, a change in the state of the local programming electronic device or a connected system such as an implanted device, user input from a local user at the local programming electronic device, a change in the state or condition of the patient or the patient's implanted device detected through any channel such as an external heart monitor or alarm, etc.). If the change in state cannot be detected directly and instantaneously, it is desirable to use a fixed static persistent state threshold in addition to periodically monitoring dynamic inputs. For example, the start of the static time evaluation is periodically restored each time the dynamic state is successfully reassessed. Therefore, the persistent action will automatically terminate only after the predefined static persistent state threshold is reached since the last dynamic state event reassessment.

[0130] While some dynamic state events can be monitored completely independently within the local programming electronic device, other state events may involve the periodic transmission of information between devices. For example, a remote electronic device (or other externally monitored input source) may periodically (such as once every 100 ms, once per second, once per minute, etc.) send a status update to the local programming electronic device to confirm that communication between the two devices exists, that the communication delay is sufficient to perform such an action, or that some other criteria essential to the safety or performance of the system are met. If the aforementioned static persistent state threshold is reached after the local programming electronic device receives the most recent periodic status update, this will be interpreted as a loss of communication, requiring the automatic termination of the persistent action, as no input from the remote electronic device can be expected to be sent to the local programming electronic device when the communication channel is unavailable. Therefore, at 612, all of the previously described information sources will be used to evaluate the combination of all available dynamic input and manual user input collected during the persistent action that are within the currently defined static persistent state threshold, which then transitions to 614 and terminates the programming state due to an exception from any of the aforementioned monitored criteria.

[0131] In a first example of method 600, dynamic status monitoring interrupt control with a static persistent status threshold is provided. Periodic status messages are sent from the remote electronic device (i.e., every 0.5 to 1 second) to the locally programmed electronic device. Optionally, this can be limited to the time period during which persistent (remote) user input is active, or can be continuous while the remote electronic device is connected to the locally programmed electronic device. Each time such a status message is received, a static timer or counter on the locally programmed electronic device is restarted. If no status message is received before the static timer expires, the locally programmed electronic device signals any software processes subscribed to such status update events that communication with the remote electronic device has been lost.

[0132] In the event that a remote user at a remote electronic device initiates a persistent action that temporarily changes the state of the system (i.e., the patient's device), and communication with the remote electronic device is lost while the persistent action is still in progress, a static timer expires after a defined persistent state threshold has been reached since the last status message was received. This automatically terminates the persistent user action (button release or other), triggering the local programming electronic device to restore the IMD's operation from its temporary state. Similarly, the system can allow two or more attempts to assess the condition before terminating the persistent user action. This is to allow for situations where the monitoring interval (i.e., the rate at which these features are updated) is short enough to support the collection of two or more samples within the static or dynamic threshold established for the action being performed. In one example, three samples are collected.

[0133] In a second example, a remotely configurable static persistent state threshold may be provided. The persistent state threshold may be manually set using a remote input (e.g., an input button) of a remote electronic device. The shape and size of the remote input, as well as the text font, may be adapted to match the appropriate user interface style recommendation, as long as it allows the currently selected static threshold to be displayed. The value may be in any suitable range and unit deemed appropriate for the applications supported by the system. Figure 7 and Figure 8 In the example, the value (for example, 706) is Figure 7 is reflected as 2 seconds in Figure 8 is reflected as 5 seconds.

[0134] Upon initialization or when a new test or action is selected, the system defaults the value (e.g., 706) to the lowest, safest value in its supported range. In this example, 2 seconds would be the default value. In one example, when the user presses the remote user input button, the safety threshold cycles through a predefined set of values. In this example, the next available value is 5 seconds, so upon the first press of the remote input button, a value of 5 is displayed to the user. Additional presses of the button cycle through each available value until returning to the initial value of the series, in this case, 2 seconds. For example, a series of presses could cycle from 2 seconds to 5 seconds, to 10 seconds, to 15 seconds, to 30 seconds, to 60 seconds, and then back to 2 seconds to repeat from the beginning. Any sequence can be defined. Alternatively, the user can use the remote electronic device's keyboard to enter an exact number, such as 42, to set the persistent state threshold. Alternatively, the software can define a minimum, maximum, or recommended value that can be selected by the remote user for any given test or feature group, as previously defined.

[0135] In this example, the system may additionally restore the default value back to the initial value of 2 seconds due to any combination of other defined actions, which may include but are not limited to the following possible examples: a) upon completion of the next press and hold action (the user-selectable value is only used once and the operator may need to update the selection for each press and hold action); b) no user interaction for an extended period of time; c) the remote user suspending / resumes the remote session; d) a detected change in connectivity state or method; e) etc.

[0136] The one or more processors of the local programming electronic device may be responsible for displaying the currently selected security threshold software to the remote user via the remote user action button. This ensures that the remote user is aware of the persistent state threshold before initiating a persistent action.

[0137] When the local programming electronic device is notified of a remote user action to initiate a new persistent action, a timer is started in the local programming electronic device using the selected persistent state threshold. If the local programming electronic device does not receive an action to end the persistent event (such as releasing a mouse button or touching the screen) within the defined time limit, the local programming electronic device automatically terminates the action (and any resulting restoration of system state) in real time as needed upon the termination of such an action. Typically, the ongoing action is terminated by releasing the button, any temporary modifications to the temporary operation of the implanted device are restored, and control of the local programming electronic device is restored to the local user and / or remote user.

[0138] In a third example, a local user can terminate a persistent action. In this example, a remote user initiates a persistent action via a remote electronic device. At any time after the persistent action is initiated, any input made by the local user to the locally programmed electronic device terminates the persistent action and returns control to the local user.

[0139] In a fourth example, interrupt control for dynamic status monitoring of local or remote inputs can be provided. In this example, a patient is connected to an external monitor or measurement device supported by locally programmed electronics. This external monitor or measurement device can monitor any number of physiological characteristics against predefined thresholds, including but not limited to heart rate, blood pressure, cardiac output, blood oxygen content, respiratory rate, and the like. The locally programmed electronics periodically evaluates the status of these characteristics. Optionally, this evaluation can be limited to periods of sustained user input activity. Each time the status is evaluated and is within a desired range, a static timer on the locally programmed electronics is restarted. If the status indicates a fault, such as exceeding a programmed threshold, or if a status measurement cannot be obtained before the static timer expires, the locally programmed electronics generates a signal to any software processes subscribed to such status update events. This automatically terminates the persistent user action (button release or other) in real time, triggering the locally programmed electronics to restore system operation from its temporary state. Optionally, this change in the status of one or more monitored characteristics can be used to prevent certain subsequent actions until the system or patient's condition returns to an acceptable level.

[0140] In a fifth example, a remote electronic device is directly connected to a medical device located locally on the patient. In one example, the medical device is a monitor external to the patient; alternatively, the medical device is an IMD. After satisfying security protocols, a communication session is initiated between the remote electronic device and the medical device. In this case, because no local programming electronics are provided, both the communication session and the device session are initiated simultaneously. During the communication / device session, a static persistent state threshold can be set for a test to be performed on the medical device, involving pressing a mouse button at the remote electronic device for five seconds. In such an example, the static persistent state threshold can be set to fifteen seconds. If the medical device detects that the mouse button at the remote electronic device has been pressed for longer than fifteen seconds, the dynamic session automatically terminates and the medical device returns to its previous programming from before the dynamic session was initiated. If any dynamic changes occur during the dynamic session, the one or more processors can terminate the dynamic session, causing the medical device to return to its pre-dynamic session state at 614. This allows new attempts to update, modify, or change the medical device. To this end, once the update / modification / change is complete, the dynamic session ends. At this point, both the device session and the communication session end, as the update / modification / change has been successfully implemented.

[0141] In a sixth example, a remote electronic device is coupled to a medical device via a local electronic device that does not make determinations related to the medical device or the dynamic session and / or monitor persistent actions during the dynamic session. In such an embodiment, a remote user of the remote electronic device can set a persistent state threshold, and the medical device can monitor dynamic changes in the medical device, patient, dynamic session, etc. Based on this monitoring, one or more processors of the medical device can change the dynamic threshold or take any action as previously described with respect to the locally programmed electronic device.

[0142] In an example, a communication system 300 is provided. In this example, the communication system 300 includes a local programming electronic device 306 and a remote electronic device 304. The remote electronic device 304 is configured to communicate with a patient's medical device 302 via the local programming electronic device 306. The remote electronic device 304 includes one or more processors 316 configured to control the operation of the local programming electronic device 306 to program the medical device 302 during a dynamic session and terminate the dynamic session in response to 1) a persistent action by a user of the remote electronic device 304 exceeding a static persistence state threshold and / or 2) a monitored event exceeding a dynamic threshold.

[0143] In another example, a communication system 300 is provided. In this example, the communication system 300 includes a local programming electronic device 306 and a remote electronic device 304. The remote electronic device 304 includes one or more processors 316 configured to communicate with the local programming electronic device 306 and control the local programming electronic device 306 to program a patient's medical device 302. The local programming electronic device 306 includes one or more processors 322 configured to program the medical device 302 during a dynamic session and monitor the remote electronic device 304 for persistent actions during the dynamic session. The one or more processors 322 of the local programming electronic device 302 are further configured to monitor at least one of a patient characteristic, a medical device characteristic, or a monitoring characteristic during the dynamic session, and determine a dynamic threshold based on the patient characteristic, the medical device characteristic, and / or the monitoring characteristic. The one or more processors 322 of the local programming electronic device 302 are further configured to determine whether a dynamic threshold is exceeded during the dynamic session, and to determine whether a persistent action in the persistent action exceeds a static persistent state threshold during the dynamic session. The one or more processors 322 of the locally programmed electronic device 302 are additionally configured to terminate the dynamic session when 1) a dynamic threshold is exceeded, or 2) a persistence action exceeds a static persistence state threshold.

[0144] Ending

[0145] It should be clearly understood that the various arrangements and processes broadly described and illustrated with respect to 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, can be used independently of or in conjunction with one or more other components, elements, and / or process operations described and illustrated herein. Thus, while various arrangements and processes are broadly contemplated, described, and illustrated herein, it should be understood that they are provided in an illustrative and non-limiting manner only and may also be viewed as possible operating environments (merely examples) in which one or more arrangements or processes may function or operate.

[0146] As will be appreciated by those skilled in the art, various aspects may be embodied as systems, methods, or computer (device) program products. Thus, various aspects may take the form of entirely hardware embodiments or embodiments comprising hardware and software, which may generally be referred to herein as "circuits," "modules," or "systems." Furthermore, various aspects may 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.

[0147] Any combination of one or more non-signal computer (device) readable media may be used. The non-signal medium may be a storage medium. The storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of storage media include the following: a portable computer diskette, a hard disk, random access memory (RAM), dynamic random access memory (DRAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0148] The program code for performing the operation can be written in any combination of one or more programming languages. The program code can be executed entirely on a single device, partially on a single device, as a separate software package, partially on a single device and partially on another device, or entirely on another device. In some cases, the device can be connected via any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected via other devices (e.g., via the Internet using an Internet service provider) or via a hard-wired connection (such as via a USB connection). For example, a server having a first processor, a network interface, and a storage device for storing code can store program code for performing the operation and provide the code to a second device having a second processor via a network through its network interface for running the code on the second device.

[0149] Various aspects are described herein with reference to the accompanying drawings, which illustrate example methods, devices, and program products according to various example embodiments. Program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device or information processing device to produce a machine, such that the instructions executed by the processor of the device implement a specified function / action. Program instructions may also be stored in a device-readable medium that can direct the device to function in a particular manner such that the instructions stored in the device-readable medium produce an article of manufacture including instructions for implementing the specified function / action. Program instructions may also be loaded onto a device so that a series of operational steps are performed on the device to produce a process implemented by the device, such that the instructions executed on the device provide a process for implementing the specified function / action.

[0150] The units / modules / applications herein may include any processor-based or microprocessor-based system, including systems utilizing microcontrollers, reduced instruction set computers (RISCs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), logic circuits, and any other circuit or processor capable of performing the functionality described herein. Additionally or alternatively, a module / controller herein may represent a circuit module that may be implemented as hardware with associated instructions (e.g., software stored on a tangible and non-transitory computer-readable storage medium such as a computer hard drive, ROM, RAM, etc.) that performs the operations described herein. The above examples are merely illustrative and are not intended to limit the definition and / or meaning of the term "controller" in any way. The units / modules / applications herein may execute instruction sets stored in one or more storage elements to process data. The storage elements may also store data or other information as desired or needed. The storage elements may be in the form of information sources or physical memory elements within the modules / controllers herein. The instruction sets may include various commands that instruct the modules / applications herein to perform specific operations, such as the methods and processes of the various embodiments of the subject matter described herein. The instruction sets may be in the form of software programs. The software may take various forms, such as system software or application software. Furthermore, software may be in the form of a collection of separate programs or modules, a program module within a larger program, or a portion of a program module. Software may also include modular programming in the form of object-oriented programming. The processing of input data by a processing machine may be in response to user commands, or in response to the results of previous processing, or in response to a request made by another processing machine.

[0151] It should be understood that the subject matter described herein is not limited in its application to the construction details and component arrangements set forth in the description herein or shown in the accompanying drawings. The subject matter described herein is capable of other embodiments and can be practiced or carried out in various ways. In addition, it should be understood that the words and terms used herein are for descriptive purposes and should not be considered restrictive. The use of "including," "comprising," or "having" and variations thereof herein is intended to encompass the items listed thereafter and their equivalents as well as additional items.

[0152] It should be understood that the foregoing description is intended to be illustrative and not limiting. For example, the above-described embodiments (and / or aspects thereof) may be used in combination with each other. Furthermore, many modifications may be made to adapt a particular situation or material to the teachings herein without departing from their scope. While the dimensions and types of materials and coatings described herein are intended to define various parameters, they are by no means limiting and are illustrative in nature. Many other embodiments will be apparent to those skilled in the art upon reading the foregoing description. Therefore, reference should be made to the appended claims, along with the full scope of equivalents to which such claims are entitled, to determine the scope of the embodiments. In the appended claims, the terms "including" and "in which" are used as the plain-English equivalents of the respective terms "comprising" and "wherein." Furthermore, in the appended claims, the terms "first," "second," and "third," etc. are used merely as labels and are not intended to impose numerical requirements on their objects or on the order in which their actions may be performed.

Claims

1. A communication system comprising: a remote electronic device configured to communicate with the patient's medical device via the local programming electronic device; The remote electronic device includes one or more processors configured to: controlling the operation of the local programming electronics to program the medical device during a dynamic session; and The dynamic session is terminated in response to 1) a persistent action by a user of the remote electronic device exceeding a static persistent state threshold and 2) a monitored event exceeding a dynamic threshold.

2. The communication system according to claim 1, wherein The one or more processors are further configured to: providing a timer during the dynamic session; and A determination is made as to whether a duration of the persistent action as determined by the timer exceeds the static persistent state threshold.

3. The communication system according to claim 2, wherein: The one or more processors are further configured to: The timer is adjusted based on manual input from the user of the remote electronic device.

4. The communication system according to claim 2, wherein: The one or more processors are further configured to: Obtain patient characteristics, clinician characteristics, medical device characteristics, or monitoring characteristics; and determining the static persistent state threshold based on the obtained patient characteristics, the obtained clinician characteristics, the obtained medical device characteristics, or the obtained monitoring characteristics; and The static persistence state threshold is updated based on the determination.

5. The communication system according to claim 1, wherein The one or more processors are further configured to: Obtain patient characteristics, medical device characteristics, or monitoring characteristics; and The dynamic threshold is determined based on the obtained patient characteristics, the medical device characteristics, or the monitoring characteristics. The communication system according to claim 5 , wherein: The monitoring characteristic is associated with connectivity between the remote electronic device and the local programming electronic device.

7. The communication system according to claim 1, wherein: The dynamic session is a programming session.

8. The communication system according to claim 1, wherein: The static persistent state threshold is less than 5 seconds.

9. The communication system according to claim 1, wherein: The one or more processors are further configured to: In response to termination of the dynamic session, the medical device is restored to a previous configuration via the local programming electronic device.

10. A communication system comprising: A remote electronic device comprising one or more processors configured to: communicating with locally programmed electronic devices; controlling the local programming electronic device to program the patient's medical device; The locally programmed electronic device includes one or more processors configured to: programming the medical device during a dynamic session; monitoring persistent actions of the remote electronic device during the dynamic session; monitoring at least one of a patient characteristic, a medical device characteristic, or a monitoring characteristic during the dynamic session; determining a dynamic threshold based on the patient characteristic, the medical device characteristic, or the monitoring characteristic; determining whether the dynamic threshold is exceeded during the dynamic session; determining whether a persistent action among the persistent actions exceeds a static persistent state threshold during the dynamic session; and The dynamic session is terminated when 1) the dynamic threshold is exceeded, or 2) the persistence action exceeds the static persistence state threshold.

11. The communication system according to claim 10, wherein: The one or more processors of the local programming electronic device are further configured to: providing a timer during the dynamic session; and A determination is made as to whether a duration of the persistent action as determined by the timer exceeds the static persistent state threshold.

12. The communication system according to claim 11, wherein: The one or more processors of the remote electronic device are further configured to: The timer is adjusted based on manual input from a user of the remote electronic device.

13. The communication system according to claim 11, wherein: The one or more processors of the local programming electronic device are further configured to: determining the static persistent state threshold based on the obtained clinician characteristic, the patient characteristic, the medical device characteristic, or the monitoring characteristic; and The static persistence state threshold is updated based on the determination.

14. The communication system according to claim 10, wherein: The monitoring characteristic is associated with connectivity between the remote electronic device and the local programming electronic device.

15. The communication system according to claim 10, wherein: The persistent action includes pressing an enter button.

16. The communication system according to claim 10, wherein: The dynamic session is a programming session.

17. The communication system according to claim 10, wherein: The one or more processors of the local programming electronic device are further configured to: In response to termination of the dynamic session, the medical device is restored to a previous configuration such that the medical device can provide therapy to the patient.

18. A communication method, comprising: utilizing the remote electronic device to control the local programming electronic device to program the patient's medical device during the dynamic session; monitoring persistent actions of the remote electronic device during the dynamic session; determining whether a persistent action among the persistent actions exceeds a static persistent state threshold during the dynamic session; When the persistence action exceeds the static persistence state threshold, terminating the dynamic session; and In response to terminating the dynamic session, the medical device is restored to a previous configuration to treat the patient.

19. The method according to claim 18, further comprising: monitoring at least one of a patient characteristic, a medical device characteristic, or a monitoring characteristic during the dynamic session; determining a dynamic threshold based on the patient characteristic, the medical device characteristic, or the monitoring characteristic; determining whether the dynamic threshold is exceeded during the dynamic session; and When the dynamic threshold is exceeded, the dynamic session is terminated.

20. The method according to claim 18, wherein Determining the static persistent state threshold comprises at least one of: 1) receiving manual input from a remote user of the remote electronic device, or 2) determining the static persistent state threshold based on patient characteristics, clinician characteristics, medical device characteristics, or monitoring characteristics.

Images