US20090157695A1 - Central Server for Medical Devices - Google Patents

Central Server for Medical Devices Download PDF

Info

Publication number
US20090157695A1
US20090157695A1 US12/189,603 US18960308A US2009157695A1 US 20090157695 A1 US20090157695 A1 US 20090157695A1 US 18960308 A US18960308 A US 18960308A US 2009157695 A1 US2009157695 A1 US 2009157695A1
Authority
US
United States
Prior art keywords
medical device
server
data
medical
medical devices
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12/189,603
Inventor
Nick Roberts
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Smiths Medical ASD Inc
Original Assignee
Smiths Medical MD Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Smiths Medical MD Inc filed Critical Smiths Medical MD Inc
Priority to US12/189,603 priority Critical patent/US20090157695A1/en
Assigned to SMITHS MEDICAL MD, INC. reassignment SMITHS MEDICAL MD, INC. ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ROBERTS, NICK
Publication of US20090157695A1 publication Critical patent/US20090157695A1/en
Assigned to SMITHS MEDICAL ASD, INC. reassignment SMITHS MEDICAL ASD, INC. MERGER (SEE DOCUMENT FOR DETAILS). Assignors: SMITHS MEDICAL MD, INC.
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/20ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management or administration of healthcare resources or facilities, e.g. managing hospital staff or surgery rooms
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/40ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the management of medical equipment or devices, e.g. scheduling maintenance or upgrades
    • GPHYSICS
    • G16INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16HHEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/67ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for remote operation

Definitions

  • 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.
  • Hospitals and care centers use a variety of types and brands of medical devices to assist in monitoring and therapy administration.
  • 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.
  • 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.
  • 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.
  • a medical device such as a medical infusion pump, interfaces with a server to administer treatments to patients.
  • medical device metadata is used to define a medical device within a medical device network.
  • messages are communicated between a medical device and server to define treatments and other operations to the medical device.
  • 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.
  • timing parameters dictate communication and tracking of events between a medical device and a medical device server.
  • a server which includes a memory configured to store identification information regarding a plurality of medical devices at different customer sites, and a programmable circuit operatively connected to the memory.
  • the programmable circuit is configured to execute program instructions to receive data from medical devices at one or more of the different customer sites, store data in the memory associated with the one or more different customer sites, and associate a portion of the data with the medical device that transmitted that portion of data.
  • a server network in a second aspect, includes a plurality of medical devices at different customer sites, and a server operatively connected to the plurality of medical devices.
  • the server includes a memory configured to store identification information regarding a plurality of medical devices at different customer sites, and a programmable circuit operatively connected to the memory.
  • the programmable circuit is configured to execute program instructions to receive data from medical devices at one or more of the different customer sites, store data in the memory associated with the one or more different customer sites, and associate a portion of the data with the medical device that transmitted that portion of data.
  • the server network further includes a workstation at one of the customer sites, the workstation communicatively connected to the server and configured to request data related to the customer site.
  • 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 of FIG. 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 of FIG. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 1 shows an exemplary medical device network 100 in which aspects of the present disclosure may be implemented.
  • the medical device network 100 provides a method by which a variety of medical devices and communication systems intercommunicate.
  • the medical device network 100 includes a medical device server 102 interconnected with a variety of types of medical devices.
  • the medical devices can include an active medical device 104 , a passive medical device 106 , and a plurality of exemplary medical devices shown to be medical infusion pumps 108 .
  • the active medical device 104 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 active medical device 104 is a medical infusion device, such as the medical infusion pumps 108 shown.
  • the passive medical device 106 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.
  • the medical device server 102 communicates with the medical devices, and is one or more generalized or application-specific computing systems.
  • the medical device server 102 is configured to store and retrieve data received from the various medical devices 104 , 106 , 108 .
  • the data received by the medical device server 102 can include event log data, programming data, and various other data transmitted to the server 102 from the medical devices 104 , 106 , 108 .
  • the medical device network 100 includes additional computing devices, such as workstations 110 and portable computing systems 112 , configured to allow communicative connection to the medical device server 102 .
  • the workstations 110 and portable computing systems 112 are generalized computing systems or thin client computing systems having a communication interface allowing access to the medical device server.
  • the workstations 110 and portable computing systems 112 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 the medical device server 102 via the workstation 110 or portable computing system 112 to retrieve data gathered from a medical device, and may instruct the medical device server 102 to communicate various messages or software packages to one or more of the medical devices.
  • the medical device network 100 optionally includes network infrastructure components, such as a switch 114 and a wireless access point 116 .
  • the network infrastructure components are configured to provide the communication infrastructure between the various medical devices 104 , 106 , 108 , the medical device server 102 , and any additional computing systems 110 , 112 .
  • the medical device network 100 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, the switch 114 and wireless access point 116 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 the network 100 as well.
  • the medical device server 102 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.
  • 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.
  • 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.
  • 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 a medical device 200 .
  • the medical device 200 is any of a number of types of active or passive medical devices for therapy administration or monitoring of a patient.
  • the medical device 200 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.
  • the medical device 200 includes a programmable circuit 202 interfaced to a memory subsystem, including, for example, Random Access Memory (RAM) 204 , a flash memory 206 , and an electrically erasable, programmable memory (EEPROM) 208 .
  • the RAM 204 stores operational parameters of the medical device, as well as any non-critical storage with respect to operational data or instructions.
  • the flash memory 206 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.
  • the EEPROM 208 stores a set of initial instructions that are used by the medical device 200 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.
  • the EEPROM 208 optionally includes firmware or instructions which may be read or copied into the RAM 204 or flash memory 206 for execution, as necessary.
  • the various components of the memory subsystem used are dictated by the needs of the medical device.
  • one or more of the memory system components described herein are not present.
  • 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.
  • 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.
  • other types of non-volatile memory may be used instead, such as ferro-electric memory or others.
  • the medical device 200 further includes a battery system 210 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.
  • the battery system 210 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.
  • the battery system 210 includes different types of battery systems, such as a rechargeable battery system including a nickel-cadmium battery.
  • the medical device 200 includes an input device 212 and an output device 214 interfaced to the programmable circuit 202 .
  • the input device 212 allows a user at the location of the medical device to adjust the activity of the device.
  • the input device 212 can be, for example, a mouse, keyboard, keypad, trackball, touch screen, control buttons, or other user-controllable devices.
  • the output device 214 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.
  • the output device 214 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 the medical device 200 .
  • the medical device 200 also includes a display device 216 and an alarm 218 .
  • the display device 216 is a visual device capable of displaying information to a user of the device.
  • the display device 216 can be, for example, a display device, such as an LCD, CRT, or other screen. Additional types of display devices are possible as well.
  • the medical device is shown as including a display device 216 , in alternate embodiments a display device is not required.
  • the alarm 218 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.
  • a wired communication interface 220 provides a data communication connection from the medical device 200 that interfaces with a medical device server or other generalized computing system.
  • the wired communication interface 220 interfaces to the programmable circuit 202 , and sends and receives data from the medical device 200 .
  • the wired communication interface 220 can be an Ethernet or other data connection capable of communicating and receiving digital data.
  • a wireless communication interface 222 provides an alternative communication interface to the wired communication interface 220 , such that the medical device 200 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.
  • the wireless communication interface 222 interfaces to the programmable circuit 202 , 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.
  • 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.
  • 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.
  • the medical device 200 also includes a patient interface 224 .
  • the patient interface 224 controls the mechanical component of the medical device 200 which monitors or delivers a therapy to the user.
  • the patient interface 224 varies among the different types of medical devices based upon the function of the device.
  • the patient interface 224 may include a sensor or other physical detection equipment.
  • 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 the medical device 200 , depending upon the particular application to which the device is directed.
  • FIGS. 3-6 show an overall software environment for the medical device network 100 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 in FIGS. 1-2 .
  • the various software disclosed herein can be packaged in a variety of ways, and organized for a variety of different medical device networks.
  • the various software aspects are included in a software development kit (SDK) including some or all of the various software components described herein.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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. 3 shows a software architecture 300 in which aspects of the present disclosure are implemented.
  • the software architecture 300 provides an operating environment in which medical device data can be stored and managed remotely from the medical devices.
  • the software architecture 300 also provides an extensible architecture in which a variety of types of medical devices can operate.
  • the software architecture 300 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.
  • the software architecture 300 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 in FIG. 1 .
  • aspects of the software architecture 300 are implemented using the relational and business intelligence components of Microsoft SQL Server 2005, distributed by Microsoft Corporation.
  • various modules such as web interfaces, may be provided using a web service, such as Microsoft Internet Information Services (IIS) platform.
  • IIS Microsoft Internet Information Services
  • aspects of the system are implemented using Microsoft 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.
  • the software architecture 300 includes one or more medical devices 302 , back office components 304 , and client applications 306 .
  • the medical devices 302 monitor or deliver therapies to patients, as directed by a caregiver.
  • the medical devices 302 can be any of a variety of programmable medical devices such as those discussed in conjunction with FIGS. 1-2 , above.
  • the back office components 304 include one or more medical device servers 308 , an administration module 310 , an event tracking module 312 , and an operations module 314 .
  • the medical device server 308 manages communication with the various medical devices 302 associated with the back office components 304 , such as by relaying messages between the various modules 310 , 312 , 314 and the medical devices 302 .
  • the medical device server 302 creates messages understandable to the medical devices 302 and the various modules 310 , 312 , 314 such that a variety of types of medical devices can be managed using the modules.
  • the medical device server 308 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.
  • the medical device server 302 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.
  • the medical device server 308 resides on a computing system which also hosts the additional back office components 304 .
  • the medical device server resides on separate computing hardware from the other back office components.
  • the medical device server 308 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 in FIGS. 4-5 , below.
  • the term medical device server is intended to encompass either the medical device server 308 or the back office components 304 as a whole, depending upon the specific implementation chosen.
  • the medical device server 308 can be placed on one or more physical computing platforms, resulting in the presence of multiple medical device servers.
  • the administration module 310 provides an interface to administration data 316 , which the medical device server 308 and client applications 306 can request for various reasons, such as to allow access to event or operational data, described below.
  • the administration data 316 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.
  • user validation information such as username, password, IP authentication, or other user validation
  • rights information defining the access rights associated with the user.
  • the administration data 316 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 the administration data 316 and managed by the administration module 310 as well.
  • the administration data 316 also defines the capabilities of the various medical devices 302 managed within the environment 300 , by defining operational parameters by which the medical device server 308 interfaces with a medical device 302 .
  • 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.
  • the environment 300 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.
  • the administration module 310 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 the back office components 304 .
  • the administration module provides an interface allowing remote applications to access the data managed by the back office components 304 .
  • the event tracking module 312 provides an interface to the medical device server 308 , and organizes and manages event data 318 .
  • the event data 318 corresponds to the historical data regarding various events occurring in the medical devices 302 , which are collected and routed by the medical device server 308 .
  • the event data 318 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 the event tracking module 312 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 with FIGS. 19-24 .
  • the event tracking module 312 generates a web interface accessible by the medical device server 308 to transfer data to a storage location of event data 318 .
  • the operations module 314 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 various medical devices 302 associated with the environment 300 .
  • the operations module 314 also provides a web interface to the medical device server 308 for managing the various types of operations data 320 , and to various external computing systems to allow those systems to view the operations data 320 and transmit commands within the software architecture 300 , such as to the various medical devices 302 .
  • An optional data warehouse 322 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.
  • a reporting application receives data from the data warehouse 322 , which aggregates various data from the administration data 316 , the event data 318 , and the operations data 320 .
  • the data warehouse 322 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 warehouse 322 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.
  • 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.
  • its functionality as described herein can be provided by the Administration, Event Tracking, Operations databases and their corresponding modules, as described herein.
  • the client applications 306 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.
  • the client applications 306 accessing the back end components 304 include administration applications 324 , reporting applications 326 , dashboards 328 , maintenance forms 330 , and various additional external applications 332 .
  • the administration applications 324 provide user access to the administration data 316 include a variety of administration web forms, to define usage rights for other users attempting to access the back office components 304 , as well as to define the operational parameters of the medical devices 302 . Additional administration web forms may be included as well.
  • the reporting applications 326 provide a number of standardized reports based on the administration data 316 , the event data 318 , and the operation data 320 .
  • the reports may be based on the information in the data warehouse. Examples of reports built using the various types of data tracked in the back office components 304 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.
  • the dashboards 328 allow a caregiver or user to view the status of a medical device 302 .
  • the dashboards 328 are based on operation data, and interface to the operations module 310 .
  • the dashboards 328 available within the environment 300 correspond to the various medical devices 302 capable of frequently transmitting data to the back office components 304 .
  • the dashboards 328 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.
  • the dashboards 328 replicate the visual interface of the corresponding medical device, but in a web-portal format.
  • the maintenance forms 330 display maintenance information to a caregiver or other user of the medical devices 302 .
  • the maintenance forms 330 display tracked maintenance information included in the operations data 320 , such as performed maintenance, scheduled maintenance, suggested maintenance, and maintenance trends.
  • the maintenance forms 330 also allow the user to deploy various updates to the medical devices 302 , such as firmware updates and other software deployments.
  • the operations data 320 includes maintenance schedule information accessible by users via the maintenance forms.
  • the maintenance forms 330 display a maintenance schedule to a user, including future maintenance required for various medical devices 302 as well as historical maintenance events tracked in the operations data 320 .
  • Various external applications 332 extend the functionality of the software environment 300 by communicating with the operations module 314 .
  • the external applications 332 include any applications useable to extend the functionality of the software environment 300 .
  • FIG. 4 displays an alternative software infrastructure 400 to the one shown in FIG. 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.
  • the medical devices 302 and medical device server(s) 308 may reside at one or more hospitals or health care facilities 404 , managed by one or more healthcare entities, such as counties or private entities.
  • the storage of data from those devices may be managed by a health management organization or other organization 405 contracting to manage the data of the various facilities at an off-site location.
  • That entity can collect information from the medical device server 308 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 in FIG. 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 the system 500 of FIG. 5 commences at a start operation 500 , which corresponds to initialization of the system 500 , such as by operation of various medical devices connected to a medical device server.
  • a data receipt module 504 receives data generated by the medical devices managed by one or more entities, such as hospitals, clinics, or other health management organizations.
  • the data receipt module 504 corresponds to receipt of various administrative data, event data, or operations data from a medical device server or client applications, as shown in the back office components 304 of FIG. 4 .
  • An association module 506 associates the data received in the data receipt module 504 with the medical devices from which the data is received.
  • the association module 506 associates the data with the various locations at which the medical devices reside, or with the various entities controlling the devices, as defined in the administration data 316 .
  • the data association can be a logical or physical relationship between the data, such as can be found in a file, table, or database.
  • the association module 506 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 the association module 506 .
  • 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.
  • An optional program module 508 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.
  • 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 the data receipt module 504 and the association module 506 , above.
  • 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 an end operation 510 , 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 of FIG. 1 , in which medical device actions are interconnected.
  • the system 600 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.
  • the system 600 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 the system 600 commences at a start operation 602 , which corresponds to initial monitoring of a patient using a plurality of medical devices connected to a medical device network.
  • the start operation 602 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.
  • a status receipt module 604 receives a status of a patient from a first medical device used to monitor or administer a therapy to the patient.
  • the status receipt module 604 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.
  • a determination module 606 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.
  • the determination module 606 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.
  • execution of the determination module 606 there may exist an instance in which a monitor senses or is told that the patient is experiencing pain.
  • 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, the determination module 606 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.
  • a program module 608 generates programming for a target medical device capable of providing the changed or additional therapy or monitoring determined in the determination module 606 .
  • the program module 608 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.
  • the program module 608 requests that a caregiver approves the suggested therapy determined in the determination module 606 .
  • the program module 608 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 an end operation 610 .
  • the end operation 610 corresponds to the medical device server completing communication of the determined therapy to a workstation or medical device.
  • 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 in FIGS. 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.
  • FIGS. 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 exemplary extensible system 700 in which a medical device server associates with a remotely located medical device.
  • the system 700 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.
  • every medical device recognized by a medical device server will have an associated state held in a table on the server. Therefore, the system 700 will execute independently on the server for each medical device associated with the server.
  • the system 700 commences at a start node 702 corresponding to connection of the medical device to a medical device network including a medical device server, such as the one shown in FIG. 1 .
  • the medical device server 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 known state 704 , 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 known state 704 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.
  • the medical device 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 a determination node 706 , which corresponds to determining the state of the medical device.
  • the powered state 708 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.
  • the powered state 708 is entered from the known state 704 or the determination node 706 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 state 710 , the fault state 712 , and the alarm state 714 , 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 state 710 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.
  • the system 700 can enter the therapy state from any of the other operational states 708 , 712 , 714 , or from the determination node 706 .
  • 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 the powered state 708 . 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.
  • the fault state 712 corresponds to an error occurring in the medical device, such as a malfunction in the operation of the device during monitoring or therapy delivery.
  • the fault state 712 can be entered from either the powered state 708 or the therapy state 710 , and can also be entered from the determination node 706 .
  • the fault state 712 can trigger notification of a caregiver having control of the medical device that a fault has occurred.
  • the server can determine the fault occurring in the medical device and can correct the error.
  • the medical device 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 the powered state 708 if returning from the determination node 706 .
  • 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.
  • the alarm state 714 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.
  • the medical device may be a medical infusion pump which has run out of medicine for delivery.
  • the medical device is a heart rate monitor, and the event is monitoring and detection of an abnormally low or high heart rate.
  • the alarm state 714 can be entered from either the powered state 708 or the therapy state 710 , and can also be entered from the determination node 706 .
  • the medical device 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.
  • a nonoperative state 716 may be entered from any of the active states, including the powered state 708 , the therapy state 710 , the fault state 712 , or the alarm state 714 .
  • the nonoperative state 716 corresponds to the server being unable to determine if the medical device is active, or what state the medical device is in.
  • the nonoperative state 716 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.
  • the medical device server may or may not know how to communicate with it. Assuming it is a known device that is not currently powered, the medical device server will eventually enter the known state 704 . When the medical device is turned on, the medical device will transmit a power on message to the server, which will update the table to indicate that the medical device is in the powered state 708 . The medical device will send to the server a message when the medical device delivers a therapy, and the medical device server will associate that medical device with the therapy state 710 .
  • the medical device When the medical device completes delivering that therapy successfully, the medical device will send a message to the server, which will change the table entry of that device from the therapy state 710 to the powered state 708 . If the medical device fails for some reason, it will communicate a fault message to the server, which will associate the medical device with the fault state 712 .
  • the device will communicate an alarm message to the server, which will associate the medical device with the alarm state 714 .
  • the device 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 the powered state 708 .
  • 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 known state 704 .
  • FIG. 8 displays a diagram of an exemplary communications system 800 incorporating a medical device server and a medical device.
  • the communications system 800 is configured for receipt, processing, and storage of input messages from external devices, such as medical devices.
  • the communications system 800 uses a metadata-based communications protocol, such as the SOAP protocol.
  • the medical device server uses message schema files to validate messages received from medical devices.
  • the communications system 800 is configured such that messages sent from a medical device 802 are received by a medical device server 804 , which includes a device server object 806 , message handlers 808 , and a data tier 810 .
  • the medical device 802 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 with FIG. 2 .
  • the medical device server 804 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.
  • the medical device server 804 contains a device server object 806 , 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.
  • 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 the device server object 806 , as well as for the various device handlers incorporated into the system.
  • a sample device server object definition can read as follows:
  • 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 or more message handlers 808 receive the message in its original format from the device server object 806 , and process the message in a manner to convert the message to a format understandable to and stored by the data tier 810 of the medical device server 804 .
  • 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.
  • 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 the medical device server 804 .
  • a second exemplary server object definition describes various features of a message handler 808 :
  • the example for the message handler 808 is analogous to that describing the device server object 806 , but defined using a Provider tag indicating that the metadata defines a handler configured to define a feature.
  • the message handler 808 can be associated with the device server object 806 using the following code:
  • the medical device server 804 can route specific types of data to the appropriate handler.
  • a data tier 810 receives messages from the message handlers 808 for storage, and also responds to requests for data by providing data to the requesting message handler 808 for formation into a SOAP-based message or transmission to the medical device via the device server object 806 .
  • a programming schema 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.
  • 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.
  • the metadata schema disclosed operates using the XML protocol, and a SOAP based messaging system as described above in FIG. 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.
  • the system 900 shown is configured to provide extensibility to a variety of types and brands of medical devices, as described above in FIG. 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.
  • the system 900 instantiates at a start operation 902 , which corresponds to communicatively connecting a medical device to a medical device server.
  • the communicative connection corresponds to introducing the medical device into a medical device network including a medical device server, such as the network shown in FIG. 1 .
  • 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.
  • An association module 904 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.
  • 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 of FIGS. 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 in FIGS. 17-33 .
  • a storage module 906 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 with FIG. 8 .
  • Operational flow proceeds to an end operation 908 , 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.
  • the system 1000 of FIG. 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 the system 1000 commences at a start operation 1002 , which again corresponds to communicatively connecting a medical device to a medical device server in a medical device network.
  • the general association module corresponds to the association module 904 of FIG. 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.
  • a custom metadata module 1006 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.
  • a storage module 1008 generally corresponds to the storage module 906 of FIG. 9 , and stores the general metadata and the custom metadata on the server.
  • a device selection module 1010 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.
  • a communication module 1012 transmits a message to the selected medical device determined in the device selection module 1010 .
  • 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 the system 1000 , such as those described in FIGS. 11-16 and 19 - 24 , below. Operational flow terminates at an end operation 1014 , 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 of FIG. 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.
  • 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 an identity schema 1100 used to identify various operational characteristics of each of the medical devices communicatively associated with a medical device server.
  • the identity schema 1100 includes a main table 1102 including a variety of global parameters, as well as a network table 1104 , an access table 1106 , and one or more package tables 1108 .
  • the main table 1102 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 table 1104 , access table 1106 , and package tables 1108 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 table 1102 .
  • the network table 1104 includes the host, domain, IP address, and port information necessary to define a connection to the medical device over an Internet connection.
  • the access table 1106 includes an IP address and Physical Id corresponding to the specific networking connection corresponding to the physical device to the IP address.
  • the package tables 1108 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 with FIGS. 25-33 .
  • FIG. 12 shows a control table 1200 which includes elements describing the logistics of sending messages and tracking those elements between the medical device and medical device server.
  • the control table 1200 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 table 1300 used to track patient information for association with the medical device.
  • the patient table 1300 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 table 1400 used to indicate the location of a patient.
  • the location table 1400 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, Room 1 ” 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 table 1400 as well.
  • FIG. 15 shows a drug table 1500 used to indicate the drug, if any, associated with the medical device.
  • the drug table 1500 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 table 1600 corresponding to a doctor, nurse, or other caregiver currently controlling the medical device.
  • the user table 1600 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.
  • FIGS. 17-24 systems, methods, and schema are disclosed which are used in the medical device network of FIG. 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 in FIGS. 19-24 .
  • the system 1700 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 the system 1700 commences at a start operation 1702 , which corresponds to initial operation of the medical device network. Operational flow proceeds to an event receipt module 1704 , 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 of FIGS. 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 the event receipt module 1704 .
  • 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 of FIG. 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.
  • a storage module 1706 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, the storage module 1706 stores event log data in the event data 318 of FIGS. 3-4 .
  • a request receipt module 1708 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.
  • the request receipt module 1708 receives a request for event log data related to delivery of a specific drug by a medical infusion pump.
  • a result generation module 1710 generates results based on the specific request received by the request receipt module 1708 , 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.
  • the result generation module 1710 optionally also transmits the results to the requesting computing system.
  • the medical device server uses the example described in the request receipt module 1708 to generate 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 an end operation 1712 , 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.
  • the system 1800 uses the metadata of FIGS. 11-16 , as well as the additional event metadata of FIG. 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 with FIG. 17 allow the communication to occur.
  • the system 1800 commences at a start operation 1802 , which corresponds to initial operation of the medical device network. Operational flow proceeds to a storage module 1804 , 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.
  • the storage module 1804 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.
  • the storage module 1804 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.
  • a transmission module 1806 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.
  • the reminder may be a trigger of a user-readable message stored on the medical device.
  • the transmission module 1806 also optionally transmits maintenance data associated with the maintenance reminder.
  • the reminder sent by the transmission module 1806 disables the medical device.
  • the reminder allows the medical device to continue operation.
  • the reminder is transmitted a predetermined time prior to performance of the required maintenance of the medical device.
  • 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.
  • 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 an end operation 1808 , 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 of FIG. 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 table 1900 and a power event response table 1910 .
  • the tables 1900 , 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 table 1900 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 table 1910 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 of FIGS. 25-33 . Additional metadata may be included in the response table 1910 and the corresponding response message.
  • FIG. 20 shows an alarm event table 2000 and an alarm event response table 2010 .
  • 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 table 2000 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata.
  • 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 table 1900 .
  • the alarm event response table 2010 corresponds to the power event response table 1910 . 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 table 2010 therefore generally includes a different response than the power event response table 1910 , and communicates messages, packages or other instructions related to the alarm event.
  • FIG. 21 shows a maintenance event table 2100 and a maintenance event response table 2110 .
  • 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 table 2100 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 table 2100 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata.
  • 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 table 1900 .
  • the maintenance event response table 2110 also corresponds to the power event response table 1910 , 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 table 2200 and a telemetry event response table 2210 .
  • 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 table 2200 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata.
  • 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 table 1900 .
  • the telemetry event response table 2210 also corresponds to the power event response table 1910 , 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.
  • the therapy event response table 2310 also corresponds to the power event response table 1910 , 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 table 2400 and a therapy change event response table 2410 .
  • 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 table 2400 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata.
  • 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 table 1900 .
  • the therapy change event response table 2410 also corresponds to the power event response table 1910 , 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.
  • 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.
  • 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 table 1102 and package tables 1108 .
  • the main table 1102 indicates the capability of the device to receive a package
  • the package tables 1108 include information related to the current package information stored at the medical device for use in operation of the medical device.
  • Package delivery occurs in response to a message, and is initiated using the package data identifier in the event response tables 1910 - 2410 to indicate to the medical device that a package is available for delivery.
  • the package 2500 includes a server header 2502 , a vendor header 2504 , and information 2506 to be delivered to the medical device.
  • the server header 2502 is the portion of the package understood by the medical device server.
  • the server header 2502 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 the server header 2502 as well.
  • the server header 2502 is a 256 byte block incorporated into the package.
  • the vendor header 2504 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 the vendor header 2504 in a manner understandable to the medical devices it manufactures.
  • the vendor header generally includes information related to the size of the information 2506 , as well as the location of encryption information 2508 within the information.
  • the encryption information 2508 can be used by the medical device to decrypt the information, which is generally stored in the medical device server in an encrypted form.
  • the information 2506 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.
  • the package delivery system 2500 is not dependent upon the specific format of the vendor header 2504 or the information 2506 .
  • the information 2506 is generally stored in an encrypted form on the medical device server. When transferred to a medical device, the information 2506 is decrypted by the medical device by locating the encryption information 2508 based on information in the vendor header 2504 .
  • FIG. 26 shows systems and methods for deploying package data from a medical device server to medical devices.
  • the system 2600 is configured to distribute a package, such as the package 2500 of FIG. 5 , to a medical device in response to a message received from the medical device.
  • Operational flow within the system 2600 commences at a start module 2600 , 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.
  • a storage module 2604 stores the received package in the medical device server.
  • the storage module 2604 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.
  • the storage module 2604 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.
  • the storage module 2604 leaves the package unencrypted when it is stored on the medical device server or back office components.
  • a message receipt module 2606 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 in FIGS. 19-24 . Additional message types are possible as well.
  • An indication module 2608 indicates to the medical device that a package is intended for delivery to that device.
  • the indication module 2608 sets a parameter in a message response indicating the existence of a package.
  • the indication module 2608 can set a parameter in the package metadata included in the event response messages 1910 - 2410 of FIGS. 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.
  • a request module 2610 receives a request from the medical device to receive the package.
  • the request module 2610 may include one or more steps of requesting information about the package to verify at the medical device that the package should be accepted.
  • the request module 2610 transmits a package information request message, using metadata as shown in FIG. 27 .
  • the request module 2610 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.
  • the request module 2610 receives a request as shown in FIG. 29 or 31 .
  • a delivery module 2612 delivers the requested package to the medical device.
  • the format of the package delivery message can be as shown in FIG. 30 or 32 .
  • Operational flow terminates at an end operation 2614 , 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 in FIG. 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 table 2700 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 table 1102 or package tables 1108 related to that device in the medical device server.
  • the metadata in the table 2700 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 table 2700 and message from the medical device as well.
  • FIG. 28 shows a package information request response table 2800 including metadata used in describing a package available to be deployed to a medical device.
  • the metadata in the table 2800 includes the package identifier, corresponding to the package identifier in the package information request table 2700 , and also includes package information metadata.
  • the package information metadata links to a package information table 2802 , 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 table 2900 including metadata used in requesting package data from a medical device server.
  • the package data request table 2900 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.
  • 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 table 3000 including metadata used in deploying a package to a medical device.
  • the metadata included in the package data request response table 3000 includes a package identifier and a package binary data field.
  • the package identifier identifies the package referred to in FIG. 29
  • 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 table 3002 containing the package binary data for delivery to a medical device.
  • the package delivered to the medical device is the package 2500 of FIG. 25 .
  • FIG. 31 shows a package request table 3100 .
  • the package request table 3100 corresponds to the package data request table 2900 of FIG. 29 combined with the package information request table 2700 of FIG. 27 .
  • the package request table 3100 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 table 3100 includes a package identifier and a response type, similar to the package data request table 2900 , 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 table 3200 , 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 table 3100 of FIG. 31 .
  • the package request response table includes package identifier, package information, and package binary metadata.
  • the package information metadata links to a package information table 3202 containing name and version metadata associated to the package data.
  • the package binary metadata links to a package binary table 3204 , which includes metadata corresponding to the package to be deployed to the medical device.
  • FIGS. 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 a time messaging schema 3300 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.
  • the time schema 3300 includes a time request table 3302 , a time request response table 3304 , and a system time table 3306 .
  • the time request table 3302 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 table 3304 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 table 3306 , 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 the system 3400 commences at a start operation 3402 , corresponding to initial operation of the medical device network.
  • a server time maintenance module 3404 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 server time transmission module 3406 transmits the server time to one or more medical devices in the medical device network.
  • the server time transmission module 3406 transmits the server time value to a medical device in response to a request message from that medical device.
  • the request message may be of a form shown in the time request table 3302 of FIG. 33 , above.
  • the transmission module 3406 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.
  • a replacement module 3408 replaces the device time in the medical device with the server time value received from the medical device server.
  • the replacement module 3408 uses the time-adjusted server time value, configured to be used at the location of the medical device.
  • An optional confirmation module 3410 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 an end operation 3412 , corresponding to completion of the time synchronization process.
  • the system 3500 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.
  • the system 3500 compensates for this discrepancy when storing event log data, and also when providing it to users for review. Operational flow within the system 3500 commences at a start operation 3502 , corresponding to initial communication of event data from medical devices to the medical device server.
  • a receipt module 3504 corresponds to the medical device server receiving event log data from one or more of the medical devices.
  • 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 time zone modification module 3506 converts the time stamp information from the local time zone of the medical device to a constant time zone. In one embodiment, the time zone modification module 3506 converts the time stamp to the Universal Time Protocol (UTP).
  • UTP Universal Time Protocol
  • a storage module 3508 stores the converted time stamp and associated event log data in the medical device server or back office components.
  • An optional global tracking module 3510 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 request local event module 3512 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 request local event module 3512 generates a query for the event data requested, and returns results including event log data.
  • a conversion module 3514 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.
  • the conversion module 3514 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 the system 3500 is terminated at an end operation 3516 , which corresponds to completion of the conversion module 3514 .
  • a generalized web service architecture which manages user access to a medical device server in a medical device network, such as the one shown in FIG. 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 of FIG. 1 .
  • 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.
  • FIG. 36 shows an overall web service architecture 3600 , shown as a subsystem of the possible software architectures of the medical device network in FIGS. 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.
  • the web service architecture is implemented in a .NET architecture using Internet Information Server, by Microsoft Corporation.
  • the web service architecture 3600 includes an administrative web service 3602 , an operations web service 3604 , and an event tracking web service 3606 .
  • the administrative web service 3602 validates users of the medical device server, and includes functional interfaces for logging in, logging out, and changing a user password.
  • the administrative web service 3602 tracks information related to products, customers, contact information, medical devices associated with the customers, user accounts associated with a customer, and other variables.
  • the administrative web service 3602 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 the administrative web service 3602 is described in Part IV.A, below.
  • the operations web service 3604 provides access to operational data of the medical devices, such as operational data regarding therapy delivery or monitoring data.
  • the operations web service 3604 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 the operations web service 3604 is described in Part IV.B, below.
  • the event tracking web service 3606 tracks various event data occurring in a medical device, such as telemetry data received by a medical device server.
  • the event tracking web service 3606 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 tracking web service 3606 is described in Part IV.C, below.
  • FIG. 37 shows an exemplary class structure defining an administrative web service 3700 .
  • the administrative web service 3700 provides a possible embodiment of the administrative web service 3602 of FIG. 36 , and is accessible via any of a number of user interfaces, such as the administration web forms 324 of FIG. 3 .
  • the administrative web service 3700 includes an authentication class 3702 , an authorization class 3704 , a user class 3706 , a role class 3708 , a license class 3710 , a resource class 3712 , a metadata class 3714 , and an entity settings class 3716 .
  • 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.
  • the authentication class 3702 provides the initial access to the administrative web service 3700 , and includes login and logout functionality.
  • the authorization class 3704 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 the authorization class 3704 include read, write, create, delete, and access permission functions. Other functions may be incorporated into the authorization class 3704 as well.
  • the user class 3706 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.
  • the role class 3708 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.
  • the license class 3710 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.
  • the resource class 3712 allows an administrator to add and delete resources, which correspond to the specific functional areas of the medical device server.
  • the metadata class 3714 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 in FIGS. 42-43 .
  • the entity settings class 3716 allows writing and retrieval of entity settings. Additional administrative functionality, including additional classes, may be incorporated into the administrative web service 3700 as well.
  • FIGS. 38-41 display sample administrative reports accessible to a user.
  • the administrative reports of FIGS. 38-41 correspond to the reports 326 shown in FIGS. 3-4 , and are derived from information stored in the data warehouse 322 related to administrative events logged by the medical device server.
  • 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 administration tracking event report 3800 .
  • 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 the administration data 316 of FIG. 3 that match the query presented to the administrative web service.
  • the administration tracking event report includes time and date information 3802 , application information 3804 , and message information 3806 . Additional information, such as the code information, time zone indicator, and other information can be optionally included in the report 3800 .
  • the time and date information 3802 display the time stamp information related to the event tracked by the administrative module.
  • the time and date information 3802 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 the report 3800 shown, the local time zone option is selected.
  • the application information 3804 indicates the service or handler accessed, and the message 3806 indicates the action taken with respect to that service or handler.
  • exemplary connection events are shown for two medical device servers, labeled “MDS:Mds01” and “MDS:Mds02”.
  • FIG. 39 displays a security event report 3900 .
  • the security event report 3900 corresponds generally to the administration tracking event report 3800 , but includes events related to security of the medical device server rather than access to it.
  • the security event report 3900 includes time and date information 3902 , application information 3904 , and message information 3906 , each of which have the same functionality as in the administration tracking event report 3800 .
  • FIG. 40 displays a security event trending report 4000 .
  • the security event trending report 4000 displays a chart of security related events over time.
  • the security event trending report 4000 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 a user history report 4100 .
  • the user history report displays a chronologically ordered list of events logged regarding one or more users. Each entry in the list includes time and date information 4102 , a sorting code 4104 , a username 4106 corresponding to the active user, and a message 4108 related to the action taken by that user.
  • An optional details entry 4110 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.
  • FIGS. 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 the administrative applications 324 of FIGS. 3-4 .
  • FIGS. 47-50 display reports displaying the results of installation of the metadata and packages, and are a subset of the reports 326 available from the data warehouse 322 in FIGS. 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 an initial user interface 4200 showing the metadata packages either currently installed into the medical device server or available to be installed.
  • a listing area 4202 lists the packages, in this case displayed as “Virtual Infusion Pump”, “Virtual Patient Monitor”, and “Medfusion 4000 ”.
  • Check boxes 4204 in the listing area allow user selection of one or more of the installed packages, an install button 4206 installs the packages into the medical device server, and an uninstall button 4208 removes metadata packages from the medical device server.
  • FIG. 43 displays a metadata installation interface 4300 configured to allow a user to browse for a metadata file and install that file onto the medical device server.
  • the metadata installation interface 4300 appears following selection of one of the types of medical devices present in the system in the user interface 4200 , and allows the user to select and install a metadata file associated with the previous selection of metadata using the initial user interface 4200 .
  • FIG. 44 displays a package deployment interface 4400 providing deployment of packages for distribution to one or more medical devices, as described above in Part III.C.
  • the package deployment interface 4400 generally corresponds to the metadata installation interface 4200 of FIG. 42 , but relates to software to be installed onto a medical device, rather than into the medical device server.
  • a listing area 4402 lists the packages, in this case displayed as “Simple Infusion Pump” or “TestPackage”.
  • Check boxes 4404 in the listing area allow user selection of one or more of the installed packages, a deploy button 4406 deploys the packages into the medical device server, and an uninstall button 4408 removes the packages from the medical device server.
  • a user interface 4500 shown in FIG. 45 is displayed.
  • the user interface 4500 allows system administrators to enter a package deployment name into a name field 4502 , 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 deployment file selection field 4508 .
  • the system administration presses a deploy button 4510 to deploy the package, or a cancel button 4512 to cancel deployment.
  • a further user interface 4600 shown in FIG. 46 is displayed to allow user verification that the correct package has been selected for download to medical devices.
  • the user interface 4600 displays package deployment details in a package information field 4502 , including the selected start time, end time, and target type as entered in the previous user interfaces 4400 , 4500 .
  • the user interface 4600 further displays vendor properties in a vendor field 4504 , such as the vendor identifier, name, and version of the vendor package.
  • FIGS. 47-50 display various reports generated from the data warehouse 322 of FIGS. 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 a quarantine report 4700 , which displays a chronological list of the quarantined messages received by the medical device server.
  • the quarantine report 4700 includes time and date information 4702 , state information 4704 , and message information 4706 .
  • the time and date information 4702 display the time stamp information related to the quarantine event tracked by the medical device server.
  • the time and date information 4702 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 the report 4700 shown, the local time zone option is selected.
  • the state information 4704 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.
  • the message information 4706 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 a quarantine detail report 4800 , which is configured to display the details of a specific quarantined message received by the medical device server.
  • the quarantine detail report includes an error field 4802 including the error information displayed on the quarantine report 4700 , and a source field 4804 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 a package deployment report 4900 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 more package deployment entries 4902 , each including name and version information related to the specific package being deployed to that type of device.
  • Each of the package entries includes device sub-entries 4904 , each of which relates to a specific device qualifying for the generalized package deployment.
  • the sub-entries each include host name information 4906 , physical identification information 4908 , notification information 4910 , transfer information 4912 , and completion information 4914 .
  • the host name information 4906 corresponds to the medical device server providing the package to the device.
  • the physical identification information 4908 displays the unique identifier associated with the medical device.
  • the notification information 4910 displays the date and time at which the medical device was notified that the package was available.
  • the transfer information 4912 displays the date and time at which the package was successfully transferred to the medical device.
  • the completion information 4914 displays the full date and time at which the package was successfully applied to the medical device.
  • an error indication 4916 displays an indication of an error, and a result of the error.
  • FIG. 50 displays a package deployment error report 5000 .
  • the package deployment error report 5000 provides a detailed event history for the specific packages and corresponding devices for which a package deployment fails.
  • the package deployment error report 5000 displays a title 5002 including the target medical device type and package identifier. The title also optionally displays a name associated with the package deployment.
  • the package deployment error report 5000 displays time and date information 5004 , optional host information 5006 , physical identifier information 5008 , and message information 5010 .
  • the time and date information 5004 indicate when the error in the package deployment occurred.
  • the optional host name information 5006 displays the network name in which the medical device is located.
  • the physical identifier information 5008 includes the identifier associated with the medical device.
  • the message information 5010 displays the message associated with the package deployment error. Additional information regarding the deployment error may be included in the report 5000 as well.
  • FIGS. 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.
  • one or more of the reports of FIGS. 51-53 correspond to the maintenance forms 330 of FIGS. 3-4 .
  • FIG. 51 shows a medical device maintenance report 5100 listing maintenance records for various medical devices.
  • the medical device maintenance report 5100 includes type entries 5102 corresponding to various types of medical devices, and device sub-entries 5104 corresponding to specific medical devices.
  • the type entries 5102 are the “MedFusion 4000 ” and “Titan” entries, while the device sub-entries 5104 are the individual rows within each type.
  • each sub-entry 5104 there exists host name information 5106 , physical identifier information 5108 , version information 5110 , package information 5112 , and preventative maintenance date information 5114 .
  • the host information 5106 displays the network associated with the medical device.
  • the physical identifier 5108 displays the unique identifier associated with the medical device.
  • the version information 5110 displays one or more version numbers associated with the medical device.
  • the package information 5112 displays packages being used by the medical device.
  • the preventative maintenance information 5114 displays a date at which the medical device is due for preventative maintenance. Additional information can be displayed within each sub-entry 5104 as well.
  • FIG. 52 shows a medical device fault report 5200 .
  • the medical device fault report 5200 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 medical device fault report 5200 includes time and date information 5202 , host information 5204 , physical identifier information 5206 , and message information 5208 .
  • Use of the information 5202 - 5208 is analogous to the corresponding elements in the package deployment error report 5000 of FIG. 50 , but related to medical device fault events.
  • 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 device fault trending report 5300 .
  • the medical device fault trending report 5300 displays a chart of medical device fault related events over time.
  • the medical device fault trending report 5300 provides users with an indication of repeated errors in a medical device, or other detectable trends in medical device faults.
  • the medical device fault trending report 5300 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.
  • FIGS. 54-62 disclose various aspects of the operations web service 3604 of FIG. 36 .
  • the figures show systems, methods, and reports for remote operation of the medical devices in a medical device network.
  • 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.
  • the system 5400 includes states corresponding to the various possible states experienced in the medical device during execution of the therapy order.
  • Operational flow within the system 5400 commences at a start node 5402 , which corresponds to introduction of a new therapy order into the medical device or medical device server. Once the therapy order is introduced, the system 5400 enters a new state 5404 , indicating that the therapy order is newly introduced and has not yet been executed by the medical device. When the system 5400 is in the new state 5404 , a user has the option to cancel the therapy order. If the user chooses to cancel the therapy order, operational flow in the system 5400 proceeds to a canceled state. 5406 . From the canceled state, operational flow proceeds to an end node 5408 corresponding to completion of the therapy module. At the end node 5408 , operational flow terminates and therapy delivery events tracked using the medical device server continue to be stored for review by a user.
  • assisted setup state 5410 attempts to assist in setting up the therapy parameters. If the assisted setup is unsuccessful operational flow branches to a failed state 5412 .
  • the failed state 5412 stores an error message indicating that the assisted setup process failed. Operational flow proceeds from the failed state 5412 to the end node 5408 .
  • setup state 5414 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 the system 5400 to proceed to a started state 5416 , 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 the system 5400 to proceed to a complete state 5418 , indicating that delivery of the therapy is complete. Operational flow next proceeds to the end node 5408 .
  • FIG. 55 shows an exemplary class structure defining a therapy service 5500 .
  • the therapy service 5500 illustrates a portion of the functionality of the operations web service module 3604 .
  • the therapy service 5500 links to and uses a variety of functions from the administrative web service 3700 of FIG. 37 .
  • the therapy service 5500 includes a therapy order class 5502 , a therapy order rule utility 5504 , and a therapy order action enumeration 5506 .
  • the therapy order class 5502 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 the therapy service 5500 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 the therapy order class 5502 as well.
  • the therapy order rule utility 5504 provides expressions and actions related to execution of the therapy order, including various parameters and commands required for execution of the therapy.
  • the therapy order action enumeration 5506 provides advisory messages used during selection and/or execution of a therapy order.
  • FIG. 56 displays exemplary message exchange processes 5600 , 5620 , 5640 , and 5660 performed between a therapy order management application 5602 , an operations web service 5604 such as the one shown in FIG. 36 , a medical device server 5606 as disclosed above in FIGS. 3-4 , and a medical device 5608 , such as shown in FIG. 2 .
  • the therapy order management application 5602 can be any application configured to interface with the operations web service to communicate therapy orders and other messages to the operations service 5604 and medical device server 5608 .
  • a first message exchange process 5600 illustrates the therapy order management application 5602 transmitting a create therapy order message 5610 to the operations web service 5604 .
  • the operations web service 5604 verifies the therapy information and stores the therapy order in operations data.
  • the operations web service 5604 also responds 5612 by indicating success or failure of the message.
  • a second message exchange process 5620 illustrates the therapy order management application 5602 later in time transmitting a therapy order update message or a therapy order cancellation message 5622 .
  • the operations web service 5604 verifies the therapy information, and updates or cancels the therapy order according to the message.
  • the operations web service 5604 also responds 5624 by indicating success or failure of the message.
  • a third message exchange process 5640 occurring after the first message exchange process 5600 illustrates the therapy order management application 5602 transmitting a message 5642 indicating that the therapy order should be executed.
  • the therapy order management application 5602 transmits an execute therapy order message 5642 to the operations web service 5604 , which verifies the therapy order and in turn forwards the therapy order message 5642 to the medical device server 5606 .
  • the medical device server 5606 relays the therapy order message 5642 to a medical device 5608 .
  • the medical device 5608 transmits a message 5644 indicating the success or failure of receipt of the therapy order message 5642 .
  • the medical device server 5606 and operations web service 5604 relay the message 5644 back to the order trigger application 5602 .
  • the medical device 5608 initiates a fourth messaging process 5660 in which the medical device transmits a therapy begin message 5662 to the medical device server 5608 , indicating that the medical device has begun delivering the therapy to a patient.
  • the medical device server 5608 transmits the message 5662 to the operations web service 5604 , which updates the therapy order state.
  • the medical device server also relays the message 5662 to an event tracking web service 5605 , such as the one in FIG. 36 , to store a therapy delivery event in an event history log. Both the event tracking web service 5605 and the operations web service 5604 transmit response messages 5664 indicating the success or failure of receipt of the therapy begin message 5662 .
  • Additional events triggered by the medical device such as a therapy completion event or alarm, transmit among the components 5602 - 5608 analogously to the messaging process 5660 . 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.
  • the system 5700 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.
  • the system 5700 commences at a start operation 5702 , 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 original parameter receipt module 5704 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 updated parameter receipt module 5706 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 final parameter receipt module 5708 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.
  • the receipt modules 5704 - 5708 may occur concurrently or sequentially, and may be included in one or more messages from the medical device to the medical device server.
  • a parameter storage module 5710 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 the system 5700 can include comparing the final parameter value received in the final parameter receipt module 5708 with a hard limit or soft limit stored in the medical device server. If the final parameter value exceeds the limit, the system 5700 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 an end operation 5712 , 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 medical device history report 5800 listing original, updated, and final operational parameter values for a medical device according to the methods and systems of FIG. 57 .
  • the medical device history report 5800 includes a medical device label 5802 , date and time information 5804 , class information 5806 , trigger information 5808 , message information 5810 , location information 5812 , and drug information 5814 .
  • the medical device label 5802 corresponds to the medical device name for the device whose history is displayed in the report 5800 .
  • the date and time information 5804 correspond to the time the various events occurred that are included in the medical device history report.
  • the class information 5806 describes the type and severity of the event. In the case of a therapy change event, the class information 5806 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.
  • the trigger information 5808 displays the trigger associated with the medical device event.
  • an event in an alarm classification has a high level of concern, and includes a warning in the trigger information 5808 .
  • an event describing a therapy change will not activate the trigger information 5808 .
  • the message information 5810 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.
  • the location information 5812 includes information related to the location of the medical device, such as the department, the facility, and the entity controlling the medical device.
  • the drugs information 5814 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 medical device history report 5800 , based on the information tracked by the medical device server and operations web service.
  • FIG. 59 shows a therapy history report 5900 .
  • the therapy history report 5900 displays the same information as is displayed in the medical device event history report 5800 of FIG. 58 , but will only display therapy event information.
  • the therapy history report 5900 includes a medical device label 5902 , date and time information 5904 , class information 5906 , trigger information 5908 , message information 5910 , location information 5912 , and drug information 5914 , each of which operate analogously to the corresponding entries in the medical device event history report 5800 .
  • FIG. 60 shows a therapy trending report 6000 .
  • the therapy trending report 6000 displays a chart of therapy related events over time.
  • the therapy trending report 6000 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 therapy change history report 6100 .
  • the therapy change history report 6100 also displays the same information as is displayed in the medical device event history report 5800 of FIG. 58 , but only displays therapy change event information. Therapy change events correspond to changed parameters in delivering a therapy using a medical device.
  • the therapy change history report 6100 includes a medical device label 6102 , date and time information 6104 , class information 6106 , trigger information 6108 , message information 6110 , location information 6112 , and drug information 6114 , each of which operate analogously to the corresponding entries in the medical device event history report 5800 and the therapy history report 5900 .
  • FIG. 62 shows a therapy change trending report 6200 .
  • the therapy change trending report 6200 displays a chart of therapy change events over time.
  • the therapy change trending report 6200 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.
  • Event Web Service On-Line Status and Viewing of Device Activity
  • the event web service provides a method by which external applications collect event data from the medical device server and back office components.
  • 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 and 3 - 4 .
  • FIG. 63 is a flowchart of methods and systems for determining the on-line status of a medical device.
  • the system 6300 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 the system 6300 commences at a start operation 6302 , which corresponds to initial communication between a medical device and a medical device server. Operational flow proceeds from the start operation 6302 to an expectation module 6304 .
  • the expectation module 6304 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 receive data operation 6306 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 an update module 6308 , which updates the status of the medical device to indicate that the device is on-line.
  • An optional output update module 6310 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.
  • 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.
  • the output update module updates medical device status information in one or more of the back office components.
  • Operational flow proceeds through the receive data operation 6306 , the update module 6308 , and the output update module 6310 so long as the medical device continues in operation and the receive data operation 6306 determines that the medical device server continues to send messages to the medical device within the predetermined period.
  • the operational flow branches “no” to an offline module 6312 , 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 optional output update module 6310 , 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 an end module 6314 , 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 the system 6400 commences at a start node 6402 , which corresponds to initial operation of a medical device capable of transmitting a telemetry stream in a medical device network.
  • a new state 6404 indicates that the telemetry stream has not previously been running.
  • a stream startup process attempts to start the telemetry stream, as shown in FIG. 65 , below. If the stream startup process fails, operational flow proceeds to a failed state 6406 , corresponding to failure to start the telemetry stream. Operational flow then proceeds to an end node 6408 .
  • a collecting state 6410 corresponds to the medical device server collecting telemetry data from the medical device.
  • 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.
  • a number of possible options affect operational flow of the system 6400 . 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 an offline state 6412 .
  • the offline state 6412 corresponds to the system no longer regularly receiving telemetry data. If a telemetry report is later received, the system 6400 returns to the collecting state 6410 .
  • a paused state 6414 corresponding to a system which only temporarily is not receiving telemetry data.
  • the user can resume the telemetry stream to return the system 6400 to the collecting state.
  • a terminated state 6416 can be reached from the collecting state 6410 , the offline state 6412 , or the paused state 6414 by the user terminating the stream or the system otherwise receiving a medical device power off event.
  • the terminated state 6414 corresponds to ending the telemetry stream.
  • the system no longer receives information from the medical device, and the dashboard is not updated.
  • 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 the end node 6408 .
  • FIG. 65 displays exemplary telemetry stream message sequences 6500 , 6520 , 6540 , and 6560 performed among: a dashboard 6502 , such as the one shown in FIG. 67 ; an event tracking web service 6504 , such as the one shown in FIG. 36 ; a medical device server 6506 , as disclosed above in FIGS. 3-4 ; and a medical device 6508 , such as shown in FIG. 2 .
  • a first telemetry stream message sequence 6500 illustrates a request to initiate a telemetry stream from a medical device to a dashboard.
  • the message sequence 6500 starts by the dashboard 6502 sending a start telemetry stream message 6510 to the event tracking web service 6504 .
  • the event tracking web service communicates the message 6510 to the medical device server 6506 , which in turn communicates the message 6510 to the medical device 6508 .
  • the medical device generates a response message 6512 indicating success or failure of the message.
  • the response message is related back to the dashboard 6502 by the medical device server 6506 and event tracking web service 6504 .
  • a second telemetry stream message sequence 6520 illustrates initiation of a telemetry stream by a medical device 6508 .
  • the medical device 6508 generates a telemetry event 6522 , which includes near-continual communication of telemetry data from the medical device 6508 to the medical device server 6506 , which relays the telemetry data to the dashboard 6502 via the event tracking web service 6504 .
  • the dashboard 6502 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 a response message 6524 to the event tracking web service 6504 , indicating successful receipt of the telemetry stream.
  • the dashboard 6502 generates a get telemetry window message 6526 and transmits the message to the event tracking web service, which responds with a message 6528 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.
  • the event tracking web service 6504 will respond with a fail message and will terminate the telemetry stream.
  • a third telemetry stream message sequence 6540 illustrates ending a telemetry stream by shutting off the medical device generating the telemetry stream.
  • the medical device 6508 generates a power off event message 6542 and sends the message to the medical device server 6506 .
  • the medical device server sends a terminate telemetry stream message to the event tracking web service 6504 .
  • the event tracking web service 6504 generates a response message 6544 indicating success or failure of receipt of the message 6542 .
  • the medical device server 6506 relays the response message 6544 to the medical device 6508 .
  • a fourth telemetry stream message sequence 6560 relates to the sequence 6540 and illustrates ending a telemetry stream by discontinuing the telemetry stream at the dashboard 6502 .
  • the dashboard 6502 generates a terminate telemetry stream message 6562 , which is communicated from the dashboard to the event tracking web service 6504 , and in turn through the medical device server 6506 to the medical device 6508 .
  • the medical device 6508 terminates its telemetry stream and generates a response message 6564 indicating success or failure of receipt of the message 6562 .
  • the medical device server relays the message 6564 through the event tracking web service 6504 to the dashboard 6502 . 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 a telemetry stream class 6600 .
  • the telemetry stream structure 6600 illustrates a portion of the functionality of the event web service module 3606 .
  • the telemetry stream relates back to and uses a variety of functions from the administrative web service 3700 of FIG. 37 .
  • the telemetry stream structure 6600 includes a telemetry stream class 6602 and a latest event class 6604 .
  • the telemetry stream class 6602 includes a variety of telemetry-related operations, including starting, terminating, pausing, and retrieving available telemetry streams. Additional telemetry stream operations can be included in the telemetry stream class 6602 as well.
  • the latest event class 6604 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 the latest event class 6604 , and additional classes can be added to the telemetry stream structure 6600 .
  • FIG. 67 One example dashboard is shown in FIG. 67 .
  • the dashboard 6700 displays telemetry data (e.g. current or near-current operational status) relating to the pumps with which it is associated.
  • the dashboard 6700 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 as dashboard 328 of FIGS. 3-4 .
  • the dashboard 6700 can be updated by a telemetry stream, such as described above in FIGS. 64-66 .
  • the dashboard 6700 tracks a name 6702 , identifier 6704 , domain 6706 , address 6708 , port 6710 , and activity history 6712 , with respect to each medical device associated with the dashboard.
  • the name 6702 corresponds to a name of a device recognizable to a user, assigned by either the device itself or the server.
  • the identifier 6704 provides a unique identification useable by the server to verify the identity of the medical device.
  • the identifier can correspond to a globally-unique identifier (GUID), hardware address, or other identification of the medical device.
  • GUID globally-unique identifier
  • the domain 6706 indicates the name of a network in which the medical device resides.
  • the address 6708 provides connection information regarding how to communicate with the medical device from the server.
  • the address 6708 is shown as an IP address of the medical device.
  • the port 6710 lists the inbound communication port for the medical device.
  • the activity history field 6712 lists a date and time of the last event occurring on the medical device and communicated to the server.
  • the dashboard 6700 graphically illustrates an operational status of the pumps with which it is associated.
  • five medical devices are tracked in the dashboard 6700 , named “MD0333”, “MD0444”, “MD0524”, “MD0324”, and “MD0988.”
  • the first, fourth, and fifth devices 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 the dashboard 6700 as well.
  • a pause check box 6714 and an offline devices check box 6716 allow a user to selectably modify the dashboard.
  • the pause check box 6714 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.
  • the status information on the dashboard can continually update as data is received from the associated medical devices.
  • the offline devices check box 6716 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.

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 server is disclosed which includes a memory configured to store identification information regarding a plurality of medical devices at different customer sites, and a programmable circuit operatively connected to the memory. The programmable circuit is configured to execute program instructions to receive data from medical devices at one or more of the different customer sites, store data in the memory associated with the one or more different customer sites, and associate a portion of the data with the medical device that transmitted that portion of data.

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 server is disclosed which includes a memory configured to store identification information regarding a plurality of medical devices at different customer sites, and a programmable circuit operatively connected to the memory. The programmable circuit is configured to execute program instructions to receive data from medical devices at one or more of the different customer sites, store data in the memory associated with the one or more different customer sites, and associate a portion of the data with the medical device that transmitted that portion of data.
  • In a second aspect, a server network is disclosed. The network includes a plurality of medical devices at different customer sites, and a server operatively connected to the plurality of medical devices. The server includes a memory configured to store identification information regarding a plurality of medical devices at different customer sites, and a programmable circuit operatively connected to the memory. The programmable circuit is configured to execute program instructions to receive data from medical devices at one or more of the different customer sites, store data in the memory associated with the one or more different customer sites, and associate a portion of the data with the medical device that transmitted that portion of data. The server network further includes a workstation at one of the customer sites, the workstation communicatively connected to the server and configured to request data related to the customer site.
  • 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 of FIG. 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 of FIG. 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 to FIGS. 1 and 2, a generalized hardware environment is described. FIG. 1 shows an exemplary medical device network 100 in which aspects of the present disclosure may be implemented. The medical device network 100 provides a method by which a variety of medical devices and communication systems intercommunicate. The medical device network 100 includes a medical device server 102 interconnected with a variety of types of medical devices. The medical devices can include an active medical device 104, a passive medical device 106, and a plurality of exemplary medical devices shown to be medical infusion pumps 108.
  • The active medical device 104 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 active medical device 104 is a medical infusion device, such as the medical infusion pumps 108 shown.
  • The passive medical device 106 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.
  • The medical device server 102 communicates with the medical devices, and is one or more generalized or application-specific computing systems. The medical device server 102 is configured to store and retrieve data received from the various medical devices 104, 106, 108. The data received by the medical device server 102 can include event log data, programming data, and various other data transmitted to the server 102 from the medical devices 104, 106, 108.
  • Optionally, the medical device network 100 includes additional computing devices, such as workstations 110 and portable computing systems 112, configured to allow communicative connection to the medical device server 102. The workstations 110 and portable computing systems 112 are generalized computing systems or thin client computing systems having a communication interface allowing access to the medical device server. The workstations 110 and portable computing systems 112 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 the medical device server 102 via the workstation 110 or portable computing system 112 to retrieve data gathered from a medical device, and may instruct the medical device server 102 to communicate various messages or software packages to one or more of the medical devices.
  • The medical device network 100 optionally includes network infrastructure components, such as a switch 114 and a wireless access point 116. The network infrastructure components are configured to provide the communication infrastructure between the various medical devices 104, 106, 108, the medical device server 102, and any additional computing systems 110, 112. Although the medical device network 100 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, the switch 114 and wireless access point 116 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 the network 100 as well.
  • The medical device server 102, 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 a medical device 200. The medical device 200 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, the medical device 200 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.
  • The medical device 200 includes a programmable circuit 202 interfaced to a memory subsystem, including, for example, Random Access Memory (RAM) 204, a flash memory 206, and an electrically erasable, programmable memory (EEPROM) 208. The RAM 204 stores operational parameters of the medical device, as well as any non-critical storage with respect to operational data or instructions. The flash memory 206 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. The EEPROM 208 stores a set of initial instructions that are used by the medical device 200 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. The EEPROM 208 optionally includes firmware or instructions which may be read or copied into the RAM 204 or flash memory 206 for execution, as necessary.
  • In various embodiments of the medical device 200, 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.
  • The medical device 200 further includes a battery system 210 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, the battery system 210 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, the battery system 210 includes different types of battery systems, such as a rechargeable battery system including a nickel-cadmium battery.
  • The medical device 200 includes an input device 212 and an output device 214 interfaced to the programmable circuit 202. The input device 212 allows a user at the location of the medical device to adjust the activity of the device. The input device 212 can be, for example, a mouse, keyboard, keypad, trackball, touch screen, control buttons, or other user-controllable devices. The output device 214 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, the output device 214 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 the medical device 200.
  • The medical device 200 also includes a display device 216 and an alarm 218. The display device 216 is a visual device capable of displaying information to a user of the device. In various embodiments of the medical device 200, the display device 216 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 a display device 216, in alternate embodiments a display device is not required. The alarm 218 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.
  • A wired communication interface 220 provides a data communication connection from the medical device 200 that interfaces with a medical device server or other generalized computing system. The wired communication interface 220 interfaces to the programmable circuit 202, and sends and receives data from the medical device 200. In various embodiments, the wired communication interface 220 can be an Ethernet or other data connection capable of communicating and receiving digital data.
  • A wireless communication interface 222 provides an alternative communication interface to the wired communication interface 220, such that the medical device 200 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. The wireless communication interface 222 interfaces to the programmable circuit 202, 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.
  • The medical device 200 also includes a patient interface 224. The patient interface 224 controls the mechanical component of the medical device 200 which monitors or delivers a therapy to the user. The patient interface 224 varies among the different types of medical devices based upon the function of the device. In the case where the medical device 200 is a monitor, the patient interface 224 may include a sensor or other physical detection equipment. In the case where the medical device 200 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 the medical device 200, depending upon the particular application to which the device is directed.
  • II. Overall Software Environment
  • FIGS. 3-6 show an overall software environment for the medical device network 100 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 in FIGS. 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 of FIGS. 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.
  • 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. 3 shows a software architecture 300 in which aspects of the present disclosure are implemented. The software architecture 300 provides an operating environment in which medical device data can be stored and managed remotely from the medical devices. The software architecture 300 also provides an extensible architecture in which a variety of types of medical devices can operate. The software architecture 300 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. The software architecture 300 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 in FIG. 1.
  • In one embodiment, aspects of the software architecture 300 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 using Microsoft 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.
  • The software architecture 300 includes one or more medical devices 302, back office components 304, and client applications 306. The medical devices 302 monitor or deliver therapies to patients, as directed by a caregiver. The medical devices 302 can be any of a variety of programmable medical devices such as those discussed in conjunction with FIGS. 1-2, above.
  • The back office components 304 include one or more medical device servers 308, an administration module 310, an event tracking module 312, and an operations module 314. The medical device server 308 manages communication with the various medical devices 302 associated with the back office components 304, such as by relaying messages between the various modules 310, 312, 314 and the medical devices 302. The medical device server 302 creates messages understandable to the medical devices 302 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 the medical devices 302, the medical device server 308 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, the medical device server 302 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, the medical device server 308 resides on a computing system which also hosts the additional back office components 304. In a further embodiment, the medical device server resides on separate computing hardware from the other back office components. In such systems, the medical device server 308 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 in FIGS. 4-5, below. For simplicity, throughout the description of the software aspects the term medical device server is intended to encompass either the medical device server 308 or the back office components 304 as a whole, depending upon the specific implementation chosen. In certain embodiments, the medical device server 308 can be placed on one or more physical computing platforms, resulting in the presence of multiple medical device servers.
  • The administration module 310 provides an interface to administration data 316, which the medical device server 308 and client applications 306 can request for various reasons, such as to allow access to event or operational data, described below. The administration data 316 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, the administration data 316 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 the administration data 316 and managed by the administration module 310 as well.
  • The administration data 316 also defines the capabilities of the various medical devices 302 managed within the environment 300, by defining operational parameters by which the medical device server 308 interfaces with a medical device 302. 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, the environment 300 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, the administration module 310 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 the back office components 304. In a further embodiment, the administration module provides an interface allowing remote applications to access the data managed by the back office components 304.
  • The event tracking module 312 provides an interface to the medical device server 308, and organizes and manages event data 318. The event data 318 corresponds to the historical data regarding various events occurring in the medical devices 302, which are collected and routed by the medical device server 308. The event data 318 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 the event tracking module 312 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 with FIGS. 19-24. In a particular embodiment, the event tracking module 312 generates a web interface accessible by the medical device server 308 to transfer data to a storage location of event data 318.
  • The operations module 314 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 various medical devices 302 associated with the environment 300. The operations module 314 also provides a web interface to the medical device server 308 for managing the various types of operations data 320, and to various external computing systems to allow those systems to view the operations data 320 and transmit commands within the software architecture 300, such as to the various medical devices 302.
  • An optional data warehouse 322 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 warehouse 322, which aggregates various data from the administration data 316, the event data 318, and the operations data 320. The data warehouse 322 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 warehouse 322 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 warehouse 322, its functionality as described herein can be provided by the Administration, Event Tracking, Operations databases and their corresponding modules, as described herein.
  • The client applications 306 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. The client applications 306 accessing the back end components 304 include administration applications 324, reporting applications 326, dashboards 328, maintenance forms 330, and various additional external applications 332.
  • The administration applications 324 provide user access to the administration data 316 include a variety of administration web forms, to define usage rights for other users attempting to access the back office components 304, as well as to define the operational parameters of the medical devices 302. Additional administration web forms may be included as well.
  • The reporting applications 326 provide a number of standardized reports based on the administration data 316, the event data 318, and the operation data 320. In an embodiment in which the back office components 304 include a data warehouse 322, the reports may be based on the information in the data warehouse. Examples of reports built using the various types of data tracked in the back office components 304 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.
  • The dashboards 328 allow a caregiver or user to view the status of a medical device 302. The dashboards 328 are based on operation data, and interface to the operations module 310. The dashboards 328 available within the environment 300 correspond to the various medical devices 302 capable of frequently transmitting data to the back office components 304. The dashboards 328 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, the dashboards 328 replicate the visual interface of the corresponding medical device, but in a web-portal format.
  • The maintenance forms 330 display maintenance information to a caregiver or other user of the medical devices 302. The maintenance forms 330 display tracked maintenance information included in the operations data 320, such as performed maintenance, scheduled maintenance, suggested maintenance, and maintenance trends. The maintenance forms 330 also allow the user to deploy various updates to the medical devices 302, such as firmware updates and other software deployments. In a possible embodiment, the operations data 320 includes maintenance schedule information accessible by users via the maintenance forms. In such an embodiment, the maintenance forms 330 display a maintenance schedule to a user, including future maintenance required for various medical devices 302 as well as historical maintenance events tracked in the operations data 320.
  • Various external applications 332 extend the functionality of the software environment 300 by communicating with the operations module 314. The external applications 332 include any applications useable to extend the functionality of the software environment 300.
  • FIG. 4 displays an alternative software infrastructure 400 to the one shown in FIG. 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, the medical devices 302 and medical device server(s) 308 may reside at one or more hospitals or health care facilities 404, 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 organization 405 contracting to manage the data of the various facilities at an off-site location. That entity can collect information from the medical device server 308 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 in FIG. 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 the system 500 of FIG. 5 commences at a start operation 500, which corresponds to initialization of the system 500, such as by operation of various medical devices connected to a medical device server.
  • A data receipt module 504 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, the data receipt module 504 corresponds to receipt of various administrative data, event data, or operations data from a medical device server or client applications, as shown in the back office components 304 of FIG. 4.
  • An association module 506 associates the data received in the data receipt module 504 with the medical devices from which the data is received. In one possible embodiment, the association module 506 associates the data with the various locations at which the medical devices reside, or with the various entities controlling the devices, as defined in the administration data 316. The data association can be a logical or physical relationship between the data, such as can be found in a file, table, or database.
  • The association module 506 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 the association module 506. 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.
  • An optional program module 508 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 the data receipt module 504 and the association module 506, 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 an end operation 510, 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 of FIG. 1, in which medical device actions are interconnected. The system 600 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. The system 600 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 the system 600 commences at a start operation 602, which corresponds to initial monitoring of a patient using a plurality of medical devices connected to a medical device network. The start operation 602 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.
  • A status receipt module 604 receives a status of a patient from a first medical device used to monitor or administer a therapy to the patient. In one example, the status receipt module 604 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.
  • A determination module 606 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. The determination module 606 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 the determination module 606, 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, the determination module 606 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.
  • A program module 608 generates programming for a target medical device capable of providing the changed or additional therapy or monitoring determined in the determination module 606. The program module 608 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, the program module 608 requests that a caregiver approves the suggested therapy determined in the determination module 606. In a further embodiment, the program module 608 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 an end operation 610. The end operation 610 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 in FIGS. 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 to FIGS. 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 exemplary extensible system 700 in which a medical device server associates with a remotely located medical device. The system 700 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 the system 700, every medical device recognized by a medical device server will have an associated state held in a table on the server. Therefore, the system 700 will execute independently on the server for each medical device associated with the server. The system 700 commences at a start node 702 corresponding to connection of the medical device to a medical device network including a medical device server, such as the one shown in FIG. 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 known state 704, 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 known state 704 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 known state 704, 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 a determination node 706, 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: a powered state 708, a therapy state 710, a fault state 712, and an alarm state 714. The powered state 708 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. The powered state 708 is entered from the known state 704 or the determination node 706 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 state 710, the fault state 712, and the alarm state 714, 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 state 710 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. The system 700 can enter the therapy state from any of the other operational states 708, 712, 714, or from the determination node 706. 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 the powered state 708. 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.
  • The fault state 712 corresponds to an error occurring in the medical device, such as a malfunction in the operation of the device during monitoring or therapy delivery. The fault state 712 can be entered from either the powered state 708 or the therapy state 710, and can also be entered from the determination node 706. In a possible embodiment, the fault state 712 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 the powered state 708 if returning from the determination node 706. 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.
  • The alarm state 714 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. The alarm state 714 can be entered from either the powered state 708 or the therapy state 710, and can also be entered from the determination node 706. 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.
  • A nonoperative state 716 may be entered from any of the active states, including the powered state 708, the therapy state 710, the fault state 712, or the alarm state 714. The nonoperative state 716 corresponds to the server being unable to determine if the medical device is active, or what state the medical device is in. The nonoperative state 716 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.
  • In an example of operation of the system 700, when a medical device is introduced into a medical device network, the medical device server may or may not know how to communicate with it. Assuming it is a known device that is not currently powered, the medical device server will eventually enter the known state 704. When the medical device is turned on, the medical device will transmit a power on message to the server, which will update the table to indicate that the medical device is in the powered state 708. The medical device will send to the server a message when the medical device delivers a therapy, and the medical device server will associate that medical device with the therapy state 710. When the medical device completes delivering that therapy successfully, the medical device will send a message to the server, which will change the table entry of that device from the therapy state 710 to the powered state 708. If the medical device fails for some reason, it will communicate a fault message to the server, which will associate the medical device with the fault state 712.
  • 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 the alarm state 714. 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 the powered state 708. 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 known state 704.
  • FIG. 8 displays a diagram of an exemplary communications system 800 incorporating a medical device server and a medical device. The communications system 800 is configured for receipt, processing, and storage of input messages from external devices, such as medical devices. In one embodiment the communications system 800 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.
  • The communications system 800 is configured such that messages sent from a medical device 802 are received by a medical device server 804, which includes a device server object 806, message handlers 808, and a data tier 810. The medical device 802 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 with FIG. 2.
  • The medical device server 804 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. The medical device server 804 contains a device server object 806, 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 the device server object 806, 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 or more message handlers 808 receive the message in its original format from the device server object 806, and process the message in a manner to convert the message to a format understandable to and stored by the data tier 810 of the medical device server 804. 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 the medical device server 804.
  • A second exemplary server object definition describes various features of a message handler 808:
  • < 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 the message handler 808 is analogous to that describing the device server object 806, but defined using a Provider tag indicating that the metadata defines a handler configured to define a feature. The message handler 808 can be associated with the device server object 806 using the following code:
  • <Handler>
    . . .
    <FeatureId>XXXXXXXXXXXXX-XXXX-XXXX-
    XXXXXXXXXXXX</FeatureId>
    <HandlerId>XXXXXXXX-XXXX-XXXX-XXXX-
    XXXXXXXXXXXX</HandlerId>
    . . .
    </Handler>
  • By tying a feature 806 to a handler 808, the medical device server 804 can route specific types of data to the appropriate handler.
  • A data tier 810 receives messages from the message handlers 808 for storage, and also responds to requests for data by providing data to the requesting message handler 808 for formation into a SOAP-based message or transmission to the medical device via the device server object 806.
  • A. Metadata Programming and Communication
  • Referring now to FIGS. 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 in FIG. 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. The system 900 shown is configured to provide extensibility to a variety of types and brands of medical devices, as described above in FIG. 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. The system 900 instantiates at a start operation 902, 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 in FIG. 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.
  • An association module 904 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 of FIGS. 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 in FIGS. 17-33.
  • A storage module 906 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 with FIG. 8. Operational flow proceeds to an end operation 908, 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. The system 1000 of FIG. 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 the system 1000 commences at a start operation 1002, which again corresponds to communicatively connecting a medical device to a medical device server in a medical device network.
  • Following the start operation 1002, operational flow proceeds to a general association module 1004. The general association module corresponds to the association module 904 of FIG. 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. A custom metadata module 1006 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. A storage module 1008 generally corresponds to the storage module 906 of FIG. 9, and stores the general metadata and the custom metadata on the server.
  • A device selection module 1010 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.
  • A communication module 1012 transmits a message to the selected medical device determined in the device selection module 1010. 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 the system 1000, such as those described in FIGS. 11-16 and 19-24, below. Operational flow terminates at an end operation 1014, 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 of FIG. 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 an identity schema 1100 used to identify various operational characteristics of each of the medical devices communicatively associated with a medical device server. The identity schema 1100 includes a main table 1102 including a variety of global parameters, as well as a network table 1104, an access table 1106, and one or more package tables 1108. The main table 1102 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 table 1104, access table 1106, and package tables 1108 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 table 1102. The network table 1104 includes the host, domain, IP address, and port information necessary to define a connection to the medical device over an Internet connection. The access table 1106 includes an IP address and Physical Id corresponding to the specific networking connection corresponding to the physical device to the IP address. The package tables 1108 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 with FIGS. 25-33.
  • FIG. 12 shows a control table 1200 which includes elements describing the logistics of sending messages and tracking those elements between the medical device and medical device server. The control table 1200 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 table 1300 used to track patient information for association with the medical device. The patient table 1300 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 table 1400 used to indicate the location of a patient. The location table 1400 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, Room 1” 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 table 1400 as well.
  • FIG. 15 shows a drug table 1500 used to indicate the drug, if any, associated with the medical device. The drug table 1500 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 table 1600 corresponding to a doctor, nurse, or other caregiver currently controlling the medical device. The user table 1600 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 to FIGS. 17-24, systems, methods, and schema are disclosed which are used in the medical device network of FIG. 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 in FIGS. 19-24. The system 1700 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 the system 1700 commences at a start operation 1702, which corresponds to initial operation of the medical device network. Operational flow proceeds to an event receipt module 1704, 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 of FIGS. 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 the event receipt module 1704. 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 of FIG. 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.
  • A storage module 1706 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, the storage module 1706 stores event log data in the event data 318 of FIGS. 3-4.
  • A request receipt module 1708 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, the request receipt module 1708 receives a request for event log data related to delivery of a specific drug by a medical infusion pump.
  • A result generation module 1710 generates results based on the specific request received by the request receipt module 1708, 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. The result generation module 1710 optionally also transmits the results to the requesting computing system. Using the example described in the request receipt module 1708, 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 an end operation 1712, 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. The system 1800 uses the metadata of FIGS. 11-16, as well as the additional event metadata of FIG. 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 with FIG. 17 allow the communication to occur.
  • The system 1800 commences at a start operation 1802, which corresponds to initial operation of the medical device network. Operational flow proceeds to a storage module 1804, 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, the storage module 1804 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, the storage module 1804 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.
  • A transmission module 1806 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.
  • The transmission module 1806 also optionally transmits maintenance data associated with the maintenance reminder. In one embodiment of the system 1800, the reminder sent by the transmission module 1806 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 the storage module 1804, 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 an end operation 1808, 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 of FIG. 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 table 1900 and a power event response table 1910. The tables 1900, 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 table 1900 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 table 1910 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 of FIGS. 25-33. Additional metadata may be included in the response table 1910 and the corresponding response message.
  • FIG. 20 shows an alarm event table 2000 and an alarm event response table 2010. 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 table 2000 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata. In the case of the alarm event table 2000, 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 table 1900.
  • The alarm event response table 2010 corresponds to the power event response table 1910. 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 table 2010 therefore generally includes a different response than the power event response table 1910, and communicates messages, packages or other instructions related to the alarm event.
  • FIG. 21 shows a maintenance event table 2100 and a maintenance event response table 2110. 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 table 2100 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 table 2100 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata. In the case of the maintenance event table 2100, 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 table 1900.
  • The maintenance event response table 2110 also corresponds to the power event response table 1910, 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 table 2200 and a telemetry event response table 2210. 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 table 2200 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata. In the case of the telemetry event table 2200, 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 table 1900.
  • The telemetry event response table 2210 also corresponds to the power event response table 1910, 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 table 2300 and a therapy event response table 2310. 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 table 2300 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata. In the case of the therapy event table 2300, 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 table 1900.
  • The therapy event response table 2310 also corresponds to the power event response table 1910, 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 table 2400 and a therapy change event response table 2410. 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 table 2400 corresponds to the power event table 1900 in that it also includes trigger, message, and timestamp metadata. In the therapy change event table 2400, 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 table 1900.
  • The therapy change event response table 2410 also corresponds to the power event response table 1910, 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 to FIG. 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 table 1102 and package tables 1108. The main table 1102 indicates the capability of the device to receive a package, and the package tables 1108 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 tables 1910-2410 to indicate to the medical device that a package is available for delivery.
  • Referring now to FIG. 25, an example structure of a package 2500 used in deployment of information to a medical device is shown. The package 2500 includes a server header 2502, a vendor header 2504, and information 2506 to be delivered to the medical device. The server header 2502 is the portion of the package understood by the medical device server. The server header 2502 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 the server header 2502 as well. In one embodiment, the server header 2502 is a 256 byte block incorporated into the package.
  • The vendor header 2504 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 the vendor header 2504 in a manner understandable to the medical devices it manufactures. The vendor header generally includes information related to the size of the information 2506, as well as the location of encryption information 2508 within the information. The encryption information 2508 can be used by the medical device to decrypt the information, which is generally stored in the medical device server in an encrypted form.
  • The information 2506 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. The package delivery system 2500 is not dependent upon the specific format of the vendor header 2504 or the information 2506. The information 2506 is generally stored in an encrypted form on the medical device server. When transferred to a medical device, the information 2506 is decrypted by the medical device by locating the encryption information 2508 based on information in the vendor header 2504.
  • FIG. 26 shows systems and methods for deploying package data from a medical device server to medical devices. The system 2600 is configured to distribute a package, such as the package 2500 of FIG. 5, to a medical device in response to a message received from the medical device.
  • Operational flow within the system 2600 commences at a start module 2600, 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. A storage module 2604 stores the received package in the medical device server. The storage module 2604 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, the storage module 2604 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, the storage module 2604 leaves the package unencrypted when it is stored on the medical device server or back office components.
  • A message receipt module 2606 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 in FIGS. 19-24. Additional message types are possible as well.
  • An indication module 2608 indicates to the medical device that a package is intended for delivery to that device. In one embodiment, the indication module 2608 sets a parameter in a message response indicating the existence of a package. For example, the indication module 2608 can set a parameter in the package metadata included in the event response messages 1910-2410 of FIGS. 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.
  • A request module 2610 receives a request from the medical device to receive the package. The request module 2610 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, the request module 2610 transmits a package information request message, using metadata as shown in FIG. 27. In such an embodiment, the request module 2610 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, the request module 2610 receives a request as shown in FIG. 29 or 31.
  • A delivery module 2612 delivers the requested package to the medical device. The format of the package delivery message can be as shown in FIG. 30 or 32. Operational flow terminates at an end operation 2614, 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 in FIG. 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 table 2700 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 table 1102 or package tables 1108 related to that device in the medical device server. The metadata in the table 2700 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 table 2700 and message from the medical device as well.
  • FIG. 28 shows a package information request response table 2800 including metadata used in describing a package available to be deployed to a medical device. The metadata in the table 2800 includes the package identifier, corresponding to the package identifier in the package information request table 2700, and also includes package information metadata. The package information metadata links to a package information table 2802, 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 table 2900 including metadata used in requesting package data from a medical device server. The package data request table 2900 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 table 3000 including metadata used in deploying a package to a medical device. The metadata included in the package data request response table 3000 includes a package identifier and a package binary data field. The package identifier identifies the package referred to in FIG. 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 table 3002 containing the package binary data for delivery to a medical device. In one embodiment, the package delivered to the medical device is the package 2500 of FIG. 25.
  • FIG. 31 shows a package request table 3100. The package request table 3100 corresponds to the package data request table 2900 of FIG. 29 combined with the package information request table 2700 of FIG. 27. The package request table 3100 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 table 3100 includes a package identifier and a response type, similar to the package data request table 2900, 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 table 3200, 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 table 3100 of FIG. 31. The package request response table includes package identifier, package information, and package binary metadata. The package information metadata links to a package information table 3202 containing name and version metadata associated to the package data. The package binary metadata links to a package binary table 3204, which includes metadata corresponding to the package to be deployed to the medical device.
  • D. Time Management
  • Referring now to FIGS. 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 a time messaging schema 3300 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. The time schema 3300 includes a time request table 3302, a time request response table 3304, and a system time table 3306. The time request table 3302 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 table 3304 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 table 3306, 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 the system 3400 commences at a start operation 3402, corresponding to initial operation of the medical device network. A server time maintenance module 3404 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 server time transmission module 3406 transmits the server time to one or more medical devices in the medical device network. In one embodiment, the server time transmission module 3406 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 table 3302 of FIG. 33, above.
  • In a further embodiment, the transmission module 3406 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.
  • A replacement module 3408 replaces the device time in the medical device with the server time value received from the medical device server. The replacement module 3408 uses the time-adjusted server time value, configured to be used at the location of the medical device. An optional confirmation module 3410 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 an end operation 3412, corresponding to completion of the time synchronization process.
  • Referring now to FIG. 35, methods and systems for synchronizing event log data are disclosed. The system 3500 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. The system 3500 compensates for this discrepancy when storing event log data, and also when providing it to users for review. Operational flow within the system 3500 commences at a start operation 3502, corresponding to initial communication of event data from medical devices to the medical device server.
  • A receipt module 3504 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 time zone modification module 3506 converts the time stamp information from the local time zone of the medical device to a constant time zone. In one embodiment, the time zone modification module 3506 converts the time stamp to the Universal Time Protocol (UTP). A storage module 3508 stores the converted time stamp and associated event log data in the medical device server or back office components.
  • An optional global tracking module 3510 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 request local event module 3512 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 request local event module 3512 generates a query for the event data requested, and returns results including event log data. A conversion module 3514 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. The conversion module 3514 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 the system 3500 is terminated at an end operation 3516, which corresponds to completion of the conversion module 3514.
  • IV. Remote User to Server Communication
  • Referring now to FIGS. 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 in FIG. 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 of FIG. 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 overall web service architecture 3600, shown as a subsystem of the possible software architectures of the medical device network in FIGS. 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.
  • The web service architecture 3600 includes an administrative web service 3602, an operations web service 3604, and an event tracking web service 3606. The administrative web service 3602 validates users of the medical device server, and includes functional interfaces for logging in, logging out, and changing a user password. The administrative web service 3602 tracks information related to products, customers, contact information, medical devices associated with the customers, user accounts associated with a customer, and other variables. The administrative web service 3602 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 the administrative web service 3602 is described in Part IV.A, below.
  • The operations web service 3604 provides access to operational data of the medical devices, such as operational data regarding therapy delivery or monitoring data. The operations web service 3604 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 the operations web service 3604 is described in Part IV.B, below.
  • The event tracking web service 3606 tracks various event data occurring in a medical device, such as telemetry data received by a medical device server. The event tracking web service 3606 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 tracking web service 3606 is described in Part IV.C, below.
  • A. Administration
  • Referring now to FIGS. 37-41, systems and reports for definition and use of an administrative web service are shown. FIG. 37 shows an exemplary class structure defining an administrative web service 3700. The administrative web service 3700 provides a possible embodiment of the administrative web service 3602 of FIG. 36, and is accessible via any of a number of user interfaces, such as the administration web forms 324 of FIG. 3. The administrative web service 3700 includes an authentication class 3702, an authorization class 3704, a user class 3706, a role class 3708, a license class 3710, a resource class 3712, a metadata class 3714, and an entity settings class 3716. 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.
  • The authentication class 3702 provides the initial access to the administrative web service 3700, and includes login and logout functionality. The authorization class 3704 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 the authorization class 3704 include read, write, create, delete, and access permission functions. Other functions may be incorporated into the authorization class 3704 as well.
  • Each of the other classes link to the authorization class 3704, and each requests read or write access to the data protected by the authorization class 3704. The user class 3706 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. The role class 3708 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.
  • The license class 3710 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.
  • The resource class 3712 allows an administrator to add and delete resources, which correspond to the specific functional areas of the medical device server. The metadata class 3714 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 in FIGS. 42-43. The entity settings class 3716 allows writing and retrieval of entity settings. Additional administrative functionality, including additional classes, may be incorporated into the administrative web service 3700 as well.
  • FIGS. 38-41 display sample administrative reports accessible to a user. The administrative reports of FIGS. 38-41 correspond to the reports 326 shown in FIGS. 3-4, and are derived from information stored in the data warehouse 322 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 administration tracking event report 3800. 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 the administration data 316 of FIG. 3 that match the query presented to the administrative web service. The administration tracking event report includes time and date information 3802, application information 3804, and message information 3806. Additional information, such as the code information, time zone indicator, and other information can be optionally included in the report 3800.
  • The time and date information 3802 display the time stamp information related to the event tracked by the administrative module. The time and date information 3802 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 the report 3800 shown, the local time zone option is selected.
  • The application information 3804 indicates the service or handler accessed, and the message 3806 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 a security event report 3900. The security event report 3900 corresponds generally to the administration tracking event report 3800, but includes events related to security of the medical device server rather than access to it. The security event report 3900 includes time and date information 3902, application information 3904, and message information 3906, each of which have the same functionality as in the administration tracking event report 3800.
  • FIG. 40 displays a security event trending report 4000. The security event trending report 4000 displays a chart of security related events over time. In the embodiment shown, the security event trending report 4000 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 a user history report 4100. The user history report displays a chronologically ordered list of events logged regarding one or more users. Each entry in the list includes time and date information 4102, a sorting code 4104, a username 4106 corresponding to the active user, and a message 4108 related to the action taken by that user. An optional details entry 4110 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 to FIGS. 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 the administrative applications 324 of FIGS. 3-4. FIGS. 47-50 display reports displaying the results of installation of the metadata and packages, and are a subset of the reports 326 available from the data warehouse 322 in FIGS. 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 an initial user interface 4200 showing the metadata packages either currently installed into the medical device server or available to be installed. A listing area 4202 lists the packages, in this case displayed as “Virtual Infusion Pump”, “Virtual Patient Monitor”, and “Medfusion 4000”. Check boxes 4204 in the listing area allow user selection of one or more of the installed packages, an install button 4206 installs the packages into the medical device server, and an uninstall button 4208 removes metadata packages from the medical device server.
  • FIG. 43 displays a metadata installation interface 4300 configured to allow a user to browse for a metadata file and install that file onto the medical device server. The metadata installation interface 4300 appears following selection of one of the types of medical devices present in the system in the user interface 4200, and allows the user to select and install a metadata file associated with the previous selection of metadata using the initial user interface 4200.
  • FIG. 44 displays a package deployment interface 4400 providing deployment of packages for distribution to one or more medical devices, as described above in Part III.C. The package deployment interface 4400 generally corresponds to the metadata installation interface 4200 of FIG. 42, but relates to software to be installed onto a medical device, rather than into the medical device server. A listing area 4402 lists the packages, in this case displayed as “Simple Infusion Pump” or “TestPackage”. Check boxes 4404 in the listing area allow user selection of one or more of the installed packages, a deploy button 4406 deploys the packages into the medical device server, and an uninstall button 4408 removes the packages from the medical device server.
  • Upon selection of the deploy button 4406, a user interface 4500 shown in FIG. 45 is displayed. The user interface 4500 allows system administrators to enter a package deployment name into a name field 4502, 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 deployment file selection field 4508. The system administration presses a deploy button 4510 to deploy the package, or a cancel button 4512 to cancel deployment.
  • Upon selection of the deploy button 4510, a further user interface 4600 shown in FIG. 46 is displayed to allow user verification that the correct package has been selected for download to medical devices. The user interface 4600 displays package deployment details in a package information field 4502, including the selected start time, end time, and target type as entered in the previous user interfaces 4400, 4500. The user interface 4600 further displays vendor properties in a vendor field 4504, such as the vendor identifier, name, and version of the vendor package.
  • FIGS. 47-50 display various reports generated from the data warehouse 322 of FIGS. 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 a quarantine report 4700, which displays a chronological list of the quarantined messages received by the medical device server. The quarantine report 4700 includes time and date information 4702, state information 4704, and message information 4706. The time and date information 4702 display the time stamp information related to the quarantine event tracked by the medical device server. The time and date information 4702 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 the report 4700 shown, the local time zone option is selected.
  • The state information 4704 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.
  • The message information 4706 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 a quarantine detail report 4800, which is configured to display the details of a specific quarantined message received by the medical device server. The quarantine detail report includes an error field 4802 including the error information displayed on the quarantine report 4700, and a source field 4804 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 a package deployment report 4900 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 more package deployment entries 4902, each including name and version information related to the specific package being deployed to that type of device. Each of the package entries includes device sub-entries 4904, each of which relates to a specific device qualifying for the generalized package deployment. The sub-entries each include host name information 4906, physical identification information 4908, notification information 4910, transfer information 4912, and completion information 4914. The host name information 4906 corresponds to the medical device server providing the package to the device. The physical identification information 4908 displays the unique identifier associated with the medical device. The notification information 4910 displays the date and time at which the medical device was notified that the package was available. The transfer information 4912 displays the date and time at which the package was successfully transferred to the medical device. The completion information 4914 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, an error indication 4916 displays an indication of an error, and a result of the error.
  • FIG. 50 displays a package deployment error report 5000. The package deployment error report 5000 provides a detailed event history for the specific packages and corresponding devices for which a package deployment fails. The package deployment error report 5000 displays a title 5002 including the target medical device type and package identifier. The title also optionally displays a name associated with the package deployment.
  • The package deployment error report 5000 displays time and date information 5004, optional host information 5006, physical identifier information 5008, and message information 5010. The time and date information 5004 indicate when the error in the package deployment occurred. The optional host name information 5006 displays the network name in which the medical device is located. The physical identifier information 5008 includes the identifier associated with the medical device. The message information 5010 displays the message associated with the package deployment error. Additional information regarding the deployment error may be included in the report 5000 as well.
  • 2. Maintenance/Faults
  • Referring now to FIGS. 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 of FIGS. 51-53 correspond to the maintenance forms 330 of FIGS. 3-4.
  • FIG. 51 shows a medical device maintenance report 5100 listing maintenance records for various medical devices. The medical device maintenance report 5100 includes type entries 5102 corresponding to various types of medical devices, and device sub-entries 5104 corresponding to specific medical devices. In the embodiment shown, the type entries 5102 are the “MedFusion 4000” and “Titan” entries, while the device sub-entries 5104 are the individual rows within each type.
  • Within each sub-entry 5104, there exists host name information 5106, physical identifier information 5108, version information 5110, package information 5112, and preventative maintenance date information 5114. The host information 5106 displays the network associated with the medical device. The physical identifier 5108 displays the unique identifier associated with the medical device. The version information 5110 displays one or more version numbers associated with the medical device. The package information 5112 displays packages being used by the medical device. The preventative maintenance information 5114 displays a date at which the medical device is due for preventative maintenance. Additional information can be displayed within each sub-entry 5104 as well.
  • FIG. 52 shows a medical device fault report 5200. The medical device fault report 5200 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 medical device fault report 5200 includes time and date information 5202, host information 5204, physical identifier information 5206, and message information 5208. Use of the information 5202-5208 is analogous to the corresponding elements in the package deployment error report 5000 of FIG. 50, but related to medical device fault events. For example, in the medical device fault report 5200, 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 device fault trending report 5300. The medical device fault trending report 5300 displays a chart of medical device fault related events over time. The medical device fault trending report 5300 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 device fault trending report 5300 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 the operations web service 3604 of FIG. 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. The system 5400 includes states corresponding to the various possible states experienced in the medical device during execution of the therapy order.
  • Operational flow within the system 5400 commences at a start node 5402, which corresponds to introduction of a new therapy order into the medical device or medical device server. Once the therapy order is introduced, the system 5400 enters a new state 5404, indicating that the therapy order is newly introduced and has not yet been executed by the medical device. When the system 5400 is in the new state 5404, a user has the option to cancel the therapy order. If the user chooses to cancel the therapy order, operational flow in the system 5400 proceeds to a canceled state. 5406. From the canceled state, operational flow proceeds to an end node 5408 corresponding to completion of the therapy module. At the end node 5408, 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 the system 5400 is in the new state, operational flow proceeds to an assisted setup state 5410. The assisted setup state 5410 attempts to assist in setting up the therapy parameters. If the assisted setup is unsuccessful operational flow branches to a failed state 5412. The failed state 5412 stores an error message indicating that the assisted setup process failed. Operational flow proceeds from the failed state 5412 to the end node 5408.
  • If the assisted setup state 5410 is successful in setting up therapy parameters, operational flow branches to a setup state 5414. The setup state 5414 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 the system 5400 to proceed to a started state 5416, 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 the system 5400 to proceed to a complete state 5418, indicating that delivery of the therapy is complete. Operational flow next proceeds to the end node 5408.
  • FIG. 55 shows an exemplary class structure defining a therapy service 5500. The therapy service 5500 illustrates a portion of the functionality of the operations web service module 3604. The therapy service 5500 links to and uses a variety of functions from the administrative web service 3700 of FIG. 37.
  • The therapy service 5500 includes a therapy order class 5502, a therapy order rule utility 5504, and a therapy order action enumeration 5506. The therapy order class 5502 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 the therapy service 5500 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 the therapy order class 5502 as well.
  • The therapy order rule utility 5504 provides expressions and actions related to execution of the therapy order, including various parameters and commands required for execution of the therapy. The therapy order action enumeration 5506 provides advisory messages used during selection and/or execution of a therapy order.
  • FIG. 56 displays exemplary message exchange processes 5600, 5620, 5640, and 5660 performed between a therapy order management application 5602, an operations web service 5604 such as the one shown in FIG. 36, a medical device server 5606 as disclosed above in FIGS. 3-4, and a medical device 5608, such as shown in FIG. 2. The therapy order management application 5602 can be any application configured to interface with the operations web service to communicate therapy orders and other messages to the operations service 5604 and medical device server 5608.
  • A first message exchange process 5600 illustrates the therapy order management application 5602 transmitting a create therapy order message 5610 to the operations web service 5604. The operations web service 5604 verifies the therapy information and stores the therapy order in operations data. The operations web service 5604 also responds 5612 by indicating success or failure of the message.
  • A second message exchange process 5620 illustrates the therapy order management application 5602 later in time transmitting a therapy order update message or a therapy order cancellation message 5622. The operations web service 5604 verifies the therapy information, and updates or cancels the therapy order according to the message. The operations web service 5604 also responds 5624 by indicating success or failure of the message.
  • A third message exchange process 5640 occurring after the first message exchange process 5600 illustrates the therapy order management application 5602 transmitting a message 5642 indicating that the therapy order should be executed. The therapy order management application 5602 transmits an execute therapy order message 5642 to the operations web service 5604, which verifies the therapy order and in turn forwards the therapy order message 5642 to the medical device server 5606. The medical device server 5606 relays the therapy order message 5642 to a medical device 5608.
  • The medical device 5608 transmits a message 5644 indicating the success or failure of receipt of the therapy order message 5642. The medical device server 5606 and operations web service 5604 relay the message 5644 back to the order trigger application 5602.
  • At a time after the medical device transmits the message 5644, the medical device 5608 initiates a fourth messaging process 5660 in which the medical device transmits a therapy begin message 5662 to the medical device server 5608, indicating that the medical device has begun delivering the therapy to a patient. The medical device server 5608 transmits the message 5662 to the operations web service 5604, which updates the therapy order state. The medical device server also relays the message 5662 to an event tracking web service 5605, such as the one in FIG. 36, to store a therapy delivery event in an event history log. Both the event tracking web service 5605 and the operations web service 5604 transmit response messages 5664 indicating the success or failure of receipt of the therapy begin message 5662.
  • Additional events triggered by the medical device, such as a therapy completion event or alarm, transmit among the components 5602-5608 analogously to the messaging process 5660. 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. The system 5700 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. The system 5700 commences at a start operation 5702, 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 original parameter receipt module 5704 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 updated parameter receipt module 5706 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 final parameter receipt module 5708 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 modules 5704-5708 may occur concurrently or sequentially, and may be included in one or more messages from the medical device to the medical device server.
  • A parameter storage module 5710 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 the system 5700 can include comparing the final parameter value received in the final parameter receipt module 5708 with a hard limit or soft limit stored in the medical device server. If the final parameter value exceeds the limit, the system 5700 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 an end operation 5712, 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 medical device history report 5800 listing original, updated, and final operational parameter values for a medical device according to the methods and systems of FIG. 57. The medical device history report 5800 includes a medical device label 5802, date and time information 5804, class information 5806, trigger information 5808, message information 5810, location information 5812, and drug information 5814. The medical device label 5802 corresponds to the medical device name for the device whose history is displayed in the report 5800. The date and time information 5804 correspond to the time the various events occurred that are included in the medical device history report. The class information 5806 describes the type and severity of the event. In the case of a therapy change event, the class information 5806 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.
  • The trigger information 5808 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 the trigger information 5808. However, an event describing a therapy change will not activate the trigger information 5808.
  • The message information 5810 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. The location information 5812 includes information related to the location of the medical device, such as the department, the facility, and the entity controlling the medical device. The drugs information 5814 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 medical device history report 5800, based on the information tracked by the medical device server and operations web service.
  • FIG. 59 shows a therapy history report 5900. The therapy history report 5900 displays the same information as is displayed in the medical device event history report 5800 of FIG. 58, but will only display therapy event information. The therapy history report 5900 includes a medical device label 5902, date and time information 5904, class information 5906, trigger information 5908, message information 5910, location information 5912, and drug information 5914, each of which operate analogously to the corresponding entries in the medical device event history report 5800.
  • FIG. 60 shows a therapy trending report 6000. The therapy trending report 6000 displays a chart of therapy related events over time. In the embodiment shown, the therapy trending report 6000 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 therapy change history report 6100. The therapy change history report 6100 also displays the same information as is displayed in the medical device event history report 5800 of FIG. 58, but only displays therapy change event information. Therapy change events correspond to changed parameters in delivering a therapy using a medical device. The therapy change history report 6100 includes a medical device label 6102, date and time information 6104, class information 6106, trigger information 6108, message information 6110, location information 6112, and drug information 6114, each of which operate analogously to the corresponding entries in the medical device event history report 5800 and the therapy history report 5900.
  • FIG. 62 shows a therapy change trending report 6200. The therapy change trending report 6200 displays a chart of therapy change events over time. In the embodiment shown, the therapy change trending report 6200 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 to FIGS. 63-66, various features of the event web service of FIG. 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 and 3-4.
  • FIG. 63 is a flowchart of methods and systems for determining the on-line status of a medical device. The system 6300 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 the system 6300 commences at a start operation 6302, which corresponds to initial communication between a medical device and a medical device server. Operational flow proceeds from the start operation 6302 to an expectation module 6304. The expectation module 6304 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 receive data operation 6306 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 an update module 6308, which updates the status of the medical device to indicate that the device is on-line.
  • An optional output update module 6310 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 receive data operation 6306, the update module 6308, and the output update module 6310 so long as the medical device continues in operation and the receive data operation 6306 determines that the medical device server continues to send messages to the medical device within the predetermined period.
  • If the receive data operation 6306 fails to receive data within the predetermined period, the operational flow branches “no” to an offline module 6312, 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 optional output update module 6310, 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 an end module 6314, 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 the system 6400 commences at a start node 6402, which corresponds to initial operation of a medical device capable of transmitting a telemetry stream in a medical device network. A new state 6404 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 in FIG. 65, below. If the stream startup process fails, operational flow proceeds to a failed state 6406, corresponding to failure to start the telemetry stream. Operational flow then proceeds to an end node 6408.
  • If the stream startup process successfully starts, operational flow proceeds to a collecting state 6410, 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 collecting state 6410, a number of possible options affect operational flow of the system 6400. 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 an offline state 6412. The offline state 6412 corresponds to the system no longer regularly receiving telemetry data. If a telemetry report is later received, the system 6400 returns to the collecting state 6410.
  • If the telemetry stream is paused by a user, operational flow proceeds to a paused state 6414, corresponding to a system which only temporarily is not receiving telemetry data. The user can resume the telemetry stream to return the system 6400 to the collecting state.
  • A terminated state 6416 can be reached from the collecting state 6410, the offline state 6412, or the paused state 6414 by the user terminating the stream or the system otherwise receiving a medical device power off event. The terminated state 6414 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 the system 6400 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 the end node 6408.
  • FIG. 65 displays exemplary telemetry stream message sequences 6500, 6520, 6540, and 6560 performed among: a dashboard 6502, such as the one shown in FIG. 67; an event tracking web service 6504, such as the one shown in FIG. 36; a medical device server 6506, as disclosed above in FIGS. 3-4; and a medical device 6508, such as shown in FIG. 2. A first telemetry stream message sequence 6500 illustrates a request to initiate a telemetry stream from a medical device to a dashboard. The message sequence 6500 starts by the dashboard 6502 sending a start telemetry stream message 6510 to the event tracking web service 6504. The event tracking web service communicates the message 6510 to the medical device server 6506, which in turn communicates the message 6510 to the medical device 6508. The medical device generates a response message 6512 indicating success or failure of the message. The response message is related back to the dashboard 6502 by the medical device server 6506 and event tracking web service 6504.
  • A second telemetry stream message sequence 6520 illustrates initiation of a telemetry stream by a medical device 6508. The medical device 6508 generates a telemetry event 6522, which includes near-continual communication of telemetry data from the medical device 6508 to the medical device server 6506, which relays the telemetry data to the dashboard 6502 via the event tracking web service 6504. The dashboard 6502 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 a response message 6524 to the event tracking web service 6504, indicating successful receipt of the telemetry stream.
  • The dashboard 6502 generates a get telemetry window message 6526 and transmits the message to the event tracking web service, which responds with a message 6528 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 tracking web service 6504 will respond with a fail message and will terminate the telemetry stream.
  • A third telemetry stream message sequence 6540 illustrates ending a telemetry stream by shutting off the medical device generating the telemetry stream. The medical device 6508 generates a power off event message 6542 and sends the message to the medical device server 6506. The medical device server sends a terminate telemetry stream message to the event tracking web service 6504. The event tracking web service 6504 generates a response message 6544 indicating success or failure of receipt of the message 6542. The medical device server 6506 relays the response message 6544 to the medical device 6508.
  • A fourth telemetry stream message sequence 6560 relates to the sequence 6540 and illustrates ending a telemetry stream by discontinuing the telemetry stream at the dashboard 6502. The dashboard 6502 generates a terminate telemetry stream message 6562, which is communicated from the dashboard to the event tracking web service 6504, and in turn through the medical device server 6506 to the medical device 6508. The medical device 6508 terminates its telemetry stream and generates a response message 6564 indicating success or failure of receipt of the message 6562. The medical device server relays the message 6564 through the event tracking web service 6504 to the dashboard 6502. 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 a telemetry stream class 6600. The telemetry stream structure 6600 illustrates a portion of the functionality of the event web service module 3606. The telemetry stream relates back to and uses a variety of functions from the administrative web service 3700 of FIG. 37.
  • The telemetry stream structure 6600 includes a telemetry stream class 6602 and a latest event class 6604. The telemetry stream class 6602 includes a variety of telemetry-related operations, including starting, terminating, pausing, and retrieving available telemetry streams. Additional telemetry stream operations can be included in the telemetry stream class 6602 as well. The latest event class 6604 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 the latest event class 6604, and additional classes can be added to the telemetry stream structure 6600.
  • Various exemplary dashboards may be used to view telemetry data at a workstation of other computing device. One example dashboard is shown in FIG. 67. The dashboard 6700 displays telemetry data (e.g. current or near-current operational status) relating to the pumps with which it is associated. The dashboard 6700 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 as dashboard 328 of FIGS. 3-4. The dashboard 6700 can be updated by a telemetry stream, such as described above in FIGS. 64-66.
  • In the embodiment shown, the dashboard 6700 tracks a name 6702, identifier 6704, domain 6706, address 6708, port 6710, and activity history 6712, with respect to each medical device associated with the dashboard. The name 6702 corresponds to a name of a device recognizable to a user, assigned by either the device itself or the server. The identifier 6704 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. The domain 6706 indicates the name of a network in which the medical device resides. The address 6708 provides connection information regarding how to communicate with the medical device from the server. In the embodiment shown, the address 6708 is shown as an IP address of the medical device. The port 6710 lists the inbound communication port for the medical device. The activity history field 6712 lists a date and time of the last event occurring on the medical device and communicated to the server.
  • The dashboard 6700 graphically illustrates an operational status of the pumps with which it is associated. In the embodiment shown, five medical devices are tracked in the dashboard 6700, 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 the dashboard 6700 as well.
  • Optionally, additional features can be included in the dashboard 6700 that allow a user to filter or display different types of information. In the embodiment shown, a pause check box 6714 and an offline devices check box 6716 allow a user to selectably modify the dashboard. The pause check box 6714, 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 the pause check box 6714 is unselected, the status information on the dashboard can continually update as data is received from the associated medical devices. The offline devices check box 6716 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.

Claims (26)

1. A server comprising:
a memory configured to store identification information regarding a plurality of medical devices at different customer sites;
a programmable circuit operatively connected to the memory, the programmable circuit configured to execute program instructions to:
receive data from medical devices at one or more of the different customer sites;
store data in the memory associated with the one or more different customer sites; and
associate a portion of the data with the medical device that transmitted that portion of data.
2. The server of claim 1, wherein the different customer sites are associated with different customers.
3. The server of claim 1, wherein the programmable circuit is further programmed to send program information to one or more of the medical devices.
4. The server of claim 1, wherein the server is accessible to one or more workstations at the different customer sites.
5. The server of claim 4, wherein the programmable circuit is further programmed to provide to the workstations at least portions of the data associated with that customer site.
6. The server of claim 1, wherein the programmable circuit is further programmed to associate the plurality of medical devices with the corresponding different customer sites.
7. The server of claim 1, wherein the programmable circuit is further programmed to receive commands from a workstation at a customer site.
8. The server of claim 7, wherein the programmable circuit is further programmed to determine whether the commands received from the workstation relate to medical devices at the customer site.
9. The server of claim 8, wherein the programmable circuit is further programmed to, upon determining that the commands relate to medical devices at the customer site, execute the commands received from the workstation.
10. The server of claim 9, wherein the commands direct the server to reprogram one or more of the medical devices at the customer site.
11. The server of claim 9, wherein the commands request event log data held by the server, the event log data related to one or more of the medical devices at the customer site.
12. A server network comprising:
a plurality of medical devices at different customer sites;
a server operatively connected to the plurality of medical devices, the server comprising:
a memory configured to store identification information regarding the plurality of medical devices;
a programmable circuit operatively connected to the memory, the programmable circuit configured to execute program instructions to:
receive data from medical devices at one or more of the different customer sites;
store data in the memory associated with the one or more different customer sites;
associate a portion of the data with the medical device that transmitted that portion of data; and
a workstation at one of the customer sites, the workstation communicatively connected to the server and configured to request data related to the customer site.
13. The server network of claim 12, wherein the different customer sites are associated with different customers.
14. The server network of claim 12, wherein the programmable circuit is further programmed to send program information to one or more of the medical devices.
15. The server network of claim 12, wherein the programmable circuit is further programmed to associate the plurality of medical devices with the corresponding different customer sites.
16. The server network of claim 12, wherein the programmable circuit is further programmed to receive commands from a workstation.
17. The server network of claim 16, wherein the workstation resides at one of the customer sites.
18. The server network of claim 16, wherein the programmable circuit is further programmed to determine whether the commands received from the workstation relate to medical devices at the customer site.
19. The server network of claim 18, wherein the programmable circuit is further programmed to, upon determining that the commands relate to medical devices at the customer site, execute the commands received from the workstation.
20. The server network of claim 19, wherein the commands direct the server to reprogram one or more of the medical devices at the customer site.
21. The server network of claim 19, wherein the commands request event log data held by the server, the event log data related to one or more of the medical devices at the customer site.
22. The server network of claim 12, wherein one or more of the medical devices is a medical infusion pump.
23. The server network of claim 22, wherein the commands are selected from a group consisting of:
configuration parameters;
drug library information;
soft limits
hard limits;
care profiles;
firmware updates; and
software patches.
24. The server network of claim 12, wherein the server is operatively connected to the medical devices over a wired network connection.
25. The server network of claim 12, wherein the server is operatively connected to the medical devices over an at least partially wireless network connection.
26. The server network of claim 12, wherein the server is an application server.
US12/189,603 2007-08-10 2008-08-11 Central Server for Medical Devices Abandoned US20090157695A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US12/189,603 US20090157695A1 (en) 2007-08-10 2008-08-11 Central Server for Medical Devices

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US96444407P 2007-08-10 2007-08-10
US12/189,603 US20090157695A1 (en) 2007-08-10 2008-08-11 Central Server for Medical Devices

Publications (1)

Publication Number Publication Date
US20090157695A1 true US20090157695A1 (en) 2009-06-18

Family

ID=39830193

Family Applications (11)

Application Number Title Priority Date Filing Date
US12/189,622 Abandoned US20090157202A1 (en) 2007-08-10 2008-08-11 Therapy rules for closed loop programming of medical devices
US12/189,655 Abandoned US20090177248A1 (en) 2007-08-10 2008-08-11 Synchronizing Clocks on a Medical Device and Server
US12/189,657 Abandoned US20090099866A1 (en) 2007-08-10 2008-08-11 Time zone adjustment for medical devices
US12/189,656 Abandoned US20090177249A1 (en) 2007-08-10 2008-08-11 Package deployment of data between a server and a medical device
US12/189,640 Abandoned US20090158274A1 (en) 2007-08-10 2008-08-11 Software Development Kit for a Medical Device and Web-Based Server
US12/189,638 Abandoned US20090177769A1 (en) 2007-08-10 2008-08-11 Determining online status of a medical device
US12/189,603 Abandoned US20090157695A1 (en) 2007-08-10 2008-08-11 Central Server for Medical Devices
US12/189,595 Abandoned US20090157622A1 (en) 2007-08-10 2008-08-11 Filtering event logs for medical devices by a parameter
US12/189,674 Abandoned US20090099867A1 (en) 2007-08-10 2008-08-11 Communicating preventative maintenance data to a medical device
US12/189,624 Active 2034-05-11 US9483615B2 (en) 2007-08-10 2008-08-11 Communication of original and updated pump parameters for a medical infusion pump
US12/189,541 Abandoned US20090150484A1 (en) 2007-08-10 2008-08-11 Medical device metadata

Family Applications Before (6)

Application Number Title Priority Date Filing Date
US12/189,622 Abandoned US20090157202A1 (en) 2007-08-10 2008-08-11 Therapy rules for closed loop programming of medical devices
US12/189,655 Abandoned US20090177248A1 (en) 2007-08-10 2008-08-11 Synchronizing Clocks on a Medical Device and Server
US12/189,657 Abandoned US20090099866A1 (en) 2007-08-10 2008-08-11 Time zone adjustment for medical devices
US12/189,656 Abandoned US20090177249A1 (en) 2007-08-10 2008-08-11 Package deployment of data between a server and a medical device
US12/189,640 Abandoned US20090158274A1 (en) 2007-08-10 2008-08-11 Software Development Kit for a Medical Device and Web-Based Server
US12/189,638 Abandoned US20090177769A1 (en) 2007-08-10 2008-08-11 Determining online status of a medical device

Family Applications After (4)

Application Number Title Priority Date Filing Date
US12/189,595 Abandoned US20090157622A1 (en) 2007-08-10 2008-08-11 Filtering event logs for medical devices by a parameter
US12/189,674 Abandoned US20090099867A1 (en) 2007-08-10 2008-08-11 Communicating preventative maintenance data to a medical device
US12/189,624 Active 2034-05-11 US9483615B2 (en) 2007-08-10 2008-08-11 Communication of original and updated pump parameters for a medical infusion pump
US12/189,541 Abandoned US20090150484A1 (en) 2007-08-10 2008-08-11 Medical device metadata

Country Status (7)

Country Link
US (11) US20090157202A1 (en)
EP (2) EP3540741B1 (en)
JP (2) JP5341891B2 (en)
CN (4) CN102831294B (en)
AU (1) AU2008286957B2 (en)
CA (2) CA2696082C (en)
WO (1) WO2009023634A2 (en)

Cited By (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100229153A1 (en) * 2009-03-05 2010-09-09 Detlef Becker Providing a number of web services for imaging optional medical applications
US20110029623A1 (en) * 2009-07-29 2011-02-03 Siemens Aktiengesellschaft Taskflow unit for controlling computer-aided medical tasks within a medical computer network
US20110150336A1 (en) * 2009-12-18 2011-06-23 David Van Hardware Management Based on Image Recognition
WO2012031020A1 (en) * 2010-08-31 2012-03-08 Lantronix, Inc. Medical device connectivity to hospital information systems using device server
US20120143586A1 (en) * 2010-12-01 2012-06-07 Codewrights Gmbh Method for implementing at least one additional function of a field device in automation technology
US20120163663A1 (en) * 2010-12-27 2012-06-28 Medtronic, Inc. Security use restrictions for a medical communication module and host device
US8287495B2 (en) 2009-07-30 2012-10-16 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US20130030830A1 (en) * 2010-02-26 2013-01-31 Horst Schmoll System and method for controlling a data transmission to and/or from a plurality of medical devices
US8734428B2 (en) 2006-10-17 2014-05-27 Tandem Diabetes Care, Inc. Insulin pump having selectable insulin absorption models
US9089643B2 (en) 2009-04-14 2015-07-28 Baxter International Inc. Therapy management development platform
WO2016097514A1 (en) * 2014-12-18 2016-06-23 Bull Sas Systems for distributed management of medical equipment
WO2016099551A1 (en) * 2014-12-19 2016-06-23 Draeger Medical Systems, Inc. Medical device location-based association to a patient
US20160283682A1 (en) * 2009-09-30 2016-09-29 Covidien Lp Protocol analyzer system and method for medical monitoring module
US9594875B2 (en) 2011-10-21 2017-03-14 Hospira, Inc. Medical device update system
US20170132374A1 (en) * 2015-11-11 2017-05-11 Zyno Medical, Llc System for Collecting Medical Data Using Proxy Inputs
US9962486B2 (en) 2013-03-14 2018-05-08 Tandem Diabetes Care, Inc. System and method for detecting occlusions in an infusion pump
US20180169330A1 (en) * 2013-03-15 2018-06-21 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
US20180286510A1 (en) * 2015-09-21 2018-10-04 Wenjie Robin Liang Maintenance systems and methods for medical devices
US10238799B2 (en) 2014-09-15 2019-03-26 Icu Medical, Inc. Matching delayed infusion auto-programs with manually entered infusion programs
US10238801B2 (en) 2009-04-17 2019-03-26 Icu Medical, Inc. System and method for configuring a rule set for medical event management and responses
US10242060B2 (en) 2006-10-16 2019-03-26 Icu Medical, Inc. System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems
US10258736B2 (en) 2012-05-17 2019-04-16 Tandem Diabetes Care, Inc. Systems including vial adapter for fluid transfer
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10314974B2 (en) 2014-06-16 2019-06-11 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US10333843B2 (en) 2013-03-06 2019-06-25 Icu Medical, Inc. Medical device communication method
US10434246B2 (en) 2003-10-07 2019-10-08 Icu Medical, Inc. Medication management system
US20190349435A1 (en) * 2015-03-30 2019-11-14 Zoll Medical Corporation Medical Device Management
US10541987B2 (en) 2016-02-26 2020-01-21 Tandem Diabetes Care, Inc. Web browser-based device communication workflow
US10666733B2 (en) * 2014-01-13 2020-05-26 Carefusion 303, Inc. Remote flashing during infusion
US10682460B2 (en) 2013-01-28 2020-06-16 Smiths Medical Asd, Inc. Medication safety devices and methods
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
US10741280B2 (en) 2018-07-17 2020-08-11 Icu Medical, Inc. Tagging pump messages with identifiers that facilitate restructuring
US10765799B2 (en) 2013-09-20 2020-09-08 Icu Medical, Inc. Fail-safe drug infusion therapy system
US10861592B2 (en) 2018-07-17 2020-12-08 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US10898641B2 (en) 2014-04-30 2021-01-26 Icu Medical, Inc. Patient care system with conditional alarm forwarding
US10918785B2 (en) 2013-12-26 2021-02-16 Tandem Diabetes Care, Inc. Integration of infusion pump with remote electronic device
US20210212694A1 (en) * 2017-12-28 2021-07-15 Ethicon Llc Method for facility data collection and interpretation
US11129533B2 (en) 2017-02-24 2021-09-28 Collaborative Care Diagnostics, LLC Secure communications and records handling system and associated method
US11235100B2 (en) 2003-11-13 2022-02-01 Icu Medical, Inc. System for maintaining drug information and communicating with medication delivery devices
US11309070B2 (en) 2018-07-26 2022-04-19 Icu Medical, Inc. Drug library manager with customized worksheets
US11328805B2 (en) 2018-07-17 2022-05-10 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US20220157446A1 (en) * 2013-03-15 2022-05-19 Carefusion 303, Inc. Application licensing for a centralized system of medical devices
US11574737B2 (en) 2016-07-14 2023-02-07 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
US11571508B2 (en) 2013-08-30 2023-02-07 Icu Medical, Inc. System and method of monitoring and managing a remote infusion regimen
US11587669B2 (en) 2018-07-17 2023-02-21 Icu Medical, Inc. Passing authentication token to authorize access to rest calls via web sockets
US11605468B2 (en) 2015-05-26 2023-03-14 Icu Medical, Inc. Infusion pump system and method with multiple drug library editor source capability
US11607492B2 (en) 2013-03-13 2023-03-21 Tandem Diabetes Care, Inc. System and method for integration and display of data of insulin pumps and continuous glucose monitoring
US11925373B2 (en) 2017-10-30 2024-03-12 Cilag Gmbh International Surgical suturing instrument comprising a non-circular needle

Families Citing this family (353)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11087873B2 (en) 2000-05-18 2021-08-10 Carefusion 303, Inc. Context-aware healthcare notification system
US9427520B2 (en) 2005-02-11 2016-08-30 Carefusion 303, Inc. Management of pending medication orders
US10062457B2 (en) 2012-07-26 2018-08-28 Carefusion 303, Inc. Predictive notifications for adverse patient events
US10353856B2 (en) 2011-03-17 2019-07-16 Carefusion 303, Inc. Scalable communication system
US7860583B2 (en) 2004-08-25 2010-12-28 Carefusion 303, Inc. System and method for dynamically adjusting patient therapy
US9741001B2 (en) 2000-05-18 2017-08-22 Carefusion 303, Inc. Predictive medication safety
AU6172301A (en) 2000-05-18 2001-11-26 Alaris Meidical Systems Inc Distributed remote asset and medication management drug delivery system
JP5121280B2 (en) * 2006-05-31 2013-01-16 株式会社リコー Information processing apparatus, process control method, and process control program
US8149131B2 (en) 2006-08-03 2012-04-03 Smiths Medical Asd, Inc. Interface for medical infusion pump
JP2010512813A (en) * 2006-12-14 2010-04-30 ノボ・ノルデイスク・エー/エス User interface of medical law system with diary function with change function
US7751907B2 (en) 2007-05-24 2010-07-06 Smiths Medical Asd, Inc. Expert system for insulin pump therapy
EP2156348B1 (en) * 2007-05-30 2018-08-01 Ascensia Diabetes Care Holdings AG System and method for managing health data
US8221345B2 (en) 2007-05-30 2012-07-17 Smiths Medical Asd, Inc. Insulin pump based expert system
CN101325509B (en) * 2007-06-11 2011-04-06 华为技术有限公司 Method, system and apparatus for installing software component
US20090157202A1 (en) 2007-08-10 2009-06-18 Smiths Medical Md Therapy rules for closed loop programming of medical devices
US9848058B2 (en) 2007-08-31 2017-12-19 Cardiac Pacemakers, Inc. Medical data transport over wireless life critical network employing dynamic communication link mapping
US8515547B2 (en) 2007-08-31 2013-08-20 Cardiac Pacemakers, Inc. Wireless patient communicator for use in a life critical network
US8517990B2 (en) 2007-12-18 2013-08-27 Hospira, Inc. User interface improvements for medical devices
US8407685B2 (en) * 2008-02-15 2013-03-26 Red Hat, Inc. Systems and methods for generating ordered download selections based on usage information
KR101586513B1 (en) * 2008-04-01 2016-01-18 스미스 메디칼 에이에스디, 인크. Software features for medical infusion pump
WO2009127492A1 (en) * 2008-04-15 2009-10-22 International Business Machines Corporation A method and system for improved document access
US8808178B2 (en) * 2008-04-30 2014-08-19 Welch Allyn, Inc. On demand help/in-service for a medical device
US20090300170A1 (en) * 2008-05-28 2009-12-03 Bhame William H Test and monitoring device management with multi-faceted communication capability
US10089443B2 (en) 2012-05-15 2018-10-02 Baxter International Inc. Home medical device systems and methods for therapy prescription and tracking, servicing and inventory
US20100015955A1 (en) * 2008-07-18 2010-01-21 Sony Ericsson Mobile Communications Ab Call management between communication devices
JP4725622B2 (en) * 2008-09-22 2011-07-13 日本電気株式会社 Log management apparatus, system, method, and program
US20100138523A1 (en) * 2008-12-03 2010-06-03 General Electric Company Automatic configuration method and system for medical devices
US9459945B2 (en) * 2008-12-18 2016-10-04 Koninklijke Philips N.V. Software bug and performance deficiency reporting system
AU2010205834A1 (en) * 2009-01-15 2011-08-04 Hcs Kablolama Sistemleri San. Ve. Tic. A.S. Improved cabling system and method for monitoring and managing physically connected devices over a data network
US8319631B2 (en) 2009-03-04 2012-11-27 Cardiac Pacemakers, Inc. Modular patient portable communicator for use in life critical network
US8812841B2 (en) 2009-03-04 2014-08-19 Cardiac Pacemakers, Inc. Communications hub for use in life critical network
NZ575836A (en) * 2009-03-27 2009-08-28 Nexus6 Ltd Improvements in or Relating to Medicament Delivery Systems
US9792660B2 (en) * 2009-05-07 2017-10-17 Cerner Innovation, Inc. Clinician to device association
US8595607B2 (en) 2009-06-04 2013-11-26 Abbott Diabetes Care Inc. Method and system for updating a medical device
US20110004589A1 (en) * 2009-07-06 2011-01-06 Rockwell Automation Technologies, Inc. Diagnostics in a distributed directory system
US20110016199A1 (en) * 2009-07-17 2011-01-20 Phil De Carlo System for electronic device monitoring
RU2556450C2 (en) * 2009-08-17 2015-07-10 Конинклейке Филипс Электроникс, Н.В. System and method of synchronising device for patient monitoring with central server
US20110054936A1 (en) 2009-09-03 2011-03-03 Cerner Innovation, Inc. Patient interactive healing environment
JP5454045B2 (en) * 2009-09-25 2014-03-26 日本電気株式会社 Information processing apparatus, wireless communication system, wireless communication method, and program
US9818164B2 (en) 2009-09-25 2017-11-14 Cerner Innovation, Inc. Facilitating and tracking clinician-assignment status
US8565847B2 (en) * 2009-09-30 2013-10-22 Covidien Lp Evaluation board for a medical monitoring module system and method
US8489167B2 (en) * 2009-09-30 2013-07-16 Covidien Lp Evaluation kit for medical monitoring module system and method
DE102009048072A1 (en) * 2009-10-01 2011-04-07 Siemens Aktiengesellschaft Centralized image reconstruction for tomographic imaging in medical technology
US8771251B2 (en) * 2009-12-17 2014-07-08 Hospira, Inc. Systems and methods for managing and delivering patient therapy through electronic drug delivery systems
US20110161098A1 (en) * 2009-12-29 2011-06-30 Sultan Haider Method and system for accessing a plurality of medical data sources
US11881307B2 (en) 2012-05-24 2024-01-23 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11244745B2 (en) 2010-01-22 2022-02-08 Deka Products Limited Partnership Computer-implemented method, system, and apparatus for electronic patient care
US10242159B2 (en) 2010-01-22 2019-03-26 Deka Products Limited Partnership System and apparatus for electronic patient care
US11164672B2 (en) 2010-01-22 2021-11-02 Deka Products Limited Partnership System and apparatus for electronic patient care
US10911515B2 (en) 2012-05-24 2021-02-02 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20110313789A1 (en) 2010-01-22 2011-12-22 Deka Products Limited Partnership Electronic patient monitoring system
US10453157B2 (en) 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US11210611B2 (en) 2011-12-21 2021-12-28 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US9662438B2 (en) * 2010-02-05 2017-05-30 Deka Products Limited Partnership Devices, methods and systems for wireless control of medical devices
US11660392B2 (en) 2010-02-05 2023-05-30 Deka Products Limited Partnership Devices, methods and systems for wireless control of medical devices
WO2011116182A1 (en) * 2010-03-19 2011-09-22 Siemens Healthcare Diagnostics Inc. System and method for changeable focus modal windows
US8726266B2 (en) * 2010-05-24 2014-05-13 Abbott Diabetes Care Inc. Method and system for updating a medical device
WO2011156601A2 (en) * 2010-06-09 2011-12-15 Medtronic, Inc. Integrated health care system for managing medical device information
WO2012000073A1 (en) * 2010-06-29 2012-01-05 True North Consulting & Associates Inc. Imaging device information system and method
CN103052955B (en) * 2010-08-02 2017-04-26 皇家飞利浦电子股份有限公司 Method and device for semantic communication among a plurality of medical devices
US11901069B2 (en) 2010-08-12 2024-02-13 Fenwal, Inc. Processing blood donation data for presentation on operator interface
US11462321B2 (en) 2010-08-12 2022-10-04 Fenwal, Inc. Mobile applications for blood centers
US9208288B2 (en) * 2010-08-23 2015-12-08 Roy C Putrino System and method for remote patient monitoring and assessment to facilitate patient treatment
JP5822932B2 (en) * 2010-08-24 2015-11-25 スミス アンド ネフュー インコーポレーテッド Method and system for reliable interoperability between medical devices
US8306953B2 (en) * 2010-08-31 2012-11-06 International Business Machines Corporation Online management of historical data for efficient reporting and analytics
CN102404128A (en) * 2010-09-16 2012-04-04 江苏久信医用净化工程有限公司 Sending-responding method of sending-responding system in hospital logistics transmission system
WO2012035725A1 (en) * 2010-09-16 2012-03-22 パナソニック株式会社 Biological sample measuring device for medical institutions
JP5823222B2 (en) * 2010-09-27 2015-11-25 株式会社東芝 Biological information system
US8473502B2 (en) 2010-10-01 2013-06-25 Smiths Medical Asd, Inc. Interassociating data of a medical device
EP2627277B1 (en) 2010-10-12 2019-11-20 Smith & Nephew, Inc. Medical device
US8706520B2 (en) * 2010-10-15 2014-04-22 Roche Diagnostics Operations, Inc. Metadata tagging system for a diabetes management system of devices
US8578278B2 (en) * 2010-12-22 2013-11-05 Sap Ag Dynamic user interface content adaptation and aggregation
RU2622372C2 (en) * 2010-12-22 2017-06-14 Конинклейке Филипс Электроникс Н.В. System and method for caregiver and patient care equipment control
US8825775B2 (en) * 2011-02-21 2014-09-02 General Electric Company Methods and apparatus to correlate healthcare information
US10048992B2 (en) * 2011-04-13 2018-08-14 Microsoft Technology Licensing, Llc Extension of schematized XML protocols
WO2012143926A1 (en) 2011-04-18 2012-10-26 HCS KABLOLAMA SISTEMLERI SAN. ve TIC.A.S. A method of analyzing patching among panels
US8816868B2 (en) * 2011-06-06 2014-08-26 Apple Inc. Adaptive low-battery warnings for battery-powered electronic devices
AU2012299169B2 (en) 2011-08-19 2017-08-24 Icu Medical, Inc. Systems and methods for a graphical interface including a graphical representation of medical data
KR101942335B1 (en) * 2011-09-30 2019-01-28 삼성전자 주식회사 Method for integrated management of maintenance of electronic devices and system thereof
US9235681B2 (en) * 2011-10-04 2016-01-12 Smith & Nephew, Inc. System and method for intersystem device exchange
US20130132109A1 (en) * 2011-11-17 2013-05-23 Infosys Limited System and method for remote management of medical devices and patients
US10022498B2 (en) 2011-12-16 2018-07-17 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
CN102571438B (en) * 2012-01-16 2018-01-05 中国科学院深圳先进技术研究院 Remote monitoring system and its automatic network diagnostic method
US10638999B2 (en) 2012-02-02 2020-05-05 Netspective Communications Llc System for controlling medical devices
US9995611B2 (en) 2012-03-30 2018-06-12 Icu Medical, Inc. Air detection system and method for detecting air in a pump of an infusion system
US9092762B2 (en) * 2012-04-05 2015-07-28 Welch Allyn, Inc. Medical device maintenance system
US9223903B2 (en) * 2012-04-19 2015-12-29 International Business Machines Corporation Analyzing data from a sensor-enabled device
US9996681B2 (en) * 2012-05-18 2018-06-12 Carefusion 303, Inc. Mobile device access for medical devices
US11871901B2 (en) 2012-05-20 2024-01-16 Cilag Gmbh International Method for situational awareness for surgical network or surgical network connected device capable of adjusting function based on a sensed situation or usage
US20130321425A1 (en) 2012-06-05 2013-12-05 Dexcom, Inc. Reporting modules
US9886550B2 (en) * 2012-06-06 2018-02-06 Zyno Medical, Llc Medical pump with operator-authorization awareness
US9238100B2 (en) 2012-06-07 2016-01-19 Tandem Diabetes Care, Inc. Device and method for training users of ambulatory medical devices
US10650917B2 (en) * 2012-07-02 2020-05-12 Carefusion 303, Inc. Patient-device association system
US20140025392A1 (en) * 2012-07-18 2014-01-23 Curlin Medical Inc. Systems and Methods for Validating Treatment Instructions
ES2743160T3 (en) 2012-07-31 2020-02-18 Icu Medical Inc Patient care system for critical medications
US20150302214A1 (en) * 2012-08-01 2015-10-22 Koninklijke Philips N.V. Federated patient guaranteed unique identificaiton (guid) matching
US9269074B2 (en) 2012-11-06 2016-02-23 Oracle International Corporation Facilitating viewing of temporal values for multiple fields
CA2891242C (en) 2012-11-13 2022-08-30 Baxter International Inc. Infusion line management system
DE102012023412A1 (en) * 2012-11-30 2014-06-05 Dräger Medical GmbH Pump compatibility test
CN112270969A (en) * 2012-12-21 2021-01-26 德卡产品有限公司 System for electronic patient care
CA3217838A1 (en) * 2012-12-21 2014-06-26 Deka Products Limited Partnership System, method, and apparatus for communicating data
NZ709291A (en) * 2012-12-21 2018-11-30 Deka Products Lp System and apparatus for electronic patient care
US9124585B1 (en) * 2012-12-31 2015-09-01 Emc Corporation Framework for mapping network addresses to hosts in an enterprise network
TWI512665B (en) * 2013-01-18 2015-12-11 Kuo Yuan Chang Ward cloud system
CN105103156B (en) * 2013-01-23 2018-06-01 百特恩格伍德公司 The dedicated configuration output of care equipment
US11182728B2 (en) 2013-01-30 2021-11-23 Carefusion 303, Inc. Medication workflow management
US10430554B2 (en) 2013-05-23 2019-10-01 Carefusion 303, Inc. Medication preparation queue
EP2954483B1 (en) 2013-02-05 2021-12-29 Invenix, Inc. Medical device management using associations
CA3188079A1 (en) * 2013-02-05 2014-08-14 Deka Products Limited Partnership Devices, methods and systems for wireless control of medical devices
US9871701B2 (en) 2013-02-18 2018-01-16 Hcs Kablolama Sistemleri Sanayi Ve Ticaret A.S. Endpoint mapping in a communication system using serial signal sensing
EP2973370A4 (en) 2013-03-13 2016-08-17 Carefusion 303 Inc Predictive medication safety
WO2014159280A1 (en) 2013-03-13 2014-10-02 Carefusion 303, Inc. Patient-specific medication management system
US9737649B2 (en) 2013-03-14 2017-08-22 Smith & Nephew, Inc. Systems and methods for applying reduced pressure therapy
AU2014236701B2 (en) * 2013-03-14 2018-07-19 Smith & Nephew Inc. Systems and methods for applying reduced pressure therapy
US11284815B2 (en) * 2013-04-26 2022-03-29 Roche Diabetes Care, Inc. Bolus calculator time keeping between mobile phone application and bG meters
WO2014190264A1 (en) 2013-05-24 2014-11-27 Hospira, Inc. Multi-sensor infusion system for detecting air or an occlusion in the infusion system
AU2014274146B2 (en) 2013-05-29 2019-01-24 Icu Medical, Inc. Infusion system which utilizes one or more sensors and additional information to make an air determination regarding the infusion system
CA2913918C (en) 2013-05-29 2022-02-15 Hospira, Inc. Infusion system and method of use which prevents over-saturation of an analog-to-digital converter
US9838645B2 (en) 2013-10-31 2017-12-05 Elwha Llc Remote monitoring of telemedicine device
US9075906B2 (en) 2013-06-28 2015-07-07 Elwha Llc Medical support system including medical equipment case
US10155070B2 (en) 2013-08-13 2018-12-18 Smith & Nephew, Inc. Systems and methods for applying reduced pressure therapy
CN104426644A (en) * 2013-08-21 2015-03-18 华为技术有限公司 Equipment time synchronization method and device
US9889257B2 (en) * 2013-08-21 2018-02-13 Medtronic Minimed, Inc. Systems and methods for updating medical devices
US10430424B2 (en) 2013-10-30 2019-10-01 Entit Software Llc Parameter suggestion based on user activity
US20150120312A1 (en) * 2013-10-31 2015-04-30 Elwha Llc Telemedicine device with usage monitoring
TWI526976B (en) * 2013-11-21 2016-03-21 動聯國際股份有限公司 Monitoring system, method, and medical monitoring system
KR102250094B1 (en) * 2013-12-23 2021-05-10 삼성전자주식회사 Method for performing function and mobile apparatus using the method
WO2015100340A1 (en) 2013-12-26 2015-07-02 Tandem Diabetes Care, Inc. Safety processor for wireless control of a drug delivery device
US9962485B2 (en) * 2013-12-30 2018-05-08 Cerner Innovation, Inc. Automatically disassociating medical devices from patients
US9558649B2 (en) * 2013-12-31 2017-01-31 General Electric Company System and method for managing patient monitoring alarms
KR101557056B1 (en) * 2014-01-07 2015-10-05 주식회사 비트컴퓨터 Medical device gateway supporting dynamic connectivity and method for driving thereof
GB2524717A (en) * 2014-01-30 2015-10-07 Cellnovo Ltd Managing communications to and from a handset device controlling a therapeutic product delivery device
EP3110474B1 (en) 2014-02-28 2019-12-18 ICU Medical, Inc. Infusion system and method which utilizes dual wavelength optical air-in-line detection
US10441717B2 (en) 2014-04-15 2019-10-15 Insulet Corporation Monitoring a physiological parameter associated with tissue of a host to confirm delivery of medication
US10832495B2 (en) 2014-04-18 2020-11-10 Carefusion 303, Inc. Remote maintenance of medical devices
WO2015179915A1 (en) 2014-05-27 2015-12-03 Resmed Limited Remote respiratory therapy device management
AU2015266706B2 (en) 2014-05-29 2020-01-30 Icu Medical, Inc. Infusion system and pump with configurable closed loop delivery rate catch-up
US20160294605A1 (en) * 2014-07-07 2016-10-06 Symphony Teleca Corporation Remote Embedded Device Update Platform Apparatuses, Methods and Systems
CN106687154B (en) 2014-07-31 2021-02-09 史密夫和内修有限公司 Systems and methods for administering reduced pressure therapy
WO2016020825A1 (en) * 2014-08-04 2016-02-11 Koninklijke Philips N.V. Translating respiratory therapy parameters
US10002235B2 (en) * 2014-08-13 2018-06-19 Ivenix, Inc. Medical device management and theft inhibitor techniques
US10410745B2 (en) 2014-09-03 2019-09-10 Smiths Medical Asd, Inc. Medical device association systems and methods
EP3720099B1 (en) * 2014-10-17 2024-03-13 Gambro Lundia AB Method for providing operation data to a fluid processing medical apparatus using a medical accessory and a medical accessory
US11504192B2 (en) 2014-10-30 2022-11-22 Cilag Gmbh International Method of hub communication with surgical instrument systems
US10792422B2 (en) * 2014-11-10 2020-10-06 White Bear Medical LLC Dynamically controlled treatment protocols for autonomous treatment systems
US11344668B2 (en) 2014-12-19 2022-05-31 Icu Medical, Inc. Infusion system with concurrent TPN/insulin infusion
AU2015374639B2 (en) 2014-12-30 2020-09-10 Smith & Nephew, Inc. Systems and methods for applying reduced pressure therapy
WO2016109041A1 (en) 2014-12-30 2016-07-07 Smith & Nephew, Inc. Systems and methods for applying reduced pressure therapy
US20160253077A1 (en) * 2015-02-27 2016-09-01 General Electric Company Synchronizing system and method for syncing event logs from different monitoring systems
US10269452B2 (en) 2015-02-27 2019-04-23 Zoll Medical Corporation Downloading and booting method and system for a wearable medical device
US10850024B2 (en) 2015-03-02 2020-12-01 Icu Medical, Inc. Infusion system, device, and method having advanced infusion features
JPWO2016152238A1 (en) * 2015-03-26 2018-01-18 テルモ株式会社 Pump monitoring system and pump monitoring server
US20160283671A1 (en) * 2015-03-27 2016-09-29 Siemens Aktiengesellschaft Scheduling apparatus, scheduling method and diagnostic system
WO2016160841A1 (en) * 2015-03-30 2016-10-06 Zoll Medical Corporation Clinical data handoff in device management and data sharing
EP3281602A4 (en) * 2015-04-07 2018-11-21 J. Morita Manufacturing Corporation Medical diagnostic apparatus
KR101750334B1 (en) * 2015-04-29 2017-06-23 씨제이씨지브이 주식회사 System and method for controlling movie theater
US11567962B2 (en) * 2015-07-11 2023-01-31 Taascom Inc. Computer network controlled data orchestration system and method for data aggregation, normalization, for presentation, analysis and action/decision making
EP3326139A4 (en) * 2015-07-21 2019-03-20 The Arizona Board of Regents On Behalf of the University of Arizona Patient coordination system and method
CN105022926B (en) * 2015-07-29 2018-10-02 苏州麦迪斯顿医疗科技股份有限公司 Medical system information processing method
US11883202B2 (en) * 2015-09-22 2024-01-30 Medtronic, Inc. System and method for interacting with an implantable medical device
US11315681B2 (en) 2015-10-07 2022-04-26 Smith & Nephew, Inc. Reduced pressure therapy device operation and authorization monitoring
US9633088B1 (en) * 2015-10-20 2017-04-25 Voalte, Inc. Event log versioning, synchronization, and consolidation
US10881783B2 (en) * 2015-11-20 2021-01-05 Fenwal, Inc. Processing infusion pump data for presentation on operator interface
EP3173958A1 (en) * 2015-11-25 2017-05-31 Fenwal, Inc. Medical device location authorization
US10306012B2 (en) * 2015-11-25 2019-05-28 Fenwal, Inc. Secure network access to infusion pump
RU2734294C2 (en) 2015-12-17 2020-10-14 Фрезениус Виаль Сас Method and system for distributing keys between a server and a medical device
US20170185953A1 (en) * 2015-12-28 2017-06-29 Dexcom, Inc. Controlled ordering of supplies for medical devices and systems
US11516617B2 (en) * 2016-03-14 2022-11-29 Koninklijke Philips N.V. System and method for facilitating a user interface via device-on premise detection and event generation based thereon
EP3454917B1 (en) 2016-05-13 2022-04-06 Smith & Nephew, Inc Automatic wound coupling detection in negative pressure wound therapy systems
AU2017264784B2 (en) 2016-05-13 2022-04-21 Icu Medical, Inc. Infusion pump system and method with common line auto flush
EP3252635B1 (en) * 2016-06-03 2019-12-04 Fenwal, Inc. Medical device connection status monitoring
EP3468635A4 (en) 2016-06-10 2019-11-20 ICU Medical, Inc. Acoustic flow sensor for continuous medication flow measurements and feedback control of infusion
SE541780C2 (en) * 2016-07-07 2019-12-17 Brighter Ab Publ Method involving a mobile phone for monitoring a medical device
US10816937B2 (en) * 2016-07-12 2020-10-27 Stryker Corporation Patient support apparatuses with clocks
WO2018038853A1 (en) * 2016-08-24 2018-03-01 OrangeMed, Inc. Multiple control interface for medical ventilator
US10304566B2 (en) 2016-08-26 2019-05-28 Sap Se Method and system for control of electromechanical medical devices
US11370113B2 (en) * 2016-09-06 2022-06-28 Verily Life Sciences Llc Systems and methods for prevention of surgical mistakes
AU2017335635B2 (en) 2016-09-29 2023-01-05 Smith & Nephew, Inc. Construction and protection of components in negative pressure wound therapy systems
CN106373346A (en) * 2016-11-21 2017-02-01 湖南比扬医疗科技有限公司 Alarm method for medical electrical equipment regular maintenance and scrapping
WO2018114346A1 (en) * 2016-12-21 2018-06-28 Gambro Lundia Ab Medical device system including information technology infrastructure having secure cluster domain supporting external domain
DE102016015368A1 (en) * 2016-12-22 2018-06-28 Drägerwerk AG & Co. KGaA Medical device and method for operating a medical device
JP6879752B2 (en) * 2017-02-03 2021-06-02 株式会社日立システムズ Medical device monitoring system
US10506926B2 (en) 2017-02-18 2019-12-17 Arc Devices Limited Multi-vital sign detector in an electronic medical records system
US10492684B2 (en) 2017-02-21 2019-12-03 Arc Devices Limited Multi-vital-sign smartphone system in an electronic medical records system
JP6665815B2 (en) * 2017-02-28 2020-03-13 コニカミノルタ株式会社 Inspection reservation management system
DE102017206877A1 (en) * 2017-04-24 2018-10-25 Fresenius Medical Care Deutschland Gmbh Monitoring system for at least one peritoneal dialysis machine
US9928712B1 (en) * 2017-05-05 2018-03-27 Frederick Huntington Firth Clark System and method for remotely monitoring a medical device
JP6978852B2 (en) * 2017-05-10 2021-12-08 キヤノン株式会社 Synchronous signal output device, control method, and program
CN107145752A (en) * 2017-05-12 2017-09-08 成都康拓邦科技有限公司 Medical Devices control method, device, electronic equipment and readable storage medium storing program for executing
EP3422355B1 (en) * 2017-06-28 2021-08-18 Fenwal, Inc. System and method of synchronizing medical device databases
WO2019014141A1 (en) 2017-07-10 2019-01-17 Smith & Nephew, Inc. Systems and methods for directly interacting with communications module of wound therapy apparatus
US10602987B2 (en) 2017-08-10 2020-03-31 Arc Devices Limited Multi-vital-sign smartphone system in an electronic medical records system
US10637930B2 (en) * 2017-08-14 2020-04-28 Foundry Health System for integrating a detectable medical module
EP3457408B1 (en) * 2017-09-19 2021-09-15 Siemens Healthcare GmbH Healthcare network
JP7176913B2 (en) * 2017-10-12 2022-11-22 日本光電工業株式会社 Biological information processing device, biological information processing method, program and storage medium
JP7039921B2 (en) * 2017-10-16 2022-03-23 富士通株式会社 Location management system and programs
CN111263949A (en) * 2017-10-25 2020-06-09 皇家飞利浦有限公司 Extracting sales and upgrade opportunities from utilization data
US11564756B2 (en) 2017-10-30 2023-01-31 Cilag Gmbh International Method of hub communication with surgical instrument systems
US11291510B2 (en) 2017-10-30 2022-04-05 Cilag Gmbh International Method of hub communication with surgical instrument systems
US11317919B2 (en) 2017-10-30 2022-05-03 Cilag Gmbh International Clip applier comprising a clip crimping system
US11229436B2 (en) 2017-10-30 2022-01-25 Cilag Gmbh International Surgical system comprising a surgical tool and a surgical hub
US11311342B2 (en) 2017-10-30 2022-04-26 Cilag Gmbh International Method for communicating with surgical instrument systems
US11123070B2 (en) 2017-10-30 2021-09-21 Cilag Gmbh International Clip applier comprising a rotatable clip magazine
US11510741B2 (en) 2017-10-30 2022-11-29 Cilag Gmbh International Method for producing a surgical instrument comprising a smart electrical system
US11801098B2 (en) 2017-10-30 2023-10-31 Cilag Gmbh International Method of hub communication with surgical instrument systems
US11911045B2 (en) 2017-10-30 2024-02-27 Cllag GmbH International Method for operating a powered articulating multi-clip applier
JP7013817B2 (en) * 2017-11-24 2022-02-01 トヨタ自動車株式会社 Medical information systems, medical devices, data communication methods, and programs
JP7009955B2 (en) * 2017-11-24 2022-01-26 トヨタ自動車株式会社 Medical data communication equipment, servers, medical data communication methods and medical data communication programs
WO2019112844A1 (en) * 2017-12-05 2019-06-13 Zoll Medical Corporation Medical equipment management
US10089055B1 (en) * 2017-12-27 2018-10-02 Icu Medical, Inc. Synchronized display of screen content on networked devices
US11576677B2 (en) 2017-12-28 2023-02-14 Cilag Gmbh International Method of hub communication, processing, display, and cloud analytics
US11771487B2 (en) 2017-12-28 2023-10-03 Cilag Gmbh International Mechanisms for controlling different electromechanical systems of an electrosurgical instrument
US11410259B2 (en) 2017-12-28 2022-08-09 Cilag Gmbh International Adaptive control program updates for surgical devices
US11376002B2 (en) 2017-12-28 2022-07-05 Cilag Gmbh International Surgical instrument cartridge sensor assemblies
US11666331B2 (en) 2017-12-28 2023-06-06 Cilag Gmbh International Systems for detecting proximity of surgical end effector to cancerous tissue
US11304699B2 (en) 2017-12-28 2022-04-19 Cilag Gmbh International Method for adaptive control schemes for surgical network control and interaction
US11446052B2 (en) 2017-12-28 2022-09-20 Cilag Gmbh International Variation of radio frequency and ultrasonic power level in cooperation with varying clamp arm pressure to achieve predefined heat flux or power applied to tissue
US11659023B2 (en) 2017-12-28 2023-05-23 Cilag Gmbh International Method of hub communication
US10695081B2 (en) 2017-12-28 2020-06-30 Ethicon Llc Controlling a surgical instrument according to sensed closure parameters
US11818052B2 (en) 2017-12-28 2023-11-14 Cilag Gmbh International Surgical network determination of prioritization of communication, interaction, or processing based on system or device needs
US11308075B2 (en) 2017-12-28 2022-04-19 Cilag Gmbh International Surgical network, instrument, and cloud responses based on validation of received dataset and authentication of its source and integrity
US11056244B2 (en) 2017-12-28 2021-07-06 Cilag Gmbh International Automated data scaling, alignment, and organizing based on predefined parameters within surgical networks
US10898622B2 (en) 2017-12-28 2021-01-26 Ethicon Llc Surgical evacuation system with a communication circuit for communication between a filter and a smoke evacuation device
US10892899B2 (en) 2017-12-28 2021-01-12 Ethicon Llc Self describing data packets generated at an issuing instrument
US11266468B2 (en) 2017-12-28 2022-03-08 Cilag Gmbh International Cooperative utilization of data derived from secondary sources by intelligent surgical hubs
US11903601B2 (en) 2017-12-28 2024-02-20 Cilag Gmbh International Surgical instrument comprising a plurality of drive systems
US11389164B2 (en) 2017-12-28 2022-07-19 Cilag Gmbh International Method of using reinforced flexible circuits with multiple sensors to optimize performance of radio frequency devices
US11304763B2 (en) 2017-12-28 2022-04-19 Cilag Gmbh International Image capturing of the areas outside the abdomen to improve placement and control of a surgical device in use
US11202570B2 (en) 2017-12-28 2021-12-21 Cilag Gmbh International Communication hub and storage device for storing parameters and status of a surgical device to be shared with cloud based analytics systems
US10849697B2 (en) 2017-12-28 2020-12-01 Ethicon Llc Cloud interface for coupled surgical devices
US11278281B2 (en) 2017-12-28 2022-03-22 Cilag Gmbh International Interactive surgical system
US11291495B2 (en) 2017-12-28 2022-04-05 Cilag Gmbh International Interruption of energy due to inadvertent capacitive coupling
US10892995B2 (en) 2017-12-28 2021-01-12 Ethicon Llc Surgical network determination of prioritization of communication, interaction, or processing based on system or device needs
US11832899B2 (en) 2017-12-28 2023-12-05 Cilag Gmbh International Surgical systems with autonomously adjustable control programs
US11844579B2 (en) 2017-12-28 2023-12-19 Cilag Gmbh International Adjustments based on airborne particle properties
US11069012B2 (en) 2017-12-28 2021-07-20 Cilag Gmbh International Interactive surgical systems with condition handling of devices and data capabilities
US11304720B2 (en) 2017-12-28 2022-04-19 Cilag Gmbh International Activation of energy devices
US11744604B2 (en) 2017-12-28 2023-09-05 Cilag Gmbh International Surgical instrument with a hardware-only control circuit
US11602393B2 (en) 2017-12-28 2023-03-14 Cilag Gmbh International Surgical evacuation sensing and generator control
US11864728B2 (en) 2017-12-28 2024-01-09 Cilag Gmbh International Characterization of tissue irregularities through the use of mono-chromatic light refractivity
US11076921B2 (en) 2017-12-28 2021-08-03 Cilag Gmbh International Adaptive control program updates for surgical hubs
US11832840B2 (en) 2017-12-28 2023-12-05 Cilag Gmbh International Surgical instrument having a flexible circuit
US11672605B2 (en) 2017-12-28 2023-06-13 Cilag Gmbh International Sterile field interactive control displays
US11559308B2 (en) 2017-12-28 2023-01-24 Cilag Gmbh International Method for smart energy device infrastructure
US11096693B2 (en) 2017-12-28 2021-08-24 Cilag Gmbh International Adjustment of staple height of at least one row of staples based on the sensed tissue thickness or force in closing
US11419667B2 (en) 2017-12-28 2022-08-23 Cilag Gmbh International Ultrasonic energy device which varies pressure applied by clamp arm to provide threshold control pressure at a cut progression location
US11432885B2 (en) 2017-12-28 2022-09-06 Cilag Gmbh International Sensing arrangements for robot-assisted surgical platforms
US10943454B2 (en) 2017-12-28 2021-03-09 Ethicon Llc Detection and escalation of security responses of surgical instruments to increasing severity threats
US11786245B2 (en) 2017-12-28 2023-10-17 Cilag Gmbh International Surgical systems with prioritized data transmission capabilities
US11179208B2 (en) 2017-12-28 2021-11-23 Cilag Gmbh International Cloud-based medical analytics for security and authentication trends and reactive measures
US11529187B2 (en) 2017-12-28 2022-12-20 Cilag Gmbh International Surgical evacuation sensor arrangements
US11678881B2 (en) 2017-12-28 2023-06-20 Cilag Gmbh International Spatial awareness of surgical hubs in operating rooms
US11109866B2 (en) 2017-12-28 2021-09-07 Cilag Gmbh International Method for circular stapler control algorithm adjustment based on situational awareness
US11100631B2 (en) 2017-12-28 2021-08-24 Cilag Gmbh International Use of laser light and red-green-blue coloration to determine properties of back scattered light
US11273001B2 (en) 2017-12-28 2022-03-15 Cilag Gmbh International Surgical hub and modular device response adjustment based on situational awareness
US11284936B2 (en) 2017-12-28 2022-03-29 Cilag Gmbh International Surgical instrument having a flexible electrode
US11896443B2 (en) 2017-12-28 2024-02-13 Cilag Gmbh International Control of a surgical system through a surgical barrier
US11234756B2 (en) 2017-12-28 2022-02-01 Cilag Gmbh International Powered surgical tool with predefined adjustable control algorithm for controlling end effector parameter
US11213359B2 (en) 2017-12-28 2022-01-04 Cilag Gmbh International Controllers for robot-assisted surgical platforms
US11419630B2 (en) 2017-12-28 2022-08-23 Cilag Gmbh International Surgical system distributed processing
US11857152B2 (en) 2017-12-28 2024-01-02 Cilag Gmbh International Surgical hub spatial awareness to determine devices in operating theater
US11589888B2 (en) 2017-12-28 2023-02-28 Cilag Gmbh International Method for controlling smart energy devices
US11317937B2 (en) 2018-03-08 2022-05-03 Cilag Gmbh International Determining the state of an ultrasonic end effector
US11013563B2 (en) 2017-12-28 2021-05-25 Ethicon Llc Drive arrangements for robot-assisted surgical platforms
US11464535B2 (en) 2017-12-28 2022-10-11 Cilag Gmbh International Detection of end effector emersion in liquid
US11166772B2 (en) 2017-12-28 2021-11-09 Cilag Gmbh International Surgical hub coordination of control and communication of operating room devices
US11540855B2 (en) 2017-12-28 2023-01-03 Cilag Gmbh International Controlling activation of an ultrasonic surgical instrument according to the presence of tissue
US11324557B2 (en) 2017-12-28 2022-05-10 Cilag Gmbh International Surgical instrument with a sensing array
US11147607B2 (en) 2017-12-28 2021-10-19 Cilag Gmbh International Bipolar combination device that automatically adjusts pressure based on energy modality
US11424027B2 (en) 2017-12-28 2022-08-23 Cilag Gmbh International Method for operating surgical instrument systems
US11364075B2 (en) 2017-12-28 2022-06-21 Cilag Gmbh International Radio frequency energy device for delivering combined electrical signals
US11257589B2 (en) 2017-12-28 2022-02-22 Cilag Gmbh International Real-time analysis of comprehensive cost of all instrumentation used in surgery utilizing data fluidity to track instruments through stocking and in-house processes
US11051876B2 (en) 2017-12-28 2021-07-06 Cilag Gmbh International Surgical evacuation flow paths
US11464559B2 (en) 2017-12-28 2022-10-11 Cilag Gmbh International Estimating state of ultrasonic end effector and control system therefor
US11786251B2 (en) 2017-12-28 2023-10-17 Cilag Gmbh International Method for adaptive control schemes for surgical network control and interaction
US11896322B2 (en) 2017-12-28 2024-02-13 Cilag Gmbh International Sensing the patient position and contact utilizing the mono-polar return pad electrode to provide situational awareness to the hub
US11571234B2 (en) 2017-12-28 2023-02-07 Cilag Gmbh International Temperature control of ultrasonic end effector and control system therefor
US10987178B2 (en) 2017-12-28 2021-04-27 Ethicon Llc Surgical hub control arrangements
US11423007B2 (en) 2017-12-28 2022-08-23 Cilag Gmbh International Adjustment of device control programs based on stratified contextual data in addition to the data
US11633237B2 (en) 2017-12-28 2023-04-25 Cilag Gmbh International Usage and technique analysis of surgeon / staff performance against a baseline to optimize device utilization and performance for both current and future procedures
US11304745B2 (en) 2017-12-28 2022-04-19 Cilag Gmbh International Surgical evacuation sensing and display
US10755813B2 (en) 2017-12-28 2020-08-25 Ethicon Llc Communication of smoke evacuation system parameters to hub or cloud in smoke evacuation module for interactive surgical platform
US10932872B2 (en) 2017-12-28 2021-03-02 Ethicon Llc Cloud-based medical analytics for linking of local usage trends with the resource acquisition behaviors of larger data set
US11559307B2 (en) 2017-12-28 2023-01-24 Cilag Gmbh International Method of robotic hub communication, detection, and control
US11132462B2 (en) 2017-12-28 2021-09-28 Cilag Gmbh International Data stripping method to interrogate patient records and create anonymized record
US10966791B2 (en) 2017-12-28 2021-04-06 Ethicon Llc Cloud-based medical analytics for medical facility segmented individualization of instrument function
US10758310B2 (en) 2017-12-28 2020-09-01 Ethicon Llc Wireless pairing of a surgical device with another device within a sterile surgical field based on the usage and situational awareness of devices
US11311306B2 (en) 2017-12-28 2022-04-26 Cilag Gmbh International Surgical systems for detecting end effector tissue distribution irregularities
US20190200981A1 (en) 2017-12-28 2019-07-04 Ethicon Llc Method of compressing tissue within a stapling device and simultaneously displaying the location of the tissue within the jaws
US20190201146A1 (en) 2017-12-28 2019-07-04 Ethicon Llc Safety systems for smart powered surgical stapling
US11160605B2 (en) 2017-12-28 2021-11-02 Cilag Gmbh International Surgical evacuation sensing and motor control
US11179175B2 (en) 2017-12-28 2021-11-23 Cilag Gmbh International Controlling an ultrasonic surgical instrument according to tissue location
US11253315B2 (en) 2017-12-28 2022-02-22 Cilag Gmbh International Increasing radio frequency to create pad-less monopolar loop
US10944728B2 (en) 2017-12-28 2021-03-09 Ethicon Llc Interactive surgical systems with encrypted communication capabilities
US11856406B2 (en) * 2018-01-29 2023-12-26 Koninklijke Philips N.V. Securing headless devices from malicious (re-)configuration
JP6481787B1 (en) * 2018-02-14 2019-03-13 オムロン株式会社 Device selection apparatus, data set selection apparatus, device selection method and program
US11534196B2 (en) 2018-03-08 2022-12-27 Cilag Gmbh International Using spectroscopy to determine device use state in combo instrument
US11337746B2 (en) 2018-03-08 2022-05-24 Cilag Gmbh International Smart blade and power pulsing
US11259830B2 (en) 2018-03-08 2022-03-01 Cilag Gmbh International Methods for controlling temperature in ultrasonic device
US11589865B2 (en) 2018-03-28 2023-02-28 Cilag Gmbh International Methods for controlling a powered surgical stapler that has separate rotary closure and firing systems
US11096688B2 (en) 2018-03-28 2021-08-24 Cilag Gmbh International Rotary driven firing members with different anvil and channel engagement features
US11278280B2 (en) 2018-03-28 2022-03-22 Cilag Gmbh International Surgical instrument comprising a jaw closure lockout
US11471156B2 (en) 2018-03-28 2022-10-18 Cilag Gmbh International Surgical stapling devices with improved rotary driven closure systems
US10973520B2 (en) 2018-03-28 2021-04-13 Ethicon Llc Surgical staple cartridge with firing member driven camming assembly that has an onboard tissue cutting feature
US11166716B2 (en) 2018-03-28 2021-11-09 Cilag Gmbh International Stapling instrument comprising a deactivatable lockout
US11219453B2 (en) 2018-03-28 2022-01-11 Cilag Gmbh International Surgical stapling devices with cartridge compatible closure and firing lockout arrangements
US11090047B2 (en) 2018-03-28 2021-08-17 Cilag Gmbh International Surgical instrument comprising an adaptive control system
US11207067B2 (en) 2018-03-28 2021-12-28 Cilag Gmbh International Surgical stapling device with separate rotary driven closure and firing systems and firing member that engages both jaws while firing
WO2019199920A1 (en) * 2018-04-10 2019-10-17 Bigfoot Biomedical, Inc. Time management for time-dependent therapy management systems, methods, and devices
US20190327584A1 (en) * 2018-04-18 2019-10-24 Fresenius Medical Care Holdings, Inc. Home Dialysis Management Using a Connected Health System Network
US10485431B1 (en) 2018-05-21 2019-11-26 ARC Devices Ltd. Glucose multi-vital-sign system in an electronic medical records system
DE102018005193A1 (en) * 2018-07-02 2020-01-02 Drägerwerk AG & Co. KGaA Method for operating a medical device and medical device operating according to the method
EP3591662A1 (en) * 2018-07-05 2020-01-08 Advanced Microfluidics SA Medical device and secure control system
US20200013501A1 (en) * 2018-07-09 2020-01-09 General Electric Company Predictive medical equipment maintenance management
CN109065141A (en) * 2018-07-25 2018-12-21 深圳市理邦精密仪器股份有限公司 A kind of Medical Devices configuration management device, system and its configuration information synchronous method
US11241532B2 (en) 2018-08-29 2022-02-08 Insulet Corporation Drug delivery system with sensor having optimized communication and infusion site
EP3637429A1 (en) * 2018-10-10 2020-04-15 Gambro Lundia AB Operating a medical device during startup and shutdown
AU2019372236A1 (en) * 2018-10-31 2021-04-15 Alcon Inc. System and method of utilizing data of medical systems
CN111125436B (en) * 2018-10-31 2023-08-08 杭州海康威视系统技术有限公司 Data management method, device and system
GB201820668D0 (en) 2018-12-19 2019-01-30 Smith & Nephew Inc Systems and methods for delivering prescribed wound therapy
CA3121850A1 (en) 2019-01-03 2020-07-09 Avive Solutions, Inc. Defibrillator communications architecture
US11751872B2 (en) 2019-02-19 2023-09-12 Cilag Gmbh International Insertable deactivator element for surgical stapler lockouts
US11357503B2 (en) 2019-02-19 2022-06-14 Cilag Gmbh International Staple cartridge retainers with frangible retention features and methods of using same
US11317915B2 (en) 2019-02-19 2022-05-03 Cilag Gmbh International Universal cartridge based key feature that unlocks multiple lockout arrangements in different surgical staplers
US11369377B2 (en) 2019-02-19 2022-06-28 Cilag Gmbh International Surgical stapling assembly with cartridge based retainer configured to unlock a firing lockout
US11259807B2 (en) 2019-02-19 2022-03-01 Cilag Gmbh International Staple cartridges with cam surfaces configured to engage primary and secondary portions of a lockout of a surgical stapling device
US11159550B1 (en) 2019-03-01 2021-10-26 Chronicle Llc Correcting timestamps for computer security telemetry data
CA3130429A1 (en) * 2019-03-27 2020-10-01 Alcon Inc. System and method of utilizing data of medical systems
CN112071414A (en) * 2019-05-21 2020-12-11 佳纶生技股份有限公司 Event state management method and system
US20220223286A1 (en) * 2019-06-07 2022-07-14 University Of Virginia Patent Foundation System, method and computer readable medium for improving symptom treatment in regards to the patient and caregiver dyad
USD950728S1 (en) 2019-06-25 2022-05-03 Cilag Gmbh International Surgical staple cartridge
USD964564S1 (en) 2019-06-25 2022-09-20 Cilag Gmbh International Surgical staple cartridge retainer with a closure system authentication key
USD952144S1 (en) 2019-06-25 2022-05-17 Cilag Gmbh International Surgical staple cartridge retainer with firing system authentication key
CA3146872A1 (en) 2019-07-16 2021-01-21 Beta Bionics, Inc. Blood glucose control system
US11056232B2 (en) 2019-08-18 2021-07-06 Medigate tech Ltd. Medication usage auditing based on analysis of infusion pump network traffic
US10825566B1 (en) 2019-08-18 2020-11-03 Medigate tech Ltd. Ensuring availability of medical devices to receive maintenance
US10658079B1 (en) 2019-08-18 2020-05-19 Medigate tech Ltd. Crowd-based recommendations of a version of firmware for medical devices
US10600512B1 (en) 2019-08-18 2020-03-24 Medigate tech Ltd. Network-based calculation of prevalence of repeated medical imaging
US11424025B2 (en) * 2019-08-30 2022-08-23 GE Precision Healthcare LLC Systems and methods for medical device monitoring
WO2021095004A1 (en) * 2019-11-14 2021-05-20 ResMed Pty Ltd Remote respiratory therapy device management
CA3159626A1 (en) * 2019-11-25 2021-06-03 Nxstage Medical, Inc. User interface monitoring and verification thereof in medical treatment systems
US11278671B2 (en) 2019-12-04 2022-03-22 Icu Medical, Inc. Infusion pump with safety sequence keypad
CA3179709A1 (en) * 2020-04-10 2021-10-14 Carefusion 303, Inc. Infusion management system
AU2021258206A1 (en) * 2020-04-24 2022-11-03 Baxter Healthcare Sa Medical device audible and visual alarm synchronization
US11911595B2 (en) 2020-05-18 2024-02-27 Tandem Diabetes Care, Inc. Systems and methods for automated insulin delivery response to meal announcements
WO2021247300A1 (en) 2020-06-01 2021-12-09 Arc Devices Limited Apparatus and methods for measuring blood pressure and other vital signs via a finger
WO2022020184A1 (en) 2020-07-21 2022-01-27 Icu Medical, Inc. Fluid transfer devices and methods of use
US11561884B2 (en) 2020-11-18 2023-01-24 Netspective Communications Llc Computer-controlled metrics and task lists management
US11135360B1 (en) 2020-12-07 2021-10-05 Icu Medical, Inc. Concurrent infusion with common line auto flush
CN112559252B (en) * 2020-12-23 2021-09-03 广州技象科技有限公司 Configuration data management method and device based on attribute classification
US20220229915A1 (en) * 2021-01-20 2022-07-21 Dell Products L.P. Electronic device management utilizing a distributed ledger
KR102527619B1 (en) * 2021-06-29 2023-04-28 가톨릭대학교 산학협력단 Medical device management system and method based on virtual warehouse platform
US11311346B1 (en) * 2021-11-24 2022-04-26 Bh2 Innovations Inc. Systems and methods for automated control of medical instruments using artificial intelligence

Citations (87)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5434775A (en) * 1993-11-04 1995-07-18 The General Hospital Corporation Managing an inventory of devices
US5455851A (en) * 1993-07-02 1995-10-03 Executone Information Systems, Inc. System for identifying object locations
US5458123A (en) * 1992-12-16 1995-10-17 Siemens Medical Systems, Inc. System for monitoring patient location and data
US5522396A (en) * 1992-05-12 1996-06-04 Cardiac Telecom Corporation Method and system for monitoring the heart of a patient
US5542420A (en) * 1993-04-30 1996-08-06 Goldman; Arnold J. Personalized method and system for storage, communication, analysis, and processing of health-related data
US5549117A (en) * 1994-05-23 1996-08-27 Enact Health Management Systems System for monitoring and reporting medical measurements
US5582593A (en) * 1994-07-21 1996-12-10 Hultman; Barry W. Ambulatory medication delivery system
US5594786A (en) * 1990-07-27 1997-01-14 Executone Information Systems, Inc. Patient care and communication system
US5658250A (en) * 1993-07-13 1997-08-19 Sims Deltec, Inc. Systems and methods for operating ambulatory medical devices such as drug delivery devices
US5687717A (en) * 1996-08-06 1997-11-18 Tremont Medical, Inc. Patient monitoring system with chassis mounted or remotely operable modules and portable computer
US5713856A (en) * 1995-03-13 1998-02-03 Alaris Medical Systems, Inc. Modular patient care system
US5788669A (en) * 1995-11-22 1998-08-04 Sims Deltec, Inc. Pump tracking system
US5832448A (en) * 1996-10-16 1998-11-03 Health Hero Network Multiple patient monitoring system for proactive health management
US5842976A (en) * 1996-05-16 1998-12-01 Pyxis Corporation Dispensing, storage, control and inventory system with medication and treatment chart record
US5897493A (en) * 1997-03-28 1999-04-27 Health Hero Network, Inc. Monitoring system for remotely querying individuals
US5907291A (en) * 1997-06-05 1999-05-25 Vsm Technology Inc. Multi-patient monitoring apparatus and method
US6032155A (en) * 1997-04-14 2000-02-29 De La Huerga; Carlos System and apparatus for administering prescribed medication to a patient
US6074345A (en) * 1998-10-27 2000-06-13 University Of Florida Patient data acquisition and control system
US6101478A (en) * 1997-04-30 2000-08-08 Health Hero Network Multi-user remote health monitoring system
US6144922A (en) * 1997-10-31 2000-11-07 Mercury Diagnostics, Incorporated Analyte concentration information collection and communication system
US6168563B1 (en) * 1992-11-17 2001-01-02 Health Hero Network, Inc. Remote health monitoring and maintenance system
US6196970B1 (en) * 1999-03-22 2001-03-06 Stephen J. Brown Research data collection and analysis
US6221011B1 (en) * 1999-07-26 2001-04-24 Cardiac Intelligence Corporation System and method for determining a reference baseline of individual patient status for use in an automated collection and analysis patient care system
US6270457B1 (en) * 1999-06-03 2001-08-07 Cardiac Intelligence Corp. System and method for automated collection and analysis of regularly retrieved patient information for remote patient care
US6283923B1 (en) * 1998-05-28 2001-09-04 The Trustees Of Columbia University In The City Of New York System and method for remotely monitoring asthma severity
US6290646B1 (en) * 1999-04-16 2001-09-18 Cardiocom Apparatus and method for monitoring and communicating wellness parameters of ambulatory patients
US6334778B1 (en) * 1994-04-26 2002-01-01 Health Hero Network, Inc. Remote psychological diagnosis and monitoring system
US20020016719A1 (en) * 2000-06-19 2002-02-07 Nemeth Louis G. Methods and systems for providing medical data to a third party in accordance with configurable distribution parameters
US6350237B1 (en) * 1999-11-05 2002-02-26 General Electric Company Method and apparatus for monitoring fetal status data
US6352200B1 (en) * 1994-06-09 2002-03-05 Consumer Health Entrepreneurs B.V. Medicament distribution system and automatic dispenser for such system
US6364834B1 (en) * 1996-11-13 2002-04-02 Criticare Systems, Inc. Method and system for remotely monitoring multiple medical parameters in an integrated medical monitoring system
US6368273B1 (en) * 1997-03-28 2002-04-09 Health Hero Network, Inc. Networked system for interactive communication and remote monitoring of individuals
US20020049684A1 (en) * 2000-05-31 2002-04-25 Shunichi Nagamoto Medical checkup network system
US6400987B1 (en) * 1997-08-13 2002-06-04 Sorin Biomedica Cardio S.P.A. Active implantable device
US6402691B1 (en) * 1999-09-21 2002-06-11 Herschel Q. Peddicord In-home patient monitoring system
US20020072933A1 (en) * 2000-06-30 2002-06-13 Vonk Glenn Philander Health outcomes and disease management network and related method for providing improved patient care
US6409662B1 (en) * 1997-10-28 2002-06-25 Alere Medical, Inc. Patient interface system
US20020087362A1 (en) * 2001-01-02 2002-07-04 Cobb David M. Systems and methods for tracking administration of medical products
US20020128864A1 (en) * 2001-03-06 2002-09-12 Maus Christopher T. Computerized information processing and retrieval system
US20020133377A1 (en) * 2001-03-14 2002-09-19 Brown Stephen J. Interactive patient communication development system for reporting on patient healthcare management
US6454705B1 (en) * 1999-09-21 2002-09-24 Cardiocom Medical wellness parameters management system, apparatus and method
US20020147390A1 (en) * 2000-12-20 2002-10-10 Markis John Emmanuel M.D. Methods and apparatus for acquiring and using bedside medical data
US20020156650A1 (en) * 2001-02-17 2002-10-24 Klein Michael V. Secure distribution of digital healthcare data using an offsite internet file server
US20020169638A1 (en) * 2001-05-09 2002-11-14 Domingo Rodriguez-Cue System and method for providing wireless, paperless medical care and communication
US6485415B1 (en) * 1998-09-25 2002-11-26 Pioneer Corporation Medical monitoring system
US20020177758A1 (en) * 1996-12-30 2002-11-28 Ido Schoenberg Patient treatment and progress monitor display
US20030004751A1 (en) * 2001-05-24 2003-01-02 Kok-Hwee Ng System and method for tracking a blood collection kit in a blood collection facility
US20030014283A1 (en) * 2000-07-14 2003-01-16 Kenji Iwano Medical information system patient-use terminal device, medium
US6522916B1 (en) * 2000-05-09 2003-02-18 Ki Chul Kwon Telemetric system for fetal care
US20030065536A1 (en) * 2001-08-13 2003-04-03 Hansen Henrik Egesborg Portable device and method of communicating medical data information
US6544198B2 (en) * 2001-06-11 2003-04-08 Hoseo University Stethoscope system for self-examination using internet
US20030069753A1 (en) * 1992-11-17 2003-04-10 Brown Stephen J. Multi-user remote health monitoring system with biometrics support
US20030078812A1 (en) * 2001-08-30 2003-04-24 Olympus Optical Co., Ltd. Medical information system for improving efficiency of clinical record creating operations
US6558321B1 (en) * 1997-03-04 2003-05-06 Dexcom, Inc. Systems and methods for remote monitoring and modulation of medical devices
US20030093301A1 (en) * 2001-11-13 2003-05-15 Hypertension Diagnostics, Inc. Centralized clinical data management system process for analysis and billing
US20030098022A1 (en) * 2001-11-27 2003-05-29 Omron Corporation Nebulizer optimal for patient at home care
US6574511B2 (en) * 2000-04-21 2003-06-03 Medtronic, Inc. Passive data collection system from a fleet of medical instruments and implantable devices
US6575900B1 (en) * 1999-03-29 2003-06-10 Beckman Coulter, Inc. Meter with integrated database and simplified telemedicine capability
US20030107487A1 (en) * 2001-12-10 2003-06-12 Ronen Korman Method and device for measuring physiological parameters at the wrist
US6579231B1 (en) * 1998-03-27 2003-06-17 Mci Communications Corporation Personal medical monitoring unit and system
US6598011B1 (en) * 1998-11-25 2003-07-22 Ianne Mae Howards Koritzinsky Medical diagnostic system services interface
US20030163351A1 (en) * 1997-11-21 2003-08-28 Brown Stephen J. Public health surveillance system
US6612984B1 (en) * 1999-12-03 2003-09-02 Kerr, Ii Robert A. System and method for collecting and transmitting medical data
US6618745B2 (en) * 1999-09-10 2003-09-09 Fisher Rosemount Systems, Inc. Linking device in a process control system that allows the formation of a control loop having function blocks in a controller and in field devices
US6633772B2 (en) * 2000-08-18 2003-10-14 Cygnus, Inc. Formulation and manipulation of databases of analyte and associated values
US20030200114A1 (en) * 2000-10-19 2003-10-23 Nihon Kohden Corporation Medical care support system
US6640246B1 (en) * 1999-09-17 2003-10-28 Ge Medical Systems Global Technology Company, Llc Integrated computerized materials management system
US20030204419A1 (en) * 2002-04-30 2003-10-30 Wilkes Gordon J. Automated messaging center system and method for use with a healthcare system
US20030204563A1 (en) * 2002-03-19 2003-10-30 Colin Corporation Diagnosis delivering method
US20030212579A1 (en) * 2002-05-08 2003-11-13 Brown Stephen J. Remote health management system
US20030216624A1 (en) * 2002-05-16 2003-11-20 Microlife Intellectual Property Gmbh System for monitoring medical data, a terminal device for measuring and storing medical data, a medicine container and a holder for medical containers
US6656115B1 (en) * 2000-03-31 2003-12-02 Matsushita Electric Industrial Co., Ltd. Medical information system
US6669631B2 (en) * 2000-06-14 2003-12-30 Medtronic, Inc. Deep computing applications in medical device systems
US20040019259A1 (en) * 1992-11-17 2004-01-29 Brown Stephen J. Remote monitoring and data management platform
US6694177B2 (en) * 2001-04-23 2004-02-17 Cardionet, Inc. Control of data transmission between a remote monitoring unit and a central unit
US6699187B2 (en) * 1997-03-27 2004-03-02 Medtronic, Inc. System and method for providing remote expert communications and video capabilities for use during a medical procedure
US6714969B1 (en) * 1995-11-17 2004-03-30 Symbol Technologies, Inc. Mobile terminal with integrated host application software
US6747556B2 (en) * 2001-07-31 2004-06-08 Medtronic Physio-Control Corp. Method and system for locating a portable medical device
US6758812B2 (en) * 2001-02-23 2004-07-06 Brook W. Lang Emergency medical treatment system
US20040199409A1 (en) * 1992-11-17 2004-10-07 Brown Stephen J. Remote health monitoring and maintenance system
US6804656B1 (en) * 1999-06-23 2004-10-12 Visicu, Inc. System and method for providing continuous, expert network critical care services from a remote location(s)
US20040225533A1 (en) * 1999-04-16 2004-11-11 Cosentino Daniel L. Weight loss or weight management system
US6820057B1 (en) * 1996-11-29 2004-11-16 Ventracor Limited Telemedicine system
US20040236606A1 (en) * 2003-05-20 2004-11-25 Olympus Corporation Medical tool management and support system
US6824052B2 (en) * 1999-12-28 2004-11-30 Christopher S. Walsh Healthcare verification methods, apparatus and systems
US6827713B2 (en) * 1998-02-19 2004-12-07 Curon Medical, Inc. Systems and methods for monitoring and controlling use of medical devices
US20040249673A1 (en) * 2003-04-18 2004-12-09 Smith Baird M. Integrated point-of-care systems and methods

Family Cites Families (290)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5935099A (en) * 1992-09-09 1999-08-10 Sims Deltec, Inc. Drug pump systems and methods
US5876370A (en) * 1995-10-11 1999-03-02 Sims Deltec, Inc. Intermittent fluid delivery apparatus and method
US6241704B1 (en) * 1901-11-22 2001-06-05 Sims Deltec, Inc. Drug pump systems and methods
US5108367A (en) * 1984-02-08 1992-04-28 Abbott Laboratories Pressure responsive multiple input infusion system
US5088981A (en) * 1985-01-18 1992-02-18 Howson David C Safety enhanced device and method for effecting application of a therapeutic agent
US5153827A (en) * 1989-01-30 1992-10-06 Omni-Flow, Inc. An infusion management and pumping system having an alarm handling system
IT1244884B (en) * 1990-12-21 1994-09-13 Healtech Sa PROCEDURE AND EQUIPMENT FOR THE UNIQUE COMBINATION OF DRUGS CORRESPONDING TO A THERAPY PREDICTED TO A CERTAIN PATIENT
US5262943A (en) * 1991-10-15 1993-11-16 National Computer Systems, Inc. System and process for information management and reporting
ATE198159T1 (en) * 1992-10-15 2001-01-15 Gen Hospital Corp INFUSION PUMP WITH ELECTRONICALLY LOADABLE MEDICATION LIBRARY
US5956501A (en) * 1997-01-10 1999-09-21 Health Hero Network, Inc. Disease simulation system and method
US8078431B2 (en) 1992-11-17 2011-12-13 Health Hero Network, Inc. Home power management system
US9215979B2 (en) 1992-11-17 2015-12-22 Robert Bosch Healthcare Systems, Inc. Multi-user remote health monitoring system
US6968375B1 (en) 1997-03-28 2005-11-22 Health Hero Network, Inc. Networked system for interactive communication and remote monitoring of individuals
US5940801A (en) * 1994-04-26 1999-08-17 Health Hero Network, Inc. Modular microprocessor-based diagnostic measurement apparatus and method for psychological conditions
US6330426B2 (en) 1994-05-23 2001-12-11 Stephen J. Brown System and method for remote education using a memory card
US5790409A (en) * 1993-01-25 1998-08-04 Medselect Systems, Inc. Inventory monitoring and dispensing system for medical items
US5993046A (en) * 1993-01-25 1999-11-30 Diebold, Incorporated System for dispensing medical items by brand or generic name
US5912818A (en) * 1993-01-25 1999-06-15 Diebold, Incorporated System for tracking and dispensing medical items
US6108588A (en) * 1993-01-25 2000-08-22 Diebold, Incorporated Restocking method for medical item dispensing system
US5368562A (en) * 1993-07-30 1994-11-29 Pharmacia Deltec, Inc. Systems and methods for operating ambulatory medical devices such as drug delivery devices
US5447164A (en) * 1993-11-08 1995-09-05 Hewlett-Packard Company Interactive medical information display system and method for displaying user-definable patient events
US5660176A (en) * 1993-12-29 1997-08-26 First Opinion Corporation Computerized medical diagnostic and treatment advice system
US6206829B1 (en) * 1996-07-12 2001-03-27 First Opinion Corporation Computerized medical diagnostic and treatment advice system including network access
US5594638A (en) * 1993-12-29 1997-01-14 First Opinion Corporation Computerized medical diagnostic system including re-enter function and sensitivity factors
FR2716286A1 (en) * 1994-02-16 1995-08-18 Debiotech Sa Installation of remote monitoring of controllable equipment.
US8015033B2 (en) 1994-04-26 2011-09-06 Health Hero Network, Inc. Treatment regimen compliance and efficacy with feedback
AU2365695A (en) * 1994-04-26 1995-11-16 Raya Systems, Inc. Modular microprocessor-based diagnostic measurement system for psychological conditions
US5910776A (en) * 1994-10-24 1999-06-08 Id Technologies, Inc. Method and apparatus for identifying locating or monitoring equipment or other objects
US7574370B2 (en) 1994-10-28 2009-08-11 Cybear, L.L.C. Prescription management system
US5845255A (en) 1994-10-28 1998-12-01 Advanced Health Med-E-Systems Corporation Prescription management system
US6749586B2 (en) 1994-11-25 2004-06-15 I-Flow Corporation Remotely programmable infusion system
US5848593A (en) * 1994-12-16 1998-12-15 Diebold, Incorporated System for dispensing a kit of associated medical items
US7349858B1 (en) 1994-12-16 2008-03-25 Automed Technologies, Inc. Method of dispensing and tracking the giving of medical items to patients
US7467093B1 (en) 1994-12-16 2008-12-16 Automed Technologies, Inc Method of tracking and despensing medical items to patients through self service delivery system
US5971593A (en) * 1994-12-16 1999-10-26 Diebold, Incorporated Dispensing system for medical items
US5814015A (en) * 1995-02-24 1998-09-29 Harvard Clinical Technology, Inc. Infusion pump for at least one syringe
US5781442A (en) * 1995-05-15 1998-07-14 Alaris Medical Systems, Inc. System and method for collecting data and managing patient care
US6671563B1 (en) 1995-05-15 2003-12-30 Alaris Medical Systems, Inc. System and method for collecting data and managing patient care
US5651775A (en) * 1995-07-12 1997-07-29 Walker; Richard Bradley Medication delivery and monitoring system and methods
US5700998A (en) * 1995-10-31 1997-12-23 Palti; Yoram Drug coding and delivery system
US5838907A (en) * 1996-02-20 1998-11-17 Compaq Computer Corporation Configuration manager for network devices and an associated method for providing configuration information thereto
US5732401A (en) * 1996-03-29 1998-03-24 Intellitecs International Ltd. Activity based cost tracking systems
US5999493A (en) * 1996-05-13 1999-12-07 Survivalink Corporation Synchronization method and apparatus for isolated clock system
US6434569B1 (en) * 1996-06-06 2002-08-13 Kabushiki Kaisha Toshiba Integrated medical information system formed of text-based and image-based databases, and display thereof
US5758643A (en) * 1996-07-29 1998-06-02 Via Medical Corporation Method and apparatus for monitoring blood chemistry
US6689091B2 (en) * 1996-08-02 2004-02-10 Tuan Bui Medical apparatus with remote control
US5895371A (en) * 1996-08-27 1999-04-20 Sabratek Corporation Medical treatment apparatus and method
US5781703A (en) * 1996-09-06 1998-07-14 Candle Distributed Solutions, Inc. Intelligent remote agent for computer performance monitoring
US6164920A (en) * 1996-09-30 2000-12-26 Minnesota Mining And Manufacturing Company Perfusion system with control network
US6021392A (en) * 1996-12-09 2000-02-01 Pyxis Corporation System and method for drug management
US5950630A (en) * 1996-12-12 1999-09-14 Portwood; Michael T. System and method for improving compliance of a medical regimen
US6259654B1 (en) * 1997-03-28 2001-07-10 Telaric, L.L.C. Multi-vial medication organizer and dispenser
US7061831B2 (en) 1997-03-28 2006-06-13 Carlos De La Huerga Product labeling method and apparatus
US5960085A (en) * 1997-04-14 1999-09-28 De La Huerga; Carlos Security badge for automated access control and secure data gathering
US7941534B2 (en) * 1997-04-14 2011-05-10 Carlos De La Huerga System and method to authenticate users to computer systems
JPH1139769A (en) * 1997-07-17 1999-02-12 Internatl Business Mach Corp <Ibm> Information processor and power saving device
US5945651A (en) * 1997-07-17 1999-08-31 Chorosinski; Leonard Remotely programmable medication dispensing system
US6608638B1 (en) * 2000-02-07 2003-08-19 National Instruments Corporation System and method for configuring a programmable hardware instrument to perform measurement functions utilizing estimation of the hardware implentation and management of hardware resources
US6784903B2 (en) * 1997-08-18 2004-08-31 National Instruments Corporation System and method for configuring an instrument to perform measurement functions utilizing conversion of graphical programs into hardware implementations
US6219628B1 (en) * 1997-08-18 2001-04-17 National Instruments Corporation System and method for configuring an instrument to perform measurement functions utilizing conversion of graphical programs into hardware implementations
US6971066B2 (en) * 1997-08-18 2005-11-29 National Instruments Corporation System and method for deploying a graphical program on an image acquisition device
US6311149B1 (en) * 1997-08-18 2001-10-30 National Instruments Corporation Reconfigurable test system
US20020013538A1 (en) * 1997-09-30 2002-01-31 David Teller Method and apparatus for health signs monitoring
US6409674B1 (en) * 1998-09-24 2002-06-25 Data Sciences International, Inc. Implantable sensor with wireless communication
US7216802B1 (en) 1997-10-21 2007-05-15 Carlos De La Huerga Method and apparatus for verifying information
US7536309B1 (en) * 1997-11-12 2009-05-19 I-Flow Corporation Method and apparatus for monitoring a patient
US7487101B1 (en) * 1997-11-12 2009-02-03 I-Flow Corporation Method and apparatus for monitoring a patient
US7509280B1 (en) 1997-11-24 2009-03-24 Clinlcomp International, Inc. Enterprise healthcare management system and method of using same
US20040039606A1 (en) * 1997-12-01 2004-02-26 Andrew Loch Telemedicine system
US7152027B2 (en) * 1998-02-17 2006-12-19 National Instruments Corporation Reconfigurable test system
US7085670B2 (en) * 1998-02-17 2006-08-01 National Instruments Corporation Reconfigurable measurement system utilizing a programmable hardware element and fixed hardware resources
US6718547B2 (en) * 1998-02-17 2004-04-06 Fuji Photo Film Co., Ltd. Medical network system
US6200289B1 (en) * 1998-04-10 2001-03-13 Milestone Scientific, Inc. Pressure/force computer controlled drug delivery system and the like
US7449008B2 (en) 1998-04-10 2008-11-11 Milestone Scientific, Inc. Drug infusion device with tissue identification using pressure sensing
US7647237B2 (en) 1998-04-29 2010-01-12 Minimed, Inc. Communication station and software for interfacing with an infusion pump, analyte monitor, analyte meter, or the like
US7308894B2 (en) * 1998-06-03 2007-12-18 Scott Laboratories, Inc. Apparatuses and methods for providing a conscious patient relief from pain and anxiety associated with medical or surgical procedures according to appropriate clinical heuristics
EP1082056B1 (en) * 1998-06-03 2007-11-14 Scott Laboratories, Inc. Apparatus for providing a conscious patient relief from pain and anxiety associated with medical or surgical procedures
US20060093785A1 (en) * 1998-06-03 2006-05-04 Scott Laboratories, Inc. Apparatus, method and drug products for providing a conscious patient relief from pain and anxiety associated with medical or surgical procedures
US7565905B2 (en) * 1998-06-03 2009-07-28 Scott Laboratories, Inc. Apparatuses and methods for automatically assessing and monitoring a patient's responsiveness
US8521546B2 (en) 1998-09-25 2013-08-27 Health Hero Network Dynamic modeling and scoring risk assessment
US6578002B1 (en) * 1998-11-25 2003-06-10 Gregory John Derzay Medical diagnostic system service platform
US6434572B2 (en) * 1998-11-25 2002-08-13 Ge Medical Technology Services, Inc. Medical diagnostic system management method and apparatus
US6358202B1 (en) * 1999-01-25 2002-03-19 Sun Microsystems, Inc. Network for implanted computer devices
JP2000242322A (en) * 1999-02-24 2000-09-08 Toshiba Corp Plant operation training device
US6416471B1 (en) * 1999-04-15 2002-07-09 Nexan Limited Portable remote patient telemonitoring system
US7945451B2 (en) * 1999-04-16 2011-05-17 Cardiocom, Llc Remote monitoring system for ambulatory patients
US20080201168A1 (en) 1999-05-03 2008-08-21 Brown Stephen J Treatment regimen compliance and efficacy with feedback
US6312378B1 (en) * 1999-06-03 2001-11-06 Cardiac Intelligence Corporation System and method for automated collection and analysis of patient information retrieved from an implantable medical device for remote patient care
US6804558B2 (en) * 1999-07-07 2004-10-12 Medtronic, Inc. System and method of communicating between an implantable medical device and a remote computer system or health care provider
US7149773B2 (en) * 1999-07-07 2006-12-12 Medtronic, Inc. System and method of automated invoicing for communications between an implantable medical device and a remote computer system or health care provider
US6922729B1 (en) * 1999-07-30 2005-07-26 International Business Machines Corporation Multi-connection control system
US6264614B1 (en) * 1999-08-31 2001-07-24 Data Critical Corporation System and method for generating and transferring medical data
JP3608448B2 (en) * 1999-08-31 2005-01-12 株式会社日立製作所 Treatment device
US7023833B1 (en) * 1999-09-10 2006-04-04 Pulse-Link, Inc. Baseband wireless network for isochronous communication
US6464136B2 (en) * 1999-12-28 2002-10-15 Christopher S. Walsh Record and verification method, apparatus and system
US6637649B2 (en) 1999-12-28 2003-10-28 Christopher S. Walsh Record and verification method, apparatus and system
US6497358B1 (en) * 1999-09-13 2002-12-24 Christopher S. Walsh Record and verification method and system for radiation therapy
US7933780B2 (en) * 1999-10-22 2011-04-26 Telaric, Llc Method and apparatus for controlling an infusion pump or the like
US6442433B1 (en) * 1999-10-26 2002-08-27 Medtronic, Inc. Apparatus and method for remote troubleshooting, maintenance and upgrade of implantable device systems
US6648820B1 (en) * 1999-10-27 2003-11-18 Home-Medicine (Usa), Inc. Medical condition sensing system
DE10053118A1 (en) * 1999-10-29 2001-05-31 Medtronic Inc Remote self-identification apparatus and method for components in medical device systems
US6327501B1 (en) * 1999-11-02 2001-12-04 Pacesetter, Inc. System and method for determining safety alert conditions for implantable medical devices
US6976958B2 (en) * 2000-12-15 2005-12-20 Q-Tec Systems Llc Method and apparatus for health and disease management combining patient data monitoring with wireless internet connectivity
US6602191B2 (en) * 1999-12-17 2003-08-05 Q-Tec Systems Llp Method and apparatus for health and disease management combining patient data monitoring with wireless internet connectivity
US7156809B2 (en) * 1999-12-17 2007-01-02 Q-Tec Systems Llc Method and apparatus for health and disease management combining patient data monitoring with wireless internet connectivity
US7060031B2 (en) * 1999-12-17 2006-06-13 Medtronic, Inc. Method and apparatus for remotely programming implantable medical devices
US6497655B1 (en) * 1999-12-17 2002-12-24 Medtronic, Inc. Virtual remote monitor, alert, diagnostics and programming for implantable medical device systems
US6442432B2 (en) * 1999-12-21 2002-08-27 Medtronic, Inc. Instrumentation and software for remote monitoring and programming of implantable medical devices (IMDs)
DE29922736U1 (en) * 1999-12-24 2001-05-03 Braun Melsungen Ag Infusion device with several infusion pumps
US7369635B2 (en) 2000-01-21 2008-05-06 Medtronic Minimed, Inc. Rapid discrimination preambles and methods for using the same
US6733446B2 (en) * 2000-01-21 2004-05-11 Medtronic Minimed, Inc. Ambulatory medical apparatus and method using a telemetry system with predefined reception listening periods
US6408232B1 (en) * 2000-04-18 2002-06-18 Agere Systems Guardian Corp. Wireless piconet access to vehicle operational statistics
US6373389B1 (en) * 2000-04-21 2002-04-16 Usm Systems, Ltd. Event driven information system
US6440068B1 (en) * 2000-04-28 2002-08-27 International Business Machines Corporation Measuring user health as measured by multiple diverse health measurement devices utilizing a personal storage device
US6522925B1 (en) 2000-05-13 2003-02-18 Cardiac Pacemakers, Inc. System and method for detection enhancement programming
US20020116485A1 (en) * 2001-02-21 2002-08-22 Equipe Communications Corporation Out-of-band network management channels
US8302072B2 (en) * 2000-06-05 2012-10-30 National Instruments Corporation System and method for programmatically generating a graphical program based on a sequence of motion control, machine vision, and data acquisition (DAQ) operations
US7849416B2 (en) * 2000-06-13 2010-12-07 National Instruments Corporation System and method for graphically creating a sequence of motion control, machine vision, and data acquisition (DAQ) operations
US8640027B2 (en) * 2000-06-13 2014-01-28 National Instruments Corporation System and method for configuring a hardware device to execute a prototype
US6605038B1 (en) * 2000-06-16 2003-08-12 Bodymedia, Inc. System for monitoring health, wellness and fitness
US6757558B2 (en) * 2000-07-06 2004-06-29 Algodyne, Ltd. Objective pain measurement system and method
US7139844B2 (en) 2000-08-04 2006-11-21 Goldman Sachs & Co. Method and system for processing financial data objects carried on broadcast data streams and delivering information to subscribing clients
US7188159B2 (en) * 2000-08-09 2007-03-06 Infineon Technologies Ag Efficient software download to configurable communication device
US6917829B2 (en) * 2000-08-09 2005-07-12 Clinical Care Systems, Inc. Method and system for a distributed analytical and diagnostic software over the intranet and internet environment
LV12612B (en) * 2000-08-21 2001-03-20 Jehezkelis FINKELŠTEINS Method and device for collecting and processing of biomedical information
GB2366691B (en) * 2000-08-31 2002-11-06 F Secure Oyj Wireless device management
US20020032766A1 (en) * 2000-09-08 2002-03-14 Wei Xu Systems and methods for a packeting engine
US6978301B2 (en) * 2000-12-06 2005-12-20 Intelliden System and method for configuring a network device
US7200838B2 (en) * 2000-12-20 2007-04-03 National Instruments Corporation System and method for automatically generating a graphical program in response to a state diagram
SE0004843D0 (en) * 2000-12-22 2000-12-22 St Jude Medical Programming system for medical devices
EP1219243A1 (en) * 2000-12-28 2002-07-03 Matsushita Electric Works, Ltd. Non-invasive brain function examination
US20020151770A1 (en) * 2001-01-04 2002-10-17 Noll Austin F. Implantable medical device with sensor
US6551243B2 (en) * 2001-01-24 2003-04-22 Siemens Medical Solutions Health Services Corporation System and user interface for use in providing medical information and health care delivery support
EP1226784B1 (en) * 2001-01-25 2007-04-11 Matsushita Electric Industrial Co., Ltd. Vital signs detection system and health control method
JP2002230200A (en) * 2001-02-06 2002-08-16 Shimadzu Corp Analytical instrument maintenance system
US6839753B2 (en) 2001-02-23 2005-01-04 Cardiopulmonary Corporation Network monitoring systems for medical devices
US6950851B2 (en) * 2001-04-05 2005-09-27 Osburn Iii Douglas C System and method for communication for a supervisory control and data acquisition (SCADA) system
US6664893B1 (en) 2001-04-23 2003-12-16 Cardionet, Inc. Method for controlling access to medical monitoring device service
US6665385B2 (en) 2001-04-23 2003-12-16 Cardionet, Inc. Medical monitoring system having multipath communications capability
US20030040938A1 (en) * 2001-04-28 2003-02-27 Baxter International Inc. A system and method for managing inventory of blood component collection soft goods in a blood component collection facility
EP1256897A3 (en) * 2001-05-10 2009-12-09 Siemens Aktiengesellschaft Method for monitoring the course of a therapy for a patient in therapy
US7051088B2 (en) * 2001-05-14 2006-05-23 Hewlett-Packard Development Company, L.P. Systems and methods for providing off-line backup of a programmable device's configuration data to users of programmable devices at a service location
US20020173991A1 (en) * 2001-05-18 2002-11-21 Boaz Avitall Health care information management system and method
US7103578B2 (en) * 2001-05-25 2006-09-05 Roche Diagnostics Operations, Inc. Remote medical device access
CN1554061A (en) * 2001-06-20 2004-12-08 ͨ��ҽ�ƹ�˾ A method and system for integrated medical tracking
US6783492B2 (en) * 2001-06-26 2004-08-31 Steven Dominguez System and method for monitoring body functions
JP2003016212A (en) * 2001-07-04 2003-01-17 Hitachi Medical Corp Remote service system and program for medical equipment
US20030027118A1 (en) * 2001-07-27 2003-02-06 Klaus Abraham-Fuchs Analysis system for monitoring training during rehabilitation
DE10138710A1 (en) 2001-08-07 2003-02-20 Siemens Ag Extension of the OPC protocol
US20030130567A1 (en) * 2002-01-09 2003-07-10 Mault James R. Health-related devices and methods
US7050923B2 (en) * 2001-08-15 2006-05-23 National Instruments Corporation Network-based system for configuring a measurement system using configuration information generated based on a user specification
US7043393B2 (en) * 2001-08-15 2006-05-09 National Instruments Corporation System and method for online specification of measurement hardware
US6889172B2 (en) * 2001-08-15 2005-05-03 National Instruments Corporation Network-based system for configuring a measurement system using software programs generated based on a user specification
US7013232B2 (en) * 2001-08-15 2006-03-14 National Insurance Corporation Network-based system for configuring a measurement system using configuration information generated based on a user specification
US20030069752A1 (en) * 2001-08-24 2003-04-10 Ledain Timon Remote health-monitoring system and method
SE0102918D0 (en) * 2001-08-30 2001-08-30 St Jude Medical Method of providing software to an implantable medical device system
US6677854B2 (en) * 2001-10-05 2004-01-13 Case, Llc Remote vehicle diagnostic system
US7657444B2 (en) * 2001-10-16 2010-02-02 Qi Yu Distance-treatment through public network
US6588670B2 (en) * 2001-10-30 2003-07-08 Symbol Technologies, Inc. Medical diagnostic monitoring
US6763269B2 (en) * 2001-11-02 2004-07-13 Pacesetter, Inc. Frequency agile telemetry system for implantable medical device
US7430608B2 (en) 2001-12-04 2008-09-30 Siemens Medical Solutions Usa, Inc. System for processing data acquired from multiple medical devices
US6957102B2 (en) * 2001-12-10 2005-10-18 Medtronic Emergency Response Systems, Inc. Enhanced interface for a medical device and a terminal
US7577573B2 (en) * 2001-12-12 2009-08-18 General Electric Company Medical support system
US7051120B2 (en) 2001-12-28 2006-05-23 International Business Machines Corporation Healthcare personal area identification network method and system
US20030125662A1 (en) * 2002-01-03 2003-07-03 Tuan Bui Method and apparatus for providing medical treatment therapy based on calculated demand
KR100453503B1 (en) 2002-01-08 2004-10-20 주식회사 케이티프리텔 Remote medical treating method and system with local wireless interface
JP4585161B2 (en) * 2002-01-24 2010-11-24 株式会社東芝 Inspection reservation system
US20030140928A1 (en) * 2002-01-29 2003-07-31 Tuan Bui Medical treatment verification system and method
US7698156B2 (en) 2002-01-29 2010-04-13 Baxter International Inc. System and method for identifying data streams associated with medical equipment
US20030140929A1 (en) * 2002-01-29 2003-07-31 Wilkes Gordon J. Infusion therapy bar coding system and method
US7136916B2 (en) 2002-03-08 2006-11-14 Siemens Aktiengesellschaft Method for event management
WO2003077745A1 (en) * 2002-03-18 2003-09-25 Medic4All Ag Monitoring method and monitoring system for assessing physiological parameters of a subject
US7448996B2 (en) * 2002-04-16 2008-11-11 Carematix, Inc. Method and apparatus for remotely monitoring the condition of a patient
US6969369B2 (en) * 2002-04-22 2005-11-29 Medtronic, Inc. Implantable drug delivery system responsive to intra-cardiac pressure
US20040167465A1 (en) * 2002-04-30 2004-08-26 Mihai Dan M. System and method for medical device authentication
US20050055242A1 (en) * 2002-04-30 2005-03-10 Bryan Bello System and method for medical data tracking, analysis and reporting for healthcare system
US20040176667A1 (en) * 2002-04-30 2004-09-09 Mihai Dan M. Method and system for medical device connectivity
US6939111B2 (en) * 2002-05-24 2005-09-06 Baxter International Inc. Method and apparatus for controlling medical fluid pressure
US20050060202A1 (en) * 2002-05-31 2005-03-17 Richard Taylor System and method for coupling a plurality of medical devices in serverless grid
US20040024662A1 (en) * 2002-08-02 2004-02-05 David Gray Equipment documentation management system, method, and software tools
US7294105B1 (en) 2002-09-03 2007-11-13 Cheetah Omni, Llc System and method for a wireless medical communication system
US7818184B2 (en) 2002-09-24 2010-10-19 Draeger Medical Systems, Inc. Patient medical fluid parameter data processing system
US20040064342A1 (en) * 2002-09-30 2004-04-01 Browne David W. Health care protocols
EP1565102A4 (en) * 2002-10-15 2008-05-28 Medtronic Inc Synchronization and calibration of clocks for a medical device and calibrated clock
US7246159B2 (en) * 2002-11-01 2007-07-17 Fidelia Technology, Inc Distributed data gathering and storage for use in a fault and performance monitoring system
US20040088403A1 (en) 2002-11-01 2004-05-06 Vikas Aggarwal System configuration for use with a fault and performance monitoring system using distributed data gathering and storage
US20050038680A1 (en) * 2002-12-19 2005-02-17 Mcmahon Kevin Lee System and method for glucose monitoring
US20040122353A1 (en) 2002-12-19 2004-06-24 Medtronic Minimed, Inc. Relay device for transferring information between a sensor system and a fluid delivery system
JP2006510982A (en) 2002-12-19 2006-03-30 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ Method for managing metrics for use on diagnostic medical modalities, and apparatus and methods for performing medical investigations
JP4184247B2 (en) * 2003-01-24 2008-11-19 株式会社リコー Management device, remote management system, and program
US7423526B2 (en) 2003-01-29 2008-09-09 Despotis George J Integrated patient diagnostic and identification system
JP2004234158A (en) * 2003-01-29 2004-08-19 Sony Corp Information processor, contents management method, contents information management method and computer program
US20040172284A1 (en) 2003-02-13 2004-09-02 Roche Diagnostics Corporation Information management system
JP2004295568A (en) 2003-03-27 2004-10-21 Sony Corp Information processor, information processing method, and computer program
NZ542646A (en) 2003-03-28 2008-10-31 Cardinal Health 303 Inc Infusion data communication system
US20050038674A1 (en) * 2003-04-15 2005-02-17 Braig James R. System and method for managing a chronic medical condition
US7187979B2 (en) * 2003-04-25 2007-03-06 Medtronic, Inc. Medical device synchronization
JP4133579B2 (en) * 2003-05-20 2008-08-13 株式会社リコー Image processing device management system
US7607571B2 (en) * 2003-05-30 2009-10-27 Intellidot Corporation Medical work flow system
US20050038326A1 (en) * 2003-05-30 2005-02-17 Michael Mathur System, device, and method for remote monitoring and servicing
US7357308B2 (en) 2003-06-30 2008-04-15 At&T Bls Intellectual Property, Inc. System and method of automatically displaying patient information
US20050002483A1 (en) * 2003-07-03 2005-01-06 Wilcox John Richardson Apparatus and method for radiological image interpretation using different time zones
US7098788B2 (en) 2003-07-10 2006-08-29 University Of Florida Research Foundation, Inc. Remote surveillance and assisted care using a mobile communication device
US7860727B2 (en) 2003-07-17 2010-12-28 Ventana Medical Systems, Inc. Laboratory instrumentation information management and control network
US20070141711A1 (en) 2005-12-19 2007-06-21 Randy Stephens Automated lean methods in anatomical pathology
US7591801B2 (en) * 2004-02-26 2009-09-22 Dexcom, Inc. Integrated delivery device for continuous glucose sensor
US20050033369A1 (en) * 2003-08-08 2005-02-10 Badelt Steven W. Data Feedback loop for medical therapy adjustment
US20050108057A1 (en) 2003-09-24 2005-05-19 Michal Cohen Medical device management system including a clinical system interface
US8065161B2 (en) * 2003-11-13 2011-11-22 Hospira, Inc. System for maintaining drug information and communicating with medication delivery devices
US7490021B2 (en) 2003-10-07 2009-02-10 Hospira, Inc. Method for adjusting pump screen brightness
US20050102167A1 (en) * 2003-11-12 2005-05-12 Kapoor Ashok K. Provisioning and controlling medical instruments using wireless data communication
US7317941B2 (en) * 2003-11-13 2008-01-08 Medtronic, Inc. Time syncrhonization of data
US7010360B2 (en) * 2003-11-20 2006-03-07 International Business Machines Corporation Automatic conversion of dates and times for messaging
AU2004298025B9 (en) * 2003-12-05 2010-12-09 Carefusion 303, Inc. System and method for network monitoring of multiple medical devices
US20050124306A1 (en) * 2003-12-05 2005-06-09 Cheng Brett A. Method and apparatus for obtaining and maintaining accurate time
US20050131735A1 (en) * 2003-12-15 2005-06-16 Degeorge Michael P. Computerized system and method for identifying and storing time zone information in a healthcare environment
JP2005182344A (en) * 2003-12-18 2005-07-07 Fuji Photo Film Co Ltd In-hospital management device and program
KR20050065976A (en) * 2003-12-26 2005-06-30 한국전자통신연구원 Apparatus and method for computing sha-1 hash function
US7255683B2 (en) * 2003-12-31 2007-08-14 Cardinal Health 303, Inc. System for detecting the status of a vent associated with a fluid supply upstream of an infusion pump
US20050154612A1 (en) 2004-01-09 2005-07-14 Steris Inc. Communication server for an instrument management system
US8954336B2 (en) * 2004-02-23 2015-02-10 Smiths Medical Asd, Inc. Server for medical device
US20050187789A1 (en) 2004-02-25 2005-08-25 Cardiac Pacemakers, Inc. Advanced patient and medication therapy management system and method
US7634579B1 (en) * 2004-03-01 2009-12-15 American Megatrends, Inc. Method and system for interpreting and displaying time data received from a server management device
US20050207658A1 (en) 2004-03-05 2005-09-22 Nortel Networks Limited Method and apparatus for extracting information from a medical image
JP2007529928A (en) * 2004-03-19 2007-10-25 ノボ・ノルデイスク・エー/エス Reducing the format size of packet headers used for data transmission of medical devices
US7457869B2 (en) * 2004-04-06 2008-11-25 Sitewatch Technologies, Llc System and method for monitoring management
US7697994B2 (en) * 2004-06-18 2010-04-13 Medtronic, Inc. Remote scheduling for management of an implantable medical device
US7565197B2 (en) * 2004-06-18 2009-07-21 Medtronic, Inc. Conditional requirements for remote medical device programming
US8359338B2 (en) * 2004-07-30 2013-01-22 Carefusion 303, Inc. System and method for managing medical databases for patient care devices
US8398592B2 (en) * 2004-09-07 2013-03-19 Thomas Leibner-Druska Medication data transfer system and method for patient infusions
US8140594B2 (en) * 2004-09-17 2012-03-20 Sap Ag Advanced message mapping with sub-object key mapping
US7608042B2 (en) * 2004-09-29 2009-10-27 Intellidx, Inc. Blood monitoring system
US7167755B2 (en) * 2004-10-05 2007-01-23 Cardiac Pacemakers, Inc. Adaptive software configuration for a medical device
FI121213B (en) 2004-10-18 2010-08-31 Medixine Oy Method and system for monitoring health information
US20060089542A1 (en) 2004-10-25 2006-04-27 Safe And Sound Solutions, Inc. Mobile patient monitoring system with automatic data alerts
EP1815370A2 (en) * 2004-11-12 2007-08-08 Koninklijke Philips Electronics N.V. Message integrity for secure communication of wireless medical devices
EP1815372A1 (en) * 2004-11-16 2007-08-08 Koninklijke Philips Electronics N.V. Time synchronization in wireless ad hoc networks of medical devices and sensors
US20060116639A1 (en) 2004-11-29 2006-06-01 Russell Claudia J Total patient input monitoring
US20060173260A1 (en) * 2005-01-31 2006-08-03 Gmms Ltd System, device and method for diabetes treatment and monitoring
US7529543B2 (en) * 2005-01-31 2009-05-05 Fujitsu Limited Configuring a device using a configuration manager
JP4991574B2 (en) 2005-02-11 2012-08-01 ケアフュージョン 303、インコーポレイテッド Drug management identification system and method
EP1722310A1 (en) 2005-04-12 2006-11-15 Roche Diagnostics GmbH Medical software download to mobile phone
US8195658B2 (en) * 2005-04-28 2012-06-05 Samsung Electronics Co., Ltd. Method of storing phone book data in mobile communication terminal and a mobile communication terminal implementing the same
US7389409B2 (en) * 2005-04-29 2008-06-17 Alcatel Lucent Electronic device configuration management systems and methods
US20060253300A1 (en) * 2005-05-03 2006-11-09 Somberg Benjamin L System and method for managing patient triage in an automated patient management system
US20070244997A1 (en) 2005-08-31 2007-10-18 Tindal Glen D System and method for configuring a network device
US20070078497A1 (en) * 2005-10-03 2007-04-05 Vandanacker John P Remote programming of implantable medical devices
US20070094657A1 (en) * 2005-10-25 2007-04-26 Cyberonics, Inc. Method and apparatus for installing an application into a device
WO2007060558A2 (en) 2005-11-23 2007-05-31 Koninklijke Philips Electronics N.V. Method and apparatus for remote patient monitoring
US7571208B2 (en) * 2005-11-30 2009-08-04 Microsoft Corporation Creating proxies from service description metadata at runtime
US20070136098A1 (en) * 2005-12-12 2007-06-14 Smythe Alan H System and method for providing a secure feature set distribution infrastructure for medical device management
US7451002B2 (en) * 2006-01-06 2008-11-11 Ge Medical Systems Global Technology Company, Llc Automated generation of transfer functions based upon machine data
WO2007126948A2 (en) * 2006-03-28 2007-11-08 Hospira, Inc. Medication administration and management system and method
WO2007138154A1 (en) * 2006-05-29 2007-12-06 Wristop Technologies Oy Apparatus and method for dosing drug and wireless remote control of a drug pump
AU2007307684A1 (en) * 2006-10-11 2008-04-17 Quartex, Division Of Primex, Inc. Traceable record generation system and method using wireless networks
US8126730B2 (en) * 2006-10-24 2012-02-28 Medapps, Inc. Systems and methods for storage and forwarding of medical data
WO2008140554A2 (en) * 2006-10-24 2008-11-20 Medapps, Inc. Systems and methods for adapter-based communication with a medical device
US8126733B2 (en) * 2006-10-24 2012-02-28 Medapps, Inc. Systems and methods for medical data interchange using mobile computing devices
US20080097917A1 (en) * 2006-10-24 2008-04-24 Kent Dicks Systems and methods for wireless processing and medical device monitoring via remote command execution
US20080167900A1 (en) 2006-12-29 2008-07-10 Medrad, Inc. Biometric characterization of agents and patient safety in biological injection or administration
US20080178150A1 (en) * 2007-01-19 2008-07-24 Microsoft Corporation Complex time zone techniques
US20080175275A1 (en) * 2007-01-22 2008-07-24 Samsung Electronics Co., Ltd. Time synchronization method between nodes in network and apparatus for implementing the same
US20080220403A1 (en) * 2007-02-16 2008-09-11 Ohio University System and method for managing diabetes
US20100042043A1 (en) * 2007-03-27 2010-02-18 Koninklijke Philips Electronics N.V. Automatic drug administration with reduced power consumption
US8425469B2 (en) 2007-04-23 2013-04-23 Jacobson Technologies, Llc Systems and methods for controlled substance delivery network
US20080269673A1 (en) * 2007-04-27 2008-10-30 Animas Corporation Cellular-Enabled Medical Monitoring and Infusion System
EP2152350A4 (en) * 2007-06-08 2013-03-27 Dexcom Inc Integrated medicament delivery device for use with continuous analyte sensor
US8932250B2 (en) 2007-06-15 2015-01-13 Animas Corporation Systems and methods to pair a medical device and a remote controller for such medical device
US8444595B2 (en) 2007-06-15 2013-05-21 Animas Corporation Methods to pair a medical device and at least a remote controller for such medical device
US7997474B2 (en) 2007-06-21 2011-08-16 General Electric Company System and method for configuring a medical device
US8613044B2 (en) 2007-06-22 2013-12-17 4Dk Technologies, Inc. Delegating or transferring of access to resources between multiple devices
US20090005729A1 (en) * 2007-06-27 2009-01-01 Animas Corporation Medical infusion pumps
US7948833B2 (en) * 2007-07-25 2011-05-24 Computime, Ltd. Clock setup over a network
US20090157202A1 (en) 2007-08-10 2009-06-18 Smiths Medical Md Therapy rules for closed loop programming of medical devices
US7717903B2 (en) * 2007-09-06 2010-05-18 M2 Group Holdings, Inc. Operating an infusion pump system
US8517990B2 (en) * 2007-12-18 2013-08-27 Hospira, Inc. User interface improvements for medical devices
US7942817B2 (en) * 2008-01-04 2011-05-17 Siemens Medical Solutions Usa, Inc. Patient monitoring and treatment medical signal interface system
US8660856B2 (en) * 2008-01-31 2014-02-25 Medicity, Inc. Healthcare service management using a centralized service management module
US8285386B2 (en) 2008-02-19 2012-10-09 Codman Neuro Sciences Sárl Implant revision recognition by exchanging the revision data during transmission
US20090246171A1 (en) * 2008-03-27 2009-10-01 Van Antwerp William P Automatic system for dose control in treating hepatitis c using infusion pumps
US20090243833A1 (en) 2008-03-31 2009-10-01 Ching Ching Huang Monitoring system and method for patient care
US20090259217A1 (en) * 2008-04-09 2009-10-15 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Methods and systems associated with delivery of one or more agents to an individual
US20090259112A1 (en) * 2008-04-09 2009-10-15 Searete Llc, A Limited Liability Corporation Of The State Of Delaware Sensors
US20090265316A1 (en) 2008-04-21 2009-10-22 John Poulin System And Method For Facilitating Access To De-Identified Electronic Medical Records Data
KR101748544B1 (en) 2008-05-27 2017-06-16 스트리커 코포레이션 Wireless medical room control arrangement for control of a plurality of medical devices
CN102089763A (en) * 2008-07-10 2011-06-08 伊西康内外科公司 Medical system which controls delivery of a drug and which includes a backpack pouch
DE102008040502A1 (en) * 2008-07-17 2010-01-21 Biotronik Crm Patent Ag Medical implant with at least two data communication channels
US9095274B2 (en) * 2008-08-31 2015-08-04 Empire Technology Development Llc Real time medical data analysis system
US8172798B2 (en) * 2009-05-12 2012-05-08 Sigma International General Medical Apparatus LLC System and method for managing infusion therapies
US8874383B2 (en) * 2009-09-03 2014-10-28 Schlumberger Technology Corporation Pump assembly

Patent Citations (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6259355B1 (en) * 1990-07-27 2001-07-10 Elot, Inc. Patient care and communication system
US5689229A (en) * 1990-07-27 1997-11-18 Executone Information Systems Inc. Patient care and communication system
US5594786A (en) * 1990-07-27 1997-01-14 Executone Information Systems, Inc. Patient care and communication system
US5522396A (en) * 1992-05-12 1996-06-04 Cardiac Telecom Corporation Method and system for monitoring the heart of a patient
US20030069753A1 (en) * 1992-11-17 2003-04-10 Brown Stephen J. Multi-user remote health monitoring system with biometrics support
US6168563B1 (en) * 1992-11-17 2001-01-02 Health Hero Network, Inc. Remote health monitoring and maintenance system
US20040019259A1 (en) * 1992-11-17 2004-01-29 Brown Stephen J. Remote monitoring and data management platform
US20040199409A1 (en) * 1992-11-17 2004-10-07 Brown Stephen J. Remote health monitoring and maintenance system
US5458123A (en) * 1992-12-16 1995-10-17 Siemens Medical Systems, Inc. System for monitoring patient location and data
US5542420A (en) * 1993-04-30 1996-08-06 Goldman; Arnold J. Personalized method and system for storage, communication, analysis, and processing of health-related data
US5455851A (en) * 1993-07-02 1995-10-03 Executone Information Systems, Inc. System for identifying object locations
US5658250A (en) * 1993-07-13 1997-08-19 Sims Deltec, Inc. Systems and methods for operating ambulatory medical devices such as drug delivery devices
US5434775A (en) * 1993-11-04 1995-07-18 The General Hospital Corporation Managing an inventory of devices
US6334778B1 (en) * 1994-04-26 2002-01-01 Health Hero Network, Inc. Remote psychological diagnosis and monitoring system
US5732709A (en) * 1994-05-23 1998-03-31 Enact Health Management Systems System for monitoring and reporting medical measurements
US5549117A (en) * 1994-05-23 1996-08-27 Enact Health Management Systems System for monitoring and reporting medical measurements
US5626144A (en) * 1994-05-23 1997-05-06 Enact Health Management Systems System for monitoring and reporting medical measurements
US5704366A (en) * 1994-05-23 1998-01-06 Enact Health Management Systems System for monitoring and reporting medical measurements
US6352200B1 (en) * 1994-06-09 2002-03-05 Consumer Health Entrepreneurs B.V. Medicament distribution system and automatic dispenser for such system
US5582593A (en) * 1994-07-21 1996-12-10 Hultman; Barry W. Ambulatory medication delivery system
US5713856A (en) * 1995-03-13 1998-02-03 Alaris Medical Systems, Inc. Modular patient care system
US6714969B1 (en) * 1995-11-17 2004-03-30 Symbol Technologies, Inc. Mobile terminal with integrated host application software
US5788669A (en) * 1995-11-22 1998-08-04 Sims Deltec, Inc. Pump tracking system
US5842976A (en) * 1996-05-16 1998-12-01 Pyxis Corporation Dispensing, storage, control and inventory system with medication and treatment chart record
US5687717A (en) * 1996-08-06 1997-11-18 Tremont Medical, Inc. Patient monitoring system with chassis mounted or remotely operable modules and portable computer
US6246992B1 (en) * 1996-10-16 2001-06-12 Health Hero Network, Inc. Multiple patient monitoring system for proactive health management
US5832448A (en) * 1996-10-16 1998-11-03 Health Hero Network Multiple patient monitoring system for proactive health management
US6364834B1 (en) * 1996-11-13 2002-04-02 Criticare Systems, Inc. Method and system for remotely monitoring multiple medical parameters in an integrated medical monitoring system
US6820057B1 (en) * 1996-11-29 2004-11-16 Ventracor Limited Telemedicine system
US20030036687A1 (en) * 1996-12-30 2003-02-20 Ido Schoenberg Medical order information display system
US20020177758A1 (en) * 1996-12-30 2002-11-28 Ido Schoenberg Patient treatment and progress monitor display
US6558321B1 (en) * 1997-03-04 2003-05-06 Dexcom, Inc. Systems and methods for remote monitoring and modulation of medical devices
US6699187B2 (en) * 1997-03-27 2004-03-02 Medtronic, Inc. System and method for providing remote expert communications and video capabilities for use during a medical procedure
US6368273B1 (en) * 1997-03-28 2002-04-09 Health Hero Network, Inc. Networked system for interactive communication and remote monitoring of individuals
US5897493A (en) * 1997-03-28 1999-04-27 Health Hero Network, Inc. Monitoring system for remotely querying individuals
US6381577B1 (en) * 1997-03-28 2002-04-30 Health Hero Network, Inc. Multi-user remote health monitoring system
US6032155A (en) * 1997-04-14 2000-02-29 De La Huerga; Carlos System and apparatus for administering prescribed medication to a patient
US6101478A (en) * 1997-04-30 2000-08-08 Health Hero Network Multi-user remote health monitoring system
US5907291A (en) * 1997-06-05 1999-05-25 Vsm Technology Inc. Multi-patient monitoring apparatus and method
US6400987B1 (en) * 1997-08-13 2002-06-04 Sorin Biomedica Cardio S.P.A. Active implantable device
US6409662B1 (en) * 1997-10-28 2002-06-25 Alere Medical, Inc. Patient interface system
US6144922A (en) * 1997-10-31 2000-11-07 Mercury Diagnostics, Incorporated Analyte concentration information collection and communication system
US20030163351A1 (en) * 1997-11-21 2003-08-28 Brown Stephen J. Public health surveillance system
US6827713B2 (en) * 1998-02-19 2004-12-07 Curon Medical, Inc. Systems and methods for monitoring and controlling use of medical devices
US20030195399A1 (en) * 1998-03-27 2003-10-16 Mci Communications Corporation Personal medical monitoring unit and system
US6579231B1 (en) * 1998-03-27 2003-06-17 Mci Communications Corporation Personal medical monitoring unit and system
US20030216625A1 (en) * 1998-03-27 2003-11-20 Mci Communications Corporation Personal medical monitoring unit and system
US6283923B1 (en) * 1998-05-28 2001-09-04 The Trustees Of Columbia University In The City Of New York System and method for remotely monitoring asthma severity
US6485415B1 (en) * 1998-09-25 2002-11-26 Pioneer Corporation Medical monitoring system
US6074345A (en) * 1998-10-27 2000-06-13 University Of Florida Patient data acquisition and control system
US6598011B1 (en) * 1998-11-25 2003-07-22 Ianne Mae Howards Koritzinsky Medical diagnostic system services interface
US6196970B1 (en) * 1999-03-22 2001-03-06 Stephen J. Brown Research data collection and analysis
US6575900B1 (en) * 1999-03-29 2003-06-10 Beckman Coulter, Inc. Meter with integrated database and simplified telemedicine capability
US6723045B2 (en) * 1999-04-16 2004-04-20 Cardiocam Apparatus and method for monitoring and communicating wellness parameters of ambulatory patients
US20040225533A1 (en) * 1999-04-16 2004-11-11 Cosentino Daniel L. Weight loss or weight management system
US6290646B1 (en) * 1999-04-16 2001-09-18 Cardiocom Apparatus and method for monitoring and communicating wellness parameters of ambulatory patients
US6270457B1 (en) * 1999-06-03 2001-08-07 Cardiac Intelligence Corp. System and method for automated collection and analysis of regularly retrieved patient information for remote patient care
US6804656B1 (en) * 1999-06-23 2004-10-12 Visicu, Inc. System and method for providing continuous, expert network critical care services from a remote location(s)
US6221011B1 (en) * 1999-07-26 2001-04-24 Cardiac Intelligence Corporation System and method for determining a reference baseline of individual patient status for use in an automated collection and analysis patient care system
US6618745B2 (en) * 1999-09-10 2003-09-09 Fisher Rosemount Systems, Inc. Linking device in a process control system that allows the formation of a control loop having function blocks in a controller and in field devices
US6640246B1 (en) * 1999-09-17 2003-10-28 Ge Medical Systems Global Technology Company, Llc Integrated computerized materials management system
US6454705B1 (en) * 1999-09-21 2002-09-24 Cardiocom Medical wellness parameters management system, apparatus and method
US6402691B1 (en) * 1999-09-21 2002-06-11 Herschel Q. Peddicord In-home patient monitoring system
US6350237B1 (en) * 1999-11-05 2002-02-26 General Electric Company Method and apparatus for monitoring fetal status data
US20020028989A1 (en) * 1999-11-05 2002-03-07 Pelletier Andrew Michael Method and apparatus for monitoring fetal status data
US6612984B1 (en) * 1999-12-03 2003-09-02 Kerr, Ii Robert A. System and method for collecting and transmitting medical data
US6824052B2 (en) * 1999-12-28 2004-11-30 Christopher S. Walsh Healthcare verification methods, apparatus and systems
US6656115B1 (en) * 2000-03-31 2003-12-02 Matsushita Electric Industrial Co., Ltd. Medical information system
US6574511B2 (en) * 2000-04-21 2003-06-03 Medtronic, Inc. Passive data collection system from a fleet of medical instruments and implantable devices
US6522916B1 (en) * 2000-05-09 2003-02-18 Ki Chul Kwon Telemetric system for fetal care
US20020049684A1 (en) * 2000-05-31 2002-04-25 Shunichi Nagamoto Medical checkup network system
US6669631B2 (en) * 2000-06-14 2003-12-30 Medtronic, Inc. Deep computing applications in medical device systems
US20020016719A1 (en) * 2000-06-19 2002-02-07 Nemeth Louis G. Methods and systems for providing medical data to a third party in accordance with configurable distribution parameters
US20020072933A1 (en) * 2000-06-30 2002-06-13 Vonk Glenn Philander Health outcomes and disease management network and related method for providing improved patient care
US20030014283A1 (en) * 2000-07-14 2003-01-16 Kenji Iwano Medical information system patient-use terminal device, medium
US6633772B2 (en) * 2000-08-18 2003-10-14 Cygnus, Inc. Formulation and manipulation of databases of analyte and associated values
US20030200114A1 (en) * 2000-10-19 2003-10-23 Nihon Kohden Corporation Medical care support system
US20020147390A1 (en) * 2000-12-20 2002-10-10 Markis John Emmanuel M.D. Methods and apparatus for acquiring and using bedside medical data
US20020087362A1 (en) * 2001-01-02 2002-07-04 Cobb David M. Systems and methods for tracking administration of medical products
US20020156650A1 (en) * 2001-02-17 2002-10-24 Klein Michael V. Secure distribution of digital healthcare data using an offsite internet file server
US6758812B2 (en) * 2001-02-23 2004-07-06 Brook W. Lang Emergency medical treatment system
US20020128864A1 (en) * 2001-03-06 2002-09-12 Maus Christopher T. Computerized information processing and retrieval system
US20020133377A1 (en) * 2001-03-14 2002-09-19 Brown Stephen J. Interactive patient communication development system for reporting on patient healthcare management
US6694177B2 (en) * 2001-04-23 2004-02-17 Cardionet, Inc. Control of data transmission between a remote monitoring unit and a central unit
US20020169638A1 (en) * 2001-05-09 2002-11-14 Domingo Rodriguez-Cue System and method for providing wireless, paperless medical care and communication
US20030004751A1 (en) * 2001-05-24 2003-01-02 Kok-Hwee Ng System and method for tracking a blood collection kit in a blood collection facility
US6544198B2 (en) * 2001-06-11 2003-04-08 Hoseo University Stethoscope system for self-examination using internet
US6747556B2 (en) * 2001-07-31 2004-06-08 Medtronic Physio-Control Corp. Method and system for locating a portable medical device
US20030065536A1 (en) * 2001-08-13 2003-04-03 Hansen Henrik Egesborg Portable device and method of communicating medical data information
US20030078812A1 (en) * 2001-08-30 2003-04-24 Olympus Optical Co., Ltd. Medical information system for improving efficiency of clinical record creating operations
US20030093301A1 (en) * 2001-11-13 2003-05-15 Hypertension Diagnostics, Inc. Centralized clinical data management system process for analysis and billing
US20030098022A1 (en) * 2001-11-27 2003-05-29 Omron Corporation Nebulizer optimal for patient at home care
US20030107487A1 (en) * 2001-12-10 2003-06-12 Ronen Korman Method and device for measuring physiological parameters at the wrist
US20030204563A1 (en) * 2002-03-19 2003-10-30 Colin Corporation Diagnosis delivering method
US20030204419A1 (en) * 2002-04-30 2003-10-30 Wilkes Gordon J. Automated messaging center system and method for use with a healthcare system
US20030212579A1 (en) * 2002-05-08 2003-11-13 Brown Stephen J. Remote health management system
US20030216624A1 (en) * 2002-05-16 2003-11-20 Microlife Intellectual Property Gmbh System for monitoring medical data, a terminal device for measuring and storing medical data, a medicine container and a holder for medical containers
US20040249673A1 (en) * 2003-04-18 2004-12-09 Smith Baird M. Integrated point-of-care systems and methods
US20040236606A1 (en) * 2003-05-20 2004-11-25 Olympus Corporation Medical tool management and support system

Cited By (108)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10434246B2 (en) 2003-10-07 2019-10-08 Icu Medical, Inc. Medication management system
US11235100B2 (en) 2003-11-13 2022-02-01 Icu Medical, Inc. System for maintaining drug information and communicating with medication delivery devices
US10242060B2 (en) 2006-10-16 2019-03-26 Icu Medical, Inc. System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems
US11194810B2 (en) 2006-10-16 2021-12-07 Icu Medical, Inc. System and method for comparing and utilizing activity information and configuration information from multiple device management systems
US8734428B2 (en) 2006-10-17 2014-05-27 Tandem Diabetes Care, Inc. Insulin pump having selectable insulin absorption models
US11217339B2 (en) 2006-10-17 2022-01-04 Tandem Diabetes Care, Inc. Food database for insulin pump
US20100229153A1 (en) * 2009-03-05 2010-09-09 Detlef Becker Providing a number of web services for imaging optional medical applications
US8380809B2 (en) * 2009-03-05 2013-02-19 Siemens Aktiengesellschaft Providing a number of web services for imaging optional medical applications
US10546101B2 (en) 2009-04-14 2020-01-28 Baxter International Inc. Therapy management development platform
US9089643B2 (en) 2009-04-14 2015-07-28 Baxter International Inc. Therapy management development platform
US11654237B2 (en) 2009-04-17 2023-05-23 Icu Medical, Inc. System and method for configuring a rule set for medical event management and responses
US10238801B2 (en) 2009-04-17 2019-03-26 Icu Medical, Inc. System and method for configuring a rule set for medical event management and responses
US11013861B2 (en) 2009-04-17 2021-05-25 Icu Medical, Inc. System and method for configuring a rule set for medical event management and responses
US8984069B2 (en) * 2009-07-29 2015-03-17 Siemens Aktiengesellschaft Taskflow unit for controlling computer-aided medical tasks within a medical computer network
US20110029623A1 (en) * 2009-07-29 2011-02-03 Siemens Aktiengesellschaft Taskflow unit for controlling computer-aided medical tasks within a medical computer network
US8287495B2 (en) 2009-07-30 2012-10-16 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US11285263B2 (en) 2009-07-30 2022-03-29 Tandem Diabetes Care, Inc. Infusion pump systems and methods
US8926561B2 (en) 2009-07-30 2015-01-06 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US9211377B2 (en) 2009-07-30 2015-12-15 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US8758323B2 (en) 2009-07-30 2014-06-24 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US11135362B2 (en) 2009-07-30 2021-10-05 Tandem Diabetes Care, Inc. Infusion pump systems and methods
US8298184B2 (en) 2009-07-30 2012-10-30 Tandem Diabetes Care, Inc. Infusion pump system with disposable cartridge having pressure venting and pressure feedback
US20160283682A1 (en) * 2009-09-30 2016-09-29 Covidien Lp Protocol analyzer system and method for medical monitoring module
US8229224B2 (en) * 2009-12-18 2012-07-24 David Van Hardware management based on image recognition
US20110150336A1 (en) * 2009-12-18 2011-06-23 David Van Hardware Management Based on Image Recognition
US20130030830A1 (en) * 2010-02-26 2013-01-31 Horst Schmoll System and method for controlling a data transmission to and/or from a plurality of medical devices
US10026504B2 (en) * 2010-02-26 2018-07-17 B. Braun Melsungen Ag System and method for controlling a data transmission to and/or from a plurality of medical devices
EP2612255A4 (en) * 2010-08-31 2015-05-27 Lantronix Inc Medical device connectivity to hospital information systems using device server
WO2012031020A1 (en) * 2010-08-31 2012-03-08 Lantronix, Inc. Medical device connectivity to hospital information systems using device server
US20130160082A1 (en) * 2010-08-31 2013-06-20 Lantronix, Inc. Medical Device Connectivity to Hospital Information Systems Using Device Server
US10095208B2 (en) * 2010-12-01 2018-10-09 Codewrights Gmbh Method for implementing at least one additional function of a field device in automation technology
US20120143586A1 (en) * 2010-12-01 2012-06-07 Codewrights Gmbh Method for implementing at least one additional function of a field device in automation technology
US20120163663A1 (en) * 2010-12-27 2012-06-28 Medtronic, Inc. Security use restrictions for a medical communication module and host device
US11626205B2 (en) 2011-10-21 2023-04-11 Icu Medical, Inc. Medical device update system
US9971871B2 (en) 2011-10-21 2018-05-15 Icu Medical, Inc. Medical device update system
US9594875B2 (en) 2011-10-21 2017-03-14 Hospira, Inc. Medical device update system
US10258736B2 (en) 2012-05-17 2019-04-16 Tandem Diabetes Care, Inc. Systems including vial adapter for fluid transfer
US10682460B2 (en) 2013-01-28 2020-06-16 Smiths Medical Asd, Inc. Medication safety devices and methods
US10881784B2 (en) 2013-01-28 2021-01-05 Smiths Medical Asd, Inc. Medication safety devices and methods
US10333843B2 (en) 2013-03-06 2019-06-25 Icu Medical, Inc. Medical device communication method
US11470000B2 (en) 2013-03-06 2022-10-11 Icu Medical, Inc. Medical device communication method
US11607492B2 (en) 2013-03-13 2023-03-21 Tandem Diabetes Care, Inc. System and method for integration and display of data of insulin pumps and continuous glucose monitoring
US9962486B2 (en) 2013-03-14 2018-05-08 Tandem Diabetes Care, Inc. System and method for detecting occlusions in an infusion pump
US11776689B2 (en) 2013-03-15 2023-10-03 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US20180169330A1 (en) * 2013-03-15 2018-06-21 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US10456524B2 (en) * 2013-03-15 2019-10-29 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US20220157446A1 (en) * 2013-03-15 2022-05-19 Carefusion 303, Inc. Application licensing for a centralized system of medical devices
US11152115B2 (en) 2013-03-15 2021-10-19 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US11887726B2 (en) * 2013-03-15 2024-01-30 Carefusion 303, Inc. Application licensing for a centralized system of medical devices
US11049614B2 (en) 2013-03-15 2021-06-29 Tandem Diabetes Care, Inc. Field update of an ambulatory infusion pump system
US11571508B2 (en) 2013-08-30 2023-02-07 Icu Medical, Inc. System and method of monitoring and managing a remote infusion regimen
US10765799B2 (en) 2013-09-20 2020-09-08 Icu Medical, Inc. Fail-safe drug infusion therapy system
US11501877B2 (en) 2013-11-11 2022-11-15 Icu Medical, Inc. Medical device system performance index
US10311972B2 (en) 2013-11-11 2019-06-04 Icu Medical, Inc. Medical device system performance index
US10042986B2 (en) 2013-11-19 2018-08-07 Icu Medical, Inc. Infusion pump automation system and method
US11037668B2 (en) 2013-11-19 2021-06-15 Icu Medical, Inc. Infusion pump automation system and method
US11763927B2 (en) 2013-11-19 2023-09-19 Icu Medical, Inc. Infusion pump automation system and method
US11911590B2 (en) 2013-12-26 2024-02-27 Tandem Diabetes Care, Inc. Integration of infusion pump with remote electronic device
US10918785B2 (en) 2013-12-26 2021-02-16 Tandem Diabetes Care, Inc. Integration of infusion pump with remote electronic device
US11330058B2 (en) * 2014-01-13 2022-05-10 Carefusion 303, Inc. Remote flashing during infusion
US10666733B2 (en) * 2014-01-13 2020-05-26 Carefusion 303, Inc. Remote flashing during infusion
US10898641B2 (en) 2014-04-30 2021-01-26 Icu Medical, Inc. Patient care system with conditional alarm forwarding
US11628246B2 (en) 2014-04-30 2023-04-18 Icu Medical, Inc. Patient care system with conditional alarm forwarding
US10314974B2 (en) 2014-06-16 2019-06-11 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US11628254B2 (en) 2014-06-16 2023-04-18 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US10646651B2 (en) 2014-06-16 2020-05-12 Icu Medical, Inc. System for monitoring and delivering medication to a patient and method of using the same to minimize the risks associated with automated therapy
US11289183B2 (en) 2014-09-15 2022-03-29 Icu Medical, Inc. Matching delayed infusion auto-programs with manually entered infusion programs
US10799632B2 (en) 2014-09-15 2020-10-13 Icu Medical, Inc. Matching delayed infusion auto-programs with manually entered infusion programs
US10238799B2 (en) 2014-09-15 2019-03-26 Icu Medical, Inc. Matching delayed infusion auto-programs with manually entered infusion programs
US11574721B2 (en) 2014-09-15 2023-02-07 Icu Medical, Inc. Matching delayed infusion auto-programs with manually entered infusion programs
WO2016097514A1 (en) * 2014-12-18 2016-06-23 Bull Sas Systems for distributed management of medical equipment
FR3030801A1 (en) * 2014-12-18 2016-06-24 Bull Sas SYSTEMS FOR DISTRIBUTED MANAGEMENT OF MEDICAL EQUIPMENT
WO2016099551A1 (en) * 2014-12-19 2016-06-23 Draeger Medical Systems, Inc. Medical device location-based association to a patient
US11924282B2 (en) 2015-03-30 2024-03-05 Zoll Medical Corporation Medical device management
US11595478B2 (en) * 2015-03-30 2023-02-28 Zoll Medical Corporation Medical device management
US20190349435A1 (en) * 2015-03-30 2019-11-14 Zoll Medical Corporation Medical Device Management
US11605468B2 (en) 2015-05-26 2023-03-14 Icu Medical, Inc. Infusion pump system and method with multiple drug library editor source capability
US20180286510A1 (en) * 2015-09-21 2018-10-04 Wenjie Robin Liang Maintenance systems and methods for medical devices
US20170132374A1 (en) * 2015-11-11 2017-05-11 Zyno Medical, Llc System for Collecting Medical Data Using Proxy Inputs
US10541987B2 (en) 2016-02-26 2020-01-21 Tandem Diabetes Care, Inc. Web browser-based device communication workflow
US11470069B2 (en) 2016-02-26 2022-10-11 Tandem Diabetes Care, Inc. Web browser-based device communication workflow
US11574737B2 (en) 2016-07-14 2023-02-07 Icu Medical, Inc. Multi-communication path selection and security system for a medical device
US11659995B2 (en) 2017-02-24 2023-05-30 Collaborative Care Diagnostics, Llc. Secure communications and records handling system and associated method
US11129533B2 (en) 2017-02-24 2021-09-28 Collaborative Care Diagnostics, LLC Secure communications and records handling system and associated method
US11925373B2 (en) 2017-10-30 2024-03-12 Cilag Gmbh International Surgical suturing instrument comprising a non-circular needle
US20210212694A1 (en) * 2017-12-28 2021-07-15 Ethicon Llc Method for facility data collection and interpretation
US11783935B2 (en) 2018-07-17 2023-10-10 Icu Medical, Inc. Health checks for infusion pump communications systems
US11373753B2 (en) 2018-07-17 2022-06-28 Icu Medical, Inc. Converting pump messages in new pump protocol to standardized dataset messages
US11587669B2 (en) 2018-07-17 2023-02-21 Icu Medical, Inc. Passing authentication token to authorize access to rest calls via web sockets
US11594326B2 (en) 2018-07-17 2023-02-28 Icu Medical, Inc. Detecting missing messages from clinical environment
US10741280B2 (en) 2018-07-17 2020-08-11 Icu Medical, Inc. Tagging pump messages with identifiers that facilitate restructuring
US11328804B2 (en) 2018-07-17 2022-05-10 Icu Medical, Inc. Health checks for infusion pump communications systems
US11328805B2 (en) 2018-07-17 2022-05-10 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US11923076B2 (en) 2018-07-17 2024-03-05 Icu Medical, Inc. Converting pump messages in new pump protocol to standardized dataset messages
US10861592B2 (en) 2018-07-17 2020-12-08 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US10950339B2 (en) 2018-07-17 2021-03-16 Icu Medical, Inc. Converting pump messages in new pump protocol to standardized dataset messages
US10964428B2 (en) 2018-07-17 2021-03-30 Icu Medical, Inc. Merging messages into cache and generating user interface using the cache
US11483402B2 (en) 2018-07-17 2022-10-25 Icu Medical, Inc. Maintaining clinical messaging during an internet outage
US11670416B2 (en) 2018-07-17 2023-06-06 Icu Medical, Inc. Tagging pump messages with identifiers that facilitate restructuring
US11152110B2 (en) 2018-07-17 2021-10-19 Icu Medical, Inc. Tagging pump messages with identifiers that facilitate restructuring
US11152108B2 (en) 2018-07-17 2021-10-19 Icu Medical, Inc. Passing authentication token to authorize access to rest calls via web sockets
US11139058B2 (en) 2018-07-17 2021-10-05 Icu Medical, Inc. Reducing file transfer between cloud environment and infusion pumps
US11881297B2 (en) 2018-07-17 2024-01-23 Icu Medical, Inc. Reducing infusion pump network congestion by staggering updates
US11483403B2 (en) 2018-07-17 2022-10-25 Icu Medical, Inc. Maintaining clinical messaging during network instability
US11152109B2 (en) 2018-07-17 2021-10-19 Icu Medical, Inc. Detecting missing messages from clinical environment
US10692595B2 (en) 2018-07-26 2020-06-23 Icu Medical, Inc. Drug library dynamic version management
US11309070B2 (en) 2018-07-26 2022-04-19 Icu Medical, Inc. Drug library manager with customized worksheets
US11437132B2 (en) 2018-07-26 2022-09-06 Icu Medical, Inc. Drug library dynamic version management

Also Published As

Publication number Publication date
WO2009023634A2 (en) 2009-02-19
JP2014006915A (en) 2014-01-16
US20090158274A1 (en) 2009-06-18
EP3540741B1 (en) 2022-10-26
JP2010536111A (en) 2010-11-25
US9483615B2 (en) 2016-11-01
CN102831293A (en) 2012-12-19
EP2186030A2 (en) 2010-05-19
AU2008286957A1 (en) 2009-02-19
CA3029603C (en) 2022-05-17
CN102982226B (en) 2016-12-21
EP3540741A1 (en) 2019-09-18
CN102831293B (en) 2016-05-18
US20090177769A1 (en) 2009-07-09
EP2186030B1 (en) 2019-02-20
CA3029603A1 (en) 2009-02-19
US20090177249A1 (en) 2009-07-09
CN101821743A (en) 2010-09-01
CA2696082C (en) 2019-02-26
US20090099866A1 (en) 2009-04-16
CN102831294A (en) 2012-12-19
US20090177248A1 (en) 2009-07-09
WO2009023634A9 (en) 2009-04-16
US20090156991A1 (en) 2009-06-18
US20090157202A1 (en) 2009-06-18
JP5341891B2 (en) 2013-11-13
US20090099867A1 (en) 2009-04-16
CA2696082A1 (en) 2009-02-19
AU2008286957B2 (en) 2012-11-01
US20090150484A1 (en) 2009-06-11
US20090157622A1 (en) 2009-06-18
CN102831294B (en) 2016-08-17
CN102982226A (en) 2013-03-20

Similar Documents

Publication Publication Date Title
US9483615B2 (en) Communication of original and updated pump parameters for a medical infusion pump
AU2021209222B2 (en) System and apparatus for electronic patient care using web services
US11164672B2 (en) System and apparatus for electronic patient care
US10242060B2 (en) System and method for comparing and utilizing activity information and configuration information from multiple medical device management systems
US10242159B2 (en) System and apparatus for electronic patient care
AU2012261569B2 (en) Communicating preventative maintenance data to a medical device

Legal Events

Date Code Title Description
AS Assignment

Owner name: SMITHS MEDICAL MD, INC., MINNESOTA

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ROBERTS, NICK;REEL/FRAME:022313/0161

Effective date: 20090219

AS Assignment

Owner name: SMITHS MEDICAL ASD, INC., MASSACHUSETTS

Free format text: MERGER;ASSIGNOR:SMITHS MEDICAL MD, INC.;REEL/FRAME:023182/0621

Effective date: 20090731

Owner name: SMITHS MEDICAL ASD, INC.,MASSACHUSETTS

Free format text: MERGER;ASSIGNOR:SMITHS MEDICAL MD, INC.;REEL/FRAME:023182/0621

Effective date: 20090731

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION