Healthplus.ai

The models are the product and are regulated as such. PERISCOPE is certified as software as a medical device in its own right, the company is effectively single product, and removing the prediction leaves nothing saleable. No platform layer, no data aggregation business and no services wrapper dilutes the claim. This is one of the cleanest centrality A cases in the category.

Adjunctive by design and by certification. The output is a risk probability rendered as one of three traffic light categories inside the existing EHR workflow, and clinicians decide what follows. Hospitals build their own pathways around the categories, which puts the action threshold with the institution rather than the vendor, the same property that earned Affineon and Haystack credit.

The exposure is the low risk category, and it is the same structure flagged on CLEW's low risk model. A clinician quoted in the company's own material describes low risk as meaning more confidence when discharging, and the company markets safer discharge directly. A false low risk label does not generate a visible error. It quietly accelerates a discharge, and nobody is positioned to notice the patient who returns to another hospital.

Held at B rather than A because no false negative rate at the discharge relevant threshold is surfaced in customer facing material, even though the underlying paper reports the analysis that would support one.

Among the strongest in the index, and the reason is calibration. The model class is named plainly as XGBoost rather than described as proprietary AI, the input space is stated at roughly 50 preoperative and intraoperative clinical parameters drawn from existing record data, and the two prediction horizons of seven and 30 days are explicit.

The decisive point is that the peer reviewed paper reports calibration slope, intercept and plots alongside discrimination. Almost nothing in this index publishes calibration at all, and without it a risk percentage cannot be interpreted as a probability, which is exactly what a traffic light category asks a clinician to do.

The development, validation and local updating methodology is fully described and reproducible in outline. Held short of perfection only by the absence of a published feature list and a model card, though the parameter count and data sources are given.

One design property genuinely narrows the footprint and one disclosed practice opens the question that matters. The narrowing: the system reuses data already present in the record and requires no new measurements or additional collection, so it adds nothing to a hospital's estate, which is a smaller privacy proposition than any product that captures something new and the vendor states it plainly.

The question: models are recalibrated per hospital site to reflect local patients, professionals and protocols, and the published validation describes models developed at one hospital and then updated at others using their own historical record data. Recalibrating locally is the right way to build a prediction model, because performance degrades when a model trained elsewhere meets a different population, and disclosing that it happens is better than the silence most vendors offer.

It also means a hospital's retrospective data is used for model updating, and where that computation runs is unstated. If recalibration executes inside the hospital's environment on its own data, the chain is short and the answer is favourable. If an extract moves to the vendor for the purpose, that is a transfer with its own basis, retention and residency questions, and European data protection law governs it. Ask for the recalibration architecture, the data flow it requires, the retention of any extract, and whether the resulting model stays specific to that hospital.

The best evidence in this category. van der Meijden SL, van Boekel AM, Schinkelshoek LJ et al., The Lancet Regional Health Europe, published 5 December 2024, doi 10.1016/j.lanepe.2024.101163. 253,010 surgical procedures, data from 2014 to 2023, multiple surgical specialties, models developed at one hospital and validated and updated at two further hospitals across the Netherlands and Belgium, with the two most recent years held out for temporal validation.

What separates it from everything else assessed here is the outcome measure set: discrimination, calibration, and clinical utility through decision curve analysis with net benefit. Decision curve analysis answers the question AUROC cannot, namely whether acting on the model at a given threshold is better than not acting, weighing the relative harm of false positives against false negatives. That is the analysis this category most needs, and this is the only vendor assessed that has published one.

Funding did not come from the vendor. The study was supported by a REACT EU grant from the European Regional Development Fund. Conflicts are disclosed, with the chief executive a major shareholder and two authors employees, alongside a substantial independent academic author list.

One caution. Partner and marketing material reduces all of this to accuracy above 90 percent, which for an outcome the company itself puts at roughly one in five patients is close to what predicting no infection every time would achieve. The paper is the evidence; the accuracy figure is not.

No privacy policy, data processing agreement, retention statement or training use disclosure was located, and the earlier assessment's framing holds: the governing obligations arise from European data protection law and do not depend on vendor publication.

The design property recorded earlier is confirmed and deserves crediting again, because it is a real reduction rather than a claim. The system reuses data already present in the record and requires no new measurements or additional collection. A product that adds no data to a hospital's estate is a smaller privacy proposition than one that captures anything new, and this vendor says so plainly.

The open question is now specific rather than general, because the second pass establishes what the earlier note suspected. Models are recalibrated per hospital site to reflect local patients, professionals and protocols, and the published validation work describes models developed at one hospital and then updated at others using their own historical record data.

That is the right way to build a prediction model, since performance degrades when a model trained elsewhere meets a different population. It also means a hospital's retrospective data is used for model updating, and the question is where that happens. Establish whether recalibration runs inside the hospital's environment on its own data, or whether an extract moves to the vendor for the purpose, what legal basis covers it, and whether the resulting model is specific to that hospital or contributes to a shared one.

Ask for the recalibration architecture, the data flow it requires, and the retention of any extract.

This axis does not map, and the earlier assessment's handling of that is the right one: saying so is more useful to a buyer than grading a vendor down for failing a test that does not apply to it.

The product is a European medical device certified as Class IIa under the device regulation, deployed in the Netherlands, Belgium, Denmark and the United Kingdom. The governing instruments are the European data protection regulation and the device regulation, and a business associate agreement is not among them. What a buyer needs instead is a data processing agreement under the European framework, with the controller and processor roles defined, the legal basis for processing health data identified, and the position on transfers stated. The British deployment sits under the equivalent domestic regime following departure from the European Union, so the transfer position between the two is a live question rather than an assumed one.

The conditional recorded earlier stands and is now closer. The company states it is preparing to expand into North America and pursuing United States authorisation, and its investors describe the same. At the point a United States deployment exists, this axis becomes live and should be reassessed from scratch: a business associate agreement will be required, and European compliance will not substitute for it.

That transition is worth flagging to any early United States adopter, because a vendor entering the market on the strength of its European certification may not yet have the contractual apparatus the domestic rule requires.

A second pass reaches the vendor's own material, which states that it meets both the medical device quality management standard and the information security management standard. That is materially better than the position recorded earlier and it is one document short of a higher grade.

The distinction this index applies elsewhere applies here. Meeting a standard and holding certification against it are different: certification is an audited determination by an accredited body, issued with a scope statement and an expiry date. The quality management certification is separately confirmed as achieved, and the parallel phrasing suggests both are held at the same level, but a reader cannot tell. Ask for the certificate, the certifying body, the scope and the expiry.

One nuance is new to this index and worth recording, because it partially closes the gap the earlier note identified. Under the European device regulation, a manufacturer must address information technology security as part of the essential requirements, and a notified body assesses that as part of granting certification. So a European certified device has had a security element examined by an external party, scoped to the safety and performance of the device rather than to the company's enterprise information security.

That is more than a clearance carries and it is not a substitute for an information security certification. Both statements are true and a buyer should hold them together.

Ask for the information security certificate and, separately, the security documentation submitted for device certification.

No FDA clearance; the company states it is pursuing US authorisation. What it holds instead deserves precise handling, because a naive prestige ranking of regulators gets this backwards.

PERISCOPE is CE certified as Class IIa software as a medical device under the EU Medical Device Regulation, with ISO 13485. The MDR route requires a clinical evaluation supported by clinical evidence. Compare the US 510(k) pathway, where substantial equivalence to a predicate can be established with no clinical data at all, as happened with another vendor in this same category whose filing states in terms that the device did not require clinical data. So on the specific dimension of clinical evidence demanded, this vendor has cleared a higher bar than some FDA cleared competitors, in a different jurisdiction.

The question for a buyer is therefore which regulatory route a vendor took and what evidence that route actually required, rather than which regulator sounds more demanding. Graded B rather than A because the authorisation is regional, covers no US market, and MDR Class IIa is not the highest EU risk class.

The third distinct answer in this category to the institutional variability problem, and the only one that is an empirical research finding rather than a company commitment. CLEW binds retraining through a regulator reviewed change control plan. Etiometry claims continuous production drift monitoring. Healthplus.ai calibrates to each hospital's own data, and its published study was designed to test exactly that, developing at one site then validating and updating at two others and measuring performance before and after updating. The paper's stated conclusion is that local updating is necessary to account for domain shifts in patient populations and data distributions across settings. That turns the Epic Sepsis Model institutional variability finding into a method.

Held below A on two counts. No subgroup performance is published by sex, age, ethnicity or socioeconomic status. And the prediction target is defined as the probability of requiring clinical action related to postoperative infection, which is a label learned from what clinicians actually did rather than from biological ground truth, so it can encode differential recognition and response patterns. Birth Model's obstetric risk labels carry the same structure. Nothing published addresses it.

This record answers the specific gap this index has flagged across the monitoring category, and it should be cited when a competitor claims the disclosure is impractical. The peer reviewed work reports calibration slope, intercept and plots alongside discrimination.

Almost nothing else in this index publishes calibration at all, and without it a risk percentage cannot be read as a probability, which is precisely what a categorised risk display asks a clinician to do: a well discriminating but poorly calibrated model puts patients in the right order and the wrong bands, so the threshold that triggers action fires at the wrong rate. Publishing calibration is what makes a stated risk actionable rather than merely rank ordered. The rest supports it.

The model class is named plainly rather than described as proprietary artificial intelligence, the input space is stated at roughly fifty preoperative and intraoperative parameters drawn from existing record data, both prediction horizons are explicit, and the development, validation and local updating methodology is described in enough detail to be reproducible in outline.

Held below the top grade because no warranty, indemnity or remediation commitment attaches, and because the feature list and a model card are absent even though the parameter count and data sources are given. Ask whether calibration is re measured after each local update, and what a site sees if it drifts.

Integration is the delivery model rather than an add on: predictions render inside the existing EHR workflow rather than in a separate dashboard, which the company quantifies as saving around ten clicks per patient per shift by consolidating infection relevant information in one place. Distribution runs partly through Founda Health, a Dutch healthcare interoperability platform, which is a real third party integration route.

The product also requires no new data capture, drawing only on what the record already holds, which materially lowers the integration burden compared with vendors in this lane that need live device feeds. Held at B because no EHR vendor is named anywhere, there is no marketplace listing or partner certification, and no FHIR or SMART on FHIR capability is described.

Named clinical sites include Amsterdam UMC and Deventer Ziekenhuis, with the published study drawing on three hospitals across the Netherlands and Belgium. Market scope is stated: licensed to operate in the EU with initial focus on Benelux and Germany, which is a clearer geographic statement than most vendors offer.

Local calibration is a named implementation step rather than a marketing phrase. The company states models are calibrated to each hospital's data, and the published work demonstrates the updating procedure, so a buyer knows a site specific step exists.

Held at B because no implementation timeline, resourcing requirement, hosting architecture or data residency commitment is published, and it is not stated whether local calibration is included in the licence or charged separately.

No pricing published at any level: no rate card, no unit of pricing, no band and no implementation or calibration fee.

The asymmetry is worth naming because it recurs across this category, and Droxi takes the same posture. The company publishes the customer's upside in detail, citing avoided costs of more than four million euro per hospital per year in one place and a bottom line improvement above two million euro in another, while gating its own price entirely. A buyer modelling return on investment has one side of the equation and not the other. The two savings figures are also inconsistent across sources, with no stated basis or derivation for either.

Narrow on condition and broad on specialty, with the limits published. The target is postoperative bacterial infection defined inclusively, covering surgical site infection, pneumonia, urinary tract infection and other bacterial infections rather than surgical site infection alone, which is a wider and more clinically honest target than most competitors in the surgical risk space attempt. Coverage spans a wide range of surgical procedures and multiple specialties, evidenced by a development and validation cohort drawn across specialties rather than a single service line. Adults only.

The 30 day horizon is an unusual property in this category and worth noting. It extends past discharge, so the product straddles inpatient monitoring and post discharge risk in a way nothing else in this lane does, which raises a question the vendor does not address about who is watching, and who is accountable, once the patient has gone home.

Geographic coverage is EU only.