Fault-tolerant remote reprogramming for a patient-worn medical device

• US 20030095648A1
• Filed: 11/27/2002
• Published: 05/22/2003
• Est. Priority Date: 10/05/1999
• Status: Abandoned Application

• Current Assignee: Zoll Medical Corporation (Asahi Kasei Corporation)
• Original Assignee: Zoll Lifecor Corporation (Asahi Kasei Corporation)
• Inventors: Nguyen, Thomas T., Kaib, Thomas E., Donnelly, Edward J.
• Application Number:
  US10/305,515
• Publication Number:
  US 20030095648A1
• Time in Patent Office: Days
• US Class Current: 379/106.02
• CPC Class Codes: A61B 5/0006 ECG or EEG signals
• CPC Class Codes: A61N 1/37 Monitoring; Protecting
• CPC Class Codes: A61N 1/37282 characterised by communication with experts in remote locations using a network
• CPC Class Codes: A61N 1/3956 Implantable devices for applying electric shocks to the heart, e.g. for cardioversion
• CPC Class Codes: G06F 8/65 Updates security arrangements therefor G06F21/57
• CPC Class Codes: G16H 40/40 for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
• CPC Class Codes: G16Z 99/00 Subject matter not provided for in other main groups of this subclass

Abstract

A method of remotely updating or upgrading the operating parameters of the wearable medical device is also provided. The method will automatically update the operational software of the device during a data download sequence. During such a download sequence, after the data has been downloaded, a remote server at the remote location will query the device'"'"'s current operating software version which is stored in a main memory area of the device. If a software upgrade is needed, the method will clear an alternate memory area in the device. The remote server will then begin downloading the new (upgraded) operating software to the medical device where it will be stored in an alternate memory area. After downloading is complete, the integrity of the new operating software in the alternate memory area is verified by performing a cyclic redundancy check (CRC) or other error checking method If the new operating software passes verification, the method will add a new entry to a boot vector table in the device that will cause the medical device to execute the new operating software located in the alternate memory area during the next power-up sequence. The medical device will continue to execute its current operating software version until the device power is cycled. The new operating software will self-install during the next power-up sequence. In the event of a failure during the updating sequence, a valid operating software image is always available from either the main or alternate memory areas.

Claims

1. A method of remotely updating operating software for a device, the method comprising the steps of:

downloading new operating software from a remote server to the device;

storing the downloaded new operating software in a first memory in the device; and

adding a first new vector to a boot vector table, wherein the first new vector will cause the device to load the new operating software from the first memory for execution during a next power-up sequence.

2. The method of claim 1, wherein the device comprises a medical device operatively attachable to a patient for monitoring and recording patient medical data, and wherein the downloading, storing and adding steps are all performed automatically during a data download sequence.

3. The method of claim 2, wherein the medical device comprises a wearable cardioverter defibrillator.

4. The method of claim 1, further comprising the step of verifying the downloaded new operating software, wherein the first new vector is added to the boot vector table only if the downloaded new operating software passes the verification step.

5. The method of claim 4, wherein the verifying step comprises performing a cyclic redundancy check on the downloaded new operating software.

6. The method of claim 1, wherein during the next power-up sequence, the method further comprises the steps of:

copying the new operating software from the first memory to a second memory in the device for execution;

erasing old operating software from a third memory in the device;

copying the new operating software to the third memory; and

adding a second new vector to the boot vector table, wherein the second new vector will cause the device to load the new operating software from the third memory for execution during subsequent power-up sequences,

7. The method of claim 6, further comprising the step of verifying the new operating software in the first memory, wherein the new operating software is copied to the second memory only if the new operating software in the first memory passes the verification step.

8. The method of claim 6, further comprising the step of executing the new operating software in the second memory, wherein the old operating software is erased from the third memory only after the new operating software has begun executing.

9. The method of claim 6, further comprising the step of verifying the new operating software in the third memory, wherein the second new vector is added to the boot vector table only if the new operating software in the third memory passes the verification step.

10. The method of claim 6, further comprising the step of erasing the first memory after the second new vector has been added to the boot vector table.

11. A method of remotely updating operating software for a medical device for monitoring patient medical data, the medical device storing the monitored medical data and transmitting the stored medical data, via a communications network, to a remote location during a data download sequence, the method comprising the steps of:

querying the medical device'"'"'s current operating software to determine if an update is required, the current operating software stored in the first memory in the medical device; and

if an update is required,

downloading new operating software from a remote server to a second memory in the medical device;

verifying the downloaded new operating software in the second memory;

if the downloaded new operating software in the second memory passes the verification step, configuring the medical device to load the new operating software from the second memory for execution during a next power-up sequence; and

if the downloaded new operating software in the second memory does not pass the verification step, continuing to load the current operating software from the first memory for execution during the next power-up sequence.

12. The method of claim 11, wherein the configuring step comprises adding a first new vector to a boot vector table, wherein the first new vector will cause the medical device to load the new operating software from the second memory for execution during the next power-up sequence.

13. The method of claim 11, wherein if an update is required and the downloaded new operating software in the second memory passed the verification step, the method further comprising the steps of:

during the next power-up sequence,

loading the new operating software from the second memory for execution;

replacing the current operating software in the first memory with the new operating software;

verifying the new operating software in, the first memory;

if the new operating software in the first memory passes the verification step, configuring the medical device to load the new operating software from the first memory for execution during subsequent power-up sequences; and

if the new operating software in the first memory does not pass the verification step, continuing to load the new operating software from the second memory for execution during subsequent power-up sequences.

14. The method of claim 13, wherein the replacing step comprises the steps of:

deleting the current operating software from the first memory; and

copying the new operating software to the first memory.

15. The method of claim 13, wherein the configuring step comprises adding a second new vector to the boot vector table, wherein the second new vector will cause the medical device to load the new operating software from the first memory for execution during subsequent power-up sequences.

16. The method of claim 13, further comprising the step of executing the loaded new operating software, wherein the replacing step is not performed until after the new operating software has begun executing.

17. The method of claim 13, further comprising the step of verifying the new operating software in the second memory prior to the loading step, wherein the new operating software is loaded for execution only if the new operating software in the second memory passes the verification step.

18. The method of claim 13, wherein if the new operating software in the first memory passes the verification step, the method further comprises the step of erasing the second memory.

19. The method of claim 11, wherein the medical device comprises a wearable cardioverter defibrillator, and wherein the patient medical data comprises electrocardiogram data of the patient'"'"'s heart rhythm.

20. The method of claim 11, wherein the querying, downloading, verifying and configuring steps are all performed automatically during a data download sequence.

21. The method of claim 20, wherein the querying, downloading, verifying and configuring steps are all performed automatically after the patient medical data has been downloaded to the remote location during the data download sequence.

22. A method of remotely updating operating software for a medical device for monitoring patient medical data, the medical device storing the monitored medical data and transmitting the stored medical data, via a communications network, to a remote location during a data download sequence, the method comprising the steps of:

during a data download sequence, automatically

determining that the medical device'"'"'s current operating software needs to be updated, the current operating software stored in a first memory in the medical device;

downloading new operating software from a remote server to a second memory in the medical device;

verifying the downloaded new operating software in the second memory; and

if the downloaded new operating software in the second memory passes the verification step, configuring the medical device to load the new operating software from the second memory for execution during a next power-up sequence.

23. The method of claim 22, further comprising the step of:

if an error condition occurs at any of the determining, downloading, verifying and configuring steps, loading the current operating software from the first memory for execution during the next power-up sequence.

24. The method of claim 22, wherein the configuring step comprises adding a first new vector to a boot vector table, wherein the first new vector will cause the medical device to load the new operating software from the second memory for execution during the next power-up sequence.

25. The method of claim 22, further comprising the steps of:

during the next power-up sequence, automatically

verifying the new operating software in the second memory;

if the new operating software in the second memory passes the verification step, loading the new operating software from the second memory for execution; and

if the new operating software in the second memory does not pass the verification step, loading the current operating software from the first memory for execution.

26. The method of claim 22, further comprising the steps of:

during the next power-up sequence, automatically

loading the new operating software from the second memory for execution;

executing the loaded new operating software;

replacing the current operating software in the first memory with the new operating software; and

configuring the medical device to load the new operating software from the first memory for execution during subsequent power-up sequences.

27. The method of claim 26, wherein the configuring step comprises adding a second new vector to the boot vector table, wherein the second new vector will cause the medical device to load the new operating software from the first memory for execution during subsequent power-up sequences.

28. The method of claim 26, wherein the replacing step comprises the steps of:

deleting the current operating software from the first memory; and

copying the new operating software to the first memory.

29. The method of claim 28, further comprising the step of verifying the copied new operating software in the first memory, wherein the medical device is configured to load the new operating software from the first memory for execution during subsequent power-up sequences only if the new operating software in the first memory passes the verification step.

30. The method of claim 29, wherein if the new operating software in the first memory does not pass the verification step, continuing to load the new operating software from the second memory for execution during subsequent power-up sequences.

31. The method of claim 26, wherein the replacing step is performed only after the new operating software has begun executing.

32. The method of claim 22, wherein the medical device comprises a wearable cardioverter defibrillator, and wherein the patient medical data comprises electrocardiogram data of the patient'"'"'s heart rhythm.

33. The method of claim 22, wherein the determining, downloading, verifying and configuring steps are all performed automatically after the patient medical data has been downloaded to the remote location during the data download sequence.