Patent ID: 12186052

While the invention is amenable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the invention to the particular embodiments described. On the contrary, the invention is intended to cover all modifications, equivalents, and alternatives falling within the scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION

FIG.1illustrates a screen aggregation system100, which may also be referred to as a remote interface system, including patient monitoring devices10each configured for physical attachment to patient5, according to embodiments of the present invention. As one example, patient monitoring device10may be a defibrillator, and electrodes from the defibrillator10may be attached to the patient5. For example, device10may be a ZOLL® X Series or R Series patient monitor and defibrillator equipped as described herein. Other sensors may also be attached to the patient, either physically or wirelessly, for example a blood pressure sensor, heart rate monitor, or a pulse oximeter. The monitoring device10may include a display screen11configured to display information about the patient5, for example the patient's electrocardiogram ECG wave data, blood pressure over time, heart rate, pulse oximetry data, alarms, and other patient information, according to embodiments of the present invention.

FIG.1also illustrates a remote interface device20, which may also be referred to as a screen aggregation device20, which is configured to communicate wirelessly or with a wired connection with each of the patient monitoring devices10. The remote interface device20includes a screen22for displaying information. The screen22may be controlled by a display module which causes the screen22to display information about two or more of the patient monitoring devices10. For example, as shown inFIG.1, the screen22may be configured to display the user interface screen11of each device10in one of six screen positions31-36of screen22. For example, the user interface11of one device10is shown in screen position31; the user interface11′ of another device10′ is shown in screen position32; and the user interface11″ of another device10″ is shown in screen position34. According to some embodiments, the user interfaces11,11′,11″ are viewed remotely on screen22in “real time,” such that what is displayed on each of user interfaces11,11′,11″ is displayed simultaneously on screen22.

According to other embodiments of the present invention, the screen22is configured to display information or data received from devices10,10′,10″ other than, and/or in addition to, the information or data simultaneously displayed on screens11,11′,11″. In some cases, the screen22is configured to display information or data from devices10,10′,10″ which those devices are simply unable to display, or are not configured to display under any circumstances. This could include data which may be deemed not important enough to display on the device10due to device's role in monitoring a patient and conveying critical patient information, and may also include data of a different type or format than that displayed on device10, including for example historical data or combinations or plots of certain data types.

Although six screen positions31-36are shown on device20, one of ordinary skill in the art will appreciate based on the present disclosure that various other numbers, shapes, layouts, and configurations of screen positions may be used, according to embodiments of the present invention.

FIG.2illustrates a device10and device20, according to embodiments of the present invention. Patient monitoring device10may include one or more sensors108configured for physical attachment to a patient, a processor100configured to receive information from the one or more sensors108and to generate patient data based on the information, a web server102, a wireless or wired communication system104, a database106, and a display or screen11configured to display a representation of at least a portion of the patient data. The remote interface device20includes a wireless or wired communication system204, a screen or display22, a processor200, and a web browser202, according to embodiments of the present invention. The processor200may be configured to run an application, for example in the form of instructions stored in database206and executable by processor200. Such an application may be configured to detect a presence of the first wireless or wired communication system104. This detection may be accomplished using an auto-discovery system, for example multicast domain name system (mDNS). Example of auto-discovery systems that may be used by processor200to discover the communication system104include Apple Bonjour and Rendezvous, Avahi, Zeroconf, mDNS, and the like. As used herein, “communication system” is used in its broadest sense to refer to a system capable of establishing communications, either directly or indirectly, and via one or a combination of a wired, wireless, or other connection capable of exchanging information.

Once communication system104is discovered (e.g. its presence is discovered within a certain wireless range of device20), a communication link is established between communication system104and communication system204. This may be a direct wireless connection between wireless communications systems104,204, wherein the communication link does not travel over any wires outside of the patient monitoring device10and the remote interface device20. Alternatively, this may be an indirect wireless connection, for example via a wired network120, according to embodiments of the present invention. Alternatively, this may be a direct wired connection, either direct or via network120, according to embodiments of the present invention. Next a websocket connection is established between web browser202and web server102. The websocket connection may employ the WebSocket Protocol as defined by the Internet Engineering Task Force (IETF) and WebSocket API as described in publications of the W3C as part of the HTML5 initiative. The websocket connection may alternatively be based on, but not conforming to, such protocols and APIs. The websocket connection may be a reliable connection channel, even if such reliable connection channel is not a WebSocket connection. According to some embodiments of the present invention, the websocket connection is secure and/or encrypted, for example using standard TCP/IP encryption techniques such as basic authentication with secure socket layer (SSL) encryption. Once the websocket connection is established, the processor200receives patient data via the websocket connection (via web browser202), and displays at least a portion of the patient data on the screen22, according to embodiments of the present invention. According to some embodiments of the present invention, a websocket connection is a low latency bi-directional communication pipe, for example having a latency of 40-200 ms, which, once established, is not driven by requests like HTTP but is instead an established communications pipe.

FIG.6illustrates an example of the establishment of a websocket connection between server102and browser202, according to embodiments of the present invention. In server request62, the browser202sends a request to the server102to establish a websocket connection, and then the server102sends responses63-66back to the browser202. According to some embodiments of the present invention, each server response63-66includes 120 milliseconds (ms) of patient data from patient monitoring device10. For some patient data, this includes an average or other data processing result of sample data taken at a rate of one sample per 4 ms; for other patient data, this includes a new waveform (e.g. ECG waveform) or changes to the waveform (or other plot or graph) over the 120 ms period. As such, because each of the messages63-66includes a 120 ms block of data, the websocket messages63-66may be sent every 120 ms as shown, according to embodiments of the present invention. These websocket messages significantly reduce latency compared with a streaming data setup, because no additional server request, other than the initializing websocket server request62, is necessary in order to prompt the sending of messages63-66to the browser202. According to some embodiments of the present invention, each message63-66includes 40 to 200 ms of patient data, and each message63-66is sent 40-200 ms apart.

The websocket connection ofFIG.6may be compared with the illustration of a traditional http polling connection ofFIG.8.FIG.8illustrates an example of the establishment of a streaming or polling connection between server102and browser202, according to embodiments of the present invention. In server request82, the browser202sends a request for content to the server102, including full header information, and then the server102sends a response83back to the browser202. The browser202then sends another request for content84to the server102, and then the server102sends the next response85back to the browser202. This continues back-and-forth, thus increasing the overall latency of the connection compared with a websocket connection. In the connection ofFIG.8, a separate request is made for each period of patient data, and each separate request is responded to with the particular requested information. By contrast, with the websocket connection ofFIG.6, once the communication pipe is established, the server102continues to send each period of the patient data even without it being further requested, according to embodiments of the present invention.

The websocket messages63-66may be sent in the form of packets, for example having a header and a payload (e.g. patient data). The packet may be formatted according to the JavaScript Object Notation (JSON) protocol or other suitable format. Using a protocol such as JSON provides a data format that is relatively easy to parse and interpret, in a non-proprietary sense, which permits designers of screen aggregation devices or other web browser-enabled devices to more easily design an interface with devices10, according to embodiments of the present invention. As such, in some embodiments the communications connection between devices10and20may be secure and authenticated, for example using SSL, but the patient data itself may be human-readable and sent via websockets in the JSON or similar protocol. JSON is a text-based format that is language-independent and human-readable. Some elements of the data structure may include values (e.g. a heart rate value), while other elements may include arrays (e.g. data sufficient to reconstruct a patient's ECG waveform over the sample period). JSON also compresses well, and most off-the-shelf web browsers have the ability to handle JSON compression. Objects may be named with strings which help other users identify the data type for such object for use in subsequent parsing, according to embodiments of the present invention. Use of such protocol may also reduce an overall amount of code, by permitting recipients of the patient data to easily parse it rather than interpreting, converting, and/or translating it. The data sent via the websocket connection may be compressed using customary supported compression standards, according to embodiments of the present invention. Other nonproprietary or proprietary data formats or standards may be used for the data transmitted by the websocket connection, according to embodiments of the present invention.

FIGS.3and4illustrate example screen displays22, showing that screen positions for user interface displays may be changed or customized by the user. For example,FIG.3shows a simultaneous display of three screens from three different devices10,10′,10″. The user interface displayed in screen position32may be moved to a new screen position33, for example by selecting the user interface in position32and dragging it to screen position33in the direction of arrow37, according to embodiments of the present invention. Similarly, the user interface displayed in screen position34may be moved to a new screen position35, for example by selecting the user interface in position32and dragging it to screen position35in the direction of arrow38, according to embodiments of the present invention. This would result in the new screen22layout resembling that ofFIG.4. Screen positions31-36may alternatively be referred to as “slots.”

In addition to moving screen displays to different positions on the aggregated screen22, new websocket connections may be established between device20and other patient monitoring devices. For example, the device aggregation application running on device20may permit the user to select a menu or listing of patient monitoring devices10that have been discovered or that are available for connection, permitting the user to select one of the devices with which to establish a new websockets connection. According to some embodiments of the present invention, the application may also prompt the user to specify a screen location for the new user interface display on screen22. According to some embodiments of the present invention, the application permits reconfiguration “on the fly” of which display “slots” or screen positions31-36are in communication with which devices10.

According to embodiments of the present invention, the aggregation device20may itself be connected to one or more additional internal or external monitors or screens (not shown), and the user may reassign and/or rearrange the screen position corresponding to each device10to which device20is connected across any of the “slots” on any of the screens associated with device20, according to embodiments of the present invention. This ability is dynamic and does not affect the devices10,10′,10″ to which the device20is connected, or the connectivity as between the devices10,10′,10″ and the aggregation console device20, according to embodiments of the present invention. In a similar manner, a screen replication, or other data from, the same device10may be placed in more than one “slot” simultaneously anywhere among the various “slots” of the device20and its associated monitors or screens. The same device10interface may also be displayed simultaneously by two or more different aggregation devices20, according to embodiments of the present invention. This ability is dynamic and does not affect the devices10,10′,10″ involved, according to embodiments of the present invention.

According to some embodiments of the present invention, the arrangement and number of slots31-36on each device20and across multiple screens22of device20is configurable. A default configuration including a particular number of slots may be requested during a request for a particular frame from any one of the devices10,10′,10″, according to embodiments of the present invention.

FIG.4also illustrates an additional visual arrangement which may be used with screen22on device20, according to embodiments of the present invention. Screen positions31,33,35each replicate a display11,11′,11″ of one of devices10,10′,10″ simultaneously with those displays, while screen positions32,34,36may be used to display information that is in addition to the information currently displayed by the device10,10′,10″ itself, and may even include information which the respective patient monitoring device is incapable of displaying. For example, screen position31may be configured to simultaneously replicate a user interface11of device10, while screen position32may be configured to display a different format for the same data as displayed in screen position31, or data or a portion thereof that is received via the websocket connection with device10and that is in addition to or different from the data shown in screen position31. According to some embodiments of the present invention, screen positions31and32each display different portions of the patient data received via the same websocket connection; according to other embodiments of the present invention, screen positions31and32each display patient data or portions of patient data received via independent websocket connections with the same device10.

The screen aggregation device20may be a portable computing device, for example a computing tablet or mobile device, according to embodiments of the present invention. According to some embodiments of the present invention, device10may also be configured to generate a portable document format (PDF) report and send it to a subscribing device (e.g. device20) via a websocket link. The web server102may also support regular HTTP requests for data, for example a historical database of patient data stored in database106, according to embodiments of the present invention. Because device10includes a web server102, the device20may be any computing device, for example an off-the-shelf computer with no special software pre-installed. In this scenario, the application which device20runs in order to connect with device10may be transmitted from the web server102to the browser202and executed in order to install or open the application on the second device20. In other words, the web server102also permits any special software used to receive the data from device10to be sent directly to any other device20with a web browser202and processor200, according to embodiments of the present invention.

For example, the device20can request both the console frame software (e.g. the software that makes the browser display the one or more slots or screen positions31-36on screen22) and the device content (e.g. device screen content) from any of devices10,10′,10″ because each of those devices may include servers102that are able to provide not only the content but the software for viewing the content. A user of console20can make a request (to device10) for the console frame (e.g. the screen replication of device screen11) and preselect in the request the number of available slots per monitor or screen for the console20. Once the frame software is loaded at the console20, the frame software does not need to be loaded again unless the console's20browser202stops, according to embodiments of the present invention.

At the screen aggregation console20, the user may configure the number of slots per monitor or screen, and the arrangement of the slots on each monitor or screen of console20. This information about the configuration, arrangement, and/or number of slots per monitor or screen can be stored and updated in a configuration file. The configuration file may be stored, for example, on the console device20, which may in some cases be a PC. Configuration files are compatible with frame software originating from any device, according to embodiments of the present invention. The configuration file may be in a JSON file format, though other file formats or implementations will suitably store the information, according to embodiments of the present invention. Such configuration files may be accessed from cloud storage, and/or carried with or associated with each user, such that the configuration file for a user is useable with frame software originating from any device10,10′,10″, according to embodiments of the present invention.

According to some embodiments of the present invention, for devices10which are temporarily or permanently fixed in location (e.g. in a temporary hospital ward), the screen22may include a map of the geographic or physical location, with the screen positions31overlaid at a position corresponding to the location of the corresponding device on the map, to permit a person who is viewing aggregated information from one or more devices in the particular ward or location to see where in such ward or location the device is located. According to some embodiments of the present invention, instead of screen positions31overlaid on the map, the map includes characters or icons showing a location of a device10with an availability for a websocket connection, and a user's selection of such icon or character establishes the websocket connection and/or changes all or a portion of the screen22to display the patient data from such websocket connection. According to embodiments of the present invention, the device20permits the data shown on screen22, or portions thereof, to be selected and/or enlarged and/or minimized.

WhileFIG.2shows a single patient monitoring device10communicably coupled with a single remote interface system20, one of ordinary skill in the art will appreciate that remote interface system20may be communicably coupled, for example via websocket connections, with multiple patient monitoring devices10. For example, device20may even be coupled with more patient monitoring devices10than device20is capable of visually representing at any one time on screen22. In such cases, the screen22may permit vertical and/or horizontal scrolling in order to view additional screen positions and additional user interface displays. According to some embodiments, a user may select a particular screen position, for example screen position31, which causes the user interface screen11displayed at that screen position to become enlarged and/or to enlarge to the full size of screen22.

Additionally, multiple remote interface devices20may establish websocket connections with the same patient monitoring device10. As such, multiple screen aggregators20may be used, each with its own or a subset of devices10,10′,10″ displayed, permitting the user of devices20to decide which screens to aggregate on that particular device at a particular time. Such websocket connections would be established as described herein, according to embodiments of the present invention.

While device10is described as a patient monitoring device, device10may alternatively be a different type of device, for example a different type of medical device10, which has a visual display. For example, the device10may be a navigation device located in an ambulance, and the screen aggregator20may be used to simultaneously display the user interface (and/or associated data) from the navigation device alongside the user interface (and/or associated data) from the patient monitoring device10for the patient5in the same ambulance, according to embodiments of the present invention. Such non-patient monitoring devices may establish websocket connections similarly to those described above for the connections between devices10and devices20, according to embodiments of the present invention.

According to some embodiments of the present invention, for example for web browsers202which do not fully support HTML5 functionality, the patient data information may be packaged into a browser cookie, such that it is transmitted to the browser via a browser session, rather than with a basic authentication header. While this workaround achieves increased performance over existing streaming and permits the systems described herein to work with a wider range of browsers, it may exhibit a latency that is larger than that of websockets.

FIG.5is an example of a computer or computing device system500with which embodiments of the present invention may be utilized. For example, devices10or20may be or incorporate a computer system500, according to embodiments of the present invention. According to the present example, the computer system includes a bus501, at least one processor502, at least one communication port503, a main memory504, a removable storage media505, a read only memory506, and a mass storage507.

Processor(s)502can be any known processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), or AMD® Opteron® or Athlon MP® processor(s), or Motorola® lines of processors, or any known microprocessor or processor for a mobile device, such as, but not limited to, ARM, Intel Pentium Mobile, Intel Core i5 Mobile, AMD A6 Series, AMD Phenom II Quad Core Mobile, or like devices. Communication port(s)503can be any of an RS-232 port for use with a modem based dialup connection, a copper or fiber 10/100/1000 Ethernet port, or a Bluetooth® or WiFi interface, for example. Communication port(s)503may be chosen depending on a network such a Local Area Network (LAN), Wide Area Network (WAN), Virtual Private Network (VPN) or any network to which the computer system500connects. Main memory504can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known to one of ordinary skill in the art. Read only memory506can be any static storage device(s) such as Programmable Read Only Memory (PROM) chips for storing static information such as instructions for processor502, for example.

Mass storage507can be used to store information and instructions. For example, flash memory or other storage media may be used, including removable or dedicated memory in a mobile or portable device, according to embodiments of the present invention. As another example, hard disks such as the Adaptec® family of SCSI drives, an optical disc, an array of disks such as RAID (e.g. the Adaptec family of RAID drives), or any other mass storage devices may be used. Bus501communicably couples processor(s)502with the other memory, storage and communication blocks. Bus501can be a PCI/PCI-X or SCSI based system bus depending on the storage devices used, for example. Removable storage media505can be any kind of external hard-drives, floppy drives, flash drives, zip drives, compact disc-read only memory (CD-ROM), compact disc-re-writable (CD-RW), or digital video disk-read only memory (DVD-ROM), for example. The components described above are meant to exemplify some types of possibilities. In no way should the aforementioned examples limit the scope of the invention, as they are only exemplary embodiments of computer system500and related components.

FIG.7illustrates an alternative screen aggregation display, according to embodiments of the present invention. The display on the screen ofFIG.7includes one or more tabs72which permit a user to select a “layer” of screens to view at any one time. Each tab72may correspond to a screen having its own set of screen positions31-36, and not all the devices10to which device20is communicably connected need be displayed simultaneously on the same screen. Also, while device is illustrated inFIGS.1,3,4, and7as resembling an interface of a tablet computing device, one of ordinary skill in the art will understand, based on the present disclosure, that other kinds of devices20may be employed in a similar fashion, for example desktops, servers, personal computers, “smart” televisions, personal mobile devices, music players, and other devices.

According to some embodiments of the present invention, the aggregation device20, and/or the software application running on the aggregation device20to aggregate and display data from various monitoring devices10,10′,10″, is configured to emit an audible alarm and/or a visual alarm when any device10,10′,10″ monitored by the aggregation device20issues an alarm. The device20or its software may employ a global alarm suspend feature, which permits the alarm caused by any of the devices10,10′,10″ on device20to be suspended for a configurable number of minutes (for example, by permitting the user to select a button or a software button to suspend the alarm). When the configurable number of minutes has passed, and at least one device10,10′,10″ alarm is still active, the console20alarm is reactivated, according to embodiments of the present invention. According to other embodiments of the present invention, the global alarm (i.e. the visual and/or audible alarm on the console device20) is initiated or resumed if an alarm from a new or additional monitored device10is initiated while the global alarm suspend period is still active. In other words, the alarm suspend is interrupted and the sound is reactivated by a new alarm being initiated, either from the same device10or a new device10′,10″ from the plurality of devices configured to interact with the aggregation console20, according to embodiments of the present invention.

Various modifications and additions can be made to the exemplary embodiments discussed without departing from the scope of the present invention. For example, while the embodiments described above refer to particular features, the scope of this invention also includes embodiments having different combinations of features and embodiments that do not include all of the described features. Accordingly, the scope of the present invention is intended to embrace all such alternatives, modifications, and variations as fall within the scope of the claims, together with all equivalents thereof.