AI applied in hospitals can estimate the risk of sepsis, acute myocardial infarction, and pneumonia hours in advance by continuously analyzing vital signs, test results, medications, and clinical history. These models do not replace medical diagnosis: they function as decision-support systems that prioritize patients for evaluation, provided they are validated in the local population, integrated into the care workflow, and monitored for false alerts and degradation.
What AI Can Actually Predict in an ICU
An ICU produces dense time series: heart rate, blood pressure, oxygen saturation, temperature, respiratory rate, laboratory results, fluid balance, mechanical ventilation, and medication administration. AI combines these variables to identify deterioration patterns that are difficult to detect through isolated analyses.
The most useful output is not a statement such as “the patient will develop sepsis,” but a probability associated with a time window and explicit clinical criteria. Examples include:
- risk of sepsis within the next 6, 12, or 24 hours;
- risk of myocardial infarction or myocardial injury within the next few hours;
- risk of hospital-acquired or ventilator-associated pneumonia;
- probability of deterioration requiring review by the care team;
- factors that contributed most to the score at that moment.
This distinction is essential. Prediction is a statistical estimate; diagnosis requires clinical evaluation, confirmatory tests, and the application of medical protocols.
Which Hospital Data Feed the Models
Prediction quality depends less on raw volume and more on the temporal consistency, coverage, and clinical meaning of the data.
Vital Signs and Monitoring
The main data include heart rate, respiratory rate, blood pressure, temperature, SpO₂, level-of-consciousness scale, and ventilatory parameters. In addition to absolute values, the model can analyze trends, variability, and rate of change.
A progressive drop in blood pressure, for example, may be more informative than an isolated measurement that is still within the reference range.
Laboratory Tests
Lactate, white blood cell count, platelets, creatinine, bilirubin, troponin, blood gas analysis, C-reactive protein, and other tests help characterize infection, organ dysfunction, and cardiac injury. The actual collection time and result release time must be preserved to prevent information leakage during training.
Prescriptions, Procedures, and Clinical Context
Antibiotics, vasopressors, anticoagulants, mechanical ventilation, cultures, invasive access, and previous diagnoses provide context. However, some of these variables reflect medical decisions that have already been made. If used carelessly, the model may merely reproduce existing practices instead of anticipating the event.
HL7 v2 and FHIR Integration
Hospitals often distribute data across electronic health records, laboratories, pharmacies, monitors, and administrative systems. HL7 v2 messages, such as ADT and ORU, are common in legacy environments; FHIR resources, such as Patient, Observation, Encounter, MedicationRequest, and DiagnosticReport, enable more structured APIs.
The architecture must normalize units, codes, identifiers, and timestamps before inferring risk. It also needs to handle duplicate messages, corrected results, and patients transferred between departments.
How to Model Sepsis, Myocardial Infarction, and Pneumonia
Each condition requires its own outcome definition. Combining diseases into a single generic deterioration label reduces clinical usefulness.
Sepsis Prediction
A sepsis project must state how the event will be labeled. The Sepsis-3 definition associates sepsis with infection and organ dysfunction, but its retrospective operationalization varies according to the available data.
Relevant variables may include temperature, blood pressure, lactate, white blood cell count, kidney function, platelets, respiratory rate, mental status, cultures, and antimicrobials. The model must exclude information recorded only after the clinical onset of the condition.
The prediction horizon must also be selected. Alerting too early may increase false positives; alerting too late reduces the operational benefit.
Prediction of Myocardial Infarction and Myocardial Injury
The Fourth Universal Definition of Myocardial Infarction distinguishes myocardial injury, characterized by changes in troponin, from myocardial infarction associated with evidence of ischemia. Therefore, predicting only “elevated troponin” is not equivalent to predicting myocardial infarction.
A hospital model can combine serial troponin measurements, structured electrocardiogram data when available, blood pressure, heart rate, recorded symptoms, vasopressor use, and cardiovascular history. Labels must distinguish type 1 myocardial infarction, type 2 myocardial infarction, and other causes of myocardial injury when the clinical use requires this separation.
Pneumonia Prediction
Hospital-acquired pneumonia and ventilator-associated pneumonia present labeling challenges. Fever, secretions, leukocytosis, and radiological changes may have other causes in critically ill patients.
Models can consider ventilation duration, respiratory parameters, oxygenation, temperature, microbiological tests, and imaging reports. Institutional criteria should be compared with recognized references, such as CDC/NHSN surveillance definitions, without confusing epidemiological surveillance with individual diagnosis.
How to Evaluate Whether the Model Is Clinically Useful
A high AUROC alone does not demonstrate usefulness. For less frequent events, the area under the precision-recall curve, or AUPRC, tends to be more informative.
The evaluation should include:
- sensitivity: how many events were detected;
- specificity: how many patients without an event were correctly ruled out;
- positive predictive value: how many alerts corresponded to actual cases;
- calibration: whether predicted risks of 20% occur in approximately 20% of similar cases;
- median lead time: how much useful time existed between the alert and the event;
- alerts per bed per day;
- performance by age, sex, unit, comorbidities, and care profile;
- impact on evaluation time and protocol adherence.
The alert threshold must be decided with the clinical team. If an ICU generates 40 alerts per day and only 4 are actionable, the problem is not only statistical: there is a risk of alert fatigue.
Proper validation separates data by time and, whenever possible, by hospital. Randomly dividing records from the same patient between training and testing can inflate performance. Before activating notifications, a silent phase is recommended, during which the system calculates risks without interfering with care.
Recommended Technical Architecture
A secure implementation can be organized into six layers:
- Ingestion: receipt of events from the electronic health record, laboratory, pharmacy, and monitors through HL7 v2, FHIR, or authorized interfaces.
- Normalization: conversion of units, terminologies, dates, identifiers, and physiological ranges.
- Clinical timeline: consolidation of the events available at each point in time without using future information.
- Inference: versioned execution of the model, with logging of inputs, outputs, and timestamps.
- Clinical delivery: display in the electronic health record, dashboard, or worklist, accompanied by a response protocol.
- Monitoring: tracking latency, missing data, calibration, drift, and alert volume.
The system must also operate appropriately during failures. If the laboratory stops sending data or the integration is delayed, the risk must not be presented as though it were up to date. The interface must display the last update and the quality of the data used.
Security, LGPD, and Clinical Governance
Health data are sensitive personal data under Brazil’s General Data Protection Law (LGPD). The project must apply role-based access control, encryption in transit and at rest, audit trails, environment segregation, and retention compatible with the intended purpose.
Training and validation must use only the necessary data. Pseudonymization reduces exposure but does not eliminate legal obligations. The legal basis, the roles of controller and processor, and incident response procedures must be documented.
In addition to privacy, clinical governance must be established. A responsible committee must approve the objective, usage criteria, and conditions for suspending the model. Changes in equipment, tests, protocols, or patient profiles may cause drift even without code changes.
Depending on the intended purpose, presentation method, and decisions influenced, the solution may be subject to regulatory requirements applicable to software as a medical device. This analysis must take place before deployment in patient care, not afterward.
Checklist for a Hospital Project
Before purchasing or developing a solution, verify:
- [ ] Is the outcome defined by auditable clinical criteria?
- [ ] Is there a prediction window that is useful to the team?
- [ ] Do the timestamps represent when the information became available?
- [ ] Was testing performed on a period different from the training period?
- [ ] Are local validation and subgroup analysis available?
- [ ] Is the presented risk calibrated?
- [ ] Can the operation handle the expected number of alerts?
- [ ] Does each alert have an assigned owner and response protocol?
- [ ] Does the integration support HL7 v2 or FHIR without relying on manual input?
- [ ] Does the system report unavailability and delayed data?
- [ ] Are audit, access control, and incident plans in place?
- [ ] Will performance be monitored after production deployment?
Key Trade-Offs
More complex models can capture nonlinear relationships, but they are more difficult to audit. Simple models, such as logistic regression, may be sufficient when data are limited and explainability is a priority.
High sensitivity detects more cases but increases false alerts. High specificity reduces interruptions but may leave at-risk patients without warnings. Real-time processing improves timeliness, although it requires more robust integrations and infrastructure than periodic updates.
The best model is not necessarily the one that wins on a retrospective metric. It is the one that delivers reliable risk at the right time, to the responsible person, with a defined clinical action.
How Predictor Solutions Addresses This
Predictor Solutions develops Predictor AI Hospitals to support the prediction of sepsis, myocardial infarction, and pneumonia in ICUs. The work combines clinical data engineering, HL7 v2 and FHIR integration, time-series modeling, dashboards, cloud/DevOps, security, and model monitoring.
Implementation begins with the clinical definition of the outcome and the mapping of hospital data sources. Next, the clinical timeline, retrospective validation, silent phase, and integration into the care workflow are structured. The company also develops Predictor Health, which focuses on health dashboards and wearable data.
Based in Lavras, Minas Gerais, Predictor Solutions has served 9 medium-sized and large companies. Across its projects, it reports average results of R$ 1.32 million in savings per client per year, a 70% increase in productivity, and 43% profit growth in six months; these indicators are corporate and should not be interpreted as clinical results of the hospital model.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246