Method and system for a healthcare provider assistance system

Abstract

The present invention provides various methods and systems for a healthcare provider assistance system. In one example, a system includes: a human-machine interface; and a computing device operably coupled to the human-machine interface and configured to execute instructions stored in a memory to: execute a plurality of different algorithms, wherein the input of each of the plurality of different algorithms includes current and past data representing the health and current condition of a patient, wherein each of the plurality of different algorithms uses the same data or a subset of the same data for input; output a list of a first number of possible diagnoses for the patient to the human-machine interface based on outputs of the plurality of different algorithms executed; and present, via the human-machine interface, a suggested next action for narrowing down the first number of possible diagnoses, the suggested next action being determined based on the outputs of the plurality of different algorithms executed.

Description

Technical Field

[0001] Embodiments of the subject matter disclosed herein relate to healthcare diagnosis of patients, and in particular, to using electronic interfaces to provide assistance in diagnosing patients. Background Art

[0002] Health care providers (e.g., physicians, nurse practitioners, and physician assistants) utilize a thought process called differential diagnosis when diagnosing a patient. Differential diagnosis involves determining multiple possible diagnoses for a patient's disease based on available patient health data and the patient's symptoms. The physician then narrows down the differential diagnosis by performing additional diagnostic tests or evaluating the patient's additional health data until he / she is confident that he / she has identified the correct diagnosis. Collecting a patient's health data for differential diagnosis may involve the care provider searching for medical information about the patient in multiple different hospital (or clinic) information systems (e.g., referred to as "Health Care Information Technology (HCIT) Systems"). This process can be time-consuming and error-prone, especially when the patient has an extensive medical history. In addition, when performing differential diagnosis and deciding how to treat the patient, the care provider may need to consult available medical standards and guidelines, or call these medical standards and guidelines from memory. This may also be time-consuming and / or cause the care provider to miss a possible diagnosis. Summary of the Invention

[0003] In one embodiment, a system includes: a human-machine interface; and a computing device that is operably coupled to (e.g., via a wired or wireless connection, such as via the Internet, Bluetooth, the cloud, etc.) the human-machine interface and is configured to execute instructions stored in a memory to: execute a plurality of different algorithms, wherein the input to each of the plurality of different algorithms includes current and past data representing the patient's health and current condition, wherein each of the plurality of different algorithms uses the same data or a subset of the same data for the input; output a list of a first number of possible diagnoses for the patient (e.g., the patient's diseases or conditions) to the human-machine interface based on the output of the plurality of different algorithms executed; and present, via the human-machine interface, a suggested next action for narrowing down the first number of possible diagnoses, the suggested next action being determined based on the output of the plurality of different algorithms executed.

[0004] It should be understood that the above brief description is provided to introduce in 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 uniquely 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 from the following description of non-limiting embodiments with reference to the accompanying drawings, in which:

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

[0007] Figure 2 Shown Figure 1 An exemplary schematic diagram of a specific implementation of a healthcare provider assistance system.

[0008] Figure 3 A first exemplary user interface display of a differential diagnosis list view for a patient's diagnostic record is shown.

[0009] Figure 4 A second exemplary user interface display of a detailed diagnostic summary page for a patient's diagnostic record is shown.

[0010] Figure 5 A third exemplary user interface display of a summary report view for a patient's diagnostic record is shown.

[0011] Figure 6 A fourth exemplary user interface display of an algorithm report for a patient's diagnostic record is shown.

[0012] Figure 7 A fifth exemplary user interface display is shown of a detailed algorithm report for a patient's diagnostic record.

[0013] Figure 8 A sixth exemplary user interface display of a patient status report for a patient's diagnostic record is shown.

[0014] Figure 9 A flow chart illustrating an exemplary method for providing assistance to a healthcare provider in diagnosing and caring for a patient is shown. DETAILED DESCRIPTION

[0015] The following description relates to various embodiments of a healthcare provider assistance system that compiles patient health data from multiple sources and provides guidance to the healthcare provider in diagnosing and caring for the patient based on the output of one or more algorithms run on the compiled data. Figure 1An exemplary healthcare provider assistance system is shown in the figure, which includes a server system that is in electronic communication with a healthcare provider device and multiple external services, databases, and monitoring devices. The server system may employ one or more processors and / or modules to generate a digital representation of a patient's health by compiling and integrating multiple sources of patient health data (including data obtained in real time and past patient data). In some embodiments, the digital representation of the patient's health may be raw patient health data. In other embodiments, the digital representation of the patient's health may be raw patient health data that has been compiled and manipulated to be more usable as input to the algorithms discussed herein. Single and / or multiple algorithms stored and executed at the server system may be run on the digital representation of the patient's health (as input to each algorithm) to perform a virtual differential diagnosis on the patient. The output of the single and / or multiple algorithms may be used to form a diagnostic record for the patient, which may be presented to the healthcare provider in various user interfaces, which may include various human-machine interfaces such as displays, audio interfaces, etc., such as Figure 2 The diagnostic record may include healthcare insights about the patient, such as current possible diagnosis, future possible diagnosis, etc. An exemplary user interface displayed via a healthcare provider display device is shown in FIG. Figures 3 to 8 . In one example, a user interface display may include a visualization of a list of possible diagnoses determined based on the outputs of multiple algorithms. In some examples, each possible diagnosis in the list may have an associated estimated probability that may also be presented to the user. The user interface display may also present a list of subsequent actions to be performed to narrow down the list of possible diagnoses. For each diagnosis, the user interface may also provide data elements that contribute to the diagnosis. In this way, the healthcare provider assistance system can use patient data compiled from multiple different sources to suggest a differential diagnosis for a patient's condition, and present the differential diagnosis, patient health data, and suggested actions to the healthcare provider in an organized and efficient format. Therefore, healthcare providers may be able to make more accurate diagnoses while saving time and effort that can be focused on higher-level tasks.

[0016] Figure 1 An exemplary healthcare provider assistance system 100 that can be implemented in a healthcare facility, such as a hospital, office, clinic, or remote location of a healthcare provider, is schematically illustrated. The healthcare provider assistance system 100 may include a server system 102. The server system 102 may include resources (e.g., memory 130, processor 132) that may be allocated to store and execute diagnostic records for each of a plurality of patients (which may include one or more diagnostic records, including outputs or results of a plurality of algorithms, as further explained below) and a digital twin. For example, Figure 1As shown, diagnostic records 104 and digital twins 108 are stored on server system 102 for a first patient (Patient 1); multiple additional diagnostic records and digital twins may be stored on server system 102, each corresponding to a respective patient (Patient 2 through Patient N).

[0017] As further explained herein, patient medical information (including medical history, current status, vital signs, and other information) can be input into the digital twin 108, which can be used as a basis for caregiver situational awareness, the patient's clinical environment and medical history to facilitate predicted patient status, acquisition of relevant treatment guidelines, patient status diagnosis, alternative diagnosis, or future prediction of patient diagnosis, etc. As further explained below, the digital twin 108 can be used as input to multiple algorithms configured to facilitate patient diagnosis. Multiple algorithms can predict the patient's health state, predict a specific diagnosis based on the digital twin, etc. The diagnostic record 104 can include patient diagnostic data and health state data obtained (e.g., generated or compiled) from the output of multiple algorithms.

[0018] As used herein, "diagnosis" can refer to the current or future predicted state of a patient. For example, the diagnostic record 104 can present a list of current possible diagnoses for a patient's state, or a trend toward a future diagnosis or future state (e.g., a change thereof) for the patient. As an example, if the patient's current health state continues, the system described herein can present information to a health care provider indicating how long the patient has before reaching a specific state or condition (e.g., septic shock). In this way, the diagnostic record described herein can provide actionable information, typification, grouping, classification, or identification of significant elements about the patient's current state, and / or predictions about the patient's future state, which can be used to make care decisions.

[0019] The diagnostic record 104 (which may include one or more different types of diagnostic reports) may be presented via one or more suitable human interface devices (such as displays and / or audio devices) that may be associated with corresponding care provider devices and / or medical institution management devices. Figure 1As shown, multiple 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), an audio interface 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, a smart watch, a smart speaker, wearable goggles, another type of audio device (such as a listening device in the form of headphones), or other such devices. Each care provider device may be suitable for sending and receiving encrypted data and displaying medical information (including medical images and non-medical images in a suitable format such as Digital Imaging and Communications in Medicine (DICOM) or other standards). The care provider devices may be located locally at the medical facility (such as in a nurse's station or in a patient's room) and / or remotely at the medical facility (such as a mobile device of a care provider). In addition, the server system 102 may be located locally at the medical facility or remotely from the medical facility.

[0020] When reviewing the diagnostic record 104 via a human-machine interface (such as a display or audio interface 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 link to a user interface of the diagnostic record or the selection of a user interface control button, the user input may trigger the display of different user interfaces or display states of the diagnostic record, each of which may present the output of the algorithm in a different format with a different amount of information, as further described below.

[0021] The server system 102 is communicatively coupled to a hospital operations system 118. The hospital operations system 118 can 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 facility), patient care plans and workflows, diagnostic test results, and care provider information (including which care providers monitor / treat which patients). Furthermore, 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 devices 120 may include conventional medical devices for monitoring respective patients, such as pulse oximeters, heart rate monitors, blood glucose monitors, ECGs, as well as microphones, cameras, continuous blood pressure wristbands, and other devices. The monitoring devices 120 may send output directly to the server system 102 and / or may send output to the EMR database 122. For example, a plurality of monitoring devices monitoring patient 1 may be configured to send output to the server system 102, which may then store and analyze the received output. The server system 102 may then transmit the analyzed data or a report based on the analyzed data to a care provider device (care provider device 134 ).

[0022] The hospital operations system 118 can direct the creation of each diagnostic record and control access to each diagnostic record. 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 push notification of the newly admitted patient to the server system 102. In an alternative embodiment, the server system 102 can periodically query the hospital operations system 118 to identify newly admitted patients. After the server system 102 receives a signal indicating that a new patient has been admitted and / or determines that a new patient has been admitted based on the queried information, the server system 102 can continue to generate diagnostic records for the patient, as further described below.

[0023] After the care provider reviews the patient and enters health data, the care provider may initiate the creation of an updated diagnostic record 104 based on the output of multiple algorithms running on the digital twin 108, for example, via the care provider device 1. In still other embodiments, the created diagnostic record may be continuously updated as the server system 102 receives new patient health data.

[0024] The server system 102 may also store (e.g., in memory 130) instructions for a plurality of data acquisition modules and algorithms 135 and be configured to execute (e.g., via processor 132) the plurality of data acquisition modules and algorithms. The data acquisition module may acquire patient health data, standards and guidelines, and historical and demographic data (related to the patient, related to other patients, or data derived from historical data, as further described below) from external sources. The algorithm 135 may then use the acquired data (compiled into a digital twin and incorporated into the digital twin) to generate a diagnostic record 104. The algorithm 135 may be part of a unique module or may be part of the data acquisition module described below. As shown, the server system 102 includes an electronic medical record (EMR) module 110, a standards / guideline module 112, a historical and demographic data module 114, a non-medical sensor module 116, and a monitoring module 117. The modules may be implemented as several modules (each serving a different purpose), various groups of modules, or as one overall module representing all the different external data collected and used by the algorithm 135 for generating the diagnostic record 104 .

[0025] The EMR module 110 is configured to retrieve and / or receive patient information from an electronic medical record database (such as an EMR database 122). The processor 132 can then use the retrieved patient information to generate a digital twin 108 of the patient. The EMR database 122 can be an external database that the EMR module 110 can access via a secure hospital interface, or the EMR database 122 can be a local database (e.g., housed on a device at the hospital). The EMR database 122 can be a database stored in a large-capacity storage device that is configured to communicate with a secure channel (e.g., HTTPS and TLS) and store data in encrypted form. In addition, the EMR software 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. Therefore, the EMR module 110 serves as a connection to the EMR database. The EMR module may also update the patient's EMR database based on the patient's generated digital twin 108 and diagnostic records 104 .

[0026] The guideline module 112 is configured to retrieve relevant care guidelines from the external guideline service 124. The guideline module 112 can retrieve different care guidelines based on the different algorithms being run and / or based on the output of the algorithms. For example, based on one or more diagnoses predicted based on the output of multiple algorithms 135, the processor 132 can request the guideline module 112 to retrieve guidelines for those specific diagnoses, and then use the algorithm outputs and the guidelines to generate information in the diagnostic record. In another example, the algorithm can use the care guidelines retrieved from the guideline module 112 as additional input to the algorithm for generating the diagnostic record 104, and can request specific care guidelines from the guideline module 112 during the operation of one or more of the multiple algorithms. In one embodiment, the guideline module 112 can search a priori indexes of available guideline data to retrieve relevant care guidelines. In another embodiment, a search for guideline data can be performed for relevant references, guidelines, standards, etc. via the guideline module.

[0027] For example, different algorithms may predict the onset or presence of different medical conditions (e.g., sepsis, diabetes, acute kidney injury, etc.), and if the output of the algorithm indicates that a particular diagnosis is possible, the guideline module may automatically retrieve criteria and guidelines for the particular diagnosis (e.g., treatment guidelines, additional indications of disease state, etc.). The algorithm 135 may then use the retrieved criteria and guidelines to present (e.g., display or transmit via an audio device) relevant guidelines to the care provider and / or generate a recommendation or subsequent action (e.g., a diagnostic test to be run on the patient) as part of the diagnostic record 104 based on the diagnosis identified by the caregiver through normal human insight and request or identified by the mechanism of multiple algorithms 135.

[0028] 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 within 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 server system 102. In addition, the external guideline service 124 may include differential diagnosis trees that the guideline module 112 may access to determine potential diagnoses based on the patient's condition or state via the algorithm 135.

[0029] For example, the guidelines module 112 may input specific search terms into the guidelines service 124 based on the patient's status and symptoms (e.g., a SOFA score of five, a blood glucose level of 190 mg / dL), or the guidelines module 112 may specifically query for guidelines for a given condition (e.g., sepsis) based on the specific algorithm being run and / or based on the diagnosis output via the plurality of algorithms 135.

[0030] The historical and demographic data module 114 is configured to retrieve historical and / or demographic medical data related to different patient populations and medical conditions from an external historical and demographic data service 126. This external historical and demographic data service may be similar to the external guideline service 124 described above, but contains historical and / or demographic medical data categorized by patient population and medical condition. The historical and / or demographic medical data may also include data derived from the historical data, such as parameters for a machine learning model. The external historical and demographic data service 126 may be a remote service accessed via a network, or it may be a local service executed on a computing device at the hospital. As an example, based on the digital twin 108 generated for a patient, the historical and demographic data module 114 may retrieve historical records (including actual outcomes) for other patients (e.g., previous patients) whose digital twins match or are closest to the current patient's digital twin. The algorithm 135 may then use this retrieved historical data to generate recommendations, follow-up actions (e.g., to narrow down diagnoses), present similar patients to healthcare providers, and / or diagnoses indicated for the diagnostic record 104.

[0031] The non-medical sensor module 116 is configured to receive output from the non-medical sensors 121 and can track a patient condition or status based on the received output. In other embodiments, the non-medical sensor module 116 is configured to receive output from the non-medical sensors 121 (also referred to as monitoring devices) and transfer the received output to the processor 132 to generate the digital twin 108. In this way, the processor 132 can retrieve the output received from the non-medical sensors and use them to generate the digital twin 108. The non-medical sensors may include various cameras, microphones, and non-medical grade sensing devices (such as a continuous blood pressure wristband) attached to the patient or attached near the patient (e.g., in the same room as the patient).

[0032] The monitoring module 117 is configured to receive outputs from the medical sensors and devices of the monitoring device 120 and can track the patient's condition or state based on the received outputs. The processor 132 can retrieve the outputs received from the medical sensors and devices and use them to generate the digital twin 108.

[0033] The above modules (e.g., modules 110, 112, 14, 116, and / or 117) may work together in conjunction with the algorithm 135 and the generation of the digital twin 108 via one or more processors 132. For example, the modules may be configured to process a patient's medical information (e.g., vital signs, medical history, current symptoms) received from a patient EMR, monitoring equipment, care provider, and / or other source, and then transfer that information to the processor 132 for use in generating the patient's digital twin 108. The modules may be further configured to retrieve specific data for use by the algorithm 135 when generating the diagnostic record 104. Additionally, the modules and / or algorithms may include one or more machine learning algorithms trained using optimization methods. In some embodiments, medical terminology data may be used to train one or more trained machine learning algorithms. In this way, the modules may be accessed by similar modules configured to execute the algorithm 135, and / or the modules may be part of or combined into a single module suitable for running the algorithm 135. Further description of the algorithm 135 will be referenced below. Figure 2 Provide a description.

[0034] The server system 102 includes a communication module 128 , memory 130 , and a processor 132 to store and execute digital twins, diagnostic records, algorithms, and modules, as well as to send and receive communications, graphical user interfaces, audio communications or interfaces, medical data, and other information.

[0035] 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. 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 communicate via a wired local area network (LAN), a wireless LAN, a wide area network (WAN), etc. using any past, present, or future communication protocol (e.g., BLUETOOTH). TM , USB 2.0, USB 3.0, etc.) to communicate.

[0036] Memory 130 includes one or more data storage structures, such as optical memory devices, magnetic memory devices, or solid-state memory devices, for storing programs and routines executed by processor 132 to implement the various functions disclosed herein. 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. Processor 132 may be, for example, any suitable processor, processing unit, or microprocessor. Processor 132 may be a multi-processor system and, therefore, may include one or more additional processors that are identical or similar to each other and communicatively coupled via an interconnect bus.

[0037] 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 device's hard-wired logic. 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.

[0038] 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, and the like. 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 the operations.

[0039] 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 server system 102 via 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 (SaaS or PaaS), Infrastructure as a Service (IaaS), or the like. 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. Additionally, while the server system 102 may be Figure 1 1 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.

[0040] Although not in Figure 1 130, and processor 132. Although not explicitly shown in FIG, the additional devices described herein (care provider device 134, care provider device 136, and care provider device 138, hospital operations system 118, monitoring device 120, EMR database 122, external guideline service 124, and external history and demographics 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, and thus the description of the communication module 128, memory 130, and processor 132 also applies to the other devices described herein. The user input devices of the care provider devices may include a keyboard, mouse, touch screen, microphone, or other suitable device.

[0041] As used herein, the computing device of system 100 may include one or more of server system 102 and a care provider device (e.g., a processor and display and / or audio interface of the care provider device). Figure 2 To explain further, the server system 102 can output a graphical user interface for display on a display device, which can include a display screen of a care provider device (e.g., a smart phone, smart watch, smart speaker, table, laptop computer, and / or desktop computer). In other embodiments, the server system 102 can output an audio file for transmission to the user via an audio interface (e.g., a microphone) of the care provider device. The graphical user interface and / or audio interface can have different forms, as further described below, and present data in a format different from the diagnostic record 104.

[0042] Figure 2 Shown Figure 1FIG20 is an exemplary schematic diagram 200 of an implementation of the healthcare provider assistance system 100 for a healthcare provider. Specifically, the schematic diagram 200 illustrates the flow of data and information into the plurality of algorithms 135 from the various sources described above with reference to the system 100, as well as the output from the algorithms 135. The schematic diagram 200 illustrates a digital twin 108 and diagnostic record 104 for a single exemplary patient. However, as described above, the server system 102 may have a unique digital twin 108 and diagnostic record 104 for each patient seen at a hospital, clinic, or medical facility.

[0043] Schematic diagram 200 shows various data inputs into the digital twin 108, including EMR data 210, monitoring equipment data 217, diagnostic data 218, and non-medical sensor data 216. Figure 2 Four data inputs are shown in FIG, but it should be noted that in alternative embodiments, additional data sources related to the patient's health may also exist and be used to generate the patient's digital twin 108. EMR data 210 may be obtained from Figure 1 The illustrated EMR module 110 and / or EMR database 122 obtains and may include the patient's past and current medical data, including health status, health statistics (weight, height, age, gender, country, etc.), past diagnostic test results, medications, family history, etc. Monitoring device data 217 may include data processed by the monitoring module 117 and / or received directly from the monitoring device 120 and may include real-time data from a pulse oximeter, heart rate monitor, blood glucose monitor, ECG, etc., which may be attached to the patient in the medical facility. Thus, the monitoring device data 217 may be continuously received at the server system (e.g., at the monitoring module 117) and continuously input into the digital twin 108. As further described below, the digital twin 108 may be continuously updated as the input data is received and / or updated. Diagnostic data 218 may include data and / or test results from medical imaging procedures, laboratory tests (such as blood tests and urine tests), etc., and may be obtained from the monitoring device 120 and / or monitoring module 117. Non-medical sensor data 216 may be obtained from the non-medical sensor module 116 and / or the monitoring device 120 and may include data output from non-medical sensors (such as cameras, microphones, and non-medical-grade sensing devices (such as a continuous blood pressure wristband)) attached to the patient or attached near the patient (e.g., in the same room as the patient).

[0044] The digital twin 108 is a digital representation of the patient's health status. The digital twin 108 can be generated by a processor of the server system (e.g., processor 132) and / or one or more modules of the server system according to instructions, models, and / or algorithms stored in the system's memory and using the above-mentioned data inputs. The resulting digital twin 108 can be a digital compilation of all available health data for the patient and can be continuously updated in real time to reflect the patient's current health as the data is received by the system's processor. The digital twin 108 can represent all data that a medical professional (e.g., a health care provider) will use to perform a differential diagnosis of the patient's medical condition.

[0045] The digital twin 108 is stored on the server system (e.g., in memory) and used as an (electronic) input into the algorithm 135. The algorithm 135 includes a plurality of different algorithms, such as a first algorithm 220, a second algorithm 222, a third algorithm 224, a fourth algorithm 226, and a fifth algorithm 228. Although Figure 2 , but the plurality of different algorithms 135 may include more or less than five algorithms. For example, the plurality of different algorithms 135 may include at least two algorithms, more than three algorithms, ten algorithms, 50 algorithms, 100 algorithms, and the like. The algorithms 135 may differ in functionality, but may all output information related to the patient and their health status and treatment. In one embodiment, each algorithm in the algorithms 135 may predict the presence of a different medical condition in the patient. For example, the first algorithm 220 may be adapted (according to the specific code of the algorithm) to predict sepsis in the patient based on the input to the algorithm, the second algorithm 222 may be adapted (according to the specific code of the algorithm) to predict diabetes in the patient based on the input to the algorithm, the third algorithm 224 may be adapted (according to the specific code of the algorithm) to predict acute kidney injury in the patient based on the input to the algorithm, the fourth algorithm 226 may be adapted (according to the specific code of the algorithm) to predict myocardial infarction in the patient based on the input to the algorithm, and the fifth algorithm 228 may be adapted (according to the specific code of the algorithm) to predict hyperthyroidism in the patient based on the input to the algorithm. Figure 2As shown, each algorithm in the algorithms 135 uses the same input, which includes the same digital twin 108, and each algorithm in the algorithms 135 runs in parallel with each other. However, each algorithm in the algorithms 135 may output different information to the medical provider, such as different possible disease states, a confidence measure (e.g., a confidence percentage) for the presence of a particular disease state, a treatment guideline for a disease state or diagnosis, and / or following actions for narrowing down or confirming the output diagnosis. Additionally, in some embodiments, while the same digital twin 108 is used by and input into each algorithm in the algorithms 135, each algorithm 135 may use all or only a subset of all the data within the digital twin 108. For example, each algorithm in the algorithms 135 may be configured to extract and use a specific subset of the available data in the digital twin for running a specific algorithm.

[0046] The algorithms 135 can be configured to run in complementary, competitive, or aggregate modes. In complementary mode, each algorithm in the algorithms 135 looks for different hints at the state of the digital twin 108. For example, the first algorithm 220 may look for indications of infection, and the second algorithm 222 may look for cardiac manifestations, and the third algorithm 224 may look for signs of pulmonary distress. The output from each complementary running algorithm can be used to formulate a diagnostic report and present it to the user, and / or additional algorithms (such as meta-algorithms) can use the output from the complementary algorithms to determine a list of possible diagnoses. In competitive mode, the algorithms 135 (each of which differs in its structure or approach) can provide different perspectives based on the same digital twin 108. For example, each algorithm in the algorithms 135 may indicate the likelihood of different disease states being present in the patient. In the case of any given patient condition, a "majority report" and a "minority report" of the patient's state can be obtained based on the diversity of the algorithm results. For example, a majority report may include the most prevalent diagnosis (or diagnoses, e.g., the top 3 most frequently occurring or output diagnoses from the multiple algorithms 135) predicted by the multiple algorithms 135, while a minority report may include the least prevalent diagnosis (or diagnoses) predicted by the multiple algorithms 135. In aggregate mode, the supervisory algorithm takes the output of all of the algorithms 135 running in parallel and creates a composite or aggregated result that is published and presented to the caregiver. For example, the supervisory algorithm may include code suitable for taking the output of each of the algorithms 220, 222, 224, 226, and 228 (which, in one example, may include different diagnoses and / or disease indications) and formulating a differential diagnosis for the patient (including a list of possible diagnoses for the patient).

[0047] In another embodiment, the algorithms 135 may additionally or alternatively include one or more algorithms (e.g., one or more of algorithms 220, 222, 224, 226, and 228) that include code suitable for stratifying a patient's risk of worsening within a set time window based on the input digital twin 108. In this embodiment, the one or more algorithms may output a probability (e.g., a percentage) of the likelihood that the patient will worsen within the predetermined time window.

[0048] Each of the algorithms 135 may utilize additional information, which may be considered additional inputs, and may include historical and demographic data 214 (from Figure 1 14 and / or external historical and demographic data service 126) and medical standards / guidelines 212 (obtained from guideline module 112 and external guideline service 124). In some embodiments, each algorithm may request / extract relevant historical and / or demographic data from history module 114 and request / extract relevant standards / guidelines from guideline module 124. For example, if first algorithm 220 is adapted to predict sepsis in a patient, first algorithm 220 may utilize historical and / or demographic data and / or standards / guidelines specific to sepsis.

[0049] The output from each algorithm in the algorithms 135 may be stored in the patient's diagnostic record 104. For example, the output of each algorithm may be stored in the diagnostic record 104, and / or the results from parallel algorithms running in complementary, competitive, or aggregated modes may be stored in the diagnostic record 104. In addition, a majority or minority report of the output of the algorithms 135 may be formulated at the diagnostic record 104 by a processor of the server system and / or by another algorithm in the algorithms 135, and then stored in the diagnostic record 104. In one example, the processor may perform a meta-analysis on the results of each algorithm in the algorithms 135 via a meta-algorithm and store the results of the meta-analysis in the diagnostic record 104. The meta-analysis results may include a differential diagnosis for the patient, including a finite list of the most likely, possible diagnoses based on the output of the algorithms 135 (e.g., a list of two, three, four, five, etc. diagnoses). In this way, the diagnostic record 104 may include the output (e.g., results) of each algorithm in the parallel running algorithms 135 with respect to the same digital twin 108, as well as one or more aggregated or summarized analyses of the algorithm outputs. In some embodiments, the diagnostic report 104 may include medical standard / guideline data 212 (e.g., received from the guideline module 112) related to the resulting diagnosis in the diagnostic report 104. In another embodiment, the diagnostic report 104 may include historical data 214 (including actual results) for other patients whose digital twins match or most closely match the digital twin 108 of the current patient (e.g., as received / extracted from the history module 114). Additionally, the diagnostic record may present the percentage likelihood of multiple possible diagnoses output by the algorithm and / or the percentage likelihood of diagnoses that may be from the output list, as confirmed by the healthcare provider. Additionally, the diagnostic record may summarize the patient's health status, which may become part of the healthcare provider's notes about the patient and / or medical record.

[0050] Additionally, the diagnostic record 104 may be accessed via a healthcare provider device (such as a server system 102) based on the healthcare provider's preferences and / or interaction with the system (e.g., the diagnostic record of the server system 102). Figure 1For example, if a physician relies on or selects a diagnosis or result output from a particular algorithm more frequently than other algorithms, or takes an actionable result based on a diagnosis output from a particular algorithm (such as listing the diagnosis in a patient's medical record, ordering a diagnostic test or lab to confirm a particular diagnosis, etc.), the system may mark (e.g., label) the particular algorithm as "more trusted" and, therefore, prioritize the results / output from that algorithm over other algorithms for future updates to the diagnostic record 104 and / or for alternative diagnostic records for different patients (seen by the same health care provider). In this way, a system (e.g., server system 102) may include machine learning capabilities for learning the algorithm preferences of a particular health care provider. The machine learning capabilities may be stored as programmable code, as instructions, or as described above. Figure 1 in the memory of the processor. Figure 1 and Figure 2 This prioritization of the illustrated system can be performed through unique provider-patient interactions, or through an ensemble of interactions within the same ward, institution, or even globally as a statistical measure of the algorithm's effectiveness.

[0051] Additionally, the algorithms 135 may include multiple algorithms, each of which may be run each time the digital twin 108 is updated. In alternative embodiments, only a subset of the multiple algorithms 135 (e.g., Figure 2 108 ). In one example, if one or more of the algorithms 135 are not applicable to the patient (e.g., one of the algorithms 135 is configured to predict a condition that only exists in infants and the patient is an adult), only a subset of the algorithms 135 may be run on the digital twin 108. Thus, before executing an algorithm 135, the system may first select a relevant algorithm from the algorithms 135 and then execute the selected algorithm 135 on the digital twin 108. The relevant algorithm may be further prompted or selected based on user input (e.g., a healthcare provider requests screening for a particular disease state via an algorithm).

[0052] The results of the diagnostic record 104 are then presented to a user (e.g., a medical professional, such as a nurse, physician, or physician's assistant) via a human-machine interface 208. In one embodiment, the human-machine interface 208 may be a display including a display screen of a display device, such as a Figure 1 In another embodiment, the human-machine interface 208 may be a device included in the care provider device 134, 134 and 138. Figure 1An audio interface on one of the illustrated care provider devices 134, 134, and 138. Different user interfaces may be presented to the user via the human-machine interface 208 based on stored user preferences, via one or more selections by the user at the human-machine interface 208, and / or based on a preset presentation order of the user interfaces. Figure 2 Three user interfaces are shown, including user interface 202, user interface 204, and user interface 206. However, in alternative embodiments, more or fewer than three user interfaces may be used to present to a user. In one embodiment, the user interface may be an audio interface presented to the user via a speaker or similar audio device. In another embodiment, the user interface may be a user interface display (e.g., a graphical user interface) that may be displayed via a display of a user device. The exemplary user interface is shown in FIG. Figures 3 to 8 , as further described below.

[0053] In one embodiment, each user interface display can be a graphical user interface that includes a visualization of all, a portion, or a summary of the algorithm results in the diagnostic record 104. As an example, the user interface display 202 may include a visualization of a first list of multiple possible diagnoses for a patient based on the output of multiple different algorithms running on the digital twin 108. The user interface display 204 may include a visualization of a summary / majority report (including a majority of diagnoses). The user interface display 206 may include a visualization of details on the algorithm and / or diagnosis, which may be selected from one of the other user interface displays (such as the user interface display 202). In this way, different user interface displays can present different information to medical professionals that can be used to diagnose the patient's condition more quickly, easily, and accurately and take actionable steps (e.g., treatment, further testing, etc.). In an alternative embodiment, the above-mentioned user interface display can be an audio interface that presents a summary or specific portion of the algorithm results in an audible format.

[0054] Figures 3 to 8 Examples of different user interface displays (e.g., graphical user interfaces) that may be displayed to a medical professional (e.g., a nurse, physician, etc.) via a display device (e.g., an iPad, a smartphone, a laptop, a desktop computer, etc.) 308 are shown. Specifically, Figures 3 to 8 Each of the diagrams shows a different exemplary user interface display. As further explained below, Figures 3 to 8The different user interface displays of the can be linked to each other via one or more selectable buttons displayed on the various user interface displays. The different user interface displays can also be automatically displayed to the user after the user selects the diagnostic record of the patient based on the settings previously selected by the user. For example, the care provider can select a patient from a plurality of patients that they see in a menu user interface display (not shown). After selecting the patient, the user can request to view the diagnostic record 104 of the selected patient via another user interface display. The care provider device (e.g., display device 308) can then automatically display the patient's Figures 3 to 8 One or more of the user interface displays shown, as further described below. In one example, Figure 3 The user interface display 300 shown may be a default user interface display displayed on the display device 308 when a care provider selects a particular patient's diagnostic record. However, in an alternative embodiment, another of the user interface displays described herein may be set as a default user interface display that is automatically displayed after selecting a particular patient's diagnostic record. In yet another embodiment, upon selecting a particular patient's diagnostic record, a diagnostic record menu with links to each user interface display described below may be automatically displayed. As described below, all information visually displayed via the user interface display is part of the patient's diagnostic record 104, as determined based on the output of multiple different algorithms running on the patient's digital twin. Each of the user interface displays described below may include a main desktop button 302 and an exit button 304, which returns the care provider to the selected patient's diagnostic record menu or main menu, and the exit button can exit the patient's diagnostic record application and completely shut down the system. However, in an alternative embodiment, these main desktop buttons and exit buttons may not exist, only one of these buttons may exist, or an alternative menu button may be included to return the user to an alternative menu user interface display.

[0055] First go to Figure 3 , user interface display 300 is a diagnosis list view (also referred to herein as a differential diagnosis summary) of a diagnostic record for a patient (e.g., patient ID 1234). User interface display 300 includes a visualization of a list 312 of possible diagnoses for the patient as determined based on the output of a plurality of different algorithms. Figure 3As shown, the possible diagnosis list includes a list of four different diagnoses. However, in an alternative embodiment, the list may include more or less than four different diagnoses (depending on the output of the algorithm). The possible diagnosis list 312 may be similar to the differential diagnosis of the patient, as the algorithm automatically performs by using the patient's digital twin as input. An information button 314 is included next to each diagnosis listed in the possible diagnosis list 312. The information button 314 can be selected by the user (e.g., via user input, such as a touch of a finger or stylus to the screen of the display device 308, or via another user input device, such as a mouse or keyboard) to display a corresponding user interface display, which can be a detailed diagnosis summary page that includes additional details about the selected possible diagnosis (e.g., which data points of the digital twin contribute to each of the suggested diagnoses). In an alternative embodiment, the listed possible diagnoses themselves (e.g., "diagnosis 1") can be selectable to display the corresponding detailed diagnosis summary page user interface display.

[0056] Figure 4 , an exemplary user interface display 400 is shown showing a detailed diagnosis summary page that can be reached via selecting the information button 314 next to the desired diagnosis or via selecting the listed diagnosis itself (e.g., "Diagnosis 1" in the list of possible diagnoses 312 of the user interface 300). For example, after a user selects the information button 314 next to Diagnosis 1 on the user interface display 300, the user interface 400 can be automatically displayed via the display device 308. At 402, the user interface display 400 includes details about the selected diagnosis (e.g., a visualization thereof). The details about the selected diagnosis 402 may include a textual summary or list of details about the selected diagnosis, historical / demographic data about the selected diagnosis, treatment guidelines for the selected diagnosis, etc. At 404, the user interface display 400 may also include a visualization of a list of algorithms that output or determine the selected diagnosis. Each of the algorithms listed at 404 may be individually selectable to display a detailed algorithm report for the selected algorithm. For example, selecting "Algorithm 1" may automatically cause a detailed algorithm report for Algorithm 1 to be displayed via the display device 308, as described below with reference to Figure 7 As further described. At 406, the user interface display 400 may also include a visualization of suggested next actions for confirming the selected diagnosis. The suggested next actions may include one or more diagnostic tests to be run, such as blood tests, urine tests, imaging procedures (e.g., ultrasound, MRI, x-ray, etc.), etc. The user interface display 400 may also include a plurality of buttons for returning to or navigating to other related user interface displays, such as causing the display of Figure 3 The user interface of the display 300 displays the diagnostic list view button 408, which causes the display Figure 5The summary report button 320 of the user interface display 500 (as further described below) and the summary report button 320 that causes the display Figure 8 800 (as further described below). In alternative embodiments, different or additional buttons for navigating to different related user interface displays of a patient's diagnostic record may be included in user interface display 400 and other user interface displays described herein.

[0057] return Figure 3 At 316, the user interface display 300 may additionally include a visualization of actions for narrowing down the patient's diagnoses. For example, the actions 316 for narrowing down the diagnoses may include one or more suggested diagnostic tests (e.g., labs, imaging procedures, etc.) to be run on the patient in order to narrow down the list of possible diagnoses at 312. For example, following one or more of the actions at 316 to obtain additional health data about the patient may result in the list of diagnoses at 314 being narrowed down from four diagnoses to two diagnoses. The actions listed at 316 may be based on the output of the algorithm, the resulting diagnoses in the diagnosis list 312, and / or based on medical standards and guidelines (e.g., Figure 2 For example, based on the possible diagnoses listed at 312, as determined based on the output of the algorithm, the system (e.g., Figure 1 and Figure 2 The system (e.g., server system 102) may determine additional diagnostic tests that can narrow down the diagnosis based on medical standards and guidelines for the listed diagnoses. For example, test A listed at 316 may be used to exclude one or more of the diagnoses listed at 312. In some examples, the action 316 for narrowing down the diagnosis may include additional instructions, such as if the result of test A is X, then test B should be performed to further narrow down the possible diagnosis list 312, or if the result of test A is Y, then test B should be performed to further narrow down the possible diagnosis list 312. In this way, the user interface display 300 may provide the user (e.g., a care provider) with instructions on how to narrow down the patient's diagnosis in the most efficient way possible. As further explained below, upon receiving test results from one or more of the tests listed at 316, the system (e.g., server system 102) may automatically update the patient's digital twin, rerun the algorithm on the updated digital twin, and update the displayed user interface display 300. The updated user interface display 300 may include a smaller number of diagnoses in the possible diagnosis list 312 (e.g., only two diagnoses may be listed, such as diagnosis 1 and diagnosis 2). The user interface display 300 may then be updated with a new set of actions for narrowing down the diagnosis at 316 .

[0058] The user interface display 300 may additionally include a plurality of buttons for returning to or navigating to other related user interface displays, such as a button selectable to display Figure 6 The algorithm report button 319 of the user interface 600 (described further below) can be selected to display Figure 5 The summary report button 320 of the user interface display 500 (described further below) and the Figure 8 The user interface displays 800 (as further described below) with a patient status overview button 322 .

[0059] Go to Figure 5 , the user interface display 500 is a summary report view that presents a summary or majority report of the algorithm results to the user. Specifically, in Figure 5 In the example shown, the user interface display 500 includes a visualization of the majority diagnosis at 502. The majority diagnosis 502 may list the most common diagnoses output by the algorithm (e.g., Diagnosis X). The majority diagnosis "Diagnosis X" listed at 502 may be selected by the user to automatically switch to a user interface display that displays a detailed diagnostic record via the display device 308, such as Figure 4 At 506, the user interface display 500 may also include a visualization of the percentage of the algorithm that outputs or predicts the majority diagnosis 502. The percentage displayed at 506 (e.g., 60%) may be selected by the user to automatically switch to a user interface display that displays an algorithm report, such as Figure 6 The algorithm report may list the different algorithms that output and / or predict the presence of a majority of diagnoses. In some embodiments, such as Figure 5 As shown, at 504, the user interface display 500 may additionally include a visualization of a minority diagnosis, which includes a list of the least common diagnoses (e.g., Diagnosis Y) output by the algorithm. The minority diagnosis "Diagnosis Y" listed at 504 may be selected by the user to automatically switch to a user interface display that displays a detailed diagnostic record for Diagnosis Y via the display device 308, such as Figure 4 In an alternative embodiment, the user interface display may not include visualization of a minority of diagnoses 504. In some embodiments, such as Figure 5 As shown, at 508, the user interface display 500 may further include a visualization of historical diagnoses based on the patient's digital twin. The historical diagnoses listed at 508 (diagnosis X in this example) may be output by an algorithm that is configured to determine the diagnosis of a previous patient with a health history (e.g., health record) that is most similar to the current patient's digital twin based on historical and / or demographic data. In this way, historical diagnoses of patients with health data similar to the current patient can be presented to the user. The user interface display 500 may include similar navigation buttons as described above for the previously presented user interface display (algorithm report button 318, diagnosis list view button 408, and patient status overview button 322).

[0060] Continue to Figure 6 , the user interface display 600 is an algorithm report that presents different algorithms run on the patient's digital twin, outputting different algorithms for the diagnoses listed in the possible diagnoses list of the diagnosis list view (in Figure 3 ), and / or different algorithms that output and / or predict the presence of the majority of diagnoses listed in the summary report (in Figure 5 Specifically, at 602, the user interface display 600 includes a visualization of a list of algorithms. Each algorithm listed at 602 can be individually selected via the screen of the display device 308 to automatically display a corresponding detailed algorithm report, such as Figure 7 700 is shown (described further below). In some embodiments, the user interface display 600 may include additional statistics about the multiple algorithms running on the patient's digital twin, such as the percentage of algorithms that output a particular diagnosis (such as a majority diagnosis) and / or the most trusted algorithms (as learned by the system and / or set by the user). The user interface display 600 may include similar navigation buttons as described above for the previously presented user interface displays (algorithm report button 318, summary report button 320, diagnosis list view button 408, and patient status overview button 322).

[0061] Figure 7User interface display 700 is shown, which includes a detailed algorithm report that presents additional details of the (selected) algorithm running on the digital twin and outputs the results to the diagnostic record. User interface display 700 can be accessed from a corresponding button or selection of a specific algorithm listed on another user interface display (such as one of the user interface displays described above (e.g., user interface display 600, user interface display 500, and / or user interface display 400)) and is automatically displayed in response thereto. User interface display 700 shows an exemplary detailed algorithm report for Algorithm 1. At 702, user interface display 700 may include a visualization of details regarding the selected algorithm. The details of the selected algorithm 702 may include a textual summary or list of details regarding the selected algorithm, including the disease state or biological system that the algorithm is configured to detect and / or monitor, historical usage data for the selected algorithm, details of the code and / or configuration of the selected algorithm, and the like. At 704, user interface display 700 may additionally include a visualization of the set priority of the selected algorithm. As explained above, the system may learn the priority of a specific algorithm, and / or the user may set and / or adjust the priority of the selected algorithm. For example, the higher the priority, the more the output of the selected algorithm is emphasized compared with the output of other algorithms, and therefore, it can have greater weight in determining differential diagnosis list and / or majority diagnosis. As shown in 704 places, the user can set the priority of the selected algorithm via display device 308. As shown in the example of user interface display 700, the visualization of priority setting is a slide bar that can be moved between a relatively low setting and a high setting. However, in an alternative embodiment, the visualization of the priority setting at 704 places can be a different type of visualization, such as adjustable percentage, vertical movable bar etc. User interface display 700 may include the similar navigation buttons (algorithm report button 318, summary report button 320, diagnosis list view button 408 and patient status overview button 322) as described above for the user interface previously presented.

[0062] Go to Figure 8, user interface display 800 is displayed via display device 308. User interface display 800 is a patient health status report depicting the patient's health status. For example, at 802, user interface display 800 may display a patient status, which includes a probability (e.g., a percentage) of the likelihood that the patient will deteriorate within a predetermined time window (e.g., duration X). In another embodiment, the visualization of the patient status at 802 may include a relative text scale (e.g., unstable / moderately stable / very stable) or a color scale (e.g., red, yellow, green). At 804, user interface display 800 may also include a visualization of an alert status. For example, a user can set the alert to be on or off, where when the alert is "on", the system may automatically alert (via a pop-up dialog box, a flashing indicator light, an audible noise, etc.) when the patient's status exceeds a threshold level (e.g., the probability at 802 increases to above 70%).

[0063] It should be pointed out that Figures 3 to 8 The user interface displays presented in are exemplary in nature and may include alternative or additional visualizations for providing assistance to healthcare providers based on the outputs of multiple different algorithms running on the same digital twin of the patient. The user interface displays may provide an organized and guided visualization of the patient's diagnostic record and enable healthcare providers to more quickly and accurately perform differential diagnoses on the patient. For example, one or more of the user interface displays may provide the user with the ability to specify a final selected diagnosis via one or more user inputs (such as a button or displayed selectable element, as described above, or via audio input). A report similar to one or more of the reports described herein may then be generated, and / or the final selected diagnosis may be used for future machine learning tasks, which may then be implemented using the system described herein for future differential diagnoses.

[0064] Figure 9 , which is a flowchart illustrating a method 900 for providing assistance to a healthcare provider in diagnosing and caring for a patient. 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 instructions on the memory 130 shown in FIG. 10 are combined with various signals received at the server system from components of the health care provider auxiliary system (e.g., patient medical data signals from the monitoring device 120, communications from the hospital operation system 118, communications from the care provider device, etc.) and signals sent from the server system to the care provider device and / or other system components to perform the method 900. The processor executing the method 900 may further include one or more modules of the server system, such as Figure 1One or more of the modules shown.

[0065] At 902, method 900 includes obtaining medical data of a patient. Obtaining medical data of a patient may include obtaining past medical data of the patient (e.g., historical or previously obtained medical data about the patient, such as from an EMR system or database, as described herein) and current medical data of the patient (e.g., current data obtained in real time from one or more patient monitoring devices or via input from a user). As described above with reference to Figure 1 and Figure 2 As described, the patient's medical data may include EMR data (e.g., Figure 2 EMR data 210 in), monitoring equipment data (e.g., Figure 2 Monitoring equipment data 217 in, diagnostic data (e.g., Figure 2 Diagnostic data 218 shown) and non-medical sensor data (e.g., Figure 2 Non-medical sensor data 216 is shown. The non-medical sensor data may be obtained (e.g., received at the processor) in real time (e.g., from monitoring devices and non-medical sensors), received via user input (e.g., manual data entry from a care provider device and / or from a hospital operations system in communication with the processor), and / or from an external database such as an EMR database (e.g., Figure 1 The data may be obtained (e.g., retrieved or received) from an EMR database 122 (shown as an example). Thus, obtaining medical data may include acquiring data (and receiving the required data) via a medical device coupled to or near the patient, as well as passively retrieving previously acquired medical data from a separate medical device, database, or the like. For example, prior imaging procedure data may be retrieved from an EMR database, a hospital operations system, and / or a historical database.

[0066] The method continues to 904 to automatically generate a digital representation of the patient's health based on the acquired medical data. The digital representation of the patient's health may be referred to herein as a digital twin of the patient (such as Figure 1 and Figure 2 The system's processor may compile all of the medical data obtained at 902 to generate a digital representation of the patient and store the digital representation in a memory of the computing device. As further explained herein, the processor may be configured to automatically update the patient's digital twin in response to receiving new and / or updated health data for the patient. For example, if new imaging or lab results are uploaded to the system, the processor may then automatically update the digital twin based on the newly received data.

[0067] At 906, method 900 includes automatically running a plurality of different algorithms on the generated digital representation of the patient's health, wherein all or a subset of data from the same generated digital representation of the patient's health is input into each of the plurality of different algorithms. Figure 1 and Figure 2 The algorithm 135 shown can be part of and executed by a processor of the device and includes code configured to output diagnostic data related to the patient. For example, the patient's digital twin can be input into each algorithm selected to be run (e.g., all stored algorithms or a subset of all stored algorithms selected based on user input, learned user preferences, and / or based on the digital twin itself, as described above), and the executed algorithms can then output one or more of a plurality of possible diagnoses for the patient. In this way, the output of the algorithm is based on the input patient's digital twin. More details about the algorithm will be referred to below. Figure 2 For example, as described above, each of a plurality of different algorithms is adapted to identify a different diagnosis using the generated digital representation of the patient as input.

[0068] At 908, the method includes outputting a first user interface for presentation to a user, the user interface including a first list of diagnoses and an action for narrowing the list. In one example, the user interface is an audio or graphical user interface. For example, the first (graphical) user interface may be displayed on a display device, the first graphical user interface including a visualization of a first list of multiple possible diagnoses for a patient based on outputs of multiple different algorithms and a visualization of a suggested next action for narrowing the first list of multiple possible diagnoses, the suggested next action being based on outputs of automatically running one or more of the multiple different algorithms. In one example, the first graphical user interface may be similar to Figure 3The user interface shown is 300. For example, in response to a user (e.g., a care provider) selecting a patient, selecting a patient's diagnostic report, and / or selecting a differential diagnosis summary list (e.g., a diagnosis list view) of the patient's diagnostic report from one or more menu displays output for display on a display device and presented to the user, a first graphical user interface may be output for display on the display device. In some embodiments, the care provider may receive an alert (audio or visual) via their care provider device indicating that the patient's diagnostic record has been updated (e.g., multiple algorithms have been automatically run on the patient's updated digital twin) and is ready for review by the care provider. In addition, the recommended following actions may include one or more diagnostic tests to be performed on the patient. For example, the recommended following actions may include one or more imaging procedures to be performed (e.g., x-ray, ultrasound, MRI, etc.) and / or laboratory tests to be run on the patient (e.g., blood tests, urine tests, etc.). In addition or alternatively, the recommended following actions may include specific values ​​or results to be obtained and input from the performed diagnostic tests. In one embodiment, the recommended following actions may include an ordered list of actions to be taken in order to narrow down the diagnosis. For example, the ordered list of actions below may include performing a first diagnostic test, and then performing a second diagnostic test or a third diagnostic test based on those results.The ordered list of actions below may additionally or alternatively include a list of diagnostic tests to be performed in a specified order.

[0069] At 906, method 900 includes determining whether the system has received user input for navigating to another user interface. For example, the first user interface may display one or more navigation buttons that can be individually selected by the user to display another user interface display, or the diagnoses and / or actions in their corresponding lists presented on the first graphical user interface may be individually selectable to display another user interface display related to the selected elements. For example, as described above, selecting one of the listed diagnoses may cause the system to automatically display a user interface display of a detailed diagnosis summary that includes additional details about the selected diagnosis. Thus, receiving the user input may include receiving a signal from a display device of the care provider device that the user has selected one of the buttons or features displayed at the first graphical user interface. In response to receiving such a signal, the method proceeds to 912 to output the requested (e.g., second) graphical user interface (e.g., user interface display) for display on the display device. More details about examples of linked user interface displays are provided above with reference to Figures 3 to 8 Provide a description.

[0070] If the method determines that the system has not received user input requesting navigation to another user interface, the method proceeds to 914 to maintain the current user interface output. This may include continuing to display the first graphical user interface on the display device. Alternatively, this may include presenting the same audio user interface to the user via the user device.

[0071] At 916, method 900 includes determining whether additional medical data for the patient has been received. For example, performing one or more of the following recommended actions may include receiving test results or additional health data for the patient in real time in the system via a patient monitoring device and / or a hospital operations system (e.g., laboratory or diagnostic data updated to the hospital / clinic / office's operational system). In this way, the additional medical data may include results from one or more diagnostic tests. If no additional medical data for the patient has been received (e.g., different from the original data used to generate the patient's digital twin), the method returns to 914. Alternatively, if additional medical data is received at the device (e.g., system), the method proceeds to 918 to automatically update the generated digital representation of the patient's health (e.g., digital twin) based on the received additional medical data, automatically run multiple different algorithms on the updated digital representation of the patient's health, and output an updated first user interface for display on a display device (or for presentation via an audio interface), the updated first user interface including a visualization (or audio representation) of an updated second list of multiple possible diagnoses for the patient based on the outputs of the multiple different algorithms. For example, the second list may include different and / or fewer diagnoses than the first list. In this way, the additional received medical data can help narrow the differential diagnoses presented to the user to a smaller number. In some examples, the second list may have more diagnoses than the first list, but the second list may contain more accurate diagnoses, thereby enabling the user to more accurately diagnose the patient and implement an effective treatment plan. The method then ends. In some embodiments, the method may return to 904 and repeat.

[0072] In one embodiment, method 900 may be repeated until the differential diagnosis list is sufficiently narrowed so that the care provider can make an accurate diagnosis for the patient. The system may additionally present to the user via the diagnostic record the actions to be taken (e.g., treatment) based on the patient's selected or final diagnosis.

[0073] In this way, the aforementioned healthcare provider assistance system can assist healthcare providers when diagnosing a patient. By compiling all available health data about a patient via a digital twin, multiple algorithms can then be executed against the same digital twin. Integrating patient medical data in this way can save healthcare providers considerable time and effort, allowing them to focus their time and effort on higher-level clinical tasks. The output from the multiple algorithms can be used to form a patient's diagnostic record, which can include digital information about the patient's possible diagnoses, the patient's health status, additional actions to be taken to confirm and / or narrow down the possible diagnoses, and recommended treatments based on the possible diagnoses. This information can then be presented to the user (healthcare provider) in various forms via a user interface display and / or an audible user interface. The user can interact with the user interface display or audible user interface to navigate through the different information from the diagnostic record. In this way, the system can present information about the patient in an organized manner that enables the provider to quickly and efficiently narrow down the patient's diagnosis and accurately treat the patient. The aforementioned system (including the algorithms) mimics the thought process that a healthcare provider would undergo to diagnose a patient. However, the system performs this process in a more thorough, organized, and efficient manner, and with improved accuracy. Thus, the technical effects are of automatically running multiple different algorithms on a generated digital representation of a patient's health, wherein the same generated digital representation of the patient's health is input into each of the multiple different algorithms; and outputting a graphical user interface for display on a display device, the first graphical user interface comprising a visualization of a first list of multiple possible diagnoses for the patient based on the outputs of the multiple different algorithms and a visualization of a suggested next action for narrowing the first list of multiple possible diagnoses, the suggested next action providing organized information about the patient's health to healthcare providers based on the outputs of one or more of the multiple different algorithms that were automatically run, and enabling them to make more accurate diagnoses for the patient in a more timely and simple manner (compared to performing traditional differential diagnoses from EMRs and memories and / or looking up standard and guideline principles).

[0074] In one embodiment, a system includes: a human-machine interface; and a computing device operably coupled to the human-machine interface and configured to execute instructions stored in a memory to: execute a plurality of different algorithms, wherein the input to each of the plurality of different algorithms includes current and past data representing the patient's health and current condition, wherein each of the plurality of different algorithms uses the same data or a subset of the same data for the input; output a list of a first number of possible diagnoses for the patient to the human-machine interface based on the output of the plurality of different algorithms executed; and present, via the human-machine interface, a recommended next action for narrowing down the first number of possible diagnoses, the recommended next action being determined based on the output of the plurality of different algorithms executed. In a first example of the system, the instructions are further executable to receive additional patient health data obtained in accordance with the execution of the recommended next action, and output an updated list of a second number of possible diagnoses to the human-machine interface, the second number being less than the first number. A second example of the system optionally includes the first example, and further includes wherein the instructions are further executable to output an updated list of a second number of possible diagnoses to the human-machine interface in response to receiving additional patient health data, wherein the updated list includes different diagnoses than the list of the first number of possible diagnoses, and wherein the first number and the second number may be the same or different. A third example of the system optionally includes one or more of the first and second examples, and further includes wherein the presented suggested next actions include an ordered list of diagnostic tests to be performed on the patient. A fourth example of the system optionally includes one or more of the first through third examples, and further includes wherein the instructions further include instructions for outputting a majority report to the human-machine interface indicating the most likely diagnosis for the patient based on the most frequently occurring outputs of the plurality of different algorithms. A fifth example of the system optionally includes one or more of the first through fourth examples, and further includes wherein the inputs to each of the plurality of different algorithms further include demographic data and medical standards and guideline data, and wherein the past data includes the patient's health data from the patient's electronic health record, and wherein the current data includes real-time patient monitoring data. A sixth example of the system optionally includes one or more of the first to fifth examples, and further includes wherein each of the plurality of different algorithms is adapted to identify a different disease based on the input.A seventh example of the system optionally includes one or more of the first to sixth examples, and further includes wherein the human-machine interface is a display of a care provider device, wherein the computing device includes one or more processors, and wherein the computing device electronically communicates directly or indirectly through an additional server with one or more databases or services, the one or more databases or services including an electronic medical record database, an external guideline service, and a historical and demographic data service.

[0075] As another embodiment, a method includes: obtaining medical data of a patient; automatically generating a digital representation of the patient's health based on the obtained medical data; running a plurality of different algorithms on the generated digital representation of the patient's health, wherein the same generated digital representation of the patient's health is input into each of the plurality of different algorithms; and outputting a first graphical user interface for display on a display device, the first graphical user interface including a visualization of a first list of multiple possible diagnoses for the patient based on outputs of the plurality of different algorithms and a visualization of a suggested next action for narrowing the first list of multiple possible diagnoses, the suggested next action being based on outputs of one or more of the automatically run plurality of different algorithms. In a first example of the method, the suggested next action includes one or more diagnostic tests to be performed on the patient. A second example of the method optionally includes the first example and further includes receiving additional medical data for the patient, the additional medical data including results from the one or more diagnostic tests and / or updated medical data for the patient; automatically updating the generated digital representation of the patient's health based on the received additional medical data; automatically running the plurality of different algorithms on the updated digital representation of the patient's health; and outputting an updated first graphical user interface for display on the display device, the updated first graphical user interface including a visualization of an updated second list of multiple possible diagnoses for the patient based on the outputs of the plurality of different algorithms. A third example of the method optionally includes one or more of the first and second examples and further includes wherein the second list includes different and / or fewer diagnoses than the first list. A fourth example of the method optionally includes one or more of the first through third examples and further includes wherein the obtained medical data includes current medical data for the patient and historical medical data for the patient. A fifth example of the method optionally includes one or more of the first through fourth examples and further includes wherein each of the plurality of different algorithms is adapted to identify a different diagnosis using the generated digital representation of the patient as input. A sixth example of the method optionally includes one or more of the first to fifth examples, and also includes wherein obtaining the medical data of the patient includes acquiring data in real time from a medical device suitable for monitoring the patient, and passively receiving data acquired by another medical device and stored at the other medical device and / or data from a database.The seventh example of the method optionally includes one or more of the first to fourth examples, and also includes outputting a second graphical user interface for display on the display device in response to receiving user input selecting the visualized diagnosis of the first list from the first graphical user interface, the second graphical user interface including a visualization of details about the selected diagnosis.

[0076] As yet another embodiment, a computing device includes a human-computer interface, the computing device configured to present, via the human-computer interface, a differential diagnosis summary, the differential diagnosis summary listing one or more most likely possible diagnoses for a patient based on outputs of a plurality of different algorithms executed by the computing device, each of the plurality of different algorithms using as input a portion or all of the same set of current and past health data for the patient, wherein the one or more most likely possible diagnoses are selectable to present a corresponding detailed diagnosis summary, the detailed diagnosis summary including additional details about the selected possible diagnosis, wherein the details about the selected possible diagnosis include a suggested next step for confirming the selected possible diagnosis. In a first example of the computing device, the suggested next step includes one or more diagnostic tests to be run on the patient, and wherein using as input the portion or all of the same set of current and past health data for the patient includes each algorithm selecting as input a portion or all of the data included in the same set of current and past health data for the patient. A second example of the computing device optionally includes the first example, and further includes wherein the detailed diagnosis summary further includes a list of algorithms from the plurality of algorithms that output the selected possible diagnosis. A third example of the computing device optionally includes one or more of the first example and the second example, and also includes wherein the human-machine interface is a display screen, wherein the differential diagnosis summary is included on a graphical user interface output to the display screen, and wherein the differential diagnosis summary also lists one or more suggested following actions for narrowing down and / or confirming the one or more most likely possible diagnoses listed in the differential diagnosis summary.

[0077] In another embodiment, a system includes a display; and a computing device operably coupled to the display and configured to execute instructions stored in a memory to: automatically generate a digital representation of a patient's health based on the patient's medical data; execute a plurality of different algorithms, wherein an input to each of the different algorithms includes the generated digital representation of the patient's health; output to the display a list of a first number of possible diagnoses for the patient based on the output of the plurality of different algorithms executed; and continuously update the displayed list in response to receiving updates to the patient's medical data. In one example, the instructions are further executable to obtain the patient's medical data in real time based on the patient's electronic medical health record, based on data received from one or more patient monitoring sensors, and based on received uploaded diagnostic data (including imaging and laboratory data of the patient).

[0078] As used herein, 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 said elements or steps, unless such exclusion is explicitly stated. In addition, reference to "one 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 otherwise, embodiments that "comprise", "include" or "have" an element or multiple elements with a particular characteristic may include additional such elements that do not have that characteristic. The terms "comprise" and "in..." are used as the concise language equivalents of the corresponding terms "comprise" 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.

[0079] This written description uses examples to disclose the invention, including the best mode, and also to enable one 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 one of ordinary skill in the art. Such other examples are intended to be 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 insignificant differences from the literal language of the claims.

Claims

1. A system comprising: Human-machine interface; and a computing device operably coupled to the human-machine interface and configured to execute instructions stored in a memory to: executing a plurality of different algorithms, wherein an input to each of the plurality of different algorithms includes current and past data representing the health and current condition of the patient, wherein each of the plurality of different algorithms uses the same data or a subset of the same data for the input, wherein each algorithm can predict a different medical condition in the patient; outputting, via the human-machine interface, a differential diagnosis summary comprising a listing of a first number of possible diagnoses for the patient determined based on outputs of the executed plurality of different algorithms; and presenting, via the human-machine interface, a suggested next action for narrowing the first number of possible diagnoses, the suggested next action determined based on the outputs of the executed plurality of different algorithms, the suggested next action comprising one or more suggested diagnostic tests that narrow the list of possible diagnoses; In response to receiving a selection of a diagnosis from the differential diagnosis summary at the human-machine interface, updating the display of the human-machine interface to present details of the diagnosis from the differential diagnosis summary, wherein the diagnosis is from a list of the first number of possible diagnoses in the differential diagnosis summary, and updating the display of the human-machine interface to present a list of algorithms used by the computing device to determine the diagnosis selected from the differential diagnosis summary.

2. A system according to claim 1, wherein the instructions are further executable to receive additional patient health data obtained based on the execution of the action following the recommendation, and output a list of a second number of possible diagnoses to the human-machine interface, the second number being less than the first number.

3. A system according to claim 1, wherein the instructions are further executable to output a list of the second number of possible diagnoses to the human-machine interface in response to receiving additional patient health data, wherein the list of the second number of possible diagnoses includes diagnoses that are different from the list of the first number of possible diagnoses, and wherein the first number and the second number can be the same or different. 4 . The system of claim 1 , wherein a suggested next action for confirming the diagnosis is further presented in response to receiving the selection at the human-machine interface.

5. The system of claim 1 , wherein the instructions further comprise instructions for outputting a summary report to the human-machine interface, the summary report comprising a majority diagnosis report and a minority diagnosis report indicating a most likely diagnosis for the patient based on the most frequently occurring outputs of the plurality of different algorithms.

6. The system of claim 1 , wherein the input to each of the plurality of different algorithms further comprises demographic data and medical standards and guideline data, and wherein the past data comprises health data of the patient from the patient's electronic health record, and wherein the current data comprises real-time patient monitoring data.

7. The system of claim 1, wherein updating the display of the human-machine interface to present a list of algorithms used by the computing device to determine the diagnosis to select from the differential diagnosis summary is also responsive to receiving a selection at the human-machine interface.

8. The system of claim 1, wherein each algorithm presented in the algorithm list can be individually selected to display a corresponding algorithm report.

9. A method comprising: Access to patients’ medical data; automatically generating a digital representation of the patient's health based on the acquired medical data; running a plurality of different algorithms on the generated digital representation of the patient's health, wherein the same generated digital representation of the patient's health is input into each of the plurality of different algorithms, wherein each algorithm can predict a different medical condition in the patient; outputting a first graphical user interface for display on a display device, the first graphical user interface comprising a visualization of a differential diagnosis summary, the differential diagnosis summary comprising a visualization of a first list of a plurality of possible diagnoses for the patient determined based on outputs of the plurality of different algorithms and a visualization of a suggested next action for narrowing the first list of the plurality of possible diagnoses, the suggested next action being based on outputs of one or more of the automatically executed plurality of different algorithms, the suggested next action for narrowing the first number of possible diagnoses comprising one or more diagnostic tests to be performed on the patient; accepting, via the display device, a selection of a diagnosis from the differential diagnosis summary; and In response to accepting the selection, details of the diagnosis from the differential diagnosis summary are presented via the display device, wherein the diagnosis is from the first list of the plurality of possible diagnoses, and a listing of algorithms used to determine the diagnosis selected from the differential diagnosis summary is presented via the display device.

10. The method of claim 9, wherein a suggested next action for confirming the diagnosis from the first list of the plurality of possible diagnoses is presented in response to accepting the selection.

11. The method according to claim 10, further comprising: receiving additional medical data for the patient, the additional medical data including results from the one or more diagnostic tests and / or updated medical data for the patient; automatically updating the generated digital representation of the patient's health based on the received additional medical data; automatically running said plurality of different algorithms on said updated digital representation of said patient's health; as well as An updated first graphical user interface is output for display on the display device, the updated first graphical user interface including a visualization of an updated second list of a plurality of possible diagnoses for the patient based on outputs of the plurality of different algorithms.

12. The method of claim 11, wherein the second list includes different and / or fewer diagnoses than the first list.

13. The method according to claim 9, wherein the obtained medical data includes current medical data of the patient and historical medical data of the patient.

14. The method of claim 9, further comprising receiving a selection of a summary report button displayed on the display device; and A summary report is presented via the display device, the summary report including presentation of a majority diagnosis and a minority diagnosis in response to receiving selection of the summary report button, and wherein each of the plurality of different algorithms is adapted to identify a different diagnosis using the generated digital representation of the patient as input.

15. The method according to claim 9, wherein obtaining the medical data of the patient comprises acquiring data in real time from a medical device suitable for monitoring the patient, and passively receiving data acquired by another medical device and stored at the other medical device and / or data from a database.

16. The method of claim 9, the algorithm list comprising a plurality of different algorithms for determining the diagnosis.

17. A computing device comprising: A human-machine interface, the computing device being configured to present a differential diagnosis summary via the human-machine interface, the differential diagnosis summary comprising a list of one or more most likely possible diagnoses for a patient determined based on outputs of a plurality of different algorithms executed by the computing device, each of the plurality of different algorithms using as input a portion or all of the same set of current and past health data for the patient, wherein the one or more most likely possible diagnoses from the list included in the differential diagnosis summary can be selected to present a corresponding detailed diagnosis summary, wherein presenting the corresponding detailed diagnosis summary comprises presenting additional details regarding the possible diagnosis selected from the differential diagnosis summary, the possible diagnosis selected from the list included in the differential diagnosis summary, and presenting a list of algorithms used by the computing device to determine the possible diagnosis selected from the differential diagnosis summary, wherein the additional details regarding the selected possible diagnosis include a recommended next action for confirming the selected possible diagnosis, wherein each algorithm can predict a different medical condition in the patient, the recommended next action comprising one or more diagnostic tests to be run on the patient.

18. A computing device according to claim 17, wherein using the portion or all of the same set of current and past health data of the patient as input includes each algorithm selecting a portion or all of the data included in the same set of current and past health data of the patient as input to the algorithm.

19. A computing device according to claim 17, wherein the human-machine interface is a display screen, wherein the differential diagnosis summary is included on a graphical user interface output to the display screen, and wherein the differential diagnosis summary also lists one or more suggested following actions for narrowing down and / or confirming the one or more most likely possible diagnoses listed in the differential diagnosis summary.

20. The computing device of claim 17, wherein the list of algorithms comprises a plurality of different algorithms used by the computing device to determine the possible diagnosis.

Images