hellocare.ai

The safety monitoring models are real inference work: fall prevention, fall detection, and pressure injury prevention running continuously across many rooms is exactly what a human sitter cannot scale to. Still, a substantial share of the platform is video infrastructure, communication tooling, digital signage, and carts, which function without AI. The company's own naming, AI Assisted Virtual Nursing, is accurate: the AI assists a nurse who remains the actor.

The staffing model is the oversight model, it is described consistently, and the threshold that would make it testable is not published.

What is published is a real structure rather than a phrase. The models detect and alert; a remote clinician observes the room and decides; bedside staff intervene. The company frames the product as extending clinical capacity rather than acting on its own, and its own naming keeps the nurse as the actor. Remote clinicians can bring in frontline caregivers, other health professionals, family members, interpreters and consultants by video and audio during an event. A person is therefore always between a detection and a clinical action, which is the correct ceiling for inpatient safety monitoring.

What is missing is the threshold. Nothing states what triggers an alert, at what confidence, what the system will not do, what happens when a detection is wrong, or what a remote clinician is required to do within what time once an alert fires. The published supervision ratio makes that gap load bearing: continuous observation of up to thirty two rooms on a single monitor means the operator cannot independently catch what the models do not surface, so the alerting threshold is effectively the safety boundary of the product.

One published sentence cuts against the framing. The terms of use instruct users not to rely on the service for emergency medical needs and to call the emergency number instead, while the platform is sold on constant vigilance and immediate intervention. Those are not the same statement.

The model functions are named individually, which is better than a general claim to use AI, and nothing beneath them is described.

What is public: distinct capabilities for fall prevention, fall detection, pressure injury prevention and patient mobility tracking, plus ambient documentation, with the statement that the algorithms run on the edge of the devices. Naming four separate computer vision functions rather than referring to monitoring generally lets a buyer reason about what is being claimed, and stating that inference happens on the device is a real architectural disclosure.

What is absent is every particular. No model or method is named, no architecture described, no training data characterized, no version or update practice documented, and no evaluation published for any of the four functions. For ambient documentation, nothing states whether the underlying language model is the company's own or licensed, or where it runs, which matters because that capability is the one most likely to depend on a third party service and therefore the one where the edge processing claim is least likely to hold.

The distinction between fall prevention and fall detection is also undefined. Detection identifies an event that has occurred. Prevention implies predicting one before it happens, which is a materially harder task with a different error profile, and the company does not explain what the prevention model actually does or on what signal it acts.

One architectural claim answers part of this and probably does not cover the part that most needs it.

The company states that its algorithms run on the edge of the devices, which for the vision functions means inference happens in the room rather than in a vendor estate, and that is a real structural bound. Four capabilities are named individually rather than folded into monitoring generally, which lets a buyer see what is being claimed.

The gap is specific. Ambient documentation is listed as a platform module in the company's own announcements, and nothing states whether the underlying language model is its own or licensed, or where it runs. That capability is the one most likely to depend on a third party service and therefore the one where an edge processing claim is least likely to hold, so a statement made about the product as a whole may not describe the component carrying the most content. It also has no product page of its own, which makes it the hardest module to establish anything about.

What the privacy policy adds is the shape of the chain rather than its members: processing by the company, its affiliates and service providers, with secure cloud storage from a third party provider that is not named, and consent to transfers outside the jurisdiction. No subprocessor list is published anywhere.

Nothing else is enumerated: no model or method for any of the four vision functions, no training data characterization, and no hosting arrangement for the platform tier behind the devices.

Adoption is extensive, dated and named, and no published figure measures whether the product works.

The customer list is the strongest part of the public case. Named enterprise deployments include Ardent Health across more than two thousand patient rooms, WVU Health System across twenty five hospitals, MultiCare, UCHealth, OSF HealthCare, Allina Health, Cooper University Health Care, Saint Peter's Healthcare System, Cottage Health, One Brooklyn Health, Reid Health, AdventHealth, and West Tennessee Healthcare through an intensive care program run with a named device manufacturer. Several are expansions from a narrower starting point to an enterprise standard, which is a customer deepening its commitment rather than signing once. A collaboration with Mayo Clinic on an artificial intelligence project is also published, as is a $47 million funding round.

None of that is evidence of benefit, because scale of use is not a result. The closest published statement to an outcome is a July 2026 announcement describing the successful completion of a pilot that demonstrated improvements in patient safety, clinical workflows and patient engagement. No number accompanies it, and no baseline, period, denominator or method.

For this product the measures that matter are specific and none exists: fall rate against baseline, pressure injury rate against baseline, detection sensitivity, and the false alarm burden carried by a clinician watching thirty two rooms. The company cites no peer reviewed publication.

The published terms answer part of this, and what they permit is the finding rather than any silence.

A privacy policy and terms of use are published and they are substantive. Storage is stated: information is maintained, processed and stored by the company, its affiliates and service providers in the United States and, as necessary, in secure cloud storage from an unnamed third party provider, with the reader consenting to transfers outside the jurisdiction in which the information was provided. Retention is a posture rather than a period: information is kept only as long as needed to provide the services and to comply with law, after which it is deleted or anonymized.

Two permissions matter more than the absences. The terms state the company may, at its own discretion, review and monitor examination data and audiovisual recordings to detect incorrect use of the services. That confirms recordings exist, that they persist long enough to be reviewed, and that the vendor may look at them without the customer being the one who decides. And the privacy policy permits the company to disclose or otherwise use non personal information, defined to include medical information anonymized into that category, at its own discretion. No de-identification standard is named, so the boundary of that permission is set by the company.

Training use is wholly unstated. Nothing says whether video, audio or documentation content from one hospital improves models serving another, and for a product built on computer vision that is the question.

This is continuous video and audio in rooms holding patients who are confused, sedated, undressed or dying, together with the families and staff who enter. Nothing states whether capture is continuous or event triggered, what patients are told, or whether they may decline.

No published material addresses safety engineering, guardrails or how a detection failure is handled.

A published privacy document states business associate status, and that document is written for the patient rather than for the hospital that signs.

The privacy policy carries a dedicated section on the health privacy rule stating that the company's practices are intended to comply with its obligations as a business associate with respect to the reader's health care provider, that it will maintain the privacy of personal information as required by that rule and by any business associate agreement it has with the provider, and directing the reader to the provider's own notice of privacy practices. Naming the status and the counterparty matters, and the surrounding document is substantive rather than a cookie notice: it covers storage, transfer, retention, deidentification and consent at length.

The agreement itself is not published. No template, no execution path, no scope statement covering which modules fall inside it, and no subcontractor position, which matters because the platform spans devices, a cloud tier and a third party cloud provider named only as such.

Two questions sit outside the health privacy rule. Audio: microphones are installed in patient rooms and the published terms permit the company to review audiovisual recordings at its own discretion. Recording or intercepting a conversation is governed by state wiretap law rather than by the health privacy rule, and a substantial number of states require every party to consent. Second, virtual sitting replaces a human assigned to watch a patient continuously, and those patients are frequently at risk of self harm, delirious, or subject to a legal hold, and some cannot meaningfully consent at the time.

Three recognized attestations are named in the company's own material and nothing sits behind any of them.

The site navigation carries a Certifications and Compliance entry listing HITRUST, HIPAA, ISO 27001 and SOC. That is the company presenting attestations as its own rather than attaching them to a cloud host, which is the distinction that decides whether a certification covers the product at all, and it is published on a surface the company controls. The corporate entity behind the product is Solaborate Inc of Clearwater, Florida, trading as hellocare.ai, so there is no separate parent whose badge might not reach the product.

What is missing is everything that would let the claims be checked. The navigation entry is a label with no page behind it: no report, no trust portal, no scope statement, no observation period, no assessor and no date. SOC is named without a number or a type, so whether it refers to a SOC 1 or a SOC 2, and whether Type I or Type II, is not stated. Nothing states which systems fall inside any audited boundary.

Scope matters especially here, because the failure mode differs in kind from a records breach. This vendor operates cameras and microphones mounted in occupied patient rooms across dozens of named health systems, one of them spanning twenty five hospitals. A compromise means live audio and video access to rooms holding undressed, sedated, distressed and pediatric patients, in real time. The published terms also permit the company to review audiovisual recordings at its own discretion.

No clearance is claimed and none appears in the public databases. A partial boundary statement is published, and it does not address device status.

What the terms do say is that the company does not itself provide any physician or other healthcare provider services, that all providers are independent and merely use the platform, and that the service must not be relied on for emergency medical needs. Those sentences draw a line around clinical responsibility and leave the device question untouched.

The reasoning that would place the platform outside device regulation is available and is probably right. It observes patients and alerts staff, it does not diagnose or direct treatment, and a nurse decides what to do. Video based fall alerting has not typically been regulated as a device.

What complicates it is what the product replaces. Continuous observation is ordered for patients at risk of falling, of self harm, or experiencing delirium, and a human sitter is a clinical intervention documented in the record. Substituting software for that intervention means the software performs a safety function a care plan relies on, and pressure injury prevention monitoring likewise supports a nursing intervention with mandated documentation and defined outcome measures. A missed detection in either case is a patient harm event rather than a workflow inconvenience.

The emergency sentence sharpens this rather than settling it. A platform sold on constant vigilance and immediate intervention, whose terms tell the user not to rely on it in an emergency, has published two positions and reconciled neither.

No governance framework, model documentation or performance disclosure is published, and one figure the company does publish makes that absence unusually consequential.

The virtual sitting service is described as continuous observation for up to thirty two rooms on a single remote clinician's monitor. A traditional sitter watches one patient. That ratio is the product's economic argument, and it is only safe if the models reliably surface the rooms that need attention, because a person monitoring thirty two live tiles cannot independently catch what the software does not flag. A published supervision ratio is therefore a claim about model sensitivity whether or not it is presented as one, and no sensitivity figure is published for fall detection, fall prevention, mobility tracking or pressure injury prevention.

The fairness question here is specific. These are computer vision models inferring body position, movement and posture from video in rooms with varying light. Optical measurement in health care has a documented history of performing unevenly across skin tones, and the same physical mechanism that degrades optical signal acquisition on darker skin applies to segmenting a body from a background. Nothing published reports detection performance by patient skin tone, body habitus, mobility aid use, or room lighting. A monitoring system that detects falls less reliably for some patients concentrates harm precisely where it is least visible, because the missed event presents as a patient found on the floor rather than as a model error.

Pediatric rooms raise the same questions against a different evidence base, and the platform is deployed in them.

No accuracy figure, false alarm rate or validation methodology is published for any of the detection capabilities, and the terms disclaim warranties in terms.

The published position is explicit rather than merely absent. The services are provided on an as is and as available basis without warranties of any kind, express or implied, including fitness for a particular purpose. No indemnity or remediation commitment appears anywhere. For a product whose function is to notice that a patient is falling, the absence of any measured performance claim and the presence of a broad disclaimer sit together uncomfortably.

One published distinction is undefined and it matters more than a missing percentage. Fall detection identifies an event that has occurred. Fall prevention implies predicting one before it happens, a materially harder task whose false positives land on staff as repeated alerts and whose false negatives are invisible by construction. Nothing published explains what the prevention model predicts, on what signal, or how far ahead, so it is unclear whether the product is a detector, a predictor, or a detector described as a predictor.

The terms also instruct users not to rely on the service for emergency medical needs and to call the emergency number, while the platform is marketed on constant vigilance and immediate intervention. Nothing published says which statement governs when a fall alert does not fire.

The recording surface leaves affected people with no route. Continuous video of patients in hospital rooms captures those who are confused, sedated, undressed or dying, along with family and staff, and nothing states what patients are told, whether they can decline, how long footage persists, or how a complaint would be raised.

Named record systems, a verifiable listing in one vendor's own catalog, and named production sites behind it.

The company names Epic, Cerner and Allscripts as integrated record systems. One integration is independently checkable: Epic's patient facing bedside experience runs natively on the company's in room devices and is published in Epic's own toolbox catalog, which is an artifact anyone can open rather than a claim on a product page. That integration is named as live at a specific health system in a dated announcement, so the connection is evidenced in production rather than described in the abstract.

The direction of integration is also the right one for this setting. Clinicians launch virtual care sessions from within the record rather than from a separate console, digital whiteboards and room signage display patient specific information that only works if it is current, and the virtual nursing module supports admission and discharge workflows, which are the most record intensive moments in an inpatient stay.

The write path is claimed rather than shown. Ambient documentation is listed as a platform module and would be the clearest write into the chart, but it has no product page, no description of what it writes or where it lands, and no named deployment of that module specifically. No interface documentation, conformance statement or supported standard is published for any of the three record systems, and nothing states which of them are live beyond the one catalog listing.

One substantive architectural claim, a residency statement that qualifies itself, and nothing about the platform tier.

The architectural claim stands out. The company states its algorithms run on the edge of the devices themselves and presents this as protecting patient privacy while tracking behavior, monitoring for falls and alerting staff. Processing video where it is captured rather than streaming it to a server is the right design for this problem, and if the model runs in the room and only an alert leaves, the exposure is transformed.

Residency is stated in the privacy policy rather than on a product page, and it is stated and then loosened in the same passage. Information is maintained, processed and stored by the company, its affiliates and service providers in the United States and, as necessary, in secure cloud storage from a third party provider that is not named. The reader then consents to the place of storage and transfer described, including transfers outside the jurisdiction in which the information was provided. Read on its own, the first half suggests a United States commitment that the second half does not give.

The rest is unpublished: no hosting provider, no region, no tenancy separation between health systems, no retention schedule for video or audio, and no subprocessor list. The same devices deliver live two way audio and video between the room, remote clinicians and family members, so video plainly leaves the room in normal operation whatever runs on the edge.

The hardware dimension has no software equivalent. This is a fleet of network connected cameras and microphones physically installed in patient rooms, in one case across more than two thousand rooms at a single customer.

Pricing is not published and is available only by contacting the vendor. Enterprise agreements are sold by module, with named deployments describing specific module combinations, so scope is negotiable. Hardware is included in the offering, with smart carts and in wall fixed devices, so capital cost sits alongside subscription, and a per room deployment across thousands of rooms carries a materially different cost structure from software alone.

Coverage is bounded to a setting rather than a specialty, stated clearly, and supported by publicly named deployments.

The platform is organized around where it operates rather than what it treats: hospital, home care and primary care, each with a published module list. Inside the hospital it spans virtual nursing with rounding, admissions and discharges, virtual sitting and patient safety monitoring, patient engagement, digital whiteboards and room signage, ambient documentation, and hospital at home, with remote patient monitoring and a digital clinic extending past discharge. Hardware is part of the boundary, since the modules run on in room fixed devices and mobile carts.

What supports it is the deployment record rather than a validation study. Named health systems run the platform enterprise wide across diverse inpatient environments, including one spanning twenty five hospitals and another across more than two thousand patient rooms, and one named site runs an intensive care program on it alongside a named device manufacturer. That is coverage demonstrated across unit types rather than asserted from a single pilot.

Two boundaries remain unclear. Ambient documentation appears in the company's module lists but has no product page describing where it works or in which specialties. And international expansion is stated without naming a country or a live site.