CLEW Medical
CLEW Medical, based in Netanya, Israel, with US operations in Boston, sells FDA cleared machine learning models that predict clinical deterioration in hospital critical care, delivered through a clinical surveillance platform for bedside and tele-ICU teams. Its operating characteristics are public because the models are regulated as medical devices and the 510(k) summaries state them.
The cleared device, the CLEWICU System, contains two models. CLEWHI estimates the likelihood that a patient will develop hemodynamic instability requiring vasopressor or inotrope support within the next eight hours. CLEWLR indicates that a patient is at low risk of deterioration. The system ingests EHR and patient monitoring data over an HL7 connection and runs on infrastructure the hospital provides. Around the models the company sells a platform it describes as built on those models and rules-based best practices, with unit level situational awareness, rounding worklists and configurable notifications.
The first 510(k), K200717, cleared in January 2021. A second clearance, K233216, granted on 13 January 2024 under 21 CFR 870.2210, product code QNL, Class II, broadened the use environment from the ICU to all hospital critical care areas for adults, showed the models met the same pre-specified criteria after retraining on 50 input features rather than 80, and added a predetermined change control plan permitting further retraining under stated conditions. In April 2024 the company announced its "FDA-cleared" platform for all inpatient settings, including medical and surgical floors, which the clearance does not cover.
Evidence comes from the regulatory file and the peer reviewed literature: retrospective validation on the UMass eICU (6,534 stays) and MIMIC-III (5,069 stays) datasets, and a 2024 CHEST paper, with CLEW coauthors, comparing the models with telemedicine alerts and bedside monitor alarms at UMass Memorial and WakeMed. Named sites include UMass Memorial, WakeMed Health and Hospitals, Penn State Health, EQUUM Medical, Sheba Medical Center and Tel Aviv Sourasky Medical Center. 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 cleared device is machine learning, and the product now sold around it is a wider platform. FDA's K233216 summary describes the CLEWICU System as stand-alone software that "uses models derived from machine learning" to compute CLEWHI, the likelihood of hemodynamic instability needing vasopressor or inotrope support within eight hours, and CLEWLR, an indication that a patient is at low risk of deterioration.
CLEW's April 2024 release describes the platform it sells as "built upon proprietary, machine-learning derived prediction models and rules-based best practices", with built-in clinical protocols and surveillance tools for bedside and tele-ICU teams. The prediction models are the engine of the core module; the rules-based protocols and surveillance workflow carry value of their own. B.
Adjunctive by label, with the low risk model as the exposure. The cleared indication says predictions are for reference only and no therapeutic decision should rest on them alone, and the models notify rather than act. CLEWHI flags patients likely to need vasopressor or inotrope support within eight hours; CLEWLR labels patients as low risk of deterioration, a label a unit may lean on when deciding who can step down.
That second model is where oversight matters: at about 90 percent specificity, about one in ten patients who are not low risk still receives the low risk label, and a wrong low risk label removes attention rather than adding an alert someone can dismiss. The escalation rule, the lead time seen in live use and how clinicians respond to notifications are not published. B.
What each model predicts and how it was validated is public; the models themselves are not described in detail. The K233216 filing names the two models, their outputs and horizons (hemodynamic instability needing vasopressor or inotrope support within eight hours; low risk of deterioration), the inputs (EHR and bedside monitor data over HL7), the reduction from 80 to 50 input features, the pre-set performance targets and results with confidence intervals, software development to IEC 62304, and a change control plan that governs retraining.
The CHEST 2024 paper describes how notifications were compared with telemedicine alerts and monitor alarms. The approach is named, without the model class, the feature list, the training population, or a record of which retrained version a given site runs.
A structurally short chain for the cleared device. The K233216 summary describes models derived from machine learning running inside CLEW's own server software on infrastructure the hospital provides, with no outside model provider in the data path.
The open question is retraining: the change control plan lets CLEW retrain on new datasets "as they become available" and for sites with different inputs, which implies hospital data reaching CLEW's in-house training unless the contract says otherwise, and the company is headquartered in Israel. No subprocessor list or data processing terms appear in the filing, though CLEW's website may carry them.
Retrospective validation in the regulatory file and one peer reviewed comparison with vendor coauthors. The K233216 validation ran the models over each patient stay in time order, without access to future data, on two independently evaluated datasets: the University of Massachusetts eICU dataset (6,534 stays) and the public MIMIC-III dataset (5,069 stays).
CLEWHI reached 63 and 69 percent sensitivity, 93 and 87 percent specificity, and 12 and 10 percent positive predictive value; CLEWLR reached 47 and 35.5 percent sensitivity at about 90 percent specificity, all against targets set before testing.
Lilly and colleagues (CHEST, 2024; data from 14 intensive care units at UMass Memorial and WakeMed, with authors also from Sheba Medical Center and the University of Iowa and CLEW staff among them) compared the machine learning notifications with telemedicine system alerts and bedside monitor alarms for predicting intubation and vasopressor starts, reporting accuracy of 0.87 to 0.94 against 0.28 to 0.53 and 0.019 to 0.028, and about 50-fold lower alarm burden than the telemedicine alerts.
Published research with its method, short of independent validation. There is no prospective or outcome study, and nothing is published for the medical and surgical floors the platform was extended to in 2024.
The 510(k) states that the server and interface components are software only and run on infrastructure the user provides, which allows a hospital to keep processing inside its own environment. That answer comes from the regulatory filing rather than customer facing material: no privacy policy, data processing addendum or retention statement is published.
Nothing published addresses whether customer data is used for model retraining, which the Predetermined Change Control Plan turns into a live question rather than a theoretical one, or cross border handling given Israeli headquarters serving US health systems.
CLEW publishes no statement on business associate agreements, execution terms or cost. Named United States health system deployments mean agreements almost certainly exist, and nothing about them is published.
Three features of this deployment make scope the substantive question rather than a formality, and none is obvious from the product description.
The first is the data itself. The platform receives both record system data and medical device output. Device data is protected health information when it is attributable to a patient, and an agreement drafted around record system access may not describe a continuous feed from bedside monitors. Whether both are covered is not stated.
The second is the remote care model. Where a platform supports monitoring by teams outside the unit, and remote intensive care coverage is frequently provided by a separate organization or a contracted group, the chain acquires another party. Nothing published says who the remote users are, which entity employs them, or whether their access is covered by the hospital's agreement with this vendor or requires its own.
The third is corporate structure. The company is headquartered outside the United States and operates a domestic entity. The signing entity, the location of development and support staff, and the terms for offshore access to protected health information are all undisclosed. Offshore access of that kind is permitted when it is documented.
No attestation, trust center or report request path is published.
A clearance is a safety and effectiveness determination, not an information security attestation, and the same applies to a quality management system certification. A company holding two clearances and selling into critical care has been examined on whether its models work, not on how it protects the data they run on.
The architecture is what makes that gap matter. The platform ingests both record system data and medical device data in near real time. Bedside monitor output comes from the clinical device network, which hospitals deliberately segment and control more tightly than their general network precisely because those devices are hard to patch and directly attached to patients. A vendor drawing from both sits across two security zones an organization has separated on purpose, and that crossing is the central exposure.
The remote care model adds a second surface. The product is built for local units and remote monitoring teams alike, so platform access extends beyond the hospital, potentially to clinicians at a different organization.
And the company is headquartered outside the United States with a domestic entity, so development and support access location is a live question.
Two clearances are real and verifiable, and the company has put the cleared label on use they do not cover. K200717 (9 January 2021) and K233216 (13 January 2024) clear the CLEWICU System under 21 CFR 870.2210, product code QNL, Class II.
K233216 indicates it "for use in hospital critical care settings for patients 18 years and over" (intensive care, emergency department critical care or resuscitation, post-anesthesia care, step-down, post-surgical recovery, and specialized units such as cardiac and neurocritical care), says predictions are "for reference only" with no therapeutic decision to rest on them alone, and includes a predetermined change control plan allowing retraining against fixed performance floors.
That filing's purpose was to show the models still met the original criteria after retraining on 50 input features instead of 80, and to widen the setting from the ICU to all critical care areas; it was not a performance improvement. On 29 April 2024 CLEW announced "general availability of its FDA-cleared, AI-driven, intelligent clinical surveillance platform" across all inpatient settings, naming medical and surgical floors, where no CLEW clearance applies.
A June 2024 release from its partner AvaSure described the clearance correctly, as predictive models for critical care. The cleared label attached to deterioration prediction outside the cleared setting.
A regulator reviewed plan governs how the models may change. The predetermined change control plan cleared with K233216 lets CLEW retrain the models for hospitals with fewer, less frequent or additional inputs, or on new datasets, without a new submission, on published conditions: training and testing data completely independent; validation on patient data from at least three geographically diverse sites, with no site above 50 percent of the validation set; and the same minimum performance (CLEWHI sensitivity 0.6 and positive predictive value 0.1, CLEWLR sensitivity 0.25 and specificity 0.9). No results by age, sex, race or admission type are published, and MIMIC-III, one of the two validation sets, comes from a single Boston center.
Error rates are published with their method and denominators, in the company's own regulatory filing. The K233216 summary states the performance targets set before testing and the results against them on 6,534 and 5,069 patient stays with 95 percent confidence intervals. CLEWHI sensitivity was 63 and 69 percent with positive predictive value of 12 and 10 percent, so roughly nine in ten high risk notifications are not followed by the event.
CLEWLR specificity was about 90 percent, so about one in ten patients who are not low risk still receives the low risk label. The change control plan binds any retrained model to the same floors. Nothing stands behind the output beyond that: none of the filings or company releases mentions a warranty, indemnity or remediation commitment.
Standards based integration with named deployments behind it. The 510(k) describes the server importing EHR and bedside monitor data over an HL7 connection, the sensible choice for device streams that FHIR serves poorly, and a heavier build than an app.
Deployments are named in the company's releases and the CHEST paper (UMass Memorial, WakeMed, Sheba Medical Center, Penn State Health), but no EHR vendor, marketplace listing or write-back into the record is documented in the filings or releases, and the change control plan itself anticipates hospitals whose input data types and frequencies differ. B.
Software only, on infrastructure the hospital provides. The 510(k) states that the server and user interface are software-only devices run on a user-provided server or cloud infrastructure, so data can stay in the hospital's environment and residency follows the customer's choice.
The change control plan anticipates site-specific retraining, so the model a hospital runs may be a retrained variant validated under that plan rather than the model in the filing; where that retraining happens, and on whose data, is not stated. Options and residency follow the customer, with the processing path for retraining left open.
No pricing published at any level. No rate card, no stated unit of pricing, no indicative band, and no published implementation or integration fee. Enterprise quote on contact only.
The cleared setting is named and bounded, and the platform has been sold beyond it. K233216 covers adults 18 and over in hospital critical care settings: intensive care, emergency department critical care or resuscitation areas, post-anesthesia care, step-down, post-surgical recovery, and specialized units such as cardiac, neurocritical and high dependency care, which rules out pediatric use.
Validation behind that is retrospective on UMass eICU and MIMIC-III data, plus the CHEST comparison at UMass Memorial and WakeMed. In April 2024 CLEW announced the platform for all inpatient settings, including medical and surgical floors and perioperative suites, with Penn State Health named as a site; no validation for those settings is published. Coverage named, with validation behind the critical care part.
Alternatives to CLEW Medical
Vendors in the same categories as CLEW Medical whose graded profiles look most alike, with a line on what each product does.
Similar is not the same, so check that each one does the job you need. No vendor pays for placement.
AITRICS is a Seoul medical AI company whose AITRICS-VC (VitalCare) predicts deterioration in hospitalized adults from routine electronic medical record data.
Etiometry, based in Dedham, Massachusetts, sells a clinical intelligence platform for critical care that combines vendor neutral ICU data aggregation with four FDA cleared physiologic risk indices.
AvaSure makes virtual care technology for hospitals, and launched virtual sitting (TeleSitter) in 2009.
HealthLeap screens every adult hospital inpatient every day for malnutrition risk.
Healthplus.ai, based in Amsterdam, sells PERISCOPE, CE marked software that predicts which adult surgical patients will develop a postoperative bacterial infection.
PeriGen sells perinatal software for labor and delivery units.
Ordered by how closely the graded profiles match across the fifteen axes, inside the same categories. See how each axis is graded in the methodology.
Compared With
Each comparison carries a written verdict, the buyer conditions that favor each vendor, and a graded side by side. Pairs that cross a category boundary are grouped separately, and their verdicts state where the boundary sits rather than manufacturing a head to head.
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 information of any kind is published. No rate card, no stated unit of pricing such as per bed, per monitored patient day or per unit, no indicative band and no published implementation, integration or model validation fee. Contact is gated behind a demo request form and sales telephone numbers.
Two cost factors a buyer should raise directly, both implied by the regulatory filing rather than by commercial material: the system runs on infrastructure the hospital provides, so server or cloud cost sits with the customer and is not part of any vendor quote, and the cleared change control plan anticipates that models may need retraining against a given site's available data, so establish whether site specific model training and validation is included in the license or charged separately.