Patent Application
20050108057
A fixed-format transaction that contains information validated using a checksum and consistent with the use of a hand-held barcode scanner is sometimes used for delivering IV/epidural order information to an IV/epidural health information system and storing it. This approach is consistent with legacy systems using manually operated IV/epidural pumps. Known systems use either hand-held barcode readers or manually entered (i.e., keyed) information to the IV/epidural pump. A system according to invention principles addresses deficiencies of known systems.
An information system for managing operation of medical devices in delivering treatment to a patient, comprising: an order processor for processing a physician order for initiating providing a treatment to a patient; a device management processor for receiving data items from the order processor comprising at least one of, (a) a patient identifier and (b) an identifier for identifying the physician order, and for processing and using the data items in managing access to a medical device used for delivering the treatment to the patient; and a communication interface enabling bidirectional communication between the device management processor and the medical device.
The invention and its wide variety of embodiments are more readily understood through the following detailed description, with reference to the accompanying drawings in which:
When the following terms are used herein, the accompanying definitions apply:
absence—a lack of presence.
access—communicate with.
address—an identifier denoting location.
alert—a warning signal.
application—a program adapted to carry out a useful task.
authentication processor—a processor adapted to receive user identification information, determine if a user is authorized to access an application used in managing a particular device, and/or inhibit access to the device by the user in response to a determination that access by the user is unauthorized.
authorize—to grant authority, permission, or power to.
barcode—information expressible as a series of parallel bars of varying widths, in which each of the digits zero through nine are represented by a different pattern of bars that can be read by an optical scanner.
bidirectional—capable of communicating in opposing directions.
communication—an exchange of information.
communication interface—a 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. A communication interface enables communication between a device management processor and a device.
compatible—the ability of one device or program to work with another device or program.
configure to set up for a particular purpose.
data—numbers, characters, symbols etc., that are related to a subject.
deliver—give forth or produce.
device management processor—a processor adapted to receive data items for processing in managing operation of a device.
determine—ascertain, obtain, calculate, and/or provide.
duration—a period of time.
Ethernet—a type of networking technology.
fail—to be unsuccessful.
field—a logical storage space for a type of data. Fields can contain textual, numeric, date, graphical, audio, video, and/or calculated data. Any text field has properties comprising a fixed or variable length, a pre-defined display format, and/or relatability to another field.
fixed—a stable and/or unalterable form.
flow rate—an amount of liquid provided to a particular place within a stated time period.
fluid infusion pump—a device adapted to propel a liquid into a patient.
fluid medication—a substance, delivered in a liquid medium, that treats, prevents, and/or alleviates the symptoms of at least one medical condition.
fluid volume—an amount of space occupied by a liquid.
format—an arrangement and/or parameter of data relating to the packetizing, conveying, communicating, presenting display, and/or rendering of that data.
generate—an act of processing or producing.
geographic location—a position on the earth.
greater—larger and/or more than.
group—a number of individuals or things considered together because of similarities.
hierarchy—a series of ordered groupings of people or things within a system.
HealthLevel 7—a healthcare specific communication standard for data exchange between computer applications.
healthcare—the prevention, treatment, and/or management of illness and the preservation of mental and physical well being through the services offered by the medical and allied health professions.
identification device—a device adapted to provide and/or transmit information used to identify an entity. For example, an RFID is an embodiment of an identification device.
identifier—a group of symbols that are unique to a particular entity, activity, and/or document. An identifier can be, for example, a medical record number. An identifier can be human and/or machine readable, such as for example, a number, an alphanumeric string, a bar code, an RFID, etc.
identify—to establish an identity of.
inactive session—an idle connection between two information devices.
inhibit—prohibit and/or forbid.
initiate—begin.
information—data.
information device—any processing device (in 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, wearable computer, and/or Personal Digital Assistant (PDA), etc.
interrogate—ask.
IP (Internet Protocol)—a network protocol that specifies the format of packets, also called datagrams, and the addressing scheme for the packets. By itself, IP is a protocol for providing a message from a source to a network, but does not establish a direct link between the source and the destination. TCP/IP, on the other hand, can establish a connection between two communicators so that they can send messages back and forth for a period of time.
item—a single article or unit.
location—a place substantially approximating where something physically exists.
MAC (Media Access Control) address—an address for a device as it is identified at the Media Access Control layer in a network architecture.
machine-readable—of a form from which an information device can obtain data and/or information.
manage—direct and/or control.
map—a logical association of values of one variable with values of a different variable.
medical condition—a patient health status characterized by at least one symptom.
medical device—an apparatus adapted for diagnosing an illness and/or application of a medication.
medication—a substance adapted to relieve at least one symptom of and/or cure a medical condition.
medication order information—data related to the dispensing of medicine in a healthcare system.
member—an entity classified as being a part of a logical group.
message—a communication.
monitor—observe.
multiple login attempts—more than one try at authentication in a system with restricted access.
new user registration—an act of recording and/or documenting a first-time user.
non-scanned—not digitally encoded via an optical scanning device.
operation—a series of actions in performing a function.
operational characteristic—a feature associated with an operation.
order—(n.) an authoritative indication to be obeyed.
order—(v.) to issue an authoritative instruction.
order processor—a processor adapted to process an order for initiating management of an operation. For example, in medical device management systems, an order processor is adapted to initiate providing a treatment to a patient.
organized—ordered and/or arranged.
particular—specific.
patient—a human or other type of animal under supervision for health care purposes.
patient management information—data related to the care and/or medication of a patient.
patient monitoring device—an apparatus adapted to observe and/or sense information related to the well being of a patient.
patient specific—associated with and/or peculiar to a particular patient.
patient usage—an amount or amounts of substances administered to a patient.
perform—carry out.
permitted—allowed.
pharmacy information—data related to dispensing medications.
physician—a person licensed to practice medicine.
predetermined—established in advance.
processor—any device and/or set of machine-readable instructions adaptable to perform a specific task. A processor comprises any one or combination of hardware, firmware, and/or software adaptable to perform a specific task. A processor acts upon information by manipulating, analyzing, modifying, converting, transmitting the information to an information device, and/or routing the information to an output device.
provide—furnish or supply.
radio frequency identification (RFID)—a technology wherein electromagnetic or electrostatic coupling in the RF portion of the electromagnetic spectrum is typically used to transmit signals to automatically identify people or objects. There are several methods of identification, but the most common is to store a serial number that identifies a person or object, and perhaps other information, on a microchip that is attached to an antenna (the chip and the antenna together are called an RFID transponder or an RFID tag). The antenna enables the chip to transmit the identification information to a reader. The reader converts the radio waves reflected back from the RFID tag into digital information that can then be communicated with information devices.
record—a collection of data elements.
recording—an act of preserving information.
registered—formally recorded and/or accorded authority. For example, a registered user is identified and/or recorded by a medical device management system and is associated with, and accorded authority to use and/or control, a particular medical device.
repository—a device or database in which data is stored.
re-stocking—to replenish and/or replace a depleted inventory.
resource—something used for support or help.
required—necessary and/or essential.
safe—relatively free from risk or danger.
safety check—an inspection adapted to determine whether some thing or act meets a risk threshold.
safety determination—an evaluation adapted to determine whether some thing or act meets a risk threshold.
status information—data relating to a descriptive characteristic of a device and or system.
succession—consecutively arranged.
system—a collection of mechanisms, devices, and/or instructions, the collection performing one or more specific functions.
tag—an attachment adapted to identify, classify, and/or label, etc. For example, a tag is typically a radio frequency identification device (RFID).
test—evaluate.
tracking processor—a processor adapted to record identification information related to the use and/or control of a device.
treatment—administration or application of one or more remedies to a patient or for a disease or injury.
unauthorized—not endowed or provided with authority.
unregistered—not formally recorded and/or accorded authority.
user—a person interfacing with an information device.
ventilator—a respirator. A ventilator is used to assist patient breathing.
wireless—any data communication technique that utilizes electromagnetic waves emitted by an antenna to communicate data (i.e., via an unguided medium), including such data communication techniques 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 specifically excluding human voice radio transmissions, the data communication technique having a carrier frequency ranging from about 1 Hz to about 2×1014 Hz (about 200 teraHertz), including any values therebetween, such as for example, about 40 Hz, 6.010 kHz, 8.7 MHz, 4.518 GHz, 30 GHz, etc. and including any subranges therebetween, such as for example, from about 100 kHz to about 100 MHz, about 30 MHz to about 1 GHz, about 3 kHz to about 300 GHz, etc. Wireless communications can include analog and/or digital data, signals, and/or transmissions.
A physician generates an order verbally, in writing, by gesture, and/or via machine entry (e.g., such as via typing with a computer keyboard), and relevant information regarding the order can be generated, processed, and/or transmitted for manual and/or automatic implementation of at least a portion of the order. Initially and/or after processing, an order comprises information regarding the physician, the patient, the medication, the device for administering the medication, and/or the condition being treated, etc. Regarding the medication, the order typically indicates a generic type, a brand, compounding instructions, a dosage, a frequency of administration, a rate of administration, a route of administration, and/or other medication administration specifics, etc.
Server 1100 comprises an authentication processor 1130, an order processor 1140, a tracking processor 1150, a device management processor 1160, and/or a communications interface 1170. Authentication processor 1130 receives user identification information such as a username, password, pre-assigned moniker, social security number, barcode identifier, pass code, personal identification number, and/or biometric identifier, etc.
Biometrics is a technology that statistically analyzes and/or compares measured biological data, such as relatively unique physical characteristics, such as fingerprints. A digital system, such as medical device management system 1000 can utilize biometrics to identify and/or authenticate individuals. Biometric features used for identification and/or authentication comprise fingerprints; face, iris, and retina scanning; and/or voice identification; etc. Biometric devices typically include and/or utilize a scanning or reading device, software to convert the scanned information into a digital format, and/or a memory to store biometric information for comparison with stored records. The software identifies specific matched points of data that have been obtained from a scanning and/or reading device and compares them with stored data associated with individuals.
Authentication processor 1130 determines whether a user is a member of a predetermined group of authorized users permitted to access information related to, and/or an application used in managing, medical device 1400 and/or medical device 1500. Authentication processor 1130 inhibits access to information concerning, and/or an application used in managing, device 1400 and/or device 1500 in response to a determination that access is unauthorized. Authentication processor 1130 maintains a record indicating a hierarchy of users able to view corresponding hierarchically organized information based on user authorization level.
Order processor 1140 processes an order to initiate the provision of a treatment to a patient. The order comprises data items such as an originating physician, patient identifier (e.g., patient name, patient number and/or a social security number, etc.), an identifier for identifying the order (e.g., an order number, prescription number, physician number, and/or treatment number, etc.), patient specific healthcare related information (e.g., allergies, admission date, and/or procedure identifier, etc.), and/or information related to a patient specific medical condition (e.g., a diagnosis of hypertension), etc. Order processor 1140 performs activities comprising: initiating a communication of information associated with a particular medical device to a pharmacy information system for use in preparing and re-stocking medications, initiating a communication of information associated with the particular medical device to a medication order information system for use in monitoring usage of a particular medication, and/or initiating a communication of information associated with the particular medical device to a patient management information system for monitoring the patient's condition, etc.
Tracking processor 1150 is adapted to record information comprising user identification information, and/or an audit trail of user activity related to the medical device, etc. An audit trail records actions such as, for example, medical device information accessed, changes to medication, changes to a medication dosage, and/or changes to a ventilator volume, etc.
Device management processor 1160 receives data items from order processor 1140, processes the data items, and/or uses the data items to manage access to medical device 1400 and/or medical device 1500 as used for delivering a treatment to a patient. Data items comprise a physician identifier, patient identifier, user identifier, medical unit identifier, medical record number, prescription identifier, prescription dosage, medical pump flow rate, patient diagnosis, patient medical allergies, and/or procedure associated with a particular patient, etc. Device management processor 1160 receives data items from the order processor in a message of predetermined format having predetermined data fields (e.g., in the form of a formatted database record). The message of predetermined format comprises a HealthLevel 7 (HL7) compatible message. Managing access to medical device 1400 and/or medical device 1500 comprises managing access to information concerning each respective medical device.
Managing access to medical device 1400 and/or medical device 1500 occurs responsive to a determination that the user is authorized and/or registered. The determination that the user is authorized results from comparing an identifier associated with the user with a list of preauthorized users. The list of preauthorized users is typically associated with personnel records for a medical organization. Registered users are authorized users that have been granted particular rights and permissions in the management of device 1400 and/or medical device 1500. As an example, Nurse Jones is authorized to operate IV pumps on the west wing of floor 12 of a particular hospital, but not on the east wing or on other floors. Device management processor 1160 uses at least one data item in configuring the medical device for delivering the treatment to the patient. Actions of device management processor 1160 relative to medical device 1400 and/or medical device 1500 comprise interrogation for status information, performance and/or communications tests, determination of a location, determination that access, and/or performance of a safety check to determine whether it is safe to initiate the treatment, etc.
Server 1100 is communicatively coupled to a 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 comprises name, gender, identification number, birth date, next of kin, diagnosis, prescribed medications, and/or age, etc. Patient information comprises patient specific information, insurance provider information, insurance group code, physician, medical facility department by which the patient is being treated, available medications, and/or procedures to be performed, etc.
Device management processor 1160 uses data items and/or patient specific information for determining whether it is safe to use medical device 1400 and/or medical device 1500 for delivering the treatment to the patient. The determination of whether it is safe to use medical device 1400 and/or medical device 1500 for delivering the treatment to the patient is based on a presence or an absence of required data in a predetermined data field of the message. For example, treatment is not deemed safe in the absence of information comprising a physician identifier, prescription number, and/or patient number, etc. As another example, a prescribed drug treatment is deemed safe in the absence of data in a field for listing known drug allergies. Device management processor 1160 determines whether it is safe to use medical device 1400 and/or medical device 1500 in response to a user authorization determination. Device management processor 1160 makes the safety determination differently for a patient without patient specific information available in repository 1180 than for a patient having patient specific information available in repository 1180. For example, an outpatient is not approved for open-heart surgery, but an inpatient is approved. Device management processor 1160 makes a safety determination for a patient without patient specific information available in repository 1180, based on an absence of required data in a predetermined data field of the message. For example, giving a patient penicillin is determined as unsafe in the absence of an answer to a question asking whether the patient is known to have any allergies. Device management processor 1160 makes a safety determination for a patient having patient specific information available in repository 1180, based on comparing data in a predetermined data field of the message with data in repository 1180.
Responsive to the safety determination, device management processor 1160 initiates generation of an alert message for communication to an administrator. Alert messages comprise alerting of a new user registration, alerting when multiple login attempts fail in succession, alerting of an inactive session greater than a predetermined duration, and/or alerting when a user attempts to access an unauthorized resource, etc.
Device management processor 1160 manages operation of medical device 1400 and/or medical device 1500 using medical device location information derived using a communication address of a device, such as via a radio frequency identification (“RFID”) tag attached to medical device 1400 and/or medical device 1500.
The tag comprises a wireless identification device and a communication address comprising an IP (Internet Protocol) or Ethernet MAC address. Device management processor 1160 derives medical device location information using a map associating a communication address medical device 1400 and/or medical device 1500 with a corresponding medical device geographic location.
Communications interface 1170 enables bidirectional communications between device management processor 1160 and medical device 1400 and/or medical device 1500. Types of communications interface 1170 comprise serial, parallel, USB, Ethernet, token ring, and/or modem, etc.
Medical device management system 1000 comprises a network 1300. Network 1300 is adapted to communicatively couple information devices such as server 1100 and information device 1200. Architectures for network 1300 comprise a direct connection, local area network, wide area network such as the public switched telephone network, Internet, extranet, or any combination thereof. Types of network 1300 comprise a packet-switched, circuit-switched, connectionless, connection-oriented network, interconnected networks, or any combination thereof. Orientations of network 1300 comprise voice, data, or voice and data communications. Moreover, transmission media of network 1300 comprise wireline, satellite, wireless, or a combination thereof, etc.
Information device 1200 is adapted to receive information transmitted from sever 1100. Information device 1200 comprises components such as a user interface 1260, and a client program 1240. User interface 1260 is adapted to render information regarding medical device management to a user. Client program 1240 is adapted to accept information from the user related to medical device management.
Information device 1200 can be communicatively coupled to a repository 1280. Repository 1180 and/or repository 1280 are adapted to store information obtained from and/or provide information to information devices communicatively coupled to network 1300. Repository 1180 and/or repository 1280 are adapted to store information related to medical device management in a manner allowing the information to be accessible from devices communicatively coupled to network 1300.
Repository 1180 and/or repository 1280 are devices capable of storing analog or digital information, for example, a non-volatile memory, volatile memory, Random Access Memory, RAM, Read Only Memory, ROM, flash memory, magnetic media, a hard disk, a floppy disk, a magnetic tape, an optical media, an optical disk, a compact disk, a CD, a digital versatile disk, a DVD, and/or a raid array, etc. Repository 1180 and repository 1280 are adapted to store information related to medical device management. Formats to store information on repository 1180 and/or repository 1280 comprise database standards such as XML, Microsoft SQL, Microsoft Access, MySQL, Oracle, FileMaker, Sybase, and/or DB2, etc.
Information stored on repository 1180 and/or repository 1280 comprises at least one of patient specific information, medication information identifying characteristics of a medication being delivered in a treatment, operational characteristics of a fluid infusion pump, medical device location information, medical device IP or Ethernet compatible MAC address, authorized user identification information, infusion pump fluid delivery flow rate, and/or infusion pump fluid volume delivered, etc.
Device 1400 and/or device 1500 are used for delivering a treatment to a patient. Embodiments of device 1400 and/or device 1500 comprise medication delivery pumps, ventilators, temperature monitoring devices, blood pressure monitoring devices, and/or electrocardiograms, etc.
Medical device management system 1000 integrates a medical device management and order interface system, which expedites the process of entering patient information and order data related to medications. The medical device management and order interface system directly translates an order from a HealthLevel 7 (HL7) compatible or other data format, into a machine-readable barcode transaction, such as a non-scanned barcode formatted transaction. The non-scanned barcode formatted transaction is interpreted directly by medical device medical device 1400 and/or medical device 1500. Medical device management system 1000 comprises utilities for authentication, security, and reporting. Medical device management system 1000 controls and regulates a specific domain of users of medical devices based in a healthcare setting. Medical device management system 1000 allows registration of new users, automatic administrator notifications, alerts, and/or updates to a user log database. Authentication of medical device 1400 and/or medical device 1500 is facilitated by associating the specific device with a list of practitioners, such as nurses, who are allowed to manage medical device 1400 and/or medical device 1500. A browser-based architecture for medical device management system 1000 supports user mobility.
System features of medical device management system 1000 comprise: employment of a pluggable and customizable generic architecture; minimization of problems related to user mobility; a flexible Web Manager security architecture that allows for plugging in of new modules without changing the existing code base, for example: SSL support, GSM support, etc.; platform independence; a real-time graphical view of device information; and/or a dynamically updated operational dashboard providing insight into device operations. As used herein, the term “SSL” means Secure Socket Layer, a protocol used to provide encrypted communications on the Internet. As used herein, the term “Global Session Manager, or GSM means a software module used for authentication and authorization.
Medical device management system 1000 provides authentication, security, and reporting sub-systems, which control and regulate device users in a healthcare setting. Medical device management system 1000 utilizes software for controlling medical device 1400 and/or medical device 1500, either of which can include one or more IV and/or epidural pumps. Medical device management system 1000 establishes a security mechanism for regulating access to medical device 1400 and/or medical device 1500 by authorized users and refusing access to unauthorized users.
Via system 1000, an originator of an order can send the order, such as for a medical device, directly to a database engine, related to medical device 1400 and/or medical device 1500, using an interface engine. The database engine: stores this transaction, processes the order, checks for validity of information comprised in the order, stores relevant information in a database, and/or sends the order to medical device 1400 and/or medical device 1500, etc. There is not necessarily a need to generate a barcode for each patient, to optically scan the barcode, or to manually enter demographics or orders at locations such as the pharmacy and/or the medication pump. Medical device management system 1000 automates the process of translating order transactions into fixed-format transactions stored within the database for delivery to the pharmacy, medical device 1400, and/or medical device 1500.
Medical device management system 1000 provides user interface 1110 and a method for processing orders received from a standard medication administration system and translates these into HL7 version V2.4, and/or HL7 version V2.5 orders that can be directed to manage and/or control medical device 1400 and/or medical device 1500.
Medical device management system 1000: communicates via either raw socket connectivity or via a data exchange application; validates transactional content; directs storage of order data items within a pre-defined SQL Server database, such as a database residing in repository 1180; and/or validates the content of the transaction by confirming that each transaction contains valid patient, dosage, and network connectivity between the database and a medical device; etc. In addition, medical device management system 1000 accurately performs error checking and/or correction, such as computing checksum information, to confirm that data have not been corrupted in the process of delivery to the database and/or medical device.
Table I comprises 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 involves minimizing response times for a given transaction load. As used herein, the term “Apache Tomcat” refers to a Servlet container that is used in a reference implementation for Java Servlet and JSP technologies. Tomcat is an open source implementation that is used as a Web server. Tomcat runs Servlets and JavaServer Pages (JSP) in Web applications. The Apache Foundation is community of open-source software projects headquartered in Forest Hill, Md. As used herein, the term “Apache Jmeter” refers to a Java application that load tests functional behavior and measures performance
While a number of factors can affect performance, adding additional resources in the following two ways, or a combination of both, can be used to good effect:
At activity 2200, user authorization is determined. Once authorization is determined, the user is authorized to access an application used in managing a particular medical device used for delivering a treatment to a patient. Access is inhibited in response to a determination access is unauthorized. A user is also registered and/or associated with the particular medical device in order to access the application used in managing the particular medical device. For example,
At activity 2300, data items, such as from an order from a physician, are received. The data items comprise a patient identifier and/or an identifier for identifying the order. The data items are in a message of predetermined format having predetermined data fields. For example, data items from the order comprise predetermined information such as patient name, prescription number, medication identification, and/or medication dosage, etc. Each data item is provided in a predetermined format.
At activity 2400, the data items are processed. Treatment is initiated responsive to processing the data items, such as via activation and control of a pump delivering medication to the patient. Processed information provides information such as medication and/or dosage rate usable for controlling the particular medical device, such as an intravenous (IV) and/or epidural pump.
At activity 2500, communications with the device are enabled. Communications with the device is bidirectional and responsive to both user identification and data items received and/or processed. The communication can comprise at least one data item and/or information related to the order. For example,
Information device 3600 provides a user, such as a nurse, with software and a user interface for managing IV/epidural pump 3950 and/or IV/epidural pump 3975. Via information device 3600, the user receives information such as patient ID, medication type, medication dosage, medical device identification and/or patient condition, etc. The user causes medications and equipment to be properly placed for fulfillment of orders. Data items related to orders are transferred to server 3900. Server 3900 causes data item storage in a database residing on repository 3800 in any one of a plurality of database storage standards. Server 3900 provides control and/or dosage information to IV/epidural pump 3950 and/or IV/epidural pump 3975. IV/epidural pump 3950 and/or IV/epidural pump 3975 deliver ordered medications to patients.
Factors considered in providing system configurations comprise size and capacity of available systems and the characteristics of web applications. Depending on the number of database reads/updates etc, it makes sense to isolate the database server to give it a maximum amount of power.
Software managing the medical device is configurable as a three-tiered web application that resides on a web application server and interacts 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, data architecture can be based around a SQL Server database engine. Clients are web pages generated as JSP pages deployed in Apache Tomcat, a JSP/Servlet engine. As used herein, the term “Java” means a programming language developed by Sun Microsystems, Santa Clara, Calif. As used herein the term “JSP” means Java server pages, which are web pages developed via a 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 for streamlining workflow for the device user (e.g., a nurse having to be tied down to any one physical location in the hospital). The user is able to obtain near real-time updates of device status using graphical tools comprised in the device management software.
The device management software is a multi-tier application that uses a web container but may include EJB/application level containers like JBOSS or functionally equivalent containers. As used herein, the term “EJB” means enterprise Java bean, which is a server-side component architecture for writing reusable business logic and portable enterprise applications. As used herein, the term “JBOSS” means an application server written in Java that can host business components developed in Java. A pluggable architecture has been found to be suitable for administering user level access to the management of IV and/or epidural pumps.
Constraints for implementing device management software comprise support and implementation flexibility; modularity of software (e.g., partitioning presentation and business layers); open architecture capability for handling legacy data sources; platform portability of middleware and software leading to open interfaces, independent at the web container level; and/or cost considerations; etc.
A Java platform supports five enumerated constraints as follows:
JSP pages allow web developers to create content-rich, dynamic pages rapidly and easily. JSP uses XML-like tags to encapsulate logic generating web pages. JSP pages separate page logic from conception and display, which prevents the overlapping of roles between web creators and programmers. As used herein the term “XML” means eXtensible Markup Language, which is a language for software coding primarily used in the development of web pages;
Model-View-Controller (“MVC”) is Java blueprint's recommended architectural pattern for interactive applications. MVC organizes an interactive application into three separate modules: one for the application model with its data representation and business logic, the second for views that provide data presentation and user input, and the third for a controller to dispatch requests and control flow. A medical device management software application framework uses a variation of the MVC pattern. This architecture is applied to solve specific problems associated with IV and/or epidural pump administration by nurses.
Orders related to patient and demographic data are sent from a health information system or a medication administration check to a medication administration order interface transaction system (MAOIT) retrieve transaction sub function via an interface engine that supports data translation, interpretation, and communication among separate and independent software functionality. An interface engine, called “OPENLink.” OPENLink is a system that bidirectionally exchanges data between two different computer systems using compatible or incompatible data communication formats and protocols. Third-party examples of such interface engines are available as well. The use of “OPENLink” in the text is only as an exemplar. Once received demographics data are translated into an equivalent barcode (with a commensurate checksum) and sent to a database manager where the data are stored. Data validity is then checked. If demographics data are valid, patient name and identifiers are recorded in the database.
An IV Pump application composes an acknowledgment message and sends through “OPENLink” to an originating system. Two “OPENLink” interfaces are comprised in the medical device management system: one for outbound vitals transactions, and another for inbound pump medication interactions. The inbound transaction is delivered to the MAOIT application. The outbound transaction is sent from a database application to a health information system, medication administration check, and/or pharmacy.
The medical device management system maintains a work and communication flow from an original order to the actual device itself. There is no need for manual maintenance and providing barcodes or scanning their information.
Automatic alerts are sent to the administrator in the event of any significant events in the system.
JavaScript is typically used in this page to ensure the user submits required 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.
User interface 15000 provides real-time information on “vital statistics” on selected devices and allows administrators to set a validation time and update rate settings, etc. This reporting mechanism has generic applications in healthcare settings and specific application for IV Epidural Pumps.
A pump manager's web tier serves HTTP requests. The web tier does four basic things in a specific order: interprets client requests; dispatches those requests to business logic; selects the next view for display; and generates and delivers the next view.
Certain implementations use the following three levels of security for any user logging in via the Internet: secure sockets layer support; VPN/corporate firewall access; and form based login and password based authentication. As used herein, the term “VPN” means virtual private network, which is a network that is constructed by using public wires to connect nodes. Communications on a VPN are typically encapsulated in a manner so as not to be readable by unintended recipients thereof. The first two are provided by any corporate entity/hospital. The pump manager provides the last and its generic architecture also enables easy integration this with the following levels of security: Microsoft LDAP (the Windows standard for directory enabled networking); Global Session Manager, or GSM (used for authentication and authorization); Sun Java JNDI (Java Native Directory Interface); XML file based authentication (used for security attributes by most commercial application server implementations); and/or biometric (e.g., fingerprints, voice patterns, or DNA); etc.
Other authentication mechanisms can combine these; an example is digital certificates, where key-based (e.g., user name and password, etc.) and knowledge-based (e.g., SSL, etc.) authentication is exercised.
If demographics data are valid, patient name and identifiers are recorded in the database. IV pump system software applications compose an acknowledgment message and send the message through OPENLink to an originating system.
Flow diagram 22000 comprises two OPENLink interfaces: one for an outbound interaction and one for an inbound interaction. The inbound interaction sends information to a pump application. Outbound interaction sends information from the pump application.
Transactions processed via process diagram 24000 as a valid demographics event need to be in an HL7 standard format with required fields filled out. A method for controlling duplication is incorporated in the application. A duplication method prevents duplicate information from being entered to the database.
Transactions processed via process diagram 24000 as valid orders are in an HL7 format that follows ORC syntax. The Common Order segment (ORC) is used to transmit fields that are common to orders (types of services that are requested). The ORC syntax is a standard syntax employed within HL7 orders (inclusive of Pharmacy, Dietary, for example). Demographic information (such as patient name, patient ID etc.) is stored in a database in order to be used as a validation mechanism. For example, an order to a specific patient that is associated with a specific pump cannot be transmitted to a different pump.
The drug table comprises a drug name, drug identifier, patient identifier, volume delivered, units for delivered volumes, operating time, operating time units, remaining time for a particular medication administration, units of remaining time, flowrate, and/or units of flowrate, etc. The user login table comprises a nurse identifier, password, user level, first name, middle name, last name, e-mail address, and/or location, etc. The location table comprises an IV pump identifier, bed label, and/or patient identifier, etc. The time table comprises a date, current time, current time units, time zone, time zone units, operating time, operating time units, remaining time, remaining time units, update rate, and/or update rate units, etc.
Table II provides detail of a database schema for a medical device management system. Records for the database schema comprise:
Each table comprises more than one field. Fields within records, as indicated in Table II, are prenamed and predefined. Fields have a predetermined format. Fields are used to accept, store, transfer, and/or render data.
Using Tomcat, a medical device web application is built, packaged, and/or deployed. Deployment steps comprise creating the web application directory structure, creating a web application ServletContext, adding JSPs and Servlets, adding tag libraries, and/or creating and deploying a WAR file, etc. These steps are easily extensible to any medical device application that follows the architecture of the medical device management system.
Table III illustrates a web application directory structure for a medical device management system. The directory structure comprises a plurality of directories and subdirectories for storing web pages, web page resources, utilities, and/or archive files, etc.
To add a new ServletContext to Tomcat an entry is added to a file such as a TOMCAT_HOME/conf/server.xml file, setting the values for the path and docBase to the name of the web application, such as an IVPump application. The entry is thus: <Context path=“/IVPump” docBase=“IVPump” debug=“0” reloadable=“true”/>.
The first, path=“/IVPump”, tells the Servlet container that requests with /IVPump appended to the server's URL belong to the IVPump web application. The second, docBase=“IVPump”, tells the Servlet container that the web application exists in the/IVPump directory.
Steps for adding Servlets and JSPs comprise placing JSP pages directly under a WEB-INF folder, compiling Servlets, and/or moving Servlets into a directory such as the /IVPump/WEB-INF/classes/com/IVPump directory, etc.
Software used in running the medical device application comprises: a JSP/Servlet implementation can be run as a standalone or as an extension to a web server (in a test embodiment, Tomcat 4.0.3 was used since the standard Tomcat tag libraries are used extensively, the application is in some way tied to Tomcat); an SMTP mail server, this is optional but since the application usually uses a corporate intranet, it is reasonable to expect this; Microsoft SQL Server is recommended as a relational database management system (other embodiments of the medical device manager can use MySQL as a database engine); and/or Apache Jmeter has been used to load test the application; etc.
As used herein “JSTL” means, JavaServer Pages Standard Tag Library, which encapsulates as simple tags core functionalities common to many Web applications. JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags. JSTL also provides a framework for integrating existing custom tags with JSTL tags. As used herein, the term “Jakarta Struts” means an open source framework for building Java web applications. The Struts framework comprises a control layer based on technologies like Java Servlets, JavaBeans, ResourceBundles, and XML.
A clinical context object workgroup (“CCOW”) is a standard that specifies architectures, component interfaces, and data definitions as well as interoperable technology-specific mappings of these architectures, interfaces, and definitions. Using CCOW, multiple applications can be automatically coordinated and synchronized at a point-of-use. Specified architectures establish a basis for bringing interoperability among healthcare applications to a point-of-use. A JBOSS application server is a Java 2 Enterprise Edition application server with EJB support.
Considerations in creating a system comprise: providing a registration module (such a's a Web application) comprising a user interface (such as a user interface that uses XML messaging, rather than an HTML Web browser); using JSTL instead of Java Beans can be a performance bottleneck in the event of multiple users logging in at the same time; a MVC framework like Jakarta Struts; integrating with GSM, or, CCOW; and/or an Open Source EJB container like a Jboss Application server, or an HIS Application Server along with Apache Tomcat at the web layer; etc.
Table IV illustrates a total IV pump inventory and associates specific infusion pumps with particular room locations and patient identifiers (PID/MRN=patient identification/medical record number) within specific units in the enterprise. The information carried by the RFID tag (patient identifier and local pump internet protocol address, for instance) uniquely defines the pump association with a particular patient. Thus, a pump can be located quickly by way of such a view. This view can be generated quickly via scripts and displayed within a Web browser.
The medical device system information provides feedback to a pharmacy entity on the location of monitored devices within the enterprise and/or the proximity of a particular pump to the pharmacy entity. For example, as patients arrive or leave, are administered intravenous fluids on pumps, and/or removed from pumps; a rendered user interface is updated.
Information regarding unassigned medical devices allows a clinician ordering drips for a patient to determine a quantity of pumps available for use, and those that are active within an enterprise. Information regarding unassigned medical devices also provides useful information for managing maintenance on previously active pumps to prepare those pumps for use on future patients.
When an order is placed for an application using a medical device, a particular medical device can be assigned with the order (e.g., a pump identifier is carried with the electronic order). The medical device is associated with a patient and is managed by at least one clinician. An identifier, such as a unique serial identification associated with that medical device, is communicable via a wireless network adapter then provides a way to manage and know both the location of the medical device and the patient; the location of a particular patient with respect to an assigned medical device; whether that medical device is experiencing malfunction (moved to maintenance) or whether administered medication is running low; and/or whether the medical device is in need of general maintenance.
Orders assigned to a particular medical device have location and identifiers associated with them so that the pharmacy can ascertain without ambiguity the location and patient assigned to any pump.
Therefore, using an RFID tag in cooperation with a Web manager (application different from medical devices) has benefits from the perspective of being able to locate inventories of surgical trays, such as surgical tray 35000; having specific information as to the whereabouts of a particular tray, such as surgical tray 35000; and/or having specific information as to the location of a patient upon which surgery is to be performed; etc. In this way, a surgical order specifies the need for a particular type of surgical tray 35000 together with the time and operating theatre into which surgical tray 35000 should be delivered. Thus, surgical tray 35000 can be delivered to the operating theatre and segregated offline before patient surgery so that they are not misappropriated or valuable time is not wasted in the process of attempting to locate surgical tray 35000. The RFID tag is typically applied directly to the surgical tray 35000 (the underside, for instance).
Radio frequency identification tags (RFIDs), implemented as both passive and active types, retain specific information regarding their associated objects (specifically, identifiers of devices, patients, etc.). Passive RFID tags do not have their own power supply: the minute electrical current induced in an RFID antenna by the incoming radio-frequency scan provides enough power for the tag to send a response. Due to power and cost concerns, a response of a passive RFID tag is necessarily brief, typically just an ID number (GUID). Active RFID tags comprise a power source, and may have longer ranges and larger memories than passive tags, as well as an ability to store additional information sent by a transceiver.
Attaching RFID tags allows devices (infusion pumps, patient monitors, etc.) to be managed and tracked. For example, the following table illustrates a view that can be managed through a medical device (such as an IV pump) Web manager interface that shows the quantity of medical devices in use in specific units and rooms within an enterprise.
A mechanical ventilator for respiratory support is often employed within intensive care units. Mechanical ventilation is normally ordered for patients who cannot sustain spontaneous respiration and therefore require assistance in breathing. Many types of patients require assistance in this manner, one type being a coronary bypass-grafting patient. The use of the mechanical ventilator requires that a physician order its use for a particular patient. These orders translate into locating a mechanical ventilator within the room of a patient, sometimes in preparation for patient arrival. Locating mechanical ventilators for use within an enterprise can benefit from the use of RFID tags in concert with a management system for associating the location of the mechanical ventilator with a particular patient. The RFID tag can be attached directly to the ventilator's exterior. Once programmed with a unique identifier (the serial number of the ventilator, for instance) the data can be transmitted to the Web-based application (transaction manager) and associated with a particular patient. In this way, the medical device management system: tracks the location of the ventilator; associates ordered changes on a particular patient (identified by patient medical record number or external identifier) positively with a particular ventilator; maintains an audit trail within the patient's clinical record as to which specific ventilator was employed during therapy (for the purpose of quality control and for legal reasons should a patient experience complications post-extubation); and/or to verifies the settings of the mechanical ventilator with the physician order by way of validating the specific ventilator settings available through a care system with the patient identifier, and then associating the identifier with the mechanical ventilator, etc. An auditing trail can be used also for quality control to ensure that a physician's orders were carried out on a specific ventilator at a specific time (feedback on a clinical order).
A prescription 37100 arrives at a pharmacy where a pharmacist, as illustrated at 37200, processes prescription 37100 and prepares drugs and intravenous medications to be delivered to the patient via an IV pump 37900.
Medications and intravenous fluid bags are tagged by the pharmacist at 37200 with patient, ordering clinician, and drug identifying information. This information is stored in the form of barcode labels and/or RFID tags created by pharmacy processing software.
During the prescription fulfillment process, the pharmacist transmits identifying information to a point of care using (in one embodiment), at 37300, an order entry user interface that can receive: data provided manually by the pharmacist, data provided via a network in a non-scanned barcode format, and/or data provided via a barcode scanner (at 37225) and/or radio frequency tag reader (at 37250).
Medication, patient, and device identifying information are stored within order tables of an IV pump manager database at 37400.
At 37600, IV pump manager order processor, directed and monitored by IV pump manager process manager 37500, continuously polls and retrieves new order information from order tables 37400.
Queuing processor 37700 receives new orders from order processor 37600 and extracts from orders specific patient and IV pump identifying information. Process manager 37500 continuously updates the queuing processor 37700 as to individual IV pump profile changes (i.e., changes in alert status, pump polling attempts, valid pumps, etc.)
Queuing processor 37700 communicates an appropriately formatted message to communications processor 37800, which attempts to transmit a message to a patient-specific IV pump 37900.
Communications processor 37800 communicates with IV pump 37900 using standard network protocols (typically wired or wireless communication via TCP/IP protocol transmission).
Communications processor 37800 notifies queuing processor 37700 in the event that (i) network communication cannot be established with IV pump 37900, (ii) IV pump 37900 is not responding to a properly formatted transmission, (iii) IV pump 37900 is not in the correct state to receive a transmission, and/or, (iv) IV 37900 pump has acknowledged receipt of the transmission.
Upon receipt of one of these messages, queuing processor 37700 communicates with the process manager 37500, informing it of either successful or unsuccessful transmission, and as to the reason in the case of unsuccessful transmission. Process manager 37500 provides a notification message that is made available to the pharmacist and the clinician. Process manager 37500 communicates this notification message through order processor 37600 to order tables 37400.
Once the notification message is stored within order tables 37400, the notification message is available for transmission to any number of recipients. One embodiment of this notification is through an order status user interface 37950 that provides a tabular status of every order, when the order was transmitted, when the order was accepted by IV pump 37900, and whether the order has been executed at the point of care (i.e., a clinician has confirmed acceptance of the order).
Queuing processor 37700 maintains a list of common orders to pumps and attempts in round-robin fashion to re-transmit orders to pumps for which previous attempts have been unsuccessful. The total number of attempts and the duration over which queuing processor 37700 attempts re-transmissions are dictated by a profile managed by process manager 37500.
Queuing processor 37700 can assist with the logistics of transmitting a fulfilled order from a pharmacy to IV pump 37900 at the point of care. Physically, a pharmacist and a particular IV pump are not likely to be co-located. Queuing processor 37400 eliminates a need for a clinician and a pharmacist to coordinate transmission of an order to the point of care at the same time. The queuing processor 37700 provides both the pharmacist and the clinician with the flexibility to act and respond asynchronously to a transmitted order, without risking the loss of information or requiring a pharmacist to manually re-transmit the order to the bedside. Instead, the pharmacist transmits the order and the fulfillment of that order occurs later (within clinically acceptable time limits) to allow for clinician notification of the transmission and relocation to the bedside. Queuing processor 37700 “waits” for the clinician and allows the clinician to reach the appropriate IV pump so that the pump can be directed to receive the in-bound order.
Still other embodiments are readily apparent to those skilled in this art from reading the above-recited detailed description and drawings of certain exemplary embodiments.
This application claims priority to pending provisional application Ser. No. 60/505,503 (Applicant Docket No. 03P14624US), filed 24 Sep., 2003.
| Number | Date | Country | |
|---|---|---|---|
| 60505503 | Sep 2003 | US |
