CN1856793A - A medical device management system including a clinical system interface - Google Patents

Abstract

An information system for managing the operation of a medical device delivering therapy to a patient includes: a command processor for processing physician commands to initiate delivery of therapy to a patient; a device management processor for receiving from the command processor an item of data comprising at least one of (a) a patient identifier and (b) an identifier identifying a physician's order, and used in managing access to medical devices used to deliver therapy to patients processing and using the data items in access; and a communication interface enabling bi-directional communication between the device management processor and the medical device.

Description

Medical equipment management system including clinical system interface

Cross References to Related Applications

This application claims priority to pending provisional application Serial No. 60/505,503 filed September 24, 2003 (Applicant Docket No. 03P14624US).

Background technique

A fixed format transaction (transaction), which includes the use of checksum to verify and comply with the information used by the handheld barcode scanner. This approach is consistent with traditional systems using manually operated IV/epidural pumps. Those known systems either use a handheld barcode reader or manually entered (ie, typed) information for the IV/epidural pump. A system according to the principles of the present invention addresses the disadvantages of known systems.

overview

An information system for managing the operation of a medical device delivering therapy to a patient includes: a command processor for processing a physician's command to initiate delivery of therapy to a patient; a device management processor for receiving from the command processor receiving a data item comprising at least one of: (a) a patient identifier and (b) an identifier for identifying a physician's order and for use in managing an identifier for delivering therapy to a patient The data items are processed and used in accessing the medical device; and a communication interface enables bi-directional communication between the device management processor and the medical device.

Description of drawings

The invention and its various variations in its embodiment will be more readily understood from the following detailed description, with reference to the accompanying drawings, in which:

FIG. 1 is a block diagram of a medical equipment management system 1000;

FIG. 2 is a flowchart of a method 2000 for managing medical equipment;

FIG. 3 is a block diagram of a pump manager architecture 3000;

Fig. 4 is a functional flowchart 4000 of the medical equipment management system;

FIG. 5 is a process diagram 5000 of data transmission demographics to an IV pump manager;

FIG. 6 is a process diagram 6000 illustrating the sequence of successful pump command transmission events;

Figure 7 is a process diagram 7000 of sending invalid patient demographics to a pump manager;

Figure 8 is a flow diagram of a pump manager web application architecture 8000;

Figure 9 is a user interface 9000 for logging into the medical equipment management system;

Fig. 10 is the user interface 10000 of the registered medical equipment management system;

FIG. 11 is a user interface 11000 of a registration error message from a medical equipment management system;

Figure 12 is a user interface 12000 for logging into the medical equipment management system;

Fig. 13 is a user interface 13000 of a login error related to the medical equipment management system;

Figure 14 is a user interface 14000 showing available pumps;

Figure 15 is an exemplary user interface 15000 for monitoring a pump;

Figure 16 is a graphical user interface 16000 for monitoring pump flow;

Figure 17 is a user interface 17000 for graphically displaying pump information;

Figure 18 is a flow logic diagram 18000 of user interface navigation;

Figure 19 is an exemplary flow logic diagram 19000 of a medical device management system pump manager application;

Figure 20 is a block diagram of a process flow 20000 for authentication in a medical device management system diagram;

Fig. 21 is a process flow diagram of the security mapping 21000 of the medical equipment management system;

Figure 22 is a flowchart 22000 of an open link transaction (open link transaction);

Figure 23 is a process diagram 23000 for transferring data to a pump manager;

Figure 24 is a process diagram 24000 for sending commands to a pump manager;

Figure 25 is a process diagram 25000 for sending an invalid command to a pump;

Figure 26 is a process diagram 26000 of successful registration in the medical equipment management system;

Figure 27 is a process diagram 27000 of registration failure in the medical equipment management system;

Figure 28 is a process diagram 28000 of verifying device data by an authorized user;

Figure 29 is a process diagram 29000 of successfully logging into the medical equipment management system;

Figure 30 is a process diagram 30000 of failure to attempt to start a session without logging in;

Figure 31 is a process diagram 31000 of login failure;

Figure 32 is a block diagram of a database schema architecture 32000;

Figure 33 is part 33000 of the XML code related to controlling the equipment in the medical equipment management system;

FIG. 34 is an exemplary user interface 34000 for presenting stress test results related to a medical device management system;

Figure 35 is an exemplary surgical tray 35000 that can be identified and tracked by a medical equipment management system;

Figure 36 is a block diagram of information equipment 36000; and

Figure 37 is a process flow diagram 37000 of the medical equipment management system.

definition

When the following terms are used herein, the attached definitions apply:

missing - not present.

Access - communicate with.

Address - An identifier indicating a location.

ALERT - An alert signal.

application program - a program adapted to perform a useful task.

authentication processor - a processor adapted to receive user identification information, determine whether the user is authorized to access an application for managing a particular device, and/or ban the user in response to a determination that the user's access is not authorized access the device.

authorization - to grant power, permission, or permission.

Barcode - Information that can be expressed as a series of parallel bars of varying widths, where each of the digits zero through nine is represented by a different bar pattern that can be read by an optical scanner.

Bidirectional - Capable of communicating in opposite directions.

Communication - exchange of information.

communication interface - bus, connector, network adapter, local area network interface, wired network interface, telephone line interface, cellular network interface, broadband cable interface, modem, wireless network interface, radio receiver, transceiver, and/or antenna, etc. The communication interface enables communication between the device management processor and the device.

Compatible - the ability of one device or program to work with another device or program.

Configuration - set up for a specific purpose.

data - numbers, characters, symbols, etc. relating to a subject.

To deliver - to send out or produce.

Device Management Processor - A processor adapted to receive data items for processing in operation of a management device.

determine - to ascertain, obtain, calculate, and/or provide.

duration - a period of time.

Ethernet - A type of networking technology.

Fail - not succeed.

Field - A logical storage space for a class of data. Fields may include textual, numeric, date, graphical, audio, video, and/or calculated data. Any text field has attributes including fixed or variable length, predetermined display format, and/or association with other fields.

fixed - a form that is stable and/or cannot be changed.

Flow - The amount of liquid delivered to a specific place over a certain period of time.

Infusion Pump - A device adapted to push fluids into a patient's body.

Liquid Drug - A substance, delivered in a liquid medium, that treats, prevents, and/or alleviates the symptoms of at least one condition.

Fluid Volume - The amount of space occupied by liquid.

format - the structure and/or parameters of data related to grouping, transmission, communication, presenting display, and/or rendering of data.

Generate - The act of processing or producing.

Geolocation - A location on Earth.

greater - greater than and/or more than.

Group - Considering multiple individuals or things together due to their similarity.

Hierarchy - An ordered group of people or things within a system.

HealthLevel 7 - A healthcare-specific communication standard for data exchange between computer applications.

Health Care - the prevention, treatment and/or management of disease and the maintenance of mental and physical health through services provided by the medical or allied health professions.

Identification device - a device adapted to provide and/or transmit information identifying an entity. For example, RFID is an implementation for identifying devices.

Identifier - A set of symbols unique to a particular entity, activity, and/or document. The identifier may be, for example, a medical record number. Identifiers may be human and/or machine readable, such as numbers, alphanumeric strings, barcodes, RFID, and the like.

Recognize - establish its identity.

Inactive Session - An idle connection between two messaging devices.

Prohibit - Block and/or disallow.

start - start.

information - data.

Information device - any processing device (in the form of software or hardware) capable of processing information, such as any general purpose and/or special purpose computer, such as a personal computer, workstation, server, minicomputer, mainframe, supercomputer, computer terminal, laptop Computers, wearable computers, and/or personal digital assistants (PDAs), etc.

ask - ask.

IP (Internet Protocol) - A network protocol that specifies the format of data packets, also known as datagrams, and the addressing scheme for data packets. By itself, IP is a protocol for delivering messages from a source to a network, but not establishing a direct link between source and destination. TCP/IP, on the other hand, is capable of establishing a connection between two communicating parties so that the two communicating parties can send messages back and forth over a period of time.

item - a single clause or unit.

Location - Basically close to where something physically exists.

MAC (Media Access Control) address - as identified as the address of a device at the Media Access Control layer in the network architecture.

Machine Readable - A form in which data and/or information can be obtained by an information device.

manage - to direct and/or control.

Mapping - The logical association of the value of one variable with the value of a different variable.

Condition - the patient's state of health characterized by at least one symptom.

Medical Device - a device suitable for diagnosing disease and/or pharmaceutical applications.

Drug - a substance suitable for alleviating at least one symptom and/or curing a condition.

Medication ordering information - data pertaining to the distribution of medicines in the health care system.

member - an entity classified as part of a logical group.

Messaging - Communication.

Monitor - observe.

Multiple Login Attempts - Authentication is attempted more than once in a system with limited access.

New User Registration - The act of recording a first-time user and/or providing them with documentation.

Non-scanned - not digitally encoded via an optical scanning device.

Run - A sequence of actions in an executive function.

Operational Characteristics - Characteristics related to operation.

command - (noun) An authorized instruction to be obeyed.

Command - (verb) To issue an authorized instruction.

Command Processor - Processor for processing commands used to start run management. For example, in a medical equipment management system, a command processor is adapted to initiate the delivery of treatment to a patient.

organized - ordered and/or arranged.

specific - dedicated.

Patient - A human or other type of animal that is supervised for health care purposes.

Patient Administration Information - Data related to a patient's care and/or medication.

Patient Monitoring Device - a device adapted to observe and/or read out information related to the well-being of a patient.

Patient-specific - Relating to and/or specific to a particular patient.

Patient Dose - The amount of a substance administered to a patient.

Execute - implement.

Allow - allow.

Pharmacy Information - Data related to dispensing medication.

Physician - A person qualified to practice medicine.

Predetermined - Established in advance.

Processor - any device and/or set of machine-readable instructions adapted to perform a particular task. A processor includes any one or combination of hardware, firmware, and/or software adapted to perform particular tasks. A processor acts on information by manipulating, analyzing, modifying, converting, transmitting the information to an information device, and/or sending the information to an output device.

To furnish - to furnish or furnish.

Radio Frequency Identification (RFID) - A technology in which electromagnetic or electrostatic coupling to the RF portion of the electromagnetic spectrum is typically used to transmit signals to automatically identify persons or objects. There are several methods of identification, but the most common is to store a serial number, which identifies the person or object and possibly other information, on a microchip attached to the antenna (the chip and the antenna are called RFID transponders or RFID tags). The antenna enables the chip to transmit identification information to the reader. The reader converts the radio waves that bounce off the RFID tag into digital information that can then be communicated with information devices.

Record - A collection of data elements.

record-keeping - the act of preserving information.

registered - formally recorded and/or empowered. For example, a registered user is identified and/or recorded by the medical device management system and is associated with, and/or authorized to use and/or control, a particular medical device.

Repository - A device or database in which data is stored.

Restocking - replenishing and/or replacing obsolete stock.

resource - something for support or assistance.

required - necessary and/or indispensable.

Safe - Relatively free of risk or danger.

Security Checks - Checks suitable for determining whether something or behavior meets a risk threshold.

Safety Determination - An assessment suitable for determining whether something or an action meets a risk threshold.

Status Information - Data relating to descriptive characteristics of a device and or system.

Contiguous - Contiguous array.

system - a collection of mechanisms, devices, and/or instructions that perform one or more specialized functions.

Label - an attachment suitable for identification, classification, and/or marking, etc. For example, tags are often radio frequency identification devices (RFID).

Test - evaluate.

Tracking Processor - A processor adapted to record identifying information relating to the use and/or control of a device.

treatment - administering or applying one or more treatments to a patient or to a disease or injury.

Unauthorized - No authority is conferred or provided.

Unregistered - Not officially documented and/or empowered.

User - A person who interacts with an information device.

Ventilator - Respirator. Ventilators are used to help patients breathe.

Wireless - Any data communication technology that utilizes electromagnetic waves emitted by an antenna to transmit data (that is, via an unguided medium), including such data communication technologies as sonar, radio, cellular, cellular radio, digital cellular radio, ELF, LF, MF, HF, VHF, UHF, SHF, EHF, radar, microwave, satellite microwave, laser, infrared, etc., and especially excluding human voice radio broadcasting, the carrier frequency range of this data communication technology is from about 1Hz to about 2×10 ¹⁴ Hz (about 200 megahertz), including any value therebetween, such as about 40Hz, 6.010kHz, 8.7MHz, 4.518GHz, 30GHz, etc., and including any local range therebetween, such as from about 100kHz to About 100 MHz, from about 30 MHz to about 1 GHz, from about 3 kHz to about 300 GHz, etc. Wireless communications may include analog and/or digital data, signals, and/or broadcasts.

A detailed description

1 is a block diagram of a medical device management system 1000, which includes a server 1100, an information device 1200, a network 1300, a medical device 1400 (for example, a pump, a ventilator, and/or a monitoring device, etc.), and/or Medical equipment 1500 etc. Server 1100 includes user interface 1110 and/or client program 1120 . Applications of the client program 1120 include: verifying the identity of the user; processing commands, such as commands for delivering medication via the medical device 1400 and/or the medical device 1500; monitoring the medical device 1400 and/or the medical device 1500; and/or communicating with Medical device 1400 and/or medical device 1500 communicate. User interface 1110 receives input from a user, and/or presents output to the user.

Physicians generate orders and related information about the orders verbally, in writing, by gestures, and/or via machine entry (such as via typing with a computer keyboard) that can be generated, processed, and/or transmitted to manually and/or automatically execute at least part of the command. At the beginning and/or after processing, the order includes information about the physician, the patient, the medication, the device on which the medication is taken, and/or the condition being treated, among others. With respect to the drug, the order generally indicates the general type, brand name, compounding instruction, dosage, frequency of administration, rate of administration, route of administration, and/or other drug administration instructions, etc.

The server 1100 includes an authentication processor 1130 , a command processor 1140 , a tracking processor 1150 , a device management processor 1160 , and/or a communication interface 1170 . The authentication processor 1130 receives user identification information, such as a username, password, pre-assigned token, social security number, barcode identifier, password, pin number, and/or biometric identifier, among others.

Biometrics is the technique of statistically analyzing and/or comparing measured biological data, such as relatively unique physical characteristics, such as fingerprints. Digital systems, such as the medical device management system 1000, can utilize biometrics to identify and/or authenticate individuals. Biometric features used for identification or authentication include: fingerprints; facial, iris, and retinal scans; and/or voice recognition, among others. Biometric devices typically include and/or utilize scanning or reading devices, software that converts scanned information into digital format, and/or memory that stores biometric information for comparison with stored records. The software identifies particularly matching points of data that have been obtained from the scanning and/or reading device and compares these points with stored data relating to the individual.

Authentication processor 1130 determines whether the user is a member of a predetermined group of authorized users, allows the authorized user to access information related to medical device 1400 and/or medical device 1500, and/or for managing medical device 1400 and/or An application for the medical device 1500 . The authentication processor 1130 prohibits access to information related to the device 1400 and/or the device 1500 and/or an application for managing the device 1400 and/or the device 1500 in response to the determination that the access is not authorized. The authentication processor 1130 maintains a record indicating the level at which the user is able to view the corresponding hierarchically organized information according to the user's authorization level.

Command processor 1140 processes commands to initiate delivery of therapy to the patient. The order includes data items such as an originating physician, a patient identifier (e.g., patient name, patient number, and/or social security number, etc.), an identifier for identifying the order (e.g., order number, prescription number, Physician number, and/or treatment number, etc.), patient-specific health care-related information (e.g., allergies, admission date, and/or procedure identifier, etc.), and/or information about patient-specific medical conditions (e.g., hypertension diagnosis), etc. Order processor 1140 performs the following activities, which include: initiating transfer of information related to a particular medical device to a pharmacy information system for use in preparing and restocking medications; transmission, for use in monitoring the use of certain medications; and/or initiating transmission of information related to certain medical devices to a patient management information system, for monitoring a patient's condition, etc.

The tracking processor 1150 is adapted to record information including user identification information, and/or audit trail user activity with respect to the medical device, and the like. The audit trail records actions such as accessed medical device information, changes in medication, changes in medication dosage, and/or changes in ventilator volume.

Device management processor 1160 receives data items from command processor 1140, processes these data items, and/or uses these data items to manage access to medical device 1400 and/or medical device 1500, medical device 1400 and/or medical device 1500 as used to deliver therapy to a patient. Data items include physician identifiers, patient identifiers, user identifiers, medical unit identifiers, medical record numbers, prescription identifiers, prescription dosages, medical pump flow rates, patient diagnoses, patient medical allergies, and/or Specific patient-related procedures, etc. The device management processor 1160 receives data items from the command processor in a message in a predetermined format (eg, in the form of a formatted database record) with predetermined data fields. The messages of the predetermined format include HealthLevel 7 (HL7) compliant messages. Managing access to medical device 1400 and/or medical device 1500 includes managing access to information related to each respective medical device.

Management of access to medical device 1400 and/or medical device 1500 occurs in response to a determination that a user is authorized and/or registered. A determination that the user is authorized is obtained by comparing an identifier associated with the user to the list of pre-authorized users. This list of pre-authorized users is typically associated with the individual records of the medical institution. A registered user is an authorized user given certain rights and permissions in the management of device 1400 and/or device 1500 . For example, Nurse Jones is authorized to operate the IV pumps on the 12th floor of the west wing of a particular hospital, but not the IV pumps on the east wing or other floors. The device management processor 1160 uses at least one data item in configuring the medical device to deliver therapy to the patient. Actions of device management processor 1160 with respect to medical device 1400 and/or medical device 1500 include: querying for status information, performance and/or communication testing, determining location, determining access, and/or performing security checks to determine whether it is safe to initiate therapy wait.

Server 1100 is communicatively coupled with repository 1180 . Repository 1180 is adapted to store patient related information. Much of the patient-related information stored in repository 1180 is typically patient-specific. Patient specific information includes name, gender, identification number, date of birth, next of kin, diagnosis, prescribed medication, and/or age, among others. Patient information includes patient specific information, insurance provider information, insurance group codes, physician, which medical facility sector the patient is being treated for, available medications, and/or procedures to be performed, and the like.

Device management processor 1160 uses the data items and/or patient-specific information to determine whether it is safe to use medical device 1400 and/or medical device 1500 to deliver therapy to a patient. The determination of whether it is safe to use medical device 1400 and/or medical device 1500 to deliver therapy to a patient is based on the presence or absence of requisite data in predetermined data fields of the message. For example, in the absence of information including physician identifier, prescription number, and/or patient number, etc., the treatment is not considered safe. As another example, a prescription drug treatment is considered safe in the absence of data in a field listing known drug allergies. In response to the user authorization determination, device management processor 1160 determines whether it is safe to use medical device 1400 and/or medical device 1500 . The device management processor 1160 makes security determinations differently for patients without patient-specific information available in the repository 1180 than for patients with patient-specific information available in the repository 1180 . For example, open-heart surgery is not permitted for outpatients, but open-heart surgery is allowed for inpatients. The device management processor 1160 makes a safety determination for patients for which no patient-specific information is available in the repository 1180 based on the absence of required data in predetermined data fields of the message. For example, it is considered unsafe to give a patient penicillin when the question of whether the patient is known to have any allergies is not answered. Based on a comparison of data in predetermined data fields of the message with data in repository 1180 , device management processor 1160 makes a safety determination for patients for which patient-specific information is available in repository 1180 .

In response to the security determination, the device management processor 1160 initiates generation of an alert message to be communicated to the administrator. Alert messages include alerts for new user registrations, alerts for consecutive failed login attempts, alerts for inactive sessions exceeding a predetermined duration, and/or alerts for users attempting to access unauthorized resources, etc.

Device management processor 1160 manages the operation of medical device 1400 and/or medical device 1500 using medical device location information derived using the device's communication address, such as via a device attached to medical device 1400 and/or medical device 1500 on a radio frequency identification ("RFID") tag to export.

The tag includes a wireless identification device and a communication address including an IP (Internet Protocol) or Ethernet MAC address. Device management processor 1160 derives medical device location information using a map that associates communication addresses of medical devices 1400 and/or medical devices 1500 with corresponding medical device geographic locations.

Communication interface 1170 enables two-way communication between device management processor 1160 and medical device 1400 and/or medical device 1500 . Types of communication interface 1170 include serial, parallel, USB, Ethernet, token ring, and/or modem, among others.

The medical equipment management system 1000 includes a network 1300 . Network 1300 is adapted to communicatively couple information devices, such as server 1100 and information device 1200 . Architectures of the network 1300 include direct connections, local area networks, wide area networks such as the public switched telephone network, the Internet, extranets, or any combination thereof. Types of network 1300 include: packet-switched, circuit-switched, connectionless, connection-oriented networks, interconnected networks, or any combination thereof. The orientation of the network 1300 includes: voice, data, or voice and data communication. In addition, the transmission medium of the network 1300 includes: wired line, satellite, wireless, or a combination thereof.

The information device 1200 is adapted to receive information transmitted from the server 1100 . The information device 1200 includes components such as a user interface 1260 , and a client program 1240 . The user interface 1260 is adapted to present information to the user regarding medical device management. The client program 1240 is adapted to accept information related to medical device management from a user.

Information device 1200 is communicatively coupled to repository 1280 . Repository 1180 and/or repository 1280 are adapted to store information obtained from and/or provide information to an information device communicatively coupled to network 1300 . Repository 1180 and/or repository 1280 are adapted to store information related to medical device management in such a manner that the information can be accessed from devices communicatively coupled with network 1300 .

Repository 1180 and/or repository 1280 are devices capable of storing analog or digital information, such as nonvolatile memory, volatile memory, random access memory (RAM), read only memory (ROM), flash memory, magnetic media , hard disk, floppy disk, magnetic tape, optical media, compact disk (CD), digital versatile disk (DVD), and/or disk array (raidarray), etc. Repository 1180 and repository 1280 are adapted to store information about medical device management. Formats for storing information on repository 1180 and/or repository 1280 include database standards such as XML, Microsoft SQL, Microsoft Access, MySQL, Oracle, FileMaker, Sybase, and/or DB2, among others.

Information stored on repository 1180 and/or repository 1280 includes patient-specific information, medication information identifying characteristics of medication delivered in therapy, operating characteristics of infusion pumps, medical device location information, medical device IP or Ethernet At least one of a compatible MAC address, authorized user identification information, liquid delivery flow rate of the infusion pump, and/or volume of liquid delivered by the infusion pump.

Device 1400 and/or device 1500 are used to deliver therapy to a patient. Embodiments of device 1400 and/or device 1500 include: a drug delivery pump, a ventilator, a body temperature monitoring device, a blood pressure monitoring device, and/or an electrocardiogram, and the like.

The medical device management system 1000 integrates the medical device management and order interface system, which speeds up the process of entering patient information and drug-related order data. The medical device management and command interface system directly converts commands from HealthLevel 7 (HL7) compliant or other data formats into machine-readable barcode transactions, such as transactions in non-scannable barcode formats. This non-scanned barcode format transaction is directly interpreted by the medical devices of medical device 1400 and/or medical device 1500 . The medical device management system 1000 includes utilization of authentication, security and reporting. The medical device management system 1000 controls and regulates a specific range of medical device users according to healthcare settings. The medical device management system 1000 allows for: new user registration, automatic notification to administrators, alerts, and/or updates to the user log database. Authentication of medical device 1400 and/or medical device 1500 is simplified by associating a dedicated device with a list of practitioners, such as nurses who are allowed to manage medical device 1400 and/or medical device 1500 . The browser-based architecture of the medical device management system 1000 supports user mobility.

System features of the medical device management system 1000 include: utilizing a pluggable and customizable common architecture; minimizing issues involving user mobility; a flexible network manager (Web Manager) security architecture, such as: SSL support, GSM support, etc.; platform independence; real-time graphical view of device information; and/or a dynamically updated operational dashboard that provides insight into device operation. As used herein, the term "SSL" means Secure Socket Layer, a protocol for providing encrypted communications over the Internet. As used herein, the term "Global Session Manager" or "GSM" denotes a software module used for authentication and authorization.

The medical device management system 1000 provides authentication, security, and reporting subsystems that control and regulate device users in a healthcare setting. Medical device management system 1000 utilizes software to control medical devices 1400 and/or medical devices 1500, any of which may include one or more IV and/or epidural pumps. The medical device management system 1000 establishes a security mechanism to regulate access to the medical device 1400 and/or the medical device 1500 by authorizing users and denying access to unauthorized users.

Via system 1000 , the originator of the command may use the interface engine to send commands, such as directed to the medical device, directly to the database engine involving medical device 1400 and/or medical device 1500 . The database engine: stores the transaction, processes the order, verifies the validity of information contained in the order, stores relevant information in a database, and/or sends the order to the medical device 1400 and/or the medical device 1500 wait. There is no need to generate barcodes for each patient, optically scan barcodes, or manually enter demographics or orders at locations such as pharmacies and/or drug pumps. The medical device management system 1000 automates the process of converting order transactions into fixed-format transactions that are stored within a database for delivery to pharmacies, medical devices 1400 , and/or medical devices 1500 .

The medical equipment management system 1000 provides a user interface 1110 and a method for processing commands received from a standard medication management system and converting these commands into HL7 version V2.4 and/or HL7 version V2.5 commands, which HL7 version V2.5 commands may be used to manage and/or control medical device 1400 and/or medical device 1500 .

Medical device management system 1000: communicates via raw socket connectivity or via data exchange applications; validates the content of transactions; directs command data within a predetermined SQL Server database, such as the database located in repository 1180 and/or verify the content of the transaction by confirming that each transaction includes a valid patient, dose, and network connection between the database and the medical device; etc. In addition, the medical device management system 1000 precisely performs error checking and/or correction, such as computing checksum information to confirm that data has not been corrupted during delivery to the database and/or medical device.

Table 1 includes hardware configurations for various servers and/or information devices, such as server 1100 and/or information device 1200 . Optimizing performance for a given hardware configuration includes minimizing response time for a given transaction load. As used herein, the term "Apache Tomcat" refers to the Servlet container used in the reference implementation for Java Servlet and JSP technologies. Tomcat is an open source implementation used as a web server. Tomcat runs Servlets and JavaServer Pages (JSPs) in web applications. The Apache Foundation is an open source software engineering community headquartered in Forest Hill, Md. As used herein, the term "Apache Jmeter" means a Java application that load tests functional behavior and measures performance.

Table 1 Web server (running Apache Tomcat) Database server (running Microsoft SQLServer2000) OPEN-Link Server (Version 23.1) Client (running Internet Explorer v 6.0.2) Performance testing machine (running JakartaJmeter) type IBM ThinkPad T23 IBM PC IBM PC IBM Think-Pad T23 IBM PC CPU P-III 1.3GHz P-2 433MHz P-2 433MHz P-2 600MHz P-III 1.3GHz RAM 256MB 256MB 256MB 256MB 256MB hard disk 40GB 60GB 20GB 40GB 40GB network adapter Ethernet Pro 100 Ethernet Pro 100 Ethernet Pro 100 Ethernet Pro 100 Ethernet Pro 100

Although there are many factors that affect performance, adding additional resources in two ways, or a combination of them, can have beneficial effects:

First, vertical scaling, which involves spawning additional web server processes on a single physical machine in order to provide multiple thread pools, each thread pool corresponding to a JVM associated with each web server process. As used herein, the term "JVM" means a Java Virtual Machine (Virtual Machine), which is an abstract computing machine or virtual machine. The JVM is a platform-independent execution environment that converts Java code into machine language and executes the machine language.

Second, horizontal scaling, which involves spawning additional web server processes across multiple physical machines.

FIG. 2 is a flowchart of an exemplary implementation of a use 2000 of a method for managing medical devices. At act 2100, user identification information is received. For example,

In act 2200, user authorization is determined. Once authorization is established, the user is authorized to access the application that is used to manage the particular medical device used to deliver therapy to the patient. In response to the determination result that the access is not authorized, the access is prohibited. Users are also registered and/or associated with a particular medical device in order to access applications used to manage that particular medical device. For example,

At act 2300, a data item, such as an order from a physician, is received. The data item includes a patient identifier and/or an identifier identifying the order. The data item is in a message of a predetermined format having predetermined data fields. For example, data items from the order include predetermined information such as patient name, prescription number, drug identification, and/or drug dosage, and the like. Each data item is provided in a predetermined format.

In act 2400, a data item is processed. Therapy is initiated in response to processing of the data item, such as via activation and control of a pump delivering medication to the patient. The processed information provides information, such as medication and/or dosage rates, that can be used to control the particular medical device, such as an intravenous (IV) and/or epidural pump.

At act 2500, communication with a device is effected. Communication with the device is bi-directional and responsive to both user identification and received and/or processed data items. The communication may include at least one data item and/or command-related information. For example,

FIG. 3 is a block diagram of a pump manager architecture 3000 including an information appliance 3100 . Information device 3100 allows a user, such as a physician, pharmacy, and/or administrator, to monitor medical equipment, such as IV/epidural pump 3950 and/or IV/epidural pump 3975 . The information device 3100 is communicatively coupled to other information devices via the network 3200 . The pump manager 3400 is communicatively coupled to the information device 3100 through the first firewall 3300 via the network 3200 . The first firewall 3300 protects the pump manager 3400 from unauthorized access and/or control by unauthorized parties. Pump manager 3400 receives commands to manage and/or monitor IV/epidural pump 3950 and/or IV/epidural pump 3975 . The pump manager 3400 is communicatively coupled to the information device 3500 and the server 3900 through the second firewall 3500 . The second firewall 3500 further protects the pump manager 3400 from unauthorized access and/or control.

The telematics device 3600 provides a user, such as a nurse, with software and a user interface for administering the IV/epidural pump 3950 and/or the IV/epidural pump 3975 . Via the information device 3600, the user receives information such as patient ID, drug type, drug dose, medical device identification, and/or patient condition, among others. The user causes the drugs and devices to be properly placed to meet the requirements of the order. Data items related to the command are transmitted to the server 3900. Server 3900 causes data items to be stored in a database located on repository 3800 in any one of a number of database storage standards. Server 3900 provides control and/or dosing information to IV/Epidural Pump 3950 and/or IV/Epidural Pump 3975. IV/Epidural Pump 3950 and/or IV/Epidural Pump 3975 deliver prescribed medications to the patient.

Factors considered in providing system configurations include size and capacity of available systems and characteristics of network applications. Depending on the number of database reads/updates etc., it makes sense to isolate the database server to give it the maximum amount of power.

The software for managing medical devices can be configured as a three-tier web application residing on a web application server and conjoined with an SMTP mail server. As used herein, the term "SMTP" means Simple Mail Transfer Protocol, which is a standard by which many electronic mail communications occur. In a web-based configuration, the data schema can be based on the SQL Server database engine. The client is a web page generated as a JAP page developed by Apache Tomcat and JSP/Servlet engine. As used herein, the term "Java" denotes a programming language developed by Sun Microsystem, Santa Clara, CA. As used herein, the term "JSP" means Java Server Pages, which are web pages developed by server-side technology developed by Sun Microsystems. As used herein, the term "Servlet" means a small program that runs on a server. The device management software allows organizing workflows for device users (eg nurses who must be tethered to any one physical location in a hospital). The user can use graphical tools included in the device management software to obtain near real-time updates of device status.

The device management software is a multi-tier application that uses a web container but can also include an EJB/application level container like JBOSS or a functionally equivalent container. As used herein, the term "EJB" refers to enterprise Java components, which are server-side component architectures for writing reusable business logic and portable enterprise applications. As used herein, the term "JBOSS" refers to an application server written in Java that is capable of hosting business components developed in Java. A pluggable architecture was found to be suitable for managing user levels accessing administration of IV and/or epidural pumps.

Constraints for implementing device management software include support and implementation flexibility; modularity of software (e.g., splitting presentation and business layers); open architecture capabilities for processing legacy data sources; middleware and software leading to open interfaces platform portability, independent of the web container level; and/or cost considerations, etc.

The Java platform supports the five constraints listed below:

JSP pages allow web developers to quickly and easily generate content-rich, dynamic pages. JSP uses XML-like tags to encapsulate (encapsulate) logic to generate web pages. JSP pages separate page logic from conception and display, which prevents overlapping roles between web page creators and programmers. As used herein, the term "XML" means eXtensible Markup Language, which is a software coding language primarily used for the development of web pages;

Java Servlets extend the functionality of a server by providing specific services within a defined framework. Java code (usually just a single class (class)) provides specific services. For example, an HTTP Servlet can provide login functionality and security for users of a medical equipment management system. Another HTTP Servlet can allow administrators to register new users. As used herein, the term "HTTP" means HyperText Transfer Protocol (HyperText Transfer Protocol), which is the underlying protocol used by the World Wide Web;

JDBC uses open standards for database interaction and handles returning uniform, access to a wide range of relational databases and a common base upon which database tools can be built. As used herein, the term "JDBC" means Java Database Connectivity, which is a Java API that enables Java programs to execute SQL statements. As used herein, the term "API" means Application Programming Interface, which is a set of routines, protocols, and tools for building software applications. The Java Connector API, recently released by Sun Microsystems, enables Java-based web containers/application servers to access enterprise information sources; and

A web application (as defined in the Servlet specification) is a collection of Servlets, JSPs, HTML documents, images, and/or other web resources configured in such a way as to span any Servlet-enabled web servers for portable deployment (Tomcat, reference Servlet/JSP specification distributed under the Apache license for deploying web applications in a platform-independent manner. As used herein, the term "HTML" means hypertext markup Language, the hypertext markup language is an editing language for producing documents on the World Wide Web. In addition, the JavaMail ^TM API is a Java standard extension, and the JavaMail ^TM API provides a strict protocol-independent method for email sending and receiving. The API is used for Notify the administrator that some important event occurred in the running of the application). The costs involved in managing relational databases can also be improved if SQL Server is replaced with the later release of MySQL.

Model-View-Controller ("MVC", Model-View-Controller) is a sample architecture recommended by Java Blueprints for interactive applications. MVC organizes interactive applications into three separate modules: one for the application model, with its data representation and business logic; the second for the view, which provides data display and user input; And a third for controllers, to dispatch requirements and control flow. The medical equipment management software application framework uses a variation of the MVC sample. This architecture is used to address specific issues associated with nurse administration of IV and/or epidural pumps.

FIG. 4 is a functional flowchart 4000 of the medical equipment management system.

Send patient-related commands and demographic data from a health information system or medication management inspection to the medication management command interface transaction system (MAOIT) retrieval (retrieve) transaction subfunction via an interface engine that supports data conversion, interpretation, and separation communication with individual software functions. Interface Engine Known as "OPENLink." OPENLink is a system that bi-directionally exchanges data between two different computer systems using compatible or incompatible data communication formats and protocols. Third-party instances of this interface engine are also available. "OPENLink" is used herein as an example only. Once received the demographic data is converted into an equivalent barcode (with a commensurate checksum) and sent to the database manager where the data is stored. Then check the validity of the data. If demographic data is available, the patient name and identifier are recorded in the database.

The IV pump application composes an acknowledgment message and sends it to the originating system via the "OPENLink". Two "OPENLink" interfaces are included in the medical device management system: one for outbound important transactions and the other for inbound pump drug interactions. Input transactions are fed to the MAOIT application. Output transactions are sent from the database application to the health information system, medication administration test, and/or pharmacy.

FIG. 5 is a process diagram 5000 of transferring demographics data to an IV pump manager. Process diagram 5000 depicts successful demographics transfer events and shows a sequence of successful demographics events. The Health Care Information System (HIS) initiates the event. The information is checked for validity and then stored in a SQL Server database. In this case, the medical device (eg, IV pump) is unaffected and remains in its current mode.

FIG. 6 is a process diagram 6000 illustrating the sequence of successful pump command transmission events. The command-related data include, inter alia, information relating to the running/running of the pump. If a valid patient identifier and name is recorded in the database, then the order associated with that patient is updated within the database.

In a valid demographics event, the transaction is in an HL7 standard message, which has the required fields filled. A method for controlling duplication is introduced in the medical device management system. This method prevents duplicate information from being entered into the database.

Transactions are in HL7 format following ORC syntax in valid command events. The Common Order segment (ORC) is used to transport fields that are common to the order (type of service requested). This is the standard syntax used within HL7 commands (eg include pharma, meal). This demographic status (such as patient name, patient ID, etc.) has been stored in a database and thus can be used as a validation mechanism. For example, an order for a particular patient that is associated to a particular pump cannot be assigned to a pump other than the pump invoked in the order.

The Network Manager software component allows the user to send patient demographic information and order transactions to the infusion pump interface application using the HL7 standard. The interface application communicates directly with the pump via wireless 802.11b protocol and allows changes to be submitted to the pump. Therefore, commands initiated by medical management checks are pushed to the pump. Confirmation about the changed order includes: data items (flow rate, dose, volume to be delivered, drug id, and/or drug concentration, etc.) ) to provide feedback for the command.

Observable from the workflow, input to the HIS (via HL7 transactions) can be provided within the workflow engine, such as verifying the execution of a planned command. This mechanism is also suitable for mechanical ventilation, where commands set by the respiratory therapist through the HIS are confirmed via output transactions from the mechanical ventilator on a particular patient. The RFID tag associates the location of the mechanical ventilator with the patient identifier. A specific ventilator positioned at a specific location to assist a specific patient receives a dedicated command, and the results of that command are verified by a comparable output significant transaction from the ventilator at the location associated with the patient medical record number (MRN). machine.

FIG. 7 is a process diagram 7000 for sending invalid patient demographics to the pump manager. The processed information does not affect the information stored in the relational database. Error messages are sent back to the Admission, Discharge and Transfer (ADT) initiator. For invalid commands sent to a device control manager, such as an IV pump manager, the invalid command information does not affect IV pump operation. An error message is sent back to the command initiator.

The medical device management system maintains the flow of work and communication from the original command to the actual device itself. There is no need to manually maintain and provide barcodes or scan their information.

FIG. 8 is a flow diagram of a pump manager web application architecture 8000. The application is divided into the following modules:

A user module, which is a web application through which a user logs in and views IV pump information and visual statistics. In this embodiment, the user is a nurse; and

Registration module, which is a web application that provides registration of new users (nurses). This module also provides workflows that enable such systems to be managed seamlessly.

FIG. 9 is a user interface 9000 for logging into the medical device management system. If the application is installed on a device named "localhost" accessible via port 8085, the user accesses user interface 9000 via an HTML browser to a URL that begins with the phrase http and includes //localhost:8085/ IVPump/login. jsp. Ports are identified semi-arbitrarily: There are dedicated ports for OS level and HIS inter-process communication. These dedicated ports are usually numbered in the range from 0 to 8000. Generally use port values greater than 8000 because these port values are less likely to conflict with existing application software and operating system communications. User interface 9000 allows a user to log in; register as a new user of the pump manager system (unless the user already exists), redirect the request to a URL that accesses the register.jsp page; and send an email to the administrator in case of login difficulties. mail.

Send automatic alerts to administrators in case of any significant events in the system.

FIG. 10 is a user interface 10000 for registration with the medical equipment management system. If the user chooses to register as a new user, then a user interface 10000 (such as an interface similar to register.jsp) appears. Via the user interface 10000, the user: enters a chosen login username; enters a desired password and confirms it; enters a desired management level (overrideable by the administrator); and enters work location details such as location and/or phone number; etc.

JavaScript is typically used in this page to confirm that the user submitted the necessary information and to minimize server traffic. Once the user presses "submit," this information is entered into the database and the user is redirected to the login page.

FIG. 11 is a user interface 11000 of a registration error message from a medical device management system. In case the user exists, already has duplicate information, then a user interface 11000 (such as an interface similar to registerError.jsp) is displayed to the user and prompted to select a different login name.

Figure 12 is a user interface 12000 for logging into the medical device management system. If the registration is successful, the user is directed to user interface 12000 to log into the medical equipment management system. At this point, an email is automatically sent to the administrator. The user interface 12000 is displayed using JavaMail API and "Java Activation Framework". As used herein, the term "Java Activation Framework" means a set of standard services, available from Sun Microsystems, to determine the type of any piece of data, encapsulate access to it, discover operations available on it, and Instantiates the appropriate component to perform the operation.

FIG. 13 is a user interface 13000 of a login error related to the medical equipment management system. If the login fails, the user is presented with user interface 13000 that prompts the user to try the login process again and provides a link to contact an administrator in case of repeated difficulties. If three login attempts fail, an email is automatically sent to the administrator stating that unauthorized access was attempted.

Figure 14 is a user interface 14000 showing available pumps. In case of a successful login, the user is directed to view pump information according to the user's administrative rights or census (selected during registration and later verified by the administrator). The user interface 14000 enables the user to view pump information by pump identification; pump location; pump MAC address; pump current status; pump uptime; access point MAC address; As used herein, the term "MAC address" means a media access control address, which is a hardware address that uniquely identifies each node of a network. The user can also refresh the pump information by pressing the "Refresh Pump Data" user interface button. This button refreshes the user interface 14000 in real time to ensure the user is viewing the latest information in the IV pump SQL Server database. The user may exit at any time using buttons or other rendering provided by user interface 14000.

FIG. 15 is an exemplary user interface 15000 for monitoring a pump. A user may view textual and/or graphical information via user interface 15000 about any particular pump using the link provided under the access point field.

The user interface 15000 provides real-time information on "vital statistics" on selected devices and allows administrators to set verification times and update rate settings, among other things. This reporting mechanism has general application in healthcare settings and a dedicated application for IV epidural pumps.

Figure 16 is a graphical user interface 16000 for monitoring pump flow. User interface 16000 is activated, for example, by a button or a comparable drawing included in a user interface such as user interface 15000 in FIG. 15 . User interface 16000 is typically rendered as a pop-up window. After viewing user interface 16000, the user may close the popup using the "Close" button. The user can then exit the application using the "Exit" button provided.

Figure 17 is a user interface 17000 that graphically displays pump information. User interface 17000 provides real-time information on traffic flow as a function of time for selected devices. This reporting mechanism has general application for medical devices in healthcare settings with applications for IV epidural pumps.

FIG. 18 is a flow logic diagram 18000 of user interface navigation showing the sequence of navigating through JSP pages. Flow Logic Diagram 18000 illustrates exemplary rendering criteria and sequencing of multiple JSP pages.

The pump manager's network layer (tier) serves HTTP requests. This network layer does four basic things in a specific order: interprets client requests; dispatches those requests to business logic; selects the next view to display; and produces and delivers that next view.

FIG. 19 is an exemplary flow logic diagram 19000 of a medical device management system pump manager application. An early step in enforcing authentication and authorization requires users to authenticate or prove their identifiers in order to access the Common Application's Pump Manager group. The user may submit information such as a password or credentials to prove identity. The security system checks this information against a database of known users. If the submitted information matches that in the database, the user is successfully authenticated.

Certain implementations use the following three levels of security for any user logging in via the Internet: secure socket slayer support; VPN/enterprise-grade firewall access; and form-based login and password-based identity verify. As used herein, the term "VPN" means a virtual private network, which is a network constructed by connecting nodes using public lines. Communication over a VPN is usually encapsulated in some way so that it cannot be read by its unintended recipients. The first two are provided by any corporate entity/hospital. Pump Manager provides the last and its common architecture also makes it easy to integrate it with the following security levels: Microsoft LDAP (the Windows standard that enables networked directories); Global Session Manager, or GSM (for authentication and authorization); Sun Java JNDI (JavaNative Directory Interface); XML file-based authentication (a security attribute used by most commercial application server implementations); and/or biometrics (biometric) (eg, fingerprints, voice patterns, or DNA); etc.

Other authentication mechanisms can combine these; examples are digital certificates, where key-based (eg, username and password, etc.) and knowledge-based (eg, SSL, etc.) authentication can be practiced.

Fig. 20 is a block diagram of a process flow 20000 for authentication in a medical device management system diagram showing a generic but pluggable architecture for security by the pump manager. The pump manager architecture provides task-based security mechanisms that can be configured by selecting appropriate and required user settings at registration time. Depending on the security level chosen, resources are allocated or limited accordingly. Private groups of users may be allowed access to specific pumps, such as specific nurses and clinicians associated with specific patients, beds, nursing units, and/or pumps, and the like.

Fig. 21 is a process flow diagram of security mapping (mapping) 21000 of the medical equipment management system. Security map 21000 shows security relationships of functions. Users access secure resources via authentication and/or authorization processes. Users access patient information from network resources, database resources, and/or messaging resources, among others. Administrators and/or database engineers implement and/or enforce security policies and mappings.

Figure 22 is a flow diagram 22000 of an open link transaction that models workflow through an application. Patient demographics are sent from the HIS to the Pump Manager via OPENLink. Once received by OPENLink, this demographic data is redirected to the IV pump app. The application then handles the request. Verify the validity of the request.

If demographic data is available, the patient name and identifier are recorded in the database. The IV pump system software application composes the confirmation message and sends the message to the priming system via OPEMLink.

Flowchart 22000 includes two OPENLink interfaces: one for outgoing interactions and one for incoming interactions. The input interaction sends information to the pump application. The output interaction sends information from the pump application.

Figure 23 is a process diagram 23000 of transferring data to a pump manager showing a sequence of successful demographic events. Data obtained via the user interface initiates the event. Check the validity of the information and then store it in the SQL server database. In this case the pump is unaffected and remains in its current mode.

Figure 24 is a process diagram 24000 of sending a command to the pump manager showing a successful command transmission event. This command includes information relating specifically to the operation/running of the pump. If a valid patient identifier and/or name is recorded in the database, the IV pump manager accepts commands related to that patient to update within the database.

Transactions processed via Process Map 24000 to be valid Demographics Events need to be in the HL7 standard format and have the required fields filled. Introduced methods for controlling repetition in the application. This method of duplication prevents duplicate information from being entered in the database.

Transactions processed by the graph 24000 as valid commands are in HL 7 format following the ORC syntax. The common command segment (ORC) is used to transport fields that are common to the command (type of service requested). ORC syntax is the standard syntax used within HL7 commands (eg, including pharmaceutical, meal). Demographic information (such as patient name, patient ID, etc.) is stored in a database to be used as an authentication mechanism. For example, an order for a particular patient associated with a particular pump cannot be transmitted to a different pump.

Figure 25 is a process diagram 25000 for sending an invalid command to a pump. Process Diagram 25000 shows that invalid order information does not affect information stored in the database. An error message is sent back to the command initiator. Process diagram 25000 is also used in situations where an invalid command is sent to the pump manager. This information does not affect pump operation. An error message is sent back to the sending system originator.

Figure 26 is a process diagram 26000 for successful registration in the medical equipment management system. Users register by providing their credentials and hitting submit on the register.jsp page. The authentication request is then sent to the Servlet svltRegister, which then uses the registerUser() method to check the database for duplicate usernames. If so, a registration error page is rendered, urging the user to try registration again. If registration is successful, the user is directed to login.

Figure 27 is a process diagram 27000 for a failed registration in a medical device management system where a user registers by providing credentials and directs the submission of these credentials by selecting an icon, such as a submit button on the register.jsp page. The mail is then sent to the Servlet svltRegister, which then uses the registerUser() method to check the database for duplicate usernames. If a duplicate username is found, render a registration error page and urge the user to try registration again.

Figure 28 is a process diagram 28000 for verifying device data by an authorized user.

Figure 29 is a process diagram 29000 of a successful login to a medical device management system, where a user registers by providing credentials and directing the submission of those credentials by selecting an icon, such as a submit button on the login.jsp page. The mail is then sent to the ServletsvltController, which then uses the getUser() method to check the database to see if there is a match. If the information indicates that the user is already registered, the user is allowed to log in.

Figure 30 is a process diagram 30000 of a failed attempt to open a session without logging in, where the user types the name of the Servlet controller directly into the address window of the browser. The svltController uses session tracking to know that the user is not in a session. The user is redirected to an error page.

Figure 31 is a process diagram 31000 for a failed login where the user registers by providing their credentials and clicking Submit on the login.jsp page. A mail (POST) is then sent to the Servlet svltController, which then checks the database using the getUser() method to see if there is a match. If the user is not authorized, an error page is rendered and the user is urged to make another login attempt.

32 is a block diagram of a database schema schema 32000 that includes a plurality of tables that include information about IV pumps, patients, medications, user logins, locations, and/or times, among others. The IV pump information table includes pump ID, bed identifier, status, MAC address, run time, patient identifier, drug name, flow rate, mode, channel, update rate, and/or update unit, among others. In Database Schema Schema 32000, IV pump information is divided into two tables. Patient form includes last name, first name, middle name not filled in, patient identifier, medical record number, visit identifier, height, height unit, weight, weight unit, nurse identifier, IV pump identifier, medication name, and/or or drug identifier, etc.

The dose table includes dose name, dose identifier, patient identifier, volume delivered, units of volume delivered, elapsed time, units of elapsed time, time remaining for a particular medication dose, units of time remaining, flow rate, and /or units of flow, etc. The user login form includes a nurse identifier, password, user level, first name, middle name, last name, email address, and/or location, among others. The location table includes IV pump identifiers, hospital bed tags, and/or patient identifiers, among others. The time table includes date, current time, units of current time, time zone, units of time zone, elapsed time, units of elapsed time, remaining time, units of remaining time, update rate, and/or units of update rate, and the like.

Table II provides details of the database schema of the medical equipment management system. A record of the database schema includes:

Patient: holding patient information linked to a specific medical device;

Medical equipment: holding medical equipment information;

Pharmacy: holds information on pharmaceuticals to be managed by medical equipment;

Time: holds the time attribute of the medical device application;

Location: holds information about where the medical device is; and

Login: Holds information about authorized users and associated pumps.

Each form includes more than one field. Fields within a record (as indicated in Table II) are pre-named and predefined. Fields have a predetermined format. Fields are used to accept, store, transmit, and/or render data.

Table II form name Function Attributes patient This form holds patient information that is linked to a specific IV pump Last_Name, First_Name, MI, Ext_PID, MRN, VISIT_ID, Height, Height_Units, Weight, Weight_Units, Nurse_ID, IVPump_ID, Drug_name, Drug_ID IV pump This form holds IV pump information IVPump_ID, Bed_Lable, Ext_PID, Drug_name, Flow_rate, Flow_rate_Units, State, Current_mode, Active_Channel, Update_rate, Update rate units potion This form holds information about medications infused through the IV pump Drug_Name, Drug_ID, Ext_PID, Volume_Delivered, Volume_Delivered_Units, Time_operating, Time_operating_units, Remaining_Time, Remaining_Time_units, Flow_rate, Flow_rate_units, Dosage, Dose_Units, Concentration, Concentration_Units time This form holds some time attributes for IV pump applications Date, Current_time, Current_time_units, Time_zone, Time_zone_units, Time_operating, Time_operating_units, Remaining_time, Remaining_time_units, Update_rate, Update_rate_units Location This form provides information on where the IV pump is IVPump_ID, Bed_Label, Ext_PID Log in This table holds information about authorized users and associated pumps Nurse_ID, password, User_level, First_Name, Last_Name, Email_Address, Location

Build, package, and/or deploy medical device web applications using Tomcat. The deploying step includes establishing a network application directory structure, establishing a web application ServletContext, adding JSP and Servlet, adding a tag library, and/or establishing and expanding a WAR file, etc. These steps are easily extended to any medical device application that follows the architecture of the medical device management system.

Table III shows the network application directory structure of the medical equipment management system. The directory structure includes multiple directories and subdirectories for storing webpages, webpage resources, utility programs and/or archive files, and the like.

Table III Table of contents content /IVPump This is the root directory of the web application. JSP and HTML files are stored here. /IVPump/WEB-INF This directory contains application-related resources that are not in the application's root document. This is where the IVPump web application unwind descriptor resides. It should be noted that the WEB-INF directory is not part of the document. Any files included in this directory are not directly available to clients. /IVPump/WEB-INF/classes This directory is where the Servlet and utility classes are located. /IVPump/WEB-INF/lib This directory contains the Java archives that the Pump Manager web application depends on. For example this is where you put the JAR file that gives us the jsp taglib and Java mail support.

Figure 33 is a portion 33000 of XML code related to controlling devices in a medical device management system. A step in establishing the web application directory structure is to add deployment descriptors. Part 33000 of the XML code is copied to a director, such as TOMCAT_HOME/IVPump/WEB-INF/directory. After establishing the web application directory structure, add a new ServletContext to Tomacat. The ServletContext defines a set of methods used by components of the web application to communicate with the Servlet container. The ServletContext acts as a container for web applications. There is only one ServletContext per web application.

To add a new ServletContext to Tomcat, an entry is added to a file, such as the TOMACAT_HOME/conf/server.xml file, to set the path and docBase values to the name of the web application, such as the IVPump application. The entry is thus: <Context path="/IVPump" docBase="IVPump" debug="0" reloadable="true"/>.

First, path="/IVPump" informs the Servlet container that the request appended with /IVPump after the URL of the server belongs to the IVPump network application. Second, docBase="IVPump" informs the Servlet container that the web application exists in the /IVPump directory.

The steps for adding Servlet and JSP include: placing JSP pages directly under the WEB-INF folder, compiling the Servlet, and/or moving the Servlet to a directory such as the /IVPump/WEB-INF/classes/com/IVPump directory, etc.

34 is an exemplary user interface 34000 for plotting stress test results related to a medical device management system, using Apache JMeter to load test the medical device manager application. User interface 34000 is presented in tabular representation with additional Jmeter data, in actual testing, 10 simultaneous active users were handled when running on a Pentium 4, 1.3GHz PC with 256MB of RAM Has a maximum response time of 297 ms, while handling a peak load of 40 users saw a 23% drop in response time.

The software used to run the medical device application includes: JSP/Servlet implementations that can run as stand-alone or extensions to web servers (in the test implementation, Tomcat 4.0.3 was used, because the standard Tomcat tag library is widely used, so the application program relies on Tomcat in some form); SMTP mail server, which is optional but since the application typically uses the corporate intranet, it is reasonable to expect this; Microsoft SQL Server is recommended as a relational database management system (Other implementations of the medical device manager may use MySQL as the database engine); and/or Apache Jmeter has been used to load test the application; etc.

As used herein, "JSTL" means the Java Server Pages Standard Tag Library (JavaServer Pages Standard Tag Library), which encapsulates the core functionality of simple tags common to many web applications. JSTL has support for common, structural tasks such as iteration and conditional, tags for manipulating XML documents, internationalization tags, and SQL tags. JSTL also provides a framework for integrating existing client tags with JSTL tags. As used herein, the term "Jakarta Struts" refers to an open source framework for building Java web applications. The Struts framework includes a control layer based on technologies like Java Servlet, JavaBean, ResourceBundle and XML.

The clinical context object workgroup ("CCOW") is a standard that specifies architectures, component interfaces, and data definitions and interoperable technologies (specific mappings of these architectures, interfaces, and definitions). Using CCOW, multiple applications can automatically coordinate and synchronize at the point-of-use. A dedicated architecture establishes the basis for bringing interoperability to the point of use in healthcare applications. The JBOSS application server is a Java 2 Enterprise Edition application server with EJB support.

Factors to consider in setting up the system include: providing a registration module (such as a web application) that includes a user interface (such as one that uses XML messaging rather than an HTML web browser); , using JSTL instead of Java components may be a performance bottleneck; MVC framework like Jakarta Struts; combined with GSM, or CCOW; and/or open source like Jboss application server at the network layer, or HIS application server together with Apache Tomcat EJB container; etc.

Table IV shows the entire IV pump inventory and associates dedicated infusion pumps with specific room locations and patient identifiers (PID/MRN=Patient Identification/Medical Record Number) within specific units in the establishment. The information carried by the RFID tag (eg, patient identifier and local pump IP address) uniquely defines the pump associated with a particular patient. Therefore, the pump can be positioned very quickly with this view. This view can be quickly generated via script and displayed within a web browser.

Table IV IV Pump List: 50 Unit: 5 - West Side Pumps in use: 10 Room/POD MAC/IP address PID/MRN 5W 101 00-30-F1-35-54-D8 400336 5W 102 31-67-G3-67-23-A1 844179 ... ... ... 5W 110 98-H2-45-89-01-J4 143582 Unit: ICU-1 Pumps in use: 20 Room/POD MAC/IP address PID/MRN ICU 1101 89-32-54-69-B4-19 903512 ... ... ... ICU 1120 90-11-D7-76-A8-18 796380 Unassigned list: 12 Under maintenance: 8

The medical device system information provides feedback to the pharmacy entity on the location of the monitored device within the enterprise and/or provides feedback to the pharmacy entity in the vicinity of a particular pump. For example, when a patient arrives or leaves, administers and/or removes IV fluid from the pump; updates to the presented user interface.

Information about unallocated medical equipment enables clinicians to order drips for patients, to determine the number of pumps available and available in the establishment. Information about unallocated medical equipment also provides useful information for managing maintenance of previously active pumps in order to prepare those pumps for future patients.

When an order is given to an application using a medical device, a particular medical device can be assigned that order (eg, an electronic order carrying a pump identifier). Medical devices are associated with patients and managed by at least one clinician. An identifier, such as a unique serial identification associated with the medical device, can be communicated via the wireless network adapter and then provide a means of managing and knowing the location of both the medical device and the patient; a particular patient relative to the assigned medical device the location of the medical device; whether the medical device is being serviced out of order (moved to a repair station) or medications being taken are decreasing; and/or whether the medical device requires general maintenance.

Orders assigned to a particular medical device have a location and an identifier associated with them so that the pharmacy can unambiguously determine the location and patient assigned to any pump.

Figure 35 is an exemplary surgical tray 35000 that can be identified and tracked by a medical equipment management system. The Scheduling operating room for surgical procedures includes linking clinical orders to scheduling entities. Commands for surgical procedures translate into multiple demands on resources: available staff, operating rooms available on a particular day and time, and/or equipment that must be brought in to support a particular procedure, etc. The Surgical Tray 35000 is a piece of equipment that is tracked and must be prepared and dispatched for surgery. An RFID tag can be associated with a Surgical Tray 35000 to track the Surgical Tray 35000 as part of an inventory (the contents of the Surgical Tray 35000 vary depending on the type of procedure being performed).

Therefore, using RFID tags in cooperation with a network manager (a different application than a medical device) has the advantage of being able to locate an inventory of a surgical tray such as the Surgical Tray 35000; having specific information about where a particular tray such as the Surgical Tray 35000 is ; and/or have specific information about the location where the patient is to undergo surgery; etc. In this manner, the surgical order specifies the particular type of surgical tray 35000 needed and when and to which operating theater the surgical tray 35000 should be sent. Thus, the Surgical Tray 35000 can be brought to the operating room and isolated off-line prior to patient surgery so that it is not misappropriated or valuable time is wasted trying to locate the Surgical Tray 35000. The RFID tag is typically applied directly to the Surgical Tray 35000 (e.g., the back).

Radio frequency identification tags (RFID), implemented in passive and active types, retain specific information about their associated objects (in particular, identifiers of equipment, patients, etc.). Passive RFID tags do not have their own power source: the microcurrent induced in the RFID antenna by the incoming RF scan provides enough energy for the tag to send a response. Due to energy and cost, the response of passive RFID tags must be short, usually only the ID number (GUID). Active RFID tags include a power source and can have a longer range and greater memory than passive tags and the ability to store additional information sent by the transceiver.

Attaching RFID tags allows for equipment (infusion pumps, patient monitors, etc.) to be managed and tracked. For example, the following table shows a view that can be managed through a medical device (such as IV pump) network manager interface showing the number of medical devices used in a particular unit and room within an enterprise.

Mechanical ventilators for respiratory support are often used in intensive care units. Mechanical ventilators are usually assigned to patients who are unable to maintain spontaneous breathing and therefore need assisted breathing. There are many types of patients who need help in this way, one type is coronary artery bypass graft patients. The use of a mechanical ventilator requires a physician to order the use of a ventilator for a specific patient. These orders translate into placing mechanical ventilators in patients' rooms, sometimes in preparation for the patient's arrival. Locating mechanical ventilators for use within the enterprise would benefit from RFID tags consistent with management systems for associating the location of the mechanical ventilator with a specific patient. The RFID tag can be attached directly to the exterior of the ventilator. Once programmed with a unique identifier (eg, the serial number of the ventilator), this data can be transferred to a web-based application (transaction manager) and associated with a specific patient. In this way, the medical equipment management system: tracks the location of the ventilator; positively associates a commanded change to a specific patient (identified by the patient medical record number or external identifier) with the specific ventilator; within the patient's clinical record Maintain an audit trail of clinical records regarding specific ventilators used during treatment (for volume control purposes and legal reasons should be patients with post-extubation complications); and/or utilize physician orders Verifying the settings of the mechanical ventilator by verifying the specific ventilator settings available through the care system with the patient identifier and then associating the identifier with the mechanical ventilator, etc. Audit trails can also be used for volume control to determine that a physician's order was executed on a specific ventilator at a specific time (feedback to clinical orders).

Fig. 36 is a block diagram of an information device 36000, for example, the information device 36000 includes the information device 1200 and/or the server 1100 in Fig. 1 . Information device 36000 includes any number of well-known components, such as one or more network interfaces 36100, one or more processors 36200, one or more memories 36300 containing instructions 36400, one or more input/output (I/O) device 36500, and/or one or more user interfaces 36600 coupled to I/O device 36500, and/or the like. Via one or more user interfaces 36600, such as a graphical user interface, a user can view a plot of information related to the use and/or management of the medical device.

Figure 37 is a block diagram of a medical device management system 37000 depicting the main functions performed by the IV pump manager with the support of command processing.

The prescription 37100 arrives at the pharmacy, as shown at 37200, where a pharmacist processes the prescription 37100 and prepares the dose and intravenous medication to be delivered to the patient via IV pump 37900.

At 37200 the pharmacist labels the medication and IV fluid bags with patient, order to clinician, and medication identification information. This information is stored in the form of barcode labels and/or RFID tags created by the pharmacy processing software.

During the prescription fulfillment process, the pharmacist (in one embodiment) transmits identifying information to the point of care using a command entry user interface (at 37300), which can receive: data manually provided by the pharmacist, via network Data provided in scanned barcode format, and/or via barcode scanner (at 37225) and/or radio frequency tag reader (at 37250).

At 37400, drug, patient and device identification information is stored in the order table of the IV pump manager database.

At 37600, the IV Pump Manager Command Processor directed and monitored by the IV Pump Manager Processing Manager 37500 is constantly polling and retrieving new command information from the Command Table 37400.

Queue Processor 37700 receives new orders from Order Processor 37600 and extracts from the order information identifying the particular patient and IV pump. The Process Manager 37500 continuously updates the Queuing Processor 37700 for changes to individual IV pump profiles (ie, changes in alarm status, pump polling attempts, active pumps, etc.).

The Queuing Processor 37700 passes the appropriately formatted message to the Communications Processor 37800 which attempts to transmit the message to the IV Pump 37900 dedicated to the patient.

The communication processor 378000 communicates with the IV pump 37900 using standard network protocols (usually wired or wireless communication via TCP/IP protocol transmission).

Communications Processor 37800 notifies Queuing Processor 37700 when: (i) network communication with IV Pump 37900 cannot be established; (ii) IV Pump 37900 does not respond to a properly formatted transmission, (iii) IV Pump 37900 is not in a receiving The correct status of the transmission, and/or, (iv) IV Pump 37900 has acknowledged receipt of the transmission.

Upon receipt of one of these messages, the Queue Processor 37700 communicates with the Process Manager 37500 to inform it that the delivery was successful or that the delivery failed and, in the event of a failed delivery, the reason. The Treatment Manager 37500 provides notification messages that can be used by pharmacists and clinicians. The processing manager 37500 transmits the notification message to the command table 37400 through the command processor 37600 .

Once the notification message is stored within the command form 37400, the notification message is available for delivery to any number of recipients. One implementation of this notification is through the Order Status User Interface 37950, which provides the form status of each order, when the order was delivered, when the order was accepted by the IV Pump 37900, and whether it is at the point of care The order is executed (ie, the clinician has confirmed acceptance of the order).

The Queue Handler 37700 maintains a list of pump common commands and attempts to resend these commands in a round robin fashion to pumps whose previous attempts failed. The total number and duration of retransmission attempts by the Queue Processor 37700 are dictated by the Profile managed by the Process Manager 37500.

Queue Processor 37700 can facilitate the delivery of fulfilled orders from the pharmacy to the logistics of the IV Pump 37900 at the point of care. It is unlikely that the pharmacist and the specific IV pump will be co-located physically. The Queue Processor 37400 eliminates the need for clinicians and pharmacists to coordinate delivery of orders to the point of care at the same time. The Queue Processor 37700 provides both the pharmacist and the clinician with the flexibility to act and asynchronously respond to transmitted commands without the risk of losing information or requiring the pharmacist to manually resend the order to the bedside . Instead, the pharmacist transmits the order and the order is executed later (within a clinically acceptable time limit) to allow the clinician to be aware of the transmission and move to the bedside. Queue Processor 37700 "waits" for the clinician and allows the clinician to reach the appropriate IV pump so that the pump can be directed to accept input commands.

Other embodiments will be readily apparent to those of ordinary skill in the art from reading the foregoing detailed description and drawings of certain exemplary embodiments.

Claims (20)

1. An information system for managing the operation of medical equipment delivering treatment to patients, the information system comprising: an order processor for processing orders from physicians to initiate delivery of treatment to patients; a device management processor configured to receive a data item from said command processor, said data item comprising at least one of the following: (a) a patient identifier, and (b) an identifier used to identify the physician's order, and for processing and using said data item in managing access to a medical device used to deliver said therapy to said patient, wherein said device manager processor associates at least one registered user with the medical device is associated, and wherein the device management processor is adapted to register unregistered users; and A communication interface that enables two-way communication between the device management processor and the medical device. 2. The information system of claim 1, wherein The patient identifier comprises a non-scannable fixed format barcode. 3. The information system of claim 1, wherein In said medical device configured to deliver said therapy to said patient, said device management processor uses at least one of said data items, and The device management processor uses at least one of the data items in at least one of: (a) interrogating the medical device for status information, (b) testing the medical device, (c) Determining the location of the medical device, (d) determining that access to the medical device is authorized, and (e) performing a security check to determine whether it is safe to use the medical device to initiate the therapy. 4. The information system of claim 1, wherein The medical device includes at least one of: (a) an infusion pump, (b) a respirator, (c) a patient monitoring device, and The managing access to the medical device includes managing access to information about the medical device. 5. The information system of claim 1, comprising an authentication processor for receiving user identification information and for determining that the user is a member of a predetermined authorized group of users, and for inhibiting access to said medical device information in response to the determination that access is unauthorized , the authorized user is permitted to access information about said medical device, and A tracking processor for recording at least one of (a) user identification information, and (b) data identifying accessed medical device information in response to user access to said information about said medical device. 6. The information system of claim 1, comprising A repository that includes patient-specific information, where said device management processor uses said received data item and said patient-specific information in said repository for determining whether it is safe to use said medical device to deliver said therapy to said patient, and said device management processor receives a data item from said command processor in a message of a predetermined format having predetermined data fields, the device management processor determines whether it is safe to use the medical device to deliver the therapy to the patient based on the absence of required data in a predetermined data field of the pre-formatted message, and Said predetermined formatted messages having predetermined data fields comprise HealthLevel7 (HL7) compliant messages. 7. The information system of claim 1, wherein the facility management processor receives data items from the command processor, the data items comprising patient-specific healthcare-related information, and The device management processor uses the patient-specific healthcare-related information to determine whether it is safe to use the medical device to deliver the therapy to the patient. 8. An information system for managing the operation of medical equipment delivering treatment to a patient, the information system comprising: an authentication processor for receiving user identification information and determining that the user is authorized to access an application, and for prohibiting access to the application in response to the determination that the access is not authorized, the application being used to manage Specific medical equipment used to deliver treatment to patients; a device management processor, responsive to a user authorization determination, for receiving a data item in a message of a predetermined format having predetermined data fields, and for processing said data item in operation to manage said particular medical device, wherein , if the user is already registered, the device management processor associates the user with the medical device, and wherein, if the user is not registered, the device management processor is adapted to register the user ;as well as A communication interface that enables communication between the device management processor and the medical device. 9. The information system of claim 8, wherein The message includes a non-scanned fixed format barcode identifier and the data item includes: (a) Patient Identifier, (b) an identifier for identifying a physician's order associated with said particular medical device being used to deliver said therapy, and (c) Patient-Specific Condition-Related Information. 10. The information system of claim 8, comprising A repository that includes patient-specific information, where said device management processor uses said received data item and said patient-specific information in said repository to determine whether it is safe to use said medical device to deliver said therapy to said patient, wherein The repository includes at least one of: (a) drug information identifying characteristics of the drug delivered in the therapy, (b) operating characteristics of the infusion pump, (c) medical device location information, (d) Medical device IP or Ethernet compatible MAC address, (e) authorized user identification information, (f) infusion pump fluid delivery flow rate, and (g) infusion pump fluid volume delivered. 11. The information system of claim 8, wherein the device management processor determines whether it is safe to use the particular medical device to deliver the therapy to the patient based on the absence of required data in a predetermined data field of the predetermined format message, and the device management processor manages the operation of the particular medical device using medical device location information derived using a communication address of a tag attached to the medical device, and said tag includes a wireless identification device and said communication address includes an IP (Internet Protocol) or Ethernet MAC address, and The device management processor derives the medical device location information using a map that associates a plurality of medical device communication addresses with a corresponding plurality of medical device geographic locations. 12. The information system of claim 11 comprising an order processor for processing physician orders to initiate delivery of treatment to the patient, and wherein the device management processor for receiving data items receives the data items from the command processor, and The command processor initiates at least one of the following: (a) transmitting information related to the specific medical device to a pharmacy information system for restocking medication; (b) transmitting information related to the specific medical device transmitting information to a medication order information system for monitoring usage of the particular liquid medication; and (c) transmitting information related to the particular medical device to a patient management information system for monitoring usage of the medication by the patient. 13. An information system for managing the operation of medical equipment delivering treatment to a patient, the information system comprising: an authentication processor for receiving user identification information and for determining that the user is authorized to access an application program used to manage delivery of Specific medical equipment for treatment; a repository, which includes patient-specific information; a device management processor for receiving a data item in a message of a predetermined format having predetermined data fields in response to a user authorization determination, and for processing said data item in operation to manage said particular medical device, and for determining whether it is safe to use said medical device to deliver said therapy to said patient using said received data item and said patient-specific information in said repository, wherein, if said user is registered, the device management processor then associates the user with the medical device, and wherein, if the user is not registered, the device management processor is adapted to register the user; and A communication interface that enables communication between the device management processor and the medical device. 14. The information system of claim 13, wherein The message includes a non-scanned fixed format barcode identifier, and the data item includes a patient identifier, and the device management processor compares the patient specific information available in the repository with the patient in the repository. Patients with patient-specific information available in the repository make safety determinations differently. 15. The information system of claim 13, wherein (i) for a patient for whom no patient-specific information is available in said repository, necessary data is missing from a predetermined data field of a message according to said predetermined format, and (ii) for patients for whom patient-specific information is available in said repository, based on a comparison of data in a predetermined data field of said predetermined format message with data in said repository, the device management processor makes the security determination, and In response to the security determination, the device management processor initiates generation of an alert message to the user, the alert message alerting at least one of the following: (a) new user registration, (b) when more consecutive failed login attempts, (c) an inactive session for more than a predetermined duration, and (d) when a user attempts to access a resource for which it is not authorized. 16. The information system of claim 13, wherein said authentication processor maintains a record indicating the level at which a user is able to view the corresponding hierarchically organized information according to the user authorization level, and The data items include: (a) Patient Identifier, (b) an identifier for identifying a physician's order associated with said particular medical device used to deliver said therapy, and (c) Patient-Specific Condition-Related Information. 17. A method for managing the operation of a medical device delivering therapy to a patient comprising the following activities: process orders from physicians to initiate the delivery of treatment to patients; A data item is received from the physician order, the data item including at least one of: (a) a patient identifier, and (b) an identifier used to identify the physician's order; processing and using said data item in managing access to a medical device used to deliver said therapy to said patient; associating at least one registered user with said medical device; If the user is not registered, register said user; and Two-way communication is enabled with the medical device to convey information related to the physician's orders. 18. A method for managing the operation of a medical device delivering therapy to a patient comprising the following activities: receiving user identification information and determining that the user is authorized to access an application, the application being used to manage a particular medical device used to deliver therapy to a patient, and disabling said access in response to a determination that access is not authorized; associating the user with the particular medical device, if the user is already registered; if said user is not registered, register said user; receiving a data item in a message of a predetermined format having predetermined data fields in response to a user authorization determination, and for processing said data item in operation to manage said particular medical device; and Communication with said medical device is enabled to communicate at least one of said data items. 19. An information system for managing the operation of medical equipment delivering treatment to a patient, the information system comprising: an order processor for processing physician orders to initiate the delivery of treatment to the patient; device management processor for: receiving a data item from the command processor, the data item including at least one of the following: (a) patient identifier, and (b) a non-scanned fixed format barcode identifier identifying the physician order, and processing and using said data item in managing access to a medical device used to deliver said therapy to said patient; and a communication interface enabling bi-directional communication between the device management processor and the medical device. 20. A method for managing the operation of a medical device delivering therapy to a patient comprising the following activities: receiving user identification information and determining that the user is authorized to access an application, the application being used to manage a particular medical device used to deliver therapy to a patient, and disabling said access in response to a determination that access is not authorized; receiving a data item in a message of a predetermined format having predetermined data fields in response to a user authorization determination, and for processing said data item in operation to manage said particular medical device, said message including at least one non-scanned fixed formatted barcodes; and enabling communication with said medical device to transmit at least one of said data items.

Images