[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

WO2018160929A1 - Outil d'admission, de sortie et de surveillance prédictif de patient - Google Patents

Outil d'admission, de sortie et de surveillance prédictif de patient Download PDF

Info

Publication number
WO2018160929A1
WO2018160929A1 PCT/US2018/020597 US2018020597W WO2018160929A1 WO 2018160929 A1 WO2018160929 A1 WO 2018160929A1 US 2018020597 W US2018020597 W US 2018020597W WO 2018160929 A1 WO2018160929 A1 WO 2018160929A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
patient
prediction
categorized
database
Prior art date
Application number
PCT/US2018/020597
Other languages
English (en)
Inventor
Dino Peter RUMORO
Original Assignee
Rush University Medical Center
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Rush University Medical Center filed Critical Rush University Medical Center
Priority to US16/490,815 priority Critical patent/US11646105B2/en
Publication of WO2018160929A1 publication Critical patent/WO2018160929A1/fr

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
    • G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/30—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for calculating health indices; for individual health risk assessment
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
    • G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02A—TECHNOLOGIES FOR ADAPTATION TO CLIMATE CHANGE
    • Y02A90/00—Technologies having an indirect contribution to adaptation to climate change
    • Y02A90/10—Information and communication technologies [ICT] supporting adaptation to climate change, e.g. for weather forecasting or climate simulation

Definitions

  • the subject technology is generally directed to computer-implemented planning and prediction of a patient stay at a healthcare facility for efficient administration of patient care.
  • Patients can be admitted to a healthcare facility (e.g., hospital) by one of a variety of means, such as delivery by emergency medical service ("EMS"), walk-in, transfer-in, or scheduled outpatient arrival.
  • EMS emergency medical service
  • a sudden influx of unanticipated patients can cause strain on the resources and capacity of a hospital.
  • Inefficient operation of a health care facility can lead to excessively long or excessively short patient length of stay as well as increased hospital operating expenses.
  • a system for storing electronic data can include: one or more processors; a raw patient database; a normalized and categorized patient database; a prediction database; a user interface; and a memory comprising instructions.
  • the instructions can cause the one or more processors to: receive initial patient data; store the initial patient data in the raw patient database; extract, from the initial patient data, initial categorized patient data relating to one or more conditions of a patient upon arrival to a first unit of a healthcare facility; store the initial categorized patient data in the normalized and categorized patient database; after storing the initial categorized patient data in the normalized and categorized patient database, delete the initial patient data from the raw patient database; based on the initial categorized patient data, generate a first prediction comprising a predicted characteristic of a patient stay at the first unit; store the first prediction in the prediction database; receive additional patient data based on the patient stay at the first unit; store the additional patient data in the raw patient database; extract, from the additional patient data, additional categorized patient data
  • a method for storing electronic data can include: receiving initial patient data; storing the initial patient data in a raw patient database; extracting, from the initial patient data, initial categorized patient data relating to one or more conditions of a patient upon arrival to a first unit of a healthcare facility; storing the initial categorized patient data in a normalized and categorized patient database; after storing the initial categorized patient data in a normalized and categorized patient database, deleting the initial patient data; based on the initial categorized patient data, generating a first prediction comprising a predicted characteristic of a patient stay at the first unit; storing the first prediction in a prediction database; receiving additional patient data based on the patient stay at the first unit; storing the initial patient data in the raw patient database; extracting, from the additional patient data, additional categorized patient data relating to one or more conditions of the patient upon discharge from the first unit; storing the additional categorized patient data in a normalized and categorized patient database; after storing the additional categorized patient data in a normalized and categorized patient database
  • a non-transitory computer-readable medium can include instructions for storing electronic data. When executed by one or more computers, the instructions can cause the one or more computers to: receive initial patient data; store the initial patient data in a raw patient database; extract, from the initial patient data, initial categorized patient data relating to one or more conditions of a patient upon arrival to a first unit of a healthcare facility; store the initial categorized patient data in the normalized and categorized patient database; after storing the initial categorized patient data in the normalized and categorized patient database, delete the initial patient data from the raw patient database; based on the initial categorized patient data, generate a first prediction comprising a predicted characteristic of a patient stay at the first unit; store the first prediction in a prediction database; receive additional patient data based on the patient stay at the first unit; store the additional patient data in the raw patient database; extract, from the additional patient data, additional categorized patient data relating to one or more conditions of the patient upon discharge from the first unit; store the additional categorized patient data in the normalized and categorized patient
  • Generating the second prediction can include comparing the segmented data to one or more patterns of a predictive model.
  • the characteristic of the patient stay at the first unit can include an admit to the second unit prediction, a discharge prediction, a length-of stay in the first unit prediction.
  • the characteristic of the patient stay at the second unit can include a length-of-stay in the second unit prediction, and/or a final disposition prediction.
  • the condition of the patient can include arrival location, clinical condition, and/or demographics data.
  • Generating the second prediction can include: comparing the segmented data to patterns of a plurality of predictive models; combining results of the comparing with majority or weighted voting or statistical combination.
  • the instructions when executed by one or more processors, can cause the one or more processors to: after receiving the initial data, receive temporal data comprising variables relating to the patient; transform the temporal data into transformed data; and store the transformed data in one or more of a plurality of pattern categories.
  • the transforming can include: converting a variable of the temporal data into a categorical variable; changing a scale or orientation of the variable; combining multiple variables of the temporal data; and transforming a coordinate system of the temporal data.
  • FIG. 1 illustrates an example pathway of a patient stay at a hospital, according to some embodiments of the subject technology.
  • FIG. 2 illustrates an example pathway of a patient stay at a hospital, according to some embodiments of the subject technology.
  • FIG. 3 illustrates an example workflow of a prediction model system for storing and analyzing data following entry of patient data, according to some embodiments of the subject technology.
  • FIG. 4 illustrates an example workflow of a prediction model system for storing and analyzing data following a patient event, according to some embodiments of the subject technology.
  • FIG. 5 illustrates an example workflow for predicting analytics relating to inpatient, emergency department (“ED”), and outpatient length-of-stay (“LOS”) and location predictions, according to some embodiments of the subject technology.
  • ED emergency department
  • LOS outpatient length-of-stay
  • FIG. 6 illustrates an example data segmentation workflow for segmenting patient data, according to some embodiments of the subject technology.
  • FIG. 7 illustrates an example temporal data transformation workflow, according to some embodiments of the subject technology.
  • FIG. 8 illustrates an example record of spliced data, according to some embodiments of the subject technology.
  • FIG. 9 illustrates an example workflow for tracking and predicting LOS and location for patients entering a hospital at an emergency department, according to some embodiments of the subject technology.
  • FIG. 10 illustrates an example workflow for tracking and predicting LOS and location for patients entering a hospital for scheduled visitation to an OR/surgical department, according to some embodiments of the subject technology.
  • FIG. 1 1 illustrates an example workflow for tracking and predicting LOS and location for patients entering a hospital for scheduled outpatient or other procedures, according to some embodiments of the subject technology.
  • FIG. 12 conceptually illustrates an example electronic system, according to some embodiments of the subject technology.
  • the subject technology implements predictive analytics for operational efficiencies.
  • the subject technology includes a tool for predicting admission from an emergency department ("ED") and the final disposition from the unit along with the overall duration of the stay.
  • the subject technology in some embodiments, a tool to monitor the entire patient stay throughout the ED and unit. Aspects of the subject technology can facilitate admission prediction from the ED to the inpatient setting, movement within the inpatient setting (e.g., along with duration of stay, final disposition location, and overall inpatient length-of-stay), and active reporting using user interfaces.
  • some of the techniques described herein may be used, among other things, to assimilate relevant data from multiple clinical sources to determine if a defined set of criteria are met for a patient's condition.
  • the data may be used to determine a probability that the patient will be admitted to a hospital, develop a certain other condition, require a certain treatment, etc.
  • Computing device(s) implementing the subject technology may also recommend certain treatments (e.g. to prescribe a first medication or not to prescribe a second medication) based on the assimilated data.
  • the subject technology can be implemented as a computer-implemented method, a computer system, or a non-transitory computer-readable medium including instruction (e.g., software code).
  • a computing device can include a server, a data repository, a database, a laptop computer, a desktop computer, a netbook, a mobile phone, a tablet computer, a personal digital music player, a personal digital assistant (PDA), etc.
  • PDA personal digital assistant
  • the application of one or more computing devices allows for efficient collection, analysis, and communication of patient statuses, predications, assignments, and dispositions.
  • computing devices as described further herein, can perform functions that have been previously performed manually by medical personnel.
  • the subject technology can be implemented during a patient visit to a healthcare facility, such as an emergency department ("ED"). Data relating to the patient is collected, and a prediction relating to admission and/or discharge of a patient is made based on certain data. Predictions can also include a determined duration of stay overall, a determined duration of stay in each of a plurality of units, and/or a determined next unit location. The subject technology can be implemented to further analyze new data to enhance its predictive capabilities as the new data is entered. Once the prediction includes an indicator that is above a threshold for admission, the patient is listed as "Predicted Admission.”
  • Prediction analysis can be performed, for example, by a combination of linear and logistic regression statistics for data analysis to code variables into categories after which the categories are converted into binary classifiers to predict whether or not a patient should be admitted to the hospital.
  • emergency departments can account for a significant percent of admissions to a hospital, these admissions are unplanned and can disrupt hospital operations and planned admissions (i.e., from the operating rooms).
  • the subject technology can be implemented to begin the process of finding an inpatient bed for emergency department patients early in the duration of an emergency department visit. Accommodations to admit the patient can be reserved and arranged even before the emergency physician has completed their evaluation and treatment and decided to admit the patient, thereby allowing the patient to be transferred promptly to the hospital for an inpatient stay. Accordingly, the ED can maintain efficient patient throughput and decrease the number of patients who leave before treatment.
  • the hospital can also efficiently move patients through the system, keeping beds occupied and maximizing staff efficiency.
  • the subject technology includes systems and methods that can be implemented to improve the patient experience, plan for efficient and timely movement to point of discharge, and advance the quality of care delivered. Additionally, the subject technology includes systems and methods that can improve hospital operations/finances by providing real-time optimization of patient throughput (bed turnover), decrease backlogs in ERJOR, maximize staffing and resource utilization, and decrease operational costs to enhance net income.
  • the subject technology in some implementations, relates to a real-time, scalable, automated, knowledge-based disease detection and diagnosis system.
  • the subject technology includes conducting real-time (e.g., immediate, within one minute, within ten minutes, within one hour, etc., or without any intentional delay) analysis of multiple pre-diagnostic parameters received from electronic medical records as they are routinely documented as part of a clinical encounter.
  • Some implementations of the subject technology can be utilized at any location where a patient seeks treatment (e.g., emergency departments, doctors' offices, clinics, etc.).
  • the data being analyzed in some implementations of the subject technology may include, among other things, chief complaints, history and physical examination notes, nursing and physician notes, other provider notes, radiology dictated reports or laboratory test results.
  • the subject technology is able to analyze discreet variables from "check boxes" as well as "pull down" menus and has a robust natural language processor to analyze free-text entries including comments of negation.
  • the natural language processor can operate based on a library of terms, such as the national library of medicine. Other libraries can be applied according to fields, languages, etc.
  • the term "real-time" is a term of art that is understood to mean occurring without any intentional delay after an entry of a command or a triggering occurrence.
  • a command that is executed in real-time after a mouse click can be executed without any intentional delay after the mouse click, for example, within one second, ten seconds, one minute, ten minutes, one hour, etc., of the mouse click.
  • FIGS. 1 and 2 show pathways 100 and 200 of a patient stay at a hospital.
  • a patient pathway can be initiated with delivery by emergency medical service ("EMS"), walk-in, transfer in, or scheduled outpatient arrival.
  • the pathway can include visits to an emergency department ("ED"), an intensive care unit ("ICU"), an inpatient unit, and/or an operating room.
  • the pathway can include or terminate in discharge to home, expiration, transfer-out, or discharge to long term care.
  • a pathway can include one of a variety of initiations, admissions, and terminations.
  • the subject technology can be implemented during the patient visit to a healthcare facility to accurately predict some or all of a pathway of the patient, thereby allowing the healthcare facility to plan and
  • the subject technology in some embodiments, can operate based on a workflow for storing and analyzing data following entry of patient data.
  • FIG. 3 shows a workflow 300 for a prediction model system in which some examples of the subject technology can be implemented.
  • Each of the cylinders e.g., raw patient database 320, normalized and categorized patient database 330, and prediction database 340
  • a data store e.g., a table or set of related tables within a structured database.
  • Each of the boxes connecting to the cylinders can represent an operation implemented in code which processes inputs (either from a data store or the outputs of another operation) and generates outputs.
  • the stack of pages e.g., incoming messages 310) can represent data being received from external systems (e.g., an EMR).
  • the prediction model system can receive incoming messages 310 (e.g., Health Level 7 ("HL7”) messages) and process data for analysis and storage.
  • the messages can include, for example, admission, discharge and transfer (“ADT") messages from an EMR and/or unsolicited transmission of an observation (“ORU”) messages.
  • the messages can be received, for example, by a Transmission Control Protocol (“TCP") server that listens on one or more specific ports for the incoming messages.
  • TCP Transmission Control Protocol
  • a message processor can convert all of the information from the incoming messages into an internal format and manages any links between different messages (e.g., multiple messages for the same patient, a lab order and its associated results, a very large message broken into multiple smaller messages, etc.).
  • Patient data is extracted from the messages 310 and stored in raw patient database 320.
  • the extracted data can be interpreted with Bayesian text analysis prior to storage.
  • the patient data can include, for example, means of arrival, age, gender, acuity, mental status, level of consciousness, chief complaint, vital signs, (pulse, temperature, response, etc.), lab results (CBC, CMP, etc.), and/or past medical history (asthma, diabetes, etc.).
  • the patient data stored in the raw patient database 320 can be normalized and/or categorized.
  • the results of the normalization and/or categorization can be stored in normalized and categorized patient database 330.
  • the patient data can also be analyzed for predicting characteristics of a patient pathway during the hospital stay. The characteristics can include probability of admission, confidence interval of prediction, and/or actual prediction (admit, discharge, unknown).
  • the results of the prediction modeling can be stored in prediction database 340. Additional details regarding prediction generation are described below.
  • each of the raw patient database 320, the normalized and categorized patient database 330, and the prediction database 340 can be separate data stores to facilitate different processing of the data contained therein.
  • raw messages are stored as they arrive from the EMR in incoming messages 310.
  • the data that is used during the workflow 300 can be extracted out of the messages and stored in a different format in raw patient database 320.
  • the data stored in the raw patient database 320 can be converted, categorized, and/or normalized. For example, a metric (e.g. "temperature of 104°F”) can be converted into one of a variety of indicators (e.g., "high fever”), which is stored in normalized and categorized patient database 330.
  • a metric e.g. "temperature of 104°F”
  • indicators e.g., "high fever
  • the prediction operations are applied to the converted data and to output a prediction for each patient. For example, a new prediction can be generated each time new data arrives.
  • the prediction and its associated data are stored in the prediction database 340.
  • the data in the incoming messages 310 and the raw patient database 320 can be deleted once each has been processed and/or stored in subsequent database, but the data in the normalized and categorized patient database 330 can be preserved throughout the patient's stay.
  • computing device(s) analyze the data in real-time, meaning the data is entered into the system and analyzed without intentional delay, for example, within one minute, one hour, one day, or two days of the patient being seen.
  • the subject technology in some embodiments, conducts real-time analysis of multiple pre-diagnostic parameters from records already being collected within an emergency department (or other treatment facility), such as triage chief complaints, physician exam notes, and test orders and results.
  • the computing device(s) in some embodiments, can send alerts mobile devices (e.g., pagers, mobile phones, and the like) of hospital personnel notifying the physicians of possible or confirmed needs for accommodations when they are identified (e.g., within one minute of identification).
  • FIG. 4 shows a workflow 400 for a prediction model system in which some examples of the subject technology can be implemented.
  • Each of the cylinders e.g., event database 420, action database 430, duration database 440, patient status database 450, summary statistics database 460, and overall status database 470
  • a data store e.g., a table or set of related tables within a structured database.
  • Each of the boxes connecting to the cylinders can represent an operation implemented in code which processes inputs (either from a data store or the outputs of another operation) and generates outputs.
  • the stack of pages e.g., incoming messages 410) can represent data being received from external systems (e.g., an EMR).
  • the prediction model system can receive incoming messages 410 (e.g., HL7 messages) and process data for analysis and storage following an event.
  • the messages can include, for example, ADT messages from an EMR.
  • Event data is extracted from the messages 410 and stored in event database 420.
  • Event data can include, for example, patient identification, arrival data, transfer data, room assignment, disposition, admission data, etc.
  • the format of the incoming messages 310 and the incoming message 410 can be the same or similar.
  • the data contained within the incoming messages 310 and the incoming message 410 can be different.
  • the process of extracting data from the incoming messages 310 can include extracting data important for predicting admission (e.g., mode of arrival, demographics, vital signs, past medical history, etc.) for storage in the raw patient database 320.
  • the process of extracting data from the incoming message 410 can include extracting data important for tracking patient movement (e.g., current patient location, current patient disposition, etc.) for storage in the event database 420.
  • the incoming messages contain all of the fields necessary for both purposes, then the incoming message 310 and the incoming message 410 can be the same message or copies of the same message, which can include the same data or a shared resource.
  • the portions of data that are extracted can be different according to different purposes for which they are used.
  • patient-specific action tracking is performed to generate action data specific to one or more patients.
  • the action data for each patient can include arrival time, roomed time, provider time, disposition time, admission time, discharge time, "left without being seen” (“LWBS”) time, and/or absconded time.
  • the action data can be stored in action database 430.
  • a patient-specific duration calculation is performed to generate duration data specific to one or more patients.
  • the duration data for each patient can include arrival-to-roomed, arrival-to-provider, roomed-to-provider,
  • duration data can be stored in duration database 440.
  • current patient status tracking is performed to generate patient status data specific to one or more patients.
  • the patient status data for each patient can include current location (bed, waiting room, etc.), current treatment team (A, B, C, etc.), and/or current status (waiting, triage, roomed, seen, etc.).
  • the patient status data can be stored in patient status database 450.
  • an overall status calculation is performed to generate overall status data for a set of patients.
  • the overall status data for a set of patients can include patients in a waiting room, beds occupied, beds available, patients ready for admission, and/or patients ready for transport.
  • the overall status data can be stored in overall status 470.
  • summary statistics calculation is performed to generate summary statistics data for each item or item category in duration database 440 and overall status database 470.
  • the summary statistics data can include statistics for minimum value(s), maximum value(s), median value(s), overall value(s), value(s) for each treatment team, each shift, and/or for rolling (e.g., 8-hour and 24-hour) windows of time.
  • the summary statistics data can be stored in summary statistics database 460.
  • the overall status data stored in overall status database 470 and the summary statistics data stored in summary statistics database 460 can be retrieved for display, use, and/or manipulation by a user interface 480.
  • the user interface 480 can provide overall and patient-specific information to a user and/or other system components.
  • the result of the workflow 300 e.g., from the data store 340, can be a source of data for a user interface 480, in addition to data provided from summary statistics database 460 and/or overall status database 470, to include prediction data within the user interface 480 alongside current status information.
  • each of the event database 420, the action database 430, the duration database 440, the patient status database 450, the summary statistics database 460, and the overall status database 470 can be separate data stores to facilitate different processing of the data contained therein.
  • raw messages from the incoming messages 410 are processed and the relevant event data is extracted into the event database 420.
  • Those events are then processed into event categories (e.g. "arrival”, “disposition”, “transfer”, etc.) and stored in the action database 430.
  • event categories e.g. "arrival”, "disposition”, “transfer”, etc.
  • durations, statuses, etc. can be calculated and stored in their own locations. Some locations are patient-specific, some are aggregated at a particular point in time, and some are aggregated for a given time period. All of these pieces of data drive the user interface 480.
  • FIG. 5 illustrates an example workflow 500 for predicting analytics relating to inpatient, emergency department (“ED”), and outpatient length-of-stay (“LOS") and location predictions.
  • the workflow 500 includes stages for "Data Segmentation,” “Temporal Data Transformations,”
  • stages include a steps of "Processing Task Optimization,” in which data to be processed is, at such a point in the workflow 500, stored in a
  • FIG. 6 illustrates an example data segmentation workflow 600 for segmenting patient data. Based on incoming data, extraction can be performed using discrete fields of the natural language processors. For example, the data can be coded using National Library of Medicine ("NLM”) concepts and/or other libraries selected based on applicable fields and languages. The resulting data is segmented into categories that can include arrival location, current clinical condition, prior clinical condition,
  • NLM National Library of Medicine
  • the data is segmented according to its kind and based on how it is used within the prediction operations.
  • the segmented data segmented data can include a plurality of time series 610.
  • Each of the time series 610 can include a plurality of conditions 620 of the patient across a period of time within the corresponding time series 610. For example, if a patient has 12 different readings of "fever" (e.g., 8 measured temperatures, I selected as the primary chief complaint, and 3 noted within the review of systems and past medical history), then all 12 of those readings are segmented into a single time series, which is distinct from a "blood pressure" time series, etc.
  • "fever" e.g. 8 measured temperatures, I selected as the primary chief complaint, and 3 noted within the review of systems and past medical history
  • FIG. 7 illustrates an example temporal data transformation workflow 700.
  • Data transformations can be used to accurately model complex systems within simplified statistical models.
  • the temporal data can be transformed to generate new data based on one or more patterns, including increasing patterns, decreasing patterns, peak patterns, valley patterns, statistical patterns, nonlinear patterns, temporal categorical data patterns, continuous to categorical patterns, and/or combinations thereof.
  • Examples of temporal data can include lab results (e.g., WBCs, potassium levels, etc.), vital signs (e.g., temperature, pulse, etc.), patient status (e.g., acuity levels, etc.), radiology results (e.g., CT scans), among others.
  • the data segmentation described herein can be utilized for multiple prediction models to capture unique location, diseases, and other specific characteristics of underlying patient populations. All data can be timestamped, so each segment of data is essentially a time series of related readings. Based on the type of data, it will be aggregated in different ways. For example, only one "mode of arrival" may be expected, so if the data contains multiple modes of arrival, it can be inferred that the original was updated by staff, so the most recent can be used. By further example, with vital signs, the overall time series (e.g., minimum, maximum, trend) is significant. Any new data can be appended to the visit instance of the patient and stored in the raw patient database 320.
  • a single variable can be transformed in a data transformation.
  • a nominal or continuous variable can be converted into a categorical variable.
  • a function can be executed on a continuous variable to change its scale or orientation (e.g. exponentiation, logarithms, etc.).
  • multiple variables can be combined in a data transformation.
  • novel variables can be created by combining the values of multiple existing variables through weighted voting, thresholding, logical operations, fully connected conditional probability tables, etc.
  • variables can be combined through statistical methods or by using expert clinical insight and guidance.
  • the coordinate system can be transformed in a data transformation.
  • the scale and orientation of all variables within a model can be changed using a coordinate system transformation (e.g. radial basis function, Gaussian kernel function, Cartesian to polar coordinate transformation, etc.).
  • a coordinate system transformation e.g. radial basis function, Gaussian kernel function, Cartesian to polar coordinate transformation, etc.
  • the selected data transformation can be based on multiple aspects such as clinical conditions, statistical prediction model performance metrics, type and frequency of data availability, relative importance of the variable/data, among others.
  • the data transformation selection process could be optimized through iterative applications of various transformations and selection of highest performing transformation with respect to the prediction model performance metrics. Due to the nature of some data elements along with clinically observed patterns, only certain transformations will be applied. Systems described herein can include a library of data elements and applicable transformations for ease for implementation.
  • FIG. 8 illustrates data that is provided at various stages with respect to the duration of a patient's visit.
  • prior unit data can be generated prior to the beginning of a patient's visit.
  • initial visit data can be provided.
  • initial visit data can include information received from the patient during an admission process.
  • Data between the initial and final hours of the visit can be provided.
  • supplemental information can be received, as well as updates regarding the patient's condition, treatment, and/or response to treatment.
  • data can be provided during the last hours of the patient's visit. For example, information can be collected during a procedure for discharging the patient.
  • the data can be spliced based on when, during the patient encounter, it is coming from.
  • a prediction model provides different weights to data from major time periods (e.g., pre- visit, early-visit, mid-visit, late- visit). For example, a high temperature on arrival to the ED is not as significant for predicting admission and admission duration as a high temperature near the end of an ED stay.
  • the incoming data can be continuous. However, for building the prediction models and implementing them, particular portions of the data can be utilized. These sections represent when and how early the predictions can be compiled.
  • the first 8 hours of inpatient data can be used to build a model that predicts the total LOS as well as a final disposition. This information can assist the clinicians as well as administrators to provide optimal treatment as well as plan for the discharge and arrange for any necessary patient support system.
  • the last 24 hours of data could be used to generate a report of predicted discharges in next 24 hours. This information can provide short term but reliable predictions that can be used for informing the discharge conversations, communications between various clinical and non-clinical providers, and communications with patients and their families.
  • the subject technology in some embodiments, can apply one or more models to predict the pathway and/or LOS of one or more patients. For example, multiple statistical models can be applied based on different outcomes, different independent variables, and the timing of the readings.
  • one or more decisions Y jk can be defined based on different models, j, different variables, , and different readings, k, as shown below: k i
  • P 0J k and ⁇ 3 ⁇ 4 are coefficients of a linear regression model which is applied to the
  • X ik normalized/categorized data values represented by X ik .
  • Other models e.g. logistic regression, neural networks, etc.
  • the decisions can be continuous, categorical, nominal, or binary.
  • the models can be built using linear regression, generalized linear models, general linear models, logistic regression, and multinomial logistic regression among others.
  • a first data mining model can be used to determine a LOS category for a patient. Based on each of a number of patterns, a result can be determined. As described herein, the data transformations can create derived independent variables. The raw/original variables in combination with the derived variables will be used to create predictive models. Data mining models can create knowledge in form of patterns (see "Artificial Intelligence, Data Mining and Statistical Modeling for predicting Unit LOS and Next Unit and/or Final disposition" in the workflow 500 of FIG. 5). According to some embodiments, for each Pattern ijk, the following logic can apply:
  • the results from the first data mining model according to each Pattern ijk can be generated and stored, as described herein.
  • a second data mining model can be used to determine a "next unit" category for the patient.
  • the determination of a next unit can indicate whether a patient is to be admitted, discharged, or otherwise directed to a location within the hospital.
  • a result can be determined. For example, for each Pattern ijk, the following logic can apply:
  • Decisions can be modeled as either binary or categorical. Nominal or continuous decisions are converted into categorical decisions using thresholds prior to model building and application. Assignment of parents is based on observed conditional independence, D-separation within the directed acyclic graph nodes, causal sufficiency assumptions, domain expert feedback, or a combination of these factors. Additional graph topology optimization can occur after initial assignment of parents using Markov blanket covering or similar algorithms in order to improve the accuracy and confidence of the initial topology. Conditional probability tables for each node within the graph are based on historical data, literature-derived values or a combination of both.
  • Feedback and additional information can be incorporated within the Bayesian network to improve accuracy either through changes to the structure or the conditional
  • the multiple decisions can be combined to produce a final decision.
  • the decisions can be subjected to a voting scheme, weighted voting scheme, or a statistical combination.
  • Multiple models of the same or different statistical types for the same outcome can be statistically combined to yield a final decision/outcome.
  • Each model's individual outcome receives a single vote or its vote is weighted based on its prediction confidence, tuning-based bagging/boosting coefficients, or a predefined weighting scheme.
  • Multiple outcomes/models can also be combined stochastically using Monte Carlo simulations to provide additional weighting among outcomes.
  • the decision/outcome with the highest overall votes/score will be selected as the final decision.
  • the Final Decision Y can be expressed as:
  • the decision(s) can be processed with thresholding.
  • various thresholding approaches can be employed. Decisions can be made only if a certain level of confidence is achieved. For example, if a predicted confidence is greater than or equal to a threshold, then the final decision is the prediction value. Otherwise, the decision can be unknown or additional information can be required.
  • Thresholds can be determined based on balancing statistical performance metrics as well as clinical inputs and can be unique for each model per application. Thresholds can be determined using one or more of (1) Gaussian
  • additional data can be added to refine the models and improve statistical performance metrics as well a clinical interpretability and operational ability. Feedback and additional information will be incorporated within each model and within the final decision algorithm in order to improve accuracy, either through changes to the structure of the model(s) and/or the values associated with the model(s).
  • Additional data can be data that is not utilized in the current model but can be added.
  • the additional data can be already available in the current data feeds (e.g., WBC available but not used in the current model).
  • the additional data can be new data fields added due to clinical and operational reasons (e.g., adding travel to specific regions for say ebola/zika monitoring, socioeconomic data points such as home support, etc.).
  • the additional data can be newly derived variables due to temporal transformations.
  • workflows can be specifically tailored to track and predict pathways for ED patients, OR/surgical patients, and/or outpatient/other patients. Aspects discussed above, such as data segmentation, temporal data
  • transformations, visit segments, prediction models, majority or weighted voting or statistical combination to predict outcome, and thresholding, among others, can be applied to ED workflows, OR/surgical workflows, and/or outpatient/other patient workflows. According to some embodiments, aspects of these workflows can be similar to the workflow 500 shown in FIG. 5 and described above. Accordingly, these aspects are not repeated for each of the workflows described below.
  • FIG. 9 illustrates an ED workflow 900 for tracking and predicting LOS and location for patients entering a hospital at an emergency department.
  • FIG. 10 illustrates an OR/surgical workflow 1000 for tracking and predicting
  • FIG. 1 1 illustrates an outpatient/other patient workflow 1 100 for tracking and predicting LOS and location for patients entering a hospital for scheduled outpatient or other procedures.
  • the workflows 900, 1000, and/or 1 100 can include multiple sets of data segmentation.
  • the first set of data segmentation can be based on initial data, which may have limited information for data segmentations. For example, chief complaint in the ED are subject to change and could be different than final ED diagnosis. Thus, initial data segmentation may utilize a limited number of aspects while the subsequent data segmentation after completing the ED, OR, and/or outpatient visits will utilize more reliable information.
  • the first set of predictions can be used for setting specific operations such as ED, OR, and/or outpatient. The goal of these predictions can be either to admit or discharge the patients after completing the visit in that setting as well as estimating the expected LOS in the respective settings.
  • no data segmentations may be performed. While as the initial OR data will have more reliable information than ED, data segmentation can be applied prior to initial predictions. Thus, two levels of data segmentation can be used (e.g., initial limited data based segmentation and regular data segmentation).
  • FIG. 12 conceptually illustrates an electronic system 901 with which some implementations of the subject technology are implemented.
  • the electronic system 901 can be a computer (e.g., a mobile phone, PDA), or any other sort of electronic device.
  • Such an electronic system includes various types of computer readable media and interfaces for various other types of computer readable media.
  • Electronic system 901 includes a bus 905, a processor or processing unit 910, a system memory 915, a read-only memory 920, a permanent storage device 925, an input device interface 930, an output device interface 935, and a network interface 940.
  • the bus 905 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 901. For instance, the bus 905 communicatively connects the processing unit(s) 910 with the read-only memory 920, the system memory 915, and the permanent storage device 925.
  • the processing unit(s) 910 retrieves instructions to execute and data to process in order to execute the processes of the subject technology.
  • the processing unit(s) can be a single processor or a multi-core processor in different implementations.
  • the read-only-memory (ROM) 920 stores static data and instructions that are needed by the processing unit(s) 910 and other modules of the electronic system.
  • the permanent storage device 925 is a read- and- write memory device. This device is a non-volatile memory unit that stores instructions and data even when the electronic system 901 is off.
  • Some implementations of the subject technology use a mass-storage device (for example, a magnetic or optical disk and its corresponding disk drive) as the permanent storage device 925.
  • the system memory 915 is a read- and- write memory device. However, unlike storage device 925, the system memory 915 is a volatile read- and- write memory, such a random access memory. The system memory 915 stores some of the instructions and data that the processor needs at runtime. In some
  • the processes of the subject technology are stored in the system memory 915, the permanent storage device 925, or the read-only memory 920.
  • the various memory units include instructions for generating a diagnosis or detecting an outbreak of a medical condition in accordance with some implementations. From these various memory units, the processing unites) 910 retrieves instructions to execute and data to process in order to execute the processes of some implementations.
  • the bus 905 also connects to the input and output device interfaces 930 and 935.
  • the input device interface 930 enables the user to communicate information and select commands to the electronic system.
  • Input devices used with input device interface 930 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices").
  • Output device interfaces 935 enables, for example, the display of images generated by the electronic system 901.
  • Output devices used with output device interface 935 include, for example, printers and display devices, for example, cathode ray tubes (CRT) or liquid crystal displays (LCD).
  • CTR cathode ray tubes
  • LCD liquid crystal displays
  • bus 905 also couples electronic system 901 to a network (not shown) through a network interface 940.
  • the electronic system 901 can be a part of a network of computers (for example a local area network (LAN), a wide area network (WAN), or an Intranet, or a network of networks, for example the Internet. Any or all components of electronic system 901 can be used in conjunction with the subject technology.
  • the above-described features and applications can be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium).
  • a computer readable storage medium also referred to as computer readable medium.
  • processing unites e.g., one or more processors, cores of processors, or other processing units
  • Examples of computer readable media include, but are not limited to, CD-ROMs, flash drives, RAM chips, hard drives, EPROMs, etc.
  • the computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.
  • the term "software” is meant to include firmware residing in read-only memory or applications stored in magnetic storage or flash storage, for example, a solid-state drive, which can be read into memory for processing by a processor.
  • multiple software technologies can be implemented as sub-parts of a larger program while remaining distinct software technologies.
  • multiple software technologies can also be implemented as separate programs.
  • any combination of separate programs that together implement a software technology described here is within the scope of the subject technology.
  • the software programs when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.
  • a computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment.
  • a computer program may, but need not, correspond to a file in a file system.
  • a program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code).
  • a computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.
  • Programmable processors and computers can be included in or packaged as mobile devices.
  • the processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry.
  • General and special purpose computing devices and storage devices can be interconnected through communication networks.
  • Some implementations include electronic components, for example,
  • microprocessors storage and memory that store computer program instructions in a machine readable or computer-readable medium (alternatively referred to as computer-readable storage media, machine-readable media, or machine-readable storage media).
  • computer-readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra-density optical discs, any other optical or magnetic media, and floppy disks.
  • CD-ROM compact discs
  • CD-R recordable compact discs
  • CD-RW rewr
  • computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations.
  • Examples of computer programs or computer code include machine code, for example is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
  • ASICs application specific integrated circuits
  • FPGAs field programmable gate arrays
  • the terms "computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people.
  • display or displaying means displaying on an electronic device.
  • computer readable medium and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
  • implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
  • a display device e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor
  • keyboard and a pointing device e.g., a mouse or a trackball
  • Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.
  • a computer can interact with a user by sending documents to and receiving documents from a device that
  • the subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components.
  • the components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (LAN) and a wide area network (WAN), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
  • LAN local area network
  • WAN wide area network
  • Internet inter-network
  • peer-to-peer networks e.g.,
  • the computing system can include clients and servers.
  • a client and server are generally remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.
  • data e.g., an HTML page
  • client device e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device.
  • Data generated at the client device e.g., a result of the user interaction
  • a phrase, for example, an "aspect” does not imply that the aspect is essential to the subject technology or that the aspect applies to all configurations of the subject technology.
  • a disclosure relating to an aspect may apply to all configurations, or one or more configurations.
  • a phrase, for example, an aspect may refer to one or more aspects and vice versa.
  • a phrase, for example, a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology.
  • a disclosure relating to a configuration may apply to all configurations, or one or more configurations.
  • a phrase, for example, a configuration may refer to one or more configurations and vice versa.

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Public Health (AREA)
  • Medical Informatics (AREA)
  • Biomedical Technology (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Pathology (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Des prédictions peuvent être fournies pour l'admission, la sortie, la voie et les unités pour un patient pendant un séjour dans un établissement de santé. Selon certains aspects, un dispositif informatique reçoit des données initiales concernant le patient et génère une prédiction d'admission ou de sortie indiquant une probabilité que le patient soit admis dans l'établissement de santé ou en sorte. Le dispositif informatique segmente des parties des données initiales en données segmentées et stocke les données segmentées dans une ou plusieurs catégories parmi une pluralité de catégories de segmentation. Le dispositif informatique compare les données segmentées à un ou plusieurs motifs d'un modèle prédictif et, sur la base de la comparaison, génère une prédiction de durée de séjour totale (LOS) indiquant une durée pendant laquelle le patient restera dans l'établissement de santé.
PCT/US2018/020597 2017-03-03 2018-03-02 Outil d'admission, de sortie et de surveillance prédictif de patient WO2018160929A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US16/490,815 US11646105B2 (en) 2017-03-03 2018-03-02 Patient predictive admission, discharge, and monitoring tool

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201762466974P 2017-03-03 2017-03-03
US62/466,974 2017-03-03

Publications (1)

Publication Number Publication Date
WO2018160929A1 true WO2018160929A1 (fr) 2018-09-07

Family

ID=63370265

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/020597 WO2018160929A1 (fr) 2017-03-03 2018-03-02 Outil d'admission, de sortie et de surveillance prédictif de patient

Country Status (2)

Country Link
US (1) US11646105B2 (fr)
WO (1) WO2018160929A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200005910A1 (en) * 2018-06-28 2020-01-02 Clover Health Data folding and unfolding

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2037713A1 (fr) 2005-07-01 2009-03-18 Research In Motion Limited Système et procédé pour accélérer la sélection d'un réseau par un dispositif d'équipement de l'utilisateur (UE) sans fil
US20200365255A1 (en) * 2017-08-30 2020-11-19 Nec Corporation Medical information processing device, medical information processing method, and storage medium
US10558709B2 (en) * 2018-03-13 2020-02-11 C/Hca, Inc. Techniques for generating investigatory-event mappings using graph-structure trajectories
US11908573B1 (en) * 2020-02-18 2024-02-20 C/Hca, Inc. Predictive resource management
US12003426B1 (en) 2018-08-20 2024-06-04 C/Hca, Inc. Multi-tier resource, subsystem, and load orchestration
FR3089331B1 (fr) * 2018-11-29 2020-12-25 Veyron Jacques Henri Système et procédé de traitement de données pour la détermination du risque d’un passage aux urgences d’un individu
US11600380B2 (en) * 2018-12-31 2023-03-07 Cerner Innovation, Inc. Decision support tool for determining patient length of stay within an emergency department
US20220336088A1 (en) * 2019-09-30 2022-10-20 GE Precision Healthcare LLC Efficiently generating machine learning models configured to forecast information regarding time until occurrence of clinical events
KR102510992B1 (ko) * 2020-03-05 2023-03-16 가톨릭대학교 산학협력단 환자의 정보를 기반으로 재원기간을 예측하는 장치, 방법 및 프로그램
KR102310455B1 (ko) * 2020-03-05 2021-10-07 가톨릭대학교 산학협력단 관상동맥우회술 환자의 최초 중환자실 재실시간과 최초 기도삽관시간을 이용하여 재원기간을 예측하는 방법, 시스템 및 프로그램
CN113393939B (zh) * 2021-04-26 2024-05-28 上海米健信息技术有限公司 重症监护室患者住院天数预测方法及系统
US11252209B1 (en) 2021-07-13 2022-02-15 Audacious Inquiry, LLC Network architecture for parallel data stream analysis and modification

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150307A1 (en) * 2005-12-22 2007-06-28 Cerner Innovation, Inc. Displaying clinical predicted length of stay of patients for workload balancing in a healthcare environment
US20090105550A1 (en) * 2006-10-13 2009-04-23 Michael Rothman & Associates System and method for providing a health score for a patient
US20110245630A1 (en) * 2010-03-31 2011-10-06 St Pierre Shawn C Integrated Patient Data Management for Physiological Monitor Devices
US20120232926A1 (en) * 2009-07-16 2012-09-13 Justin Boyle System and method for prediction of patient admission rates

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030101076A1 (en) * 2001-10-02 2003-05-29 Zaleski John R. System for supporting clinical decision making through the modeling of acquired patient medical information
US8949082B2 (en) * 2001-11-02 2015-02-03 Siemens Medical Solutions Usa, Inc. Healthcare information technology system for predicting or preventing readmissions
CA2833779A1 (fr) * 2011-04-20 2012-10-26 The Cleveland Clinic Foundation Modelisation predictive
US20140108033A1 (en) * 2012-10-11 2014-04-17 Kunter Seref Akbay Healthcare enterprise simulation model initialized with snapshot data
CA2918332C (fr) * 2013-07-18 2023-08-08 Parkland Center For Clinical Innovation Systeme et procede de surveillance des soins des malades

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070150307A1 (en) * 2005-12-22 2007-06-28 Cerner Innovation, Inc. Displaying clinical predicted length of stay of patients for workload balancing in a healthcare environment
US20090105550A1 (en) * 2006-10-13 2009-04-23 Michael Rothman & Associates System and method for providing a health score for a patient
US20120116180A1 (en) * 2006-10-13 2012-05-10 Rothman Healthcare Corporation Systems and methods for providing a health score for a patient
US20120232926A1 (en) * 2009-07-16 2012-09-13 Justin Boyle System and method for prediction of patient admission rates
US20110245630A1 (en) * 2010-03-31 2011-10-06 St Pierre Shawn C Integrated Patient Data Management for Physiological Monitor Devices

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200005910A1 (en) * 2018-06-28 2020-01-02 Clover Health Data folding and unfolding
US11508465B2 (en) * 2018-06-28 2022-11-22 Clover Health Systems and methods for determining event probability

Also Published As

Publication number Publication date
US20200013490A1 (en) 2020-01-09
US11646105B2 (en) 2023-05-09

Similar Documents

Publication Publication Date Title
US11646105B2 (en) Patient predictive admission, discharge, and monitoring tool
US11600390B2 (en) Machine learning clinical decision support system for risk categorization
US11783134B2 (en) Gap in care determination using a generic repository for healthcare
US11664097B2 (en) Healthcare information technology system for predicting or preventing readmissions
Bayati et al. Data-driven decisions for reducing readmissions for heart failure: General methodology and case study
US20190325995A1 (en) Method and system for predicting patient outcomes using multi-modal input with missing data modalities
US10332624B2 (en) System and methods for an intelligent medical practice system employing a learning knowledge base
US20120065987A1 (en) Computer-Based Patient Management for Healthcare
Hosseinzadeh et al. Assessing the predictability of hospital readmission using machine learning
US20190005195A1 (en) Methods and systems for improving care through post-operation feedback analysis
US20210098090A1 (en) System and method for identifying complex patients, forecasting outcomes and planning for post discharge care
Delen et al. An analytic approach to better understanding and management of coronary surgeries
US20170169173A1 (en) System for adapting healthcare data and performance management analytics
JP7244711B2 (ja) 臨床リスクモデル
US20210082575A1 (en) Computerized decision support tool for post-acute care patients
US20220336088A1 (en) Efficiently generating machine learning models configured to forecast information regarding time until occurrence of clinical events
Golmohammadi et al. Prediction modeling and pattern recognition for patient readmission
Ben-Assuli et al. Analysing repeated hospital readmissions using data mining techniques
US20180322942A1 (en) Medical protocol evaluation
Na et al. Patient outcome predictions improve operations at a large hospital network
Weatherall et al. Clinical trials, real-world evidence, and digital medicine
WO2018112185A1 (fr) Systèmes et procédés destinés à la prédiction de volume de patients en temps réel
EP4300512A1 (fr) Génération efficace de modèles d'apprentissage automatique configurés pour prévoir des informations concernant le temps jusqu'à l'apparition d'événements cliniques
US20180322959A1 (en) Identification of low-efficacy patient population
US20240079119A1 (en) Systems and methods for medical patient classification

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18760867

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18760867

Country of ref document: EP

Kind code of ref document: A1