Systems and methods for generating and testing clinical decision support protocols to support targeted patient interventions

Abstract

The system simulates a medical protocol. The system includes an application simulator configured to receive eligibility rules and compliance rules for the medical protocol. The simulator is further configured to receive patient data collected from a plurality of patients. The collected patient data includes longitudinal patient data regarding specific parameters collected over a period of time from one or more sensors and / or medical devices. The simulator is further configured to compare the patient data with the eligibility rules to determine when the patient was eligible for the protocol. The simulator is further configured to compare the patient data with the compliance rules to determine a historical dynamic conformance rate for the protocol. The historical dynamic conformance rate for the protocol indicates the rate at which the patient data conformed to the compliance rules for the protocol over that time period.

Description

[Technical Field]

[0001] Priority This application claims the benefit of U.S. Provisional Patent Application No. 63 / 444,875, filed February 10, 2023, and U.S. Provisional Patent Application No. 63 / 444,869, filed February 10, 2023, each of which is incorporated by reference herein in its entirety.

[0002] This application also names Dimitar V. Baronov, Robert Hammond-Oakley, and Evan This application is a continuation-in-part of U.S. Patent Application No. 17 / 502,005, filed October 14, 2021, and U.S. Patent Application No. 17 / 402,256, filed August 13, 2021, naming J. Butler, both of which claim priority to U.S. Provisional Patent Application No. 63 / 091,493, filed October 14, 2020, U.S. Provisional Patent Application No. 63 / 091,427, filed October 14, 2020, U.S. Provisional Patent Application No. 63 / 180,881, filed April 28, 2021, U.S. Provisional Patent Application No. 63 / 183,979, filed May 4, 2021, and U.S. Provisional Patent Application No. 63 / 190,070, filed May 18, 2021, each of which is incorporated by reference in its entirety herein.

[0003] Technical Field Exemplary embodiments of the present invention relate generally to systems and methods for patient monitoring, and more particularly, exemplary embodiments relate to creating, simulating, and editing medical protocols.

[0004] Background technology Healthcare operations are becoming increasingly complex due to the introduction of new sensors and treatments. As a result, clinicians are faced with an avalanche of patient data that must be evaluated and fully understood in order to prescribe optimal treatment from the numerous available options while reducing patient risk. One environment where this avalanche of information is increasingly problematic is the intensive care unit (ICU). There, the attending physician's experience and their ability to absorb available physiological information have a significant impact on clinical outcomes. Hospitals that do not maintain trained intensivists on a 24-hour basis experience a mortality rate of 14.4%, compared to a 6.0% mortality rate in adequately staffed centers. It is estimated that raising the level of care across all ICUs to that of the average trained physician could save 160,000 lives annually and $4.3 billion. As of 2012, there was a shortage of intensivists, and this shortage is only expected to worsen, reaching a 35% level by 2020.

[0005] The value of critical care experience can be explained by the fact that clinical data in the ICU is distributed at a rate far faster than even the most competent physicians can absorb it; studies have shown that errors are six times more likely under conditions of information overload and 11 times more likely under severe time pressure. Furthermore, treatment decisions in the ICU depend heavily on clinical signs that are not directly measurable but are inferred from other physiological information. Therefore, the expertise and background of clinicians play a more important role in the minute-by-minute decision-making process.

[0006] Summary of the Invention According to one embodiment of the present invention, a computer-implemented method generates a clinical decision support application. The method configures protocol eligibility conditions by selecting one or more eligibility condition objects from an available list in a configuration graphical user interface. Each eligibility condition object is associated with at least one corresponding condition type, each type being configurable with specific parameters. Protocol compliance conditions are configured by selecting one or more compliance condition objects from an available list in the configuration graphical user interface. Each compliance condition object is associated with a patient parameter. A threshold at which compliance is achieved is selected for each patient-related parameter. The patient-related parameters are arranged in the order in which they are to be displayed in the active graphical user interface. A list of notification conditions is configured by selecting from a list of specific notification types that users of the clinical decision support application will be notified of, and each notification type is associated with at least one of a plurality of users. The method then generates executable clinical decision support application code.

[0007] In various embodiments, an interface may be provided that is configured to receive conditions from a graphical user interface and generate executable clinical decision support application code in response to the received conditions.

[0008] Among other things, the plurality of eligibility condition objects includes rate-based objects, measurement-based objects, and event-based objects. Similarly, the plurality of compliance condition objects may include rate-based objects, measurement-based objects, and event-based objects.

[0009] In some embodiments, a second protocol condition object is selected from the configuration graphical user interface. The second protocol condition object is different from the first protocol condition object. The second selected protocol condition object is displayed together with the first selected protocol condition object in a protocol sequence window of the graphical user interface. Additionally, a second specific parameter window associated with parameter requirements corresponding to the second selected object may be displayed in the sequence window. Specific parameters associated with the corresponding parameter requirements may be entered in the second specific parameter window. A clinical protocol may be generated having conditions according to the received specific parameters for the first and second selected protocol condition types.

[0010] In some embodiments, the condition is an eligibility or compliance condition for a protocol. Some embodiments select multiple protocol condition objects from a graphical user interface. Multiple protocol condition objects can be rearranged within a protocol sequence window, and multiple protocol condition objects can be logically linked using statements and / or statements.

[0011] The generated protocol may be displayed within an active user interface.

[0012] According to another embodiment, a method creates a protocol. The method includes selecting a protocol condition object from a graphical user interface displaying a plurality of different protocol condition objects, each associated with at least one corresponding parameter requirement. The selected protocol condition object is displayed in a protocol sequence window of the graphical user interface. A specific parameter window associated with the parameter requirement corresponding to the selected object may be displayed. Specific parameters associated with the corresponding parameter requirement in the specific parameter window are received. A clinical protocol is generated having conditions according to the received specific parameters for the selected protocol condition type.

[0013] In various embodiments, multiple protocol condition objects are selected from a graphical user interface. Multiple protocol condition objects may be rearrangeable within a protocol sequence window. Rules may include multiple protocol condition objects logically linked using and / or statements. The generated protocol may be displayed within a patient display. Patient data is collected in association with the generated protocol, and data related to the generated protocol is displayed within the patient display.

[0014] In some embodiments, the qualifying condition is a parent-based condition. In some embodiments, the qualifying condition may be a function of an internal state variable. In some embodiments, the qualifying condition is an event-based condition.

[0015] According to another embodiment, a system creates a medical protocol. The system includes a condition library including graphically selectable eligibility objects and graphically selectable compliance objects associated with the medical protocol. The system also includes a graphic compiler that generates a user interface. The user interface is configured to display the graphically selectable eligibility objects and the graphically selectable compliance objects. The user interface is further configured to display a sequence window in which the graphically selectable eligibility objects may be moved to define eligibility rules for the protocol. The graphically selectable compliance objects may be moved within the sequence window to define compliance rules for the protocol.

[0016] In various embodiments, the system includes a reporting module configured to provide reports to healthcare personnel. The reports may be configured using a graphical compiler. The graphical report objects may be related to adoption by healthcare personnel, among other things. Examples of graphical objects for reporting include counts of clicks by healthcare staff in the interface, counts of interactions with the interface by healthcare staff, average patient compliance, time from eligibility to protocol initiation, ICU length of stay, mechanical ventilation time, extubation failure rate, readmission rate, and / or patient outcomes for dynamic patient matching.

[0017] In various embodiments, the system also includes an event detector configured to analyze the patient data to automatically detect patient events, which may include, among other things, extubation, reintubation, length of extubation, detection of extubation failure, detection of cardiac arrest, detection of vasoactive drug withdrawal, and / or detection of acute kidney injury.

[0018] According to one embodiment, a method simulates a medical protocol. The method receives eligibility rules and compliance rules for the medical protocol. Each of the rules has one or more conditions. Collected patient data from a plurality of patients is received. The collected patient data includes longitudinal patient data for specific parameters collected over a period of time from one or more sensors and / or medical devices. The method determines when a patient was eligible for the protocol according to the eligibility rules and the collected patient data. The method determines a historical dynamic concordance rate for the protocol. The historical dynamic concordance rate for the protocol indicates the rate at which patient data matched the compliance rules for the protocol over that time period.

[0019] In various embodiments, the collected patient data includes data from an EHR. Additionally, the collected patient data may include patient data from a newly deployed medical device. Accordingly, a protocol may be generated that includes one or more conditions regarding the patient data from the newly deployed medical device. The protocol may then be adjusted in response to the patient data from the newly deployed medical device.

[0020] Among other things, the method may report a patient outcome in response to high compliance with the protocol compared to low compliance with the protocol. If the patient outcome for high compliance is undesirable, the protocol may be adjusted.

[0021] The eligibility and / or compliance rules for the protocol may be adjusted to define an adjusted protocol. The method may determine a patient outcome based on high compliance with the protocol compared to low compliance with the adjusted protocol. The process may be repeated until the outcome for high compliance is desired.

[0022] The method may receive a notification rule associated with the protocol. The notification rule may be used to determine a number of simulated notifications over a period of time. The notification rule may be adjusted to reduce the number of simulated notifications.

[0023] In various embodiments, the protocol's eligibility and compliance rules are generated using a graphical compiler. The protocol's eligibility and / or compliance rules may be adjusted using the graphical compiler (e.g., after receiving feedback regarding patient outcomes in response to high protocol compliance). The protocol's eligibility and / or compliance rules may be adjusted using the graphical compiler after receiving feedback regarding the number of notifications generated by the protocol.

[0024] According to another embodiment, a system simulates a medical protocol. The system includes an application simulator configured to receive eligibility rules and compliance rules for the medical protocol. The simulator is further configured to receive patient data collected from a plurality of patients. The collected patient data includes longitudinal patient data related to specific parameters collected over a period of time from one or more sensors and / or medical devices. The simulator is further configured to compare the patient data with the eligibility rules to determine when the patient was eligible for the protocol. The simulator is further configured to compare the patient data with the compliance rules to determine a historical dynamic conformance rate for the protocol. The historical dynamic conformance rate for the protocol indicates the rate at which the patient data conformed to the compliance rules for the protocol over that time period.

[0025] Various embodiments include a database including eligibility rules and compliance rules. A graphics compiler may be configured to graphically generate the eligibility rules and / or compliance rules. An application simulator may be configured to receive notification rules associated with a protocol and to determine the number of notifications as a function of the protocol and patient data.

[0026] An exemplary embodiment of the present invention is implemented as a computer program product having a computer usable medium having computer readable program code thereon, which may be read and utilized by a computer system in accordance with conventional processes.

[0027] Those skilled in the art will more fully appreciate the advantages of various embodiments of the present invention from the following detailed description, which proceeds with reference to the drawings summarized immediately below. [Brief explanation of the drawings]

[0028] [Figure 1] 1 is a diagram that schematically illustrates a clinical patient environment, in accordance with an exemplary embodiment of the present invention; [Figure 2] FIG. 1 is a diagram illustrating a general example of a medical protocol having eligibility rules, compliance rules, protocol triggers, subscription rules, and notification rules, according to an exemplary embodiment. [Figure 3] 1A-1C are diagrams that schematically illustrate active interfaces for viewing patient protocol information, according to exemplary embodiments; [Figure 4A] FIG. 2 is a diagram illustrating a schematic diagram of system details according to an exemplary embodiment of the present invention. [Figure 4B] FIG. 4B is a schematic diagram illustrating details of a subsystem of the system of FIG. 4A. [Figure 4C] FIG. 4B is a schematic diagram illustrating details of a subsystem of the system of FIG. 4A. [Figure 5] FIG. 1 illustrates a process for simulating a clinical protocol according to an exemplary embodiment of the present invention. [Figure 6] FIG. 1 illustrates a process for generating a clinical protocol using a graphics compiler according to an exemplary embodiment of the present invention. [Figure 7] FIG. 2 is a diagram that schematically illustrates the generation of well-being rules using a user interface of a graphical compiler according to an exemplary embodiment of the present invention; [Figure 8] FIG. 2 is a diagram that schematically illustrates the generation of well-being rules using a user interface of a graphical compiler according to an exemplary embodiment of the present invention; [Figure 9] FIG. 2 is a diagram that schematically illustrates the generation of well-being rules using a user interface of a graphical compiler according to an exemplary embodiment of the present invention; [Figure 10] 1A-1C are diagrams that schematically illustrate the selection of display options using a user interface of a graphical compiler, according to an exemplary embodiment; [Figure 11] 11 is a diagram illustrating a selected display option from FIG. 10 in the user interface of FIG. 3. [Figure 12] FIG. 2 is a diagram that schematically illustrates the generation of compliance rules using a user interface of a graphical compiler according to an exemplary embodiment of the present invention. [Figure 13] 1A-1C are diagrams that schematically illustrate the selection of display options using a configuration user interface of a graphical compiler, according to an exemplary embodiment; [Figure 14] FIG. 14 is a diagram that schematically illustrates an active user interface configured with the selected compliance visualization shown in FIG. 13, according to an exemplary embodiment. [Figure 15] FIG. 10 is a diagram that schematically illustrates a user interface for configuring notification rules, according to an exemplary embodiment; [Figure 16] FIG. 10 is a diagram that schematically illustrates a user interface for configuring notification rules, according to an exemplary embodiment; [Figure 17] FIG. 10 is a diagram that schematically illustrates a user interface for configuring notification rules, according to an exemplary embodiment; [Figure 18] 10 is a schematic illustration of a configuration user interface for a reporting module, according to an exemplary embodiment; [Figure 19] FIG. 19 is a diagram schematically illustrating the configuration user interface of FIG. 18 after selection of a graphical object, according to an exemplary embodiment. [Figure 20] FIG. 20 is a diagram that schematically illustrates a report generated based on the selections of FIGS. 18-19, according to an exemplary embodiment. [Figure 21] FIG. 2 illustrates a schematic diagram of generating reporting requirements using a user interface of a graphical compiler according to an exemplary embodiment of the present invention; [Figure 22] 10A-10C are diagrams that schematically illustrate reports generated based on selections within a compliance sub-menu interface, in accordance with an exemplary embodiment; [Figure 23A] FIG. 2 illustrates a schematic diagram of generating reporting requirements using a user interface of a graphical compiler according to an exemplary embodiment of the present invention; [Figure 23B] FIG. 23B illustrates the interface of FIG. 23A after a user has selected a graphical object, according to an exemplary embodiment. [Figure 24] FIG. 23C is a diagram that schematically illustrates a report generated based on the selected graphical object from FIG. 23B, according to an exemplary embodiment. [Figure 25] FIG. 2 is a diagram that schematically illustrates a user interface of a graphical compiler, according to an exemplary embodiment of the present invention; [Figure 26A] FIG. 10 is a diagram that schematically illustrates an extubation failure rate report for a first protocol, according to an exemplary embodiment. [Figure 26B] FIG. 10 is a diagram that schematically illustrates an extubation failure rate report for the second protocol, according to an exemplary embodiment. [Figure 27] FIG. 10 is a diagram that schematically illustrates a user interface for configuring a report associated with a protocol, according to an exemplary embodiment; [Figure 28]FIG. 10 is a diagram that schematically illustrates a user interface for configuring a report associated with a protocol, according to an exemplary embodiment; [Figure 29] FIG. 10 is a diagram that schematically illustrates a view of a data collection that may be used by an analyzer to automatically determine clinical events and / or outcomes, according to an exemplary embodiment. [Figure 30] FIG. 10 is a diagram that schematically illustrates a view of a data collection that may be used by an analyzer to automatically determine clinical events and / or outcomes, according to an exemplary embodiment. [Figure 31] FIG. 10 is a diagram that schematically illustrates a view of a data collection that may be used by an analyzer to automatically determine clinical events and / or outcomes, according to an exemplary embodiment. [Figure 32] FIG. 10 is a diagram that schematically illustrates a view of a data collection that may be used by an analyzer to automatically determine clinical events and / or outcomes, according to an exemplary embodiment. [Figure 33A] FIG. 1 illustrates a process for creating a best practice alert in accordance with an exemplary embodiment. [Figure 33B] FIG. 1 is a diagram illustrating a user interface of an electronic health record, according to an exemplary embodiment. [Figure 34] FIG. 1 illustrates a process for generating and optimizing protocols for a newly deployed medical device, according to an exemplary embodiment. [Figure 35] FIG. 10 is a diagram that schematically illustrates an example of a protocol for using a newly deployed medical device, according to an exemplary embodiment.

[0029] MODE FOR CARRYING OUT THE INVENTION In an exemplary embodiment, the protocol compiler allows a medical practitioner to generate and / or modify medical protocols within a graphical user interface. Among other things, the graphical user interface provides selectable protocol eligibility conditions and / or selectable protocol compliance conditions (commonly referred to as "protocol conditions"). In particular, one or more selectable protocol condition objects are displayed within the interface. One or more selected protocol condition objects may be used to generate medical protocol rules (e.g., by combining them using logical operators). Depending on the type of condition object, the medical practitioner can enter values ​​for specific parameters within a parameter window within the user interface. The exemplary embodiment provides a parameter window above or adjacent to one or more selected model objects. The window can display one or more properties associated with each of the selected protocol condition objects. Furthermore, properties may be edited in the window itself and propagated throughout the system.

[0030] Furthermore, in an exemplary embodiment, a protocol simulator allows medical personnel to test the performance of a protocol using actual historical patient data. The simulator simulates a protocol (e.g., a protocol generated using a compiler or traditional coding methods) and provides patient outcome performance characteristics (e.g., based on the patient's overall adherence with the protocol). The performance characteristics enable rapid iteration of a protocol based on desired patient and / or clinician performance. For example, if patient performance from the simulation is relatively unsatisfactory despite high compliance, the protocol (or specific parameters thereof) may be iterated (e.g., using a compiler) until the desired patient performance corresponds to high patient compliance. Furthermore, if patient performance is acceptable above a certain compliance threshold, medical personnel can focus hospital resources to bring all patients within the desired threshold for compliance.

[0031] Additionally, exemplary embodiments enable performance monitoring of medical staff responsible for overseeing and executing specific protocols and subsequent interventions. Medical staff performance may be output in custom reports. Reporting criteria may be established using a graphical user interface. To enable reporting, the system includes a library of functions that analyze data and extract results from the data (e.g., determining that a patient failed to extubate by analyzing ventilator performance data).

[0032] Additionally, various embodiments allow for protocol optimization, particularly when it comes to newly deployed medical devices. Optimization insights may be determined by iterating over multiple versions of the protocol with different conditions until a desirable protocol is produced. Details of exemplary embodiments are described below.

[0033] 1 illustrates a schematic representation of a clinical patient environment, in accordance with an exemplary embodiment of the present invention. In various embodiments, a medical protocol generated using the graphical compiler may be active within the clinical patient environment of FIG. 1. Additionally or alternatively, the protocol may be simulated using historical data collected from the clinical patient environment illustrated herein. In various embodiments, the clinical patient environment may be a particular clinical environment (e.g., a neonatal ICU).

[0034] The environment includes sensors 102 (also referred to as monitors 102) for providing patient data to a healthcare provider, such as a doctor, nurse, or other healthcare provider. To that end, the patient 101 may be coupled to one or more physiological sensors 102 or bedside monitors 102 that can monitor various physiological parameters of the patient. Note that the patient 101 may be human or non-human (e.g., a non-human, e.g., a veterinary patient such as a dog).

[0035] The sensors 102 may include, but are not limited to, a blood oximeter, a blood pressure measuring device, a pulse measuring device, a glucose measuring device, one or more analyte measuring devices, an electrocardiogram recording device, among others. Additionally, the patient 101 may be subjected to periodic examinations and tests, and the data may be stored in an electronic health record (EHR). The EHR may include stored information such as, but not limited to, hemoglobin, arterial and venous oxygen content, lactate, weight, age, sex, ICD-10 code, capillary refill time, subjective clinician findings, patient self-assessment, prescribed medications, medication regimens, genetic characteristics, test results, allergies, and the like.

[0036] Additionally, the patient 101 may be coupled to one or more therapy devices 104 configured to administer therapy to the patient 101. In some embodiments, the one or more therapy devices 104 may be controlled by the systems disclosed herein in response to, for example, output from the trajectory interpretation module defining the patient's condition or pathology. In various embodiments, the therapy device 104 may include an extracorporeal membrane oxygenator, a mechanical ventilator, a drug infusion pump, an implantable ventricular assist device, or the like.

[0037] The illustrative embodiments provide a real-time, automated determination of whether a patient 101 is eligible for a medical protocol course of action (commonly referred to as protocol eligible) based at least in part on data obtained directly from sensors and peripheral devices. Real-time determination is advantageous over prior art methods that require medical personnel to review disparate patient data reports and analyze the data to determine whether the patient 101 is protocol eligible. Furthermore, in the prior art, medical personnel typically check a patient's eligibility sporadically, leading to suboptimal clinical outcomes when optimal treatment for the patient 101 requires early initiation of the protocol. Similarly, sporadic eligibility checks cannot account for dynamic matching of the patient's 101 eligibility because measurements are taken at static points in time.

[0038] In various embodiments, system 100 can track the duration for which patient variables adhere to established eligibility criteria, advantageously improving medical protocol technology by enabling new protocols with long-term (e.g., duration-based) criteria, as opposed to protocols that use the most recent static data points. Accordingly, exemplary embodiments track dynamic agreement, i.e., the rate at which a patient's physiological data conforms to protocol requirements after the protocol has begun. This advantageously allows healthcare professionals to visualize patient data as adherence rates per duration (e.g., 60% dynamic agreement 3 hours after protocol initiation). Furthermore, tracking eligibility time advantageously allows healthcare professionals to prioritize patients who have been eligible for a long period of time, thus mitigating any risk arising from the fact that a patient has not received prescribed protocol treatment for a long duration.

[0039] Dynamic concordance calculations based on longitudinal measurements of patient variables also support using metrics as actionable treatment goals, thereby delivering treatments targeted to increase patient concordance. Furthermore, the inventors have preliminary data showing that patients who achieve a desired dynamic concordance rate can experience better outcomes compared to patients with lower concordance rates.

[0040] By providing continuous, real-time assessment of whether a patient's trajectory is progressing according to the protocol-specified pathway, dynamic matching allows for more focused and timely interventions to keep patients within the most favorable course of action, a significant improvement over what is possible with current technology. The longer a patient spends within the desired trajectory, as measured by the rate of match, the more likely the patient is to avoid complications and achieve the optimal possible clinical outcome. Conversely, the shorter a patient spends within the desired trajectory, as measured by the rate of match, the more likely the patient is to experience complications and achieve a suboptimal clinical outcome.

[0041] 2 illustrates a general example of a medical protocol 120 having eligibility rules 122, compliance rules 124, protocol triggers 126, subscription rules 128, and notification rules 130, according to an exemplary embodiment. Each of the aforementioned rules / triggers may have one or more conditions 115. Furthermore, in some embodiments, the medical protocol 120 may not include subscription rules 128, notification rules 130, compliance rules 124, and / or protocol triggers 126.

[0042] The eligibility rules 122 may include one or more conditions 115 that must be met (e.g., true or false) for the patient 101 to be eligible for the protocol 120. The eligibility module 110 may compare data in the database 105 and / or EHR to the rules 122 to determine whether the rules 122 are met. Additionally or alternatively, the eligibility rules 122 may include one or more parametric conditions 115 that must be met (e.g., a particular variable is greater than a particular value). The eligibility module 110 may receive patient data from the device interface 106 to determine whether the patient 101 is eligible (e.g., the conditions 115 of the rules 122 are met). In some embodiments, the eligibility rules 122 of a protocol may depend on compliance with another protocol (referred to as a parent protocol and a child protocol), as described in U.S. Patent Application No. 17 / 502,005, which is incorporated herein by reference in its entirety.

[0043] Similarly, compliance rules 124 may include one or more conditions 115 that must be met (e.g., true or false) for the patient 101 to comply with the protocol 120. The matching module 110 may compare data in the database 105 and / or EHR 103 with the rules 122 to determine whether the rule 122 is met (i.e., whether each condition of the rule is met). While the EHR 103 and database 105 are shown as separate components, it should be understood that the database 105 may interface with the EHR 103 to extract relevant patient information from the EHR 103 and store data from the EHR 103 in the database. Thus, the exemplary embodiments may make the determinations described herein by communicating with the EHR 103, the database 105, or both.

[0044] Additionally or alternatively, the compliance rules 124 may include various parametric conditions that must be met (e.g., a particular variable is greater than a particular value). The system 100 may receive patient data from the device interface 106 to determine whether the patient has complied with the protocol 120 (e.g., the rules 124 are met).

[0045] Additionally, in some embodiments, the protocol 120 can define protocol trigger rules 126 that include one or more conditions 115 that, when met, automatically trigger and initiate a course of action. In some embodiments, the conditions 115 may include a dynamic match rate for a given protocol or parent protocol. The protocol trigger module 116 can detect when these conditions 115 are met and can communicate with and / or control one or more medical devices 104 to initiate a course of action.

[0046] In various embodiments, protocol 120 may further include subscription rules 128 and notification rules 130. Subscription rules 128 assign different subscription levels to different healthcare professionals. For example, a direct care team may be at subscription level 1, and an administrative team may be at subscription level 2. Subscription rules 128 may be used in notification rules 130. Thus, different subscriptions may receive different notifications and / or notifications for different reasons.

[0047] Any of the above rules may include a condition 115 based on the probability that the patient is in a physiological condition (e.g., an abnormal physiological condition). Various embodiments may use internal state variables (ISVs) (e.g., hidden internal state variables) as one or more conditions 115. To that end, various embodiments may use a probability density function (PDF) of the internal state variables (ISVs) generated by the risk engine 1000 as one or more conditions 115. Additionally, clinical events / outcomes detected by an event detector may be used as one or more conditions 115.

[0048] As used herein (e.g., to refer to subscription rules 128, notification rules 130, eligibility rules 122, and compliance rules 124), the term "rules" is intended to include a single rule having a single condition 115. For convenience, rules with multiple conditions may be referred to in the plural as "rules." However, these terms are used interchangeably. Example embodiments using the term "rules" do not necessarily require multiple conditions. It should be understood that both the singular "rule" or the plural "rules" are intended to include one or more conditions.

[0049] In a given clinical environment, one or more patients 101 may be following medical protocols 120 (e.g., the same or different protocols). The sensors 102 of FIG. 1 are collecting data related to the protocols 120 (e.g., a general example of a protocol shown in FIG. 2). To that end, a patient protocol compliance and adherence system, generally referred to herein as system 100, may be configured to receive patient-related information including real-time information from the sensors 102, EHR patient information from electronic health records, information from treatment devices 104 such as ventilation status, infusion rates, medication types, and other patient-related information, which may include the patient's medical history, previous treatment plans, results from previous and current lab tests, allergy information, predispositions to various diseases, and any other information that may be deemed relevant to the treatment.

[0050] The system 100 provides real-time protocol eligibility updates. Additionally, the exemplary embodiment can determine the range of time that a patient 101 is protocol eligible. Thus, healthcare professionals can have quantifiable criteria by which their performance is judged (e.g., time from eligibility to protocol initiation, protocol adherence rate, etc.).

[0051] To that end, system 100 may include a display (e.g., coupled to system 100). In various embodiments, the display may be an interactive display that provides easy visualization of a patient's performance with respect to eligibility and / or compliance with a particular protocol. In various embodiments, the display provides a list of all patients seen by a healthcare professional or all patients in a particular unit, and further provides details of the protocol status for each patient. For example, exemplary embodiments provide a visual indication of whether a patient is eligible for a course of treatment associated with a protocol and the amount of time the patient has been eligible. If a patient is complying with a protocol, exemplary embodiments provide a visual indication of how long the patient has been complying with the protocol and how well the patient has adhered to the protocol. Some embodiments may provide a visual indication of the compliance rate per individual parameter of the protocol for each patient. After selecting a visual indication, the display shows patient performance variables associated with the particular protocol. In various embodiments, this display may be accessed via an EHR 103 interface.

[0052] 3 schematically illustrates an active interface 112A for viewing information in a patient protocol 120, according to an exemplary embodiment. A patient's 101 medical event history, as well as ongoing protocols, completed protocols, and / or protocol eligibility history, can be viewed by a medical professional within the interface 112A. Among other things, the interface can show the patient's bed number, name, condition, health record number, gender, age, recent treatments, map treatments 132, and / or other parameter values.

[0053] The interface 112 displays one or more patients 101 eligible for an eligibility protocol and / or one or more patients 101 enrolled in the protocol. The exemplary embodiment provides a single user interface 112 configured to display patient information for multiple patients 101. The multiple patients 101 may be all of the patients 101 on a particular hospital floor, in a particular hospital unit, associated with a particular protocol 120, and / or under the care of a particular healthcare professional. The same user interface 112 also shows and describes the protocol actions 132 for each patient 101. For example, patient 101A is shown as eligible for an extubation readiness attempt (ERT) protocol 120 (e.g., eligibility icon 131) and the eligibility time (e.g., 1 day and 17 hours for patient 101A) is shown. Patient 101B is shown as having completed the ERT protocol 120 (e.g., completion icon 133) and the total protocol time completed (i.e., 2 hours and 0 minutes for patient 101B) is shown. Patient 101C is shown as currently enrolled / in progress in ERT protocol 120 (e.g., enrollment icon 137), and the total time patient 101C has been on the protocol (e.g., 1 hour and 19 minutes for patient 101C) is shown.

[0054] The interface 112 may also show the calculated dynamic concordance rate 135. As shown in Figure 3, optionally, exemplary embodiments may display the amount of time that the patient 101 is or has been following the protocol 120, as well as the dynamic concordance rate 135.

[0055] In various embodiments, the dynamic match rate may be updated in real time or when new data is received from the sensors and / or medical devices. Some embodiments may update the dynamic match rate 135 on a predefined schedule (e.g., every 30 seconds, every minute, etc.). The dynamic match rate may be displayed as it updates. The system 100 may determine which direction the dynamic match rate is trending. In an exemplary embodiment, trend information may be displayed on the user interface. For example, the dynamic match indicator icon 139 may indicate whether the dynamic match rate is increasing (e.g., a green arrow icon 139A), decreasing (e.g., a red arrow icon 139B), or stable within a predefined time frame (e.g., a horizontal green arrow 139C if the overall match is above a threshold, or a horizontal red arrow 139D if the overall match is below a threshold).

[0056] The system 100 can visually indicate completed protocols with a checkmark on the user interface 116. These visualizations allow for simplified transfer of clinical care from one healthcare provider to another, thus leading to better patient outcomes. For example, extubation decisions are typically made by the care team during morning rounds based on extubation readiness attempts completed during the previous shift. The rounds team may review which patients have completed ERT and then determine to extubate all patients with high overall agreement. Longitudinal data for patients with lower agreement can be reviewed in more detail to determine the reason for non-compliance and evaluate whether this reason indicates an unacceptable risk of extubation failure. Furthermore, in reality, by the time the protocol 120 is completed, the healthcare provider responsible for the patient may have changed shifts. The illustrative embodiment provides visualizations that simplify prioritization of patient care for subsequent clinicians.

[0057] 4A schematically illustrates details of a system 100, in accordance with an exemplary embodiment of the present invention. The system 100 includes a sensor / medical device interface 106 configured to communicate with one or more sensors 102 and / or one or more medical devices 104. For convenience, the exemplary embodiment may generally refer to receiving data from one or more sensors and / or one or more medical devices as receiving data from a sensor 102. However, it should be understood that references to receiving data from a sensor 102 are also intended to include receiving data from a medical device 104.

[0058] Again, the device interface 106 receives / streams real-time patient data from the sensors 102. The device interface 106 can receive data from a variety of sensors 102, such as a blood oximeter, a blood pressure measuring device, a pulse measuring device, a glucose measuring device, one or more analyte measuring devices, and / or an electrocardiogram recording device, among others. In some embodiments, the device interface 106 communicates with multiple sensors 102 and / or medical devices simultaneously. Thus, the device interface 106 can aggregate and / or compile the various received patient data.

[0059] The system 100, as previously described, includes a database 105 that accesses a patient EHR 103. Figure 4B schematically illustrates details of the interaction between the EHR 103 and the database 105, according to an exemplary embodiment. In various embodiments, the system 100 can communicate with the EHR 103 via a Rapid Healthcare Interoperability Resources (FHIR) interface 107.

[0060] FHIR is a standard for the electronic exchange of health information. FHIR is designed to facilitate the exchange of health data between different health systems, applications, and organizations in a standardized, secure, and interoperable manner. FHIR is closely related in some ways to electronic health records (EHRs).

[0061] For example, FHIR provides a standardized framework for exchanging electronic health information, including data stored within EHRs 103. Using FHIR, EHRs 103 can communicate with other healthcare applications, systems, and devices, enabling seamless data exchange and interoperability. FHIR also promotes interoperability by defining standard data formats and APIs (application programming interfaces) for accessing and exchanging healthcare data. This allows different EHRs 103 to communicate and share patient information more effectively, regardless of the specific technology or platform they use.

[0062] FHIR also defines a set of resource types and data elements for representing various aspects of medical information, such as patients, medications, allergies, encounters, and findings. EHRs 103 can use FHIR resources to organize and represent patient data in a structured format, making it easy to access, find, and exchange specific information.

[0063] Many modern EHRs 103 support FHIR as a means of interoperability and data exchange. They may provide FHIR APIs that allow external applications to access and interact with patient data stored within the EHR. This allows the FHIR interface 107 to seamlessly integrate with the EHR 103 and leverage data stored within the EHR 103. In various embodiments, the FHIR interface 107 may include a graphical button or option to "push protocols to the EHR." Alternatively, the EHR 103 may be automatically updated as new protocols 120 are created. This allows protocols 120 to be entered or updated within the EHR 103.

[0064] In various embodiments, the system 100 may be integrated with the EHR 103 so that the system is accessible via single sign-on 109 (SSO 109). SSO 109 allows users to access multiple medical applications and systems with a single set of login credentials. Instead of requiring users to remember and enter a separate username and password for each application or system they need to access, SSO 109 simplifies the authentication process by providing a centralized authentication mechanism. Because medical professionals often need access to a variety of clinical applications, diagnostic systems, and patient management tools, SSO 109 can significantly improve workflow efficiency and user experience.

[0065] Advantageously, exemplary embodiments can deliver and assign alerts using Best Practice Alerts 111 (BPAs) in the electronic health record 103 (e.g., via the FHIR interface 107). The BPAs 111 in the EHR 103 notify healthcare providers of potential issues or opportunities for improvement in patient care based on established best practices, guidelines, or protocols. The BPAs 111 are integrated into the EHR 103 system to assist clinicians in making informed decisions at the point of care, thereby improving patient safety, quality of care, and adherence to evidence-based practice.

[0066] In various embodiments, examples of BPA111 in an EHR103 system include: · Alerting providers to potential drug-drug interactions or allergies when prescribing medications. · Reminding providers to order recommended preventive screenings or vaccinations based on the patient's age, sex, and medical history. ·Notifying providers of abnormal test results or vital signs requiring further evaluation or intervention. ·Flag instances of duplicate orders, excessive medication dosages, or improper medication regimens. ·Advising providers on evidence-based clinical guidelines for managing specific medical conditions or clinical scenarios.

[0067] Advantageously, as described further below, the exemplary embodiments enable the discovery and implementation of new medically relevant protocols, any of which may be integrated into the BPA 111 of the EHR 103. Thus, the BPA 111 can externally distribute notifications / alerts generated by various embodiments of the system 100.

[0068] Returning to FIG. 4A , the database 105 can also communicate with the device interface 106 to store real-time data received via the device interface 106. The database may also include a medical protocol library containing information regarding multiple medical protocols. By way of example, the medical protocols may include an extubation readiness attempt protocol, a ventilation vasoactive drug weaning protocol, a sepsis management protocol, an enhanced recovery after surgery (ERAS) protocol, and / or other hospital protocols. The information in the library 108 includes eligibility and compliance rules for each of the protocols, which are described in further detail below. The medical protocol library may also include specific subscription and / or notification rules for each protocol, which are described in further detail below.

[0069] The protocol eligibility and matching module 110 is configured to determine the patient's eligibility for at least one of the medical protocols responsive to the received patient data. Additionally, the eligibility and matching module 110 may access historical data (e.g., from the EHR 103 or from the database 105) to determine the patient's eligibility. To that end, the eligibility and matching module 110 may communicate with, among other things, the device interface 106, the database 105, and the library 108. The eligibility and matching module 110 may sometimes be referred to as the eligibility module 110 and / or the matching module 110.

[0070] Generally, a patient's eligibility depends on one or more measurements of the patient's data meeting a threshold condition (e.g., above or below a given threshold, or within a particular range) according to the requirements of a protocol stored in the library (e.g., a particular FiO2 and / or BPM measurement). When the patient 101 is eligible for the protocol, the eligibility module 110 triggers an indication that the patient 101 is eligible. In some embodiments, the eligibility module 110 sounds an alarm and / or communicates with the user interface 112 to visually indicate that the patient is eligible. For example, the eligibility module 110 can prompt a notification on a healthcare professional's device (e.g., a smartphone) indicating that the patient is eligible for the protocol. In some embodiments, the user interface 112 also communicates the amount of time the patient has been eligible. Thus, the exemplary embodiments advantageously provide real-time updates regarding the patient's eligibility status.

[0071] Real-time data collection and eligibility updates contrast with prior art methods that rely on healthcare professionals to check, collect, aggregate, and analyze multiple static patient parameters to determine protocol eligibility. Eligibility and / or compliance rules for a particular protocol may vary by treatment center (e.g., extubation readiness attempts may have different eligibility criteria at different hospitals). Furthermore, healthcare professionals are limited by the time they have available for a particular shift, and their attention is largely divided between examining a large number of patients 101. By providing real-time collection and aggregation of multiple data streams from patient-coupled devices 102, exemplary embodiments advantageously provide potentially life-saving clinical response speeds. In various embodiments, one or more healthcare professionals determined by the system 100 to be on-call and assigned to a particular patient may be notified of the real-time eligibility (or compliance) status. Accordingly, prompt action may be taken to improve the patient's 101 outcome. Additionally or alternatively, various embodiments may automatically enroll the patient 101 in a protocol.

[0072] Eligibility determinations are based on a set of measurement thresholds, events, and / or other binary variables. For example, eligibility rules for a vasoactive drug withdrawal protocol might include that the patient is under cardiology care (as determined by the hospital's ADT stream or EHR), is receiving a medication infusion (another event), has an IDO2 index below a threshold, and has blood pressure above another threshold.

[0073] The system 100 may include a quality reporting module 114 that tracks the time elapsed since a patient became eligible until a user confirms the patient's eligibility (e.g., a healthcare professional interacts with a notification). Alternatively or additionally, the quality reporting module 114 may track the time elapsed since a patient became eligible until a healthcare professional begins the course of treatment associated with the protocol for which the patient 101 is eligible. By tracking this information, healthcare professional performance may be objectively measured (e.g., which healthcare professionals are the quickest responders, and what is the impact of response time on the patient's 101 clinical outcome for a given protocol).

[0074] The system 100 may also include a protocol trigger module 116 that instructs the eligibility and conformance module 110 to begin tracking compliance data for the patient 101. The protocol trigger module 116 is configured to receive information regarding the initiation of a course of action in a protocol 120. In various embodiments, a medical professional can initiate a course of action (e.g., based on feedback from the eligibility module 110 indicating that the patient 101 is eligible) and notify the protocol trigger module 116 of the initiation of the course of action (e.g., via the user interface 112). In some embodiments, the protocol trigger module 116 is configured to automatically initiate the course of action by communicating with the therapy device 104 (e.g., after the medical professional acknowledges the initiation via the user interface). In other embodiments, the protocol trigger module 116 can automatically detect that a professional has initiated the course of action and begin tracking conformance data. For example, in an ERT protocol, when the system 100 detects that the ventilator mode has changed, this may be used to detect the initiation of the ERT protocol and trigger dynamic conformance tracking for the protocol.

[0075] After a course of action for a protocol has begun, the conformance module 110 can continue to communicate with the same, different, or additional sensors 102 to determine the patient's 101 compliance with the protocol. The conformance module 110 can determine the patient's 101 dynamic conformance with the medical protocol in response to newly received patient data and the compliance rules in the protocol library. Compliance with a particular eligibility or compliance rule may be determined by calculating, comparing, measuring, and / or otherwise determining whether a patient parameter meets the criteria (e.g., whether a condition is met) in the protocol library for the particular protocol. To that end, in various embodiments, the patient variable is compared to the level or range of the compliance rule for the protocol in the library 108. In various embodiments, the dynamic conformance rate is the rate at which patient data (e.g., measured, calculated hidden internal state variables, and / or otherwise determined) conforms with the protocol's compliance rules 124 over time. Thus, an overall dynamic conformance rate may be determined for patients following the protocol. In some embodiments, a parameter-specific dynamic match rate may be calculated for each parameter of the compliance rule 124 (eg, the two parameters in the compliance rule 124 of FIG. 2).

[0076] Additionally, the matching module 110 can calculate and visually indicate (e.g., via the user interface 112) a real-time dynamic match status for the patient. FIG. 4A schematically illustrates eligibility rules 122 and compliance rules 124 for an example extubation readiness testing protocol, according to an exemplary embodiment. It should be understood that the parameters tracked for eligibility may differ from the parameters tracked for compliance. In the example of FIG. 2, the eligibility rules 122 have three separate variables / parameters, and the compliance rules 124 have two separate variables / parameters. The matching module 110 can calculate a dynamic match rate for the overall compliance rules 124. Additionally or alternatively, the matching module 110 can calculate a dynamic match rate for each individual parameter. The matching module 110 transmits the dynamic match rate to the user interface 112, which displays the dynamic match rate. Thus, medical personnel's attention may be directed to patients 101 needing treatment (e.g., patients with a low or downwardly trending dynamic match rate).

[0077] The quality reporting module 114 can track dynamic match rates as the percentage of time the patient 101 is compliant with medical protocols. The quality reporting module 114 can also track patient eligibility times. Additionally, the quality reporting module 114 can retrospectively examine patient match rates and / or eligibility times to see how well a particular patient and / or a particular healthcare professional's patients performed compared to the patient population. Additionally, the reporting module 114 may be configured to display received patient data and highlight non-compliant portions of the received data. Thus, the quality reporting module 114 allows healthcare facilities and / or staff to retrospectively assess how well a patient was managed. For example, if eligibility times are very high, healthcare professionals will become aware of this. This can aid in hospital policy formation and help ensure prompt treatment by healthcare staff.

[0078] The system may include a patient tracking module 118 configured to receive subscription rules 128 and notification rules 130, as well as patient status information from the protocol eligibility and conformance module 110. When the rules 130 are satisfied, the tracking module 118 sends notifications to various registered users according to their subscription level. For example, notifications may be sent when eligibility status changes, when a course of action (also called protocol enrollment) is initiated, and / or when a patient falls out of compliance.

[0079] The system of FIG. 4A may include a risk-based monitoring engine 1000 (also referred to as “risk engine 1000”) configured to receive data from a bedside monitor 102, an electronic health record 103, a treatment device 104, and any other information that may be deemed relevant to making an informed assessment of a patient's clinical risk, as well as any combination of the aforementioned elements.

[0080] In an exemplary embodiment, the risk engine 1000 may include a physiological observer module 119 that utilizes multiple measurements to estimate probability density functions (PDFs) of internal state variables (ISVs) that describe components of the physiology related to the patient's treatment and medical condition according to a predetermined physiological model. The ISVs may be directly observable in noise (as a non-limiting example, heart rate is a directly observable ISV), hidden (as a non-limiting example, oxygen delivery (DO2), defined as the flow of saturated oxygen in the blood through the aorta, cannot be directly measured and is therefore hidden), or intermittently measured (as a non-limiting example, hemoglobin concentration measured from a complete blood count test is an intermittently observable ISV).

[0081] In some embodiments, when physiological observer module 119 evaluates a set of ISVs at a given time step (e.g., tk; tk+1; generally tk+n), system 100 may not have a complete set of ISV measurements simultaneously with the given time step. For example, system 100 may have measurements during the given time step for some internal state variables, but may not have measurements during the given time step for some other internal state variables (e.g., concurrent measurements of intermittent ISVs may not be available at the given time step). As a result, the intermittent ISVs are hidden ISVs for purposes of evaluating ISVs at the given time step. However, evaluation of a set of ISVs by the physiological observer module 119 (described herein) is nevertheless possible according to the embodiments described herein because the predicted PDF of the ISV 211 is affected by past measurements of that intermittent ISV, and as a result, in the exemplary embodiment, the predicted PDF of the ISV 211 is sufficient input for the physiological observer module 119.

[0082] In one embodiment, instead of assuming that all variables can be deterministically estimated without error, the physiological observer module 119 of the present disclosure provides a probability density function as an output. Further details regarding the physiological observer module 119 are provided herein.

[0083] The clinical trajectory interpretation module 123 may, for example, be configured with multiple possible patient states and may determine which of those patient states are likely and with what probability given an estimated probability density function of internal state variables. Examples of specific patient states include, but are not limited to, hypotension with sinus tachycardia, hypoxia with myocardial depression, compensated circulatory shock, cardiac arrest, and hemorrhage, among others. Additionally, these patient states may be specific to particular medical conditions, and the boundaries of each patient state may be defined by various physiological variable and data thresholds. In various embodiments, the clinical trajectory interpretation module 123 may determine the patient state into which a patient may be classified using information collected from reference materials, information provided by a healthcare provider, or other sources.

[0084] The reference materials may be stored, for example, in the database 105 or other storage device accessible to the risk-based monitoring application 1020 via the network interface 113. These reference materials may include materials synthesized from reference books, medical literature, expert surveys, physician-provided information, and any other materials that may be used as a reference for providing medical care to a patient. In some embodiments, the clinical trajectory interpretation module 123 may first identify a patient population similar to the target patient being monitored. By doing so, the clinical trajectory interpretation module 123 may be able to use relevant historical data based on the identified patient population to help determine the likely patient condition.

[0085] The clinical trajectory interpretation module 123 can also determine the possible patient states into which the patient may currently be classified, taking into account the estimated probability density functions of the internal state variables provided by the physiological observer module 119. In this manner, each possible patient state is assigned a probability value between 0 and 1. The combination of the patient states and their probabilities is defined as the clinical risk to the patient.

[0086] Further details regarding the risk-based patient monitoring engine 1000 and the calculation of hidden internal state variables are provided in U.S. Patent Application Nos. 17 / 033,591 and 17 / 501,978, each of which is incorporated herein by reference in its entirety.

[0087] In view of the above, it should be understood that the accurate establishment of appropriate medical protocols 120 is critical to the overall management and well-being of the patient 101. For many medical procedures, uniform standards for protocols 120 have not been established. For example, the eligibility rules 122, compliance rules 124, protocol trigger rules 126 (also referred to as protocol triggers 126), subscription rules 128, and / or notification rules 130 of any given protocol 120 (e.g., ERT protocol 120) may vary from hospital to hospital. Generally, protocols 120 are built around the expertise and preferences of medical staff in a given clinical environment.

[0088] In practice, both generating protocols 120 and integrating them with system 100 (e.g., to receive streamed data and track eligibility / compliance) can be challenging and time-consuming. The illustrative embodiments advantageously provide a configuration user interface 112 that enables healthcare professionals to visually create and / or edit medical protocols 120 within a graphical user interface with little or no coding. This innovation enables point-of-care adjustments to protocols 120 in real time and also allows healthcare professionals to optimize protocols 120 by simulating with historical data acquired by system 100 (e.g., from the same clinical environment or a different clinical environment). Furthermore, in various embodiments, the interface for generating protocols may be part of or displayed on the same monitor as active interface 112A that displays patient data (e.g., as shown in FIGS. 3 and 14 ). Alternatively, the interface for generating protocols may be different from interface 112.

[0089] For clarity, the active interface 112A used when a protocol is deployed at a medical site (e.g., as shown in FIGS. 3, 11, and 14) may be referred to as the active interface 112A. The interface 112 used to generate the protocol 120 may be referred to as the configuration interface 112. The active interface 112A and the configuration interface 112 may be, but are not necessarily, part of the same interface. Furthermore, the active interface 112A and the configuration interface 112 may be, but are not necessarily, found on the same device. For simplicity, the two interfaces are described herein as being part of the same interface 112 (e.g., on the same display device). However, in various embodiments, these interfaces 112A and 112 may be separate (e.g., on different displays).

[0090] 4C schematically illustrates a system 100 for generating and simulating a medical protocol 120, according to an exemplary embodiment. Among other things, the system 100 includes a database 105 that stores real-time patient data received from sensors 102 and / or medical devices 104. The database also has access to a patient EHR 103. Additionally, the database 105 may include test and / or sample data (e.g., from blood tests) associated with one or more patients 101.

[0091] Database 105 may be the same database 105 shown in FIG. 4A. Database 105 may store patient data as it is collected by or entered into system 100 (e.g., during operation of system 100, as described in U.S. Patent Application No. 17 / 502,005). Thus, the patient data may be from a particular clinical use environment (e.g., a particular hospital or hospital unit). However, in some embodiments, patient data may be pooled from multiple clinical use environments (e.g., a collection of data from multiple hospitals collected from various systems 100). Thus, when protocol 120 is simulated using historical data, this historical data may be drawn from database 105, among other sources. However, some embodiments may also include non-patient-generated data (e.g., simulated data, hypothetical data, AI-generated data, etc.).

[0092] The database 105 may also include a medical protocol library containing information about one or more medical protocols. By way of example, the medical protocols may include information about an extubation readiness testing protocol, a ventilation vasoactive drug weaning protocol, a sepsis management protocol, an enhanced recovery after surgery (ERAS) protocol, and / or other hospital protocols. The information in the database 105 includes eligibility rules 122 and compliance rules 124 for each of the protocols 120. The database 105 may also include, for each protocol, protocol trigger rules 126, subscription rules 128, and / or notification rules 130.

[0093] In various embodiments, the system 100 may include a data anonymizer 140 in communication with the database 105. Because the system 100 may perform simulations using actual historical patient data, it may be advantageous to anonymize the patient data (i.e., separate patient identifying information from the data). Communication between the data anonymizer 140 and the database 105 may be two-way communication such that the patient data in the database 105 is anonymized.

[0094] The system 100 includes a protocol simulator 142 in communication with the database 105 and / or the graphical compiler 146. The protocol simulator 142 receives details of one or more protocols 120 (e.g., the protocols' various rules and conditions) from stored protocols in the database 105 or from generated protocols from the graphical compiler 146. The simulator 142 also retrieves patient data from the database 105 and uses the patient data to simulate the results of the received protocol 120.

[0095] For example, simulator 142 may be part of system 100 in a medical-surgical ICU at Boston Children's Hospital. Database 105 may have access to patient data from all patients in the unit within the past 12 months. The patient data may be anonymized by anonymizer 140. Simulator 142 may then simulate how a received protocol 120 would have performed within a particular unit based on the patient data from that unit.

[0096] As an example, simulator 142 can simulate how often patient 101 is compliant with protocol 120, how often patient 101 adheres to protocol 120, dynamic concordance rates for patient 101, and compare outcomes for patients 101 with high compliance to a given protocol versus low compliance to a given protocol. This information may be used to iterate protocol 120 using graphical compiler 146, as described further below.

[0097] Various embodiments provide a graphical compiler 146 that enables graphical generation and / or modification of protocols 120. As described above, the graphical compiler 146 allows a user to create new clinical protocols using a graphical interface. Instead of or in addition to writing code that describes the protocol, a user can select pre-configured graphical objects with various protocol 120 requirements.

[0098] The user can arrange the graphical objects in a particular order and can also edit the values ​​of parameters associated with the graphical objects in adjacent parameter windows, thereby creating a new clinical protocol 120. Instead of writing code, the user can advantageously write the protocol 120 graphically, having windows for providing values ​​for particular parameters (e.g., using drop-down menus). Thus, the graphical compiler 146 allows the user to edit a MAP in a graphical manner.

[0099] The simulator 142 communicates with a protocol analyzer 144. The analyzer 144 provides reports (e.g., how often the protocol notifies, what the expected impact on patient outcomes is, etc.). This information can be used as feedback to iterate the protocol 120 (e.g., change some of the protocol's settings using the graphics compiler 146). The user can continue iterating until they are satisfied with the patient outcomes associated with a particular protocol 120 (e.g., a given level of compliance with the protocol). The protocol 120 may then be deployed to a production platform 148 at the clinical site.

[0100] It should be apparent that various components of system 100 and subsystem 100B can communicate with each other. The arrows in FIG. 4C are shown as an example of a communication workflow according to an exemplary embodiment. However, some embodiments may not include some components (e.g., data anonymizer 140) and / or may combine some components (e.g., simulator 142 and analyzer 144). As another example, analyzer 144 may be combined with quality reporting module 114.

[0101] System 100 advantageously enables practitioners to rapidly deploy medical protocols in the hopes of achieving successful clinical outcomes. For example, medical practitioners will understand how specific protocols are implementable, how often they require interaction, and what changes need to be made in their practices to improve clinical outcomes.

[0102] 4A-4C schematically illustrate details of system 100 of FIG. 1 configured in accordance with an exemplary embodiment of the present invention. Each of these components is operably connected by any conventional interconnection mechanism. FIGS. 4A-4C simply illustrate a bus communicating with each component. Those skilled in the art should understand that this generalized representation can be modified to include other conventional direct or indirect connections. Thus, the description of a bus is not intended to limit various embodiments.

[0103] Indeed, it should be noted that Figures 4A-4C only illustrate each of these components diagrammatically. Those skilled in the art should understand that each of these components may be implemented in various conventional manners, such as by using hardware, software, or a combination of hardware and software across one or more other functional components. For example, simulator 142 (described in detail below) may be implemented using multiple microprocessors executing firmware. As another example, compiler 146 may be implemented using one or more application-specific integrated circuits (i.e., "ASICs") and associated software, or a combination of ASICs, discrete electronic components (e.g., integrated circuits), and microprocessors. Thus, the representation of simulator 144 and other components within a single box in Figures 4A-4C is merely for simplicity. Indeed, in some embodiments, simulator 144 in Figures 4A-4C is distributed across multiple different components, not necessarily within the same housing or chassis.

[0104] It should be reiterated that the representations of Figures 4A-4C are highly simplified representations of system 100. Those skilled in the art should understand that such devices have other physical and / or functional components, such as a central processing unit, other packet processing modules, and short-term memory. Thus, this description is not intended to suggest that Figures 4A-4C represent all elements of system 100. Indeed, much of what has been described with respect to Figures 4A-4C can also be applied to the components of system 100 of Figure 1.

[0105] FIG. 5 illustrates a process 500 for simulating a clinical protocol 120, according to an exemplary embodiment of the present invention. Note that this method is substantially simplified from a longer process that may typically be used. Thus, the method illustrated in FIG. 5 may have many other steps that one skilled in the art would likely use. Additionally, some of the steps may be performed in a different order than shown, or simultaneously (e.g., steps 502 and 504). Furthermore, in some embodiments, some of these steps may be optional. Thus, process 500 is merely illustrative of one process according to an exemplary embodiment of the present invention. Accordingly, one skilled in the art may modify the process as appropriate.

[0106] Process 500 begins at step 502, which receives a clinical protocol 120. As previously described, the clinical protocol 120 may be a protocol stored in the database 105 and / or received from the graphics compiler 146. In some embodiments, more than one clinical protocol 120 may be received by the simulator 142 at one time. The received clinical protocol 120 may be similar to the protocol 120 shown in FIG. 2. Among other things, the clinical protocol 120 may include eligibility rules 122, compliance rules 124, protocol triggers 126, subscription rules 128, and / or notification rules 130. Each rule and / or trigger may have one or more conditions. The protocol 120 may include one or more eligibility criteria 115, compliance criteria 115, trigger criteria 115, subscription criteria 115, and notification criteria 130.

[0107] The process then proceeds to step 504, where the simulator 142 receives the patient data. The received patient data may be stored in the database 105. In various embodiments, the patient data is actual, historical patient data from the same clinical site (e.g., the same unit in the same hospital). The user can select the time frame from which the data is pulled. For example, data may be used from the past six months, the past 12 months, or for a specific window (e.g., from date X to date Y). For example, patient data may be selected over a specific time window. One skilled in the art can filter the patient data on a demographic basis (e.g., age, sex, race, weight), health status (e.g., the patient has heart disease, the patient has COVID, the patient recently underwent surgery), and / or event basis (e.g., from the onset of COVID to the release of a vaccine, etc.). One skilled in the art can filter the patient data to simulate the operation of the clinical protocol 120 for a desired patient population. Thus, the received patient data may relate to specific parameters collected over a period of time from one or more sensors and / or medical devices. In some embodiments, the data may include live data collected in real time as well as data from the database 105 and / or EHR 103.

[0108] In step 506, the process 500 simulates the clinical protocol 120 using the received patient data. The simulator 142 can compare any of the details of the protocol 120 with the patient data. As an example, the simulator 142 can compare the compliance rules 124 of the received protocol 120 with patient data over the past 12 months. Additionally or alternatively, the simulator 142 can compare the eligibility rules 122 of the protocol 120 with patient data for a particular type of patient (e.g., patients with cardiac disease). The simulator 142 can simulate all aspects of the protocol 120, including simulating notification conditions as well as configured reporting conditions. As described further below, various reporting conditions may be simulated, such as conditions represented by graphical objects 150 in the adoption, adherence, impact, and / or likelihood submenus. The simulator 142 can pass results to the analyzer 144 to analyze performance metrics of the simulated protocol 120.

[0109] In step 508, performance metrics of the simulated protocol are analyzed. To that end, simulator 142 communicates with analyzer 144. Analyzer 144 is configured to provide desired performance metrics of simulated protocol 120 for patient data. Analyzer 144 obtains the results of the simulation and provides them to medical personnel / administrative staff in an easily digestible manner. For example, simulator 142 may determine that a first population of patients from the patient data is 100% compliant with the protocol and that a second population of patients from the patient data is 50% compliant with the protocol. Preferably, the first and second populations are pre-selected to be demographically similar (e.g., age, medical condition, etc.) or have some common medical history (e.g., patients in the same oncology ward). Analyzer 144 may indicate that the first population of patients stayed in the ICU for two days and that the second population stayed in the ICU for five days. In this manner, medical personnel can determine that patients 101 with high compliance have reduced ICU stays compared to patients 101 with low compliance.

[0110] To that end, the analyzer 144 may include an event detector 149 configured to detect various patient events by automatically analyzing data received from the sensor / medical device interface 106 and / or protocol simulator 142. The event detector 149 may include a function library having one or more functions configured to analyze the data and determine the events (as described further below).

[0111] Thus, healthcare professionals can choose to adjust hospital procedures or direct hospital resources toward 100% patient compliance, thereby providing a target outcome based on past patient performance. In the example above, the target outcome is to reduce the average length of ICU stay by three days when converting low-compliance patients to high-compliance patients. At a minimum, the exemplary embodiment highlights the potential for improvement based on adherence to protocols.

[0112] The simulator 142 can also indicate how often active notifications will be sent (e.g., to respiratory therapists or nurses) according to various conditions 115 of the subscription rules 128. In various use cases, it may be beneficial to have the protocol 120 send two to five notifications per day instead of thousands. In various embodiments, the simulator 142 simulates all aspects of how the protocol 120 functions at any given time for each of the patients in the database 105. Thus, a medical professional can use the graphical compiler 146 to tune or create new protocols 120.

[0113] The process then proceeds to step 510, which asks whether the performance of the protocol 120 is acceptable. For example, if high compliance leads to beneficial clinical outcomes, the performance of the protocol 120 may be acceptable. As yet another example, if the number of notifications sent to medical staff is below a certain threshold number, the performance of the protocol 120 may be unacceptable. Conversely, if high compliance does not lead to beneficial clinical outcomes and / or if the number of notifications is too high, the performance of the protocol 120 may be unacceptable. What qualifies as acceptable protocol 120 performance may vary from medical practice to medical practice.

[0114] If the performance of the protocol 120 is unacceptable, the process proceeds to step 512, which modifies the clinical protocol 120. For example, the simulator 142 may simulate a second given protocol 120. The analyzer 144 may determine that a first population of patients had 100% compliance with the protocol 120 and that a second population of patients had 50% compliance with the protocol 120. The analyzer 144 may indicate that the first population of patients remained in the ICU for three days and that the second population remained in the ICU for three days. In this manner, the medical professional may determine that a difference in compliance with the protocol 120 (e.g., at least 50% to 100%) does not beneficially affect clinical outcomes. Thus, the medical professional may deem the protocol performance unacceptable and may choose to proceed to step 512, which adjusts the second given protocol 120 and / or creates a new protocol 120 (e.g., using the graphics compiler 146). Steps 502-510 are then repeated. In step 502, it should be apparent that the received clinical protocol is a new protocol. In step 504, the patient data may be the same patient data previously received. Thus, in some embodiments, the process may be indicated to proceed immediately to step 506.

[0115] If the protocol is acceptable at step 510, the process proceeds to step 514, which deploys the protocol. Once the protocol 120 is deployed, it is applied to actual patients in real time (e.g., on-site at a medical facility using the system 100). The various sensors 102 and medical devices 104 track relevant patient data and provide feedback regarding eligibility. Thus, the system 100 can begin tracking patient eligibility and / or compliance with the deployed clinical protocol 120. The process then ends.

[0116] It should be apparent that the above-described process provides several advantages. As previously described, protocols 120 may be hospital-specific or unit-specific, for example. Thus, the exemplary embodiments advantageously allow for customization of protocols 120 based on unit (e.g., cardiac ICU, general ICU) and / or specific patient demographics. The exemplary embodiments advantageously allow medical personnel to easily create, test, modify, and deploy new clinical protocols.

[0117] FIG. 6 illustrates a process for generating a clinical protocol using graphics compiler 142, according to an exemplary embodiment of the present invention. Note that this method is substantially simplified from a longer process that may typically be used. Thus, the method illustrated in FIG. 6 may have many other steps that one skilled in the art would likely use. Furthermore, some of the steps may be performed in a different order than shown or simultaneously. Furthermore, in some embodiments, some of these steps may be optional. Thus, process 600 is merely illustrative of one process according to an exemplary embodiment of the present invention. Accordingly, one skilled in the art may modify the process as appropriate.

[0118] Process 600 begins at step 602, which configures eligibility rules 122. Eligibility conditions 155 may come in various types and may include specific parameters. To that end, the graphical compiler 146 may provide a configuration user interface 112 pre-populated with various selectable graphical condition objects 150. The user interface 112 may be provided on a touchscreen display (e.g., of a hospital monitor, mobile device, smartphone, etc.), among other things.

[0119] 7 is a schematic illustration of a user interface 112 of a graphical compiler 142, according to an exemplary embodiment of the present invention. The user interface 112 has options for setting all of the various conditions associated with a protocol 120. In the particular view of FIG. 7, the interface 112 shown is for selecting eligibility conditions 115.

[0120] To reach the Eligibility menu, a user can select Eligibility button 172 in main menu 171. Submenu 173 displays items associated with the selected menu item (e.g., Conditions, Views, and Exceptions items). The "Conditions" item 174 is selected in submenu 173 shown in FIG. 7.

[0121] In this figure, to configure the qualifying conditions 115, a user can select one or more graphical objects 150 to define one or more conditions 115 from a condition library 151. Among other things, the graphical objects 150 can be rate-based objects 150, measurement-based objects 150, event-based objects 150, and / or parent-based objects 150. Various combinations of objects 150 may be used to select the qualifying conditions 115 for the protocol 120. For example, as shown in FIG. 7 , the qualifying conditions 115 for the protocol 120 may include the patient 101 being placed on a ventilator (an event-based object) and the patient's 101 heart rate being greater than 100 (a measurement-based object). In this manner, a user can select the event-based objects 150 and the measurement-based objects 150 and populate the simultaneously displayed sequence window 152 with the objects 150. The sequence window 152 shows all selected graphical objects 160 for the qualifying rule 122. The selected graphical objects 150 become the qualifying conditions 115 for the qualifying rule 122. Thus, after the protocol 120 is deployed, if the patient 101 meets the eligibility criteria set within the sequence window 152, the patient 101 becomes eligible for the protocol 120.

[0122] As shown, the selected graphical object 150 may include logical operators 175 that allow for further customization of the rule. For example, in various embodiments, the logical operators may include "and," "or," "and / or," "not," etc. In FIG. 7, the logical operator is the "and" operator. Additionally, each graphical object 150 may include its own additional input values ​​to help define the condition. In various embodiments, the additional input values ​​(e.g., patient on ventilator, HR>100) may be entered directly into the sequence window 152 (e.g., in the parameter window 154 shown in FIG. 8).

[0123] FIG. 8 schematically illustrates the user interface of FIG. 7 for modifying conditions of a protocol 120 using a graphical compiler 146. As illustrated, a user can select a condition object 150 from a condition library 151 and move the object 150 (e.g., drag and drop the object 150) at 153 into a sequence window 152. This allows the user to create or adjust the protocol 120. For example, FIG. 8 shows a user adding a rate-based condition 150 using the compiler 146. In the example of FIG. 8, the eligibility rules for the protocol now include a first condition 115 that the patient is placed on a ventilator (selected event-based object 160A), and a second condition 115 that the patient's heart rate is above 100 (selected measurement-based object 160B) or a third condition 115 that the patient's lactase increases by 2 mmol / L per hour (selected rate-based object 160C).

[0124] After selecting a graphical object 150 from the library 151, the graphical object moves into the protocol sequence window 152 and becomes the selected graphical object 160. In various embodiments, the selected graphical object 160 may be configured to receive specific parameters or requirements based on the type of selected graphical object 160. To that end, a parameter window 154 may appear as an overlay or adjacent to the corresponding graphical object 160. The parameter window 154 receives input from the user regarding the conditions 115. Based on the type of selected object 160, the window 154 may be pre-populated with specific parameter requirements. For example, the parameter window 154 for the rate-based graphical object 160C may have input for what to measure, the time to measure, and any limitations over that time period. In the example of FIG. 8, the user inputs into the parameter window 154 that the lactate rate be greater than 2 mmol / L per hour. Thus, as shown in FIG. 9, the qualifying conditions 115 are set for the protocol 120 using the user interface of the graphical compiler 146.

[0125] The process then proceeds to step 604, which sets the visualization associated with the eligibility. The visualization is what the active interface 112 shows to the healthcare professional when the patient 101 is eligible. FIG. 10 schematically illustrates a configuration interface 112 for selecting a display visualization for the active interface 112, according to an exemplary embodiment. The visualization for eligibility may differ from the conditions. However, in various embodiments, the eligibility display object 150 may be selected to match the eligibility conditions 115.

[0126] In various embodiments, a user selects a “View” submenu item 176 to access the display interface 112. The display interface 112 shows a plurality of selectable graphical display objects 150. While FIG. 10 shows six options, it should be understood that various embodiments may provide more or fewer options. Preferably, the pre-fill library 151 includes a list of display objects 150 corresponding to the selected eligibility conditions 115. The user can select one or more of the various objects 150. As shown in the example of FIG. 10, the user has selected display objects 160 for Fio2, IVCO2, and IDO2. The selected display objects 160 are populated into the selected display objects window 152, and the user can remove the objects (e.g., by pressing an “X” icon in the corner or by swiping the selected display object off the screen).

[0127] Figure 11 shows a schematic example of a user interface 112 displaying the selected display parameters 160 of Figure 10. As shown, from the census overview, selecting a given eligible protocol displays 220 the display variables 160 selected from the object window 152. Additionally or alternatively, a more detailed view may be provided of parameters collected over time (as shown in Figure 14).

[0128] Returning to the process of FIG. 6 , in step 606, compliance conditions for the protocol 120 are set. FIG. 12 schematically illustrates the generation of compliance rules 124 using the user interface 112 of the graphical compiler 146, according to an exemplary embodiment of the present invention. The interface of FIG. 12 operates similarly to the interfaces shown in FIGS. 7-9 . Thus, step 606 operates similarly to step 602, except that the selected conditions 115 correspond to compliance conditions 115 of the protocol 120, as opposed to eligibility conditions 115. The user selects desired compliance condition objects from a plurality of graphical compliance objects 158. Once the objects 158 are selected, they are populated in the selected compliance condition window 152. The various conditions include parameter settings, such as lower and upper limits (e.g., 50 bpm and 120 bpm), that can be entered by the user. The parameter window 154 may be integrated with (or adjacent to, as shown in FIG. 8 ) the selected graphical compliance object 160.

[0129] After the compliance conditions 115 are set, the process proceeds to step 608, which sets compliance visualization for the active interface 112 after the protocol 120 has started, also referred to as user compliance visualization. Similar to step 604, the user selects one or more parameters to be displayed while the protocol is in progress. The user can select parameters of the same type as the compliance conditions and / or different parameters.

[0130] 13 schematically illustrates a configuration interface 112 for selecting a display visualization for the active interface 112, according to an example embodiment. The visualization for compliance may differ from the condition. However, in various embodiments, the compliance display object 150 may be selected to match the compliance condition 115.

[0131] In various embodiments, a user selects a “View” submenu item to access the display interface 112. The display interface 112 shows a plurality of selectable graphical display objects 150. While FIG. 13 shows eight options, it should be understood that various embodiments may provide more or fewer options. Preferably, a pre-filled library 151 includes a list of display objects 150 corresponding to the selected compliance condition 115. The user can select one or more of the various objects 150. As shown in the example of FIG. 13, the user has selected display objects 160 for RR, SpO2, FiO2, and HR. The selected display objects 160 are populated into the selected display objects window 152. The user can remove objects (e.g., by pressing an “X” icon in the corner or by swiping the selected display object off the screen) if they are no longer desired as part of the visualization.

[0132] 14 schematically illustrates the user interface 112 with the selected compliance visualizations from FIG. 13. This user interface is viewable by a healthcare professional reviewing a given patient following the generated protocol. As shown, the display automatically populates with the various selected visualizations (e.g., RR, SpO2, FiO2, and HR) selected in step 608.

[0133] Additionally, the user interface 112 may have a variety of additional features. For example, the user interface 112 may display a start protocol indicia 899 indicating the start time of the protocol for the displayed data. Similarly, exemplary embodiments may display an end protocol indicia 900 indicating the end time of the protocol for the displayed data. The user interface 112 may include a user-selectable marker 901 adjacent to the start protocol indicia 899. Additionally, the user interface 112 may be configured to indicate periods of non-compliance 140 (e.g., represented by a shaded area in the patient data).

[0134] In step 610, the process sets notification conditions. To do so, a user can configure notification rules 130 within the interface 112. FIGS. 15-17 schematically illustrate the user interface 112 for configuring notification rules 130, according to an exemplary embodiment. From the user interface 112, the user selects the "Notification" menu item. The type of notification may be set. The notification may include details regarding the type of notification (e.g., event-based, parameter-based, etc.) and the amount of time from the trigger of the notification (e.g., immediately, one hour, etc.). For example, the user may select to provide a notification when the patient has been protocol-eligible for one hour. Of course, the notification may be associated with any of the rules for the various conditions 115 or protocols 120.

[0135] Recipients to receive the notifications may also be selected, as shown in FIG. 16. In various embodiments, the relevant healthcare professionals may be pre-populated in the recipient field. For example, a respiratory therapist may be selected to be notified when the patient is eligible for an hour. Multiple notifications may be configured, as shown in FIG. 17. Additionally, various embodiments may choose to make one or more of the notifications BPA (e.g., by sending notifications and / or notification requirements to the EHR 103 via the FIHR interface 107).

[0136] In step 612, process 600 sets reporting conditions for reports generated by quality reporting module 114 (e.g., based on real-time data or data from simulator 142). Notification conditions are intended to keep medical personnel updated in real time regarding patient-specific actionable insights, while reporting conditions are intended to provide actionable insights to clinical sites (e.g., for an entire hospital unit). In other words, reporting conditions report on medical staff performance against protocols 120. For example, reporting conditions might include the average time it takes for medical staff to initiate a course of treatment from the time a patient is eligible for the course of treatment. Additionally or alternatively, reporting conditions might include clinical protocol conflicts or other related procedure items, treatments, and / or courses of treatment associated with the completion of a given clinical outcome (e.g., a parameter at a particular value, a change in patient condition, etc.).

[0137] 18-22 generally illustrate the generation of reporting requirements using a graphical compiler user interface according to exemplary embodiments of the present invention. In various embodiments, the reporting module 114 includes a reporting submenu 177. In this embodiment, the reporting submenu 177 includes reports on "adoption," "compliance," "impact," and "likelihood." The reporting submenu 177 may include additional or fewer menu items. The user interface 112 is not limiting of various embodiments.

[0138] FIG. 18 schematically illustrates a configuration user interface 112 for the reporting module 114, according to an exemplary embodiment. As previously described, the active user interface 112 presented to a healthcare professional when tracking a patient may have several different views (e.g., a census view (shown in FIG. 3), a protocol view (shown in FIG. 14), etc.) that the healthcare professional can alternate between. An exemplary embodiment may track the frequency and / or number of times that the healthcare professional interacts with individual protocols (e.g., clicking an eligibility flag to go to the main screen, changing protocol parameters, etc.). Thus, an exemplary embodiment may track user selections (e.g., touchscreen selections, mouse inputs, etc.), among other things.

[0139] 18 shows schematically two selected graphical objects 160. In this example, the reporting condition being tracked is "all" interactions (i.e., the total number of clicks in the interface). The user then selects the "Click to see compliance" graphical object 150, which has been added as a reporting condition in the sequence window 152. FIG. 19 shows schematically the configuration user interface 112 of FIG. 18 after selection of the "Click to see compliance" graphical object 150. In this example, the graphical objects suggest displaying the report as a long-term chart or histogram.

[0140] In step 613, the process generates a report. FIG. 20 schematically illustrates a report generated based on the selections of FIGS. 18-19. The report may be viewed (e.g., by a hospital administrator) in reporting interface 112B. For clarity, reporting interface 112B may, but is not necessarily, part of the same interface as active interface 112A and / or configuration interface 112. Furthermore, reporting interface 112B may, but is not necessarily, viewed on the same device as active interface 112A and / or configuration interface 112. For simplicity, the three interfaces are described herein as being part of the same interface 112 (e.g., on the same display device). However, in various embodiments, these interfaces 112A, 112B, and 112B may be separate (e.g., viewed on different displays by different users).

[0141] As shown, the report shows the number of “all interactions” as well as the number of “clicks to see compliance.” In this way, the report provides insight into how healthcare professionals interact with the active user interface 112.

[0142] FIG. 21 schematically illustrates generating reporting criteria (e.g., step 612) using a graphical compiler user interface, according to an exemplary embodiment of the present invention. FIG. 21 is similar to FIG. 18, except that the "Adherence" button is selected under the Reports submenu option. As shown, switching to a different submenu item changes the interface 112. In particular, the selectable graphical objects 150 change. In this case, several graphical objects related to a healthcare professional's adherence to protocols are populated. For example, a user may select to track and display "time from eligible to protocol start" in a report. As another example, a user may select "average patient compliance" (e.g., 80%).

[0143] Some embodiments may include a large list of selectable graphical objects 150. However, some embodiments may use submenus to assist in easy identification and management of related selectable graphical objects. Various embodiments may include an "Adherence" submenu item. The adherence selectable graphical objects relate to reporting on the performance of the healthcare professional / user (as opposed to the patient). For example, the adherence selectable graphical objects 150 may include an option such as the average monthly wait time from when a patient becomes eligible to when they begin the course of treatment for a protocol. This is a metric for the healthcare staff because patients do not control when they are placed in the course of treatment after becoming eligible.

[0144] As an example, if medical staff strictly adhere to a protocol, each time a patient is flagged as eligible (e.g., in the case of an ERT protocol), the medical staff immediately initiates a course of action (e.g., switching the ventilator mode to see how well the patient is breathing). Adherence allows system 100 to track statistics such as the average time between a patient being flagged and actually starting a course of action (i.e., the patient starting the protocol).

[0145] In some embodiments, adherence may be measured over time. For example, system 100 may measure how many minutes it takes for medical staff to place a patient on a protocol. Advantageously, the total time that elapses between a patient being eligible and the patient being placed on a course of treatment may be used to help direct resources and / or training. For example, if it takes an average of six hours for medical staff to place a patient on a protocol, the patient may be suffering from kidney damage, nerve injury, or the like. Thus, hospitals may track metrics that can be used to measure adherence to protocols from the perspective of medical staff. Thus, hospitals may track metrics that can be used to measure adherence to protocols from the perspective of medical staff.

[0146] 22 schematically illustrates another example of a report (step 613) generated based on selections in the compliance sub-menu interface. The report may be viewed (e.g., by a hospital administrator) in a reporting interface 112B.

[0147] FIG. 23A schematically illustrates another example of setting report conditions (step 612) using the graphical compiler's user interface, according to an exemplary embodiment of the present invention. FIG. 23A is similar to FIGS. 18 and 21, except that the "Impact" button has been selected under the Report submenu. As illustrated, selecting a different submenu item changes the interface 112. In particular, the selectable graphical objects 150 change. In this case, several graphical objects related to protocol impact are populated. For example, a user may select to track and display "Time from Eligibility to Protocol Start" in the report. As another example, a user may select "Average Patient Compliance" (e.g., 80%). FIG. 23B illustrates the interface of FIG. 23A after a user has selected a graphical object. The four selected graphical objects 160A-160D are populated in the sequence window 152.

[0148] In various embodiments, the user can select a particular patient outcome (e.g., ICU length of stay, ventilation hours, mortality, extubation failure rate, etc.). The selected outcome is shown longitudinally over a selected time frame; for example, ventilation hours per month. Advantageously, this allows the hospital to see whether medical staff are correctly adopting policies and the impact of that adherence.

[0149] Selectable graphical objects under the Impact tab may relate to specific patient outcomes (e.g., ICU length of stay, ventilation time, mortality, extubation failure rate, etc.). These graphical objects are used to provide reports showing specific outcomes over time (e.g., month to month). For example, ventilation time is shown monthly. Advantageously, these metrics enable hospitals to see if medical staff are correctly adopting protocol policies and what the impact is.

[0150] 24 schematically illustrates another example of a report generated based on selected graphical objects 160A-160D from FIG. 23B. The report may be viewed (e.g., by a hospital administrator) within reporting interface 112B. As shown, patient length of stay 170A, number of failed extubations 170B, duration of mechanical ventilation 170C, and number of ICU readmissions 170D are displayed in the report as selected by the user within configuration interface 112C.

[0151] FIG. 25 schematically illustrates a user interface of a graphical compiler, according to an exemplary embodiment of the present invention. FIG. 25 is similar to FIG. 18, except that the "Probability" button is selected under the Reports submenu option. As illustrated, switching to a different submenu item changes the interface 112. In particular, the selectable graphical objects 150 change. In this case, several graphical objects related to potential outcomes for the protocol are populated. For example, a user may select to track and display "Extubation Failure Rate" in a report. As another example, a user may select "Ventilation Time" (e.g., 3 days, 15 hours, 20 seconds).

[0152] Some embodiments may include a large list of selectable graphical objects 150. However, some embodiments may use submenus to assist in easy identification and management of relevant selectable graphical objects. Various embodiments may include a "Potential" submenu item. Potential selectable graphical objects 150 relate to reports related to whether a protocol has the potential to improve patient outcomes. Potential reports (e.g., shown in FIGS. 26A-26B) show differences in outcomes when adherence rates for patients differ.

[0153] FIG. 26A schematically illustrates an extubation failure rate report for a first protocol, according to an exemplary embodiment. The extubation failure rate is mapped according to patient adherence quartiles (i.e., 0%-25% adherence, 26%-50% adherence, 51%-75% adherence, and 76%-100% adherence). As shown in FIG. 26A, there appears to be little to no correlation between patient adherence to the protocol and the extubation failure rate. Therefore, these results indicate to medical personnel that the current adherence conditions for the protocol are not likely to positively impact the extubation failure rate. Therefore, the process can proceed to step 614, where the adherence conditions may be adjusted.

[0154] FIG. 26B schematically illustrates an extubation failure rate report for a second protocol, according to an exemplary embodiment. The second protocol may be a slightly modified version of the first protocol. For example, certain compliance parameters may be adjusted, added, and / or removed. By viewing the extubation failure rate by compliance level, the potential of the protocol becomes very clear. There is a nearly linear relationship between the extubation failure rate and the compliance level. Thus, hospital staff know that adherence to this protocol will result in desirable clinical outcomes. Therefore, hospital staff can prioritize maximizing patients' compliance with the protocol, as the patient's likelihood of clinical success with the protocol is easily visualized.

[0155] In various embodiments, a theoretically ideal protocol should have the most positive clinical outcomes (e.g., lowest extubation failure rate) for the most compliant patients. The report shows medical personnel that adherence to the protocol used in FIG. 26B makes a significant difference. Importantly for medical staff, the report shows that the current medical protocol used in FIG. 26A does not positively impact patient outcomes. Thus, medical staff have actionable insights that can be used to determine (or adjust) an appropriate protocol. Thus, exemplary embodiments provide actionable insights by measuring likelihood.

[0156] The reporting conditions may also include interventions that occur when a patient is non-compliant. For example, Figures 27-28 schematically illustrate a user interface 112 for configuring a report, according to an exemplary embodiment.

[0157] The reports generated by the system 100 provide actionable insights and objective analysis of medical staff performance with respect to eligibility and compliance criteria. For example, among other things, the quality reporting module 114 tracks the time elapsed since a patient became eligible until a user confirms the patient's eligibility (e.g., a medical professional interacts with a notification). Alternatively or additionally, the quality reporting module 114 may track the time elapsed since a patient became eligible until a medical professional begins the course of treatment associated with the protocol for which the patient 101 is eligible. Alternatively or additionally, the time elapsed from non-compliance to the associated patient intervention may be tracked. By tracking this information, medical professional performance may be objectively measured (e.g., which medical professionals are the quickest responders and what is the impact of response time on the patient's 101 clinical outcome for a given protocol).

[0158] General reporting protocols may be set up via the configuration interface 112. Additionally, specific interventions may be established via the reporting interface. Thus, the graphic compiler 146 allows a healthcare professional to set anticipated interventions for the healthcare professional when a patient is non-compliant. Figure 27 schematically illustrates the configuration interface 112 for creating reports associated with a protocol 120.

[0159] A user can generate a decision tree using methods similar to those described above. An object library 151 (e.g., a measurement library and / or an intervention library) is pre-populated with multiple graphical objects. Selecting graphical objects 150 moves them into a selected object window 152.

[0160] The interface 112 also allows the user to build decision trees for reporting. For example, when a patient is non-compliant and CVP>10, the intervention is to give fluids. The reporting module can track how long it takes from non-compliant CVP>10 until fluids are provided.

[0161] 28 shows a schematic example of a user constructing a decision tree. In the same decision tree as FIG. 27, if CVP>10 but MAP>60, the intervention is red blood cell transfusion. However, if MAP>60, the user may indicate that the intervention is to provide a vasopressor to the patient. Thus, the quality reporting module 114 can track reports as outlined by the user.

[0162] The quality reporting module 114 examines the established protocol rules and provides some statistical data. For example, what is the average time between a patient becoming non-compliant and applying any of the possible interventions? Additionally, the reporting module 114 can work with the simulator to determine the percentage of time an intervention is the correct intervention (e.g., a net positive outcome based on historical data). Thus, the reporting module is advantageous not only from a simulation perspective but also during deployment. Based on the reporting configuration set using the compiler 146, the reporting module 114 informs the user how well the clinician is performing this particular protocol.

[0163] The report may be configured to provide several different statistical data, such as the mean time and histogram of time between patient non-compliance and any possible interventions, the percentage of desired interventions applied, and the success rate of the intervention in bringing the patient into compliance.

[0164] The quality reporting module 114 can track dynamic match rates as the percentage of time the patient 101 is compliant with medical protocols. The quality reporting module 114 can also track patient eligibility times. Additionally, the quality reporting module 114 can retrospectively examine patient match rates and / or eligibility times to see how well a particular patient and / or a particular healthcare professional's patients performed compared to the patient population. Additionally, the reporting module 114 may be configured to display received patient data and highlight non-compliant portions of the received data. Thus, the quality reporting module 114 allows healthcare facilities and / or staff to retrospectively assess how well a patient was managed. For example, if eligibility times are very high, healthcare professionals will become aware of this. This can aid in hospital policy formation and help ensure prompt treatment by healthcare staff.

[0165] In an exemplary embodiment, the quality reporting module 114 tracks the time when the patient 101 becomes eligible for the protocol 120 and the duration from the time of eligibility to a predetermined event. The predetermined event may be, for example, when a medical professional qualifies the patient (e.g., a pop-up notification on a touchscreen display via the user interface 112) or when a course of action for an eligible protocol is initiated.

[0166] An exemplary embodiment can provide periodic reports to assist healthcare professionals in understanding compliance across the institution.

[0167] Returning to FIG. 6 , the process proceeds to step 614, which asks whether the protocol should be adjusted. For example, if a simulation is run and the quality reporting module 114 indicates that clinician performance is substandard, that patient outcomes for highly compliant patients are not beneficial, or that the protocol results in too many notifications (e.g., alert fatigue), the process can return to any and / or all of steps 602-612, and the protocol may be adjusted. This process may be repeated in real time by the healthcare professional as many times as desired. If the protocol does not need to be adjusted, the process proceeds to step 616, where the protocol is edited and deployed to the system. The process then ends.

[0168] It should be apparent to one skilled in the art that the process of Figure 6 may be incorporated into the process of Figure 5. In particular, process 600 shows a detailed view of the steps for generating a protocol received in step 502. Thus, a protocol generated using the process of Figure 6 may be used in the process outlined in Figure 5. Additionally, in step 512, the graphical editing methods described above with respect to process 600 may be used to modify the protocol or create a new protocol.

[0169] It should further be understood that various steps may be modified or omitted in exemplary embodiments. For example, some embodiments may skip step 612 and may not include reporting conditions associated with protocols. In some embodiments, reporting conditions may be associated with one or more protocols.

[0170] Furthermore, in some embodiments, the step of deploying the protocol 616, which may be performed additionally or alternatively, comes at the beginning of the process. For example, the method 600 of FIG. 6 may be used to modify and / or analyze a previously deployed protocol.

[0171] In various embodiments, the reporting module 114 is in communication with an analyzer 144. The analyzer 144 is configured to analyze patient data and extract outcomes from the data to aid in reporting. The outcomes may include, among other things, length of ICU stay, time on mechanical ventilation, etc. To that end, the analyzer 144 includes an event detector 149 configured to scour the data from the sensors 102 and medical devices 104 and automatically determine these outcomes without requiring manual input from medical staff. However, in some embodiments, the database 105 may provide the outcomes directly, or the outcomes may be extracted as a secondary interaction with the patient database 105.

[0172] 29-32 show schematic diagrams of data collection that may be used by analyzer 144 to automatically determine clinical events and / or outcomes.

[0173] FIG. 29 schematically illustrates a view of the protocol interface 112, according to an exemplary embodiment. The analyzer 144 is configured to detect, among other things, when a patient is extubated and intubated. FIG. 29 also schematically illustrates ventilator data. The ventilator data (bottom diagram) shows collected ventilator data and then stops collection. The analyzer 144 is configured to determine the ventilator mode from the patient data (including ventilator data). In this example, the data line (i.e., the blue line) indicates the ventilator mode. At one point (the green arrow labeled "Extubate"), the blue line shifts to PC NIV, which is a non-invasive ventilation mode. This indicates that the ventilator's breathing tube has been removed from the patient. As shown in the figure, the data signal may contain some noise during the subsequent period, but at some point (e.g., identified by the red arrow labeled "Reintubate"), the ventilator data reverts to SIMV mode, an invasive ventilation mode requiring intubation. Above that is pressure support, and when the patient is no longer intubated, the sensor 102 can no longer measure pressure support. When the ventilation mode is switched, the event detector 149 may automatically determine that the patient has been extubated. The data is then later redisplayed and the event detector 149 can determine that the patient has been reintubated.

[0174] Between extubation and reintubation, the ventilator switches from non-invasive mode to null, meaning the ventilator is not running / collecting data. This is a standard data plot that may be obtained from the ventilator. The event detector 149 scours this data and determines that the patient has been extubated.

[0175] As shown below, the event detector 149 may be configured to detect various clinically significant events (e.g., when a patient develops acute kidney injury due to the fact that their creatinine spikes, when a patient is in cardiac arrest due to a progression of their heart rate, etc.). An exemplary embodiment uses machine learning / pattern recognition to extract outcomes / events from patient data. These outcomes / events may then be used as conditions 115 in any of the rules.

[0176] 30 schematically illustrates a view of the protocol interface 112, according to an exemplary embodiment. The event detector 149 can, among other things, automatically detect acute kidney injury (AKI). For patients with normal creatinine levels upon ICU admission (e.g., adult males: 0.74-1.35 mg / dL, adult females: 0.59-1.04 mg / dL), AKI is defined as the first increase in creatinine of 0.3 mg / dL or more within 48 hours of their ICU stay.

[0177] The event detector 149 analyzes the data and determines that the patient's initial creatinine level after ICU admission is normal. The event detector 149 then determines that creatinine increased by 3 mg / dL or more within 48 hours of their ICU stay, and that this is the first time this increase has occurred. The analyzer 144 can evaluate the patient data for the current creatinine lab result minus the minimum previous creatinine level to determine that the patient's creatinine has increased by 0.3 mg / dL or more. Thus, the event detector 149 determines the time when the current creatinine lab is considered the time of an event (e.g., AKI) and / or that the patient has a particular condition / outcome (e.g., AKI). Thus, the event detector 149 determines the event, condition, and / or outcome from the patient data, as well as the onset, duration, and / or end time.

[0178] 31 schematically illustrates a view of the protocol interface 112, according to an exemplary embodiment. The data in this example is used by the event detector 149 to determine when a patient has cardiac arrest. Cardiac arrest can have various characteristics in the patient's vitals, but most commonly represents the following: 1. A sudden drop in heart rate followed by large fluctuations 2. Lowering blood pressure and narrowing the gap between systolic and diastolic blood pressure 3. Decreased and / or lost peripheral oxygen saturation (SpO2).

[0179] By analyzing the data and looking for these particular features, the event detector 149 can determine when the patient has undergone cardiac arrest. The three conditions that the event detector 149 looks for are labeled in Figure 31. In response, the event detector 149 determines that the patient has undergone cardiac arrest and the time at which the cardiac arrest occurred.

[0180] 32 schematically illustrates a view of the protocol interface 112, according to an exemplary embodiment. In this example, the event detector 149 is configured to, among other things, detect when a patient experiences vasoactive drug withdrawal. Vasoactive drug withdrawal is defined as the complete cessation of infusion of all six vasoactive drugs. Dopamine Dobutamine Milrinone Epinephrine Norepinephrine Vasopressin

[0181] As shown, event detector 149 is configured to detect vasoactive drug withdrawal from patient data as well as the time when withdrawal began.

[0182] It should be understood that, similar to the other rules and reports described herein, the event detector 149 may be configured to detect various events / conditions / outcomes using a graphical compiler. Additionally or alternatively, the event detector 149 may be pre-configured to detect various events / conditions / outcomes. Furthermore, the results obtained by the event detector 149 may be used as conditions 115 in one or more rules.

[0183] It should be apparent to those skilled in the art that the exemplary embodiments offer several advantages over the state of the art. To begin with, the exemplary embodiments advantageously provide a system for the creation and modification of all aspects of clinical protocols, from eligibility to reporting, using an intuitive graphical object-based interface. Furthermore, the exemplary embodiments provide for simulation of protocols, so that simulated protocol performance (e.g., dynamic patient conformance) may be used as a feedback mechanism to adjust the protocol (e.g., adjusting protocol conditions if simulated patient compliance is good but patient outcomes are poor, adjusting notification conditions if there are too many notifications, etc.). Furthermore, custom reports may be generated to determine medical staff performance (e.g., how quickly medical staff act, whether appropriate interventions are followed, etc.). Thus, the exemplary embodiments advantageously enable a thorough review and rapid revision of medical protocol effectiveness, both from a patient outcome perspective and / or a clinician execution perspective.

[0184] Additionally, various embodiments advantageously provide reports showing overall performance of healthcare professionals / clinical sites. This advantageously allows hospitals and other clinical care sites to analyze metrics of their medical staff. Currently, there are many quality metrics in healthcare. Quality metrics may relate to how hospitals receive reimbursement from insurance companies. Exemplary embodiments allow clinical environments to identify that a particular protocol has been implemented and the compliance rate of medical staff, as well as the actual outcomes of implementing the protocol (e.g., a reduction in extubation failure rate from 15% to 10%).

[0185] Additionally, the reporting module 114 provides specific reports regarding, among other things, adoption and compliance by medical staff, and the impact and potential of the protocol.

[0186] FIG. 33A illustrates a process for creating a best practice alert, according to an exemplary embodiment. Note that this method is substantially simplified from a longer process that may typically be used. Thus, the method illustrated in FIG. 33A may have many other steps that one skilled in the art would likely use. Furthermore, some of the steps may be performed in a different order than shown or simultaneously. Furthermore, in some embodiments, some of these steps may be optional. Thus, the process of FIG. 33A is merely illustrative of one process according to an exemplary embodiment of the present invention. Thus, one skilled in the art may modify the process as appropriate.

[0187] As previously described, system 100 receives patient data for patients following a given protocol. Notification conditions for the protocol are evaluated by system 100, which generates notifications when the conditions are met. These steps have been described in more detail previously and will not be repeated here.

[0188] The notification may be pushed through to the healthcare professional (or interested party) via the electronic health record 103 platform. Thus, the exemplary embodiment may generate a single sign-on link that, when selected, leads to a relevant view (e.g., eligibility view or adherence view) associated with the notification. Additionally, via the FHIR interface 107, the notification with the link may be sent to the EHR 103 as a best practice alert.

[0189] 33B shows a user interface of the electronic health record 103, according to an exemplary embodiment. In this particular example, the patient is eligible for the SBT protocol and provides the healthcare professional with next steps to be performed (e.g., performing a clinical evaluation, etc.). The user interface 112 may be viewed via the EHR 103. For example, the EHR may show a generated single sign-on link that can be selected (in this example, to view a patient census view (e.g., such as in FIG. 11 ) or an eligibility window showing relevant metrics for the eligibility conditions for the particular patient).

[0190] It should be appreciated that accessing the system 100 through the EHR 103 interface provides several advantages. Because healthcare professionals spend a great deal of time in the EHR 103, from the healthcare professional's perspective, integrating the system 100 into the user interface within the EHR 103 (e.g., via single sign-on) is highly efficient. This advantageously increases usage of the system 100 and compliance with the terms of a given protocol.

[0191] FIG. 34 schematically illustrates a process for generating and optimizing a protocol for a newly deployed medical device, according to an exemplary embodiment. Note that this method is substantially simplified from a longer process that may typically be used. Thus, the method illustrated in FIG. 34 may have many other steps that one skilled in the art would likely use. Furthermore, some of the steps may be performed in a different order than shown or simultaneously. Furthermore, in some embodiments, some of these steps may be optional. Thus, the process of FIG. 34 is merely illustrative of one process according to an exemplary embodiment of the present invention. Thus, one skilled in the art may modify the process as appropriate.

[0192] Figure 34 is similar to the process shown in Figure 5 and therefore includes many similar steps that are not repeated in detail again. Advantageously, the process of Figure 34 uses the protocol generation and simulation methods described herein to provide clinically relevant insights into new medical devices.

[0193] When new medical devices become available, it can be difficult to determine which patients will benefit from device use, which patients will benefit most from device use, the specific beneficial parameters and / or dynamic match rates, and / or the best use of the device in conjunction with other available devices and / or data. Various embodiments provide for flagging patients as eligible for use with a particular medical device (e.g., implantation of a heart pump), similar to how patients are flagged as eligible for a particular protocol (e.g., SBT). Additionally, once a new medical device is deployed to a patient for a given protocol, patient compliance can be managed using system 100. Thus, a patient's eligibility to use the new medical device, management, and protocol adherence may be determined and monitored via system 100 and further via EHR 103.

[0194] 34 begins at step 501, which deploys one or more new medical devices at a clinical site. As an example, the new medical device may be a hemodynamic monitoring device used to optimize management of cardiogenic shock. The new hemodynamic monitoring device may measure cardiac index.

[0195] In step 502, a protocol 120 is received. Figure 35 shows a schematic of one example of a protocol 120 using a new device. Of course, this protocol is merely exemplary, and a variety of different protocols may be used. In this example, compliance rules for a particular protocol include a given measurement from the new device (e.g., cardiac index > 2), as well as other measurements from other devices (e.g., mean arterial pressure and IDO2 index).

[0196] In step 504, patient data is received. The patient data may include historical patient data. However, the received patient data here includes data obtained from new equipment (as well as other data described with reference to FIG. 5, for example). Advantageously, system 100 allows a medical professional to determine how to optimally utilize new collected data (e.g., cardiac index) in conjunction with data generated by the system using other collected data (e.g., mean arterial pressure) or other collected information (e.g., IDO2 index from a risk analysis engine). This is accomplished by generating a new protocol to manage the patient in a specific manner.

[0197] In step 505, the protocol 120 is simulated and the patient's dynamic agreement with the protocol is tracked. In some embodiments, "simulating" the protocol first in step 506 may include actively executing the protocol in real time (e.g., in a clinical setting with an actual patient). In step 508, performance metrics of the protocol are analyzed. By tracking dynamic agreement, insights into outcomes using new medical equipment may be gained. For example, analysis of the protocol may indicate that, when used with a new medical device, a dynamic agreement of 95% or greater results in early patient discharge from the hospital. Alternatively, no insights may be derived, and the process may proceed to step 512 of modifying the protocol and then determining patient outcomes for the modified protocol.

[0198] By using patient data to determine patient outcomes on a protocol, it is possible to establish insights that would not otherwise be known. For example, the analyzer may determine that a patient has a desirable clinical outcome when the patient's dynamic agreement on the protocol is greater than 50% over a two-hour period, particularly when the vasoactive inotropy range is greater than 20.

[0199] The process proceeds to step 510, which asks whether the protocol has desirable performance. For example, if a desirable clinical outcome is seen at a given threshold % dynamic agreement, then the protocol performance is desirable. However, if insight or a desirable clinical outcome is not gained from the given threshold % dynamic agreement, the process proceeds to step 512, where the protocol is modified. The newly modified protocol may be simulated using historical data previously collected in step 504. In this manner, multiple different protocols may be simulated, and desirable outcomes may be determined depending on the new medical device being used with the patient.

[0200] The process then proceeds to step 514, which develops a protocol with new insights about the medical device. The new insights may include which patients will benefit from use of the device, which patients will benefit most from use of the device, certain beneficial parameters and / or dynamic match rates, and / or the best use of the device in conjunction with other available devices and / or data. Multiple simulations may be run for multiple protocols using patient data from different patients, and decisions may be made regarding the best clinical outcomes for different patients. Patient demographics, dynamic matches, and protocol rules, among other things, may all be optimized for clinical outcomes using the new medical device. The process then ends.

[0201] Returning to the example shown in FIG. 35, the process of FIG. 34 may be used to determine that it is advisable to place a patient on ECMO management protocol 120B when, for example, there is less than 50% dynamic agreement over two hours for parent protocol 120A in combination with a vasoactive inotropy score of less than 20. In this example, system 100 detects when hemodynamic goals cannot be achieved and flags the patient for escalation to mechanical circulatory support. (The vasoactive inotropy score indicates the amount of support the patient is receiving from medications; the higher the support, the less likely it is that more support will lead to compliance with hemodynamic goals.)

[0202] The simulator allows healthcare professionals to select the correct combination of parameters (dynamic concordance thresholds over specific times and VIS scores) to optimize the following outcomes: Initiating mechanical circulatory support early enough to avoid end-organ damage from hypoperfusion, Avoiding premature initiation of mechanical circulatory support, given that this support is associated with significant morbidity, e.g., bleeding, stroke, etc. Improve overall survival from cardiogenic shock.

[0203] Various embodiments of the present invention may be implemented, at least in part, in any conventional computer programming language. For example, some embodiments may be implemented in a procedural programming language (e.g., "C") or an object-oriented programming language (e.g., "C++"). Other embodiments of the present invention may be implemented as pre-programmed hardware elements (e.g., application-specific integrated circuits, FPGAs, programmable analog circuits, and digital signal processors) or other related components.

[0204] In alternative embodiments, the disclosed apparatus and methods (see, e.g., the various flowcharts described above) may be implemented as a computer program product for use with a computer system. Such an implementation may include a series of computer instructions fixed on any tangible, non-transitory medium, such as a computer-readable medium (e.g., a diskette, CD-ROM, ROM, or fixed disk). The series of computer instructions may embody all or part of the functionality previously described herein with respect to the system.

[0205] Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages ​​for use with many computer architectures or operating systems. Furthermore, such instructions may be stored in any memory device, such as semiconductor, magnetic, optical, or other memory devices, and may be transmitted using any communications technology, such as optical, infrared, microwave, or other transmission technology.

[0206] Among other things, such computer program products may be distributed as removable media with accompanying printed or electronic documentation (e.g., shrink-wrapped software), pre-loaded on a computer system (e.g., on a system ROM or fixed disk), or distributed over a network (e.g., the Internet or World Wide Web) from a server or bulletin board. Indeed, some embodiments may be implemented in a software-as-a-service model ("SAAS") or cloud computing model. Of course, some embodiments of the present invention may be implemented as a combination of both software (e.g., a computer program product) and hardware. Still other embodiments of the present invention are implemented entirely in hardware or entirely in software.

[0207] As used in this specification and claims, the singular forms "a," "an," and "the" refer to plural referents unless the context clearly dictates otherwise. For example, a reference to a singular "rule" includes a plurality of rules, and a reference to a singular "condition" includes one or more conditions and equivalents known to those skilled in the art. Thus, in various embodiments, any reference to the singular includes the plural. Similarly, a reference to more than one component (e.g., one or more, plural) can include the singular.

[0208] Also, with regard to terminology, the exemplary embodiments refer to the protocol as having "rules," such as "eligibility rules" or "compliance rules." Furthermore, the exemplary embodiments refer to each "rule" as having "conditions." Prior applications have referred to "conditions" and "rules" interchangeably (e.g., eligibility rules may be referred to as eligibility conditions). However, for purposes of explanation, the exemplary embodiments generally refer to "rules" having "one or more conditions." Furthermore, both the singular term "rule" and the plural term "rules" refer to one or more conditions. Thus, use of the plural term "rules" (e.g., eligibility rules, compliance rules, subscription rules, notification rules, etc.) is meant to refer to one or more conditions of a rule (e.g., one or more conditions of an eligibility rule) and does not imply that the protocol requires multiple different rules (e.g., multiple different eligibility rules).

[0209] While various embodiments of the present invention have been described and illustrated herein, those skilled in the art will readily envision a variety of other means and / or structures for performing the functions and / or obtaining the results and / or one or more advantages described herein, and each of such variations and / or modifications is deemed to be within the scope of the embodiments of the present invention described herein. More generally, those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be exemplary, and that the actual parameters, dimensions, materials, and / or configurations will depend on the particular application in which the teachings of the present invention are used. Those skilled in the art will recognize, or be able to ascertain using no more than routine experimentation, many equivalents to the specific embodiments of the present invention described herein.

[0210] Accordingly, the foregoing embodiments are presented by way of example only, and it is to be understood that, within the scope of the appended claims and their equivalents, the embodiments of the present disclosure may be practiced otherwise than as specifically described and claimed. Exemplary embodiments of the present disclosure relate to individual features, systems, articles, materials, kits, and / or methods described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods is within the inventive scope of the present disclosure, provided such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent. The disclosed embodiments, or portions thereof, may be combined in ways not listed above and / or not explicitly claimed. Thus, one or more features from the various disclosed examples and embodiments may be combined in various ways.

[0211] Various inventive concepts may be embodied as one or more methods, examples of which are provided. The actions performed as part of a method may be ordered in any suitable manner. Thus, embodiments may be constructed in which actions are performed in an order different from that shown, and may include performing some actions simultaneously even though shown as sequential actions in an example embodiment.

[0212] While the above description discloses various exemplary embodiments of the present invention, it will be apparent to those skilled in the art that various modifications may be made which will achieve some of the advantages of this invention without departing from the true scope of the invention.

Claims

1. 1. A method of backtesting a medical protocol, comprising: receiving eligibility and compliance rules for a medical protocol, each of the rules having one or more conditions; receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data regarding particular parameters collected over a period of time from one or more sensors and / or medical devices; determining that the patient was eligible for the protocol according to the eligibility rules and the collected patient data; determining a historical dynamic conformance rate for the protocol, the historical dynamic conformance rate for the protocol indicating the rate at which the patient data conformed to the compliance rules for the protocol over the period of time; A method comprising:

2. determining patient outcomes as a function of high compliance with said protocol compared to low compliance with said protocol; The method of claim 1 further comprising:

3. adjusting the eligibility or compliance rules for the protocol to define an adjusted protocol; determining a patient outcome as a function of high compliance with the adjusted protocol compared to low compliance with the adjusted protocol; The method of claim 1 further comprising:

4. the collected patient data includes patient data from newly deployed medical devices; adjusting the protocol in response to the patient data from the newly deployed medical device; The method of claim 3.

5. receiving a notification rule associated with the protocol; determining a number of past notifications over the period of time in response to the notification rules; adjusting the notification rules to reduce the number of past notifications; The method of claim 1 further comprising:

6. The method of claim 1 , wherein the protocol eligibility and compliance rules are generated using a graphics compiler.

7. adjusting the eligibility and / or compliance rules of the protocol using the graphical compiler after receiving feedback regarding patient outcomes in response to high compliance with the protocol; and / or adjusting the protocol's eligibility and / or compliance rules using the graphical compiler after receiving feedback regarding the number of notifications generated by the protocol. The method of claim 6 further comprising:

8. 1. A computer program product for use in a computer system for enrolling patients in medical protocols, the computer program product comprising a tangible, non-transitory computer usable medium having computer readable program code thereon, the computer readable program code comprising: program code for receiving eligibility and compliance rules for a medical protocol; program code for receiving collected patient data from a plurality of patients, the collected patient data including longitudinal patient data regarding particular parameters collected over a period of time from one or more sensors and / or medical devices; program code for receiving a determination of when a patient is eligible for the protocol according to the eligibility rules and the collected patient data; program code for receiving a program to determine a historical dynamic conformance rate for the protocol, the historical dynamic conformance rate for the protocol indicating a rate at which the patient data conformed to the compliance rules for the protocol over the period of time; a computer program product,

9. and program code for determining a patient outcome as a function of high compliance with the protocol compared to low compliance with the protocol.

9. The computer program product of claim 8, further comprising:

10. program code for adjusting the eligibility or compliance rules for the protocol to define an adjusted protocol; program code for determining a patient outcome as a function of increased compliance with the protocol compared to decreased compliance with the adjusted protocol; 9. The computer program product of claim 8, further comprising:

11. program code for receiving notification rules associated with the protocol; program code for determining the number of past notifications over the period of time in accordance with the notification rules; program code for adjusting the notification rules to reduce the number of past notifications; 9. The computer program product of claim 8, further comprising:

12. 9. The computer program product of claim 8, wherein the protocol eligibility and compliance rules are generated using a graphics compiler.

13. and program code for adjusting the protocol's eligibility and / or compliance rules using the graphical compiler after receiving feedback regarding patient outcomes in response to high compliance with the protocol.

13. The computer program product of claim 12, further comprising:

14. program code for adjusting eligibility and / or compliance rules of the protocol using the graphical compiler after receiving feedback regarding the number of notifications generated by the protocol.

13. The computer program product of claim 12, further comprising:

15. 1. A system for simulating a medical protocol, the system comprising: an application simulator configured to receive eligibility and compliance rules for a medical protocol, the simulator further configured to receive patient data collected from a plurality of patients, the collected patient data including longitudinal patient data related to particular parameters collected over a period of time from one or more sensors and / or medical devices; the simulator is further configured to compare the patient data with the eligibility rules to determine when the patient is eligible for the protocol; the simulator is further configured to compare the patient data with the compliance rules to determine a historical dynamic conformance rate for the protocol, the historical dynamic conformance rate for the protocol indicating the rate at which the patient data conformed to the compliance rules for the protocol over the period of time. system.

16. The system of claim 15 further comprising a database containing the eligibility rules and the compliance rules.

17. The system of claim 16 , wherein the application simulator is configured to receive notification rules associated with the protocol and determine the number of notifications as a function of the protocol and the patient data.

18. 17. The system of claim 16, further comprising a reporting module configured to provide reports on the protocol, the reports including clicks by medical staff in the interface, interactions with the interface by medical staff, average patient compliance, time from eligibility to protocol initiation, length of ICU stay, length of ventilation, extubation failure rate, readmission rate, and / or patient outcomes for the patient dynamic match.

19. The system of claim 18 , further comprising a graphics compiler configured to graphically generate the eligibility rules and / or the compliance rules.

20. 20. The system of claim 17, wherein the protocol rules are modified using the graphical compiler after generating the report.

Images