AI applied in hospitals can estimate the risk of sepsis, heart attacks, and pneumonia by continuously analyzing vital signs, laboratory tests, medications, and ICU clinical history. Its value does not lie in replacing medical decision-making, but in identifying deterioration hours before static rules, prioritizing patients, and delivering explainable alerts within the care workflow.
How clinical prediction works in an ICU
A hospital predictive system transforms distributed clinical data into an updated risk estimate. Instead of considering only an isolated value, such as temperature or heart rate, the model evaluates trends, combinations of variables, and changes in the patient’s condition.
The basic workflow has six stages:
- Collect data from the electronic health record, laboratory, monitors, and imaging systems.
- Normalize units, codes, timestamps, and patient identifiers.
- Create a clinical timeline without improperly using future information.
- Calculate the risk of an event within a defined window, such as 6, 12, or 24 hours.
- Apply alert criteria compatible with the team’s operational capacity.
- Record the clinical response and outcome for auditing and model improvement.
The prediction window must correspond to a possible action. An alert issued 12 hours in advance may be useful if there is a protocol for reassessment, test collection, or monitoring adjustments. A prediction without an associated course of action only increases the volume of notifications.
What data feeds the models
ICUs generate dense, heterogeneous, and failure-prone data. The most common sources are:
- vital signs: blood pressure, heart rate, respiratory rate, temperature, and oxygen saturation;
- tests: complete blood count, lactate, creatinine, troponin, blood gas analysis, and inflammatory markers;
- clinical support: mechanical ventilation, oxygen, vasoactive drugs, and fluid balance;
- medication prescriptions and administrations;
- diagnoses, comorbidities, and previous procedures;
- clinical notes and reports, when secure text processing is available;
- ECGs, X-rays, and CT scans, if the project includes signals or images;
- administrative events, such as admission, transfer, and discharge.
More data does not automatically mean better performance. Measurement frequency, missing values, and the decision to order a test also carry information, but they may introduce bias. A model trained in an ICU that orders lactate tests frequently may not work in the same way at another institution.
Integration through HL7 v2 and FHIR
In legacy environments, HL7 v2 messages such as ADT and ORU can carry admissions, transfers, and laboratory results. In more recent architectures, FHIR resources such as Patient, Encounter, Observation, Condition, MedicationRequest, and DiagnosticReport provide a standardized representation for clinical APIs.
At a minimum, the integration must address:
- correct linkage among the patient, hospitalization, and bed;
- conversion of local units and codes;
- message deduplication;
- events received out of order;
- latency between collection, release, and data availability;
- traceability back to the original source.
FHIR does not eliminate semantic problems. Two hospitals may use the same Observation resource and represent the same test with different codes, units, or interpretations. Therefore, clinical mapping must be validated with care professionals and interoperability specialists.
Sepsis prediction
Sepsis involves organ dysfunction associated with a dysregulated response to infection. Predictive models seek to detect patterns consistent with deterioration before clinical confirmation by combining variables such as blood pressure, temperature, respiratory rate, lactate, white blood cell count, kidney function, vasopressor use, and ventilatory support.
The first challenge is defining the target event. Criteria based on Sepsis-3, diagnosis codes, cultures, antibiotics, or manual review may produce different patient datasets. If the label is inaccurate, the model will learn an approximation of the documentation process rather than necessarily learning the clinical condition.
Information leakage must also be prevented. For example, using a prescription issued after medical suspicion to predict supposedly earlier sepsis produces artificially high metrics. Each variable must be available at the actual time when the prediction would be calculated.
Heart attack prediction and cardiovascular deterioration
Cardiovascular risk assessment can combine documented symptoms, ECGs, troponin, blood pressure, heart rate, oxygenation, comorbidities, and changes over time. In sedated patients or those with limited communication, physiological and laboratory changes may carry greater weight because classic symptoms are unavailable.
A model should not display “confirmed heart attack” when it produces only a probability. The safer result is a risk classification accompanied by contributing factors and operational guidance, such as reassessing the patient or following the institutional protocol.
When ECG or troponin data are part of the input, it is essential to distinguish the collection time, release time, and time of access by the algorithm. In addition, validation must analyze subgroups, including age, sex, comorbidities, and different ICU profiles, because clinical presentation and prevalence vary.
Pneumonia prediction
Pneumonia prediction may use temperature, white blood cell count, saturation, secretions, ventilatory parameters, microbiology, and radiological findings. For patients on mechanical ventilation, the project must clearly distinguish community-acquired, hospital-acquired, and ventilator-associated pneumonia because their criteria and onset times differ.
Images can be analyzed through computer vision, but they should not be treated in isolation. Radiological infiltrates may also occur in pulmonary edema, atelectasis, and other conditions. Combining structured data, reports, images, and clinical context tends to be more useful than a context-free classification.
The label must account for diagnostic uncertainty. Specialist review, institutional criteria, and adjudication of discordant cases are more reliable than relying exclusively on codes entered for billing or discharge purposes.
How to assess whether the model actually works
Accuracy alone is inadequate for relatively rare events. A system that classifies all patients as negative may appear accurate while still failing to detect any relevant cases.
The minimum metrics include:
- sensitivity: proportion of events identified;
- specificity: proportion of non-events correctly ruled out;
- positive predictive value: how many alerts correspond to events;
- area under the precision-recall curve, useful for imbalanced classes;
- calibration: correspondence between predicted risk and observed frequency;
- useful lead time: time between the alert and the clinical event;
- alerts per patient/day and per professional/shift;
- alert acknowledgment, action, and silencing rates.
Validation must be temporal, using periods after training, and external whenever possible. Before affecting care, a silent phase is recommended: the system calculates risks without displaying them, allowing performance, latency, and stability to be measured in the real-world environment.
Criteria for moving into production
A hospital should answer “yes” to the following questions:
- Does the target event have a documented clinical definition?
- Is the alert linked to a protocol and a responsible person?
- Has the model been validated with local data and recent periods?
- Is there an acceptable limit of alerts per shift?
- Do predictions show contributing factors and data timestamps?
- Is there monitoring for failures, drift, and performance by subgroup?
- Can the system be stopped without compromising the electronic health record?
- Is every action, model version, and data source auditable?
Security, LGPD, and human oversight
Health data is sensitive personal data under the LGPD. The project must restrict access, log operations, encrypt data in transit and at rest, and define retention, purpose, and legal basis with the institution’s governance team.
The architecture must also separate development and production environments. Identifiable data must not be copied into testing environments without appropriate controls. Techniques such as pseudonymization reduce exposure but do not eliminate the risk of re-identification.
Depending on its intended purpose, form of use, and regulatory classification, the software may be subject to requirements applicable to software as a medical device. This analysis must take place before implementation, with participation from clinical, legal, security, quality, and, when applicable, regulatory teams.
Human oversight does not mean merely displaying a warning that “the decision is the physician’s.” The system must allow users to review evidence, challenge the alert, record the rationale, and communicate data unavailability or poor data quality.
Key trade-offs
The alert threshold determines the balance between detecting more cases and generating more false positives. Increasing sensitivity may heighten alert fatigue; increasing positive predictive value may fail to flag patients whose condition is deteriorating.
Other trade-offs include:
- complex models may achieve better discrimination but make explanations more difficult;
- real-time updates reduce delays but increase cost and operational complexity;
- local models better reflect the hospital but may generalize less effectively;
- textual data and images broaden the context but require additional infrastructure and governance;
- excessive automation increases risk; insufficient automation may not change the operational outcome.
Therefore, the goal should not be to maximize a single metric, but to produce measurable clinical benefits with a sustainable alert burden.
How Predictor Solutions addresses this
Predictor Solutions develops Predictor AI Hospitals for predicting sepsis, heart attacks, and pneumonia in ICUs by combining clinical data engineering, artificial intelligence, and hospital integration. The implementation accounts for HL7 v2 and FHIR interoperability, temporal validation, traceability, drift monitoring, security, and risk delivery within the care workflow.
The company also maintains Predictor Health, focused on health dashboards and wearable data. Across its software, data, and automation projects, Predictor Solutions has served 9 medium-sized and large companies; the reported aggregate results are 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 figures are general results from the company’s operations and should not be interpreted as clinical metrics for Predictor AI Hospitals.
A responsible hospital implementation begins with event definition, source assessment, silent-mode integration, and local validation. Only then should the alert be incorporated into care protocols, always with professional oversight and continuous monitoring.
Contact: contato@predictorsolutions.com / WhatsApp +55 31 98835-3246