Methods and systems for integrating continuous analyte monitoring

Abstract

A method of displaying continuous analyte data including receiving analyte data through a communication interface, wherein the analyte data comprises a plurality of analyte readings; determining a numerical value corresponding to a current analyte level based on the analyte data; and displaying the numerical value on a display screen.

Description

METHODS AND SYSTEMS FOR INTEGRATING CONTINUOUS ANALYTE MONITORINGCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to and the benefit of U.S. Provisional Application No. 63 / 701,180, filed September 30, 2024 entitled “Methods And Systems For Integrating Continuous Analyte Monitoring,” and to U.S. Provisional Application No. 63 / 701,206, filed September 30, 2024 entitled “Methods And Systems For Integrating Continuous Analyte Monitoring,” the disclosures of each of which applications are incorporated herein by reference in their entireties.FIELD

[0002] The subject matter of this disclosure generally relates to systems, devices, and methods for improving diagnosis systems using data from continuous analyte monitoring systems and providing for customizable visual elements, alerts, and notifications. More specifically, this disclosure relates to improved integration of continuous analyte monitors with existing equipment to implement a continuously connected graphical user interface system for dynamically generating alerts and notifications based on continuous analyte data.BACKGROUND

[0003] This disclosure relates to the field of continuous analyte monitoring in the context of a distributed monitoring and / or diagnosis system that interconnects different diagnosis devices, such as patient devices, health care provider devices, electronic health record (EHR) systems, remote monitoring systems, and caregiver devices. In some embodiments, the distributed diagnosis system provides continuous lactate monitoring and utilizes continuous lactate data within the system. The use of continuous analyte data enables the real-time monitoring and notification that provides improved monitoring, diagnostic and communication capabilities between the interconnected devices of the diagnosis system.

[0004] Currently, lactate is measured using blood draws, typically in a hospital or other health care setting. These measurements are often reactive in nature because they are usually taken in response to patient issues (e.g., a patient presenting with certain symptoms) or at a given point in time. This results in analysis of lactate levels and any potential corresponding treatment just before or as a patient’s medical condition deteriorates. This is because typical methodologies do not constantly monitor patient conditions and use the monitored information to predict potential patient outcomes, which could lead to earlier identification of deterioration and earlier administration of preventative and / or curative treatment.

[0005] Lactate is an analyte in which in vivo levels may vary in response to numerous environmental or physiological factors including, for example, eating, physiological stress, exercise, sepsis or septic shock, heart failure and liver disease, and the like. In the case of chronic, ongoing conditions, such as heart failure or liver disease, periodic laboratory measurements of lactate levels may be sufficient to determine whether these conditions are increasing or decreasing in severity, and / or if the patient is responding to treatment. Other lactate-altering conditions may be episodic in nature, such as sepsis or septic shock, in which case lactate levels may fluctuate very rapidly and irregularly. Other use-cases in which continuous analyte information, including lactate, may be used are for predicting patient outcomes for patients in a hospital setting or in a home setting, predicting the onset of disease (e.g., sepsis), enabling the early detection of disease, and monitoring patients post-surgery. Conventional laboratory methodologies may be ill suited to monitor lactate levels in such instances. Namely, lactate levels may have changed several times between successive measurements, and an abnormal lactate level may be completely missed in such instances, thereby leading to potentially incorrect diagnoses. In the case of rapidly changing lactate levels, it can be desirable to measure an individual's lactate levels continuously to detect the onset of a lactate spike, such as through using an implanted in vivo lactate sensor. Even if a lactate spike is observed when measuring lactate levels with periodic laboratory measurements, there often is no possibility of taking proactive actions to alleviate or remediate a particular condition leading to the enhanced lactate levels. This can have significant consequences for a patient’s health and well-being in some cases.

[0006] Current existing computing devices, such as bedside multiparameter monitors used in the medical setting, are not able to receive, process, or display continuous lactatedata. Thus, even if continuous lactate data from a patient is present, it is not able to be integrated in a visual manner in a medical setting. Therefore, there exists a need to integrate continuous lactate data into equipment like existing bedside multiparameter monitors. This integration should also address the integration of alarms, notifications, and analysis based on the lactate data into the bedside multiparameter monitor. There also exists a need to update the communication capabilities, security, and interfaces of existing computing devices to accommodate and display continuous analyte data in combination with existing patient health data.BRIEF SUMMARY OF THE INVENTION

[0007] This disclosure describes continuous analyte monitoring as an exemplary implementation for a continuous monitoring system within a distributed diagnostic system. The present disclosure describes a transmitter device that is configured to facilitate data transfer between devices that were not capable of communicating with each other: a bedside multiparameter monitor device and a continuous analyte sensor device. The transmitter device is configured to address data compatibility issues (e.g., raw sensor data from the continuous analyte sensor device, proprietary sensor data from the continuous analyte sensor device) as well as security concerns (e.g., protecting patient data privacy), while enabling wireless data receiving functionality at the bedside multiparameter monitor device.

[0008] The present disclosure further describes modifications to the user interfaces of devices, which previously were not configured to communicate with or display data from a continuous analyte monitoring system. The user interfaces are configured to receive processed analyte data, e.g., from transmitter device, and display the processed analyte data in configurations associated with one or more other legacy information elements of the bedside multiparameter monitor (e.g., heart rate, oxygen saturation, blood pressure). In some embodiments, the user interfaces are configured to display the patient health information at different time scales to accommodate for the different frequencies at which patient data is received from the various sensors connected to the bedside multiparameter monitor.

[0009] However, the systems and methods of receiving, processing, and displaying the lactate data are generally applicable to other forms of analyte data. Thus, other analytesmay be utilized, either in combination with lactate (e.g., a dual sensor continuous monitoring system) or independently on its own. Other examples of analytes that can be utilized within this distributed diagnostic system include, but are not limited to, glucose and ketone.

[0010] In an embodiment, a method of displaying continuous analyte data on a patient monitoring device, wherein the patient monitoring device is connected to a multiparameter monitor and a legacy monitoring device, includes receiving, via the multiparameter monitor by the patient monitoring device, analyte data from an analyte sensor operably connected to a patient through a communication interface, wherein the analyte data comprises a plurality of analyte readings; receiving, by the patient monitoring device, patient medical data from a medical monitoring device operable to determine the patient medical data from a patient; determining a numerical value corresponding to a current analyte level based on the analyte data; generating a first user interface component comprising the patient medical data; generating a second user interface component comprising the numeral value; and displaying the first user interface component and the second user component on a display screen of the patient monitoring device.

[0011] In a further embodiment, the method includes plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data over a time period; and displaying the graph on the display screen, wherein the time period on the graph is different than a time period used to display at least one other patient health data on the display.

[0012] In a further embodiment, the method includes displaying a plurality of time periods for the graph on the display screen; receiving a user selection of one of the plurality of time periods; plotting the plurality of analyte readings on a second graph using the selected time period; and displaying the second graph.

[0013] In a further embodiment, the method includes determining a rate of change of a value of the analyte data; and displaying a trend arrow that graphically indicates the rate of change on the display screen.

[0014] In a further embodiment, the method includes altering an orientation of the trend arrow to correspond to a change in the rate of change.

[0015] In a further embodiment, the method includes displaying a numerical value corresponding to the rate of change on the display screen.

[0016] In a further embodiment, the method includes displaying an alarm limit corresponding the lactate data on the display screen; receiving a user input related to the alarm limit; and altering the displayed alarm limit based on the user input.

[0017] In a further embodiment, the method includes receiving an input from a user corresponding to the analyte data; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

[0018] In a further embodiment, the method includes receiving an input form a user corresponding to a portion of the graph; and displaying a lactate value that corresponds to the portion of the graph.

[0019] In a further embodiment, the method includes displaying an alarm indication associated with the analyte data on the display screen; receiving an input from a user corresponding to the alarm indication; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

[0020] In an embodiment, a non-transitory computer readable medium includes instructions that, when executed on a processor of a patient monitoring device that is connected to a multi-parameter monitor and a legacy monitoring device, perform the steps of: receiving, via the multi -parameter monitor by the patient monitoring device, analyte data through a communication interface from an analyte sensor operably connected to a patient, wherein the analyte data comprises a plurality of analyte readings; receiving, by the patient monitoring device, patient medical data from a medical monitoring device operable to determine the patient medical data from a patient; determining a numerical value corresponding to a current analyte level based on the analyte data; and generating a first user interface component comprising the patient medical data; generating a second user interface component comprising the numeral value; and displaying the first user interface component and the second user component on a display screen of the patient monitoring device.

[0021] In a further embodiment, the instructions include plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data over a time period; and displaying the graph on the display screen, wherein the time period on the graph is different than a time period used to display at least one other patient health data on the display.

[0022] In a further embodiment, the instructions include displaying a plurality of time periods for the graph on the display screen; receiving a user selection of one of the plurality of time periods; plotting the plurality of analyte readings on a second graph using the selected time period; and displaying the second graph.

[0023] In a further embodiment, the instructions include determining a rate of change of a value of the analyte data; displaying a trend arrow that graphically indicates the rate of change on the display screen.

[0024] In a further embodiment, the instructions include altering an orientation of the trend arrow to correspond to a change in the rate of change.

[0025] In a further embodiment, the instructions include displaying a numerical value corresponding to the rate of change on the display screen.

[0026] In a further embodiment, the instructions include displaying an alarm limit corresponding the lactate data on the display screen; receiving a user input related to the alarm limit; and altering the displayed alarm limit based on the user input.

[0027] In a further embodiment, the instructions include receiving an input from a user corresponding to the analyte data; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

[0028] In a further embodiment, the instructions include receiving an input form a user corresponding to a portion of the graph; and displaying a lactate value that corresponds to the portion of the graph.

[0029] In a further embodiment, the instructions include displaying an alarm indication associated with the analyte data on the display screen; and receiving an input from a user corresponding to the alarm indication; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

[0030] Certain aspects of the disclosure have other steps or elements in addition to or in place of those mentioned above. The steps or elements will become apparent to those skilled in the art from a reading of the following detailed description when taken with reference to the accompanying drawings.BRIEF DESCRIPTION OF THE DRAWINGS / FIGURES

[0031] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present disclosure and, together with the description, further serve to explain the principles thereof and to enable a person skilled in the pertinent art to make and use the same.

[0032] FIG. 1 is an exemplary system and data flow diagram of a continuous lactate monitor (“CLM”) system, according to some embodiments.

[0033] FIG. 2 is an exemplary system data flow diagram of a CLM system, according to some embodiments.

[0034] FIG. 3 is an exemplary data flow diagram of a CLM system, according to some embodiments.

[0035] FIG. 4 is an exemplary data flow diagram of a CLM system, according to some embodiments.

[0036] FIG. 5 is an exemplary system diagram of a transmitter for a CLM system, according to some embodiments.

[0037] FIG. 6 is an exemplary process flow for activation of a CLM system, according to some embodiments.

[0038] FIG. 7 is an exemplary data flow diagram of a CLM system, according to some embodiments.

[0039] FIG. 8 is an exemplary data flow diagram of a CLM system, according to some embodiments.

[0040] FIG. 9 is an exemplary data flow diagram of a CLM system, according to some embodiments.

[0041] FIG. 10 is an exemplary system diagram of a transmitter for a CLM system, according to some embodiments.

[0042] FIG. 11 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0043] FIG. 12 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0044] FIG. 13 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0045] FIG. 14 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0046] FIG. 15 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0047] FIG. 16 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0048] FIG. 17 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0049] FIG. 18 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0050] FIG. 19 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0051] FIG. 20 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0052] FIG. 21 is an exemplary user interface with a lactate user interface component for a computing device, according to some embodiments.

[0053] In the drawings, like reference numbers generally indicate identical or similar elements. Additionally, generally, the left-most digit(s) of a reference number identifies the drawing in which the reference number first appears.DETAILED DESCRIPTION

[0054] Reference will now be made in detail to systems and methods illustrated in the accompanying drawings. When a particular feature, structure, or characteristic is described in connection with an example, it is submitted that it is within the knowledge of one skilled in the art to affect such a feature, structure, or characteristic in connection with other examples whether or not explicitly described.

[0055] The following discussion focuses on continuous lactate monitoring devices in communication with other patient monitoring devices, such as a bedside multiparameter monitor. Accordingly, the embodiments below are discussed with respect to lactate, but the described features may also apply to glucose and ketone monitoring using, for example, a continuous glucose monitoring device, a continuous ketone monitoringdevice, and a dual-sensor (e.g., glucose-ketone, glucose-lactate, ketone-lactate) continuous analyte monitoring device.

[0056] Lactate is a bi-product of human metabolism that is present in the human body. Lactate levels that exceed predetermined ranges can indicate a variety of different abnormal conditions in a patient. Current practice is for lactate to be measured using a standard blood draw in a healthcare setting, which provides only a single measurement at one point in time. These measurements are also usually reactive in that the lactate measurement is usually ordered when the patient is already in the healthcare setting with other symptoms. This means that elevated lactate measurements are typically not useful in predicting therapy needs in a patient in advance. Further, the single point measurement cannot capture transient fluctuations in lactate. Finally, the limited lactate data reduces the ability to leverage data analysis tools and alerts that can improve patient outcomes by helping Health Care Professionals (“HCPs”) better understand a patient’s metabolic health. Thus, there exists a need for improved lactate monitoring and data analysis.

[0057] Continuous lactate monitoring systems employ an insertable or implantable sensor, which detects and monitors blood lactate levels. As such, these systems can be referred to as "in vivo" monitoring systems. The sensor can be part of the continuous lactate monitor that resides on the body of the user. The monitoring system can contain the electronics and power supply that enable and control the lactate sensing. Typically, an applicator is employed to insert the sensor in the body of the patient. Transferring the continuous lactate data from the sensor to the bedside multiparameter monitor has multiple benefits, including allowing the HCP to monitor the patient’s lactate levels in real-time, enabling alarms and notifications based on changing lactate values, and improving analysis of patient health by allowing for lactate values to be considered by the HCP alongside other vital sign parameters.

[0058] The invention relates to a system that includes a continuous lactate monitor connected to the patient. The continuous lactate monitor is configured to repeatedly and periodically record the patient’s lactate levels. The lactate data is transmitted from the continuous lactate monitor to an external transmitter that acts as an adaptor to pass that data to a connected computing device. The computing device can be an existing device and includes a processor and memory, the memory storing instructions that when executed by the processor cause the processor to receive lactate data from the continuous lactate monitor. Further instructions cause the processor to analyze the lactate data tocompare the data to an alarm limit and cause the processor to transmit a notification and / or an alert if the lactate data exceeds the alarm limit.

[0059] Benefits of this disclosure include enabling communication of continuous analyte data to external devices, such as a bedside multiparameter monitor in a hospital setting, that were not previously capable of receiving and processing that data due to data compatibility and security concerns. Such external devices are typically connected to other types of monitoring devices that provide real-time patient data, such as heart rate, electrocardiogram data, blood pressure data, respiratory data, and blood oxygen saturation (SpCh) data. Other types of patient data, such as their analyte data, were not previously accessible to external devices due to communication and compatibility constraints. For example, continuous analyte sensor devices typically are only configured to communicate with certain external devices, such as a reader device, in order to protect patient data.

[0060] The present disclosure provides a transmitter to continuously analyze lactate data to identify trends or transient variations in the lactate data. This can result in abnormal conditions being identified earlier, which can improve patient outcomes by enabling earlier treatment initiation. Further, as will be discussed below, different alerts and alarms based on data analysis can also identify conditions that would not be apparent with a single reading. These benefits can be integrated into an existing system, such as an existing hospital monitoring system, which reduces implementation costs.

[0061] FIG. 1 is a system diagram of a continuous lactate monitoring system 100. In some embodiments, system diagram may include other continuous analyte monitoring systems in addition to or instead of continuous lactate monitoring system 100. For example, other continuous analyte monitoring may include monitoring glucose and ketone. A continuous lactate monitor 110 is configured to be connected to a patient for measuring patient lactate levels. As discussed below, the continuous lactate monitor 110 may be removably disposed on the patient’s skin. Continuous lactate monitor 110 is designed to repeatedly measure and transmit patient lactate data at either regular or irregular intervals. For example, continuous lactate monitor 110 can repeatedly measure and transmit lactate levels at a predetermined interval, such as every minute, five minutes, or ten minutes. This frequency can be changed by a suitable command received at continuous lactate monitor 110. Continuous lactate monitor 110 may also measure lactate “on demand.” On demand measurements are based on continuous lactate monitor 110 receiving an instruction to measure lactate, for example from a separate device operatedby user as discussed below. Continuous lactate monitor 110 includes suitable processing and memory capability to record and store the lactate data readings as required.

[0062] Continuous lactate monitor 110 also includes a transmitter 112 that enables continuous lactate monitor 110 to communicate with a remote computing device 120 using a multi-parameter monitor module 122. In some embodiments, remote computing device 120 is not capable of communicating with continuous lactate monitor 110 without multi-parameter monitor module 122. In some embodiments, multi-parameter monitor module 122 may be integrated as in internal component of remote computing device 120. In some embodiments, multi-parameter monitor module 122 may be implemented as a removable component and configured to connect to the remote computing device 120 via a wired connection, such as through a port (e.g., universal serial bus (USB)), a docking station connected to remote computing device 120, or a rack attached to the remote computing device 120. Transmitter 112 and multi-parameter monitor module 122 may be configured to communicate wirelessly through a suitable wireless communication protocol, such as Bluetooth, Bluetooth Low Energy, WiFi, NFC, for example. In some embodiments, multi-parameter monitor module 122 can communicate on multiple wireless communication protocols, such as both Bluetooth Low Energy, WiFi, and NFC. In addition or alternatively, transmitter 112 and multi -parameter monitor module 122 may include a wired connection.

[0063] Remote computing device 120 can include any number of computing devices that are physically separate from continuous lactate monitor 110. For example, remote computing device 120 can include one or more reader devices 124 (see FIG. 3), a gateway (e.g., a Bluetooth gateway), one or more remote servers 126, and / or one or more display devices 128, such as a patient bedside multiparameter monitoring device, (see FIG. 4) each having suitable processor and memory capabilities. Reader devices 124, remote servers 126, and display devices 128 may be directly connected to or physically incorporate multi-parameter monitor module 122, or may be indirectly connected to the multi -parameter monitor module 122, for example by other suitable data transmitters, computing devices, servers, or other similar structures. Reader devices 124 may be a dedicated device for interfacing with and controlling the operation of continuous lactate monitor 110, or in some embodiments, reader devices 124 may be a separate computing device running an application that allows the computing device to interface and control operation of continuous lactate monitor 110. For example, reader device 124 may be amobile phone or tablet running an application. Remote servers 126 can be any physically separated computing device that is configured to send and receive data using a suitable data network. Display devices 128 may be devices that can receive and display lactate data. These devices generally cannot control operation of continuous lactate monitor 110. An example would include an existing bedside multiparameter monitor. It should be noted that reader devices 124 may also be considered display devices 128 if they include display capabilities. Any of these reader devices 124, remote servers 126, and display devices 124 can include a display that can be used to visualize lactate data and alarm notifications. The reader devices 124 and remote servers 126 can include an input mechanism such as a keyboard or touchscreen to input commands.

[0064] FIG. 4 depicts a data flow diagram of a distributed diagnostic system 400 using continuous lactate data. The distributed diagnostic system is configured with real-time alarms capability based on its receipt of continuous lactate data from multiple continuous lactate sensors. Because it has access to continuous lactate data from multiple sources (e.g., different patients, different hospitals), the distributed diagnostic system is configured to detect trends and tracks patterns for identifying and predicting disease progression based on the continuous lactate data. The distributed diagnostic system includes legacy devices, such as reader device 124 (for example, a bedside monitor) that is designed to reliably and securely transmit and receive lactate measurement data from continuous lactate monitor 110 via multi-parameter monitor module 122. The combination of reader device 124 and multi-parameter monitor module 122 enables reader device 124 to receive proprietary lactate data (e.g., from continuous lactate monitor 110), generate customized visual elements for displaying the lactate data, and configure alerts and notifications associated with the lactate data that can be transmitted to digitally connected devices.

[0065] In some embodiments, the multi -parameter monitor module 122 configures reader device 124 with additional capabilities for receiving and displaying lactate data in combination with other legacy patient information, such as heart rate, oxygen saturation, and blood pressure. The graphical user interfaces of reader device 124 are modified to display an additional lactate user interface component in relation to legacy patient information and, in some embodiments, different time ranges or scales then the legacy patient information. Where legacy patient information such as heart rate and oxygensaturation are provided and displayed continuously in real-time based on patient monitoring data, continuous lactate data may be provided at discrete intervals.

[0066] Incorporating lactate data into reader device 124 improves the functionality of such devices because the use of continuous lactate data provides better adherence to disease (e.g., sepsis) protocols. Real-time data eliminates blind spots within distributed diagnostic systems, detects deterioration and accelerates treatment decisions, leading to better patient outcomes. This detection can be supported by third party monitoring services 102 (see FIG. 3), which can receive the lactate data and continuously monitor it for issues. The third-party monitoring service 102 can, in turn, contact the patient, caregiver, and / or HCP directly to alert them of the issue. Note that this communication can be facilitated by the lactate monitoring application running on remote computing devices 120, which can include messaging services to enable remote computing device 120 to facilitate communication between users. In addition or alternatively, messaging can be accomplished by other suitable techniques (e.g., phone, email, text messaging).

[0067] As seen in FIGS. 2 and 3, for example, multi-parameter monitor module 122 acts as an adapter that enables communication between continuous lactate monitor 110 and one or more existing remote computing device(s) 120. Examples of an existing remote computing device 120 include a multi -parameter monitor module 122 such as a bedside patient monitor and a remote interface (e.g., such as a server) that provides an interface to backend systems such as cloud storage and electronic health record (EHR) systems. In these embodiments, multi-parameter monitor module 122 includes at least two interfaces: one that communicates wirelessly with continuous lactate monitor 110 and one that communicates with remote computing device 120. This second interface can use one or more suitable data communication protocols, such as a wired connection (e.g., a universal serial bus (USB) connection) and / or a wireless connection (e.g., a WiFi connection). In this way, a computing device that is not designed to interface with continuous lactate monitor 110 can be leveraged to become reader devices 124 or display devices 128 without requiring replacement of the existing computing device. For example, multiparameter monitor module 122 can be plugged into an existing patient bedside multiparameter monitor, which can then be used to access lactate data from continuous lactate monitor 110 via multi-parameter monitor module 122. A single multi-parameter monitor module 122 may be sufficient to pass lactate data in a hospital setting because of the existing data network in place. For example, patient bedside multiparameter monitorsare already configured to share data with a central monitoring station and / or the patient’s electronic health record. Thus, multi-parameter monitor module 122 need only be integrated with the corresponding patient bedside multiparameter monitor to allow sharing of the lactate data with other hospital computing systems such as the central monitoring station, which is the data flow illustrated by the 124a, 126a and 128a elements in FIG. 4.

[0068] An example of this can be seen in FIG. 7, where app-enabled device 123 connects to a remote server 126, which in turn passes the data on to multiple other reader devices 124, including a tablet running an application, a computer accessing a web-based application, and a computer at a nurse’s station. In the embodiment of FIG. 7, multiparameter monitor module 122 takes the form of an application running on a mobile device. Multi-parameter monitor module 122 may act only as a pass-through device for any lactate data, and will not retain any of that data in any memory once the data has been forwarded. Note that multi-parameter monitor module 122 can simultaneously interface with multiple remote computing devices 120, including through the use of different communication protocols (e.g., a wired connection and a wireless connection). An example of this configuration is shown in FIG. 9, with multi-parameter monitor module 122 connecting to a reader device 124 and a remote server 126, each of which is in turn connected to other remote computing devices 120. These multiple network connections can be facilitated by continuous lactate monitor 110, which in some embodiments can maintain multiple data connections, potentially through the same or different wireless communication protocols, such as Bluetooth and / or WiFi. FIG. 8 shows continuous lactate monitor 110 connected to a network hub 129 that provides data connection to other data networks. Continuous lactate monitor 110 is also connected through multiparameter monitor module 122 to two separate remote computing devices 120, here a reader device 124 and a remote server 126.

[0069] As seen in FIG. 5, multi-parameter monitor module 122 can be formed with a housing 501 that contains the electronic components needed for multi-parameter monitor module 122 to function. Housing 501 can be environmentally sealed to a suitable standard, such as being resistant to liquid splashing. This includes a processor 502, a memory 504 operably connected to processor 502, a first network interface 504, and a second network interface 506, both operably connected to processor 502. Each of network interfaces 504 and 506 may include multiple communication interfaces. For example, firstnetwork interface 504 may include a Bluetooth Low Energy interface, NFC, and a WiFi interface, while second network interface 506 may include a universal serial bus interface and an Ethernet interface. A power source 508 is also included in housing 501. In some embodiments power source 508 is an external power interface, such as a socket for an external power adapter. In some embodiments, multi-parameter monitor module 122 can be powered by an external power source, such as the bedside multiparameter monitor. In some embodiments, the external power source may be from the existing computing device. In some embodiments, multi -parameter monitor module 122 can include an internal power source, such as a battery, that allows for multi-parameter monitor module 122 to be moved while active (without connection to an external power source). This can be useful if the existing computing device it itself portable, which can be the case with devices such as bedside multiparameter monitors. Multi-parameter monitor module 122 can be configured with suitable attachment devices, such as straps, magnets, clips, or fasteners that allow it to be fixed to an existing computing device. In some embodiments, multi -parameter monitor module 122 can be shaped to be received into an existing socket or recess that is part of an existing computing device for the same purpose.

[0070] In some embodiments, multi-parameter monitor module 122 can act as a standalone wireless monitor for continuous lactate monitor 110. This is useful in settings where display device 128 (e.g., a bedside multiparameter monitor) is not available and a display for sensor data is desired. Multi-parameter monitor module 122 may have a suitable display to achieve this goal, such as a touchscreen display 509 fixed in or on housing 501. IN some embodiments, the display (e.g., touchscreen display 509) may be detachably coupled to multi -parameter monitor module 122 and be capable of functioning independently of multi-parameter monitor module 122. In these embodiments the display can be detached from multi-parameter monitor module 122 and used to monitor data and system status via a suitable wireless communication path, for example via a remote server or cloud connection. In these embodiments the undetached portion of multi-parameter monitor module 122 can stay connected to the relevant device (e.g., display device 128) and continue to receive data and upload that data for use by the detached portion using a suitable wireless communication path. Multi-parameter monitor module 122 can also have status display lights to display system status, for example power, connection to continuous lactate monitor 110, and connection to the existing computing device. Multiparameter monitor module 122 can, as discussed above, also send the data into a suitablewireless network. In some embodiments multi -parameter monitor module 122 can be an application that is operating on an existing smartphone, tablet, reader, or other mobile computing device. In any of these embodiments, multi-parameter monitor module 122 (or portions thereof like the display) can continue to display the alarms discussed in other portions of this disclosure when it is being used independently.

[0071] Multi-parameter monitor module 122 can be built to a common standard for existing data ports, such as a common network interface standard. In some embodiments there may be one or more adapter cables or devices 122a that physically and electrically adapt multi-parameter monitor module 122 to match the specifications for a specific existing computing device (seen, for example, in FIG. 10). Multi -parameter monitor module 122 can also be built to insert into a docking station on a monitor. In some embodiments multi-parameter monitor module 122 may format the lactate data into a compatible format before passing it onwards to the existing computing device. In some embodiments this formatting may be in addition to software that is loaded onto the existing computing device to help display the lactate data. In some embodiments external transmitter may be configured to function with multiple different existing computing devices.

[0072] Multi-parameter monitor module 122 may be configured to approve continuous lactate monitor 110 to be able to receive data packets from continuous lactate monitor 110, for example, over Bluetooth. Multi-parameter monitor module 122 may be configured to communicate with a single continuous lactate monitor 110. In addition or alternatively, multi -parameter monitor module 122 may be configured to communicate with multiple continuous lactate monitors 110 concurrently.

[0073] In some embodiments, multi-parameter monitor module 122 can be used to activate and pair with continuous lactate monitor 110. This may be accomplished wirelessly through one of the wireless interfaces of multi -parameter monitor module 122 (e.g., NFC). This process can also associate a specific continuous lactate monitor 110 with a specific multi-parameter monitor module 122, which can occur through transmission of a specific identifying and associating information to or from multiparameter monitor module 122 and continuous lactate monitor 110. Note that this process can occur repeatedly to activate and pair multiple continuous lactate monitors 110 with a specific multi-parameter monitor module 122. Multi-parameter monitor module 122 can also be used to synchronize a previously installed continuous lactate monitor 110. This isuseful if a patient is being moved to a new location with a different multi-parameter monitor module 122. The activation process with the new multi-parameter monitor module 122 can allow the existing continuous lactate monitor 110 to send data to the correct multi-parameter monitor module 122, as well as associate that data with updated location information. In some embodiments, activation can be initiated by proximity detection of continuous lactate monitor 110 to multi-parameter monitor module 122. For example, multi-parameter monitor module 122 may detect when continuous lactate monitor 110 comes within a predetermined distance and begin the activation process. This can be facilitated by making multi-parameter monitor module 122 portable using the techniques discussed above (e.g., internal battery power and releasable clip mounting), which allows multi-parameter monitor module 122 to be brought to continuous lactate monitor 110 after application to a user. Activation may also be performed using an authorized reader device 124 that may be installed with an application that allows activation of the monitor and receiving data and alerts from the continuous lactate monitor 110. Activation may be a two-way communication between the continuous lactate monitor 110 and the application. Once continuous lactate monitor 110 has been applied and activated, it must then be associated to a patient’s identity, in order for the lactate data to be tied to a specific patient.

[0074] After the continuous lactate monitor 110 has warmed up post-activation and is ready to transmit lactate data, individual data packets may be transmitted to multiparameter monitor module 122. In some embodiments multi-parameter monitor module 122 can transmit data during warm up of continuous lactate monitor 110, which can be beneficial for diagnostic purposes. Multi-parameter monitor module 122 may be located within Bluetooth communication range of the continuous lactate monitor 110. Individual data packets may contain (at a minimum) measurement value, sensor serial number, and time stamp. Individual data packets may be transmitted at a predetermined frequency (e.g., once every one minute). Note that individual remote computing devices 120 can each have their own customized frequency at which they receive data. This customized frequency may differ from the data reception frequency from continuous lactate monitor 110. This customized frequency may also be modified based on various factors, including patient condition. For example, if a patient’s condition is stable, the frequency may be reduced to reduce the data transmission requirements. If a patient condition is deteriorating, the frequency may be increased to ensure adequate coverage of the patient’slactate measurements. This change in frequency can be manually input by an HCP or other user, or may be automatically updated based on lactate data analysis using techniques discussed below.

[0075] Once sensor data (from a single monitor or from multiple monitors simultaneously) is received by remote computing device 120, it can send the data to downstream locations, such as other remote computing devices. The remote computing device 120 can send the sensor data to downstream locations over one or more wired and / or wireless communication methods (e.g., Wi-Fi, cellular, radio frequency). Examples of other remote computing devices include a cloud server (i.e., cloud data management (“DM”) account), an on-premise server (i.e., on-premise DM account), a hospital cloud server, hospital on-premise server, and / or other cloud or on-premise server.

[0076] In addition to sending data over a wired or wireless connection into the monitor, multi-parameter monitor module 122 can also be an internet-connected device with the ability to send data into a wireless network using Wi-Fi or other communication mechanisms. This is in addition to communication with continuous lactate monitor 110 and the existing computing device. In these embodiments multi-parameter monitor module 122 can be configured to communicate to a wireless network through configuration by a separate computing device, such as a mobile phone or tablet running a specific application. This can provide benefits by allowing the lactate data to be passed both locally (into the existing computing device) and into a remote server or the cloud without requiring the data to be passed through the existing computing device.

[0077] Multi-parameter monitor module 122 can have memory that can store lactate data. In some embodiments, multi-parameter monitor module 122 may be able to store historic lactate data. This can be useful if, for example, multi-parameter monitor module 122 loses connection with other computing devices. In this situation, multi-parameter monitor module 122 can save the historic data and then upload when a connection is reestablished. This capability can also be useful because it can allow multi-parameter monitor module 122 to independently determine if an alarm condition is met based on the data stored. This is useful in situations of lost connection, and also in situations where multi-parameter monitor module 122 is being used in a standalone mode independent from another computing device. Further detail regarding alarms is discussed below.

[0078] As discussed above, there may be multiple remote computing devices 120 that are able to receive lactate data from continuous lactate monitor 110. FIGS. 3 and 4 show anexample of continuous lactate monitor 110 being connected to several reader devices 124, remote servers 126 (FIG. 4), and display devices 128 via suitable data transmission networks. Some examples of reader devices 124 include existing patient monitors, mobile phones, tablets, or centralized monitoring systems. Examples of display devices 128 includes computing devices such as computers, mobile phones, or tablets belonging to an HCP or third party service. The lactate data can also be transmitted directly to the patient’s electronic health record for storage and access purposes. This system allows for increased flexibility and continuity in accessing patient data because different HCPs who have appropriate data access can review the patient’s lactate data on their own reader device 124 as needed. This flexibility extends to situations where the patient starts lactate monitoring at home and then moves to a healthcare facility because the data from home is maintained and can be accessed at a later time at the healthcare facility. The opposite situation is also a benefit of this system because the HCP can maintain continuity of lactate monitoring of the patient after discharge from a hospital back to a home environment. Note that as shown in FIG. 3, there can be multiple pathways for the lactate data to be received by various computing devices 120, including via several different external transmitters 122 and / or reader devices 124. These pathways can also update dynamically as the patient moves from different locations as needed to ensure lactate data is properly transferred as needed.

[0079] Remote computing devices 120 are configured to receive lactate data from continuous lactate monitor 110, including historical and real-time data. Remote computing devices 120 can be further configured to analyze the lactate data from continuous lactate monitor 110. Remote computing devices 120 can also be configured to display the lactate data from continuous lactate monitor 110. Remote computing devices 120 can also include alarms and analytical metrics of the data. The analytical metrics can include, for example, any combination of minimum lactate value, maximum lactate value, average lactate value, median lactate value, rate of change of any of the prior metrics, measures of the variability of the lactate values, and other suitable calculated metrics. The analytical metrics can be calculated over predetermined or customized time periods. Corresponding alarms can also be set with predetermined lactate data limits, such as a predetermined maximum, average, or minimum lactate values, or with customized limits. Other alarms examples can relate to system operation, such a loss of signal from the sensor, sensor expiration, or sensor failure. Certain alarms may be also have tiered values.For example, a maximum lactate value of 2 mmol / L may trigger a first tier high lactate alarm, while a value over 4 mmol / L may trigger a second tier alarm that has a higher priority than the first tier. Alarms may also be tailored to events. For example, an alarm may be triggered if lactate levels are not dropping after an intervention, or not dropping by a desired amount in a given time (i.e., a desired rate of decrease). Alarms may also require multiple conditions to trigger. For example, a high lactate alarm may also require the high lactate over a certain time period. For example, the high limit alarm may only be triggered if lactate is above 2 mmol / L for one hour. There may be multiple variants of these multi -limit alarms for a single value. Using the high limit alarm above as an example, there may additionally be an alarm that triggers if the value is above 4 mmol / L for fifteen minutes. Alarms may also vary based on patient condition. For example, if a patient is stable then the alarm limits may be more relaxed to reduce false alarms. A deteriorating or critically ill patient may have strict alarm limits to notify HCPs of any changes more quickly. Other examples of varying alarm limits being tailored to the patient can be alarm limits based on the patient’s medical history, including any current medical treatments or diseases. For example, certain medical treatments or disease history may warrant stricter alarm limits because of potential interactions between excess lactate and the treatment / disease.

[0080] Remote computing devices 120 can be further configured to compare the lactate data to an alarm limit. Remote computing devices 120 will transmit a notification or an alert if any alarm limits are triggered. The notification or alert may inform the user that alarm limits have been triggered. The notification or alert may be an audible and / or visual alert. The notification or alert can be transmitted by any suitable means, such as email, text message, or internal message. Notifications and alerts can be stored in the patient’s electronic health record. Notifications and alerts can be transmitted at the remote computing device and additionally be transmitted to one or more separate remote computing devices. Any combination of these techniques is possible. For example, local audible / visual notification on remote computing device 120 is possible, while simultaneously a notification can also be sent via email to a second remote computing device 120. This can be useful if an alarm limit is triggered in a home environment because the patient can be notified locally at their remote computing device 120 while the patient’s HCP can also be notified by a separate message (e.g., an email) at their remote computing device. The alarms and / or notifications can be transmitted to any number ofrecipients, including various HCPs that are responsible for the patient, alerting systems (such as a central monitoring system at a hospital), patient caregivers, and the patient. This group can be dynamically updated as the patient’s status changes. For example, when the patient is transferred to different departments in a hospital (e.g., ICU versus general floor), the list of recipients may change to accommodate different HCPs. This change can be made manually by altering settings in an application. This change can also be made automatically as part of the association and activation process of continuous lactate monitor 110. Each activation may have a unique default list of users to receive alarms that is prepopulated.

[0081] The use of continuous analyte data provides the capability to have real-time adjustments and configurability to alerts and notifications. As one example, threshold conditions associated with trends (e.g., an upward trend of 2.0 mmol / L or 4.0 mmol / L) may be used to trigger alerts and notifications. Certain recipient devices may be configured to enable (or prevent) the ability to toggle the threshold setting on and off and configure the threshold setting. Other trigger conditions may be associated with rate of change, threshold rate of lactate clearance, a threshold period of time for the rate of change, and rates of change before and after treatments.

[0082] Alerts and notification timing may also be adjusted and configured based on the real-time data. For example, lactate clearance may be included as part of the alerting criteria. There may be a threshold buffer time for an abnormal reading before an alert is triggered.

[0083] Recipients of alerts and notifications may also be changed such as having an audible setting, location-based settings (e.g., within the hospital such as HCPs or nurses), EHR-based notifications, text to device, and bedside notifications.

[0084] Remote server 126 may be implemented as a cloud-based server (or network of distributed servers). Remote server 126 may further be configured to implement components for generating alerts and notifications based on received continuous lactate data. The component may be implemented as a machine learning model (or models) for processing the continuous lactate data and performing an alert and notification process that includes steps for determining one or more recipient devices for receiving an alert and / or notification, determining the content to be included in the alert and / or notification, determining the visual format of the content based on the recipient devices and content, and transmitting the alert and / or notifications.

[0085] Inputs to the machine learning model may be chosen based on ensuring accuracy and relevancy of generated alerts to the particular recipient (e.g., EHR system, web application). One input may include continuous lactate data which consists of real-time measurements from continuous lactate monitor 110. Another input includes patient demographics such as age, gender, and medical history, which can influence the interpretation of analyte data. Another input can include historical health data, for example, where previous records of the patient's lactate levels, along with outcomes of past interventions, enable the model to identify trends and patterns that are specific to the patient. Another input may include environmental and contextual data such as time of day, current context (e.g., home vs. hospital), discharge information, previous and ongoing treatments, and hospital environment settings. These data can affect lactate levels and are thus included to refine the model's predictions.

[0086] Output from the machine learning model is a specifically structured alert or notification that is customized based on the continuous lactate data and the recipients receiving the data. Examples of visually structuring the alert or notification include a content explaining the alert and notification, severity level, actionable recommendations, and customized visual content. For severity level, the model may categorize the urgency of the alert based on one or more of the inputs, using thresholds trained from historical data to classify alerts into levels such as critical, urgent, or informational. Based on the severity and the patient's specific context, the model generates actionable recommendations, such as adjusting medication dosages, scheduling medical reviews, and contacting emergency personnel. For customized visual content, the model, for each alert, may select visual content appropriate for the intended recipient. This might include graphs showing trends in lactate levels for doctors, color-coded alerts for patients on their applications, or detailed tabular data for monitoring services. Note that these graphs can be customized as desired in terms of data points displayed, time ranges, data trend indications (and corresponding time ranges), and similar data. There may be default graph settings that are prepopulated in the various systems.

[0087] The user may set preferred or customized alarm limits, alerts and / or notifications. For example, each individual user may customize preferred alarm limit settings. User preferences can be stored on the memory of the remote computing device 120. User preferences can also be stored on remote server 126 and retrieved by the computing device 120, optionally using a data network.

[0088] The type of recipient devices may impact and shape the type of alerts and notifications (e.g., those generated by the machine learning model). Recipient type not only influences the immediacy and urgency of the response but also determines the nature and detail of the visual indications and information that are incorporated into each alert and notification. Tailoring alerts and notifications ensures that each recipient receives the most relevant and actionable data in a format that best supports their role in patient care.

[0089] For a web application, remote alerts need to be comprehensive yet quickly interpretable to facilitate swift decision-making. Remote computing device 120 may therefore, generate alerts with detailed graphs and trend analyses. The graphs and trend analyses can highlight critical changes in lactate levels. The remote computing device may further suggest potential causes. These visual representations may be accompanied by a summary of the patient's current condition and optionally a comparison with previous similar cases, aiding staff in assessing the situation rapidly.

[0090] For an EHR system, the focus may be on documentation and long-term trend monitoring rather than immediate action. Alerts and notifications may be integrated as part of the ongoing record, with each notification including a timestamp, the measured lactate levels, and any actions taken or recommended. Visual content for the EHR may be more static, often presented in a format for providing long-term and short-term trends and providing access to an increased amount of visualization options which can be presented for display to understand the patient's history and adjust treatment plans accordingly.

[0091] For an HCP application, alerts and notifications may be designed to prompt immediate and informed medical intervention. Remote computing device 120 may provide alerts and notifications with high-resolution charts and / or predictive models that forecast the potential progression of the patient’s condition based on the current lactate data. The application might also receive alerts with embedded links to the patient’s her, for example, including past and current treatments, and optionally access to the patient’s current location.

[0092] For a caregiver application, alerts and notifications may be simplified to ensure clarity and prevent unnecessary anxiety. These notifications often use color-coded systems — such as green, yellow, and red — to indicate the state of their health. Accompanying text is written in layman's terms, with straightforward recommendations like "Please rest" or "Time for your medication," or “Call your doctor’s office.” Visualsfor caregiver applications may be customized with icons or simple graphs to show trends without overwhelming them with data.

[0093] For a monitoring service, which operates continuously, alerts and notifications may include a combination of detailed and summarized alerts. Third party monitoring services may receive comprehensive data, for example, including all past alerts, current analyte levels, and predictive insights from the model. Visual components in these alerts may be configured for quick scanning, and, for example, may include both detailed charts and summary bullet points. The monitoring service may be configured to perform realtime monitoring of the received continuous analyte data and generate customized visual elements for alerts and notifications based on the analyzed continuous analyte data and the intended recipient devices for the alerts and notifications.

[0094] Remote server 126 may store continuous analyte (e.g., lactate) data. Analyte data may be stored in a structured format. Analyte data may be stored within a secure database. The continuous analyte data may include metadata to allow for the traceability of the continuous analyte data and its accurate pairing with the associated patient. Examples of recipients include but are not limited to web applications, electronic health record systems, an application customized for use by a health care provider (e.g., the application may be secured from use by anyone other than the health care provider), an application associated with a dedicated caregiver (e.g., a user that is specified by the health care provider or the patient), and a third-party platform such as a remote monitoring system.

[0095] Remote server 126 may configure alerts / notifications based on the recipients that may have different access privileges to the continuous lactate data. For example, web applications may be configured with access privileges for the continuous lactate data, such as only having access to real-time and historical lactate values and calculated metrics (e.g., lactate rate of change). A web application may be configured to receive alerts both within the application and outside of the application (e.g., email, SMS, etc.). Electronic health record (EHR) systems may be configured to allow for dynamic navigation of stored data (such as using a flowsheet). Dynamic navigation may enable viewing of real-time lactate values and calculated metrics which may be provided at a frequency that is established by provider or health system workflows. Based on its access to additional user historical data EHR systems may be configured with additional alerts and notifications, such as popup alerts, abnormal result flags. The additional alerts andnotifications may be customized based on the user data and / or settings established by the HCP or other authorized user.

[0096] An HCP application may be configured with access privileges to not only view real-time lactate values and calculated metrics, but may have permissions for communicating with EHR systems and other applications (i.e., other HCP applications, other caregiver applications), and generating recommendations to be included in alerts and notifications based on those access privileges. A caregiver application may be configured with more limited access privileges compared to the HCP application. Alerts and notifications for the HCP and caregiver applications may be provided both within the respective applications as well as outside of the application, based on settings or permissions established for the particular continuous lactate data and the user of the application. A third-platform system, such as a remote monitoring system may integrate continuous lactate data into third-party visualizations based on access privileges granted to the third-party platform system.

[0097] Any remote computing devices 120 discussed above can include these data metrics and alarms. For example, the data metrics and alarms may be integrated into the patient’s electronic health record such that they are available for access by an HCP. Data applications running on an existing computing device (e.g., a mobile phone or tablet) can also access the data metrics and alarms by effectively turning those existing computing devices into reader devices 124. There may be applications specific to the user. For example, in some embodiments there may be an HCP application and a caregiver application. Each application may require login by the user (e.g., the HCP or caregiver / patient) before accessing any data. These applications may have different data presentations depending on the context and target user. For example, the caregiver application may have a simplified and more user-friendly display of the data, while the HCP application may include more details (e.g., more data and data metrics) by default. Some users may have more restricted access to display of the data. For example, patient or caregiver displays may be restricted in what data is available to display. These restrictions may be managed or adjusted by, for example, the response HCP. These displays can be customized by each individual user, in terms of, for example, what data to display and / or the alarm limit settings to apply. User preferences can be stored on the memory of the remote computing device 120. User preferences can also be stored on remote server 126 and retrieved by the computing device 120, optionally using a datanetwork. For example, the user preferences can be stored in the user’s account and applied when the user logs in to remote computing device 120.

[0098] FIG. 6 shows a sensor initialization method 600 in a hospital setting. In an initialization step 602, continuous lactate monitor 110 is initialized using the adaptor embodiment multi-parameter monitor module 122. This can be beneficial because no separate reader device 124 (or similar device) is needed because multi-parameter monitor module 122 is typically already present in the patient’s room being attached to an existing computing device (e.g., the patient’s bedside multiparameter monitor). This activation option may also be the preferred technique used in a patient telemetry environment (e.g., a hospital) because it can allow for easier integration of lactate data with the existing patient monitoring systems. Continuous lactate monitor 110 may be paired directly with multi-parameter monitor module 122 instead of reader device 124. Multi-parameter monitor module 122 may also be configured to allow continuous lactate monitor 110 to join or pair with the relevant data network at a later time (i.e., after the connection is initiated). In a step 604 data from continuous lactate monitor 110 is captured by multiparameter monitor module 122 and is transmitted to the existing computing device. Continuous lactate monitor 110 is associated with the patient automatically because the patient information is already present on the existing computing device. For example, the existing computing device (e.g., the patient bedside multiparameter monitor (reader device 124)) already is associated with and has access to the patient’s information, including a patient identifier. In other embodiments, the patient information can be captured by using multi-parameter monitor module 122 to scan a patient’s wristband, or the patient information could be input into the system using manual entry (e.g., typing). In such embodiments, multi-parameter monitor module 122 may be implemented with an identification scanner, such as a bar code scanner or a quick-response (QR) scanner, for scanning patient identification (e.g., bar code or QR code) from the wristband. In some embodiments known patient location data can be combined with access to an admissiondischarge-transfer (ADT) feed to retrieve patient information.

[0099] In some embodiments, app-enabled device 123 may be configured to capture patient information via a combination of a camera on the app-enabled device 123 in combination with an installed application, that provides scanning functionality to the camera. App-enabled device 123 may be further configured to store the scanned patientidentification in a cloud database. The system may be configured to associate the patient identification with device identification of the continuous lactate monitor 110.

[0100] Connecting multi-parameter monitor module 122 to the existing computing device allows the lactate data to be associated with the patient information (e.g., the patient identifier) already present. Finally, in a step 606 lactate data is transmitted to other remote computing devices 120 as discussed above. Note that in telemetry environments, transmission of all lactate data from continuous lactate monitor 110 may pass through multi-parameter monitor module 122 only. Any reader devices 124 or displays 128 will receive lactate data through suitable data networks (e.g., a hospital WiFi network) after the lactate data has been passed to remote servers 126 for access.

[0101] As discussed above, one of the benefits of multi-parameter monitor module 122 is the display of lactate data on existing remote computing devices 120, including display of data analysis and alerts and notifications. Lactate data from continuous lactate monitor 110 presents challenges when being displayed alongside existing data because of the unique, continuous nature of the lactate data. For example, continuous analyte sensors like continuous lactate monitor 110 take readings at predetermined intervals such as every minute, five minutes, or fifteen minutes. This means that the analyte data is not measured at the same rate as, for example, heart rate data. Displaying this data is further complicated because the analyte values tend to change at a relatively slow rate compared to heart rate or respiration. This means that the period of time that would typically be used to display analyte data is much longer than the time period used to display other data such as heart rate or respiration. Accordingly, the improvements to the user interface of the bedside multiparameter monitor allow the display of the continuous analyte data alongside that real-time data. The user interface examples discussed below address these problems and provide benefits including improved patient analysis based on the visual display of lactate data, including analysis and alarms. The user interfaces discussed below can operate on any suitable remote computing device 120 with a display, such as reader device 124 and display device 128. Any device that displays these user interfaces will do so using instructions recorded on a memory of that device that causes the processor or processors of that device to produce the elements of the user interface on the display.

[0102] FIG. 11 shows an embodiment of a user interface that displays legacy patient health data 1100 and that does not include any lactate data display. As can be seen in FIG. 11, there are several other types of legacy patient health data 1100 displayed visually inboth numerical and graphical form. These include heart rate data display 1101, oxygen saturation display 1102, blood pressure display 1103, central venous pressure display 1104, pulmonary artery pressure display 1105, respiration rate display 1106, and temperature display 1107. Some data is, such as heartrate data display 1101 and central venous pressure display 1104 are displayed in both graphical and numerical form, with the graph showing the detected heartrate in the immediate preceding time period. Other data, such as patient temperature display 1107 is shown numerically only. The data displayed, and how it is displayed, can be controlled by a user to customize the display to their preferences. Each data source can be displayed in a unique color to improve user identification of the data.

[0103] FIG. 12 shows an embodiment of a user interface 1200 showing lactate data, although as discussed above different analytes such as glucose and ketone can also be displayed instead of lactate. User interface 1200 and the other user interface embodiments below use icons, numbers, and graphs to display patient data, such as legacy patient health data 1100. These user interface embodiments are interactive and can change based on user input. In some embodiments the display elements are themselves interactive and able to be selected and altered, as will be discussed below. These user interfaces are programmed into memory of the corresponding reader device 124 or display device 128 and are displayed using a suitable display screen or display screens.

[0104] In this embodiment a lactate data UI component 1202 displays lactate data for a user. Various numerical and / or graphical techniques can be used, alone or in combination, as lactate data UI component 1202. In user interface 1200 lactate data UI component 1202 is configured to display a numerical representation of the lactate value on the right hand portion of the screen. There is no graphical representation present. The most recent lactate value (here, 1.4 mmol / L) is presented on the screen for the user. Lactate data UI component 1202 may further be configured to display a trend arrow in combination with the numerical lactate value. The trend arrow can point either diagonally upwards, as shown, horizontally away from the lactate value, or diagonally downwards. These three indications correspond to the immediate historical trend of the lactate value, with the upwards arrow showing an increasing trend, the horizontal arrow showing a stable trend, and the downwards arrow showing a decreasing trend. The specific orientation of the arrow can be varied to show the rate of change. For example, a vertically upwards arrow may show a lactate value that is rapidly increasing, while a diagonally upwards arrowmay show a moderately increasing lactate trend. Also shown immediately below the trend arrow is a numerical representation of the rate of change, which here is 0.7 mmol / L / hr. Finally, visible to the immediate left of the lactate value are a pair of values that correspond to a visual representation of high and critical lactate limits, in this case 4.0 mmol / L and 2.0 mmol / L. Lactate data UI component 1202 can be positioned in any suitable location on user interface 1200, and can be presented in a unique color for improved identification. FIG. 13 shows an embodiment of a user interface 1300 similar to the embodiment of FIG. 12 but without the trend arrow and numerical representation of lactate rate of change. This can be desirable to simplify the display of lactate data and may be controlled by a setting accessible to a user.

[0105] In some embodiments, lactate data UI component 1202 is configured to display lactate data based on a different time scale then legacy patient health data 1100. For example, lactate data UI component 1202 may display time scales including one hour, two hours, three hours, four hours, six hours, twelve hours, or twenty-four hours. Legacy patient health data 1100 can be displayed on substantially shorter scales, such as the previous ten seconds, thirty seconds, or one minute. As explained above, the longer time scales of lactate data UI component 1202 are useful to accommodate more measurements from continuous lactate monitor 110, which has a relatively long measurement interval. These longer time scales also show changes or trends in lactate data more clearly because lactate data tends to change more slowly than legacy patient health data 1100.

[0106] In the embodiments of FIG. 12 and 13 it can be desirable to examine the historical trends of the lactate data in greater detail to improve patient analysis and diagnosis. In some embodiments there can be a separate user interface screen 1400 that displays a graphical version of lactate data UI component 1202 that is configured to display recent historical lactate data. Screen 1400 can be accessed by a menu setting or icon, for example an icon displayed on a bottom row of the primary user interface screen shown in FIGS. 12 and 13. FIG. 14 shows an embodiment of the user interface screen 1400 as a pop up screen that is overlaid on the primary screen (e.g., user interface 1200 or 1300 discussed above). User interface screen 1400 can be accessed through a suitable menu setting, virtual button, or by selecting lactate data display 1202, for example. In some embodiments user interface screen 1400 can be its own full screen display (i.e., not a pop up). Shown in FIG. 14 is the current lactate value at the top of the screen (here. 1.4 mmol / L) and a graphical display of the proceeding historical lactate data with timedisplayed on a horizontal axis and the value displayed on the vertical axis. The time period may be a predetermined time period of the proceeding one, two, four, six, twelve, or twenty four hours, for example. The user may select and modify the time period as desired to display additional data, as shown by the selection buttons in the top right of the popup display showing several different hourly time period choices. In some embodiments like the one in FIG. 14 the user can also select a point along the data line to receive a numerical indication of the value of the lactate at that point in time, as shown by the “2.4” popup in the center of FIG. 14.

[0107] FIG. 15 shows another embodiment of lactate data UI component 1200 implemented within a user interface 1500. Lactate data UI component 1200 includes both a graphical and numerical display of lactate data. In some embodiments, lactate data UI component may be configured to display the numerical display adjacent to the graphical display and can be similar or the same as the numerical display discussed above in FIGS. 12 and 13. The graphical display 1502 is generally similar to user interface 1400 discussed above and shown in FIG. 14 and shows lactate data plotted over a predetermined period of time. The discussion above with respect to variation of the predetermined time and selection of data points applies equally here. There may be different icons, colors, or other indications used to improve differentiation of the time period selections for lactate data UI component 1202 versus time period selections for legacy patient data 1100. FIG. 16 shows an embodiment of user interface 1600 similar to the one of FIGS. 15 and 16 without any trend arrow (either on the numerical indication or on the graphical representation).

[0108] FIG. 17 shows an embodiment of user interface 1700 similar to the one of FIG. 16. However, in this embodiment the graphical representation includes dots or other indications that show the individual lactate data points received during the time period. This can help a user better understand how the graphical representation correspond to the actual lactate data UI component 1202 received. This is particularly beneficial because of the different lactate data intervals discussed above, allowing the user to visually distinguish the longer data intervals of the lactate data versus the shorter data intervals for legacy patient data 1100. In this embodiment there is no lactate data trend arrow, but a trend arrow can be included per the techniques discussed above. Indeed, an important feature of multi-parameter monitor module 122 enables reader device 124 the capability to display data captured at varying data intervals, such as patient data that is monitoredcontinuously (e.g., heart rate) and patient data that is monitored at longer data intervals (e.g., lactate data from a continuous lactate monitor).

[0109] FIG. 18 shows another embodiment of a user interface 1800 having lactate data UI component 1200 implemented that includes both a numerical and graphical representation of lactate data. This embodiment is similar to user interface 1700 of FIG. 17 but shows an alternate representation of the graphical display of lactate data. This representation is smaller and offset from other graphical displays, which can be useful to display a different timescale for the lactate data versus the time scales of the other displays. Lactate data can change at a slower rate than some other data displayed, such as heart rate data. The separate graphical display can clarify the different time scales of the various graphical displays. FIG. 19 shows embodiment user interface 1900 similar to the embodiment of FIG. 18 but includes a lactate data trend arrow, which is discussed in the embodiments above.

[0110] FIG. 20 shows a user interface 2000 similar to the one of FIG. 11 without any lactate data on the screen. However, a lactate alarm 1204 is displayed in a popup type fashion. This type of display removes lactate from the primary display, which can be beneficial to prevent too much detail being shown. However, the popup nature of lactate alarm 1204 ensures a user is informed of any relevant lactate data. The example in FIG. 20 shows a high lactate data alarm, however any suitable alarm can be shown in this manner.[OHl] After an alarm is shown (as in FIG. 20) further lactate data detail can be shown in additional screens. For example, FIG. 21 shows an embodiment of a popup lactate data detail screen 2100 that is similar to user interface 1400 discussed in FIG. 14. This embodiment is linked to lactate alarm 1204 that was shown in FIG. 20 as can be seen by the presence of the lactate alarm information in the upper right of the screen. FIG. 21 is otherwise identical to the embodiment of FIG. 14.

[0112] It is to be appreciated that the Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.

[0113] The foregoing description of the system and methods will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and / or adapt for various applications the systems and methods,without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed invention, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

[0114] The breadth and scope of the present invention should not be limited by any of the above-described examples, but should be defined only in accordance with the following claims and their equivalents.

Claims

WHAT IS CLAIMED IS:

1. A method of displaying continuous analyte data on a patient monitoring device, wherein the patient monitoring device is connected to a multi-parameter monitor and a legacy monitoring device, the method comprising: receiving, via the multi-parameter monitor by the patient monitoring device, analyte data from an analyte sensor operably connected to a patient through a communication interface, wherein the analyte data comprises a plurality of analyte readings; receiving, by the patient monitoring device, patient medical data from a medical monitoring device operable to determine the patient medical data from a patient; determining a numerical value corresponding to a current analyte level based on the analyte data; generating a first user interface component comprising the patient medical data; generating a second user interface component comprising the numeral value; and displaying the first user interface component and the second user component on a display screen of the patient monitoring device.

2. The method of claim 1, further comprising: plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data over a time period; and displaying the graph on the display screen, wherein the time period on the graph is different than a time period used to display at least one other patient health data on the display.

3. The method of claim 2, further comprising: displaying a plurality of time periods for the graph on the display screen; receiving a user selection of one of the plurality of time periods; plotting the plurality of analyte readings on a second graph using the selected time period; and displaying the second graph.

4. The method of any one of claims 1-3, further comprising: determining a rate of change of a value of the analyte data; displaying a trend arrow that graphically indicates the rate of change on the display screen.

5. The method of claim 4, further comprising altering an orientation of the trend arrow to correspond to a change in the rate of change.

6. The method of claim 4, further comprising displaying a numerical value corresponding to the rate of change on the display screen.

7. The method of any one of claims 1-3, further comprising: displaying an alarm limit corresponding the lactate data on the display screen; receiving a user input related to the alarm limit; and altering the displayed alarm limit based on the user input.

8. The method of claim 1, further comprising: receiving an input from a user corresponding to the analyte data; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

9. The method of any one of claims 2, 3, or 8, further comprising: receiving an input form a user corresponding to a portion of the graph; and displaying a lactate value that corresponds to the portion of the graph.

10. The method of any one of claims 1 or 2, further comprising: displaying an alarm indication associated with the analyte data on the display screen; and receiving an input from a user corresponding to the alarm indication; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; anddisplaying in a separate screen the graph on the display screen.

11. A non-transitory computer readable medium comprising instructions that, when executed on a processor of a patient monitoring device that is connected to a multi-parameter monitor and a legacy monitoring device, perform the steps of: receiving, via the multi-parameter monitor by the patient monitoring device, analyte data through a communication interface from an analyte sensor operably connected to a patient, wherein the analyte data comprises a plurality of analyte readings; receiving, by the patient monitoring device, patient medical data from a medical monitoring device operable to determine the patient medical data from a patient; determining a numerical value corresponding to a current analyte level based on the analyte data; and generating a first user interface component comprising the patient medical data; generating a second user interface component comprising the numeral value; and displaying the first user interface component and the second user component on a display screen of the patient monitoring device.

12. The non-transitory computer readable medium of claim 11, the instructions further comprising: plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data over a time period; and displaying the graph on the display screen, wherein the time period on the graph is different than a time period used to display at least one other patient health data on the display.

13. The non-transitory computer readable medium of claim 12, the instructions further comprising: displaying a plurality of time periods for the graph on the display screen; receiving a user selection of one of the plurality of time periods; plotting the plurality of analyte readings on a second graph using the selected time period; and displaying the second graph.

14. The non-transitory computer readable medium of any one of claims 1-3, the instructions further comprising: determining a rate of change of a value of the analyte data; displaying a trend arrow that graphically indicates the rate of change on the display screen.

15. The non-transitory computer readable medium of claim 14, the instructions further comprising altering an orientation of the trend arrow to correspond to a change in the rate of change.

16. The non-transitory computer readable medium of claim 4, further comprising displaying a numerical value corresponding to the rate of change on the display screen.

17. The non-transitory computer readable medium of any one of claims 11-13, the instructions further comprising: displaying an alarm limit corresponding the lactate data on the display screen; receiving a user input related to the alarm limit; and altering the displayed alarm limit based on the user input.

18. The non-transitory computer readable medium of claim 11, the instructions further comprising: receiving an input from a user corresponding to the analyte data; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

19. The non-transitory computer readable medium of any one of claims 12, 13, or 18, the instructions further comprising: receiving an input form a user corresponding to a portion of the graph; and displaying a lactate value that corresponds to the portion of the graph.

0. The non-transitory computer readable medium of any one of claims 11 or 12, the instructions further comprising: displaying an alarm indication associated with the analyte data on the display screen; and receiving an input from a user corresponding to the alarm indication; plotting the plurality of analyte readings on a graph such that the graph shows the variation of the analyte data versus time; and displaying in a separate screen the graph on the display screen.

Images