Patent Application
20110077965
In a healthcare environment, various sources capture, communicate, and store information, such as monitored values of a patient, locations of a person or a device, equipment utilization, etc. Exemplary sources of information include medical devices that monitor patients, real-time locator systems, nurse-call systems, patient-bedside systems, communication systems (e.g., in-house phone, mobile device, pager, etc.), and a healthcare information system. These various sources are typically not integrated with one another in a manner that allows information from one source to be combined with information of other sources. Integrating these sources into a single solution would enable a more efficient combination and use of captured information.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. The present invention is defined by the claims.
The present invention is directed to providing event information that is received from various sources in a healthcare environment. In an exemplary embodiment, the information that is received from the various sources is converted to a standardized format. Once converted to a standardized format, the information is filtered according to various criteria (e.g., source device, recipient component, event type, source location, etc.) and stored. After filtering, the information is compared to a rules engine to determine whether additional processing and/or routing is appropriate.
In another exemplary embodiment of the present invention a first event indication, which describes an alarm-triggering event, is received from a medical device. A rules engine is referenced to determine that when the medical device detects the alarm-triggering event a notification is to be provided to a notification recipient. A patient-to-device data store is referenced to receive a patient identifier, which identifies a patient that is associated with the medical device. The patient identifier is used to retrieve patient-specific information, and the recipient is provided with the notification, which indicates both the event and the patient-specific information.
In another embodiment, a method of providing event information includes receiving from a medical device a first event indication, which indicates an instant in time at which an active state of the medical device begins. A second event indication, which indicates a subsequent instant in time at which the medical device changes from the active state to an inactive state, is received from the medical device. An active-state-duration value is stored that quantifies a duration of the active state between the instant in time and the subsequent instant in time. Based on the active-state-duration value and other active-state-duration values, it is determined that the medical device should receive a type of maintenance. A notification is provided indicating that the medical device should receive the type of maintenance.
In a further embodiment, a method of providing event information includes receiving event indications from a plurality of event-detecting applications. Each event indication includes respective event information that is organized in a respective indication format. Each respective indication format is both dependent upon a respective event-detecting application and distinct from other respective indication formats. The respective event information of each event indication is transformed to include a standard indication format and stored in an event data store. Upon receiving an event-indication sorting criterion that is usable to isolate a portion of the event indications, the portion is presented.
Embodiments are described in detail below with reference to the attached drawing figures, wherein:
The subject matter of the present invention is described with specificity herein to meet statutory requirements. However, the description itself is not intended to limit the scope of this patent. Rather, the inventors have contemplated that the claimed subject matter might also be embodied in other ways, to include different steps or combinations of steps similar to the ones described in this document, in conjunction with other present or future technologies. Moreover, although the terms “step” and/or “block” might be used herein to connote different elements of methods employed, the terms should not be interpreted as implying any particular order among or between various steps herein disclosed unless and except when the order of individual steps is explicitly stated.
An embodiment of the present invention is directed to providing event information that is received from various sources in a healthcare environment. In an exemplary embodiment, the information that is received from the various sources is converted to a standardized format. Once converted to a standardized format, the information is filtered according to various criteria (e.g., source device, recipient component, event type, source location, etc.). After filtering, the information is compared to a rules engine to determine whether additional processing and/or routing is appropriate. Additional processing might include using the information to generate a notification and a report.
Having briefly described embodiments of the present invention, an exemplary operating environment suitable for use in implementing embodiments of the present invention is described below. Referring to
The present invention might be operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and/or configurations that might be suitable for use with the present invention include personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above-mentioned systems or devices, and the like.
The present invention might be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Exemplary program modules include routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. The present invention might be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules might be located in association with local and/or remote computer storage media (e.g., memory storage devices).
With continued reference to
The control server 22 typically includes therein, or has access to, a variety of computer-readable media, for instance, database cluster 24. Computer-readable media can be any available media that might be accessed by server 22, and includes volatile and nonvolatile media, as well as, removable and nonremovable media. Computer-readable media might include computer storage media. Computer storage media includes volatile and nonvolatile media, as well as, removable and nonremovable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. In this regard, computer storage media might include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVDs) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other magnetic storage device, or any other medium which can be used to store the desired information and which may be accessed by the control server 22. Combinations of any of the above also may be included within the scope of computer-readable media.
The computer storage media discussed above and illustrated in
The control server 22 might operate in a computer network 26 using logical connections to one or more remote computers 28. Remote computers 28 might be located at a variety of locations in a medical or research environment, including clinical laboratories (e.g., molecular diagnostic laboratories), hospitals and other inpatient settings, veterinary environments, ambulatory settings, medical billing and financial offices, hospital administration settings, home healthcare environments, and clinicians' offices. Clinicians might include a treating physician or physicians; specialists such as surgeons, radiologists, cardiologists, and oncologists; emergency medical technicians; physicians' assistants; nurse practitioners; nurses; nurses' aides; pharmacists; dieticians; microbiologists; laboratory experts; laboratory technologists; genetic counselors; researchers; veterinarians; students; and the like. The remote computers 28 might also be physically located in nontraditional medical care environments so that the entire healthcare community might be capable of integration on the network. The remote computers 28 might be personal computers, servers, routers, network PCs, peer devices, other common network nodes, or the like and might include some or all of the elements described above in relation to the control server 22. The devices can be personal digital assistants or other like devices.
Exemplary computer networks 26 include local area networks (LANs) and/or wide area networks (WANs). Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and the Internet. When utilized in a WAN networking environment, the control server 22 might include a modem or other means for establishing communications over the WAN, such as the Internet. In a networked environment, program modules or portions thereof might be stored in association with the control server 22, the database cluster 24, or any of the remote computers 28. For example, various application programs may reside on the memory associated with any one or more of the remote computers 28. It will be appreciated by those of ordinary skill in the art that the network connections shown are exemplary and other means of establishing a communications link between the computers (e.g., control server 22 and remote computers 28) might be utilized.
In operation, a clinician might enter commands and information into the control server 22 or convey the commands and information to the control server 22 via one or more of the remote computers 28 through input devices, such as a keyboard, a pointing device (commonly referred to as a mouse), a trackball, or a touch pad. Other input devices include microphones, satellite dishes, scanners, or the like. Commands and information might also be sent directly from a remote healthcare device to the control server 22. In addition to a monitor, the control server 22 and/or remote computers 28 might include other peripheral output devices, such as speakers and a printer.
Although many other internal components of the control server 22 and the remote computers 28 are not shown, those of ordinary skill in the art will appreciate that such components and their interconnection are well known. Accordingly, additional details concerning the internal construction of the control server 22 and the remote computers 28 are not further disclosed herein.
Turning now to
In an embodiment of the present invention, device/person locator 210 includes a device that is used to locate a person and/or a device. For example, device/person locator 210 might include a scanner configured to recognize a barcode on a medical device. Alternatively, device/person locator 210 might be configured to recognize a tagged item, such as an identification badge or other transmitter, when the tagged item passes a scanning device. In an embodiment of the present invention, once device/person locator 210 detects a location of a device or person, that information is communicated to other components (e.g., bus 216) of operating environment 200, as will be further discussed below. Moreover, device/locator 210 might also receive information from other components, as will also be described below.
In another embodiment of the present invention, medical devices 212 and 214 include devices that are used to monitor and/or administer care to a patient in a healthcare setting. For example, medical devices 212 and 214 might include monitors, infusion pumps, cardiac ventilators, balloon pumps, patient beds, sequential-compression devices, electronic security devices, and vital-sign detecting devices. Medical devices 212 and 214 generate various data (e.g., measured heart rate) that, as described in more detail below, is communicated to other components (e.g., bus 216) of operating environment 200. Moreover, medical devices 212 and 214 might also receive information from components of operating environment 200.
In a further embodiment of the present invention, healthcare information system 228 includes an integrated system of healthcare-related information that is usable by a healthcare facility to operate and provide patient care. For example, healthcare information system 228 includes an electronic medical record 229 (also referred to herein as “EMR”), a point-of-care solutions component 290, and a workload/resources management component 270. EMR 229 includes an electronic version of patient records, such as examination reports, testing and lab results, medical history, etc. Point-of-care solutions component 290 includes information that is provided at a patient's point-of-care (e.g., patient bedside) to assist healthcare professionals to provide appropriate care. Workload/resources management component 270 includes information that evaluates past and current use of personnel and resources and suggests a future allocation thereof. In an embodiment of the present invention, healthcare information system 228 receives information from other components, as will be described in more detail below. Moreover, healthcare information system 228 might also generate information that is communicated to other components of operating environment 200.
In a further embodiment of the present invention, communication devices 226 include devices that are used within a healthcare facility to receive and send information. Communication devices 226 also facilitate requests to receive additional information. Exemplary communication devices 226 include personal communication devices 246, a workstation 234, patient bedside devices 260, nurse call 262, an intercom system 264, and an email system 266. Personal communication devices 246 include devices that are used by an individual to receive and send information, such as an in-house phone, a pager, and a mobile device. Workstation 234 includes a remote computer terminal that is used to present information to a user and receive input. Workstation 234 might be set up at a nurse's station to or at a patient bedside. Patient bedside 260 includes a communication device that presents information to and receives information that is input by a patient. For example, a patient bedside 260 communication device might present learning modules to a patient and/or receive a patient's electronic signature on a consent form. Nurse call 262 includes communication devices that present information to and receive information from a nurse (or other healthcare professional), such as in a patient's room. Intercom 262 includes communication devices that receive and announce information, such as using speakers. Email 266 might be implemented using one or more of the other communication devices 226 (e.g., personal communication device 246, workstation 234, and patient bedside 260) to send and receive messages (e.g., email messages, SMS messages, etc.) to various users. Accordingly, in an embodiment of the present invention, communication devices 226 present to users information that is received from other components of operating environment 200. For example, personal communication device 246 might display, or intercom 264 might announce, information from medical device 220. Moreover, communication devices 226 might also generate information (e.g., code-blue alert) that is communicated to other components of operating environment 200. Communication devices 226 also communicate to other components of operating environment 200 requests to receive additional information. For example, personal communication device 246 might communicate a request of a physician to receive information from EMR 229.
As previously indicated, and as depicted in
In an embodiment of the present invention, event-information handler 224 communicates with bus 216 and functions to consolidate and manage information received from the various components of operating environment 200. In a further embodiment, instead of components communicating directly with one another, information is routed through and normalized by event-information handler 224. Event-information handler 224 allows for consolidation and communication of information from various sources, which are not easily integrated or combinable by direct communication. For example, event-information handler 224 allows for information from medical devices 212 and 214 to be packaged with information from healthcare information system 228 in order to generate and communicate a more information-rich notification to a notification recipient (e.g., personal communication device 246). Moreover, a set of normalized information is more easily sorted and reported than a set of information that organized in alternative formats of various information sources.
In a further embodiment, event-information handler 224 includes various components that exchange information with one another, such as an event receiver 230, a patient-information retriever 249, a notifier 243, a reporter 274, an event sorter 272, a device-to-location datastore 238, a patient-to-device datastore 240, a rules database 242, and an events database 232. As discussed in more detail below, an event receiver 230 might receive and process event indications (e.g., data 218, 220, and 222), which are then stored in events database 232. Patient-info retriever 249 functions to retrieve patient information from datastores, such as from patient-to-device datastore 240 and a patient EMR 229. Notifier 243 functions to compose and send notifications to notification recipients, such as communication devices 226. Exemplary notifications are depicted in
Management and communication of information between the various components of operating environment 200 will now be described in more detail. In an embodiment of the present invention, each of data 218, 220, and 222 is a separate event indication, which describes an event detected by device/person locator 210 and medical devices 212 and 214 (respectively). As used herein “event” describes an occurrence that is detected by a component. Exemplary events include detecting that a measured value has exceeded a threshold value, detecting that a measured value has increased or decreased, detecting a person or a piece of equipment (e.g., detecting arrival at or departure from a location), detecting that a device has been connected to or disconnected from bus 216, detecting that a device has been connected to or disconnected from a patient, detecting that an input has been entered, detecting that an alarm has been activated (e.g., code blue), and detecting that a device has started or stopped measuring a value of a patient. As used herein “event indication” includes a string of text that describes an event. For example, an event indication might include a set of text (e.g., words and numerals) that describe an occurrence that is detected by a component. As will be described in more detail below, event indications might be generated by components (e.g., person/device locator 210, medical devices 212 and 214, communication devices 226, and healthcare information system 228) that are external to both bus 216 and event-information handler 224 Such event indications that are generated by external components are sometimes referred to herein as “external event indications”. In a further embodiment, event indications are also generated by either bus 216 or event-information handler 224 and are sometimes referred to herein as “internal event indications”.
As previously indicated, device/person locator 210 might include a scanner configured to recognize a barcode on a medical device. Alternatively, device/person locator 210 might be configured to recognize a tagged item, such as an identification badge or other transmitter, when the tagged item passes a scanning device. As such, when device/person locator 210 detects an event (e.g., detects a medical device or a person), data 218 (i.e., event indication) is communicated to bus 216. An exploded view 218b of data 218 is shown in
In a further exemplary embodiment, data 227 is an event indication that describes an event detected by one of communication devices 226. For example, patient bedside 260 might detect that a patient has executed a consent form and send an appropriate event indication, which is communicated to event-information handler 224 via bus 216. Alternatively, nurse call 262 might detect an activation of a call type (e.g., code blue), in which case an appropriate event indication (e.g., data 227) is sent. An exploded view 227b of data 227 is shown in
In a further embodiment of the present invention, event indications are generated by healthcare information system 228. For example, event indications (e.g., data 250) might describe that a lab result has been obtained, that an order relating to a patient's treatment has been submitted, or that a patient has been assigned to a specific location. Via bus 216, data 250 is communicated to other components of
In an embodiment of the present invention, event indications are generated internally by bus 216 and/or event-information handler 224 as the result of event indications that are received from external devices, such as device/person locator 210, medical devices 212 and 214, healthcare information system 228 and communication devices 226. For example, event indications might be generated in response to a device being connected to or disconnected from a patient, a device being connected to or disconnected from bus 216, and a device starting or stopping performance of a function (e.g., infusion). An example of an internally generated event indication includes a notification that is communicated to workload/resources manager and that indicates a device is available to be used. Such an internally generated event indication might be generated as the result of another event indication that was received from a medical device and that indicated that the medical device was disconnected from a patient. In one embodiment, bus 216 creates internally generated event indications, which are then communicated to event-information handler 224 for subsequent processing. In an alternative embodiment, event-information handler 224 creates internally-generated event indications.
Exemplary event indications are depicted below in Table 1 to illustrate event categories and event types that are included in an embodiment of the present invention. In an embodiment of the present invention, event indications listed in Table 1 are externally-generated event indications, which are generated by device/person locator 210 or medical devices 212 or 214. For example, categories I and II might be generated by medical devices 212 or 214 and category III might be generated by device/person locator 210.
In an embodiment of the present invention, an event indication (either externally generated or internally generated) that is received by event-indication handler 224 is filtered according to raw information of the event indication. For example, an event indication might be filtered according to an identifier of a source device (e.g., device/person locator 210 and medical devices 212 and 214), a Java class name of a component that received the event indication, a Java class name of the raw incoming event indication, and location information (if provided). Filters might also include device name, device type, connection state, location, event type, event detail, device association status.
In an alternative embodiment, instead of immediately filtering an event indication, the event indication is processed before being filtered, such as by conforming data of the event indication and retrieving additional information associated with the event indication. In an embodiment of the present invention, data 218, 220, 222, and 227 are communicated to bus 216, which conforms data 218, 220, 222, and 227 into a common structure that is more easily used by other components and applications that might lack specific knowledge of a model of the source device of data 218, 220, 222, and 227. That is, information is normalized into a common format. Data 218, 220, 222, and 227 are then communicated to event-information handler 224 to be further processed. In a further embodiment, event receiver 230 receives data 218, 220, 222, and 227. Event receiver 230 might include event-listener components 236 that are each responsible for listening to a particular respective topic of bus 216 and capturing event indications (e.g., data 218, 220, 222, and 227) that are categorized under that topic. For example, an emergency-notification listener might listen for alarm-triggering event indications (e.g., data 220 and 227) and a device-locator listener might listen for event indications (e.g., data 218) that indicate a location of a device.
In a further embodiment of the present invention, once an event indication is received, event-listener components 236 conform each event indication to include specific context. In one embodiment of the present invention, all event indications are conformed based on a standard indication format, such that each event indication includes the same categories of data. These categories of data include an effective date and time of the event described by the event indication, identification of a source device (e.g., components 210, 212, 214, and 262) that generated the event indication, identification of a location associated with the source device, identification of a person (e.g., patient) associated with the source device, a coded priority of the event indication, and event acknowledgement information (if available). In a further embodiment, in order to process an event indication to include certain data, other databases must be referenced. For example, data 220 might identify medical device 212; however, data 220 might not identify either a location of medical device 212 or a person associated with medical device 212. Accordingly, the location of medical device 212 might be retrieved from a device-to-location database 238 and a person associated with medical device 212 might be retrieved from a patient-to-device database 240. In an embodiment of the present invention, associations stored in device-to-location database 238 might be created by an RTLS tag on a device, a device association with a static location, or a device connection to bus 216 at a static location. In embodiments of the present invention, associations stored in patient-to-device database 240 are created pursuant to methods described in U.S. patent application Ser. No. 12/347,475.
In a further embodiment, context that is additional to the standard indication format is added to event indications based on a type of the event indication. A type of event indication might depend on whether the event indication was received from an external source or was generated internally as the result of an observed condition. For example, one type of event indication is received from an external system, such as medical devices 212 and 214, device/person locator 210, healthcare information system 228, and communication devices 226 (e.g., nurse call 262). Event indications that are received from an external system include alarm-triggering event indications (e.g., data 220 that indicates “High HR—205 BPM”) and tracking event indications (e.g., data 218 that indicates “Device 789—RM 102”). An event indication that is received from external sources is supplemented to include received-event information, such as a date and time at which the event indication was received; a category of the event indication (e.g., emergency notification service and device/person-locator service); an event type (e.g., device started, device stopped, high heart rate, low heart rate, and device located); a value reported from the source (e.g., 205 bpm, Rm. 102, and 14:30); an event message subject and event message body (if available); a serialized representation of the original received event indication (e.g., data 218, 220, and 222); a Java class name identification of the component that received the event indication; and/or a Java class name identification of the event object that was received.
As previously indicated, in an embodiment of the present invention, an event that is received from an external source might serve either an alarm-triggering purpose or a tracking purpose. For example, if an event is designed to trigger an alarm, the alarm-triggering event indication that is received from an external component is supplemented to include alarm-triggering information, such as an alarm level (e.g., advisory, warning, and crisis); an alarm state (e.g., active, silenced, and cleared); an alarm text that describes the event (e.g., leads failed); an alarm instance count of alarms that report repeatedly until cleared; and/or a Java class name identification of the component that identified the event as an alarm-triggering event (i.e., if the event indication was not already marked as alarm-triggering when it was received). The supplemented alarm-triggering information is added to the standard-indication-format information and the received-event information. In alternative embodiments of the present invention, an event indication that is received from an external source might serve tracking purposes, as opposed to alarming purposes, in which case the event indication is supplemented with tracking information, such as a unique identifier of the person or object whose position is being reported and/or a unique identifier of the tracking tag that initiated the tracking event. The tracking information is added to the standard-indication-format information and the received-event information.
In further embodiments of the present invention, an alternative type of event indication is generated internally as the result of conditions that are detected based on event indications that are received from external sources. For example, a utilization level of a medical device might trigger an internal event indication, which indicates that the medical device needs to be serviced. A utilization level (e.g., frequency of utilization, duration of utilization, utilization load, etc.) might be determined based on various factors, such as cumulative connection time to bus 216, cumulative connection time to one or more patients, and cumulative run time. In one embodiment of the present invention, utilization levels are determined based on active-state-duration values. For example, data 222 might be recorded and combined with other event indications that indicate start and stop times of medical device 214. Durations of time between start and stop indications can be used to determine an active-state-duration value. Based on the combined start and stop times (e.g., combined active-state-duration values) a determination could be made that medical device 214 has run for a specific duration of time that requires maintenance to be performed on medical device 214. As such, an internal event indication might be generated that indicates that medical device 214 is required to receive service before further use. In embodiments of the present invention, internal event indications include standard-indication-format information that was previously described.
In further embodiments of the present invention, once an event indication has been conformed to include all types of appropriate information (e.g., standard-indication-format information, received-event information, alarm-triggering information, and tracking information) the event indication is further processed, such as by filtering the event, referencing a rules engine 242, and/or storing the event indication in events datastore 232.
In an embodiment of the present invention event indications are filtered by information included in the standard-indication-format information and received-event information. For example, an event indication might be filtered by an associated location (e.g., a location retrieved from datastore 238) or an associated person (e.g., a person identified in datastore 240). Moreover, event indications might be filtered by information included in alarm-triggering information or tracking information. As previously indicted filtering might include by device name, device type, connection state, location, event type, event detail, device association status, etc.
The rules engine 242 is responsible for analyzing event indications and determining if a rule exists for a particular alarm-triggering event indication (e.g. high heart rate), tracking event indication, (e.g., location of patient), and internally created event indication (e.g., service required). If a rule exists that applies to particular data, the rules engine 242 inspects the data of the event indication to determine whether a rule has been satisfied (e.g., whether a value is above or below a threshold value). If the rule has been satisfied, the rules engine triggers subsequent action, such as triggering a notifier component 243 to send a notification (e.g., data 244 and 245) to a notification recipient (e.g., communication device 226). Alternatively, if a notification is not to be sent to a notification recipient, the rules engine might trigger a log event, which creates a stored record that a rule was violated. For example, rules engine 242 might dictate that if a particular device (e.g., medical device 212) detects a heart rate that exceeds 200 beats-per-minute, notification 244 should be sent to communications device 246. In another example, a rule might dictate that a notification 248 should be sent to a medical resources department when medical device 214 is disconnected from bus 216 and is available to be used to treat other patients.
In embodiments of the present invention rules engine 242 is extensible, such that new rules can be created and added to rules engine 242. One type of rule might be created when a healthcare professional subscribes to receive notifications that are generated from event indications of a certain medical device. In an embodiment of the present invention, rules engine 242 is configurable to generate notifications of any event that is detected. That is, not only are alarm-triggering events (e.g., cardiac arrest) reportable to subscribing healthcare professionals, but any event (e.g., high/low heart rate, increase/decrease in heart rate, start/stop infusion, etc.) that is captured by event-information handler 224 is also reportable. In this respect, an embodiment of the present invention enables notification rules of a healthcare professional to be customizable based on a particular patient. A healthcare professional might generally not want to receive notifications of a high heart rate; however, because of a particular patient's condition, the healthcare professional might want to receive notifications of the patient's high heart rate. As such, an embodiment of the present invention allows the healthcare professional to create a notification rule that applies to the patient.
In a further embodiment of the present invention, additional information is retrieved prior to event-information handler 224 sending notifications (e.g., notifications 244 and 245). For example, as previously described, a patient identifier of a patient that is associated with a medical device is retrievable from patient-to-device datastore 240. As such, using the patient identifier, EMR 229 might be referenced to obtain additional information regarding the patient. For example, a patient information retriever 249 might send via bus 216 a request 248 to receive medical history, a diagnosis, current treatment, critical lab result(s), and other information stored in EMR 229, in order to create a more information-rich notification 244. An expanded view 244b of notification 244 is shown in
In an embodiment of the present invention, event indications are used in various ways to generate notifications, such as notifications 244 and 245. Additional types of notifications that are enabled by the present invention include: a dementia-roaming notification that is published (e.g., to com device 246) when a dementia-suffering patient exits his/her room; a device-maintenance notification that is provided (e.g., to nurse call 262) when a healthcare professional associates a pump with a patient that is due for maintenance, thereby alerting the healthcare professional to select a different pump; a device-maintenance notification that is provided when a healthcare professional disassociates a pump from a patient, thereby alerting the healthcare professional to set the pump aside and alerting a biomedical equipment department (e.g., via email 266) to perform the maintenance; infusion-completion notification that informs a healthcare professional that an infusion has reached a predetermined completion percentage; patient-fall-monitoring that provides a notification to a healthcare professional that a patient, who is considered to be a fall risk, has left a bus-connected bed; and a presurgery-condition notification that, when a position tracking system sends an event indication reporting that a patient has entered a surgical operating suite and a predetermined set of condition are not met, informs surgical staff by a spoken message (e.g., via intercom 264) that the condition is not met.
In an embodiment of the present invention, a notification recipient includes one or more of various components of operating environment 200.
In alternative embodiments, event indications are provided to other components of operating environment 200. A notification might also be provided to healthcare information system 228. For example, information in an event notification might be published to EMR 229, a workload/resources management component 270, or other components of healthcare information system 228. Other notification recipients might include applications that manage specific events of a particular medical device, such as an application that consumes all event history of an infusion pump.
In a further embodiment, communication devices 226 submit data 225 to event-information handler. As such, the present invention facilitates bidirectional communication between information stores and communication devices 226. For example, upon receiving a notification (e.g., notification 244), a user of personal communications device 246 might want to view additional information that is related to a patient associated with the notification and that is stored in events datastore 232, in EMR 229, or with medical device 212. Examples of such additional information include all event indications associated with the patient that are stored in events datastore 232, current treatment information of the patient stored in EMR 229, and/or recent data values that were measured by medical device 212. As such, personal communications device 246 might be used to send a request for information (e.g., data 225) to event-information handler. Upon receiving a request for additional information from a notification recipient, the source of the additional information is referenced to retrieve the requested additional information, and the additional information is provided to the notification recipient. For example, a healthcare professional (e.g., floor nurse) working in “Patient Room A” might use a mobile device to request that device data values be sent from a monitor in “Patient Room B” to his/her phone. Personal communication device might also be used to acknowledge that a notification was received or to indicate that a user is unable to accept a notification. As such, in an embodiment of the invention, a failure to acknowledge a notification creates an event escalation, whereby the notification is sent with a higher priority and/or sent to alternative recipients.
In a further embodiment of the present invention, event indications are stored in events datastore 232, which provides a long-term data store for reporting and analysis of various events and event indications. Contents of event datastore 232 are viewable, such as by using a monitor of a computing device. For example,
In a further embodiment, event datastore 232 is searchable and receives and processes search queries of event indications. For example, a user might want to view only those event indications that satisfy an event-indication sorting criterion. Examples of event-indication sorting criterion include an event-indication keyword, a patient identifier, an event type, a medical-device identifier, a location, an event state, an event time, and an event level. In response to a user inputting an event-indication sorting criterion, an event sorter component 272 queries the event datastore 232 to identify those event-indications that include contents that match the criterion. A reporter component 274 presents to the user event-indications that have contents that match the criterion. For example, referring to
Referring to
Referring to
Referring to
Many different arrangements of the various components depicted, as well as components not shown, are possible without departing from the scope of the claims below. Embodiments of our technology have been described with the intent to be illustrative rather than restrictive. Alternative embodiments will become apparent to readers of this disclosure after and because of reading it. Alternative means of implementing the aforementioned can be completed without departing from the scope of the claims below. Certain features and subcombinations are of utility and may be employed without reference to other features and subcombinations and are contemplated within the scope of the claims.
