Kinometrix
Kinometrix builds machine learning models that predict hospital acquired harm from data already in the electronic health record. Its first product, the K-FRAS fall risk assessment system, is a proprietary predictive model producing real time fall risk predictions with the specific risk drivers attached, delivered to the frontline clinician. A pressure injury product follows the same pattern.
The company's argument for why a model is needed is sharper than most in this category and is worth stating in full, because it describes a failure mode rather than an opportunity. Nurses currently complete manual fall risk scores. Those instruments lack specificity and systematically overestimate risk, because they are built to avoid missing an at risk patient. The consequence is that a large proportion of patients get labelled high risk, and once that happens an organisation cannot resource individualised prevention, so it falls back on generic precautions applied to everyone. Kinometrix's position is that a more specific model lets a hospital direct resource intensive interventions to the patients who actually need them rather than diluting them across a ward.
Architecturally the platform is described as headless, meaning it carries no interface of its own and can be integrated with any EHR and configured to a given hospital's needs. It runs in the background against the record, evaluates markers to build a risk profile, writes updates back into the EHR automatically, and surfaces recommended interventions matched to that profile. The company emphasises that it adds no documentation burden, in contrast to tools that require nurses to complete additional fields, and the model takes the nurse's own expert assessment as one input alongside objective record data rather than replacing it.
Published claims include accuracy of around 98 percent, elimination of false low risk assessments, and a 6.5 to 1 return on investment, none of which is accompanied by a derivation, denominator or independent evaluation. Context the company cites for the problem: roughly one million hospitalised patients fall each year in the United States, about a third of those falls cause injury, and the annual cost to US hospitals is given variously as 6 and 7 billion dollars across its own pages. Pricing is not published.
Capability Axes
An AI Health Index grade measures what a buyer can verify from public sources on the date shown. It is not a rating of how good the product is. A vendor can build an excellent system and grade low on an axis because it publishes nothing an outsider can check. How grades read
The model is the entire product. Kinometrix has no hardware, no interface of its own and no services layer: it is a headless machine learning system that reads the electronic health record, computes a risk profile and writes it back. Apply the standard test and nothing remains if the model is removed.
This is the cleanest centrality case among the harm prevention vendors in this category, and the direct contrast with VirtuSense, which predicts the same outcome from in room sensing rather than from record data.
Nothing is auto actioned clinically. The system computes a risk profile, writes it to the record and prompts the care team with interventions matched to that profile, and a nurse decides what to do.
Two properties earn the B rather than a lower grade. The nurse's own expert assessment is an input to the model rather than something the model replaces, which is the same structural property that distinguishes Luminare in this category: the clinician sits inside the computation rather than downstream of it. And the output carries specific risk drivers rather than an opaque score, so a clinician can disagree with a driver rather than only with a number.
Held below A because no threshold, false negative rate or abstention behaviour is published, and because writing risk profiles into the record automatically raises an unaddressed question about what happens when the model's assessment and the nurse's documented assessment diverge.
The model is described only as a proprietary predictive machine learning model. No model class, no feature list, no training population, no development or validation methodology, no calibration and no operating characteristics are published.
Two partial disclosures are credited without lifting the grade. The input space is characterised at a high level as existing EHR data including the nurse's own assessment. And the product surfaces specific risk drivers alongside each prediction rather than a bare score, which is a real interpretability property, since a clinician can see what is driving the number and act on that rather than on the number alone. That driver level output is more than most competitors offer, and it would support a higher grade if the underlying model were described at all.
Nothing identifies any party in the chain: no model or model family, no hosting arrangement and no sub processor list was located in two passes, and no retention or training position was found. Two features of the data flow make the training question sharper here than the usual formulation.
The system reads existing record data including the nurses' own documented assessment, so what it consumes includes clinical judgement recorded by staff rather than only measurements, and it writes a score with its drivers back into the chart, so its output becomes part of the permanent record. That means the score does not need to be held twice, and what the vendor retains after writing it is unstated. The sharper point concerns outcomes.
A fall risk model improves by learning which predictions were followed by falls, so outcome data is the single most valuable material a deployment generates, and a hospital's falls are reportable safety events rather than ordinary operational data. Whether those outcomes flow back to the vendor, in what form, and whether one hospital's adverse events improve a model sold to another, is the material term and it is unaddressed in either direction. Ask where processing occurs, what is retained after a score is written, whether outcome data returns to the vendor, and on what basis.
Every claim is vendor published without derivation, and the headline figure is the weakest kind. Accuracy of around 98 percent is stated for an outcome the company itself describes as affecting roughly one million patients a year across US hospitals, which is an incidence of a few percent of admissions, so predicting that no patient will fall would already produce accuracy in the high nineties. Accuracy is the wrong metric for this problem, and its use here obscures performance rather than demonstrating it.
Elimination of false low risk assessments, reduction of preventable falls to virtually zero, superiority to all other fall risk prediction tools and a 6.5 to 1 return on investment are all asserted with no denominator, comparison group, time period or method. No peer reviewed evaluation, external validation or named customer result was located.
An internal inconsistency is recorded on the same basis applied to Affineon and Etiometry: the annual US cost of inpatient falls is given as 6 billion dollars on one page and 7 billion on another.
No privacy policy, data processing statement, retention period or training use disclosure was located, and the earlier assessment's framing of the architecture is confirmed.
The system reads existing record data continuously, including the nurses' own documented assessment, and returns a risk score with its contributing drivers into the chart. So the material it consumes includes clinical judgement recorded by staff, and the material it produces becomes part of the record.
Three questions follow and none is answered publicly. Where does processing occur, inside the hospital environment or the vendor's. What is retained by the vendor after a score is written, given the score itself now lives in the chart and does not need to be held twice. And does deployment data contribute to model development.
That last question has particular force for this product. A fall risk model improves by learning which predictions were followed by falls, so outcome data is the most valuable material a deployment generates. Establish whether outcomes flow back to the vendor, in what form, and whether a hospital's own falls, which are reportable safety events, contribute to a model other hospitals use.
One further point belongs here because it bears on what the retained record means. The vendor makes strong performance claims, including near elimination of preventable falls and of false low risk assessments. Where a score is written into the chart and a fall subsequently occurs, that sequence is a documented artefact with consequences. Establish what is retained about scores that preceded an adverse event, and who can reach it.
No public statement on business associate agreements, execution terms, cost or subprocessor disclosure was located, and no named hospital customer was identified, so the posture appears untested in public.
One feature of this product places it in a category buyers frequently overlook, and it is worth stating precisely. The rule reaches a business associate that creates, receives, maintains or transmits protected health information on a covered entity's behalf. Most vendors in this index sit in the receiving and maintaining categories: data flows to them, they process it, output returns. This system also creates. A risk score written into a patient's chart is new protected health information that did not exist before the software produced it, and it becomes part of the legal medical record.
That changes what the agreement needs to describe. Establish what the vendor is authorised to write, into which fields, whether a score can be amended or retracted once filed, who is recorded as its author, and what happens to written content if the relationship ends. A hospital cannot simply remove entries from a record it is obliged to retain.
A second question follows from the same fact. Because scores are consumed by nursing staff and drive documented interventions, the written output participates in the record that would be examined after an adverse event. Establish how responsibility is allocated in the agreement between the party that generated the score and the party that acted on it.
Ask for the agreement, the write scope, and the authorship attribution.
A second pass again located no attestation, trust centre or report request path, and the earlier assessment was right that for a product requiring continuous read and write access this is a material gap rather than a formality.
The second pass confirms the architecture and it is the most privileged in this lane. The platform runs headlessly inside the record system, analyses patient data continuously, and sends risk profiles back into the record where nurses act on them. So it holds standing access in both directions: it reads without a clinician invoking it, and it writes without one either.
A write privilege is a different order of trust from a read. What an examination would need to describe is therefore wider than usual: how the standing credential is issued, scoped and rotated, what identity the writes carry in the record system's audit log, whether a hospital can distinguish a system written risk score from a nurse entered one after the fact, and what the system does if it cannot reach the record.
That last question matters because a fall risk score that silently stops updating looks identical to one that is current.
The evidentiary position differs from its peers in this lane in one respect worth noting. No named hospital customer was identified, so unlike vendors with enterprise deployments there is no basis to infer that a customer's security review has already occurred privately.
Ask which report is held or scheduled, the credential and audit model, and for a reference customer.
No FDA clearance was located and none is claimed. A fall risk score that surfaces its own risk drivers to a clinician who retains the decision has a reasonable clinical decision support exclusion argument available, and the driver level transparency strengthens it, since the exclusion turns on whether a clinician can independently review the basis for a recommendation.
But the company does not make that argument publicly and nothing states the regulatory basis on which the product operates. The pressure injury product warrants the same question separately, since it predicts a condition rather than a safety event.
No subgroup performance, calibration or fairness analysis is published.
The exposure specific to fall prediction is label quality, and it is serious. A model trained on recorded inpatient falls learns from an outcome that is known to be inconsistently captured. Unwitnessed falls, near misses and falls without injury are variably documented, and documentation practice differs by unit, by shift and by staffing level. A model trained on that record therefore learns where falls get reported as much as where they occur. Birth Model's obstetric risk labels and Healthplus.ai's action defined labels carry the same problem.
A second exposure follows from the design. Because the nurse's assessment is an input, whatever variation exists in that assessment is carried into the model rather than corrected by it.
Nothing published addresses either, and no performance breakdown by age, mobility status, cognitive impairment, unit type or staffing level exists.
The model is described only as a proprietary predictive machine learning model, with no model class, feature list, training population, development or validation methodology, calibration or operating characteristics published, and no warranty, indemnity or remediation commitment located. Against that emptiness sit performance claims of an unusually strong kind, including near elimination of preventable falls and of false low risk assessments.
The second of those is a claim about the false negative rate, which is the number nobody in this category publishes and the hardest to establish, and it is asserted with no figure, denominator or method behind it. One real interpretability property deserves credit and does not lift the grade: the product surfaces specific risk drivers alongside each prediction rather than a bare score, so a clinician can see what is pushing the number and act on that rather than on the number alone.
That would support a higher grade if the underlying model were described at all. One consequence of the design belongs on this axis because it is a liability fact rather than a privacy one. The score and its drivers are written into the chart, so where a documented low risk score is followed by a fall, that sequence is a permanent artefact in the record with obvious significance in any subsequent review or claim. Ask for the false negative rate with its denominator, for calibration, and for what the vendor commits to when a documented score preceded a fall.
The headless architecture is the substantive claim on this axis and it is a genuine design position rather than a slogan. Carrying no interface of its own means the product can integrate with any EHR and render inside existing workflow, and predictions are written back into the record automatically rather than held in a parallel dashboard, which is the property that determines whether a risk score is actually seen.
The company also emphasises that it requires no additional documentation from nurses, explicitly contrasting itself with EHR integrated tools that add fields to complete, and in a category whose failure mode is clinician burden that is a meaningful differentiator. Held at B because no EHR vendor is named anywhere, no marketplace listing, Showroom entry or partner certification was located, and no FHIR or interface specification is published, so the any EHR claim is unverified.
No named hospital deployment, customer count or installed base was identified anywhere. No implementation timeline, resourcing requirement, hosting architecture or data residency commitment is published.
What can be said is confined to the architecture: a headless system reading and writing the record, configurable per organisation, with no hardware and no additional clinician documentation, which implies a light implementation but nothing published confirms it.
A currency caveat is recorded rather than left implicit. The retrieved material dates largely from 2023 and no more recent activity was identified, so establish current commercial status and reference customers directly before evaluating.
No pricing published at any level: no rate card, no unit of pricing, no band and no implementation fee.
The asymmetry is becoming a pattern in this category, with Droxi and Healthplus.ai taking the same posture. The company publishes a specific customer side return, 6.5 to 1 on investment, while gating its own price entirely, so a buyer is handed one side of the equation and asked to trust the other. The ratio has no stated basis, cost model or time horizon.
Narrow and early. Coverage is confined to two hospital acquired conditions, inpatient falls as the first product and pressure injuries as the second, within general hospital inpatient settings. No specialty depth, no unit specific configuration, no paediatric or obstetric application and no population limits are described. The company frames a broader ambition to address hospital acquired conditions generally, but only the two are documented. Narrow scope is a reasonable position for an early stage vendor and the falls problem is genuinely large, but this axis measures coverage and the coverage is two conditions.
Pricing
Vendor-published figures are labeled as such. Figures labeled “Estimated” are derived from third-party sources and have not been confirmed by the vendor.
| Entry Price | Pricing Basis | BAA Tier | Implementation | Source |
|---|---|---|---|---|
|
Not published
|
Not published | Not published | Not published | Vendor Published |
No pricing published at any level: no rate card, no unit of pricing such as per bed, per admission or per site, no band and no implementation fee. The company does publish a specific customer side return of 6.5 to 1 on investment, with no stated cost model, denominator or time horizon, which is the same asymmetry recorded against Droxi and Healthplus.ai: the upside is quantified while the price is gated, so a buyer receives one half of the calculation.
Two questions follow from the architecture rather than from any pricing material: whether the headless integration work with a given EHR is included or scoped separately, since the any EHR claim implies per site configuration, and whether the pressure injury product is licensed separately from the fall risk product or bundled.