Platform-independent real-time medical data display system

Abstract

A system for providing real-time medical data to a client device regardless of the type of platform of the client device. The system uses different types of connections to establish a connection between the client device and the system, and transmits real-time medical data between the client device and the system. For example, a hypertext transfer protocol (HTTP) connection can be used to establish a connection between the client device and the system, and a websocket connection can be used to transmit real-time medical data between the client device and the system. By using an HTTP connection, the system can initially establish a connection between the system and any client device compatible with an HTTP connection.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 782,455, filed December 20, 2018, the contents of which are incorporated herein by reference in their entirety. Background Art

[0003] The patient treatment experience in hospitals and other health care institutions can change in many ways, including the initial interaction between the patient and the caregiver, diagnosis, treatment progress, the patient's physical movement in the institution, hospital stay, recovery and rehabilitation.For example, in some cases, the patient initiates the interaction with the hospital by arriving at the emergency room so that the hospital staff solves the urgent demand (such as injury, heart failure, sudden pain or other sudden emergency medical events).From the emergency room, the patient may be operated on urgently, arranged to be operated on later, given one or more medicines, arranged for later diagnosis consultation, treatment and leave (release), transferred to the intensive care unit, transferred to the recovery ward, or any other multiple measures may be taken for the patient.As another example, in some cases, the patient initiates the interaction with the hospital by scheduled surgical treatment.In such a case, the patient may, for example, arrive at the hospital, prepare for surgery, experience the surgical procedure, spend a period of time in the recovery ward and then be transferred to the general hospital ward, leave from the hospital afterwards and go home.

[0004] In many cases, one or more surgical procedures form part of the patient's treatment plan. After the surgical procedure, the patient can be transferred through a variety of environments. Immediately after the surgical procedure, the patient gradually recovers to a stable condition, and then they are discharged home or receive long-term care. For patients who need 24 / 7 clinician care, the initial recovery process begins in the intensive care unit (ICU). ICU has the equipment required for monitoring the patient's status and a high staffing ratio to help the patient recover. This environment may be very expensive for patients, because this is usually the highest daily cost among any room in the hospital, and leaving this environment as soon as possible is beneficial, because this can minimize the total cost. For hospitals built around intensive care, ICU patient throughput is a highly concerned measure for its overall operational efficiency-relative to staff and resources, ICU is the most expensive environment of the hospital, and keeping the patient there longer than the required time means that another patient must wait for the bed to become available before receiving treatment. Therefore, for both hospitals and patients, it is preferred to transfer patients out of the ICU, but the risks associated with premature discharge often prevent patients from leaving early.

[0005] While the patient is in the ICU, basic vital sign data needed to determine patient stability is measured, recorded, tracked, and trended, a process that typically relies on clinical staff and may limit clinicians to specific physical locations where they can monitor the patient in person (e.g., by viewing a bedside ECG monitor with sensors connected to the patient) and view vital signs and other data. The patient vital signs collected may include: blood pressure, temperature, respiratory rate, blood oxygenation, heart rhythm (via ECG), and heart rate. In addition to this, soft metrics such as patient responsiveness and visual assessment are also used.

[0006] In some cases, the recovery process may include moving the patient to a recovery room directly after surgery or after a period of time in the ICU. As with the ICU, patient monitoring within the recovery room environment also includes heavy reliance on clinician interpretation of any data generated, and this data may or may not be readily available to the original physician overseeing the patient's recovery.

[0007] Patients may often be transferred from the ICU or recovery room to a general ward. General wards typically include a lower staffing ratio of caregivers to patients and less or no vital signs monitoring. In many cases, vital signs are not usually monitored nearly continuously, but nurses will make rounds to measure key vital signs. In addition, such vital sign measurements may often be limited to some basic parameters, such as temperature and blood pressure. After the general ward, the next stage in the patient's recovery progress is often the patient's discharge. It is generally believed that it is best for patients to return home as soon as possible and recover in this more comfortable environment. Leaving the hospital to continue recovery at home can minimize the risk of nosocomial complications unrelated to infection and can better enable family members to help patients recover at a lower cost.

[0008] During the management of patients in multiple in-hospital and out-of-hospital environments, various stakeholders (human and non-human) are interested in consuming real-time medical data associated with the patient's status and the care received. This real-time medical data usually resides in different human and non-human resources and is communicated to stakeholders in various ways. In addition, with many stakeholders constantly changing, it is difficult to coordinate care in a patient-centric manner. Technical Field

[0009] The present invention relates to a system for providing real-time medical data. Summary of the invention

[0010] The present specification describes methods, systems, and computer-readable media for providing real-time medical data obtained from a monitoring device to a client device. In particular, the system can provide real-time medical data to a client device regardless of the type of platform of the client device. The system uses different types of connections to establish a connection between a client device and the system, and to transmit real-time medical data between the client device and the system. For example, a hypertext transfer protocol (HTTP) connection can be used to establish a connection between a client device and the system, and a websocket connection can be used to transmit real-time medical data between the client device and the system. By using an HTTP connection, the system can initially establish a connection between the system and any client device compatible with an HTTP connection.

[0011] Generally, one innovative aspect of the subject matter described in this specification can be implemented in a method performed, for example, by a computing system having one or more computers executing computer instructions stored on one or more non-transitory computer storage devices. The method may include: receiving, by a service agent, a first request for a web page from a client device via a hypertext transfer protocol (HTTP) connection, the first request including patient information of a specific patient; in response to the first request, determining, by the service agent, a specific web page based on the patient information of the specific patient, the specific web page displaying a first user interface; providing, by the service agent, the specific web page to the client device via the HTTP connection for establishing a websocket connection between the service agent and the client device; establishing a websocket connection between the service agent and the client device; receiving, by the service agent, a second request for first real-time medical data from the client device via the websocket connection, the second request identifying a medical data protocol defining one or more data attributes of the first real-time medical data; obtaining, by the service agent, a first real-time medical data sample set from one or more data sources, the first real-time medical data sample set including corresponding values ​​of one or more attributes of the first real-time medical data; generating the first real-time medical data based on the values ​​of the one or more data attributes of the first real-time medical data; and providing, by the service agent, a second user interface to the client device via the websocket connection to present the first real-time medical data.

[0012] The method may optionally include one or more of the following features. In response to loading a specific web page on a client device, the specific web page may be configured to trigger (invoke) the client device to establish a websocket connection between the client device and the service agent. Establishing a websocket connection between the service agent and the client device may include: receiving, by the service agent, a websocket connection request from the client device that is triggered in response to loading a specific web page on the client device; and in response to the websocket connection request, providing, by the service agent, a websocket connection response to the client device for establishing a websocket connection between the service agent and the client device. The method may also include the service agent asynchronously pushing medical data to the client device via the websocket connection.

[0013] Generating the first real-time medical data based on the values ​​of one or more data attributes of the first real-time medical data may include: identifying, by a service agent, corresponding values ​​of an identifier, a sampling rate, a plotting time, and buffer information from a second request, the second request including corresponding values ​​of one or more data attributes of the first real-time medical data; determining, based on the value of the identifier, a specific waveform among one or more waveforms monitored in real time by a monitoring device; writing, by the service agent, a specific waveform into a buffer using the sampling rate at the plotting time based on the corresponding values ​​of the plotting time, the sampling rate, and the buffer information; and generating, by the service agent, the first real-time medical data based on the specific waveform written into the buffer.

[0014] The method may further include storing the generated first real-time medical data in a database. Providing the first real-time medical data may include: reading the first real-time medical data stored in the database by the service agent, and providing the first real-time medical data to the client device by the service agent through a websocket connection. The client device may be a subscriber of the service agent for medical data. A websocket connection may be established between the service agent and the client device using communication based on Hypertext Markup Language (HTML).

[0015] The specific web page can simultaneously display (i) a first user interface provided from the service agent to the client device via an HTTP connection and (ii) a second user interface presenting first real-time medical data provided from the service agent to the client device via a websocket connection. The method can also include: receiving, by the service agent, a third request for second real-time medical data from the client device via a websocket connection, the third request including corresponding values ​​of one or more data attributes of the second real-time medical data; receiving, by the service agent, a second real-time medical data sample set from one or more data sources; generating second real-time medical data from the second real-time medical data sample set based on the values ​​of one or more data attributes of the second real-time medical data; and updating, by the service agent, the second user interface to present the second real-time medical data instead of the first real-time medical data, while maintaining the first user interface.

[0016] The subject matter described in this specification can be implemented in a specific implementation, and one or more of the following advantages can be generated. Conventional systems use the same type of connection to establish a connection between a client device and a conventional system and to transmit real-time medical data between the client device and the conventional system. In contrast, the system described in this specification uses different types of connections to establish a connection between a client device and the system and to transmit real-time medical data between the client device and the system. In particular, by using a common type of connection such as an HTTP connection to establish a connection between a client device and the system, the system can establish a data connection to any client device compatible with the connection type regardless of the platform of the client device. Therefore, the system improves the compatibility and flexibility of managing real-time medical data by enabling caregivers and other interested parties to view real-time medical data collected from patients using a standard interface (e.g., a web browser) on a remote computing device. The system provides data integrity without the need for a specialized application.

[0017] In addition, the system does not require an additional agent to establish a connection between the client device and the system. This reduces the number of network devices in the entire network, so that the same data can be transmitted between the system and the client device using fewer network resources. Therefore, network resources can be used efficiently.

[0018] In addition, each time real-time medical data is transmitted, conventional systems require a new connection to be made between the client device and the conventional system. Therefore, even if a connection has been established before, a new connection should be established to transmit new real-time medical data. In contrast, once the system described herein establishes a connection between the system and the client device for transmitting real-time medical data, no subsequent connection process is required to transmit the real-time medical data. Therefore, compared with conventional systems, the system uses less network resources.

[0019] The subject matter described in this specification can be implemented to achieve one or more of the following advantages. Compared with conventional systems, the disclosed technology is more efficient. The disclosed system determines whether the current deployment manifest deployed in the deployment system is outdated, and provides a notification to the client device indicating whether the current deployment manifest is outdated. In response to the notification, it can be determined whether the current deployment manifest should be upgraded or when to upgrade the current deployment manifest. As a result, the system can avoid downtime by upgrading service implementations when the system is not performing other tasks or the system is not busy. Therefore, the system can efficiently perform upgrades to service implementations.

[0020] The details of one or more implementations of the subject matter described in this specification are set forth in the accompanying drawings and the description below. Other features, aspects, and advantages of the subject matter will become apparent from the description, drawings, and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 is a diagram illustrating an example system for tracking and monitoring information associated with a patient.

[0022] Figure 2 is a diagram illustrating an example system that monitors waveforms obtained from a patient and provides real-time medical data to a client device.

[0023] Figure 3 is a sequence diagram illustrating example operations for providing real-time medical data to a client device.

[0024] Figure 4 is a flow diagram illustrating example operations for providing real-time medical data to a client device.

[0025] Figure 5 is a flow diagram illustrating example operations for generating real-time medical data.

[0026] Figure 6 is a diagram illustrating a network for facilitating a publisher / subscriber system for real-time healthcare information.

[0027] 7A to 7D is a diagram illustrating an example interface displayed on a client device for providing real-time medical data.

[0028] Like reference numbers and designations in the various drawings indicate like elements. DETAILED DESCRIPTION

[0029] Figure 11 is a diagram illustrating an example system 100 for tracking and monitoring information associated with a patient. System 100 can be used to monitor patient vital signs, track patient activity, track patient movement, record information associated with a patient, coordinate patient care, and provide up-to-date information to health care providers. System 100 includes: one or more monitoring devices, such as monitoring devices 102, 106, 107, and 108; a service agent, such as service agent 113; and a client device, such as client device 114.

[0030] The monitoring device detects and records the patient's medical data. For example, the monitoring device can detect and record various vital signs and other information of the patient. In some implementations, the monitoring device includes a sensor worn by the patient. For example, the sensor worn by the patient may include a chest sensor 102 attached to the chest of the patient 104 for tracking various vital signs of the patient 104. In addition, the sensor worn by the patient may include a wrist sensor 106, which is attached to the right wrist of the patient 104 in the example shown, but in fact the wrist sensor 106 can be attached to any wrist of the patient 104. The sensor worn by the patient can interact with other components of the system 100 to identify the alarm state of the patient 104. The alarm state may include various medical states or medical emergencies of the patient, which may or may not require one or more caregivers to intervene. In some implementations, the alarm state can be identified based on the deviation of one or more vital signs or other metrics of the patient 104 beyond an acceptable range. Detection of an alarm state or other problem associated with a component of the patient 104 or the system 100 that requires attention may cause one or more components of the system to issue a warning. The alert may take the form of information regarding the alarm status or other problem displayed by the computing device, a notification sent to one or more caregivers, an audio alarm, a visual alarm, a tactile alarm (eg, a vibration), or another indication.

[0031] The chest sensor 102 may include several adhesive electrodes for contacting the skin of the patient 104 to record various vital signs of the patient, including heart rhythm (via ECG) and heart rate. The chest sensor 102 may be, for example, a 6-lead ECG sensor with I, II, III, aVL, aVR, and aVF leads. Other vital signs that may be monitored by the chest sensor 102 or a combination of the chest sensor 102 and the wrist sensor 106 may include blood pressure, body temperature, respiratory rate, blood oxygenation, blood sugar level, hydration level, and perspiration. In some implementations, the chest sensor 102 may include a reusable or permanent part and a disposable part. For example, the chest sensor 102 may include a permanent housing for accommodating electrical components, which are used to process signals received from the patient and signals detected in association with the patient and transmit information to other devices. The chest sensor 102 may also include a disposable adhesive electrode pad designed to be attached to the chest of the patient 104. The electrodes included as part of the disposable adhesive electrode pads can be configured to contact the electrical leads of the permanent housing to transmit signals from the patient 104 to the electrical components within the chest sensor 102. In some implementations, the permanent housing can include snap connectors for engaging the electrodes of the disposable adhesive electrode pads and securing the disposable adhesive electrode pads to the permanent housing. The disposable adhesive electrode pads can be periodically removed and replaced with new disposable adhesive electrode pads, while allowing many of the components of the chest sensor 102 to be continuously reused.

[0032] The chest sensor 102 may also include sensors for detecting bioimpedance to monitor hydration levels, body fat levels, or other fluid levels of the patient 104. In some implementations, the chest sensor 102 may include electronics for processing and analyzing vital sign information and other information collected from the patient 104. In some implementations, the chest sensor 102 and / or other patient-worn sensors collect raw, pre-processed information and then transmit the information to other portions of the system 100 for further processing and analysis.

[0033] In some implementations, the chest sensor 102 includes a temperature sensor extending from the body of the chest sensor 102 to under the armpit of the patient 104 to monitor, track, and record the body temperature of the patient 104. The temperature sensor may include both a reusable portion and a temporary / disposable portion. For example, the temperature sensor may include a disposable contact for attaching to the skin of the patient 104 under the armpit of the patient 104. The temperature sensor may also include, for example, a permanent portion that includes a temperature sensing portion, a circuit system for interpreting and processing temperature data received from the patient, and a cable extending from the body of the chest sensor 102 around the chest of the patient 104 to the armpit of the patient 104. In some implementations, in addition to including functionality for interpreting temperature data collected from the patient 104, the temperature sensor may also collect raw data processed by a circuit system contained within the main housing of the chest sensor 102 or other parts of the system 100.

[0034] In some implementations, the chest sensor 102 includes one or more accelerometers for detecting and recording patient movement, activity, position, and posture. For example, an accelerometer included in the chest sensor 102 can track patient activity to enable a caregiver to determine whether the patient 104 is receiving a sufficient level of daily exercise or whether the patient 104 is engaging in too much activity for the current physical condition of the patient 104. The accelerometer can also be used to determine whether the patient 104 has fallen or whether the patient 104 has been stationary for a specified period of time. For example, the accelerometer can determine that the patient has been in a specific posture for a specified period of time, which can enable the system 100 to identify the patient's alarm state and issue one or more warnings to cause a caregiver to respond to the patient's alarm state. The accelerometer can also be used to track the patient's sleep pattern or to track the patient's 104 posture so that the caregiver can provide suggestions on how the patient 104 can better position himself when sitting, lying, standing, etc. In addition, the accelerometer can provide the caregiver with information that can be used to determine whether the patient 104 is engaging in activities or habits that may increase the risk of re-injury or development of complications.

[0035] The chest sensor 102 may also include circuitry and components for identifying the physical location of the patient 104. For example, the chest sensor 102 may include a GPS unit or a location determination device based on radio signal triangulation. The GPS unit or other location determination circuitry included in the chest sensor 102 may be used to identify the patient's location, for example, when the patient is not at the location where he or she should be at a specified time. The GPS unit may be used to locate patients with dementia or other mental illnesses who are prone to wandering off and getting lost. As another example, if an accelerometer in the chest sensor 102 determines that the patient 104 has fallen, the chest sensor 102 may transmit a warning to one or more caregivers that includes the location of the patient 104 so that the caregiver can more easily determine where the patient 104 fell and quickly and effectively meet the needs of the patient 104.

[0036] Other components that may be included as part of the chest sensor 102 include a power source, a button or other input mechanism for receiving user input, one or more audible alarms or speakers, and a display light or display screen. The power source for the chest sensor 102 may take the form of a battery pack for accommodating standard disposable batteries, rechargeable batteries, or a removable battery pack that can be replaced with a fully charged battery pack. The chest sensor 102 may also include an input mechanism, such as a button, a key, or a touch screen. The input mechanism may allow the patient 104 or a caregiver to adjust settings for the chest sensor 102, perform various tests (e.g., sensor tests, battery power level tests, etc.), or reset one or more alarms of the chest sensor 102. For example, the patient 104 or a caregiver may silence the audible alarm of the chest sensor 102 or stop the flashing light alarm of the chest sensor 102 by pressing a button on the chest sensor 102.

[0037] The chest sensor 102 may also include one or more audible alarms or speakers. When a specific patient event occurs, a speaker or other noise emitting unit included as part of the chest sensor 102 may provide an audible alarm. In some implementations, different types of audible alarms may indicate different patient events. For example, a first alarm sound may indicate cardiac arrest, while a second alarm sound may indicate that the patient 104 has fallen, and a third alarm may indicate irregular breathing of the patient 104. In some implementations, a button or other input device of the chest sensor 102 may be used to pause or reset an audible alarm or a visual alarm. The chest sensor 102 may also include a display light, a display screen, or other display mechanism. For example, one or more LED lights may indicate the current state of one or more vital signs of the patient 104 or the current state of one or more components of the chest sensor 102. For example, one LED may indicate that the battery of the chest sensor 102 is low, while another LED may indicate that a communication unit (e.g., a wireless Bluetooth communication circuit system) has failed. As yet another example, a display screen included as part of the chest sensor 102 may provide an indication of one or more vital signs or other information collected by the chest sensor 102. For example, the display screen may show one or more ECG readings for the patient 104.

[0038] In some implementations, a button or other input device of the chest sensor can allow the patient 104 to initiate a patient call for help. For example, the patient 104 can select a button on the chest sensor 102 that causes the chest sensor 102 to transmit a distress signal to the bedside monitor 108 or other computing device using wireless communication and / or by communicating via the network 112. For example, when the patient 104 presses the button, the chest sensor 102 can transmit a distress signal to a computer located at a nurse's station. The nurse's station can then indicate to the caregiver that the patient 104 has initiated a distress call. In addition, information related to the distress call can be recorded and stored along with an indication of the time when the distress call was made and the patient's vital signs and other information at the time of the distress call.

[0039] In some implementations, one or more input devices of the chest sensor 102 can activate a microphone function of the chest sensor 102. For example, the patient 104 can select a button on the chest sensor 102 to activate a microphone included in the chest sensor 102. The microphone can allow the patient 104 to make an audio recording to, for example, indicate symptoms that the patient 104 is currently experiencing or has recently experienced. The audio recording is recorded along with a timestamp when the recording was made and stored in a computer memory of the chest sensor 102 and / or another computing device in communication with the chest sensor 102. The audio recording (e.g., which includes symptoms stated by the patient 104) can be used by one or more caregivers to diagnose the patient 104.

[0040] In some implementations, the microphone functionality of the chest sensor 102 can be used to facilitate one-way or two-way audio communication between the patient 102 and a caregiver located at a different location. For example, the patient 104 can select a button of the chest sensor 102 to activate the microphone of the chest sensor 102 and initiate a two-way audio communication session with a caregiver at a computing device that is at a different physical location from the patient 104 and the chest sensor 102. For example, the patient 104 can talk to a nurse at a nurse station located on the same floor of the hospital as the patient 104 to convey questions, symptoms, or other information to the nurse. The nurse can respond to the patient 104. For example, the chest sensor 102 can include a speaker to emit audio transmitted by the nurse station so that the nurse can provide instructions or comfort to the patient 104 or notify the patient 104 that help is being provided.

[0041] As mentioned above, the patient-worn sensors included as part of the system 100 may include a wrist sensor 106. The wrist sensor 106 may be used to track and record the blood pressure and blood oxygenation (SpO2) of the patient 104. As with the chest sensor 102, the wrist sensor 106 may include both a reusable portion and a disposable portion. For example, the wrist sensor 106 may include a reusable housing and circuitry for processing signals received from the patient 104 and a disposable portion for contacting the skin of the patient 104.

[0042] In some implementations, the patient-worn sensor includes a finger sensor 107 that extends from the wrist sensor 106 and engages with one or more fingers of the patient 104. The finger sensor 107 can be used, for example, to measure blood oxygenation (SpO2) of the patient 104. In some implementations, the wrist sensor 106 can take the form of an upper arm sensor located at the upper arm (above the elbow) of the patient 104, rather than at the wrist of the patient 104. The upper arm sensor can be used, for example, to measure the blood pressure of the patient 104.

[0043] In some implementations, the monitoring device may include a bedside monitor 108. The chest sensor 102 may communicate with the bedside monitor 108 to transmit information collected by the chest sensor 102 and / or other patient-worn sensors (e.g., patient vital signs, patient activity, and patient position) to the bedside monitor 108. For example, the chest sensor 102 may communicate wirelessly with the bedside monitor 108 using Bluetooth technology. As another example, the chest sensor 102 may communicate with the bedside monitor 108 using a WiFi protocol or a cellular protocol. As yet another example, the chest sensor 102 may communicate with the bedside monitor 108 using a wired connection. The communication connection between the chest sensor 102 and the bedside monitor 108 may also be used to forward information from the bedside monitor 108 to the chest sensor 102. For example, the bedside monitor 108 may be used to change settings for the chest sensor 102, such as acceptable ranges for heart rate, respiratory rate, blood oxygenation, or other vital signs monitored by the chest sensor 102 and / or other patient-worn sensors. As another example, the bedside monitor 108 may be used to change the frequency with which the chest sensor 102 and / or the wrist sensor 106 capture and transmit a particular vital sign of the patient 104. As yet another example, the bedside monitor 108 may be used to change the sensitivity level of one or more vital sign reading components of the chest sensor 102 and / or the wrist sensor 106.

[0044] In some implementations, the wrist sensor 106 also communicates (e.g., via a wireless Bluetooth connection, other wireless connection, or via a wired connection) with the bedside monitor 108. In some implementations, the wrist sensor 106 does not communicate directly with the bedside monitor 108, but rather transmits information to the chest sensor 102 (e.g., via a wireless or wired connection) and the chest sensor 102 then transmits the information collected by the wrist sensor 106 to the bedside monitor 108 and transmits the settings and other information indicated by the bedside monitor 108 to the wrist sensor 106.

[0045] In some implementations, various different vital signs are recorded at different sampling rates, and these vital signs are buffered and sent to the bedside monitor (and therefore to other computing devices that communicate directly or indirectly with the bedside monitor) at a uniform and consistent rate. For example, the raw data of the ECG waveform may be sampled at 200 samples per second, while blood oxygenation and bioimpedance are sampled at 33 samples per second. The various information sampled at different rates may be buffered together so that they can all be sent (bush) to the bedside monitor at a consistent rate (e.g., 9 times per second).

[0046] The bedside monitor 108 can allow a caregiver 110 (e.g., a nurse, doctor, caregiver, physical therapist, or other caregiver) to view the real-time vital signs of the patient 104, the past vital signs of the patient 104, other information provided by the chest sensor 102, the wrist sensor 106, and / or other patient-worn sensors, or other information associated with the patient 104. For example, the bedside monitor 108 can display the ECG waveform of the patient 104 while also listing the current blood oxygenation level, blood pressure, hydration level, heart rate, respiratory rate, and body temperature of the patient 104. The caregiver 110 can also use the bedside monitor 108 to take notes about patient care performed on the patient 104, annotate vital sign information or other patient information, send messages to other caregivers, or record patient activities. For example, the caregiver 110 can use the bedside monitor 108 to record that the patient 104 has experienced mild dyspnea or that the patient 104 is experiencing limb pain. As another example, the caregiver 110 may be a physical therapist and may use the bedside monitor 108 to record the patient's 104 therapy activities and take notes about the patient's 104 physical therapy progress. As yet another example, the caregiver 110 may use the bedside monitor 108 to adjust the range that is considered a "normal" or "safe" range for one or more vital signs of the patient 104. As yet another example, the caregiver 110 may be a hospital attendant and may use the bedside monitor 108 to record when the patient 104 eats and the amount of food that the patient 104 eats per meal. Although described herein as a bedside monitor, it should be understood that some or all of the display, communication, sensor control, and other functions of the bedside monitor 108 may be performed by one or more devices remote from the chest sensor 102. For example, the bedside monitor 108 may be a computer or tablet device that is remote from the patient 104 and the chest sensor 102 and communicates over one or more network connections using techniques described in more detail below to receive information from and / or send information to the chest sensor 102.

[0047] The bedside monitor 108 can also be used to view notes left by other caregivers about patient care for the patient 104, or to track the patient's vital signs and activities over a period of time to help diagnose or prevent complications. The bedside monitor 108 can also transmit information associated with the alarm state of the chest sensor 102. For example, if any of the various vital signs or other information (such as the patient's movement / position) exceeds the specified "safe" limit, the chest sensor 102, the wrist sensor 106, or the bedside monitor 108 can initiate an alarm state. The bedside monitor 108 can warn the caregiver 110 of the alarm state by using a visual alarm or an audio alarm. In some scenarios, different visual alarms or audio alarms can be used for different types of alarm states, or for different emergency levels associated with different alarm states. In some implementations, the alarm state can be graded based on the severity of the alarm state, wherein some alarms are identified as more important than other alarms (and / or require more immediate attention from or to the caregiver). For example, if the chest sensor 102 detects cardiac arrest, it can be classified as a high-level emergency event that requires immediate attention, while if the wrist sensor 106 detects a slight increase in blood pressure, it can be identified as a low-level alarm state that does not require treatment until the next time a caregiver checks on the patient 104. The display of the bedside monitor 108 can indicate the various alarm states and the relative importance or level of each alarm state to the caregiver 110. The caregiver 110 can then use the bedside monitor 108 to view additional information associated with each alarm state, including changes in vital signs or other patient-related information that prompted the alarm state to be activated.

[0048] In some implementations, the chest sensor 102, the wrist sensor 106, and / or other patient-worn sensors may include circuitry for processing vital sign information and other information recorded by the chest sensor 102, the wrist sensor 106, and / or other patient-worn sensors to identify when one or more alarm conditions occur. In some implementations, the patient-worn sensors transmit raw, pre-processed vital sign information and other information collected in association with the patient 104 to the bedside monitor 108, which analyzes the raw information to determine various vital signs and other information of the patient 104 and identifies whether any alarm conditions exist (e.g., by identifying whether any vital sign or other signal deviates from an acceptable range). In other implementations, other portions of the system 100 may be used to analyze vital signs and other information collected by the chest sensor 102 and the wrist sensor 106 to identify alarm conditions associated with the patient 104.

[0049] In some implementations, the alarm state of the patient 104 can be identified by comparing one or more vital signs collected for the patient 104 with a threshold value. For example, the heart rate of the patient 104 can be compared with a threshold heart rate value, and if the heart rate of the patient 104 drops below the threshold, one or more components of the system 100 can automatically determine that the patient is experiencing cardiac arrest. The system 100 can then send a warning indicating the cardiac arrest alarm state of the patient 104 to one or more caregivers. For example, the warning can be sent to one or more caregivers within a predetermined distance of the patient 104, the supervising nurse of the hospital ward where the patient 104 is located, and the general care physician responsible for the general care of the patient 104. The warning can also be sent to the cardiologist currently on duty at the healthcare facility where the patient 104 is located.

[0050] In some implementations, the collected vital signs can be compared with a threshold value, not only to determine the type of alarm state but also to identify the severity of the alarm state. For example, a patient experiencing a respiratory rate slightly higher than the preferred range for the patient can be identified as having a respiratory alarm state of level 2, while a patient experiencing a respiratory rate that significantly deviates from the preferred range can be identified as having a respiratory alarm state of level 1 (e.g., a higher emergency level). As indicated in the previous example, the alarm state can be divided into different levels. As another example, information collected by an accelerometer included in the chest sensor 102 can indicate that the patient 104 has fallen. If the distance and speed of the fall can be compared with a threshold value, the severity of the fall can be identified and the alarm level associated with the fall can be associated. For example, a slow fall from a height of two feet can have a severity level of level 2, while a fast fall from a height of five feet can be assigned a severity level of level 1.

[0051] In addition to communicating with chest sensor 102, wrist sensor 106, and / or other patient-worn sensors, bedside monitor 108 may also communicate with one or more service agents 113 via network 112. Service agent 113 may collect information provided by various monitoring devices including bedside monitor 108, other bedside monitors, various sensors, and other computing terminals.

[0052] The service agent 113 may include multiple servers co-located or multiple servers located in different geographic locations to provide so-called "cloud" storage for information stored by the system 100. Various monitoring devices or client devices may access the service agent 113 from many different locations via the network 112. For example, the service agent 113 may be accessed by the bedside monitor 108, other bedside monitors and computing devices located in the same hospital as the bedside monitor 108, and various bedside monitors and other computing devices (e.g., mobile phones, personal computers, tablet devices, etc.) located in other physical locations.

[0053] The system 100 also includes a client device 114. For example, the client device 114 can be a central server station, a mobile device, or a laptop computer. Information collected by the service agent 113 can be accessed at the client device 114. For example, a caregiver 116 or other hospital personnel can use the client device 114 to access information about the patient 104, other patients, or other hospital or healthcare management functions. The network 112 can be a hospital internal local area network (LAN) such as a WiFi network, a wide area network (WAN) such as the Internet, or any combination of a LAN network and a WAN network. The bedside monitor 108 can be connected to the network 112 using a wireless protocol such as WiFi or a cellular communication protocol or by a wired connection. In some implementations, the client device 114 can be located at an institution different from the patient 104 and the bedside monitor 108.

[0054] The client device 114 may allow a caregiver 116 to monitor the vital signs, activities, and other information of the patient 104 from a remote location. In addition, the client device 114 may allow a caregiver 116 to simultaneously observe information of multiple patients within a healthcare institution or system. In some implementations, all information collected by sensors worn by the patient (e.g., chest sensor 102 and wrist sensor 106) and all information entered using the bedside monitor 108 are stored by the service agent 113 and may be accessed through the client device 114. In some implementations, the caregiver 116 may receive an alarm or warning associated with the patient 104 at the client device 114, and take appropriate action to dispatch one or more caregivers to resolve the alarm situation. In some implementations, the system 100 may automatically identify the alarm state of the patient 104 and alert the appropriate caregiver to respond to the situation. For example, the bedside monitor 108 may analyze the information received from the chest sensor 102 to determine that the patient 104 is suffocating. The bedside monitor 108 may identify this as an emergency level warning, and transmit the information to the service agent 113. The service agent 113 may then identify one or more caregivers in proximity to the patient 104 and alert them that the patient 104 is choking.

[0055] The warning may be sent to one or more caregivers, for example, via a bedside monitor with which the caregiver is currently interacting, a computer terminal communicating with the service agent 113, a mobile device carried or worn by the caregiver, or alarms or displays located throughout the hospital or healthcare facility where the patient 104 is located. The service agent 113 may also transmit warning information about the patient 104 to the client device 114 to notify the caregiver 116 and the bedside monitor 108 (which is associated with the chest sensor 102 worn by the patient 104) to alert the caregiver 110 or possibly one or more other caregivers in the vicinity of the bedside monitor 108. This automatic identification of the alarm state of the patient 104 and routing of the alarm to caregivers in the vicinity of the patient 104 may reduce the time taken to respond to and resolve the emergency, thereby reducing adverse effects on the patient 104.

[0056] In some implementations, in addition to the information collected by various patient-worn sensors (e.g., chest sensor 102, wrist sensor 106, and / or other patient-worn sensors), the bedside monitor 108 may include functionality for collecting information related to the patient 104. For example, the bedside monitor 108 may include one or more cameras for monitoring the movement, posture, and other aspects of the patient 104. The camera may be built into the bedside monitor 108, attached to the bedside monitor 108 as a peripheral device, or may be a stand-alone device that communicates with the bedside monitor 108 by wire or wirelessly. The camera of the bedside monitor 108 may be positioned to face the patient 104 and monitor the movement of the patient 104 when the patient 104 is in bed. This information is used to identify the patient's alarm state. For example, the bedside monitor 108 (or another computing device of the system 100, such as the service agent 113) may analyze the video images captured by the camera to identify whether the patient 104 has fallen off the bed. As another example, the camera can be used to identify that the patient 104 is not in bed when the patient 104 is expected to be in bed. If the bedside monitor 108 detects that the patient 104 has been out of bed for longer than a threshold period of time, the bedside monitor 108 can identify this as an alarm state and alert the caregiver to the situation.

[0057] As yet another example, the camera of the bedside monitor 108 may determine that the patient 104 is awake. The stored information about the patient 104 may indicate that the patient 104 should currently be in drug-induced sleep. The bedside monitor 108 may identify the patient 104 being awake during a period when the patient 104 should be asleep as an alarm state. As yet another example, the camera may be used to identify that a comatose patient is awake and moving. The bedside monitor 108 may identify this as an alarm state and warn the caregiver to check on the now awake patient.

[0058] The bedside monitor 108 may also include one or more accelerometers for determining the orientation of the bedside monitor 108. This orientation information may also be used to determine the orientation of each image captured by the camera of the bedside monitor 108. For example, depending on the positioning mode of the bedside monitor 108 relative to the patient 104, the bedside monitor 108 may be positioned at various angles. For example, the bedside monitor 108 may be connected to a railing attached to the bed of the patient 104, attached to a wall, or placed on a table or bedside table. In addition, the bedside monitor 108 may not be completely flush on the surface supporting the bedside monitor 108. The orientation of the bedside monitor 108 may be different depending on the support mode of the bedside monitor 108. The accelerometer may be used to determine the orientation of the bedside monitor 108, and thereby determine the orientation of the image captured by the camera of the bedside monitor 108.

[0059] In some implementations, the chest sensor 102 also includes one or more accelerometers that can determine movement of the chest sensor 102 and an orientation of the chest sensor 102 .

[0060] Other information that may be collected by one or more sensors or devices built into or in communication with the bedside monitor 108 may include ambient temperature, ambient humidity, noise levels, light levels, carbon monoxide detection, or smoke detection. For example, the bedside monitor 108 may recognize that the ambient temperature near the patient 104 has dropped below an acceptable level and alert a caregiver or maintenance worker to the change in temperature. As another example, the bedside monitor 108 may detect that the ambient humidity has fallen below a threshold.

[0061] In some implementations, the caregivers associated with the patient 104 may be classified into different caregiver categories. For example, a first-level caregiver may be identified as a caregiver responsible for the immediate care or daily care of the patient 104, while a second-level caregiver may be identified as a caregiver responsible for more extensive oversight of the recovery or treatment of the patient 104. For example, the attending physician of the ward where the patient 104 is located may be identified as the first-level caregiver of the patient 104, while the speech therapist who is responsible for meeting with the patient weekly and working on language skills may be classified as the second-level (or in some cases, even the third-level) caregiver of the patient 104. As another example, the immediate family of the patient 104 who is responsible for the care of the patient 104 when the patient 104 is at home may be identified as the third-level caregiver of the patient 104. For different patients, the same caregiver may have different caregiver classification levels. For example, a physical therapist may be the first-level caregiver of a patient who meets with the physical therapist several times a day for a long time, while the physical therapist may be the second-level caregiver of a patient who only meets with the physical therapist once a week.

[0062] In some implementations, when a patient event (e.g., an alarm state or another patient event identified based on vital sign information) occurs for patient 104, different alarms may be sent to different caregivers. In some implementations, different alarms may be sent to caregivers based on their caregiver classification. For example, a detailed alarm including detailed information about a particular alarm state of patient 104 and instructions on how to respond to the alarm state may be transmitted to the attending physician on duty (first level caregiver) in the ward where patient 104 is located, while a less detailed alarm indicating only the alarm state and the time at which the alarm state occurred may be sent to the general care family physician of patient 104 (second level caregiver of patient 104). As another example, a component of system 100 may determine that patient 104 is choking based on vital sign information collected by chest sensor 102. System 100 may send an emergency alarm to a nurse located near patient 104, indicating that the patient is choking and instructing the nurse to clear the airway of patient 104. A different alert may be sent to identified emergency contacts of patient 104 (eg, parents, spouse, siblings, etc.): the alert indicating that the patient experienced a choking condition, and possibly also indicating that the choking condition has been addressed and patient 104 is no longer in danger.

[0063] In some implementations, an alarm may be generated in response to detecting that a patient is in an undesirable position or that the patient has been in a specific position for longer than a specified time period. For example, a patient may be in a recovery room after surgery. The patient may be transferred to a room in a general ward of a hospital within a certain time range (e.g., within 8 hours). One or more computing devices of the system 100 may recognize that the patient has been in the recovery room for longer than eight hours, and generate an alarm indicating that the patient is still in the recovery room to provide to one or more caregivers. As another example, one or more computing devices of the system 100 may determine that the patient should have been discharged from the hospital within a specific time window. If it is recognized that the patient is still in the hospital after the specified time window, the system 100 may generate an alarm indicating that the patient should have been discharged and provide the alarm to one or more caregivers. As another example, if it is recognized that the patient does not move in the stairwell for more than a specified time period (e.g., one minute), an alarm may be generated and provided to one or more caregivers.

[0064] In some implementations, alerts regarding conditions other than alarm states associated with a patient may also be sent to a caregiver or other user of the system 100. For example, an alert may be sent to the caregiver 110 indicating that the bedside monitor 108 has lost communication with the chest sensor 102. As another example, an alert may be sent to the caregiver 110 indicating that the battery of the chest sensor 102 is low. As yet another example, a warning may be transmitted to the caregiver 110 indicating that the chest sensor 102 is not properly collecting information necessary to determine one or more vital signs of the patient 104. In this example, the caregiver 110 may resolve the problem by adjusting the contacts of the chest sensor 102 so that they properly contact the skin of the patient 104, or by replacing the chest sensor 102 with a properly functioning chest sensor.

[0065] In some implementations of the system 100, the chest sensor 102, wrist sensor 106, and / or other patient-worn sensors can eliminate the need for a bedside monitor 108 by connecting directly to the network 112 (e.g., using WiFi or other wireless protocols) to transmit vital signs and other information to the service agent 113. The information transmitted over the network to the service agent 113 can then be accessed at the client device 114 and other terminals connected to the network 112. In some implementations, the bedside monitor 108 acts as a virtual terminal that receives information from the service agent 113 and displays a graphical user interface specified by the service agent 113, rather than receiving information directly from the chest sensor 102 and / or other patient-worn sensors.

[0066] In some implementations, information about the patient 104 (e.g., vital signs, alarm status, treatment information, biological information, etc.) can be accessed using other devices that communicate with the service agent 113 and / or the bedside monitor 108. For example, the patient information can be sent to a mobile device (e.g., a smart phone, tablet, or laptop) owned by the caregiver 110 or another caregiver associated with the patient 104. As another example, the caregiver 110 can access the service agent 113 (e.g., by using the bedside monitor 108 or another computing device) and indicate that the caregiver 110 wishes to receive updates about the patient 104. The caregiver 110 can then be associated with the patient 104 (e.g., by linking the caregiver profile of the caregiver 110 to the patient profile of the patient 104). When the service agent 113 receives important information about the patient 104 (e.g., an alarm status or a significant change in the treatment plan), the service agent 113 can automatically send the information to a device associated with the caregiver 110, such as the mobile phone of the caregiver 110.

[0067] In some implementations, a caregiver associated with the patient 104 can use a computing device to communicate with the service agent 113 and access the information of the patient 104. For example, if the caregiver has the appropriate authority to access the information of the patient 104, the caregiver can access the information of the patient 104. The caregiver can indicate the authority to access the information by entering an access code or by accessing the profile of the caregiver that has been previously associated with the patient profile of the patient 104. In some implementations, the information associated with the patient 104 can be accessed through multiple different bedside monitors or client devices. Such an information access mechanism can enable caregivers and other users of the system 100 to access the information of multiple patients. For example, a doctor can be responsible for monitoring the status of multiple patients. The doctor can use a PC to access the service agent 113 and view the vital signs information, alarm information, and other information of each of the multiple patients. The information of multiple patients can be set in a news feed, which enables the doctor to easily access and view the most relevant patient information, while also providing the doctor with the ability to access other information of each patient that is not identified as the most relevant by the system 100.

[0068] In addition, the caregiver 110 can use the bedside monitor 108 to access information associated with the patient 104 that has been input into the system 100 but is not provided by the chest sensor 102 or other patient-worn sensors. For example, the caregiver 110 can use the bedside monitor 108 to access information associated with the patient 104 that is related to treatment or surgery that occurred at a location other than the current location of the patient 104. In one example, the caregiver 110 can use the bedside monitor 108 to access and view information stored at the service agent 113 about interactions between the patient 104 and emergency room staff to assess the current status of the patient 104. As another example, the caregiver 110 can view notes left by the anesthesiologist at different bedside monitors of the patient 104 regarding specific vital signs or other manifestations of the patient 104 to observe during a specified post-operative procedure period of the patient 104.

[0069] In some implementations, the service agent 113 can interface with a computing system external to the system 100 to access other information about the patient 104. For example, the service agent 113 can access electronic medical records (EMR), electronic health records (EHR), or picture archiving and communication system (PACS) information of the patient 104, containing healthcare information about the patient related to past treatments, surgeries, care plans, diagnoses, or other healthcare-related information about the patient 104 that may or may not be associated with a healthcare organization associated with the system 100.

[0070] As discussed above, the various components of the system 100 can enable caregivers (including caregivers 110 and 116) to more effectively coordinate patient care and more seamlessly transition patients from one location to another, from one environment to another, or from one group of caregivers to another. For example, a caregiver can use the system 100 to take notes about patient care, which can be stored with patient vital signs and other information. For example, caregiver 110 can take notes about the eating habits of patient 104. As another example, caregiver 116 can use client device 114 to enter notes about patient 104, based, for example, on viewing and evaluating information received from bedside monitor 108 and other sources and stored in service agent 113. Then, when other caregivers (e.g., using client device 114, bedside monitor 108, another bedside monitor, mobile device, or another computing device in communication with network 112) access information about patient 104, these notes can be viewed by the other caregivers to enable the other caregivers to make adjustments to one or more aspects of the treatment plan for patient 104. In some implementations, the notes or messages can be processed as attentions to one or more other caregivers. For example, caregiver 110 can take a note that patient 104 had a particular reaction after taking a medication and set the note as an attention to the pharmacist responsible for the patient's care. The pharmacist can receive an alert that a new note has been processed as his attention (e.g., via the pharmacist's mobile phone), review the note, and review other information associated with patient 104 to best determine whether a change to the patient's 104 medication schedule is needed.

[0071] In some implementations, the service agent 113 may include information other than information directly related to patient care. For example, the service agent 113 may store information related to healthcare facility maintenance and inventory (e.g., about medical supplies, medical equipment, medications, or conventional items such as light bulbs and batteries). This information may be accessed by a computing device included in the system 100 that communicates with the network 112. The system may also include functionality for tracking maintenance and inventory, including: planning maintenance, tracking maintenance progress, ordering new inventory when supplies run out, tracking supplier, vendor, and service provider information, and tracking maintenance and inventory budgets. The service agent 113 may also store the patient's insurance information, the patient's payment information, or other patient information that is only slightly related to patient care. Additional functionality that may be provided by the service agent 113 or other components of the system 100 includes employee payroll and personnel scheduling.

[0072] In some implementations of the system 100, multiple patient-worn sensors are associated with multiple corresponding patients, and each of these patient-worn sensors is configured to synchronize with one or more bedside monitors or intermediate devices (e.g., using Bluetooth or another wireless communication protocol). In some implementations, the patient-worn sensors can communicate with bedside monitors or other devices using a wired connection. In some implementations, some or all of the patient-worn sensors are configured to communicate directly with the network 112 (e.g., using Wi-Fi or another wireless communication protocol). Information collected by multiple patient-worn sensors can be routed to the service agent 113 and stored via the network. The information can then be accessed by components of the system 100. For example, a caregiver 116 can access information collected by multiple patient-worn sensors at a client device 114 to monitor the status of patients associated with multiple patient-worn sensors.

[0073] In some implementations, multiple bedside monitors included in the system 100 can communicate directly with each other to create network redundancy. For example, the network 112 may be down for a period of time, or the bedside monitor 108 and other bedside monitors of the system 100 may not be able to communicate with the network 112 for a period of time. The bedside monitor 108 can communicate with the service agent 113 and other computing devices of the system 100, for example, via a LAN. The LAN may experience an outage and be unavailable for a period of time. The bedside monitors of the system 100 can detect the outage, and each bedside monitor can establish direct communication with one or more other bedside monitors (or other computing devices of the system 100) to form an ad hoc backup network for transferring patient information and other information between the bedside monitor and other computing devices of the system 100. For example, each bedside monitor can communicate with other bedside monitors within range using wireless communication functions (e.g., Bluetooth or WiFi communication functions).

[0074] In many use cases, bedside monitors will be placed at substantially regular intervals throughout a hospital or other healthcare environment. For example, one or two bedside monitors are typically placed in each patient room, and computing devices of the system 100 with wireless communication capabilities are placed at nurse stations and other areas throughout the hospital. The spatial distribution of the bedside monitors can enable the bedside monitors to relay information through a series of bedside monitors (and other computing devices), thereby enabling the information to be transmitted between devices that are physically farther apart from each other than the distance that can typically be spanned through standard short-range wireless communication protocols.

[0075] In use, one or more patient-worn sensors (e.g., chest sensor 102 and wrist sensor 106) may be associated with patient 104 when patient 104 enters a healthcare facility or shortly after patient 104 enters a healthcare facility. In some implementations, if patient 104 enters a healthcare facility during an emergency (e.g., cardiac arrest, serious car accident, etc.), the patient-worn sensors may be distributed to patient 104 after the emergency has been handled and patient 104 has been stabilized. In some implementations, patient 104 may be associated with a unique patient identifier (“ID”). The patient ID may be as simple as the name of patient 104, a unique number assigned to patient 104, a unique combination of numbers, letters, and other characters, or any other unique identifier associated with patient 104. If patient 104 has previously interacted with a healthcare facility, system 100, or related systems, caregiver 110 may look up the unique identifier of patient 104 by, for example, entering the name of patient 104 at bedside monitor 108. Caregiver 110 may then access patient information for patient 104. The patient information may include biometric information such as name, age, weight, height, address, contact information, family members, emergency contacts, etc., as well as healthcare information about past (or present or future) healthcare events, treatments, surgeries, care plans, etc. of the patient 104. In some implementations, the caregiver 110 may access a patient profile of the patient 104 (e.g., using the patient ID of the patient 104). The patient profile may include any of the information listed above about the patient 104. The patient profile may also indicate caregivers associated with the patient 104, such as the physician who performed surgery on the patient 104, the physician who is scheduled to perform surgery on the patient 104 in the future, one or more caregivers responsible for the primary care of the patient 104, the emergency room physicians and participants who handled the initial emergency care of the patient 104, and other caregivers associated with the patient 104.

[0076] If the patient 104 has not previously interacted with the system 100 or related systems, a new unique ID may be assigned to the patient 104 by one or more components of the system 100 (e.g., by the bedside monitor 108 or the service agent 113). The patient's 104 biometric information, medical information, and other information may then be entered (e.g., using the bedside monitor 108 or the client device 114) and stored at the service agent 113.

[0077] When the patient-worn monitors (e.g., chest sensor 102 and wrist sensor 106) are initially provided to patient 104, the patient-worn sensors may be associated with patient 104 by associating the patient-worn sensors with a unique ID of patient 104. For example, chest sensor 102 may be synchronized with bedside monitor 108. Then, caregiver 110 may associate chest sensor 102 with patient 104 using bedside monitor 108. After chest sensor 102 is associated with patient 104, chest sensor 102 may identify patient 104 to other components of system 100, such as other bedside monitors or other monitoring stations.

[0078] The bedside monitor 108 can be synchronized with the chest sensor 102, for example, by searching for devices within a specified distance of the bedside monitor 108, displaying a list of nearby devices (e.g., the chest sensor 102, the wrist sensor 106, and one or more other patient-worn sensors worn by other nearby patients), and allowing the caregiver 110 to select the chest sensor 102 from the displayed list of devices. After synchronization, the caregiver 110 can associate the chest sensor 102 with the patient 104's unique patient ID. As another example, the caregiver 110 can synchronize the bedside monitor 108 with the chest sensor 102 by entering the unique sensor ID of the chest sensor 102 at the bedside monitor 108. The unique sensor ID can be printed on the surface of the chest sensor 102, for example. In some implementations, the bedside monitor 108 is synchronized with the chest sensor 102 using a specific scanning device that communicates with the bedside monitor 108. The caregiver 110 can use the scanning device to scan the chest sensor 102 (e.g., by detecting a signal transmitted by a component of the chest sensor 102, scanning an RF ID tag, or by reading a barcode printed on the chest sensor 102). The bedside monitor 108 can use the information from the scanning device to identify the chest sensor 102 and synchronize with the chest sensor 102. In some implementations, the bedside monitor 108 can include a scanning device that is incorporated into the design of the bedside monitor 108. For example, the bedside monitor can be a tablet device with one or more built-in cameras that can be used to scan the chest sensor 102.

[0079] In some implementations, the bedside monitor 108 can automatically synchronize patient-worn sensors and other devices that have been previously synchronized with the bedside monitor 108 as long as the patient-worn sensors and other devices are within the communication range of the bedside monitor 108. For example, the chest sensor 102 can be synchronized with the bedside monitor 108 using one of the above techniques or other techniques. The patient 104 can then leave the communication range of the bedside monitor 108, such as by going to a hospital cafeteria for lunch or going to a physical therapy area of ​​a healthcare facility. The patient 104 can then return to the communication range of the bedside monitor 108. The bedside monitor 108 can automatically detect that the chest sensor 102 has re-entered the communication range of the bedside monitor 108, with which the bedside monitor 108 and the chest sensor 102 were previously synchronized, and then synchronize with the chest sensor 102. In some implementations, the bedside monitor 108 automatically synchronizes with all patient-worn sensors within a specified communication range that are capable of communicating with the bedside monitor 108. For example, the bedside monitor 108 may synchronize with patient-worn sensors of multiple patients located in the same room and display information received from each of these sensors.

[0080] In some implementations, the sensor worn by the patient can be synchronized with any monitor (e.g., bedside monitor) within a specified communication distance. In some implementations, the sensor worn by the patient can identify the nearest monitor from multiple monitors (e.g., by the strength of the communication signal) and automatically synchronize with the nearest monitor identified. In some implementations, the sensor worn by the patient can be synchronized with multiple monitors at the same time. In some implementations, the synchronization activity of the sensor worn by the patient can be used to track the movement of the patient. For example, each monitor can be associated with a specific physical location. In this example, the bedside monitor 108 can be associated with a room 309 in a healthcare institution. In some implementations, when the monitor is moved, they become associated with a new physical location. Continuing with this example, the patient 104 can leave the room (i.e., room 309) where the bedside monitor 108 is located.

[0081] Figure 2 is a diagram illustrating an example system 200 for monitoring waveforms and / or other real-time information obtained from or associated with a patient. The system 200 is implemented on one or more computers. In some implementations, the system 200 may be Figure 1 The system 100 of or comprising Figure 1 The system 200 includes a client device 210, a service agent 230, and one or more monitoring devices 250. In some implementations, the client device 210 may be Figure 1 In the client device 114, the service agent 230 may be Figure 1 The service agent 113 in the embodiment of the present invention and the monitoring device 250 may be Figure 1 The monitoring devices 102, 106, 107 and 108 in the embodiment of the present invention are shown in FIG. 2. The service agent 230 includes a web server 232, a web application server 234, a websocket processor 236 and a database 238.

[0082] The client device 210 provides a request for a web page to the service agent 230. In some implementations, the request includes patient information for a particular patient. For example, the patient information may include information for identifying a particular patient, such as the patient's name, date of birth, social security number, and physical address. In some implementations, the request may include a patient identifier (e.g., a unique ID number) for the patient. In some implementations, the request may include patient information for multiple patients.

[0083] The service agent 230 receives a request for a web page from the client device 210. In particular, the web server 232 of the service agent 230 receives a request for a web page from the client device 210. In some implementations, the service agent 230 may receive the request via an HTTP connection. However, the type of connection between the client device 210 and the service agent 230 is not limited to an HTTP connection. Any suitable type of connection may be established between the client device 210 and the service agent 230 for various implementations. In response to the request, the service agent 230 determines the web page based on the patient information included in the request, and provides the web page to the client device via the HTTP connection. Figure 3 The process for determining a web page and providing the web page is described in more detail.

[0084] The service agent 230 may be an on-demand service agent that processes or handles real-time medical data. In some implementations, the service agent 230 obtains real-time medical data from a monitoring device 250 that monitors a patient and obtains real-time medical data from the patient. The service agent 230 allows the client device 210 to access the real-time medical data generated by the service agent 230 based on the raw waveform data obtained from the monitoring device 250. In some implementations, the service agent 230 may be implemented as one or more computers, which are configured as HTTP servers to establish an HTTP connection between the service agent 230 and the client device 210. In some implementations, the service agent 230 may be implemented on a cloud computing platform. The cloud computing platform provides an endpoint for a client device such as the client device 210. The cloud computing platform also maintains or stores a database of real-time medical data, such as a database 238. Client devices such as the client device 210 may access the service agent 230 using the cloud computing platform.

[0085] In response to the request for the web page, the web server 232 assigns the request to the web application server 236. The web application server 236 determines the specific web page based on the patient information of the specific patient. In some implementations, the web page includes an interface for presenting data identifying the specific patient corresponding to the patient information included in the request. In some implementations, the interface can be a command line interface (CLI), a graphical user interface (GUI), or various combinations of the two. The web application server 236 provides the web page including the interface to the client device 210. The web application server 236 will refer to the web application server 236 for the web page. Figure 6 A and Figure 6 B describes the interface included in the web page in more detail. In some implementations, the web page can be provided from the service agent 230 to the client device 210 via an HTTP connection. However, the type of connection between the client device 210 and the service agent 230 is not limited to an HTTP connection. Any suitable type of connection can be used between the client device 210 and the service agent 230 for various implementations.

[0086] When the web page is received from the service proxy 230, a websocket connection is established between the client device 210 and the service proxy 230. In some implementations, when the web browser of the client device 210 loads the requested web page, the web page triggers the websocket connection between the client device 210 and the service proxy 230. In this example, the web page may include specific commands, such as commands programmed in JavaScript, so that these commands can trigger the websocket connection between the client device 210 and the service proxy 230.

[0087] In particular, in order to establish a websocket connection between the client device 210 and the service proxy 230, the client device 210 provides a websocket connection request to the service proxy 230. For example, the websocket connection request can be triggered in response to loading a web page on the client device. In this example, the websocket processor 236 of the service proxy 230 receives the websocket connection request. In response to receiving the websocket connection request, the websocket processor 236 of the service proxy 230 provides a websocket connection response to the client device 210 to establish a websocket connection between the service proxy 230 and the client device 210. When the client device 210 receives the websocket connection response, a websocket connection is established between the client device 210 and the service proxy 230.

[0088] Once the websocket connection is established, the client device 210 provides a request for real-time medical data to the service proxy 230 through the websocket connection established between the client device 210 and the service proxy 230. In some implementations, the client device 210 may request real-time medical data for a specific patient identified in the patient information described above. In some implementations, the request for real-time medical data may identify a medical data protocol that defines one or more attributes of the real-time medical data.

[0089] In some implementations, the attribute includes at least one of an identification, a sampling rate, a plot time, or buffer information. For example, the identification may indicate an identification of real-time medical data for a particular patient. The sampling rate may indicate a sampling rate at which raw waveform data obtained from the monitoring device 250 is sampled. The plot time may indicate a time period for writing raw waveform data to a buffer. The buffer information may indicate which buffer will be used to be filled with raw waveform data.

[0090] In response to a request for real-time medical data, the service agent 230 obtains a real-time medical data sample set. In some implementations, the real-time medical data sample set includes corresponding values ​​of attributes of the requested real-time medical data. For example, in a case where the client device 210 provides a request for real-time medical data associated with a specific patient, the websocket processor 238 of the service agent 230 obtains a real-time medical data sample set from one or more databases including the database 238. In this example, the real-time medical data sample set may include corresponding values ​​of attributes of the requested real-time medical data. That is, the real-time medical data sample set may include values ​​of the identification, sampling rate, plotting time, and buffer information of the requested real-time medical data. In some implementations, the service agent 230 obtains the real-time medical data sample set directly from one or more monitoring devices. For example, referring to Figure 1 The service agent 230 may obtain a real-time medical data sample set from sensors worn by the patient, such as the chest sensor 104 , the wrist sensor 106 , and the finger sensor 107 .

[0091] Based on the obtained real-time medical data sample set, the service agent 230 generates the real-time medical data of the specific patient. For example, based on the corresponding values ​​of the attributes of the requested real-time medical data, the service agent 230 generates the real-time medical data of the specific patient. In particular, in the case where the attributes include identification, sampling rate, plotting time and buffer information, the service agent 230 can determine the specific waveform based on the raw waveform data obtained from one or more monitoring devices based on the value of the identification. Based on the buffer information, the service agent 230 can determine which buffer will be used to be filled with the raw waveform data. Based on the sampling rate, the service agent 230 can determine the sampling rate of the specific waveform. Based on the plotting time, the service agent can determine the duration for which the service agent 230 writes the specific waveform to the specific buffer.

[0092] Once the service agent 230 writes a specific waveform to the buffer based on the sampling rate at the plotting time, the service agent 230 can generate real-time medical data based on the waveform data written to the buffer. The service agent 230 provides the generated real-time medical data to the client device 210 through a websocket connection. In some implementations, the service agent 230 stores the generated real-time medical data in a database 238.

[0093] The client device 210 receives real-time medical data from the service agent 230 and provides the real-time medical data to the user of the client device 210. For example, the client device 210 can provide the real-time medical data to a user such as a caregiver or other hospital personnel through an interface. The interface can be a CLI, a GUI, or various combinations of the two. Examples of the interface will be referred to in Fig. 7A and Figure 7BDescribe in more detail.

[0094] Figure 3 is a sequence diagram illustrating example operations for providing real-time medical data to a client device. In some implementations, Figure 3 The client device 310, web server 332, web application server 334, websocket processor 336 and database 338 in the embodiment may be respectively Figure 2 The client device 210, web server 232, web application server 234, websocket processor 236 and database 238 in the embodiment of the present invention. Figure 3 In the embodiment, the system 300 includes a client device 310 and a service agent 330 , and the service agent 330 includes a web server 332 , a web application server 334 , a websocket processor 336 , and a database 338 .

[0095] The client device 310 provides a request for a web page to the web server 332 of the service agent 330 (step 312). In some implementations, the request includes patient information for a particular patient. For example, the patient information may include information for identifying a particular patient, such as the patient's name, date of birth, social security number, and physical address. In some implementations, the patient information may include a unique identifier for the patient, such as a patient ID number or a patient ID code. In some implementations, the request may include patient information for multiple patients. In some implementations, the request may be provided over an HTTP connection.

[0096] Once web server 332 receives a request for a web page from client device 310, web server 332 assigns the request to web application server 334 (step 314). In some implementations, web server 332 assigns the request to a specific web application server dedicated to or associated with a specific patient. For example, each web application server can be assigned to a set of specific patient IDs. For example, in the case where web application server 334 is dedicated to or associated with the above-mentioned specific patient, service agent 330 can assign the request to web application server 334.

[0097] The web application server 334 determines a web page based on the patient information included in the request, and provides the web page to the client device via an HTTP connection (step 316). The web application server 334 determines a specific web page based on the patient information of a specific patient. For example, the web application server 334 determines a web page, and the web page identification includes data of at least one of a photo of the patient, the name of the patient, the medical data of the patient, or the personal information of the patient. In some implementations, the web page includes an interface for presenting data. In some implementations, the interface can be a CLI, a GUI, or various combinations of the two. The web application server 336 provides the web page including the interface to the client device 310. In some implementations, the web page can be provided from the service agent 330 to the client device 310 via an HTTP connection.

[0098] When receiving the web page from the service proxy 330, the client device 310 provides a websocket connection request to the websocket processor 336 to establish a connection between the client device 310 and the service proxy 330 (step 342). For example, when the web browser of the client device 310 loads the requested web page, a websocket connection is established between the client device 310 and the service proxy 330. In this example, the web page may include specific commands, such as commands programmed in JavaScript, so that these commands can trigger the client device 310 to provide a websocket connection request to the websocket processor 330 in response to loading the web page including these commands on the client device 310.

[0099] In response to receiving the websocket connection request, the websocket processor 336 provides a websocket connection response to the client device 310 (step 344). When the client device 310 receives the websocket connection response, a websocket connection is established between the client device 310 and the service proxy 330.

[0100] Once the websocket connection is established, the client device 310 provides a request for real-time medical data to the service proxy 330 via the websocket connection established between the client device 310 and the service proxy 330 (step 352). In some implementations, the client device 310 may request real-time medical data for a specific patient. The websocket processor 336 is described above with reference to Figure 2 The websocket processor 336 provides the generated real-time medical data to the client device 310 (step 354).

[0101] The websocket processor 336 accesses the database and opens the database 338 (step 356). After the websocket processor 336 starts providing the real-time medical data to the client device 310, the websocket processor 336 opens the database 338 so that the real-time medical data can be provided to the client device 310 without establishing other connections between the client device 310 and the service agent 330. Therefore, when the client device 310 provides a subsequent request for real-time medical data (step 362), the service agent 330 does not need to establish other websocket connections between the client device 310 and the service agent 330 because the real-time medical data can be provided to the client device 310 through the existing websocket connection established by steps 342 and 344. Because the present technology uses fewer network resources than a conventional system that establishes a websocket connection each time a real-time medical data is requested from a service agent, the present technology improves network efficiency.

[0102] In response to a subsequent request from the client device 310, the websocket processor 336 reads the value of the attribute of the real-time medical data from the database 338 (step 364). The websocket processor 336 generates the real-time medical data based on the value of the attribute read from the database 338. The websocket processor 336 provides the generated real-time medical data to the client device 310 (step 366).

[0103] In some implementations, one or more monitoring devices asynchronously push the monitored raw waveform data to the service agent 330. In these implementations, the service agent 330 stores the raw waveform data in the database 338. Then, when the service agent 330 receives a request from a client device, the service agent 330 reads the appropriate waveform data from the database 338 to generate real-time medical data.

[0104] Figure 4 4 is a flow chart illustrating an example method 400 for providing real-time medical data to a client device. For convenience, the method 400 will be described as being performed by a system including one or more computers located at one or more locations. For example, a system appropriately programmed according to the present specification, such as Figure 2 The system 200 in can perform the method 400.

[0105] The client device provides a request for a web page to the system (step 402). In some implementations, the request includes patient information for a particular patient. For example, the patient information may include information for identifying a particular patient, such as the patient's name, date of birth, social security number, and / or physical address. As another example, the patient information may include a unique patient identifier. In some implementations, the request may include patient information for multiple patients. In some implementations, the request may be provided over an HTTP connection.

[0106] Once the system receives a request for a web page from a client device, the system determines a particular web page based on the patient information included in the request (step 404). For example, the system determines a web page that identifies data including at least one of a photo of the patient, the patient's name, the patient's medical data, or the patient's personal information. In some implementations, the web page includes an interface for presenting the data. In some implementations, the interface can be a CLI, a GUI, or various combinations of the two.

[0107] The system provides a web page including an interface for presenting data to the client device (step 406). In some implementations, the web page can be provided from the system to the client device via an HTTP connection.

[0108] When the web page is received from the system, the system establishes a websocket connection between the system and the client device (step 408). For example, when the web browser of the client device loads the requested web page, the client device provides a websocket connection request to the system, and the system provides a websocket connection response to the client device, so that a websocket connection is established between the client device and the system. In this example, the web page may include specific commands, such as commands programmed in JavaScript. These commands may trigger the client device to provide a websocket connection request to the system in response to loading a web page including these commands on the client device.

[0109] Once the websocket connection is established, the client device provides a request for real-time medical data to the system through the websocket connection established between the client device and the system 330 (step 410). In some implementations, the client device may request real-time medical data for a specific patient identified in the patient information described above. The request for real-time medical data may include a request for one or more of heart rhythm (via ECG), heart rate, blood pressure, body temperature, respiratory rate, blood oxygenation, blood glucose level, patient position, patient movement, patient sleep state, hydration level, and / or perspiration level. In some implementations, the request for real-time medical data does not indicate the type of real-time medical data requested, but the system 330 may provide a pre-specified or standard data set, or the system 330 may provide all real-time medical data currently available.

[0110] The present system allows for publisher / subscriber relationships. For example, a loosely coupled publish / subscribe pattern is used for communication between various subsystems. System components that send data (e.g., a computing device that communicates with a patient-worn sensor or other patient sensor) will publish messages including real-time data for a specific topic to an agent system (e.g., system 330). System components that want to receive data associated with a specific topic (e.g., a computing device being used by one or more caregivers) subscribe to a specific topic channel. At the core of the communication architecture is a proxy that aggregates messages published for specific topics and routes them to subscribers to those topics. For example, a topic can include real-time (time-sensitive) telemetry data, such as waveform data, vital signs, alarms, sensor function information, etc.

[0111] For example, the system 330 may publish multiple channels, each containing information about different patients and / or different sets of information about one or more patients. A client device, such as the client device 310, may subscribe to one or more channels published by the system 330 to receive specific information. For example, for a specific patient, the system 330 may publish multiple channels, each containing different sets of information about the patient and / or one or more medical devices associated with the patient. For example, one channel may include only the patient's ECG waveform and heart rate information. Another channel may include multiple vital signs of the patient, including ECG waveform and heart rate information and the patient's current blood oxygenation level, blood pressure, hydration level, heart rate, respiratory rate, and body temperature. Another channel may include only the patient's blood glucose level information. As another example, the system 330 may publish a channel that includes only the operating information of a chest sensor and / or one or more other sensors or medical devices associated with the patient, such as battery power, network connection status, or information about the function of the sensor / medical device (e.g., information that an IT worker or hospital technician would be interested in). In this example, interested parties (e.g., IT workers) can subscribe to a channel published by the system 330 that includes operational information for all patients within a specific classification, such as all patients in a specific healthcare institution, all patients located in a specific city or region, or all patients currently equipped with a patient-worn sensor. Different interested parties can use login credentials to subscribe to different channels published by the system 330. In some implementations, the system 330 will check the login credentials of a specific user logged into a client device (e.g., client device 310) to determine whether the user is allowed to access a specific channel. If the user is allowed to access the requested channel, the system 330 can provide relevant information about the patient through the requested channel. In some implementations, different client devices can provide requests for different types of real-time medical data in the form of subscribing to a specific channel with a specific desired medical data set for one or more patients or by sending a specific request for a type of information to the system 330. In particular, different client devices can request specific types of real-time medical data obtained from different monitoring devices. For example, if the client device is a nurse station, the nurse station can request all real-time medical data obtained from different monitoring devices. For example, a client device may identify all information collected by sensors worn by one or more patients that should be displayed at a nurse's station. As another example, a nurse's station may request access to a published channel that includes all information collected by sensors worn by patients for a specified set of patients, such as all patients in a specified ward or on a specified floor of a hospital.

[0112] As another example, if the client device is a nurse station desktop, the nurse station desktop can request a specific type of real-time medical data obtained from a specific monitoring device. In this example, the nurse station desktop can only request real-time medical data that is essential, such as heart rate, blood pressure, body temperature, respiratory rate, blood oxygenation, or specific alarms from the corresponding monitoring device. For example, one or more nurses monitoring the nurse station may only be interested in information indicating the patient's status that needs to be processed immediately. As another example, if the client device is a laptop computer operated by an IT staff, the laptop computer can request real-time medical data such as battery life information from all monitoring devices operated by batteries. In this example, the laptop computer does not need real-time medical data such as heart rate, blood pressure, body temperature, respiratory rate, and blood oxygenation. In fact, in this example, for the purpose of data security, the IT staff may not have permission to access such patient data. As another example, if the client device is a mobile device of a family member of a patient, the mobile device can request a specific subset of real-time medical data such as patient position information. In this example, the mobile device may not request real-time medical data such as battery life information of a monitoring device operated by a battery. By using the websocket connection established between the client device and the service proxy, the client device can easily obtain the requested real-time medical data, because the service proxy can asynchronously push the real-time medical data to the client device.

[0113] The system generates real-time medical data (step 412) and provides the generated real-time medical data to the client device (step 414). The real-time medical data provided via the websocket connection is displayed simultaneously with surrounding web page information (e.g., including information about the patient) that has been previously provided via the HTTP connection. The process of generating real-time medical data will refer to Figure 5 Describe in more detail.

[0114] Figure 5 is a flow chart illustrating an example method 500 for generating real-time medical data. For convenience, the method 500 will be described as being performed by a system including one or more computers located at one or more locations. For example, a system appropriately programmed according to the present specification, such as Figure 2 The system 200 in can execute the method 500.

[0115] In the event that the client device provides a request for real-time medical data to the system through a websocket connection established between the client device and the system, the request for real-time medical data may identify a medical data protocol that defines one or more data attributes of the real-time medical data. In some implementations, the data attributes include at least one of an identification, a sampling rate, a plotting time, and buffer information.

[0116] To generate the real-time medical data, the system obtains values ​​of attributes of the requested real-time medical data (step 502). For example, when a client device provides a request for real-time medical data associated with a particular patient, the system obtains corresponding values ​​of the attributes of the requested real-time medical data from one or more databases. That is, the system obtains corresponding values ​​of an identification, a sampling rate, a plotting time, and buffer information of the requested real-time medical data. In this example, the real-time medical data includes waveform data, and the attributes include an identification, a sampling rate, a plotting time, and buffer information.

[0117] The system determines a specific waveform from one or more waveforms monitored by one or more monitoring devices (step 504). For example, when raw waveform data of multiple waveforms are stored in a database and each waveform is associated with a corresponding identifier of a specific patient, the system can determine the specific waveform based on the value of the identifier.

[0118] The system determines the specific buffer to be used to be filled with waveform data (step 506). For example, based on the buffer information, the system can determine which buffer will be used to be filled with waveform data obtained from the database. In some implementations, double buffering technology can be used to render waveform data. For example, the client device may include two buffers, namely a first buffer and a second buffer. The first buffer can be used to be filled with waveform data. While filling the first buffer with waveform data, the waveform data stored in the second buffer can be rendered. When filling the first buffer with waveform data (for example, to a pre-specified level), the functions of the two buffers are reversed so that the second buffer receives the waveform data and renders information from the first buffer. Thus, by using two buffers, the client device can efficiently process waveform data in real time.

[0119] The system determines a sampling rate for a particular waveform (step 508). For example, based on the value of the sampling rate, the system can determine the sampling rate at which real-time medical data will be sampled based on raw waveform data stored in a database. In some implementations, different sampling rates can be used for different types of real-time medical data. For example, blood pressure can be sampled from a monitoring device to a client device 9 times per second. As another example, raw waveform data, such as ECG data obtained from a chest sensor, can be sampled 200 times per second. As another example, blood oxygenation obtained from a finger sensor can be sampled 33 times per second. As another example, bioimpedance can be sampled 33 times per second. When multiple different sampling rates are used, a buffer can be used to buffer the real-time medical data. Once a specific amount of data is buffered at the buffer, the real-time medical data can be transmitted together to the client device.

[0120] The system determines a plot time for a particular waveform (step 510). For example, based on the value of the plot time, the system can determine how long the system will write the particular waveform to a buffer determined based on the buffer information.

[0121] The system generates real-time medical data (step 512). Based on the above determinations (steps 504 to 510), the system writes a specific waveform to a buffer at a plotting time based on a sampling rate. In this example, the waveform data written is the requested waveform data. In some implementations, the system stores the generated real-time medical data in a database.

[0122] Figure 6 6 is a diagram illustrating an example system 600 for implementing a publisher / subscriber protocol to allow client devices to subscribe to various channels to receive real-time patient information. The system 600 includes a central communication agent 602, which may be, for example, Figure 3 System 330 in Figure 2 Service agent 230 or Figure 1 The central communication agent 602 receives real-time patient information from a plurality of patient-side devices, such as bedside monitors 604a to 604c. In this example, each of the bedside monitors 604a to 604c communicates with one or more patient-worn sensors and / or other sensors that can provide real-time or near real-time data of the patient, such as vital signs, position, sleep status, etc. The bedside monitors 604a to 604c can be implemented, for example, as Figure 1 Bedside monitor 108 or Figure 2 The detection device 250 in the bedside monitor 604a to 604c receives real-time patient data from one or more sensors and provides these real-time patient data to the central communication agent 602 through the network. The patient mobile device 606 also serves as a source of real-time patient information for the central communication agent 602. The patient mobile device 606 can be, for example, a mobile phone or tablet computer that belongs to or is associated with a patient who has been transferred from a healthcare facility such as a hospital to their home or a relative's home. The patient mobile device 606 wirelessly communicates with one or more patient-worn sensors and is used to aggregate data received from the patient-worn sensors and transmit these data to the central communication agent 602 through a network such as the Internet.

[0123] The central communication agent 602 can publish information received from the bedside monitors 604a to 604c and the patient mobile device 606 to a plurality of subscription channels so that other devices can subscribe to these channels to receive and present real-time patient data. For example, the central monitoring station 608 can communicate with the central communication agent 602 and subscribe to one or more channels published by the central communication agent 602. The central monitoring station 608 performs, for example Figure 1 Client device 114, Figure 2 The client device 210 or Figure 3 Other client devices may include a physician's terminal 610 and a nurse's mobile viewer 612 (e.g., a mobile phone belonging to or assigned to a nurse or other caregiver). The physician's terminal 610 and the nurse's mobile viewer 612 may be implemented to perform, for example, Figure 2 The client device 210 or Figure 3 The functionality of the client device 310 in.

[0124] System 600 implements a loosely coupled publish / subscribe model for communication between various subsystems. System components that send data (e.g., bedside monitors 604a to 604c and patient mobile devices 606) will publish messages including real-time data for specific topics to central communication agent 602. System components that want to receive data associated with specific topics (e.g., central monitoring station 608, physician's terminal 610, and nurse's mobile viewer 612) subscribe to one or more specific topic channels. At the core of the communication architecture is central communication agent 602, which aggregates messages published for specific topics and routes them to subscribers of those topics. Topics can include, for example, real-time (time-sensitive) telemetry data, such as waveform data, vital signs, alarms, sensor function information, etc.

[0125] continue Figure 6 , the central communication agent 602 can publish different channels containing real-time patient information and other patient information for different patients or different groups of patients. For example, a first channel can include relevant real-time patient information for all patients located in a specific area of ​​a healthcare facility (e.g., a specific floor of a hospital or in a specific ward). A second channel can include real-time patient information for all patients currently under the care of a specific cardiologist. This can enable a cardiologist (and other caregivers assisting the cardiologist) to subscribe to a channel that will provide information about all patients of interest to the cardiologist. A third channel can include real-time patient information for all patients in the system who are receiving treatment of a specific classification or category. For example, real-time patient information for all patients receiving kidney dialysis treatment can be published on a specific channel. In addition, the central communication agent 602 can publish one or more channels for each individual patient in the system.

[0126] As described above, the central communication agent 602 receives the real-time patient information from computing devices that communicate with patient-worn sensors (e.g., bedside monitors 604a to 604c and patient mobile device 606). These computing devices may be, for example, bedside monitors, or portable computing devices such as smartphones, tablets, personal computers, etc. that communicate with one or more patient-worn sensors. These computing devices may be, for example, Figure 2 The monitoring devices 250 in the embodiment of the present invention are provided to the central communication agent 602. These monitoring devices provide real-time patient information together with a patient identifier that identifies the patient associated with the information. Specifically, the bedside monitor 604a communicates with one or more patient-worn sensors that monitor one or more vital signs of the patient. The bedside monitor 604a provides information detected by the sensors worn by the patient (e.g., after preprocessing the information) to the central communication agent 602 via a communication network. The information is provided together with the patient's unique patient identifier so that the information can be linked to the patient when the information is provided to another end-user device (e.g., a physician's terminal 610) for presentation to a caregiver. The central communication agent 602 then publishes the real-time patient information received from the bedside monitor 604a on one or more channels. The end user can then subscribe to one or more channels to view relevant real-time patient information. For example, the nurse's mobile viewer 612 can subscribe to a channel that includes all information about a patient associated with the bedside monitor 604a by establishing a websocket connection with the central communication agent 602 and requesting information using a patient identifier of the patient associated with the bedside monitor 604a. Figure 2 The client device 210, Figure 2 The client device 310 and Figure 3 The client device 114 in the embodiment of the present invention can receive real-time patient information provided by the patient's worn sensor without directly communicating with the patient's worn sensor or a computing device that directly communicates with the patient's worn sensor. In addition, multiple subscribing devices can monitor information from the same patient at the same time. For example, a nurse's mobile viewer 612 and a physician's terminal 610 can both subscribe to a channel published by the central communication agent 602 that includes waveform information of a patient associated with a bedside monitor 604b to simultaneously monitor the waveform information.

[0127] In other words, the present system does not require an end-user device, such as a nurse's mobile viewer 612, to establish a direct connection with a patient-side computing device, such as a bedside monitor 604a to 604c. Instead, the end-user device can receive real-time data generated by the bedside monitors 604a to 604c by subscribing to one or more channels published by the central communication agent 602 and present the real-time information to the caregiver. In this way, the caregiver's end-user device (e.g., the central monitoring station 608, the physician's terminal 610, and the nurse's mobile viewer 612) does not need to know the network identification of the bedside monitors 604a to 604c, but can simply identify the channel including the desired real-time patient information, and the central communication agent 602 acts as an aggregator to provide the real-time information to the caregiver's end-user device. Specifically, the central communication agent 602 receives real-time information generated by, for example, a bedside monitor 604a, associates the real-time information with a unique identifier of a patient associated with the bedside monitor 604a, and then publishes the real-time information on one or more channels. The caregiver's end-user device may then subscribe to one or more of the one or more channels to view real-time information without directly connecting to the bedside monitor 604a or needing to know the network identification of the bedside monitor 604a.

[0128] In some implementations, one or more computing devices associated with a particular caregiver can use the caregiver identifier (ID) of the caregiver to subscribe to one or more real-time patient information channels published by the central communication agent 602. For example, the central monitoring station 608 can use the caregiver identifier to subscribe to one or more channels containing information of patients associated with the patient mobile device 606. The caregiver identifier can be, for example, a unique alphanumeric code associated with the caregiver. In some implementations, the caregiver identifier can be used by the caregiver as a login credential to log into the device to view patient information. In some implementations, the caregiver identifier of the caregiver can be associated with, for example, one or more patient identifiers of patients (e.g., patients associated with bedside monitors 604a to 604c) who are partially responsible for care by the caregiver. For example, the patient identifier of a patient who has undergone surgery or is scheduled to undergo surgery by a specific surgeon can be linked to the surgeon's caregiver identifier. The caregiver's computing device (e.g., the physician's terminal 610) can transmit the caregiver's unique identifier to the central communication agent 602. The central communication agent 602 can then use the received unique identifier to identify one or more channels of interest to the caregiver. For example, the central communication agent 602 can identify channels for patients with patient identifiers associated with caregiver identifiers (e.g., as part of a care group) and provide those published channels to the physician's terminal 610. In this way, the caregiver is not required to manually enter the information he wants to view. Instead, based on the caregiver identifier of the caregiver, relevant patient information is automatically provided to the caregiver's device.

[0129] As another example, an IT technician may have a unique caregiver identifier. Upon logging into the device, the technician's device may provide the unique caregiver ID to the central communication agent 602. The central communication agent 602 may then identify channels that include operational information about multiple patients (e.g., all patients in a particular facility or a particular ward), such as battery charge, network connection status, one or more sensors about to be detached, or information about the functionality of sensors / medical devices associated with the patient (e.g., information that may be of interest to an IT worker or hospital technician). The central communication agent 602 may then automatically subscribe the technician's device to those channels, enabling the technician to view information indicating when a particular patient sensor may require maintenance or other attention.

[0130] As another example, a cardiologist may subscribe to a channel that includes vital sign information for all patients in a cardiac care group published by the central communication agent 602. Thus, the physician may monitor patient information for all patients in the care group without requiring the physician's device to subscribe to a separate channel for each patient.

[0131] In some implementations, the central communication agent 602 will implement a set of rules for determining which information to provide to a subscribing device based on a caregiver ID. For example, the central communication agent 602 may determine that: for a caregiver ID associated with a physician, only patient data for patients directly associated with the physician will be provided (e.g., not information for all patients within a ward or nursing facility). For a caregiver ID associated with a particular supervising nurse (e.g., a nurse who may be working at a central nurse station such as a central monitoring station 608), information for all patients within a particular ward or healthcare facility will be provided. The caregiver ID of an IT technician will be provided only with information about sensor capabilities, and not information about actual patient vital sign data. A patient or a relative of a patient will be provided only with information about that patient, and not information about other patients (e.g., a relative's caregiver ID only allows the relative to subscribe to channels associated with patients related to the relative).

[0132] As an example implementation, the central communication agent 602 may require the subscribing device to specify the channel subscription information in a particular format, such as by using a particular subscription mode. One example format may require the subscribing device to identify the relevant channel information in a hierarchical manner. For example, the nurse's mobile viewer 612 may identify the channel information according to a hierarchical structure that requires the subscribing device to identify a particular system or network, a particular patient or group of patients, and a set of information about the identified one or more patients. For example, the hierarchical request may use the following nomenclature to identify a particular channel:

[0133] / system identifier / patient identifier / information type For example, using this example channel identifier nomenclature, the nurse's mobile viewer 612 may subscribe to a channel displaying waveform data for the patient with patient ID 3202 using the following channel identifier format:

[0134] / Ward 17 / 3202 / Waveform

[0135] Other types of information that may be requested in addition to waveform data may include vital sign data, alarm status data, operational data, orientation data, or specific vital signs such as respiratory rate, heart rate, blood oxygen level, etc. Static patient information (e.g., patient treatment history) may also be provided using the nomenclature. The central communication agent 602 uses the information included in the hierarchical nomenclature to identify the appropriate channel or channels for information to be provided to the subscribing device. In some implementations, the central communication agent 602 may allow wildcards. For example, the system may use the symbol "#" as a multi-level wildcard and the symbol "+" as a single-level wildcard. Multi-level wildcards request all available information at the indicated level and all subsequent levels in the hierarchy, while single-level wildcards will require the user to specify a lower level. For example, the following indicator would be a request for all patient information for patient 3202:

[0136] / Ward 17 / 3202 / #

[0137] The following indicator would be a request for all patient information for all patients in ward 17:

[0138] / Ward 17 / #

[0139] Continuing with the example, the following indicator would be a request for battery charge information for all patients in ward 17:

[0140] / Ward 17 / + / Battery Level Other combinations based on this nomenclature are apparent from the examples above. A data viewing application running on a subscriber device (e.g., a web browser establishing a websocket connection) can select a publisher channel topic of interest and consume data from that channel topic as needed and present the data appropriately. A subscription pattern is a filter sent to the communication agent to be applied to the connection. Such a subscription service based on patient ID and identified information type enables subscribers to easily follow a patient as he or she moves through different environments, including from immediate post-surgery recovery to physical therapy to home, without requiring the subscribing device to know the patient's location or the identity of the patient-side computing device (e.g., the patient's mobile phone or bedside monitor).

[0141] In some implementations, in addition to providing real-time patient information, the bedside monitors 604a to 604c and the patient mobile device 606 can act as subscription devices. For example, a user of the patient mobile device 606 can subscribe to one or more channels published by the central communication agent 602. In some implementations, the devices (bedside monitors 604a to 604c and the patient mobile device 606) that provide real-time patient information will automatically subscribe to one or more channels published by the central communication agent 602. For example, the bedside monitors 604a to 604c and the patient mobile device 606 can automatically subscribe to a channel indicating an alarm confirmation. For example, the bedside monitor 604a can provide information indicating the alarm state (e.g., cardiac arrest) of the patient associated with the bedside monitor 604a to the central communication agent 602. The caregiver who receives the alarm can (e.g., by selecting a button or control) confirm that the alarm has been received to let other caregivers know that they are paying attention to the patient alarm state. The caregiver's confirmation of the alarm state may be provided from the caregiver's device back to the central communication agent 602 and then provided to the bedside monitor 604a on a publishing channel.

[0142] In some implementations, there is a separate instance of the central communication agent 602 for each specific grouping of monitoring devices. For example, the system 600 can implement a separate instance of the central communication agent 602 for each ward in a hospital. As another example, each healthcare institution within a healthcare system can have a separate instance of the central communication agent 602. In some implementations, when the monitoring device is connected to the system 600, the monitoring device can specify a specific ward to be grouped within other groups. For example, a user of a bedside monitor 604a can specify a specific ward to be associated with the bedside monitor 604a when the bedside monitor 604a is initialized. Thereafter, even if the bedside monitor 604a is moved to another physical location, the bedside monitor 604a can continue to be associated with the initially designated ward, and therefore will continue to be associated with (and provide real-time patient information to) the same instance of the central communication agent 602.

[0143] In some implementations, a caregiver may request historical information from the central communication agent 602. For example, a physician may use the physician's terminal 610 to replay a past data stream of a patient associated with a bedside monitor 604a. The physician may specify a date and time to retrieve previous real-time patient information from the central communication agent 602. The historical data may be provided, for example, via a websocket connection between the physician's terminal 610 and the central communication agent 602. In some implementations, a user device such as the physician's terminal 610 may not be able to process a large amount of data at once, and therefore the central communication agent 602 may break down the requested historical information into smaller pieces of information before providing the information to the physician's terminal 610 for display to the physician.

[0144] 7A to 7D is a diagram illustrating an example interface displayed on a client device for providing real-time medical data. Fig. 7A 710 is a diagram showing an example interface 710 displayed on a client device such as a laptop or desktop device. The interface provides real-time medical data of one or more specific patients. For example, the interface 710 includes a first portion 711 that provides real-time medical data of a first patient, a second portion 712 that provides real-time medical data of a second patient, and a third portion 713 that provides real-time medical data of a third patient. The first portion 711 includes an image 714 associated with the patient, an identification code 715 that identifies the patient, digital data 716 of the patient's real-time medical data, and graphical data 717 of the patient's real-time medical data.

[0145] Figure 7B 7 is a diagram showing an example of an example interface 720 displayed on a client device. In particular, the interface 720 provides a method for performing a task on a monitoring device (e.g., Figure 2 Monitoring device 250 and / or Figure 2 The user interface 720 provides various real-time medical data of a specific patient. The user interface 720 includes icons 726, which indicate battery information of multiple sensors currently synchronized with the monitoring device. Each icon in the icons 726 indicates the battery charge level of each sensor. In some implementations, the icon 726 may also indicate the name or identifier of the sensor so that the user can know which sensor is associated with a specific icon. In this example, the icon 726 includes an indicator "O2" to indicate that the icon 726 indicates the battery charge level of the blood oxygenation sensor associated with and / or attached to the patient. In these implementations, a request for real-time medical data for displaying an icon can be provided from a client device to a service agent via an HTTP connection. Information on how to display an icon can be provided by a system (e.g., system 330) using an HTTP connection, and real-time medical data for icon 726 can be provided from a service agent to a client device via a websocket connection. In this way, relatively static data that is unlikely to change is provided via an HTTP connection, while real-time medical data is provided via a websocket connection. In this particular example, the information provided via the HTTP connection may specify the location and shape of the battery icon, while the websocket connection provides information about the charge level of one or more batteries. The browser at the client device then combines this information (static display information from the HTTP connection and real-time value information from the websocket connection) to display a battery icon showing the current charge level of each sensor device.

[0146] In addition, user interface 720 shows various vital signs waves and digital levels. For example, user interface 720 shows a patient's heart rate waveform 728 and a patient's digital heart rate value 741. In the example shown, the patient's heart rate value 741 is 80 beats per minute. User interface 720 indicates that the patient's acceptable heart rate level falls between 60 and 100 beats per minute at 742. Since the patient's current heart rate is 80 beats per minute and falls within the indicated acceptable range, there is currently no alarm state for the patient's heart rate. This is indicated by icon 744. Icon 744 indicates whether the patient's current heart rate is within an acceptable range. In the case where the patient's heart rate is not within an acceptable level, icon 744 can change to indicate an alarm state. For example, the color can be changed to red. In addition, the bedside monitor can send an audible alarm to warn the patient's alarm state to nearby caregivers. In some implementations, other parts of user interface 720 can flash or otherwise indicate an alarm state. For example, when the patient's heart rate exceeds an acceptable level, the displayed heart rate value 741 can flash. In some implementations, icon 744 can flash at different rates to indicate the severity of a particular alarm state. For example, the further the patient's heart rate is from an acceptable range, the faster icon 744 flashes.

[0147] In these implementations, a request for real-time medical data for displaying heart rate waveforms 728, digital heart rate values ​​741, acceptable heart rate levels 742, and alarms 744 can be provided from a client device to a service agent via an HTTP connection. For example, a user of a client device can use the client device to subscribe to a publishing channel that includes all information presented on the user interface 720. The client device then receives information specifying how to display real-time information via the HTTP connection. For example, information provided by a system (e.g., system 330) to a client device (e.g., client device 310) that is displaying the user interface 720 via an HTTP connection between the two devices can specify where certain types of information (e.g., ECG and other waveform data 728, 746, and 754, heart rate values ​​741, alarm status 744, etc.) are displayed on the screen. The HTTP data can also disclose the manner in which the data is displayed, including the color, value, background, and border of various waveforms, the size of the various values ​​of the appearance of icons such as the alarm status icon 744 (e.g., the size of the numbers and icons), the fonts of the numbers and letters, and other display aspects. This display information can be considered as static information that is unlikely to change or will only change occasionally (e.g., when the client device requests a different set of patient information and / or subscribes to a different information channel). Therefore, this static or nearly static information that controls the display context of the patient information is transmitted via an HTTP connection.

[0148] In contrast, real-time medical data indicating the value of each piece of displayed information, including, for example, heart rate waveform 728, digital heart rate value 741, and alarm status 744, is provided from the service proxy to the client device via a websocket connection. This information is dynamic in that it changes as new information is collected from sensors worn by the patient. The websocket connection facilitates rapid transmission of this real-time, dynamically changing data, which is displayed on the user interface 720 according to the display parameters specified by the information received via the HTTP connection.

[0149] The user interface 720 also shows a patient's blood oxygenation waveform 746 and a digital blood oxygenation value 748. The waveform and the value represent dynamic data collected at a patient monitoring device, such as a sensor worn by the patient, and published by the service agent via a websocket connection. As described above, the display characteristics of the blood oxygenation waveform 746 and the digital blood oxygenation value 748 are defined by data provided by the system to the client device via an HTTP connection. The user interface 720 also shows the patient's acceptable blood oxygenation range at 750. The user interface 720 also includes an alarm status icon 752 indicating that the patient's blood oxygenation level is within the acceptable range. As described above, information about how to display the alarm status icon 752 is provided by the HTTP connection, and the state of the alarm status icon 752 (e.g., an indication of an alarm state or a non-alarm state) is based on the dynamic information received via the websocket connection.

[0150] In addition, the user interface 720 includes a respiratory rate waveform 754 and a digital respiratory rate value 756, which shows a digital value indicating the number of breaths taken by the patient per minute. As with the patient data described above, the waveform and numerical value represent dynamic data collected at a patient monitoring device, such as a sensor worn by the patient. The dynamic data is published by the service agent via a websocket connection with a client device. As described above, the display characteristics of the respiratory rate waveform 754 and the digital respiratory rate value 756 are defined by data provided to the client device by the system via an HTTP connection. In the example shown, as indicated by the respiratory rate value 756, the patient's respiratory rate is 15 breaths per minute. The user interface 720 also shows an acceptable respiratory rate range for the patient at 758. In the example shown, the acceptable respiratory rate range is 8 breaths per minute to 40 breaths per minute. The user interface 720 also includes an alarm status icon 760 indicating that the patient's respiratory rate is within an acceptable range. As described above, information on how to display the alarm status icon 760 is provided by the HTTP connection, while the state of the alarm status icon 760 (eg, indication of an alarm state or a no-alarm state) is based on dynamic information received via the websocket connection.

[0151] The user interface 720 also includes a blood pressure value 762 for the patient. In the example shown, the blood pressure value 762 indicates that the patient's current blood pressure is 128 / 78. In addition, the user interface 720 includes an acceptable blood pressure range for the patient at 764. As described above, information indicating the nature of how the blood pressure value 762 is displayed is provided via an HTTP connection between the system and the client device. This information may include, for example, the size, font, position, and color of the displayed blood pressure value 762. The value of the blood pressure value 762 is dynamic information provided to the client device by the service agent via a websocket connection.

[0152] The user interface 720 also includes an alarm status icon 766 indicating that the patient's blood pressure is within an acceptable range. Again, different display characteristics of the alarm status icon 766 can be defined by information received via the HTTP connection. For example, the information received via the HTTP connection can indicate several possible alarm status icons 766 for indicating different alarm states. The information indicating which alarm status icon 766 to display is dynamic information received via the websocket connection.

[0153] The user interface 720 also includes an orientation indication 767 indicating the patient's current orientation and a time indication 768 indicating how long the patient has been in the current orientation. The orientation indication 768 can help the caregiver identify whether the patient has been in the current orientation for longer than a preferred length of time. The orientation indication 768 can also be used to indicate (e.g., by using an audible alarm or a visual alarm, indicating that the alarm is "off") that the patient has fallen and needs help. The client device can receive multiple orientation indications 767 via an HTTP connection, wherein each change in the orientation indication 767 indicates a different orientation of the patient (e.g., supine, prone, lying on one side or the other, semi-reclined, sitting upright, standing, etc.). The client device can receive dynamic information indicating the patient's orientation via a websocket connection, and then the client device can use the dynamic information received via the websocket connection to determine which orientation indication 767 received via the HTTP connection to display. In other words, the information received via the HTTP connection defines how to display information indicating a specific orientation, while the information received via the websocket connection indicates the patient's orientation and therefore determines which orientation indication 767 previously received is displayed.

[0154] The user interface 720 also includes a digital temperature value 770 of the patient. In the example shown, the temperature value 770 indicates that the patient's current temperature is 102.0 degrees Fahrenheit. The user interface 720 also includes an acceptable temperature range for the patient at 772, and an alarm status icon 774 indicating whether the patient's temperature is within the acceptable range. As described above, information indicating how to display the nature of the temperature value 770 is provided via an HTTP connection between the system and the client device. This information may include, for example, the size, font, position, and color of the displayed temperature value 770. The value of the temperature value 770 is dynamic information provided to the client device by the service agent via a websocket connection. Again, different display characteristics of the alarm status icon 774 can be defined by information received via an HTTP connection. For example, information received via an HTTP connection can indicate several possible alarm status icons 774 for indicating different alarm states. The information indicating which alarm status icon 774 is to be displayed is dynamic information received via a websocket connection.

[0155] User interface 720 also includes control buttons 782, 784 and 776. Control button 782 is used to access various controls or other display screens of one or more other monitoring devices. For example, control button 782 can be used to access additional information about the system, monitoring device (e.g., a sensor worn by a patient or a bedside monitor) or a patient. As another example, control button 782 can be used to access a settings menu. The settings menu can be used to, for example, change the brightness of the display of the monitoring device. Volume control button 784 allows the user to change the volume of the audible alarm. Control button 786 allows the user to mute all of the above alarms. In some implementations, control button 786 can mute specific alarms based on user settings. Display characteristics and actions performed in response to user interactions with control buttons 782, 784 and 776 can be defined by information received via an HTTP connection, because the functions performed according to control buttons 782, 784 and 776 are generally static in nature and have no direct relationship to real-time data received from one or more patient sensors.

[0156] In some implementations, the user interface 720 may include additional static and / or dynamic information associated with the patient and / or sensors associated with the patient. For example, the user interface 720 may also include the patient's name or other identifier and a picture of the patient. The user interface 720 may also include information about the patient's recent or planned medical procedures. The user interface 720 may also include information about the patient's medical history or recently experienced medical conditions. Such information is generally considered to be static or relatively static in nature, and therefore may be provided via an HTTP connection. In some implementations, such patient-specific information may be provided via a websocket connection because such information is patient-specific and is considered sensitive.

[0157] In other examples (not depicted), user interface 720 may have different display characteristics. These different display characteristics may be defined by information received via the HTTP connection. User interface 720 may be changed for a variety of reasons. For example, different users with different information access rights may only be able to access Figure 7B Thus, user interface 720 may be modified to display only the information that is allowed to be accessed by that particular user. As another example, a user may wish to, for example, Figure 7B A subset of the information shown in and / or included by subscription is Figure 7B The example shows more information than Figure 7B The examples show little or no information Figure 7B The information shown in the example can be changed selectively by using different channels of different information. For example, a physical therapist may only be interested in heart rate and patient position information. The physical therapist can subscribe to a publishing channel that only provides this information for the patient.

[0158] When subscribing to a channel, the client device establishes an HTTP connection with the system (e.g., system 330). The client device can specify which information is being requested (or which channel is being requested) via the HTTP connection. The system can then provide information about how to display the requested information via the HTTP connection. The service agent then provides the real-time value of the required information via the websocket connection. The client device can then only display the requested information type specified by the HTTP information with the value specified by the websocket information. In this way, by subscribing to different channels (or requesting different patient information sets), the client device receives update information via the HTTP connection, which specifies how to display this new subset of information through the user interface 720. In this example, the HTTP information can, for example, specify that the patient's heart rhythm information is displayed along the upper half of the screen, while the patient's position information is displayed along the bottom of the screen. It should be recognized that any combination of the information described above can be requested and displayed, and different display formats / layouts are defined by the information received via the HTTP connection, while the value of the displayed information is received via the websocket connection.

[0159] Figure 7C730 is a diagram showing an example of an example interface 730 displayed on a client device. For example, user interface 730 may be a user interface of a mobile device such as a smartphone with a limited display screen area, while user interface 720 may be a user interface of a computing device such as a laptop, a desktop computer, a dedicated nurse station, or a tablet device with a larger display screen. The interface provides real-time medical data of one or more patients. For example, interface 730 includes a first portion 731 providing real-time medical data of a first patient, a second portion 732 providing real-time medical data of a second patient, and a third portion 733 providing real-time medical data of a third patient. The first portion 731 includes an image 734 associated with the patient, one or more icons such as icons 735 and 736 indicating the medical status of the patient. For example, icon 735 indicates a plurality of new notifications about a news feed of the patient indicated in portion 731. Icon 736 indicates an alarm condition of the patient indicated in portion 731, for example, the patient may have fallen, may have an irregular heartbeat, or may have missed a scheduled medication dose. In some implementations, portion 737 for displaying icons 737a to 737d may be displayed in interface 730. Selecting icon 737a may enable the caregiver to write a private message to the patient indicated in portion 731 using the user interface 730. Selecting icon 737b may enable the caregiver to send a message to other caregivers in the patient's care group using the user interface 730. Selecting icon 737c may cause a list or other visual representation of the caregivers in the care group of the patient indicated in portion 731 to be displayed. Selecting icon 737d may enable the caregiver to use the user interface 730 to push a message to the "wall" of the patient indicated in portion 731, which may be viewed by all or a subset of the patient's caregivers.

[0160] In some implementations, the user interface 730 also includes a portion 738. Portion 738 shows a control button 738a, which allows the user of the mobile device to access additional information and control menus. For example, the control button 738a allows the user to access a menu screen. The menu screen can allow the user to access its additional information, change settings, or indicate warning preferences or view preferences. For example, the user can select the control button 738a to cause the mobile device to display a settings screen or other menu screen. The user can select the icon 738b to view a list of care group members. For example, selecting the icon 738b can cause the user interface 730 to display a list of patients for whom the user is an associated caregiver. As another example, selecting the icon 738b can cause the user interface 730 to display a list of caregivers (e.g., a list of all caregivers in a radiation caregiver group) who are part of one or more specific caregiver groups of which the user is a member. The user can select the icon 738c to write a message to another user of the application, such as another caregiver or patient.

[0161] Fig.7D 740 is a diagram showing an example of an example interface 740 displayed on a client device. For example, the interface 740 can be displayed on a mobile device such as a smartphone or a tablet computer having a limited display screen area. In some implementations, the user interface 740 can be displayed in response to a user clicking on the above reference Figure 7C The user interface 730 is presented by selecting part 733 in the user interface 730 described above. Return to reference Fig.7D , interface 740 provides real-time medical data for a specific patient.

[0162] The user interface 740 includes a portion 792, which includes a plurality of regions 792a to 792g for providing various real-time medical data. Region 792a indicates that the patient is located in bed 8 of room 2043 of the healthcare facility. Region 792b indicates the patient's digital heart rate value. In the example shown, the heart rate value is 100 beats per minute. Region 792c indicates the patient's digital blood oxygenation value. Region 792d indicates the patient's digital respiration rate value. In this example, the respiration value is 100 breaths per minute. Region 792e indicates the patient's blood pressure value. In the example shown, the patient's current blood pressure is 122 / 80. Region 792f indicates the patient's digital temperature value. In the example shown, the patient's current temperature is 100.04 degrees Fahrenheit. Region 792g indicates various vital sign waves. In some implementations, region 792g can display a type of vital sign wave. For example, region 792g can display a heart rate waveform. In some implementations, region 792g may display multiple types of vital sign waves. For example, region 792g may display a heart rate waveform and a respiratory rate waveform. Figure 7B As described, the information shown in the user interface 740 may be a combination of information received via an HTTP connection and a websocket connection. For example, the nature of how to display information and what information to display may be specified by information received via the HTTP connection. The value of the displayed information is specified by dynamic data received via the websocket connection.

[0163] The user interface 740 includes a portion 793 that displays patient information. For example, the portion may display a photo of the patient and the patient's name. In some implementations, portion 793 also indicates information about the patient's symptoms or illness. In some implementations, the patient information is transmitted between the client device and the service agent via an HTTP connection because the information is typically static data.

[0164] Selecting icon 795a can cause the user interface 740 to display the patient's care feed and alarm history. The care feed can include, for example, messages posted by the patient and / or a caregiver associated with the patient, the patient's historical medical information (including historical vital signs information), the patient's past alarm states, the nature of these alarm states, and the actions taken in response to these alarm states. Selecting icon 795b can cause only the care feed to be displayed without displaying the alarm list. Selecting icon 795c can cause the alarm list to be displayed without displaying other care feed information.

[0165] User interface 740 includes a portion 794 that displays various real-time medical data of the patient. Portion 794 provides more detailed real-time medical data than portion 792. In some implementations, when a user selects a specific area of ​​portion 792, user interface 740 displays real-time medical data associated with a specific area in portion 794. For example, when a user selects region 792b associated with a heart rate value, portion 794 provides detailed real-time medical data associated with the heart rate value of the patient. In particular, portion 794 includes multiple regions and icons 794a to 794g for displaying detailed real-time medical data associated with the heart rate value of the patient. Region 794a displays the current heart rate value of the patient. Region 794b displays the name of the patient. Icon 794c indicates that there is currently an effective alarm for the patient that has not been processed by the caregiver. In some implementations, selecting alarm 794c can cause additional details about the alarm state to be displayed. In some implementations, icon 794c can be color-coded or have other visual indications (e.g., flashing at a specific speed) to indicate the relative severity of the alarm condition of the patient. Area 794d shows that the patient's acceptable heart rate level falls between 50 beats per minute and 120 beats per minute. Since the patient's current heart rate is 130 beats per minute and falls within the indicated acceptable range, there is currently no alarm state about the patient's heart rate. This is indicated by icon 794e. Icon 794e indicates whether the patient's current heart rate is within an acceptable range. In the case where the patient's heart rate is not within an acceptable level, icon 794e can change to indicate an alarm state. For example, icon 794e can change color. As another example, when the patient's heart rhythm exceeds an acceptable level, icon 794e can flash. In some implementations, icon 794e can flash at different rates to indicate the severity of a specific alarm state. For example, the farther the patient's heart rate is from the acceptable range, the faster icon 744 flashes. Area 794f shows the time when a high heart rate alarm state is detected for the first time. As described above, the information shown in part 794 can be a combination of information received via HTTP connection and websocket connection. For example, the nature of how information is displayed and what information is to be displayed may be specified by information received via an HTTP connection. The value of the displayed information is specified by dynamic data received via a websocket connection.

[0166] Part 796 provides one or more activities of the patient. In some implementations, area 796a provides the patient's name. Area 796b displays the patient's recent activities. For example, if the patient has recently had a CT scan, area 796b can indicate that the patient has had a CT scan. Part 796 can also provide time information. That is, area 796c can display the time when the patient's activity is reported to the system or the time when the patient performs the activity. Part 796 can also include icon 796d, which enables the user to share information about the patient's activities with other users such as hospital staff, the patient's family or caregivers. In these implementations, patient information including the patient's name can be transmitted between the client device and the service agent via an HTTP connection, and real-time medical data including the patient's activities and timestamps can be updated asynchronously between the client device and the service agent via a websocket connection.

[0167] In some implementations, the patient information displayed in sections 793 and 796 can be static, while the real-time medical data displayed in sections 792, 794, and 796 can be continuously updated by the service agent. For example, the real-time medical data displayed in sections 792 and 794 and the patient activities and timestamps displayed in section 796 can be updated asynchronously by the service agent via a websocket connection. On the other hand, the static patient information displayed in section 793 and the patient name displayed in section 796 can be provided via an HTTP connection. The service agent does not update the patient information asynchronously. Therefore, the real-time medical data can be updated efficiently using a websocket connection. By using two different types of connections, the system can effectively manage patient information and real-time medical data.

[0168] Can be used as 7A to 7D Other information displayed as part of one or more user interfaces shown in the diagram may include an instantaneous health score / index for each patient. For example, for each vital parameter, the system may identify the clinical range for the parameter and indicate for each vital sign how close the patient is to being within the clinical range on a scale of, for example, 1 to 10 or 0 to 5. For example, an instantaneous health score of 0 may indicate that a particular vital sign of the patient is within the optimal range (performing well), while an instantaneous health score of 5 may indicate that the vital sign is significantly out of range (very poor). The health score template may be configured for each clinical setting. In addition, a single health score based on all vital signs may be calculated for the patient. The health score may be calculated by considering the parameter values ​​and the corresponding scores. The cumulative score may represent a health index (e.g., 0 to 2 means good, 3 to 5 means bad). Health score trends viewed over a period of time may indicate to the caregiver the overall health status of the patient over a given period of time.

[0169] The embodiments of the subject matter and functional operations described in this specification can be implemented in digital electronic circuit systems, in tangibly embodied computer software or firmware, in computer hardware including the structures disclosed in this specification and their equivalent structures, or in one or more combinations thereof. The embodiments of the subject matter described in this specification can be implemented as one or more computer programs, that is, one or more modules of computer program instructions encoded on a tangible non-transient program carrier to be executed by a data processing device or to control the operation of the data processing device. Alternatively or additionally, the program instructions can be encoded on an artificially generated propagation signal such as a machine-generated electrical, optical or electromagnetic signal, which is generated to encode information for transmission to a suitable receiver device, thereby being executed by a data processing device. The computer storage medium can be a machine-readable storage device, a machine-readable storage substrate, a random or serial access storage device, or a combination of one or more of them.

[0170] The term "data processing apparatus" refers to data processing hardware, and includes various devices, equipment and machines for processing data, including, for example, a programmable processor, a computer or multiple processors or computers. The apparatus may also be or may also include a dedicated logic circuit system, such as an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, the apparatus may optionally include code that creates an execution environment for a computer program, for example, code constituting processor firmware, a protocol stack, a database management system, an operating system, or a combination of one or more of them.

[0171] A computer program (also referred to or described as a program, software, software application, module, software module, script or code) may be written in any form of programming language including a compiled language or an interpreted language or a declarative language or a procedural language, and may be deployed in any form including as a standalone program or as a module, component, subroutine or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), may be stored in a single file dedicated to the program in question, or may be stored in multiple collaborative files (e.g., files storing one or more modules, subroutines or partial codes). A computer program may be deployed to execute on one computer or on multiple computers located at one site or distributed on multiple sites and interconnected by a communication network.

[0172] The processes and logic flows described in this specification may be performed by one or more programmable computers executing one or more computer programs to perform functions by operating on input data and generating output. The processes and logic flows may also be performed by, and the apparatus may be implemented as, a special purpose logic circuit system such as an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0173] For example, a computer suitable for executing a computer program includes, for example, a central processing unit that can be based on a general-purpose microprocessor or a special-purpose microprocessor or both, or any other type of central processing unit. Typically, the central processing unit will receive instructions and data from a read-only memory or a random access memory or both. The basic element of a computer is a central processing unit for executing or running instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include or be operably coupled to one or more large-capacity storage devices for storing data, to receive data from the one or more large-capacity storage devices or to transmit data to the one or more large-capacity storage devices or to perform the two, the one or more large-capacity storage devices being, for example, a magnetic disk, a magneto-optical disk or an optical disk. However, a computer does not need to have such a device. In addition, a computer can be embedded in another device, for example, a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver or a portable storage device such as a universal serial bus (USB) flash drive, to name a few.

[0174] Computer readable media suitable for storing computer program instructions and data include all forms of nonvolatile memory, media and storage devices, including, for example, EPROM, EEPROM and flash memory devices, magnetic disks, such as internal hard disks or removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by or incorporated in a special purpose logic circuit system.

[0175] To provide interaction with a user, embodiments of the subject matter described in this specification may be implemented on a computer having a display device, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices may also be used to provide interaction with the user: for example, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form including auditory, voice, or tactile input. In addition, the computer may interact with the user by sending documents to and receiving documents from a device used by the user, for example, by sending a web page to a web browser on a user's client device in response to a request received from the web browser.

[0176] Implementations of the subject matter described in this specification may be implemented in a computing system that includes a back-end component, such as a data server; or includes a middleware component, such as an application server; or includes a front-end component, such as a client computer with a graphical user interface or a web browser, through which a user can interact with implementations of the subject matter described in this specification; or any combination of one or more such back-end components, middleware components, or front-end components. The components of the system may be interconnected by any form or medium of digital data communication, such as a communication network. Examples of communication networks include local area networks (LANs) and wide area networks (WANs) such as the Internet.

[0177] A computing system may include clients and servers. Clients and servers are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on respective computers and having a client-server relationship to each other.

[0178] Although this specification contains many specific implementation details, these implementation details should not be interpreted as limitations on the scope of any invention or the scope that can be claimed, but as descriptions of features that can be specific to a particular embodiment of a particular invention. Certain features described in the context of different embodiments in this specification may also be implemented in a combined manner in a single embodiment. Conversely, the individual features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. In addition, although the features may be described as acting in a certain combination as described above and even initially claimed as such, in some cases, one or more features from the claimed combination may be deleted from the combination, and the claimed combination may be directed to a sub-combination or a variation of the sub-combination.

[0179] Similarly, although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in a continuous order, or that all of the operations shown be performed to achieve the desired results. In some cases, multitasking and parallel processing may be advantageous. In addition, the separation of various system modules and components in the above-described embodiments should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0180] Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. For example, the subject matter is described in the context of a scientific paper. The subject matter can be applied to other indexing efforts that add depth aspects to searches. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. In addition, the processing depicted in the accompanying drawings does not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous.

Claims

1. A real-time medical data presentation method, include: receiving, by the service agent, a first request for a web page from a client device via a Hypertext Transfer Protocol (HTTP) connection, the first request including patient information of a specific patient; In response to the first request, the service agent determines a specific webpage based on the patient information of the specific patient, the specific webpage displays a first user interface; The service agent provides the specific web page to the client device through the HTTP connection, so as to establish a websocket connection between the service agent and the client device; Establishing the websocket connection between the service proxy and the client device; receiving, by the service agent from the client device through the websocket connection, a second request for first real-time medical data, the second request identifying a medical data protocol defining one or more data attributes of the first real-time medical data; Obtaining, by the service agent, a first real-time medical data sample set from one or more data sources, the first real-time medical data sample set including corresponding values ​​of one or more data attributes of the first real-time medical data; generating the first real-time medical data based on values ​​of one or more data attributes of the first real-time medical data; as well as The service agent provides a second user interface to the client device through the websocket connection to present the first real-time medical data.

2. The real-time medical data presentation method according to claim 1, in, In response to loading the specific webpage on the client device, the specific webpage is configured to trigger the client device to establish the websocket connection between the client device and the service proxy.

3. The real-time medical data presentation method according to claim 1, in, Establishing the websocket connection between the service proxy and the client device includes: receiving, by the service agent, from the client device, a websocket connection request triggered in response to loading the specific web page on the client device; and In response to the websocket connection request, the service agent provides a websocket connection response to the client device, so as to establish the websocket connection between the service agent and the client device.

4. The real-time medical data presentation method according to claim 1, further comprising: include: The medical data is asynchronously pushed to the client device by the service agent through the websocket connection.

5. The real-time medical data presentation method according to claim 1, in, The one or more data attributes defined in the medical data protocol include at least one of an identification, a sampling rate, a plotting time, and buffer information.

6. The real-time medical data presentation method according to claim 5, in, Generating the first real-time medical data based on the values ​​of one or more data attributes of the first real-time medical data includes: identifying, by the service agent, corresponding values ​​of the identifier, the sampling rate, the plotting time, and the buffer information from the second request, the second request including corresponding values ​​of one or more data attributes of the first real-time medical data, Based on the value of the identifier, determining a specific waveform among one or more waveforms monitored in real time by the monitoring device, Based on the plotting time, the sampling rate, and the corresponding values ​​of the buffer information, the service agent writes the specific waveform into a buffer at the plotting time using the sampling rate, and The first real-time medical data is generated by the service agent based on the specific waveform written into the buffer.

7. The real-time medical data presentation method according to claim 6, in, Providing the first real-time medical data includes: The service agent reads the first real-time medical data stored in the database, and The first real-time medical data is provided to the client device by the service agent through the websocket connection.

8. The real-time medical data presentation method according to claim 1, in, The client device is a subscriber of the service broker for medical data.

9. The real-time medical data presentation method according to claim 1, in, The websocket connection is established between the service proxy and the client device using hypertext markup language HTML based communication.

10. The real-time medical data presentation method according to claim 1, in, The specific web page simultaneously displays (i) the first user interface provided from the service agent to the client device via the HTTP connection, and (ii) the second user interface presenting the first real-time medical data provided from the service agent to the client device via the websocket connection.

11. The real-time medical data presentation method according to claim 10, further comprising: include: receiving, by the service agent through the websocket connection, a third request for second real-time medical data from the client device, the third request including corresponding values ​​of one or more data attributes of the second real-time medical data; receiving, by the service agent, a second set of real-time medical data samples from the one or more data sources; generating the second real-time medical data according to the second real-time medical data sample set based on values ​​of one or more data attributes of the second real-time medical data; as well as The second user interface is updated by the service agent to present the second real-time medical data instead of the first real-time medical data while maintaining the first user interface.

12. A real-time medical data presentation system, include: One or more computers and one or more storage devices having stored thereon instructions operable when executed by the one or more computers to cause the one or more computers to perform operations comprising: receiving, by the service agent, a first request for a web page from a client device via a Hypertext Transfer Protocol (HTTP) connection, the first request including patient information of a specific patient; In response to the first request, the service agent determines a specific webpage based on the patient information of the specific patient, the specific webpage displays a first user interface; The service agent provides the specific web page to the client device through the HTTP connection, so as to establish a websocket connection between the service agent and the client device; Establishing the websocket connection between the service proxy and the client device; receiving, by the service agent from the client device through the websocket connection, a second request for first real-time medical data, the second request identifying a medical data protocol defining one or more data attributes of the first real-time medical data; Obtaining, by the service agent, a first real-time medical data sample set from one or more data sources, the first real-time medical data sample set including corresponding values ​​of one or more data attributes of the first real-time medical data; generating the first real-time medical data based on values ​​of one or more data attributes of the first real-time medical data; and The service agent provides a second user interface to the client device through the websocket connection to present the first real-time medical data.

13. The real-time medical data presentation system according to claim 12, in, In response to loading the specific webpage on the client device, the specific webpage is configured to trigger the client device to establish the websocket connection between the client device and the service proxy.

14. The real-time medical data presentation system according to claim 12, in, Establishing the websocket connection between the service proxy and the client device includes: receiving, by the service agent, from the client device, a websocket connection request triggered in response to loading the specific web page on the client device; and In response to the websocket connection request, the service agent provides a websocket connection response to the client device, so as to establish the websocket connection between the service agent and the client device.

15. The real-time medical data presentation system according to claim 12, in, The one or more data attributes defined in the medical data protocol include at least one of an identification, a sampling rate, a plotting time, and buffer information.

16. The real-time medical data presentation system according to claim 15, in, Generating the first real-time medical data based on the values ​​of one or more data attributes of the first real-time medical data includes: identifying, by the service agent, corresponding values ​​of the identifier, the sampling rate, the plotting time, and the buffer information from the second request, the second request including corresponding values ​​of one or more data attributes of the first real-time medical data, Based on the value of the identifier, determining a specific waveform among one or more waveforms monitored in real time by the monitoring device, Based on the plotting time, the sampling rate, and the corresponding values ​​of the buffer information, the service agent writes the specific waveform into a buffer at the plotting time using the sampling rate, and The first real-time medical data is generated by the service agent based on the specific waveform written into the buffer.

17. The real-time medical data presentation system according to claim 12, in, The specific web page simultaneously displays (i) the first user interface provided from the service agent to the client device via the HTTP connection, and (ii) the second user interface presenting the first real-time medical data provided from the service agent to the client device via the websocket connection.

18. The real-time medical data presentation system according to claim 17, wherein the operation further comprises: include: receiving, by the service agent through the websocket connection, a third request for second real-time medical data from the client device, the third request including corresponding values ​​of one or more data attributes of the second real-time medical data; receiving, by the service agent, a second set of real-time medical data samples from the one or more data sources; generating the second real-time medical data according to the second real-time medical data sample set based on values ​​of one or more data attributes of the second real-time medical data; as well as The second user interface is updated by the service agent to present the second real-time medical data instead of the first real-time medical data while maintaining the first user interface.

19. A non-transitory storage device storing instructions that, when executed by one or more computers, are operable to cause the one or more computers to perform operations, the operations include: receiving, by the service agent, a first request for a web page from a client device via a Hypertext Transfer Protocol (HTTP) connection, the first request including patient information of a specific patient; In response to the first request, the service agent determines a specific webpage based on the patient information of the specific patient, the specific webpage displays a first user interface; The service agent provides the specific web page to the client device through the HTTP connection, so as to establish a websocket connection between the service agent and the client device; Establishing the websocket connection between the service proxy and the client device; receiving, by the service agent from the client device through the websocket connection, a second request for first real-time medical data, the second request identifying a medical data protocol defining one or more data attributes of the first real-time medical data; Obtaining, by the service agent, a first real-time medical data sample set from one or more data sources, the first real-time medical data sample set including corresponding values ​​of one or more data attributes of the first real-time medical data; generating the first real-time medical data based on values ​​of one or more data attributes of the first real-time medical data; as well as The service agent provides a second user interface to the client device through the websocket connection to present the first real-time medical data.

20. The non-transitory storage device according to claim 19, in, In response to loading the specific webpage on the client device, the specific webpage is configured to trigger the client device to establish the websocket connection between the client device and the service proxy.

Images