Remotely programming a patient medical device

The present invention relates generally to programming medical devices, specifically to systems and methods for remotely programming patient medical devices.

The Food and Drug Administration (FDA) classifies medical devices into three classes based on medical regulations and federal law. Class III medical devices are subject to ongoing regulatory control and can only be queried and programmed under the supervision of a licensed medical caregiver. Class III medical devices include implantable medical devices (IMDs) such as cardiac pacemakers, defibrillators, and cerebral stimulators, and certain external medical devices such as automated external defibrillators (AEDs). (EMD) is included.

To date, class III medical device queries and programming have used radio telemetry, such as inductive or, more recently, radio frequency (RF) telemetry, to read patient data and device settings and apply new programming. It had to be done in a clinic or hospital using an FDA-regulated programmer recorder. However, seeing a doctor at a clinic is time-consuming, costly, and inconvenient, to say the least. Therefore, in order to improve patient management, patient-operable monitors such as repeaters have been developed that allow caregivers to remotely access the patient's medical device outside the clinic or hospital. These monitors can remotely read patient data and device settings that are regularly delivered to the repository for caregiver consideration and storage.

Despite its convenience, patient-operable monitors are currently not allowed to program medical devices for patient safety and regulatory compliance reasons. For example, any remote programming must now include an interface through a well-regulated device, as programming cannot be done by non-FDA regulated devices. Similarly, some device parameters are used to test the operation of the device in the field, which can be life-threatening. As a result, these parameters can only be changed within a clinic equipped with life safety devices and under trained medical personnel. Finally, programming in the clinic can be subject to patient consent, but must be explicitly ensured before remote programming is attempted. Traditional approaches have not adequately addressed these issues.

For example, Patent Document 1 (issued to Webb et al. On June 13, 2006) discloses a system and method for remotely programming IMD. The pending programming requests are placed in the request queue, which is ordered from the newest request. Requests can be encrypted and can be assigned a sequence number that allows the remote monitor to determine that the request is in a later order than any earlier request applied to IMD. However, Webb assumes a fully regulated infrastructure to enable remote programming. In addition, such infrastructure is expensive to deploy and may not be available when a physician is requested to make programming changes.<patcit num="1"><text>U.S. Pat. No. 7,060,031</text></patcit>

<p> Therefore, there is a need for an approach to telemedicine device programming that does not require a regulatory environment as the only means of specifying programming and ensures both patient safety and compliance.</p>

<p> In both IMD and EMD, systems and methods that allow caregivers to remotely program patient medical devices (PMDs) are paired to logically separate regulated or non-regulated components. Includes control zones. Caregivers can specify programming instructions using unregulated components such as dedicated applications running on personal computers and web clients, or regulatory components such as remotely connectable programmers. Programming instructions can be specified in real time or deferred time. To avoid endangering the patient, the caregiver can only choose programming instructions that specify operations that can be safely performed when the patient is not under the care of the caregiver. Programming instructions issued from the non-regulated control zone are transferred to the regulated control zone through the server. Each programming instruction is translated into a command formatted in PMD representation, which is checked for its accuracy. PMD format commands are digitally signed by a trusted server. The PMD format command is converted to a simple web page or displayable representation, which is returned to the caregiver for accuracy. After caregiver approval, PMD format commands are marked for delivery to a remote programming device (RPD). PMD format commands are verified for authenticity and integrity by RPD, IMD, or both devices. If the verification is successful, the PMD format command is applied to the PMD. The PMD is then queried to read the programmed data for confirmation and caregiver review.</p><p> One embodiment provides a system and method for remotely programming a patient medical device (PMD). Remotely specified programming instructions are translated into commands formatted for it to control the functionality of the PMD. The accuracy of PMD format commands is checked. Patient consent to alter PMD functionality is confirmed. Controls the application of PMD format commands to PMD during a remotely started and executed programming session. The application of PMD format commands is confirmed through PMD queries to verify the changed functionality.</p><p> Embodiments of the invention are described for the purpose of exemplifying the best embodiments considered for carrying out the invention, and the following detailed description will readily reveal to those skilled in the art yet other embodiments. right. As will be appreciated, the invention may have other different embodiments, some of which may be modified in various self-evident points without departing from the spirit and scope of the invention. .. Therefore, the drawings and detailed description should be considered as exemplary in nature, not restrictive.</p>

Although IMD and EMD are described herein with the intention of providing treatment and monitoring of the heart and cardiopulmonary system, the embodiments described can generally be queried and programmed remotely. Applies to all forms of patient medical devices.

Essentially, PMD remote programming requires the logical separation of components that must maintain compliance with the FDA and other applicable patient management regulations and guidelines from other components. Remote programming also requires establishing and managing secure, secure and reliable coordination between all these components. FIG. 1 is a block diagram showing a system 10 for remotely programming a patient medical device, for example, according to one embodiment. System 10 includes control zones 31 and 32 that logically separate the system components into two groups. Regulatory and non-regulatory control zones 31, 32, logically, rather than physically, separate those devices and applications that must be controlled for compliance from those that are not controlled. Regulatory control zone 31 includes regulated medical devices and applications, such as Class III medical devices and regulated software applications running on server platforms. Non-regulated control zone 32 contains those unregulated system components. Components that include both regulatory and non-regulatory aspects fall into regulatory control zone 31.

Regulatory control zone 31 contains a set of four broadly classified components. First, the caregiver uses a data entry mechanism within the non-regulated control zone 32 or within the regulated control zone 31, a regulated but remotely connectable data entry mechanism, eg, remotely connectable. Programming instructions for PMD can be specified through programmer 19. Other regulated data entry mechanisms are also possible. In addition, all PMDs are classified in regulatory control zone 31, IMD12 such as pacemakers, implantable cardioverter-defibrillators (ICDs), drug pumps, and neurostimulators; automatic external defibrillators (AEDs), etc. EMD 14; Implantable sensors 13 such as cardiac and respiratory monitors and multi-sensor defibrillators for diagnosis; and external defibrillators 15 such as Holter monitors. Other types of implantable or extracorporeal PMDs for therapeutic, diagnostic, or other medical purposes are also possible. Each patient 11 with PMDs 12-15 suitable for remote programming, such as a repeater or patient communicator, in the form of a regulatory device that allows the caregiver to remotely access the patient's PMD outside the clinic or hospital. Equipped with RPD17. Finally, each RPD17 can issue digitally signed PMD format commands from or remote from the regulatory server 24, which is trusted in terms of data security and can support the execution of regulatory components (including regulatory software application 30). Receives directly from a regulated data entry mechanism such as connectable programmer 19. The regulated server 24 communicates with the RPD 17 over the trusted network 28 and with the components in the non-regulated zone 32 over the dedicated secure connection 33 to the non-regulated server 22. Other regulatory system components are also possible.

Non-regulated control zone 32 includes all other components, including non-regulated data entry mechanisms, servers, and PMDs. For example, the caregiver can specify programming instructions using a remote web client 18, a dedicated application 20 running on a personal computer 34, or a local web client 21. Programming instructions issued by any of these unregulated data entry mechanisms and from remotely connected regulatory data entry mechanisms are forwarded to the regulated server 24 through the unregulated server 22 connected via the open network 27. There must be. Finally, unregulated PMDs such as scale 16 or sphygmomanometer cuffs (not shown) usually do not affect patient safety and can be classified as part of unregulated control zone 32. Other unregulated system components are also possible.

The regulated server 24 and the non-regulated server 22 act as a gateway between the regulated and non-regulated control zones 31 and 32, exchanging messages via a dedicated secure connection 33. The regulated server 24 can run the regulated application 30, but the non-regulated server 22 does not. However, the unregulated server 22 can run a wider range of unregulated applications 29, such as a web server (not shown) for providing web content to web clients 18 and 21. The functionality of regulated and non-regulated servers 22 and 24 can be hosted on physically the same hardware platform, but the implementation of any changes to regulated application 30 must remain in control for compliance. It doesn't become. Regulatory and non-regulated servers 22, 24 also share access to secure storage 26, which can securely store patient data and other information. Other server and storage functionality is also possible.

The networkable components within the regulatory control zone 31 depend on the trusted network 28, and the networkable components within the non-regulatory control zone 32 are trusted through the open network 27 or, in a further embodiment. Communicate via network 28. The trusted network 28 is a private wide area network and can include both traditional wired and wireless secure interconnectivity. The open network 27 is a non-private wide area network such as the Internet, which can also include both conventional wired and wireless secure interconnectivity. In a further embodiment, the trusted network 28 can operate over a public wide area network, but the communication uses a virtual private network, etc. to ensure patient privacy and protect against harm or interference, etc. It must be encrypted or otherwise protected. Both trusted network 28 and open network 27 are based on the Transmission Control Protocol / Internet Protocol (TCP / IP) network communication protocol, but other communication protocols are possible. Other trusted and open network topologies and configurations are also possible.

RPD17 is based on direct means such as wired connectivity, or based on inductively coupled telemetry, optical telemetry, or, for example, "strong" Bluetooth® or IEEE 802.11 wireless fidelity "WiFi" and "WiMax" interface standards. , PMDs 12-16 can be queried and programmed through indirect means such as selective radio frequency or radio telemetry. Other forms of medical device interfaces are also possible. In a further embodiment, PMDs 12-16 also, for example, a US patent application by the same applicant, filed May 3, 2005, entitled "System and Method for Managing Alert Notifications in an Automated Patient Management System", Application No. 1. It is managed remotely through RPD17, as described in 11/121,870 (pending and its disclosure is incorporated herein by reference).

In a further embodiment, subjective impressions of an individual's health that make up qualitative data values can be collected for post-programming considerations. For example, patients 11 can be asked to answer health questions related to their health and can be collected after changes in PMD programming. To provide a subjective impression, patient 11 inputs data into a device with a built-in user interface, such as a personal computer or telephone handset (not shown), or RPD17 if equipped.

In a further embodiment, for example, U.S. Pat. No. 6,336,903 to Bardy issued January 8, 2002, U.S. Pat. No. 6,368,284 to Bardy issued April 9, 2002, issued June 2, 2002, relating to sharing, for example. US Pat. No. 6,398,728 to Bardy, US Pat. No. 6,411,840 to Bardy issued June 25, 2002, and US Pat. No. 6,440,066 to Bardy issued August 27, 2002 (these disclosures are by reference). As described in (incorporated), the collected patient data can be assessed by RPD17 or servers 22, 24 for the occurrence of one or more chronic or acute health conditions.

In a further embodiment, medical information privacy that has recently come into force, such as the Health Insurance Portability and Accountability Act (HIPAA) and the European Privacy Directive, which protects patient privacy. To comply with the law, patient data is protected from unauthorized disclosure to third parties, such as during collection, aggregation, evaluation, transmission, and storage. At a minimum, patient health information that identifies a particular individual with health-related and medical-related information is treated as protected, but other types of confidentiality in addition to or in lieu of that particular patient's health information. Information can also be protected.

Structurally, servers 22 and 24 are server-grade computing platforms configured as single, multiple, or distributed processing systems, and web clients 18 and 21 are web browsers or equivalent applications for individuals. Run on a general purpose computing platform, such as a desktop or notebook computer, or other web-enabled device. A personal computer 34 running servers 22, 24, web clients 18, 21, and dedicated application 20 interconnects, for example, a central processing unit (CPU), memory, network interfaces, persistent storage, and their components. Includes components traditionally found in computing devices, such as various components for.

Data is typically exchanged between components in regulated and non-regulated control zones in four stages. In general, in the first stage, the caregiver uses a data entry mechanism to specify remote programming commands and associated parameters, which are then validated (ie, accepted) by the caregiver in the next stage. Translated into PMD format commands. If accepted, the PMD format command will be provided to the RPD. The PMD format command is then validated and applied. Validation is performed by RPD, PMD, or both devices. At the final stage, after remote programming, the PMD is queried to obtain physiology data. An overview of these steps will be described with reference to FIGS. 2 and details will be described with reference to FIGS. 3-6.

To maintain control of compliance, data is passed between control zones only via messages securely exchanged between regulated and non-regulated servers. FIG. 2 is a data flow diagram showing the overall data exchange 50 between regulated and unregulated control zones, 51 and 52, respectively. Messages 70, 71 are received by servers 53, 61, which process each message to determine the appropriate action to take.

In general, the caregiver uses the data entry mechanism 62, located within the non-regulated control zone 52, or within the regulated control zone 51 if performed on a regulated device (not shown). Can remotely contact and program PMD55. If the data entry mechanism 62 is a web client, the web content 66 is provided so that the data entry mechanism 62 can show information formatted as a web page.

Within the non-regulated control zone 52, the non-regulated server 61 provides the caregiver with PMD settings and patient physiology information as pre-programming data 67. The caregiver can then specify programming instruction 63 and any associated parameters 64, which are transferred to regulatory server 53 for translation into command 56 formatted for PMD representation. The PMD format command 56 is provided again to the caregiver in a form that can be viewed as validation data 68, which the caregiver accepts or rejects 65. The caregiver can also review the post-remote programming IMD settings and patient data provided by the unregulated server 61 as post-programmed data 69.

Within the regulatory control zone 51, the caregiver-designated programming instruction 63 and all associated parameters 64 are processed by the regulatory server 53. Programming instructions 63 and parameters 64 are checked for accuracy and translated into commands formatted for PMD representation 56, as described below with reference to FIG. The PMD format command 56 is also digitally signed by the trusted server, the regulatory server 53, to protect the transmission of the command to the RPD 54 and PMD 55. Digital signatures allow RPD54, PMD55, or both devices to verify the authenticity and integrity of PMD format command 56. Authenticity confirms the identity of the command source as legitimate, and integrity ensures that the command was not modified on the move. After digital signature, the command is also housed in secure storage.

The validation data 68 is created within the regulatory control zone 51 and is delivered to the non-regulatory control zone 52 via a dedicated secure connection 33 for presentation to the caregiver.

After caregiver approval, PMD format command 56 is delivered and validated by RPD54, PMD55, or both devices. Verification includes checking PMD format command 56 for authenticity and integrity. Only validated commands are applied to modify the PMD55 programming.

Finally, to enable remote programming, the RPD54 applies not only the PMD format command 56, but any other data 57 such as query commands or firmware patches to the PMD55. After successful application, the RPD54 can contact the PMD55 to read the patient's physiological function data 58, parametric data 59, and environmental data 60, if applicable, but these are programming confirmations and It is provided to the data entry mechanism 62 as post-programmed data 69 for caregiver review. In a further embodiment, the PMD 55 may itself apply the PMD format command 56 and autonomously provide the patient's physiology data 58, parametric data 59 and, where applicable, environmental data 60. ..

The caregiver can remotely query and program the PMD using a data entry mechanism to specify programming instructions and all associated parameters. FIG. 3 is a data flow diagram showing the caregiver data input 80 of the remote programming instruction in the system 10 of FIG. The data entry mechanism can be located inside or outside the regulatory control zone. However, instructions issued by data entry mechanisms outside the regulatory control zone must be coordinated through regulatory servers that perform accuracy checks and digital signatures.

For remote programming purposes, caregivers are limited to a subset of PMD's programmable features, except for features that can only be performed when the patient and caregiver are in physical proximity. The remaining set of "safe" features can be programmed remotely without worrying about jeopardizing patient safety. In addition, programming instructions and associated parameters must be translated into commands formatted for PMD representation by a regulatory server, or other regulatory device capable of translating PMD-formatted commands.

Remote programming can be applied to PMD in real time or deferred time. Real-time remote programming requires a valid connection between the data entry mechanism, the PMD, and each component in between. From the caregiver's point of view, through post-programming data review, all end-to-end remote programming operations that underlie the specification of programming instructions and parameters occur in a single session. Therefore, apart from the distance that may separate the caregiver from the patient and the slight additional delay required for command translation, accuracy checking, data security, acceptance, and transmission, real-time remote programming. The session is closest to the programming session in the clinic. On the other hand, remote programming at a postponed time is an intentional delay, that is, remote programming scheduled to be applied at a later time or at time intervals, or end-to-end real-time. There is any delay that is longer than the minimum delay required to enable remote programming.

First, the current patient PMD settings and patient physiology information are presented to the caregiver as pre-programming data 81. The pre-programmed data 81 is incorporated into the caregiver data entry page 82, which may be a web page or other representation for display to the caregiver on the data entry mechanism. The caregiver can specify remote programming instructions and any accompanying parameters 83.

To ensure patient safety, only secure remote programmable features are displayed as a caregiver's choice through the data entry mechanism. In a further embodiment, secure programmable features can be further limited to: (1) Functions allowed when the PMD is in a specific state or mode, (2) A parameter that provides a subset of the range of features allowed for any of the features in the immediate vicinity, or (3) Preset commands. This can be programming a set of settings within the device as a single unit. In addition, the scope can be further limited to a single direction, i.e., a complete increase or decrease, with respect to parameters that limit the choices to a functional subset of the function in the immediate vicinity. Operationally, the data entry mechanism limits choices to the programming instructions and parameters that can be allowed, or provides immediate feedback to the caregiver when attempts to select programming instructions or parameters are not allowed. Other restrictions on programming instruction and parameter choices are possible.

Upon receipt, the regulatory server translates the programming instruction and parameter 83 into PMD format command 84, which is checked for accuracy as described further below with reference to FIG. After the accuracy check, the PMD format command is digitally signed (85) and a digitally signed PMD format command 86 is created, which is also stored in secure storage. If remote programming is performed using a regulated data entry mechanism, such as a remotely connectable programmer, the accuracy check and digital signature is performed by the regulated data entry mechanism itself. Digital signatures allow RPD, PMD, or both devices to verify the authenticity and integrity of commands.

Programming instructions and associated parameters specified using the unregulated data entry mechanism must be verified by the caregiver to ensure an accurate translation into the PMD representation. FIG. 4 is a data flow diagram showing validation 90 of the caregiver's remote programming instructions in system 10 of FIG. The PMD format command 84 is reverse translated into validation data 91 and incorporated into caregiver validation page 92, even if it is a web page or other representation for display to the caregiver on the data entry mechanism. Good. In one embodiment, caregiver validation page 92 uses the simple parameter: old value, new value representation format, but other formats are possible. Upon receipt, the caregiver indicates acceptance or refusal, which is provided to the regulatory server as caregiver response 93 and is housed in secure storage. If accepted, the regulatory server marks the digitally signed PMD format command 86 (shown in Figure 3) for delivery to the RPD associated with the remotely programmed PMD (94), digitally signed and Create a PMD format command marked for delivery, or simply create an "accepted" PMD format command 95. The mark 94 indicating that the accepted PMD format command 95 is ready for delivery may be in the form of a digital signature. Digitally signed PMD format command 86 that is not marked for delivery is not sent.

Other processing is possible for PMD format commands for which caregiver approval is pending. For example, PMD format command 84 may be stored in secure storage without being initially digitally signed. Command 84 is signed only after the caregiver approves, and unsigned commands are not sent. Alternatively, the PMD format command 84 is digitally signed and stored in secure storage, but receives a second digital signature after the caregiver's approval. Commands without a second digital signature are not sent. Finally, PMD format command 84 can be signed and stored in secure storage. After receiving caregiver approval, the regulatory server checks the digital signature and, if valid, replaces the original digital signature with a new digital signature. No second undigitally signed command will be sent. Other processing is possible for the command.

Verification and application of remote programming is independent of the device used for programming input, accuracy checking, and acceptance. FIG. 5 is a data flow diagram showing the validation and application 100 of the accepted PMD format command 95 in system 10 of FIG. The accepted PMD format command 95 is received by the RPD before the next inquiry session of the PMD. The accepted PMD format command 95 is either pushed to the RPD or pulled to the RPD by the regulatory server. In addition, regulatory server and RPD interface connections are made on a regular or on-demand basis. In a further embodiment, the accepted PMD format command 95 is received directly by the PMD using the same or similar form of interface connection to the regulatory server or other regulatory component.

After receiving the accepted PMD format command 95, the RPD verifies the authenticity of the command, that is, the source, as well as the integrity of the command, the digital signature, as described further below with reference to Figure 9. (101). In a further embodiment, the PMD itself can verify the authenticity and integrity of the command in addition to or on behalf of the RPD. In a further embodiment, the RPD can also check for accepted PMD format command 95 for obsolescence and redundancy, as described further with reference to FIG.

In contrast to the clinic or hospital environment where the caregiver and the patient are physically close to each other and the patient's consent can be established, remote programming is an explicit patient consent 102. Needs. Patient consent 102 can be confirmed through several approaches, including: (1) The RPD may prompt the patient to press a button on the user interface or a similar control unit to indicate consent. (2) The caregiver can manually inform the patient that new programming is available for the patient's PMD, and the patient can initiate a programming session through interaction with the PMD. (3) For example, the PMD itself can prompt the patient at the same time as the inquiry session for reading the stored patient data. (4) The patient's consent is accepted before the start of remote programming and is stored in secure storage. The regulatory server can confirm prior patient consent before sending the accepted PMD format command 95 to the RPD. In a further embodiment, the prior patient consent can be contained within the accepted PMD format command 95, in which case the prior patient consent is RPD before initiating a remote programming session with the PMD. Can be used by. Other forms of confirming patient consent 102 are also possible.

Once the patient's consent is confirmed, the RPD performs the actual programming 103 by applying the accepted PMD format command 95 to the PMD during the programming session. Long-distance telemetry, such as RF telemetry, through short-range telemetry, such as guided telemetry, using a wand physically connected to the RPD, or only requiring the patient to be in the immediate vicinity of the RPD. Through, it is possible to apply the accepted PMD format command 95. In a further embodiment, U.S. Patent Application No. 10 / 800,806 (pending) by the same applicant filed March 15, 2004, and U.S. Patent Application No. 10 / 801,150 (pending) filed March 15, 2004. Medium) (these disclosures are incorporated by reference), guidance or other forms of short-range telemetry, or authentication through physical communication or interface, through long-range telemetry. It may be required before starting a programming session.

Programming is handled in a single session. If the programming session is interrupted due to the patient moving out of range or dropping the wand, the patient may be prompted to resume the session. If necessary, upon receiving a response from the patient to resume the session, the RPD will retry the application of programming by automatically resuming the session if the interruption was for a very short period of time. .. If prior patient consent has already been obtained, the RPD can automatically retry without first prompting the patient. However, if the patient ignores the prompt or the interruption lasts for a long time, the programming session is stopped and the state of the previous PMD program is restored.

After a remote programming session, you can check the programming and evaluate its effectiveness by contacting PMD. FIG. 6 is a data flow diagram showing the report 110 after remote programming in the system 10 of FIG. After the programming session is complete, the RPD can contact the PMD (111) to read patient and device data 112, which is provided by the unregulated server as post-programmed data 113 and is housed in secure storage. To. The programmed data 113 is incorporated into the caregiver report page 114, which may be a web page or other representation for display to the caregiver on the data entry mechanism. In a further embodiment, the patient provides qualitative patient data through the user interface of the RPD or other patient-operable device to provide subjective feedback after application of the accepted PMD format command 95. can do.

Remote programming begins with the caregiver's actions and ends with reporting to the caregiver the success or failure of applying the programming to the desired PMD. FIG. 7 is a process flow diagram illustrating method 130 for remotely programming a patient medical device, according to one embodiment. Remote programming is performed as a series of operations, which in certain cases may be stopped or paused at specific points as needed. First, the caregiver conducts a remote programming session through the data entry mechanism (operation 131). The caregiver-selected programming instructions and parameters are translated by the regulatory server into PMD-formatted commands, which are checked for accuracy and digitally signed (operation 132). The PMD format command is also reverse translated and provided to the caregiver in a viewable form for acceptance or rejection (operation 133). If the translated programming is rejected by the caregiver, control returns to the caregiver programming session (operation 131). Otherwise, the PMD format command is marked for delivery to the RPD and is verified for authenticity and integrity after receipt by the RPD (operation 134). In a further embodiment, the PMD itself can perform command validation in addition to or on behalf of the RPD. Assuming the command has been validated, the patient's consent is confirmed before applying the command (operation 135). However, if the patient does not give consent, control returns to the programming session again (operation 131). After consent, the RPD conducts a programming session (operation 136). If the session is interrupted and not resumed, or if it terminates abnormally, the original PMD programming is restored and control returns to the programming session (operation 131). If the programming is successful, after the programming session is complete, the RPD will contact the PMD and report the post-programming results to the caregiver for review and evaluation (operation 13).

The caregiver-specified programming instructions and any associated parameters are applied to the PMD in a remote programming session to ensure that only the allowed settings are specified and to ensure compliance with medical regulations. It must be checked for accuracy before it can be done. FIG. 8 is a process flow diagram showing the programming accuracy check 150 performed in method 130 of FIG. All programming instructions and parameters must be checked for accuracy. Regulatory data entry mechanisms, such as remotely connectable programmers, can perform a complete accuracy check and directly generate PMD format commands. However, programming instructions and parameters issued by the unregulated data entry mechanism must be checked by the regulatory server or equivalent components. As a result, the caregiver-specified programming instructions and associated parameters are provided to the regulatory server as caregiver data selection, which is translated into PMD format commands and checked for accuracy. Is included. (1) Is the command allowed, that is, is the patient safe and remote designation allowed (operation 151)? (2) The value of the parameter is within the appropriate constraint range (operation 152). (3) The command complies with any interaction restrictions, that is, the command is combined with other commands or the current state of the PMD to be patient-safe (operation 153). Other forms of accuracy checking are also possible.

Remote programming requires the transfer of PMD format commands over a network or other interconnect, which creates the potential for harm or error. PMD format commands are protected using a digital signature on a regulatory server or a source that is a regulatory data entry mechanism, such as a programmer, in the case of programming originating from an unregulated data entry mechanism. FIG. 9 is a process flow diagram showing verification 160 of the PMD format command executed in method 130 of FIG. After accuracy checking and caregiver acceptance, PMD format command 56 is digitally signed by regulatory server 53 if remote programming is performed using an unregulated data entry mechanism (operation 161). Otherwise, the digital signature is done by the regulatory data entry mechanism. In one embodiment, a 2048-bit asymmetric RSA key with a SHA-1 hash algorithm is used for digital signatures, but other forms of digital signatures are also possible. When marked for delivery, the digitally signed PMD command is sent to the RPD associated with the remotely programmed PMD (operation 162). After receipt, the digitally signed PMD format command is verified by the RPD, PMD, or both devices before being applied. Verification includes authenticity decisions (operation 163), including confirmation that the source is a certified regulatory server or other certified regulatory device, and integrity verification (operation 164). Other types of verification are also possible.

Remote programming introduces a delay between when new PMD programming is specified and when the generated PMD format commands are actually applied to the PMD. Considering the presence of intervention events such as PMD programming in a clinic or hospital environment, delays can lead to programming obsolescence or redundancy. FIG. 10 is a process flow diagram showing an obsolescence check 170 performed in a further embodiment of method 130 of FIG. After accuracy checking and caregiver acceptance, the accepted PMD format command 95 must have an additional expiration date, i.e., after which certain programming must be rejected (operation 173) and applied (operation 174). ) You can add a "obsolete" check (operation 171) to set when it shouldn't be.

The accepted PMD format command 95 can also be checked for redundancy prior to application (operation 172). A time stamp indicating the time when the PMD was last programmed may be stored by the PMD. This "last programming" time stamp is one of the pre-programming data 67 (shown in Figure 2) provided to the caregiver for consideration and consideration when entering programming instructions and parameters with the data entry mechanism. Can be provided as a department. The time stamp of that particular last programming is then included in the later accepted PMD format command 95. Before being applied to the PMD, the last programming timestamp contained in command 95 is checked against the last programming timestamp currently stored in the PMD. If the timestamps do not match, this particular programming is rejected as redundant (operation 173) and does not apply (operation 174). Other forms of obsolescence and redundancy checking are also possible.

Although the present invention has been specifically shown and described with reference to embodiments, those skilled in the art will be made to the above and other modifications in mode and detail without departing from the gist and scope of the invention. It will be understood that it can be done.

<figref num="1">FIG. 1 is a block diagram showing a system for remotely programming a patient medical device, for example, according to one embodiment.</figref><figref num="2">FIG. 2 is a data flow diagram showing the overall data exchange between the medical regulated control zone and the non-regulated control zone.</figref><figref num="3">FIG. 3 is a data flow diagram showing the caregiver's data input of remote programming instructions in the system of FIG.</figref><figref num="4">FIG. 4 is a data flow diagram showing validation of caregiver remote programming instructions in the system of FIG.</figref><figref num="5">FIG. 5 is a data flow diagram showing verification and application of PMD format commands in the system of FIG.</figref><figref num="6">FIG. 6 is a data flow diagram showing a report after remote programming in the system of FIG.</figref><figref num="7">FIG. 7 is a process flow diagram illustrating a method for remotely programming a patient medical device according to an embodiment.</figref><figref num="8">FIG. 8 is a process flow diagram showing the accuracy check of remote programming performed by the method of FIG.</figref><figref num="9">FIG. 9 is a process flow diagram showing the verification of the PMD format command executed by the method of FIG.</figref><figref num="10">FIG. 10 is a process flow diagram showing an obsolescence check performed in a further embodiment of the method of FIG.</figref>