Devices and methods for healthcare collaboration spaces

Abstract

The present invention provides various systems and devices for facilitating communication in a health care environment. In one example, a system includes a display and a computing device operably coupled to the display. The computing device stores instructions executable to output a patient-specific dashboard to the display, the dashboard including medical information specific to the patient, the dashboard also including a displayed link to a patient-specific communication thread; and in response to a user selecting the link, output a portion of the communication thread to the display, wherein the communication thread includes communications between one or more care providers and one or more virtual health care assistants monitoring the patient.

Description

Technical Field

[0001] Embodiments of the subject matter disclosed herein relate to healthcare communications, and in particular to healthcare communications in an acute care environment. Background Art

[0002] Acute or subacute care for patients in a hospital or other medical facility may be provided by multiple care providers for each patient and may include multiple patient monitoring devices monitoring each patient. Thus, near-continuous monitoring of the outputs from multiple monitoring devices may be required to ensure a rapid response when a patient's condition deteriorates. Furthermore, coordination of patient care among all care providers may be complex or time consuming, further draining care provider resources. Summary of the invention

[0003] In one embodiment, a system includes a display and a computing device operably coupled to the display. The computing device stores instructions executable to output a patient-specific dashboard to the display, the dashboard including medical information specific to the patient, the dashboard also including a displayed link to a patient-specific communication thread; and in response to a user selecting the link, output a portion of the communication thread to the display, wherein the communication thread includes communications between one or more care providers and one or more virtual health care assistants monitoring the patient.

[0004] It should be understood that the above brief description is provided to introduce in a simplified form selected concepts that are further described in the detailed description. It is not meant to identify key or essential features of the claimed subject matter, the scope of which is solely defined by the claims that follow the detailed description. Furthermore, the claimed subject matter is not limited to implementations that solve any disadvantages noted above or in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The present invention will be better understood by reading the following description of non-limiting embodiments with reference to the accompanying drawings, in which:

[0006] Figure 1 An exemplary collaborative healthcare system is schematically illustrated.

[0007] Figure 2 An exemplary display device is shown that displays communication threads occurring on a communication channel of a collaborative healthcare system.

[0008] Figure 3 An exemplary display device is shown displaying a dashboard of a collaborative healthcare system.

[0009] Figure 4An exemplary display device is shown, which displays Figure 3 Dashboard, including Figure 2 A display of a portion of a communication thread.

[0010] Figure 5 An exemplary display device is shown, which displays Figure 3 Dashboard, including Figure 2 The full version of the communication thread is displayed.

[0011] Figure 6 An exemplary display device is shown, which displays Figure 2 The communication thread includes Figure 3 A preview of the dashboard is displayed.

[0012] Figure 7 is a flow chart illustrating an exemplary method for facilitating communications within a collaborative healthcare system.

[0013] Figure 8 and Fig. 9 is a flow chart illustrating an exemplary method for coordinating one or more virtual healthcare assistants of a healthcare system.

[0014] Fig.10 An exemplary display device displaying a collaboration interface is shown. DETAILED DESCRIPTION

[0015] The following description relates to various embodiments of a collaborative health care system that facilitates communication between a patient's care providers and also utilizes a virtual health care assistant to perform certain patient monitoring activities. The collaborative health care system includes patient-specific communication channels that include communication thread-dashboard pairs to facilitate communication between the care provider and the virtual health care assistant (also known as a robot) on the communication thread, while also providing relevant patient care information (current vital signs, trends, medical history) to the care provider in a graphical manner via a dashboard.

[0016] The virtual health care assistant can act as an information retriever, data monitor, predictor, etc. to assist the care provider. The virtual health care assistant can provide requested patient data (e.g., obtain data from electronic medical records), detect changes in patient status and alert the care provider to the changed status (e.g., by detecting that the patient's vital signs have reached a condition relative to a threshold), and provide care guidelines and diagnosis to the care provider. The virtual health care assistant can be trained to communicate using natural language (including medical language), thereby allowing the care provider to communicate with the virtual health care assistant in the same manner as other care providers.

[0017] Each communication channel may be specific to a given patient in a given acute care facility or other medical facility or health care environment (e.g., a hospital, urgent care facility, or nursing home). A communication channel may be initiated when a patient is admitted to a medical facility. Each care provider of the patient may be connected to the communication channel, thereby allowing collaboration and communication between all care providers of the patient (e.g., doctors, nurses, and / or specialists such as radiologists). The one or more virtual health care assistants may also be connected to the communication channel. The communications occurring on the communication channel may be in the form of text messages, rich media, and / or other forms, thereby allowing care providers to view graphs of patient medical trends, medical images, and the like. Messages sent and received on the communication channel may be saved as communication threads at a central location, thereby allowing care providers to access previous conversations on the channel. For example, if a virtual health care assistant detects a change in a patient's condition indicating a potential health problem (such as high blood pressure), the virtual health care assistant may note the high blood pressure and alert the care provider via the communication thread. Blood pressure may be displayed together with the alert via the patient dashboard. The care provider may view the blood pressure measurement by selecting the alert in the communication thread. The care provider can then select the graphical display of the alert in the dashboard to initiate the portion of the communication thread that issues the blood pressure alert.

[0018] The dashboard and communication thread may be viewable from a variety of client devices, including but not limited to provider client devices (such as monitors in nurse stations) and provider mobile devices (such as tablets or smartphones). Thus, care providers can obtain relevant data and assistance from the virtual health care assistant from nearly any allowed location within the medical institution, and in some examples even off-site locations.

[0019] Figure 1 An exemplary collaborative health care system is shown in FIG. The collaborative health care system may be included within or associated with a medical institution and may include a communication channel including a communication thread and a dashboard for each inpatient of the medical institution. The collaborative health care system may also include one or more virtual health care assistants. Communications may occur over the communication channel in the form of a communication thread (e.g., of text and / or rich media messages) between a patient's care provider and the one or more virtual health care assistants, such as Figure 2 Patient-specific medical information can be displayed to care providers and / or other users via the dashboard. Figure 3 As shown, the dashboard may be launched in response to a first selection of a link on the communication thread. The dashboard may be configured to display alerts output by the one or more virtual health care assistants, and these alerts may be selectable to initiate a portion of a communication thread occurring on the communication channel, such as Figure 4The dashboard may be further configured to display a control button that is selectable to launch a full version of the communication thread, such as Figure 5 As shown. Figure 6 As shown, a preview of the dashboard may be initiated in response to a second selection of a link on the communication thread. Fig.10 The illustrated collaboration system interface may be displayed on a suitable display device to allow a user to select a communication channel or dashboard to view.

[0020] According to Figure 7 The method shown generates and accesses a communication thread-dashboard pair. A virtual health care assistant can provide assistance to a patient's care provider by retrieving the patient's medical information from an electronic medical record, providing treatment or care guidance, and / or providing a prediction of a future patient status, such as Figure 8 The virtual health care assistant may be further configured to monitor the patient's condition / status and notify the care provider when the virtual health care assistant determines that the patient's state or condition has changed, such as Fig. 9 The method shown is shown in FIG.

[0021] Figure 1 An exemplary collaborative health care system 100 that can be implemented in a medical institution, such as a hospital, is schematically illustrated. The collaborative health care system 100 can include a collaborative space server system 102. The server system 102 can include resources (e.g., memory 130, processor 132) that can be allocated to store and execute communication threads, dashboards, and digital twins for each of a plurality of patients. For example, Figure 1 As shown, the communication thread 104, dashboard 106, and digital twin 108 are stored on the server system 102 for a first patient (Patient 1); multiple additional communication threads, dashboards, and digital twins may be stored on the server system 102, each corresponding to a respective patient (Patient 2 through Patient N).

[0022] As explained above, the communication thread 104 can facilitate communication between multiple care providers and one or more virtual health care assistants (explained in more detail below), each providing care to a patient (e.g., Patient 1). Messages sent on the communication thread 104 can be saved and can be accessed via the dashboard 106 (and the dashboard can be accessed via the communication thread). In addition, patient medical information (including medical history, current status, vital signs, and other information) can be entered into the digital twin 108, which can be used to obtain the patient's situational awareness, clinical context, and medical history to facilitate predicting the patient's status, obtaining relevant treatment guidelines, patient status diagnosis, etc.

[0023] The communications occurring on the communication thread 104 may be displayed on one or more suitable display devices associated with the corresponding care provider device and / or medical institution management device. Similarly, the dashboard 106 may be displayed on the one or more display devices. Figure 1 As shown, a plurality of care provider devices (from a first care provider device 134, a second care provider device 136 to an nth care provider device 138) are communicatively coupled to the server system 102. Each care provider device may include a processor, a memory, a communication module, a user input device, a display (e.g., a screen or monitor), and / or other subsystems, and may be in the form of a desktop computing device, a laptop computing device, a tablet computer, a smart phone, or other device. Each care provider device may be suitable for sending and receiving encrypted data, displaying medical information (including medical images in a suitable format such as Digital Imaging and Communications in Medicine (DICOM) or other standards), and ensuring that only authenticated users can access patient medical information. The care provider device may be located locally in a medical facility (such as in a nurse's station or in a patient's room) and / or remotely in a medical facility (such as a mobile device of a care provider).

[0024] While viewing the communication thread 104 and / or dashboard 106 via a display of a care provider device, the care provider may enter input (e.g., via a user input device, which may include a keyboard, mouse, microphone, touch screen, stylus, or other device), which may be processed by the care provider device and sent to the server system 102. In examples where the user input is a message to be sent to other care providers and / or one or more virtual health care assistants, the message may be sent to the server system 102, where the message may be saved as part of the communication thread 104, which may then be sent to other authenticated participants on the communication channel (e.g., other care providers and / or one or more virtual health care assistants connected to the communication channel). In examples where the user input is a link to a dashboard or selection of a user interface control button, the user input may trigger display of the communication thread, trigger advancement to a desired state of the dashboard (e.g., trigger display of desired patient medical information), trigger an update to a configuration of the dashboard, or other actions.

[0025] The collaborative space server system 102 is communicatively coupled to a hospital operations system 118. The hospital operations system 118 may store and / or control a variety of hospital-related, care provider-related, and patient-related information, including, but not limited to, patient hospitalization information (including the patient's hospitalization date and location within the medical institution), patient care plans and workflows, and care provider information (including which care providers monitor / treat which patients). In addition, the hospital operations system 118 is communicatively coupled to a plurality of monitoring devices 120, an electronic medical record (EMR) database 122 (described in more detail below), and one or more care provider devices. The monitoring device 120 may include conventional medical devices for monitoring the respective patient, such as pulse oximeters, heart rate monitors, blood glucose monitors, ECGs, and medical imaging modalities (e.g., ultrasound, CAT, MRI), as well as microphones, cameras, and other devices. The monitoring device 120 may send outputs directly to the server system 102, and / or may send outputs to the hospital operations system 118, the EMR database 122, and / or one or more care provider devices. For example, multiple monitoring devices monitoring patient 1 may be configured to send output to a care provider device (care provider device 134 ), and the care provider device may be configured to send some or all of the data output by the monitoring devices to the server system 102 .

[0026] The hospital operations system 118 can direct the creation of each communication thread and dashboard and control access to each communication thread and dashboard. For example, when a patient is admitted to the hospital, the hospital operations system 118 can associate the patient with an identifier (e.g., an identification code) and notify the collaborative space server system 102 to generate a communication channel for the patient. When a care provider is assigned to assist in the management / treatment of the patient, the hospital operations system 118 can notify the collaborative space server system 102 to connect the care provider to the patient's communication channel (the care provider can also be associated with an identifier that can be used to identify the care provider and appropriately distribute messages sent and received on the channel). In this way, the hospital operations system 118 can control who can access patient information, and can rely on biometrics or other ways to authenticate users, as well as control access levels based on the location of the care provider's device (e.g., a device located in a medical institution can access more patient information than a device located far away from the medical institution). Additional information about the hospital operations system 118 is provided below.

[0027] The collaborative space server system 102 may also store instructions for multiple virtual health care assistants (VHAs) (e.g., in the memory 130) and be configured to execute the multiple virtual health care assistants (e.g., via the processor 132). As shown, the collaborative space device 102 includes an electronic medical record (EMR) VHA 110, a guideline VHA 112, a predictive VHA 114, a listening VHA 116, and a monitoring VHA. These VHAs can be implemented as several VHAs each for different purposes as described herein, various VHA groups (e.g., the guideline VHA 112 and the predictive VHA can be combined into one VHA that is configured to diagnose or predict patient status and output related guidelines), or as one comprehensive VHA (which represents all the different attributes that will be described herein). All activations of the VHAs by human care providers can be performed through text or voice using natural language (including medical language).

[0028] The EMR VHA 110 is configured to retrieve patient information from an electronic medical record database (such as the EMR database 122) and present the retrieved data via a communication thread and / or a dashboard. For example, a care provider may send a request for a particular patient medical history stored in the patient's EMR to the EMR VHA 110 via a communication channel. The EMR VHA 110 may receive the request and determine that the patient medical history has been requested based on the natural language of the text. The EMR VHA 110 may obtain the medical history from the EMR database 122. The EMR VHA 110 may then send the medical history to the care provider in the form of a message on the communication thread 104. In some examples where the requested medical history is also stored in the digital twin 108, the EMR VHA 110 may be configured to retrieve the medical history from the digital twin 108.

[0029] The EMR database 122 may be an external database that the EMR VHA 110 can access via a secure hospital interface, or the EMR database 122 may be a local database (e.g., housed on a device at the hospital). The EMR database 122 may be a database stored in a mass storage device that is configured to communicate with a secure channel (e.g., HTTPS and TLS) and store data in an encrypted form. In addition, the EMR mass storage device is configured to control access to the patient's electronic medical records so that only authorized health care providers can edit and access the electronic medical records. The patient's EMR may include patient demographic information, family medical history, past medical history, existing medical conditions, current medications, allergies, surgical history, previous medical screenings and procedures, previous hospitalizations and visits, etc.

[0030] Thus, the EMR VHA 110 serves as a connection to the EMR database. The EMR VHA can interpret patient-related questions asked by human care providers and allow queries to the EMR database for relevant information about the patient (e.g., "What is the average systolic blood pressure in the last four hours?" or "Show me the trend of O2 saturation"). The query may implicitly involve the patient's status or medical history. The EMR VHA 110 also allows EMR-generated alerts to be formatted and sent to the patient communication thread (the manner in which it is used can be configured through a "settings" option or voice command such as telling it, for example, "Don't show me this alert again"). The EMR VHA 110 can also be used as a medication safety alert system (including allergies, drug-drug relationships, etc.), and therefore can be connected to a relevant medical knowledge base.

[0031] The Guidelines VHA 112 is configured to retrieve relevant care guidelines from the external guideline service 124. The Guidelines VHA 112 may be prompted to retrieve care guidelines via communications occurring on the communication channel. For example, a care provider may explicitly request a care guideline for a given condition (such as sepsis) on a communication thread, and the Guidelines VHA 112 may query the external guideline service 124 in response to the explicit request. In other examples, the Guidelines VHA 112 may implicitly determine that a care guideline for a given patient condition is requested and / or may be useful. For example, the Guidelines VHA 112 may parse communications on the communication thread 104 (e.g., between one or more care providers and / or appropriate VHAs) to determine that a guideline is requested (e.g., the Guidelines VHA 112 does not receive an explicit request for these guidelines, but may determine that two care providers are discussing guidelines and may retrieve these guidelines without requesting to do so). In another example, the Guidelines VHA 112 may determine based on patient vital signs (e.g., output of the one or more monitoring devices 120), the digital twin 108, and / or other sources that a patient may be experiencing a given condition (e.g., a high heart rate) and may automatically obtain guidelines for treating the condition.

[0032] The external guideline service 124 may be a remote service accessed via a network, or the external guideline service 124 may be a local service executed on a computing device at the hospital. The care guidelines obtained from the external guideline service 124 may be pre-configured with protocols and guidelines specific to the medical institution served by the collaborative space server system 102. In addition, the external guideline service 124 may include differential diagnosis trees that the guideline VHA 112 may access to determine potential diagnoses based on the patient's condition or status.

[0033] For example, with respect to the patient's status and medical history as search terms, for example, if a diabetic patient has a high sequential organ failure assessment (SOFA) score and a high blood sugar level, a specific guideline will be queried without additional query terms, or alternatively, an external guideline service can be queried by specifying a specific guideline. In other words, the guideline VHA can enter a specific search term into the guideline service based on the patient's status and symptoms (e.g., diabetes, SOFA score of five, blood sugar level of 190 mg / dL) to obtain one or more potential diagnoses and / or guidelines, or the guideline VHA can explicitly ask for a guideline for a given condition (e.g., sepsis). The guideline VHA can also be used as a source to generate reminders for treatment as part of a care plan, or to track what decision-driven tests have been completed and what is still needed to complete the plan. Changes in patient status can be triggers for automatic notifications of relevant guidelines. The guideline VHA can also be used to plan the trajectory of both disease progression and care paths for patients. When doing so, the guideline VHA can assist care providers in keeping established routes and issuing early warnings when patients deviate from the planned trajectory.

[0034] The predictive VHA 114 is configured to retrieve predictions of future patient states from an external predictive service 126. The predictive VHA 114 can detect relevant changes in patient states (e.g., small but worrisome changes in vital signs, changes in qSOFA scores) and issue alerts on these relevant changes. The predictive VHA 114 can also predict future events (e.g., predictions of sepsis within the next four hours) by connecting to the external predictive service 126. The predictive VHA 114 can query the external predictive service 126 using search terms indicating current and / or past patient states (e.g., blood pressure trends, blood sugar level trends, etc.). If the predictive service 126 outputs a possible future condition, the predictive VHA 114 can send an alert as text to the communication thread and can provide supplemental information related to the alert. The predictive VHA 114 can also track the response of human care providers, as reflected in the communication channel or EMR doctor order registration system. The predictive VHA 114 may obtain patient data from the EMR and different online monitoring devices 120 (ECG, cameras, etc.), as represented in the digital twin.

[0035] The monitoring VHA 116 is configured to monitor communications on the communication channel 104 as well as actual human voice communications to obtain / infer various information related to the patient. In doing so, the monitoring VHA 116 acts as a monitor by monitoring events in the patient's surroundings, including medical staff conversations and patient inputs (from groans to speech). The monitored conversations / inputs can be used to record the patient's state (for EMR / digital twins) or infer clinician reasoning (for example, the monitoring VHA can hear the doctor's order to prescribe a certain antibiotic and understand that an infection is suspected). The monitoring VHA 116 can receive output from one or more microphones positioned near the patient, for example, to monitor conversations and inputs.

[0036] The monitoring VHA 117 is configured to receive outputs from the monitoring device 120, and can track the patient's condition or status based on the received output. In some examples, the monitoring VHA 117 can present the received data via a communication thread and / or a dashboard. For example, a care provider can send a request for a specific patient monitoring data (such as current heart rate) to the monitoring VHA 117 via a communication channel. The monitoring VHA 117 can receive the request and determine that the patient's medical data has been requested based on the natural language of the request. The monitoring VHA 117 can obtain the patient's medical data from the relevant monitoring device in the monitoring device 120. The monitoring VHA 117 can then send the medical data to the care provider in the form of a message on the communication thread 104. In some examples, the monitoring VHA 117 can be configured to save the medical data at the digital twin 108. In addition, the medical data received by the monitoring VHA 117 can be displayed via a dashboard. In some examples, the monitoring VHA 117 can obtain the patient's medical data only in response to a request from a care provider. In other examples, additionally or alternatively, the monitoring VHA 117 may obtain medical data from the monitoring device 120 independently of a caregiver request, and may output the requested medical data when the caregiver requests the data and / or when it is detected (by the VHA) that the received medical data is abnormal, has changed, or otherwise indicates an urgent patient state. In some examples, the monitoring VHA 117 may be configured to provide the received medical data to the predictive VHA 114 and / or the guidelines VHA 112 to predict future patient states based on current patient medical data and / or to retrieve relevant care guidelines based on current patient medical data.

[0037] The VHA may be configured to receive messages from human care providers and utilize natural language processing to determine what information is conveyed in these messages. For example, the VHA may utilize natural language processing to determine whether a message received on a communication channel includes a request for patient medical information, and if so, determine what medical information is being requested. The VHA may also be configured to process medical information (e.g., vital signs, medical history, current symptoms) of patients received from patient EMRs, monitoring devices, care providers, and / or other sources, and determine which parameters of the medical information (e.g., entered into a guide or prediction service) can be used to determine the patient's state (such as determining the possibility of a patient experiencing a condition such as sepsis). Machine learning (e.g., deep learning) such as neural networks or other training mechanisms specific to medical terminology may be used to train the VHA. In addition, the VHA may be configured to learn the above parameters in a patient and / or care provider-specific manner. For example, a predictive VHA may be trained to determine that hypotension may be a relevant symptom that should be entered into a prediction service or diagnostic tree, but then the predictive VHA may be trained for a specific patient (whose hypotension is benign and may have less relevance).

[0038] The VHA may be trained in a suitable manner. In a first example, the VHA may be a rule-based assistant that is configured with a set of answers to a predetermined set of possible questions. When the VHA receives a question, the VHA may be configured to output an answer from the set of answers. In a second example, the VHA may include a directed acyclic graph (DAG) of states, each directed acyclic graph including rules on how to react to various questions and how to go to various questions. However, such a VHA may only be configured to respond when there is a clear indication of user intent (e.g., the user presses a button "get heart rate") and an entity (answering "please provide the patient's date of birth" with a date).

[0039] Thus, the VHA described herein may include artificial intelligence and be adapted to process natural language (which is a way of taking human input and mapping it to intents and entities). The VHA may be adapted to maintain a state and map that state together with (intent, entity) to an API that can operate. This mapping may be performed by providing the VHA with examples of such mappings to teach the machine learning model. If the VHA is autonomous, the VHA may include predictions or other mechanisms that may trigger the VHA to initiate communication. The VHA may also be configured to change its reactions to make the VHA more human-like (this may also be performed by providing examples to the machine learning training algorithm).

[0040] In addition, the training mechanism utilized may be specific to different VHAs. For example, the listening VHA (and the natural language processing engines of other VHAs) may be trained by using a deep network of natural language with medical language. This may be combined with the taxonomy of the medical field. The EMR VHA and the guideline VHA may receive outputs (intents and entities) from the listening VHA and / or the corresponding natural language processing engine and map the outputs to queries. The VHA may be trained by examples with the best results of existing queries. The predictive VHA may be trained on its own clinical tasks. For example, if the predictive VHA is to predict whether a patient will survive early discharge from the intensive care unit, the predictive VHA may be trained on data of patients who are in the ICU and discharged at different stages.

[0041] Additional VHAs may be included on the server system, such as VHAs specific to patient status. Such an example may include a sepsis VHA that may be connected to a patient communication channel only when the patient is experiencing sepsis or is at risk of developing sepsis. The sepsis VHA may be trained to specifically predict sepsis and obtain treatment guidelines for sepsis. Other VHAs may include a patient comfort VHA (e.g., a VHA configured to detect or predict patient pain, discomfort, hunger, or other symptoms that do not necessarily indicate a specific medical condition, but a care provider may wish to be notified of these symptoms to improve patient comfort), a communication VHA (e.g., a communication VHA that parses communications from caregivers and facilitates information sharing between these VHAs), and / or other VHAs. In addition, various configurations of the VHAs not disclosed above are within the scope of the present disclosure, such as related VHAs grouped into a single VHA (e.g., monitoring and EMR VHAs combined into one medical data VHR).

[0042] A global view of multiple or all patient communication thread-dashboard pairs may be provided via one or more of the care provider device and the hospital operations system 118. For example, selection of a specific thread / dashboard pair to access may be controlled by an access application executed on the collaborative space server system 102 that allows the user to view all relevant patients (e.g., communication thread-dashboard pairs for all patients treated / monitored at a nurse's station may be accessed on a nurse's workstation at the nurse's station, or communication thread-dashboard pairs for all patients treated / monitored by a given care provider may be accessed on his or her mobile device). In some examples, alerts and important events within all relevant communication channels will be represented in the global view. Selection to enter a specific communication channel may be made by the user selecting a patient in the global view (or by explicit voice command), but the selection may also be automated using automated mechanisms that detect the care provider's location relative to the patient (such as via a cursor when entering the vicinity of the patient). to detect location or based on the context of the detected discussion).

[0043] The access application may allow only specific widgets of a communication thread and / or dashboard (such as a patient's blood pressure graph) to be exported, or may allow more complex widgets (such as a patient dashboard or a portion of a thread) to be exported to selected external applications and / or devices. For example, as explained above, a device located off-site at a medical institution may only be allowed to access some patient medical data, and the access application may control which patient medical data can be viewed outside the medical institution.

[0044] The management application executed on the hospital operations system 118 and / or the collaborative space server system 102 may allow an administrator to update the care team that has access to the patient's communication channel as described above. The management application may include an interface for configuring hospital-specific protocols and care guidelines. The management application may also aggregate information from the communication channels for use in predicting hospital operations needs, thereby providing forecasts for capital assets, disposable assets, and human assets based on overall acuity or disease statistics. In addition, analysis of the information on the communication channels may be used to improve the system and its predictors.

[0045] The collaborative space server system 102 includes a communication module 128, a memory 130, and a processor 132 to store and execute communication channel-dashboard pairs, digital twins, and VHAs and to send and receive communications, graphical user interfaces, medical data, and other information.

[0046] The communication module 128 facilitates the transmission of electronic data within and / or between one or more systems. Communication via the communication module 128 can be implemented using one or more protocols. In some examples, communication via the communication module 128 occurs according to one or more standards (e.g., Digital Imaging and Communications in Medicine (DICOM), Health Level Seven (HL7), ANSI X12N, etc.). The communication module 128 can be a wired interface (e.g., a data bus, a universal serial bus (USB) connection, etc.) and / or a wireless interface (e.g., radio frequency, infrared, near field communication (NFC), etc.). For example, the communication module 128 can use any past, current, or future communication protocol (e.g., BLUETOOTH) via a wired local area network (LAN), a wireless LAN, a wide area network (WAN), etc. TM , USB 2.0, USB 3.0, etc.) to communicate.

[0047] The memory 130 is one or more data storage structures, such as an optical memory device, a magnetic memory device, or a solid-state memory device, which is used to store programs and routines executed by the processor 132 to implement the various functions disclosed herein. The memory 130 may include any desired type of volatile and / or non-volatile memory, such as, for example, static random access memory (SRAM), dynamic random access memory (DRAM), flash memory, read-only memory (ROM), etc. The processor 132 may be, for example, any suitable processor, processing unit, or microprocessor. The processor 132 may be a multi-processor system and may therefore include one or more additional processors that are identical or similar to each other and communicatively coupled via an interconnect bus.

[0048] As used herein, the terms "sensor," "system," "unit," or "module" may include hardware and / or software systems that operate to perform one or more functions. For example, a sensor, module, unit, or system may include a computer processor, controller, or other logic-based device that performs operations based on instructions stored on a tangible and non-transitory computer-readable storage medium (such as a computer memory). Alternatively, a sensor, module, unit, or system may include a hard-wired device that performs operations based on the hard-wired logic of the device. The various modules or units shown in the figures may represent hardware that operates based on software or hard-wired instructions, software that instructs hardware to perform operations, or a combination thereof.

[0049] A “system,” “unit,” “sensor,” or “module” may include or represent hardware and associated instructions (e.g., software stored on a tangible and non-transitory computer-readable storage medium, such as a computer hard drive, ROM, RAM, etc.) that performs one or more operations described herein. The hardware may include electronic circuitry that includes and / or is connected to one or more logic-based devices, such as microprocessors, processors, controllers, etc. These devices may be off-the-shelf devices that are appropriately programmed or instructed to perform the operations described herein in accordance with the instructions described above. Additionally or alternatively, one or more of these devices may be hardwired with logic circuitry to perform these operations.

[0050] One or more of the devices described herein may be implemented via a cloud or other computer network. In some examples, for example, users (e.g., patients and / or care providers) may access functionality provided by the collaborative space server system 102 via a software as a service (SaaS) implementation on a cloud or other computer network. In some examples, all or part of the server system 102 may also be provided via a platform as a service (PaaS), infrastructure as a service (IaaS), etc. For example, the server system 102 may be implemented as a cloud-delivered mobile computing integrated platform as a service. For example, a set of consumer-oriented web-based, mobile, and / or other applications enables users to interact with the PaaS. In addition, although the server system 102 is Figure 1 102 as constituting a single entity, it should be understood that the server system 102 may be distributed across multiple devices, such as across multiple servers and / or clouds.

[0051] Although not in Figure 1 102, but the additional devices described herein (care provider device 134, care provider device 136, and care provider device 138, hospital operation system 118, monitoring device 120, EMR database 122, external guideline service 124, external prediction service 126) may also include user input devices, memories, processors, and communication modules / interfaces similar to the communication module 128, memory 130, and processor 132 described above, so the description of the communication module 128, memory 130, and processor 132 is also applicable to the other devices described herein. As an example, a care provider device (e.g., care provider device 134) may store user interface templates in memory that include placeholders for relevant information stored on server system 102. For example, care provider device 134 may store a user interface template for a patient dashboard that a user of care provider device 134 may configure using placeholders for desired patient information. When the dashboard is displayed on the care provider device, relevant patient information may be retrieved from server system 102 and inserted into these placeholders. The patient information may include current patient vital signs, VHA alerts, expected patient status trends, or other information, as explained in more detail below.The user input device may include a keyboard, mouse, touch screen, microphone, or other suitable device.

[0052] Figure 2An exemplary communication thread 200 of a patient-specific communication channel is shown, and thus may be a non-limiting example of a communication thread 104. The communication thread 200 may be displayed on a display device 202. The display device 202 may include a screen on which the communication thread is displayed, and may be coupled to a computing device (such as a care provider device 134) and / or included as part of the computing device. The communication thread 200 may be displayed in response to a user request to display the communication thread. For example, a user (e.g., a care provider) may access a collaborative system interface that includes a global view of all communication threads and dashboards that the user is authenticated to participate in (which may include all patients cared for by the care provider at the medical institution), and may select a desired communication thread to view. Fig.10 200. An exemplary collaboration system interface 1000 is shown in FIG. The collaboration system interface 1000 may be displayed on the display device 202 or other suitable device and may include all patients admitted to a specific ward or unit of a medical institution. As shown, the collaboration system interface 1000 includes identification information for a specified medical institution ("Acute Care Center") and an associated ward of the medical institution ("Ward 1"), and also includes patient-specific communication threads and links to dashboards for patients in that ward of the medical institution. However, in other examples, the patients shown via the collaboration system interface 1000 may be specific to a care provider.

[0053] The collaboration system interface 1000 may include a notification portion, whereby a user viewing the collaboration system interface 1000 may be notified of urgent patient conditions, active communication channel discussions, and other information. For example, the collaboration system interface 1000 includes a notification portion showing that a patient requires attention (e.g., due to deteriorating vital signs) and that there are two new discussions.

[0054] The collaborative system interface 1000 also includes a link to a patient communication thread-dashboard pair. For example, Fig.10 Links to communication thread-dashboard pairs for patient ID 0123, patient ID 1111, patient ID 1234, and patient ID 1235 are shown. As explained above, an identifier can be assigned to each patient, which can be used to identify the patient on the communication thread and dashboard. In other examples, other mechanisms for identifying patients can be used, such as location (e.g., bed 2 in room 4) or actual patient name. Additional patient links can be viewed by scrolling the interface. Each patient link may include related notifications. For example, a link for patient ID 1111 includes a notification that three new messages are available for viewing on the patient's communication channel. A link for patient ID 1234 includes a notification that action is required (e.g., due to detection of hypertension or other important vital signs, which will be explained in more detail below) and a notification that a new message is available on the patient's communication channel.

[0055] Selection of a patient link may launch a communication thread or dashboard for that patient. For example, selection of a link for patient ID 1234 may launch Figure 2 Communication thread 200 for patient ID 1234 is shown and explained in more detail below.

[0056] Back to Figure 2 , the communication thread 200 may include an identification header that identifies the patient being discussed / monitored via the communication thread. In the example shown, the communication thread 200 is specific to patient ID 1234. In the illustrated portion of the communication thread 200, communications occur between a care provider (Dr. Smith) and three virtual health care assistants (i.e., EMR VHA, Predictive VHA, and Guideline VHA). The communication thread 200 is being viewed by Dr. Smith, but any authenticated / approved user may view the communication thread 200. As shown in the first message seen above, Dr. Smith is requesting medical information related to the patient from one of the VHAs by asking for a heart rate graph in natural language ("Can I have a heart rate graph, please?"). In response, the EMR VHA sends an image of the patient's heart rate, which is available from the patient's EMR. The image of the heart rate can be viewed in the communication thread and can also be selected via appropriate user input to be viewed in a different form (such as via a patient dashboard).

[0057] At a later time (e.g., 4:00 p.m.), the predictive VHA outputs an alert / notification in the communication thread indicating a change in the patient's status (here, a deterioration in vital signs). The alert is accompanied by a recommended course of action that the care provider can take, including checking respiratory rate and mental status. The predictive VHA may issue another alert at 5:00 p.m., indicating that sepsis is suspected based on the quick SOFA score (qSOFA), which is due to low systolic blood pressure and a low Glasgow Coma Scale. The alerts issued by the predictive VHA may include, for example, a link to a patient dashboard, allowing the user to select the link to launch the dashboard and view medical data related to these alerts. For example, the alert "Systolic blood pressure less than 100 mmHg" is underlined, indicating that a link to additional information is available. The user can select the link via suitable input (such as via a mouse click, touch input, or voice command). As shown, the user can select the link using cursor 204. As will be explained in more detail below, selecting the link using a first selection (e.g., double-clicking) can launch the patient dashboard (e.g., Figure 3 Selecting the link using a second selection (e.g., clicking or hovering) may initiate a preview in which only the patient's blood pressure graph is shown (as described below with respect to Figure 6 More detailed explanation).

[0058] In response to an alert related to potential sepsis, Dr. Smith requests guidelines at 5:01 p.m. Since the predictive VHA has immediately previously issued an alert related to possible sepsis due to the qSOFA score, the guidelines VHA may assume that the guidelines requested by Dr. Smith include guidelines for sepsis based on the qSOFA score. In response, the guidelines VHA retrieves guidelines related to the qSOFA score from an external guidelines service and outputs these guidelines to the communication thread. As shown, only a portion of these guidelines are displayed in the communication thread. By selecting the link (underlined "qSofa Guidelines"), the user may be taken to a different interface displaying the full guidelines, or the full guidelines may be displayed over the top of the communication thread that is still displayed.

[0059] Although not in Figure 2 , but the communication thread 200 may include a search box / function where the user can search for past messages on the communication thread. For example, the user may enter (via voice or text) a command requesting that all messages related to the patient's heart rate be displayed. A communication thread button 206 and a dashboard button 208 are also displayed on the display device 202. Figure 2 , the user is viewing a communication thread 200 occurring on a communication channel. Thus, the communication thread button 206 is highlighted. To switch to the dashboard for patient ID 1 234, the user can select the dashboard button 208.

[0060] Figure 3 An exemplary dashboard 300 is shown that may be displayed on display device 202 or other suitable device. Dashboard 300 may be displayed in response to user input to communication thread 200 (e.g., by selecting a link within medical information displayed in the communication thread, as explained above) or in response to selection of dashboard button 208. However, dashboard 300 may be displayed in response to other inputs (such as in response to selecting a global view including multiple communication threads and dashboards). Fig.10 The dashboard 300 is displayed based on the user input of the collaborative system interface selecting the dashboard. Figure 3 A sidebar 302 is shown displayed along with a dashboard 300 showing patient dashboards for patients currently being cared for by Dr. Smith. User input to the sidebar may launch different dashboards, for example, Dr. Smith may choose to view each currently available dashboard to quickly assess the status of each patient.

[0061] The dashboard 300 may be configured to display patient medical information based on the current patient status and user-configured settings. For example, a dashboard for a patient being treated for pneumonia at a medical facility may be configured to display different medical information than a dashboard for a patient being treated for stroke at a medical facility. In some examples, when a patient is hospitalized at a medical facility, a dashboard may be automatically generated for the patient based on the reason for hospitalization (e.g., pneumonia), thereby including the most relevant patient medical information for the patient's condition, such as blood oxygen level and respiratory rate. The user may also configure which medical data to view via the dashboard, for example, a doctor caring for a patient may choose to view heart rate instead of respiratory rate.

[0062] The medical information displayed on the dashboard may be obtained from one or more monitoring devices currently monitoring the patient, so that the medical information is displayed on the dashboard in real-time (or near real-time). Additionally or alternatively, the medical information displayed on the dashboard may be obtained from the patient's EMR, a digital twin associated with the patient, and / or a communication thread. As explained above, one or more VHAs may obtain patient medical information from the patient's EMR, monitoring device, guideline service, or other source, and include the obtained medical information as a message in a communication thread on a communication channel. To view the medical information in more detail, the user may select the medical information from the communication thread, where the medical information may then be displayed in the dashboard.

[0063] Additional information may also be displayed via the dashboard, such as patient information (location, demographics, medical history), care provider information (such as which doctors, nurses, and / or other care providers care for the patient), and a timeline of selected or related messages from the communication thread. For example, the latest alerts may be displayed as a timeline on the dashboard.

[0064] Referring to dashboard 300 as an example, patient information 304 is displayed at the top of the dashboard, including patient identification information and location. Care provider information 306 is also displayed in dashboard 300, including the patient's current care provider. In addition, user interface control button 308 is shown, which, when selected, can allow a care provider viewing dashboard 300 to view and interact with the communication thread.

[0065] Dashboard 300 also includes real-time medical information indicators 310. As shown, indicators 310 include SOFA score and blood glucose level, which are depicted as gauge charts with corresponding pointers that move to indicate the current SOFA score and blood glucose relative to a range of possible SOFA scores and blood glucose levels. Figure 3 , but the meter chart may include, for example, color coding for quickly determining normal, intermediate, and high scores / levels. The meter chart shown is exemplary in nature, and the patient medical information may be shown in other forms.

[0066] The dashboard also includes medical history trends, including a first graph 312 depicting mean arterial blood pressure trends (e.g., blood pressure over time) and a second graph 314 depicting blood glucose trends (e.g., blood pressure over time). Figure 3 The illustrated medical history trends may be displayed on the dashboard in response to a request from a user (e.g., in response to a care provider selecting a link to a patient's medical history from a communication thread). Figure 2 As shown, the predictive VHA issues an alert at 5:00 PM that includes a reference to the patient's blood pressure in the form of a link. When the link is selected (eg, via cursor 204), dashboard 300 may be displayed showing a first graph 312 of the patient's blood pressure trend.

[0067] As previously explained, one or more of the virtual health care assistants may be configured to monitor patient vital signs via outputs from monitoring devices, information stored in a digital twin, or other sources. If the vital signs (or other health parameters) meet a predetermined condition, the one or more virtual health care assistants may be configured to output an alert to notify the one or more care providers caring for the patient that a patient follow-up may be required. These alerts may be included in the communication thread, as discussed above. Additionally or alternatively, these alerts may be displayed on the dashboard. As shown, the first graph 312 includes two alerts, each of which is issued when the mean arterial blood pressure drops below a threshold value (such as 80 mmHg). Selection of an alert may trigger the display of a portion of a communication thread that references the alert occurring on a communication channel.

[0068] Therefore, if Figure 4 As shown, in response to user input via cursor 204 to select a second alert (eg, “Alert 2” box) displayed on dashboard 300, Figure 2 Portion 402 of the communication thread 202 is shown displayed above the dashboard 300. The displayed portion 402 may include only the portion of the communication thread that references the medical information that triggered the alert, and may also include additional messages around the message that references the alert to put the alert into context. In this way, the user may be able to quickly determine what else may have occurred around the time the alert was issued, determine whether the care provider who provided the care implemented the treatment, or determine other relevant information. In some examples, portion 402 may not include the most recent message in the communication thread. In addition, the user may not be able to access the entire communication thread when viewing the portion, and may not be able to interact with the communication channel (e.g., send messages). Therefore, different selections on the dashboard may enable the user to view the entire communication thread.

[0069] Additionally or alternatively, while viewing the portion of the communication thread, the user may scroll to view other portions of the communication thread or may enter another input into the portion of the communication thread to enable viewing of the full version of the communication thread. Alternatively, rather than showing a fragment from the communication channel, the full version of the communication thread may be displayed, with the focus being the point in the communication channel that references the alert (which may enable the user to view before and after that point in the thread as desired). In another example, only a fragment of the communication thread may be displayed, and if the fragment is selected, the full version of the communication thread may be displayed. In this way, either automatically or upon further user input, the user may be able to interact with the communication thread (e.g., send a message via the communication thread).

[0070] therefore, Figure 1 The collaborative health care system shown may generate a communication channel-dashboard pair associated with the collaborative health care system for each patient. The collaborative health care system may include one or more computing devices, such as the care provider device 134. The computing device may include a display screen, and the computing device may be configured to display the dashboard on the screen. The dashboard may include patient medical information. The computing device may be further configured to display alerts related to the patient medical information on the screen. For example, Figure 3 As shown, dashboard 300 may be displayed on a screen of a computing device (e.g., display device 202, which may be a screen of a computing device such as care provider device 134). Dashboard 300 may display patient medical information, such as a graph of a patient's blood pressure trend (e.g., first graph 312). The displayed medical information may include alerts, such as alert 2 shown on first graph 312.

[0071] The alert may be selectable to initiate a communication thread between the care provider and the virtual health care assistant. Figure 4 As shown, selection of alert 2 initiates a communication thread between the care provider (Dr. Smith) and the virtual health care assistant (Predictive VHA). Selection of this alert enables a portion of the communication thread that references the displayed patient medical information to be visible within the communication thread. For example, Figure 4 The communication thread 202 is shown displayed in response to the selection of the alert 2. Figure 2 4 (shown in FIG. 4 ). Portion 402 includes a reference to the patient's blood pressure, which is also displayed on the patient dashboard. In addition, the alert can be displayed on the dashboard (at least initially) while the communication thread is in an inactive state. For example, the alert can be displayed on the dashboard 300 while the communication thread is not displayed, such as while the communication thread is inactive. In some examples, the entire communication thread can be displayed instead of just a portion, where the entire communication thread is focused on the portion that references the patient's blood pressure. According to some embodiments, both the communication thread and the dashboard can be displayed simultaneously on the display device.

[0072] In this way, the computing device provides a specific way to display a limited set of information to the user (e.g., specifically referencing the portion of the communication thread of the medical information displayed on the dashboard), rather than using conventional user interface methods to display a general index / list on the computer, which may require the user to step through multiple menus and / or lists of communications and alerts to find the relevant portion of the communication related to the medical information. The dashboard interface-communication thread link disclosed herein can be advantageous because it avoids the user having to scroll and switch views multiple times to find the desired data / function, thereby preventing drilling down multiple layers to obtain the desired data / function (which may be slow, complicated and difficult to learn). The disclosed dashboard interface-communication thread link can improve the efficiency of using the computing device by putting together the portion of the communication thread that is most relevant to the user (because it involves the displayed medical information) and the dashboard that actually displays the medical information, thereby allowing the user to view the most relevant information on the communication thread without actually opening the communication thread. The speed of the user's navigation through various views and windows can be improved because the disclosed link between the dashboard and the communication thread eliminates the need for the user to navigate from the dashboard to the communication thread, open the communication thread, and then navigate within the communication thread so that the portion of interest can be seen or the function of interest can be activated.

[0073] Figure 5 A full version 502 of a communication thread is shown that may be displayed in response to a user input at control button 308 (shown by cursor 204). Full version 502 may include the most recent messages sent on the communication channel. For example, full version 502 includes messages not shown in portion 402 of the communication thread, such as a guideline VHA sent a message at 7:00 PM regarding patient blood glucose levels. Additionally, a user interface user input block is present at the bottom of the communication thread via which a user may type a message to be sent on the communication channel. Due to space limitations, all of the messages on the full version of the communication thread may not be visible at once, so full version 502 may include a prompt to which the user may swipe or enter other input to view additional messages. Additionally, although Figure 5 The full version 502 is shown superimposed on the dashboard 300 , but it should be understood that in other examples the dashboard may be replaced by a communication thread on the display device.

[0074] Figure 6 An example is shown in which a full version 502 of a communication thread is displayed as a separate interface on the display device 202 without additionally displaying a dashboard. Figure 6In the example shown, user input to a link on the communication thread ("Systolic blood pressure is less than 100 mmHg") can trigger display of a preview 600 of the patient's blood pressure. As shown, the preview 600 can include a first graph 312 of the patient's blood pressure over time, including the two alerts discussed previously. For example, the preview 600 can be displayed in response to a click or mouse hover over the link.

[0075] therefore, Figure 1 The collaborative health care system shown may generate a communication thread-dashboard pair associated with the collaborative health care system for each patient. The collaborative health care system may include one or more computing devices, such as the care provider device 134. The computing device may include a display screen, and the computing device may be configured to display the communication thread on the screen. The computing device may also be configured to display a dashboard on the screen that is directly accessible from the communication thread. For example, Figure 2 As shown, the communication thread may include a link that, when selected, launches a dashboard, such as Figure 3 Instrument panel 300 is shown.

[0076] The communication thread displays communications between the care provider and the virtual health care assistant, and the communication thread includes medical information of the patient. At least a portion of the displayed medical information is selectable to launch the dashboard and enable the selected medical information to be visible within the dashboard. For example, see Figure 2 , the communication thread includes a link referencing patient medical information (here, the patient's blood pressure), and selection of the link launches a portion or all of the dashboard. The dashboard includes a display of the patient's medical information included in the link (e.g., a trend in the patient's blood pressure). In one example, selection of the link may launch a full version of the dashboard, such as Figure 2 In another example, selection of the link may launch only a portion of the dashboard, such as Figure 6 The preview shown. Communication threads can be displayed while the dashboard is not started (at least initially). For example, Figure 2 The communication thread is shown displayed without the dashboard being displayed, so the dashboard may be inactive until a link on the communication thread is selected.

[0077] In this way, the computing device provides a specific way to display a limited set of information to the user (e.g., a dashboard specifically including the medical information referenced in the communication thread), rather than displaying a general index / list on the computer using conventional user interface methods, which may require the user to step through multiple menus and / or lists of communications and alerts to find the relevant medical information. The communication thread-dashboard interface link disclosed herein may be advantageous because it avoids the user having to scroll and switch views multiple times to find the desired data / function, thereby preventing drilling down multiple layers to obtain the desired data / function (which may be slow, complicated and difficult to learn). The disclosed communication thread-dashboard interface link can improve the efficiency of using the computing device by putting together (via the dashboard) the medical information most relevant to the user and the communication thread that references the medical information, thereby allowing the user to view the most relevant medical information discussed on the communication thread without actually accessing the electronic medical record or a separate interface that may display patient monitoring data. The speed of the user's navigation through various views and windows can be improved because the disclosed link between the communication thread and the dashboard eliminates the need for the user to navigate to the electronic medical record database, open the database, and then navigate within the database so that the medical information of interest can be seen or the function of interest can be activated.

[0078] Figure 7 700 is a flowchart showing a method 700 of a collaborative health care system serving a medical institution (such as a hospital). Figure 1 The processor 132 of the server system 102) generates a signal according to the non-transitory memory stored in the device (e.g., Figure 1 The method 700 is executed by combining instructions on the memory 130 shown in the figure with various signals received at the server system from components of the collaborative healthcare system (e.g., patient medical data signals from the monitoring device 120, communications from the hospital operations system 118, etc.) and signals sent from the server system to the care provider devices and / or other system components.

[0079] At 702, method 700 includes receiving a notification that a patient has been admitted to a medical facility. The notification may be received from a hospital operations system and may include a patient identifier, a patient status (e.g., the condition for which the patient is admitted), and care provider information. The care provider information may include identifiers of various care providers (such as doctors and nurses) currently caring for the patient.

[0080] At 704, method 700 includes generating a communication channel for the patient including a communication thread and a dashboard. To generate the communication channel, the patient's verified care provider (e.g., as indicated by a notification from a hospital operations system) and one or more virtual health care assistants (VHAs) may be connected to the communication channel, as indicated at 706. The communication channel may facilitate the sending of text-based and / or rich media messages between all verified care providers and VHAs connected to the communication channel. The one or more VHAs may include an EMR VHA, a guideline VHA, a predictive VHA, a listening VHA, a monitoring VHA, and / or other VHAs. To connect to the channel, each VHA may receive a message that a new channel has been opened and an access application (e.g., executed on server system 102) may add the VHA to eligible participants of the channel. In addition, in some examples, not all available VHAs may be invited to all channels (e.g., a sepsis VHA may not be invited in a non-related case, or a listening VHA may not be invited because the patient refuses to be monitored by recording).

[0081] Generating a dashboard may include configuring the dashboard based on the patient status and / or user settings, as indicated at 708. As previously explained, the patient dashboard may be a graphical user interface that facilitates the display of patient medical information (such as real-time vital signs, medical history, treatment plan, and / or other information). The dashboard may also include relevant / expected messages from the communication thread. Which medical information to display on the dashboard and in what format may be determined based on the patient status (e.g., the current medical condition for which the patient is being treated) and / or user settings (which may be configured by the ultimate viewer of the dashboard). In this way, different patients may have different medical information displayed on different dashboards, and different care providers may view different medical information for the same patient as needed.

[0082] At 710, method 700 includes receiving text-based and / or rich media messages from participants on a communication channel, including care providers and VHA. During the process of patient care, care providers may communicate with each other via messages on the communication channel via the communication thread to coordinate care, give care guidance, and / or confirm that appropriate care is being implemented. In addition, the care provider may send a request for various information related to patient care to the VHA via the communication thread, including patient medical history, care guidelines, predicted future patient status, etc. Further, the VHA may send notifications of changes in patient status, patient medical history, patient care guidelines, predicted future patient status, etc. via the communication thread. Messages sent by the care provider may be sent from a care provider device (e.g., device 134) and received at a server system via a suitable connection (e.g., a wired or wireless connection, such as via the Internet). Messages sent from the VHA may be generated by the VHA, which may be stored and executed on a server system, cloud, and / or remote device. As used herein, a message may refer to any suitable information sent and received on a communication thread, including, but not limited to, text messages (entered via typing, touch or stylus input, voice input, or automatically generated by the VHA), images, voice messages (e.g., a recording of voice input), and videos.

[0083] At 712, method 700 includes distributing the received message to other participants on the communication channel and saving the received message as a communication thread. Each message sent to the server system may be tagged with various identifiers (e.g., a patient identifier) ​​that identify the sender and the patient communication thread to which the message belongs. The server system may then send the message to other participants of the communication channel, such as a care provider and / or VHA that did not send the original message, and save the message as part of the saved communication thread. The saved communication thread may then be viewed by other users at other times, retrieved in response to a user request to view a portion or all of the communication thread, etc. However, in some examples, the device from which the original message was sent (e.g., a care provider device) may send the message to all other participants on the communication channel, so the server system may not distribute the message to the other participants.

[0084] At 714, method 700 includes receiving patient medical information. Patient medical information may be received from one or more patient monitoring devices configured to measure patient status and condition, including sensors that measure vital signs (e.g., blood pressure, heart rate, and blood oxygen level), diagnostic imaging modalities, microphones near the patient, and the like. In addition, patient medical information may be received from a communication thread. For example, two care providers may be messaging each other on a communication thread and exchanging information related to the patient, such as visual information of the patient that may indicate the patient's status (e.g., pale, red, or yellow skin). One or more VHAs may be configured to parse the message and determine that relevant medical information is being communicated, and then save the medical information as a message within the communication thread.

[0085] At 716, method 700 includes updating a digital twin of the patient with the medical information. The digital twin may be a digital copy / representation of the patient stored at a computing device (e.g., digital twin 108 stored on server system 102). The digital twin may include patient demographic information, medical history, and other information that provides a simulation / representation of the current patient medical state to the extent possible. When new or updated medical information is received, the digital twin may be updated to reflect the latest patient medical state. The digital twin may be accessed (e.g., by one or more VHAs) to retrieve patient medical information, predict future patient states (e.g., simulations may be performed using information stored in the digital twin to determine the likelihood of a patient developing a certain condition), and provide appropriate context when retrieving care guidelines.

[0086] At 718, method 700 includes outputting the communication thread for display when prompted. In one example, the prompt may include an explicit request to view the patient's communication thread, entered by selection of an appropriate link / control button on the patient dashboard or selection of the patient's communication thread from the collaboration interface, as indicated at 720. For example, Figure 5 As shown, a message button may be displayed via a patient dashboard, and selection of the message button may trigger display of the patient's communication thread. Fig.10As shown, a patient link may be selected to initiate a communication thread from the collaborative system interface. In one example, a communication thread to be displayed may be automatically output in response to a request from one or more VHAs, as indicated at 722. For example, a listening VHA may detect that one or more care providers are discussing a particular patient history, and the listening VHA may send a portion of the communication thread including a reference to the particular history to the care provider's device for display. In another example, the VHA may detect that a patient's vital signs have reached a level that may indicate a potential emergency patient condition, and the VHA may output an alert related to the vital signs on a communication channel. In some examples, the issuance of such an alert may prompt the automatic display of the communication thread on each participant's display device.

[0087] At 724, method 700 includes outputting the dashboard for display when prompted. In one example, the prompt may include an explicit request to view the patient's dashboard, entered by selection of an appropriate link / control button on the communication thread or selection of the patient's dashboard from the collaboration interface, as indicated at 726. For example, Figure 2 As shown, a link to the dashboard can be displayed in the communication thread, and selecting the link can trigger the display of the dashboard for the patient. In one example, the dashboard to be displayed can be automatically output in response to a request from one or more VHAs, as indicated at 728. For example, the listening VHA can detect that the care provider is discussing the patient's current medical status, and can automatically output the dashboard to be displayed on the care provider's device so that the care provider can view the patient's medical information related to the current medical status being discussed displayed in the dashboard. Then, method 700 returns.

[0088] Figure 8 8 is a flow chart illustrating a method 800 of sending medical information to a care provider via one or more virtual health care assistants. Figure 1 The processor 132 of the server system 102) generates a signal according to the non-transitory memory stored in the device (e.g., Figure 1 The method 800 is executed by the instructions on the memory 130 shown in FIG. Figure 1 As explained, the server system 102 may store / execute one or more virtual healthcare assistants (VHAs) configured to perform certain tasks related to providing the patient's medical information to the one or more care providers caring for the patient, as explained below.

[0089] At 802, method 800 includes receiving a message including a request for medical information related to a patient from a care provider. For example, as previously explained, each patient may have a dedicated communication channel, including a communication thread that facilitates communication between the care provider and one or more VHAs treating the patient. When a care provider sends a message on the communication thread, the message may be received at the server system and may be analyzed to determine which patient the care provider is referring to and what information is being requested. The information request may be an explicit request, as indicated at 804, where the care provider explicitly asks for certain medical information, such as "Please send me the patient's heart rate in the last four hours." In other examples, the request may be implicit, as indicated at 806. Implicit requests may include assumptions (in terms of the VHA executing on the server system) that certain medical information may be useful when changes in a patient's vital signs are detected, which are not accompanied by an actual request from the care provider.

[0090] At 808, method 800 includes determining an appropriate VHA for processing the request for medical information. For example, if the request includes a request for a patient's medical history, the EMR VHA may process the request. If the request includes a request for a patient care guide, the guideline VHA may process the request. In some examples, each VHA may process the received message to understand the intent of the message (in natural language) and determine whether the intent of the message includes a task that the VHA is trained / configured to perform. In some examples, the server system may include a central entity that is configured to understand the intent of the message (e.g., based on the natural language of the message) and determine which VHA is best configured to process the request. The mapping from intents (and VHAs) to specific APIs of specific VHAs is then one-to-one, i.e., only one VHA processes one specific intent (or intent-entity combination).

[0091] At 810, method 800 includes retrieving the requested information using the selected VHA. The requested information may be retrieved from the patient's EMR (as indicated at 812) or from the patient's digital twin. In other examples, the requested information may be retrieved from a guidance service or a predictive service, as indicated at 814. In a further example, the requested information may be retrieved from the one or more monitoring devices currently monitoring the patient. At 816, method 800 includes sending a message including the retrieved medical information to a care provider via a communication channel. Then, method 800 returns.

[0092] Fig. 9 is a flow chart illustrating a method 900 for monitoring a patient's status via one or more virtual health care assistants. Figure 1The processor 132 of the server system 102) generates a signal according to the non-transitory memory stored in the device (e.g., Figure 1 The method 900 is executed by the instructions on the memory 130 shown in FIG. Figure 1 As explained, the server system 102 may store / execute one or more virtual healthcare assistants (VHAs) configured to perform certain tasks related to monitoring the state or condition of a patient and notifying a care provider of the patient's state when the state changes, as explained below.

[0093] At 902, method 900 includes monitoring a patient's condition via output from one or more monitoring devices (e.g., monitoring device 120) monitoring the patient, a digital twin of the patient (e.g., digital twin 108), and / or an electronic medical record of the patient. As previously explained, one or more VHAs (such as monitoring VHAs, predictive VHAs, and / or guideline VHAs) may receive medical data related to the patient's state in order to determine whether the patient's condition has changed, predict future patient events, etc. At 904, method 900 includes determining whether one or more parameters of the patient's condition have reached a predetermined condition. The one or more parameters may include currently monitored vital signs or other health parameters, and the one or more parameters reaching a predetermined condition may include the one or more parameters reaching an abnormal condition, such as a condition that may indicate a potential emergency patient condition that requires treatment or evaluation by a care provider. For example, a parameter may include a heart rate, and the heart rate reaching a predetermined condition may include the heart rate reaching a threshold, such as the heart rate falling below a threshold heart rate. The abnormal condition (e.g., a threshold heart rate) may be based on the patient's baseline condition. In the example of heart rate, the patient may have a baseline heart rate of 75 bpm, which may represent an average of multiple heart rates of the patient measured over time while the patient is at rest. The threshold heart rate may be based on the baseline heart rate, such as being equal to the baseline heart rate or being somewhat lower than the baseline heart rate (e.g., 75% of the baseline).

[0094] Other parameters that may be monitored include respiratory rate, blood oxygen saturation, blood glucose, patient mental state, and the like. Reaching the condition may include reaching a certain condition relative to a threshold, such as falling below a threshold (as explained above with respect to heart rate), exceeding a threshold (e.g., a blood glucose level exceeding a threshold may indicate an emergency condition), or other conditions relative to a threshold. In a further example, method 900 does not monitor the value of a given parameter relative to a fixed threshold, but may include detecting whether the parameter has changed (e.g., changed by a threshold amount, such as an increase or decrease of 10% or more). In addition, method 900 may include detecting whether a set of parameters has changed in a specific manner, or may include determining whether one or more parameters indicate a potential health problem. For example, a predictive VHA may be configured to enter a set of parameters (e.g., obtained by a monitoring VHA) into an external predictive service to determine whether the parameters indicate an undiagnosed or untreated medical condition.

[0095] If all parameters have not reached a predetermined (e.g., abnormal) condition, method 900 returns to 902 and continues to monitor the patient's condition. If one or more parameters reach a predetermined condition, method 900 proceeds to 906 to output an alert referencing the one or more parameters. The alert may be output as a message within a communication thread on the patient's communication channel, as indicated at 908. For example, if Figure 2 As shown, it is detected that one of the VHAs (the predictive VHA) sent an alert indicating a deterioration in vital signs on the communication thread for patient ID 1234 at 4:00 p.m.; another set of alerts indicating suspected sepsis due to hypotension and low Glasgow Coma Scale score were sent from the predictive VHA at 5:00 p.m. Additionally or alternatively, the alerts may be output on the dashboard for the patient, as indicated at 910. For example, Figure 3 As shown, two alerts are displayed on the blood pressure trend graph displayed in the instrument panel 300 .

[0096] In some examples, only one parameter may need to reach its condition relative to its threshold in order to trigger an alert. For example, a large drop in heart rate may trigger an alert, regardless of the state of other parameters. In other examples, two or more parameters may need to reach corresponding conditions relative to corresponding thresholds to trigger an alert. For example, a small drop in heart rate plus a drop in blood oxygen saturation may trigger an alert, while a small drop in heart rate alone may not trigger an alert. Thus, a given parameter (e.g., heart rate) may actually be associated with multiple thresholds, such that a drop below a first threshold (e.g., 75% of a baseline heart rate) may trigger an alert, while a drop below a second threshold (e.g., 90% of a baseline heart rate) but not the first threshold may not trigger an alert unless the drop below the second threshold is also accompanied by a specific change in another parameter (e.g., a drop in blood oxygen levels).

[0097] At 912, method 900 optionally includes retrieving corresponding guidelines and outputting these guidelines as messages within a communication thread on the communication channel. For example, if the parameter change detected at 904 indicates the possibility of sepsis (e.g., as determined by the predictive VHA), guidelines for treating sepsis can be output along with an alert indicating the possibility of sepsis. Method 900 then returns.

[0098] The technical effect of generating a communication channel including a communication thread-dashboard pair for each patient is to facilitate communication between the patient's care providers and allow a virtual health care assistant to provide information retrieval and patient monitoring tasks, thereby reducing care provider workload, increasing communication between care providers to avoid redundancy or omission of patient care, and allowing communications occurring on the channel to be saved in a central location accessible to care providers. By saving the communications on the channel, patient medical status, care decisions, etc. can be viewed in context at a later time. The saved communications on the communication channel can be used to automatically populate medical records, reports, or other forms, and can be used for large-scale (e.g., hospital-wide) analysis of treatment guidelines and patient outcomes.

[0099] One example provides a system that includes a display and a computing device that is operably coupled to the display and stores instructions that are executable to: output a patient-specific dashboard to the display, the dashboard including medical information specific to the patient, the dashboard also including a displayed link to a patient-specific communication thread; and in response to a user selecting the link, output a portion of the communication thread to the display, wherein the communication thread includes communications between one or more care providers and one or more virtual health care assistants monitoring the patient. In a first example of the system, the portion of the communication thread output to the display is a portion of the communication thread that references the medical information included on the dashboard. In a second example of the system (which optionally includes the first example), the one or more virtual health care assistants include an electronic medical record (EMR) virtual health care assistant, and wherein the portion of the communication thread includes a first message and a second message, the first message including a request for medical information from a care provider of the one or more care providers to the EMR virtual health care assistant, the second message including medical information sent from the EMR virtual health care assistant, the EMR virtual health care assistant configured to retrieve medical information from the patient's EMR. In a sub-example of the second example, the display is a first display of a client computing device coupled to the computing device via a network, and the first message also includes a request to display the medical information on a second display, the second display coupled to the computing device via the network. For example, the first display may be a screen or monitor of a caregiver computing device, and the second display may be a display present in an operating room or other room of a medical facility where the patient and / or one or more caregivers of the patient are located. The computing device (e.g., the computing device may include the above with respect to Figure 1Instructions on a server system (e.g., the server system) are executable to output at least a second message to be displayed on a second display in response to receiving the first message. In one example, a caregiver operating a caregiver computing device may enter input in the form of a voice command ("Draw a trend of blood pressure over the last 12 hours and send it to the large screen in room 3"), and the EMR VHA may (e.g., using natural language processing) determine the intent of the message, retrieve the blood pressure trend from the patient's EMR or other source (e.g., a digital twin of the patient stored on the server system), and output a graph showing the blood pressure trend to at least a second display. In some examples, the requested medical information may be output above the communication thread, so any display currently viewing the communication thread may also display the requested medical information. If the requested display (e.g., the second display) is not currently displaying the communication thread, the communication thread may be started on the requested display. In this way, multiple displays may be coupled to a computing device (e.g., a server system) via a network, and any one or more of the displays may be commanded to display the requested information. In a third example of the system (which optionally includes one or both of the first and second examples), the one or more virtual health care assistants include a predictive virtual health care assistant, and the portion of the communication thread includes a message sent by the predictive virtual health care assistant, the message including an alert notifying the one or more care providers that a parameter of the medical information has reached a predetermined condition. In some examples, the message including an alert notifying the one or more care providers that a parameter of the medical information has reached a predetermined condition may be sent by a monitoring virtual health care assistant rather than a predictive virtual health care assistant. In some examples, the parameter reaching a predetermined condition may include the parameter reaching a certain condition relative to a threshold, such as falling below a threshold or rising above a threshold. In a fourth example of the system (which optionally includes one or more or each of the first to third examples), the one or more virtual health care assistants include a guidance virtual health care assistant, and wherein the portion of the communication thread includes a message sent by the guidance virtual health care assistant to the one or more care providers, the message including a guide for treating or diagnosing a patient state associated with the parameter of the medical information. In a fifth example of the system (which optionally includes one or more or each of the first to fourth examples), the parameter of the medical information includes a rapid sequential organ failure assessment (qSOFA) score, wherein the parameter of the medical information reaches a certain condition relative to a threshold value includes the qSOFA score exceeding the threshold score, and wherein the guidelines include guidelines for diagnosing and / or treating sepsis based on the qSOFA score. In a sixth example of the system (which optionally includes one or more or each of the first to fifth examples), the portion of the communication thread includes a second link to the dashboard, and the instructions are further executable to output the dashboard to the display in response to the user selecting the second link.In a seventh example of the system (which optionally includes one or more or each of the first to sixth examples), the one or more virtual health care assistants are configured to communicate on the communication thread using natural language, and the communication between the one or more care providers and the one or more virtual health care assistants on the communication channel includes one or more of text-based communication, audio-based communication, image-based communication, and video-based communication. In an eighth example of the system (which optionally includes one or more or each of the first to seventh examples), the link is displayed within the medical information on the dashboard. In a ninth example of the system (which optionally includes one or more or each of the first to eighth examples), the link is a first link, wherein the dashboard also includes a second link, and wherein the instructions are executable to output a complete version of the communication thread to the display in response to the user selecting the second link.

[0100] One example provides a computing device including a display screen, the computing device being configured to display a dashboard including patient medical information on a screen, and further configured to display an alert related to the patient medical information on the screen, wherein the alert is selectable to initiate a communication thread between a care provider and a virtual health care assistant and enable a portion of the communication thread referencing the displayed patient medical information to be visible within the communication thread, and wherein the alert is displayed while the communication thread is in an unstarted state. In a first example of the computing device, the virtual health care assistant is configured to obtain the patient medical information from one or more of an electronic medical record of the patient, a medical device monitoring the patient, and a digital twin of the patient. In a second example of the computing device (which optionally includes the first example), the virtual health care assistant is configured to output an alert to be included on the dashboard in response to detecting that a parameter of the patient medical information has reached a predetermined condition such as reaching (e.g., exceeding or falling below) a threshold. In a third example of the computing device (which optionally includes the first example and / or the second example), the virtual health care assistant is further configured to output the alert to include as a message of the communication thread, and wherein the message is included in the portion of the communication thread referencing the patient medical information. In a fourth example of a computing device (which optionally includes one or more or each of the first to third examples), patient medical information is obtained by a virtual health care assistant in response to a request from a care provider. In a fifth example of a computing device (which optionally includes one or more or each of the first to fourth examples), the virtual health care assistant is configured to output an alert to be included on a dashboard in response to the virtual health care assistant determining a predicted condition of the patient based on one or more of a digital twin of the patient, outputs from a medical device monitoring the patient, and an external prediction service. In a sixth example of a computing device (which optionally includes one or more or each of the first to fifth examples), the portion of the communication thread can be initiated via a first selection of the dashboard, and the full version of the communication thread can be initiated via a second selection of the dashboard.

[0101] One example provides a computing device including a display screen, the computing device being configured to display a communication thread on the screen, and further configured to display a dashboard directly reachable from the communication thread on the screen, wherein the communication thread displays communications between a care provider and a virtual health care assistant, the communication thread includes medical information of a patient, at least a portion of the displayed medical information is selectable to launch the dashboard and enable the selected medical information to be visible within the dashboard, and wherein the communication thread is displayed while the dashboard is in an unlaunched state. In a first example of the computing device, the communication thread includes one or more of a first message, a second message, a third message, and a fourth message, and communications between a plurality of care providers, the first message including a request from the care provider for electronic medical record data of the patient, the second message including the electronic medical record data of the patient from the virtual health care assistant, the third message including a request from the care provider for a guideline related to the patient's medical information, and the fourth message including the guideline from the virtual health care assistant. In a second example of the computing device (which optionally includes the first example), the portion of the displayed medical information that is selectable to launch the dashboard includes a link displayed within the displayed medical data. In a third example of a computing device (which optionally includes one or both of the first and second examples), the portion of the displayed medical information selectable to launch the dashboard includes a link on a displayed text communication from the virtual healthcare assistant.

[0102] One example provides a method that includes generating multiple patient-specific communication channels, each of which includes a patient-specific dashboard and a patient-specific communication thread. The method also includes, for a selected communication channel, storing text-based and / or rich media messages between a care provider monitoring the patient and a virtual health care assistant on a communication thread of the selected communication channel, at least a portion of the messages on the communication thread including patient-specific medical data; and in response to a prompt, outputting at least a portion of the communication thread including the patient-specific medical data to a display. In a first example of the method, the prompt includes a user selection of a link displayed in a dashboard of the selected communication channel. In a second example of the method (which optionally includes the first example), outputting at least the portion of the communication thread including the patient-specific medical data to the display includes outputting a first message by a care provider requesting the patient-specific medical data and outputting a second message by the virtual health care assistant providing the requested patient-specific medical data.

[0103] Another example provides a method comprising generating a plurality of patient-specific communication channels, wherein each channel comprises a patient-specific dashboard and a patient-specific communication thread. The method further comprises, for a selected communication channel, outputting to a display at least a portion of a communication thread of the selected communication channel, the communication thread comprising communications between a care provider monitoring the patient and a virtual health care assistant; and in response to a user selection of a link displayed in the communication thread, outputting to the display a dashboard of the selected communication channel. In a first example of the method, the method further comprises storing text-based and / or rich media messages on the communication thread of the selected communication channel, the messages on the communication thread comprising patient-specific medical data, and wherein the links displayed in the communication channel comprise links displayed within the patient-specific medical data. In a second example of the method (which optionally comprises the first example), outputting to the display a dashboard comprises outputting a dashboard comprising patient-specific medical data.

[0104] In another representation, a method includes generating a patient-specific collaboration channel including a patient-specific dashboard and a communication thread between a care provider and a virtual health care assistant monitoring the patient; storing text-based and / or rich media messages on the communication thread between the care provider and the virtual health care assistant at the channel, at least a portion of the messages on the communication thread including patient-specific medical data; and outputting at least a portion of the communication thread including the patient-specific medical data to a display device in response to a prompt. In one example, the prompt may be automatic (e.g., based on an alert / detection of a condition from a virtual health care assistant running in the background). In one example, the prompt may include manual interaction with the channel.

[0105] As used herein, the elements or steps listed in the singular and beginning with the word "one" or "a kind of" should be understood as not excluding a plurality of the elements or steps, unless such exclusion is explicitly stated. In addition, the reference to "an embodiment" of the present invention is not intended to be interpreted as excluding the existence of additional embodiments that also include the cited features. In addition, unless explicitly stated to the contrary, the embodiment of "including", "comprising" or "having" an element or multiple elements with a specific characteristic may include additional such elements without the characteristic. The terms "including" and "in..." are used as the concise language equivalents of the corresponding terms "including" and "wherein". In addition, the terms "first", "second" and "third" etc. are only used as marks, and are not intended to impose numerical requirements or specific positional order on their objects.

[0106] This written description uses examples to disclose the invention, including the best mode, and also to enable a person of ordinary skill in the relevant art to practice the invention, including making and using any devices or systems and performing any included methods. The patentable scope of the invention is defined by the claims, and may include other examples that occur to a person of ordinary skill in the art. Such other examples are intended to fall within the scope of the claims if they have structural elements that do not differ from the literal language of the claims, or if they include equivalent structural elements with minor differences from the literal language of the claims.

Claims

1. A system comprising: monitor; and a computing device operably coupled to the display and storing instructions executable to: outputting to the display a patient-specific dashboard, the dashboard comprising a graph of a parameter of medical information specific to the patient, the dashboard further comprising a displayed first link to a patient-specific communication thread, the first link being included in the graph of the parameter of the medical information; and In response to a user selecting the first link, a portion of the communication thread is output to the display, wherein the communication thread includes communications between one or more care providers and one or more virtual health care assistants monitoring the patient, the portion of the communication thread output to the display includes a reference to the parameter of the medical information, and at least one medical data point in the graph of the parameter of the medical information of the patient indicating that the patient is suspected of having a specific condition.

2. The system of claim 1 , wherein the one or more virtual health care assistants include an electronic medical record (EMR) virtual health care assistant, and wherein the portion of the communication thread includes a first message and a second message, the first message including a request for the medical information from a care provider among the one or more care providers to the EMR virtual health care assistant, the second message including the medical information sent from the EMR virtual health care assistant, the EMR virtual health care assistant being configured to retrieve the medical information from the patient's EMR.

3. A system according to claim 2, wherein the display is a first display of a client computing device coupled to the computing device via a network, wherein the first message also includes a request to display the medical information on a second display, the second display is coupled to the computing device via the network, and wherein the instructions are executable to output at least the second message to be displayed on the second display in response to receiving the first message.

4. The system of claim 1 , wherein the one or more virtual health care assistants include a predictive virtual health care assistant, and wherein the portion of the communication thread includes a message sent by the predictive virtual health care assistant, the message including an alert notifying the one or more care providers that the parameter of the medical information has reached a predetermined condition.

5. The system of claim 4, wherein the alert is selectable to initiate a preview of the graph of the parameter of the medical information.

6. The system of claim 1 , wherein the one or more virtual health care assistants include a guidance virtual health care assistant, and wherein the portion of the communication thread includes a message sent by the guidance virtual health care assistant to the one or more care providers, the message including guidance for treating or diagnosing a patient condition associated with the parameter of the medical information.

7. The system of claim 1, wherein the portion of the communication thread includes a second link to the dashboard, and wherein the instructions are further executable to output the dashboard to the display in response to the user selecting the second link.

8. The system of claim 1 , wherein the one or more virtual health care assistants are configured to communicate on the communication thread using natural language, and wherein the communication between the one or more care providers and the one or more virtual health care assistants on the communication thread comprises one or more of text-based communication, audio-based communication, image-based communication, and video-based communication.

9. A system according to claim 1, wherein the dashboard also includes a second link, and wherein the instructions are executable to output a complete version of the communication thread to the display in response to the user selecting the second link, the complete version of the communication thread including the portion of the communication thread and one or more additional messages of the communication thread.

10. A method comprising: generating a plurality of patient-specific communication channels, wherein each communication channel includes a patient-specific dashboard and a patient-specific communication thread; as well as For the selected communication channel, storing messages between a care provider monitoring the patient and a virtual health care assistant on the communication thread of the selected communication channel, at least a portion of the communication thread including patient-specific medical data; as well as In response to a prompt for a user selection of a link, at least a portion of the communication thread including the patient-specific medical data is output to a display, wherein the link is displayed within a graph of the patient's medical device data displayed on the display, and the patient-specific medical data included in at least a portion of the communication thread includes at least one medical device data point in the graph of the patient's medical device data indicating that the patient is suspected of having a specific condition.

11. A method according to claim 10, wherein the message comprises a text-based and / or rich media-based message, and the patient-specific medical data included in at least a portion of the communication thread includes an indication from the virtual healthcare assistant that the patient is suspected of having a specific condition based on the at least one medical device data point.

12. The method of claim 10, wherein outputting to the display at least a portion of the communication thread including the patient-specific medical data includes outputting a first message by the care provider requesting the patient-specific medical data and outputting a second message by the virtual health care assistant providing the requested patient-specific medical data.

13. A method comprising: generating a plurality of patient-specific communication channels, wherein each channel includes a patient-specific dashboard and a patient-specific communication thread; as well as For the selected communication channel, storing messages between a care provider monitoring the patient and a virtual health care assistant on the communication thread of the selected communication channel, at least a portion of the communication thread including patient-specific medical data; In response to a user selection of a link, at least a portion of the communication thread including the patient-specific medical data is output to a display, wherein the link is displayed within a graph of the patient's medical device data displayed on the display, and the patient-specific medical data included in at least a portion of the communication thread includes at least one medical device data point in the graph of the patient's medical device data indicating that the patient is suspected of having a specific condition.

14. The method of claim 13, wherein the patient-specific medical data included in the at least a portion of the communication thread includes an indication from the virtual healthcare assistant that the patient is suspected of having a specific condition based on the at least one medical device data point.

15. The method of claim 14, wherein the graph of the patient's medical device data comprises a graph of the patient's blood pressure, the particular condition is sepsis, and the at least one medical device data point is a blood pressure value of the patient indicative of sepsis.

Images