System for pairing a medical system with a network controller by using a dongle

Abstract

To provide a medical system.SOLUTION: A first medical device can acquire a physiological parameter value from a patient and communicate the physiological parameter value to a medical network interface. The medical network interface can link a patient ID associated with the physiological parameter and a device ID associated with the first medical device with a device ID of the medical network interface. The medical network interface can pass the physiological parameter value to a second medical device for further processing or can route to another medical device.SELECTED DRAWING: Figure 81

Description

Technical Field

[0001] Related Applications This application is related to the following U.S. patent applications, the disclosures of which are hereby incorporated by reference in their entirety. Application Number Filing Date Title Docket Number 62 / 463,452 February 24, 2017 Patient Monitor Communication Platform MAS.1126PR 62 / 463,297 February 24, 2017 Modular Multi-Parameter Patient Monitoring Device MAS.1130PR 62 / 463,517 February 24, 2017 System for Displaying and Controlling Medical Monitoring Data MAS.1132PR1 62 / 503,109 May 8, 2017 System for Displaying and Controlling Medical Monitoring Data MAS.1170PR1 62 / 535,757 July 21, 2017 System for Displaying and Controlling Medical Monitoring Data MAS.1170PR2 62 / 463,614 February 25, 2017 Patient Monitor Communication Platform MAS.1133PR

[0002] Many of the embodiments described herein are compatible with the embodiments described in the above related applications. Further, some or all of the features described herein may be used in conjunction with many of the features described in the applications listed above or otherwise combined in some other form.

[0003] The present disclosure generally relates to patient monitoring devices, and more particularly to patient monitors and medical data communication hubs.

Background Art

[0004] Today's patient monitoring environment is populated with sophisticated, often electronic medical devices that provide a wide variety of monitoring and treatment activities for a given patient. Generally, many of these devices, if not all, are from different manufacturers and many can be portable devices. These devices may not communicate with each other and may each have their own dedicated controls, displays, alarms, configurations, and the like. What complicates matters is that in many cases caregivers wish to associate all types of measurement and usage data from these devices with a particular patient. Thus, patient information entry is often done device by device. Sometimes, due to inconsistencies within the device, it becomes necessary for the caregiver to simply print to paper from each device for review and store in the patient's chart.

[0005] As a result of such differences in devices, in many cases, there are multiple displays and alarms scattered within the caregiver environment, potentially creating a chaotic experience. Such chaos can be harmful to the patient in many situations, including surgical environments where caregiver distraction is undesirable and recovery or monitoring environments where patient distraction or confusion may be undesirable.

[0006] Various manufacturers are producing multi-monitor devices or devices that expand in a modular fashion to increase the diversity of monitoring or treatment activities that a particular system can achieve. However, as medical device technology expands, such multi-monitor devices begin to become obsolete from the moment they are installed.

Prior Art Documents

Patent Documents

[0007] [Patent Document 1] U.S. Patent Application No. 13 / 269,296 [Patent Document 2] U.S. Patent Application No. 13 / 371,767 [Patent Document 3] U.S. Patent Application No. 12 / 904,925 [Patent Document 4] U.S. Patent Publication No. 2002 / 0140675 [Patent Document 5] U.S. Patent Publication No. 2010 / 0274099 [Patent Document 6] U.S. Patent Publication No. 2011 / 0213273 [Patent Document 7] U.S. Patent Publication No. 2012 / 0226117 [Patent Document 8] U.S. Patent Publication No. 2010 / 0030040 [Patent Document 9] U.S. Patent Application No. 61 / 242,792 [Patent Document 10] U.S. Patent Application No. 61 / 387457 [Patent Document 11] U.S. Patent Application No. 61 / 645,570 [Patent Document 12] U.S. Patent Application No. 13 / 554,908 [Patent Document 13] U.S. Patent No. 6,157,850 [Patent Document 14] U.S. Patent No. 6,334,065 [Patent Document 15] U.S. Patent Publication No. 2011 / 0105854 [Patent Document 16] U.S. Patent Publication No. 2011 / 0169644 [Patent Document 17] U.S. Patent Publication No. 2007 / 0180140 [Patent Document 18] U.S. Patent Publication No. 2011 / 0172561 [Patent Document 19] U.S. Application No. 14 / 032,132 [Patent Document 20] U.S. Patent No. 9,142,117 [Patent Document 21] U.S. Application No. 62 / 463,262 [Patent Document 22] U.S. Publication No. 2014 / 0077956 [Patent Document 23] U.S. Application No. 14 / 511,972 [Patent Document 24] Application No. 14 / 030,360 [Patent Document 25] U.S. Patent No. 9,749,232 [Patent Document 26] U.S. Patent Application No. 15 / 902,193 [Summary of the Invention] [Problems to be Solved by the Invention]

[0008] In the present disclosure, embodiments of a medical monitoring hub as a center of monitoring for a monitored patient are described. The hub can include a configurable medical port and a serial port for communicating with other medical devices near the patient. Further, the hub can communicate with a portable patient monitor. The monitor may present different display graphics when docked to the hub than when undocked. The display graphics can include anatomical information. The hub can assemble a large amount of electronic medical data in many cases, associate it with the patient being monitored, and in some embodiments, transfer the data to the patient's medical record by communication. [Means for Solving the Problems]

[0009] In some aspects of the present disclosure, a first medical device having digital logic circuitry receives a physiological signal associated with a patient from a physiological sensor, obtains a first physiological parameter value based on the physiological signal, and outputs the first physiological parameter value for display. The first medical device can also receive a second physiological parameter value from a second medical device different from the first medical device, where the second physiological parameter value is formatted according to a protocol not used by the first medical device, such that the first medical device cannot process the second physiological parameter value to generate a displayable output value. The first medical device can transfer physiological parameter data from the first medical device to a separate translation module, receive the translated parameter data from the translation module in the first medical device, and the translated parameter data can be processed for display by the first medical device and a second value from the translated parameter data can be output and displayed. The first medical device can be, for example, a monitoring hub, a portable physiological monitor, or a multi-patient monitoring system, and the second medical device can be an infusion pump, a ventilator, or the like.

[0010] For the purpose of summarizing the present disclosure, some aspects, advantages, and novel features are described herein. It should be understood that not necessarily all such aspects, advantages, or features are embodied in any particular embodiment of the invention, and one of ordinary skill in the art will recognize from the disclosure herein that there are numerous combinations of such aspects, advantages, or features.

[0011] The following drawings and associated descriptions are provided to illustrate embodiments of the present disclosure and do not limit the scope of the claims.

Brief Description of the Drawings

[0012]

Figure 1A

Figure 1B

Figure 1C

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7A

Figure 7B

Figure 8

Figure 9A

Figure 9B

Figure 10

Figure 11A

Figure 11B

Figure 11C

Figure 11D

Figure 11E

Figure 11F

Figure 11G1

Figure 11G2

Figure 11H

Figure 11I

Figure 11J

Figure 11K

Figure 10

Figure 11A

Figure 11B

Figure 11C

Figure 11D

Figure 11E

Figure 11F

Figure 11G1

Figure 11G2

Figure 11H

Figure 11I

Figure 11J

Figure 11K

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17A

Figure 17B

Figure 18

Figure 19A

Figure 19B

Figure 19C

Figure 19D

Figure 19E

Figure 19F

Figure 19G

Figure 19H

Figure 19I

Figure 19J

Figure 20A

Figure 20B

Figure 20C

Figure 21A

Figure 21B

Figure 22A

Figure 22B

Figure 23A

Figure 23B

Figure 23C

Figure 23D

Figure 23E

Figure 23F

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40A

Figure 40B

Figure 41A

Figure 41B

Figure 41C

Figure 41D

Figure 42

Figure 43A

Figure 43B

Figure 44

Figure 45A

Figure 45B

Figure 45C

Figure 45D

Figure 46

Figure 47

Figure 48

Figure 49

Figure 50

Figure 51

Figure 52

Figure 53

Figure 54

Figure 55

Figure 56

Figure 57

Figure 58

Figure 59

Figure 60

Figure 61

Figure 62

Figure 63

Figure 64

Figure 65

Figure 66

Figure 67

Figure 68

Figure 69

Figure 70

Figure 71

Figure 72A

Figure 72B

Figure 72C

Figure 72D

Figure 72E

Figure 72F

Figure 72G

Figure 73

Figure 74

Figure 75

Figure 76

Figure 77A

Figure 77B

Figure 78A

Figure 78B

Figure 79

Figure 80

Figure 81

Figure 82

Figure 83

Figure 84A

Figure 84B

Figure 84C

Figure 84D

Figure 85A

Figure 85B

Figure 85C

Figure 86A

Figure 86B

Figure 87A

Figure 87B

Figure 87C

Figure 87D

Figure 88

Figure 89

Embodiments for Carrying Out the Invention

[0013] In the above "Brief Description of the Drawings", various embodiments of the present disclosure are generally referred to. However, those skilled in the art will recognize that such embodiments are not mutually exclusive from the disclosure herein. Rather, those skilled in the art will recognize that there are countless combinations of some or all of such embodiments.

[0014] I. Introduction Based at least on the above, there is a need for solutions to coordinate various medical devices for treating or monitoring patients. Embodiments of such solutions should provide seamless patient identification across the device space, and embodiments of such solutions should be extensible to future technologies without necessarily requiring repeated software upgrades. In addition, embodiments of such solutions may include electrical isolation of the patient if desired.

[0015] Accordingly, the present disclosure relates to a patient monitoring hub that is central to a patient's monitoring and treatment activities for a given patient. Embodiments of the patient monitoring hub provide the flexibility to interface with legacy devices without requiring legacy reprogramming and to interface with future devices without requiring software upgrades, and optionally provide electrical isolation of the patient. In one embodiment, the hub comprises a large display that dynamically provides caregivers with information regarding parameters determined by a wide variety of measurements or some other means. Additionally, in one embodiment, the hub comprises a docking station for a portable patient monitor. The portable patient monitor may communicate with the hub through the docking station or through various wireless paradigms known to those skilled in the art from the disclosure herein, including WiFi, Bluetooth®, Zigbee, or the like.

[0016] In yet other embodiments, the portable patient monitor modifies its screen when docked. The undocking display may be partially or entirely transferred to the large dynamic display of the hub, and the docked display presents one or more anatomical graphics of the body part being monitored. For example, the display may present the heart, lungs, brain, kidneys, intestines, stomach, other organs, fingers, gastrointestinal system, or other body parts when docked. In one embodiment, the anatomical graphics may advantageously be displayed as an animation. In one embodiment, the animation may generally follow the behavior of the measured parameter. For example, the lungs may inflate approximately correlating to the measured respiratory rate and / or the determined inspiratory portion of the respiratory cycle and deflate similarly following the expiratory portion. The heart may beat according to the heart rate and generally follow the actual cardiac systole pattern of the heart as generally understood and may perform similar operations. Further, in one embodiment, when the measured parameter indicates that a caregiver needs to be warned, a changing color severity may be associated with one or more of the displayed graphics such as the heart, lungs, brain, or the like. In yet further other embodiments, the body part may include an animation regarding where, when, or how to attach the measurement device to the patient's measurement site. For example, the monitor may provide animated instructions for CCHD screening procedures or glucose strip reading protocols, application of forehead sensors, finger or toe sensors, one or more electrodes, acoustic sensors, and ear sensors, attachment of cannula sensors or the like.

[0017] The present disclosure relates to a medical monitoring hub configured to be central to monitoring activities for a given patient. In one embodiment, the hub includes a large, readable display, such as a ~10-inch display that dominates most of the occupancy area on the front of the hub. The display can be quite large or quite small depending on design constraints. However, with respect to portability and current design goals, the preferred display size is approximately proportional to one vertical footprint of a dockable, portable patient monitor. Other considerations will be recognizable to those of ordinary skill in the art from the disclosure herein.

[0018] The display provides numerical data for a wide variety of monitoring parameters for the patient under observation in numerical or graphical form and is automatically configured in various embodiments based on the types of data and information received at the hub. In one embodiment, the hub is movable, portable, and wearable to be positioned in a convenient area within the caregiver environment. For example, the hub is gathered within a single housing.

[0019] In one embodiment, the hub can advantageously receive data from a portable patient monitor that is either docked or undocked from the hub. Typical portable patient monitors, such as an oximeter or a CO-oximeter, can provide measurement data for a number of physiological parameters derived from signals output from optical and / or acoustic sensors, electrodes, or the like. Physiological parameters include, but are not limited to, for example, oxygen saturation, carboxyhemoglobin, methemoglobin, total hemoglobin, glucose, pH, bilirubin, saturation fraction, heart rate, respiratory rate, components of the respiratory cycle, an indication of perfusion including perfusion index, signal quality and / or reliability, plethysmograph data, an indication of health or a health index or other combination of measurement data, auditory information responsive to respiration, disease identification or diagnosis, blood pressure, patient and / or measurement site temperature, depth of sedation, organ or brain oxygen supply, fluid supply, measurements responsive to metabolism, combinations thereof, or the like. In other embodiments, the hub can output sufficient data to perform closed-loop drug administration in combination with an infusion pump or the like.

[0020] In one embodiment, the hub communicates with other devices in a monitoring environment that interface with the patient in various ways. For example, the hub can advantageously receive serial data from other devices without the need for their reprogramming or reprogramming of the hub. Such other devices include pumps, ventilators, any type of monitor that monitors any combination of the foregoing parameters, ECG / EEG / EKG devices, electronic patient beds, and the like. Additionally, the hub can advantageously receive channel data from other medical devices without the need for their reprogramming or reprogramming of the hub. When devices communicate through channel data, the hub can advantageously change a large display to include measurement information from that device. In addition, the hub accesses a nurse call system to ensure that nurse call situations from the devices are passed to an appropriate nurse call system.

[0021] The hub also communicates with the hospital system and advantageously associates incoming patient measurement and treatment data with the monitored patient. For example, the hub may communicate wirelessly or otherwise with a plurality of patient monitoring systems, such as a server or a collection of servers, which may then communicate with the caregiver's data management system, such as, for example, an admission / discharge / transfer ("ADT") system and / or an electronic medical record ("EMR") system. The hub advantageously associates the data flowing through it with the monitored patient, thereby providing the electronic measurement and treatment information that should be passed on to the caregiver's data management system without the caregiver having to associate each device in the environment with the patient.

[0022] In one embodiment, the hub advantageously comprises a reconfigurable, removable docking station. The docking station may dock additional layers of docking stations to accommodate different patient monitoring devices. In addition, the docking station itself is modular so that it can be removed if the form factor of the main dockable portable patient monitor changes. Thus, the hub has flexibility in the way its docking station is configured.

[0023] In one embodiment, the hub comprises a large-capacity memory for receiving, processing, and / or storing some or all of the data associated with the patient, and / or the results of communication with other devices and systems. Advantageously, some or all of the memory may comprise a removable SD memory.

[0024] The hub communicates with other devices through at least (1) a docking station for acquiring data from a portable monitor, (2) an innovative universal medical connector for acquiring channel data, (3) a serial data connector such as an RJ port for acquiring output data, (4) Ethernet (registered trademark), USB, and a nurse call port, (5) a wireless device for acquiring data from a portable monitor, and (6) other wired or wireless communication mechanisms known to those skilled in the art. The universal medical connector preferably has optionally electrically isolated power and communication functions, which are designed to have a smaller cross-sectional area compared to isolation requirements. The connector and the hub communicate and preferably translate data from other devices or configure it to be usable and displayable on the hub. In one embodiment, a software development kit ("SDK") is provided to the device manufacturer to determine or define the behavior and meaning of the data output from the device. When the output is defined, the definition is programmed into memory located on the cable side of the universal medical connector and supplied to the device provider as an original equipment manufacturer ("OEM"). When the cable is connected between the device and the hub, the hub can understand the data and use it for display and processing purposes without the need for a software upgrade to the device or the hub. In one embodiment, the hub can even negotiate a schema and add additional compression and / or encryption. Through the use of the universal medical connector, the hub can organize measurement and treatment data into a single display and alarm system and effectively and efficiently send commands to the monitoring environment.

[0025] When the hub receives and tracks data from other devices according to the channel paradigm, the hub can advantageously perform processing to create virtual channels for patient measurements or treatment data. In one embodiment, the virtual channel can include, for example, non-measured parameters that are the result of various measured or processed data from other parameters. An example of such a parameter includes a health metric derived from various measured parameters that gives an overall indication of the health status of the patient being monitored. An example of a health parameter is disclosed in U.S. Patent Application No. 13 / 269,296, U.S. Patent Application No. 13 / 371,767, and U.S. Patent Application No. 12 / 904,925, which are assigned to the assignee of the present disclosure and incorporated herein by reference. By organizing data into channels and virtual channels, the hub can advantageously synchronize incoming data and virtual channel data over time.

[0026] The hub also receives serial data through a serial communication port, such as an RJ connector. The serial data is associated with the patient being monitored and passed on to the plurality of patient server systems and / or caregiver backend systems described above. By receiving the serial data, the caregiver can advantageously avoid the need to associate devices within the caregiver environment from various manufacturers with a specific patient in many cases and the possibility of communication with the hospital system. Such an association is important because it reduces the time the caregiver spends entering personal and demographic information into each device with respect to the patient. Further, in one embodiment, through the SDK, the device manufacturer can advantageously provide information associated with the measurement latency of the device, thereby further enabling the hub to synchronize serial incoming data and other data associated with the patient over time.

[0027] In one embodiment, when a portable patient monitor is docked and it has its own dedicated display, the hub effectively increases its display occupancy area. For example, in one embodiment, the portable patient monitor can simply continue to display its measurement and / or treatment data, and it can be replicated on the hub display, or the docked display can change its display to provide additional information. In one embodiment, the display being docked presents anatomical graphic data of, for example, the heart, lungs, organs, brain, or other body parts being measured and / or treated when docked. The graphic data can advantageously be an animated display that is similar to and matched to the measurement data. For example, the lungs expand approximately correlating to the measured respiratory rate and / or the determined inhalation / exhalation portions of the respiratory cycle, the heart beats according to the pulse rate and generally along the understood actual cardiac contraction pattern, and the brain can change color or activity based on the changing depth of sedation or the like. In one embodiment, when it indicates that a measurement parameter needs to alert the caregiver, a changing severity of color can be associated with one or more of the displayed graphics such as the heart, lungs, brain, organs, the circulatory system or a part thereof, the respiratory system or a part thereof, other body parts, or the like. In yet other embodiments, the body part can include an animation regarding where, when, or how to attach the measurement device.

[0028] The hub may also advantageously be one that overlays the parameter display to provide additional image information to the caregiver. Such an overlay can be user-definable and configurable. This display may incorporate analog display icons or graphic markings.

[0029] For the sake of clarity, not all features of the actual implementation forms are described in this specification. A person skilled in the art will of course have to make a number of implementation-specific decisions in the development of such actual implementation forms (such as in a development project) to achieve the specific goals and sub-goals of the developer, such as adapting to system and business-related constraints that vary for each implementation form. Furthermore, although such development efforts can be complex and time-consuming, it is understood that it is routine business in device design for those skilled in the art who utilize this disclosure.

[0030] To further the complete understanding of this disclosure, the remainder of the detailed description will describe the disclosure with reference to the drawings, in which like reference numerals refer to like numbers throughout.

[0031] II. Exemplary Hub Embodiments FIG. 1A illustrates a monitoring environment, including a perspective view of an exemplary medical monitoring hub 100 that includes an exemplary docked portable patient monitor (PPM) 102 according to one embodiment of the present disclosure. The hub 100 includes a display 104 and a docking station 106 configured to mechanically and electrically mate with the portable patient monitor 102 in one embodiment, and each is housed within a housing 108 that is movable, wearable, and portable. The housing 108 includes a generally upright inclined shape configured to rest on a horizontal and flat surface, although the housing 108 can be attached to a variety of positions and mounts and can include those of a variety of shapes and sizes.

[0032] In one embodiment, the display 104 may present a wide variety of measurement and / or treatment data in numerical, graphical, waveform, or other indicia 110 of display. In one embodiment, the display 104 occupies most of the front of the housing 108, although those skilled in the art will understand that the display 104 may take on a table or tabletop horizontal configuration, a laptop-like configuration, or a similar configuration. Other embodiments may include communicating display information and data to a table computer, a smartphone, a television, or a display system understandable to those skilled in the art. The upright tilt configuration of FIG. 1A presents the display information in a manner that is easy for the caregiver to view.

[0033] FIG. 1B shows a side perspective view of one embodiment of a hub 100 including a docking station 106 with the housing 108, the display 104, and the portable monitor undocked. Also shown is a connector for non-invasive blood pressure.

[0034] The portable patient monitor 102 of FIG. 1A advantageously is commercially available from Masimo Corporation of Irvine, California, and / or is disclosed in U.S. Patent Publication No. 2002 / 0140675, U.S. Patent Publication No. 2010 / 0274099, U.S. Patent Publication No. 2011 / 0213273, U.S. Patent Publication No. 2012 / 0226117, U.S. Patent Publication No. 2010 / 0030040, and U.S. Patent Application No. 61 / 242,792, U.S. Patent Application No. 61 / 387457, U.S. Patent Application No. 61 / 645,570, U.S. Patent Application No. 13 / 554,908, and U.S. Patent No. 6,157,850, U.S. Patent No. 6,334,065, and the like, and may include an oximeter, a co-oximeter, a respiratory monitor, a depth of sedation monitor, a non-invasive blood pressure monitor, a vital signs monitor, or the like. The monitor 102 may communicate with various non-invasive and / or minimally invasive devices such as a light sensor having a light emission and detection circuit, an acoustic sensor, a device for measuring blood parameters from a finger prick, a cuff, a ventilator, and the like. The monitor 102 may include a dedicated display 114 that presents a dedicated indication 116 of it, as described below with reference to FIGS. 19A-19J. The indication advantageously may change based on the docking state of the monitor 102. When undocked, the indication may be, for example, one that includes parameter information and changes its orientation based on a gravity sensor or an accelerometer.

[0035] In one embodiment, the docking station 106 of the hub 100 includes a mechanical latch 118, or a mechanically releasable catch, to ensure that the monitor 102 is not mechanically detached in a manner that could be damaged if the hub 100 is moved.

[0036] Although disclosed with reference to a particular portable patient monitor 102, those skilled in the art will understand from the disclosure herein that there are a number of diverse medical devices that can advantageously dock with the hub 100. Further, the docking station 106 may advantageously be electrically connected to the monitor 102 and not mechanically connected and / or communicate with it wirelessly.

[0037] FIG. 2 shows a simplified block diagram illustrating an exemplary monitoring environment 200 that includes the hub 100 of FIG. 1, according to one embodiment of the present disclosure. As shown in FIG. 2, the environment may comprise a portable patient monitor 102 that communicates with one or more patient sensors 202, such as, for example, an oxygen measurement optical sensor, an acoustic sensor, a blood pressure sensor, a respiratory sensor, or the like. In one embodiment, additional sensors, such as, for example, a NIBP sensor or system 211 and a temperature sensor or sensor system 213, may communicate directly with the hub 100. The sensors 202, 211, and 213 are typically located near the patient being monitored when in use, although not actually attached to the patient's measurement site.

[0038] As disclosed, the portable patient monitor 102 communicates with the hub 100, and in one embodiment, through the docking station 106 when docked, and in one embodiment, wirelessly when undocked, although such undocked communication is not required. The hub 100 communicates with one or more patient monitoring servers 204 or server systems, such as those disclosed by, for example, U.S. Patent Publication No. 2011 / 0105854, U.S. Patent Publication No. 2011 / 0169644, and U.S. Patent Publication No. 2007 / 0180140. Generally, the server 204 communicates with a caregiver backend system 206, such as an EMR and / or ADT system. The server 204 can advantageously obtain patient information entered at the time of patient admission, such as demographic information, billing information, and the like, through push, pull, or combination techniques. The hub 100 accesses this information to seamlessly associate the monitored patient with the caregiver backend system 206. The communication between the server 204 and the monitoring hub 100 can be any communication means recognizable to those skilled in the art from the disclosure herein, including wireless, wired, mobile, or other computing networks, or the like.

[0039] FIG. 2 also shows a hub 100 that communicates through serial data port 210 and channel data port 212. As disclosed in the foregoing description, serial data port 210 can provide data from a wide variety of patient medical devices, including an electronic patient bed system 214, an infusion pump system 216 including a closed loop control system, a ventilation device system 218, a blood pressure or other vital sign measurement system 220, or the like. Similarly, channel data port 212 can provide data from a wide variety of patient medical devices, including any of the foregoing devices and other medical devices. For example, channel data port 212 can receive data from a depth of anesthesia monitor 222, such as those commercially available from SEDLine, a brain or other organ oximeter device 224, a non-invasive blood pressure or acoustic device 226, or the like. In one embodiment, the channel device may advantageously comprise a board in cable ( "BIC") solution, in which case the processing algorithms and the signal processing devices that implement those algorithms are mounted on a board housed within the cable or cable connector, which in some embodiments does not have additional display technology. The BIC solution outputs its measured parameter data to channel port 212 for display on display 104 of hub 100. In one embodiment, hub 100 can be formed, in whole or in part, as a BIC solution that communicates with other systems, such as, for example, a tablet, a smartphone, or other computing system.

[0040] Although disclosed with reference to a single docking station 106, the environment 200 may comprise stacked docking stations, in which case the subsequent docking stations mechanically and electrically dock to the first docking station and change the form factor for different portable patient monitors as described with reference to FIG. 5. Such stacking may comprise more than two docking stations and may reduce or increase the form factor to mechanically fit the mating mechanical structure on the portable device.

[0041] Figure 3 shows a simplified exemplary hardware block diagram of the hub 100 of FIG. 1, according to an embodiment of the present disclosure. As shown in FIG. 3, the housing 108 of the hub 100 positions and / or includes a meter board 302, a display 104, a memory 304, various communication connections including a serial port 210, a channel port 212, an Ethernet® port 305, a nurse call port 306, other communication ports 308 including a standard USB or the like, and a docking station interface 310. The meter board 302 includes one or more substrates including communication interconnects, wiring, ports, and the like for enabling the communications and functions described herein, including inter-board communications. The core board 312 includes main parameters, signals, and other processors and memories, the portable monitor board (“RIB”) 314 includes patient electrical isolation for the monitors 102 and one or more processors, the channel board (“MID”) 316 controls communication with the channel port 212 including optional patient electrical isolation and a power supply 318, and the wireless board 320 includes components configured for wireless communication. In addition, the meter board 302 may advantageously include one or more processors and controllers, buses, any type of communication connection functions and electronics, memories, a memory reader including an EPROM reader, and other electronics recognizable to those skilled in the art from the disclosure herein. Each board includes substrates for positioning and support, communication interconnects, controllers, electronic components including logic devices, hardware / software combinations, and the like for performing the tasks specified above and other tasks.

[0042] Those skilled in the art will understand from the disclosure herein that the meter board 302 may comprise a number of electronic components arranged in a number of ways. By using different boards such as those disclosed above, advantageously, the arrangement and partitioning into a complex system is achieved.

[0043] Figure 4 shows a perspective view of an exemplary removable docking station 400 of the hub 100 of FIG. 1, according to one embodiment of the present disclosure. As shown in FIG. 4, the docking station 400 provides a mechanical fit to the portable patient monitor 102 and provides secure mechanical support when the monitor 102 is docked. The docking station 400 includes a cavity 402 having a shape similar to the outer perimeter of the housing of the portable monitor 102. The station 400 also includes one or more electrical connectors 404 that provide communication with the hub 100. Although shown to be bolted on, the docking station 400 may be snap-fitted, use movable tabs or catches, be magnetically attached, or employ a variety of attachment mechanisms or combinations of mechanisms known to those skilled in the art from the disclosure herein. In one embodiment, the attachment of the docking station 400 should be sufficiently secure such that the monitor 102 and the docking station cannot be accidentally detached in a manner that might damage the instrument, even if, for example, the hub 100 bumps into it accidentally, and the monitor 102 and the docking station 400 should remain intact.

[0044] The housing 108 of the hub 100 also includes a cavity 406 for housing the docking station 400. To the extent that a change in form factor for the portable patient monitor 102 occurs, the docking station 400 is advantageously removable and replaceable. Similar to the docking station 400, the hub 100 includes an electrical connector 408 within the cavity 406 of the housing 108 that provides electrical communication to the docking station 400. In one embodiment, the docking station 400 includes its own microcontroller and processing capabilities, as disclosed in U.S. Patent Publication No. 2002 / 0140675. In other embodiments, the docking station 400 communicates through the electrical connector 408.

[0045] FIG. 4 also shows a housing 108 having an opening for the channel port 212 as a universal medical connector described in detail below.

[0046] FIG. 5 shows a perspective view of exemplary portable patient monitors 502 and 504 that have been undocked from the hub 100 according to one embodiment of the present disclosure. As shown in FIG. 5, monitor 502 may be removed, and other monitors such as monitor 504 may also be provided. The docking station 106 includes an additional docking station 506 that mechanically mates with the original docking station 106 and provides a form factor that can mechanically mate with monitor 504. In one embodiment, monitor 504 mechanically and electrically mates with the stacked docking stations 506 and 106 of hub 100. As can be readily understood by one of ordinary skill in the art from the disclosure herein, the stackable functionality of the docking stations provides a highly flexible mechanism for charging, communicating, and interfacing a wide variety of patient monitoring devices to hub 100. As noted above, the docking stations may be stacked or, in other embodiments, removed and replaced.

[0047] FIG. 6 shows a simplified block diagram of a conventional patient electrical isolation principle. As shown in FIG. 6, host device 602 is generally associated with patient device 604 through communication and power. Since patient device 604 often includes electronic devices such as sensors or the like that are near or connected to the patient, specific safety requirements stipulate that, for example, there should be no electrical path to the patient from an electrical surge in the power distribution network connected to the host device. This generally refers to what is known in the art as "patient isolation", which in this specification includes the removal of a direct, unbroken electrical path between host device 602 and patient device 604. Such isolation is achieved, for example, through isolation device 606 on power conductor 608 and communication conductor 610. Isolation device 606 can include transformers, optical devices that emit and detect optical energy, and the like. The use of isolation devices, especially on power conductors, is expensive in terms of components, costly in terms of size, and may waste power. Conventionally, isolation devices have been incorporated into patient device 604, but patient device 604 tends to be miniaturized and not all devices incorporate isolation.

[0048] Figure 7A shows a simplified block diagram of an exemplary optional patient isolation system according to one embodiment of the present disclosure. As shown in Figure 7A, host device 602 communicates with patient device 604 isolated through isolation device 606. However, memory 702 associated with a particular patient device notifies host 602 whether that device requires an isolated power supply. If patient device 708, such as certain cuffs, infusion pumps, ventilators, or the like, does not require an isolated power supply, host 602 can provide a non-isolated power supply through signal path 710. This power supply may be considerably higher than what can be provided cost-effectively through isolated power conductor 608. In one embodiment, non-isolated patient device 708 receives isolated communication since such communication is typically at a lower voltage and not prohibitively costly. Those skilled in the art will recognize from the disclosure herein that communication can also be non-isolated. Thus, Figure 7A shows patient isolation system 700 for optional patient isolation between host 602 and a wide variety of potential patient devices 604, 708. In one embodiment, hub 100 comprises channel port 212 incorporating a similar optional patient isolation principle.

[0049] FIG. 7B shows an exemplary optional non-isolated power level added to the system of FIG. 7A according to one embodiment of the present disclosure. As shown in FIG. 7B, after host 602 recognizes that patient device 604 includes self-isolating patient device 708 and thus does not require isolated power, host 602 provides power through separate conductor 710. Since the power is not isolated, memory 702 can also impose power requirement conditions on host 602, which may be selected from among two or more voltage or power levels. In FIG. 7B, host 602 provides some high power, such as about 12 volts, but can have a wide range of voltages or very high power, such as about 24 volts or more, and can have a wide range of voltages for patient device 708. One of ordinary skill in the art will recognize that the power supply voltage can advantageously be varied to substantially meet the specific requirements of any device 708, and / or that the memory can supply information to host 602 that has supplied wide range non-isolated power to patient device 708.

[0050] Further, by using memory 702, host 602 can determine not to simply make available any unused power, regardless of whether it is an isolated power source or one or more of higher voltage non-isolated power sources, thereby increasing the efficiency of the host.

[0051] Figure 8 shows a simplified exemplary universal medical connector configuration process 800 according to an embodiment of the present disclosure. As shown in Figure 8, this process includes step 802, where a cable is attached to a universal medical connector incorporating optional patient isolation as disclosed in the above description. In step 804, the host device 602 or hub 100, more specifically, the channel data board 316 of the instrument board or the EPROM reader, reads the data stored in the memory 702, and in step 806, determines whether the connected device requires an isolated power supply. In step 808, when an isolated power supply is required, the hub 100 preferably enables the use of an isolated power supply, and in step 810, may enable isolated communication. In step 806, when an isolated power supply is not required, the hub 100 simply enables the use of a non-isolated power supply in an optional step 812, and in an embodiment where the communication remains isolated, may enable isolated communication in step 810. In other optional embodiments, in step 806, when an isolated power supply is not required, the hub 100 may determine the amount of power required for the patient device 708 using the information from the memory 702 in step 814. When sufficient power is not available, for example, because other connected devices are also using the connected power supply, a message indicating that the power supply and power are not provided may be displayed in step 816. When sufficient power is available, it may be possible to enable the use of a non-isolated power supply in an optional step 812. Alternatively, in an optional step 818, it may be determined whether the memory 702 indicates that higher or lower power is desired. When higher power is desired, the hub 100 may enable the use of higher power in step 820, and when not, may enable the use of lower power in step 822. Then, the hub 100 enables isolated communication in step 810. In one embodiment, the hub 100 simply determines in step 818 how much power is required and may supply at least sufficient power to the self-isolating device 708.

[0052] One skilled in the art can determine whether sufficient power is available for the hub 100 from the disclosure herein, or based on the information from the memory 702, it may supply one, two, or multiple levels of non-isolated voltage.

[0053] Figures 9A and 9B show simplified block diagrams showing an exemplary universal medical connector 900 having a smaller cross-sectional size and cross-sectional shape compared to conventional isolation requirements. In one embodiment, the connector 900 physically separates the non-isolated signals on one side 910 from the isolated signals on the other side 920, but these sides can be reversed. The gap during such separation can be at least partially defined by safety rules defining patient isolation. In one embodiment, the distance between side 910 and side 920 may appear to be too small.

[0054] As can be seen from the different perspective views of Figure 9B, the distance "x" between the connectors appears to be small. However, with this gap, this distance includes an indirect path between the conductors. For example, a short must travel through path 904, and the distance of such a path is within or greater than the scope of such safety rules in that the distance is greater than "x". The non-linear path 904 occurs throughout the connector, for example, on the board connector side where solder connects various pins to the PCB board, which is worthy of note.

[0055] Figure 10 shows a perspective view of the side of the hub 100 of Figure 1 showing an exemplary instrument-side channel input 1000 as an exemplary universal medical connector. As shown in Figure 10, the input includes a non-isolated side 910, an isolated side 920, and a gap. In one embodiment, the memory 702 communicates through the pins on the non-isolated side.

[0056] Figures 11A - 11K show various views of an exemplary male universal medical connector and a mating female universal medical connector according to embodiments of the present disclosure. For example, FIGS. 11G1 and 11G2 show various preferred, but not necessary, sizing settings, and FIG. 11H shows incorporating electronic components such as memory 702 into the connector. FIGS. 11I - 11K illustrate wiring diagrams and cable routing details of the cable itself when connecting to the universal medical connector.

[0057] FIG. 12 shows a simplified block diagram depicting a channel system for the hub of FIG. 1 according to an embodiment of the present disclosure. As shown in FIG. 12, the male cable connector as shown in FIG. 11 above includes a memory such as an EPROM. The memory advantageously stores information describing the type of data that hub 100 may expect to receive and how to receive it. The controller of hub 100 communicates with the EPROM to negotiate how to receive the data and, if possible, how to display the data on display 104, alarms when necessary, and the like. For example, a medical device supplier may contact the hub provider and receive a software development kit ("SDK") that gives the supplier guidance on how to describe the type of data output from the device. After working with the SDK, a map, image, or other translation file may advantageously be loaded into the EPROM, and further, the power requirements and isolation requirements described above may also be loaded. When the channel cable is connected to hub 100 through channel port 212, hub 100 reads the EPROM and the controller of hub 100 negotiates how to process the incoming data.

[0058] FIG. 13 shows an exemplary logical channel configuration that can be stored in the EPROM of FIG. 12. As shown in FIG. 13, each incoming channel describes one or more parameters. Each parameter can describe anything that the hub 100 should know about the incoming data. For example, the hub 100 may want to know whether the data is streaming data, waveform data, already determined parameter measurement data, a range on the data, the data delivery speed, the unit of the data, the step of the unit, the color to display, alarm parameters and thresholds including complex algorithms for alarm calculation, other events driven by parameter values, combinations thereof, or the like. In addition, the parameter information may include a device delay time to assist in data synchronization or an approximation of data synchronization between the parameters or other data received by the hub 100. In one embodiment, the SDK presents a self-describing schema for the type and order of incoming data to the device supplier. In one embodiment, this information preferably negotiates with the hub 100 to determine whether to apply compression and / or encryption to the incoming data stream.

[0059] Such an open architecture preferably enables the device manufacturer to port the output of the device to the hub 100 for display, processing, and data management as disclosed in the foregoing description. Through implementation via a cable connector, the device manufacturer avoids reprogramming its original device and rather simply informs the hub 100 how the existing output is formatted through the cable connector. Further, by describing the data in a language already understood by the hub 100, the hub 100 also avoids upgrading the software to accommodate data from medical devices that are "new to the hub".

[0060] Figure 14 shows a simplified exemplary process for constructing a channel according to an embodiment of the present disclosure. As shown in Figure 14, the hub provider provides the SDK to the device manufacturer in step 1402, and then the manufacturer uses the SDK to self-describe the output data channel from the device in step 1404. In one embodiment, the SDK is a series of questions that serve as development guidelines, and in other embodiments, the SDK provides a language and schema for describing data behavior.

[0061] After the device provider has described the data, the hub provider creates a binary image or other file in step 1405 that is stored in the memory within the cable connector, although the SDK could create the image and simply transmit it to the hub provider. The cable connector is provided to the provider as an OEM part in step 1410, and the provider fabricates and manufactures the cable in step 1412 to mechanically and electrically mate with the output port on the device.

[0062] After the caregiver obtains a properly manufactured cable where one end matches the device provider's system and the other OEM end matches the hub 100 at its channel port 212, in step 1452, the caregiver can connect the hub between the devices. In step 1454, the hub 100 reads the memory, supplies isolated or non-isolated power, and the cable controller and the hub 100 negotiate a protocol or schema for data delivery. In one embodiment, the controller on the cable may negotiate the protocol, and in an alternative embodiment, the controller of the hub 100 negotiates a specific protocol with other processors on the hub. After the protocol is set, the hub 100 can use, display, and process the incoming data stream in an intelligent manner.

[0063] By using the universal medical connector described herein, there are numerous devices that can be connected to the hub 100 through direct programming of the cable connector, as opposed to requiring software upgrades for each device.

[0064] FIG. 15 shows a perspective view of the hub of FIG. 1, including an exemplary attached board-in cable (“BIC”) for forming an input channel, according to one embodiment of the present disclosure. As shown in FIG. 15, the SEDLine depth of consciousness board transmits data from appropriate patient sensors to the hub 100 for display and review by the caregiver. As described, the board provider may simply use the SDK to describe the data channel, and the hub 100 understands how to present the data to the caregiver.

[0065] FIG. 16 shows a perspective view of the back of the hub 100 of FIG. 1, showing an exemplary serial data input. In one embodiment, the input includes, for example, an RJ45 port. As is understood in the art, these ports include data ports similar to those on computers, network routers, switches, and hubs. In one embodiment, a plurality of these ports are used to associate data from various devices with a particular patient identified at the hub 100. FIG. 16 also shows a speaker, a nurse call connector, an Ethernet® connector, a USB, a power connector, and a medical ground terminal.

[0066] FIG. 17A shows an exemplary monitoring environment that communicates through the serial data connection of the hub 100 of FIG. 1 according to one embodiment of the present disclosure. As shown and as disclosed in the foregoing description, the hub 100 may use the serial data port 210 to collect data from various devices within the monitoring environment, including an electronic bed, an infusion pump, a ventilator, a vital sign monitor, and the like. The difference between the data received from these devices and the data received through the channel port 212 is that the hub 100 may not know the format or structure of this data. The hub 100 may not be able to display the information from this data or use this data for calculation or processing. However, by porting the data through the hub 100, the data is conveniently associated with the patient being specifically monitored throughout the caregiver system chain, including the aforementioned server 204 and end system 206. In one embodiment, the hub 100 may be able to determine sufficient information regarding the incoming data to attempt to synchronize that data with the data from the hub 100.

[0067] In FIG. 17B, the control screen may provide information regarding the type of data being received. In one embodiment, a green light next to the data indicates the connection to the device and the serial input where the connection is made.

[0068] FIG. 18 shows a simplified exemplary patient data flow process according to an embodiment of the present disclosure. As illustrated, when a patient is admitted and enters a caregiver environment at step 1802, data regarding the patient is written to the caregiver backend system 206. The server 204 may advantageously obtain or receive this information at step 1804 and then make it accessible from the hub 100. When a caregiver assigns the hub 100 to a patient at step 1806, the caregiver simply looks at the currently available patient data and selects the particular patient currently being monitored. The hub 100 then associates the measurements, monitoring, and treatment data it receives and determines with that patient at step 1808. The caregiver does not need to reassign another device to the patient as long as that device is communicating through the hub 100 using (1) a docking station, (2) a universal medical connector, (3) a serial data connector, or (4) other communication mechanisms known to those skilled in the art. At step 1810, some or all of the received, processed, and / or determined data is passed to the server system described above.

[0069] Figures 19A through 19J illustrate exemplary displays of anatomical graphics for a portable patient monitor docked to the hub 100 of FIG. 1. As shown in FIG. 19A, the heart, lungs, and respiratory system are shown while the brain is not highlighted. Thus, a caregiver can readily determine that the depth of consciousness monitoring or brain oxygen measurement system is not currently communicating with the hub 100 via the portable patient monitor connection or the channel data port. However, it is likely that acoustic or other respiratory data and heart data are being transmitted to or measured by the hub 100. Additionally, the caregiver can readily determine that no alarm occurrence data is being received regarding the body part highlighted by the hub 100. In one embodiment, the highlighted portion may be an animated video so as to show the currently measured behavior, or alternatively, may be an animated video in a predetermined pattern.

[0070] FIG. 19B shows the addition of a virtual channel indicating a health metric. As shown in FIG. 19B, this metric is positive as it is "34" on a severity scale that gradually increases up to "100". The health metric can also be shaded to indicate a problem. In contrast to FIG. 19B, FIG. 19C shows a health score that is becoming a problem or has become a problem, and an alarm occurrence heart graphic. Thus, by a caregiver responding to a patient alarm on the hub 100 or otherwise responding on another device or system where the patient is being monitored or treated, it can be quickly determined that a reexamination of vital signs and other parameters related to heart function is necessary to diagnose and / or treat the patient.

[0071] FIGS. 19D and 19E show the brain included in the highlighted body part, which means that the hub 100 is receiving data related to brain function, such as, for example, depth of sedation data or brain oxygen measurement data. FIG. 19E additionally shows an alarm occurrence heart function similar to that of FIG. 19C.

[0072] In FIG. 19F, additional organs such as the kidneys are being monitored, but the respiratory system is not. In FIG. 19G, the alarm-generating cardiac function is illustrated, and in FIG. 19H, the alarm-generating circulatory system is illustrated. FIG. 19I shows health indicators along with the lungs, heart, brain, and kidneys. FIG. 19J shows the lungs, heart, and circulatory systems where an alarm has occurred, as well as health indicators. Further, FIG. 19J shows severity contrasts, for example, the heart generating an alarm in red for an emergency situation and the circulatory system generating an alarm in yellow for an attention warning. One skilled in the art will recognize that there are other color schemes that are appropriate from the disclosure herein.

[0073] Figures 20A - 20C show exemplary displays of measurement data showing data separation and data overlap, respectively, according to embodiments of the present disclosure. Figures 21A and 21B also show exemplary displays of measurement data showing data separation and data overlap, respectively, according to embodiments of the present disclosure.

[0074] For example, acoustic data from an acoustic sensor can advantageously provide respiratory sound data, but plethysmograph and ECG or other signals can also be posted in separate waveforms (top of the screen capture in FIG. 20A). The monitor can determine any of a variety of respiratory parameters of a patient, including respiratory rate, expiratory flow, tidal volume, minute volume, apnea duration, breath sounds, rales, ronchi, wheezing, and changes in breath sounds such as a decrease or change in the volume of air flow. In addition, in some cases, the system monitors other physiological sounds such as heart rate, heart sounds (S1, S2, S3, S4, and heart murmurs), and changes in heart sounds from normal to heart murmurs or split heart sounds indicating fluid overload, which assist in probe-off detection.

[0075] By providing visual correlations between multiple physiological signals, the signals can bring a number of valuable advantages with several observable physiological correlations. As an example of such a correlation, changes in the morphology (e.g., envelope and / or baseline) of a plethysmograph signal can indicate the level of a patient's blood or other body fluids. Also, these changes can be monitored to detect a state of decreased blood volume or other body fluid level relationships. For example, the pulse wave variability index can provide an indication of the body fluid level. Also, changes in the morphology of the plethysmograph signal are correlated with respiration. For example, changes in the envelope and / or baseline of the plethysmograph signal are correlated with respiration. This is due, at least in part, to aspects of the human anatomical structure such as the mechanical relationship and interaction between the heart and lungs during respiration.

[0076] Accordingly, by overlaying the plethysmograph signal and the respiration signal (Figure 20B), an operator can obtain an indicator of the effectiveness of the plethysmograph signal or a signal derived therefrom, such as the pulse wave variability index. For example, if the bursts in the respiration signal indicating inhalation and exhalation are correlated with the changes in the peaks and valleys of the plethysmograph envelope, this gives the monitoring personnel a visual indication that the plethysmograph changes are actually due to respiration and not due to some other background factor. Similarly, when the bursts in the respiration signal are aligned with the peaks and valleys within the plethysmograph envelope, this provides the monitoring personnel with an indication that the bursts in the respiration signal are due to the patient's breath sounds and not due to some other non-target sound (e.g., patient non-breath sounds or non-patient sounds).

[0077] The monitor may also be configured to process the signals to determine whether there is a correlation threshold level between the two signals or to evaluate the correlation in some other way. However, this display provides the operator with a continuous, intuitive, and easily observable measure of a particular physiological correlation, such as by showing signals that are superimposed on one another, in addition to providing a visual indication of the correlation. For example, by viewing the superimposed signals, the user can observe trends in the correlation over time that might not otherwise be discernible.

[0078] The monitor can show visual correlations of a wide variety of other types of signals instead of, or in addition to, the plethysmograph and respiratory signals. For example, FIG. 20C shows a screen shot of another exemplary monitoring display. As shown in the upper right portion of FIG. 20C, this display superimposes a plethysmograph signal, an ECG signal, and a respiratory signal. In other configurations, more than three different types of signals can be superimposed on one another.

[0079] In one embodiment, the hub 100 provides an interface that allows the user to move the signals together so that they overlap one another. For example, the user may be able to use a touch screen interface to drag and drop the respiratory signal onto the plethysmograph signal. Conversely, the user may also be able to use the touch screen interface to separate the signals. In another embodiment, the monitor includes buttons that the user can press or some other user interface that allows the user to superimpose and separate the signals as needed. FIGS. 21A and 21B show similar separation and connection of those signals.

[0080] In some configurations, in addition to providing a visual correlation between the plethysmograph signal and the respiratory signal, the monitor is further configured to process the respiratory signal and the plethysmograph signal and determine the correlation between these two signals. For example, the monitor may process these signals to determine whether the peaks and valleys of the changes in the envelope and / or baseline of the plethysmograph signal correspond to bursts in the respiratory signal. And in response to determining that there is, or is not, a threshold level of correlation, the monitor may provide some indication to the user. For example, the monitor may provide a graphic indication (e.g., a change in the color of a pulse wave variability index indicator), an audible alarm, or some other indication. The monitor may employ one or more envelope detectors or other suitable signal processing components when making the determination.

[0081] In some embodiments, the system may further provide an audible indication of the patient's breath sounds instead of, or in addition to, the graphic indication. For example, the monitor may include a speaker, or an earpiece (e.g., a wireless earpiece) may be provided to the caregiver for providing an audible output of the patient sounds. Examples of sensors and monitors having such functionality are described in U.S. Patent Publication No. 2011 / 0172561, which is incorporated herein by reference.

[0082] In addition to the advantages described above, presenting both the acoustic signal and the plethysmograph signal on the same display in the manner described allows the caregiver to more easily detect apnea events such as the absence of breathing, the presence of high ambient noise that can degrade the acoustic signal, an inappropriate sensor placement, and the like.

[0083] Figures 22A - 22B show exemplary analog displays according to an embodiment of the present disclosure. As shown in Figures 22A and 22B, the screenshots display health indicators of various physiological parameters in addition to other data. Each health indicator can include an analog indicator and / or a digital indicator. In embodiments where the health indicator includes analog and digital indicators, the analog and digital indicators can be positioned in any number of arrangements, such as adjacent, above, below, transposed, etc. In the illustrated embodiment, the analog indicator is positioned above and adjacent to the digital indicator. As more clearly shown in Figure 22B, the analog display can include a colored warning section, dashes indicating positions on the graph, and digital information specifying quantitative information from the graph. In Figure 22B, for example, the pulse rate PR graph indicates that there is a pulse of approximately 50 to approximately 140 beats per minute. The graph is neutral or starting to become a matter of concern, but other than these pulse rates, the graph is colored to indicate a critical condition. Thus, as the dash moves along the arc, the caregiver can easily confirm where the current measurement result falls within the acceptable, attention, and crisis ranges.

[0084] Each analog indicator of the health indicator can comprise a dial that moves along an arc based on the measured level of the physiological parameter being monitored. As the measured physiological parameter level increases, the dial moves clockwise, and as the measured physiological parameter level decreases, the dial can move counterclockwise or vice versa. In this way, the user can quickly determine the patient's situation by looking at the analog indicator. For example, when the dial is at the center of the arc, the observer can confirm that the current physiological parameter measurement result is normal. When the dial is tilted too far to the left or right, the observer can quickly assess the severity of the physiological parameter level and take appropriate measures. In other embodiments, a normal parameter measurement result can be indicated when the dial is on the right or left, etc.

[0085] In some embodiments, the dial may be implemented as a dot, dash, arrow, or the like, and the arc may be implemented as a circle, spiral, pyramid, or other shape as desired. Further, based on the current physiological parameter measurement level, the entire arc may be lit, or only a portion of the arc may be lit. Additionally, the arc may change color or be highlighted based on the current physiological parameter level. For example, as the dial approaches a threshold level, the arc and / or the dial can change from green to yellow, red, become brighter, blink, expand, move to the center of the display, or undergo similar changes.

[0086] Different physiological parameters can have different thresholds indicating abnormal states. For example, some physiological parameters may raise the lower threshold level, while other parameters only have an upper or lower threshold. Thus, each health metric can be adjusted based on the physiological parameters being monitored. For example, the SpO2 health metric can have a lower threshold that activates an alarm when met, and the respiratory rate health metric can have both lower and upper thresholds, with an alarm being activated when either is met. The thresholds for each physiological parameter may be based on standard values, expected thresholds, and / or user-specified thresholds.

[0087] Digital metrics can provide a numerical representation of the current level of a physiological parameter, can indicate the actual level or a normalized level, and can also be used to quickly assess the severity of a patient's condition. In some embodiments, the display includes multiple health metrics for each monitored physiological parameter. In some embodiments, the display includes fewer health metrics than the number of monitored physiological parameters. In such embodiments, the health metrics can cycle among different monitored physiological parameters.

[0088] Figures 23A - 23F show exemplary displays of measurement data representing, for example, the data of Figures 23A - 23D when the depth - of - consciousness monitor is connected to the channel port of the hub of FIG. 1. As shown in Figures 23A - 23C, the hub 100 advantageously approximately branches its display 104 to show, for example, various information from a SEDLine device commercially available from Masimo Corp. of Irvine, California. In Figure 23D, the hub 100 includes an attached PhaseIn device commercially available from PHASEIN AB of Sweden, which provides, for example, information regarding a patient's respiration. The hub 100 also includes SEDLine information and thus appropriately divides the display 104. In Figure 23E, a temperature and blood - pressure sensor communicate with the hub of FIG. 1, and the hub 100 creates an appropriate display occupancy area therefor. In Figure 23F, an acoustic sensor also communicates with the hub of FIG. 1 and further communicates with the aforementioned blood - pressure and temperature sensors. Thus, the hub 100 adjusts the display occupancy area to accommodate data from each attached device.

[0089] As used herein, the phrase “and / or” has the broadest, least - restrictive meaning, which means that the disclosure includes only A, only B, both A and B together, or either A or B in an alternative, without requiring both A and B or requiring only one of A or B. As used herein, the phrase “at least one of A, B, and C” should be interpreted to mean logical A or B or C using an inclusive disjunction.

[0090] The term “plethysmograph” includes its ordinary broad meaning as known in the art, including data responsive to changes in volume within an organ or the body as a whole (usually resulting from fluctuations in the amount of blood or air it contains).

[0091] III. Additional Monitoring Environment Embodiments FIG. 24 illustrates another embodiment of the monitoring environment 2000 that includes the hub 100 of FIG. 1. The monitoring environment 2000 can include any of all the features of the monitoring environment 200 of FIG. 2, as well as other features described above. In addition thereto, the monitoring environment 2000 shows another embodiment of the plurality of patient monitoring systems 204, namely, a plurality of patient monitoring systems (MMS) 2004. The MMS 2004 includes a translation module 2005 that can receive serial data, translate the serial data into a format recognizable by the monitoring hub 100, and provide the serial data to the monitoring hub 100 (and optionally between other devices). An auxiliary device 2040 that can communicate with the MMS 2004, the monitoring hub 100, or the PPM 102 in a wired or wireless manner is also shown.

[0092] As described above, the hub 100 can receive serial data from a variety of medical devices, including a patient's bed 214, an infusion pump 216, a ventilator 218, and other vital sign monitors 220. The hub 100 can pass the serial data from these sources to the MMS 2004. As described above, the MMS 2004 can then also store the serial data in a caregiver backend system 206, such as an EMR system or an ADT system.

[0093] Serial data may, for example, have known data types defined based on the SDK described above. When serial data is supplied from a medical device, the hub 100 or MMS 2004 can easily identify its data type and frequency. Exemplary data types may include (1) waveform data or high-frequency data, (2) parameter data, and (3) event data. Advantageously, in some embodiments, instead of having a large database containing various data types, the database may be designed based on known data types. The data acquisition process may vary based on the data type. For example, when the data is waveform data or high-frequency data, the hub 100 or MMS 2004 may not attempt to recover losses when the data comes in from the medical device. Rather, any received data can be streamed as it is acquired and stored in the database. Parameter data can enter (into the hub 100 or MMS 2004) at a specific frequency (e.g., every 1 Hz). As a result, the hub 100 or MMS 2004 can take a snapshot of the data at that frequency. Event data, such as patient alarms (and optionally, parameter data associated with the alarms), can be generated in response to specific events. The event data may include a timestamp that can be associated with the time when the data was taken or the time of the event. In addition or alternatively, the hub 100 or MMS 2004 can also receive audio or video data associated with the patient.

[0094] Medical devices that provide this serial data may use a wide variety of different proprietary protocols, messaging infrastructures, and the like that may not be natively recognizable by the hub 100. Thus, the hub 100 need not have a native function to read parameter values or other data from this medical device, and as a result, need not have a function to display parameter values or other data from these devices. Advantageously, however, the translation module 2005 in the MMS 2004 can receive serial data from these devices, translate the serial data into a format recognizable by the monitoring hub 100, and provide the serial data to the monitoring hub 100. The monitoring hub 100 can then read parameter values and other data from the translated information and output these values or data to a display, such as any of the displays described above.

[0095] In one embodiment, the translation module 2005 applies one or more translation rules to the serial data and translates or converts the serial data from one format to another. The serial data may be formatted according to the Health Level Seven ( "HL7") protocol in one embodiment. The HL7 protocol has been developed to provide a messaging framework for the communication of clinical messages between medical computer systems and devices. However, the HL7 standard is extremely flexible and only provides a framework of guidelines. As a result, all HL7-compliant medical devices or clinical computer systems may still not be able to communicate with each other. For example, the medical devices 214-220 may each implement a version of the HL7 protocol, but these implementations may differ from the HL7 protocol implemented by the monitoring hub 100. Therefore, even though both use the HL7 standard, the monitoring hub 100 may not be able to analyze or read messages from the medical devices 214-220. Further, the translation module 2005 may be translated between different implementations of a common standard that differ from the HL7 protocol implemented by the hub 100 and the medical devices 214-220 in some embodiments.

[0096] In addition to translation between different implementations of a common electronic medical communication protocol (e.g., different formats of HL7 messages), the translation module 2005 can also perform translation between input and output messages that follow different communication protocols. In some embodiments, the translation module 2005 can, for example, respond to a message from one medical communication protocol and translate it to a separate medical communication protocol. For example, the translation module 2005 can facilitate communication between messages sent according to the HL7 protocol, the ISO11073 protocol, other open protocols, or proprietary protocols. Thus, the translation module 2005 can translate an input message sent according to the HL7 protocol into an output message that follows a different protocol, or vice versa. In some embodiments, the translation module 2005 can implement any of the translation features described in more detail in the section entitled "Translation Module Embodiments" below, and further in U.S. Application No. 14 / 032,132, filed September 19, 2013, entitled "Medical Monitoring System", the disclosure of which is hereby incorporated by reference in its entirety.

[0097] Advantageously, in some embodiments, the translation module 2005 can feed back the translated serial data to the hub 100 or the PPM 102. Since the translated data is in a format readable by the hub 100 or the PPM 102, the hub 100 or the PPM 102 can output data from the medical devices 214 - 220 onto the display of the hub 100 or the PPM 102. In addition, the translation module 2005 can supply the translated data to devices other than the hub 100, including clinician devices (such as mobile phones, tablets, or pagers) and the auxiliary device 2040 described below. Further, since the serial data supplied by the medical devices 214 - 220 may include alarm notifications, the translation module 2005 can pass these alarm notifications to the hub 100 or the PPM 102. Thus, the hub 100 or the PPM 102 can generate visual or audible alarms in response to these alarm notifications. Additionally, the translation module 2005 can provide alarm notifications to clinician devices, for example, over a hospital network or a wide area network (such as the Internet). In addition, the translation module 2005 can supply alarm notifications to the auxiliary device 2040.

[0098] The translation module 2005 is shown as implemented in the MMS 2004 because it may be beneficial to maintain and update the translation rules of the translation module 2005 within a single location. However, in other embodiments, the translation module 2005 can be implemented in (or instead of) the hub 100 or the PPM 102. Thus, the hub 100 or the PPM 102 can access the internal translation module 2005 to translate the serial data for output to the display of the hub 100 or the PPM 102.

[0099] The auxiliary device 2040 can also be a computing device having physical computer hardware, a display, and the like. For example, the auxiliary device 2040 can be a handheld computing device used by a clinician, such as a tablet, laptop, mobile phone or smartphone, personal digital assistant (PDA), wearable computer (such as a smartwatch or smart glasses), or the like. The auxiliary device 2040 can also simply be a display device, such as a computer monitor or digital TV. In one embodiment, the auxiliary device 2040 provides a second screen function for the hub 100, PPM 102, or MMS 2004. As such, the auxiliary device 2040 can communicate with the hub 100, MMS 2004, or PPM 102 in a wireless manner or through a wired connection.

[0100] As a second screen device, the auxiliary device 2040 can show at least a portion of the display of the hub 100 (or PPM 102) or a copy of a different version of the display of the hub 100 (or PPM 102). For example, the auxiliary device 2040 can receive physiological parameter data, trend data, or waveforms from the hub 100, PPM 102, or MMS 2004 and display the parameter data, trend data, or waveforms. The auxiliary device 2040 can output any information available to the hub 100, PPM 102, or MMS 2004. One use of the auxiliary device 2040 is as a clinician device that can be used by a clinician to view data from the hub 100, PPM 102, or MMS 2004 while away from (or even while in) the patient's room. The clinician can use the auxiliary device 2040 to view detailed information regarding additional physiological parameters displayed on the hub 100 or PPM 102 in one embodiment (see, for example, FIG. 39). For example, the auxiliary device 2040 can include a zoom function or similar function that allows the clinician to zoom in on trends or waveforms and examine parameter activity in more detail.

[0101] One exemplary reason for copying at least a portion of the display of hub 100 or PPM 102 is to enable different clinicians to have the same view of the data during a surgical procedure. For example, in some surgical procedures, two anesthesiologists monitor the patient, one anesthesiologist monitors the patient's brain function and cerebral oxygen supply, and the other monitors the patient's peripheral oxygen supply. A brain sensor as described above can be attached to the patient and provide brain monitoring and oxygen supply data that is output to hub 100 or PPM 102 for presentation to the first anesthesiologist. A finger or toe / foot light sensor can also be attached to the patient and can output data to hub 100 or PPM 102. For example, the light sensor can be attached to the patient's body (e.g., finger, toe, earlobe, forehead, and other locations). The emitter can radiate light through the body tissue, and the detector can receive the light attenuated by the body tissue and measure data of the patient's blood parameters. Hub 100 or PPM 102 can transmit this data to auxiliary device 2040, which the second anesthesiologist can monitor to observe the oxygen supply status in the patient's peripheral limb. The second anesthesiologist may also need to know the oxygen supply to the brain to assist in interpreting the severity or lack of low peripheral oxygen supply values. However, in many surgical procedures, a curtain or screen is placed over the patient as part of the surgery, blocking the second anesthesiologist's view of hub 100 or PPM 102. Accordingly, hub 100 or PPM 102 can output a copy of at least a portion of its display to auxiliary device 2040 so that the second anesthesiologist can monitor the brain function or oxygen supply status.

[0102] In one embodiment, the auxiliary device has a display area that is wider than the display of the hub 100. For example, the hub 100 may have a relatively small display such as about 10 inches, but the auxiliary device 2040 may be similar and have a TV monitor or a display of 40 inches or larger (although any size display may be used for the auxiliary device 2040). In one embodiment, the auxiliary device 2040 as a TV can include a hardware module that includes a processor, a memory, and a wireless or wired networking interface or the like. The processor can execute a program from the memory that includes a program for displaying physiological parameters, trends, and waveforms on the TV display. Since the TV monitor of the auxiliary device 2040 is larger than the embodiment of the hub 100, the TV monitor version of the auxiliary device 2040 can display finer details of the patient waveforms and trends in some embodiments (see, for example, FIG. 39).

[0103] In another embodiment, the auxiliary device 2040 may be configured to display any one of the displays described herein while the hub 100 is displaying another portion. For example, the auxiliary device 2040 may display any one of the anatomical graphics described above with reference to FIGS. 19A-19J while the hub 100 is displaying any one of the parameter displays described above with reference to FIGS. 20A-23F (or vice versa). Similarly, the auxiliary device 2040 may display the translated data received from the translation module 2005 while the hub 100 is displaying channel data (or vice versa). In another embodiment, the auxiliary device 2040 can display both the translated data and the channel data (see, for example, FIG. 38).

[0104] In yet another embodiment, the auxiliary device 2040 can perform at least a portion of the processing of physiological parameters, including any of the functions of the monitoring hub 100. For example, the auxiliary device 2040 may comprise a translation module 2005 and operate to perform its features.

[0105] FIG. 25 illustrates one embodiment of a translation message processing process 2100. The process 2100 may be implemented by the translation module 2005 described above or by any other computing system. In one embodiment, at block 2502, the translation module 2005 receives a message from the hub 110 (or PPM 102) that includes a message from a medical device that does not have native compatibility with the hub 100 (or PPM 102). At block 2504, the translation module 2005 translates the message based on one or more translation rules to create a translated output message that can be processed by the hub 100 (PPM 102). At block 2506, the translation module supplies the translated output message to the hub 100 for display at the hub 100 (or PPM 102) or at the auxiliary device 2040. The hub 100 (or PPM 102) may route the translated data to the auxiliary device 2040, or the auxiliary device 2040 may receive the translated data directly from the translation module 2005.

[0106] For example, in one embodiment, a first medical device having a digital logic circuit receives a physiological signal associated with a patient from a physiological sensor, obtains a first physiological parameter value based on the physiological signal, and outputs the first physiological parameter value for display. The first medical device can also receive a second physiological parameter value from a second medical device different from the first medical device, the second physiological parameter value being formatted according to a protocol not used by the first medical device, whereby the first medical device cannot process the second physiological parameter value to generate a displayable output value. The first medical device passes physiological parameter data from the first medical device to a separate translation module, receives the translated parameter data from the translation module in the first medical device, and the translated parameter data can be processed for display by the first medical device and a second value from the translated parameter data can be output and displayed. The first medical device may be, for example, hub 100, PPM 102, or MMS 2004, and the second medical device may be infusion pump 216 or ventilator 218 or the like.

[0107] Figures 26-38 and 46-71 show additional exemplary hub displays, including displays of measurement data. Each of these displays may be implemented by auxiliary device 2040, although similar displays may also be output directly on hub 100 (or PPM 102). The exemplary figures shown are shown as being implemented for a tablet computer with a touch screen function. The touch screen function is optional and may be replaced by other suitable input devices such as a keyboard, mouse, track wheel, and the like.

[0108] Referring to FIG. 26, the illustrated user interface represents a device connected to the auxiliary device 2040. The illustrated device is "Omar's Hawk", which can be an embodiment of the monitoring hub 100. The auxiliary device 2040 is wirelessly connected to the hub 100 in this embodiment to receive data from the hub 100. In other embodiments, the auxiliary device can also be wirelessly connected to the MMS 2004 or the PPM 102.

[0109] FIG. 27 shows the display of the default parameters on the auxiliary device 2040. The parameter values are shown together with the waveforms in the upper part of the display, and other parameters (such as SpHb, SpMet, PVI, etc.) are shown at the bottom of the display without their corresponding waveforms. Any of these parameters at the bottom of the display can show the waveform by being dragged and dropped to the upper part of the display. For example, FIG. 28 shows a display similar to FIG. 27 except that the SpHb parameter is dragged and dropped to the upper part of the display, showing additional details regarding the SpHb waveform and alarm limits (18 and 7). Similarly, FIG. 29 shows the same display as FIG. 28 except that the SpMet parameter is dragged and dropped to the upper part of the display, showing its waveform and alarm limit (3).

[0110] In each of the displays of FIGS. 27-29, a time window button is shown in the upper right corner. This time window button is shown as "1 hr" in FIGS. 27-29, but can be selected by the user to change the time window, which can affect the trend or waveform data window shown in the display. The user selection of this time window button and the change to a 10-minute window are shown in FIG. 30. As can be seen, the waveforms in FIG. 30 are shown in a smaller time window than in the previous figures.

[0111] FIG. 31 shows another version of the display of FIG. 29 having stacked waveforms, including stacked SpO2 and respiratory waveforms, similar to other stacked waveforms described elsewhere in this specification. FIG. 32 shows a display similar to FIG. 29 in which the pulse rate (PR) and SpMet (methemoglobin) parameters are highlighted as being in an alarm state. The alarm state can be represented, in one embodiment, as a red box around the parameter value and waveform, or by making at least a portion of the box red transparent. The red box or transparency may blink in one embodiment, and an audible alarm may be heard. Other methods of representing the alarm state are used in other embodiments.

[0112] FIG. 33 shows a pop-up interface that allows the user to adjust the alarm limits for a parameter (in this embodiment, SpHb or total hemoglobin). The pop-up interface includes a scroll wheel that allows the user to quickly scroll above the possible parameter limit values and select a value.

[0113] Figures 34 to 38 show a landscape display view in contrast to the portrait display view of FIGS. 26 to 33. These landscape display views can be accessed by rotating the auxiliary device 2040 (such as a tablet) to a landscape orientation. FIG. 34 shows a first set of parameters, while FIGS. 35 and 36 add additional parameters that are dragged and dropped, along with details of waveforms and additional alarm limits, similar to those described above with respect to FIGS. 27 to 29. FIG. 37 shows the stacked parameter waveforms, with the SpO2 and respiratory waveforms stacked. FIG. 38 shows both channel parameters (such as SpO2, PR (pulse rate), and RRa (acoustic measured respiratory rate)), as well as the translated serial data parameters 2210, including parameters from the pump and ventilator. These translated serial data parameters 2210 may be received from the translation module 2005 either through the hub 100 or directly from the MMS 2004.

[0114] Referring back to FIG. 24, as described above, the hub 100 or the PPM 102 can output at least a copy of the display to the auxiliary device 2040. In other embodiments, the hub 100 or the PPM 102 can output data regarding a subset of all the parameters shown on the hub 100 or the PPM 102 to the auxiliary device 2040. For example, the hub 100 or the PPM 102 may be equipped with a function that allows a clinician to select one or more of the parameters shown thereon and view only those one or more parameters displayed on the auxiliary device 2040. By doing so, since fewer parameters are shown on the display of the auxiliary device 2040 compared to the hub 100 or the PPM 102, it may be possible to increase the details shown regarding the one or more selected parameters on the auxiliary device 2040.

[0115] FIG. 39 shows an exemplary display of the auxiliary device 2040 showing data regarding one parameter, namely respiratory rate. Different from the main display of the hub 100 or the PPM 102, the display shown in FIG. 39 includes not only the current value 2215 of the respiratory rate, the recent trend 2230, and small waveforms but more. In addition to that, this display shows a histogram 2220 of the past maximum and minimum values (e.g., of the past few days) of the patient being monitored. In addition to that, a detailed waveform 2240 is illustrated, which may be larger than the waveform shown on the main display of the hub 100 or the PPM 102 and can give the user a more detailed insight into the patient's respiratory state. The user selects to expand the display of the waveform 2240 (or other aspects of the display), whereby the waveform 2242 is expanded to fill the display instead of the other elements of the display or to do something similar. Other graphs, tables, waveforms, and data may be shown for the respiratory parameter on the auxiliary device display 2040. Of course, parameters other than the respiratory rate may also be selected for the detailed display on the auxiliary device 2040. For example, the hub 100 or the auxiliary device 2040 can show the cerebral blood flow while the doctor is performing bypass surgery based on the output of the brain / organ oxygen measurement (BIC) device 224. Advantageously, in some embodiments, the hub 100 or the auxiliary device 2040 can enable the doctor to easily view the cerebral blood flow and have time to confirm the adequacy of proper perfusion to the patient while maintaining the doctor's attention on the bypass circuit.

[0116] IV. Embodiments of the Translation Module Any of the following features described with reference to FIGS. 40A through 45D may be implemented by the translation module 2005 of FIG. 24 or in conjunction with any of the devices described above with reference to FIG. 24.

[0117] Medical costs continue to increase, and the demand for high-quality patient care at affordable prices is also on the rise. Medical costs can be reduced by enhancing the effectiveness of hospital information systems. One factor that can affect the effectiveness of healthcare facilities is the extent to which the various clinical computer systems employed in the healthcare facilities can interact with each other for information exchange.

[0118] Hospitals, patient treatment facilities, and healthcare providers typically have a variety of different clinical computer systems for managing electronic medical information. Each of the clinical computer systems in the overall IT or management infrastructure can assist in performing a specific category or aspect of the patient treatment process. For example, a hospital can include a patient monitoring system, a medical documentation and / or imaging system, a patient management system, an electronic medical record system, an electronic medical practice management system, business and financial systems (such as pharmacy benefits and billing), and / or a communication system, etc.

[0119] The quality of care in a hospital or other patient treatment facility can be improved if each of the different clinical computer systems spanning the IT infrastructure (or even within the same hospital ward, see, for example, FIGS. 1 and 24) can communicate effectively with each other. This can enable the patient data collected by one clinical computer system to interact with another clinical computer system that can utilize such patient data. For example, this can enable decisions regarding patient treatment and the taking of measures based on a complete analysis of all available information.

[0120] In current practice, individual clinical computer systems can be provided by different vendors and are often provided that way. As a result, individual clinical computer systems may be implemented using a dedicated network or communication infrastructure, a dedicated communication protocol, etc., and the various clinical computer systems used in a hospital may not necessarily be able to communicate effectively with each other.

[0121] Medical device and healthcare system vendors sometimes develop proprietary systems that cannot effectively communicate with other vendors' medical devices and systems in order to increase market share and sell additional products, systems, and / or upgrades at a premium to healthcare providers. As a result, healthcare providers are forced to make enterprise-wide or system-wide purchasing decisions rather than select the best available technology for each type of individual clinical computer system they use.

[0122] One example of where this occurs is in the area of life-saving technology available for patient monitoring. For example, many different bedside devices for monitoring various physiological parameters are available from different vendors or providers. One such provider may offer the top-of-class device for monitoring a particular physiological parameter, while another such provider may offer the top-of-class device for another physiological parameter. Thus, in some situations, it may be desirable for a hospital to have the freedom to use monitoring devices from multiple manufacturers, but this may not be possible if devices from different manufacturers do not have an interface for patient information and cannot communicate with each other. Thus, the ability to provide high-quality patient treatment at an affordable price may be impaired. In addition, since each hospital or patient treatment facility may also implement its own proprietary communication protocol for the clinical computer network environment, information exchange can be further hampered.

[0123] As described above, the Health Level Seven ("HL7") protocol has been developed to provide a messaging framework for the communication of clinical messages between medical computer systems and devices. The HL7 communication protocol defines a number of standards, guidelines, and methods that various HL7-compliant clinical computer systems can use to communicate with each other.

[0124] The HL7 communication protocol has been adopted by many medical device manufacturers. However, the HL7 standard is extremely flexible and only provides a framework of guidelines (e.g., the high-level logical structure of messages). As a result, each medical device or medical system manufacturer or vendor may implement the HL7 protocol in somewhat different ways while still being HL7 compliant. For example, the format of HL7 messages may vary from implementation to implementation, as will be described in more detail herein. In some cases, an HL7 message in one implementation form may also contain information content not included in the message by another HL7 implementation form. Therefore, all HL7-compliant medical devices or clinical computer systems may still not be able to communicate with each other.

[0125] As a result, a translation module may be provided that can improve the communication of medical messages between medical devices or systems that use different permitted implementation forms of an established communication protocol (e.g., HL7), thereby enhancing the quality of patient care through the integration of multiple clinical computer systems.

[0126] FIG. 40A shows a first medical device 2405 and a second medical device 2410 communicating with each other via a translation module 2415. The first medical device 2405 is configured to transmit and receive messages according to a first permitted format or implementation form of an accepted electronic medical communication protocol, while the second medical device 2410 is configured to transmit and receive messages according to a second permitted format or implementation form of the electronic medical communication protocol. In some embodiments, the first and second protocol formats are different implementation forms of the HL7 communication protocol. Other electronic medical communication protocols other than HL7 can also be used.

[0127] The translation module 2415 receives an input message having a first protocol format from the first medical device 2405 and generates an output message to the second medical device 2410 having a second protocol format. The translation module 2415 also receives an input message having the second protocol format from the second medical device 2410 and generates an output message to the first medical device 2405 having the first protocol format. Thus, the translation module 2415 can enable the first and second medical devices 2405, 2410 to communicate effectively and seamlessly with each other without necessarily requiring modifications to the communication devices or protocols implemented by each device.

[0128] In some embodiments, the translation module 2415 determines the expected protocol format, for example, based on information within the input message by the intended recipient of the input message or by referring to a database storing protocol formats used by various devices, and then generates an output message based on the protocol format used by the intended recipient device or system. The output message can be generated based on comparison and application with a set of translation rules 2420 accessible by the translation module 2415.

[0129] The translation module 2420 can comprise rules that determine how to handle changes that may occur between formatting implementations within a common protocol. Examples of changes in formatting implementations of electronic medical communication protocols include, for example, the delimiter or separator characters used to delimit data fields, whether a particular field is mandatory or optional, the repeatability of a portion of the message (e.g., segments, fields, components, sub-components), the order of a portion of the message (e.g., the order of fields or components), whether a particular portion of the message is included, the length of the message or a portion of the message, and the data types used for various portions of the message.

[0130] In some embodiments, translation rule 2420 defines the additions, deletions, swapping, and / or modifications to be performed to "translate" an input message conforming to a first HL7 implementation form into an output message conforming to a second HL7 implementation form. The output message can have, for example, a formatting different from that of the input message while maintaining all or part of the substance or content of the input message.

[0131] In addition to translation between different implementations of a common e - healthcare communication protocol (e.g., different formats of HL7 messages), translation module 2415 can also perform translation between an input message and an output message conforming to different communication protocols. In some embodiments, translation module 2415 can, for example, respond to a message from one healthcare communication protocol and translate it into a separate healthcare communication protocol. For example, translation module 2415 can facilitate communication between messages sent according to the HL7 protocol, the ISO11073 protocol, other open protocols, and / or proprietary protocols. Thus, an input message sent according to the HL7 protocol can be translated into an output message conforming to a different protocol, or vice versa.

[0132] The operation of translation module 2415 and translation rule 2420 will be described in more detail below. Next, various embodiments of the system architecture including translation module 2415 will be described.

[0133] In some embodiments, the first medical device 2405, the second medical device 2410, and the translation module 2415 are communicatively coupled via a connection to a common communication network or directly (e.g., via cable or wirelessly) through, for example, the hub 100, PPM 102, and / or MMS 2004. In some embodiments, the translation module 2415 can be communicatively coupled between the first medical device 2405 and the second medical device 2410 such that all messages between the first medical device 2405 and the second medical device 2410 are routed through the translation module 2415 (either via the communication network or without a communication network). Other architectures are possible.

[0134] The first medical device 2405, the second medical device 2410, and the translation module 2415 can be included, for example, as part of the monitoring environment of FIG. 1 or FIG. 24 described above. The first medical device 2405 can be, for example, an infusion pump 216 or a ventilator 218, while the second medical device 2410 can be, for example, the monitoring hub 100, PPM 102, MMS 2004, or an auxiliary device 2040. The translation module 2415 is an exemplary implementation of the translation module 2005.

[0135] In some embodiments, the translation module 2415 can facilitate communication spanning multiple networks within a hospital environment. In other embodiments, the translation module 2415 can facilitate communication of messages spanning one or more networks extending outside of a hospital or clinical network environment. For example, the translation module 2415 can provide a communication interface with financial institutions, insurance providers, government agencies, external pharmacies, other hospitals, nursing homes, or patient treatment facilities, medical offices, and the like.

[0136] In some embodiments, the translation module 2415 of FIG. 40 can be, for example, a component of the environment 2000 described above with respect to FIG. 24. For example, the translation module 2415 can be communicatively coupled to a hospital network or other network or the monitoring environment described above. In such embodiments, the translation module 2415 can facilitate the exchange of patient monitoring information, including, for example, physiological parameter measurements, physiological parameter trend information, and physiological parameter alarm states, between a bedside medical monitoring device, a monitoring nurse station, a hospital or clinical information system (which may store electronic medical records), and / or many other medical devices and systems. The translation module 2415 can enable seamless communication between different medical devices and systems, each of which may use different implementations of an electronic medical communication protocol, such as the HL7 communication protocol, within a clinical or hospital network environment.

[0137] In some embodiments, the translation module 2415 can also facilitate communication between a first medical device that is part of a patient monitoring subsystem and a second medical device that is not part of or is external to the patient monitoring system 200. As such, the translation module 2415 can be configured to respond to externally generated medical messages (such as patient information update messages, status inquiry messages, and the like from a HIS or CIS) and generate external report messages (such as event report messages, alarm notification messages, and the like from a patient monitor or monitoring nurse station).

[0138] In another embodiment, the first medical device 2405 and the second medical device 2410 communicate with each other over a communication bus 2421. The communication bus 2421 can include any one or more of the communication networks, systems, and methods described above, including the Internet, a hospital WLAN, a LAN, a personal area network, and the like. For example, any of the networks described above can be used to facilitate communication between multiple medical devices, including the first medical device 2405 and the second medical device 2410 described above. Such an embodiment is illustrated in FIG. 40B.

[0139] In FIG. 40B, the first medical device 2405 sends a message over the communication bus 2421. The message is intended to be received by the second medical device 2410, but since the first medical device 2405 and the second medical device 2410 communicate according to different communication protocol formats, the second medical device 2410 cannot process the message.

[0140] The translation module 2415 monitors the communication bus 2421 for such messages. The translation module receives the message and determines that the first medical device 2405 is attempting to communicate with the second medical device 2410. The translation module 2415 determines that message translation will facilitate communication between the first medical device 2405 and the second medical device 2410. Accordingly, the translation module 2415 utilizes the appropriate translation rules stored in the translation module 2420. The translation module 2420 can comprise a memory, an EPROM, a RAM, a ROM, and the like.

[0141] Translation module 2415 translates messages from the first medical device 2405 according to any of the methods described herein. After translation, the translation module 2415 distributes the translated messages to the communication bus 2421. The second medical device 2410 receives the translated messages and responds accordingly. For example, the second medical device may perform a function of communicating with the first medical device 2405 and / or attempt to communicate. The translation module 2415 facilitates communication from the second medical device 2410 to the first medical device 2405 in a similar manner.

[0142] The first medical device 2405 and the second medical device 2410 can be any of the medical devices or systems communicatively coupled to, for example, a hospital network or hub 100, PPM 102, and / or MMS 2004. These medical devices or systems can include, for example, a medical act occurrence time management device (such as a bedside patient monitor), a data storage unit or patient record database, a hospital or clinical information system, a centralized monitoring room (such as a monitoring nurse station), and / or a clinician device (such as a pager, mobile phone, smartphone, personal digital assistant (PDA), laptop, tablet PC, personal computer, pod, and the like).

[0143] In some embodiments, the first medical device 2405 is a patient monitor communicatively coupled to a patient to track physiological parameters (such as oxygen saturation, heart rate, blood pressure, etc.), and the second medical device 2410 is a hospital information system ("HIS") or a clinical information system ("CIS"). In some embodiments, the patient monitor can transmit physiological parameter measurement results, physiological parameter alarms, or other physiological parameter measurement result information generated during patient monitoring to the HIS or CIS for inclusion in the patient's electronic medical record maintained by the HIS or CIS.

[0144] In some embodiments, the first medical device 2405 is a HIS or CIS, and the second medical device 2410 is a monitoring nurse station, as described herein. However, the translation module 2415 can facilitate communication between a wide variety of medical devices and systems used in a hospital or other patient treatment facility. For example, the translation module 2415 can facilitate communication between patient physiological parameter monitoring devices, between a monitoring device and a monitoring nurse station, etc.

[0145] By using the translation module 2415, a patient monitoring subsystem (e.g., the physiological monitoring system 200) as described herein can push data to, or pull data from, the HIS even if the HIS is using a different implementation of the HL7 protocol or some other electronic medical communication protocol.

[0146] In some embodiments, the patient monitoring subsystem can be configured to push / pull data at predetermined intervals. For example, a patient monitor or clinical monitoring station can automatically download patient data from the HIS at regular intervals so that patient data is already available when the patient is connected to the patient monitor. Patient data transmitted from the HIS can include admission / discharge / transfer (``ADT'') information received after the patient's registration. The ADT message is initiated by the hospital information system and can inform an auxiliary system, e.g., that a patient has been admitted, discharged, transferred, or registered, that patient information has been updated or merged, or that a transfer or discharge has been cancelled.

[0147] In other embodiments, the patient monitoring subsystem may be configured to push / pull data to / from the HIS only when the HIS is billed by an inquiry. For example, a clinician may make a request for information stored in the patient's electronic medical record on the HIS.

[0148] In yet other embodiments, the patient monitoring subsystem may be configured to push / pull data to / from the HIS in response to non-billing events. For example, the physiological parameters of a monitored patient may enter an alarm state, which may be automatically transmitted to the HIS and stored in the patient's electronic medical record. In still other embodiments, any combination of the above methods or alternative methods may be employed to determine when to communicate messages to / from the HIS.

[0149] Exemplary system architectures and exemplary triggers for the communication of messages with the translation module 2415 have already been described. Next, looking at the operation of the translation module, FIGS. 25A-25D show exemplary medical messages in different phases or steps of the translation process. The translation process will be described in more detail below with respect to FIGS. 26, 27A, and 27B.

[0150] FIG. 41A shows an exemplary ADT input message 2505 received by the translation module 2415 from the HIS. The ADT input message 2505 is implemented according to the HL7 communication protocol and includes information related to the patient's admission to the hospital. The ADT message 2505 includes a plurality of segments including a message header segment 2506, an event segment, a patient identification segment, a patient visit segment, a duty segment, a diagnosis segment, and a plurality of custom segments.

[0151] In some embodiments, the message header ("MSH") segment 2506 defines how the message is sent, field delimiters and encoded characters, message type, sender and recipient, etc. The first symbol or character after the MSH string can define the field delimiter character or separator symbol (in this message, the "caret" symbol). The next four symbols or characters can define the encoded characters. The first symbol defines the component separator symbol ("~"), the second symbol defines the repeatable separator symbol ("|"), the third symbol defines the escape separator symbol ("\"), and the fourth symbol defines the sub-component separator symbol ("&"). All of these delimiter symbols can vary for each HL7 implementation form.

[0152] In some embodiments, an exemplary header segment 2506 further includes a sending application ("VAFC PIMS"), a receiving application ("NPTF-508"), the date and time of the message ("20091120104609-0600"), the message type ("ADT-A01"), the message control ID ("58103"), the processing ID ("P"), and the country code ("USA"). As represented by consecutive caret symbols, the header segment also includes a plurality of empty fields.

[0153] FIG. 41B shows the message header segment 2506 after being parsed based on the identified field delimiter symbol (caret symbol) and divided into fields or elements. In some embodiments, the parsed input message includes an XML message configured to be transformed according to Extensible Stylesheet Language Transformations (XSLT) rules.

[0154] In some embodiments, the parsed input message can be encoded. FIG. 41C illustrates the parsed message header segment of the input message after being encoded (e.g., using the Unicode Transformation Format-8 ("UTF-8") encoding scheme).

[0155] The symbolized message header segment indicates some of the various data types that can be used within the message. For example, the transmitting application of the third parsed field ("VAFC PIMS") and the receiving application of the fifth parsed field ("NPTF-508") are represented using the hierarchical designator ("HD") name data type. The date and time field (the seventh parsed field) is represented using the timestamp ("TS") data type. The processing ID field (the eleventh parsed field) is represented using the processing type ("PT") data type. Fields that do not contain a data type identifier are represented using the string ("ST") data type. Other possible data types include, for example, coded elements, structured values, timing quantities, text data, dates, input identifiers, coded values, numerical values, and sequence identifiers. The data types used for the various fields or attributes of the segment can vary for each formatting implementation form.

[0156] FIG. 41D shows an exemplary output message 2510 from the translation module 2415 based on the exemplary input message 2505 of FIG. 41A. The output message 2510 includes a message confirmation response segment 2512.

[0157] Looking at the operation of the translation module, the translation module 2415 can create, generate, or form an output message that reflects the input message, for example, based on the application of a set of translation rules 2420. In some embodiments, the translation module 2415 can translate, transform, convert, reformat, configure, change, reconfigure, modify, adapt, alter, or adjust the input message, for example, based on a comparison with and application of a set of translation rules 2420 for forming the output message. In some embodiments, the translation module 2415 can, for example, exchange or substitute the input message with an output message that retains the content of the input message, but has a new formatting implementation based on a comparison with and application of a set of translation rules 2420.

[0158] FIG. 42 shows an exemplary translation process 2600 for generating an output message based on a comparison of an input message with a set of translation rules 2420 associated with the translation module 2415. The translation process 2600 begins at block 2602, where the translation module 2415 receives an input message from a first medical device.

[0159] In block 2604, the translation module 2415 determines the formatting implementation form of the input message and the formatting implementation form to be used for the output message. In some embodiments, the input message can include one or more identifiers indicating the formatting implementation form. In some embodiments, the determination of the formatting implementation form can be made, for example, by analyzing the message itself by identifying delimiter symbols or encoded characters used, field order, segments, fields, or repeatability of components, data types of fields, or other implementation form changes. In some embodiments, the translation module 2415 can assist in determining the formatting implementation form by separating or parsing out the formatting from the content of the message (as shown in FIG. 41B). In some embodiments, the translation module 2415 determines the formatting implementation form of the input message by referring to a database that stores the implementation forms used by each device configured to interface with the translation module 2415.

[0160] In some embodiments, the determination of the formatting implementation form used by the output message can also be made from the input message. For example, the input message can include a field identifying the intended recipient application, facility, system, device, and / or destination. Alternatively, the input message can include a field identifying the type of message being sent (e.g., an ADT message), and the translation module 2415 can determine the appropriate recipient and / or sending application, device, or system from the type of message being sent. The translation module 2415 can then determine the formatting implementation form required by the intended recipient of the input message.

[0161] In decision block 2605, translation module 2415 determines whether the rule set is configured for translation from the identified formatting implementation form of the input message to the identified formatting implementation form to be used for the output message. The rule set may be configured manually before installation of the translation module software or may be configured automatically before receiving the input message. If the rule set is already configured, the translation process 2600 proceeds to block 2606 and continues. If the rule set is not configured, the rule set is configured in block 2607. The configuration of the rule set can be performed as described below with respect to FIGS. 44 and 45A - 45D. Then, the translation process 2600 proceeds to block 2608 and continues.

[0162] In block 2606, translation module 2415 identifies a pre - configured rule from a set of translation rules 2420 that determine the translation between the determined formatting implementation form of the input message and the formatting implementation form of the output message. In some embodiments, the identification of the pre - configured rule can be done manually.

[0163] In block 2608, translation module 2415 generates an output message based on the configured rule set of translation rules 2420. In some embodiments, the output message retains all or at least a portion of the content of the input message but has a format expected and supported by the intended recipient of the input message.

[0164] Translation rule 2420 can include, for example, unidirectional rules and / or bidirectional rules. A unidirectional rule may be applicable, for example, to a message from a first medical device (e.g., 2405) to a second medical device (e.g., 2410), but not to a message from the second medical device to the first medical device. For example, a unidirectional rule can handle differences in delimiters used between fields for two different formatting implementations of the HL7 communication protocol. The translation module 2415 can apply the field delimiter to determine whether the field delimiter of the input message is supported by the intended recipient of the message. If the field delimiter of the input message is not supported by the intended recipient, the field delimiter rule can replace the fields of the input message with a field delimiter supported by the intended recipient.

[0165] For example, an input message from an input medical device can include a formatting implementation that uses the "caret" symbol ("^") as a field delimiter or separator symbol. However, the formatting implementation recognized by the intended recipient medical device may use the "pipe" symbol ("|") as the field delimiter. The translation module 2415 can identify the field delimiter used in the formatting implementation recognized by the intended recipient medical device from a set of translation rules 2420, and generate an output message based on an input message that uses the pipe field delimiter instead of the caret field delimiter used in the input message. The rule of substituting the pipe symbol for the caret symbol applies only to messages sent to recipient devices that recognize the pipe symbol as the field delimiter in this case. This rule can be accompanied by a supplementary rule indicating that the caret symbol should be used instead of the pipe symbol in the case of messages directed to recipient devices known to recognize the caret symbol as the field delimiter.

[0166] Another one-way rule can handle the presence or absence of some fields between different formatting implementations. For example, an input message from an input medical device can include fields not recognized by the intended recipient medical device. The translation module 2415 can generate an output message that does not include unrecognized or unsupported fields. In situations where the input message does not include fields expected by the intended recipient medical device, the set of translation rules 2420 can include rules that insert a null entry or an empty "" string into the fields expected by the intended recipient medical device and / or warn that the fields expected by the recipient device do not exist. The sender device can also be notified by the translation module 2415 that the recipient device does not support some parts of the message.

[0167] Other unidirectional rules can, for example, smooth the conversion from one data type to another (e.g., from a string ("ST") to text data ("TX") or from structured numeric ("SN") to numeric ("NM")), and the increase or decrease in the lengths of the various parts of a message. Unidirectional rules can also be used to handle variations in the repeatability of parts of a message. For example, the translation module 2415 can apply a field repeatability rule to repeated instances of segments, fields, components, or sub-components of a message to determine, if any, how many such repeated instances are supported by the recipient device and, if necessary, delete or add any repeated instances. For example, the phone number field of a patient identification segment can be made a repeatable field to allow entry of home, work, and mobile phone numbers.

[0168] Bidirectional rules can also be used. Such rules can be equally applied to messages between a first medical device and a second medical device (e.g., 2405, 2410) regardless of which device is the sender and which device is the receiver. The bidirectional rules can be used, for example, to handle order changes. In some implementations, the input message from the input medical device can include one or more patient name fields where the first name component appears before the last name component. However, the intended recipient medical device may expect an implementation where the last name component appears before the first name component. Thus, the set of translation rules 2420 can include bidirectional rules that swap the order of the first name component and the last name component when communicating between two medical devices or between two formatting implementations. Generally, the field order rules are applied to determine whether the fields, components, or sub-components are in the correct order for the intended recipient and can be reordered if necessary. Other bidirectional rules can be included, for example, to handle other sequential changes during formatting implementations or other types of changes.

[0169] The translation rules 2420 can also include compound word rules. For example, the compound word rules can include if-then sequences of rules where the rules can depend on the results of other rules. Some of the translation rules 2420 can be those that use calculations and logic (e.g., boolean logic or fuzzy logic).

[0170] As described above, messages transmitted over a hospital-based communication network can adopt the HL7 protocol. FIGS. 43A and 43B illustrate translation processes 2700A, 2700B in which an HL7 message is transmitted between an HIS and a medical device over a hospital-based communication network or a clinical network. The translation processes 2700A, 2700B are described assuming that rules for determining a "translation" between a first HL7 format and a second HL7 format have already been configured.

[0171] FIG. 43A shows a translation process 2700A that smooths the transmission of an HL7 message, such as the ADT message of FIG. 41A, from an HIS having a first HL7 format to an intended recipient medical device, such as a patient monitor or a clinician monitoring station, having a second HL7 format.

[0172] The translation process 2700A begins at block 2701, where the translation module 2415 receives an input message having a first HL7 format from the HIS. In some embodiments, the input message includes, for example, information regarding patient admission and / or patient identification, and patient medical history information from an electronic medical record database.

[0173] In block 2703, the translation module 2415 determines the formatting implementation form of the input message and the formatting implementation form to be used for the output message. These determinations can be made in a manner similar to the determinations described above with respect to block 2604 of FIG. 42.

[0174] In block 2705, the translation module 2415 identifies rules that determine the translation between the determined HL7 format of the input message and the HL7 format of the output message, and generates an output message having a second HL7 format based on the identified rules. In some embodiments, the output message retains the content of the input message sent by the HIS, but has the format expected and supported by the intended recipient of the input message.

[0175] In block 2707, the translation module 2415 can output the output message to the intended recipient on the hospital-based communication network. In some embodiments, the intended recipient can send back to the hospital information system a confirmation response message that confirms receipt success or reports that an error has occurred.

[0176] FIG. 43B illustrates a translation process 2700B that facilitates the transmission of an HL7 message from a medical device, such as a patient monitor, having a first HL7 format to a HIS having a second HL7 format, where the translation module 2415 has the first HL7 format. For example, the patient monitor can transmit report event data m, such as patient alarm data, to the HIS and store it in the electronic medical record of the patient.

[0177] The translation process 2700B begins at block 2702, where the translation module 2415 receives an input message having a first HL7 format from the medical device. In some embodiments, the input message includes patient monitoring data or alarm data regarding one or more physiological parameters of a monitored patient to be stored in an electronic medical record database associated with the HIS.

[0178] In block 2704, the translation module 2415 determines the formatting implementation form of the input message and the formatting implementation form to be used for the output message. These determinations can be made in a manner similar to the determinations described above with respect to block 2604 of FIG. 42.

[0179] In block 2706, the translation module 2415 identifies the rules for determining the translation between the determined HL7 format of the input message and the HL7 format of the output message, and generates an output message having a second HL7 format based on the identified rules. In some embodiments, the output message retains the content of the input message transmitted by the medical device, but has a format expected and supported by the HIS.

[0180] In block 2708, the translation module 2415 can output the output message to the hospital information system on the hospital-based communication network. In some embodiments, the HIS can send a confirmation response message to the medical device to confirm successful reception or report that an error has occurred.

[0181] FIG. 42, FIG. 43A, and FIG. 43B were diagrams illustrating the operation of the translation module 2415. FIGS. 44 and 45A-45D are used to illustrate the configuration of the translation rules 2420.

[0182] The translation rules 2420 can be implemented as one or more style sheets, hierarchical relationship data structures, tables, lists, other data structures, combinations thereof, and / or the like. In some embodiments, the translation rules 2420 can be stored in the local memory within the translation module 2415. In other embodiments, the translation rules 2420 can be stored in an external memory or in a data storage device device communicatively coupled to the translation module 2415.

[0183] The translation module 2415 can comprise a single rule set or multiple rule sets. For example, the translation module 2415 can comprise separate rule sets for each medical device / system and / or for each possible communication pair of medical devices / systems that are coupled to or can be coupled to a network. In some embodiments, the translation module 2415 can comprise separate rule sets for each possible pair of formatting implementations permitted under a medical communication protocol such as, for example, the HL7 protocol.

[0184] In some embodiments, the translation rules 2420 can be manually entered, for example, using the messaging implementation software tool 2800 illustrated in FIG. 44. For example, a software developer for a particular hospital network can determine the protocol message formats used by devices and / or systems that are coupled to or can be coupled to the hospital network and then manually enter rules for facilitating the “translation” between the various protocol message formats supported or recognized by the devices and / or systems.

[0185] FIG. 44 shows an exemplary screenshot from a messaging implementation software tool 2800 for manually configuring translation rules 2420 as used by translation module 2415. Screenshots from the messaging implementation software tool 2800 illustrate various parameters that can vary for each formatting implementation of an electronic medical communication protocol, such as HL7. The screenshot also includes an area where a user can enter information to define or to be used in defining translation rules for conversion between different HL7 implementations. In some embodiments, the messaging implementation software tool 2800 stores a variety of preconfigured rule sets, for example, based on known communication protocol implementations of various medical devices. In such embodiments, a user can configure one or more translation rules 2420 to be used in communication with such devices by entering identifying information such as device manufacturer, model number, etc. Based on this identifying information, the messaging implementation tool 2800 can identify a preconfigured set of translation rules for communicating with that device.

[0186] In other embodiments, the translation rules 2420 can be automatically generated. For example, the automatic generation of a new set, or multiple sets, of rules can be triggered by the detection of newly recognized "communicating" medical devices or systems on the network. In some embodiments, the automatic generation of a new set or multiple sets of rules can occur when a first message is received from, or transmitted to, a new "communicating" medical device or system coupled to the network. In yet other embodiments, the automatic generation of a rule set includes updating or dynamically modifying a previously existing set of rules.

[0187] The automatic generation of translation rule sets can be performed in a variety of ways. For example, in some embodiments, the translation module 2415 can automatically initiate the use of a previously configured set of translation rules 2420 based on, for example, the type and model of a new device recognized on the network. In some embodiments, the translation module 2415 can request one or more messages from a new device or system and then analyze those messages to determine the type of formatting implemented, as illustrated by the automatic rule configuration process 2900A of FIG. 45A. The automatic rule configuration process 2900A begins at block 2901, where the translation module 2415 receives one or more messages from a medical device or system detected on the network. The messages can be received after being transmitted to the intended recipient medical device or system or in response to a query transmitted by the translation module 2415 or another medical device or system coupled to the network.

[0188] In block 2903, the translation module 2415 determines the protocol of one or more received messages, for example, by analyzing the messages or by examining a database indicating what communication protocol / format is implemented by each medical device or system on the network. In some embodiments, the translation module 2415 is configured to handle medical messages implemented using a single common protocol, such as HL7. Thus, if it is determined that a received message is implemented using an unsupported or unrecognized protocol, the translation module can ignore the message received from the detected medical device or system, output a warning or alert, or allow the message to be transmitted without translation.

[0189] In block 2905, the translation module 2415 determines the formatting implementation form of the received message. In some embodiments, the received message can include one or more identifiers indicating the formatting implementation form. In other embodiments, the determination of the formatting implementation form can be made by analyzing the message itself, for example, by checking the field order, the delimiter or encoded characters used, or other implementation form changes. In some embodiments, the translation module 2415 can assist in the determination of the formatting implementation form by separating or parsing and removing the formatting from the content of the message.

[0190] In block 2907, the translation module 2415 configures one or more rules or rule sets to handle messages received from and / or sent to the detected medical device or system. In some embodiments, configuring the rules involves creating or generating new rules. In other embodiments, configuring the rules involves modifying or updating existing rules. The configured rules or rule sets can be included with the translation rules 2420. If a set of rules already exists for the formatting implementation form used by a new device or system, it may not be necessary to configure new translation rules. Instead, the existing translation rules can be associated with the new device or system and used in communications involving that device or system. In other embodiments, the translation module 2415 can create a new set of rules adapted in a manner specific to the new device or system, or modify an existing set of rules based on a minor change in the identified formatting.

[0191] In other embodiments, the translation module 2415 can generate test messages that can help identify the communication protocols and implementations used by a device or system. For example, the translation module can cause a newly detected device or system to perform a specific action (e.g., store information), and then query the newly detected device for information regarding the action performed to determine whether or how the test message was understood. This is illustrated by the automatic rule configuration process 2900B of FIG. 45B.

[0192] The automatic rule configuration process 2900B begins at block 2902, where the translation module 2415 transmits one or more test, or initialization, messages to a remote device or system detected on the network. The test message can be configured to instruct the remote device or system to perform a specific action (e.g., store patient information), for example. In some embodiments, the test message can be configured to generate a response indicating the type of formatting recognized or supported by the remote device or system. In other embodiments, the test message can be configured such that only devices or systems that support a particular formatting implementation will understand the test message and perform an appropriate action in response thereto.

[0193] In block 2904, the translation module 2415 queries a remote device or system and receives information regarding an action to be performed based on a test message sent to the remote device or system and determines whether the test message was understood. For example, if the test message instructs the remote device or system to store patient information at a specific location, the translation module 2415 can query for the information from that location to determine whether the test message was understood. If the test message was not understood, the translation module 2415 can continue to send test messages in known formatting implementations until a determination is made that the test message was understood.

[0194] In block 2906, translation module 2415 determines the protocol and formatting implementation based on the received information. As an example, in some embodiments, the test message can include instructions that direct the storage of patient name information. The test message can comprise a patient name field having a first name component followed by a last name component. The translation module 2415 can then query the remote device or system to return the patient name. Depending on whether the patient name or first name is returned, this query can be useful in determining information regarding the order of fields in the formatting implementation used by the remote device or system. As another example, the test message can direct the detected device or system to store repeated instances of a component. The translation module 2415 can query the device or system to return the repeated instances and also, if any, to find out which are stored. This repeatability information can also be useful in determining whether a particular field is allowed to be repeated in the formatting implementation used by the remote device or system and, if so, how many repeated instances are allowed.

[0195] In block 2908, the translation module 2415 is configured to handle one or more rules for messages received from and / or sent to the detected medical device or system. For example, the rules can convert a message from the message format used by a first medical device to the message format used by a second medical device, as described herein. In some embodiments, configuring the rules involves creating or generating new rules. In other embodiments, configuring the rules involves modifying or updating existing rules. If a set of rules already exists for the formatting implementation used by a new device or system, it may not be necessary to configure new translation rules. Instead, the existing translation rules can be associated with the new device or system and used in communications involving that device or system.

[0196] Figures 29C and 29D illustrate an automatic rule configuration process performed by the translation module 2415 for messages utilizing the HL7 protocol. The HL7 protocol can be used, for example, to transmit electronic messages that support administrative, logistics, financial, and clinical processes. For example, HL7 messages can include patient management messages, such as ADT messages, which are used to exchange patient demographics and visit information across various healthcare systems.

[0197] The automatic rule configuration process 2900C illustrated in FIG. 45C is similar to the process 2900A illustrated in FIG. 45A. In block 2911, the translation module 2415 receives one or more messages from an HL7 medical device. In block 2915, the translation module 2415 determines the formatting implementation form of the HL7 medical device from the one or more received messages. As described above, the determination of the formatting implementation form can be done, for example, by checking the order or sequence of fields, field delimiter characters, repeatability, cardinality, and other HL7 implementation form changes.

[0198] In block 2917, the translation module 2415 configures one or more rules to handle messages received from and / or sent to an HL7 medical device. In some embodiments, configuring the rules involves creating or generating new rules for the detected formatting implementation form. In other embodiments, configuring the rules involves dynamically modifying or updating existing rules. If a set of rules already exists for the formatting implementation form used by a new HL7 medical device, it may not be necessary to configure new translation rules. Instead, the existing translation rules can be associated with the new HL7 medical device and used in communications involving that device.

[0199] The automatic rule configuration process 2900D illustrated in FIG. 45D is similar to the process 2900B illustrated in FIG. 45B. In block 2912, the translation module 2415 transmits one or more test, dummy, or initialization messages to the HL7 medical device. In other embodiments, the translation module 2415 may cause one or more test messages to be transmitted from another HL7 medical device to the new HL7 medical device. As described above, the test message can include a message having a known HL7 format configured to determine whether the HL7 device understands the test message. The test message can include, for example, a test ADT message.

[0200] In block 2914, in response to the test message, the translation module 2415 queries the HL7 medical device and receives information regarding the actions to be performed or the information stored. In block 2916, the translation module 2415 determines the formatting implementation of the HL7 device based on the received information. In some embodiments, the translation module 2415 can analyze the received information to determine whether one or more test messages were properly understood. If none of the test messages were properly understood, the translation module 2415 can send additional test messages having other known HL7 formats and repeat blocks 2914 and 2916.

[0201] In block 2918, the translation module 2415 is configured to handle one or more translation rules for messages received from and / or sent to the detected HL7 medical device. In some embodiments, configuring the translation rules involves creating or generating new translation rules. In other embodiments, configuring the rules involves modifying or updating existing rules. If a set of translation rules already exists for the formatting implementation used by the new HL7 medical device, it may not be necessary to configure new translation rules. Instead, the existing translation rules can be associated with the new HL7 medical device and used in communications involving that HL7 medical device.

[0202] The automatic rule configuration process described above can be triggered by the detection of a network device or system by the translation module 2415. The medical devices referred to in FIGS. 45A-45D can include any of the devices or systems illustrated in FIG. 1 or FIG. 24.

[0203] In some embodiments, the automatic generation of translation rules can advantageously be performed after the installation and compilation of the messaging subsystem software, including the translation module 2415. In some embodiments, the automatic generation or dynamic modification of the translation rules 2420 can be performed without recompiling or rebuilding the translation module software. This feature can be advantageous with respect to efficiently complying with the requirements of the US Food and Drug Administration ("FDA") regarding the validation of software used in healthcare environments.

[0204] For example, consider a situation where a medical device manufacturer plans to use the translation module 2415 to facilitate communication between a specific medical device or system (e.g., a patient monitoring system as described herein) or other patient treatment equipment to be installed within a hospital, and other devices or systems already installed in the hospital (e.g., HIS or CIS). Any software required for the operation of the new medical device to be installed can be at least partially validated for FDA compliance prior to installation in the hospital, despite the fact that the HL7 implementation forms of other existing devices or systems in the hospital may still be unknown. For example, any aspect of the software for a new medical device that depends on receiving messages from other hospital devices can be validated prior to installation as being able to operate completely and correctly when the expected message format is received. After the medical device is installed in the hospital, the software validation can then be accomplished by showing that the translation module 2415 can provide messages in the expected format to the newly installed device. In this way, the FDA validation task can be significantly allocated to a pre-installation time frame that can be more easily executed in a more controlled manner rather than on-site.

[0205] In addition, the translation module 2415 can further facilitate rationalizing FDA validation efforts when, for example, a medical device or system is expected to be installed in different hospitals where existing devices use different implementations of, for example, the HL7 protocol. Ordinarily, this type of situation could impose the requirement that the entire software functionality for a new medical device be fully validated at each hospital. However, when the translation module 2415 is used to interface between a new medical device and an existing device at a hospital, much of the software functionality can, in some cases, be validated only once prior to installation, as just described. Then, after installation at each hospital, the software validation for the medical device can be accomplished by verifying that the correct message format is received from the translation module (site-customizable translation rules). As a result, the on-site validation procedure can be made significantly more efficient, which advantageously enables more efficient FDA compliance for more rapidly delivering life-saving medical technology to patients by using site-customizable translation rules.

[0206] V. Exemplary Embodiments In some embodiments, a system for providing a medical data translation result for output on a medical monitoring hub can include a portable physiological monitor that receives physiological signals associated with a patient from physiological sensors, calculates physiological parameters based on the physiological signals, and includes a processor that can supply a first value of the physiological parameters to the monitoring hub for display. The monitoring hub can include a docking station that can receive the portable physiological monitor. The monitoring hub receives a first value of the physiological parameters from the portable physiological monitor, outputs and displays the first value of the physiological parameters, receives physiological parameter data from a medical device other than the portable physiological monitor, the physiological parameter data being formatted according to a protocol other than a protocol natively readable or displayable by the monitoring hub, passes the physiological parameter data to a translation module, receives translated parameter data from the translation module, the translated parameter data being preferably readable and displayable by the monitoring hub, and can output and display a second value from the translated parameter data.

[0207] The system of the previous paragraph can be combined with any sub - combination of the following features, which are as follows. The monitoring hub is further configured to output the first value of the physiological parameters and the second value from the translated parameter data to separate displays, the monitoring hub is further configured to output the second value from the translated parameter data to an auxiliary device having a display separate from the display of the monitoring hub, the auxiliary device being selected from the group consisting of a television, a tablet, a phone, a wearable computer, and a laptop, the physiological parameter data includes data from an infusion pump, the physiological parameter data includes data from a ventilator, and the translation module is configured to translate the physiological parameter data from a first Health Level Seven (HL7) format to a second HL7 format.

[0208] In some embodiments, a method of providing a medical data translation result for output on a medical monitoring hub includes receiving, under the control of a first medical device having a digital logic circuit, a physiological signal associated with a patient from a physiological sensor; obtaining a first physiological parameter value based on the physiological signal; outputting and displaying the first physiological parameter value; receiving a second physiological parameter value from a second medical device different from the first medical device, the second physiological parameter value being formatted according to a protocol not used by the first medical device, whereby the first medical device cannot process the second physiological parameter value to generate a displayable output value; passing physiological parameter data from the first medical device to a separate translation module; receiving translated parameter data from the translation module in the first medical device, the translated parameter data being processable for display by the first medical device; and outputting and displaying a second value from the translated parameter data.

[0209] The method of the preceding paragraph can be combined with any sub - combination of the following features, which are as follows. Further comprising translating a message by translating at least the message from a first Health Level Seven (HL7) format to a second HL7 format, the message can include data from a physiological monitor, the message can include data from an infusion pump or a ventilator, the message can include data from a hospital bed.

[0210] In some embodiments, a system for providing a medical data translation result output on a medical monitoring hub can comprise a first medical device that acquires a first physiological parameter value associated with a patient, outputs and displays the first physiological parameter value, receives a second physiological parameter value from a second medical device different from the first medical device, the second physiological parameter value being formatted according to a protocol not used by the first medical device, whereby the first medical device cannot process the second physiological parameter value to generate a displayable output value, transfers physiological parameter data from the first medical device to a translation module, receives translated parameter data from the translation module in the first medical device, the translated parameter data being processable for display by the first medical device, and comprises electronic hardware capable of outputting and displaying a second value from the translated parameter data.

[0211] The system of the previous paragraph can be combined with any sub-combination of the following features, which are as follows. The first medical device can also output a first value of a physiological parameter and a second value from the translated parameter data to the same display. The first medical device can also output a first value of a physiological parameter and a second value from the translated parameter data to separate displays. The first medical device can also output a second value from the translated parameter data to an auxiliary device, which may be a television monitor. The auxiliary device may be selected from the group consisting of a tablet, a phone, a wearable computer, and a laptop. The first medical device can comprise a translation module. The first medical device can also transfer physiological parameter data to the translation module over a network. The physiological parameter data can include data from an infusion pump or a ventilator.

[0212] VI. Augmented Reality Embodiments Today's patient monitoring environment provides one or more conventional displays or screens for clinicians that present data from one or more electronic medical devices associated with a variety of monitoring, treatment, or procedures for a patient. Thus, during such patient monitoring, treatment, or procedures, a clinician typically reviews one or more conventional displays to gather information about the patient. However, while a clinician is looking at one or more conventional displays, the clinician's attention may be diverted from the patient, such as when the clinician looks away from the patient to view a conventional display while performing a surgical procedure. For example, during certain surgical procedures such as endoscopy or epidural, the clinician performing the procedure typically looks at the patient to see where the probe is advancing, but the clinician has to look away from the patient to view a conventional display, which is inefficient.

[0213] The systems and methods described herein may advantageously, in some embodiments, use augmented reality to improve the presentation of data or provide an improved interactive user interface. For example, a clinician using an augmented reality device, such as augmented reality glasses, may be presented with medical monitoring data that can be received from a medical monitoring hub as described herein. In some embodiments, the advantage of augmented reality is that the augmented reality display overlays visual information of the real world. Thus, a clinician can remain visually focused on the patient while receiving augmented reality information simultaneously. In some embodiments, the advantage of augmented reality is that the display area for the augmented reality user interface can be larger than that of a conventional display, such as a device screen. For example, the augmented reality display area can be ten times larger than a conventional display area. Shown next are examples of an improved augmented reality user interface.

[0214] Exemplary augmented reality devices present one or more user interfaces. Exemplary user interfaces that may be presented on an augmented reality device include any of the user interfaces described herein. Additionally, the augmented reality user interface can improve the efficiency of a surgical procedure. For example, during some procedures such as an endoscopy or an epidural, a clinician can efficiently confirm where a probe is advancing while maintaining line of sight to the patient, and at the same time view an overlay user interface that includes data that was previously only available on a conventional display. In some embodiments, the augmented reality user interface can be pinned to a three-dimensional space or a specific region within a patient's room. For example, a clinician can interactively manipulate the augmented reality device to pin the augmented reality user interface to a physical device, location, or patient. Continuing with this example, the augmented reality user interface that is pinned is visible to a clinician using the augmented reality device when looking near the physical device or pinned location, but the augmented reality user interface is not presented when the clinician looks away from the physical device or its location. In some embodiments, the auxiliary device 2040 may be optional, or any information displayed on the auxiliary device 2040 may be presented through the augmented reality device.

[0215] Another example of an improved user interface using augmented reality is presenting an analog display mark as an overlay on a patient. Exemplary analog display marks that can be presented on an augmented reality device include any of the analog display marks described herein. Exemplary analog display marks, such as two-dimensional or three-dimensional lungs, hearts, brains, or circulatory systems, can be overlaid and displayed on a patient. Thus, a clinician will see the overlaid analog display mark when viewing the patient. In some embodiments, the analog display mark is pinned to the patient such that the analog display mark is not presented when the clinician looks away from the patient. As described herein, the analog display mark can present health indicators of various physiological parameters. Exemplary health indicators include color-coded analog display marks, such as green, yellow, or red marks, each of which can indicate a nominal, caution, or severe situation, which is described in more detail herein.

[0216] In some embodiments, the improved augmented reality user interface enables a user to configure or interactively operate the user interface. For example, the augmented reality user interface may be a dashboard that allows a user to add or remove specific virtual display panels, or change the layout configuration or location of augmented reality panels or objects. The augmented reality device may be configured to receive user input corresponding to user interaction. Exemplary user interactions include voice input or commands, visual or eye commands, touch input, or movements such as head movement or hand gestures. Exemplary head gestures include tilting the head, slightly moving the head, or nodding. As another example, a clinician may receive augmented reality patient data while outside the patient's room or area. In an example, a clinician passing by the side of a patient's room interactively operates an augmented reality device to receive data regarding the patient or data from an electronic medical device within the patient's room. Continuing with this example, the clinician performs a gesture of virtually grasping the patient's data and causes the augmented reality device to present the data without entering the patient's room. As another example, patient data may be virtually posted outside the room. In addition to, or alternatively, in some embodiments, patient data may be available anywhere within a healthcare facility or even far away, such as when a clinician is dozens or hundreds of miles away from the patient's physical location.

[0217] Additional exemplary user interfaces and systems for patient monitoring and notification are disclosed in U.S. Patent Application No. 14 / 511,972, which is incorporated herein by reference in its entirety by the assignee of the present disclosure.

[0218] FIG. 72A illustrates another embodiment of a monitoring environment 7202 that includes the hub 100 of FIG. 1 and the device of FIG. 24. The monitoring environment 7202 may include all or some of the features of the monitoring environment 200 of FIG. 2 or the monitoring environment 2000 of FIG. 24, as well as any of the other features described above. In addition, the monitoring environment 7202 shows a plurality of patient monitoring systems (MMS) 2004. The MMS 2004 includes a translation module 2005 that can receive serial data, translate the serial data into a format recognizable by the monitoring hub 100, and provide the serial data to the monitoring hub 100 (optionally between other devices). Also shown is an auxiliary device 2040 that can communicate with the MMS 2004, the monitoring hub 100, or the PPM 102 in a wired or wireless manner. Similarly, the augmented reality device 7200 can communicate with the MMS 2004, the monitoring hub 100, or the PPM 102 in a wired or wireless manner.

[0219] The exemplary augmented reality device 7200 includes an augmented reality glasses, a head-mounted display, a head-up display, contact lenses, a smartphone, or a tablet. The augmented reality device 7200 can include any combination of one or more hardware processors, displays, sensors, or input devices. For example, the augmented reality device 7200 can include a camera, an accelerometer, a gyroscope, a GPS device, or a solid state compass. The augmented reality device 7200 can include one or more wired or wireless devices that enable communication on a wired or wireless network such as a Bluetooth® network, a USB network, a wired network, or a Global System for Mobile Communications (GSM®) network, a Code Division Multiple Access (CDMA) network, a Long Term Evolution (LTE) network, Wi-Fi, or any other type of wireless network. In some embodiments, the augmented reality device 7200 may communicate with an augmented reality server (not shown), which can handle some augmented reality processing. Thus, an exemplary augmented reality device can offload some or all of the augmented reality processing to be performed by the augmented reality server in a distributed manner.

[0220] FIG. 72B shows an exemplary augmented reality user interface 7204. The exemplary augmented reality user interface 7204 includes one or more augmented reality user interface objects. As described herein, a medical monitoring system can receive one or more physiological signals associated with a patient being monitored via one or more physiological sensors. The medical monitoring system can calculate physiological parameters based on the physiological signals. An augmented reality device 7200 or another device in a medical monitoring environment can generate one or more augmented reality user interface objects from physiological monitoring data that includes physiological parameters. As described herein, the physiological monitoring data may be updated in real time or near real time, and thus, the augmented reality user interface objects that display the physiological monitoring data can be updated in real time or near real time. In some embodiments, a clinician using the augmented reality device may configure the augmented reality user interface. For example, the augmented reality device may receive user input corresponding to a user interaction that configures the augmented reality user interface. Exemplary user configurations of the augmented reality user interface include addition or deletion of augmented reality objects, change in the position of augmented reality objects, cyclic selection of different augmented reality user interfaces, or selection of a particular augmented reality user interface. For example, a first augmented reality user interface corresponds to a first set of augmented reality objects for monitoring patient physiological data, a second augmented reality user interface corresponds to a second set of augmented reality objects for presenting patient medical history, or a third augmented reality user interface corresponds to a third set of augmented reality objects for presenting patient demographic data.

[0221] FIG. 72C shows another exemplary augmented reality user interface 7206. The exemplary augmented reality user interface 7206 includes one or more augmented reality objects 7208 and an augmented reality display area 7210. As described herein, the exemplary augmented reality objects 7208 include analog indicia that are overlaid and displayed on the patient. For example, the augmented reality object 7208 corresponds to a color-coded visual representation of the patient's lung condition. The patient may be connected to one or more devices 7214 or may be worn as such, which may be further connected to another device 7212 corresponding to, for example, a hub, a monitoring system, or a conventional display. In some embodiments, an augmented reality system, such as the augmented reality device 7200 or an augmented reality server, determines the position of the augmented reality object 7208 based on position information derived from one or more devices 7214. For example, the one or more devices 7214 may comprise tracking sensors such as accelerometers, GPS, gyroscopes, solid state compasses, RFID, or wireless sensors. In addition or alternatively, the one or more devices 7214 may comprise visual markers that may be detected by the augmented reality device 7200 for image registration, or the patient may be worn as having one or more visual markers for image registration. In some embodiments, a clinician using the augmented reality device 7200 may pin the augmented reality display area 7210 to the device 7212. The augmented reality display area 7210 may include any of the exemplary user interfaces described herein.

[0222] Similar to the visual markers or tracking sensors associated with a patient or one or more devices 7214, the augmented reality system can determine the position of the augmented reality display area 7210 based on the visual markers or tracking sensors associated with the device 7210. As described herein, an exemplary augmented reality system determines the position of the augmented reality display area 7210 by identifying a reference object, here the device 7212, determining a reference position for the reference object, and calculating a position offset from the reference position. In some embodiments, the position offset can be calculated as a predetermined or configurable distance and direction from the reference object. Continuing with this example, a clinician using the augmented reality device can change or update the position offset of the augmented reality display area 7210.

[0223] Figures 72D and 72E each show additional exemplary augmented reality user interfaces 7216A and 7216B. The exemplary augmented reality user interfaces 7216A and 7216B may be similar to the augmented reality user interface 7206 of FIG. 72C. As illustrated, the exemplary augmented reality user interfaces 7216A and 7216B each include user interface display areas 7218A and 7218B, which each include user interface objects 7220A and 7220B. The exemplary user interface objects 7220A and 7220B may correspond to the exemplary user interfaces described herein.

[0224] Figure 72F shows the augmented reality display generation process 7222. Process 7222 shows an exemplary mode of operation of the environment 7202 of FIG. 72A and may be implemented by various components shown within the environment 7202, such as the augmented reality device 7200, or by an augmented reality server remote from the augmented reality device 7200. For convenience, process 7222 is described in the context of environment 7202 (such as implemented by the augmented reality system and herein referred to as the augmented reality device 7200 or by the augmented reality server), but instead, it may be implemented by other systems described herein or other computing systems not shown. Further, process 7222 provides an exemplary approach that the augmented reality device 7200 or the augmented reality server can use to generate an augmented reality display. Depending on the embodiment, the process of FIG. 72F may include fewer blocks, or additional blocks may be added, or the blocks may be executed in an order different from that illustrated.

[0225] In block 7224, the augmented reality system server initiates a connection with the communication interface. For example, the augmented reality device 7200 may connect to the communication interface of the MMS 2004, the monitoring hub 100, or the PPM 102 in a wired or wireless manner. In some embodiments, the augmented reality device 7200 must be authenticated via one or more security protocols before a connection with the communication interface can be established.

[0226] In block 7226, the augmented reality system receives data from the communication interface. As described herein, exemplary data includes physiological monitoring data, which may include physiological parameter data from a patient calculated from physiological signals captured by physiological sensors monitoring the patient.

[0227] In block 7228, the augmented reality system formats the received data so that it can be presented. For example, the augmented reality system may access user interface configuration data indicating which augmented reality objects should be displayed or the placement of the augmented reality objects. In some embodiments, a clinician using the augmented reality device 7200 may update or modify the user interface configuration data via one or more user interactions with the augmented reality device 7200 as described herein. Thus, the augmented reality system can format the received data, such as physiological monitoring data, into user interface display data according to the user interface configuration data. For example, the augmented reality system generates one or more augmented reality objects from the physiological monitoring data according to user interface configuration data that defines which objects should be generated or where the objects should be presented on the display of the augmented reality device.

[0228] In block 7230, the augmented reality system presents the formatted data within the display of the augmented reality device. Exemplary augmented reality user interfaces are illustrated and described in more detail with reference to FIGS. 72B-72E.

[0229] In block 7232, the augmented reality system receives and processes input data. Exemplary input data includes user interaction data received from the augmented reality system. For example, a clinician may interactively operate the augmented reality user interface to modify the user interface. Accordingly, the augmented reality system returns to block 7226, receives additional data, continues to process user interaction data, display data, or monitoring data, and may present an updated augmented reality user interface. For example, the augmented reality user interface may be updated substantially in real-time or in real-time based on updated data captured by physiological sensors from new data received from a patient or from MMS2004, monitoring hub 100, or PPM102.

[0230] Figure 72G shows an augmented reality positioning process 7234. Process 7234 shows an exemplary mode of operation of the environment 7202 of FIG. 72A and may be implemented by various components shown within the environment 7202, such as the augmented reality device 7200, or by an augmented reality server remote from the augmented reality device 7200. For convenience, process 7234 is described in the context of environment 7202 (such as being implemented by the augmented reality system), but instead may be implemented by other systems described herein or other computing systems not shown. Further, process 7234 provides an exemplary approach used by the augmented reality system to determine the position of one or more augmented reality objects. Depending on the embodiment, the process of FIG. 72G may include fewer blocks, or additional blocks may be added, or the blocks may be executed in an order different from that illustrated. Further, the blocks of process 7234 may correspond to one or more blocks of process 7222 of FIG. 72F, such as blocks 7226, 7228, 7230, or 7232.

[0231] In block 7236, the augmented reality system receives input data. Exemplary input data includes tagged or pinned reference objects or locations. Exemplary tagged and pinned reference objects can correspond to one or more physical objects, such as an auxiliary display, a device of a monitoring system, or a patient. In addition or alternatively, exemplary input data includes location or location relationship data, such as image data, video data, accelerometer data, GPS data, gyroscope data, solid state compass data, RFID data, or wireless data. Exemplary location or location relationship data can correspond to data captured by an augmented reality device or one or more devices of a monitoring system, such as an auxiliary display or one or more devices attached to a patient. As another example, image or video data can capture a known visual marker (also known or referred to as a fiducial marker as used herein) attached to a patient or a device of a monitoring system.

[0232] In block 7238, the augmented reality system determines position display data from input data. For example, the augmented reality system determines, or calculates, a reference position to a reference object from image data, video data, accelerometer data, GPS data, gyroscope data, solid state compass data, RFID data, or wireless data. Typically, GPS data is accurate within a range of several meters. Thus, the augmented reality system may use other position-related data, such as image or video data, accelerometer data, gyroscope data, solid state compass data, RFID data, or wireless data, to determine a more accurate position relative to the reference object. In an example of computer vision, the augmented reality system performs an image registration process that identifies known visual markers through one or more feature detection techniques, such as corner detection, blob detection, edge detection, thresholding, or other image processing techniques. In addition to, or alternatively to, this, the augmented reality system uses pose estimation techniques to determine a three-dimensional position relative to the reference object. In some embodiments, the augmented reality system generates a real-world coordinate system from the obtained, or generated, position data. An exemplary real-world coordinate system includes at least three-dimensional coordinates.

[0233] An exemplary augmented reality system generates position display data from obtained or generated position data. In the example of pinning, the augmented reality system determines a position offset from a reference object, such as a display or device of a patient or a monitoring system. The augmented reality system may calculate the position offset from a predefined or configurable distance and the direction from the reference object. Exemplary predefined distances include 5 or 10 centimeters to the right or left of the reference object. In some embodiments, user interaction input received from a clinician may update the position offset. For example, the clinician may interactively manipulate the augmented reality object by moving it, such as by pushing, pulling, or waving a hand gesture. In the example of a direct overlay or superposition, the augmented reality system may display one or more augmented reality objects at a reference position relative to the reference object. For example, the reference position of the patient may correspond to specific coordinates within a coordinate system, and the augmented reality system presents the object at those coordinates. As described herein, the augmented reality system may present analog displays, such as the coordinate positions of a patient's lung, heart, or brain region, at a reference position corresponding to the patient. Thus, when the reference object moves, one or more pinned augmented reality objects may move with the reference object.

[0234] VII. Additional Exemplary Aspects of Augmented Reality Embodiments In a first aspect, a method for presenting augmented reality data from a medical monitoring system, comprising receiving, under the control of a hardware processor, physiological monitoring data including physiological parameter values associated with a patient from a monitoring hub, accessing user interface configuration data, generating, from the physiological monitoring data, a plurality of augmented reality objects according to the user interface configuration data, and presenting the plurality of augmented reality objects within an augmented reality display.

[0235] In a second aspect, the method of aspect 1 further includes receiving user interaction data from a user input sensor of an augmented reality device and generating user interface configuration data from the user interaction data.

[0236] In a third aspect, the method according to either aspect 1 or 2 further includes receiving user interaction data from a user input sensor of an augmented reality device, determining a reference object from the user interaction data, determining a reference position for the reference object, and calculating a position offset from the reference position, wherein a plurality of augmented reality objects are presented with respect to the reference position according to the position offset.

[0237] In a fourth aspect, the method according to any one of aspects 1 to 3 further includes determining whether to present a direct overlay from the user interface configuration data, determining a reference object from the user interface configuration data, and determining a reference position for the reference object, wherein an overlay object of a plurality of augmented reality objects is presented at the reference position.

[0238] In a fifth aspect, the method of aspect 4, wherein the reference object corresponds to a patient.

[0239] VIII. Additional Auxiliary Device Embodiments Next, several additional embodiments associated with the auxiliary device 2040 are described, including authentication features (see FIG. 73), features for controlling a device that transmits data to the auxiliary device 2040 (see FIGS. 74 and 76), and features for controlling the output to the auxiliary device 2040 (see FIG. 75).

[0240] Generally, as described above, the auxiliary device 2040 can provide a second screen function for the hub 100, PPM 102, or MMS 2004. Further, as described above, the translation module 2005 can be implemented on any device, including the hub 100 or MMS 2004. Data set to the auxiliary device 2040 by the translation module 2005 (or from another device shown in FIGS. 24 or 72A) is transmitted in a format suitable for the auxiliary device 2040 and may be used to determine how to display on the display of the auxiliary device 2040. In other words, a device can send data to the auxiliary device 2040 regardless of any specific user interface formatting, and the auxiliary device 2040 can determine how to format that data and how to display it on the display. For example, a software module (not shown) installed on the auxiliary device 2040 can format the received data into any desired user interface format. In one embodiment, the data received by the auxiliary device 2040 is in XML format or another similar format, and software running on the hardware processor of the auxiliary device 2040 parses the XML (or similar) data and generates a display based on that data.

[0241] Referring to FIG. 73, an embodiment of an auxiliary device authentication process 7300 is illustrated. The process 7300 can be implemented using the components of the system described above with respect to FIGS. 24 and 72A. Generally, the process 7300 can be implemented by software or firmware running on a hardware processor. The process 7300 can enable the auxiliary device 2040 to authenticate with the hub 100, MMS 2004, or PPM 102. (For convenience, in the remainder of this disclosure, the communication between the auxiliary device 2040 and the hub 100 is addressed, but it should be understood that any of these communications can also occur between the auxiliary device 2040 and the MMS 2004 or PPM 102.)

[0242] It may be desirable to authenticate the auxiliary device 2040 to the hub 100 so that communication can occur between these two devices. In another view, the process 7300 can be considered a process for pairing the auxiliary device 2040 with the hub 100. Multiple auxiliary devices 2040 can be paired with or otherwise authenticated to the hub 100 all at once. This can be useful, for example, where multiple clinicians can each have a tablet or other auxiliary device 2040 instead of and / or in addition to the TV auxiliary device 2040 being present in the patient room. Further, in some embodiments, the augmented reality device 7200 described above may be an example of one of the auxiliary devices 2040, and multiple clinicians may have an augmented reality device 7200 that they would like to use with the hub 100 (e.g., such that each can have a different head-up display with a set of views customized for that particular clinician).

[0243] In block 7302, the user requests the hub 100 (or MMS 2004, etc.) to wirelessly connect to the auxiliary device 2040 (wired connections are also possible in other embodiments). For example, the user can access the settings menu on the hub 100 to initiate pairing or authentication of the auxiliary device 2040. In block 7304, the hub 100 displays a PIN number or other authentication code (e.g., alphanumeric) on the display. In block 7306, the user enters the PIN or other authentication code on the auxiliary device. In block 7308, the auxiliary device transmits the PIN or other authentication code to the hub or MMS. In block 7310, the hub or MMS transmits data collected from the patient monitor to the auxiliary device. Block 7310 can be implemented either before, during, or after the execution of process 7300.

[0244] Referring to FIG. 74, an embodiment of an auxiliary device control process 7400 is illustrated. Process 7400 may be implemented using the components of the system described above with respect to FIGS. 24 and 72A. Generally, process 7400 may be implemented by software or firmware running on a hardware processor. Process 7400 may enable auxiliary device 2040 to control hub 100 (and / or MMS 2004, etc.). Thus, for example, auxiliary device 2040 may not only receive data, but may also be able to send data to hub 100 or other devices described above. This data may include control data that enables auxiliary device 2040 not only to passively receive and display data, but also to control the settings of any of the devices described above, including third-party monitors (e.g., 214 - 220) serially connected to hub 100 or otherwise connected, and first-party monitors (e.g., 222 - 226) connected to hub 100 via a channel or otherwise.

[0245] For example, auxiliary device 2040 may be able to control options or settings that can be controlled either at the patient monitor or at hub 100. For example, alarms, user interface layouts, settings, etc. may be controlled via auxiliary device 2040. Auxiliary device 2040 may output a user interface that enables control of these settings. For example, referring to FIG. 76, an exemplary user interface 7600 is illustrated that includes settings 7610 for controlling an infusion pump, a patient bed, and a ventilator, and further for displaying parameter values from multiple devices. Thus, with a single auxiliary device 2040, a clinician may be able to control several devices in the room, and even all devices (e.g., those communicating with hub 100 or MMS 2004).

[0246] In one embodiment, the manufacturer of the hub 100 can provide a software development kit (SDK) for use by third-party patient monitor manufacturers to enable the auxiliary device 2040 to communicate with the hardware. By using the SDK, for example, a third-party monitor manufacturer can install a software library on a third-party patient monitor (e.g., 214-220) to enable the auxiliary device 2040 to directly communicate settings or other parameter changes to those devices. One or more software libraries can include, for example, routines or functions that the auxiliary device 2040 can call or invoke to set different settings within a third-party device and an application programming interface (API) that defines related parameters. One or more similar libraries can be installed on first-party devices such as channel devices (222-226). In one embodiment, the auxiliary device 2040 comprises a set of instructions or libraries that it can call to send setting changes to the hub 100 (or MMS 2004) for delivery by the hub 100 to third-party or first-party devices. The hub 100 may also translate setting request changes from the auxiliary device 2040 into more complex instructions provided to individual patient monitors. In one embodiment, the manufacturer of the hub 100 can certify medical devices that can be controlled by the auxiliary device 2040. In another embodiment, any functionality for controlling third-party and first-party devices can be implemented directly by the hub 100, instead of or in addition to, the auxiliary device 2040.

[0247] Accordingly, the hub 100 or the auxiliary device 2040 can become essentially a monitor itself as it enables full control of a wide variety of patient monitoring devices. In another view, the auxiliary device 2040 or the hub 100 can comprise a unified display for managing multiple patient devices.

[0248] Referring again to FIG. 74, an exemplary process is illustrated in which the auxiliary device 2040 can perform setting changes to a medical device connected to the hub 100. In block 7402, the auxiliary device accesses the API of the device connected to the hub, either directly or through the hub itself. In block 7404, the auxiliary device exposes the connected device settings, for example, on a user interface (see, e.g., FIG. 76) that the user can access. In block 7460, the auxiliary device receives setting changes from the user through the user interface. In block 7408, the auxiliary device accesses the appropriate medical device API, either directly or through the hub, and affects the setting changes. And in block 7410, the auxiliary device receives data from the connected device. Of course, block 7410 may operate in parallel with process 7400, and data may be received before, during, and / or after the settings are changed.

[0249] Referring to FIG. 75, an embodiment of an auxiliary device data flow process 7500 is illustrated. Process 7500 can be implemented using the components of the system described above with respect to FIGS. 24 and 72A. Generally, process 7500 can be implemented by software or firmware running on a hardware processor. Process 7500 can enable the auxiliary device 2040 or the hub 100 to control the flow of data to the auxiliary device 2040.

[0250] In some current implementations, the translation module 2005 pushes most or all of the data received from most or all of the devices connected to the hub 100 onto the auxiliary device 2040. For some auxiliary devices 2040 with low computing resources (e.g., low processing power, low memory, low battery capacity, low battery power, low bandwidth connection, etc.), this can mean that those devices may be overwhelmed by the received data. As a result, these devices may crash or obtain bad or incomplete results.

[0251] One way to solve this problem is, for example, to cause the translation module 2005 to send data less frequently to the auxiliary device 2040 by reducing the frequency of data reception. Another way is for the auxiliary device 2040 to have a module that reduces the firehose effect of all the data received by requesting a specific subset of the information from the translation module 2005 or the hub 100 instead. An example of such a module is shown in FIG. 72A, which is the IAP (instrument auxiliary protocol) layer 2042. This layer 2042 can automatically request that a subset of the information be provided to the auxiliary device 2040. In one embodiment, the IAP layer 2042 exposes a user interface on the auxiliary device 2040 that allows the user to control what data should be provided to the auxiliary device 2040. Similarly, in other embodiments, the layer 2042 can be implemented as a module directly on the MMS 2004 or within the hub 100.

[0252] In another embodiment, rather than being completely flexible, the IAP layer 2042 may have a predefined function for receiving data at the auxiliary device 2040. This function may be determined, for example, by the level of service paid for by the clinical facility using the auxiliary device 2040, or the like. For example, as the level of service increases, it may be possible to enable more parameters or a greater variety of different parameters to be provided to the auxiliary device 2040.

[0253] Referring particularly to process 7500 shown in FIG. 75, at block 7502, the auxiliary device outputs a user interface that enables the user to select information received from the hub or MMS. At block 7506, the auxiliary device receives a user selection of specific parameters from the interface. For example, the user may request to display ventilation or pump data while excluding other data. At block 7508, the auxiliary device transmits the user selection to the hub or MMS. And at block 7510, the hub or MMS records the selection and transmits the requested data.

[0254] IX. Additional Exemplary Aspects of Auxiliary Device Embodiments A method for authenticating an auxiliary device to a medical monitoring hub, the method comprising receiving a request to wirelessly connect the auxiliary device to the medical monitoring hub under the control of the medical monitoring hub comprising a hardware processor, outputting, on a display of the medical monitoring hub, an authentication code for the user to enter into the auxiliary device, receiving, from the auxiliary device, an indication that the authentication code has already been entered into the auxiliary device, and transmitting data from one or more patient monitors coupled to a patient to the auxiliary device.

[0255] In a second aspect, a method for controlling an auxiliary device communicating with a medical monitoring hub, comprising a hardware processor, accessing a software library corresponding to a medical device connected to the medical monitoring hub under the control of the auxiliary device communicating with the medical monitoring hub, outputting settings associated with the medical device on a display of the auxiliary device, receiving a change to the settings from the display, and transmitting the changed settings to the medical device through the medical monitoring hub using the software library.

[0256] In a third aspect, a method for controlling a data flow to an auxiliary device communicating with a medical monitoring hub, comprising a hardware processor, outputting a user interface having a function for a user to select a specific type of information received from the medical monitoring hub under the control of the auxiliary device communicating with the medical monitoring hub, receiving a user selection of a first type of information received by the auxiliary device from the medical monitoring hub, transmitting the user selection to the medical monitoring hub, and receiving data corresponding to the first type of information at the auxiliary device.

[0257] X. Medical Network Interface Embodiments The hub 100 described above is beneficial in that it provides a function for stand-alone devices (such as beds, pumps, ventilators, and other monitors) to connect to the hub 100, and this function is included along with other important patient monitoring functions within the same box. That is, in some embodiments, the hub 100 can calculate physiological parameters obtained from the sensor (202), receive and process channel data from various sensors (e.g., FIGS. 2, 24, and 74A), and can also receive serial data from stand-alone devices. The functions of the hub advantageously enable channel devices (e.g., 222, 224, 226) and stand-alone (serial) devices to supply patient data to the MMS 2004 for storage in the EMR, and further optionally display data from the channel or serial devices at the hub 100. However, the function that enables stand-alone patient devices to transmit data for storage in the EMR requires including the seller function of the hub 100. When the use of the hub 100 is not desirable, or when the hub 100 is unavailable or a low-function monitoring device is being used, it is desirable to provide this function separately.

[0258] In this section, an embodiment of a medical network interface that can advantageously provide the network connection function of the hub 100 without including other functions of the hub 100 will be described. For example, the medical network interface may be a network device that receives data from a stand-alone patient device and then transfers this data to the MMS2004. As described below, the MMS2004 can also use this data to perform other functions. The medical network interface can function as a networking hub that does not necessarily perform patient monitoring itself (e.g., a network device without a patient monitoring function as distinguished from the hub 100), a switch, a router, or a network bridge. One medical network interface can be used for one patient, or a device that takes care of multiple patients can be connected to a single medical network interface (e.g., two patients in one hospital room can be connected to a single interface). The medical network interface can advantageously provide network operation for stand-alone patient devices, which may not have the native ability to connect to a hospital network (e.g., other than those having a hardware port for connecting to the network, these devices may be configured by software consisting of the information necessary to connect to the MMS2004). The medical network interface may be an information technology (IT) appliance in some implementations.

[0259] Furthermore, as described in detail below, a wireless pairing system can be used to pair a medical network interface with stand-alone patient devices such that these devices can wirelessly transmit patient data to the medical network interface. The pairing system can include connecting a wireless dongle to the medical network interface to obtain an identifier and / or security key and then connecting the wireless dongle to the stand-alone patient device to enable the stand-alone patient device to transmit data wirelessly and, optionally, securely, to the medical network interface. Advantageously, in some embodiments, this pairing system is easy and quick for a clinician to use, allowing the clinician to spend less time configuring the device and get back to patient treatment more quickly.

[0260] FIG. 77A illustrates another embodiment of a monitoring environment 7700 that includes a medical network interface 7710, a patient monitor 7701, and the devices and systems of FIGS. 24 and 72A. The monitoring environment 7700 can include all or some of the features of the monitoring environment 200 of FIG. 2, the monitoring environment 2000 of FIG. 24, or the monitoring environment 7202, as well as any of the other features described above. In addition, the monitoring environment 7700 shows a medical network interface 7710, which is one embodiment of the medical network interface already described.

[0261] The medical network interface 7710 can support various wired or wireless connections, for example, via a universal medical connector, an Ethernet (registered trademark) port, a USB port, Bluetooth (registered trademark), Wi-Fi, or other types of wired or wireless connections described herein. The medical network interface 7710 can be connected to the MMS2004 using a wired or wireless network connection. In some embodiments, the medical network interface 7710 is also configured to be connected to devices such as, for example, a patient monitor 7701, an auxiliary device 2040, an extended reality device 7200, a stand-alone device and sensor 7720 (including a patient bed 214, an infusion pump 216, a ventilator 218, a PPM102), or other devices and sensors described herein. In some implementations, the medical network interface 7710 can be paired with one or more devices prior to performing data transmission via a wired or wireless connection, as described in detail below.

[0262] Advantageously, in some embodiments, the medical network interface 7710 provides connectivity for a stand-alone patient device 7722 to communicate with the MMS2004. The medical network interface 7710 can provide this connectivity when the monitoring hub 100 is not available, or in addition to the monitoring hub in the same hospital room. However, in the illustrated embodiment, the hub 100 is replaced with a patient monitor 7701 that does not directly connect to the stand-alone patient device 7720. The patient monitor 7701 (equipped with a docking station, PPM102, channel ports, extended reality, etc.) can also be omitted in other embodiments for the convenience of other types of patient monitors (including non-full-function monitors) that can be connected to the medical network interface 7710, such as the stand-alone patient device 7720 (see, for example, FIG. 77B).

[0263] The medical network interface 7710 can transfer data obtained from a medical device to the MMS system 2004. During the execution of this process, the medical network interface 7710 can automatically discover the communication protocol used by the devices connected to the medical network interface 7710. The medical network interface 7710 can further update a message containing one or more data packets from the medical device to include the identifier of the medical network interface 7710 before transmission to the patient monitor 7701 or the MMS 2004. Thus, the patient monitor 7701 and the MMS 2004 can identify that the message is from the medical network interface 7710. Further, the medical network interface 7710 may include a display 7712 to facilitate (or for other reasons) pairing with the stand-alone patient device 7720, as described in more detail below.

[0264] To simplify the description and not limit the present disclosure, FIG. 77A illustrates only one medical network interface 7710. However, multiple medical network interfaces may be used to connect to the patient monitor 7701, MMS 2004, and other devices, sensors, or systems. As an example, two medical network interfaces 7710 may be connected to each other, thereby expanding the ports available on one medical network interface. As another example, two or more medical network interfaces 7710 may be connected to the MMS 2004, where each medical network interface is associated with a patient. Thus, the MMS 2004 can process data associated with multiple patients. Further, although the example of the medical network interface 7710 in this specification is described as being connected to the MMS 2004, in various embodiments, the medical network interface 7710 can also be connected to the patient monitor 7701 (or hub 100) via a wired or wireless connection. For example, the medical network interface 7710 can transfer data obtained from medical devices to the patient monitor 7701 or hub 100 in addition to, or instead of, the MMS 2004. The patient monitor 7701 or hub 100 can transfer this data to the MMS 2004. Thus, for example, the medical network interface 7710 can expand the function of the hub 100 by connecting to a port of the hub 100 instead of directly connecting to the medical network. A detailed exemplary description of the medical network interface 7710 will be described below with reference to FIGS. 78A, 78B, and 80.

[0265] FIG. 77B shows another example of a monitoring environment 7702 in which a medical network interface 7710 is illustrated. As in FIG. 77A, a stand-alone patient device 7720 connects to a medical network interface 7710 that provides network connectivity to these devices by connecting to a hospital network 7750. Also connected to the hospital network 7750 are an MMS 7704 and other hospital devices 7760 such as, for example, a nurse station computer, a kiosk, a computer on wheels (COW), and clinician devices (phones, pagers, tablets, and the like). The MMS 7704 can also communicate with an external network 7770 that can communicate with clinician devices or patient devices 7780 located away from the hospital. The MMS 7704 also interfaces with an EMR 7790. Thus, in some embodiments, the medical network interface 7710 enables data from the stand-location device 7720 to be transmitted to any of the other components shown in FIG. 77B, among other possible components.

[0266] MMS7704 may be assumed to have all the functions of MMS2004 as described elsewhere in this specification. The specific functions shown can also be processed by MMS2004. This function includes the ability to route data to a nurse station (sometimes referred to as a central station). Data received from the stand-alone patient device 7720 of the medical network interface 7710 can be provided to, among other things, stations, central stations, and clinician devices. MMS7704 can also execute clinician notifications, for example, by routing alarms obtained from the patient device 7720 to devices 7760, 7780. Further, MMS7704 can perform analysis and journal processing, for example, as disclosed in U.S. Patent No. 9,142,117, titled "Systems and Methods for Storing, Analyzing, Retrieving and Displaying Streaming Medical Data", filing number MASIMO.609P1C1, filed on September 22, 2015, and U.S. Application No. 62 / 463,262, titled "Systems and Methods for Storing, Analyzing, Retrieving and Displaying Streaming Medical Data", filing number MASIM0.1131PR, filed on February 24, 2017, which are hereby incorporated by reference in their entirety. Further, MMS7704 can include a telepresence module for performing telepresence monitoring of a patient by a clinician from a remote location, for example, as described in U.S. Publication No. 2014 / 0077956, titled "Intelligent Medical Network Edge Router", filed on September 18, 2013, which is hereby incorporated by reference in its entirety. Further, MMS7704 may be expandable, like MMS2004, and can supply data to other software engines and databases, including EMR7790.

[0267] Data obtained from the stand-alone patient device 7720 (or from the patient monitor of FIG. 77A) by the medical network interface 7710 can take one or more of the forms of waveform data, parameter data, or event data. The waveform data can include trend data, which may be high-frequency data. The network interface 7710 and / or the MMS 7704 may be configured to handle this data in the same manner as video streaming data, such that in the event of losses (e.g., due to buffer overflow), those losses are ignored. The parameter data (e.g., physiological parameter measurements such as oxygen saturation values) may come at a set frequency such as once per second (1 Hz). The medical network interface 7710 may combine the parameter data into a patient snapshot and provide this snapshot to the MMS 7704 or other devices shown. The event data can include event-driven data such as alarms (e.g., parameter values outside of bounds) and alerts (e.g., a process is slowing down or an alarm setting has been changed on the device 7720). Events may be supplied asynchronously when they occur, and the medical network interface 7710 may timestamp any events received from the patient device 7720 before supplying the event data to other devices on the network.

[0268] XI. Example of a Medical Network Interface FIGS. 78A and 78B show the schematic of an exemplary embodiment of the medical network interface 7710 described above. FIG. 78A shows a schematic front perspective view 7800a, while FIG. 78B shows a schematic rear perspective view 7800b of the exemplary medical network interface 7710.

[0269] As shown in FIG. 78A, the front of an exemplary medical network interface 7710 can include an Ethernet® port 7810, a channel port 7822, and a USB port 7832 (among others, not shown). The medical network interface 7710 can also include an optional display screen 7850 and a label 7840. As shown in FIG. 78B, the back of the medical network interface 7710 can include two USB ports 7824 and one Ethernet® port 7834. The back of the medical network interface 7710 can also include a power port 7860 that can accept a power cord. The power cord can connect the medical network interface 7710 to an AC outlet (e.g., on the wall of a patient's hospital room).

[0270] The Ethernet (registered trademark) port 7810 can be an example of the "Ethernet" port shown in FIG. 16. The Ethernet (registered trademark) port 7810 can also be an embodiment of the serial port 210 shown in FIGS. 24 and 74A. The channel port 7822 is an embodiment of the port 113 shown in FIG. 1B, the channel port 212, or the universal connector port shown in FIGS. 11E and 11F. The channel port 7822 can be configured to mate with a dedicated connector that can be connected to a device (e.g., illustrated in FIG. 77A) via a cable. Advantageously, in some embodiments, the medical network interface 7710 can include more ports than the hub 100. For example, the hub 100 can include four Ethernet (registered trademark) ports 7810, while the medical network interface 7710 can include eight (or more) Ethernet (registered trademark) ports 7810. As a result, the medical network interface 7710 can increase the number of devices that can communicate with the MMS2004 (and other devices; see FIG. 77B) (e.g., via the medical network interface 7710). Alternatively, the medical network interface 7710 may have the same number of ports as the hub 100 or fewer ports than that.

[0271] The medical network interface 7710 can also include a USB port for connecting to other devices in the patient's hospital room. The USB port can be configured to support Type-A, Type-A Superspeed, Type-B, Type-B Superspeed, Type-C, Mini or Micro USB (e.g., Mini-A, Mini-AB, Mini-B, Micro-AB, Micro-B, Micro-B Superspeed), or other types of USB connectors known to those skilled in the art.

[0272] In some embodiments, the medical network interface 7710 can also support a wireless connection. The wireless connection can involve Bluetooth®, Wi-Fi, ZigBee, or other types of wireless connections. As will be described in more detail below with reference to FIG. 81, the medical network interface 7710 can use a dongle to pair the medical network interface 7710 with a device that can communicate with the medical network interface 7710. For example, the dongle can be plugged into one of the USB ports 7832. The dongle can receive information from the medical network interface 7710 via the connector port 7832. Next, the user can disconnect the dongle from the medical network interface 7710 and plug the dongle into one of the stand-alone devices. The stand-alone device can then communicate with the medical network interface 7710 using the wireless capabilities of the dongle, which can utilize the information of the dongle obtained from the medical network interface 7710.

[0273] This received information can be security information. For example, the dongle can receive a permission key from the medical network interface 7710. This key can be a cryptographic key, which can be used with an asymmetric or symmetric encryption algorithm (such as a secret or public key). The dongle can then be plugged into a medical device, whereby the medical device also receives or generates a permission key. The medical network interface 7710 can interrogate the devices within its environment and identify medical devices that have the permission key. In one embodiment, after the medical network interface 7710 identifies a medical device and authenticates the permission key, the medical network interface 7710 can communicate with the medical device wirelessly.

[0274] The medical network interface 7710 can also receive signals (e.g., RFID, Wi-Fi, Bluetooth (registered trademark)) emitted by medical devices that require direct pairing with the medical network interface 7710. Thus, in one embodiment, the dongle is not necessary for pairing with a stand-alone patient device. The medical network interface 7710 can reply with a pairing protocol (or permission key) to establish a connection for transferring patient data.

[0275] Another possible approach is for the medical network interface 7710 to interrogate the medical device to determine what protocol the medical device uses to communicate. For example, the medical network interface 7710 can attempt to communicate with the medical device using a first protocol (e.g., wirelessly), and then, if that protocol fails, attempt communication with a second protocol, and continue this process until the correct protocol that the medical network interface 7710 uses to communicate with the medical device is selected. This protocol may refer to a network communication protocol, a message format used by the medical device, and / or a data format used by the medical device. For example, this protocol may refer to whether the messages used by the medical device have a fixed length or a dynamically variable length, whether a checksum or CRC (cyclic redundancy check) code is used, framing parameters, etc. Further, the medical network interface 7710 can communicate with the medical device using a standard protocol such as TCP / IP, and optionally, in addition to that, a custom application layer specific to the medical device. For example, the medical device may format the application layer messages in a manner specific to that medical device. The medical network interface 7710 can sequentially try different possible protocols--including different message formats--and continue until the correct message format that can understand the messages transmitted by the medical device is found.

[0276] For example, a message format may well include key-value pairs (sometimes also referred to as tag-value pairs), where the key defines the type or category of data (parameter type, alarm, etc.), and the value is an instance of those types or categories (specific parameter value, alarm state, etc.). The protocol or message format used by a medical device may be custom, whereby the medical network interface 7710 can inspect the messages received from the medical device and thereby automatically determine what message format or protocol is used by the medical device. The message format used by a medical device may well be formatted according to XML, whereby the tag-value pairs are directly machine-readable by the medical network interface 7710 from the XML. The medical network interface 7710 can include a library of different protocols or message formats for different medical devices and can thus be read. In an exemplary implementation, the medical network interface 7710 identifies the type of device wirelessly connected to the medical network interface 7710 based on analyzing the message format from the medical device, comparing the message format to known message formats in the protocol library, and identifying the correct medical device from the library.

[0277] The medical network interface 7710 can associate one or more identifiers with data obtained from a patient device. The medical network interface 7710 can, for example, have its own identifier. Each stand-alone patient device may be assumed to have its own dedicated identifier, either supplied by the device or generated by the medical network interface 7710. Further, each patient may be assumed to have an identifier. The patient identifier may be obtained by optically scanning a machine-readable code, such as a QR (Quick Response) code or a barcode, which may take the form of a tag or sticker on the patient's list bracelet. The optical scanner may be attached to the medical network interface 7710 for this purpose, or the clinician may use their phone, tablet, or other device to perform the scan function. The scan function is described in more detail in U.S. Application No. 14 / 511,972, filed October 10, 2014, entitled "Alarm Notification System," docket number MASIM0.963A, which is hereby incorporated by reference in its entirety. The features in this '972 application may be used, for example, in combination with the features described herein, by performing a scan of a patient or device identifier using these features.

[0278] In some embodiments, the medical network interface 7710 tags or associates data received from a patient device with a patient identifier, a device identifier, and a medical network interface identifier. The medical network interface 7710 can supply the data, along with this identification data, to the MMS2004 or 7704 (for convenience, when referring to one of the MMS2004 or 7704 individually in the remainder of this specification, this may be considered to also refer to the other).

[0279] Optionally, the medical network interface 7710 can include a display 7850. The display 7850 can indicate which patient the medical network interface 7710 is associated with and which devices are currently communicating with the medical network interface 7710. The display 7850 can also provide an indication of the pairing status. For example, in some embodiments, the display 7850 can indicate information about the medical device during or immediately after pairing (and optionally any of the identification information described above). The display 7850 can also illuminate a light pattern to indicate that the medical device is paired with the medical network interface 7710.

[0280] In addition to, or alternatively to, the ports shown in the front perspective view 7800a, the medical network interface 7710 can also include various ports on the back as shown in the rear perspective view 7800b of FIG. 78B. For example, the medical network interface 7710 can include two USB ports 7824 and one Ethernet® port 7834. One of the USB ports 7824 can connect the medical network interface 7710 to the patient monitor 7701, while the other USB port can connect the medical network interface 7710 to a display device that can collectively display the patient's data. The medical network interface can also be connected to the hospital's main network using the Ethernet® port 7834. The medical network interface 7710 can pass data obtained from a medical device via the Ethernet® port 7834 to the MMS 2004.

[0281] The medical network interface 7710 can also include a power port 7860. The power cord can be used to connect an AC outlet in the environment to the patient monitoring box 7710 (via the power port 7860). In some embodiments, the medical network interface 7710 attaches and secures the power cord to the power port 7860. The medical network interface 7710 can also have a backup battery (such as an uninterruptible power supply (UPS)) for use in the event of a power outage. In some implementations, the power port 7860 (or the power cord) is optional. The medical network interface 7710 can be powered from a battery.

[0282] The medical network interface 7710 can be assigned to a specific patient such that the medical network interface 7710 can obtain data from medical devices (e.g., pumps, ventilators, other devices, or sensors) associated with the patient. The medical network interface 7710 can also be configured to collect data from multiple patients. Advantageously, in some embodiments, a portion of the medical network interface 7710 can be color-coded to indicate from which patient the data received at a port is. For example, the four ports above the Ethernet® port 7810 can be color-coded yellow, while the four ports below the Ethernet® port 7810 can be color-coded blue. (More generally, some of the ports on the device can be color-coded to represent one patient, while other ports on the device can be color-coded to represent another patient.) Yellow represents data from devices associated with Patient A, while blue represents data from devices associated with Patient B in this case. As another example, the left side of the front of the medical network interface 7710 can be color-coded yellow to indicate that the ports on this side of the medical network interface 7710 should be connected to medical devices of Patient A. The right side of the front of the medical network interface 7710 can be color-coded blue to indicate that the ports on this side of the medical network interface 7710 should be connected to medical devices of Patient B. The display 7850 can also provide an indication as to from which patient the medical network interface 7710 is collecting data. For example, the display 7850 can list the patient ID associated with Patient A on one line and the patient ID associated with Patient B on the next line. The display can be a touch screen or other means.

[0283] More generally, data received on a particular color-coded port for one patient can be automatically associated with that patient's ID at the medical network interface, while data received on another color-coded port for another patient can be automatically associated with that patient's ID at the medical network interface.

[0284] In some embodiments, pairing using the dongle does not require entering a passcode on either the dongle or the patient device or the medical network interface. By avoiding this requirement, the clinician can quickly pair the network interface and the patient device without being distracted by entering a pairing code that could take time away from treating the patient. This hands-free operation (except for inserting the dongle) can enable the clinician to quickly return to treating the patient and more quickly obtain data from the patient device. However, in other embodiments, a pairing code is used.

[0285] Exemplary components including ports 7810, 7822, 7824, 7832, 7834, 7860, display 7850, and label 7840 are shown only schematically. Medical network interface 7710 can comprise fewer or more components as illustrated. Further, the positions of these components in FIGS. 78A and 78B are for illustration only, and these components need not be arranged at the positions illustrated in these figures. For example, one or more of the ports in FIG. 7800a may be moved to the back of medical network interface 7710. Further, the sizes of these exemplary components are not illustrated to scale. In addition, some ports may be arranged on the sides of the device instead of or in addition to the front or back portions.

[0286] XII. Examples of Dongles FIG. 79 shows an exemplary embodiment of a dongle 7900 used to pair a medical network interface 7910 with another device. The dongle 7900 may be used for pairing for Bluetooth®, Wi-Fi, or other types of wireless communication. Advantageously, in some embodiments, the use of wireless communication among medical devices results in a cleaner hospital environment with fewer infections (e.g., by reducing cable sharing), and user interaction with medical devices may become easier. As an example, by adopting wireless communication, an operating room no longer needs to use long Ethernet® cables to connect various medical devices.

[0287] The dongle 7900 can be equipped with an antenna 7920 (or beacon), a location tag 7930, a battery 7940, and a processing unit 7910. The processing unit 7910 can include a processor 7912, a memory 7914, and a network interface 7916. The processing unit 7910 can include an embodiment of the core board 312. The dongle 7900 can also be provided with an optional display 7952 and / or a light 7954. In various embodiments, the dongle 7900 can be provided with fewer or more components as illustrated in FIG. 79. For example, the dongle 7900 can be provided with either, but not both, the beacon 7920 or the location tag 7930.

[0288] The dongle 7900 can be used to pair a medical network interface 7710 with a medical device that requires communicating with the medical network interface 7710. A clinician can insert the dongle 7900 into one of a USB port 7822 or an Ethernet® port 7810 to obtain a permission key. For example, the processing unit 7910 can be programmed to communicate with the medical network interface 7710 to receive a permission key from the medical network interface 7710 after the dongle 7900 is plugged into the medical network interface. The permission key can include a device identifier of the medical network interface 7710. In addition or alternatively, the permission key can be a password, a token, or an encryption / decryption key for establishing communication with the medical network interface 7710.

[0289] The clinician can insert the dongle into the patient device. To establish a pairing between the medical network interface 7710 and the patient device after the dongle is inserted, the dongle 7900 can pass the permission key received from the medical network interface 7710 to the medical device, for example, by inserting it into a USB port of the medical device. In some embodiments, the medical device may not have a compatible port into which the dongle 7900 can be inserted. As a result, the dongle 7900 can use a connector that can adapt the dongle 7900 to connect to the port of the medical device.

[0290] The medical device can retrieve a permission key from the dongle 7900. The medical device can search for the medical network interface 7710 using the device ID received from the dongle 7900 (of the medical network interface 7710). As described above, to speed up pairing, the medical device can optionally avoid the need to provide a password to connect to the medical network interface. In some embodiments, the medical network interface 7710 interrogates the surrounding devices for a permission key. The medical network interface 7710 can establish a connection and receive patient data from the medical device if the medical device can provide a permission key in response to the interrogation of the medical network interface 7710.

[0291] In some embodiments, the permission key is supplied and shared to a plurality of medical devices that request connection to the medical network interface 7710. For example, the dongle 7900 can be plugged into the medical device A so that the medical device A can receive the permission key from the dongle 7900. The dongle 7900 can also be plugged into the medical device B and transfer the permission key to the medical device B. In some implementations, the dongle 7900 stores a plurality of permission keys, and the medical devices may receive different permission keys. For example, the dongle 7900 can store the permission keys A and B in the memory 7914, and the permission key A may be used to pair the medical network interface 7710 with the patient bed 214, and the permission key B may be used to pair the medical network interface 7710 with the ventilator 218. The permission keys A and B may have different expiration dates. For example, the permission key A (for the patient bed 214) may include a longer expiration date than the permission key B (for the ventilator 218). Further, in some situations, the permission keys A and B may be issued from two different medical network interfaces.

[0292] In some embodiments, the medical network interface 7710 can update the permission key periodically or based on a trigger event, reducing the probability that a malicious device can obtain a connection to the medical network interface 7710. For example, the permission key may be configured to automatically expire after a certain time period (e.g., 24 hours, one week, one month, etc.). The permission key may also be automatically updated, for example, when the medical network interface 7710 is associated with a new patient. The permission key may be stored in the memory 7914 so that it can be transferred to another device later. After the old permission key has expired, the medical network interface 7710 may need to be paired again with other devices.

[0293] In addition to using the dongle 7900 for pairing, or alternatively, other techniques can be used to pair the medical network interface 7710 with another medical device. For example, the medical network interface 7710 and the other device can be paired using a label (e.g., barcode or RFID, etc.) on the medical network interface 7710 or the other device. Additionally, a system administrator can add the device identifier of the medical device to the white list of the medical network interface 7710. Thus, the medical network interface 7710 can initiate communication with the medical device when the medical device is within the communication range of the medical network interface 7710. In some implementations, the dongle 7900 can obtain the permission key via a wireless connection. For example, the dongle 7900 may be configured to establish a connection with the medical network interface 7710 wirelessly and then receive the permission key from the medical network interface 7710 using the network interface 7916.

[0294] Advantageously, in some embodiments, the location of the dongle can be tracked by the location tag 7930 in addition to, or alternatively to, the antenna 7920. The location tag 7930 may be an RFID tag or the like. The location tag 7930 or the antenna 7920 can emit a signal that can be picked up by another device. For example, the patient monitor 7701 can automatically detect the dongle 7900. The patient monitor 7701 can determine the location (e.g., the room where the dongle 7900 is located) based on the signal emitted by the location tag or the antenna 7920. In some implementations, multiple patient monitors 7701 can pick up the signal of the dongle 7900. Thus, the location of the dongle 7900 can be identified by triangulation using the locations of the patient monitors 7701 or by triangulation using access points in the hospital. In some embodiments, a map of the hospital room can be electronically accessed by any of the devices shown in FIGS. 77A or 77B to determine the location of the dongle within the room. The map can indicate the location of the dongle as determined, for example, based on this triangulation or RFID tag positioning. If the connection between the dongle and the patient monitor is not operational, the dongle can attempt to communicate wirelessly with a nearby patient monitor that may be in a nearby hospital room. The dongle can transmit data wirelessly to a nearby patient monitor, and thus this data can be sent to a remote server or an electronic medical record so that it can be retrieved later by the patient monitor in the room having the dongle.

[0295] The dongle 7900 can also include a battery 7940. The battery 7940 can be charged while the dongle 7900 is plugged into one of the USB port 7822 or the Ethernet port 7810. For example, after the dongle 7900 obtains a permission key from the medical network interface 7710, the dongle 7900 can remain plugged in for charging.

[0296] The dongle 7900 can include an optional display 7952 and an optional light component 7954. The display 7952 and the light component 7954 can provide an indication indicating a pairing situation or the situation of the dongle 7900. For example, after the dongle 7900 is fully charged, the light component 7954 can light up in a specific color or pattern (e.g., green blinking) to indicate that the battery is fully charged. As another example, the display 7952 can display the device ID of the device into which the dongle 7900 is currently plugged. As yet another example, the light component 7954 can light up, or the display 7952 can provide an alert when the medical network interface 7710 is paired with a medical device using the permission key stored in the dongle 7790. In this example, assuming that the medical network interface 7710 is paired with the patient monitor 7701, the display 7952 can indicate the hub ID (e.g., 1162) and the status "paired". In addition to or alternatively to the visual indications provided by the display 7952 and the light component 7954, the dongle can also include a speaker that plays a sound indicating the pairing situation or the situation of the dongle 7900. The color, pattern, sound, or display can be easily visible and distinguishable by the clinician.

[0297] Advantageously, in some embodiments, the dongle 7900 may be hot-swappable without interrupting the function of the device into which the dongle 7900 is plugged. For example, the dongle may be plugged into the patient medical device 7720 (either directly or via a dongle socket). The dongle may consume battery power to communicate with the medical network interface 7710 while plugged into the patient medical device 7720. However, the physician may notice that the battery power of the dongle has decreased due to the light component 7954 turning amber. The physician can unplug the dongle from the patient medical device 7720 and swap the dongle with a fully charged dongle that is currently plugged into the medical network interface 7710. Thus, the physician can plug the fully charged dongle into the patient medical device 7720 while the dongle with decreased battery power is plugged back into the medical network interface 7710 for charging. During the execution of this swap process, the communication between the patient medical device 7720 and the medical network interface 7710 may remain uninterrupted. For example, to avoid interruption of data transmission, the patient medical device 7720 may assume that the fully charged dongle has the same permission key (for the same medical network interface 7710) as the dongle with decreased battery power, and that no pairing with the fully charged dongle is necessary since the fully charged dongle is plugged into the patient medical device 7720 within a specific threshold period when the dongle with decreased battery power is removed.

[0298] Exemplary Components of a Medical Network Interface FIG. 80 shows an exemplary embodiment of the components of a medical network interface. These components are for illustrative purposes only, and the medical network interface 7710 may comprise fewer or more components than shown in FIG. 80.

[0299] The medical network interface 7710 can include hardware components such as, for example, a memory 8012, a processor 8014, a network interface 8016, and an optional backup battery 8020. In some embodiments, the hardware components can include a core board on which a main processor 8014 (or a separate processor) can act as a network bridge. The network interface controller 8016 can be configured to receive communications from various devices via a wired or wireless connection, such as, for example, Ethernet®, Wi-Fi, Bluetooth®, or other types of connections. The network interface controller 8016 can be configured to pass data to another device, such as, for example, a patient monitor 7701, an MMS 2004, a multiparameter monitor, etc. As further described with reference to the network data processing system 8030, the processor 8014 and the memory 8012 can facilitate the transfer of this data together with the network interface controller 8016. For example, the memory can store instructions associated with the network data processing system 8030, and the processor 8014 can execute these instructions to identify a patient identifier and a device identifier of the device from which the network interface controller 8016 receives the communication. The processor 8014 can also associate the device identifier of the medical network interface 7710 with the data packet received from the device and pass the data packet (updated with the device identifier of the medical network interface 7710) to the patient monitor 7701 and the MMS 2004. In one embodiment, the network interface controller 8016 can act as a network bridge.

[0300] As described above with reference to FIG. 78A, the medical network interface 7710 can include a power port 7860 for obtaining power from an AC outlet. An optional backup battery 8020 can supply battery power in the event that the medical network interface 7710 cannot obtain power from another source (e.g., during a power outage). Thus, the medical network interface 7710 can be powered entirely by the battery.

[0301] The medical network interface 7710 can also include software components such as a network data processing system 8030, a device pairing system 8040, and an optional display system 8050. At least some of these software components may be stored in the memory 8012. The processor 8104 can be programmed to execute these software components.

[0302] The network data processing system 8030 can be configured to process data received from one device and pass that data to another device. The network data processing system 8030 can analyze the received packets to identify the device ID of the source of the data received by the medical network interface 7710. These packets can include a patient ID (which can be added by the device transmitting the data packet), and the network data processing system 8030 can appropriately identify the patient ID within the data received from the device. The network data processing system 8030 can also add the device ID of the medical network interface 7710 to the data received from the device and route that data to another device. Alternatively, the medical network interface 7710 may already store a patient ID based on a scan of the patient's list bracelet, as described above. Thus, the medical network interface 7710 can associate the patient ID, the ID of interface 7710, and the patient device ID with the data obtained from the patient device and send this data to MMS2004 or another device (such as hub 100 or another interface 7710).

[0303] The network data processing system 8030 can recognize the source of a packet by analyzing the packet. However, in some embodiments, the network data processing system 8030 does not process the content within the packet (e.g., parameter values of patient measurements, etc.). As an example of passing data, the medical network interface 7710 can be connected to the patient monitor 7701 and can receive packets from the pump. The packet can indicate the device ID for the pump and the patient ID. The network data processing system 8030 can add the device ID of the medical network interface 7710 to the header without modifying the parameter values obtained by the pump. Next, the network data processing system 8030 can transmit the marked or tagged packet to the MMS 2004.

[0304] Optionally, the network data processing system 8030 can prioritize packets based on a variety of factors such as, for example, patient ID, source of the data (e.g., which device sent the packet), destination of the data, or based on an alarm. For example, additional details regarding routing and prioritizing packets by devices such as MMS 2004, patient monitor 7701, medical network interface 7710, or another device (and as may be demonstrated herein) are described in Application No. 14 / 030,360, filed September 18, 2013, entitled "Intelligent Medical Network Edge Router", Docket No. MASIMO.909A, now U.S. Patent No. 9,749,232 ("the '232 patent"), which is hereby incorporated by reference in its entirety. Further, the medical network interface described herein can perform the functions of the edge router described in the '232 patent. For example, the medical network interface can prioritize alarms higher than other data or prioritize parameters higher than other data (optionally excluding alarms).

[0305] The device pairing system 8040 can control the permission key, identify devices in the environment for pairing with the medical network interface 7710, and establish a connection between a device in the environment and the medical network interface 7710. For example, the device pairing system 8040 can periodically generate or update the permission key for the dongle 7900. The device pairing system 8040 can also receive and process signals from the dongle 7900 or a medical device that requests to pair with the data collection system 7710. The device pairing system 8040 can authenticate a request to connect to the medical network interface based on whether the request includes the correct permission key.

[0306] An optional display system 8050 can generate user interface commands for an optional display 7850 (shown in FIG. 78A). For example, when a medical device is paired with a medical network interface 7710, the device pairing system 8040 can instruct the display system 8050 to generate a command to indicate the device identifier of the medical device on the display 7850. As another example, the display system 8050 can communicate with the network data processing system 8030 or the device pairing system 8040 to obtain the status of the devices connected to the medical network interface 7710 (e.g., disconnected, connected, paired, repair mode, etc.). The display system 8050 can thus instruct the display 7850 to present the status of the devices.

[0307] XIII. Exemplary Process for Pairing a Medical Network Interface FIG. 81 shows an exemplary embodiment of a state flow diagram for pairing a medical network interface with a medical device. The exemplary environment 8100 of FIG. 81 may be part of the environment 7700 shown in FIG. 77. The exemplary environment 8100 can involve a medical device 8110, a medical network interface 7710, and a dongle 7900. The medical device 8110 can be any of the devices exemplified in FIG. 77 or other devices described herein.

[0308] In state (1), the dongle 7900 can receive a permission key and optionally an identifier (of interface 7710) from the medical network interface 7710. The dongle 7900 can receive the permission key (and optionally the ID) when plugged into the medical network interface 7710. The dongle 7900 can be plugged into a USB port, a medical port, an Ethernet® port, or another port on the medical network interface 7710. The dongle 7900 can also receive the permission key (and optionally the ID) from the medical network interface 7710 using other technologies, such as a wireless method (e.g., Bluetooth®) pairing between the dongle 7900 and the medical network interface 7710.

[0309] In state (2), the dongle 7900 can pass the permission key (and optionally the ID) to the medical device 8110. For example, the dongle 7900 can be unplugged from the medical network interface 7710 and plugged into the medical device 8110 again. The medical device 8110 can detect that the dongle 7900 is connected and can automatically access the permission key (and optionally the ID) stored in the dongle 7900.

[0310] In state (3), the medical device 8110 can establish a connection with the medical network interface 7710. For example, the medical network interface 7710 can interrogate the devices in its vicinity and request a permission key to start the connection. As another example, the medical device 8110 can contact the medical network interface 7710 with a permission key to obtain access rights to the medical network interface 7710.

[0311] Medical device 8110 can communicate with medical network interface 7710 to transfer patient data (and optionally an ID) from medical device 8110 to medical network interface 7710. Medical network interface 7710 can further transfer the patient data to another device, such as patient monitor 7701 or MMS2004. Packets transmitted from medical device 8110 can include a patient ID and a device ID of medical device 8110 (or the patient ID may not be in the packet and instead is inserted into the data stream by interface 7710). Medical network interface 7710 can also associate another device ID of medical network interface 7710 with the data packet before the data is transferred to other devices. In some implementations, medical network interface 7710 can automatically link its device ID to the device ID (and patient ID) of medical device 8110.

[0312] In some embodiments, medical network interface 7710 can also receive data from other devices (e.g., from patient monitor 7701 or MMS2004) and transfer this data to medical device 8110. For example, medical network interface 7710 can receive commands from patient monitor 7701 to adjust parameters of medical device 7710 (e.g., increase the frequency of measurements or adjust the delivery rate of infusion pump 216). Medical network interface 7710 can transfer the commands received from patient monitor 7701 to medical device 7710 to cause medical device 7710 to execute the commands. In some embodiments, the connection between medical device 8110 and the medical network interface is maintained while dongle 7900 is plugged into medical device 8110. After dongle 7900 is removed from medical device 8110, communication between medical device 8110 and medical network interface 7710 can end.

[0313] Figure 82 shows an exemplary embodiment of a process for pairing a medical network interface with a medical device. Process 8200 may be executed by a medical network interface 7710.

[0314] In block 8210, the medical network interface can generate a permission key for pairing with a medical device. The permission key may be a randomly generated alphanumeric string. The permission key may also encode device information or a password associated with the medical network interface. The permission key may be updated periodically after initial pairing to reduce the probability of unauthorized devices or users obtaining access to the medical network interface.

[0315] In block 8220, the medical network interface can transfer the permission key to a dongle (such as dongle 7900, etc.). For example, when the dongle is plugged into a port of the medical network interface, the medical network interface can send the permission key to the dongle or receive a request to download the permission key (from the dongle).

[0316] In block 8230, the medical network interface can discover a medical device within the environment of the medical network interface. For example, the medical network interface can send an interrogation signal to peripheral devices and request that the peripheral devices provide the permission key. As another example, the medical device may initiate contact with the medical network interface (e.g., based on the device ID of the medical network interface) and provide the permission key to the medical device.

[0317] In block 8240, the medical network interface can verify the legitimacy of the permissions of a medical device, at least in part, based on a permission key. For example, the medical network interface can determine whether the permission key provided by the medical device is valid. In some embodiments, device pairing is performed over a wired connection. For example, the medical network interface can be connected to the MMS2004 using a USB connection. The medical network interface and the MMS2004 can be paired by receiving and recognizing the device identifier of the MMS2004 via the USB connection. In other embodiments, the medical network interface can pair with another device using a wireless connection without requiring a dongle. For example, the medical network interface can pair with the patient monitor 7701 via Wi-Fi. In this example, the device identifier of the medical network interface can be added to the whitelist of permitted devices for the patient monitor 7701. The patient monitor 7701 can use the device identifier of the medical network interface to find and connect to the medical network interface.

[0318] In block 8250, the medical network interface can establish a connection with the medical device in response to determining that the permissions have been verified as legitimate. The medical network interface can pass data received from the medical device to another device, such as the patient monitor 7701, the MMS2004, the multi-parameter monitor, and the extended reality device 7200.

[0319] XIV. Exemplary Process for Data Processing by a Medical Network Interface FIG. 83 shows an exemplary embodiment of a process 8300 for data processing by the medical network interface 7710.

[0320] In block 8310, the medical network interface can receive data packets from a first medical device. The first medical device can be a medical device that can acquire patient data (for example, other devices and sensors 7720 in FIG. 77, etc.). The patient data acquired by the first medical device can be associated with a patient ID that identifies from which patient the data was acquired. The patient data can also be associated with a first device ID, which can be the device identifier of the first medical device.

[0321] The medical device can transfer patient data to the medical network interface via a wired or wireless connection as described with reference to FIG. 78A. The first device ID and the patient ID can be part of a header file for the patient data. In block 8320, the medical network interface can process the data packet to link a second device ID associated with the medical network interface to the first device ID and the patient ID. In some embodiments, the medical network interface can link the second device ID to the first device ID when the medical network interface is paired with the first medical device. Thus, the link between the first device ID and the second device ID can be made before the first medical device transmits patient measurement results to the medical network interface. In some embodiments, after the medical network interface links the first device ID and the second patient device ID, the medical network interface can automatically stamp the device ID of the medical network interface on the data packet.

[0322] In block 8330, the medical network interface can identify a second medical device connected to the medical network interface 8330. The second medical device may be a patient monitor 7701, MMS2004, a display (e.g., a multi-parameter monitor, etc.), or another device described herein. The medical network interface can identify the second medical device by determining which device is plugged into the port. The medical network interface can also identify the second medical device by scrutinizing a list of devices connected in a wireless manner.

[0323] In block 8340, the medical network interface can transmit data packets to the second device. The data packet may include a first device ID that identifies the first medical device (which acquires patient data), a patient ID, and a second device ID (which may be imprinted by the medical network interface). The second device can further process the data packet, such as by routing the data packet to another device or system, perform data analysis, or display patient data.

[0324] Furthermore, it should be understood that troubleshooting of the medical network interface may be made possible by passing the identifier of the medical network interface along with the patient data.

[0325] Furthermore, in another embodiment, the wireless dongle comprises two pieces - the first piece remains connected to the medical network interface, and the second piece is severed from the first piece. The second piece is connected to a corresponding first piece of a similar dongle within the medical device. The exemplary dongles of FIGS. 77A - 83 are referred to as wireless connectors in FIGS. 84A - 88 as described below.

[0326] XV. Exemplary Techniques for Connecting a Medical Network Interface to a Patient Monitor As described with reference to FIGS. 77A - 78B, a medical network interface 7710 can be communicatively coupled to a patient monitor 7701 or a hub 100 via a wired or wireless connection. The medical network interface 7710 can also be mechanically coupled to the patient monitor 7701 or the hub 100 in addition to, or alternatively to, the wired or wireless connection. For example, the medical network interface 7710 can be mechanically coupled to the patient monitor 7701 by attaching the top or bottom surface of the medical network interface 7710 to the surface (e.g., top, bottom, or side) of the patient monitor 7701 or the hub 100. In some embodiments, attaching the medical network interface 7710 to the patient monitor 7701 or the hub 100 is not permanent, and thus, the patient monitor 7701 or the hub 100 can be detached from the medical network interface 7710. In other embodiments, the medical network interface 7710 is integrally formed with the hub 100 as part of the hub 100.

[0327] FIGS. 84A and 84B show an exemplary embodiment of a medical network interface where the medical network interface is removably attached to the bottom surface of a hub. The hub 8401 may be an embodiment of the patient monitoring hub 100 or the patient monitor 7701 described herein. The medical network interface 8410 may be an embodiment of the medical network interface 7710 of FIGS. 77A - 78B, and FIG. 80.

[0328] FIG. 84A shows a perspective view 8400a of a hub 8401 and a medical network interface 8410. The front face of the medical network interface 8410 can include various ports for interfacing with devices, such as, for example, a patient device 7720 or other devices shown within a computing environment 7700. In FIG. 84A, the front face of the medical network interface 8410 includes (by way of example) four interface ports 8412. Other embodiments may include more or fewer ports. The interface ports 8412 can be configured to connect to a wireless connector 8480. The wireless connector 8480 can be an embodiment of the dongle 7900 described in FIG. 79. As illustrated in FIG. 84A, three wireless connectors 8480 are currently plugged into three of the four interface ports 8412. The interface ports 8412 can be an embodiment of a USB port 7832. In some implementations, the wireless connector 8480 is a proprietary connector and the interface ports 8412 can be customized to receive the wireless connector 8480.

[0329] The medical network interface 8410 can be attached to the bottom of the hub 8401 using various mounting types or standards such as a GCX (registered trademark) slide-in track, a VESA mount, a tab mount, a universal mount. The medical network interface 8410 and the hub 8401 can also be bonded using other techniques such as a clamp or an adhesive. By way of example, one side of the hub 8401 can be provided with one or more clamps that can be used to hold the medical network interface 8410. In some embodiments, the hub 8401 includes one or more holes in its bottom surface. The top surface of the medical network interface 8410 can be provided with corresponding protrusions for insertion into the holes in the bottom surface of the hub 8401.

[0330] FIG. 84A illustrates four interface ports, but other types of ports may be provided on the front surface of the medical network interface 8410. For example, as described with reference to FIG. 78A, the medical network interface 8410 can also include an Ethernet® port 7810, a channel port 7822, or a USB port 7832. The medical network interface 8410 can also include fewer and more interface ports 8412, such as, for example, 2, 3, 6, 8, or other numbers of interface ports 8412. Further, although the four interface ports 8412 are arranged in the same row in FIG. 84A, the layout of the interface ports 8412 can be different in different embodiments. For example, the medical network interface 8410 can include multiple rows (such as two rows) of interface ports 8412, and optionally, each row can include the same number of interface ports.

[0331] The number and layout of the interface ports 8412 on the medical network interface 8410 can be determined based on the size of the medical network interface 8410. For example, if the medical network interface 8410 is designed to be a thin housing that fits directly under the patient monitor 8401, such as in the example shown in FIG. 84A, the medical network interface 8410 can include one row of interface ports 8412 to keep the height of the medical network interface 8410 small. On the other hand, if the medical network interface 8410 is designed to be mounted on either side (left or right) of the hub 8401, the medical network interface 8410 can be short in length and tall in height. Thus, the medical network interface 8410 can include four rows of interface ports 8412, and each row can include one interface port 8412.

[0332] The number and layout of the interface ports 8412 may also depend on the size and shape of the wireless connector 8480. For example, if the wireless connector 8480 is a USB Type-A connector, the medical network interface 8410 may include more interface ports 8412 than when the wireless connector 8480 takes the shape shown in FIG. 84A, because the USB Type-A port cannot occupy an area as large as that of a port configured to receive the wireless connector 8480 of the shape shown in FIG. 84A. However, one of the advantages of the wireless connector configuration shown and described in more detail below is that it has a larger battery capacity than a USB-sized device. Because of this large battery capacity, it may be possible to insert the wireless connector 8480 into a longer stand-alone medical device than a USB-sized device (which may be useful when, for example, a medical device does not supply power to the wireless connector).

[0333] FIG. 84B illustrates a rear view 8400b of a hub 8401 and a medical network interface 8410. As illustrated, the back of the hub 8401 can include two USB ports 8403, one Ethernet® port 8405, and four channel ports 8422. The two USB ports 8403, the one Ethernet® port 8405, and the four channel ports 8422 can each be an embodiment of a USB, Ethernet®, and RJ port, respectively, in FIG. 16. The back of the medical network interface 8410 can include one battery port 8460, two USB ports 8432, three Ethernet® ports 8434, and four channel ports 8422. Referring to FIGS. 78A and 78B, the battery port 8460 can be an embodiment of the battery port 7860, the USB port 8432 can be an embodiment of the USB port 7832, the Ethernet® port 8434 can be an embodiment of the Ethernet® ports 7810 and 7834, and the channel port 8422 can be an embodiment of the channel port 8422.

[0334] The medical network interface 8410 is shown as having ports under the hub 8401, but in some implementations, the medical network interface 8410 may be omitted. Rather, the hub 8401 itself may, for example, be provided with ports such as port 8422 on the front, back, side, or top of the hub 8401. Thus, some or all of the functions of the medical network interface 8410 can be incorporated within the hub 8401 or within another monitor or medical device. For example, an anesthesia machine (such as a Draeger Apollo (trademark) or the like) could incorporate the features of the medical network interface 8410. Further, any of the medical network interfaces described herein could also communicate with the hub 8401 through one of the hub's channel ports, for example, using the Massimo Open Connect (MOC) protocol as described in U.S. Patent Application No. 15 / 902,193, filed February 22, 2018, titled "System for Displaying Medical Monitoring Data," which is hereby incorporated by reference in its entirety.

[0335] Figures 84C and 84D show another example of the medical network interface 8410. The medical network interface 8410 can be connected to the monitoring hub 8401 as described with reference to Figures 84A and 84B.

[0336] FIG. 84C shows a front perspective view 8400c of a medical network interface 8410. Similar to FIG. 84A, the front of the medical network interface 8410 can include various ports for interfacing with devices, such as, for example, a patient device 7720 or other devices shown within the computing environment 7700. In contrast to FIG. 84A, the front of the medical network interface includes, for example, three interface ports 8412 and a display 8482. As described herein, the interface ports 8412 can be configured to connect to a wireless connector 8480.

[0337] Display 8482 may be an example of the display 7850 shown in FIG. 78A. Display 8482 may be arranged in the leftmost area of the front surface of the hub as shown in FIG. 84C. The medical network interface 8410 can replace one interface port 8412 with the display 8482 (compared with FIG. 84A). Display 8482 can show various information related to the medical network interface 8410, the hub 8401, and other devices connected to the network interface 8410. For example, the medical network interface 8410 may be connected to one or more medical devices via the hub 8401 and the wireless connector 8480. Display 8482 can provide an indication of the connection status to the hub 8401 and the medical device 8480. Display 8482 can also show information about the patient (such as patient identifier, monitored parameters, etc.) to whom the medical network interface is connected via the hub 8401 or other medical devices. Display 8482 can also display information indicating the status of the wireless connector or the battery charge status. Display 8482, or any display in this specification, can also output patient data such as waveforms, trends, and / or physiological parameter values. Therefore, the medical network interface described in this specification can also act as a patient monitor based on the data received through the interface port.

[0338] FIG. 84D shows a rear view 8400d of the medical network interface 8410. Similar to the view 8400b of FIG. 84B, the back of the medical network interface 8410 can include two USB ports 8432, three Ethernet® ports 8434, and four channel ports 8422. The medical network interface 8410 can also include a battery port 8462. The battery port 8462 can be an example of the battery port 7860 shown in FIG. 78B. The battery port 8462 can be configured to connect the medical network interface 8410 to an AC power outlet in the environment via a power connector. In this exemplary view 8400d, the battery port 8462 accepts a different power connector than the battery port 8460 shown in FIG. 84B.

[0339] As described in FIGS. 77A - 78B, the medical network interface 8410 can be connected to various medical devices, such as patient device 7720, hub 7801, multiple patient monitoring system 2004, etc., using ports 8432, 8434, 8422, or 8412. For example, one of the USB ports 8432 can be connected to one of the USB ports 8403 on the hub 7801. Another USB port 8432 of the medical network interface 8410 can be connected to a physician's computer. In addition to using the USB ports 8432, the hub 7801 and the medical network interface 8410 can be connected to each other via other technologies, such as, for example, channel ports 8422 and 8407, Ethernet® ports 8432 and 8405, or a dedicated port (not shown). In some embodiments, the dedicated port can be located on the top surface of the medical network interface 8410, and the connector to the dedicated port can be attached to the hub 8401. As another example, the dedicated port can be located on the hub 8401 (e.g., on the bottom or left / right surface), and the connector can be on the medical network interface 8410.

[0340] In some embodiments, the medical network interface 8410 can be used as a docking station for the hub 8401. The medical network interface 8410 can duplicate existing ports already on the hub 8401 or provide additional ports, either alone or in combination. Advantageously, in some embodiments, the medical network interface 8410 can provide more ports than physically exist on the hub 8401. This allows the hub 8401 to have fewer physical ports (or no such ports at all) while still providing the same range of features. For example, the Ethernet® port 8434 can increase the number of Ethernet® connections from 1 (such as provided by the Ethernet® port 8405) to 3. Similarly, the USB port 8432 can provide two additional USB connections and four additional channel ports to the hub 8401, enabling more devices to communicate with the hub 8401 (via the medical network interface 8410).

[0341] As described with reference to FIG. 78B, the medical network interface 8410 may be powered by a battery or connected to an AC outlet when a power cord is plugged into port 8460. In some embodiments, when the hub 8401 is connected to the medical network interface 8410, both the hub 8401 and the medical network interface 8410 can be powered when port 8460 is connected to an outlet via a power cord. As another example, when the hub 8401 is connected to a power source, the power source can also be used to power both the hub 8401 and the network interface 8410.

[0342] As shown in FIGS. 84A and 84B, the medical network interface 8410 can be mechanically attached to the hub 8401. For example, the top housing of the medical network interface 8410 can be attached to the bottom of the hub 8401. In various other embodiments, the top housing of the medical network interface 8410 can also be attached to the side or back of the hub 8401. The hub 8401 can also be mechanically attached to the surface of a physical structure within a hospital environment. For example, the bottom surface of the hub 8401 can be attached to the wall, door, or table of a patient's hospital room. In some embodiments, the medical network interface 8410 is attached to both the physical structure and the hub 8401, such that the medical network interface is sandwiched between the physical structure and the hub 8401. In other embodiments, the medical network interface 8410 is attached to one side of either the physical structure or the hub 8401 and not to both sides. The medical network interface 8410 can also be attached to the hub 8401 using other mechanisms, such as via magnetic force if a part of the medical network interface 8410 (e.g., the top of the medical network interface 8410), a part of the hub 8401, or both include magnets.

[0343] Figures 85A, 85B, and 85C show exemplary structures for mechanically mounting a medical network interface. Figure 85A shows an exemplary top housing 8510 of a medical network interface 8410. The top housing 8510 can include four holes for mounting to a hub 8401 or a physical structure. Figure 85B shows a bottom view 8520 of the hub 8401. The bottom 8530 can include a connection plate 8524. The connection plate 8524 includes four slots 8522 as illustrated in Figure 85B. The connection plate 8524 can be a VESA standard 75 / 100 connection plate that can include a square hole of 100×100 mm or 75×75 mm. The connection plate 8524 in Figure 85B shows a pattern of square holes of 100×100 mm, although in other examples the connection plate 8524 can have a pattern of square holes of 75×75 mm or a combination of patterns of square holes of 75×75 mm and 100×100 mm (the connection plate 8524 having eight slots 8522). Other configurations are possible.

[0344] The top housing 8510 of the medical network interface 8410 can be mounted to the bottom of the hub 8401 using screws. For example, four M4 screws can be used to attach the slots 8522 of the connection plate 8524 to holes 8512 on the top housing 8510.

[0345] In this example, the connection plate 8524 is disposed on the bottom surface of the hub 8401, but the connection plate 8524 need not be on the hub 8401. For example, the connection plate 8524 can be disposed on the medical network interface 8410, and the bottom surface of the hub 8401 can include four holes for attaching the medical network interface 8410.

[0346] FIG. 85C shows a bottom perspective view of the medical network interface 8410 after the medical network interface 8410 is attached to the hub 8401. The bottom surface 8540 can include holes 8542. The holes 8542 may also follow a pattern of square holes of 100×100 mm or 75×75 mm. The medical network interface 8410 can be attached to a wall using a wall mount. For example, one end of the wall mount may be attached and fixed to the wall, while the other end of the wall mount may include a connection plate having the same hole pattern as the hole pattern of the holes 8542. Thus, the medical network interface 8410 can be attached to the wall mount by attaching the wall mount to the bottom surface 8540 using screws.

[0347] Although a VESA mount is used as an example in FIGS. 85A - 85C, other types of mounting interfaces can also be used on the top housing 8510 of the medical network interface 8410, the bottom surface 8540 of the hub 8401, or the bottom surface 8540 of the medical network interface 8410. For example, the hole pattern can also reflect a universal mount. As another example, the medical network interface 8410 and the hub 8401 can be mounted using a GCX (registered trademark) slide - in mount. Further, the top and bottom surfaces of the medical network interface 8410 do not have to have the same hole pattern. For example, the bottom surface of the medical network interface 8410 has a hole pattern for a universal mount (which can facilitate wall - mounting smoothly), while the top surface of the medical network interface 8410 can have a VESA mount. As another example, when the medical network interface 8410 can be mounted on one side, the medical network interface 8410 does not have to have holes on both the top and bottom surfaces. In one embodiment, the holes are arranged on the top surface of the medical network interface 8410. The top surface is mounted to the hub 8401, while the bottom surface can be placed on a tabletop. The medical network interface 8410 can also be mounted alone on a wall (e.g., via the top surface) without the hub 8401 being attached to the bottom surface.

[0348] The medical network interface 8410 does not need to be mounted on the hub 8401 in the same manner as illustrated in FIGS. 85A - 85C. The medical network interface 8410 can be mounted on the left, right, or back using the techniques described herein. For example, the back of the hub 8401 can include a connection plate for mounting the medical network interface 8410 using the VESA standard. Further, it is not necessary for the medical network interface 8410 to be attached to the hub 8401 using the top surface of the medical network interface 8410. For example, the bottom surface, left surface, or right surface can also be used to mount the medical network interface 8410 to the hub 8401.

[0349] In addition to or alternatively to mounting on the hub 8401, similar techniques can be used to mount the medical network interface 8410 with other medical devices such as the patient device 7720, device 7760, or other devices illustrated in the computing environments 7700 and 7702. For example, the medical network interface 8410 can be mounted on a patient bed using the techniques described herein.

[0350] XVI. Exemplary Mechanical Structures of Wireless Connectors and Dongle Sockets As described herein, the medical network interface 8410 can be communicatively coupled to various devices and systems such as the hub 8401, MMS 2004, patient device 7720, or another medical network interface 8410 using a wired or wireless connection. The medical network interface 8410 can include an interface port 8412 configured to receive a wireless connector 8480. The wireless connector 8480 can be used to pair the medical network interface 8410 with another device to achieve communication in a wireless manner. The interface port 8412 can be a dedicated port, a USB port, or another type of port as described with reference to FIG. 84A.

[0351] The wireless connector 8480 can include various software and hardware components to achieve the functions described above, for example, with reference to FIGS. 77A - 83. FIGS. 86A and 86B show exemplary embodiments of the hardware components of the wireless connector. The wireless connector 8480 can be an embodiment of the dongle 7900 described in FIG. 79. The dongle 8480 of FIG. 86A can include a housing 8670, data storage and processing components 8610, and optionally one or more lights 8654 (e.g., elongated light-emitting diodes (LEDs)).

[0352] The housing 8670 can accommodate various hardware components. For example, a part of the data storage and processing component 8610 and the battery 8640 are positioned inside the housing 8670 as shown in FIG. 86B. The battery may be a 3.7V, 280mAh battery, but other specifications are also possible. In some embodiments, there are two batteries 8640 inside the housing 8670. As an example, one battery may be positioned on top of the data storage and processing component 8620, and the other battery may be placed below the data storage and processing component 8620. The battery 8640 can be charged when the wireless connector 8480 is plugged into the medical network interface 8410 (e.g., via the interface port 8412) as described in FIG. 79, or when the wireless connector is plugged into the stand-alone patient device 7720 as described with reference to FIGS. 87A - 88.

[0353] The data storage and processing component 8610 can include a processing unit 7910. Thus, the data storage and processing component 8610 can perform functions such as pairing, data reception and transmission, and various other functions as described in FIGS. 77A - 83. If the wireless connector 8480 includes a battery 8640, the data storage and processing component 8610 can also include an antenna 7920 in addition to the processing unit 7910. The antenna 7920 can be arranged inside the housing 8670.

[0354] Light 8654 can be an embodiment of the light component 7954 shown in FIG. 79. Light 8654 can comprise an LED strip or elongated LEDs. As described in FIG. 79, the light pattern by which light 8654 emits light can indicate the situation of the wireless connector 8480. This situation can include, among other things, the connection situation (e.g., whether a medical device is paired with the medical network interface 8410), the handshake situation (which may be part of the connection situation), or the battery situation. As an example of indicating the battery situation, light 8654 emits green light when the battery is fully charged and amber light when the battery is about to run out. A plurality of lights may be provided, such that one light indicates the charging situation and one light indicates the connection situation, data transfer situation, or the like.

[0355] Although not illustrated in FIGS. 86A and 86B, the housing 8670 can also house other components inside. For example, the housing 8670 can also house a location tag 7930 that can facilitate another device (hub 8401) to determine the location of the wireless connector 8480.

[0356] The wireless connector 8480 can have a back surface 8602 and a front surface 8604. The front surface 8604 can comprise light 8654. The back surface 8602 is inserted into the interface port 8412, thereby enabling communication to be established between the wireless connector 8480 and the medical network interface 8410. The back surface 8602 can also be inserted into a port within the medical device 8110 so that the medical device 8110 can communicate wirelessly with the medical network interface 8410.

[0357] In some situations, the medical device 8110 may not have a port (e.g., an interface port or a USB port) suitable for inserting the wireless connector 8480. To enable wireless communication via the wireless connector 8480, advantageously, in some embodiments, the dongle socket can comprise a medical connector for connecting to a port on the medical device 8110. The dongle socket can comprise the wireless connector 8480, thereby enabling the wireless connector 8480 to be connected to the medical device via the medical connector.

[0358] Figures 87A - 87D illustrate an exemplary embodiment of a dongle socket that can connect a medical device to a wireless connector. The dongle socket may be referred to as a dongle in the example described with reference to Figures 87A - 88. Figure 87A shows a medical network interface 8410 attached to a hub 8401 and a dongle 8710 that can be connected to a medical device 8110, such as a pump or a ventilator (see, e.g., Figure 81).

[0359] The dongle 8710 can comprise a front face 8702 and a back face 8704. The front face 8702 can comprise a socket housing 8712 that can accommodate the wireless connector 8480.

[0360] The wireless connector 8480 may have been previously plugged into the medical network interface 8410 for charging or for obtaining a permission key. The socket housing 8712 may be connected to a medical device connector 8714 disposed on the back 8704 of the dongle 8710 via a wire 8724. The medical device connector 8714 may be plugged into a part of the medical device 8110. The port of the medical device 8110 may be a video graphics array (VGA) port, a digital visual interface (DVI) port, a high-definition multimedia interface (HDMI (registered trademark)) port, a USB port, an Ethernet (registered trademark) port, a dedicated port, or other types of ports configured to perform electronic data transmission. Advantageously, in some embodiments, by connecting the wireless connector 8480 to the port of the medical device 8110 via the dongle 8710, the medical device 8110 can be paired with the medical network interface 8410 and transmit data to the medical network interface 8410 wirelessly.

[0361] In addition or alternatively, the pairing between the medical device 8110 and the medical network interface 8410 can be achieved by bringing the dongle 8710 closer to the medical network interface 8410. The medical network interface 8410 can automatically scan for nearby devices and identify the dongle 8710 when the dongle 8710 enters the range of the medical network interface 8410. In this embodiment, a separate wireless connector 8480 may be omitted, and thus the function of the wireless connector 8480 is integrated into the dongle 8710. Alternatively, the dongle 8710 can include a detachable wireless connector 8480. The back surface 8704 of the dongle 8710 can be plugged into the medical device 8110. After the wireless connector 8480 (integrated or separate) within the dongle 8710 is recognized, the medical network interface 8410 can assign and establish a connection to the medical device 8110 (via the wireless connector 8480). Advantageously, in some embodiments, by integrating the function of the wireless connector 8480 with the dongle 8710 (e.g., by providing a transceiver and a battery integrated with the dongle 8710), the dongle 8710 can be paired simply by bringing the dongle 8710 within the wireless range of the medical network interface 8410.

[0362] In some embodiments, the wireless connector 8480 does not have a battery, and the medical device 8110 can supply power to the wireless connector 8480 via the dong...

Claims

**Claim 1** A wireless adapter for a stand-alone medical device, a wireless dongle, a socket housing at a first end of the wireless adapter along the longitudinal axis of the wireless adapter, the socket housing being configured to receive the wireless dongle, and a medical device connector at a second end of the wireless adapter opposite the first end along the longitudinal axis, the medical device connector being electrically connected to the stand-alone medical device, receiving patient data from the stand-alone medical device, transferring the patient data to the wireless dongle such that the wireless dongle can wirelessly transmit the patient data to a medical network interface coupled to a patient monitoring hub, the wireless dongle being already inserted into a port of the medical network interface so as to enable pairing between the stand-alone medical device and the medical network interface when the wireless dongle is received within the socket housing. A wireless adapter. **Claim 2** The wireless dongle accommodates information provided by the medical network interface when the wireless dongle is inserted into the port of the medical network interface, the information being sufficient for the wireless dongle to provide wireless connectivity between the medical network interface and any one of a plurality of medical devices, the plurality of medical devices including the stand-alone medical device. The wireless adapter according to claim 1. **Claim 3** The wireless adapter according to claim 2, wherein the medical network interface is assigned to a specific patient and the plurality of medical devices are assigned to the specific patient. **Claim 4** The wireless dongle is configured to transmit a permission key from the medical network interface to the stand-alone medical device, whereby the connection between the stand-alone medical device and the medical network interface is authenticated using the permission key. The wireless adapter according to claim 2.

5. The stand-alone medical device is a legacy device that does not have the function of communicating wirelessly with the medical network interface. The wireless adapter according to claim 2.

6. The connectivity between the medical network interface and the stand-alone medical device is established without the need for reprogramming the stand-alone medical device. The wireless adapter according to claim 2.

7. The medical network interface is configured to automatically scan for nearby devices and identify the wireless dongle when the wireless dongle enters the range of the medical network interface. The wireless adapter according to claim 2.

8. The wireless dongle includes a data storage device, a processing unit, and a battery. The wireless adapter according to claim 1.

9. The wireless adapter is configured to be charged wirelessly. The wireless adapter according to claim 8.

10. The wireless dongle further includes an elongated light indicating the battery level or power status. The wireless adapter according to claim 8.

11. The wireless dongle further includes an elongated light indicating the connection status. The wireless adapter according to claim 8.

12. The wireless dongle does not include a battery. The wireless adapter according to claim 8.

13. The wireless adapter further comprises a power cable, which is electrically connected to the socket housing at a first end thereof, and is configured to be connected to a power supply at a second end thereof opposite to the first end, the power cable being configured to receive power and supply power to the wireless dongle when the wireless dongle is received within the socket housing, the wireless adapter according to claim 1.

14. The medical device connector is configured to be connected to a port of the stand-alone medical device, the port being a video graphics array (VGA) port, a digital visual interface (DVI) port, a high definition multimedia interface (HDMI (registered trademark)) port, a USB port, an Ethernet port, a dedicated port, or any other type of port configured to perform electronic data transmission, the wireless adapter according to claim 1.

15. The socket housing has a front face and a back face, the front face comprising an opening shaped to receive the wireless dongle, the wireless adapter according to claim 1.

16. The socket housing further comprises a connector inside thereof, the connector being configured to receive a preliminary connector on the wireless dongle, the wireless adapter according to claim 15.

17. The socket housing further comprises a circuit configured to interface the wireless dongle and the medical device connector, the wireless adapter according to claim 16.

18. The back face of the socket housing comprises at least two sockets configured to be attached to different cables, the wireless adapter according to claim 15.

19. The socket housing has a size such that when the wireless dongle is received within the socket housing, a part of the wireless dongle protrudes from the socket housing, the wireless adapter according to claim 1.

20. The wireless adapter according to claim 1, further comprising a cable having a first end and a second end opposite the first end, wherein the first end of the cable is coupled to the socket housing, the second end of the cable is coupled to the medical device connector, and the cable is configured to transfer the patient data from the medical device connector to the socket housing.

Images