Qventus

Prediction and automated action are the product, not reporting. The company states the platform goes beyond making optimization recommendations, using AI and behavioral science with hyper localized data to predict barriers, optimize decisions, and take action on behalf of the care team. The distinction from analytics dashboards, which is what most operational software in hospitals actually is, is that the system executes the next step rather than surfacing a chart about it.

The AI Operational Assistants act autonomously on administrative coordination work, described as speaking, hearing, reading, gathering, understanding, and writing to anticipate next steps and take action. The safety boundary is that the work is operational rather than clinical: discharge planning coordination, ancillary order prioritization, fax processing, and pre admission testing follow up. Clinical judgment stays with the care team. What is not published is the escalation logic when an assistant's action is wrong, which for discharge planning has real patient impact.

Technique is named at a general level, generative AI plus machine learning plus behavioral science, with one meaningful architectural claim: the company states its platform is trained on each customer's own data and tuned to their processes rather than deploying generic models producing one size fits most guidance. That is a real design position with cost and performance implications. No model provider, validation methodology, or performance characteristics are published.

Nothing identifies any party in the chain: no model or provider is named, no hosting arrangement is published and no sub processor list was located, and no protected health information specific stewardship statement, retention period or training commitment was found. One published term decides the grade and it belongs in the same family as the unrestricted derived data permissions this index has recorded elsewhere.

The website privacy policy states that the company and its business partners reserve the right to continue using de identified data indefinitely after personal data has been removed, and to keep disclosing de identified data to third parties. Two features make that consequential. The grant runs to business partners as well as to the contracting company, so the set of parties holding derived data is larger than the party a customer negotiates with and is not enumerated anywhere.

And de identified is not defined, so what survives removal is whatever the company classifies as de identified rather than a stated statutory method, which this index has flagged repeatedly as leaving an entire commitment resting on one undefined word. Read that against the company's own description of training on each customer's own data.

A buyer should first establish whether this policy governs platform data at all or only the website, since those are frequently separate instruments, then get the de identification standard and the derived data rights written into the agreement rather than inferred from a web page.

The strongest operational evidence in this category tier. Multi year results are published at named institutions with specific figures: a three year HonorHealth inpatient deployment reporting 86 percent of patients receiving early discharge plans, more than 50,000 excess days saved, and 62 million dollars in savings; OhioHealth reporting nearly 1,400 excess days and roughly half a million dollars within the first month; Northwestern Medicine unlocking over 1,300 operating room hours monthly at a stated 15x annualized ROI.

Aggregate 2025 figures across clients are also disclosed. Buyers should note these are vendor reported rather than independently audited, and that discharge acceleration metrics deserve scrutiny for readmission effects, which are not addressed in the published figures.

No PHI specific stewardship statement, retention period or training use commitment was located. What the company does publish is a website privacy policy, and one term in it is worth carrying into diligence: Qventus and its business partners reserve the right to continue using de identified data indefinitely after personal data has been removed, and to keep disclosing de identified data to third parties.

Two things follow. The grant runs to business partners as well as to Qventus, so the set of parties holding derived data is larger than the contracting party. And de identified is not defined, so what survives removal is whatever the company classifies as de identified rather than a stated standard.

Read this alongside the deployment axis, where the company describes training on each customer's own data. A buyer should establish whether that policy governs platform data at all or only the website, since the two are frequently different instruments, and should get the de identification standard and the derived data rights written into the agreement rather than inferred from a web page.

No HIPAA statement and no business associate agreement terms were located in the company's own published materials. Business associate status is structurally certain given the customer base is United States health systems and the platform processes patient level data inside the electronic health record, but this axis grades what is published rather than what can be inferred.

The trust centre at trust.qventus.com is the obvious place for a buyer to request the agreement and any HIPAA documentation, and its existence means the material is likely available on request even though it is not public.

A trust centre does exist, at trust.qventus.com on the company's own subdomain, which corrects an earlier finding in this index that none was published. Its contents load dynamically and could not be retrieved, so no attestation is confirmed here and none is credited. Third party listings assert a security posture for this company, but aggregator claims are not treated as evidence of certification in either direction.

Graded C on what is verifiable rather than on an assessed weakness, and this is the axis most likely to move on a single request. A buyer should ask for trust centre access directly and establish which report exists, its type, its period and its scope. For a platform embedded in the electronic health record across more than 150 hospital facilities and taking autonomous action on administrative workflows, that scope question matters as much as the certificate.

No FDA pathway applies and none is claimed. The platform automates operational and administrative coordination rather than informing diagnosis or treatment selection, which keeps it outside Software as a Medical Device. Graded B on category non application rather than C, because the axis genuinely does not reach this business model and the company does not overclaim clinical benefit to imply otherwise.

The boundary is worth naming precisely, because the discharge planning products sit close to it. A predicted discharge date shapes when a bed is freed, when ancillary orders are prioritised and when a care team begins planning, so it influences the environment around a clinical decision even though it is not one. The distinction holds as long as the output is presented as an operational forecast a clinician can override, and it would stop holding if the product moved to asserting readiness for discharge. That is the question to re test if the product line changes.

No AI governance framework, model monitoring disclosure or bias evaluation was located.

This matters more than it first appears in operational AI. Models that predict discharge readiness and prioritise ancillary resources are allocating scarce hospital capacity, so systematic bias in those predictions would distribute access to care unevenly without ever surfacing as a clinical decision anyone reviews. A discharge date set slightly earlier for one group and slightly later for another produces a real difference in length of stay that no chart audit would attribute to a model. Nothing published addresses whether that is monitored, and the company's own emphasis on autonomous action on administrative workflows raises rather than lowers the importance of the question.

Two passes located no accuracy figure, no validation methodology, no performance characteristics, no published limitations and no warranty, indemnity or remediation commitment. One design position is stated and is worth crediting even though it does not reach this axis: the platform is described as trained on each customer's own data and tuned to their processes rather than deploying generic models producing one size fits most guidance.

That is a real architectural choice with cost and performance implications, and per customer tuning is a stronger default than a shared model. It also makes the absence of measurement harder rather than easier to accept, because a vendor tuning to each customer necessarily measures something during that tuning to know when it is done, and none of it is published.

What this product decides is operational rather than clinical, covering flow, capacity and discharge planning, and this index has recorded the pattern that follows: a scheduling or capacity error produces a patient waiting longer or a bed held unnecessarily rather than a wrong document, and neither generates a complaint that reaches the vendor. Ask what the tuning process measures and against what baseline, what the model optimises for, and what the vendor commits to when a capacity or discharge prediction is materially wrong.

EHR integration is the delivery mechanism rather than a feature. The company states the platform is deeply integrated with the EHR, pulling together multiple data streams and acting inside it, and describes the inpatient solution as seamlessly embedded in the EHR where it populates expected discharge dates and dispositions by the first morning after admission.

Writing structured clinical workflow data back into the chart is a materially higher integration bar than reading data out, and the customer base of large academic medical centers implies Epic depth in practice.

No hosting provider, region, tenancy model or data residency commitment was located, and no subprocessor list was retrievable.

The question that matters most here is not where the data sits but what the models retain. The company describes training on each customer's own data, which is the right architecture if it holds, and the privacy policy separately reserves indefinite use of de identified data by the company and its business partners. Those two statements are compatible only if derived artefacts are isolated per customer, and nothing published says they are. Ask directly whether model artefacts trained on one health system's operational data can influence outputs at another, and get the answer in the contract.

No published pricing, tier or mechanism. Contracts are quoted custom and scoped to the health system, which is the norm for enterprise hospital operations platforms.

One partial offset worth crediting: the outcome figures the company publishes are unusually specific for this category, which lets a buyer model the value side of the case even without a price. The cost side stays entirely opaque until sales contact, so the two halves of the business case are available on very different terms.

Coverage is deliberately scoped to acute care operations: perioperative care coordination, surgical growth and operating room utilization, and inpatient capacity and discharge. Earlier materials also reference emergency department and command center settings. Named customers span academic medical centers, community hospitals, and multi hospital systems. Ambulatory, post acute, and payer settings are outside scope, and the AI Solution Factory is the stated path to workflows beyond the core three.