US20090158274A1

Movatterモバイル変換

Info

Publication number: US20090158274A1
Application number: US12/189,640
Authority: US
Inventors: Nick Roberts
Original assignee: Smiths Medical MD Inc
Current assignee: Smiths Medical ASD Inc
Priority date: 2007-08-10
Filing date: 2008-08-11
Publication date: 2009-06-18
Also published as: AU2008286957A1; CN102831294B; CA2696082C; AU2008286957B2; US20090156991A1; JP2010536111A; EP2186030B1; CN102831294A; CN102982226A; US20090157695A1; US20090177769A1; CN102831293B; US20090099866A1; CA2696082A1; US20090150484A1; US20090157202A1; EP2186030A2; US20090157622A1; US9483615B2; CA3029603A1

Abstract

Methods and systems of patient treatment are disclosed. The methods and systems include use of medical device informatics to modify and validate therapies and drugs used in those therapies. In certain embodiments, a medical device, such as a medical infusion pump, interfaces with a server to administer the patient treatments. In one aspect, a software development kit is disclosed. The kit includes medical device installation software containing computer-readable instructions allowing a user to define metadata related to one or more characteristics of a medical device. The kit also includes data package delivery software including computer-readable instructions configured to deliver a data package from a server to a medical device. The kit further includes server software containing computer-readable instructions for execution on a medical device server, the server software configured to control communication from the server to the medical device.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority to U.S. Provisional Patent Application No. 60/964,444, entitled “Patient Treatment Systems Employing Medical Device Informatics”, and filed Aug. 10, 2007. That application is hereby incorporated by reference in its entirety.

TECHNICAL FIELD

In general, the present disclosure relates to treatment of patients via systems for use and control of medical devices. More specifically, the present disclosure relates to software for treatment of patients using medical devices.

BACKGROUND

Patients at hospitals and other care centers require controlled therapy administration and monitoring. Hospitals and care centers use a variety of types and brands of medical devices to assist in monitoring and therapy administration. For example, medical devices used to assist in therapy administration may include medical infusion pumps, pulse oximeters, cardiopulmonary monitors, and other therapy delivery and patient monitoring equipment. The various types and brands of medical devices each generally use differing, proprietary communication standards.

The proprietary standards employed by the different devices limit interoperability among the devices, making therapy administration difficult. During use of one or more of the medical devices, a caregiver may want to perform a number of actions related to the medical device. For example, a caregiver may wish to set parameters in a medical device based on the observed characteristics of the patient. Or, the caregiver may wish to view data gathered by a monitor. Due to the proprietary standards used by various medical devices, the caregiver may use a number of types of software and hardware to access the information gathered by the medical device needed to treat the patient.

Coordinating usage of medical devices also can be difficult. A single medical device can be programmed for administering different therapies and in different locations within a hospital. Usage records of multiple medical devices of varying types and in different hospitals may need to be compared. Similarly, the status of a medical device can be difficult to monitor because the devices are often in locations other than where the caregiver is located.

SUMMARY

Methods and systems of patient treatment are disclosed. The methods and systems include use of medical device informatics to modify and validate therapies and drugs used in those therapies. In the various aspects of the present disclosure, a medical device, such as a medical infusion pump, interfaces with a server to administer treatments to patients.

In certain aspects, medical device metadata is used to define a medical device within a medical device network. In further aspects, messages are communicated between a medical device and server to define treatments and other operations to the medical device. In still other aspects, operational and historical data is communicated from medical devices to a medical device server to allow remote monitoring of the administration of a therapy to a patient. In further aspects, timing parameters dictate communication and tracking of events between a medical device and a medical device server.

In a particular aspect, a software development kit is disclosed. The kit includes medical device installation software containing computer-readable instructions allowing a user to define metadata related to one or more characteristics of a medical device. The kit also includes data package delivery software including computer-readable instructions configured to deliver a data package from a server to a medical device. The kit further includes server software containing computer-readable instructions for execution on a medical device server, the server software configured to control communication from the server to the medical device.

In a second aspect, a kit for enabling communication between a medical device and a medical device server is disclosed. The kit includes medical device installation software containing computer-readable instructions allowing a user to define metadata related to one or more characteristics of a medical device, the medical device installation software associating the metadata with the one or more characteristics on the medical device and the medical device server. The kit also includes data package delivery software, the data package delivery software including computer-readable instructions configured to deliver a data package from a server to a medical device, the data package containing computer-readable instructions configured to control operation of the medical device. The kit further includes server software containing computer-readable instructions for execution on a medical device server, the server software configured to control communication from the server to the medical device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows an exemplary medical device network in which aspects of the present disclosure may be implemented;

FIG. 2 is a block diagram of a medical device useable in aspects of the present disclosure;

FIG. 3 is a diagram of a software architecture for a medical device network;

FIG. 4 is a diagram of a second software architecture for a medical device network;

FIG. 5 is a flowchart of methods and systems for remote management of medical devices controlled by multiple entities;

FIG. 6 is a flowchart of methods and systems for server based control of medical devices;

FIG. 7 is a state diagram of possible state for remote control of a medical device;

FIG. 8 is a functional diagram of a messaging system for use in a medical device network;

FIG. 9 is a flowchart of methods and systems for communication between a medical device and a medical device server;

FIG. 10 is a flowchart of further methods and systems for communication between a medical device and a medical device server;

FIG. 11-16 are data models including metadata useable to facilitate extensible communication systems for medical devices and medical device servers;

FIG. 17 is a flowchart of methods and systems for filtering medical device events;

FIG. 18 is a flowchart of methods and systems for managing maintenance of medical devices;

FIGS. 19-24 are data models including event metadata useable to track events occurring in medical devices;

FIG. 25 is a diagram of a data packet formatted for transmission from a medical device server to one or more medical devices;

FIG. 26 is a flowchart of methods and systems for delivery of the data packet ofFIG. 25;

FIGS. 27-32 are data models including metadata useable to facilitate delivery of data packets to medical devices from a medical device server;

FIG. 33 is a schematic diagram including metadata useable to synchronize time within a medical device network;

FIG. 34 is a flowchart of methods and systems for synchronization of medical devices in a medical device network;

FIG. 35 is a flowchart of methods and systems for time adjustment of event log data;

FIG. 36 is a block diagram of functional units of a medical device server, according to a possible embodiment of the present disclosure;

FIG. 37 is a block diagram of medical device server administration systems;

FIG. 38 is a sample medical device administration event tracking report accessible from a medical device server;

FIG. 39 is a sample security event tracking report accessible from a medical device server;

FIG. 40 is a sample security event trending report accessible from a medical device server;

FIG. 41 is a sample user history report accessible from a medical device server;

FIG. 42 is a user interface for management of medical device metadata;

FIG. 43 is a further user interface for installation of medical device metadata;

FIG. 44 is a user interface for management of data packet distribution in a medical device network;

FIG. 45 is a further user interface for deployment of data packets to medical devices in a medical device network;

FIG. 46 is a user interface confirming deployment of a data packet to a medical device;

FIG. 47 is a sample quarantine report indicating erroneous data transmission from a medical device server to a medical device;

FIG. 48 is a sample detailed quarantine report, corresponding to the quarantine report ofFIG. 47;

FIG. 49 is a sample package deployment report displaying deployments of data packets from a medical device server to medical devices;

FIG. 50 is a sample package deployment error report displaying erroneous deployments of data packets from a medical device server to medical devices;

FIG. 51 is a sample maintenance report displaying medical device maintenance events;

FIG. 52 is a sample medical device fault report displaying medical device faults communicated to a medical device server;

FIG. 53 is a sample medical device fault trending report displaying trends in medical device faults communicated to a medical device server;

FIG. 54 is a flowchart of methods and systems for communicating parameter changes from a medical device server to a medical device;

FIG. 55 is a schematic diagram including metadata useable to facilitate therapy-based programming of medical devices from a medical device server;

FIG. 56 is an exemplary messaging sequence for therapy-based programming of a medical device;

FIG. 57 is a flowchart of methods and systems for tracking changed medical device parameters communicated to a medical device server;

FIG. 58 is a sample medical device history report displaying event log data communicated from a medical device to a medical device server;

FIG. 59 is a sample therapy history report displaying therapy event log data communicated from a medical device to a medical device server;

FIG. 60 is a sample therapy trending report displaying therapy trends derived from therapy event log data communicated from a medical device to a medical device server;

FIG. 61 is a sample therapy change history report displaying changes to therapies in therapy event log data communicated from a medical device to a medical device server;

FIG. 62 is a sample therapy change trending report displaying therapy change trends derived from therapy event log data communicated from a medical device to a medical device server;

FIG. 63 is a flowchart of systems and methods for determining an on-line status of a medical device;

FIG. 64 is a flowchart of systems and methods for collecting telemetry data from a medical device;

FIG. 65 is an exemplary messaging sequence for receiving telemetry data from a medical device;

FIG. 66 is schematic diagram including metadata useable to facilitate communication of telemetry data from medical devices to a medical device server;

FIG. 67 is an example dashboard useable to display telemetry data related to one or more medical devices.

DETAILED DESCRIPTION

Various embodiments of the present invention will be described in detail with reference to the drawings, wherein like reference numerals represent like parts and assemblies throughout the several views. Reference to various embodiments does not limit the scope of the invention, which is limited only by the scope of the claims attached hereto. Additionally, any examples set forth in this specification are not intended to be limiting and merely set forth some of the many possible embodiments for the claimed invention.

The logical operations of the various embodiments of the invention described herein are implemented as: (1) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a computer, (2) a sequence of computer implemented steps, operations, or procedures running on a programmable circuit within a medical device; and/or (3) interconnected machine modules or program engines within the programmable circuits.

The description set forth herein discusses use and programming of a variety of medical devices and a medical device server in a medical device network. One skilled in the art will realize that a wide variety of medical devices are used in administering a therapy to a user, such as medical infusion pumps, pulse oximeters, cardiopulmonary monitors, and other therapy delivery and patient monitoring equipment. These and additional medical devices may be used in the medical device network of the present disclosure. In various aspects of the present disclosure, the term medical device server refers to a computing system and a message handling and storage service used for coordination of various other components of the system. Additionally, the term “user” in the context of the medical device generally applies to the person who is receiving a therapy. In many other contexts, such as the context of usage of the medical device server, the user could also refer to any other person such as a caregiver that is operating the medical device or a computer with access to information about the medical device.

Additionally, the medical devices and interconnected computing systems considered in the present disclosure generate and present information and fields in user interfaces and reports, which are also referred to as displays. The user interfaces and reports can include fields, alpha/numeric character strings, times, and dates. The fields, also referred to as cells, prompt users to enter and/or select information. Various types of input and display devices are available on various computing systems and medical devices.

The various types of medical devices encompassed by the present disclosure execute or utilize operating parameters, which customize or personalize operation of computer implemented steps, machine modules, and programs to meet the requirements of individual medical device users. The operating parameters can be numerical values, text strings, flags, argument names, or any other aspect of medical device programming that the user or a caregiver can set to control operation of the medical device. In certain aspects of the present disclosure, metadata indicates a textual definition of the capabilities of the various operating parameters within the medical device, and to servers and other computing systems interfaced with the medical device.

I. Hardware Environment

Referring generally toFIGS. 1 and 2, a generalized hardware environment is described.FIG. 1 shows an exemplarymedical device network100 in which aspects of the present disclosure may be implemented. Themedical device network100 provides a method by which a variety of medical devices and communication systems intercommunicate. Themedical device network100 includes amedical device server102 interconnected with a variety of types of medical devices. The medical devices can include an activemedical device104, a passivemedical device106, and a plurality of exemplary medical devices shown to be medical infusion pumps108.

The activemedical device104 refers to any of a number of medical devices configured to assist in administering a therapy to a patient. Active medical devices include medical infusion pumps for delivery of fluidic therapies, or other therapy-providing equipment. In one embodiment, the activemedical device104 is a medical infusion device, such as the medical infusion pumps108 shown.

The passivemedical device106 refers to any of a number of observation devices configured to monitor the status of a patient, rather than to actively assist in administering a therapy to that patient. Examples of passive medical devices include pulse oximeters, cardiopulmonary monitors, or other patient observation systems for measuring vital signs of the patient, such as breathing, heart rate and rhythm, blood oxygen levels, and other health indicators.

Themedical device server102 communicates with the medical devices, and is one or more generalized or application-specific computing systems. Themedical device server102 is configured to store and retrieve data received from the various

medical devices

104,106,108. The data received by themedical device server102 can include event log data, programming data, and various other data transmitted to theserver102 from the

medical devices

104,106,108.

Optionally, themedical device network100 includes additional computing devices, such asworkstations110 andportable computing systems112, configured to allow communicative connection to themedical device server102. Theworkstations110 andportable computing systems112 are generalized computing systems or thin client computing systems having a communication interface allowing access to the medical device server. Theworkstations110 andportable computing systems112 generally include input devices and displays, so as to allow a user (i.e. a caregiver) access to data about a patient when that user is not in the same location as the patient. The users may access themedical device server102 via theworkstation110 orportable computing system112 to retrieve data gathered from a medical device, and may instruct themedical device server102 to communicate various messages or software packages to one or more of the medical devices.

Themedical device network100 optionally includes network infrastructure components, such as aswitch114 and awireless access point116. The network infrastructure components are configured to provide the communication infrastructure between the various

medical devices

104,106,108, themedical device server102, and any

additional computing systems

110,112. Although themedical device network100 requires a communicative conduit between the various components included in the network, the specific components included in a given medical device network will vary based upon the particular infrastructure and needs of users of the medical device network. Therefore, theswitch114 andwireless access point116 are intended as exemplary components for implementation of a communicative interconnection between the various components of the network. Additional types of medical devices, computing systems, or networking components may be used in thenetwork100 as well.

Themedical device server102, as well as the

additional computing system

110,112, can correspond generally to a general purpose computing system configured to execute program instructions for performing a variety of operations in the medical device network. Example computing systems can include those constructed by a variety of computer manufacturers, such as Apple, Dell, International Business Machines, and the like. Such computing systems can include, for example, a general purpose or specifically-designed programmable circuit and operably connected memory device, and are configured to execute program instructions to execute the operations described herein.

The programmable circuit can be, for example any of a variety of processing units available from a variety of manufacturers, for example, Intel or Advanced Micro Devices. The computing system also typically includes a system memory that couples various system components including the system memory to the processing unit. A display device can be used to display the user interfaces, as processed by the memory and programmable circuit. The display device can be a touch screen or other type of display. Other peripheral devices can be included in the computing system as well.

The computing system can operate based on instructions stored on computer storage media, communication media, or other means of encoding computer instructions. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by the computing system.

Communication media typically embodies computer-readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” refers to a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared, and other wireless media. Combinations of any of the above should also be included within the scope of computer-readable media. Computer-readable media may also be referred to as computer program product.

FIG. 2 shows an exemplary block diagram of amedical device200. Themedical device200 is any of a number of types of active or passive medical devices for therapy administration or monitoring of a patient. In one possible embodiment, themedical device200 is a medical infusion pump configured to infuse drugs and other fluidic therapies to a patient. Other types of medical devices are possible as well.

Themedical device200 includes aprogrammable circuit202 interfaced to a memory subsystem, including, for example, Random Access Memory (RAM)204, aflash memory206, and an electrically erasable, programmable memory (EEPROM)208. TheRAM204 stores operational parameters of the medical device, as well as any non-critical storage with respect to operational data or instructions. Theflash memory206 stores instruction and/or data memory defining operation of the pump, such as pump programs, pump parameters for use in those pump programs, or other system firmware. TheEEPROM208 stores a set of initial instructions that are used by themedical device200 and must be preserved in the event of a failure of the device, such as due to a power failure, dead battery, or other unanticipated event. TheEEPROM208 optionally includes firmware or instructions which may be read or copied into theRAM204 orflash memory206 for execution, as necessary.

In various embodiments of themedical device200, the various components of the memory subsystem used are dictated by the needs of the medical device. In certain devices, one or more of the memory system components described herein are not present. In such devices, some or all of the data and instructions stored in that device may be stored in another component of the memory subsystem present in the device. RAM may also temporarily provide storage for critical operational data or instructions. Also, alternate embodiments can be provided whereby the contents of the flash memory and the contents of the EEPROM memory previously described may be interchanged, or whereby the contents may be entirely stored in one type of non-volatile memory and none in the other. Finally, other types of non-volatile memory may be used instead, such as ferro-electric memory or others.

Themedical device200 further includes abattery system210 configured to provide a direct current source of power to the medical device when the device cannot be plugged in to a wall power outlet or some other AC power source. In one embodiment, thebattery system210 includes a rechargeable lithium-ion smart battery system configured to provide power management and intelligent switching between DC and AC power modes depending on the presence of AC power. In further embodiments, thebattery system210 includes different types of battery systems, such as a rechargeable battery system including a nickel-cadmium battery.

Themedical device200 includes aninput device212 and anoutput device214 interfaced to theprogrammable circuit202. Theinput device212 allows a user at the location of the medical device to adjust the activity of the device. Theinput device212 can be, for example, a mouse, keyboard, keypad, trackball, touch screen, control buttons, or other user-controllable devices. Theoutput device214 can be any type of audio, video, or data interface configured to provide information regarding the medical device to users and devices external to the device. In various embodiments, theoutput device214 may be a data interface to a second medical device, or may be a connection to an external monitor for display of information to a user regarding the status of themedical device200.

Themedical device200 also includes adisplay device216 and analarm218. Thedisplay device216 is a visual device capable of displaying information to a user of the device. In various embodiments of themedical device200, thedisplay device216 can be, for example, a display device, such as an LCD, CRT, or other screen. Additional types of display devices are possible as well. Furthermore, although the medical device is shown as including adisplay device216, in alternate embodiments a display device is not required. Thealarm218 can be configured to provide various types of audio indications to the user of various conditions detected in the user or the device. These conditions include a health condition detected, such as an abnormally low or high heart rate or respiration rate, or a warning related to the device, such as indicating that a supply of a drug is running low, or that maintenance may be required for the device. The alarm optionally triggers based on additional alarm conditions beyond those listed here; the alarms selected generally relate to the type of medical device implemented and conditions experienced by that device.

Awired communication interface220 provides a data communication connection from themedical device200 that interfaces with a medical device server or other generalized computing system. Thewired communication interface220 interfaces to theprogrammable circuit202, and sends and receives data from themedical device200. In various embodiments, the wiredcommunication interface220 can be an Ethernet or other data connection capable of communicating and receiving digital data.

Awireless communication interface222 provides an alternative communication interface to the wiredcommunication interface220, such that themedical device200 can maintain data communications with a medical device server or other computing system when a wired communication connection is not available or convenient, based on the location of the medical device. Thewireless communication interface222 interfaces to theprogrammable circuit202, and sends and receives data wirelessly from the medical device. Usage of one or both of the wired or wireless communication interfaces is dependent upon the location of the medical device and the need for communication with a medical device server. In one embodiment, the medical device provides a constant data stream to one or both interfaces such that individuals with access to a medical device server can continuously track the status of the medical device. In further embodiments, the medical device activates and/or communicates using one or both interfaces periodically, or intermittently, so as to update the operational data or other information held by either the medical device or the medical device server.

Themedical device200 also includes apatient interface224. Thepatient interface224 controls the mechanical component of themedical device200 which monitors or delivers a therapy to the user. Thepatient interface224 varies among the different types of medical devices based upon the function of the device. In the case where themedical device200 is a monitor, thepatient interface224 may include a sensor or other physical detection equipment. In the case where themedical device200 is a medical infusion pump, the patient interface may include a drive mechanism, occlusion sensor, fluid volume sensor, or other drug control or delivery interfaces. Other medical devices, and corresponding patient interfaces, are possible as well. Additional components beyond those shown may also be included in various embodiments of themedical device200, depending upon the particular application to which the device is directed.

II. Overall Software Environment

FIGS. 3-6 show an overall software environment for themedical device network100 and its components, according to various embodiments of the present disclosure. The software environment disclosed herein is discussed in two sections: (1) those aspects which relate to communications between medical devices and a medical device server, found in part III, and (2) aspects encompassing user interaction with the medical device network, such as to view data related to medical device activity, or to administer changes or additions to the medical device network, found in part IV. Both aspects relate generally to coordination of medical devices in a medical device network, of which the primary physical features are described above inFIGS. 1-2.

The various software disclosed herein, including the metadata installation software, package deployment software, and server software described in Parts II-IV, below can be packaged in a variety of ways, and organized for a variety of different medical device networks. In a possible embodiment, the various software aspects are included in a software development kit (SDK) including some or all of the various software components described herein. In such an embodiment, the medical devices can include monitors and medical infusion pumps, and the software can include pre-packaged metadata files useable on both the medical devices and medical device server. User-readable documentation regarding the software can be included as well.

Additionally, the various software disclosed herein and claimed below can be embodied on any of a number of types of computing systems operable within the hardware environment ofFIGS. 1-2. For example, a computing device typically includes at least some form of computer-readable media. Computer readable media can be any available media that can be accessed by the computing system. By way of example, and not limitation, computer-readable media might comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store the desired information and that can be accessed by a computing system.

FIG. 3 shows asoftware architecture300 in which aspects of the present disclosure are implemented. Thesoftware architecture300 provides an operating environment in which medical device data can be stored and managed remotely from the medical devices. Thesoftware architecture300 also provides an extensible architecture in which a variety of types of medical devices can operate. Thesoftware architecture300 operates using one or more computing systems in communicative connection to various medical devices, and is configurable to operate across multiple locations and different business entities. Thesoftware architecture300 operates within a medical device network including one or more medical devices and a medical device server. A possible configuration of the medical device network in which the software architecture operates is described above inFIG. 1.

In one embodiment, aspects of thesoftware architecture300 are implemented using the relational and business intelligence components of Microsoft SQL Server 2005, distributed by Microsoft Corporation. In such an embodiment, various modules, such as web interfaces, may be provided using a web service, such as Microsoft Internet Information Services (IIS) platform. In further possible embodiments, aspects of the system are implemented usingMicrosoft SQL Server 2000, Oracle, or other database management and business intelligence products, in conjunction with various web services, such as an Apache-based or other web server.

Thesoftware architecture300 includes one or moremedical devices302,back office components304, andclient applications306. Themedical devices302 monitor or deliver therapies to patients, as directed by a caregiver. Themedical devices302 can be any of a variety of programmable medical devices such as those discussed in conjunction withFIGS. 1-2, above.

Theback office components304 include one or moremedical device servers308, anadministration module310, anevent tracking module312, and anoperations module314. Themedical device server308 manages communication with the variousmedical devices302 associated with theback office components304, such as by relaying messages between the

various modules

310,312,314 and themedical devices302. Themedical device server302 creates messages understandable to themedical devices302 and the

various modules

310,312,314 such that a variety of types of medical devices can be managed using the modules. Using the messages sent to themedical devices302, themedical device server308 collects historical information from the medical devices, automates various maintenance operations, assists with therapy setup at a user's bedside, and provides medical device monitoring. In a possible embodiment, themedical device server302 manages a metadata-based messaging system for communicating with a variety of types of medical devices, such as by using XML or some other type of metadata or markup language via SOAP or another messaging protocol.

In one possible embodiment, themedical device server308 resides on a computing system which also hosts the additionalback office components304. In a further embodiment, the medical device server resides on separate computing hardware from the other back office components. In such systems, themedical device server308 may be placed at a different location from the other back office components, or may be managed by a different entity from the other back office components, as is described inFIGS. 4-5, below. For simplicity, throughout the description of the software aspects the term medical device server is intended to encompass either themedical device server308 or theback office components304 as a whole, depending upon the specific implementation chosen. In certain embodiments, themedical device server308 can be placed on one or more physical computing platforms, resulting in the presence of multiple medical device servers.

Theadministration module310 provides an interface toadministration data316, which themedical device server308 andclient applications306 can request for various reasons, such as to allow access to event or operational data, described below. Theadministration data316 includes user validation information, such as username, password, IP authentication, or other user validation, as well as rights information defining the access rights associated with the user. For example, theadministration data316 may associate a username with a password, and require a user to provide the correct username and password to receive a validation right. The username and password information may in turn be associated with access rights information, which defines the specific categories of data, subsets of medical devices, or types of commands allowed to that user. Additional access rights may be defined in theadministration data316 and managed by theadministration module310 as well.

Theadministration data316 also defines the capabilities of the variousmedical devices302 managed within theenvironment300, by defining operational parameters by which themedical device server308 interfaces with amedical device302. For example, a medical device configured to monitor a patient may include a variety of defined parameters relating to monitoring functions, but will not include parameters relating to therapy delivery. In allowing user-definition of a variety of possible medical device capabilities by setting operational parameters within the administration data, theenvironment300 provides a user-extensible set of back office components which are configurable with a variety of medical devices having various capabilities, manufactured by different entities, and employed at different locations.

In a particular embodiment, theadministration module310 generates a web interface accessible to various client application interfaces to remotely validate users or caregivers wishing to access data held within one or more of theback office components304. In a further embodiment, the administration module provides an interface allowing remote applications to access the data managed by theback office components304.

Theevent tracking module312 provides an interface to themedical device server308, and organizes and managesevent data318. Theevent data318 corresponds to the historical data regarding various events occurring in themedical devices302, which are collected and routed by themedical device server308. Theevent data318 correlates a medical device identifier with an event identifier, and additional descriptive information regarding the event occurring in the medical device. Examples of events tracked using theevent tracking module312 include power events, alarm events, maintenance events, telemetry events, therapy events, or therapy change events in the various medical devices. Examples of various events and schema used for tracking such events are discussed below in conjunction withFIGS. 19-24. In a particular embodiment, theevent tracking module312 generates a web interface accessible by themedical device server308 to transfer data to a storage location ofevent data318.

Theoperations module314 manages various operational characteristics of the system, such as system operational information, therapy orders, maintenance jobs, and other information used to affect operation of the variousmedical devices302 associated with theenvironment300. Theoperations module314 also provides a web interface to themedical device server308 for managing the various types ofoperations data320, and to various external computing systems to allow those systems to view theoperations data320 and transmit commands within thesoftware architecture300, such as to the variousmedical devices302.

An optional data warehouse322 aggregates and coordinates the various predefined and collected data, including the administration data, the event data, and the operations data, for use by various client applications. In the embodiment shown, a reporting application receives data from the data warehouse322, which aggregates various data from theadministration data316, theevent data318, and theoperations data320. The data warehouse322 provides a convenient static repository useable to generate reports based on one or more of these types of data. Example reports are described in conjunction with the user to server communication systems described in Part IV, below. The data warehouse322 can be formed using any of a number of relational or On-Line Analytical Processing products, such as SQL Server Analysis Services, Hyperion Essbase, Oracle OLAP, or other data store configured to allow querying or access to various combinations of data. For those embodiments without the optional data warehouse322, its functionality as described herein can be provided by the Administration, Event Tracking, Operations databases and their corresponding modules, as described herein.

Theclient applications306 generally access one or more of the

data sources

316,318,320,322 to generate user output forms indicating to caregivers or other users current or historical information about the medical devices to which that caregiver or user has access. Theclient applications306 accessing theback end components304 includeadministration applications324, reportingapplications326,dashboards328, maintenance forms330, and various additionalexternal applications332.

Theadministration applications324 provide user access to theadministration data316 include a variety of administration web forms, to define usage rights for other users attempting to access theback office components304, as well as to define the operational parameters of themedical devices302. Additional administration web forms may be included as well.

Thereporting applications326 provide a number of standardized reports based on theadministration data316, theevent data318, and theoperation data320. In an embodiment in which theback office components304 include a data warehouse322, the reports may be based on the information in the data warehouse. Examples of reports built using the various types of data tracked in theback office components304 include security reports, user histories, software deployment reports, medical device programming reports, maintenance reports, device history reports, therapy reports, and other reports. Additional examples of the reports are described in Part IV, below.

Thedashboards328 allow a caregiver or user to view the status of amedical device302. Thedashboards328 are based on operation data, and interface to theoperations module310. Thedashboards328 available within theenvironment300 correspond to the variousmedical devices302 capable of frequently transmitting data to theback office components304. Thedashboards328 receive operational data regarding the medical devices, such as the most recent therapy delivered by the devices. This information is reflected on the dashboard user interface, presented on a display device of a computing system accessible to a caregiver or user. In one possible embodiment, thedashboards328 replicate the visual interface of the corresponding medical device, but in a web-portal format.

The maintenance forms330 display maintenance information to a caregiver or other user of themedical devices302. The maintenance forms330 display tracked maintenance information included in theoperations data320, such as performed maintenance, scheduled maintenance, suggested maintenance, and maintenance trends. The maintenance forms330 also allow the user to deploy various updates to themedical devices302, such as firmware updates and other software deployments. In a possible embodiment, theoperations data320 includes maintenance schedule information accessible by users via the maintenance forms. In such an embodiment, the maintenance forms330 display a maintenance schedule to a user, including future maintenance required for variousmedical devices302 as well as historical maintenance events tracked in theoperations data320.

Variousexternal applications332 extend the functionality of thesoftware environment300 by communicating with theoperations module314. Theexternal applications332 include any applications useable to extend the functionality of thesoftware environment300.

FIG. 4 displays analternative software infrastructure400 to the one shown inFIG. 3, and may be used in the instance in which the storage of data from the medical devices is managed by an entity other than the facility at which the medical devices operate. For example, themedical devices302 and medical device server(s)308 may reside at one or more hospitals orhealth care facilities404, managed by one or more healthcare entities, such as counties or private entities. However, the storage of data from those devices may be managed by a health management organization or other organization405 contracting to manage the data of the various facilities at an off-site location. That entity can collect information from themedical device server308 also residing at the facility, which in turn communicates data appropriately to one of the web-based

modules

310,312,314 described above. Such an arrangement allows the hospital to aggregate data from its medical devices at a medical device server, but allows a third party to manage the computing infrastructure and perform the maintenance tasks related to long term storage, administration, access and/or reporting of the data.

FIG. 5 shows systems and methods for management of a software infrastructure such as the one shown inFIG. 4, in which a third party handles the data management tasks related to the data collected from medical devices located within and controlled by various healthcare organizations at various locations, or customer sites. Operational flow within thesystem500 ofFIG. 5 commences at astart operation500, which corresponds to initialization of thesystem500, such as by operation of various medical devices connected to a medical device server.

Adata receipt module504 receives data generated by the medical devices managed by one or more entities, such as hospitals, clinics, or other health management organizations. In one embodiment, thedata receipt module504 corresponds to receipt of various administrative data, event data, or operations data from a medical device server or client applications, as shown in theback office components304 ofFIG. 4.

Anassociation module506 associates the data received in thedata receipt module504 with the medical devices from which the data is received. In one possible embodiment, theassociation module506 associates the data with the various locations at which the medical devices reside, or with the various entities controlling the devices, as defined in theadministration data316. The data association can be a logical or physical relationship between the data, such as can be found in a file, table, or database.

Theassociation module506 prepares the data such that when a user from a particular hospital or location seeks information about medical devices, the back office components can provide to that user only information about the medical devices at that same location or within the same entity as the user, depending upon the particular implementation of theassociation module506. For example, a single hospital or ward of a hospital may have a variety of medical devices whose data is collected and managed by a third party. A doctor, nurse, or other caregiver working in that hospital or ward may access information related to the specific medical devices in that ward from a remote server, not controlled by that ward or hospital.

Anoptional program module508 distributes data or instructions from the back office components to a medical device, based on the specific instructions related to that entity or location. For example, a hospital or ward can request a software upgrade to their medical devices, and the back office components will direct the specific software upgrade requested by the hospital to only that entity's devices or devices only of a specific type, excluding other devices associated with or monitored by the back office components.

In a further example, a workstation at a hospital or other healthcare location can view status information about the medical devices at that location, such as by execution of thedata receipt module504 and theassociation module506, above. In this example, the user of the workstation may optionally choose to reprogram the medical devices, and can do so by issuing a global command to all of the medical devices of a specific type at the location associated with the user. The back office components can transmit to the appropriate medical device server the specific instructions necessary to distribute to the medical devices at that location, without transmitting those instructions to the same medical devices at other locations managed by the back office components.

Operational flow terminates at anend operation510, which corresponds to completion of a communication session with one or more medical devices.

FIG. 6 shows systems and method executable within the medical device network ofFIG. 1, in which medical device actions are interconnected. Thesystem600 specifically relates to interconnection of different types of medical devices at a specific location, such as a group of medical devices all associated with a single patient. Thesystem600 includes a number of rules which execute on the medical device server or other back office components so as to determine any additional advisable therapy or monitoring activity using a second medical device based on observed activity of a patient with a first medical device, as received by the medical device server or back office components.

Operational flow within thesystem600 commences at astart operation602, which corresponds to initial monitoring of a patient using a plurality of medical devices connected to a medical device network. Thestart operation602 also optionally corresponds to receipt of at least one event at the medical device server, as logged by a first medical device which is associated with a patient.

Astatus receipt module604 receives a status of a patient from a first medical device used to monitor or administer a therapy to the patient. In one example, thestatus receipt module604 can receive a status of a patient from a medical device associated with that patient. The status of the patient may include the heart or breath rate or regularity, an indication by the patient that he is experiencing pain, the blood glucose level of the patient, or the progress of one or more therapies administered to the patient. The status of the patient optionally also includes alarms generated by medical devices monitoring or delivering therapies to the patient.

Adetermination module606 executes one or more rules based on the status of the patient received from the first medical device. The one or more rules define whether any additional action is needed with respect to that patient, such as additional or changed therapies or monitoring of the patient. Thedetermination module606 associates various rules with specific medical devices capable of executing the changed therapy. Only those rules are executed which correspond to active medical devices currently monitoring or delivering therapies to the patient. In one example of execution of thedetermination module606, there may exist an instance in which a monitor senses or is told that the patient is experiencing pain. In such an instance, one or more rules execute to determine whether a pain management therapy is available to that patient, and, if such a therapy is available, to determine an appropriate therapy to be administered to that patient. For example, if a medical infusion pump is associated with that patient, thedetermination module606 concludes that the pump is capable of delivering a pain management therapy and calculates appropriate pump parameters for delivery of the appropriate therapy to the patient.

Aprogram module608 generates programming for a target medical device capable of providing the changed or additional therapy or monitoring determined in thedetermination module606. Theprogram module608 communicates the changes or additions to the therapy to either a workstation accessible to a caregiver of the patient, or to a medical device capable of administering the therapy. In one embodiment, theprogram module608 requests that a caregiver approves the suggested therapy determined in thedetermination module606. In a further embodiment, theprogram module608 directly programs the medical device capable of delivering the therapy, such that the therapy may be delivered without any additional caregiver approval or intervention.

Operational flow terminates at anend operation610. Theend operation610 corresponds to the medical device server completing communication of the determined therapy to a workstation or medical device.

III. Medical Device to Server Communication

FIGS. 7-35 describe generally various systems and methods for communication between the medical devices and the medical device server or other back office components, as shown inFIGS. 1-2. The systems and method described in this section relate to coordination of medical devices in a medical device network, which may span across one or more facilities, organizations, time zones, or other logical entities. These systems can be used during user interaction with the medical device network, described in Part IV, below, in that involvement with the user relates to coordination of medical devices as well as collection and communication of data from the medical devices in the medical device network.

Referring now toFIGS. 7-8, communications between a medical device server and a variety of types of medical devices are described. The communication methods used by the medical device server and the medical devices provides an extensible system allowing the medical device server to communicate with a variety of different types of medical devices made by a variety of different medical device manufacturers, each having different communication protocols, capabilities, and other characteristics.

FIG. 7 shows an exemplaryextensible system700 in which a medical device server associates with a remotely located medical device. Thesystem700 tracks the states of medical devices associated with a medical device server, and is used to associate new and existing medical devices with the medical device server to provide an extensible medical device network allowing intercommunication of a variety of types and brands of medical devices placed at a variety of different hospitals or locations within a hospital. In thesystem700, every medical device recognized by a medical device server will have an associated state held in a table on the server. Therefore, thesystem700 will execute independently on the server for each medical device associated with the server. Thesystem700 commences at astart node702 corresponding to connection of the medical device to a medical device network including a medical device server, such as the one shown inFIG. 1.

Upon connection of the medical device, the medical device server must determine whether the medical device is of a known type. If the medical device is of an unknown type, operational flow proceeds to a knownstate704, which corresponds to receiving information about the capabilities of the medical device, so that the medical device is able to be added to the medical device network. The knownstate704 may result from receiving user input describing the operational capabilities of the medical device, or may include communication or testing between the medical device and medical device server. When the medical device server considers a device to be in a known state corresponding to the knownstate704, the medical server treats the medical device as a recognized device, but that is not powered on or otherwise recognized by the system. If the medical device is of a known type, operational flow proceeds to adetermination node706, which corresponds to determining the state of the medical device.

Four operational states define the operation of the medical device from the perspective of the medical device server: apowered state708, a therapy state710, afault state712, and analarm state714. Thepowered state708 corresponds to a medical device which is powered on and experiencing normal operation, but is not currently being used to monitor or deliver a therapy to a patient. Thepowered state708 is entered from the knownstate704 or thedetermination node706 when the medical device transmits an indication to the medical device server that it has been turned on. The powered state is entered from the remaining operational states, i.e. the therapy state710, thefault state712, and thealarm state714, when the medical device server receives an indication that the medical device has cleared the condition causing the server to associate the medical device with one of those states.

The therapy state710 corresponds to a medical device communicating to the medical device server that it is currently in operation, delivering a therapy or monitoring a patient. The specific action taken by the medical device will be dictated by the characteristics of that specific medical device; however, the medical device server need only recognize that the medical device is currently in operation. Thesystem700 can enter the therapy state from any of the other

operational states

708,712,714, or from thedetermination node706. When the medical device successfully completes the therapy, it communicates that event to the medical device server, which returns the table entry associated with that device to thepowered state708. If the medical device fails to complete the therapy due to a fault or alarm event, it will communicate that event to the medical device server, which changes the table entry associated with the device to the appropriate operational state.

Thefault state712 corresponds to an error occurring in the medical device, such as a malfunction in the operation of the device during monitoring or therapy delivery. Thefault state712 can be entered from either thepowered state708 or the therapy state710, and can also be entered from thedetermination node706. In a possible embodiment, thefault state712 can trigger notification of a caregiver having control of the medical device that a fault has occurred. In a further embodiment, when the medical device server receives an indication which generates a fault state entry in the table, the server can determine the fault occurring in the medical device and can correct the error. Upon clearance of the fault state, the medical device transmits an indication to the medical device server that it has returned to its previous operational state, or has entered thepowered state708 if returning from thedetermination node706. The table held by the medical device server tracking the state of the medical device is updated appropriately to reflect the state of the medical device.

Thealarm state714 corresponds to the medical device server receiving an indication from the medical device of an event occurring in the medical device which requires the attention of a doctor, nurse, or other caregiver. For example, the medical device may be a medical infusion pump which has run out of medicine for delivery. In another example, the medical device is a heart rate monitor, and the event is monitoring and detection of an abnormally low or high heart rate. Thealarm state714 can be entered from either thepowered state708 or the therapy state710, and can also be entered from thedetermination node706. Upon clearance of the alarm event, the medical device transmits an indication to the medical device server that it has returned to its previous operational state, and the table is updated appropriately.

Anonoperative state716 may be entered from any of the active states, including thepowered state708, the therapy state710, thefault state712, or thealarm state714. Thenonoperative state716 corresponds to the server being unable to determine if the medical device is active, or what state the medical device is in. Thenonoperative state716 indicates to a user of the medical device server that attention to that medical device may be needed so as to properly associate the medical device to the medical device server.

If the medical device runs out of a drug or detects a dangerous condition of the patient, the device will communicate an alarm message to the server, which will associate the medical device with thealarm state714. When the device completes delivering the therapy, it sends a message to the server that delivery of the therapy is complete, and the server associates the medical device with thepowered state708. A caregiver may then turn off the medical device, and prior to shutting down the device sends a message to the server, which in turn associates the medical device with the knownstate704.

FIG. 8 displays a diagram of anexemplary communications system800 incorporating a medical device server and a medical device. Thecommunications system800 is configured for receipt, processing, and storage of input messages from external devices, such as medical devices. In one embodiment thecommunications system800 uses a metadata-based communications protocol, such as the SOAP protocol. In such a system, the medical device server uses message schema files to validate messages received from medical devices.

Thecommunications system800 is configured such that messages sent from amedical device802 are received by amedical device server804, which includes adevice server object806,message handlers808, and adata tier810. Themedical device802 can be any of a number of medical devices capable of communication with a medical device server. Various embodiments of the medical device are described above in conjunction withFIG. 2.

Themedical device server804 can be any of a number of generalized computing systems configured to collect information from medical devices and assist with medical device setup and monitoring. Themedical device server804 contains adevice server object806, which handles messages sent and received from the medical device server, and parses the messages to determine that they include required information for the medical device server to act on the message. For example, the device server object can parse various metadata tags contained in the message, as well as data associated with that metadata, to verify the message type, source or destination device identification or network identification, and message data. Other components of the message may be determined as well.

Exemplary message contents describe various features of thedevice server object806, as well as for the various device handlers incorporated into the system. A sample device server object definition can read as follows:


<Feature>
<Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id>
<LicenseId>XXXXXXXX-XXXX-XXXX-XXXX-
XXXXXXXXXXXX</LicenseId>
<Name>Medical Device Secured Server</Name>
<Provider>MedicalDeviceServer.MedicalDeviceSoapTcpServer,
MedicalDeviceServer.MedicalDeviceSoapTcpServer.-
MedicalDeviceSoapSecureTcpServer</Provider>
<Description>Receives inbound connection over SSL secured
TCP/IP networks.</Description>
<Type>Server</Type>
</Feature>

In this example, the Feature tag defines the object as a feature of the device server object. The Id tag defines the GUID, or statistically unique number used to identify the feature. The LicenseID tag identifies the license containing the features defined. The Name tag provides the name of the feature. The Provider, Description, and Type tags define the various implementation details of the object. Additional implementation details may be included as well.

One ormore message handlers808 receive the message in its original format from thedevice server object806, and process the message in a manner to convert the message to a format understandable to and stored by thedata tier810 of themedical device server804. The various handlers are assigned messages based on the type of message received, with each handler processing a specific type of messages in a given way. In one embodiment, the message handlers include an alarm handler, a fault handler, a maintenance handler, a power handler, a request handler, various telemetry handlers, and various therapy handlers. Additional or fewer handlers are possible, based on the variety of types of messages managed by themedical device server804.

A second exemplary server object definition describes various features of a message handler808:


< Feature >
<Id>XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX</Id>
<LicenseId>XXXXXXXX-XXXX-XXXX-XXXX-
XXXXXXXXXXXX</LicenseId>
<Name>Medical Device Event Handler</Name>
<Provider>Informatics.BackOffice.MedicalDeviceServer</Provider>
<Description>Validates received events and stores them in the
Operations database</Description>
<Type>Handler</Type>
</Feature>

The example for themessage handler808 is analogous to that describing thedevice server object806, but defined using a Provider tag indicating that the metadata defines a handler configured to define a feature. Themessage handler808 can be associated with thedevice server object806 using the following code:


	<Handler>
	. . .
	<FeatureId>XXXXXXXXXXXXX-XXXX-XXXX-
	XXXXXXXXXXXX</FeatureId>
	<HandlerId>XXXXXXXX-XXXX-XXXX-XXXX-
	XXXXXXXXXXXX</HandlerId>
	. . .
	</Handler>

By tying afeature806 to ahandler808, themedical device server804 can route specific types of data to the appropriate handler.

Adata tier810 receives messages from themessage handlers808 for storage, and also responds to requests for data by providing data to the requestingmessage handler808 for formation into a SOAP-based message or transmission to the medical device via thedevice server object806.

A. Metadata Programming and Communication

Referring now toFIGS. 9-16, a programming schema is disclosed which lists metadata used to define the operational characteristics of a variety of medical devices. The metadata also allows the medical device server to communicate with a wide variety of medical devices, such as medical infusion pumps or other therapy delivery or monitoring equipment. By defining medical devices in the medical device server in terms of their operational characteristics rather than specific proprietary interfaces, the medical device server need not understand the inner workings of each type of medical device. Rather, the server will understand how to communicate with the medical device based on expected operation of that device. In general, the metadata schema disclosed operates using the XML protocol, and a SOAP based messaging system as described above inFIG. 8. However, other standardized communication methodologies could be used as well.

FIG. 9 shows systems and methods for communication between a medical device and a medical device server. Thesystem900 shown is configured to provide extensibility to a variety of types and brands of medical devices, as described above inFIG. 2. The medical device server can communicate with the medical device by defining a predetermined set of metadata and associated parameters for each medical device. Thesystem900 instantiates at astart operation902, which corresponds to communicatively connecting a medical device to a medical device server. In one embodiment, the communicative connection corresponds to introducing the medical device into a medical device network including a medical device server, such as the network shown inFIG. 1. In a further embodiment, the communicative connection corresponds to installation of a corresponding metadata package onto the medical device, using software for installing a metadata communication layer provided in a software development kit or otherwise provided as consistent with the present disclosure.

Anassociation module904 associates metadata with various medical devices in a database of a medical device server. The medical devices store corresponding metadata, so that the associated metadata corresponds to the metadata set on the device. The metadata corresponds to at least one attribute or operational characteristic common to the medical devices, and can be used to distinguish among, identify, and communicate with the various medical devices in the medical device network. In various possible embodiments, operational characteristics defined by the metadata include patient information, user or caregiver information, control information, drug information, or location information. Additional operational characteristics can be included as well, such as those described in one or more of the schema ofFIGS. 11-16. The metadata also corresponds to various events occurring in the medical device, such as power events, alarm events, maintenance events, telemetry events, therapy events, therapy change events, or other events. Additional events are described below inFIGS. 17-33.

Astorage module906 stores the metadata on a medical device server or back office components. The medical device server is configured to communicate with each of the medical devices by using the metadata and the metadata-based messaging systems described above in conjunction withFIG. 8. Operational flow proceeds to anend operation908, which corresponds to completion of establishing the communication schema between the medical device and medical device server.

FIG. 10 shows further systems and methods for communication between a medical device and a medical device server. Thesystem1000 ofFIG. 10 stores metadata common to all medical devices in the medical device networks, and also stores information specific to a subset of the medical devices as well, allowing for customized communications between those medical devices and the medical device server. Operational flow of thesystem1000 commences at astart operation1002, which again corresponds to communicatively connecting a medical device to a medical device server in a medical device network.

Following thestart operation1002, operational flow proceeds to ageneral association module1004. The general association module corresponds to theassociation module904 ofFIG. 9, in that it associates metadata defining the characteristics of each medical device in the medical device network by defining a predetermined set of metadata and associated parameters for each medical device. Acustom metadata module1006 associates metadata with one or more medical devices, the metadata being specific to that device. Examples of custom metadata include specific power events occurring in a particular type of medical device, specialized communication types supported by those devices, or other operational parameters which are defined for less than all of the devices included in a medical device network. Astorage module1008 generally corresponds to thestorage module906 ofFIG. 9, and stores the general metadata and the custom metadata on the server.

Adevice selection module1010 selects one or more of the medical devices in the medical device network to communicate with, based on the metadata defining that device stored in the medical device server. In one embodiment, the device selection module executes upon receiving a message from the medical device(s). In a further embodiment, the medical device server selects and communicates with one or more medical devices without receiving a previous signaling communication from one of the medical devices.

Acommunication module1012 transmits a message to the selected medical device determined in thedevice selection module1010. The communication module forms a SOAP-based message for transmission to the medical device, including destination information identifying the medical device as well as the data to be transmitted to the medical device. The message includes various information identified by the metadata tags defined in the schema understood by thesystem1000, such as those described inFIGS. 11-16 and19-24, below. Operational flow terminates at anend operation1014, which corresponds to completion of transmission of the message to the medical device.

FIGS. 11-16 show various schema including metadata useable to facilitate extensible communication systems for medical devices and medical device servers. The schema are used in the medical device network ofFIG. 1 to identify a variety of medical devices to a medical device server, and to allow the medical device server to communicate with the devices. The schema include metadata related to various operational parameters, or attributes, common to all of the medical devices in the network or specialized to one or more of the medical devices. By using the various schema disclosed, a medical device server can identify a medical device, identify the characteristics of the device, and know how to interoperate with the device by (1) knowing the device's capabilities and limits and (2) sharing an extensible communications protocol with other medical devices.

FIG. 11 shows anidentity schema1100 used to identify various operational characteristics of each of the medical devices communicatively associated with a medical device server. Theidentity schema1100 includes a main table1102 including a variety of global parameters, as well as a network table1104, an access table1106, and one or more package tables1108. The main table1102 includes metadata associated with a variety of generalized device identification characteristics, including device type, device identifier, session identifier, network identifier, access identifier, and package acceptance. The device type relates to identification of the type of the medical device such as the manufacturer and model of the device, while the device identifier is unique to each device. The session, network, and access identifiers define the connection string to allow the message to be routed correctly to the medical device. The package identifier indicates whether the medical device is configured to receive packages from the medical device server, and can link to tables indicating the current packages enabled on each device.

The remaining tables, including the network table1104, access table1106, and package tables1108 provide additional information related to connection and capabilities of the medical device, and are linked to the main table by the network identifier, access identifier, and package identifier in the main table1102. The network table1104 includes the host, domain, IP address, and port information necessary to define a connection to the medical device over an Internet connection. The access table1106 includes an IP address and Physical Id corresponding to the specific networking connection corresponding to the physical device to the IP address. The package tables1108 describe additional details of the software or firmware package in use by the medical device, such as the name and version of the software package. Additional details regarding package deployment to medical devices are described below in conjunction withFIGS. 25-33.

FIG. 12 shows a control table1200 which includes elements describing the logistics of sending messages and tracking those elements between the medical device and medical device server. The control table1200 shown includes message identifier, timestamp, and response metadata. The message identifier provides an identification string used to track the message, and corresponds to the identity of the medical device. The timestamp indicates a time at which the message is sent from the medical device server or medical device. The response provides a Boolean indication of whether the message is originating from a medical device or is a response from the server. Additional metadata related to message tracking can be included in the control table as well.

FIG. 13 shows a patient table1300 used to track patient information for association with the medical device. The patient table1300 includes an identifier and a name element. The name element holds metadata related to the patient's name, and the identifier associates to a statistically unique identifier for association with that patient. Other patient-related metadata can be included as well.

FIG. 14 shows a location table1400 used to indicate the location of a patient. The location table1400 includes metadata defining an alias element and a description element. The description element refers to a linguistic description of the location of a patient, such as “Hospital X, Neonatology,Room1” or some similar entry. The alias element provides a shorthand code used to associate the location with the medical device. Additional metadata describing the location of a patient or medical device can be included in the location table1400 as well.

FIG. 15 shows a drug table1500 used to indicate the drug, if any, associated with the medical device. The drug table1500 may or may not be populated for each medical device, due to the fact that only some medical devices are capable of delivering drug-based therapies to a patient. The drug table includes metadata related to a drug identifier, a drug name, and a drug concentration. Additional metadata entries can be used to further identify or describe the drug in use by the medical device.

FIG. 16 shows a user table1600 corresponding to a doctor, nurse, or other caregiver currently controlling the medical device. The user table1600 includes metadata related to a user identifier and user name, as well as any additional identifying characteristics of the user necessary for operation of the system.

B. Event Logging and Maintenance

Now referring toFIGS. 17-24, systems, methods, and schema are disclosed which are used in the medical device network ofFIG. 1 to track event and maintenance information for the various medical devices associated with the medical device server. These event-based schema can be used to track current and historical performance of the medical devices in the medical device network, as well as to maintain the medical devices. The schema described below define both a messaging system and an ordering of event or operational data stored by a medical device server or other back office components of a medical device network. The event logging and maintenance tracking schema define specific events or tasks occurring in the medical device network, as compared to the schema described in part II.A, above, which relate to relatively constant operational characteristics of the medical devices or server.

FIG. 17 shows methods and systems for receiving event log results from the medical device server or back office components using the various event-based message schema disclosed inFIGS. 19-24. Thesystem1700 generally executes on a medical device server or other back office components of a medical device network, and provides event log data stored in one or more databases managed by those components to a caregiver or other user.

Operational flow in thesystem1700 commences at astart operation1702, which corresponds to initial operation of the medical device network. Operational flow proceeds to anevent receipt module1704, which receives event log data from the various medical devices associated with the medical device server. The event log data represents events occurring in the medical devices, and can be any of a number of types of events, such as power events, telemetry events, alarm events, therapy events, maintenance events, or other events such as those defined in the schema ofFIGS. 19-24.

A sample message body illustrates communication of an event from a medical device to the medical device server, such as is received by theevent receipt module1704. In the example, the medical device is a medical infusion pump that is sending a power event to the medical device server, indicating that the pump has been turned on:


<env:Body><mds:PowerEvent xmlns:mds=‘mds:xml-schema:soap11’>
<Trigger>on</Trigger>
<Message>Normal Power Up Complete</Message>
<Timestamp>1900-01-01T00:00:08</Timestamp>
<Medfusion4000_Power>
<Source>AC</Source>
<Capacity>90.0%</Capacity>
</Medfusion4000_Power>
</mds:PowerEvent></env:Body>

This message portion identifies that this is the body of the message, and that it uses the SOAP 1.1 messaging protocol. The message transmitted from the pump indicates that power up process has been completed, and includes a timestamp assigned by the pump. The various power parameters correspond to those parameters included in the power event table ofFIG. 19, below, and are associated with specific values by the medical infusion pump. The message is received from the medical infusion pump by the medical device server, and the values are stored in appropriate database tables corresponding to the power event schema.

Analogous messages are sent from the medical device to the medical device server, and responses are sent from the server back to the medical device, as related to the other types of events tracked in the medical device network, as described herein.

Astorage module1706 stores the event log data in a database associated with the correct metadata as defined in the message from the medical device to the server. In one embodiment, thestorage module1706 stores event log data in theevent data318 ofFIGS. 3-4.

Arequest receipt module1708 receives a request for a subset of the event log data stored in the medical device server or other back office components. The request received may come from a workstation, portable computing device, or other type of computing system. The request includes one or more narrowing parameters such as a date range, a caregiver name or identifier, a patient name or identifier, a drug name or identifier, a specific device, or other types of information associated with the event log data. In one example, therequest receipt module1708 receives a request for event log data related to delivery of a specific drug by a medical infusion pump.

Aresult generation module1710 generates results based on the specific request received by therequest receipt module1708, such as by filtering event log data held by the medical device server or back office components based on the narrowing parameters of the request. Theresult generation module1710 optionally also transmits the results to the requesting computing system. Using the example described in therequest receipt module1708, the medical device server generates a query configured to return event log data related to delivery of the identified drug by the identified pump. This query can be formed in SQL or some other database querying language, such that the database management system associated with the medical device server returns the query results.

Operational flow terminates at anend operation1712, corresponding to completion of generation and transmission of results to the requesting computing system.

FIG. 18 shows systems and methods for communicating preventative maintenance data to a medical device. Thesystem1800 uses the metadata ofFIGS. 11-16, as well as the additional event metadata ofFIG. 19-24, to track and communicate maintenance tasks to be performed on one or more of the medical devices in a medical device network. The various message transmission principles described in conjunction withFIG. 17 allow the communication to occur.

Thesystem1800 commences at astart operation1802, which corresponds to initial operation of the medical device network. Operational flow proceeds to astorage module1804, which stores a maintenance schedule on the medical device server associated with one or more medical devices. The maintenance schedule is stored in a database of the medical device server or back office components, and includes both a time value for the maintenance reminder events included in the schedule and for the medical device. The maintenance schedule also optionally references maintenance data, such as required operational software updates or various other configuration parameters.

In one example, thestorage module1804 stores a maintenance schedule that includes indications for suggested recalibration of a series of medical infusion pumps periodically, or for a specific medical infusion pump. In such an example, thestorage module1804 can store a maintenance schedule provided by the user or manufacturer of the medical infusion pump to provide reminders to the user of the pump when the indicated maintenance is scheduled.

Atransmission module1806 transmits a reminder to the one or more medical devices associated with the maintenance schedule when a maintenance event occurs. The reminder may be a user-readable message displayed on a display associated with the medical infusion pumps, indicating to the caregiver that recalibration is suggested. Or, the reminder may be a trigger of a user-readable message stored on the medical device.

Thetransmission module1806 also optionally transmits maintenance data associated with the maintenance reminder. In one embodiment of thesystem1800, the reminder sent by thetransmission module1806 disables the medical device. In a further embodiment, the reminder allows the medical device to continue operation. In yet another embodiment, the reminder is transmitted a predetermined time prior to performance of the required maintenance of the medical device.

Continuing the example of the medical infusion pump from thestorage module1804, above, a maintenance event is transmitted to the medical infusion pumps. The maintenance event indicates to a medical device that maintenance of that device is needed, and includes a reminder message displayed on a display device of the medical infusion pump, such as “Maintenance Required—Please Contact Manufacturer”, or some other indication of required maintenance. In certain configurations, the maintenance event allows the medical device to continue operation until a caregiver contacts the manufacturer, who may have specific instructions regarding maintenance and care of the medical device.

Operational flow terminates at anend operation1808, which corresponds to completion of the transmission of a maintenance reminder and any corresponding maintenance data to the medical device.

FIGS. 19-24 show event-based schema for communications and responses between medical devices and a medical device server. The schema disclosed are useable in the medical device network ofFIG. 1 to allow the medical device server and back office components to gather and store event log data, as well as to transmit messages to the medical devices. The medical devices and medical device server of the network transmit messages and event data using the metadata described below to identify the contents of the messages. The medical device server or back office components store the event data in correspondence with the metadata.

FIG. 19 shows a power event table1900 and a power event response table1910. The tables1900,1910 define metadata used to track various power events in a medical device, such as turning the device on, turning the device off, battery warnings, and other power-related events. The power event table1900 includes metadata related to a trigger, a message, and a timestamp. The trigger corresponds to a changed event in the medical device, such as turning the device on, off, or updating the powered status of the device. The message describes the specific event that occurred in the medical device, such as a low battery warning, an occurrence of power on event, an occurrence of a power off event, or some other power-related event. The timestamp indicates the time at which the medical device experienced the power event.

The power event response table1910 includes metadata defining various possible responses to the power events received by the medical device server. For example, when the medical device server receives a power on event, the server may respond that specific maintenance tasks are required, or that software or firmware is available to be downloaded. The power event response table includes result, message, session, interval, and package metadata. The result metadata relates to the result of the power event, such as a changed state of the medical device, or various other server-recognized results of the received event. The message metadata includes a message to be transmitted to the medical device, such as to describe the contents of the response message, for display on a display device associated with the medical device. The session metadata includes information related to the communication session between the device and server. The interval metadata includes information related to the expected interval between communications from the medical device to the server, which is related to server detection of the on-line status of the medical device, described in Part IV, below. The package metadata provides an indication to the device as to whether new package information is available for that device, and which may be delivered via the package deployment methods and systems ofFIGS. 25-33. Additional metadata may be included in the response table1910 and the corresponding response message.

FIG. 20 shows an alarm event table2000 and an alarm event response table2010. Alarm events relate to activation or clearing of an alarm triggered in a medical device, and the corresponding messages generated by the device and communicated to the medical device server. Activation or clearing of an alarm in the medical device may relate to detection of a patient condition detected by the medical device, or may relate to the The alarm event table2000 corresponds to the power event table1900 in that it also includes trigger, message, and timestamp metadata. In the case of the alarm event table2000, the trigger metadata relates to an activate, clear, or update alarm message. The message and timestamp metadata are used analogously to the corresponding fields of the power event table1900.

The alarm event response table2010 corresponds to the power event response table1910. Messages generated using the alarm event response table metadata are communicated to the medical device in response to receipt of an alarm event message. The alarm event response table2010 therefore generally includes a different response than the power event response table1910, and communicates messages, packages or other instructions related to the alarm event.

FIG. 21 shows a maintenance event table2100 and a maintenance event response table2110. Maintenance events correspond to specific reactions of the medical device to an indication that maintenance is required, such as requesting updated operational software, calibration software, or notification messages indicating the maintenance that is required. The maintenance event table2100 corresponds to data received in a message from a medical device ready to perform maintenance in conjunction with the medical device server, for situations in which maintenance requires a software upgrade or some other remotely-controllable maintenance event. The maintenance event table2100 corresponds to the power event table1900 in that it also includes trigger, message, and timestamp metadata. In the case of the maintenance event table2100, the trigger metadata relates to an update or a package applied. The message and timestamp metadata are used analogously to the corresponding fields of the power event table1900.

The maintenance event response table2110 also corresponds to the power event response table1910, and is generated by the medical device server or other back office components. Messages generated using the maintenance event response table metadata are communicated to the medical device in response to receipt of a maintenance event message, and relate to messages, packages or other instructions that occur response to the maintenance event, such as additional details regarding the maintenance required, maintenance schedule information, information to be displayed by the medical device about the maintenance required.

FIG. 22 shows a telemetry event table2200 and a telemetry event response table2210. Telemetry refers to near-continuous streaming of event data from a medical device to the medical device server such that users with access to the medical device server can monitor operation of the medical device remotely in a near real-time fashion. The telemetry event table2200 corresponds to the power event table1900 in that it also includes trigger, message, and timestamp metadata. In the case of the telemetry event table2200, the trigger metadata relates to an update event regarding telemetry received from the medical device. The message and timestamp metadata are used analogously to the corresponding fields of the power event table1900.

The telemetry event response table2210 also corresponds to the power event response table1910, but is generated by the server. Messages generated using the telemetry event response table metadata are communicated to the medical device in response to receipt of a telemetry event message, and communicate messages, packages or other instructions in response to the telemetry event.

FIG. 23 shows a therapy event table2300 and a therapy event response table2310. Therapy events relate generally to the start and stop of therapies or monitoring processes in a medical device. The specific therapy started or stopped depends upon the type of medical device used, and can include monitoring, drug delivery, or other therapies. The therapy event table2300 corresponds to the power event table1900 in that it also includes trigger, message, and timestamp metadata. In the case of the therapy event table2300, the trigger metadata relates to a setup, begin, end or update therapy event as related to initialization or ending of a therapy by a medical device. The message and timestamp metadata are used analogously to the corresponding fields of the power event table1900.

The therapy event response table2310 also corresponds to the power event response table1910, but is generated by the server. Messages generated using the therapy event response table metadata are communicated to the medical device in response to receipt of a therapy event message, and communicate messages, packages or other instructions in response to the therapy event.

FIG. 24 shows a therapy change event table2400 and a therapy change event response table2410. Therapy change events relate generally to changes in therapies operating on a medical device, and are related to therapy events, discussed above. Therapy change events include, for example, changed parameters related to monitoring or delivering of therapies, such as changed drug delivery rates. The therapy change event table2400 corresponds to the power event table1900 in that it also includes trigger, message, and timestamp metadata. In the therapy change event table2400, the trigger metadata relates to an override, warning, abandon, or update event as related to a therapy change. The message and timestamp metadata are used analogously to the corresponding fields of the power event table1900.

The therapy change event response table2410 also corresponds to the power event response table1910, but is generated by the server. Messages generated using the therapy change event response table metadata are communicated to the medical device in response to receipt of a therapy event message, and communicate messages, packages or other instructions in response to the therapy change event.

C. Package Deployment

Referring back toFIG. 11, various systems and methods exist for deploying packages to medical devices from a medical device server. The packages deployed may include firmware upgrades, maintenance information, new or changed parameters for therapies, or other software upgrades or changes to the medical devices in a medical device network. In a possible embodiment, a package can be used to reprogram the medical device to which it is sent with any of the possible types of package data. Medical devices capable of receiving package data indicate this capability in the main table1102 and package tables1108. The main table1102 indicates the capability of the device to receive a package, and the package tables1108 include information related to the current package information stored at the medical device for use in operation of the medical device. Package delivery, as discussed in greater detail below, occurs in response to a message, and is initiated using the package data identifier in the event response tables1910-2410 to indicate to the medical device that a package is available for delivery.

Referring now toFIG. 25, an example structure of apackage2500 used in deployment of information to a medical device is shown. Thepackage2500 includes aserver header2502, avendor header2504, andinformation2506 to be delivered to the medical device. Theserver header2502 is the portion of the package understood by the medical device server. Theserver header2502 is in a common format to all packages, and contains identification information related to the type of device configured to receive the package, as well as the source of the package. Additional information, such as package size, encryption format, or encryption key location information may be included in theserver header2502 as well. In one embodiment, theserver header2502 is a 256 byte block incorporated into the package.

Thevendor header2504 contains vendor specific information related to use of the package within the medical device receiving the package. The vendor providing the package to the medical device server is generally the manufacturer or maintenance company associated with the medical device intended to receive the package, so the vendor will format thevendor header2504 in a manner understandable to the medical devices it manufactures. The vendor header generally includes information related to the size of theinformation2506, as well as the location ofencryption information2508 within the information. Theencryption information2508 can be used by the medical device to decrypt the information, which is generally stored in the medical device server in an encrypted form.

Theinformation2506 generally includes any software to be transferred from the medical device server to a medical device, such as a firmware upgrade, a file including therapy parameters, or other binary data. Thepackage delivery system2500 is not dependent upon the specific format of thevendor header2504 or theinformation2506. Theinformation2506 is generally stored in an encrypted form on the medical device server. When transferred to a medical device, theinformation2506 is decrypted by the medical device by locating theencryption information2508 based on information in thevendor header2504.

FIG. 26 shows systems and methods for deploying package data from a medical device server to medical devices. Thesystem2600 is configured to distribute a package, such as thepackage2500 ofFIG. 5, to a medical device in response to a message received from the medical device.

Operational flow within thesystem2600 commences at astart module2600, which corresponds to receipt of package information from a vendor of a medical device, an administrator of the medical device, or another entity having familiarity with the operation of the medical device. Astorage module2604 stores the received package in the medical device server. Thestorage module2604 can also set an alert or other variable for a medical device such that the next time the medical device communicates with the server, an indication of the existence of the package is included in the response to the medical device. In one embodiment, thestorage module2604 encrypts the package while stored on the medical device server or back office components, and either the medical device server or the medical device itself decrypts the message when the package is to be used or transmitted. In a further embodiment, thestorage module2604 leaves the package unencrypted when it is stored on the medical device server or back office components.

Amessage receipt module2606 receives at the medical device server a message from a medical device. The message may be any of a number of types of messages, such as the power, maintenance, alarm, telemetry, therapy, or therapy change event messages described above inFIGS. 19-24. Additional message types are possible as well.

Anindication module2608 indicates to the medical device that a package is intended for delivery to that device. In one embodiment, theindication module2608 sets a parameter in a message response indicating the existence of a package. For example, theindication module2608 can set a parameter in the package metadata included in the event response messages1910-2410 ofFIGS. 19-24. Additional methods of indicating the existence of a package are possible as well, such as transmission of a specific message related to package deployment, a package request by the medical device, or other methods.

Arequest module2610 receives a request from the medical device to receive the package. Therequest module2610 may include one or more steps of requesting information about the package to verify at the medical device that the package should be accepted. In a possible embodiment, therequest module2610 transmits a package information request message, using metadata as shown inFIG. 27. In such an embodiment, therequest module2610 optionally also transmits a package data request message separate from the package information request message, the package data request message transmitted following receipt of package information describing the package contents from the medical device server. In further embodiments, therequest module2610 receives a request as shown inFIG. 29 or31.

Adelivery module2612 delivers the requested package to the medical device. The format of the package delivery message can be as shown inFIG. 30 or32. Operational flow terminates at anend operation2614, which corresponds to completion of the package transmission to the medical device.

FIGS. 27-32 show schema including metadata used in messages and tables in a medical device network, such as the one shown inFIG. 1, to deploy packages from a medical device server to a medical device. The schema display various request and response scenarios in which a medical device requests delivery of package information and receives the requested information in response. One or more messages may be sent between the medical device and the medical device server prior to delivery of the package and its enclosed data.

FIG. 27 shows a package information request table2700 including metadata used to request information about a package that is available to be deployed to a medical device. The medical device is notified of an available package based on a previous response from the medical device server, as reflecting information in the main table1102 or package tables1108 related to that device in the medical device server. The metadata in the table2700 includes a package identifier, which is used by a medical device to identify the package and request information about its contents. Additional metadata related to the package may be included in the table2700 and message from the medical device as well.

FIG. 28 shows a package information request response table2800 including metadata used in describing a package available to be deployed to a medical device. The metadata in the table2800 includes the package identifier, corresponding to the package identifier in the package information request table2700, and also includes package information metadata. The package information metadata links to a package information table2802, which contains name and version metadata. Values associated with the name and version metadata describe the package, such that the medical device can determine whether to request deployment of the package.

FIG. 29 shows a package data request table2900 including metadata used in requesting package data from a medical device server. The package data request table2900 includes package identifier and response type metadata. The package identifier represents a unique identifier for the package available for deployment to the medical device. The response type represents an identifier indicating the desired delivery format of the package data. In one embodiment, the package data can be delivered to the medical device in either a plain text format or using an xop format.

FIG. 30 shows a package data request response table3000 including metadata used in deploying a package to a medical device. The metadata included in the package data request response table3000 includes a package identifier and a package binary data field. The package identifier identifies the package referred to inFIG. 29, and the package binary data field denotes the binary data representing the package being delivered to the medical device. The package binary data field can optionally link to a separate package binary data table3002 containing the package binary data for delivery to a medical device. In one embodiment, the package delivered to the medical device is thepackage2500 ofFIG. 25.

FIG. 31 shows a package request table3100. The package request table3100 corresponds to the package data request table2900 ofFIG. 29 combined with the package information request table2700 ofFIG. 27. The package request table3100 can be used by the medical device in an instance in which the medical device does not need to validate the package information prior to downloading the package. The package request table3100 includes a package identifier and a response type, similar to the package data request table2900, but indicates by requesting the entire package that package information and package data messages need not be separated.

FIG. 32 shows a package request response table3200, representing the schema of a message from the medical device server sent in response to a message of the form reflected by the package request table3100 ofFIG. 31. The package request response table includes package identifier, package information, and package binary metadata. The package information metadata links to a package information table3202 containing name and version metadata associated to the package data. The package binary metadata links to a package binary table3204, which includes metadata corresponding to the package to be deployed to the medical device.

D. Time Management

Referring now toFIGS. 33-35, systems and methods for time management in a medical device network are shown. Because the medical device network can vary in size or configuration, the time management systems described are configured to extend across various business entities, various locations, and various time zones. The systems and methods described provide a uniform way to synchronize time tracking in medical devices and a medical device server located in one or more locations or time zones.

FIG. 33 shows atime messaging schema3300 useable to track medical device time at the medical device server, and also transmit time synchronization messages between a medical device and a medical device server. Thetime schema3300 includes a time request table3302, a time request response table3304, and a system time table3306. The time request table3302 optionally includes no metadata, but represents a time request response sent from a medical device to the medical device server for synchronization of the medical device time with the time stored in the server or back office components. The time request response table3304 includes system time metadata, associated with the system time value stored on the medical device server. The system time metadata optionally links to a system time table3306, which contains a time value useable to synchronize the time of the medical device with the time received from the medical device server. Additional metadata or other information useable to assist in time synchronization can be used as well.

FIG. 34 shows methods and systems for time synchronization of medical devices and a medical device server within a medical device network. Operational flow in thesystem3400 commences at astart operation3402, corresponding to initial operation of the medical device network. A servertime maintenance module3404 maintains a global time value in the server that is to be used to synchronize the time values of the medical devices communicatively connected thereto.

A servertime transmission module3406 transmits the server time to one or more medical devices in the medical device network. In one embodiment, the servertime transmission module3406 transmits the server time value to a medical device in response to a request message from that medical device. In such an embodiment, the request message may be of a form shown in the time request table3302 ofFIG. 33, above.

In a further embodiment, thetransmission module3406 converts the server time value to a localized server time value based on the time zone of the location of the medical device. This conversion may take place if the server resides in a different time zone from the medical device. The server and medical device thereby have a synchronized time value that is converted to the appropriate time zone. One possible implementation of this embodiment converts all times to the Universal Time Protocol upon transmission from the server, and the destination medical device reconverts the time value to the local time of that destination device's location. Other time zone conversions, such as from the local time of the medical device server to the local time of the medical device, are possible as well.

Areplacement module3408 replaces the device time in the medical device with the server time value received from the medical device server. Thereplacement module3408 uses the time-adjusted server time value, configured to be used at the location of the medical device. Anoptional confirmation module3410 sends a confirmation message to the medical device server indicating that the medical device is successfully synchronized to the server, allowing the server to track which medical devices have been successfully synchronized with the server. Operational flow terminates at anend operation3412, corresponding to completion of the time synchronization process.

Referring now toFIG. 35, methods and systems for synchronizing event log data are disclosed. Thesystem3500 accommodates event log data received from medical devices located in different locations in a plurality of time zones. The event log data is configured such that the local time stamp of the event log data represents the time zone in which that device resides, so event logs from different time zones having the same time stamp in actuality occurred at different times. Thesystem3500 compensates for this discrepancy when storing event log data, and also when providing it to users for review. Operational flow within thesystem3500 commences at astart operation3502, corresponding to initial communication of event data from medical devices to the medical device server.

Areceipt module3504 corresponds to the medical device server receiving event log data from one or more of the medical devices. As described above, the event log data includes various details regarding various types of events, such as therapy events, alarm events, maintenance events, telemetry events, or other types of events, each of which are associated with a time stamp reflecting the current time value of the medical device, reflecting the local time zone of that device. A timezone modification module3506 converts the time stamp information from the local time zone of the medical device to a constant time zone. In one embodiment, the timezone modification module3506 converts the time stamp to the Universal Time Protocol (UTP). Astorage module3508 stores the converted time stamp and associated event log data in the medical device server or back office components.

An optionalglobal tracking module3510 tracks global events using the uniform time zone information. For example, a user desiring to track events that occur at single instantaneous moment across all time zones can track global events using the Universal Time Protocol to maintain a standard time across all time zones. The user sends a request for event log data related to the global events stored on the server, and receives event log information with a time stamp having constant time zone information.

A requestlocal event module3512 receives a request for local event data, including types of event data associated with the time zone in which the event occurs. Examples of time zone specific events can include events timed to occur at the beginning or end of a shift at a hospital, or other local events. The requestlocal event module3512 generates a query for the event data requested, and returns results including event log data. Aconversion module3514 converts the uniform time zone information to local time zone information based on the location of the medical device from which the event log data was recorded. Theconversion module3514 optionally generates a report from the event log data for distributing to a requesting user, including the compensated local time event log. Operational flow within thesystem3500 is terminated at anend operation3516, which corresponds to completion of theconversion module3514.

IV. Remote User to Server Communication

Referring now toFIGS. 36-66, a generalized web service architecture is disclosed which manages user access to a medical device server in a medical device network, such as the one shown inFIG. 1. The web service architecture allows remote user to server communication, to provide data access and programming capabilities related to medical devices in the medical device network ofFIG. 1. For example, users can perform administrative tasks, administer software updates to medical devices, access event and operational records, perform maintenance, change therapies, and view near real-time operation of the medical devices while remotely located from the devices. These functions, and others, are described below.

FIG. 36 shows an overallweb service architecture3600, shown as a subsystem of the possible software architectures of the medical device network inFIGS. 3-4. The web service architecture includes various web modules or services configured to validate users and provide access to data stored on the medical device server. In a possible embodiment, the web service architecture is implemented in a .NET architecture using Internet Information Server, by Microsoft Corporation.

Theweb service architecture3600 includes anadministrative web service3602, anoperations web service3604, and an event trackingweb service3606. Theadministrative web service3602 validates users of the medical device server, and includes functional interfaces for logging in, logging out, and changing a user password. Theadministrative web service3602 tracks information related to products, customers, contact information, medical devices associated with the customers, user accounts associated with a customer, and other variables. Theadministrative web service3602 uses this tracked information to validate specific users, each of whom is associated with a specific health care facility, referred to in the administrative web service as a customer. A specific implementation class of theadministrative web service3602 is described in Part IV.A, below.

Theoperations web service3604 provides access to operational data of the medical devices, such as operational data regarding therapy delivery or monitoring data. Theoperations web service3604 tracks the various therapy states occurring in a medical device, and enables a messaging sequence that can occur to trigger or track a therapy event in a medical device. A specific implementation of theoperations web service3604 is described in Part IV.B, below.

The event trackingweb service3606 tracks various event data occurring in a medical device, such as telemetry data received by a medical device server. The event trackingweb service3606 enables users to view near-real time activity of a medical device while located remote from the medical device, and allows the user to determine the on-line status of the medical device. A specific implementation of the event trackingweb service3606 is described in Part IV.C, below.

A. Administration

Referring now toFIGS. 37-41, systems and reports for definition and use of an administrative web service are shown.FIG. 37 shows an exemplary class structure defining anadministrative web service3700. Theadministrative web service3700 provides a possible embodiment of theadministrative web service3602 ofFIG. 36, and is accessible via any of a number of user interfaces, such as the administration web forms324 ofFIG. 3. Theadministrative web service3700 includes anauthentication class3702, anauthorization class3704, auser class3706, arole class3708, alicense class3710, aresource class3712, ametadata class3714, and anentity settings class3716. Each of the classes includes a number of functions remotely accessible via the internet and web-based user interfaces to perform administrative tasks. Functionality of the various classes is described below.

Theauthentication class3702 provides the initial access to theadministrative web service3700, and includes login and logout functionality. Theauthorization class3704 includes a variety of resource control functions to ensure that two users are not reading from and writing to the same data concurrently, or otherwise causing data conflicts. The resource control functions incorporated into theauthorization class3704 include read, write, create, delete, and access permission functions. Other functions may be incorporated into theauthorization class3704 as well.

Each of the other classes link to theauthorization class3704, and each requests read or write access to the data protected by theauthorization class3704. Theuser class3706 allows the system to perform various user administration tasks, such as creating new users, editing user information, changing passwords, deleting users, defining user roles, and retrieving user histories. Other functions are possible as well. Therole class3708 defines roles assignable to users, and includes the ability to create, update, delete or retrieve various roles defined in the administration data. Roles may correspond to various classes of individuals who can access data managed by the medical device server and back office components, such as doctors, nurses, or healthcare administrators. Roles may also correspond to the various entities with which the individuals are associated.

Thelicense class3710 defines licenses installed into the system to control the number of users able to log in at once, as well as to define usage models for various accounts. For example, a particular account may allow only a limited number of individuals to view telemetry data or to access therapy records at once, or may define a way of charging a customer for tracked usage of the medical device server or other back office components.

Theresource class3712 allows an administrator to add and delete resources, which correspond to the specific functional areas of the medical device server. Themetadata class3714 provides the underlying functionality for installing metadata into either the administration system, such as custom metadata corresponding to a newly introduced medical device, or into a newly introduced medical device itself. Exemplary interfaces for installation of metadata are shown below inFIGS. 42-43. Theentity settings class3716 allows writing and retrieval of entity settings. Additional administrative functionality, including additional classes, may be incorporated into theadministrative web service3700 as well.

FIGS. 38-41 display sample administrative reports accessible to a user. The administrative reports ofFIGS. 38-41 correspond to thereports326 shown inFIGS. 3-4, and are derived from information stored in the data warehouse322 related to administrative events logged by the medical device server. In a possible embodiment of the present disclosure, the various reports are generated using SQL Server Reporting Services, by Microsoft Corporation. Other reporting and business intelligence software may be used as well.

FIG. 38 displays an administrationtracking event report3800. The administration tracking event report displays detailed information regarding administration events, such as user access and connection to the medical device server. The number and contents of entries in the report correspond to data from theadministration data316 ofFIG. 3 that match the query presented to the administrative web service. The administration tracking event report includes time anddate information3802,application information3804, andmessage information3806. Additional information, such as the code information, time zone indicator, and other information can be optionally included in thereport3800.

The time anddate information3802 display the time stamp information related to the event tracked by the administrative module. The time anddate information3802 display on the report in varying formats, depending upon whether a user chooses a local time zone option or a GMT normalized time option. In thereport3800 shown, the local time zone option is selected.

Theapplication information3804 indicates the service or handler accessed, and themessage3806 indicates the action taken with respect to that service or handler. In the example shown, exemplary connection events are shown for two medical device servers, labeled “MDS:Mds01” and “MDS:Mds02”.

FIG. 39 displays asecurity event report3900. Thesecurity event report3900 corresponds generally to the administrationtracking event report3800, but includes events related to security of the medical device server rather than access to it. Thesecurity event report3900 includes time anddate information3902,application information3904, andmessage information3906, each of which have the same functionality as in the administrationtracking event report3800.

FIG. 40 displays a securityevent trending report4000. The securityevent trending report4000 displays a chart of security related events over time. In the embodiment shown, the securityevent trending report4000 displays a bar chart showing the frequency of security events by month. Other configurations displaying trends in security events are possible as well.

FIG. 41 displays auser history report4100. The user history report displays a chronologically ordered list of events logged regarding one or more users. Each entry in the list includes time anddate information4102, asorting code4104, ausername4106 corresponding to the active user, and amessage4108 related to the action taken by that user. Anoptional details entry4110 displays additional information associated with the history information, in raw form, such as the session key, location, name, location, or other activities occurring in the user history.

1. Metadata and Package Deployment Interfaces

Referring now toFIGS. 42-50, various methods of programming the medical device server and medical device with metadata, firmware, or other binary data are shown.FIGS. 42-46 display administrative forms useable to perform various administrative tasks in the medical device server, such as providing or removing metadata or packages, intended for configuration of the medical device server or medical devices, respectively. The administrative forms can correspond to forms generated by theadministrative applications324 ofFIGS. 3-4.FIGS. 47-50 display reports displaying the results of installation of the metadata and packages, and are a subset of thereports326 available from the data warehouse322 inFIGS. 3-4.

FIGS. 42-43 display user interfaces configured to allow an administrative user to manage metadata installed into the medical device server, as described above in Parts III.A and III.B.FIG. 42 shows aninitial user interface4200 showing the metadata packages either currently installed into the medical device server or available to be installed. Alisting area4202 lists the packages, in this case displayed as “Virtual Infusion Pump”, “Virtual Patient Monitor”, and “Medfusion4000”. Checkboxes4204 in the listing area allow user selection of one or more of the installed packages, an installbutton4206 installs the packages into the medical device server, and anuninstall button4208 removes metadata packages from the medical device server.

FIG. 43 displays ametadata installation interface4300 configured to allow a user to browse for a metadata file and install that file onto the medical device server. Themetadata installation interface4300 appears following selection of one of the types of medical devices present in the system in theuser interface4200, and allows the user to select and install a metadata file associated with the previous selection of metadata using theinitial user interface4200.

FIG. 44 displays apackage deployment interface4400 providing deployment of packages for distribution to one or more medical devices, as described above in Part III.C. Thepackage deployment interface4400 generally corresponds to themetadata installation interface4200 ofFIG. 42, but relates to software to be installed onto a medical device, rather than into the medical device server. Alisting area4402 lists the packages, in this case displayed as “Simple Infusion Pump” or “TestPackage”. Checkboxes4404 in the listing area allow user selection of one or more of the installed packages, a deploybutton4406 deploys the packages into the medical device server, and anuninstall button4408 removes the packages from the medical device server.

Upon selection of the deploybutton4406, auser interface4500 shown inFIG. 45 is displayed. Theuser interface4500 allows system administrators to enter a package deployment name into aname field4502, and also allows the administrator to enter a start time and end time, into start and

end fields

4504,4506, respectively. The user interface further allows the system administrator to select a package deployment file to use in a package deploymentfile selection field4508. The system administration presses a deploybutton4510 to deploy the package, or a cancelbutton4512 to cancel deployment.

Upon selection of the deploybutton4510, afurther user interface4600 shown inFIG. 46 is displayed to allow user verification that the correct package has been selected for download to medical devices. Theuser interface4600 displays package deployment details in apackage information field4502, including the selected start time, end time, and target type as entered in the

previous user interfaces

4400,4500. Theuser interface4600 further displays vendor properties in avendor field4504, such as the vendor identifier, name, and version of the vendor package.

FIGS. 47-50 display various reports generated from the data warehouse322 ofFIGS. 3-4, as related to metadata-defined event messages or package deployment.FIG. 47-48 relate to message handling and debugging of faulty messages received from a medical device.FIGS. 49-50 display package deployment reports, incorporating records of successful and unsuccessful deployment of software or other binary data to medical devices.

FIG. 47 displays aquarantine report4700, which displays a chronological list of the quarantined messages received by the medical device server. Thequarantine report4700 includes time anddate information4702,state information4704, andmessage information4706. The time anddate information4702 display the time stamp information related to the quarantine event tracked by the medical device server. The time anddate information4702 display on the report in varying formats, depending upon whether a user chooses a local time zone option or a GMT normalized time option. In thereport4700 shown, the local time zone option is selected.

Thestate information4704 relates to the state of the quarantined message, such as whether it is a new message, a released message, or a reinserted message. New messages refer to newly located problematic messages, while released messages correspond to messages which cannot be resolved and must be dropped. Reinserted messages refer to those messages which are reintroduced to the message server in case the medical device is awaiting a response from the server.

Themessage information4706 describes the error occurring in the message transfer. Various error messages are possible, generally relating to the ability of the medical device server to understand the message received from a medical device.

FIG. 48 displays aquarantine detail report4800, which is configured to display the details of a specific quarantined message received by the medical device server. The quarantine detail report includes anerror field4802 including the error information displayed on thequarantine report4700, and asource field4804 which displays the metadata and values included in the message, for user debugging or correction of message activity in the medical device server. Additional information can be displayed regarding the quarantined message as well.

FIG. 49 displays apackage deployment report4900 showing package deployments known to the medical device server, with an associated list of medical devices of various types and the status of the package deployment to each of the medical devices. The package deployment report includes one or morepackage deployment entries4902, each including name and version information related to the specific package being deployed to that type of device. Each of the package entries includesdevice sub-entries4904, each of which relates to a specific device qualifying for the generalized package deployment. The sub-entries each includehost name information4906,physical identification information4908,notification information4910, transferinformation4912, andcompletion information4914. Thehost name information4906 corresponds to the medical device server providing the package to the device. Thephysical identification information4908 displays the unique identifier associated with the medical device. Thenotification information4910 displays the date and time at which the medical device was notified that the package was available. Thetransfer information4912 displays the date and time at which the package was successfully transferred to the medical device. Thecompletion information4914 displays the full date and time at which the package was successfully applied to the medical device.

Additional information can be tracked for each package deployment. For example, in an instance in which a package fails to deploy, anerror indication4916 displays an indication of an error, and a result of the error.

FIG. 50 displays a packagedeployment error report5000. The packagedeployment error report5000 provides a detailed event history for the specific packages and corresponding devices for which a package deployment fails. The packagedeployment error report5000 displays atitle5002 including the target medical device type and package identifier. The title also optionally displays a name associated with the package deployment.

The packagedeployment error report5000 displays time anddate information5004,optional host information5006,physical identifier information5008, andmessage information5010. The time anddate information5004 indicate when the error in the package deployment occurred. The optionalhost name information5006 displays the network name in which the medical device is located. Thephysical identifier information5008 includes the identifier associated with the medical device. Themessage information5010 displays the message associated with the package deployment error. Additional information regarding the deployment error may be included in thereport5000 as well.

2. Maintenance/Faults

Referring now toFIGS. 51-53, reports related to maintenance and faults of medical devices are shown. The reports provide user access to records of maintenance performed on the medical devices as well as information related to medical device failures and trends in those failures. Additional reports related to maintenance or faults may be incorporated as well, and correspond to the maintenance event data collected by the medical device server, as described above in Part III.B. In a possible embodiment, one or more of the reports ofFIGS. 51-53 correspond to the maintenance forms330 ofFIGS. 3-4.

FIG. 51 shows a medicaldevice maintenance report5100 listing maintenance records for various medical devices. The medicaldevice maintenance report5100 includestype entries5102 corresponding to various types of medical devices, anddevice sub-entries5104 corresponding to specific medical devices. In the embodiment shown, thetype entries5102 are the “MedFusion4000” and “Titan” entries, while thedevice sub-entries5104 are the individual rows within each type.

Within each sub-entry5104, there existshost name information5106,physical identifier information5108,version information5110,package information5112, and preventativemaintenance date information5114. Thehost information5106 displays the network associated with the medical device. Thephysical identifier5108 displays the unique identifier associated with the medical device. Theversion information5110 displays one or more version numbers associated with the medical device. Thepackage information5112 displays packages being used by the medical device. Thepreventative maintenance information5114 displays a date at which the medical device is due for preventative maintenance. Additional information can be displayed within each sub-entry5104 as well.

FIG. 52 shows a medicaldevice fault report5200. The medicaldevice fault report5200 displays events related to medical device faults communicated to a medical device server, such as due to a faulty battery, motor, or other mechanical component. The medicaldevice fault report5200 includes time anddate information5202,host information5204,physical identifier information5206, andmessage information5208. Use of the information5202-5208 is analogous to the corresponding elements in the packagedeployment error report5000 ofFIG. 50, but related to medical device fault events. For example, in the medicaldevice fault report5200, the message information includes device fault event information, such as motor, battery, or other mechanical faults of a medical device.

FIG. 53 shows a medical devicefault trending report5300. The medical devicefault trending report5300 displays a chart of medical device fault related events over time. The medical devicefault trending report5300 provides users with an indication of repeated errors in a medical device, or other detectable trends in medical device faults. In the embodiment shown, the medical devicefault trending report5300 displays a bar chart showing the frequency of device fault events by month. Other configurations displaying trends in device fault events are possible as well.

B. Operations Web Service: Operation and Control of Therapy States

FIGS. 54-62 disclose various aspects of theoperations web service3604 ofFIG. 36. Specifically, the figures show systems, methods, and reports for remote operation of the medical devices in a medical device network. In one possible embodiment, the systems and methods describe tracking of changed therapy parameters in a medical device by tracking original, updated, and final parameters of the medical device.

FIG. 54 shows a flowchart of methods and systems for tracking therapy order states in a medical device server. Therapy orders refer to commands to a medical device to provide a therapy to a patient. Thesystem5400 includes states corresponding to the various possible states experienced in the medical device during execution of the therapy order.

Operational flow within thesystem5400 commences at astart node5402, which corresponds to introduction of a new therapy order into the medical device or medical device server. Once the therapy order is introduced, thesystem5400 enters anew state5404, indicating that the therapy order is newly introduced and has not yet been executed by the medical device. When thesystem5400 is in thenew state5404, a user has the option to cancel the therapy order. If the user chooses to cancel the therapy order, operational flow in thesystem5400 proceeds to a canceled state.5406. From the canceled state, operational flow proceeds to anend node5408 corresponding to completion of the therapy module. At theend node5408, operational flow terminates and therapy delivery events tracked using the medical device server continue to be stored for review by a user.

If the user chooses not to cancel the therapy order while thesystem5400 is in the new state, operational flow proceeds to an assistedsetup state5410. The assistedsetup state5410 attempts to assist in setting up the therapy parameters. If the assisted setup is unsuccessful operational flow branches to a failedstate5412. The failedstate5412 stores an error message indicating that the assisted setup process failed. Operational flow proceeds from the failedstate5412 to theend node5408.

If the assistedsetup state5410 is successful in setting up therapy parameters, operational flow branches to asetup state5414. Thesetup state5414 indicates that the therapy is successfully set up in the medical device, and is ready for delivery to a patient.

A begin therapy event, optionally sent from the medical device server or generated at the medical device, triggers thesystem5400 to proceed to a startedstate5416, which corresponds to starting the therapy delivery in the medical device. An end therapy event received from the medical device or medical device server causes operational flow in thesystem5400 to proceed to acomplete state5418, indicating that delivery of the therapy is complete. Operational flow next proceeds to theend node5408.

FIG. 55 shows an exemplary class structure defining atherapy service5500. Thetherapy service5500 illustrates a portion of the functionality of the operationsweb service module3604. Thetherapy service5500 links to and uses a variety of functions from theadministrative web service3700 ofFIG. 37.

Thetherapy service5500 includes atherapy order class5502, a therapyorder rule utility5504, and a therapyorder action enumeration5506. Thetherapy order class5502 includes a variety of therapy order operations for starting, stopping, and defining various therapies to be delivered by medical devices in the medical device network in which thetherapy service5500 operates. The therapy order operations include therapy creation, therapy update, therapy cancel, therapy execute, and therapy retrieval operations. Additional therapy order operations can be included in thetherapy order class5502 as well.

The therapyorder rule utility5504 provides expressions and actions related to execution of the therapy order, including various parameters and commands required for execution of the therapy. The therapyorder action enumeration5506 provides advisory messages used during selection and/or execution of a therapy order.

FIG. 56 displays exemplary message exchange processes5600,5620,5640, and5660 performed between a therapyorder management application5602, anoperations web service5604 such as the one shown inFIG. 36, amedical device server5606 as disclosed above inFIGS. 3-4, and amedical device5608, such as shown inFIG. 2. The therapyorder management application5602 can be any application configured to interface with the operations web service to communicate therapy orders and other messages to theoperations service5604 andmedical device server5608.

A firstmessage exchange process5600 illustrates the therapyorder management application5602 transmitting a createtherapy order message5610 to theoperations web service5604. Theoperations web service5604 verifies the therapy information and stores the therapy order in operations data. Theoperations web service5604 also responds5612 by indicating success or failure of the message.

A secondmessage exchange process5620 illustrates the therapyorder management application5602 later in time transmitting a therapy order update message or a therapyorder cancellation message5622. Theoperations web service5604 verifies the therapy information, and updates or cancels the therapy order according to the message. Theoperations web service5604 also responds5624 by indicating success or failure of the message.

A thirdmessage exchange process5640 occurring after the firstmessage exchange process5600 illustrates the therapyorder management application5602 transmitting amessage5642 indicating that the therapy order should be executed. The therapyorder management application5602 transmits an executetherapy order message5642 to theoperations web service5604, which verifies the therapy order and in turn forwards thetherapy order message5642 to themedical device server5606. Themedical device server5606 relays thetherapy order message5642 to amedical device5608.

Themedical device5608 transmits amessage5644 indicating the success or failure of receipt of thetherapy order message5642. Themedical device server5606 andoperations web service5604 relay themessage5644 back to theorder trigger application5602.

At a time after the medical device transmits themessage5644, themedical device5608 initiates afourth messaging process5660 in which the medical device transmits atherapy begin message5662 to themedical device server5608, indicating that the medical device has begun delivering the therapy to a patient. Themedical device server5608 transmits themessage5662 to theoperations web service5604, which updates the therapy order state. The medical device server also relays themessage5662 to an event tracking web service5605, such as the one inFIG. 36, to store a therapy delivery event in an event history log. Both the event tracking web service5605 and theoperations web service5604 transmitresponse messages5664 indicating the success or failure of receipt of the therapy beginmessage5662.

Additional events triggered by the medical device, such as a therapy completion event or alarm, transmit among the components5602-5608 analogously to themessaging process5660. Further, additional messaging schema can be included as well.

FIG. 57 shows methods and systems for tracking changed parameters in a medical device, such as a medical infusion pump. Thesystem5700 communicates original, updated, and final parameter values used for operation of the medical device, using metadata as described herein to identify the various changes in parameters. Thesystem5700 commences at astart operation5702, which corresponds to initiation of a therapy in a medical device. The therapy initiated in the medical device includes parameters needing parameter values to define various aspects of the therapy. For example, in a therapy delivered by a medical infusion pump, various parameters include basal rates, bolus rates, thresholds, and various other parameters.

An originalparameter receipt module5704 receives an original parameter value from a medical device. The original parameter is a parameter set in a medical device prior to receipt of a different parameter by that device, and can be any type of operational parameter related to delivery of a therapy or monitoring provided by the medical device. An updatedparameter receipt module5706 receives an updated parameter value from the medical device corresponding to a change from the original parameter. The updated parameter value is a new parameter value changing the operation of the medical device. The updated parameter value relates to the same parameter as the original parameter. A finalparameter receipt module5708 receives a final parameter value from the medical device. The final parameter value is the parameter value the medical device will use for therapy and monitoring after the device is reprogrammed with the updated parameter value. The final parameter value may be the same as the updated parameter value, or may be different based on, for example, various hard and soft limits set for parameters within the medical device. In various embodiments, the receipt modules5704-5708 may occur concurrently or sequentially, and may be included in one or more messages from the medical device to the medical device server.

Aparameter storage module5710 stores the original, updated, and final parameter values in memory of the medical device server or other back office components. Optional additional steps involved in thesystem5700 can include comparing the final parameter value received in the finalparameter receipt module5708 with a hard limit or soft limit stored in the medical device server. If the final parameter value exceeds the limit, thesystem5700 may trigger an alarm in the medical device server, and optionally communicate that alarm back to the medical infusion pump via a package deployment or other message. In a further embodiment, the alarm is communicated to a medical caregiver associated with the medical device.

Operational flow terminates at anend operation5712, which corresponds to completion of the change in pump parameter values and storage of the updated pump parameter values in the medical device server or other back office component.

FIG. 58 shows a medicaldevice history report5800 listing original, updated, and final operational parameter values for a medical device according to the methods and systems ofFIG. 57. The medicaldevice history report5800 includes amedical device label5802, date andtime information5804,class information5806, triggerinformation5808,message information5810,location information5812, anddrug information5814. Themedical device label5802 corresponds to the medical device name for the device whose history is displayed in thereport5800. The date andtime information5804 correspond to the time the various events occurred that are included in the medical device history report. Theclass information5806 describes the type and severity of the event. In the case of a therapy change event, theclass information5806 also includes an original value of the changed parameter, the changed value of that parameter, representing the value entered by a user, and a final value of the parameter, indicating the final set value used by the medical device.

Thetrigger information5808 displays the trigger associated with the medical device event. In the example shown, an event in an alarm classification has a high level of concern, and includes a warning in thetrigger information5808. However, an event describing a therapy change will not activate thetrigger information5808.

Themessage information5810 includes information about the status of the medical device, such as battery life, therapy delivery progress, therapy parameter limits, or physical characteristics of the device. Thelocation information5812 includes information related to the location of the medical device, such as the department, the facility, and the entity controlling the medical device. Thedrugs information5814 includes information about the drug or therapy being delivered by the medical device, and optionally is only included in the information for a therapy change. Additional information about the medical device can be displayed in the medicaldevice history report5800, based on the information tracked by the medical device server and operations web service.

FIG. 59 shows atherapy history report5900. Thetherapy history report5900 displays the same information as is displayed in the medical deviceevent history report5800 ofFIG. 58, but will only display therapy event information. Thetherapy history report5900 includes amedical device label5902, date andtime information5904,class information5906, triggerinformation5908,message information5910,location information5912, anddrug information5914, each of which operate analogously to the corresponding entries in the medical deviceevent history report5800.

FIG. 60 shows atherapy trending report6000. Thetherapy trending report6000 displays a chart of therapy related events over time. In the embodiment shown, thetherapy trending report6000 displays a bar chart showing the frequency of therapy events by month. Other configurations displaying trends in therapy events are possible as well.

FIG. 61 shows a therapychange history report6100. The therapychange history report6100 also displays the same information as is displayed in the medical deviceevent history report5800 ofFIG. 58, but only displays therapy change event information. Therapy change events correspond to changed parameters in delivering a therapy using a medical device. The therapychange history report6100 includes amedical device label6102, date andtime information6104,class information6106, triggerinformation6108,message information6110,location information6112, anddrug information6114, each of which operate analogously to the corresponding entries in the medical deviceevent history report5800 and thetherapy history report5900.

FIG. 62 shows a therapychange trending report6200. The therapychange trending report6200 displays a chart of therapy change events over time. In the embodiment shown, the therapychange trending report6200 displays a bar chart showing the frequency of therapy change events by month. Other configurations displaying trends in therapy change events are possible as well.

C. Event Web Service: On-Line Status and Viewing of Device Activity

Referring now toFIGS. 63-66, various features of the event web service ofFIG. 36 are described. The event web service provides a method by which external applications collect event data from the medical device server and back office components. In particular, the event web service provides an indication of the on-line status of the medical device, and also provides user access to telemetry streams allowing near-real-time telemetry information regarding operation of a medical device in the context of a medical device network as described in FIGS.1 and3-4.

FIG. 63 is a flowchart of methods and systems for determining the on-line status of a medical device. Thesystem6300 executes on a medical device server or other back office components, and expects communication from a medical device within a predetermined period in order to ensure accurate communication between the device and server.

Operational flow within thesystem6300 commences at astart operation6302, which corresponds to initial communication between a medical device and a medical device server. Operational flow proceeds from thestart operation6302 to anexpectation module6304. Theexpectation module6304 sets in the medical device server and/or back office components an expected, predetermined period within which the medical device server will expect communication.

A receivedata operation6306 determines whether a message has been received by the medical device server. If data has been received by the medical device server, operational flow branches “yes” to anupdate module6308, which updates the status of the medical device to indicate that the device is on-line.

An optionaloutput update module6310 updates data output from the medical device server based on information received in the message. The information received in the message can include medical device status information, event log data, telemetry data, or various other types of data. In one embodiment, the message indicates the beginning of a telemetry stream, and, in response to the message from the medical device, the medical device server and back office components update the appearance of a dashboard screen to reflect the received telemetry data. In a further embodiment, the output update module updates medical device status information in one or more of the back office components.

Operational flow proceeds through the receivedata operation6306, theupdate module6308, and theoutput update module6310 so long as the medical device continues in operation and the receivedata operation6306 determines that the medical device server continues to send messages to the medical device within the predetermined period.

If the receivedata operation6306 fails to receive data within the predetermined period, the operational flow branches “no” to anoffline module6312, which changes the state of the medical device to offline in the medical device server and/or back office components. Operational flow proceeds to the optionaloutput update module6310, which updates the output to indicate that the currently displayed data is no longer considered current by the medical device server until additional messages have been received. Operational flow terminates at anend module6314, corresponding to suspension of operation of the medical device network.

FIGS. 64-66 provide methods and systems for operation of telemetry streams received from a medical device. The telemetry streams described herein provide nearly-continuous communication from the medical devices to the medical device server, and are viewable on a dashboard or other web portal.

FIG. 64 shows a flowchart of systems and methods for near-real-time display of telemetry information from a medical device. Operational flow in thesystem6400 commences at astart node6402, which corresponds to initial operation of a medical device capable of transmitting a telemetry stream in a medical device network. Anew state6404 indicates that the telemetry stream has not previously been running. After the new state, a stream startup process attempts to start the telemetry stream, as shown inFIG. 65, below. If the stream startup process fails, operational flow proceeds to a failedstate6406, corresponding to failure to start the telemetry stream. Operational flow then proceeds to anend node6408.

If the stream startup process successfully starts, operational flow proceeds to a collectingstate6410, which corresponds to the medical device server collecting telemetry data from the medical device. In the collecting state, the telemetry data can be stored in the medical device server or other back office components, and also can be output to a dashboard or other monitoring user interface.

From the collectingstate6410, a number of possible options affect operational flow of thesystem6400. If a message, including a telemetry stream message, is not sent from the medical device to the medical device server within an expected, predetermined time set in the medical device server or back office components, operational flow proceeds to anoffline state6412. Theoffline state6412 corresponds to the system no longer regularly receiving telemetry data. If a telemetry report is later received, thesystem6400 returns to the collectingstate6410.

If the telemetry stream is paused by a user, operational flow proceeds to a paused state6414, corresponding to a system which only temporarily is not receiving telemetry data. The user can resume the telemetry stream to return thesystem6400 to the collecting state.

A terminatedstate6416 can be reached from the collectingstate6410, theoffline state6412, or the paused state6414 by the user terminating the stream or the system otherwise receiving a medical device power off event. The terminated state6414 corresponds to ending the telemetry stream. In the terminated state, the system no longer receives information from the medical device, and the dashboard is not updated. In a possible embodiment, when thesystem6400 is in the terminated state, a dashboard or other monitoring interface indicates to a user that data is not currently being collected. From the terminated state, operational flow proceeds to theend node6408.

FIG. 65 displays exemplary telemetry

stream message sequences

6500,6520,6540, and6560 performed among: adashboard6502, such as the one shown inFIG. 67; an event trackingweb service6504, such as the one shown inFIG. 36; amedical device server6506, as disclosed above inFIGS. 3-4; and amedical device6508, such as shown inFIG. 2. A first telemetrystream message sequence6500 illustrates a request to initiate a telemetry stream from a medical device to a dashboard. Themessage sequence6500 starts by thedashboard6502 sending a starttelemetry stream message6510 to the event trackingweb service6504. The event tracking web service communicates themessage6510 to themedical device server6506, which in turn communicates themessage6510 to themedical device6508. The medical device generates aresponse message6512 indicating success or failure of the message. The response message is related back to thedashboard6502 by themedical device server6506 and event trackingweb service6504.

A second telemetrystream message sequence6520 illustrates initiation of a telemetry stream by amedical device6508. Themedical device6508 generates atelemetry event6522, which includes near-continual communication of telemetry data from themedical device6508 to themedical device server6506, which relays the telemetry data to thedashboard6502 via the event trackingweb service6504. Thedashboard6502 displays the telemetry data to the user in a near-real-time fashion. In one embodiment, the dashboard recreates the appearance of the medical device. The dashboard transmits aresponse message6524 to the event trackingweb service6504, indicating successful receipt of the telemetry stream.

Thedashboard6502 generates a gettelemetry window message6526 and transmits the message to the event tracking web service, which responds with amessage6528 indicating success or failure of the command. The telemetry window is started at this point, and the dashboard or web portal will display telemetry data.

At this point, if the medical device is powered off, the event trackingweb service6504 will respond with a fail message and will terminate the telemetry stream.

A third telemetrystream message sequence6540 illustrates ending a telemetry stream by shutting off the medical device generating the telemetry stream. Themedical device6508 generates a power offevent message6542 and sends the message to themedical device server6506. The medical device server sends a terminate telemetry stream message to the event trackingweb service6504. The event trackingweb service6504 generates aresponse message6544 indicating success or failure of receipt of themessage6542. Themedical device server6506 relays theresponse message6544 to themedical device6508.

A fourth telemetrystream message sequence6560 relates to thesequence6540 and illustrates ending a telemetry stream by discontinuing the telemetry stream at thedashboard6502. Thedashboard6502 generates a terminatetelemetry stream message6562, which is communicated from the dashboard to the event trackingweb service6504, and in turn through themedical device server6506 to themedical device6508. Themedical device6508 terminates its telemetry stream and generates aresponse message6564 indicating success or failure of receipt of themessage6562. The medical device server relays themessage6564 through the event trackingweb service6504 to thedashboard6502. Additional messaging processes are possible in order to start and terminate telemetry streams using medical devices and dashboards according to the present disclosure.

FIG. 66 shows an exemplary class structure defining atelemetry stream class6600. Thetelemetry stream structure6600 illustrates a portion of the functionality of the eventweb service module3606. The telemetry stream relates back to and uses a variety of functions from theadministrative web service3700 ofFIG. 37.

Thetelemetry stream structure6600 includes atelemetry stream class6602 and alatest event class6604. Thetelemetry stream class6602 includes a variety of telemetry-related operations, including starting, terminating, pausing, and retrieving available telemetry streams. Additional telemetry stream operations can be included in thetelemetry stream class6602 as well. Thelatest event class6604 includes functions for retrieving the latest events, so as to determine when the most recent event was received from the medical device and thereby determine the on-line status of the medical device, so as to determine the availability of telemetry stream data. Additional functions can be included in thelatest event class6604, and additional classes can be added to thetelemetry stream structure6600.

Various exemplary dashboards may be used to view telemetry data at a workstation of other computing device. One example dashboard is shown inFIG. 67. Thedashboard6700 displays telemetry data (e.g. current or near-current operational status) relating to the pumps with which it is associated. Thedashboard6700 can be any of a number of dashboard applications configured to receive and display telemetry data to a user in a near-real-time manner, and can correspond, for example, to the dashboards logically illustrated asdashboard328 ofFIGS. 3-4. Thedashboard6700 can be updated by a telemetry stream, such as described above inFIGS. 64-66.

In the embodiment shown, thedashboard6700 tracks aname6702,identifier6704,domain6706,address6708,port6710, andactivity history6712, with respect to each medical device associated with the dashboard. Thename6702 corresponds to a name of a device recognizable to a user, assigned by either the device itself or the server. Theidentifier6704 provides a unique identification useable by the server to verify the identity of the medical device. In various embodiments, the identifier can correspond to a globally-unique identifier (GUID), hardware address, or other identification of the medical device. Thedomain6706 indicates the name of a network in which the medical device resides. Theaddress6708 provides connection information regarding how to communicate with the medical device from the server. In the embodiment shown, theaddress6708 is shown as an IP address of the medical device. Theport6710 lists the inbound communication port for the medical device. Theactivity history field6712 lists a date and time of the last event occurring on the medical device and communicated to the server.

Thedashboard6700 graphically illustrates an operational status of the pumps with which it is associated. In the embodiment shown, five medical devices are tracked in thedashboard6700, named “MD0333”, “MD0444”, “MD0524”, “MD0324”, and “MD0988.” The first, fourth, and fifth devices (MD0333, MD0324, and MD0988) are illustrated as powered and delivering a therapy to a patient. The second device (MD0444) is shown to be in an alarm state, indicating a possible abnormal operation of the device or emergency condition related to the patient associated with that device. The third device (MD0524) is illustrated to be in a fault state, indicating a malfunction or error occurring in that medical device. Other states illustrating an operational status may be illustrated on thedashboard6700 as well.

Optionally, additional features can be included in thedashboard6700 that allow a user to filter or display different types of information. In the embodiment shown, apause check box6714 and an offlinedevices check box6716 allow a user to selectably modify the dashboard. Thepause check box6714, when selected, causes the dashboard to “freeze” temporarily halting the updating of information in the dashboard to allow a user to view the state of the dashboard at a single time. When thepause check box6714 is unselected, the status information on the dashboard can continually update as data is received from the associated medical devices. The offlinedevices check box6716 enables the dashboard to display information related to devices associated with the dashboard, but which are not online and from which the dashboard has not received recent status information. Other display features and filters can be incorporated into the dashboard as well, allowing a user to select the desired set of devices to monitor and allowing the user to view a specific portion of the telemetry data received from those users.

The various embodiments described above are provided by way of illustration only and should not be construed to limit the invention. Those skilled in the art will readily recognize various modifications and changes that may be made to the present invention without following the example embodiments and applications illustrated and described herein, and without departing from the true spirit and scope of the present invention, which is set forth in the following claims.