Semi-autonomous medical system and method

Abstract

To provide medical systems that use artificial intelligence to facilitate autonomous or semi-autonomous medical procedures.SOLUTION: There is provided a system for applying open heart surgery technique 200 to a patient 10, and the system includes a heart / lung machine 100, one or more monitoring devices 218, a database 206, and a computing system 200. In the technique, the computing system analyzes parameters from the one or more monitoring devices, and first medical data and second medical data, and determines, through comparison of analysis with third medical data, the prediction that operation data from the heat / lung machine or the parameters from the one or more monitoring devices tend to deviates from target ranges.SELECTED DRAWING: Figure 2A

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 929,134, filed November 1, 2019. The disclosure of the prior application is considered part of (and is incorporated by reference into) the disclosure of this application.

[0002] This document relates to medical systems that use artificial intelligence to facilitate autonomous or semi-autonomous medical treatment procedures. For example, this document relates to a heart / lung machine system that uses artificial intelligence to facilitate autonomous or semi-autonomous open-heart surgery. [Background technology]

[0003] Artificial intelligence (AI), sometimes called machine intelligence, is the intelligence exhibited by machines and systems of machines. The term "artificial intelligence" is often used to describe machines (or computers) that mimic the "cognitive" functions that humans associate with human intelligence, such as "learning" and "problem-solving."

[0004] Autonomous operation is the ability of a system to sense the state of its environment, analyze the data it senses to detect operating problems or changing resource demands, and dynamically adapt to the environment to solve them.

[0005] Heart / lung machine systems, along with extracorporeal circuits and hollow fiber oxygenators, are used to meet the circulatory and blood gas exchange needs of patients during medical procedures such as cardiopulmonary bypass surgery. Blood from the patient is either drained by gravity or vacuum-assisted venous drainage (VAVD) is used to obtain the flow needed to maintain sufficient volume within the extracorporeal circuit's reservoir. Pumps, such as peristaltic or centrifugal pumps coupled with magnetic drive systems, are sometimes used within the main line of the extracorporeal circuit to pump blood from the reservoir, through the oxygenator, and ultimately back to the patient. In addition to the heart / lung machine itself, heart / lung machine systems can include multiple types of patient monitoring devices used in conjunction with the heart / lung machine. Summary of the Invention

[0006] This document describes a medical system that uses artificial intelligence to facilitate autonomous or semi-autonomous medical treatment procedures using a medical treatment system in conjunction with other devices / systems. For example, this document describes a heart / lung machine system used in conjunction with an artificial intelligence computer system to facilitate autonomous or semi-autonomous open-heart surgery.

[0007] In one aspect, the present disclosure is directed to a system for performing an open-heart surgical procedure on a patient. The system includes a heart / lung machine, one or more monitoring devices, a database, and a computing system. The one or more monitoring devices are configured to monitor parameters indicative of the patient's health during the procedure. The database stores (1) first medical data describing one or more health conditions of the patient, (2) second medical data summarizing health information of the general population of other patients, and (3) third medical data defining target ranges for operating parameters of the heart / lung machine and one or more monitoring devices during the procedure. The computer system is configured to receive (a) the operating data from the heart / lung machine, (b) the parameters from the one or more monitoring devices, (c) the first medical data, (d) the second medical data, and (e) the third medical data in real time during the procedure. The computer system is further configured to iteratively analyze (i) the operational data from the heart / lung machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data during the procedure. The computer system is further configured to iteratively determine, during the procedure, a prediction that the operational data from the heart / lung machine or the parameters from the one or more monitoring devices will tend to fall outside of a target range based on a comparison of the analyses of (i)-(iv) with the third medical data.

[0008] Such a system for performing an open-heart surgery procedure on a patient may optionally include one or more of the following features: The computer system may be further configured to generate a trained model for the procedure based on the predictions. In some embodiments, generating the trained model for the procedure comprises iteratively training the model for the procedure by correlating each of the predictions to (i) operational data from the heart / lung machine, (ii) parameters from one or more monitoring devices, (iii) first medical data, and (iv) second medical data, across one or more model layers, using one or more machine learning algorithms. The trained models may be stored in a database. The computer system may be configured to determine a prediction that the operational data from the heart / lung machine or parameters from the one or more monitoring devices will tend to fall outside of target ranges based on applying the trained model for the procedure. In some embodiments, the computer system is further configured to generate recommended adjustments to be made to at least one of the heart / lung machine or the one or more monitoring devices in real time during the procedure based on the predictions. The computer system may be further configured to select one or more of the recommended adjustments based at least in part on analyzing (i) operational data from the heart / lung machine, (ii) parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data in real time during the procedure. The computer system may be further configured to autonomously implement the selected one or more recommended adjustments in real time during the procedure. In some embodiments, the computer system is further configured to generate a trained model for recommending procedure adjustments based on autonomously implementing the selected one or more recommended adjustments. The computer system may be further configured to receive operational data from multiple heart / lung machines. In some cases, the one or more monitoring devices include at least one of a camera or a sensor array.The one or more monitoring devices may also include a urine bag monitor. The first medical data may include the patient's current health status and the patient's past health status. The second medical data may include the patient's past health information after the procedure.

[0009] In another aspect, the present disclosure is directed to a computer-implemented method for use while performing an open-heart surgery procedure on a patient. The method includes receiving, by a computer system in real time during the procedure, (i) operational data from a heart / lung machine, (ii) parameters indicative of the patient's health status during the procedure from one or more monitoring devices, (iii) first medical data describing one or more health statuses of the patient, (iv) second medical data summarizing general population health information of other patients, and (v) third medical data defining target ranges for the operational parameters of the heart / lung machine and one or more monitoring devices during the procedure. The method also includes iteratively analyzing (i)-(iv) by the computer system during the procedure. The method also includes determining a prediction that the operational data from the heart / lung machine or the parameters from the one or more monitoring devices will tend to fall outside the target ranges based on a comparison of the analysis of (i)-(iv) with the third medical data.

[0010] Such a computer-implemented method for use while performing an open-heart surgery procedure on a patient may optionally include one or more of the following features: The method may also include generating a trained model for the procedure based on the predictions. Generating the trained model for the procedure may include iteratively training the model for the procedure by correlating each of the predictions to (i) operational data from the heart / lung machine, (ii) parameters from one or more monitoring devices, (iii) first medical data, and (iv) second medical data, across one or more model layers, using one or more machine learning algorithms. The method may also include determining a prediction that the operational data from the heart / lung machine or the parameters from the one or more monitoring devices will tend to fall outside of a target range based on applying the trained model for the procedure.

[0011] In another aspect, the present disclosure is directed to a system for performing a medical procedure on a patient. The system includes a medical treatment system, one or more monitoring devices, a database, and a computing system. The one or more monitoring devices are configured to monitor parameters indicative of the patient's health status during the procedure. The database stores (1) first medical data describing one or more health statuses of the patient, (2) second medical data summarizing health information of the general population of other patients, and (3) third medical data defining target ranges for operating parameters of the medical treatment system and one or more monitoring devices during the procedure. The computer system is configured to receive (a) the operating data from the medical treatment system, (b) the parameters from the one or more monitoring devices, (c) the first medical data, (d) the second medical data, and (e) the third medical data in real time during the procedure. The computer system is further configured to iteratively analyze (i) the operational data from the medical treatment system, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data during the procedure. The computer system is further configured to iteratively determine, during the procedure, a prediction that the operational data from the medical treatment system or the parameters from the one or more monitoring devices will tend to fall outside of the target range based on a comparison of the analyses of (i)-(iv) with the third medical data.

[0012] Such a medical treatment system may optionally include one or more of the following features: The computer system may be configured to generate recommended adjustments to be made to at least one of the medical treatment system or the one or more monitoring devices in real time during the procedure based on the predictions. The computer system may be configured to: (A) select one or more of the recommended adjustments based at least in part on analyzing (i) operational data from the medical treatment system, (ii) parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data in real time during the procedure; and (B) autonomously implement the selected one or more recommended adjustments.

[0013] The technology described herein can be used to provide multiple benefits and advantages. For example, the systems and methods described herein improve techniques used to help clinicians determine medical procedure adjustments that ensure the health and safety of patients during medical procedures. As described herein, the need for medical procedure adjustments can be accurately predicted and provided to clinicians, such as perfusionists, in a timely manner during a medical procedure. For example, in some cases, clinicians can be notified of potential harm to the patient so that they can address and avoid harm before it occurs. This protects clinicians from having to spend significant time during the procedure making any such decisions. This can also reduce the likelihood of human error when making such decisions during the stress of the procedure. Patient safety and procedural outcomes can be improved for these reasons.

[0014] The disclosed technology can also enhance information processing to provide benefits to patients and caregivers. The ability of a single human to analyze large amounts of complex data about patients and the general patient population is limited. Furthermore, human analysis may miss relevant data that could otherwise be used to accurately assess a patient's health status during a procedure. The technology described herein overcomes these challenges by providing a technological means to understand and analyze thousands of data sets and provide predictive trends and analysis of patient safety before, during, and after a medical procedure. Furthermore, the technology incorporates data from a wide variety of sources, such as databases, patient monitoring devices, and sensors, to generate robust and accurate trends and predictions. Machine learning can be incorporated into the disclosed technology to continuously improve trend analysis, prediction of patient outcomes and safety, and generation of procedure adjustment recommendations. Continuous improvement is advantageous in ensuring that the disclosed system can predict patient health status during any type of medical procedure.

[0015] Additionally, labor costs can be reduced using the systems and methods described herein. For example, as described below, in some cases, labor costs for perfusionists who control heart / lung machines during open-heart surgery can be reduced. Medical procedure adjustment recommendations and decisions can be made with the aid of this technology, which can reduce the need for a perfusionist to dedicate themselves to a single procedure, control medical devices, perform procedure adjustments, and make decisions about which adjustments are needed to ensure patient safety. Instead, in some cases, a practitioner, such as a perfusionist, can oversee multiple procedures at once from a central location and accept decisions and / or recommendations generated for each of the multiple procedures by the disclosed technology. The disclosed technology can augment the practitioner's ability to address issues that arise during a procedure. The disclosed technology can, in some cases, provide two-way communication with medical devices used during a procedure so that medical procedure adjustments can be made remotely and / or autonomously. These procedure adjustments can also be presented or suggested to the practitioner, who can make the actual decision regarding whether to implement the proposed procedure adjustments.

[0016] The disclosed technology can optionally provide semi-autonomous control of multiple devices used during medical procedures. Artificial intelligence (AI), data integration, and deep learning (DL) enable precise semi-autonomous control. As a result of using such techniques, patients may be discharged from the hospital sooner and experience fewer complications during the procedure and recovery.

[0017] The cost of medical procedures can also be reduced for a variety of reasons. First, fewer practitioners can be employed because one practitioner can oversee multiple procedures at once. Second, practitioners can focus on performing the medical procedure without the need for distractions from monitoring devices and patient health. Third, human error in diagnosing and addressing problems during the procedure can be greatly reduced and / or eliminated.

[0018] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this invention pertains. Although methods and materials similar or equivalent to those described herein can be used to practice the present invention, suitable methods and materials are described herein. In case of conflict, the present specification, including definitions, will control. Furthermore, materials, methods, and examples are illustrative only and are not intended to be limiting. Moreover, all references to features or objects A-N mean that there can be an infinite number of such features or objects.

[0019] The details of one or more embodiments of the invention are set forth in the accompanying drawings and the description herein. Other features, objects, and advantages of the invention will be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]

[0020] [Figure 1] Schematic diagram of a patient undergoing open heart surgery while supported using a conventional heart / lung machine system and an extracorporeal circuit. [Figure 2A] 1 is a schematic diagram of an exemplary system used to perform a semi-autonomous medical procedure. [Figure 2B] 1 is a schematic diagram of an exemplary system used to perform a semi-autonomous medical procedure. [Figure 3] 1 is a schematic diagram of an exemplary system for performing semi-autonomous medical procedures described herein. [Figure 4] 1 is a flowchart of a process for performing a semi-autonomous medical procedure. [Figure 5A] 1 is a flowchart of an exemplary process for predicting patient health status before, during, and after a semi-autonomous medical procedure. [Figure 5B] 1 is a flowchart of an exemplary process for predicting patient health status before, during, and after a semi-autonomous medical procedure. [Figure 6A]1 is a flowchart of an exemplary process for improving prediction of patient health status after a semi-autonomous medical procedure is completed. [Figure 6B] 1 is a flowchart of an exemplary process for improving prediction of patient health status after a semi-autonomous medical procedure is completed. [Figure 6C] 1 is a flowchart of an exemplary process for improving prediction of patient health status after a semi-autonomous medical procedure is completed. [Figure 7A] 1 is a flowchart of an exemplary process for generating procedure modification recommendations. [Figure 7B] 1 is an exemplary graph of patient health status during a conventional manual medical procedure. [Figure 7C] 10 is an exemplary graph of patient health status during a semi-autonomous medical procedure. [Figure 7D] 1 is an exemplary schematic diagram of a patient undergoing surgery using an exemplary semi-autonomous computing system described herein. [Figure 8A] 1 is an exemplary block diagram of different layers of patient health prediction interacting with each other. [Figure 8B] 1 is an exemplary block diagram of different layers of patient health prediction interacting with each other. DETAILED DESCRIPTION OF THE INVENTION

[0021] Like numbers refer to corresponding parts throughout.

[0022] This document describes medical systems that use artificial intelligence to facilitate autonomous and / or semi-autonomous medical treatment procedures using medical treatment systems in conjunction with other devices / systems. For example, this document describes heart / lung machine systems that use artificial intelligence to facilitate autonomous or semi-autonomous open-heart surgery. This document also describes heart / lung machine systems that use artificial intelligence to facilitate manual performance of open-heart surgery operations.

[0023] Although the systems provided herein for performing semi-autonomous medical procedures on a patient are primarily described in the context of an open-heart surgery procedure using a heart / pulmonary bypass machine, it should be understood that an open-heart surgery procedure using a heart / pulmonary bypass machine is merely an example. The innovative concepts described in the context of an open-heart surgery procedure using a heart / pulmonary bypass machine extend, without limitation, to various other types of medical procedures using medical treatment systems in conjunction with other devices / systems.

[0024] 1 , various types of medical procedures can be performed on patient 10 while patient 10 is connected to a life-sustaining cardiac / pulmonary bypass mechanical system 100. In this example, patient 10 is undergoing open-heart surgery, during which patient 10's heart 12 and lungs are intentionally temporarily suspended. However, because patient 10's body continues to have a metabolic need to receive a supply of circulating oxygenated blood during the medical procedure, cardiac / pulmonary bypass mechanical system 100 performs such a function. That is, as described further below, cardiac / pulmonary bypass mechanical system 100 is connected to patient 10 and performs the functions of patient 10's heart 12 and lungs so that patient 10 remains alive and healthy during the open-heart surgery.

[0025] Cardiopulmonary bypass mechanical system 100 can be used for many different types of medical procedures, including, but not limited to, coronary artery bypass grafts, heart valve repair, heart valve replacement, heart transplants, lung transplants, ablation procedures, septal defect repair, congenital heart defect repair, aneurysm repair, pulmonary endarterectomy, pulmonary thrombectomy, and the like.

[0026] Cardiopulmonary bypass machine systems 100 are typically set up and operated by specially trained clinicians / practitioners called perfusionists. Perfusionists form part of a broader cardiovascular surgical team that includes cardiac surgeons, anesthesiologists, and nurses. During a medical procedure using the cardiopulmonary bypass machine system 100, the perfusionist has many responsibilities, most important of which are ensuring that the patient 10 remains alive and healthy by regulating oxygen and carbon dioxide levels in the patient's 10 blood and operating the cardiopulmonary bypass machine system 100 in a manner that maintains blood flow to the patient's tissues. Other responsibilities of a perfusionist include, but are not limited to, administering blood products, administering anesthetic agents or anesthetic drugs, measuring selected laboratory values ​​(e.g., blood counts), monitoring circulation, monitoring blood gases, monitoring anticoagulation, inducing hypothermia, and hemodilution. The responsibilities of a perfusionist are varied and dynamic and are critical to achieving a successful outcome of procedures performed on patients 10 using cardiopulmonary bypass machine systems 100.

[0027] In the depicted example, cardiopulmonary bypass machine system 100 includes components and subsystems, such as a heart / lung machine 110, an extracorporeal circuit 120, one or more temperature control systems 130, a blood monitoring system 140, a perfusion data management system 150, and a regional oximetry system 160. Some types of procedures using cardiopulmonary bypass machine system 100 may not require all of the components and subsystems shown. Some types of procedures using cardiopulmonary bypass machine system 100 may require additional components, monitors, and / or subsystems that are not shown.

[0028] The extracorporeal circuit 120 is connected to the patient 10 and to the heart / lung machine 110. Other systems, such as a temperature control system 130, a blood monitoring system 140 (e.g., a CDI® blood gas monitor made by Terumo Cardiovascular Corporation), and a perfusion data management system 150, may be configured to interface with the extracorporeal circuit 120. The extracorporeal circuit 120 is connected to the patient 10 at the patient's heart 12. Oxygen-depleted blood (venous blood) from the patient 10 is extracted from the patient 10 at the patient's heart 12 using a venous catheter 121. As described further below, the blood circulates through the extracorporeal circuit 120 to receive oxygen and remove carbon dioxide. The oxygenated blood is then returned through the extracorporeal circuit 120 to the patient's heart 12 via an aortic cannula 129.

[0029] The extracorporeal circuit 120 may include at least venous tubing 122 (e.g., lines, tubing) coupled to a venous catheter 121, a blood reservoir 123, a centrifugal pump 124, an oxygenator 125, an arterial filter 126, one or more air bubble detectors 128, and arterial tubing 127 (e.g., lining, tubing) coupled to an aortic cannula 129. The venous catheter 121 and the venous tubing 122 are in fluid communication with the venous side of the circulatory system of the patient 10. The venous tubing 122 is also in fluid communication with an inlet to the reservoir 123. An outlet from the reservoir 123 is connected by tubing to an inlet of the pump 124. An outlet of the pump 124 is connected by tubing to an inlet of the oxygenator 125. An outlet of the oxygenator 125 is connected by tubing to an inlet of the arterial filter 126. An outlet of the arterial filter 126 is connected to the arterial tubing 127. One or more pressure transducers (not shown) can be positioned along arterial tubing 127 to detect the heart / lung machine (HLM) system line pressure of the blood in arterial tubing 127, which is measured by heart / lung machine 110 and monitored by a perfusionist. Arterial tubing 127 is connected to arterial cannula 129, which is in physical contact with heart 12 and in fluid communication with the arterial side of the circulatory system of patient 10.

[0030] Briefly, the extracorporeal circuit 120 operates by removing venous, oxygen-depleted blood from the patient 10 via a venous catheter 121 and placing the venous blood in a reservoir 123 via a venous tubing 122. In some cases, gravity is used to cause blood to flow or drain from the patient 10 into the reservoir 123. In some cases, a vacuum is used to assist blood flow from the patient 10 into the reservoir 123. It is intended that at least some amount of blood be maintained in the reservoir 123 at all times during the surgical procedure. Otherwise, if the reservoir 123 were to become empty, air could be pumped into the extracorporeal circuit 120 and potentially into the vasculature of the patient 10. Such an outcome would likely be catastrophic for the patient 10. Therefore, the perfusionist is tasked with visually monitoring the level of blood in the reservoir 123. Additionally, a level detector (not shown) may be included in conjunction with reservoir 123 to issue an alarm in response to detecting a low-level health condition within reservoir 123. Additionally, one or more air bubble detectors 128 may be positioned at various sites along extracorporeal circuit 120. Blood from reservoir 123 is drawn therefrom by pump 124. The illustrated embodiment includes a single-use centrifugal pump as pump 124, although in some cases a peristaltic pump from heart / lung machine 110 is used instead. Pressure generated by pump 124 propels the blood through oxygenator 125. A perfusionist adjusts pump 124 to operate as desired while avoiding operational issues such as negative cavitation, which can create micro-air pockets in the blood of extracorporeal circuit 120. Within oxygenator 125, venous blood is enriched with oxygen and carbon dioxide is removed from the blood. The now oxygen-rich arterial blood exits the oxygenator 125, travels through an arterial filter 126 which removes emboli, and is infused through an arterial tubing 127 into the patient's heart 12 via an aortic cannula 129.The extracorporeal circuit 120 may also include tubing and other components to facilitate functions such as, but not limited to, drainage of blood accumulating within the heart of the patient 10, providing surgical suction to maintain visibility of the surgical field, delivery of cardioplegia solution to facilitate cardioplegia of the heart 12 for the patient 10 during the procedure, measuring blood parameters, removing air from the blood, hemoconcentration, drug addition, obtaining blood samples, and heating and cooling of the blood.

[0031] During a surgical procedure using cardiopulmonary bypass machine system 100, various vital signs of patient 10 are measured and / or monitored. For example, the patient's mean arterial pressure ("MAP") may be measured. The patient's MAP is a parameter that the perfusionist operating cardiopulmonary bypass machine system 100 monitors during the surgical procedure to ensure that the cardiopulmonary bypass machine system 100 is functioning as desired. In some cases, the MAP reading is displayed on an anesthesia system screen and / or on an operating room screen. If the patient's MAP is outside of a desired range, the perfusionist may make adjustments to the cardiopulmonary bypass machine system 100 to improve the patient's MAP.

[0032] Heart / lung bypass machine system 100 also includes heart / lung machine 110, a complex system including multiple pumps, monitors, controls, user interfaces, alarms, safety devices, etc., all monitored and operated / adjusted by a perfusionist during the surgical procedure. For example, the illustrated heart / lung machine 110 includes arterial pump 111 (which may be the drive system for the illustrated disposable centrifugal pump 124 or a peristaltic pump), suction pump 112, vent / drainage pump 113, cardioplegia pump 114, and cardioplegia delivery pump 115. Heart / lung machine 110 may also include or be interfaced with devices such as tubing occluders, gas mixers, etc. Operating parameters of heart / lung machine 110, such as rotational speed and other parameters of each of the pumps, are set and adjusted by the perfusionist. For example, the speed of the arterial pump 111 is adjusted to maintain a desired level of blood in the reservoir 123 and provide the required level of blood circulation in the patient 10 .

[0033] The cardiopulmonary bypass machine system 100 also includes one or more temperature control systems 130. In a first embodiment, the temperature control system 130 is used to heat and cool the patient's blood within the oxygenator 125 via a heat exchanger. Additionally, the temperature control system 130 is used to heat and cool the cardioplegia fluid being delivered to the heart 12 of the patient 10. Typically, the temperature control system 130 is used in a cooling mode during the procedure (to reduce metabolic demand) and then used to warm the blood and / or cardioplegia fluid as the surgical procedure nears its completion. A perfusionist is tasked with monitoring and adjusting the temperature control system 130 as needed during the surgical procedure.

[0034] Cardiopulmonary bypass machine system 100 also includes a blood monitoring system 140, as shown. Blood monitoring system 140 is used to monitor the extracorporeal blood of patient 10 during the surgical procedure. Monitored parameters may include, but are not limited to, pH, pCO2, pO2, K+, temperature, SO2, hematocrit, hemoglobin, base excess, bicarbonate, minute oxygen consumption, and oxygen delivery. A perfusionist is tasked with monitoring blood monitoring system 140 during the surgical procedure. In some cases, the perfusionist is required to adjust other components or subsystems of cardiopulmonary bypass machine system 100 in response to readings from blood monitoring system 140.

[0035] Cardiopulmonary bypass machine system 100 also includes a perfusion data management system 150 and a regional oximetry system 160, as shown. These systems can also be used by a perfusionist to monitor the status of patient 10 and / or the status of cardiopulmonary bypass machine system 100 during a surgical procedure.

[0036] From the above discussion, it can be observed and understood that a perfusionist has a tremendous amount of very important responsibilities imposed upon them during a surgical procedure using cardiopulmonary bypass machine system 100. Providing assistance to the perfusionist by a system that uses artificial intelligence to facilitate autonomous or semi-autonomous operation can be very beneficial.

[0037] 2A , an exemplary computing system 202 (or “computer system”) can be used to perform a semi-autonomous medical procedure 200. The medical procedure 200 can include a practitioner 210 (e.g., a perfusionist or other type of clinician) and a patient 10. The computing system 202 can communicate (e.g., wired and / or wireless) with a heart-pulmonary bypass machine (HLM 110) monitoring device 204, a hospital database 206, one or more monitoring devices 218A-N, and a blood monitoring system 140 (e.g., a CDI® blood gas monitor). Wired and / or wireless communication can be provided via a network 212. The monitoring device 204 can display information about the HLM 110 and other devices / systems.

[0038] In some implementations, the monitoring devices 218A-N can include a local oximetry system 160 and / or a perfusion data management system 150, as described in connection with FIG. 1 . The monitoring devices 218A-N can be configured to monitor the real-time health of the patient 10 and / or the extracorporeal circuit 120 during the medical procedure 200. The monitoring devices 218A-N can be different types of monitoring systems and can include sensors and / or sensor arrays. The monitoring devices 218A-N can also be or comprise one or more cameras or other optical sensors. In some embodiments, the camera can view the device display and capture content displayed on the device display. The content can be interpreted and reported to the computing system 202 for use in further analysis, including to generate recommended procedure adjustments in real time during the procedure 200. In still other embodiments, the monitoring devices 218A-N can be devices that are not connected to the patient 10. Such devices 218A-N can include sensors configured to monitor the health of the patient 10's environment. For example, devices 218A-N may monitor room temperature and / or room humidity levels.

[0039] The computing system 202 may request and receive patient information from the hospital database 206 (A). The hospital database 206 may store patient information 220 and general patient information 222. The patient information 220 may be specific to a particular patient 10 undergoing the medical procedure 200. For example, the patient information 220 may include historical information about the patient 10 during previous procedures, health conditions, vitals, etc. The general patient information 222 may include, for example, anonymized information about patients who have undergone procedures similar to the medical procedure 200. The information 222 may also include anonymized information about patients with similar health conditions (e.g., age, gender, health issues, etc.) and / or vitals as the patient 10. Additionally, the information 222 may include anonymized general trends about the patients. The computing system 202 can use the patient-specific information 220 and general patient information 222 to perform a more robust analysis of the health conditions experienced by the patient 10 before, during, and after the procedure 200. This information can be useful in more accurately predicting potential benefits and harm to the patient 10. This information can also be useful in generating procedure adjustment recommendations that prevent predicted harm from occurring and optimize control adjustments and settings.

[0040] Computing system 202 can also automatically receive real-time health status of patient 10 from monitoring devices 218A-N and / or blood monitoring system 140 at B-C. Computing system 202 can also automatically receive real-time operational data (e.g., parameters, health status, feedback, readings, etc.) from one or more devices used during the procedure, such as from monitoring devices 218A-N and / or blood monitoring system 140. In some implementations, the real-time health status and patient information can be received simultaneously by computing system 202. In other implementations, the real-time health status and patient information can be received at different times (e.g., computing system 202 can request information and / or health status at different times). For example, computing system 202 can request patient information 220 and 222 before procedure 200. System 202 can use this requested information to predict patient health status during procedure 200. System 202 can also use this information to generate medical procedure adjustment recommendations.

[0041] During procedure 200, computing system 202 can request real-time health status from monitoring devices 218A-N and / or blood monitoring system 140 to confirm predictions made before procedure 200 began. The system can then make any necessary corrections or updates to the medical procedure adjustment recommendations. After procedure 200, computing system 202 can request patient information 220 and 222 and real-time health status to predict how the patient is likely to recover. The predictions can also be used to suggest treatments, therapies, etc. to accelerate and / or ensure a better recovery for the patient. In other examples, computing system 202 can continuously receive information from database 206, monitoring devices 218A-N, and blood monitoring system 140 before, during, and / or after procedure 200.

[0042] 2A , once computing system 202 receives patient information and / or real-time health conditions at A-C, system 202 can analyze the data at D. Artificial intelligence (AI), machine learning (ML), deep learning (DL), and / or other algorithms and models can be used by computing system 202 to predict trends in patient health conditions and parameters from one or more of monitoring devices 218A-N and / or blood monitoring system 140. For example, computing system 202 can iteratively analyze operational data from blood monitoring system 140 (e.g., heart / lung machine), parameters from one or more monitoring devices 218A-N, patient information 220 (e.g., “first medical data”), and general patient information 222 (e.g., “second medical data”) during a procedure. Computing system 202 can then determine a prediction that the operational data from blood monitoring system 40 or parameters from one or more monitoring devices 218A-N will tend to fall outside the target ranges during the procedure based on the above-described analysis of data defining target ranges for the operating parameters of blood monitoring system 140 and one or more monitoring devices 218A-N. These techniques can also be used to determine procedure adjustments that can maintain patient 10 safety and one or more parameters of blood monitoring system 140 and / or one or more monitoring devices 218A-N before, during, and / or after procedure 200.

[0043] In some embodiments, analyzing the data can be performed at a location remote from the procedure 200. In some examples, the computing system 202 can be a central server system that performs all analytics for various medical procedures (see, for example, FIG. 2B). The central server can be at a location remote from one or more of the medical procedures. In other examples, the computing system 202 can be at the location of the procedure 200 and communicate with one or more other computing systems at different locations. The system 202 can run algorithms or models that are specific to a particular device used during the procedure 200, such as the HLM 110. The system 202 can then communicate with one or more other computing systems that run other algorithms or models that are specific to other devices. As a result, more robust predictions and analyses can be performed through this distributed framework.

[0044] Based on analyzing data from multiple sources, the system 202 can determine and / or predict potential harm to the patient 10 as well as one or more safety ranges at E. As mentioned, E can be performed before, during, and / or after the procedure 200. A safety range can be determined for each parameter monitored by the devices 218A-N and the HLM 110. As further described with reference to FIGS. 7A-7D , it is important to maintain each parameter within its associated safety range during the procedure 200. Monitoring and maintaining each parameter can improve the overall health and safety of the patient 10. If a parameter escapes the determined safety range for that parameter, some level of action (e.g., adjustment) may be required. More severe and / or urgent adjustments may be made and required based on how many parameters exceed, or are expected to exceed, their associated safety ranges. A safety range for each parameter can be determined based on the real-time health status received at B and C and the patient information received at A.

[0045] The system 202 can then determine procedure adjustment recommendations at F and send the recommendations to the HLM monitoring device 204 at G. The procedure adjustment recommendations can include recommended changes to one or more of the monitoring devices 218A-N. These recommendations can be generated based on how many of the particular monitored parameters are exceeding or are expected to exceed the parameter's safety range. These recommendations can also be generated based on the patient's 10's overall real-time and / or predicted health status.

[0046] The practitioner 210 can make a decision (H) as to whether to implement one or more of the recommendations. In some embodiments, the practitioner 210 can select one or more of the recommendations on a user interface of the HLM monitoring device 204. In some implementations (e.g., a medical procedure in which a patient is put in serious harm requiring immediate procedure adjustments), the computing system 202 can transmit the determined procedure adjustments to the HLM monitoring device 204 and / or one or more monitoring devices 218A-N, which can then automatically implement the determined procedure adjustments without input or review from the practitioner 210. The computing system 202 can also inform the practitioner 210 of the procedure adjustments when they are being automatically and / or autonomously implemented. This can be beneficial in situations where one or more parameters (e.g., operating parameters) have exceeded or are expected to exceed the upper limits of a determined safety range (e.g., see FIGS. 7A-7D ). If one or more parameters are about to reach their upper limits, immediate action may be required to bring the parameters back into the safety range. Otherwise, if the parameters are not adjusted promptly, the patient's overall health and / or well-being may be put at risk. Whether the practitioner 210 makes a selection or the system 202 automatically performs the procedure adjustment, the practitioner 210 can maintain operational control of the procedure 200. The practitioner's 210 skills and expertise are not compromised; instead, the practitioner 210 can focus on other tasks that may arise during the procedure 200. In some embodiments, the practitioner 210 may be required to perform manual adjustments to one or more of the monitoring devices 218A-N. For example, a kink in the tube cannot be automatically fixed by the system 202. As a result, the practitioner 210 may be prompted to immediately fix a kink in the tube. The urgency of fixing the kink can be determined based on how close or how much the associated parameter exceeds the upper limit of the safety range.

[0047] In I, the practitioner's 210 selection of the procedure adjustment recommendation can be transmitted from the HLM monitoring device 204 to the computing system 202. The computing system 202 can update (J) the algorithms and / or models used by the system 202 to determine the patient harm and safety margin (E) and the procedure adjustment recommendation (F) based on the practitioner's 210 decision. For example, in some embodiments, the system 202 can generate a trained model for the procedure based on the predicted procedure adjustment recommendation and the practitioner's 210 selection of one of the recommendations. The trained model can be a deep learning model. Generating the trained model for the procedure can include iteratively training the model for the procedure by correlating each of the predictions to operational data from the blood monitoring system 140 (e.g., HLM), parameters from one or more monitoring devices 218A-N, patient information 220 (e.g., first medical data), and general patient information 222 (e.g., second medical data) across one or more model layers using one or more machine learning algorithms. The trained model can also be stored in a database. One or more other trained models can be generated. For example, the system 202 can generate a trained model for recommending procedure adjustments based on the practitioner's 210 autonomous implementation of one or more procedure adjustment recommendation selections.

[0048] Additionally, as described throughout this disclosure, system 202 can also determine predictions that operational data from blood monitoring system 140 or parameters from one or more monitoring devices 218A-N will tend to fall outside their respective target (e.g., safety, ideal) ranges based on applying the trained models for the procedure. As a result of generating such trained models and using them during analysis, computing system 202 can more accurately predict health conditions to ensure patient safety and improve procedure outcomes. System 202 can also update information about patient 10 and / or general patient information based on the trained models (J).

[0049] Additionally, in some embodiments, the system 202 may adjust the HLM 110 and / or one or more of the monitoring devices 218A-N based on the practitioner 210's decision at K. In other examples, as described throughout, the practitioner 210 may manually accomplish the procedure adjustment or update on behalf of the computing system 202. At the same time and / or a different time, the system 202 may transmit the updated patient information to the hospital database 206 for storage (L).

[0050] Real-time health status can be received from blood monitoring system 140 and / or monitoring devices 218A-N throughout D-L. Receiving real-time updates can be advantageous for computing system 202 to dynamically adjust the algorithms and / or models used to determine patient harm (E). Real-time updates can also be advantageous for dynamically adjusting one or more procedure adjustment recommendations provided to practitioner 210 (F). As a result, practitioner 210 can spend less valuable time during procedure 200 analyzing patient health status, as desired. Furthermore, practitioner 210 need not spend valuable time making decisions about whether and what type of procedure adjustment is needed to protect patient 10 from experiencing harm.

[0051] Continuous improvements in algorithms and / or models provide more accurate predictions of patient harm, individual parameters, and beneficial procedure adjustments. During a traditional procedure, it can be a challenge for the practitioner 210 to perform all of the tasks related to the procedure and simultaneously monitor all of the patient's health conditions. Typically, the practitioner 210 is alerted when the patient is on the verge of harm, and sometimes it is too late for the practitioner 210 to appropriately address the health condition causing harm. When the practitioner 210 is alerted to potential harm, the practitioner 210 may be under more stress to find a solution. Thus, the practitioner 210 may make mistakes in addressing the harm or other aspects of the procedure. The disclosed technology alleviates at least some of these problems by providing proactive, rather than reactive, predictions, suggestions, and / or solutions to mitigate patient harm.

[0052] 2B , the exemplary computing system 202 can be used to assist a practitioner 210 in performing and / or supervising multiple medical procedures 200A, 200B, and 200N on patients 10A, 10B, and 10N, respectively. The medical procedures 200A, 200B, and 200N can be performed simultaneously and / or at different times. In some implementations, the practitioner 210 can monitor the procedures 200A, 200B, and 200N from a remote location (such as a control room) via the HLM monitoring device 204.

[0053] As shown, computing system 202 can receive and transmit information / data to and from components / devices in each of procedures 200A, 200B, and 200N (see, e.g., FIG. 2A ). System 202 can analyze the health status of patients 10A, 10B, and / or 10N to determine procedure adjustment recommendations that will prevent patients 10A, 10B, and / or 10N from being harmed during procedures 200A, 200B, and 200N. System 202 can transmit such procedure adjustment recommendations to device 204. Practitioner 210 can select one or more of the procedure adjustment recommendations for one or more of procedures 200A, 200B, and 200N (see, e.g., FIG. 2A ).

[0054] In some examples, when practitioner 210 selects one or more procedure adjustment recommendations, the recommendations can be transmitted to devices in procedures 200A, 200B, and / or 200N. The devices in the procedure can notify a nurse, junior perfusionist, surgeon, or other practitioner at the procedure site (e.g., operating room) to perform such procedure adjustments. This is advantageous because the practitioner performing the actual procedure does not have to analyze the patient's health status and make a decision about the patient's level of harm. Instead, the practitioner can focus on performing the procedure and addressing other necessary tasks that may arise. In other examples, the selected procedure adjustment recommendations can be automatically performed / implemented by computing system 202 and / or one or more devices (e.g., robotic devices, semi-autonomous robotic devices, etc.) disposed in procedures 200A, 200B, and / or 200N. This is advantageous as it allows the practitioner performing the procedure to focus on the procedure instead of monitoring the health of the patient and / or the health of medical devices used during the procedure (e.g., HLM, urine bag monitor, etc.).

[0055] In some embodiments, the HLM monitoring device 204 can display an interactive user interface 203. The interface 203 can include information about each of the procedures 200A, 200B, and 200N. The displayed information can include real-time updates / health status (not shown) of the patients 10A, 10B, and / or 10N, and procedure adjustment recommendations 201, 231, and 241. The interface 203 can also display trend analyses of different health statuses for each patient, such as using 2D and / or 3D graphs (see, e.g., FIGS. 7B-7D).

[0056] Because a single practitioner 210 can oversee and monitor multiple procedures at once while performing or selecting procedure adjustments that prevent patients from experiencing harm and / or optimize patient outcomes, hospital and healthcare costs can be reduced. Thus, patient safety can be improved. Furthermore, in some implementations, real-time health conditions for patients 10A, 10B, and 10N can be used by computing system 202 to determine procedure adjustment recommendations for each of procedures 200A, 200B, and 200N. For example, if patients 10A, 10B, and 10N are undergoing the same medical procedure, computing system 202 can analyze patient 10A's response to one or more procedure adjustments in procedure 200A to determine which procedure adjustment recommendations to generate for procedures 200B and 200N. Such dynamic data analysis provides more robust and accurate real-time procedure adjustment generation.

[0057] In traditional medical procedures, practitioners do not have the time or ability to review and analyze data for different patients undergoing the same procedure at the same time. Therefore, the disclosed technology enables the integration of data from different sources in real time to generate patient harm predictions and procedure adjustment recommendations. Furthermore, this dynamic data analysis can be advantageous for continuously improving the algorithms and / or models used by computing system 202 to predict patient harm and determine optimal procedure adjustment recommendations.

[0058] 3 is a schematic diagram of an example computing system described herein. The computing system 202, monitoring devices 218A-N, database 206, and HLM monitoring device 204 communicate (e.g., wired and / or wireless) over a network 212. The database 206 can be associated with a particular medical institution, such as a hospital, where one or more of the procedures occur. In other examples, the database 206 can be a remote repository (e.g., in the cloud) that collects and stores anonymized patient data across different medical institutions.

[0059] In the illustrated example, the computing system 202 includes a patient health state prediction engine 310, a procedure adjustment recommendation engine 312, a prediction engine update module 314, an optional procedure device controller 316, and a communication interface 318.

[0060] The patient health state prediction engine 310 can be configured to predict how a patient is likely to respond to a medical procedure. The engine 310 can predict one or more safety ranges associated with different parameters monitored during a procedure. Understanding how each parameter may fluctuate during a procedure can be useful in determining a patient's overall health or wellness. Understanding how each parameter fluctuates can also be useful in generating adjustments to one or more monitoring and other procedural devices. The engine 310 can determine the patient health state and parameter safety ranges based at least in part on the patient information 220, general patient information 222, and / or procedure subject data 332 received from the database 206. The engine 310 can predict the patient health state and parameter safety ranges before, during, and / or after a medical procedure. Additionally, the engine 310 can adjust the predicted patient health state and / or parameter safety ranges in real time based on the patient's sensed health during the procedure.

[0061] The patient information 220 can be specific to the patient undergoing the medical procedure. The information 220 can include historical data 324 about the particular patient and / or current health data 326 about the patient. The current health data 326 can optionally include real-time information sensed by one or more of the monitoring devices 218A-N during the medical procedure. In some implementations, the data 326 can include data collected about the patient from previous similar procedures. In still other implementations, the data 326 can include a blood panel, an ECG, an EEG, an echogram, medications, skin conductivity, and / or any other vital signs monitored before, during, and after the medical procedure. Additionally, the historical data 324 can include age, region of residence, clinician notes, diagnosis, diet, gender, medical records, medications, race, sex, supplements, and / or vitamin intake, etc. Additional information about a particular patient, such as air intake, dietary intake, general stress level, and fluid intake, can be useful in determining how the patient will respond to a medical procedure compared to other patients.

[0062] The general patient information 222 may include historical data 328 about patients who have undergone similar procedures and / or have similar health conditions / vitals as the particular patient. The information 222 may also include current health condition data 330 of other patients who have undergone similar and / or the same procedures as the particular patient. The information 222 may include information that may not appear relevant to a human observer but is relevant to the algorithms used by the computing system 202. Information such as region of residence, air intake, dietary intake, general stress level, and / or water intake may prove beneficial in some cases to enable the computing system 202 to more accurately predict different patient health conditions and responses during medical procedures.

[0063] Procedure object data 332 can include information about devices and / or objects being used before, during, and / or after a medical procedure. For example, a procedure object can be any living or non-living item that is to remain in, on, and / or with a particular patient during and / or after a medical procedure. The object can be permanent, semi-permanent, or temporary. Non-limiting examples of procedure objects include a patient's appendix, biopsy, heart valve, kidney stone, knee replacement, organ transplant, pacemaker, and tonsils. Data 332 can include composition, health status, lot number, part number, status, profile, shipping history, or any other information related to performing a procedure with a procedure object. The procedure subject data 332 may also include information about devices and / or health conditions attached to the patient during the medical procedure, including, but not limited to, electrocautery scalpels, HLMs (via cannulas / tubing), intravenous devices, robotic joint replacement assist devices, long-term microinfusion devices, urinary catheters, and ventilators.

[0064] Returning to the computing system 202, the procedure adjustment recommendation engine 312 can be in communication with the patient health state prediction engine 310. The engine 312 can determine which procedure adjustments should occur during a medical procedure to prevent the patient from being harmed. The engine 312 can also determine procedure adjustments to prevent one or more of the monitored parameters from exceeding the upper and lower limits of associated safety ranges (e.g., see FIGS. 7A-7C).

[0065] The engine 312 can generate one or more procedure adjustment recommendations that are communicated to the HLM monitoring device 204. A practitioner at the device 204 can select one or more of the generated procedure adjustment recommendations for implementation. The selected procedure adjustments can then be implemented manually by the practitioner and / or automatically (e.g., autonomously and / or semi-autonomously) by the computing system 202. Adjustments can also be implemented by devices located at the site of the procedure and / or in communication with the HLM monitoring device 204 and / or computing system 202. In a preferred example, procedure adjustments can be implemented essentially immediately to prevent predicted harm to the patient from occurring. As a result, the patient can remain in a safe health state (e.g., safe range, target range, ideal range) before, during, and after the medical procedure.

[0066] The monitoring device 204 may have an output display 338, an input device 340, and a communication interface 342. The output display 338 may be configured to output one or more procedure adjustment recommendations generated and provided by the computing system 202. The display 338 may also output one or more real-time health conditions of the patient during the medical procedure. Additionally, the output display 338 may display health conditions sensed by the blood monitoring system 140 of the HLM 110.

[0067] In some embodiments, a practitioner can use the monitoring device 204 to monitor and / or control the HLM 110. The input device 340 can receive the practitioner's selection of one or more of the procedure adjustment recommendations. The input device 340 can also receive commands from the practitioner for semi-autonomous actions to be taken. For example, the practitioner can use the input device 340 to remotely adjust blood flow levels in the HLM 110. In some implementations, the input device 340 and the output display 338 can be a single device, such as a touchscreen. In other implementations, the input device 340 can be at least one of a keyboard, a mouse, a microphone, or any other conventional input device. Finally, the communication interface 342 can provide communication between the monitoring device 204 and one or more other components, devices, or systems described herein.

[0068] Returning again to the computing system 202, the prediction engine update module 314 can be configured to continuously update the AI, ML, and / or DL ​​algorithms and models used by the computing system 202 to predict a patient's health status, predict safety margins, and generate procedure adjustment recommendations. The module 314 can make continuous improvements based at least on which procedure adjustments are selected by the practitioner. The continuous improvements can also be based on how the patient responds to the selected procedure adjustments. Furthermore, the continuous improvements can be based on how a general population of patients is predicted to respond to the selected procedure adjustments. The continuous improvements can also be based on how a general population of practitioners is predicted to respond to the recommended procedure adjustments. Moreover, the continuous improvements can be based on real-time health conditions sensed during the procedure for the patient, the HLM 110, and / or the subject being used during the procedure. Continuous improvement can be advantageous to ensure that the computing system 202 produces accurate and reliable patient health predictions and procedure adjustment recommendations for each medical procedure, regardless of specific patient or procedure information.

[0069] Module 314 can be configured to provide updated information about patients, general patients, and procedure subjects to database 206. For example, module 314 can generate a model for a particular patient that indicates how the patient is expected to respond to the procedure and similar procedures. This model can be stored in patient information 220 and accessed by computing system 202 during subsequent similar procedures to more quickly and accurately predict how the patient will respond and determine which procedure adjustment recommendations should be generated. This model can be further updated, modified, and / or refined by module 314 during each subsequent procedure. Doing so can ensure more accurate predictions for patients in the future. As another example, module 314 can generate one or more models based on generalized, anonymous patients who have undergone similar and / or identical procedures. Such models can be stored in general patient information 222 and accessed when a particular patient undergoes the modeled procedure. The model can be used to more accurately predict how a particular patient will respond to a procedure by comparing the patient's health status with the modeled health status for general patients.

[0070] With further reference to computing system 202, in some embodiments, procedure device controller 316 can be configured to operate / control one or more devices used during a medical procedure and / or perform the medical procedure. For example, in an autonomous or semi-autonomous medical procedure, controller 316 can be instructed to perform / implement procedure adjustment suggestions generated by engine 312. In some embodiments, controller 316 can perform procedure adjustments without confirmation and / or input from a practitioner at monitoring device 204. In other implementations, such as when a single practitioner oversees several procedures from a remote location, the practitioner can provide input to computing system 202 that instructs controller 316 to perform selected procedure adjustments on the practitioner's behalf (e.g., semi-autonomous medical procedures). The practitioner can then remotely monitor the procedure adjustments as they are performed by controller 316. In yet other implementations, the practitioner can select a procedure adjustment at monitoring device 204 and then manually perform / implement the procedure adjustment. In such a scenario, the controller 316 may not be activated.

[0071] Finally, communication interface 318 provides computing system 202 for communication with one or more of the components described herein.

[0072] 4 is a flowchart of an example method 400 for performing a semi-autonomous medical procedure. Method 400 can be performed by a computing system (e.g., computing system 202) as described throughout this disclosure.

[0073] In step 402, procedure data can be received. As described herein, procedure data can include historical and real-time information about a patient undergoing a procedure. Data can be received before, during, and after the procedure. Procedure data can also include historical, anonymized data about the general patient, procedure subjects, and other devices used during the procedure.

[0074] In step 404, one or more patient health conditions and parameter safety ranges can be predicted. One or more of the data received in step 402 can be applied to AI, ML, and / or DL ​​models and / or algorithms to predict how the patient will respond to the medical procedure. This information can also be used to determine upper and lower safety ranges for each of the parameters being monitored during the procedure (see, e.g., FIGS. 7A-7C). Step 404 can be performed before the procedure begins. The predictions made in step 404 can then be continuously updated, if needed, during the procedure.

[0075] Procedure adjustment recommendations can be generated in step 406. As described below, procedure adjustment recommendations can be generated based on determining the range within which the patient will experience normal or safe health conditions during the procedure. A computing system described herein can determine that the patient is predicted to deviate from an overall safety range (e.g., a target range or an ideal range) at a certain time. The computing system can also determine that one or more parameters are predicted to deviate from a safety range (e.g., a target range) associated with the one or more parameters. As a result, the computing system can generate appropriate adjustment suggestions that can be applied to the procedure some time before the time when the patient and / or any of the parameters are predicted to deviate from their associated safety ranges. When the adjustments are implemented during the procedure, the patient's health conditions can be maintained within the safety range, thereby avoiding predicted harm. Furthermore, the adjustments can keep the patient's health conditions within an ideal range (target range), thereby maximizing patient outcomes.

[0076] In step 408, the procedure adjustment recommendations can be output to a display of the computing device. Step 408 can be performed after steps 402-406. For example, steps 402-406 can be performed before the medical procedure begins. Step 408 can be performed when the computing system determines that a procedure adjustment should occur to maintain either the patient or a parameter within an associated safety range during the medical procedure. A practitioner at the computing device can select one or more of the recommendations, and the selected recommendations can be received by the computing system in step 410.

[0077] The patient health state prediction algorithm can be updated in step 412. Additionally and / or alternatively, one or more other AI, ML, or DL ​​models can be updated to more accurately predict patient health states, safety margins, and subsequent procedure and procedure adjustment recommendations for the patient. Steps 402-412 can be repeated continuously over the duration of the medical procedure, as well as before and / or after the medical procedure.

[0078] 5A-5B are flowcharts of a process 500 for predicting patient health status before, during, and after a semi-autonomous medical procedure. Process 500 can be performed by a computing system described herein (e.g., computing system 202). One or more steps of process 500 can be performed during different times of the medical procedure. For example, with reference to FIG. 5A, steps 502-504 can be performed pre-procedure, i.e., before the medical procedure begins. Steps 506-512 can be performed during the procedure, i.e., while the medical procedure is in progress. Steps 514-516 can be performed post-procedure, i.e., after the medical procedure is completed.

[0079] In some examples, the pre-procedure steps can be performed immediately before the medical procedure begins. In other examples, the pre-procedure steps can be performed a certain amount of time before the medical procedure begins. The intra-procedure steps can be dynamically adjusted based on health conditions sensed and received in real time. Furthermore, in some implementations, the patient health condition can be predicted during the procedure as well as before the procedure. The post-procedure steps can be performed immediately after the medical procedure is completed. In some examples, the post-procedure steps can be performed a certain amount of time after the medical procedure. As a result, the health condition of the patient's recovery can be analyzed and used to augment the algorithms, ML, and / or AI techniques used to predict the patient health condition.

[0080] 5A , data can be received in step 502 before the procedure. As described herein, the data can include past patient data, current patient health conditions, past general patient data, past general patient current health conditions, and procedure subject data. Data can be continuously received from one or more sources (e.g., monitoring devices 218A-N, blood monitoring system 140, hospital database 206) during the pre-procedure, intra-procedure, and post-procedure phases. For example, during the intra-procedure phase, historical data about the patient can be received to diagnose and / or analyze a unique health condition the patient is experiencing during the procedure. Historical data about general patients can also be useful during this phase to determine whether the patient is currently experiencing any health conditions that are atypical for the procedure. As another example, during the post-procedure phase, the current patient health conditions and past general patient current health conditions can be received to determine whether the patient is recovering from the procedure in an atypical manner from the general population of patients who have undergone the same procedure.

[0081] Once the relevant data is received in step 502, a patient health state during the procedure can be predicted in step 504. Additionally and / or optionally, one or more parameter safety ranges can be determined in step 504 (see, for example, FIGS. 7A-7C). Step 504 can be performed before the procedure. Step 504 can also be performed during the procedure. Whether step 504 is performed before, during, or not, the patient health state prediction during the procedure can be dynamically adjusted to accommodate real-time changes in the patient's health state. The algorithms, models, ML techniques, and / or AI used by the computing system to make the prediction in step 504 are continuously trained on historical data as well as real-time data. Thus, the patient health state prediction can be more accurately generated before the procedure. The patient health state prediction may not need to be corrected and / or adjusted during the intraprocedural phase. This can reduce the time required to generate potential procedure adjustment recommendations and apply such modifications before the patient is harmed. As a result, patient safety can be improved.

[0082] Once the patient health status and / or safety range are predicted in step 504, a procedure adjustment recommendation can be determined in step 506. This step can occur during the intraprocedural phase. As another example, this step can occur pre-procedure. The procedure adjustment recommendation can be determined at least in part based on real-time health status received from one or more components used during the medical procedure. For example, blood oxygen content can be continuously monitored by a blood gas monitor (e.g., a CDI® monitor) as blood flows between the HLM and the patient's body. Based on real-time changes in blood oxygen content, a computing system can generate one or more procedure adjustments to adjust the HLM. Step 506 can be performed pre-procedure based on applying one or more algorithms, machine learning, and / or artificial intelligence techniques described herein. Such techniques can be used to analyze past patient health status and general patient health status during similar procedures for which one or more procedure adjustment recommendations were generated and / or performed.

[0083] Additionally, the techniques described herein can be used to generate fewer procedure adjustment recommendations in step 506. For example, a trained ML model can predict that, based on all data received in step 502, only one procedure adjustment will prevent a patient from being harmed. In other words, as the techniques described herein become more trained, they can more accurately determine fewer, more effective procedure adjustment recommendations. Providing the practitioner with fewer procedure adjustment recommendations can also prevent the practitioner from being overwhelmed with information during a medical procedure. The practitioner will be less overwhelmed making decisions about modifying the procedure and can focus on performing the procedure, ensuring patient safety, and optimizing patient outcomes.

[0084] During an autonomous procedure, if a trained ML model or other techniques described herein generate a procedure adjustment, that procedure adjustment can be implemented quickly and automatically because the computing system does not need to compare multiple procedure adjustment recommendations to identify and select the most optimal one. This improves the efficiency of the medical procedure. It also reduces the risk of patient harm during the procedure.

[0085] Once procedure adjustment recommendations are determined in step 506, the recommendations can be output during the procedure in step 508. As described throughout, the recommendations can be output to a display on the practitioner's monitoring device (e.g., HLM monitoring device 204). The practitioner can select one or more of the recommendations on the monitoring device.

[0086] The practitioner's selection is received by the computing system in step 510. Based on the practitioner's selection, the computing system may apply a modification to one or more of the associated procedural devices (e.g., the computing system may send a signal to the HLM to adjust blood flow) in step 512. In other examples, the practitioner may select a modification and perform the modification manually.

[0087] The patient health status and safety range prediction algorithms, or other machine learning and / or artificial intelligence techniques and models described herein, can be updated in step 514. The updates can be based at least in part on which procedure adjustments the practitioner selects. The updates can also be based on the real-time health status of (1) the patient, (2) the procedure device, and / or (3) the procedure subject during and / or after the medical procedure. Step 514 can be performed after the procedure. Step 514 can also be performed during the procedure. Performing step 514 during the procedure is beneficial for more accurately and dynamically determining procedure adjustments.

[0088] In step 516, the data received in step 502 can be updated after the procedure. The data can be continuously updated in real time (e.g., during the medical procedure). Updating the data in real time can be advantageous so that the updated data is usable in predicting patient health status and determining procedure adjustment recommendations during the medical procedure. Once the data is updated, it can be stored (e.g., in database 206).

[0089] Steps 502-516 can be repeated continuously and / or a fixed number of times. Repeating process 500 is advantageous for continually improving and enhancing the modeling and prediction techniques described herein. As a result, more accurate and reliable patient health state predictions and procedure modification recommendations can be generated.

[0090] FIG. 5B is another example of the process 500 described in connection with FIG. 5A. As shown, a medical procedure is divided into three phases: pre-procedure, intra-procedure, and post-procedure. During the pre-procedure phase, individual patient-procedure data collected during the medical procedure is stored along with individual patient historical data. Pre-procedure, individual patient pre-procedure data (e.g., heart rate before the procedure begins), ancillary pre-procedure data (e.g., information about living or non-living objects used and / or inserted and / or removed from the patient before, during, or after the procedure), individual patient historical data, generalized patient historical data, and generalized patient-procedure data can be collected. This data can be used by the algorithms, ML, and / or AI techniques described herein. Patient pre-procedure data can include pre-procedure response testing data. For example, an EKG-connected patient can be exposed to a temporary test dose of an anesthetic agent and / or drug (e.g., a non-routine stressor) to characterize the patient's behavior, response, and / or safety. Data collected about patient response to test doses can be used to refine algorithms or other techniques used to more accurately predict patient health status. This data can also be used to more accurately determine patient safety ranges, limits, and default settings for medical procedures.

[0091] The data described above can be used during the procedure to determine patient health conditions before the procedure (e.g., see the "AI Before 'Patient Connected' box in FIG. 5B), during the procedure (e.g., see the "AI During 'Patient' Connected' box in FIG. 5B), and after the procedure (e.g., see the "AI After 'Patient' Connected' box in FIG. 5B). One or more of the algorithms, ML models, and / or AI techniques described herein can be used to determine these health conditions. Accordingly, procedure adjustment recommendations can be generated during the procedure. One or more of the predicted health conditions can be output to an operator's (e.g., practitioner's) device. Input (e.g., practitioner selection of procedure modification recommendations) can also be received from the operator's device. Information received from the operator's device can be used to refine and / or adjust patient predictions before, during, and after the procedure.

[0092] Information can also be received from one or more other devices used during the procedure, such as patient monitoring devices and procedural devices. This information can be used by one or more of the techniques described herein to refine and / or adjust predictions of patient health status before, during, and after the procedure. Patient predictions and procedure modification (e.g., adjustment) recommendations can be output to one or more of the devices (e.g., settings of the HLM can be automatically adjusted).

[0093] The algorithms and other techniques used and described herein are continuously modifiable (e.g., see the "AI-Generated Fine Tuning to the Algorithm Set" box in FIG. 5B). The techniques described herein can be initially configured by humans. Using AI and / or DL, the techniques can be continuously and iteratively improved. Furthermore, adjustments to the techniques can include continuous improvement of the procedure-specific algorithm set (e.g., see the "AI Procedure-Specific Algorithm Set" box in FIG. 5B). In other words, the algorithm used to predict how a particular patient is going to respond to a particular procedure can learn from improvements made to other algorithms and thus adjust based on the improvements. The other algorithms can, for example, predict how a typical patient will respond to a similar or more generalized procedure. As a result, the algorithms can learn from each other to further refine the techniques, even when the algorithms are altered to generate predictions for different devices, procedures, and / or patients. Such continuous refinements can improve the ability of any of the algorithms used to more accurately predict patient health status and procedure adjustment recommendations. The algorithms described herein can also be improved using information received from a variety of sources (see, e.g., the "Other Information Entries" box in FIG. 5B), including hospital laboratory information management systems and remote databases or data warehouses.

[0094] Monitoring, therapy, and even procedure-related equipment can track the patient in a post-procedure setting. Thus, the disclosed technology can continue to collect valuable information / data before, during, and after the procedure. As a result, patient recovery health status can be predicted. After the procedure, patient procedure data, patient outcome data, and ancillary target outcome data can be updated based on predictions made during the procedure. The updated data can be fed back to the pre-procedure phase, which collects generalized patient history data, procedure data, and individual patient history data. Patient outcome data can be collected over time. Patient outcome data can include a subset of the complete patient post-procedure history or consist of the complete patient post-procedure history. This information can be useful for one or more of the techniques described herein when predicting patient health status and / or procedure adjustment recommendations. Ancillary target outcome data can include any information about ancillary items (e.g., subjects) that alters (or confirms the absence of) the "ancillary pre-procedure data" and / or creates information about newly generated ancillary items during the procedure. This information can be correlated with patient pre-procedure data. This information can also be correlated with patient outcome data.

[0095] Patient procedure data, patient outcome data, and ancillary target outcome data can be fed into an algorithm or model along with procedure data, device procedure data, and operator procedure data. Device procedure data can include a record of all inputs, outputs, and any other information collected from each of the devices used during the procedure. Operator procedure data can include a record of all actions taken by an operator (e.g., a practitioner) during the procedure. Algorithms can include a record of all actions, observations, and / or real-time health status indicating what happened during the procedure. Algorithms can be used to augment and adjust / fine-tune one or more of the algorithms or other techniques used during the procedure (e.g., AI-generated tweaks to the algorithm set and AI procedure-specific algorithm set). Continuous improvement of the techniques described herein can result in more accurate predictions being made before, during, and after a medical procedure to prevent patient harm, improve patient safety, and reduce the cost of the medical procedure.

[0096] 6A-6C are flowcharts of a process 600 for improving prediction of a patient's health status after a semi-autonomous medical procedure is completed. Process 600 can be performed by a computing system as described throughout this disclosure.

[0097] Referring to FIG. 6A, post-procedure data can be received in step 602. As described in connection with FIGS. 5A-5B, the post-procedure data can be intra-procedure patient health status, post-procedure patient health status, procedure-target intra-procedure data, and / or procedure-target post-procedure data. Using the data received in step 602, the patient health status prediction algorithm described herein can be updated in step 604. The procedure adjustment algorithm described herein can also be updated in step 606. Stored data can then be updated in step 608. Patient data, general patient data, and procedure target data can be updated based at least in part on the post-procedure data. Once the information and / or algorithms are updated, patient recovery can be predicted in step 610. The predicted patient recovery can also be based on real-time health status or other information received from devices connected to the patient during and after the procedure. Steps 602-610 can be repeated continuously and / or for a predetermined period of time. The patient recovery prediction can then be adjusted based on real-time health status after the procedure. After patient recovery is predicted in step 610, process 500 described in connection with Figure 5A can be performed.

[0098] 6B-6C are additional examples of the process 600 described in connection with FIG. 6A. FIG. 6B illustrates how the algorithms described herein are used to continuously improve and / or update patient data. For example, as described in connection with FIG. 5B, algorithms are applied to analyze and determine trends for procedure data, device procedure data, operator procedure data, patient procedure data, patient outcome data, and ancillary target outcome data. Insights gleaned from such analyses can be stored as ancillary post-procedure data, individual patient procedure data, generalized patient historical data, and generalized patient procedure data. Information from one or more other post-procedure data sources (e.g., manually entered by the operator) can be incorporated into the ancillary post-procedure data and individual patient procedure data. As illustrated in FIG. 6B, updating and / or refining the data and algorithms used to predict patient health status and procedure modifications is a continuous process. Doing so ensures that the algorithms used to make these predictions are accurate and reliable.

[0099] FIG. 6C illustrates how the algorithms described herein can be used to continuously improve / update algorithms used to make predictions throughout a medical procedure. For example, as described in connection with FIG. 5B , an algorithm for predicting patient health status during a procedure can be applied to one or more general algorithm sets to enhance and refine those algorithm sets. One or more procedure-specific algorithm sets can be enhanced and / or refined based on improvements made to the general algorithm set. As a result, the algorithms and techniques described throughout are continuously improved. Continuous improvement is beneficial for providing more accurate analysis of patient health status and procedure adjustment predictions.

[0100] With reference to both Figures 6B-6C, DL can be used independently and / or in conjunction with AI or other techniques described herein. DL can augment existing algorithms / sets of algorithms and / or databases implemented in the disclosed technology. Pattern recognition is the primary purpose of DL, looking for relationships between factors that are not easily observable to humans. As an illustrative example, individuals who have consumed chlorinated water for more than 12 years continuously and who are prone to episodes of gout may be found to be 175% more susceptible to acute kidney injury (AKI). This injury may be manifested, for example, by a decrease in oxygen delivery (DO2) of 272 mL min-1 for more than 3 minutes. -1 m -2 This can occur during cardiopulmonary bypass (CPB) when oxygen delivery is below threshold for more than 5.5 minutes or 250 mL min for more than 2.5 minutes. -1 m -2 It may also be discovered that when the patient's blood pressure is either below 100 or 150, the likelihood of injury is 535% higher. DL can be performed in the disclosed technology to analyze data (e.g., past patient data, current patient data, general patient historical data, general patient current data, surveys, or information from the internet or other sources) over extended periods of time to make these discoveries. Such discoveries can be applied to the techniques described herein to more accurately determine and predict patient health status, safety margins, and procedure adjustment recommendations.

[0101] 7A is a flowchart of an example process 700 for generating procedure modification recommendations. Process 700 can be performed by a computing system as described herein.

[0102] Initially, in step 702, data can be received from one or more sources. The data can include generalized patient procedure data, generalized patient historical data, pre-procedure patient health states, predicted patient health states, intra-procedure patient health states, procedure-targeted pre-procedure data, and procedure-targeted intra-procedure data.

[0103] Based on the received information, the computing system can determine a patient safety range in step 704. A patient safety range is generally a range for the duration of a procedure within which one or more parameters associated with the patient's health status should be maintained. Deviation from that range can result in patient harm. Ideally, the patient should be kept within a safety range within which potential harm can be predicted, addressed, and avoided. As a result, the patient can remain within the safety range during the procedure.

[0104] In traditional procedures, practitioners often are not informed that a patient is no longer within the safety range until the patient experiences some level of harm. At this point, in some cases, there may be too much and / or too much risk to make adjustments to the procedure. However, the techniques described herein alleviate this problem by helping to ensure that the patient remains within the patient safety range for the duration of the procedure.

[0105] Further referring to step 704, the computing system can compare the generalized patient procedure data with the patient's pre-procedure health status. In doing so, the system can determine whether the patient is entering the procedure with a different health status than previous patients. If the patient is experiencing the same or similar health status, the computing system can determine the patient's safety range based on the previously determined patient safety range. On the other hand, if the patient is experiencing a different health status than previous patients, the computing system can analyze other data received in step 702 to determine an optimal safety range for this particular patient. The determined patient safety range can also adapt and / or change over time based on predicted patient health status, patient health status recorded during the procedure, the procedure subject's health status before the procedure, the procedure subject's health status during the procedure, etc.

[0106] Dynamic adjustment of patient safety ranges during a procedure is advantageous in ensuring that the patient does not experience harm. Dynamic adjustment is also advantageous in ensuring that practitioners appropriately and quickly address patient safety issues before the patient is potentially harmed. Furthermore, receiving data from multiple sources in real time provides more accurate predictions of patient harm and patient safety scenarios. This is because practitioners, especially during a procedure, may not have the ability, capability, or time to review and analyze such a large amount of information and then make an accurate decision that determines whether the patient will be harmed during the procedure.

[0107] Once the patient safety range is determined, the computing system can determine whether the predicted patient health state exceeds the patient safety range in step 706. In some examples, the computing system can receive real-time information from one or more monitoring devices indicating the patient's health state during the procedure and / or the health state of the procedure subject during the procedure. This information can be used in addition to the predicted patient health state to determine the patient's real-time health state. Thus, the systems described herein can continuously update information regarding the patient's health state to identify whether the patient remains within the safety range. For example, before the procedure, process 700 can be performed by the computing system to determine / predict the patient's safety range. During the procedure (e.g., during the procedure), the safety range can be dynamically updated or modified based on the sensed real-time health state.

[0108] Returning to step 706, if the predicted patient health state exceeds the patient safety range, the computing system can determine a procedure modification recommendation (e.g., adjustment) in step 712. In other words, the system determines that at some point during the procedure, the patient is not within the safety zone and action needs to be taken to prevent the patient from leaving the safety zone. The procedure adjustment recommendation can be made based on analyzing the patient's real-time health state and comparing the real-time health state with the pre-procedure health state. By doing so, the computing system can determine how much the patient's health state changes over a period of time and how long the patient will have before they may leave the safety zone. Based on such a determination, the computing system can identify what relevant or proactive specific procedure adjustments should be.

[0109] Once a procedure adjustment is determined, the computing system can receive the patient's real-time health status and / or procedure target in step 714. Using this information, the computing system can select one of the procedure adjustments in step 716. The selection of a preferred procedure modification can be adjusted in real time based on the patient's health status compared to a prediction of how the patient will be. For example, if the real-time health status indicates that the patient will deteriorate from the planned / predicted patient health status, the computing system can select a more aggressive procedure modification (e.g., adjustment). On the other hand, if the real-time health status matches the predicted patient health status, a gentler, less extreme procedure modification can be selected. Selecting the optimal procedure modification can also depend on the planned amount of time it will take for the patient's health status to exceed the patient safety range. If the patient ultimately deviates from the safety range for a long period of time, a more gradual procedure modification can be selected. As a result, the patient can still remain within the patient safety range, but the patient's body may not be shocked no matter what procedure modification is selected. On the other hand, if the patient is on the verge of departing from the safe range, more aggressive procedure modifications are employed.

[0110] In some implementations, the computing system can select one or more of the procedure adjustment recommendations, or none, in step 716. This can be advantageous in semi-autonomous medical procedures in which the practitioner not only supervises but also performs the procedure. As a result, the practitioner has more ability to control the procedure and make decisions during the procedure. This can also be advantageous in situations in which the patient is within a safety range and is expected to remain within the safety range without many procedure adjustments. In other words, if the patient's health status does not fluctuate and / or fluctuates only slightly, the need for procedure adjustments is much lower. Thus, more procedure adjustments can be presented to the practitioner, and the practitioner can use their judgment to choose whether to adopt any of the procedure adjustments, modify them, or reject them.

[0111] Next, in step 718, the selected procedure adjustment can be output. As described throughout this disclosure, the selected procedure adjustment can be output to a device used by the practitioner, such as an HLM monitoring device. If multiple procedure adjustments are output to the practitioner's device, the procedure adjustments can be ranked in order of priority. For example, the computing system can suggest which of the procedure adjustments would be best implemented during the procedure. This is advantageous because it protects the practitioner from having to divide their attention and make such decisions while performing the medical procedure. As another example, if a patient is expected to fall outside of a patient safety range fairly quickly (e.g., the patient's health condition is deteriorating and, without immediate procedure adjustments, the patient will be harmed), the selected procedure adjustment can be output along with an indicator to the practitioner that a procedure adjustment is needed and must be made immediately. As a result, the practitioner can implement the procedure adjustment immediately without having to spend time deciding whether to implement the procedure adjustment and assessing the patient's current health condition. The practitioner can instead focus on other aspects related to completing the procedure.

[0112] Similarly, in step 720, the selected procedure adjustment can be implemented. In some medical procedures, the modification can be implemented by the practitioner. For example, the practitioner can select the modification from the output and then manually perform the modification. In other examples, when the practitioner selects the modification, instructions to complete the modification can be sent to a device that performs the modification. As an example, instructions to adjust the blood flow of the HLM can be sent to the HLM and / or other controllable devices such that the HLM and / or other devices automatically perform the adjustment. In yet other examples where a practitioner oversees multiple procedures at once, upon selection of the procedure adjustment, instructions to implement the procedure adjustment (e.g., modification) can be sent to one or more practitioner devices performing the procedure such that one or more practitioners can manually and / or semi-autonomously perform the procedure adjustment.

[0113] In some implementations, the procedure adjustment can be performed automatically by a computing system and / or one or more devices (e.g., during an autonomous medical procedure) in step 720. If the procedure adjustment is critical (e.g., the patient is quickly deviating from a safety range) and there is not enough time to receive confirmation from the practitioner before performing the procedure adjustment, the procedure adjustment can be performed automatically in step 720.

[0114] As described in more detail below, as procedural adjustments are performed, one or more algorithms used in the process 700 described herein can be updated.

[0115] Returning to step 706, if it is determined that the predicted patient health state does not deviate from the patient safety range, the computing system can identify that the patient is within the safety range and that no procedure adjustment is required at that time (step 708). One or more algorithms used in process 700 can then be updated in step 710. The algorithms can be updated so that much more accurate predictions of the patient's health state and patient safety range can be generated before and during a medical procedure. If pre-procedure predictions become more accurate, changes to such predictions are less likely during the procedure. This will improve the efficiency of addressing potential harm to the patient. If patient health states and safety ranges can be more accurately identified, procedure adjustment recommendations can also be more accurately determined and selected before the procedure, but also during the procedure. Continuously improving the algorithms and processes described herein is advantageous to ensure that any potential health states and / or harms can be predicted and addressed before they become issues for patient well-being and safety. As mentioned, all these predictions can be made pre-procedure, thereby improving the efficiency and accuracy of decision-making during the procedure.

[0116] After the algorithm is updated in step 710, steps 702-720 may be repeated. These steps may be repeated a predetermined number of times before or during the procedure. These steps may also be repeated for the duration of the procedure. As described throughout, repeating process 700 is advantageous to ensure more accurate predictions and dynamic adjustment of predictions, safety margins, and / or procedure modifications accounted for in real time for changes to patient health status.

[0117] FIG. 7B is an exemplary graph of patient health status during a conventional manual medical procedure. Traditionally, practitioners often do not observe that patient health status is trending away from the ideal range (or target range) for some given parameter. Range limits may be set to trigger alarms / alerts, and time is often the first indicator to the practitioner that a situation requires procedural adjustment. However, traditionally, there is no device-based notification to the practitioner of a change in patient health status trend. The practitioner needs time to analyze why the alert occurred, consider how to respond, implement the response, and then realize that their response stopped further progression but did not reverse the situation (e.g., while still within the zone of ongoing patient harm). In some conventional settings, the practitioner may overcorrect, then reverse the overcorrection, eventually returning this one given parameter to an apparent steady state within the ideal range. Furthermore, while the practitioner is preoccupied with correcting a given parameter, other parameters may escape the ideal range. Thus, during a traditional, manual medical procedure, it can become more difficult for a practitioner to assess and address one or more parameters before they exceed the ideal range, pass through range limit 2, and enter range limit 3, where the patient experiences harm.

[0118] FIG. 7C is an exemplary graph of a patient's health status during a semi-autonomous medical procedure. As shown, range limits exist on either side of an ideal range (or "target range") for a particular parameter. The ideal range is a zone within which the disclosed technology generates information about multiple upper and lower limits, maintains the patient's health status within the multiple upper and lower limits, and optimizes and generates the multiple upper and lower limits based on each specific patient. The range limits are not necessarily the same distance apart (e.g., 2-L is closer to 1-L than 2-U is to 1-U). During the medical procedure, each of the patient's health status should remain within the upper and lower range markers, range limit 1-U and range limit 1-L.

[0119] The disclosed technology and methods described herein are advantageous for predicting the future health status of a patient and the health status of one or more parameters monitored during a procedure to determine procedure adjustments. Procedure adjustments can be made to prevent either the patient or the monitored parameters from falling outside their associated ideal ranges (also called target ranges or safety ranges). Thus, the patient or parameter health status should not be in any region of patient harm or in any range above the ideal range during the procedure.

[0120] The range limits can change during the procedure. For example, the range limits can be pre-designed to change based on health conditions predicted before the procedure using the disclosed technology. In other examples, the range limits can change in real time during the procedure based on real-time changes in the patient's health condition, changes in monitored parameters, predictions made using the disclosed technology, and / or actions taken by the practitioner.

[0121] FIG. 7D is an exemplary schematic diagram of a patient 10 undergoing a procedure 730 using an exemplary semi-autonomous computing system described herein. The patient 10 can be attached to one or more monitoring and procedural devices, including an HLM 110, a blood gas monitor 140, an oximeter 736, a sensor array 732, a catheter 738, and a urine collection bag 734. In this exemplary embodiment, a monitor, display, and processing system 740 are usable by a practitioner. The system 740 can include an HLM monitoring device 204 and a computing system 202, as shown and described throughout this disclosure. As a result, some of the predictions of patient health status and parameter levels can be performed at the same location as the practitioner overseeing the procedure 730. As described throughout this disclosure, predictions of one or more patient health status and parameter levels can also be performed in a computing system in a different location that communicates with the system 740. In other embodiments, the practitioner can use a monitoring device / display separate from the computing system (see, e.g., FIGS. 2-3 ).

[0122] Each of the oximeter 736, HLM 110, blood gas monitor 140, sensor array 732, urine collection bag 734, and patient 10 can be continuously monitored by system 740 before, during, and after procedure 730. System 740 can determine safety ranges (e.g., target ranges, ideal ranges) for parameters associated with each of these devices and patient 10. As described throughout, system 740 can predict whether any of the parameters associated with these devices and patient 10 are expected to exceed their associated safety ranges, and if so, what procedure adjustment recommendations should be made and provided to the practitioner.

[0123] Additionally, correlating historical and real-time data for multiple devices used during the procedure 730 can enable more accurate predictions of patient outcomes, patient safety, patient harm, and procedure adjustment recommendations. For example, the health status of the HLM 110 can be monitored and automatically adjusted by the disclosed technology simultaneously with monitoring the urine collection bag 734. The sensor array 732 can be a pass-through device as shown (e.g., where outflow from the patient passes through on its way to the collection bag 734), can be integrated with the collection bag 734, or can be separate from the bag 734 as shown, but can communicate to / from the bag 734 and sensors, leads, etc., and / or any combination thereof. If the sensors 732 and / or sensor monitor know the volume of the collection bag 734, a prediction of impending overflow can be generated by the system 740. Procedure adjustments and / or notifications can be provided to the practitioner before the bag 734 actually overflows so that an overflow can be avoided.

[0124] The system 740 can provide procedure information 750 to the practitioner on a monitor / display. The procedure information 750 can be updated in real time as one or more health conditions or parameters change based on actions taken by the practitioner when performing the procedure 730. The system 740 can also dynamically update and / or adjust safety ranges for each of the parameters and / or the patient 10. Based on such changes in real time, the system 740 can provide procedure adjustment recommendations to the practitioner to maintain each of the parameters and / or the patient 10 within the associated safety range before, during, and after the procedure 730.

[0125] The procedure information 750 may include patient information 752 and information for each parameter and / or patient 10 monitored during the procedure 730. For example, the patient information 752 may include the patient's name, birthdate, procedure date, and scheduled procedure time. Additional information, such as pre-existing health conditions that may affect procedure outcome, may be included. As shown in FIG. 7D , parameters 754A-N may be included in the procedure information 750. One or more additional parameters being monitored may be illustrated in the information 750. All of the parameters 754A-N may be simultaneously maintained within a safety range. The faster the response rate from the practitioner and / or the greater the degree of AI autonomy, the longer the duration during the procedure 730 during which all of the parameters 754A-N are maintained within a safety range.

[0126] Each of the parameters 754A-N can be verified using a graph. The graph can show predictions or trends for the parameters 754A-N before, during, and after the procedure 730. One or more procedure adjustment recommendations can be made and displayed for each of the parameters 754A-N in the procedure information 750.

[0127] As described throughout, safety ranges and range limits can be based on general and individual patient data, including pre-procedure response testing data and / or procedure target data. Using the techniques described herein, range limit settings can be suggested to the practitioner, to be displayed as procedure information 750. The practitioner can accept the settings and / or make corresponding adjustments. The practitioner's adjustments can be recorded. These adjustments can optionally and / or additionally be displayed in procedure information 750. For example, if an adjustment is made to parameter 754A, the associated graph can be updated to reflect the real-time change. Updates can then be made to the algorithms or other techniques used to determine and suggest range limits (e.g., safety zones or ranges) based on the particular practitioner's adjustments, what other practitioners typically do, patient procedure data, patient outcome data, and other data sources described herein.

[0128] As shown in FIG. 7D, a graph of parameters 754A-N shows the level or rate over time, supplemented by indications of other factors such as minimum, maximum, and maximum values. The level or rate of each parameter 754A-N' corresponds to units seen from mass spectrometry, and the accumulated values ​​indicate what en masse analysis will ultimately indicate retrospectively. The example of parameter 754A illustrates one of the many benefits afforded by the disclosed technology: continuous monitoring that indicates whether parameter 754A is predicted to exceed acceptable or safe levels over time. As a result, practitioners can become aware of potential increases in the value of parameter 754A and address those increases before they occur.

[0129] As another example, an exemplary graph of parameter 754B illustrates a cumulative situation, such as a CPB procedure, where hemoglobin appears in the urine (e.g., hemoglobinuria). The graph can be predicted and generated based on continuous monitoring of the urine collection bag 734. Traditional population analysis only retrospectively reveals that an unacceptable, potentially dangerous situation occurred during the procedure 730. The disclosed technology not only alerts the practitioner that a threshold has been exceeded, but also predicts the situation by reporting the rate change at the inflection point and providing the practitioner with procedure adjustment recommendations and / or automatically completing such procedure adjustments.

[0130] In conventional medical procedures, the oxygenator reservoir (e.g., the venous return reservoir) can reach a low level, thereby setting off an alarm. Conventional systems are typically preprogrammed to immediately shut off pumps, such as the arterial pump, when the alarm is activated. When the arterial pump is automatically shut off, the patient endures zero perfusion (e.g., no oxygen delivery and no carbon dioxide removal) until the problem is manually resolved. Recovery is not instantaneous when flow from the oxygenator reservoir is resumed, for example, because the patient's metabolism continues. This results in oxygen deficiency and carbon dioxide buildup. Therefore, the oxygenator and flow settings must be reset and continuously adjusted by the practitioner until patient health stability is restored. The longer a patient remains in alarm, the more difficult and lengthy it becomes to return the patient to a stable state.

[0131] Using the disclosed technology, as described herein with respect to FIG. 7D , a computing system 740 (e.g., computing system 202 of FIGS. 2-3 ) can automatically predict when the oxygen reservoir level is or will be decreasing based on information received from the pump 111 flow rate and / or oxygenator reservoir level detector before and / or during the procedure 730. Such a prediction can be displayed in the procedure information 750 (e.g., parameter 754A can be associated with the oxygen reservoir). The computing system 740 can, for example, trigger and / or suggest to the practitioner a reduced pump speed when the reservoir level reaches zero rather than waiting for an alarm.

[0132] As mentioned, the disclosed technology can be used to continuously monitor and predict the health status / parameters of any device and generate procedure adjustments for any of those devices used during the medical procedure 730. For example, using the disclosed technology, data input and AI interpretation of these inputs can result in alerts, alarm health status, and procedure adjustments for blood levels in the venous reservoir, bubble activity in the vital blood pathway of a CPB circuit, and system pressure in various portions of the circuit. The disclosed technology can also use predicted health status to automatically intervene in the procedure 730 to prevent patient harm by temporarily adjusting critical metabolic support pump function. Early notifications can be sent to the practitioner to provide more time for procedure adjustments while the arterial pump or venous occluder initiates a response to changing health status, for example, involving blood volume or system pressure. As a result, more consistent patient support can be provided with efficient, less stressful practitioner responses to changing health status, which, in the absence of autonomous procedure adjustments, can result in interruptions in metabolic support.

[0133] As yet another example, the rate of blood volume change in the HLM 110 can be continuously monitored and used by the disclosed technology to generate practitioner notifications. The disclosed technology can more accurately predict emptying times and optimal rates of arterial blood pump flow reduction. Predictions can be made automatically, so that blood flow problems can be resolved and a measure of support can be maintained for the patient 10 while full cardiopulmonary bypass support can be resumed.

[0134] 8A-8B are exemplary block diagrams of different layers of patient health status predictions interacting with each other. FIG. 8A refers to the different patient health status predictions as being layered. As shown, the algorithms, AI, and other techniques described herein are applicable to different patients A-N, whether they are at the same facility, undergoing the same medical procedure, or supervised by the same practitioner. Data and health status sensed / collected / predicted during any one of the procedures for patients A-N can be used by a computing system in assessing and determining health status / procedure adjustments for any of the other patients A-N. The computing system described herein can be remote from any or all of patient A-N's procedures (e.g., see FIGS. 2A-2B ) while maintaining high capacity and speed to more efficiently generate health status and procedure adjustments for each of patients A-N.

[0135] 8B references the interplay of one or more layers of patient health status prediction. Information associated with each patient is transferred from the patient's remote location and usable by a computing system to predict each patient health status and / or procedure adjustment (see, e.g., FIGS. 2A-2B).

[0136] In some examples, each of the patient locations can include a computing system that runs one or more predictive models on the patient data. Each patient location computing system can have its own specialized models. For example, Patient A's location computing system can have an advanced model of kidney function and metabolism. Patient B's location computing system can have an advanced model for liver monitoring. Patient C's location computing system can have an advanced model for spleen function. These specialized models can then be accessed by patient computing systems at different patient locations as well as by the computing systems described herein (e.g., computing system 202 of FIG. 2).

[0137] Any patient-location computing system can be configured to support multiple procedures at multiple locations. For example, patient A's kidneys can be monitored using a patient A-location computing system model. However, patient A's liver can be monitored using a patient B-location computing system model, and patient A's spleen can be monitored using a patient C-location computing system model. As a result of such continuous connectivity and communication between different patient-location computing systems and the computing systems described herein, patient A's kidney, liver, and spleen health can be maintained within their respective safety ranges / zones during patient A's medical procedures.

[0138] Embodiments of the subject matter and operations described herein can be implemented in digital electronic circuitry, or in computer software, firmware, or hardware, including the structures disclosed herein and their equivalents, or in any combination of one or more of them. Embodiments of the subject matter described herein can also be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a computer storage medium for execution by, or to control the operation of, a data processing apparatus.

[0139] A computer storage medium can be or be included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of these. Further, a computer storage medium is not a propagated signal, but a computer storage medium can be a source or destination of computer program instructions encoded in an artificially generated propagated signal. A computer storage medium can also be or be included in one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

[0140] The operations described herein may be implemented as operations performed by a data processing apparatus on data stored on one or more computer-readable storage devices or received from other sources.

[0141] The term "data processing apparatus" encompasses all kinds of apparatuses, devices, and machines for processing data, including, by way of example, a programmable processor, a computer, a system-on-chip, or two or more of the foregoing, or a combination of the foregoing. An apparatus may include special-purpose logic circuitry, e.g., an FPGA (field-programmable gate array) or an ASIC (application-specific integrated circuit). In addition to hardware, an apparatus may also include code that creates an execution environment for the computer program in question, e.g., code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The apparatus and execution environment may implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0142] A computer program (also known as a program, software, software application, script, or code) can be written in any type of programming language, including compiled or interpreted, declarative or procedural, and can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers located at one site or distributed across multiple sites and interconnected by a communications network.

[0143] The processes and logic flows described herein may be performed by one or more programmable processors executing one or more computer programs to perform actions by operating on input data and generating output. The processes and logic flows may also be performed by, and an apparatus may be implemented as, special purpose logic circuitry, for example, an FPGA (field programmable gate array) or an ASIC (application specific integrated circuit).

[0144] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Generally, a processor receives instructions and data from a read-only memory or a random-access memory, or both. The essential elements of a computer are a processor for performing actions in accordance with the instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices, e.g., magnetic, magneto-optical, or optical disks, for storing data, or is operatively coupled to receive data from or transfer data to, or both. However, a computer need not have such devices. Furthermore, a computer can be embedded in another device, e.g., a mobile phone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive), to name just a few. Suitable devices for storing computer program instructions and data include all types of non-volatile memory, media, and memory devices, including, by way of example, semiconductor memory devices, e.g., EPROM, EEPROM, and flash memory devices; magnetic disks, e.g., internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and memory can be supplemented by, or incorporated in, special purpose logic circuitry.

[0145] To provide for user interaction, embodiments of the subject matter described herein can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) monitor or LCD (liquid crystal display) monitor, for displaying information to a user, a keyboard, and a pointing device, e.g., a mouse or trackball, by which a user can provide input to the computer. Other types of devices can be used to provide for user interaction as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user can be received in any format, including auditory input, speech input, or tactile input. Additionally, a computer can interact with a user by sending documents to and receiving documents from a device used by the user, e.g., by sending a web page to a web browser on the user's user device in response to a request received from the web browser.

[0146] Embodiments of the subject matter described herein can be implemented within a computing system, including as a back-end component, e.g., a data server, or including a middleware component, e.g., an application server, or including a front-end component, e.g., a user computer having a graphical user interface or web browser through which a user can interact with an implementation of the subject matter described herein, or any combination of one or more such back-end, middleware, or front-end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communications network. Examples of communications networks include local area networks (“LANs”) and wide area networks (“WANs”), internetworks (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0147] A computing system can include a user and a server. The user and server are generally remote from each other and typically interact through a communications network. The relationship of user and server arises by having computer programs running on the respective computers and having a user-server relationship to each other. In some embodiments, the server sends data (e.g., HTML pages) to the user device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the user device). Data generated at the user device (e.g., results of user interaction) can be received from the user device at the server.

[0148] While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any intervention or on what may be claimed, but rather as descriptions of features that are specific to particular embodiments of particular interventions. Some features described herein in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment can also be implemented separately in multiple embodiments or in any suitable subcombination. Furthermore, while features may work in several combinations above and even be initially claimed as such, one or more features from a claimed combination can, in some cases, be deleted from the combination, and the claimed combination may be directed to subcombinations or variations of the subcombination.

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

[0150] Specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the actions recited in the claims can be performed in a different order and still achieve desirable results. As an example, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.

Claims

1. 1. A system for performing an open heart surgical procedure on a patient, comprising: heart / lung machine; one or more monitoring devices configured to monitor parameters indicative of the patient's health during the procedure; first medical data describing one or more health conditions of the patient; Second medical data summarizing general population health information of other patients; third medical data defining target ranges for operating parameters of the heart / pulmonary machine and the one or more monitoring devices during the procedure; a database storing the In real time during the procedure, operational data from the heart / lung machine; the parameters from the one or more monitoring devices; the first medical data; the second medical data; and the third medical data; a computer system configured to receive the wherein the computer system repeatedly performs the following during the procedure: analyzing (i) the operational data from the heart / lung machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data; determining a prediction that the operational data from the heart / lung machine or the parameters from the one or more monitoring devices will tend to fall outside the target range based on a comparison of the analysis of (i)-(iv) with the third medical data; The system further comprises:

2. The system of claim 1 , wherein the computer system is further configured to generate a trained model for the procedure based on the prediction.

3. 3. The system of claim 2, wherein generating the trained model for the procedure comprises iteratively training a model for the procedure by correlating each of the predictions, across one or more model layers, to (i) the operational data from the heart / lung machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data using one or more machine learning algorithms.

4. The system of claim 2 or 3, wherein the trained model is stored in the database.

5. 5. The system of claim 2, wherein the computer system is further configured to determine a prediction that the operational data from the heart / pulmonary machine or the parameters from the one or more monitoring devices will tend to fall outside the target range based on applying the trained model for the procedure.

6. 6. The system of claim 1, wherein the computer system is further configured to generate recommended adjustments to be made to at least one of the heart / pulmonary machine or the one or more monitoring devices in real time during the procedure based on the prediction.

7. The computer system, in real time during the procedure, selecting one or more of the recommended adjustments based at least in part on analyzing (i) the operational data from the heart / lung machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data; and autonomously implementing the selected one or more recommended adjustments. The system of claim 6 further configured to:

8. 10. The system of claim 7, wherein the computer system is further configured to generate a trained model for recommending procedure adjustments based on autonomously performing the selected one or more recommended adjustments.

9. The system of claim 1 , wherein the computer system is further configured to receive operational data from a plurality of heart / lung machines.

10. The system of claim 1 , wherein the one or more monitoring devices include at least one of a camera or a sensor array.

11. The system of claim 1 , wherein the one or more monitoring devices include a urine bag monitor.

12. The system of claim 1 , wherein the first medical data includes a current health condition of the patient and a past health condition of the patient.

13. The system of claim 1 , wherein the second medical data includes past health information of a patient who underwent the procedure.

14. 1. A computer-implemented method for use while performing an open heart surgical procedure on a patient, comprising: receiving, by a computer system in real time during the procedure, (i) operational data from a heart / lung machine; (ii) parameters indicative of the patient's health condition during the procedure from one or more monitoring devices; (iii) first medical data describing one or more health conditions of the patient; (iv) second medical data summarizing health information of a general population of other patients; and (v) third medical data defining target ranges for operational parameters of the heart / lung machine and the one or more monitoring devices during the procedure; repeatedly analyzing (i)-(iv) by the computer system during the procedure; determining a prediction that the operational data from the heart / lung machine or the parameters from the one or more monitoring devices will tend to fall outside the target range based on a comparison of the analysis of (i)-(iv) with the third medical data; A method for providing

15. 15. The method of claim 14, further comprising generating a trained model for the procedure based on the prediction.

16. 16. The method of claim 15, wherein generating the trained model for the procedure further comprises iteratively training a model for the procedure by correlating each of the predictions to (i) the operational data from the heart / lung machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data, across one or more model layers using one or more machine learning algorithms.

17. 17. The method of claim 16, further comprising determining a prediction that the operational data from the heart / pulmonary machine or the parameters from the one or more monitoring devices will tend to fall outside the target range based on applying the trained model for the procedure.

18. 1. A system for performing a medical procedure on a patient, comprising: The medical treatment system, one or more monitoring devices configured to monitor parameters indicative of the patient's health during the procedure; first medical data describing one or more health conditions of the patient; Second medical data summarizing general population health information of other patients; third medical data defining target ranges for operating parameters of the medical treatment system and the one or more monitoring devices during the procedure; a database storing the a computer system including one or more processors, the one or more processors performing real-time processing during the procedure; operational data from the medical treatment system; the parameters from the one or more monitoring devices; the first medical data; the second medical data; and the third medical data; receiving instructions to configure the computer system to receive wherein the computer system repeatedly performs the following during the procedure: (i) analyzing the operational data from the medical treatment system, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data; determining a prediction that the operational data from the medical treatment system or the parameter from the one or more monitoring devices will tend to fall outside the target range based on a comparison of the analysis of (i)-(iv) with the third medical data; The system further comprises:

19. 20. The system of claim 18, wherein the computer system is further configured to generate recommended adjustments to be made to the medical treatment system or at least one of the one or more monitoring devices in real time during the procedure based on the prediction.

20. The computer system, in real time during the procedure, selecting one or more of the recommended adjustments based at least in part on analyzing (i) the operational data from the medical treatment system, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data; and autonomously implementing the selected one or more recommended adjustments.

20. The system of claim 19, further configured to:

Images