← All articlesIA em Saúde

    AI Applied in Hospitals: Predicting Sepsis, Heart Attack, and Pneumonia with ICU Data

    Understand how clinical ICU data can support the prediction of sepsis, heart attack, and pneumonia without replacing medical decision-making.

    August 28, 2026 · 8 min read

    AI applied in hospitals can analyze vital signs, laboratory tests, medications, and clinical progression to estimate the risk of sepsis, heart attack, and pneumonia before the condition becomes evident. To operate safely, however, the model needs reliable data, local clinical validation, integration with the electronic health record, and alerts designed to support—never replace—the care team.

    What predicting clinical events in the ICU means

    Clinical prediction is not automatic diagnosis. It is the calculation of a probability, updated as new data enters the system, to indicate which patients require priority assessment.

    In an ICU, this may mean estimating the risk of an event within a defined window, such as the next 6, 12, or 24 hours. The result can be presented as a score, a risk range, or an alert accompanied by the factors that contributed most to the estimate.

    Defining the target is critical. “Predicting sepsis,” for example, may represent different tasks:

    • identifying risk before specific clinical criteria are met;
    • detecting possible deterioration in patients with suspected infection;
    • prioritizing the review of patients with combined abnormalities;
    • estimating worsening, need for support, or an adverse outcome.

    Without a precise temporal and clinical definition, statistical performance loses practical value. An alert issued after the team has already recognized the condition does not provide advance warning, even if it is classified as a correct prediction in the database.

    Which ICU data can feed the models

    Most hospital models use structured data and time series. The most relevant sources include:

    • vital signs: heart rate, blood pressure, temperature, respiratory rate, and oxygen saturation;
    • tests: complete blood count, lactate, troponin, creatinine, blood gas analysis, and inflammatory markers;
    • clinical support: mechanical ventilation, oxygen therapy, and vasoactive drugs;
    • medications, prescriptions, and administration times;
    • diagnoses, comorbidities, age, and hospitalization history;
    • fluid balance, urine output, and device records;
    • clinical notes and reports, when secure text processing is available;
    • data from monitors, electronic health records, laboratories, and imaging systems.

    Having many fields does not mean having adequate information. Quality depends on measurement frequency, standardized units, documentation delays, missing values, and consistency across systems. A blood pressure measurement entered manually after a delay should not be treated as if it had been collected in real time.

    Integrations through HL7 v2 and FHIR help transport and organize this data. HL7 v2 remains common in hospital environments, especially for admission messages, laboratory results, and patient transfers. FHIR facilitates APIs based on resources such as Patient, Observation, Encounter, Condition, and MedicationRequest.

    How AI can support each condition

    Sepsis

    Sepsis involves organ dysfunction associated with a dysregulated response to infection. A model can combine trends in temperature, blood pressure, respiratory rate, lactate, white blood cell count, renal function, vasopressor use, and clinical context.

    The main challenge is correctly defining the onset time. Labels derived only from billing codes or discharge diagnoses may contain delays and biases. It is also necessary to prevent the model from using information documented only after the event, a problem known as data leakage.

    Heart attack

    When predicting heart attacks, troponin, symptoms, electrocardiograms, blood pressure, heart rate, comorbidities, and temporal progression may contribute to risk stratification. However, the model should not interpret every troponin elevation as a heart attack: myocardial injury can occur in other critical contexts.

    Integration with signals and reports requires temporal synchronization. When applicable, models that process ECGs or text need to be evaluated separately and then within the complete workflow. The output should support medical assessment protocols, not independently issue a definitive diagnosis.

    Pneumonia

    For pneumonia, temperature, oxygenation, respiratory rate, white blood cell count, ventilation, microbiology, antimicrobials, radiology reports, and clinical progression may be considered. In ventilated patients, distinguishing between colonization, ventilator-associated pneumonia, and other causes of respiratory deterioration requires context.

    Image-based models can help identify radiological patterns, but they do not replace medical history, physical examination, microbiology, and expert judgment. A multimodal system can combine images, text, and time series, provided that each source is validated and available at the actual time of prediction.

    Technical architecture of a hospital solution

    An operational architecture generally has five layers:

    1. Ingestion: receives data from the electronic health record, laboratory, monitors, and departmental systems through HL7 v2, FHIR, APIs, or queues.
    2. Standardization: converts units, identifies the patient and encounter, handles duplicates, and records clinical and technical timestamps.
    3. Analytics layer: generates temporal variables, runs the model, and records its version.
    4. Clinical delivery: displays risk, trends, and explanations in the dashboard or electronic health record used by the team.
    5. Monitoring: tracks availability, latency, data quality, performance, and distribution shifts.

    The system must also maintain an audit trail: which data was used, which version calculated the risk, when the alert was generated, and how it was handled. Access control, encryption, environment segregation, secrets management, and an incident response plan are basic requirements for sensitive data.

    In Brazil, data processing must comply with the LGPD and the rules applicable to the software and care context. The regulatory classification depends on the purpose, features, and risk; therefore, it must be assessed with the legal, clinical, security, and quality teams, including Anvisa requirements when applicable.

    How to assess whether the model actually works

    Accuracy alone is inadequate, especially when the event is uncommon. Metrics must reflect clinical use:

    • sensitivity: proportion of events identified;
    • specificity: proportion of non-events correctly ruled out;
    • positive predictive value: how many alerts correspond to the defined target;
    • AUROC and AUPRC: discrimination ability, considering prevalence;
    • calibration: agreement between predicted risk and observed frequency;
    • useful lead time: time between the alert and the event;
    • alerts per bed or per shift: operational burden;
    • time to assessment: effect on the care process.

    Validation must respect time. Randomly splitting records may place past and future hospitalizations from the same environment in the training and test sets, producing optimistic estimates. A more robust strategy includes temporal validation, external testing, and silent prospective evaluation.

    During the silent phase, the model runs without displaying alerts. This makes it possible to verify latency, volume, stability, and clinical timing before interfering with the workflow. A controlled deployment can then compare previously defined processes, with clinical supervision and stopping criteria.

    No model should be promoted as capable of reducing mortality or hospitalization without an appropriate study. Good retrospective performance does not prove clinical benefit.

    Main risks and trade-offs

    Alert fatigue

    Increasing sensitivity generally generates more false positives. If nearly every patient triggers the system, the team stops trusting it. The threshold must account for prevalence, response capacity, and the cost of missing a case.

    Bias and population shifts

    Performance may vary by age group, sex, comorbidity, unit, and local protocol. Changes in equipment, tests, or clinical practices also alter the data. Therefore, aggregate and stratified metrics must be continuously monitored.

    Automation without context

    Simplified explanations, such as a list of important variables, do not prove causality. The interface must disclose limitations, missing data, and the time of the last update, in addition to providing access to the clinical context.

    Infrastructure dependency

    A sophisticated model is useless if data arrives late or the dashboard is unavailable. In hospitals, reliability, contingency planning, and integration are often as important as the algorithm.

    Checklist for deploying predictive AI in the ICU

    Before purchasing or developing a solution, the hospital should answer:

    • Which event will be predicted, and within what time window?
    • What clinical action is expected after the alert?
    • Who will be responsible for reviewing and documenting the decision?
    • Does the required data exist before the event, and does it arrive with low latency?
    • Has the model been validated with populations and protocols similar to the local ones?
    • Are sensitivity, positive predictive value, calibration, and alert burden acceptable?
    • Is there integration with HL7 v2, FHIR, or the systems already in use?
    • Are there audit trails, version management, and a contingency plan?
    • Will performance be analyzed across subgroups and over time?
    • Have security, LGPD, regulation, and clinical governance been assessed?
    • Is there a protocol for suspending or recalibrating the model?
    • Will the impact be measured without confusing correlation with clinical benefit?

    How Predictor Solutions addresses this

    Predictor Solutions develops healthcare systems with HL7 v2 and FHIR integration, data engineering, cloud/DevOps infrastructure, and security controls. Predictor AI Hospitals is designed to predict sepsis, heart attack, and pneumonia in the ICU, while Predictor Health organizes healthcare dashboards and wearable data.

    The work begins with defining the event and clinical workflow, continues through data integration and quality, and includes temporal validation, delivery of risk estimates through operational interfaces, auditing, and monitoring. Care decisions remain with qualified professionals; AI acts as a prioritization and decision-support mechanism.

    As a software house, Predictor Solutions reports having served 9 medium-sized and large companies, 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 figures represent business results disclosed by the company and should not be interpreted as evidence of clinical outcomes from the hospital product.

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

    Frequently asked questions

    Can AI predict sepsis before physicians do?

    AI can detect combinations and trends in data before explicit criteria are documented, but this does not mean it outperforms physicians in every scenario. The benefit depends on data quality, useful lead time, local validation, and a protocol for the team to assess the alert.

    What data is needed to predict sepsis, heart attack, and pneumonia in the ICU?

    Models can use vital signs, laboratory tests, medications, ventilatory support, comorbidities, and temporal progression. ECGs, reports, images, and clinical notes may also contribute, provided they are available at the time of prediction and securely integrated.

    Can an AI alert confirm a diagnosis of heart attack or pneumonia?

    Not on its own. The alert represents a risk estimate and must be interpreted alongside symptoms, tests, images, protocols, and the judgment of qualified professionals.

    How can you determine whether a hospital AI model is reliable?

    Check sensitivity, positive predictive value, calibration, useful lead time, and the number of alerts per shift, as well as temporal and external validation. It is also necessary to monitor subgroups, data changes, latency, availability, and impact on the actual workflow.

    Are HL7 v2 and FHIR required to use AI in hospitals?

    They are not the only means of integration, but they help connect electronic health records, laboratories, and other systems in a structured way. HL7 v2 is common in legacy systems, while FHIR provides resources and APIs that are better suited to modern integrations.

    Keep reading