Vitalchat
Vitalchat sells ambient virtual care as software rather than as equipment. The platform performs continuous real time analysis of video, audio and sensory data captured in the care setting, identifying trends, predicting risks and flagging anomalies, which it converts into alerts and, by its own description, automated actions supporting the clinical team. Applications cover artificial intelligence assisted virtual sitting for patient safety monitoring, remote procedural support so a clinician can join an operating room or procedure from elsewhere, automated workflows aimed at nursing administrative burden, and virtual engagement letting family remain present during an inpatient stay.
The architecture is the differentiator and the reason this record reads differently from the established vendors in this segment. Vitalchat is a cloud native software as a service platform that leverages a hospital's existing infrastructure and states that it eliminates the need for additional hardware. Competitors in inpatient virtual care sell branded endpoints, install them room by room, and carry device fleet management as a core capability. Removing the capital line item entirely is a genuine commercial and operational distinction, and it is also the claim a buyer should probe hardest, because what the software runs on and what it can see depend on what the hospital already has.
Deployment is stated at more than 35 hospitals across medical surgical units, intensive care units, operating rooms and post acute facilities. Commercial launch was in 2021.
Funding is 6 million dollars in a Series A closed in February 2025, led by Green Harvest Capital Industries. That investor is a private equity firm whose stated specialisms are multifamily housing, hospitality and industrial assets rather than healthcare, which is an unusual profile for a clinical artificial intelligence company and worth noting rather than glossing, since healthcare specialist investors typically bring diligence and customer access that generalist capital does not.
Based in Raleigh, North Carolina and led by chief executive Michael Raymer.
A reader should understand what this record does not contain. Two dedicated passes located no security page, no external attestation, no health privacy statement, no pricing of any kind, no named customer, no named record system integration and no published performance figure for any model. The company describes what its technology does at the level of capability and publishes almost nothing that would let a buyer verify or evaluate it. That gap, rather than the technology, is the substance of most grades in this record.
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
Artificial intelligence is the stated basis of the product rather than an addition to it, in a platform that also carries conventional video communication.
The positioning is consistent and specific. Continuous real time analysis of video, audio and sensory data, producing trend identification, risk prediction and anomaly detection, is the described mechanism throughout, and the company has presented itself as an ambient artificial intelligence company since commercial launch rather than adopting the framing later. Virtual sitting here is an inference product, since the value claim is that models watch and flag rather than that a human watches more screens.
What sits alongside it is ordinary telehealth. Remote procedural support connects a clinician into an operating room by video, and family engagement lets relatives join an inpatient stay. Both are useful and neither involves a model.
The architectural claim cuts both ways on this axis. Running on a hospital's existing infrastructure with no additional hardware means the company ships software and models rather than devices, which concentrates value in the intelligence. It also means the models are constrained by whatever cameras and sensors the hospital already owns, and quality of inference from arbitrary existing equipment is a harder problem than from purpose built endpoints.
Graded B rather than higher because no published performance exists for any model, so the intelligence is asserted rather than demonstrated, and a buyer cannot yet distinguish genuine inference from thresholded video analytics.
A supporting role is clearly claimed, and one phrase in the company's own description points somewhere else and is never explained.
The stated model is sound. Analysis produces alerts that support clinical teams in delivering care, virtual sitting places an observer in the loop, and the framing throughout is assistance to nurses and physicians rather than replacement of their judgement. Nothing suggests the platform makes clinical decisions.
The unexplained phrase is automated actions. The company describes its analysis as being turned into meaningful alerts and automated actions, and separately markets automated artificial intelligence driven workflows. An alert is a request for human attention; an automated action is the system doing something without waiting for one. Which actions are automated, what triggers them, whether a clinician can review or reverse them, and whether any touches the patient record or the care plan are all unstated. That distinction is the entire content of this axis and it is left open.
The rest of the calibration is missing as it is for most of this segment. No observer to patient ratio, no alert volume, no notification time, no acknowledgement or closed loop mechanism, and no detection sensitivity or false alarm rate for any model.
Graded C because the intended posture is stated clearly and consistently, and rather than higher because the one autonomy claim the company actually makes is the one it does not describe.
Ask precisely which actions are automated and under what thresholds, whether any are reversible, and what the observer ratio is.
Capabilities are named and nothing beneath the names is described.
What is published amounts to three input modalities, video, audio and sensory data, and three analytic functions, trend identification, risk prediction and anomaly detection. That establishes shape and nothing else.
No performance figure of any kind exists. No accuracy, no sensitivity, no specificity, no false alarm rate, no operating point, no model card, no architecture description and no statement of which detections are model generated rather than rule based.
Two specific gaps go beyond the usual. Sensory data is never defined anywhere in public material, so a buyer cannot say what the third modality is, and it is the one that would determine whether the system observes room activity or physiological parameters. And nothing describes where inference runs. The platform is stated to be cloud native and to use existing hospital infrastructure, and those two facts together leave the processing location genuinely ambiguous, which matters for latency in a safety application and for data movement in a privacy one.
The existing infrastructure claim also needs a specification behind it and has none. What camera resolution, placement, network capacity and equipment the platform requires to work is the practical question a hospital must answer before piloting, and it is unpublished.
One pre emptive note: further capability descriptions cannot move this grade. Only published detection performance and a technical specification will.
Ask what sensory data means, where inference executes, and the minimum infrastructure the platform requires.
A dedicated pass located no cloud or infrastructure provider, no base or foundation model, no computer vision or speech component, no sub processor register, no third party library position and no statement on training data provenance.
The cloud native architecture makes at least one omission certain rather than probable. A cloud native platform runs on someone's infrastructure, and that provider is unnamed, which means a hospital cannot determine whose data centres process video and audio from its intensive care units.
The modality mix implies further undisclosed components. Audio analysis ordinarily involves a speech or acoustic processing stack, video analysis a vision framework, and a company of this size and funding stage is considerably more likely to assemble those from third party services than to build them from first principles. If any external service processes patient video or audio, the customer has not been told, and if none does, saying so plainly would be a straightforward differentiator that costs nothing.
The training position is unaddressed and the circumstances make it pressing. Building risk prediction models requires labelled clinical data, the company has 35 hospitals of continuous multimodal capture including intensive care and operating room environments, and nothing states whether that material has been used for development or under what consent, in settings where patients are frequently unconscious.
Ask for the hosting provider, the sub processor register, whether any third party service processes patient video or audio, and the consent basis of the training corpus.
Five years since commercial launch and nothing published that a buyer could evaluate.
A dedicated pass located no peer reviewed publication, no clinical study, no independent evaluation, no third party analyst recognition and no quantified outcome of any kind. No customer is named anywhere in public material, so even the testimonial tier of evidence that most vendors provide is absent here.
What exists is a deployment count. More than 35 hospitals across medical surgical units, intensive care units, operating rooms and post acute facilities, stated by the company at the time of its funding announcement in early 2025 and not updated publicly since. Breadth of setting within that count is a mildly useful signal, since operating rooms and intensive care units impose different requirements, and the count itself is modest.
The absence carries specific weight for this product. Virtual sitting exists to prevent falls and harm, and the segment's established vendors publish fall reduction figures, response times, alarm volumes and dollar outcomes at named institutions, with at least one peer reviewed longitudinal study. A buyer choosing this platform for the same job has no comparable basis, and no way to know whether the artificial intelligence performs better, worse or the same as the alternatives.
The risk prediction claim is the least supported of all, since predicting risk implies a measurable hit rate and none is offered.
Ask for a named reference site, a quantified safety outcome from a live deployment, and the current hospital count.
The most sensitive continuous capture profile in this segment, with no published account of how any of it is handled.
A dedicated pass located no encryption statement, no retention schedule, no access control model, no audit logging description, no deletion process, no consent position and no statement on whether captured data contributes to model development.
Three features of this product make the silence weigh more than the same silence would elsewhere. The capture is multimodal, covering video, audio and unspecified sensory data rather than video alone. The settings include operating rooms and intensive care units, where patients are unconscious or sedated and cannot be informed, consent or object in the moment. And the platform is cloud native, so unlike the edge processing competitors in this segment, the presumption is that data moves off site, and nothing states what moves, when, or in what form.
Sensory data is undefined throughout the public material, which means a buyer cannot enumerate what is being collected in their own patient rooms.
The training question is entirely unaddressed and is sharpened by the company's stage. A five year old company building risk prediction models needs training data, its deployed base is 35 hospitals of continuous multimodal patient capture, and nothing states whether the two are connected.
One pre emptive note: a general privacy policy cannot move this grade. Only a published retention schedule, a statement of what leaves the hospital, and a training data position will.
Ask what sensory data means, what leaves the premises, what is retained and for how long, and whether patient data trains models.
Two dedicated passes located no health privacy position of any kind: no compliance statement, no business associate agreement template, no execution requirement and no description of which entity contracts.
The absence is more consequential here than for a vendor whose applicable regime is ambiguous. Every customer is a hospital and therefore a covered entity, so agreements demonstrably exist across the deployed base; the company simply publishes nothing about them. Unlike the consumer facing sensing vendors in this index, there is no question about whether health privacy law applies, only about what the vendor's posture is.
The data at issue raises the stakes. Continuous video, audio and sensory capture in intensive care units and operating rooms means the platform is positioned to record patients during procedures, during personal care and while unconscious, alongside the clinical conversation happening around them. Operating room audio in particular captures surgical team communication, which carries its own sensitivity beyond patient privacy.
The architecture adds a question no competitor in this segment has to answer. Because the platform runs on a hospital's existing infrastructure rather than on vendor supplied endpoints, the boundary between the hospital's systems and the vendor's processing is less clear than it would be with a dedicated device, and nothing published describes where that boundary sits.
Graded D because nothing was located after a dedicated search. Ask for the agreement template, what the platform captures in an operating room, and where the vendor's processing boundary begins.
Two dedicated passes located no security page, no external attestation, no trust centre, no penetration testing statement, no vulnerability disclosure policy and no compliance documentation offered under agreement. No security credential of any kind was found.
This is the most serious gap in the record, and the architecture is why. A vendor shipping its own endpoints controls a defined perimeter. This platform runs on the hospital's existing infrastructure, which means the software operates across equipment, networks and endpoints the hospital already owns and depends on for other purposes. The blast radius of a compromise therefore extends into the hospital's own estate rather than being bounded by a fleet of vendor devices, and nothing published describes how that access is scoped, authenticated or monitored.
The capture profile compounds it. Continuous video and audio from intensive care units and operating rooms is among the most damaging material a hospital holds, and cloud native delivery means it plausibly traverses the internet.
Buyers in acute care increasingly treat an external attestation as an entry requirement rather than a differentiator, and a five year old company selling into 35 hospitals will have faced security reviews, so a posture almost certainly exists in private. It is simply not published, which leaves prospective buyers unable to begin diligence before contacting sales.
One pre emptive note: a privacy policy or a restated compliance claim cannot move this grade. Only an external attestation, or security documentation available under agreement, will.
Ask whether any external security assessment exists, how the platform authenticates to hospital infrastructure, and what documentation can be shared under agreement.
No claim made, no determination published, and a product description that repeatedly uses the language regulators attend to.
No clearance, grant or approval was located and none is asserted. The general posture supports a non device position, since alerts reach clinical teams who decide, and virtual sitting with human observers is workflow rather than a medical device function.
The language is the complication. Predicting risks and flagging anomalies from continuous physiological and behavioural observation is closer to clinical decision support than routing a video call is, and risk prediction in particular is the phrase that invites the question of what condition is being predicted, in whom, and with what accuracy. Sensory data is undefined, and if any of it constitutes physiological measurement then the analysis is operating on clinical parameters rather than on room activity.
The operating room application raises a separate consideration that nothing addresses. Technology present in a procedural environment, capturing and analysing during surgery, sits in a more heavily regulated space than a medical surgical corridor, and nothing describes what the platform does or does not do during a procedure.
The automated actions capability compounds both questions, since an automated action taken on a predicted risk is a materially different regulatory object from a notification.
Graded C consistent with the treatment of an undeclared but plausible non device position across this index. Ask for the written device determination, what risks the models predict, and what sensory data comprises.
A dedicated pass located no governance framework, no responsible artificial intelligence statement, no fairness testing, no subgroup performance, no calibration data, no drift monitoring, no model documentation and no external audit. No named individual or function holds accountability for the models publicly.
The exposure is compounded rather than singular because three modalities are in play. Video analysis of patients in beds carries documented differential error by skin tone, worsened under the low light and infrared conditions that overnight observation requires, and by body habitus, bedding and positioning equipment. Audio analysis degrades by accent, dialect, pitch and language. Whatever sensory data comprises adds a third surface that cannot be assessed because it is not described.
The existing infrastructure architecture introduces a bias mechanism specific to this vendor and absent from its competitors. Because the platform runs on whatever cameras and equipment a hospital already owns, model performance varies with the age, resolution, placement and lighting of equipment the vendor did not specify. Hospitals with older estates are disproportionately under resourced ones, so a system whose accuracy tracks equipment quality will tend to perform worst in the settings serving the least advantaged patients. Nothing published acknowledges this, and it is the kind of structural inequity that becomes visible only after deployment.
Ask for detection performance by skin tone and under low light, and for the minimum equipment specification below which accuracy degrades.
Nothing allocates responsibility, for a platform that both watches patients for harm and claims to act automatically.
A dedicated pass located no service level agreement, no accuracy warranty, no uptime commitment, no indemnity, no remediation position and no published terms.
Two features raise the stakes above the segment norm. Virtual sitting is deployed against falls and self harm, so a missed event is immediate physical harm, and no detection rate is published, meaning a unit adopting this cannot characterise the residual risk it is accepting when it changes staffing. And the automated actions capability means the system is described as doing things rather than only notifying, so a wrong output can propagate without a human gate. When a system that acts autonomously has neither a published error rate nor a published warranty, the customer is absorbing an unquantified risk on both dimensions at once.
The infrastructure architecture introduces a third allocation question absent elsewhere. When the software runs on the hospital's own cameras and network, a failure to detect could originate in the model, in the equipment the hospital owns, or in the network between them, and nothing describes how responsibility divides across that boundary. A vendor supplying its own hardware cannot make that argument; this one structurally can.
One pre emptive note: further deployment announcements cannot move this grade. Only a contractual commitment, or published detection and availability performance, will.
Ask what is warranted on detection and availability, how fault is allocated when hospital owned equipment is in the path, and what recourse follows an automated action taken in error.
Record system integration is asserted in third party descriptions and nowhere specified.
A dedicated pass located no named electronic health record, no interface standard, no marketplace or validated integration listing, no published application programming interface and no description of what data moves in either direction.
The absence is notable against the segment. Both established vendors in inpatient virtual care name their record system integrations specifically, one of them appearing in a major record vendor's validated programme for two consecutive years, and both describe nurse call integration with a stated mechanism. Nurse call is the more revealing gap here, because a virtual sitting product that cannot route an urgent event into the system a hospital's staff already monitor is asking a unit to watch a second screen, and nothing indicates whether this platform can.
The existing infrastructure architecture makes interoperability more central to this product than to its competitors rather than less. A vendor that ships its own endpoints controls its own data path; a vendor running on the hospital's estate depends entirely on integrating with equipment, networks and systems it does not own, so the integration surface is the product's foundation. None of it is described.
One related question is unanswered. Whether observation events, alerts or automated actions post to the patient record determines whether any of this is auditable after the shift ends.
Ask which record and nurse call systems are integrated in production, through what standard, and whether events write to the chart.
The delivery model is stated plainly and unusually, and the hosting behind it is not described at all.
Two real architectural facts are published. The platform is cloud native software as a service, and it runs on a hospital's existing infrastructure without requiring additional hardware. Together those describe a deployment shape genuinely different from every competitor in this segment, all of which install proprietary endpoints room by room and manage device fleets. A hospital evaluating this is evaluating a software rollout rather than a construction project, which changes timeline, capital approval and facilities involvement.
That distinction is worth crediting because it is checkable and consequential, not because it is favourable.
Everything about the hosted side is absent. No cloud provider is named, no region is stated, no tenancy model is described, no residency commitment is made and no backup or continuity position is given.
The combination of cloud native delivery and continuous multimodal capture makes the unanswered question sharper than usual. If video and audio from intensive care units and operating rooms are processed off premises, then the volume, the path and the destination all matter, and nothing states whether raw streams leave the hospital or only derived events. The competing vendors in this segment answer this by processing at the edge; this one has not answered it.
Ask where processing occurs, whether raw video and audio leave the premises, which provider hosts it, and in which region.
Cost is absent from every published surface. A dedicated pass located no pricing page, no unit of charge, no range, no tiering, no implementation fee position and no minimum commitment.
One genuine cost statement does exist and deserves recording even though it is not a price. The platform is described as eliminating the need for additional hardware by running on a hospital's existing infrastructure. In this segment that removes the single largest capital line, since competing deployments require a purpose built endpoint in every monitored room plus installation, and it is a checkable structural claim rather than a marketing adjective. A buyer can verify it during a pilot.
Everything after that is unstated. Whether the software is licensed per room, per bed, per monitored patient, per concurrent observer, per application or per enterprise is unknown, and with no hardware anchoring the unit there is not even the implicit device denominator that competitors carry. Nothing indicates whether the applications, spanning virtual sitting, procedural support, workflow automation and family engagement, are bundled or licensed separately.
No return proxy is published. Nursing administrative burden and staffing shortages are the commercial argument and no cost per room, avoided sitter hours or time released figure supports it.
The comparison worth making is that the no hardware architecture should make pricing easier to publish rather than harder, since there is no equipment quote to hide behind.
Ask for the unit of charge, whether applications price separately, and what a representative unit costs annually.
Four distinct care settings named, at modest scale, with nothing below the labels.
The named range is genuinely varied for a company this size: medical surgical units, intensive care units, operating rooms and post acute facilities. Those are not adjacent variations on one deployment. An intensive care unit and a post acute facility differ in acuity, staffing ratio, room layout and what a monitoring system is expected to notice, and an operating room is a different environment again, which the company addresses through a distinct procedural support application rather than by stretching the sitting product across it.
Building a specific application for procedural telehealth is the strongest coverage signal in the record, because it indicates the operating room was engineered for rather than listed.
What is missing is depth and current scale. More than 35 hospitals is the only figure available and it dates from early 2025. No site is named, nothing states how the count distributes across the four settings, and nothing indicates whether a typical customer runs one unit or a whole facility. No geography beyond the United States is indicated, and no specialty population, such as behavioral health or pediatrics, is addressed, which matters because behavioral health observation carries requirements that general virtual sitting does not meet.
The existing infrastructure architecture also raises an unaddressed coverage question, since what the platform can observe depends on what cameras a given unit already has.
Ask for the current hospital count, the split across settings, and what existing equipment a unit needs to qualify.
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 disclosed. No unit of charge is described anywhere, and unusually for this segment the product shape gives no hint, because a platform that ships no hardware has no device to price against. Whether charging follows the room, the bed, the monitored patient, the concurrent observer, the application or the enterprise is entirely unstated, as is whether the virtual sitting, procedural support, workflow automation and family engagement applications are licensed together or separately. | Not disclosed, and no health privacy position of any kind was located after two dedicated passes. Every customer is a hospital and therefore a covered entity, so agreements demonstrably exist across the deployed base; the company simply publishes nothing about them. Two features make the absence weigh more than usual. The capture is multimodal and covers intensive care units and operating rooms, where patients are frequently unconscious or sedated and cannot be informed or object, and operating room audio additionally captures surgical team communication. And because the platform runs on the hospital's existing infrastructure rather than on vendor supplied endpoints, the boundary between the hospital's systems and the vendor's processing is less clearly drawn than it would be with a dedicated device, so who is responsible for what is genuinely harder to establish. Ask for the agreement template, what the platform captures during a procedure, and where the vendor's processing boundary begins. | Not disclosed, though the architecture implies a materially lighter implementation than the segment norm. Because the platform is cloud native software running on a hospital's existing infrastructure with no additional hardware required, deployment involves no room by room device installation, no mounting and no facilities work, which is the bulk of implementation cost for competing inpatient virtual care systems. What replaces that effort is undescribed: no statement covers integration with existing cameras and networks, minimum equipment requirements, clinical programme design, staff training, or whether the vendor charges for any of it. No implementation timeline is published. The practical question a hospital must answer before piloting, namely what equipment and network capacity a unit needs to qualify, has no published answer. | Vendor Published |
Cost is absent from every published surface. A dedicated pass located no pricing page, no unit of charge, no range, no tiering, no implementation fee position, no minimum commitment and no trial terms.
One genuine cost statement exists and belongs on the record even though it is not a price. The platform is described as eliminating the need for additional hardware by running on a hospital's existing infrastructure. In this segment that removes the single largest capital line, because competing deployments require a purpose built endpoint in every monitored room plus mounting and installation, and it is a structural claim a buyer can verify during a pilot rather than a marketing adjective. It also changes who approves the purchase, since a software rollout and a capital equipment programme move through different committees on different timelines.
Everything after that is unstated, and the same architecture removes the implicit denominator competitors carry. With no device to count, whether the software is licensed per room, per bed, per monitored patient, per concurrent observer, per application or per enterprise cannot be inferred from the product shape at all. Nothing indicates whether the four applications, covering virtual sitting, procedural support, workflow automation and family engagement, are bundled or licensed separately, which is the question that determines whether expanding from one use case to another is an increment or a renegotiation.
No return proxy is published. Nursing administrative burden and staffing shortages are the entire commercial argument, and no cost per room, avoided sitter hours, or clinician time released figure supports it. Competitors in this segment publish dollar outcomes at named hospitals; this vendor publishes none.
Worth noting that the no hardware architecture ought to make pricing easier to publish rather than harder, since there is no equipment quotation to sit behind.
Ask for the unit of charge, whether applications price separately, the annual cost for a representative unit, and the minimum term.