Semi-autonomous medical system and method

Abstract

This document describes medical systems that use artificial intelligence to facilitate autonomous or semi-autonomous medical procedures. For example, this document describes a heart / lung machine system used in conjunction with an artificial intelligence system to facilitate autonomous or semi-autonomous open-heart surgery operations.

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 on November 1, 2019. The disclosure of the prior application is considered to be a part of the disclosure of this application (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 Art

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

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

[0005] A heart / lung mechanical system, together with an extracorporeal circuit and a hollow fiber artificial lung, is used to meet the patient's circulation and blood gas exchange needs during medical procedures such as cardiopulmonary bypass surgery. To obtain the amount of flow required to maintain a sufficient volume in the reservoir of the extracorporeal circuit, the blood from the patient is either drained by gravity or vacuum assisted venous drainage (VAVD) is used. A pump, such as a peristaltic pump or a centrifugal pump, coupled to a magnetic drive system, is sometimes used in the main line of the extracorporeal circuit to pump the blood that returns from the reservoir, through the artificial lung, and ultimately to the patient. In addition to the heart / lung machine itself, the cardiopulmonary machine system can include multiple types of patient monitoring devices used in connection 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 together with other devices / systems. For example, this document describes a heart / lung machine system used in connection 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 health state of the patient during the procedure. The database stores (1) first medical data describing one or more health states of the patient, (2) second medical data summarizing health information of a general population of other patients, and (3) third medical data defining target ranges for operating parameters of the heart / lung machine and the one or more monitoring devices during the procedure. The computing system is configured to receive in real time during the procedure (a) operating data from the heart / lung machine, (b) parameters from the one or more monitoring devices, (c) the first medical data, (d) the second medical data, and (e) the third medical data. The computing system is further configured to repeatedly analyze during the procedure (i) the operating 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. The computing system is further configured to repeatedly determine during the procedure a prediction that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target ranges based on a comparison of the analysis of (i)-(iv) with the third medical data.

[0008] Such a system for performing open-heart surgery 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 a prediction. In some embodiments, generating a trained model for the procedure comprises iteratively training a model for the procedure by correlating each of the predictions with (i) motion data from a 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 model may be stored in a database. The computer system may be configured to determine a prediction that motion data from the heart / lung machine or parameters from one or more monitoring devices tend to be outside a target range based on applying a trained model for the procedure. In some embodiments, the computer system is further configured to generate recommendations for adjustments to be made in real time during the procedure to at least one of the heart / lung machine or one or more monitoring devices based on the prediction. The computer system may be further configured to select one or more of the recommended adjustments based at least in part on analyzing, in real time during the procedure, (i) motion data from the heart / lung machine, (ii) parameters from one or more monitoring devices, (iii) first medical data, and (iv) second medical data. The computer system may be further configured to autonomously implement one or more of the selected 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 one or more of the selected recommended adjustments. The computer system may be further configured to receive motion data from multiple heart / lung machines. In some cases, one or more monitoring devices include at least one of a camera or a sensor array.One or more monitoring devices may also include a urine collection bag monitor. The first medical data may include the patient's current health state and the patient's past health state. The second medical data may include past health information of the patient who has undergone a procedure.

[0009] In another aspect, the present disclosure is directed to a computer-implemented method for use while performing an open-heart procedure on a patient. The method includes receiving, in real-time during the procedure by a computer system, (i) operating data from a heart / lung machine, (ii) parameters indicative of the patient's health state during the procedure from one or more monitoring devices, (iii) first medical data describing one or more health states 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 operating parameters of the heart / lung machine and one or more monitoring devices during the procedure. The method also includes repeatedly analyzing (i)-(iv) during the procedure by the computer system. The method further includes determining, based on a comparison of the analysis of (i)-(iv) with the third medical data, a prediction that the operating data from the heart / lung machine or the parameters from one or more monitoring devices tend to be outside the target ranges.

[0010] Such a computer-implemented method for use while performing a cardiac 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 a prediction. Generating a trained model for the procedure may include iteratively training a model for the procedure by correlating each of the predictions with (i) motion data from a 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 motion data from the heart / lung machine or parameters from one or more monitoring devices tend to be outside a target range based on applying a 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 health state of the patient during the procedure. The database stores (1) first medical data describing one or more health states of the patient, (2) second medical data summarizing health information of a general population of other patients, and (3) third medical data defining target ranges for operating parameters of the medical treatment system and the one or more monitoring devices during the procedure. The computing system is configured to receive, in real time during the procedure, (a) operating data from the medical treatment system, (b) parameters from the one or more monitoring devices, (c) the first medical data, (d) the second medical data, and (e) the third medical data. The computing system is further configured to repeatedly analyze, during the procedure, (i) the operating 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. The computing system is further configured to repeatedly determine, during the procedure, a prediction that the operating data from the medical treatment system or the parameters from the one or more monitoring devices tend to be outside the target ranges 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 recommendations for adjustments to be made in real time during a procedure to at least one of the medical treatment system or one or more monitoring devices based on a prediction. The computer system may be configured to select, at least in part based on analyzing, during the procedure in real time, (A) (i) operational data from the medical treatment system, (ii) parameters from one or more monitoring devices, (iii) first medical data, and (iv) second medical data, one or more of the recommended adjustments, and (B) to autonomously implement the one or more selected recommended adjustments.

[0013] The techniques described in this document can be used to provide multiple advantages and benefits. For example, the techniques used to assist clinicians in determining medical procedure adjustments that ensure the health and safety of patients during a medical procedure are improved by the systems and methods described herein. As described herein, the need for medical procedure adjustments can be accurately predicted and provided in a timely manner to clinicians, such as perfusion technicians, during the medical procedure. For example, in some cases, the clinician can be informed of the likelihood of harm to the patient such that the clinician can address and avoid the harm before it occurs. This protects the clinician from having to spend significant time during the procedure to make any such decisions. This can also reduce the likelihood of human error when making such decisions during the stress of the procedure. The safety of the patient and the outcome of the procedure can be improved for these reasons.

[0014] The disclosed technology can also enhance information processing to provide benefits to patients and care providers. The ability of one human to analyze large amounts of complex data about a patient and the general population of patients is limited. Further, human analysis can sometimes miss relevant data that could otherwise be used to accurately assess a patient's health status during a procedure. The technology described herein can overcome these challenges by providing technical means that understand and analyze thousands of data and provide predictive trends and analytics regarding patient safety before, during, and after a medical procedure. Further, the technology enables the incorporation of data from a 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. The continuous improvement is advantageous in ensuring that the disclosed system can predict a patient's health status during any type of medical procedure.

[0015] Furthermore, labor costs can be reduced using the systems and methods described herein. For example, in some cases, as described below, the labor costs of perfusion technicians who control the heart / lung machine 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 perfusion technicians to focus on a single procedure, control medical devices, perform procedure adjustments, and determine what adjustments are needed to ensure patient safety. Instead, in some cases, practitioners such as perfusion technicians can supervise multiple procedures at once from a central location and receive the decisions and / or recommendations generated for each of the multiple procedures by the disclosed technology. The disclosed technology can enhance the ability of practitioners to address problems that occur during procedures. 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 performed remotely and / or autonomously. These procedure adjustments can also be presented or proposed to the practitioner, who can make an actual decision as to whether to perform the proposed procedure adjustment.

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

[0017] The cost of medical procedures can also be reduced for several reasons. First, fewer practitioners can be hired because one practitioner can supervise multiple procedures at once. Second, practitioners can focus on performing medical procedures without the need to divert their attention to monitoring devices and the patient's health status. Third, human errors 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 one of ordinary skill in the art to which this invention pertains. Although methods and materials similar or equivalent to those described herein can be used in the practice of the present invention, suitable methods and materials are described herein. In case of conflict, the present specification, including definitions, will control. Furthermore, the materials, methods, and examples are illustrative only and not intended to be limiting. Moreover, all references to features or objects A - N mean that there can be any number of such features or objects.

[0019] 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 Description of the Drawings

[0020]

Figure 1

Figure 2A

Figure 2B

Figure 3

Figure 4

Figure 5A

Figure 5B

Figure 6A

Figure 6B

Figure 6C

Figure 7A

Figure 7B

Figure 7C

Figure 7D

Figure 8A

Figure 8B

DETAILED DESCRIPTION OF THE INVENTION

[0021] The same reference numbers represent corresponding parts throughout.

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

[0023] The system provided herein for performing semi-autonomous medical procedures on a patient is described primarily in the context of open-heart surgical procedures that use a heart / lung bypass machine, but it should be understood that open-heart surgical procedures that use a heart / lung bypass machine are merely examples. The innovative concepts described in the context of open-heart surgical procedures that use a heart / lung bypass machine extend to a variety of other types of medical procedures that use a medical treatment system, including but not limited to, other devices / systems.

[0024] As shown in FIG. 1, while patient 10 is connected to a life support heart / lung bypass machine system 100, various types of medical procedures can be performed on patient 10. In this example, patient 10 is undergoing open-heart surgery, during which the heart 12 and lungs of patient 10 are temporarily and intentionally stopped from functioning. However, since the body of patient 10 continues to have metabolic requirements for a supply of oxygenated blood circulating during the medical procedure, the heart / lung bypass machine system 100 performs such functions. That is, as further described below, the heart / lung bypass machine system 100 is connected to patient 10 and performs the functions of the heart 12 and lungs of patient 10 so that patient 10 remains alive and healthy during open-heart surgery.

[0025] The heart / lung bypass machine system 100 can be used for many different types of medical procedures. For example, medical procedures for which the heart / lung bypass machine system 100 can be used include, but are not limited to, coronary artery bypass graft, heart valve repair, heart valve replacement, heart transplant, lung transplant, ablation procedures, repair of septal defects, repair of congenital heart defects, repair of aneurysms, pulmonary endarterectomy, pulmonary thromboembolectomy, and the like.

[0026] A heart / lung bypass machine system 100 is generally set up and operated by a specially trained clinician / operator, called a perfusionist. The perfusionist forms part of a broader cardiovascular surgical team that includes a cardiac surgeon, an anesthesiologist, and a nurse. During a medical procedure using the heart / lung bypass machine system 100, the perfusionist has many responsibilities, among which is particularly important to ensure that the patient 10 is kept alive and healthy by operating the heart / lung bypass machine system 100 in a manner that maintains blood flow to the patient's tissues and regulates the levels of oxygen and carbon dioxide in the patient's blood. Other responsibilities of the perfusionist include, but are not limited to, administering blood products, administering anesthetics or narcotic drugs, measuring selected clinical test values (such as blood cell counts), monitoring circulation, monitoring blood gases, monitoring anticoagulation, introducing hypothermia, and including hemodilution. The responsibilities of the perfusionist are diverse and dynamic and are critically important to achieve a good outcome of the procedure performed on the patient 10 using the heart / lung bypass machine system 100.

[0027] In the illustrated example, the heart / lung 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 the heart / lung bypass machine system 100 may not require all of the illustrated components and subsystems. Some types of procedures using the heart / lung bypass machine system 100 may require additional components, monitors, and / or subsystems not shown.

[0028] The extracorporeal circuit 120 is connected to 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 (registered trademark) blood gas monitor manufactured 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 patient 10 at the patient's heart 12. Blood that has been depleted of oxygen from patient 10 (venous blood) is withdrawn from patient 10 at the patient's heart 12 using a venous catheter 121. As further described below, the blood circulates through the extracorporeal circuit 120 to receive oxygen and remove carbon dioxide. The oxygenated blood is then returned to the patient's heart 12 through the extracorporeal circuit 120 via an aortic cannula 129.

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

[0030] Put simply, the extracorporeal circuit 120 operates by removing oxygen-depleted blood from the patient's vein via the venous catheter 121 and introducing the venous blood into the reservoir 123 via the venous tube 122. In some cases, gravity is used to cause or drain the blood to flow from the patient 10 to the reservoir 123. In some cases, a vacuum is used to assist the blood to flow from the patient 10 to 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 becomes empty, air can be pumped into the extracorporeal circuit 120 and potentially into the patient's vasculature. Such a result would likely be catastrophic for the patient 10. Therefore, the perfusion technician 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 the reservoir 123 to issue an alarm in response to the detection of a low-level condition in the reservoir 123. Further, one or more bubble detectors 128 can be placed at various sites along the extracorporeal circuit 120. Blood from the reservoir 123 is withdrawn from the reservoir 123 by the pump 124. The illustrated embodiment includes a single-use centrifugal pump as the pump 124, but in some cases, the peristaltic pump of the heart / lung machine 110 is used instead. The pressure generated by the pump 124 propels the blood through the artificial lung 125. The perfusion technician adjusts the pump 124 to operate as desired while avoiding operating problems such as negative cavitation that can create microbubbles in the blood of the extracorporeal circuit 120. Inside the artificial lung 125, the venous blood is oxygenated and carbon dioxide is removed from the blood. The now oxygen-rich arterial blood exits the artificial lung 125, moves through the arterial filter 126 that removes emboli, and is injected into the patient's heart 12 via the aortic cannula 129 through the arterial tube 127.The extracorporeal circuit 120 can include, without limitation, drainage of blood accumulating within the heart of patient 10, providing surgical suction to maintain visibility in the surgical field, delivery of cardioplegia fluid to facilitate cardioplegia of the heart 12 for patient 10 during the procedure, measuring blood parameters, removing air from the blood, blood concentration, drug addition, obtaining blood samples, tubes and other components to facilitate functions such as heating and cooling of the blood, etc.

[0031] During a surgical procedure using the cardiopulmonary bypass machine system 100, various vital signs of patient 10 are measured and / or monitored. For example, the patient mean arterial pressure (“MAP”) may be measured. The MAP of patient 10 is a parameter that is monitored by the perfusion technician operating the cardiopulmonary bypass machine system 100 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 the screen of the anesthesia system and / or on the operating room screen. If the MAP of patient 10 is outside the desired range, the perfusion technician may make adjustments to the cardiopulmonary bypass machine system 100 to improve the MAP of patient 10.

[0032] The heart / lung bypass machine system 100 also includes a heart / lung machine 110. The heart / lung machine 110 is a complex system including a plurality of pumps, a monitor, a control mechanism, a user interface, an alarm, a safety device, etc., all of which are monitored and operated / regulated by a perfusion technician during the surgical procedure. For example, the illustrated heart / lung machine 110 includes an arterial pump 111 (which can be a drive system for a disposable centrifugal pump 124 or a peristaltic pump as shown), a suction pump 112, a vent / drainage pump 113, a cardioplegia solution pump 114, and a cardioplegia solution delivery pump 115. The heart / lung machine 110 can also include or interface with devices such as tubing clamps, gas mixers, etc. The operating parameters of the heart / lung machine 110, such as the rotational speed, and other parameters of each pump are set and adjusted by the perfusion technician. For example, the speed of the arterial pump 111 is adjusted to maintain the desired level of blood in the reservoir 123 and provide the required level of blood circulation in the patient 10.

[0033] The heart / lung bypass machine system 100 also includes one or more temperature control systems 130. In a first aspect, the temperature control system 130 is used to heat and cool the patient's blood in the artificial lung 125 via a heat exchanger. Further, the temperature control system 130 is used to heat and cool the cardioplegia solution being delivered to the patient's heart 12. Generally, the temperature control system 130 is used in a cooling mode during the procedure (to reduce metabolic requirements), and then, when the surgical procedure is approaching its end, it is used to warm the blood and / or the cardioplegia solution. The perfusion technician 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, as shown, a blood monitoring system 140. The blood monitoring system 140 is used to monitor the patient 10's extracorporeal blood during a surgical procedure. The parameters to be monitored can include, but are not limited to, pH, pCO2, pO2, K+, temperature, SO2, hematocrit, hemoglobin, base excess, bicarbonate, minute oxygen consumption, and oxygen transport. The perfusion technician is tasked with monitoring the blood monitoring system 140 during the surgical procedure. In some cases, the perfusion technician may need to adjust other components or subsystems of the cardiopulmonary bypass machine system 100 in response to readings from the blood monitoring system 140.

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

[0036] From the above description, it can be observed and understood that the perfusion technician is tasked with a vast amount of very important responsibilities during a surgical procedure using the cardiopulmonary bypass machine system 100. Providing assistance to the perfusion technician by a system that uses artificial intelligence to facilitate autonomous or semi-autonomous operation can be very beneficial.

[0037] Referring also to FIG. 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 wirelessly) with a heart-lung machine (HLM110) monitoring device 204, a hospital database 206, one or more monitoring devices 218A-N, and a blood monitoring system 140 (e.g., a CDI (registered trademark) blood gas monitor). Wired communication and / or wireless communication can be provided via a network 212. The monitoring device 204 can display information about the HLM110 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 status 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 include one or more cameras or other optical sensors. In some embodiments, the camera can view the device display and capture the content displayed on the device display. The content can be interpreted for further analysis, including for generating recommended procedure adjustments in real time during the procedure 200, and can be reported to the computing system 202. 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 status of the patient 10's environment. For example, the devices 218A-N can monitor room temperature and / or indoor humidity levels.

[0039] Computing system 202 can request patient information from hospital database 206 and receive patient information from hospital database 206 (A). Hospital database 206 can store patient information 220 and general patient information 222. Patient information 220 can be specific to a particular patient 10 who has undergone a medical procedure 200. For example, patient information 220 can include past information, health status, vitals, etc. about patient 10 during a previous procedure. General patient information 222 can include, for example, anonymized information about patients who have undergone procedures similar to medical procedure 200. Information 222 can also include anonymized information about patients with a health status (e.g., age, gender, health problems, etc.) and / or vitals similar to patient 10. Further, information 222 can include general anonymized trends about patients. Computing system 202 can use patient-specific information 220 and general patient information 222 to perform a more robust analysis of the health status that patient 10 experiences before, during, and after procedure 200. This information can be useful for more accurately predicting the potential benefits and harms to patient 10. This information can also be useful for generating procedure adjustment recommendations that prevent the occurrence of predicted harms and optimize control adjustments and settings.

[0040] Computing system 202 can also automatically receive the 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 operation data (such as parameters, health status, feedback, readings, etc.) from one or more devices used during the procedure, such as 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. The system 202 can use this requested information to predict the patient's health status during procedure 200. The system 202 can also use this information to generate medical procedure adjustment recommendations.

[0041] During procedure 200, computing system 202 can request the real-time health status from monitoring devices 218A - N and / or blood monitoring system 140 to confirm the prediction made before the start of procedure 200. 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 the real-time health status to predict how the patient is likely to recover. The prediction 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] Referring further to FIG. 2A, when computing system 202 receives patient information and / or real-time health status 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 status 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 operation data from blood monitoring system 140 (e.g., a heart / lung machine) during a procedure, 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"). Computing system 202 can then, during the procedure, based on the above analysis of data defining a target range for the operation parameters of blood monitoring system 140 and one or more of monitoring devices 218A - N, determine a prediction that the operation data from blood monitoring system 40 or the parameters from one or more of monitoring devices 218A - N tend to be outside the target range. These techniques can also be used to determine procedure adjustments that can maintain the safety of patient 10 before, during, and / or after procedure 200 and maintain one or more parameters of blood monitoring system 140 and / or one or more of monitoring devices 218A - N.

[0043] In some embodiments, analyzing the data can be performed at a location remote from procedure 200. In some examples, computing system 202 can be a central server system that performs all analytics for various medical procedures (see, e.g., FIG. 2B). The central server can be located at a location remote from one or more of the medical procedures. In other examples, computing system 202 can be located at the location of procedure 200 and can communicate with one or more other computing systems located at different locations. System 202 can run algorithms or models that are specific to a particular device used during procedure 200, such as HLM 110. 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 analytics can be performed through this distributed framework.

[0044] Based on analyzing data from multiple sources, system 202 can determine and / or predict potential hazards to patient 10 at E as well as one or more safety ranges. As mentioned, E can be performed before, during, and / or after procedure 200. The safety ranges can be determined for each parameter monitored by devices 218A - N and HLM 110. As further described with reference to FIGS. 7A - 7D, during procedure 200, it is important to maintain each parameter within the associated safety range. Monitoring and maintaining each parameter can improve the overall health status and the safety of 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 emergency adjustments can be generated and required based on how many parameters exceed or are expected to exceed the associated safety range. The 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] System 202 can then determine procedure adjustment recommendations at F and transmit 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 specific monitored parameters exceed or are expected to exceed the safety range of the parameter. These recommendations can also be generated based on the overall real - time health status and / or the predicted health status of patient 10.

[0046] The practitioner 210 can make a decision (H) as to whether to perform one or more of the recommendations. In some embodiments, the practitioner 210 can select one or more of the recommendations regarding the user interface of the HLM monitoring device 204. In some implementations (e.g., medical procedures where the patient is at risk of significant harm requiring immediate procedure adjustment), the computing system 202 can transmit the determined procedure adjustment to the HLM monitoring device 204 and / or one or more monitoring devices 218A - N, and then automatically perform the determined procedure adjustment without input or consideration from the practitioner 210. The computing system 202 can also inform the practitioner 210 of the procedure adjustment when the procedure adjustment is being performed automatically and / or autonomously. This can be beneficial in situations where one or more parameters (e.g., motion parameters) are above or expected to exceed the upper limit of the determined safety range (see, e.g., FIGS. 7A - 7D). If one or more parameters are about to reach the upper limit, immediate action may be required to return the parameters to the safety range. Otherwise, if the parameters are not adjusted immediately, the overall health and / or well - being of the patient may be at risk. Whether the practitioner 210 makes the selection or the system 202 automatically performs the procedure adjustment, the practitioner 210 can maintain control of the operation of the procedure 200. The skills and expertise of the practitioner 210 are not impaired; 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 twist in a tube may not be automatically fixable by the system 202. As a result, the practitioner 210 may be prompted to immediately fix the kink in the tube. The urgency to fix the twist can be determined based on how close or how much the associated parameters exceed the upper limit of the safety range.

[0047] In I, the selection of the recommended technique adjustment of the operator 210 can be transmitted from the HLM monitoring device 204 to the computing system 202. The computing system 202 can update the algorithms and / or models used by the system 202 to determine patient harm and safety range (E) and recommended technique adjustment (F) based on the decision of the operator 210 (J). For example, in some embodiments, the system 202 can generate a trained model for the technique based on either the predicted recommended technique adjustment or the selection of any one of the recommendations of the operator 210. The trained model can be a deep learning model. Generating a trained model for the technique can include iteratively training a model for the technique by correlating each of the predictions with the operation data (e.g., HLM) from the blood monitoring system 140, the 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 technique adjustment based on the autonomous implementation of one or more selections of recommended technique adjustments by the operator 210.

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

[0049] Furthermore, in some embodiments, the system 202 can adjust one or more of the HLM 110 and / or the monitoring devices 218A - N based on the decisions of the operator 210 at K. In other examples, as described throughout, the operator 210 can manually perform procedure adjustments or updates instead of the computing system 202. Simultaneously and / or at different times, the system 202 can transmit the updated patient information to the hospital database 206 for storage (L).

[0050] The real-time health status can be received from the blood monitoring system 140 and / or the monitoring devices 218A - N throughout D - L. Receiving real-time updates can be advantageous for the 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 procedural adjustment recommendations provided to the practitioner 210 (F). As a result, the practitioner 210 can, if desired, spend less valuable time during the procedure 200 analyzing the patient's health status. Further, the practitioner 210 need not spend valuable time making decisions about whether a procedural adjustment is needed to protect the patient 10 from experiencing harm and what type of procedural adjustment is needed.

[0051] The continuous improvement of the algorithms and / or models provides more accurate predictions of patient harm, individual parameters, and beneficial procedural adjustments. During conventional procedures, it can be a challenge for the practitioner 210 to perform all tasks related to the procedure while simultaneously monitoring all of the patient's health status. Typically, the practitioner 210 is alerted when the patient is about to be harmed, and sometimes, it may be too late for the practitioner 210 to appropriately respond to the health status causing the harm. When the practitioner 210 is alerted to a potential harm, the practitioner 210 may experience more stress in finding a solution. Thus, the practitioner 210 may make mistakes in dealing with the harm or other aspects of the procedure. The disclosed technology mitigates at least some of these problems by providing proactive predictions, recommendations, and / or solutions rather than reactive ones to reduce patient harm.

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

[0053] As shown, the computing system 202 can receive and transmit components / devices and information / data in each of procedures 200A, 200B, and 200N (see, e.g., FIG. 2A). The system 202 can analyze the health status of patients 10A, 10B, and 10N to determine procedure adjustment recommendations to prevent patients 10A, 10B, and / or 10N from being harmed during procedures 200A, 200B, and 200N. The system 202 can transmit such procedure adjustment recommendations to the device 204. The operator 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 the practitioner 210 selects one or more procedural adjustment recommendations, the recommendations can be sent to the device in procedures 200A, 200B, and / or 200N. The device in the procedure can inform a nurse, a junior perfusion technician, a surgeon, or other practitioner at the procedure site (e.g., the operating room) to perform such a procedural adjustment. This is advantageous because the practitioner performing the actual procedure does not have to analyze the patient's health status and make a determination about the level of patient harm. Instead, the practitioner can focus on performing the procedure and dealing with other necessary tasks that may arise. In other examples, the selected procedural adjustment recommendations can be automatically performed / implemented by the computing system 202 and / or one or more devices (e.g., a robotic device, a semi-autonomous robotic device, etc.) disposed in procedures 200A, 200B, and / or 200N. This is advantageous because it allows the practitioner performing the procedure to focus on the procedure instead of monitoring the patient's health status and / or the health status of the medical devices (e.g., HLM, urine collection bag monitor, etc.) used during the procedure.

[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 procedures 200A, 200B, and 200N. The information displayed can include real-time updates / health status (not shown) of patients 10A, 10B, and / or 10N and procedural adjustment recommendations 201, 231, and 241. The interface 203 can also display a trend analysis of different health statuses for each patient using, for example, 2D and / or 3D graphs (see, e.g., FIGS. 7B-7D).

[0056] One practitioner 210 can supervise and monitor multiple procedures at once while performing or selecting procedure adjustments that prevent the patient from experiencing harm, and / or can optimize patient outcomes, so hospital and healthcare costs can be reduced. Accordingly, patient safety can be improved. Further, in some implementations, the real-time health status for patients 10A, 10B, and 10N can be used by computing system 202 to determine procedure adjustment recommendations for each of respective procedures 200A, 200B, and 200N. For example, if patients 10A, 10B, and 10N are undergoing the same medical procedure, computing system 202 can analyze the reaction of patient 10A 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 conventional medical procedures, a practitioner does not have the time or ability to investigate and analyze data about different patients undergoing the same procedure at the same time. Accordingly, the disclosed techniques enable integrating data in real time from different sources to generate patient harm predictions and procedure adjustment recommendations. Further, this dynamic data analysis can be advantageous in continuously improving the algorithms and / or models used by computing system 202 to predict patient harm and determine optimal procedure adjustment recommendations.

[0058] Figure 3 is a schematic diagram of an exemplary computing system described herein. Computing system 202, monitoring devices 218A - N, database 206, and HLM monitoring device 204 communicate (e.g., wired and / or wirelessly) via network 212. 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, database 206 can be a remote storage (e.g., in the cloud) that collects and stores anonymized patient data across different medical institutions.

[0059] In the illustrated example, 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] 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 that are monitored during the procedure. Understanding how each parameter can vary during the procedure is useful for determining the overall health or well - being of the patient. Understanding how each parameter varies can also be useful for generating adjustments to one or more monitoring devices and other procedure devices. Engine 310 can determine the patient health state and parameter safety ranges based at least in part on patient information 220, general patient information 222, and / or procedure target data 332 received from database 206. Engine 310 can predict the patient health state and parameter safety ranges before, during, and / or after a medical procedure. Further, engine 310 can adjust the patient health state and / or parameter safety ranges predicted in real - time based on the perceived health state of the patient during the procedure.

[0061] Patient information 220 can be specific to a patient receiving a medical procedure. The information 220 can include past data 324 about a particular patient and / or current health status data 326 about the patient. The current health status 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 blood panels, ECG, EEG, echograms, medications, skin conductivity, and / or any other vital signs monitored before, during, and after the medical procedure. Further, the past data 324 can include age, residential area, clinician notes, diagnosis, diet, gender, medical records, medications, race, sex, supplements, and / or vitamin inoculations, etc. Additional information about a particular patient, such as air intake, diet intake, general stress level, and water intake, may be beneficial in determining how a patient will respond to a medical procedure compared to other patients.

[0062] General patient information 222 can include past data 328 about patients who have received procedures similar to a particular patient and / or have similar health status / vitals to the particular patient. The information 222 can also include current health status data 330 of other patients who are receiving procedures similar to and / or the same as the particular patient. The information 222 can 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 residential area, air intake, diet intake, general stress level, and / or water intake can, in some cases, demonstrate that it is beneficial for the computing system 202 to more accurately predict different patient health states and responses during a medical procedure.

[0063] The procedure target data 332 can include information about devices and / or subjects used before, during, and / or after a medical procedure. For example, the procedure target can be any living or non-living item that is intended to be placed within, on, and / or with a particular patient during and / or after a medical procedure. The target can be permanent, semi-permanent, or temporary. Non-limiting examples of procedure targets include a patient's appendix, biopsy, heart valve, kidney stone, knee replacement, organ transplant, pacemaker, and tonsils. The data 332 can include composition, health status, lot number, part number, status, profile, shipping history, or any other information related to performing the procedure with the procedure target. The procedure target data 332 can also include information and / or health status about devices attached to a patient during a medical procedure, including but not limited to an electrocautery scalpel, HLM (via cannulas / tubes), intravenous devices, robotic assisted joint replacement devices, long-term micro-infusion devices, urinary catheters, and ventilators.

[0064] Returning to the computing system 202, the procedure adjustment recommendation engine 312 can communicate with the patient health status 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 bounds of an associated safety range (see, e.g., 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. As a result, the selected procedure adjustments can be performed manually by the practitioner and / or automatically (e.g., autonomously and / or semi - autonomously) by the computing system 202. The adjustments can also be performed by devices placed at the site of the procedure and / or that communicate with the HLM monitoring device 204 and / or the computing system 202. In a preferred example, the procedure adjustments can be performed essentially immediately so that no predicted harm to the patient occurs. As a result, the patient can remain in a safe and healthy state (e.g., a safe range, a target range, an ideal range) before, during, and after the medical procedure.

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

[0067] In some embodiments, the operator can monitor and / or control the HLM 110 using the monitoring device 204. The input device 340 can receive one or more selections of the operator's recommended procedure adjustments. The input device 340 can also receive commands from the operator for semi-autonomous actions to be taken. For example, the operator can use the input device 340 to remotely adjust the blood flow level within the HLM 110. In some implementations, the input device 340 and the output display 338 can be a single device, such as a touch screen. 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 to computing system 202 again, the prediction engine update module 314 can be configured to continuously update the AI, ML, and / or DL algorithms and models used by computing system 202 to predict the patient's health state, predict the safety range, and generate surgical adjustment recommendations. Module 314 can make continuous improvements based at least on which surgical adjustments are selected by the operator. The continuous improvement can also be based on how the patient responds to the selected surgical adjustment. Further, the continuous improvement can be based on how the general population of patients is predicted to respond to the selected surgical adjustment. The continuous improvement can also be based on how the general population of operators is predicted to respond to the recommended surgical adjustment. Moreover, the continuous improvement can be based on the real-time health state sensed during the procedure with respect to the patient, HLM 110, and / or the object being used during the procedure. The continuous improvement can be advantageous in ensuring that computing system 202 makes accurate and reliable patient health state predictions and surgical adjustment recommendations for each medical procedure, regardless of the specific patient or procedure information.

[0069] Module 314 can be configured to provide updated information regarding patients, general patients, and the subject of the procedure to database 206. For example, module 314 can generate a model for a particular patient indicating how the patient has responded to the procedure and how they are expected to respond to similar procedures. This model is stored in patient information 220 to more quickly and accurately predict how the patient will respond and to determine which procedure adjustment recommendations should be generated, and is thereafter accessible by computing system 202 during subsequent similar procedures. This model can be further updated, modified, and / or improved by module 314 during each subsequent procedure. Doing so can guarantee more accurate predictions for the patient in the future. As another example, module 314 can generate one or more models based on generalized anonymous patients who have received similar and / or the same procedure. Such models are stored in general patient information 222 and are accessible when a modeled procedure is received by a particular patient. The models can be used to more accurately predict how a particular patient will respond to a procedure by comparing the modeled health state for the general patient to the patient's health state.

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

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

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

[0073] In step 402, the procedure data is receivable. As described in this specification, the procedure data can include past information and real-time information about the patient receiving the procedure. The data is receivable before, during, and after the procedure. The procedure data can also include past anonymized data about a general patient, the procedure subject, and other devices used during the procedure.

[0074] In step 404, one or more patient health states and parameter safety ranges are predictable. One or more of the data received in step 402 are applicable 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 the upper and lower limits of the safety range for each of the parameters being monitored during the procedure (see, for example, FIGS. 7A-7C). Step 404 can be performed before the procedure begins. Then, the prediction made in step 404 can be continuously updated during the procedure, if needed.

[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 a patient experiences a normal or safe health state during the procedure. The computing system described herein can determine that a 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 proposals applicable to the procedure at a time prior to when either the patient and / or the parameters are predicted to deviate from the associated safety range. When that adjustment is implemented during the procedure, the patient health state is maintained within the safety range, thereby avoiding the predicted harm. Further, the adjustment can keep the patient health state within the ideal range (target range), thereby maximizing the patient outcome.

[0076] In step 408, the procedure adjustment recommendations can be output to the display of the computing device. Step 408 can be performed after steps 402 - 406. For example, steps 402 - 406 can be performed before a medical procedure begins. Step 408 can be performed when the computing system determines that a procedure adjustment should occur to keep either the patient or the parameters within the associated safety range during the medical procedure. The 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 is updatable at step 412. Additionally and / or alternatively, one or more other AI, ML, or DL models are updatable to more accurately predict the patient health state, the safety range, and subsequent procedures and procedure adjustment recommendations for the patient. Steps 402 - 412 are continuously repeatable over the duration of the medical procedure and before and / or after the medical procedure.

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

[0079] In some examples, the pre - procedure steps are executable immediately before the medical procedure begins. In other examples, the pre - procedure steps are executable a certain amount of time before the medical procedure begins. The in - procedure steps are dynamically adjustable based on the health state sensed and received in real - time. Further, in some implementations, the patient health state is predictable during as well as before the procedure. The post - procedure steps are executable immediately after the medical procedure is completed. In some examples, the post - procedure steps are executable a certain amount of time after the medical procedure. As a result, the patient's recovered health state can be analyzed and used to enhance the algorithms, ML, and / or AI techniques used to predict the patient health state.

[0080] Referring further to process 500 of FIG. 5A, data can be received at step 502 prior to the procedure. As described herein, the data can include past patient data, current patient health status, past general patient data, current health status of past general patients, and procedure target data. The 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 phase, during-procedure phase, and post-procedure phase. For example, during the during-procedure phase, past data about the patient can be received to diagnose and / or analyze the unique health state the patient is experiencing during the procedure. Past data about general patients can also be beneficial during this phase to determine whether the patient is currently experiencing any health state that is atypical for the procedure. As another example, during the post-procedure phase, the current patient health status and current health status of past general patients can be received to determine whether the patient is recovering from the procedure in an atypical manner compared to the general population of patients who have undergone the same procedure.

[0081] When related data is received in step 502, in step 504, the patient's health state during the procedure can be predicted. Additionally and / or optionally, one or more parameter safety ranges can be determined in step 504 (see, e.g., 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 or not, whether before or during the procedure, the prediction of the patient's health state during the procedure can be dynamically adjusted to correspond to 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 with respect to past data as well as real-time data. Thus, the patient health state prediction can be generated more accurately before the procedure. The patient health state prediction may not need to be modified and / or adjusted during the in-procedure phase. This can reduce the time required to generate potential procedure adjustment recommendations and apply such corrections before the patient is harmed. As a result, patient safety can be improved.

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

[0083] Furthermore, the techniques described herein can be used in step 506 to generate fewer procedure adjustment recommendations. For example, a trained ML model can predict that only one procedure adjustment is needed to prevent the patient from being harmed based on all the data received in step 502. In other words, as the techniques described herein become more trained, they can more accurately determine fewer and more effective procedure adjustment recommendations. Providing fewer procedure adjustment recommendations to the practitioner can also prevent the practitioner from being overwhelmed with information during the medical procedure. The practitioner does not have to be as taxed to make a decision 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 technique described herein generates one procedure adjustment, that procedure adjustment can be quickly and automatically implemented. This is because then the computing system does not have to compare multiple procedure adjustment recommendations to identify and select the most optimal procedure adjustment recommendation. This improves the efficiency of the medical procedure. This also reduces the risk that the patient experiences harm during the procedure.

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

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

[0087] The patient health state and safety range prediction algorithm, or other machine learning and / or artificial intelligence techniques and models described herein, can be updated at step 514. The update can be based at least in part on which procedure adjustment the operator selects. The update can also be based on the real-time health state 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 is updatable after the procedure. The data is continuously updatable in real time (e.g., during a medical procedure). Updating the data in real time can be advantageous so that the updated data is available when predicting the patient's health state and determining procedure adjustment recommendations during the medical procedure. When the data is updated, the data can be stored (e.g., within database 206).

[0089] Steps 502 - 516 are continuously repeated and / or can be repeated a certain number of times. Repeating process 500 is advantageous for continuously 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 process 500 described in relation to FIG. 5A. As shown, the medical procedure is divided into three phases, namely, pre-procedure, during-procedure, and post-procedure. During the pre-procedure phase, the individual patient procedure data collected during the medical procedure is stored along with the individual patient past data. Before the procedure, individual patient pre-procedure data (e.g., heart rate before the procedure starts), auxiliary 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 past data, generalized patient past data, and generalized patient procedure data can be collected. This data can be used by the algorithms, ML, and / or AI techniques described herein. The patient pre-procedure data can include pre-procedure response test data. For example, a patient connected to an EKG can be exposed to a temporary test dose of anesthetic and / or drug (e.g., non-routine stressor) to characterize the patient's behavior, response, and / or safety. The data collected about the patient's response to the test dose can be used to improve an algorithm or other technique for more accurately predicting the patient's health status. This data can also be used to more accurately determine the patient safety range, limits, and initial settings for the medical procedure.

[0091] The data described above can be used during the procedure to determine the patient's health state before the procedure (e.g., refer to the "AI before 'Patient connection'" box in FIG. 5B), during the procedure (e.g., refer to the "AI during 'Patient' connection" box in FIG. 5B), and after the procedure (e.g., refer to the "AI after 'Patient' connection" 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 states. Thus, procedure adjustment recommendations can be generated during the procedure. One or more of the predicted health states can be output to the operator's (e.g., the practitioner's) device. Inputs (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 improve and / or adjust the patient prediction 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 procedure devices. This information can be used by one or more of the techniques described herein to improve and / or adjust the prediction of the patient's health state before, during, and after the procedure. Patient predictions as well as procedure modification (e.g., adjustment) recommendations can be output to one or more of the devices (e.g., the settings of the HLM can be automatically adjusted).

[0093] The algorithms and other techniques used and described herein are continuously modifiable (see, e.g., the “AI-generated fine-tuning to algorithm set” box in FIG. 5B). The techniques described herein can initially be set by a human. Using AI and / or DL, the techniques can be continuously and iteratively improved. Further, the adjustments to the techniques can include continuous improvement of the set of procedure-specific algorithms (see, e.g., the “AI procedure-specific algorithm set” box in FIG. 5B). In other words, the algorithms used to predict how a particular patient is likely to respond to a particular procedure learn from improvements made to other algorithms and can thus be adjusted based on the improvements. Other algorithms can, for example, predict how a general patient is likely to respond to a similar or more generalized procedure. As a result, the algorithms can learn from each other to further improve the techniques even when the algorithms are changed to generate predictions for different devices, procedures, and / or patients. Such continuous improvement 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 various sources including hospital laboratory information management systems and remote databases or data warehouses (see, e.g., the “other information entry” box in FIG. 5B).

[0094] Even monitoring, treatment, and procedure-related devices can track the patient in the post-procedure setting. Thus, the disclosed techniques can continue to be valuable information / data collected before, during, and after the procedure. As a result, the patient's recovery health state can be predicted. After the procedure, patient procedure data, patient outcome data, and auxiliary target outcome data can be updated based on the predictions made during the procedure. The updated data can be fed back to the pre-procedure phase that collects generalized patient past data and procedure data as well as individual patient past data. Patient outcome data can be collected over time. Patient outcome data can include or consist of a subset of the complete post-procedure patient history. This information can be beneficial for one or more of the techniques described herein when predicting patient health status and / or procedure adjustment recommendations. Auxiliary target outcome data can include any information regarding auxiliary items (e.g., targets) that change (or confirm no change) its "auxiliary pre-procedure data" and / or create information about newly generated auxiliary items during the procedure. This information can be related to the patient pre-procedure data. This information can also be related to the patient outcome data.

[0095] Patient procedure data, patient outcome data, and auxiliary 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. An algorithm can include a record of the real-time health state indicating what happened during all actions, observations, and / or procedures. The algorithm can be used to enhance and adjust / tune one or more of the algorithms or other techniques used during the algorithm or procedure (e.g., fine-tuning generated by AI for an algorithm set and an AI procedure-specific algorithm set). As a result of continuously improving the techniques described herein, more accurate predictions can be made before, during, and after a medical procedure to prevent patient harm, improve patient safety, and reduce the cost of the medical procedure.

[0096] Figures 6A-6C are flowcharts of a process 600 for improving predicting a patient's health state after a semi-autonomous medical procedure. Process 600 can be performed by a computing system as described throughout the present disclosure.

[0097] Referring to FIG. 6A, the post-procedure data can be received at 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, intra-procedure data of the procedure of interest, and / or post-procedure data of the procedure of interest. Using the data received at step 602, the patient health status prediction algorithm described herein can be updated at step 604. The procedure adjustment algorithm described herein can also be updated at step 606. Next, the stored data can be updated at step 608. The patient data, general patient data, and procedure of interest data can be updated at least partially based on the post-procedure data. When the information and / or algorithm is updated, patient recovery can be predicted at step 610. The predicted patient recovery can also be based on the 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 over a predetermined time. Next, the patient recovery prediction can be adjusted based on the real-time health status after the procedure. After the patient recovery is predicted at step 610, the process 500 described in connection with FIG. 5A can be performed.

[0098] Figures 6B - 6C are additional examples of process 600 described in relation to Figure 6A. Figure 6B illustrates how the algorithms described herein are used to continuously improve and / or update patient data. For example, as described in relation to Figure 5B, the algorithms are applied to analyze and determine trends for procedure data, device procedure data, operator procedure data, patient procedure data, patient outcome data, and auxiliary target outcome data. Insights gathered from such analysis can be stored as auxiliary post - procedure data, individual patient procedure data, generalized patient past data, and generalized patient procedure data. Information from one or more other post - procedure data sources (e.g., manually entered by an operator) can be incorporated into the auxiliary post - procedure data and individual patient procedure data. As shown in Figure 6B, updating and / or improving 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] Figure 6C illustrates how the algorithms described herein are used to continuously improve / update the algorithms used to make predictions throughout a medical procedure. For example, as described in relation to Figure 5B, an algorithm for predicting patient health status during a procedure is applicable to one or more general algorithm sets to enhance and improve those algorithm sets. One or more procedure - specific algorithm sets can be enhanced and / or improved based on the improvements made to the general algorithm sets. As a result, the algorithms and techniques described throughout are continuously improved. The continuous improvement is beneficial in providing a more accurate analysis of patient health status and procedure adjustment predictions.

[0100] In connection with both FIGS. 6B - 6C, DL can be used independently and / or with AI or other techniques described herein. DL can augment existing algorithms / algorithm sets and / or databases implemented in the disclosed technology. Pattern recognition is a primary purpose of DL, seeking relationships between factors not easily observable by humans. As an illustrative example, individuals who have consumed chlorinated water continuously for over 12 years and individuals prone to ventilation episodes may be found to be 175% more likely to develop acute kidney injury (AKI). This disorder can occur during cardiopulmonary bypass (CPB) when, for example, the oxygen delivery (DO2) drops below 272 mL·min -1 ·m -2 for over 3 minutes. For example, these individuals may also be found to be 535% more likely to be impaired when either the oxygen delivery drops below the threshold for over 5.5 minutes or below 250 mL·min -1 ·m -2 for over 2.5 minutes. In the disclosed technology, DL can be implemented to analyze data (e.g., past patient data, current patient data, general patient past data, general patient current data, surveys, or information from the Internet or other sources) over an extended period to make these kinds of discoveries. Such discoveries are applicable to the techniques described herein to more accurately determine and predict patient health status, safety margins, and procedural adjustment recommendations.

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

[0102] First, at step 702, data can be received from one or more sources. The data can include generalized patient procedure data, generalized patient past data, pre-procedure patient health state, predicted patient health state, intra-procedure patient health state, pre-procedure data for the procedure of interest, and intra-procedure data for the procedure of interest.

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

[0104] In conventional procedures, often the practitioner is not informed that the patient is no longer within the safety range until the patient experiences some level of harm. At this point, in some cases, it may be too late and / or too risky to make adjustments to the procedure. However, the techniques described herein mitigate this problem by helping to ensure that the patient remains within the patient safety range over the duration of the procedure.

[0105] Referring further to step 704, the computing system can compare the generalized patient procedure data with the patient's pre-procedure health state. In doing so, the system can determine whether the patient enters the procedure with a different health state than the previous patient. If the patient is experiencing the same or a similar health state, 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 state than the previous patient, the computing system can analyze the other data received in step 702 to determine the optimal safety range for this particular patient. The determined patient safety range can also be adapted and / or changed over time based on, for example, the predicted patient health state, the patient health state recorded during the procedure, the pre-procedure health state of the procedure subject, the in-procedure health state of the procedure subject, and the like.

[0106] The dynamic adjustment of the in-procedure patient safety range is advantageous in ensuring that the patient does not experience harm. The dynamic adjustment is also advantageous in ensuring that the operator can appropriately and promptly address patient safety before the patient is potentially harmed. Further, receiving data from multiple sources in real time provides a more accurate prediction of patient harm and patient safety scenarios. This is because the operator may not have the ability, function, or time to investigate and analyze such a large number of information, especially during the procedure, and then make an accurate decision as to whether the patient will be harmed during the procedure.

[0107] Once the patient safety range is determined, at step 706, the computing system can determine whether the predicted patient health state exceeds the patient safety range. In some examples, the computing system can receive real-time information from one or more monitoring devices indicating the health state of the patient during the procedure and / or the health state of the subject of the procedure during the procedure. This information can be used in addition to the predicted patient health state to determine the real-time health state of the patient. Thus, the systems described herein can continuously update information regarding the health state of the patient to identify whether the patient remains within the safety range. For example, prior to the procedure, process 700 can be performed by the computing system to determine / predict the patient safety range. During the procedure (e.g., during the procedure), the safety range can be dynamically updated or modified based on the perceived 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) at step 712. In other words, the system determines that at some point during the procedure the patient is not within the safety zone and that action needs to be taken to prevent the patient from exiting the safety zone. The procedure adjustment recommendation can be made based on analyzing the real-time health state of the patient and comparing the real-time health state to the pre-procedure health state. By doing so, the computing system can determine how much the patient health state changes over a period of time and how long the patient has before the patient can exit the safety zone. Based on such determinations, the computing system can identify what the relevant or specific procedure adjustments should be.

[0109] Once the manual adjustment is determined, the computing system can receive the patient's real-time health status and / or the procedure target at step 714. Using this information, the computing system can select one of the manual adjustments at step 716. The selection of the preferred procedure modification can be adjusted in real time based on the patient's health status as compared to a prediction of what the patient will be like. For example, if the real-time health status indicates that the patient is deteriorating more than 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 more gentle and less extreme procedure modification can be selected. Selecting the optimal procedure modification can also depend on the amount of time it would take for the patient's health status to exceed the patient safety range. If the patient is ultimately going to deviate from the safety range over 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 impacted by whatever procedure modification is selected. On the other hand, if the patient is on the verge of deviating from the safety range, a more aggressive procedure modification is employed.

[0110] In some implementations, the computing system can, at step 716, select one or more of the procedure adjustment recommendations or not select any. This can be advantageous in a semi-autonomous medical procedure where the practitioner not only monitors the procedure but also performs the procedure. As a result, the practitioner can have more ability to control and make decisions during the procedure. This can be advantageous even in situations where the patient is within a safety range and is expected to remain within the safety range without many procedure adjustments. In other words, when the patient's health state does not vary or varies 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, at 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 propose which of the procedure adjustments would be best to implement during the procedure. This is advantageous as it spares the practitioner from having to divide their attention and make such decisions while performing the medical procedure. As another example, if the patient is expected to deviate from the patient safety range rather quickly (e.g., the patient's health state is deteriorating and the patient will be harmed without immediate procedure adjustment), the selected procedure adjustment can be output along with an indication to the practitioner that a procedure adjustment is needed and must be made immediately. As a result, the practitioner can immediately implement the procedure adjustment without spending time deciding whether to implement the procedure adjustment and evaluating the patient's current health state. Instead, the practitioner can focus on other aspects related to completing the procedure.

[0112] Similarly, in step 720, the selected procedure adjustment is feasible. In some medical procedures, the modification can be carried out by the operator. For example, the operator can select a modification from the output and then perform the modification manually. In other examples, when the operator selects a modification, an instruction to complete the modification can be sent to the device that performs the modification. As an example, instructions for adjusting the blood flow of the HLM can be sent to the HLM and / or other controllable devices so that the HLM and / or other devices automatically perform the adjustment. In yet other examples where the operator supervises multiple procedures at once, at the time of selecting a procedure adjustment, an instruction to perform the procedure adjustment (e.g., the modification) can be sent to the device of one or more operators who perform the procedure so that one or more operators can perform the procedure adjustment manually and / or semi-autonomously.

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

[0114] As described in more detail below, when a procedure adjustment is 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 are updatable such that much more accurate predictions about the patient's health state and the patient's safety range can be generated before and during the medical procedure. If the pre-procedure prediction becomes more accurate, changes to such a prediction are less likely during the procedure. This would improve the efficiency of addressing potential hazards to the patient. If the patient health state and safety range 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 in ensuring that any potential health states and / or hazards can be predicted and addressed before they become issues regarding the patient's well-being and safety. As mentioned, all these predictions are made before the procedure, thereby enabling the improvement of the efficiency and accuracy of decision-making during the procedure.

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

[0117] FIG. 7B is an exemplary graph of a patient's health state during a conventional manual medical procedure. Conventionally, the practitioner often does not observe that the patient's health state tends to deviate from the ideal (or target) range for any given parameter. Range limit 2 may be set to trigger an alarm / alert, and often time is the first indicator to the practitioner of a situation requiring a procedure adjustment. However, conventionally, there is no device notification to the practitioner of a change in the patient's health state trend. The practitioner needs time to analyze why the alert occurred, consider how to react, implement the reaction, and then recognize that the reaction 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, and ultimately may return this one given parameter to an apparent steady state within the ideal range. Further, while the practitioner is focused on correcting a given parameter, other parameters may escape the ideal range. Thus, during a conventional manual medical procedure, it can be even more difficult for the practitioner to evaluate and address such parameters before one or more parameters exceed the ideal range, pass 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 state during a semi-autonomous medical procedure. As shown, the range limits exist on either side of the ideal (or "target") range for a particular parameter. The ideal range is the zone where the disclosed technology generates information about a plurality of upper and lower limits, maintains the patient's health state within the plurality of upper and lower limits, optimizes based on each particular patient, and generates the plurality of upper and lower limits. The range limits are not necessarily equidistant (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 states should remain within range limits 1-U and 1-L, which are the upper and lower range markers.

[0119] The disclosed technology and the methods described herein are advantageous for predicting the health state of one or more parameters monitored during a procedure to determine a patient's future health state and procedure adjustments. Procedure adjustments can be generated to prevent either the patient or any of the monitored parameters from going outside of an associated ideal range (also called a target range or a safety range). Thus, the patient or parameter health state should not be within any region of patient harm or any range that exceeds the ideal range during the procedure.

[0120] During a procedure, the range limits can change. For example, the range limits can be pre-designed to change based on the health state predicted prior to 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 health state, changes in the monitored parameters, predictions made using the disclosed technology, and / or actions taken by the practitioner.

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

[0122] Each of 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 each of these devices and the parameters associated with 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 the associated safety ranges, and if so, what procedure adjustment recommendations should be provided to the operator.

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

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

[0125] The procedure information 750 can include the patient information 752 and each parameter monitored during the procedure 730 and / or information for the patient 10. For example, the patient information 752 can include the patient's name, date of birth, procedure date, and scheduled procedure time. Additional information such as the existing health condition that can affect the procedure outcome can be included. As shown in FIG. 7D, the parameters 754A-N can be included in the procedure information 750. One or more additional parameters being monitored can be illustrated in the information 750. All of the parameters 754A-N can be maintained simultaneously within a safety range. The faster the reaction speed from the operator and / or the greater the degree of AI autonomy, the longer the duration during the procedure 730 that all of the parameters 754A-N are maintained within the 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 follow general patient data and individual patient data, including pre-procedure response test data and / or procedure target data. Using the techniques described herein, the setting of range limits can be proposed to be displayed to the practitioner as procedure information 750. The practitioner can accept the setting and / or make corresponding adjustments. The practitioner's adjustments can be recorded. These adjustments can optionally and / or additionally be displayed in the 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. The update can then be made to algorithms or other techniques used to determine and propose range limits (e.g., safety zones or ranges) based on a particular practitioner's adjustments, what other practitioners generally do, patient procedure data, patient outcome data, and other data sources described herein.

[0128] As shown in FIG. 7D, the graphs of parameters 754A-N show the level or speed over time, supplemented by the display of other factors such as minimum value, maximum value, this value, etc. The level or speed of each parameter 754A-N' corresponds to the units seen from mass spectrometry, and the accumulated values indicate what the en masse analysis ultimately retroactively indicates. The example of parameter 754A illustrates one of the many advantages provided by the disclosed technique, which is continuous monitoring to show whether parameter 754A is predicted to exceed an acceptable or safe level over time. As a result, the practitioner can be aware of the potential increase in the value of parameter 754A and can address those increases before they occur.

[0129] As another example, an exemplary graph of parameter 754B illustrates cumulative situations such as CPB surgery 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. Conventional population analysis only retrospectively reveals that an unacceptable potentially dangerous situation occurred during procedure 730. The disclosed technology not only alerts the operator that a threshold has been exceeded, but also reports the rate change at the inflection point, provides operator recommendations for procedure adjustment and / or automatically performs such procedure adjustment, thereby predicting the situation as well.

[0130] In conventional medical procedures, an artificial lung reservoir (e.g., a venous return reservoir) reaches a low level, thereby activating an alarm. Conventional systems are typically pre-programmed to immediately stop a pump such as an arterial pump when that alarm is activated. When the arterial pump is automatically stopped, the patient endures zero perfusion (e.g., no oxygen delivery, no carbon dioxide removal) until the problem is manually resolved. For example, because the patient's metabolism continues, recovery is not instantaneous when restarting the flow from the artificial lung reservoir. This results in oxygen deficiency and carbon dioxide accumulation. Thus, the artificial lung and flow settings must be continuously adjusted by the operator until the patient's health state stability is restored. The longer the patient is in an alarm state, the more difficult and time-consuming it is to return the patient to a stable state.

[0131] Using the disclosed technology, as described herein with respect to FIG. 7D, 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 the artificial lung reservoir level detector before and / or during procedure 730. Such a prediction can be displayed in procedure information 750 (e.g., parameter 754A can be associated with the oxygen reservoir). Computing system 740 can, for example, cause a reduced pump speed and / or suggest to the operator, rather than waiting for an alarm when the reservoir level reaches zero.

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

[0133] As yet another example, the rate of change of blood volume in the HLM 110 can be continuously monitored and used by the disclosed techniques to generate an operator notification. The disclosed techniques can more accurately predict the emptying time and the optimal rate of decrease in arterial blood pump flow. The prediction can be automatically performed, such that problems with blood flow can be removed and the level of support for patient 10 can be maintained while full cardiopulmonary bypass support can be resumed.

[0134] Figures 8A-8B are exemplary block diagrams of different layers of patient health state prediction that interact with each other. Figure 8A refers to different patient health state predictions as being layered. As shown, the algorithms, AI, and other techniques described herein are applicable to different patients A-N, whether patients A-N are in the same facility or not, whether they receive the same medical procedure or not, or whether they are supervised by the same operator or not. The data and health states sensed / collected / predicted during any one of the procedures for patients A-N can be used by a computing system in evaluating and determining health state / procedure adjustments for any of the other patients A-N. The computing system described herein can be remote from any or all of the procedures for patients A-N while maintaining a high level of ability and speed to more efficiently generate health states and procedure adjustments for each of patients A-N (see, e.g., Figures 2A-2B).

[0135] Figure 8B refers to the interaction of one or more layers of patient health state prediction. Information associated with each of the patients is transferred from a remote location of the patient and can be used by a computing system to predict each of the patient health states and / or procedure adjustments (see, e.g., Figures 2A-2B).

[0136] In some examples, each of the patient locations can include a computing system that runs one or more predictive models against patient data. Each of the patient location computing systems can have their own specialized models. For example, the patient A location computing system can have an advanced model of kidney function and metabolism. The patient B location computing system can have an advanced model for liver monitoring. The patient C location computing system can have an advanced model for spleen function. Those specialized models are then accessible by the 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 of the patient location computing systems can be configured to support multiple procedures at multiple locations. For example, the kidneys of patient A can be monitored using the patient A location computing system model. However, the liver of patient A can be monitored using the patient B location computing system model, and the spleen of patient A can be monitored using the patient C location computing system model. As a result of such continuous connections and communication between different patient location computing systems and the computing systems described herein, the kidney, liver, and spleen health states of patient A can be maintained within their respective safety ranges / zones during the medical procedures of patient A.

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

[0139] The computer storage medium can be, or can include, 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 them. Further, the computer storage medium is not a propagated signal, but the computer storage medium can be the source or destination of computer program instructions encoded in an artificially generated propagated signal. The computer storage medium can also be, or can include, one or more separate physical components or media (e.g., multiple CDs, disks, or other storage devices).

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

[0141] The term "data processing apparatus" encompasses all kinds of devices, apparatuses, and machines for processing data, including, by way of example, programmable processors, computers, system-on-chips, or multiple of the foregoing, or combinations of the foregoing. The apparatus can include special-purpose logic circuits, such as, for example, FPGAs (field-programmable gate arrays) or ASICs (application-specific integrated circuits). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question, such as, for example, processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or code that constitutes one or more combinations thereof. The apparatus and the execution environment can implement various 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 form of programming language, including compiled or interpreted languages, declarative or procedural languages, 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 or may not correspond to a file in a file system. The program can be stored in a part 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 cooperating files (e.g., files that store one or more modules, subprograms, or portions of code). A computer program can be deployed to be executed on one computer, or on one site, or on multiple computers distributed across multiple sites and interconnected by a communication network.

[0143] The processes and logic flows described herein can 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 can also be performed by special purpose logic circuits, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit), and the apparatus can also be implemented as special purpose logic circuits.

[0144] Processors suitable for the execution of a computer program include, by way of example, both general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. In general, a processor receives instructions and data from a read-only memory or a random access memory or both. Indispensable elements of a computer are a processor for performing actions in accordance with instructions and one or more memory devices for storing the instructions and data. In general, a computer also includes, or is operatively coupled to receive data from or transfer data to, one or more mass storage devices for storing data, such as, magnetic disks, magneto-optical disks, or optical disks. However, a computer need not have such devices. Further, a computer may be embedded in another device, such as, by way of several non-limiting examples, 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 memory device (e.g., a universal serial bus (USB) flash drive). Devices suitable for storing computer program instructions and data include, by way of example, semiconductor memory devices, such as, EPROM, EEPROM®, and flash memory devices; magnetic disks, such as, internal hard disks or removable disks; magneto-optical disks; and CD ROM disks and DVD-ROM disks, including any form of non-volatile memory, media, and memory devices. The processor and the memory may be assisted by, or incorporated in, special-purpose logic circuitry.

[0145] To provide interaction with a user, embodiments of the subject matter described herein are practicable on a computer having a display device, such as a CRT (cathode ray tube) monitor or an LCD (liquid crystal display) monitor, for displaying information to a user, a keyboard, and a pointing device, such as a mouse or a trackball, whereby the user can provide input to the computer. Other types of devices can also be used to provide interaction with a user. For example, the feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback, and the input from the user can be received in any form including auditory input, voice input, or tactile input. Further, the computer can interact with the user by sending a document to a device used by the user and then receiving the document, for example, by sending a web page to a web browser on the user's user device in response to a request received from a web browser.

[0146] Embodiments of the subject matter described in this specification can be implemented in a computing system that includes, as a back-end component, e.g., a data server, or includes a middleware component, e.g., an application server, or includes a front-end component, e.g., a user computer having a graphical user interface or a web browser through which a user can interact with an implementation of the subject matter described in this specification, or in one or more combinations of any 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., by a communication network. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (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 the server are generally remote from each other and typically interact through a communication network. The relationship between the user and the server arises by running computer programs on respective computers and having a user-server relationship with each other. In some embodiments, the server transmits data (e.g., an HTML page) to a user device (e.g., for the purpose of displaying the data to a user who interacts with the user device and then receiving user input therefrom). Data generated at the user device (e.g., as a result of user interaction) can be received at the server from the user device.

[0148] This specification includes many specific implementation details, but these should not be construed as limitations on the scope of any intervention or what may be claimed, but rather as descriptions and interpretations of features that are specific to particular embodiments of a particular intervention. Some features described in the context of separate embodiments herein may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments. Further, features may work in some of the combinations described above and even be initially claimed as such, but one or more features from the claimed combination may in some cases be removable from the combination, and the claimed combination may be directed to a sub-combination or a variant of a sub-combination.

[0149] Similarly, operations are illustrated in the drawings in a particular order, but this should not be understood as requiring that such operations be performed in the particular order shown or in a sequential order to achieve the desired result, nor that all of the shown operations be performed. In some environments, multitasking and parallel processing may be advantageous. Further, the separation of various system components in the embodiments described above should not be understood as requiring such separation in all embodiments, and the program components and systems described are generally understood to be integratable together in a single software product or packageable into multiple software products.

[0150] Particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. For example, the acts recited in the claims can be performed in a different order and still achieve the desired result. As one example, the processes illustrated in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous. The invention described in the original claims of the present application is appended below. [1] A system for performing open-heart surgery on a patient, comprising a heart / lung machine, one or more monitoring devices configured to monitor parameters indicating the health state of the patient during the procedure, first medical data describing one or more health states of the patient, second medical data summarizing health information of a general population of other patients, third medical data defining a target range for operating parameters of the heart / lung machine and the one or more monitoring devices during the procedure, and a database for storing the above, a computer system configured to receive in real time during the procedure operating 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, wherein the computer system is further configured to repeatedly, during the procedure, (i) analyze the operating 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 determine a prediction that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target range based on a comparison of the analysis of (i)-(iv) with the third medical data. A system further configured as such. [2] The system according to [1], wherein the computer system is further configured to generate a trained model for the procedure based on the prediction. ​ [3] Generating the trained model for the procedure comprises iteratively training a model for the procedure by correlating each of the predictions to (i) the motion 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, the system of [2]. [4] The system of [2] or [3], wherein the trained model is stored in the database. [5] The system of any one of [2] to [4], wherein the computer system is further configured to determine a prediction that the motion data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target range based on applying the trained model for the procedure. [6] The system of any one of [1] to [5], wherein the computer system is further configured to generate an adjustment recommended to be made in real time during the procedure to at least one of the heart / lung machine or the one or more monitoring devices based on the prediction. [7] The computer system, in real time during the procedure, (i) based at least in part on analyzing the motion 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, selects one or more of the recommended adjustments, and autonomously implements the selected one or more recommended adjustments the system of [6], further configured to be. [8] The system of [7], wherein the computer system is further configured to generate a trained model for recommending a procedure adjustment based on autonomously implementing the selected one or more recommended adjustments. [9] The system of any one of [1] to [8], wherein the computer system is further configured to receive motion data from a plurality of heart / lung machines.

[10] The system according to any one of [1] to [9], wherein the one or more monitoring devices include at least one of a camera or a sensor array.

[11] The system according to any one of [1] to

[10] , wherein the one or more monitoring devices include a urine storage bag monitor.

[12] The system according to any one of [1] to

[11] , wherein the first medical data includes the current health status of the patient and the past health status of the patient.

[13] The system according to any one of [1] to

[12] , wherein the second medical data includes the past health information of the patient who has undergone the procedure.

[14] A computer-implemented method for use while performing an open-heart procedure on a patient, comprising: receiving, in real time during the procedure by a computer system, (i) operating data from a heart / lung machine, (ii) parameters indicating the health status of the patient during the procedure from one or more monitoring devices, (iii) first medical data describing one or more health states of the patient, (iv) second medical data summarizing the health information of a general population of other patients, and (v) third medical data defining target ranges for operating parameters of the heart / lung machine and the one or more monitoring devices during the procedure; repeatedly analyzing (i) to (iv) during the procedure by the computer system; determining, based on a comparison of the analysis of (i) to (iv) with the third medical data, a prediction that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target range; A method comprising the steps of:

[15] The method according to

[14] , further comprising generating a trained model for the procedure based on the prediction.

[16] Generating the trained model for the procedure further comprises iteratively training a model for the procedure by correlating each of the predictions with (i) the motion data from the cardio-pulmonary 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, the method of

[15] .

[17] Further comprising determining a prediction that the motion data from the cardio-pulmonary machine or the parameters from the one or more monitoring devices tend to be outside the target range based on applying the trained model for the procedure, the method of

[16] .

[18] A system for performing a medical procedure on a patient, a medical treatment system, one or more monitoring devices configured to monitor parameters indicative of the health state of the patient during the procedure, first medical data describing one or more health states of the patient, second medical data summarizing health information of a general population of other patients, a database storing third medical data defining a target range for operating parameters of the medical treatment system and the one or more monitoring devices during the procedure and, a computer system including one or more processors, the one or more processors receiving instructions configuring the computer system to receive, in real time during the procedure, motion 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 and, the computer system iteratively analyzing, during the procedure, (i) the motion 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, Based on the comparison of the analysis of (i) to (iv) with the third medical data, determine a prediction that the operation data from the medical treatment system or the parameter from the one or more monitoring devices tends to be outside the target range. A system further configured as follows.

[19] The computer system is further configured to generate an adjustment recommended to be made in real time during the procedure for at least one of the medical treatment system or the one or more monitoring devices based on the prediction, as described in

[18] .

[20] The computer system, in real time during the procedure, (i) Analyze the operation data from the medical treatment system, (ii) the parameter from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data, and based at least in part on this analysis, select one or more of the recommended adjustments, Autonomously implement the selected one or more recommended adjustments A system further configured as follows, as described in

[19] .

Claims

1. A system for performing an open-heart surgical procedure on a patient, a heart / lung machine, one or more monitoring devices configured to monitor parameters indicative of the health state of the patient during the procedure, first medical data describing one or more health states of the patient, second medical data summarizing health information of a general population of other patients, third medical data defining target ranges for operating parameters of the heart / lung machine and the one or more monitoring devices during the procedure and a database storing the same, a computer system configured to receive in real-time during the procedure operating 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 and further configured such that the computer system iteratively analyzes during the procedure (i) the operating 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 determines a prediction that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to fall outside the target ranges based on a comparison of the analysis of (i)-(iv) with the third medical data. A system as described above, further comprising, wherein the computer system is further configured to generate a trained model for the procedure based on the prediction. (i) the operating 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 determines a prediction that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to fall outside the target ranges based on a comparison of the analysis of (i)-(iv) with the third medical data. Based on the comparison of the analysis of (i)-(iv) with the third medical data, a prediction is determined that the operating data from the heart / lung machine or the parameters from the one or more monitoring devices tend to fall outside the target ranges. A system further configured as described above.

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

3. Generating the trained model for the procedure comprises iteratively training a model for the procedure by correlating each of the predictions with (i) the motion data from the cardio-pulmonary 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. The system according to claim 2. **Claim 4** The system according to claim 2 or 3, wherein the trained model is stored in the database. **Claim 5** The computer system is further configured to determine a prediction that the motion data from the cardio-pulmonary machine or the parameters from the one or more monitoring devices tend to be outside the target range based on applying the trained model for the procedure. The system according to any one of claims 2 to 4. **Claim 6** The computer system is further configured to generate an adjustment recommended to be made in real time during the procedure to at least one of the cardio-pulmonary machine or the one or more monitoring devices based on the prediction. The system according to any one of claims 1 to 5. **Claim 7** The computer system, in real time during the procedure, selects one or more of the recommended adjustments based at least in part on analyzing (i) the motion data from the cardio-pulmonary machine, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, and (iv) the second medical data, and autonomously implements the selected one or more recommended adjustments. The system according to claim 6, further configured as such. **Claim 8** The system according to claim 7, further configured such that the computer system generates a trained model for recommending a procedure adjustment based on autonomously performing the selected one or more recommended adjustments. **Claim 9** The system according to any one of claims 1 to 8, further configured such that the computer system receives operational data from a plurality of cardio-pulmonary machines. **Claim 10** The system according to any one of claims 1 to 9, wherein the one or more monitoring devices include at least one of a camera or a sensor array. **Claim 11** The system according to any one of claims 1 to 10, wherein the one or more monitoring devices include a urine storage bag monitor. **Claim 12** The system according to any one of claims 1 to 11, wherein the first medical data includes the current health state of the patient and the past health state of the patient. **Claim 13** The system according to any one of claims 1 to 12, wherein the second medical data includes past health information of patients who have undergone the procedure. **Claim 14** A computer-implemented method for use while performing an open-heart procedure on a patient, comprising: receiving, in real time during the procedure by a computer system, (i) operational data from a cardio-pulmonary machine, (ii) parameters indicating the health state of the patient during the procedure from one or more monitoring devices, (iii) first medical data describing one or more health states 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 cardio-pulmonary machine and the one or more monitoring devices during the procedure; repeatedly analyzing (i) to (iv) by the computer system during the procedure; During the procedure by the computer system, determining a prediction that the operation data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target range based on the comparison of the analyses (i) to (iv) with the third medical data A method comprising. **Claim 15** The method according to claim 14, further comprising generating a trained model for the procedure based on the prediction. **Claim 16** Generating the trained model for the procedure further comprises iteratively training a model for the procedure by correlating each of the predictions with (i) the operation 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. The method according to claim 15. **Claim 17** The method according to claim 16, further comprising determining a prediction that the operation data from the heart / lung machine or the parameters from the one or more monitoring devices tend to be outside the target range based on applying the trained model for the procedure. **Claim 18** A system for performing a medical procedure on a patient, comprising: A medical treatment system; One or more monitoring devices configured to monitor parameters indicating the health status of the patient during the procedure; First medical data describing one or more health states of the patient; Second medical data summarizing health information of a general population of other patients; Third medical data defining a target range for operation parameters of the medical treatment system and the one or more monitoring devices during the procedure A database for storing A computer system including one or more processors, equipped with wherein the one or more processors, during the procedure, in real time operation 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 to configure the computer system to receive, during the procedure, the computer system repeatedly (i) the operation data from the medical treatment system, (ii) the parameters from the one or more monitoring devices, (iii) the first medical data, (iv) the second medical data, and analyze Based on the comparison of the analysis of (i) to (iv) with the third medical data, determine a prediction that the operation data from the medical treatment system or the parameters from the one or more monitoring devices tend to be outside the target range A system further configured as such.

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

20. The computer system, in real time during the procedure, Select one or more of the recommended adjustments, based at least in part on analyzing (i) the operation 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. Automatically implement the selected one or more recommended adjustments The system according to claim 19, further configured to be as described above.

Images