Sickbay

The purest platform not algorithm case in this category, and the grade describes mechanism rather than quality. Sickbay collects, aggregates, transforms, persists and displays physiological data. It does not supply a deterioration model. Its own framing is explicit about this: it provides data to clinicians, researchers and algorithm developers through APIs and development tools, and the risk indicators in its Virtual Ops module are configurable by the institution rather than learned by the vendor. A data pipe is not a risk model, however good the pipe.

It is nevertheless correctly in this category rather than routed out, on two grounds. The platform and its applications are FDA cleared specifically for inpatient patient monitoring and alarm analytics, and the Alarm Analytics Dashboard addresses this category's defining failure mode more directly than any modelling vendor here.

Nothing is decided autonomously and, unusually in this category, there is nothing for the vendor to decide. The platform displays data and surfaces indicators the institution has configured, so there is no vendor set threshold, no suppression layer of the kind AlertWatch's proprietary filtering introduces, and no low risk or de escalation output of the kind that creates the invisible failure surface on CLEW, Etiometry and Healthplus.ai.

The oversight model is strong by construction rather than by disclosure. Held at B rather than A because the Alarm Analytics Dashboard, being a cleared application aimed at alarm burden, has no published operating characteristics or methodology, and because the platform's configurability means oversight quality depends entirely on how well the institution sets it up, which nothing published helps a buyer assess.

There is no proprietary model to be opaque about, and what does exist is described in unusual technical detail: vendor neutral capture across disparate biomedical device manufacturers including non networked devices, time series waveform data at a stated average of around 25 milliseconds per patient, persistence of the full monitoring history, a grid computing architecture attributed to the chief product officer's research, and open APIs and development tools exposing the result to third parties.

Transparency by construction is worth naming here. Because risk indicators are institution configured rather than vendor learned, a hospital can state exactly what triggers a flag.

Held below A because no specification of the available indicators was located, and because the alarm analytics application, which is the most clinically consequential component, is described by function rather than by method.

There is comparatively little model chain to disclose and there is a data chain that needs describing, which is the unusual shape of this record. On the first point, risk indicators are institution configured rather than vendor learned, so no foundation model sits between the data and the flag, and the architecture is described concretely enough that a technical buyer can reason about it: vendor neutral capture across device manufacturers, waveform data at a stated interval, a grid computing architecture, and persistence of the full monitoring history.

On the second point, the platform publishes open interfaces and development tools exposing that data to third parties, which is a genuine capability and also a chain. A deployment accumulates one of the densest physiological datasets a hospital will hold, and third party algorithm developers reaching it through those interfaces are parties in possession of continuous waveform data for identified patients.

Nothing published describes how that access is governed, what a developer may retain, whether the hospital approves each one, or what the position is when a developer's product is later sold. Ask who currently holds interface access, what governs it, who owns the archive, what the retention terms are, and whether de identified data is used for product development.

No peer reviewed clinical outcome evidence was located, which is the honest position for a data platform but still leaves the axis thin. What exists is institutional and commercial rather than clinical: FDA clearance of the platform and three applications, a strategic partnership with Texas Children's Hospital involving data analysis, a named relationship with Tampa General Hospital, an industry analyst product leadership award, and marketplace presence. The 25 millisecond resolution figure is a performance specification rather than a clinical result.

The evidence question for a substrate is different from the one for a model and should be asked differently. What proportion of a hospital's device estate does it actually capture, what is the data loss rate, and has any published work demonstrated that models built on waveform data outperform the same models built on EMR data, which is the company's core claim.

A privacy policy and terms of use are published and linked from the site footer, which is more than several vendors assessed in this category offer, but neither was opened in this pass and both should be read before this grade is relied on. Recorded as a flag rather than left implicit.

The stewardship question here is larger than for most vendors in this lane, and it is structural rather than incidental. Sickbay persists continuous high resolution waveform data for every monitored patient and markets analysis of unlimited monitoring history, so a deployment accumulates one of the densest physiological datasets a hospital will hold.

Establish retention terms, who owns the archive, whether de identified data is used for product development, and what the position is when third party algorithm developers access it through the platform's APIs.

Converted from Not Rated. No statement of business associate terms, execution path, scope or subprocessors was located. The prior note's guidance stands and is the right first question: the platform can run inside the hospital environment or be delivered as a service, and those produce materially different agreements, so establish which is being quoted before assessing anything else.

A second question is specific to this platform and is arguably the more important one. The company describes the data it persists as available to clinicians, researchers and algorithm developers. Those are three different uses under one architecture. Monitoring a patient is treatment. Retrospective research on the archive is research, governed by institutional review board approval and an authorisation or waiver. Making physiological data available to algorithm developers is a further step again, and whether those developers are the hospital's own, the vendor's, or third parties changes the analysis completely.

That matters more here than for most vendors because the archive is the product's distinctive value. Waveform data at millisecond resolution is normally transient and discarded by bedside devices; persisting it is precisely what makes the platform useful for analytics and model development, and it also creates a durable, richly identifying record of every monitored patient that would not otherwise exist.

Establish which entity signs, whether the agreement permits use of the archive for the vendor's own product development, who counts as an algorithm developer for access purposes, what governs research use, and what happens to the accumulated archive at termination.

Converted from Not Rated. No SOC 2, HITRUST, ISO 27001, trust centre or report request path was located.

The prior note recorded an indirect signal worth keeping: the company's general counsel is described as holding oversight of the quality system and regulatory certifications, which implies a formal quality system exists. That inference is now confirmed from the regulatory record, since the platform and its applications hold device clearance as a class II programmable diagnostic computer for prescription use. A cleared device requires a quality system. It does not require, and does not evidence, an information security programme, which is the same distinction this index applies to device quality management standards generally.

One further distinction matters here and it is easy to get wrong. This index has recorded that a device cleared in recent years has had cybersecurity documentation reviewed by the regulator, because a submission for a networked software device must now include a security plan, a software bill of materials and a post market update process. That requirement attaches to submissions made from 2023 onward. This platform's clearance predates it by a wide margin, so no equivalent review sits behind it. The vintage of a clearance therefore changes what that clearance implies about security, and a buyer should check the date rather than the fact.

The absence weighs heavily here because of what the platform holds: continuously persisted high resolution physiological waveform data at millisecond granularity for every monitored patient, retained for retrospective analysis rather than discarded. Ask what security examination has been performed by anyone external, and when.

Genuine clearance covering both the platform and named applications: the Sickbay Clinical Platform plus Patient Monitor, Patient Alarm Data and Alarm Analytics Dashboard, cleared as Class II devices. The company's claim to be the only vendor neutral FDA cleared platform of this kind is specific and checkable rather than vague, and clearing a data platform rather than an algorithm is a distinct and non trivial regulatory position.

Held at B rather than A because the original clearance dates from 2015, no clearance numbers or indications for use text were retrieved, no recent regulatory activity was identified, and the scope of what was cleared could not be read directly. Per this index's standing method the 510(k) summary should be pulled and read on the refresh pass, since device descriptions and indications routinely differ from marketing in ways that matter.

No subgroup or fairness analysis is published, though there is comparatively little model here to be biased.

The governance exposure at this layer is different from the one elsewhere in this category, and it is novel for this index. Sickbay is the substrate on which other parties build algorithms, so differences in device coverage, capture completeness and data loss propagate silently into every downstream model. A hospital with a patchy or older device estate produces a thinner data stream, and every algorithm built on it inherits that thinness without anyone being positioned to notice.

That is a technical rather than demographic fairness problem, the same shape recorded against WELL AI Inbox Admin on scan quality, but with far wider blast radius because it sits underneath everything else. Nobody publishes capture completeness by device type or site, and nothing describes what governs third party algorithms built on the platform's APIs.

Transparency by construction carries this grade, and it is the same structural advantage this index has credited in rules engines elsewhere. Risk indicators are configured by the institution rather than learned by the vendor, so a hospital can state exactly what triggers a flag and a clinician asking why an alert fired can be answered by reading the configuration.

That places authorship where the clinical accountability already sits and it makes an alert contestable in a way a learned score is not. The underlying capture is described in unusual technical detail as well, covering vendor neutral acquisition across disparate device manufacturers including non networked equipment, waveform data at a stated sampling interval, and persistence of the full monitoring history. Held at C for two reasons.

No specification of the available indicators was located, so a buyer cannot see the menu they would be configuring from or what the shipped defaults are, and this index has recorded the same gap for supplied rule libraries elsewhere: the defaults carry the vendor's judgement without the vendor's evidence.

And the alarm analytics application, which is the most clinically consequential component, is described by function rather than by method, so the one part that reduces or reorders alerts is the part with no published account. No warranty, indemnity or remediation commitment was located. Ask for the indicator specification, the shipped defaults, and the method behind the alarm analytics.

Device side interoperability is the best in this category and it is the harder half of the problem. The platform is built specifically to defeat proprietary device data formats, capturing waveform and vitals across disparate manufacturers, reaching non networked equipment such as ventilators through dedicated connectivity hardware, and persisting the result at waveform resolution. It then exposes that data through APIs and development tools so third parties can build on it, which is a genuinely different depth from a vendor that merely consumes an interface. Marketplace presence includes Microsoft.

Held at B rather than A for a specific gap. No EHR vendor is named anywhere retrieved, no FHIR or SMART on FHIR capability is described, and no marketplace listing or partner certification with an EHR was located. Naming EHR integrations would move this to A, since the device half already clears that bar.

Flexible in ways that matter for this category. The platform runs on premise or as SaaS, supports remote and on site command centres, and renders through a browser on laptops, mobile devices and wallboards without proprietary hardware at the viewing end. The company states any bed can be scaled to a monitored ICU bed within minutes through a database change, which if accurate is the single most operationally significant claim on this record, since surge capacity is exactly what hospitals cannot buy quickly.

A dedicated rural healthcare offering is worth noting, because this lane's evidence repeatedly shows models and monitoring performing worst in resource constrained settings, and a platform aimed there is addressing the right gap. Named relationships include Texas Children's Hospital and Tampa General Hospital.

Held at B because no implementation timeline, resourcing requirement or data residency commitment is published, and the bed scaling claim carries no stated prerequisites.

No pricing published at any level: no rate card, no unit of pricing such as per monitored bed or per device interface, no band, and no implementation fee. The pricing unit is a real question for a platform of this shape, since cost could reasonably scale with beds, with device interfaces, with data retained or with named users, and each implies a very different total. Marketplace availability through Microsoft does not carry a published price. Establish also whether device integration work, particularly for older or non networked equipment requiring additional connectivity hardware, sits inside the licence or is charged separately.

Broad by design rather than by clinical specialisation, which is the correct reading for a substrate. Originally built for intensive care and extended across the enterprise, current coverage spans ICU, telemetry and general monitored beds, with modules for virtual operations and analytics, an explicit rural healthcare offering, and stated reach from hospital to home.

Because the platform is vendor neutral at the device layer, coverage is effectively a function of the hospital's monitoring estate rather than of a clinical indication, which is a genuinely different property from every modelling vendor in this category. Held at B because no age, population or clinical exclusions were retrieved, so the published limits of use are unclear, and because breadth at the data layer does not by itself establish clinical depth in any particular setting.