← All articlesIA em Saúde

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

    Learn how to use ICU data to predict sepsis, heart attacks, and pneumonia, from hospital integration to clinical validation and model monitoring.

    September 02, 2026 · 8 min read

    AI applied in hospitals can estimate the risk of sepsis, heart attacks, and pneumonia before clinical confirmation by continuously analyzing vital signs, tests, medications, and patient history. To be safe and useful, however, the solution must combine reliable data, temporal and local validation, alerts integrated into the care workflow, and supervision by healthcare professionals—the model does not replace medical diagnosis.

    What Predicting Clinical Events in an ICU Means

    A hospital predictive system calculates the probability of an event occurring within a defined window, such as sepsis within the next 6 hours or respiratory deterioration within the next 12 hours. This prediction is different from diagnosing a disease that is already present.

    A technically valid specification must answer five questions:

    1. What event will be predicted? The definition must be reproducible from clinical data.
    2. What is the population? Adults, pediatric patients, cardiac patients, or all ICU patients?
    3. What is the prediction window? Two, six, 12, or 24 hours?
    4. How often will the risk be recalculated? With each new data point, every 15 minutes, or hourly?
    5. What action should the alert trigger? Reassessment, test ordering, protocol activation, or escalation to the intensivist?

    Without these definitions, a high area under the ROC curve, or AUROC, may not represent clinical usefulness. An alert issued only a few minutes before conventional recognition, for example, may be statistically correct but operationally irrelevant.

    Which ICU Data Feed the Models

    ICUs produce heterogeneous, frequent, and failure-prone data. The most common sources are:

    • vital signs: heart rate, blood pressure, temperature, respiratory rate, and oxygen saturation;
    • laboratory tests: lactate, white blood cell count, creatinine, troponin, blood gas analysis, and inflammatory markers;
    • clinical support: mechanical ventilation, oxygen, vasopressors, and fluid balance;
    • medications, doses, and administration times;
    • diagnoses, comorbidities, and hospitalization history;
    • reports, progress notes, and other clinical texts;
    • demographic data and time since admission;
    • connected monitors and devices.

    Measurement frequency varies. A monitor may generate data every second, while a laboratory test may appear only a few times per day. The pipeline must align these time series without using future information, an error known as data leakage.

    Missingness can also carry information. A frequently ordered test may indicate clinical suspicion, but the model should not simply learn to reproduce decisions already made by the care team. It is necessary to distinguish the patient’s physiological state from the hospital’s operational behavior.

    Predicting Sepsis, Heart Attacks, and Pneumonia

    Sepsis

    Sepsis is a potentially fatal organ dysfunction caused by a dysregulated response to infection. Models can use trends in blood pressure, temperature, heart rate, lactate, kidney function, oxygenation, and clinical interventions.

    The main challenge is defining the label. Criteria associated with Sepsis-3 are useful for research, but their implementation depends on data availability and correct timestamps. Sepsis onset must not be defined using information recorded after the point at which the model would have needed to issue an alert.

    Acute Myocardial Infarction

    Predicting a heart attack requires a cardiology context. Troponin, electrocardiogram characteristics, chest pain, blood pressure, heart rate, and risk factors may contribute, but not all these data are structured.

    A solution may estimate the risk of coronary syndrome or prioritize patients for evaluation, but it should not be presented as an autonomous diagnosis. Troponin abnormalities may also occur in sepsis, kidney failure, and other conditions. Medical assessment, ECG, and biomarker trends remain essential.

    Pneumonia and Respiratory Deterioration

    For pneumonia, the model can combine temperature, white blood cell count, oxygenation, ventilatory parameters, secretions, microbiology, and imaging reports. In ventilated patients, the definition of ventilator-associated pneumonia is especially complex and subject to variation among evaluators.

    In some hospitals, predicting respiratory deterioration may be a more measurable objective than predicting pneumonia directly. The choice depends on the care protocol and the quality of the available labels.

    Technical Architecture and Interoperability

    A typical hospital architecture has four layers:

    1. Ingestion: captures information from the electronic health record, laboratory, pharmacy, and monitors.
    2. Normalization: converts units, standardizes codes, identifies duplicates, and organizes the timeline.
    3. Inference: generates the variables, runs the model, and records the version, timestamp, and explanations.
    4. Delivery: displays the risk in the system used by the care team and tracks the response to the alert.

    Legacy integrations frequently use HL7 v2, with messages such as ADT for patient movements and ORU for results. FHIR-based APIs can represent resources such as Patient, Observation, Encounter, Condition, and MedicationRequest. FHIR improves the semantics of data exchange, but it does not eliminate the need to map units, terminologies, and institution-specific rules.

    Integration unavailability must also be handled. If the latest vital sign arrived three hours ago, the system must indicate that the data are outdated, reduce its confidence, or suspend inference. Silence cannot automatically be interpreted as stability.

    How to Develop and Validate the Model

    Development must separate data by patient and by period. A random split of records may place different moments from the same hospitalization in both training and testing, producing an optimistic evaluation.

    A more realistic strategy includes:

    • training on a historical period;
    • validation on a later period at the same hospital;
    • external validation at another facility, when available;
    • a prospective silent study without displaying alerts;
    • controlled deployment with a response and auditing protocol.

    The minimum metrics are:

    • sensitivity: proportion of events correctly flagged;
    • specificity: proportion of non-events correctly excluded;
    • positive predictive value: how many alerts correspond to actual events;
    • AUROC and AUPRC: discriminatory ability, with particular attention to AUPRC for rare events;
    • calibration: correspondence between predicted risk and observed frequency;
    • useful lead time: time between the alert and the event;
    • alerts per patient/day: a direct indicator of operational burden.

    The threshold should not be selected solely to maximize a mathematical metric. If event prevalence is low, even a sensitive model may generate many false positives. The decision must consider team capacity, outcome severity, and the cost of delaying or anticipating an intervention.

    From Prediction to Clinical Decision

    The alert must indicate who is at risk, within what time horizon, and which data contributed, without implying improper causality. A useful interface can display vital-sign trends, recent tests, data integrity, and score progression.

    The response protocol must define:

    • who receives the alert;
    • how quickly reassessment must occur;
    • which clinical checks are recommended;
    • how to record acceptance, rejection, or justification;
    • when to escalate the case;
    • how to measure the care outcome.

    Excessive alerts cause fatigue and eventually become ignored. Grouping notifications, applying suppression periods, and prioritizing meaningful risk changes are generally more effective than issuing repeated warnings.

    Security, LGPD, and Governance

    Health data are sensitive personal data under the LGPD. The project must apply role-based access control, encryption, audit trails, appropriate retention, data minimization, and vendor management.

    It is also necessary to assess the solution’s regulatory classification according to its purpose, level of autonomy, and intended use. Systems that influence clinical decisions may require specific risk management, documentation, and regulation processes as medical software. This assessment must involve legal, clinical, security, and quality teams.

    After deployment, the hospital must monitor changes in prevalence, equipment, protocols, population, and electronic health record completion. Decreased calibration, increased alerts, or changes in data patterns may indicate drift. Every model update must be versioned, tested, and reversible.

    Checklist for Evaluating a Hospital AI Solution

    Before purchasing or developing a solution, verify that:

    • the outcome and prediction window are clearly defined;
    • there is temporal and, ideally, external validation;
    • metrics are presented at the actual operating threshold;
    • the vendor reports alerts per patient/day;
    • the model has been evaluated across relevant clinical and demographic groups;
    • the integration supports HL7 v2, FHIR, or the hospital’s existing standards;
    • there is a safe mode for missing or delayed data;
    • professionals can review the factors associated with risk;
    • all inferences and responses are recorded;
    • there is a monitoring, recalibration, and rollback plan;
    • deployment begins in silent mode and progresses gradually;
    • clinical and technical responsibilities are documented.

    How Predictor Solutions Addresses This

    Predictor Solutions develops AI applied to healthcare, data engineering, and hospital integrations using HL7 v2 and FHIR. Through Predictor AI Hospitals, it works with the prediction of sepsis, heart attacks, and pneumonia in ICUs, structuring projects from data ingestion to alert delivery, validation, and monitoring.

    The approach combines clinical outcome definition, time-series construction, data leakage prevention, calibration assessment, and integration into the care team’s workflow. The company also develops Predictor Health, a healthcare dashboard integrated with wearables, and applies cloud, DevOps, and security practices to environments that process sensitive data.

    Across Predictor Solutions’ software and AI projects, 9 medium-sized and large companies have already been served, with overall results of R$ 1.32 million in average savings per client per year, a 70% average increase in productivity, and a 43% increase in profit within six months. These are business indicators and do not, by themselves, represent the clinical effectiveness of hospital models, which must be demonstrated through validations specific to each institution.

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

    Frequently asked questions

    Can AI predict sepsis before doctors do?

    AI can identify risk patterns hours before clinical confirmation in some patients, but this depends on the selected window, data quality, and local validation. It functions as decision support: diagnosis and treatment decisions remain the responsibility of healthcare professionals.

    What data are needed to predict sepsis, heart attacks, and pneumonia in the ICU?

    Models typically use vital signs, laboratory tests, medications, ventilatory support, comorbidities, and hospitalization history. ECG, troponin, respiratory parameters, microbiology, and reports may be required depending on the event, provided they are available at the actual time of prediction.

    Are HL7 and FHIR mandatory for deploying AI in hospitals?

    They are not mandatory in every scenario, but they facilitate integration with electronic health records, laboratories, and other systems. HL7 v2 is common in legacy environments, while FHIR provides more standardized resources and APIs; both still require semantic mapping and data validation.

    How can you tell whether a hospital AI model is truly good?

    In addition to AUROC, evaluate sensitivity, positive predictive value, calibration, useful lead time, and alerts per patient/day. The model must undergo temporal validation, a prospective silent study, and evaluation at the hospital where it will be used.

    How long does it take to deploy predictive AI in an ICU?

    The timeline depends on data availability, integration with the electronic health record, label quality, internal approvals, and the clinical validation design. A responsible deployment includes technical assessment, integration, a retrospective study, silent operation, and gradual release, without treating software installation as the completion of the project.

    Keep reading