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 in advance by analyzing vital signs, laboratory tests, clinical history, and the patient’s progression over time in the ICU. To generate real benefits, the model must be validated with local data, integrated into the electronic health record, and used as decision support—never as a substitute for medical assessment.

What AI Can Predict in an ICU

Predictive models calculate the probability of a clinical event occurring within a defined window, such as within the next 6, 12, or 24 hours. They identify combinations and trends that may be difficult to detect during routine ICU operations, especially when there are many patients, fragmented systems, and frequent measurements.

In practice, the question being answered is not simply “does the patient have sepsis?” but something more precise: “what is the risk that this patient will develop or meet criteria consistent with sepsis within the next few hours?” The same principle applies to heart attack and pneumonia.

Sepsis Prediction

Sepsis requires rapid recognition and treatment, but its early signs can be nonspecific. A model can monitor variables such as:

• heart rate, respiratory rate, and blood pressure;
• temperature and oxygen saturation;
• lactate, white blood cells, platelets, and creatinine;
• use of vasopressors and mechanical ventilation;
• suspected or confirmed infection;
• sequential changes in organ function;
• rate of deterioration over the last few hours.

Temporal analysis is essential. An isolated blood pressure measurement may not be decisive, while a persistent drop associated with increased lactate and respiratory rate may warrant immediate assessment.

Heart Attack Prediction

For cardiac events, AI can combine clinical, laboratory, and electrocardiographic data. Potential inputs include documented chest pain, age, comorbidities, serial troponin measurements, blood pressure, heart rate, and electrocardiogram findings.

The model must distinguish between different objectives: detecting acute coronary syndrome, estimating cardiac deterioration, or prioritizing the review of test results. Failing to clearly define the outcome produces models that are statistically interesting but of little clinical use.

Pneumonia Prediction

For pneumonia, including ventilator-associated pneumonia, the system can evaluate temperature, white blood cells, respiratory secretions, ventilator parameters, oxygen saturation, structured imaging results, and microbiology results.

The challenge is distinguishing pneumonia from other conditions that produce similar signs, such as atelectasis, pulmonary edema, or noninfectious inflammation. Therefore, the safest output is usually a risk estimate accompanied by the relevant factors, rather than an automatic diagnosis.

Which Hospital Data Feed the Models

A hospital AI project depends more on data quality and availability than on the choice of algorithm. The main sources are:

1. Electronic health records: diagnoses, prescriptions, allergies, medical history, and clinical progress notes.
2. Laboratory systems: results, collection times, units, and reference values.
3. ICU monitors and equipment: vital signs, mechanical ventilation, and physiological waveforms.
4. Imaging systems: reports and, when justified by the use case, images in DICOM format.
5. Pharmacy and medication administration: antibiotics, vasopressors, anticoagulants, and administration times.
6. Administrative data: admission, transfer, discharge, bed, and care unit.

Records must be normalized. The same test may have different names, units, or reference ranges across laboratories. It is also necessary to distinguish the time when data were collected from the time when they were entered into the system, preventing the model from using information that was not available at the actual time of prediction.

How the Technical Architecture Works

A typical hospital architecture has four layers: integration, data processing, inference, and clinical delivery.

Integration with HL7 v2 and FHIR

HL7 v2 remains common for admission events, laboratory results, and hospital movements. FHIR organizes information into standardized resources such as Patient, Observation, Encounter, Condition, and MedicationRequest, facilitating APIs and interoperability between modern platforms.

Integration can follow this flow:

1. receive HL7 v2 messages, FHIR resources, or equipment events;
2. validate the patient, encounter, time, unit, and terminology;
3. transform records into a consistent clinical data model;
4. calculate features such as trends, moving averages, and variations;
5. run the predictive model;
6. return the risk to the dashboard or electronic health record used by the care team.

Near-real-time processing is important, but low latency does not compensate for incorrect data. In many scenarios, a reliable update every few minutes is more useful than an instant response based on incomplete records.

Model and Explainability

Logistic regression, decision trees, gradient boosting, and neural networks can be used. The choice should consider performance, data volume, the need for explanation, operating costs, and ease of maintenance.

At a minimum, each alert should report:

• estimated risk and time window;
• risk trend;
• variables that contributed the most;
• missing or potentially outdated data;
• time of the most recent analysis;
• expected action, such as reviewing the patient or applying an institutional protocol.

Explainability does not turn correlation into causation, but it allows professionals to verify whether the recommendation is consistent with the clinical picture.

How to Measure Whether the Prediction Works

Accuracy alone is inadequate when the event is rare. If only 5% of patients experience a given outcome, a system that always responds “no risk” will have 95% accuracy and no clinical utility.

The most relevant metrics include:

• sensitivity: proportion of actual cases identified;
• specificity: proportion of patients without the event who are correctly ruled out;
• positive predictive value: how many alerts correspond to actual cases;
• AUROC and AUPRC: discrimination ability, with particular attention to AUPRC for rare events;
• calibration: agreement between predicted risk and observed frequency;
• useful lead time: time between the alert and the event;
• alerts per bed/day: operational indicator of alert fatigue;
• time to assessment or intervention: measure of the effect on clinical workflow.

The alert threshold represents a trade-off. Lowering it increases sensitivity but also increases false positives. Raising it reduces noise but may leave at-risk patients without an alert. The definition should involve physicians, nursing staff, patient safety teams, IT, and data science.

Clinical Validation and Safe Deployment

Before displaying alerts to the care team, the hospital can run the model in silent mode: predictions are recorded but do not interfere with care. This phase makes it possible to measure performance using local data, detect integration failures, and select thresholds.

A minimum checklist includes:

• unambiguously defined clinical outcome;
• documented population and exclusion criteria;
• temporal separation between training and testing;
• prevention of future data leakage;
• validation by hospital, unit, and demographic profile;
• analysis of false positives and false negatives;
• protocol for system unavailability;
• clinical owner for each type of alert;
• drift monitoring after deployment;
• auditing of data, model, and decision versions.

It is also necessary to compare the model with protocols and scores already used by the hospital. AI is only justified if it provides measurable gains in lead time, discrimination, calibration, or operational efficiency.

Risks, LGPD, and Clinical Responsibility

Health data are sensitive personal data under the LGPD. The project must adopt role-based access control, encryption, audit logs, credential management, appropriate retention, and minimization of the data processed. Development environments should not receive indiscriminate copies of the production database.

The main technical and clinical risks are:

• bias against underrepresented groups;
• excessive alerts and resulting desensitization;
• changes in patient profiles over time;
• dependence on inconsistently completed fields;
• automation of a recommendation without human review;
• integration outages that produce outdated risk estimates.

The dashboard must make it clear that the system provides decision support. Clinical decisions, diagnoses, and treatments remain the responsibility of qualified professionals and institutional protocols. Depending on the intended purpose and manner of use, the regulatory classification applicable to the software must also be assessed.

Criteria for Prioritizing a Hospital AI Project

A hospital can prioritize the initiative when there is a relevant outcome, sufficient digital data, a response protocol, and the ability to measure results. Without these four elements, the project tends to become merely a proof of concept.

Objective questions for the decision include:

1. Which event will be predicted, and how many hours in advance?
2. Which clinical decision could change after the alert?
3. Are the required data available at the time of prediction?
4. How many alerts can the team review per shift?
5. How will safety, response time, and impact on care be measured?
6. Who will suspend the model if its performance declines?
7. Will the system remain safe when an integration fails?

A gradual deployment—starting with one unit, one outcome, and one protocol—reduces risk and facilitates comparisons between periods.

How Predictor Solutions Addresses This

Predictor Solutions develops Predictor AI Hospitals, focused on predicting sepsis, heart attack, and pneumonia in the ICU, as well as Predictor Health, which consolidates health and wearable data into dashboards. Execution combines data engineering, hospital integration with HL7 v2 and FHIR, AI models, cloud/DevOps infrastructure, security, and dashboards designed around clinical workflows.

The method begins with outcome definition and source auditing, proceeds to integration and retrospective validation, moves through silent operation, and only then advances to monitored clinical alerts. Predictor Solutions, a software house based in Lavras, Minas Gerais, has already served 9 medium-sized and large companies; considering its software and automation projects, it reports average savings of R$ 1.32 million per client per year, an average productivity increase of 70%, and a 43% increase in profit over six months. These corporate indicators do not replace the specific clinical validation required at each hospital.

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