HealthLeap

The model is the product. No hardware, no separate application, no services layer: the platform reads the chart, computes a risk score and writes it into the workflow. Remove the model and nothing remains. The company's own framing is consistent with this, positioning malnutrition as the first condition its screening engine addresses rather than as the product itself, which implies the engine rather than any one indication is the asset.

A dedicated clinical use and safety statement, which almost nothing in this category publishes, and its content is genuinely constraining rather than decorative. The software is stated not to be a diagnostic tool, not to provide treatment recommendations, not to be used as the sole basis for determining nutritional risk or the presence of malnutrition, and to support rather than direct clinical decision making, with explicit instruction to use it alongside clinical assessment, physical assessment and laboratory findings.

That is a complete adjunctive position published in one place where a clinician can find it. Nothing is auto actioned and there is no low risk or de escalation output. Held below A because no threshold, false negative rate or abstention behaviour is published, and because screening 100 percent of inpatients daily generates alert volume that nothing published quantifies, in a category whose defining failure is alerts being ignored.

The input space is enumerated properly rather than gestured at: clinical notes, laboratory results, vital signs, active medication orders and problem lists, analysed daily across the whole admission.

The technical boundary statement is the unusual part and it is credited. The company states that the software uses only existing EHR data and evidence based risk factors, and expressly that it does not acquire or process medical images, waveforms or device signals. Publishing what a system does not do is rare in this market.

One precision on what kind of scope statement this is. It bounds the data sources rather than telling a clinician what the absence of a flag does not rule out, which is the more valuable form this index credits in Eko Health.

Held at B because the model class, features, training population, validation methodology and operating characteristics are all undisclosed, and evidence based risk factors is not a specification.

The narrow purpose sits against total access, and that gap is the substance of this record. The platform is described as continuously analysing every adult inpatient chart daily across an entire health system, drawing on clinical notes, laboratory results, vital signs, active medication orders and problem lists from admission through discharge. The product exists to identify nutritional risk, and to do that it reads the whole record including free text notes.

Clinical narrative is where the most sensitive material in any chart sits: social circumstances, mental health, substance use, safeguarding concerns, family conflict, none of it relevant to a nutrition screen and all of it processed anyway. That is not an argument against the design, because a model cannot know in advance which sentence carries the signal, and a screening tool that read only structured fields would miss most of what matters.

It is the reason the retention and training questions carry more weight here than for a product reading laboratory values. Architectural credit is real and belongs alongside: the platform reads data already present in the record and ingests no device signals or images, so it adds nothing new to a hospital's estate. On enumeration there is nothing: no model, hosting arrangement or sub processor list. Ask what is retained after a score is produced, whether narrative text persists or only derived features, whether anything leaves the institution, and for the training position in contract language.

The deployment is substantial and specific: a systemwide rollout across Houston Methodist screening more than 150,000 inpatients annually, with a named executive sponsor, and stated intent to track clinical, operational and financial outcomes including length of stay and documentation accuracy. That is a real enterprise commitment at a major academic health system rather than a pilot.

The evidence claim itself could not be verified, and that is recorded rather than assumed. The company describes itself as the only commercially available peer reviewed validated platform of its kind and the only validated AI malnutrition screening tool, but no publication was retrieved in this pass, so the claim is noted as made rather than confirmed. Nothing published gives sensitivity, positive predictive value, alert burden or a comparison against the admission questionnaire the product replaces.

Flag for the refresh pass: locate the peer reviewed validation and grade it directly, since if it exists and is sound this axis moves materially.

No privacy policy, data processing statement, retention period or training use disclosure was located.

The architectural credit recorded earlier stands: the platform reads data already present in the record and ingests no device signals or images, so it adds nothing to a hospital's estate.

What the second pass establishes is the shape of what it reads, and it is the substance of this axis. The system is described as continuously analysing every adult inpatient chart daily across an entire health system, drawing on clinical notes, laboratory results, vital signs, active medication orders and problem lists, from admission through discharge.

So the purpose is narrow and the access is total. The product exists to identify nutritional risk, and to do that it reads the whole record including free text notes. Clinical narrative is where the most sensitive material in any chart sits: social circumstances, mental health, substance use, safeguarding concerns, family conflict, none of it relevant to a nutrition screen and all of it processed anyway.

That is not an argument against the design, since a model cannot know in advance which sentence carries the signal. It is the reason the retention and training questions matter more here than for a product reading structured fields. Establish what is retained after a score is produced, whether narrative text persists or only derived features, whether anything leaves the institution, and whether customer content contributes to model development.

Ask for the retention schedule and the training position in contract language.

No public statement on business associate agreements, execution terms, cost or subprocessor disclosure was located. A systemwide enterprise deployment means agreements plainly exist and were negotiated at scale, and nothing about them is published.

Two scope questions follow from what the second pass establishes, and both are worth putting even though an agreement clearly exists.

The first is population. The platform reads every adult inpatient chart continuously rather than the charts of patients referred to it. So the vendor holds protected health information about patients who were never flagged, never scored as at risk, and for whom the product did nothing. An agreement drafted around a screening service should be read to confirm it describes standing access to the whole inpatient population rather than access to the patients it acts on.

The second is where the output goes. The deployment is framed around documentation accuracy, consistency of identifying and recording patients, severity capture, and financial measures alongside clinical ones, and third party descriptions of the product mention improved diagnosis coding. Where screening output feeds documentation and coding, information derived from the record flows into revenue cycle processes. Establish whether the agreement covers that downstream use, and who is accountable if a documented diagnosis rests on a generated score.

Ask for the agreement, its description of the population and access model, and its scope over derived outputs.

A second pass again located no attestation, trust centre or report request path, and the earlier assessment was right that this is a material gap rather than a formality.

The second pass sharpens why. The access is not scoped by clinical need at the point of use. This is not a tool a clinician opens for a particular patient; it runs continuously in the background and reads every adult inpatient chart daily across a whole system, whether or not anyone has asked about that patient. So the permission the vendor holds is population wide and standing, and no human action gates any individual read.

That is an unusual privilege even among the platforms in this index, and it is what an examination would need to describe: how the standing credential is issued and rotated, what scope it carries, whether reads are logged in a way the institution can audit at patient level, and what a hospital can restrict.

The scale makes it concrete rather than theoretical. A single enterprise deployment covers a system reporting over a hundred and fifty thousand inpatients a year.

The evidentiary situation is also the familiar one and worth stating plainly for the vendor's benefit. A health system of that size does not grant standing access to its complete inpatient record without a security review, so an assessment of this company exists in a customer's hands. Publishing its outcome, or the attestation behind it, would close this row.

Ask which report is held, its scope, and how the standing access is credentialled and logged.

No FDA clearance was located and none is claimed. The clinical use and safety statement is evidently written with the clinical decision support exclusion in mind and does the work carefully: not diagnostic, no treatment recommendations, not the sole basis for a determination, supports rather than directs decision making, used alongside independent clinical and laboratory assessment.

That is a deliberately constructed exclusion posture rather than an accidental one, and it is stronger than most in this category because the underlying risk factors are described as evidence based and the clinician retains an independent assessment path. The company does not make the regulatory argument explicitly, so the basis is inferred from the language rather than stated, and a buyer should ask for it directly.

No subgroup performance, calibration or fairness analysis is published.

The structural exposure here is the revenue loop, and it is sharper than the comparable case in this category. Malnutrition is a documented comorbidity that raises the recorded severity of illness and the associated payment weight, and the company markets the platform on exactly that: aligning frontline care with hospital coding, ensuring conditions get coded, optimising reimbursement accuracy and defending against retrospective payer claim denials. So a single engine both identifies the condition and drives the documentation that captures the revenue from it, with no independent check between the two.

Identifying genuinely undiagnosed malnutrition is a real clinical good, and being paid appropriately for care delivered is legitimate, so this is recorded as a structure rather than an accusation, the same way OmniMD, Droxi Unlock and Luminare are treated. It is sharper here for a specific reason: malnutrition coding is an established area of payer scrutiny, and a product marketed partly as audit defence for a diagnosis it helped generate sits in an unusually tight loop.

A second exposure is unaddressed. A model reading free text notes inherits whatever variation exists in how thoroughly different clinicians document nutritional status, which differs by unit, by staffing and by patient.

A published negative scope statement carries this grade, and it is rare enough in this market to name. The company states that the software uses only existing record data and evidence based risk factors, and expressly that it does not acquire or process medical images, waveforms or device signals. Publishing what a system does not do is unusual, and it lets a buyer bound the product's claims without asking: whatever this tool concludes, it concluded from the chart.

The input space is also enumerated properly rather than gestured at, covering clinical notes, laboratory results, vital signs, active medication orders and problem lists, analysed daily across the whole admission. One precision about what kind of scope statement this is. It bounds the data sources rather than telling a clinician what the absence of a flag does not rule out, which is the more valuable form this index credits elsewhere.

Knowing the tool never sees a waveform is useful; knowing which malnourished patients it will systematically miss would be far more so. Held at C because the model class, features, training population, validation methodology and operating characteristics are all undisclosed, evidence based risk factors is not a specification, and no warranty, indemnity or remediation commitment was located. Ask what the absence of a flag does not rule out, for sensitivity against a reference standard, and for the risk factor list.

Workflow native by design, which is the property that determines whether a risk score is ever seen. Scores and prioritisation alerts are pushed into the interfaces nurses and dietitians already use rather than requiring a separate application or login, and the platform requires no additional documentation from clinicians, which matters in a category whose failure mode is clinician burden.

Reading unstructured clinical notes alongside structured labs, vitals, orders and problem lists implies a deeper integration than a discrete data feed. Held at B because no EHR vendor is named in retrieved material, no marketplace listing, Showroom entry or partner certification was located, and no FHIR or interface specification is published, so the depth is described by effect rather than by mechanism.

One named deployment but a serious one. Houston Methodist has rolled the platform out systemwide, covering more than 150,000 inpatients annually with 100 percent of adult inpatient charts screened daily from admission through discharge, and the health system's associate chief innovation officer is named publicly in support. An enterprise wide commitment at a large academic health system is a materially stronger reference than the pilot deployments common at this stage.

Held at B because it is a single named customer, no implementation timeline or resourcing requirement is published, no hosting architecture or data residency commitment is stated, and no second reference site was identified.

No pricing published at any level: no rate card, no unit of pricing such as per bed, per admission or per screened patient, no band and no implementation fee. The same asymmetry recorded against Droxi, Healthplus.ai and Kinometrix applies and is more pronounced here, because the company quantifies several categories of customer upside, reduced length of stay, increased revenue, improved reimbursement accuracy and reduced claim denials, while publishing nothing about cost. A buyer evaluating a return on investment case built entirely on the vendor's own revenue arithmetic should ask for the denominator.

Narrow and early. Coverage is a single condition, malnutrition risk, across adult inpatients in general hospital settings. The company frames this as the first condition rather than the only one and positions the underlying engine as a general screening safety net, but no second condition is documented and no timeline is published. No paediatric, obstetric or critical care specific configuration is described, and no population exclusions are stated beyond the adult inpatient scope. Narrow focus is reasonable for an early stage vendor with one enterprise customer, but this axis measures coverage and the coverage is one condition.