AI in Hospitals: How to Predict Sepsis, Heart Attack, and Pneumonia Using ICU Data

AI applied in hospitals can estimate the risk of sepsis, heart attack, and pneumonia several hours in advance by continuously analyzing vital signs, test results, medications, and ICU clinical history. It does not replace medical diagnosis: it works as decision support, prioritizing patients for evaluation and requiring clinical validation, integration into the care workflow, and monitoring of false alerts.

What predicting clinical events in the ICU means

A predictive model receives the data available up to a specific point in time and calculates the probability of an outcome occurring within a defined window. Examples:

• risk of sepsis within the next 6 or 12 hours;
• risk of heart attack or cardiovascular deterioration within the next few hours;
• risk of hospital-acquired or ventilator-associated pneumonia within 24 or 48 hours.

This definition must be explicit. A system that identifies sepsis that has already been recorded is not anticipating the event; it is merely reproducing an existing classification. To generate clinical value, the alert must occur early enough to enable evaluation and possible intervention, but not so early that it produces an impractical volume of false positives.

It is also necessary to distinguish among three different functions:

1. Detection: identifies signs of an event that may already be present.
2. Prediction: estimates the probability of a future event.
3. Prognosis: estimates progression, complications, or mortality after a known condition.

In all cases, the output must be presented as a risk, accompanied by the main factors considered and the timestamps of the data used. The result must not be treated as an automated diagnosis.

Which ICU data can feed the models

ICUs produce heterogeneous, frequent, and incomplete data. The most useful sources typically include:

• heart rate and respiratory rate;
• systolic, diastolic, and mean arterial pressure;
• temperature and oxygen saturation;
• complete blood count, lactate, creatinine, electrolytes, and blood gas analysis;
• troponin and other cardiac markers, when ordered;
• fluid balance and urine output;
• mechanical ventilation, fraction of inspired oxygen, and respiratory parameters;
• medications, vasopressors, antibiotics, and sedation;
• diagnoses, comorbidities, age, and hospitalization history;
• clinical notes and reports, when governance for text processing is in place.

The model must understand time. An isolated blood pressure measurement may have little value, while the trend over the previous four hours may indicate deterioration. For this reason, variables such as mean, minimum, maximum, slope, variability, and time since the last measurement are common.

Missing data also carries information, but requires caution. The absence of a test may represent clinical stability, an operational limitation, or simply an integration failure. Filling in values without considering this context creates bias and may cause the algorithm to learn hospital practices instead of patient physiology.

How to model sepsis, heart attack, and pneumonia

Sepsis prediction

Outcome construction can use documented clinical criteria and recognized definitions, such as the Sepsis-3 consensus, combining suspected infection and organ dysfunction. The label must be reviewed with the care team because antibiotic administration time, culture collection, and diagnostic records may not accurately represent clinical onset.

Relevant variables include temperature, blood pressure, respiratory rate, lactate, white blood cell count, creatinine, platelets, oxygen saturation, and vasopressor use. A common mistake is including information recorded only after sepsis has been confirmed. This data leakage produces excellent retrospective results but fails in real-world use.

Heart attack and cardiovascular deterioration prediction

Acute myocardial infarction requires clinical, electrocardiographic, and laboratory evaluation; an AI score cannot confirm it on its own. In the ICU, models can support the prioritization of patients with hemodynamic changes, elevated or trending troponin levels, rhythm abnormalities, documented pain, and risk factors.

The challenge is distinguishing myocardial infarction from other causes of myocardial injury that are common in critically ill patients. Sepsis, kidney failure, hypoxia, and shock can also elevate troponin. Therefore, the model must be trained with clinically reviewed labels, and its output must communicate risk and context rather than issue a definitive diagnosis.

Pneumonia prediction

For hospital-acquired or ventilator-associated pneumonia, factors may include intubation duration, secretions, temperature, white blood cell count, oxygenation, ventilator parameters, microbiological tests, and imaging reports. The event definition must distinguish among colonization, clinical suspicion, and the confirmation standard adopted by the hospital.

This problem involves label delay: cultures and reports may become available hours or days later. Training must use the probable clinical time of onset, preventing future information from being incorporated into variables from before the alert.

Metrics that actually determine clinical utility

Accuracy alone is inadequate when the event is rare. A model that classifies every patient as negative may appear accurate and still be useless. Evaluation must include:

• sensitivity: proportion of events correctly flagged;
• specificity: proportion of cases without the event that are correctly ruled out;
• positive predictive value: how many alerts correspond to actual events;
• AUPRC: performance accounting for the imbalance between positive and negative cases;
• AUROC: overall discrimination ability, without indicating operational utility on its own;
• calibration: agreement between predicted risk and observed frequency;
• median lead time: time between the first valid alert and the event;
• alerts per bed/day: practical measure of the burden placed on the team.

The threshold should not be selected solely to maximize a mathematical metric. If sensitivity is increased at the cost of too many alerts, alert fatigue emerges and the team begins to ignore the system. A hospital may, for example, prefer two levels: moderate risk for monitoring and high risk for immediate evaluation according to a locally defined protocol.

Subgroups must also be tested by sex, age group, comorbidities, unit, and clinical profile. Performance differences may indicate bias, insufficient data volume, or different protocols.

Architecture and hospital integration

An operational project must connect the electronic health record, laboratory, monitors, pharmacy, and admission systems. HL7 v2 remains common for exchanging hospital messages; FHIR provides standardized resources and APIs for representing observations, patients, medications, and clinical conditions.

A typical architecture includes:

1. event ingestion through HL7 v2, FHIR, databases, or APIs;
2. validation of units, identifiers, and timestamps;
3. storage with traceability and access control;
4. temporal processing of variables;
5. model inference;
6. risk delivery within the clinical workflow;
7. recording the response and outcome for auditing.

Latency must be compatible with the use case. Predicting deterioration six hours in advance is ineffective if the data reaches the model four hours late. It is also essential to define system behavior during outages, duplicate messages, corrected test results, and connection loss.

Safe validation before clinical use

Responsible implementation occurs in stages:

• retrospective temporal validation: train on an earlier period and test on a later period;
• external validation: test in another unit or hospital, when possible;
• silent deployment: calculate risks without displaying alerts while measuring real-world performance;
• controlled pilot: display results to a defined team with a response protocol;
• prospective evaluation: compare outcomes, workload, and safety;
• continuous monitoring: detect changes in data, calibration, and patient profiles.

Separation must occur by patient and by time. Mixing hospitalizations or records from the same patient between training and testing causes leakage. Likewise, a model trained only with data from one institution must not be assumed to be valid for every hospital.

Changes in equipment, tests, protocols, and population can cause drift. The hospital must define monitoring indicators, review frequency, who is responsible for suspending the model, and recalibration criteria.

Checklist for deciding whether the project is ready

Before placing AI into the care workflow, verify that:

• the outcome and prediction window are clinically defined;
• there is sufficient historical data with reliable timestamps;
• variables recorded after the event have been excluded;
• sensitivity, positive predictive value, calibration, and lead time have been measured;
• the expected number of alerts per bed/day is acceptable;
• analyses by subgroup and unit are available;
• the alert communicates risk, timestamp, and relevant factors;
• there is a human evaluation and escalation protocol;
• access, logs, retention, and purpose comply with Brazil’s General Data Protection Law (LGPD);
• HL7 v2 or FHIR integrations have been tested against failures;
• there is a plan to monitor drift, incidents, and performance;
• clinical and technical responsibilities are documented.

Main trade-offs

The first trade-off is sensitivity versus alert fatigue. The second is complexity versus explainability: neural networks can capture temporal relationships, but simpler models may make auditing and maintenance easier. The best algorithm is not necessarily the most complex one, but the one that maintains adequate performance on local data and can be operated safely.

There is also a conflict between customization and generalization. A local model may adapt better to the hospital, but it may learn overly specific practices. Multicenter models tend to generalize better, but they still require local validation and calibration.

Finally, integration is often as important as modeling. A statistically strong algorithm that is disconnected from the electronic health record or displayed on a dashboard that no one monitors will have little impact. The risk must reach the right person at the right time, with an actionable next step.

How Predictor Solutions addresses this

Predictor Solutions develops healthcare systems with HL7 v2 and FHIR integration, data engineering, and applied AI. Predictor AI Hospitals focuses on predicting sepsis, heart attack, and pneumonia in the ICU, with temporal pipelines, dashboards, hospital environment integration, and technical monitoring; clinical adoption must always undergo local clinical validation and human governance.

The company also develops Predictor Health, a health dashboard and wearable integration platform. Across its broader custom software and automation portfolio, Predictor Solutions reports serving 9 medium-sized and large companies, average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and profit growth of 43% in six months; these are overall results from the company’s operations, not clinical metrics from the hospital models.

Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246.