Patient injury prevention systems, methods, and devices

Abstract

Systems, methods, and devices to reduce occurrence of adverse health events in a patient are disclosed. A patient injury prevention system operable to receive medical records for a patient of from one or more healthcare providers of the patient, monitor the medical records, and determine compliance of the one or more healthcare providers with one or more compliance metrics. The one or more compliance metrics correspond to reducing a risk of occurrence of an adverse healthcare event to the patient. The system is also operable to generate a notification based on whether the one or more compliance metrics exceed one or more compliance thresholds. The notification is sent to the one or more healthcare providers and includes one or more recommended actions for the one or more healthcare providers.

Description

TITLEPATIENT INJURY PREVENTION SYSTEMS, METHODS, AND DEVICES CROSS REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional Patent Application Serial No.63 / 759,996, filed February 18, 2025, and titled “PATIENT INJURY PREVENTION SYSTEMS, METHODS, AND DEVICES,” which is incorporated by reference herein in its entirety.BACKGROUND1. Field

[0002] The present disclosure relates to patient injury prevention and documentation compliance systems.2. Discussion of Related Art

[0003] When a patient is admitted to a facility of a healthcare provider for treatment of one or more medical conditions, they may be put at risk of experiencing an adverse healthcare event or an injury as a result of some action or inaction from the healthcare provider. For example, a patient may be at risk of developing a pressure injury, also known as a bedsore, if the patient is poorly positioned in a bed or not repositioned frequently enough. This may be especially true for patients with limited mobility. As another example, some patients may be at risk of an abrasion or an infection from contact with medical equipment used in their treatment, such as from a catheter, breathing tube, or intravenous (IV) line, if such equipment is not monitored and regularly adjusted, cleaned, or replaced. These and other such injuries can be highly painful to the patient, may cause a stay at a healthcare provider to be lengthened unnecessarily, may complicate treatment for other medical conditions, and may result in greater financial costs to both the patient and the healthcare provider.

[0004] Many such injuries are preventable if the healthcare provider is diligent in diagnosing and providing early treatment of the symptoms of these kinds of injuries. However, with the high volume of patients admitted to healthcare facilities, and the many competing demands on the time of the healthcare provider, it can be difficult to maintain consistent care and prevent patient injuries. Adding to this difficulty is that reporting of injuries or injury risks in a patient’s medical records is often not standardized, meaning that it can be difficult for a healthcare provider to recognize warning signs of adverse healthcare events from the medical records early enough to provide preventative treatment.

[0005] It is with these observations in mind that the presently disclosed technology was conceived.1301575526SUMMARY

[0006] Systems, methods, and devices disclosed herein can address the aforementioned issues. For instance, a patient injury prevention and document compliance system can include devices configured to receive patient medical records from one or more healthcare providers, thereby enabling the system to monitor the patient medical records and identify risks of adverse health events in the patient. For example, data in the patient medical records may indicate that the patient is at risk for developing a pressure injury. The patient injury prevention system can be operable to monitor data of whether a healthcare provider is in compliance with a policy and generate reminders, alerts, or reports to aid the healthcare provider in treating the patient and remaining in compliance with the healthcare policy. For example, for patients at risk of developing a pressure injury, the patient injury prevention system may provide one or more reminders or alerts that a compliance metric related to an expected documentation practice standard has dropped. In such examples, the one or more reminders or alerts would prompt the healthcare provider to reposition the patient within the expected timeframe interval or provide some other relevant treatment and to document the care accordingly. These examples are provided here as an introduction to the more detailed description that follows.

[0007] A system of one or more computers can be configured to perform particular operations or actions by virtue of having software, firmware, hardware, or a combination of them installed on the system that in operation causes or cause the system to perform the actions. One or more computer programs can be configured to perform particular operations or actions by virtue of including instructions that, when executed by a data processing apparatus, cause the apparatus to perform the actions. One general aspect includes a method to reduce occurrence of adverse health events in a patient. The method also includes monitoring, by one or more processors, medical records for a patient. The method also includes determining, by the one or more processors, compliance of a healthcare provider of the patient with one or more compliance metrics, the one or more compliance metrics corresponding to reducing a risk of occurrence of an adverse healthcare event to the patient. The method also includes generating, by the one or more processors, a notification based on whether the one or more compliance metrics exceed one or more compliance thresholds, the notification including one or more recommended actions for the healthcare provider. The method also includes providing, by the one or more processors, the notification to the healthcare provider. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0008] One general aspect includes a system to reduce occurrence of adverse health events in a patient. The system includes a memory storing processor-readable code. The2301575526system also includes one or more processors coupled to the memory, the one or more processors configured to execute the processor-readable code to cause the one or more processors to perform operations including: monitoring medical records for a patient; determining compliance of a healthcare provider of the patient with one or more compliance metrics, the one or more compliance metrics corresponding to reducing a risk of occurrence of an adverse healthcare event to the patient; generating a notification based on whether the one or more compliance metrics exceed one or more compliance thresholds, the notification including one or more recommended actions for the healthcare provider; and providing the notification to the healthcare provider. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0009] One general aspect includes a computer-implemented tool to reduce occurrence of pressure injuries in a patient. The computer-implemented tool also includes a computer readable medium storing code which, when executed by one or more processors, causes the one or more processors to perform operations including: monitoring medical records for a patient; determining compliance of a healthcare provider of the patient with one or more compliance metrics, the one or more compliance metrics corresponding to reducing a risk of occurrence of an adverse healthcare event to the patient; generating a notification based on whether the one or more compliance metrics exceed one or more compliance thresholds, the notification including one or more recommended actions for the healthcare provider; and providing the notification to the healthcare provider. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

[0010] The foregoing has outlined rather broadly the features and technical advantages of the present invention in order that the detailed description of the invention that follows may be better understood. Additional features and advantages of the invention will be described hereinafter which form the subject of the claims of the invention. It should be appreciated by those skilled in the art that the conception and specific embodiment disclosed may be readily utilized as a basis for modifying or designing other structures for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims. The novel features which are believed to be characteristic of the invention, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that3301575526each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present invention.BRIEF DESCRIPTION OF THE FIGURES

[0011] FIG. 1 illustrates an example system for preventing adverse health events to a patient including a computing device in a wireless network architecture.

[0012] FIG. 2 illustrates an example dataflow process of data operations in a system for preventing adverse health events to a patient.

[0013] FIG. 3 illustrates an example method of preventing adverse health events to a patient which can be performed by any of the system(s) disclosed herein.

[0014] FIG. 4 illustrates an example user interface for a system for preventing adverse health events to a patient including data visualization tools and selectable elements according to aspects of the disclosure.

[0015] FIG. 5 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating patient body position.

[0016] FIG. 6 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating skin protection measures.

[0017] FIG. 7 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating patient skin health assessment.

[0018] FIG. 8 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating timing of patient skin health assessment and documentation.

[0019] FIG. 9 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating timing of patient skin health assessment and documentation.

[0020] FIG. 10 illustrates an example user interface for a system for preventing adverse health events to a patient, including models and data flow diagrams for monitoring patient health data and recommending healthcare provider actions.

[0021] FIG. 11 illustrates experimental data indicating successful reduction of adverse health events in patients.4301575526DETAILED DESCRIPTION

[0022] It will be appreciated that numerous specific details are set forth in order to provide a thorough understanding of the examples described herein. However, it will be understood by those of ordinary skill in the art that the examples described herein can be practiced without these specific details. In other instances, methods, procedures and components have not been described in detail so as not to obscure the related relevant feature being described. Also, the description is not to be considered as limiting the scope of the examples described herein. The drawings are not necessarily to scale and the proportions of certain parts may be exaggerated to better illustrate details and features of the present disclosure.

[0023] As used herein a “healthcare provider” may include one of the following, a plurality of the following, or any combination of the following: a healthcare institution, including a hospital, a medical clinic, an urgent care facility, an emergency room facility, an extended care facility, an assisted living facility, a senior care center, a memory care facility, a disability treatment facility, a rehabilitation clinic, a physical therapy facility, a hospice organization, a telehealth provider, a nursing school facility, a medical school facility, or a healthcare company; a healthcare support institution, including a management company, a financial organization, a healthcare software developer, a healthcare software distributor, a medical equipment manufacturer, or the like; a group of healthcare providers including an individual care unit, a medical practice group, a research group, a shift of healthcare staff, or a nursing group; or an individual, including a doctor, a nurse, a caregiver, a healthcare shift leader, a healthcare management professional, a medical staff, an emergency medicine technician, and so on. These are provided as non-limiting examples of healthcare providers, and it is understood that other kinds of healthcare providers not listed here or users not necessarily operating in the healthcare space may advantageously implement the systems, devices and methods described herein without departing from the spirit and scope of the present disclosure.

[0024] The systems, methods, computer implemented tools, and computer readable media may result in several technical and practical advantages to a healthcare provider. For example, the techniques disclosed herein may enable a healthcare provider to more rapidly identify warning signs of adverse healthcare events occurring to patients and act to prevent harm to the patient. For example, the techniques described herein have been shown to reduce the occurrence of pressure injuries in patients who are at risk for developing pressure injuries. This may result in a lower cost to both the patient and the healthcare provider, decreased recovery time, reduced risk of infection or other adverse healthcare events to patients. The systems described herein may improve efficiency of the healthcare provider in providing5301575526timely and consistent care to patients. Other advantages will become readily apparent to those of skill in the art.

[0025] Additionally, the disclosed systems address technical problems inherent in technology used by healthcare providers, such as electronic medical record (EMR) monitoring and alert systems that include high network bandwidth due to periodic polling, non-deterministic alert latency, and unnecessary processor cycles consumed by evaluating compliance metrics over large, unstructured datasets. The technology disclosed herein can address these technical problems, for instance, by implementing an event-driven data streaming architecture.

[0026] For example, the event-driven data streaming architecture can include an edge agent deployed on a computing device of a healthcare unit configured to subscribe to EMR change events via a secure message queue and to perform local feature extraction on received records to produce a normalized compliance-feature vector. The normalized compliance-feature vector can include timestamped fields for body position, device contact points, documentation events, and risk indices. Furthermore, the event-driven streaming architecture can include an adaptive sampling controller configured to dynamically adjust ingestion rates for sensor-derived data streams (e.g., a capnography-related data stream, a bed occupancy-related data stream, a catheter flow-related data stream, and / or combinations thereof) based on a state machine that transitions between normal and heightened monitoring modes in response to threshold-crossing events, thereby reducing average data throughput (e.g., by at least 40%) during normal conditions while preserving sub-500 ms end-to-end alert latency while in the heightened monitoring mode;

[0027] In some cases, the event-driven streaming architecture can include a sliding timewindow index stored in a memory of the computing device. The sliding time-window index can maintain amortized insertion and amortized threshold evaluation for recurrent compliance checks (e.g., by repositioning intervals every 2 hours). The sliding time-window index can use a ring buffer keyed by a patient identifier and compliance metric type to avoid repeated full-scan computations. Additionally, the event-driven streaming architecture can include a deterministic alert pipeline that can enforce a maximum jitter bound between event detection and alert issuance, through use of priority queues, precomputed rule paths, and on-device inference of trained models quantized to reduce compute overhead and memory footprint.

[0028] Furthermore, the event-driven streaming architecture can include a device-control interface configured to transmit machine control signals to connected devices over standardized protocols (e.g., HL7®, FHIR®, IEEE 11073), including commands to (i) adjust bed actuator positions to a prescribed angle for offloading pressure points, (ii) set nurse call6301575526system priority levels for immediate action, and / or (iii) alter sampling rates of patient monitors, resulting in a transformation of device states of these external devices in response to computed compliance deviations.

[0029] These components, individually and collectively, improve computer and network functioning by reducing bandwidth consumption through event-driven data stream ingestion and adaptive sampling. Also, the disclosed technology reduces CPU cycles through constanttime threshold evaluation and quantized inference, and provides deterministic alert latencies via prioritized pipelines. The system further integrates the computed compliance determinations into a practical application that controls external systems (e.g., external medical devices) and workflow systems in a particular way to improve device architecture efficiency. Exemplary performance results demonstrate a reduction in average network payload for EMR monitoring compared to periodic polling baselines, (ii) a reduction in average CPU utilization for compliance checks, and (iii) a reduced median end-to-end alert latency under heightened monitoring conditions.

[0030] Also, any of these components (e.g., event-driven streaming, edge agent, adaptive sampling, sliding time-window index, deterministic alert pipeline, and / or device-control interface) can be integrated with the computing device(s), servers, message handling, and alert generation components disclosed herein. As such, the disclosed systems can result in reductions in bandwidth, CPU cycles, and bounded alert latency. Furthermore, the devicecontrol interface actions (e.g., bed actuator, nurse call priority, altering monitor sampling rates, etc.) can integrate the compliance determinations into concrete machine control of external physical systems, consistent with the overall goal of preventing adverse events. In other words, the computed outputs can be integrated into a practical application by driving devicelevel actions or process controls (e.g., automatically adjusting infusion pumps, bed actuators, or sensor sampling rates), or by eliminating unnecessary EHR polling, using edge filtering to reduce data volume, and / or performing on-device inference to reduce latency.

[0031] Furthermore, specific data structures and processing pipeline can result in technical improvements, such as a normalized compliance-feature vector, a sliding timewindow index, and / or an immutable audit log with append-only structure to enable compliance threshold evaluation. Additionally, in combination with these data structures and processing pipelines, particular hardware / software architecture can also result in technical improvements, such as distributed microservices, message queues, cache layers, differential updates, and / or on-device ML-inference with model quantization that reduces compute and energy. The disclosed technology can also perform device control and transformation, such as direct control signals to bed actuators or nurse call systems that effect a physical repositioning workflow, altering sampling rates on connected monitors, and / or automatic activation of7301575526specific sensor modes (e.g., causing transformation of device states). Accordingly, particular performance metrics can be achieved, such as measured reductions in network payload, CPU cycles, memory footprint, deterministic response guarantees, and / or improved classification accuracy with lower compute budget.

[0032] In some examples, any of the system, components, or subcomponents disclosed herein can be integrated into and / or combined with a computer-implemented method to reduce occurrence of adverse health events in a patient, wherein the method includes receiving, at an edge agent executing on a computing device of a healthcare unit, event messages indicating updates to medical records for the patient via a secure, authenticated message queue; generating, by the edge agent, a normalized compliance-feature vector from the updates, the vector comprising timestamped fields for patient body position, device contact points, documentation events, and risk indices; maintaining, in a memory of the computing device, a sliding time-window index of the compliance-feature vector, the index configured for constant-time insertion and constant-time threshold evaluation of compliance metrics; determining, by the computing device, a transition of a monitoring state machine from a normal monitoring mode to a heightened monitoring mode in response to evaluating the compliancefeature vector against a repositioning interval threshold, and adaptively increasing sampling rates of connected patient monitors via a device-control interface; generating, by the computing device, an alert within a bounded latency from the transition, the alert including one or more recommended actions and machine control signals that (i) set a nurse call system priority level and (ii) command a bed actuator to adjust to a prescribed position for offloading a pressure point; and transmitting, by the device-control interface, the machine control signals to the connected devices using standardized healthcare communication protocols. The event-driven ingestion, constant-time threshold evaluation, and / or bounded-latency alert pipeline reduce network bandwidth and processor utilization compared to periodic polling and full-scan compliance computations.

[0033] In some examples, a system to reduce occurrence of adverse health events in a patient can include a memory storing processor-readable code and a sliding time-window index configured to maintain constant-time insertion and evaluation of compliance metrics; and one or more processors coupled to the memory, the one or more processors configured to execute the processor-readable code to perform operations comprising: subscribing to medical record update events via a secure message queue and generating normalized compliance-feature vectors; operating an adaptive sampling module that adjusts sensor data ingestion rates based on a monitoring state machine responsive to compliance threshold crossings; executing a deterministic alert pipeline that enforces a maximum jitter bound between threshold detection and alert issuance; and transmitting machine control signals via8301575526a device-control interface to actuate connected medical devices, thereby effecting a transformation of device states in response to computed compliance deviations,

[0034] In some scenarios, a computer-readable medium stores code which, when executed by one or more processors of an edge agent, causes the one or more processors to: ingest medical record update events; construct a normalized compliance-feature vector and insert the vector into a ring-buffer index keyed by patient and metric type; evaluate, in constant time, compliance thresholds corresponding to patient repositioning intervals; and upon detecting non-compliance, generate within a bounded latency a set of machine control signals conformant to HL7® or FHIR® protocols to (i) adjust a bed actuator position, (ii) modify sensor sampling rates, and (iii) elevate nurse call priority,

[0035] In some implementations, the system includes a device-control interface configured to transmit machine control signals to connected medical devices using standardized healthcare communication protocols such as HL7®, FHIR®, or IEEE 11073. The machine control signals can actuate device functions relevant to preventing adverse health events, for example by commanding a bed actuator to adjust to a prescribed angle to offload pressure points, setting a nurse call system priority level for immediate action, or altering sampling rates of patient monitors in response to detected non-compliance with a compliance metric.

[0036] Furthermore, in scenarios, monitoring of medical records is performed in an event-driven manner. An edge agent executing on a computing device of a healthcare unit subscribes to authenticated update events via a secure message queue and constructs a normalized compliance-feature vector from received updates. The normalized compliancefeature vector may include timestamped fields for patient body position, device contact points, documentation events, and risk indices. The vector can be inserted into a sliding time-window index implemented as a ring buffer keyed by patient identifier and compliance metric type, enabling constant-time insertion and constant-time threshold evaluation for recurrent compliance checks without repeated full scans of historical data.

[0037] Also, in some cases, the system operates a deterministic alert pipeline that constrains alert timing variability between threshold detection and alert issuance. The pipeline may employ priority queues, precomputed rule paths, and on-device inference of models quantized to compact integer representations to reduce compute and memory overhead while maintaining predictable responsiveness. The approach facilitates reliable delivery of alerts and associated machine control signals under variable system loads.

[0038] The system can employ a monitoring state machine that transitions between a normal monitoring mode and a heightened monitoring mode in response to evaluation of the9301575526compliance-feature vector against one or more thresholds. Upon entry into the heightened monitoring mode, the system can adaptively increase sensor data ingestion and sampling rates for selected patient monitors and, when appropriate, transmit machine control signals through the device-control interface to coordinate responsive actions by connected devices.

[0039] Additional advantages of the systems, methods, and devices discussed herein will become apparent from the detailed description below.

[0040] FIG. 1 illustrates an example system 100 for preventing adverse healthcare events to a patient including one or more computing device(s) 110 in a wireless network architecture 102. The computing device(s) 110 can receive and / or transmit data to and from the other components of the system 100 using one or more network(s) 130 which can include any type of network, such as the Internet, an intranet, a Virtual Private Network (VPN), a Voice over Internet Protocol (VoIP) network, an ethernet network, a network (e.g., Bluetooth®), a cellular network (e.g., 4G, 5G, LTE, etc.), satellite, combinations thereof, etc. Additionally, or alternatively, the systems 100 disclosed herein can include at least one or more server(s) 150 hosting a website or application that the computing device 110 may visit to access, control, adjust, and / or view the components of the system 100. The website or application can receive the inputs from the computing devices 110 and can analyze the inputs to generate the outputs and / or machine control signals discussed herein. The server 150 may be a single server, a plurality of servers with each such server being a physical server or a virtual machine, or a collection of both physical servers and virtual machines. In another implementation, a cloud hosts one or more components of the central management system for controlling and / or accessing the system 100. The server 150 can represent an instance among large instances of application servers in a cloud computing environment, a data center, or other computing environment. The server 150 may be configured to access any of the data disclosed herein, which can be stored at one or more database(s) 152.

[0041] In some instances, the computing device(s) 110 can include a computer, a personal computer, a desktop computer, a laptop computer, a terminal, a workstation, a cellular or mobile phone, a mobile device, a smart mobile device, a tablet, a wearable device (e.g., a smartwatch, smart glasses, a smart epidermal device, etc.), a multimedia console, a television, an Internet-of-Things (loT) device, a smart home device, another virtual reality (VR) or augmented reality (AR), a vehicle display system, and / or the like.

[0042] The computing device 110 can be capable of executing a computer program product to execute a computer process to perform the adverse healthcare event prevention operations and data operations disclosed herein. Data and program files may be input to the computing device 110, which reads the files and executes the programs therein. Some of the10301575526elements of the computing device 110 can include one or more hardware processors 112, one or more memory devices 114, and / or one or more ports, such as input / output (IO) port(s) 124 and communication port(s) 122. Various elements of the computing device 110 may communicate with one another by way of the communication port(s) 122 and / or one or more communication buses, point-to-point communication paths, or other communication means.

[0043] The processor 112 may include, for example, a central processing unit (CPU), a microprocessor, a microcontroller, a digital signal processor (DSP), a graphics processing unit (GPU), and / or one or more internal levels of cache. There may be one or more processors 112, such that the processor 112 comprises a single central-processing unit, or a plurality of processing units capable of executing instructions and performing operations in parallel with each other, which can be referred to as a parallel processing environment.

[0044] The computing device 110 may be a single computer, a plurality of computers (e.g., a distributed computer), or another type of computer, such as one or more external computers made available via a cloud computing architecture. The presently described technology is optionally implemented in software stored on the data storage device(s) such as the memory device(s) 114, and / or communicated via one or more of the ports 122 / 124 to the system 100, thereby transforming the computing device 110 into a non-conventional and non-generic special purpose patient injury prevention machine.

[0045] The one or more memory device(s) 114 may include any non-volatile data storage device capable of storing data generated or employed within the computing device 110, such as computer executable instructions 116 for performing a computer process, which may include instructions of both application programs and an operating system (OS) that manages the various components of the computing device 110. The memory device(s) 114 may include one or more databases 118. The memory device(s) 114 may include, without limitation, magnetic disk drives, optical disk drives, solid state drives (SSDs), flash drives, and the like. The memory device(s) 114 may include removable data storage media, non-removable data storage media, and / or external storage devices made available via a wired or wireless network (e.g., network(s) 130) with such computer program products, including one or more database management products, web server products, application server products, and / or other additional software components. Examples of removable data storage media include Compact Disc Read-Only Memory (CD-ROM), Digital Versatile Disc Read-Only Memory (DVD-ROM), magneto-optical disks, flash drives, and the like. Examples of non-removable data storage media include internal magnetic hard disks, SSDs, and the like. The one or more memory device(s) 114 may include volatile memory (e.g., dynamic random-access memory (DRAM), static random-access memory (SRAM), etc.) and / or non-volatile memory (e.g., read-11301575526only memory (ROM), flash memory, etc.). The memory device(s) 114 may be referred to as machine-readable media.

[0046] Moreover, it will be appreciated that machine-readable media may include tangible non-transitory medium capable of storing or encoding instructions to perform operations of the computing device 110. The machine-readable media can store computer-readable instructions for execution by a machine and can be capable of storing or encoding data structures and modules utilized by such instructions.

[0047] In some implementations, the computing device 110 can include one or more I / O port 124 and / or I / O devices by which information is input to or output from the computing device 110. Such I / O ports 124 may include, without limitation, one or more input devices and / or output devices. The input devices can convert a human-generated signal, such as, human voice, physical movement, physical touch or pressure, and / or the like, into electrical signals as input data into the computing device 110 via the I / O port 124. Similarly, the output devices may convert electrical signals received from the computing device 110 via the I / O port 124 into signals that may be sensed as output by a human, such as sound, light, and / or touch. Additionally or alternatively, the output devices can provide an output as a machine control signal to the computing device 110. The input device may be an alphanumeric input device, including alphanumeric and other keys for communicating information and / or command selections to the processor 112 via the I / O port 124. The input device may be another type of user input device including, but not limited to direction and selection control devices, such as a mouse, a trackball, cursor direction keys, a joystick, and / or a wheel; one or more sensors, such as a camera, a microphone, a positional sensor, an orientation sensor, an inertial sensor, an accelerometer; and / or a touch-sensitive display screen (“touchscreen”). The output devices may include, without limitation, a display, a touchscreen, one or more LEDs, a speaker, a tactile or haptic output device, and / or the like. In some implementations, the input device and the output device may be the same device, for example, in the case of a touchscreen. In some scenarios, the computing device 110 can include one or more graphical user interfaces (GUIs) for presenting the various data outputs discussed herein, such as the GUIs discussed below regarding FIGS. 4-9.

[0048] In some implementations, the communication port 122 is connected to the network 130, and the computing device 110 may receive network data useful in executing the methods and systems set out herein as well as transmitting information and network configuration changes determined thereby. Stated differently, the communication port 122 can connect the computing device 110 to one or more communication interface devices configured to transmit and / or receive information between the computing device 110 and other devices by way of one or more wired or wireless communication networks or connections, such as the network12301575526130. Further, the communication port 122 may communicate with an antenna, satellite receiver, or other link for electromagnetic signal transmission and / or reception.

[0049] System 100 may include one or more data sources 140. Data source(s) 140 may include medical records 142. Medical records 142 may include patient medical records and / or records of a healthcare provider. For example, patient medical records may be provided by a patient to the healthcare provider. Additionally or alternatively, patient medical records may be generated by the healthcare provider as part of providing healthcare to the patient. For example, patient medical records may include data recorded by the healthcare provider as part of administering healthcare to the patient, such as medical charting records. Other patient medical records may include data generated by monitoring equipment, including as nonlimiting examples, data generated by vitals signs monitors, medication administration equipment, IV monitoring equipment, oxygen administration equipment, diagnostic monitors, and the like. Records of a healthcare provider may overlap with patient medical records, such as, for example, records generated as medical charting records for the patient. Additionally or alternatively, records of a healthcare provider may be independent from patient medical records. For example, records of the healthcare provider may include data corresponding to actions undertaken by the healthcare provider in providing care to one or more patients, in administering a facility of the healthcare provider, or in managing one or more units of the healthcare provider (e.g., a shift, a medical group, a practice group, a specialty, and so on). Additionally or alternatively, the records of the healthcare provider may include data indicating one or more compliance metrics and whether the healthcare provider is in compliance with each of the one or more compliance metrics. Compliance with the one or more compliance metrics may be determined in accordance with the description herein, based on patient medical records, based on records of the healthcare provider, based on other data, or a combination thereof. Medical records 142 may include one or more medical records for each patient of a plurality of patients. Medical records 142 may include records from a plurality of healthcare providers.

[0050] Medical records 142 may include data indicating a risk of occurrence of an adverse healthcare event to the patient. For example, the medical records 142 may include data corresponding to a risk of a pressure injury, a risk of an infection (e.g., a catheter infection, or an infection of a wound, a fall risk, patient mobility, patient psychological data, a patient safety risk, a capnography record, a medication administration record, or some combination thereof

[0051] Medical records 142 may include data represented in any of various formats, including text data, numerical data, image data, and / or video data. Medical records 142 may include structured data, such as may exist when the medical record is generated from a form or by charting software, for example. Medical records 142 may also include unstructured data.13301575526Medical records 142 may include metadata corresponding to the data. The computing device(s) 110 may be configured to receive data, including medical records 142, over the network 130. Additionally or alternatively, the computing device(s) 110 may be configured to receive or generate data directly, such as from information stored in memory device(s) 114, or data received or from input at one or more of the communication port(s) 122 or the I / O port(s) 124. Computing device(s) 110 may be configured to identify, extract, and / or classify features from the data in the medical records 142 such that the

[0052] Computing device(s) 110 may include an alert generating engine 120. The alert generating engine 120 may be configured to receive and / or monitor data, including medical records 142. Alert generating engine 120 may be configured to determine whether a healthcare provider is in compliance with respect to one or more compliance metrics. For example, alert generating engine 120 may determine compliance by comparing the one or more compliance metrics with one or more compliance thresholds. Alert generating engine 120 may be configured to trigger an alert or a notification to the healthcare provider based on whether the healthcare provider is in compliance with respect to the one or more compliance metrics. Alert generating engine 120 may be configured to provide the alert or notification to the healthcare provider. The alert or notification generated by the alert generating engine 120 may include one or more recommended actions for the healthcare provider. For example, the one or more recommended actions may correspond to actions to bring the healthcare provider into compliance with the one or more compliance metrics. As an additional example, the one or more recommended actions may correspond to actions taken to prevent or mitigate an adverse healthcare event for a patient. The alert generating engine 120 may include one or more trained machine learning models configured to extract and / or categorize data from medical records 142. Alert generating engine 120 may include one or more machine learning models configured to determine a recommended action for the healthcare provider based on one or more compliance metrics. Alert generating engine 120 may be configured to identify and / or set relevant thresholds corresponding to the compliance metrics or corresponding to another desired outcome for the healthcare provider and / or the patient.

[0053] A compliance metric may include a measurable category of data corresponding to compliance with one or more policies or with one or more standards of care. A compliance metric may include or correspond to one or more actions undertaken by a healthcare provider. Compliance metrics may include legally mandated compliance practices, medical best practices, nursing best practices, medical documentation practices, patient care goals and metrics, business goals and metrics, some other internal or external goal or metric, or some combination thereof. To determine compliance with one or more policies, a compliance threshold may be used. In some cases, a compliance threshold may include a value of the14301575526compliance metric, which when reached or exceeded indicates that the healthcare provider’s actions are in compliance with the respective policy or policies. In some cases, a compliance threshold may include a value of the compliance metric, which when reached or exceeded indicates that the healthcare provider’s actions are no longer in compliance with the respective policy or policies. Multiple compliance thresholds corresponding to one or more compliance metrics may be monitored. For example, a compliance metric may have different or tiered thresholds, such that when a compliance metric meets or exceeds a first compliance threshold, a first notification may be triggered, and if the compliance metric meets or exceeds a second compliance threshold higher than the first compliance threshold, a second notification may be triggered. In other words, a compliance threshold may function as an upper threshold, a lower threshold, or both, for a compliance metric, based on the specific circumstances corresponding to the compliance metric and the respective compliance policy.

[0054] This general description of compliance metrics and compliance thresholds may be better understood by way of a few concrete examples. These examples are provided for illustrative purposes and are not intended to limit the scope of the present disclosure. A person of ordinary skill in the art would recognize that the principles disclosed herein may be applied to numerous situations, adverse healthcare events or risks thereof, compliance metrics, compliance thresholds, and / or actions (e.g., actions of a healthcare provider) without departing from the spirit and scope of the present disclosure.

[0055] Compliance metrics may include or correspond to metrics for reducing a risk of occurrence of an adverse healthcare event to a patient. An adverse healthcare event may include any injury sustained by the patient in connection with their treatment by a healthcare provider. Adverse healthcare events may include injuries sustained as a result of accident, negligence, or intentional harm. Nonlimiting examples of adverse healthcare events can include one or more of a pressure injury, a skin abrasion, a catheter associated urinary tract infection, an IV line infection, an injury related to a fall or patient handling, a medical error such as an incorrect medication administration, a misdiagnosis, or a surgical error, or a combination thereof.

[0056] In the example of a pressure injury (also known as a pressure ulcer, a pressure sore, or a bedsore), a pressure injury can refer to an area of skin damage caused by prolonged pressure to the skin. Pressure injuries often occur as a result from a patient being confined to a bed or chair for long periods of time. Pressure injuries may develop over bony areas of the body, such as the heels, hips, and / or tailbone. Pressure injuries can also occur where medical equipment or devices cause friction or pressure with the patient’s skin, such as at the bridge of the patient’s nose when a mask of a bilevel positive airway pressure (Bl PAP) machine or high flow oxygen cannula is insufficiently padded.15301575526

[0057] Pressure injuries can be highly costly to both patients and healthcare providers. It is estimated by the Agency for Healthcare Research and Quality (ARHQ) that the cost of a pressure ulcer to an individual patient ranges from $20,900 to $151,700 per pressure ulcer. Costs may not be reimbursable by insurance companies or healthcare systems for pressure injuries of stages 3 and above, usually because such pressure injuries could have been prevented with proper attention and treatment.

[0058] One metric used to evaluate a patient’s risk of developing a pressure injury is the Braden Scale, which evaluates a patient on six subscales to produce a total score which may range from 6 to 23. The six subscales include (1) sensory perception (with less perception being correlated with greater risk), (2) skin moisture (with more frequently moist skin, such as from perspiration, being correlated with greater risk), (3) physical activity or ability to walk (with patients with more limited ability to walk being correlated with greater risk), (4) mobility or the ability to change and control body position (with more limited mobility being correlated with greater risk), (5) nutrition, or usual food intake pattern (where poorer nutrition is correlated with greater risk), and (6) friction and shear (with greater friction when moving being associated with greater risk). A lower Braden score indicates higher levels of risk for pressure ulcer development. Generally, a score of 18 or less indicates at-risk status. Patients may be evaluated using the Braden Scale when admitted to a facility of the healthcare provider and may be reevaluated periodically.

[0059] To prevent pressure injuries from occurring to patients, especially for patients with a Braden score of 18 or lower, a healthcare provider may frequently change the position of the patient and provide proper skin care. To aid in this effort, a healthcare provider may implement a compliance policy that a patient’s body position be changed at regular intervals, and that such changes in position be recorded in a medical record. For example, a healthcare provider may require that a patient’s body position be adjusted every two hours. In this same example, the two-hour period between repositioning may be used as a compliance threshold, such that when repositioning does not occur within that period, alert generating engine 120 may cause an alert instructing the healthcare provider to reposition the patient to be sent. A healthcare provider may also require making or updating a medical record of a patient’s position being changed within a reasonable period of time. For example, the healthcare provider may require that a medical record, such as a charting record, ofchanging the patient’s body position be made or updated before the next time that the patient’s body is repositioned. Accurate and timely documentation in medical records can help prevent pressure injuries because it allows a healthcare provider to act before a pressure injury develops, whereas if records are not kept up to date, it may be difficult if not impossible to provide the patient with consistent adjustments. Moreover the alert generation engine 120 of system 100 may only16301575526be able to provide relevant alerts or recommended actions to the extent that it is operating on up-to-date data, including data on compliance metrics.

[0060] In the example of pressure injuries, both the frequency at which repositioning the patient occurs and the timing at which repositioning actions were documented can be considered compliance metrics that correspond to reducing the patient’s risk of developing a pressure injury. Other compliance metrics for preventing pressure injuries may include metrics for how frequently bedding or clothing of the patient is changed, a rate at which padding is provided to patients using a Bl PAP machine, the specific position at which the patient was positioned relative to their bed or chair at a specific time (e.g., on the left side, right side, on their back, or sitting up in the bed or chair), and whether the position the patient was repositioned to is different from a previous position. Such compliance metrics may also be monitored compared to respective compliance thresholds.

[0061] In the example of catheter-associated urinary tract infection, a compliance metric for reducing the risk may include one or more of how frequently a catheter was changed or cleaned, how frequently a drainage bag from the catheter was emptied, how frequently fluids were administered to the patient, how promptly the catheter was removed once no longer needed, how promptly actions taken with respect to the catheter were recorded in a medical record, and so on. Such compliance metrics may also be monitored compared to respective compliance thresholds, as would be recognized by one of ordinary skill in the art.

[0062] In the example of fall risks, compliance metrics for reducing fall risks may include how long after admittance a patient is assessed for fall risk, such as by using the Morse Fall Scale or another scale for assessing fall risk, how frequently or promptly fall hazard inspections are conducted, whether a patient or their caregivers was advised on risks of falling, the number of healthcare provider staff are on hand for aiding a patient in motion, how promptly actions taken with respect to reducing fall risk are recorded in a medical record and so on. Such compliance metrics may also be monitored compared to respective compliance thresholds, as would be recognized by one of ordinary skill in the art.

[0063] In addition to helping to prevent adverse healthcare events, compliance metrics may also include or correspond to metrics for patient recovery and / or rehabilitation. For example, metrics corresponding to patient ambulation may be monitored. Ambulation is important for patient recovery for many reasons. For example, ambulation may help patients in a medical or surgical unit who are recovering from an operation, such as a kidney or liver transplant. Ambulation immediately after an operation is very important because it can help to prevent post-operation complications and delays in recovery, reduce length of stay, improve patient satisfaction, and promote independence. An ambulation compliance metric may17301575526include, for example, an amount of time from when an operation is performed to a patient ambulating, or a length of time that the patient spent in ambulation. A unit of the healthcare provider may implement audits of compliance metrics for individual staff or patients. Audits of compliance metrics on the unit level may also be helpful in providing a broader view of average compliance for the healthcare provider, including, for example, analyzing all entries made in the electronic medical record of the healthcare provider.

[0064] Other potential process metrics with potential for monitoring were identified along with the outcome the process metric impacts, the cost impact of that outcome. The system further organizes these process metrics within a unified operational taxonomy that supports audit, reminder, education, and engagement actions to improve practice-change compliance. Illustrative process metrics include, without limitation, correct Braden scoring and documentation, bed and chair alarm usage, Foley catheter necessity and care, central line care bundle elements, hand hygiene events, blood sugar monitoring cadence, ambulation and early mobility, medication timing and reconciliation, delirium bundle completion, dysphagia screening completion, venous thromboembolism prophylaxis, head-of-bed elevation adherence, oral care frequency, early mobility protocols, pain reassessment timing, response workflows for critical labs, antibiotic re-dosing intervals, sepsis screening completion, isolation precaution compliance, intravenous site assessment intervals, stroke measure elements, heel offloading, nutrition screening, moisture management, dual verification for medications, transfusion verification, discharge education steps, removal of unnecessary lines and tubes, hourly rounding compliance, specimen label accuracy, alarm response time, and sitter utilization tracking. For each metric, the platform can associate outcome targets and estimated cost impact ranges based on published reports or institutional analyses, and select appropriate tool actions (audit for adherence, reminders for timely corrective steps, education to standardize technique and documentation, and engagement mechanisms such as scorecards and trend visualizations). This structured approach enables scalable monitoring across diverse clinical areas and supports data-driven prioritization of interventions to reduce adverse events and resource waste.

[0065] Additionally, the platform’s process metrics and outcome targets can align with published toolkits, guidelines, and standards across multiple clinical domains. In certain embodiments, the platform can organize process metrics across multiple clinical domains and associates each metric with a corresponding outcome category and validation source, enabling technology-supported adherence to evidence-based practices. Illustrative pairings of process metrics with outcome categories and / or validation sources include positioning practices linked to hospital-acquired pressure injury outcomes validated by AHRQ toolkits and peer-reviewed literature; bed and chair alarm usage tied to falls with injury, supported by18301575526AHRQ resources and clinical studies; out-of-bed falls mitigation through alarm and supervision programs referenced in AHRQ falls guidance; standardized pressure injury risk assessment aligned with AHRQ prevention materials; catheter-associated urinary tract infection prevention through device necessity reviews and care practices validated by AHRQ CUSP and CDC guidance; central line-associated bloodstream infection prevention via care bundle adherence validated by AHRQ CUSP and CDC; healthcare-associated infection controls and cost frameworks grounded in CDC and AHRQ sources; glycemic event mitigation supported by peer-reviewed analyses; pneumonia prevention, venous thromboembolism prophylaxis, and length-of-stay improvements through early mobility bundles supported by AHRQ and peer-reviewed trials; readmission and sepsis outcomes tied to timely medication and bundle compliance from peer-reviewed evidence; delirium reduction and ICU length-of-stay impacts associated with ABCDEF bundle adherence; aspiration pneumonia reduction through AHRQ patient safety indicators and dysphagia screening; DVT / PE prevention using AHRQ guides and CDC facts; ventilator-associated pneumonia and aspiration reduction using CDC guidance and IHI bundles; hospital-acquired pneumonia prevention via oral care frequency supported by CDC and peer-reviewed sources; mobility, delirium, and thrombosis outcomes tied to early rehabilitation literature; pain control impacts on length of stay and readmissions from peer-reviewed studies; rapid response to critical laboratory results linked to sepsis and cardiac outcomes; surgical site infection reduction through CDC prevention guidelines and peri-operative antibiotic timing; sepsis cost and screening impacts referenced by AHRQ and peer-reviewed sources; isolation precautions for transmissible organisms validated by CDC; extravasation prevention guided by Infusion Nurses Society standards; stroke outcomes aligned with AHA / ASA core measures and early rehabilitation guidance; heel offloading for HAPI prevention validated by AHRQ and international guidelines; nutrition screening and support for pressure injury healing referenced by AHRQ and peer-reviewed literature; moisture management for HAPI prevention guided by AHRQ; medication safety enhanced by ISMP dual verification standards; transfusion reaction prevention using CDC and AABB hemovigilance standards; readmission reduction through education and transitional care consistent with AHRQ; adverse drug event mitigation via medication reconciliation aligned with AHRQ MATCH Toolkit; line and device necessity reviews and early removal for CLABSI / CAUTI prevention supported by AHRQ CUSP and CDC; hourly rounding to reduce falls and improve pain and length-of-stay supported by peer-reviewed implementations; specimen label accuracy addressing diagnostic delays aligned with Joint Commission alerts. For each process metric, the platform can map the metric to its outcome category and recognized validation source, and apply audit, reminder, education, and engagement actions through domain-specific thresholds and workflows to standardize documentation, improve compliance, and reduce adverse events. Operations of the alert generating engine 120 and 19301575526various methods disclosed herein performed by the system 100 can be embodied as data structures and / or instructions stored on the memory devices 114 and executed by the processor 112. In other words, the methods and operations disclosed may be implemented as sets of instructions that are software-readable by the computing device 110. Also, it is to be understood that any of the computational operations discussed herein can be performed at a cloud machine, such as the server 150, locally at the computing device 110, or both.

[0066] FIG. 2 illustrates an example dataflow process 200 of data operations in a system for preventing adverse healthcare events to a patient. Such operations may be performed by a system such as system 100, or by one or more of the components of the system 100, such as computing device 110 and alert generating engine 120.

[0067] At block 202, one or more compliance thresholds for a compliance metric may be input to the system 100. Inputting the one or more compliance thresholds may include providing the compliance threshold to alert generating engine 120. Inputting a compliance threshold may include receiving a compliance threshold as healthcare data from one or more data sources. Additionally or alternatively, inputting a compliance threshold may include receiving a compliance threshold as an input from a user, for example, as an input through an input device at a user interface. A compliance threshold may be set at the time a system is configured, or it may be input at a later time. Additionally or alternatively, compliance thresholds may be modified or adjusted at any time. For example, a compliance threshold may be modified to comply with any of a legal policy, a medical best practice, improvement of a patient’s health, or a business goal of a healthcare provider. In some implementations, modifying one or more compliance thresholds may be done in response to a determination that compliance with the respective policy does not sufficiently reduce the risk of the corresponding adverse healthcare event. In other words, the compliance thresholds may be modified to improve outcomes for the patients and not just to meet a minimum compliance threshold.

[0068] At block 204, the alert generating engine 120 may monitor one or more medical records corresponding to a patient. Monitoring one or more medical records may include monitoring medical records in real time or in near-real time. For example, as medical records are generated and / or updated, the most recent records may be provided to the system for analysis and data operations. This may be understood as a dynamic monitoring of medical records for the patient. Additionally or alternatively, the medical records may be monitored from data captured at one time. For example, medical records may be monitored in response to an input requesting the medical records. Such a request may be performed by a user interacting with one or more input devices or user interfaces. Additionally or alternatively, such a request may be generated within alert generating engine 120. Data in medical records20301575526captured at one time may include a most recently updated set of medical records, or it may include a snapshot from a previous time period.

[0069] At block 206, the alert generating engine 120 may extract compliance data from the one or more medical records. Extracting compliance data may include identifying and extracting data for compliance metrics relevant to the input compliance threshold. For example, if the compliance threshold corresponds to a policy for reducing risk of a pressure injury, then the compliance data extracted may include metrics corresponding to reducing risk of a pressure injury such as time between patient admittance and Braden Score assessment, rate of repositioning, the different positions the patient was positioned at relative to a bed, chair, or other planar surface when positions were changed, how frequently bedding was changed and so on. In some implementations, extracting compliance data from the medical records may include providing the medical records to a trained machine learning model such as a natural language processing model or a classifying model to identify relevant features or metrics from the medical records. In other implementations, extracting compliance data may include formatting data from the medical records into a useful format or structure for data processing. Additionally or alternatively, if the relevant medical records include image or video data, extracting compliance data may include performing image processing on the image or video data to identify features in the image or video data. Image processing may include providing the image or video data to a trained machine learning model configured to classify images or video data. For example, in the case of a pressure injury risk evaluation, image data showing the patient’s skin on arrival and at later times may indicate the development of a pressure injury. An advantage of such extraction or classification of compliance data, whether it be text, image, video, or numerical data, is that when adverse health events to the patient or a related noncompliance from the healthcare provider are detected early enough, preventative measures may be undertaken, sparing the patient potential pain and saving costs of further treatment.

[0070] At block 208, the compliance data is compared to the one or more compliance thresholds. At decision diamond 210 it is determined whether the compliance data has crossed the compliance threshold. The determination of whether the compliance threshold has been crossed may include exceeding a compliance threshold for some compliance policies and thresholds, or falling below a compliance threshold for other compliance policies and thresholds. If the threshold has not been crossed, then at block 212 no alert is generated. In some implementations, the dataflow process 200 may then terminate. Alternatively, in some implementations, medical records and compliance data may continuously be monitored, extracted, and compared until a threshold is crossed, or until the system 100 is instructed to terminate data operations.21301575526

[0071] If, at decision diamond 210, the threshold has been crossed, a routine to generate an alert is triggered at block 214. The alert generated may include a notification that the threshold has been crossed and / or that a noncompliance has been detected. Generating the alert may include correlating the compliance threshold with one or more recommended actions that the healthcare provider may take to be in compliance. The recommended actions may vary based on the noncompliance or on the type of risk of an adverse healthcare event that may be indicated by the noncompliance. Generating the alert may include generating a report of the non-compliance(s) in a readable format. Generating an alert may be done for each compliance threshold of the one or more compliance thresholds that was crossed.

[0072] At block 216 the alert or alerts may be sent to the healthcare provider. Sending the alert may include one or more of transmitting the alert to one or more devices of the healthcare provider over a network (e.g., the network 130). The alert may be sent as a notification message such as an email, SMS, MMS, or a push notification. Additionally or alternatively the alert may be generated within an application or a website. The alert may additionally or alternatively include a report of the noncompliance detected. The alert may include one or more recommended actions for the healthcare provider to take to be in compliance with the compliance policy. Sending the alert to the healthcare provider may include sending an instruction to a nurse or medical staff of the healthcare provider to perform the one or more recommended actions. Additionally or alternatively, sending the alert to the healthcare provider may include sending the alert to a manager of the healthcare provider, such as a shift lead, nurse manager, or a clinical coordinator. After the alert is sent, in some implementations, the dataflow process 200 may then terminate. Alternatively, in some implementations, the system 100 may run the dataflow process 200 to continuously monitor, extract, and compare medical records and compliance data until another threshold is crossed, causing another alert to be generated, or until the system 100 is instructed to terminate data operations.

[0073] When the alert is sent and at any point of the data operations described herein, data may be encrypted in order to protect patient privacy and healthcare provider privacy, and to comply with applicable health and privacy laws. Access to the systems described herein, as well as to medical records, alerts, and so on, may be restricted and password protected to preserve patient and healthcare provider privacy. In some implementations, patient data or healthcare provider data may be anonymized. Different levels of anonymity may be implemented so that individuals with a need for greater access may have access to personal or sensitive information, but such information would not be available to individuals without the need to access it.22301575526

[0074] FIG. 3 illustrates an example method 300 of preventing adverse health events to a patient which can be performed by any of the system(s) disclosed herein. The method 300 may include or correspond to the dataflow process 200 described above. At block 302, the method includes monitoring, by one or more processors, medical records for a patient. The medical records for the patient may include one or more medical charting records for the patient. In some implementations, the medical records may indicate a risk of occurrence of an adverse healthcare event to the patient. For example, the medical records may include data indicating a patient’s susceptibility to a pressure injury, a risk of infection such as a catheter associated urinary tract infection, an IV line infection, or a risk of some other adverse healthcare event. The medical records may include data corresponding to a medical condition of the patient. For example, the data may include one or more of a fall risk data, a patient mobility data, a patient psychological data, a patient safety risk data, a capnography record, a medication administration record, or some combination thereof. The medical records may also include or correspond to one or more compliance metrics for the healthcare provider. For example, a compliance metric may include one or more of the compliance metrics discussed herein. In some implementations, a compliance metric may include documentation compliance, where the compliance metric includes documentation data measured against an expected standard of care.

[0075] At block 304, the method includes determining, by the one or more processors, compliance of a healthcare provider of the patient with one or more compliance metrics. The one or more compliance metrics may correspond to reducing a risk of occurrence of the adverse healthcare event. As a nonlimiting example, the one or more compliance metrics may include data corresponding to the position of a patient relative to a planar surface (e.g., relative to a bed, chair, wheelchair, operating table, and so on). As a further example, the data indicating the risk of occurrence of the adverse healthcare event to the patient may include data corresponding to how frequently the position of the patient was changed relative to the planar surface. This data may indicate when the position of the patient was changed by the healthcare provider, by the patient, or by another. The data corresponding to the position of the patient may include one or more of a plurality of predetermined positions relative to the planar surface. For example, the plurality of predetermined positions may include supinated (e.g., positioned on the patient’s back), pronated (e.g., positioned on the patient’s front), turned to the right, turned to the left, sitting up in a chair, sitting up on a wheelchair or other mobility device. For simplicity of reporting, the plurality of predetermined positions may be limited to the following: turned to the left, turned to the right, or supinated. This may be charted, in some instances, as T - L, T - R, and T- S, respectively. Timestamps of when a patient’s position changed may be included in the medical records.23301575526

[0076] At block 306 the method includes generating, by the one or more processors, a notification based on whether the one or more compliance metrics exceed one or more compliance thresholds, the notification including one or more recommended actions for the healthcare provider. The one or more recommended actions will vary based on the particular compliance metric in question, and may be based at least in part on whether the action is to provide care to a patient (e.g., treatment or preventative care) or to improve performance of the healthcare provider, or both. Examples of actions that could be recommended include repositioning the patient, providing a medication to the patient, treating the patient’s skin with an antiseptic, debriding a pressure injury, treating the patient’s skin with a skin barrier, generating a report of compliance for the healthcare provider, generating a reminder to the healthcare provider to provide treatment to the patient, providing training for the healthcare provider, or a combination thereof. Some actions that may be recommended may be more of an immediate reminder or alert to perform treatment of some sort to a patient. For example, recommending that a patient be repositioned to a new position may need to be performed right away to alleviate discomfort and help the patient avoid risk of developing a pressure injury. Other actions may be performed less immediately. For example, a recommended action to provide training to the healthcare provider on one or more compliance metrics may transmitted in an email or as part of a regular report to a manager of the healthcare provider without prompting immediate action from a patient care perspective.

[0077] At block 308, the method includes providing the notification to the healthcare provider. Providing the one or more recommended actions to the healthcare provider may include one or more of displaying the one or more recommended actions at a user interface, generating an alert with instructions to perform the one or more recommended actions, sending a digital message to a device of the healthcare provider, generating a graphical representation of the compliance metrics, generating a text or an icon presented on a user interface (e.g., a touch screen or other GUI), illuminating an LED indicator, generating an audio alert via an external speaker, or a combination thereof.

[0078] In some implementations where the compliance metrics include data corresponding to the position of the patient, and the position can be one of a plurality of predetermined positions, the plurality of predetermined positions may include a first position, a second position, and a third position. In such implementations, the data corresponding to the position of the patient may indicate indicates that at a first time the patient was positioned in one of the first position, the second position, or the third position, and that at a second time the patient was positioned in another one of the first position, the second position, or the third position. In other such implementations, the data corresponding to the position of the patient may indicate that at a first time the patient was positioned in one of the first position, the24301575526second position, or the third position, and that at a second time the patient was positioned in the same position one of the first position, the second position, or the third position. In other words, the body position of the patient was not changed within the time frame for complying with a policy for how frequently the patient is repositioned. In some such implementations, the notification may include an alert with instructions to reposition the patient to a different position of the plurality of predetermined positions.

[0079] According to some aspects, the patient may be one of a plurality of patients. In some such implementations, the medical records may include a plurality of medical records. For example, the medical records may include medical charting records. In some such implementations, each patient of the plurality of patients may be associated with at least one of the plurality of medical charting records. Indeed, a system such as has been described herein may be advantageous in managing a healthcare provider’s compliance with respect to several patients, as with increasing numbers of patients the burden of managing the healthcare provider grows significantly.

[0080] FIG. 4 illustrates an example user interface 400 for a system for preventing adverse health events to a patient including data visualization tools and selectable elements according to aspects of the disclosure. User interface 400 may include one or more selectable elements 402 for interacting with one or more categories of data. For example, in the illustration of user interface 400, the selectable element 402 is shown as presenting a main page, or an overview page of a graphical user interface. Other elements of the user interface 400 include a search bar 404, slider filters 406 for filtering aspects of the data presented (e.g., by ranges of dates or years, by score on the Braden Scale, by frequency of patient repositioning, and so on), and selectable drop down menus 408. User interface 400 may include one or more data visualization tools, such as line graph 410, bar graph 412, and data table 414, data table 416, data table 418, selectable elements 420, and selectable elements 422. Other elements may be included in user interface 400 as would be recognized by one of ordinary skill in the art, including for example, user input fields, type boxes, check boxes, radio buttons, icons, buttons, toggle switches, toolbars, breadcrumbs, forms, menus, scroll bars, and the like.

[0081] In the example of user interface 400, the line graph 410 represents the median time in minutes between the arrival of a patient and the patient’s assessment under the Braden Scale, broken out between different units (e.g., departments) of a healthcare provider. Bar graph 412 represents a median rate of applying a skin barrier (e.g., a lotion) to the skin of a patient based on how moist the patient’s skin is. Data table 414 represents a general mobility for patients in the separate units of the healthcare provider. Data table 416 represents a patient’s assessed Braden score by the hour in which it was recorded. Data table 418 represents an aggregation of several medical records of patients and / or the healthcare25301575526provider. For example, one aggregation technique which may be employed is an average of a compliance metric over a period of time for a unit of the healthcare provider. Any of these data items may include or correspond to one or more compliance metrics. Data may be provided in a raw format, as in the data tables 414 to 418. Or the data may be filtered, processed, or presented in an easier to digest way, like through a visualization tool.

[0082] In the example of FIG. 4, the data table 414 and the data table 416 shown on the main page of user interface 400 provide columns that can be lined up to compares mobility documentation for patients within two different scales. In some instances, completing such documentation scales may be mandatory (e.g., required under a compliance policy of a healthcare provider) for every nurse, every shift. In this example, the point of comparing such metrics is to make sure that patient mobility is graded uniformly and consistently within the same assessment. What is often found is that documentation is not congruent even within the same assessment, which may cause a contradicting documentation. Incongruent and conflicting documentation does not speak to the expected standard practice of having a thorough and accurate assessment documented by each nurse. Accordingly, the tools and tables illustrated in user interface 400 may serve to verify that best practices are being performed consistently and documented accurately.

[0083] Selectable elements 422 may include elements for filing data representations (e.g., to a memory of the computing device), exporting the data, sharing the data or the visualization tools, and other administrative or data manipulation tasks. Of particular note is element 424, which allows a user to set an alert for any of the compliance data. Such an alert may include one or more compliance thresholds, and may allow the user to set the compliance threshold. A user may also be able to use the element 424 or an associated tool to configure the alert to include one or more recommended actions associated with the compliance metric. For example, the recommended action(s) may include actions to aid the healthcare provider in complying with a compliance policy or in providing better treatment of a medical condition of the patient.

[0084] FIG. 5 illustrates an example user interface 500 for a system for preventing adverse health events to a patient, including a visualization of data indicating patient body position. User interface 500 may include similar elements and function similarly to user interface 400. Additionally, user interface may include different elements from user interface 400. Selectable element 502 is shown as presenting an interface page corresponding to patient body position. Selectable element 504 illustrates that one or more filters may be applied to view different aspects of the patient body data (although in this example, no filters are shown as currently selected). Examples of filters may include filters by units of a healthcare provider (e.g., nursing units or medical practice groups), filters by date, filters by compliance with a compliance26301575526threshold, filters of actions that have been recommended, and so on. Histogram 506 represents a rate of turns as a percent of the number of shifts for patients with a Braden Score of 18 or less. This represents how frequently patients are repositioned to a different position relative to a bed, chair, and so on. As a note, the jump in the repositioning frequency data for the histogram 506 correlates to experimental data from implementing a system such as has been disclosed herein, showing that an increase in consistent and timely repositioning of patients resulted from implementing the system. Data table 508 may show the same or similar data to histogram 506 in a textual format. Other metrics and data for patient body position may be included, such as metrics for average time a patient is up in a chair per shift of a healthcare provider as shown in graphical display 510 and data table 512, or the rate of patient repositioning (e.g., turning) as a percent of body position documentation completed. In some instances, data for one or more metrics may be displayed in relation to one or more other metrics, such that relevant relationships may be identified between metrics. For example, documenting metrics showing the relationship between a number of “up in chair times per shift” vs a number of “turns per shift” may highlight that some care units of a healthcare provider (e.g., ICU units) may have a higher turn rate and a lower amount of ambulation or up-in-chair rates, while other care units (e.g., medical / surgery units) may have a lower turn rate but a higher ambulation and / or up-in-chair rate. Displaying data for one or more metrics in relation to one or more other metrics may aid in identifying actions that may be particularly effective in providing treatment to patients, improving one or more compliance metrics, or bringing the healthcare provider into compliance with a compliance policy. In some instances, the several compliance metrics may enable more precise application of standards of care to individual units of the healthcare provider. Other metrics may be monitored as would be understood by one of ordinary skill in the art.

[0085] FIG. 6 illustrates an example user interface 600 for a system for preventing adverse health events to a patient, including a visualization of data indicating skin protection measures. User interface 600 may include similar elements and function similarly to user interface 400 or user interface 500. Selectable element 602 is shown as presenting an interface page corresponding to skin protection metrics. Patients for whom Bl PAP, high flow oxygen cannulas, and similar devices are ordered may experience pain or irritation at pressure points of the face, such as the bridge of the nose, which may be pressured by the respective masks and / or tubing of such equipment. Skin protection metrics may enable a healthcare provider to ensure the patient is given adequate treatment to keep skin clean and dry, well moisturized, and without unnecessary pressure or irritation. Skin protection metrics may include a rate at which padding is provided to a Bl PAP area of the patient among patients for whom Bl PAP treatment has been ordered, as illustrated by line graph 604. Skin protection metrics may27301575526include a rate at which padding is provided to a high flow cannula area of the patient among patient for whom high flow cannula use has been ordered, as illustrated by line graph 606. Other examples of skin protection metrics may include how frequently bedding for the patient is changed, whether and how frequently a skin barrier (e.g., a lotion, petroleum jelly, a cream, and so on) was applied to an area of a patient’s skin, how frequently the patient was monitored for signs of skin irritation, how often padding (e.g., cushions or heel wedges) was provided to the patient, and how long after one or more treatments was provided before the treatment was documented.

[0086] FIG. 7 illustrates an example user interface 700 for a system for preventing adverse health events to a patient, including a visualization of data indicating patient skin health assessment. User interface 700 may include similar elements and function similarly to any of the user interfaces of FIGS. 4 to 6. Selectable element 702 is shown as presenting an interface page corresponding to patient skin health assessment. User interface 700 illustrates metrics of when a bedside shift report (BSSR) was documented, including a metric of whether two nurses (e.g., RNs) assessed the patient’s skin during a change of shifts for at-risk patients (e.g., patients with a Braden score of 18 and under). When multiple nurses assess patient skin during shift changes it can prevent missed skin evaluations and help a healthcare provider provide treatment to prevent pressure injuries, irritation, or other such skin damage to the patient. For example, data visualization tools 704, 706, and 708 present data as unit-level averages of documenting that two nurses (2RN) performed the BSSR skin assessment at shift changes for multiple units of a healthcare provider. The metric in use in this example is the average percent of times “yes” was documented for the BSSR 2RN skin assessment within a certain time period after a shift change (e.g., between 6 AM and 8 AM for a shift that started at 6 AM or between 6 PM and 8 PM for a shift that started at 6 PM). A mnemonic for an example best practice, which may be implemented as a compliance policy by a healthcare provider, is “4 eyes in 4 hours” and may include having two nurses perform a full-body skin assessment on a patient within 4 hours of admission to a hospital, with a goal of reducing the occurrence of hospital-acquired pressure injuries (HAPIs).

[0087] FIG. 8 illustrates an example user interface for a system for preventing adverse health events to a patient, including a visualization of data indicating timing of patient skin health assessment and documentation. User interface 800 may include similar elements and function similarly to any of the user interfaces of FIGS. 4 to 7. Selectable element 802 is shown as presenting an interface page corresponding to timing of patient skin health assessment and documentation. A compliance metric that may be useful to a healthcare provider is an amount of time between admitting a patient and performing an assessment of the patient. Lower times between admitting a patient and assessing the patient may result in28301575526more effective care, greater patient satisfaction, and / or more efficient use of healthcare provider resources and time. More rapid documentation of the time between admittance and assessment may provide similar benefits and allow for real-time or near real-time responsive actions by the healthcare provider. In the example of FIG. 8, metrics corresponding to amounts of time between patient arrival and an assessment (e.g., a Braden Scale assessment and Braden score entry) for different units of a healthcare provider are presented in data visualization tools and data charts.

[0088] FIG. 9 illustrates an example user interface 900 for a system for preventing adverse health events to a patient, including a visualization of data indicating timing of patient skin health assessment and documentation. User interface 900 may include similar elements and function similarly to any of the user interfaces of FIGS. 4 to 8. Selectable element 902 is shown as presenting an interface page corresponding to timing of patient skin health assessment and documentation (e.g., documentation lag). Metrics of the amount of time it takes a healthcare provider to document that a patient was assessed (e.g., relative to a shift start time) can be helpful to the healthcare provider and can provide a data-driven means for improving healthcare provider performance. For example, reducing the time between a start of a shift and documenting initial patient assessments may result it more effective care, improved cost efficiency for both patient and healthcare provider, greater patient satisfaction, and / or more efficient use of healthcare provider resources and time. By risk stratifying patients before initiating prevention guidelines, healthcare providers may be able to target high-risk patients and avoid superfluous spending on prevention for patients at low risk for developing a pressure injury. As such, it may be advantageous to track documentation lag over long periods of time (e.g., over several months or years) and over shorter periods of time (e.g., days to weeks).

[0089] Such metrics may improve healthcare provider performance in both the short and long term. Short term data may provide a healthcare provider with insights into how quickly compliance policies, training, or reminders take to start seeing a difference in the healthcare provided. A goal compliance metric may be to complete documentation as close to real time as possible. An advantage of such speedy documentation is that it may trigger alerts to initiate prevention measures earlier, which can allow a healthcare provider to improve patient care more quickly. Longer term data analytics may give a healthcare provider insights into how effective compliance policies, training, or reminders are in generating a consistent or improving performance over time. Similar motivations may also apply to data analytics of other compliance metrics as described herein.

[0090] FIG. 10 illustrates an example user interface 1000 for a system for preventing adverse health events to a patient, including models and data flow diagrams for monitoring29301575526patient health data, generating alerts, and recommending healthcare provider actions. User interface 1000 includes a plurality of selectable elements 1002 which may function similarly to at least some of the selectable elements described above with respect to FIGS. 4-9. User interface 1000 may include one or more selectable elements 1004 configured to generate a new item. Such an item may include one or more of a compliance metric, a compliance threshold, an alert configuration, a scorecard configuration, a scorecard, an alert, a monitoring model, a folder, a template for one of the above, some other data item, or a combination thereof. A user selecting selectable element 1004 may have an option to create a new item using tools available within the user interface 1000. Additionally or alternatively, a user may be able to upload a preexisting item stored locally (e.g., in a memory of a computing device) or download a preexisting item over a network connection.

[0091] User interface 1000 may display representations of data structures or models, including system monitoring model 1010, alert generation model 1020, and scorecard generation model 1030. The data structures and models illustrated in FIG. 10 may include, correspond to, and / or be included in the alert generating engine 120 described herein. System monitoring model 1010 may include functionality to receive data from a data source, identify within the data one or more metrics corresponding to a compliance with a compliance policy (which may include extracting the relevant features from the data), and monitor the one or more metrics. System monitoring model 1010 may provide the data or at least the monitored metrics to alert generation model 1020 and / or scorecard generation model 1030. Alert generation model 1020 may be configured to generate alerts, including providing recommended actions to a healthcare provider. Scorecard generation model 1030 may be configured to generate scorecards, including providing indications of healthcare provider performance with respect to compliance metrics and / or goals within a period of time.

[0092] An alert may be conceptualized as an indicator of an urgent action to be undertaken by the healthcare provider. For example, in the case where a compliance policy requires that a patient with a Braden score of 18 or less be repositioned to a different position every two hours, an alert may be generated and provided to the healthcare provider if the patient was not repositioned to a different position within the previous two hours (or if it has not been documented within two hours that the patient was repositioned to a different position). In this example, the alert may include the recommended actions of repositioning the patient to a different position and documenting that the repositioning happened. An alert in this sense may serve as a reminder of an action to be taken right away by the healthcare provider, or as an activator of one or more notification systems.

[0093] A scorecard may be conceptualized as a report of performance over a period of time, including one or more goals and progress made towards achieving the one or more30301575526goals. Scorecards may also include actions to be taken by the healthcare provider to improve performance, including, for example, providing training to units or individuals on compliance with one or more compliance policies, recognizing high performing individuals or units, changing a goal, changing a compliance threshold, and so on. The distinction between an alert and a scorecard need not be too stringent, as both may make use of the same data and serve to improve a healthcare provider’s performance in treating patients. Furthermore, a scorecard may include reports of the number of alerts generated over a period of time for one or more compliance metrics.

[0094] Alert generation model 1020 may include a plurality of compliance thresholds 1022, shown here as thresholds 1 through N. Each of the plurality of thresholds may correspond to one or more of the compliance metrics provided by the system monitoring model 1010 to the alert generation model 1020. The several thresholds may correspond to different metrics for compliance with different compliance policies. For example, a first threshold may be set for a first compliance policy, and a second threshold may be set for a second compliance policy. A healthcare provider may be in compliance with a compliance policy once the compliance metric meets or exceeds the corresponding threshold. Alternatively, the healthcare provider may be in compliance with the compliance policy until the compliance metric meets or exceeds the corresponding threshold. Individual thresholds may be set for each of the relevant compliance metrics and compliance policies. Additionally, individual thresholds may be set or determined for each unit of the healthcare provider. A threshold corresponding to a particular compliance metric may be the same or different for each unit of the healthcare provider.

[0095] Alert generation model 1020 may include a plurality of alert triggers 1024, and each alert trigger of the plurality of alert triggers 1024 may correspond to a respective compliance threshold of the plurality of compliance thresholds 1022. Once a compliance metric crosses the relevant compliance threshold, such that the healthcare provider is no longer in compliance with the compliance policy with respect to that compliance metric, an alert may be triggered by the corresponding alert trigger. Triggering the alert may include generating the alert and sending or otherwise providing the alert to the healthcare provider. For example, the alert may be provided in the same or similar manner to operations that have been described herein (e.g., with respect to FIGS. 1 through 3).

[0096] Scorecard generation model 1030 may include a plurality of goals 1032, shown here as goals 1 through M. Each goal of the plurality of goals 1032 may correspond to one or more of the compliance metrics provided by the system monitoring model 1010 to the scorecard generation model 1030. Each goal of the plurality of goals 1032 may be provided to a respective scorecard model, such that a plurality of scorecards 1036 may be generated. A scorecard may include a report of whether the goal was met, as well as a report over a31301575526period of time for how well the goal was met in that period of time. For example, a scorecard may be generated for a goal and provided to the healthcare provider weekly, biweekly, monthly, quarterly, annually, or at some other regular period of time. A scorecard may include both the respective goal and cumulative rates of goal achievement up to the date that the scorecard was generated. While illustrated here as multiple scorecards 1036, with one scorecard for each of the plurality of goals 1032, it is understood that in some embodiments multiple goals and performance in reaching the goals may be all combined and reported together into a single scorecard. In some embodiments, some, but not all of the goals may be combined and reported together in a scorecard. A scorecard may be provided to a leader of the healthcare provider to identify areas for improvement or to evaluate performance of the healthcare provider, a unit of the healthcare provider, or an individual.

[0097] In some implementations, one or both of the alert generation model 1020 and the scorecard generation model 1030 may be included in the system monitoring model 1010. In such implementations, the view shown in user interface 1000 would represent a breakout of the functionality of the alert generation model 1020 and / or the scorecard generation model 1030 within the system monitoring model 1010. In some implementations, the alert generation model 1020 and / or the scorecard generation model 1030 may be expandable or collapsable elements of the user interface 1000.

[0098] Machine learning or artificial intelligence may be advantageously employed in any or all of the system monitoring model 1010, alert generation model 1020, and scorecard generation model 1030. For example, machine learning tools may enable greater automation in the creation of alerts or scorecards, as machine learning tools may be configured to generate alert or scorecard configurations based on similar parameters or goals for each of a plurality of compliance metrics. In some instances, machine learning tools may enable the system monitoring model 1010 to identify and monitor relevant compliance metrics from the data based on the compliance policy or policies. In some instances, machine learning tools may generate alert and / or scorecard parameters based on the compliance policy. A user may instruct a machine learning tool to create a set of alert configurations or scorecard configurations for each unit of the healthcare provider without the need to manually configure each configuration. This may reduce the time of manually configuring the alert and scorecard generation models for each unit of the healthcare provider, especially when a large number of metrics is captured or when a healthcare provider has many units or subunits to manage. It may also reduce the potential for human error in configuring alerts and scorecards.

[0099] An advantage of the systems, methods, user interfaces, and computer readable media described herein is that not only may they provide tools to bring a healthcare provider into compliance with one or more compliance policies, but they may also be used to identify32301575526errors and discrepancies in medical records. For example, if a nurse documented that a patient had a generalized weakness in one area of the assessment documentation for the patient, but also documented “no limitation” within the Braden score of the same assessment documentation, that would be a contradicting documentation and a gap in practice. It may also indicate an incorrect Braden score, which may lead to a gap in the implementation of preventive measures for pressure injuries if the Braden score is documented as higher than it should be. For some inconsistencies or discrepancies, an alert indicating the discrepancy may be generated when the discrepancy is identified. In other implementations, a user may not be allowed to enter contradictory piece of data to the system.

[0100] The systems, methods, user interfaces, and computer readable media described herein may be deployed in a manner that is consistent with a methodology of regular, consistent, and persistent training and education of a healthcare provider. Alerts and notifications serve this methodology by providing regular and timely reminders of recommended actions. Scorecards further aid in consistent training by providing metrics for improvement over the long term, and by identifying areas of weakness in a healthcare provider’s performance that may be addressed by further training. Monitoring of data and generating notifications, whether as an alert or as a scorecard may allow a healthcare provider to better meet compliance requirements, including legal requirements, ethical requirements, and internal goals. In many cases, when performance is measured, performance improves, and when performance is measured and reported, the rate of performance accelerates. A benefit of such systems as have been described is that they may facilitate a more productive mindset for healthcare providers toward performance metrics and patient care, because regular and consistent self-auditing and reminders of compliance policy may promote a data-driven supportive culture of regular and consistent performance within a compliance goal.EXPERIMENTAL RESULTS

[0101] FIG. 11 illustrates experimental data indicating successful reduction of adverse health events in patients using a compliance metric system such as has been described herein. The experimental data is presented in graph 1100. Graph 1100 illustrates exemplary experimental data indicating increased internal event reporting and subsequently a reduction of adverse health events in patients. In the example of graph 1100, the adverse health events included pressure injuries, but other adverse health events such as have been described herein may be similarly monitored in accordance with other implementations of this disclosure. In the experiments, compliance policies similar to those described herein were put in place for five units 1102 of a healthcare provider, listed here as “10 Orange Med / Surg,” “3 Orange NSICU,” “6 Orange Med / Surg,” “8 Blue,” and “9 Orange Neurosurgery.” Over the course of two years, 2023 and 2024, the units of the healthcare provider monitored the pressure injuries33301575526for their patients and reported whether pressure injuries occurred. Patients were assessed to determine whether they were arriving with a pressure injury already. The number of hospital acquired pressure injuries (HAPIs) was also monitored. Pressure injuries are categorized into six stages of severity, from stage 1 to stage 4, plus deep tissue injury and unstageable, summarized below in Table 1. The severity of a pressure injury is associated with increased treatment costs, length of stay, and risk of mortality.

[0102] When a HAPI occurs with a severity of stage 3 or more it is required to be reported to the Centers for Medicare & Medicaid Services (CMS) per CMS guidelines. Accordingly, in the experiments, the number of stage 3 or higher severity HAPIs was tracked for the units along with the total number of pressure injuries. In 2024 a compliance system such as has been described herein was implemented and intervening training was provided. The compliance system was configured to monitor the healthcare provider’s compliance with the compliance policies over the year 2024. The occurrence of HAPIs in patients over the year 2024 was also tracked. Using the tools and systems described herein, the units of the healthcare provider generally saw a significant decrease in total HAPIs and in reportable HAPIs in 2024 compared to 2023, before the compliance policies and training were put in 34301575526place. These results are summarized in Table 2 and in the graph 1100 of FIG. 11. The data for 2023 is complete for all 12 months. The event reporting data for 2024 is through December 13, 2024, so the last 2 weeks of December 2024 are not included. The graph 1100 illustrates the total number of pressure injuries in 2024, separated by whether the injuries were present on the patient’s admission or HAPIs. The total number of HAPIs in 2023 and 2024 shown in FIG. 11 are also reflected in the first and second column of Table 2.

[0103] To summarize Table 2, using the compliance system, tool, and methodology in 2024 generally resulted in higher awareness by staff of the healthcare provider, as evidenced by a higher number of total number of HAPIs via event reporting. Three of the five units showed a significant increase in event reporting for both the pressure injuries on admission as well as the hospital acquired ones. One unit (3 Orange) had the exact same number of event reporting, and the other unit (10 Orange) reported six fewer events in 2024. Neither unit had a higher number of reportable HAPIs for 2024; 10 Orange only had two again for 2024 and 3 Orange decreased from five to one reportable HAPIs. This reflects the increased awareness by staff as only one pressure injury progressed to above a stage 3.

[0104] The total event reporting (both present on admission and acquired in the hospital) by the five units combined totaled 421 events in 2023. The event reporting number increased to 531 for 2024. This indicates that staff were more aware of requirements to complete35301575526assessments and to report appropriate findings, which led to a greater incidence of implementing appropriate interventions to prevent further injury. This is at least a 20% increase in event reporting by staff for 2024. Internal event reporting is reviewed by Patient Safety department in hospitals for the purpose of process improvement. These events are also reviewed by leadership. Since the impact of increased event reporting extends to Patient Safety department and the leadership within healthcare organizations, this leads to the possibility of a closer look and implementation of safe practices.

[0105] Event reporting was performed mainly by nurses, especially for skin-related events. Even though there were a higher number of stages 1-2 pressure injuries reported in 2024 during the use of the disclosed tool and methodology, the total number of reportable HAPIs (stage 3 and above) from all units combined decreased from 23 to 14. This is a 40% reduction in reportable HAPIs. HAPIs are categorized as “never events” by CMS due to their overall impact to patient outcomes and subsequently the possible financial implications for healthcare organizations. While correlation does not necessarily mean causation in terms of reportable HAPIs, it is evident that the results yielded on the units using this tool and methodology were improved for all units compared to when the tool and methodology were not being used.

[0106] Similar results were achieved in a separate study for a unit of a healthcare provider in 2019 and 2020, the results of which are summarized in Table 3 below. In the table 3 below, the 2019 column shows data prior to implementing a compliance policy, including auditing and training. The number of event reporting more than tripled with increased awareness in 2020. However, the number of reportable HAPIs (stages 3 and above) was zero. In 2020, there were a total of 13 pressure ulcers (all stages) reported but zero were reportable (stages 3 and above). In 2019, there were a total of 9 pressure ulcers reported, but 4 of those were reportable (stages 3 and above). There may also be possible under reporting when no standardized use of interventions such as has been described is in place. The general trend and observation is as follows: there tends to be an increased number of skin events reported — reflective of true data — with the use of interventions and training in line with the methodology discussed herein, but there tends also to be a significantly decreased occurrence of reportable skin HAPIs.36301575526

[0107] In short, with increased awareness, it is expected to see a higher number of skin care events reported and a more accurate count of total pressure injuries. However, with higher awareness, the data shows that overall there was a significantly lower number of serious, reportable HAPIs.

[0108] The objective of the experiments was to cross-validate that the use of an audit tool (e.g., the systems and methods described herein) and other specific interventions had a positive impact on increasing nursing practice compliance with turning documentation on units with different levels of care. A 400% baseline rate was set as the policy expectation for turning patients every 2-3 hours during a 12-hour shift. To clarify, this rate implies the patient was turned every 2-3 hours around the clock. Compliance was also considered met with turn rates in the 300%-400% range (e.g., every 3-4 hours) when patients were able to mobilize out of bed. Rates proved to be different for the different levels of care of different units of the healthcare provider. For example, intensive care units (ICUs) tended to have higher turn rates due to the lower mobility level of patients during the critical time period. Med-surg units where patient populations had greater mobility, had turn rates in the 300th% range but still improved or maintained their lower number of reportable HAPIs.

[0109] The rates at which patients were repositioned (e.g., turning rates) were tracked before and after intervention training was provided to the departments (e.g., units) of the healthcare provider. A statistical analysis of the turning rates for each unit was performed to determine significance of training the departments of the healthcare provider to document turning patients to specific predetermined positions (e.g., turned left, turned right, or supinated). The analysis report demonstrated that all units had an increase in turning documentation compliance that surpassed the initial expectation of a 13% increase based on previous scholarly work.

[0110] The analytic auditing tool was created based on clinical knowledge. Novelty elements added to the tool included monthly scorecards automated for bi-monthly delivery to unit leaderships as well as the addition of data-driven triggers. The triggers were automated37301575526to inform unit leaderships when the data dropped below compliance level (e.g., a compliance threshold). The data audited for this experimental analysis included turning documentation entries from 5 different units. The number of documentation entries audited by the analytic tool varied by unit and ranged from 5,000+ to 18,000+ per month. Content guidance for the analytic tool was provided to a programmer analyst.

[0111] The experiment included an intervention. The intervention included a uniform and systematic way of delivering education, audit results, and reminders. Information was first delivered via a staff meeting and through email communication. Data was shared monthly with staff using a visual graph of audit results, education points, and reminders via and with the use of email trigger reminders from the analytic tool. An education module was in assigned to all units during the first month of intervention period of which a 77%-96% completion rate was noted within the units by the 3rd month. The education module included general teaching points about the organizational protocol for pressure injury prevention, Braden scoring education, as well as the standardized, specific, and expected manner to document turning.

[0112] The importance of clinical practice compliance and the many aspects of a patient’s hospital stay that affect patient care are discussed in the following article, which is incorporated herein by reference it is entirety: Duran, Laura, “DNP Final Report: Practice Change Compliance” (2021). DNP Final Reports. Paper 26. http: / / hdl.handle.net / 10950 / 3751

[0113] The statistical analysis included a paired t test to test whether there was significant improvement of turning rate after using the above described turning documentation. The variables were defined as follows:• Pre-intervention average rate: (base line) the 6 months average before each department’s intervention start month.• Post-intervention average rate: the 6 months average after each department’s intervention start month.• Null Hypothesis ( / 70): The average pre-lntervention turning rate is not equal to postintervention turning rate. Therefore, it is hypothesized that the intervention has no effect on the turning rates.• Alternative Hypothesis ( / - / ?): The average pre-lntervention turning rate is not equal to post-intervention turning rate. Therefore, it is hypothesized that the intervention has a statistically significant effect on the turning rates.

[0114] The results of this statistical analysis are reproduced below in Table 4 and Table 5.38301575526

[0115] The relative increase shown in Table 5 is relative to the 400% turn target goal. The 400% target turn goal reflects a cumulative average unit turn frequency of every 2-3 hrs per organizational policy. If we were to grade compliance on a 100% goal scale, the results translate into individual unit rate increases of a minimum of 16% to a maximum of 72% post use of the tool.

[0116] The paired t-test results (p-value < 0.05) indicate that the intervention had a significant effect on the turning rates. It suggests that the intervention effectively increased the turning rates.

[0117] In some examples, the disclosed framework has been evaluated across multiple clinical units in a hospital setting under an approved quality-improvement protocol, demonstrating that automated, event-driven auditing at scale is feasible and effective. The system was integrated with an electronic medical record platform to ingest and analyze large volumes of documentation entries, with typical monthly loads ranging from approximately five thousand to eighteen thousand entries per unit. This scale of ingest enables near real-time identification of non-compliance and timely feedback to care teams without requiring labor-intensive manual audits.

[0118] The automated auditing and feedback approach has been applied beyond pressure injury prevention to additional clinical domains including ambulation and early mobility, catheter-associated urinary tract infection prevention, central line bundle adherence, hand hygiene, basic hygiene practices (such as bathing, oral care, and perineal care), sitter documentation for non-suicidal observation, medication timing and reconciliation, delirium bundle adherence, dysphagia screening, venous thromboembolism prophylaxis, head-of-bed elevation, oral care frequency for pneumonia prevention, pain reassessment, response to39301575526critical laboratory results, antibiotic re-dosing, sepsis screening completion, isolation precautions, intravenous site assessment, stroke bundle elements, heel offloading, nutrition screening, moisture management, transfusion verification, discharge education, removal of unnecessary lines and tubes, hourly rounding, specimen labeling accuracy, alarm response, and other safety and quality metrics. In these embodiments, the platform ingests relevant structured and unstructured data, extracts process metrics aligned with published guidelines, and applies domain-specific thresholds to generate actionable outputs.

[0119] Consistent with these multi-domain applications, the system supports a unified taxonomy of actions to drive practice-change compliance, including audit functions to measure adherence to process metrics, timely reminders to prompt corrective actions, education modules to standardize documentation and technique, and engagement mechanisms that provide scorecards and trend visualizations to unit leadership. By standardizing documentation fields and reinforcing best practices with persistent, data-driven prompts, the system facilitates congruent documentation across assessments and reduces gaps that can adversely impact patient outcomes.

[0120] Empirical evaluation of the framework has shown that automated auditing and standardized documentation prompts are associated with increases in compliance for turning documentation within clinical units, with observed post-implementation improvements ranging from moderate to substantial across different levels of care. Statistical analyses of pre- and post-implementation periods support the conclusion that the intervention improves the likelihood of meeting turning goals, including evidence of significance using a paired comparison test and a categorical test of goal attainment. In one set of evaluations, turning compliance increased across all studied units, and facility-reported outcomes indicated a decrease in severe, reportable hospital-acquired pressure injuries following sustained use of the auditing and intervention tool, even as total event reporting increased due to heightened staff awareness and standardized documentation practices.

[0121] When applied in a pressure injury prevention context, standardized documentation of patient repositioning (for example, recording “turned” with a specific position designation such as left, right, or supine at compliant intervals) contributes to early detection of non-compliance and triggers actionable guidance. The resulting alerts and scorecards enable unit leaders to initiate focused education and workflow adjustments, while the platform’s analytics provide continuous visibility into trends and correlations between process adherence and outcome metrics. Collectively, these embodiments demonstrate that automated, event-driven auditing, combined with structured documentation and persistent training, can improve compliance across multiple care domains, increase internal event reporting accuracy, and reduce the incidence of serious, reportable adverse events.40301575526

[0122] FIG. 12 illustrates an example method 1200 which can be performed using any of the systems disclosed herein.

[0123] For instance, at operation 1202, the method 1200 can monitor, by one or more processors, medical records for a patient using an event-driven architecture by receiving authenticated update events related to the medical records via a secure message queue. At operation 1204, the method 1200 can determine, by the one or more processors, whether the authenticated update events exceed one or more compliance thresholds, stored at a computer-readable memory device, corresponding to compliance metrics, and the one or more compliance metrics correspond to reducing a risk of occurrence of an adverse healthcare event to the patient. At operation 1206, the method 1200 can generate, by the one or more processors, a notification based on whether the one or more authenticated update events exceed the one or more compliance thresholds. At operation 1208, the method 1200 can transmitting, via a device-control interface, a machine control signal to effect a transformation of a device state based on the notification.

[0124] While the present disclosure has been described with reference to various implementations, it will be understood that these implementations are illustrative and that the scope of the present disclosure is not limited to them. Many variations, modifications, additions, and improvements are possible. For example, variations in implementation of the methods described herein may result from differences in the level of care, leadership style, patient population, culture, and organization of the healthcare providers implementing the methods and tools described herein. More generally, implementations in accordance with the present disclosure have been described in the context of particular implementations. Functionality may be separated or combined differently in various implementations of the disclosure or described with different terminology. For example, any component disclosed herein can be combined with any other component disclosed herein. These and other variations, modifications, additions, and improvements may fall within the scope of the disclosure as defined in the claims that follow.41301575526

Claims

CLAIMSWhat is claimed is:

1. A method to reduce occurrence of adverse health events in a patient, the method comprising:monitoring, by one or more processors, medical records for a patient using an event-driven architecture by receiving authenticated update events related to the medical records via a secure message queue;determining, by the one or more processors, whether the authenticated update events exceed one or more compliance thresholds, stored at a computer-readable memory device, corresponding to compliance metrics, and the one or more compliance metrics correspond to reducing a risk of occurrence of an adverse healthcare event to the patient;generating, by the one or more processors, a notification based on whether the one or more authenticated update events exceed the one or more compliance thresholds; and transmitting, via a device-control interface, a machine control signal to effect a transformation of a device state based on the notification.

2. The method of claim 1 ,wherein,the adverse healthcare event is a pressure injury.

3. The method of claim 2,wherein,the risk of occurrence of the adverse healthcare event to the patient corresponds to data corresponding to a position of the patient relative to a planar surface.

4. The method of claim 3,wherein,the data corresponding to the position of the patient relative to the planar surface includes data corresponding to how frequently the position of the patient was changed relative to the planar surface by a healthcare provider.423015755265. The method of claim 3,wherein,the data corresponding to the position of the patient includes one or more of a plurality of predetermined positions relative to the planar surface.

6. The method of claim 5,wherein,the plurality of predetermined positions includes a first position, a second position, and a third position, andthe data corresponding to the position of the patient indicates that at a first time the patient was positioned in one of the first position, the second position, or the third position, and that at a second time the patient was positioned in another one of the first position, the second position, or the third position.

7. The method of claim 5,wherein,the plurality of predetermined positions includes a first position, a second position, and a third position,the data corresponding to the position of the patient indicates that at a first time the patient was positioned in one of the first position, the second position, or the third position, and that at a second time the patient was positioned in the one of the first position, the second position, or the third position, andthe notification includes an alert with instructions to reposition the patient to a different position of the plurality of predetermined positions.

8. The method of claim 2,wherein,the risk of occurrence of the adverse healthcare event to the patient is determined by evaluating the patient using a Braden Scale.433015755269. The method of claim 1,wherein,the medical records are included in a plurality of medical charting records, the patient is one of a plurality of patients, andeach of the plurality of patients is associated with at least one of the plurality of medical charting records.

10. The method of claim 1,wherein,the medical records include data corresponding to a medical condition of the patient,the data includes one or more of a risk of catheter infection data, a fall risk data, a patient mobility data, a patient psychological data, a patient safety risk data, a capnography record, a medication administration record, or some combination thereof, andthe one or more compliance metrics correspond to a treatment for the medical condition.

11. The method of claim 1 , further comprising:modifying, by the one or more processors, the one or more compliance thresholds in response to determining that the one or more compliance metrics do not reduce the risk of occurrence of the adverse healthcare event.

12. The method of claim 1 , further comprising:providing one or more recommended actions to a device of a healthcare provider, the one or more recommended actions including repositioning the patient, providing a medication to the patient, treating skin of the patient with an antiseptic, treating the skin with a skin barrier, generating a report of compliance for a healthcare provider, generating a reminder to the healthcare provider to provide treatment to the patient, providing training for the healthcare provider, or a combination thereof.4430157552613. The method of claim 1, further comprising:providing one or more recommended actions to a device of a healthcare provider by displaying the one or more recommended actions at a user interface, generating an alert with instructions to perform the one or more recommended actions, sending a digital message to the device of the healthcare provider, and generating a graphical representation of the compliance metrics.

14. A system to reduce occurrence of adverse health events in a patient, the system comprising:a memory storing processor-readable code; andone or more processors coupled to the memory, the one or more processors configured to execute the processor-readable code to cause the one or more processors to perform operations including:monitoring medical records for a patient using an event-driven architecture by receiving authenticated update events related to the medical records via a secure message queue;determining, by the one or more processors, whether the authenticated update events satisfy one or more compliance thresholds, stored at the memory, corresponding to compliance metrics, and the one or more compliance metrics correspond to reducing a risk of occurrence of an adverse healthcare event to the patient;generating a notification based on whether the one or more authenticated update events exceed the one or more compliance thresholds; andtransmitting, via a device-control interface, a machine control signal to effect a transformation of a device state based on the notification.

15. The system of claim 14,wherein,the adverse healthcare event is a pressure injury.

16. The system of claim 15,wherein,45301575526the risk of occurrence of the adverse healthcare event to the patient corresponds to data corresponding to a position of the patient relative to a planar surface.

17. The system of claim 16,wherein,the data corresponding to the position of the patient relative to the planar surface includes data corresponding to how frequently the position of the patient was changed relative to the planar surface by a healthcare provider.

18. The system of claim 16,wherein,the data corresponding to the position of the patient includes one or more of a plurality of predetermined positions relative to the planar surface.

19. The system of claim 18,wherein,the plurality of predetermined positions includes a first position, a second position, and a third position, andthe data corresponding to the position of the patient indicates that at a first time the patient was positioned in one of the first position, the second position, or the third position, and that at a second time the patient was positioned in another one of the first position, the second position, or the third position.

20. The system of claim 19,wherein,the plurality of predetermined positions includes a first position, a second position, and a third position,the data corresponding to the position of the patient indicates that at a first time the patient was positioned in one of the first position, the second position, or the third46301575526position, and that at a second time the patient was positioned in the one of the first position, the second position, or the third position, andthe notification includes an alert with instructions to reposition the patient to a different position of the plurality of predetermined positions.

21. The system of claim 15,wherein,the risk of occurrence of the adverse healthcare event to the patient is determined by evaluating the patient using a Braden Scale.

22. The system of claim 14,wherein,the medical records are included in a plurality of medical charting records, the patient is one of a plurality of patients, andeach of the plurality of patients is associated with at least one of the plurality of medical charting records.

23. The system of claim 14,wherein,the medical records include data corresponding to a medical condition of the patient,the data includes one or more of a risk of catheter infection data, a fall risk data, a patient mobility data, a patient psychological data, a patient safety risk data, a capnography record, a medication administration record, or some combination thereof, andthe one or more compliance metrics correspond to a treatment for the medical condition.

24. The system of claim 14,wherein,47301575526the operations include modifying the one or more compliance thresholds in response to determining that the one or more compliance metrics do not reduce the risk of occurrence of the adverse healthcare event.

25. The system of claim 14,wherein,the operations include providing one or more recommended actions to a device of a healthcare provider, the one or more recommended actions include repositioning the patient, providing a medication to the patient, treating skin of the patient with an antiseptic, treating the skin with a skin barrier, generating a report of compliance for the healthcare provider, generating a reminder to the healthcare provider to provide treatment to the patient, providing training for the healthcare provider, or a combination thereof.

26. The system of claim 14,wherein,the operations include providing one or more recommended actions to a device of a healthcare provider by displaying the one or more recommended actions at a user interface, generating an alert with instructions to perform the one or more recommended actions, sending a digital message to the device of the healthcare provider, and generating a graphical representation of the compliance metrics.

27. A computer-implemented tool to reduce occurrence of pressure injuries in a patient, the computer-implemented tool comprising:a computer readable medium storing code which, when executed by one or more processors, causes the one or more processors to perform operations including:monitoring, by one or more processors, medical records for a patient using an event-driven architecture by receiving authenticated update events related to the medical records via a secure message queue;determining whether the authenticated update events satisfy one or more compliance thresholds, stored at the computer readable medium, corresponding to compliance metrics, and the one or more compliance metrics correspond to reducing a risk of occurrence of an adverse healthcare event to the patient;48301575526generating a notification based on whether the one or more authenticated update events exceed the one or more compliance thresholds; andtransmitting, via a device-control interface, a machine control signal to effect a transformation of a device state based on the notification.49301575526

Images