Vivalink

Genuine algorithmic content inside a business whose primary offering is capture and delivery rather than interpretation.

This is closer to infrastructure than most records in this index, and the record should say so plainly. The product is a sensor family, an edge network, a cloud data service and a development kit, sold so that other organisations can build their own monitoring applications. Company material describes delivering standardised, integration ready data formats for ingestion into existing clinical, research and analytics platforms, which is a data pipeline proposition. Much of the customer base is buying reliable physiological capture, not a conclusion.

The intelligence that exists is real and is concentrated in cardiac analysis. Arrhythmia detection from continuous electrocardiography is a genuine machine learning problem, the electrocardiography platform holds clearance, and company material refers to advanced algorithms and to revealing insight from data streams described as too voluminous for teams to manage.

The distinction that sets the grade is who owns the clinical layer. Where a customer builds the application, the consequential interpretation is frequently theirs, and Vivalink supplies validated measurement plus a pipeline. That is valuable and it is a different thing from a product whose output is a clinical judgement.

Graded C rather than lower because cleared cardiac algorithms ship, and rather than higher because no algorithm performance is published and the platform is explicitly positioned as enabling other people's software. Ask what the algorithms detect, at what performance, and how much of the customer base uses them.

The oversight layer usually belongs to the customer, which relocates the question rather than answering it.

The platform delivers measurement and derived insight into applications that other organisations build and operate. Where a customer constructs the clinical workflow, that customer determines what triggers an alert, who receives it, how fast they must respond and what a clinician sees. Vivalink cannot describe one oversight posture because there are as many as there are integrations, and that is a coherent position for an enablement business.

What the architecture requires, and what is not published, is the boundary. Nothing describes what the platform requires of an integrating application before it may run in a clinical setting, what guidance is given on alert thresholds, or whether any clinical safety review accompanies a deployment. A cleared sensor placed inside an unvalidated application is a real risk that this model creates.

The cardiac products are where this matters most. Arrhythmia detection produces findings a clinician acts on, and no operating point, sensitivity, specificity or false alarm rate was located for any algorithm, so neither the integrator nor the end clinician can characterise the miss rate they are working with.

One element runs the right way. Data file download for retrospective analysis is offered alongside real time streams, which supports post hoc review and audit rather than only live alerting.

Ask what the platform requires of integrating applications, and for detection performance at the deployed threshold.

Hardware and architecture are specified in genuine detail, and the algorithms are not.

The device disclosure is thorough. Sensors are enumerated individually covering a multi function cardiac patch, a clinical temperature monitor, an oxygen saturation sensor and a blood pressure cuff, with parameters listed per device and reusability stated. Engineering detail extends to extended data cache, improved battery life and stronger network connectivity, described as changes made from field experience, which is more candid than a specification sheet.

The architecture is equally concrete: sensors, edge networking, cloud data services, a development kit supporting mobile integration, routers supporting on premise multi patient monitoring, machine to machine web services, and retrospective data file download. A developer can understand what they are integrating before contact.

The technical lineage is also disclosed rather than obscured, tracing the sensor substrate to a thin film integrated circuit technology developed with a major technology company's advanced research group and commercialised as a consumer product before becoming the basis of the medical range.

The algorithm layer is characterised only by label. Advanced algorithms and arrhythmia detection are referenced with no accuracy, sensitivity, specificity, operating point, model card or architecture, and nothing describes what the platform computes beyond transporting measurements.

One pre emptive note: further hardware specification cannot move this grade. Only published algorithm performance will.

Ask what the algorithms detect and at what performance, and how insight generation differs from data transport.

Partners and lineage are named openly, and the technical chain is not.

The disclosures that count are unusually forthcoming for this axis. Third party device manufacturers whose pulse oximeters, glucose monitors and sleep monitors are ingested through the platform are named, so a customer knows which external instruments are supported and by whom. A global clinical trial infrastructure provider is named as an integration partner. And the origin of the core sensor technology is stated rather than obscured, tracing the thin film substrate to a collaboration with a major technology company's advanced research group and its commercialisation as a consumer product before the medical range was built on it.

The standards basis implies documented supplier controls, since quality management certification requires them for a device manufacturer.

What is undisclosed is everything about the platform's own dependencies. No cloud or hosting provider, no sub processor register, no machine learning framework, no component or silicon supplier and no contract manufacturer was named.

Training provenance is unaddressed and the question is sharper than usual because of the dual market. The company sits across clinical care and regulated research, so physiological data flows through the platform under two different consent regimes, and nothing states whether either has informed algorithm development or how research data is walled off from commercial use.

Ask for the hosting provider and sub processor register, the manufacturing arrangement, and whether platform or trial data trains algorithms.

Wide commercial reach and real research usage, with the evidence attaching to customers' studies rather than to the vendor's own claims.

The commercial figures are substantial: more than 400 customers with brand reach across 116 countries, growing from around 200 partners in 40 countries several years earlier. Sensors are described as clinically validated and hold clearance in three major regulatory regions, which implies accuracy data was submitted and reviewed in each.

Research use is named and specific, including a longitudinal atrial fibrillation study of up to 3,000 subjects seeking biomarkers of early atrial change, a chronic obstructive pulmonary disease progression study tracking respiratory rate, heart rate variability and activity, and sleep research. A partnership embeds the technology within a global clinical trial infrastructure provider.

The distinction that holds this at C is what those studies demonstrate. They show the sensors are trusted to capture research grade data at scale, which is genuine evidence of measurement reliability. They are not evidence about Vivalink's algorithms, because in each case the scientific question belongs to the investigator and the platform is the instrument.

No peer reviewed publication of the company's own algorithm performance was located, no accuracy or agreement figures, and no outcome study showing that deployments changed care.

Ask for validation data on the electrocardiography algorithms against a reference standard, and for any outcome result from a hospital at home or ambulatory cardiac deployment.

A documented standards basis and a real architectural option, without operational specifics.

The standards stack does substantive work here. Health privacy and data protection compliance are claimed alongside the international information security management standard, the electronic records rule governing regulated research, the medical device software lifecycle standard and the risk management standard. Together those cover record integrity, audit trail, software development discipline and hazard analysis, which is a broader governance base than a privacy claim alone. End to end systems integrity checks are described as a platform property.

The architectural point is more useful than any policy statement. Development kit enabled routers support multi patient monitoring on premise, which means a deployment can consolidate and process within a facility rather than requiring every physiological stream to reach a vendor cloud. An organisation with data location constraints has an option that most monitoring vendors in this index do not offer.

What is missing is the operational detail. No encryption description, no retention schedule, no access control model, no deletion process and no position on whether data traversing the platform contributes to model development.

That last question carries weight given the research business, because data captured under a trial protocol operates on a consent basis that does not automatically extend to commercial algorithm development, and the company sits across both markets.

Ask what is retained and for how long, whether the on premise mode eliminates cloud transit entirely, and whether platform data trains algorithms.

Three regimes named including one that most vendors in this index never mention.

United States health privacy law and European data protection law are both claimed explicitly, which is appropriate for a company operating across 116 countries. The addition that distinguishes this record is compliance with the federal rule governing electronic records and electronic signatures in regulated research. That regime imposes requirements on record integrity, audit trails, system validation and attributability, and it is the standard a clinical trial sponsor must satisfy for data to be admissible to a regulator. Naming it signals the platform was built for regulated research rather than adapted to it, and no other record in this index cites it.

What is absent is the contractual layer. No business associate agreement template, execution requirement, negotiation stance or subcontractor flow down position was located.

The enablement model creates a question that goes unanswered and is specific to this vendor. Because customers build their own applications on the platform, the patient relationship belongs to them, and whether Vivalink contracts directly with covered entities, sits as a subcontractor to the application developer, or handles only de identified streams depends on architecture and is not described. A developer integrating the platform needs to know which of those applies before it can describe its own compliance position downstream.

Ask for the agreement template, where Vivalink sits in the contracting chain, and whether the platform handles identified data by default.

An information security certification is actually held, which most of this segment cannot claim, and it is named without the qualifiers that make it assessable.

The substance is real. The international information security management standard is listed among the platform's compliance basis, alongside the electronic records rule governing regulated research, which imposes audit trail and record integrity requirements, and the medical device software lifecycle and risk management standards. Across this session, sensing and monitoring vendors have repeatedly held device credentials while holding nothing covering information security, and this vendor holds both.

The imprecision costs the grade above. No revision year is stated, so whether certification is against the current control set or its predecessor is unknown. No certificate number, certification body, audit period or scope statement is published, and scope is the detail that determines whether a certificate covers the product platform or only corporate systems. This index has docked several vendors for exactly that omission and applies the same standard here.

Supporting apparatus is also absent. No trust centre, security page, penetration testing statement or vulnerability disclosure policy was located.

The surface warrants attention. Connected sensors, edge routers inside customer facilities and a cloud platform serving hundreds of integrators across many jurisdictions is a broad and shared attack surface, and the routers in particular sit on customer networks.

Ask for the certificate number, revision, scope and body, whether documentation is available under agreement, and the vulnerability disclosure route.

Clearance across three major regulatory regions and an unusually complete standards enumeration.

Sensors hold clearance in the United States, the European Union and China. That third market is uncommon in this index and is not a formality, since it involves a separate national regulator with its own testing and documentation requirements. The electrocardiography platform received United States clearance and the electrocardiography sensor holds European marking, and clearance for a platform rather than only a sensor implies the analysis layer was within scope.

The standards list is the more informative disclosure and is more complete than almost anything else recorded this session. Quality management, medical device software lifecycle, risk management and biocompatibility are all named, alongside the electronic records rule for regulated research and the information security management standard. Biocompatibility deserves specific mention because it governs materials in prolonged skin contact, which is exactly what a reusable adhesive worn patch involves, and it is the standard most commonly omitted by wearable vendors describing their compliance.

What holds this below the top is disclosure depth. No clearance numbers, indications for use, device classifications or clearance dates are published, so a buyer cannot establish precisely what each device is cleared to measure or claim, nor whether the arrhythmia algorithms are inside or outside the cleared indication.

Ask for the clearance list with numbers and indications by region, and whether algorithmic detection is within the cleared claim.

A dedicated pass located no fairness testing, no subgroup performance, no calibration data, no drift monitoring, no governance framework and no external algorithmic audit.

The standards stack is genuinely broad and none of it addresses this. Risk management, software lifecycle and information security standards govern hazard analysis, development discipline and data protection respectively; none requires demonstrating that a measurement or an algorithm performs equivalently across patient populations, and this record does not credit them as if they did.

Two exposures apply directly. Oxygen saturation is measured optically, and optical measurement through skin carries a well documented tendency to overestimate saturation in patients with darker pigmentation, an effect serious enough to have prompted regulatory attention. Another vendor in this same segment publishes an explicit skin tone validation claim, which establishes that the disclosure is achievable here.

The second concerns cardiac analysis. Electrocardiographic morphology and arrhythmia prevalence vary with sex, age, body habitus and ancestry, and an arrhythmia detection algorithm trained on one distribution can perform unevenly on another. Sensor placement and signal quality also vary with chest size and body composition.

The enablement model adds a third dimension. Customers deploy these algorithms inside their own products across 116 countries and diverse populations, inheriting whatever performance characteristics exist without published subgroup data to evaluate them against.

Ask for oximetry accuracy by skin pigmentation, and arrhythmia detection performance by sex, age and ancestry.

One published warranty and no allocation of clinical responsibility.

A dedicated pass located no service level agreement, no accuracy warranty, no uptime commitment, no indemnity and no remediation position. A product warranty is published, which indicates hardware terms are documented and is more than most vendors here offer, and a hardware warranty covers device failure rather than clinical consequence.

The enablement model makes allocation genuinely complex rather than merely undisclosed, and it runs three deep. A patient is monitored by a sensor Vivalink made, through a pipeline Vivalink operates, inside an application a customer built, used by a clinician the customer's own customer employs. When a cardiac event goes undetected, fault could originate in the sensor, in data transmission, in the algorithm, in the integrating application's alert logic, or in clinical response, and nothing published describes how responsibility divides at any of those boundaries.

The absent detection performance compounds it, since no sensitivity figure exists for any algorithm and therefore no party in that chain can characterise the residual risk it is accepting.

Availability is unaddressed despite continuous monitoring and live trial data collection both depending on it, and a research customer additionally faces data loss as a study integrity problem rather than only a clinical one.

One pre emptive note: further certifications or customer counts cannot move this grade. Only contractual terms, or published detection and availability performance, will.

Ask what is warranted beyond hardware, the availability commitment, and how liability divides between platform and integrator.

Integration is the product rather than a feature, described concretely, with no named system or standard.

The capability set is substantive and specific. Standardised, integration ready data formats are offered for ingestion into existing clinical, research and analytics platforms, with integrated formatting and transformation described as a platform function. A development kit supports mobile and cloud integration, machine to machine web services permit direct application access, retrospective data file download supports analysis pipelines, and multi endpoint multi site data consolidation is offered with end to end integrity checks. Third party devices from established manufacturers are ingested alongside the company's own sensors, so the platform absorbs as well as emits.

That combination reflects a company whose commercial existence depends on being easy to integrate, and the disclosure is correspondingly practical rather than aspirational.

What is missing is naming. No electronic health record is identified, no interface standard such as HL7 or FHIR is described, and no marketplace or validated integration listing was located. Standardised format is asserted without saying which standard, and for a clinical trial customer the relevant question is whether output maps to research data standards, which is equally unstated.

Graded B because integration breadth and mechanism are genuinely described and demonstrated through third party device ingestion, and held there because a buyer cannot confirm compatibility with any named system.

Ask which standards the output formats conform to, and which record and research systems are integrated in production.

Three deployment modes are described, including one that keeps data inside the customer's environment.

The architecture is disclosed as an edge to cloud design and the options are genuinely distinct. Cloud web services support direct machine to machine integration for applications hosted remotely. Development kit enabled routers support server based multi patient monitoring on premise, which allows consolidation and processing within a facility. Retrospective data file download supports pipelines that need neither live streaming nor a hosted service. Multi endpoint, multi site consolidation is offered with end to end integrity checks.

The on premise option matters more than the others and is rare in this segment. A hospital or a research site with data location obligations can run monitoring without every physiological stream traversing a vendor cloud, and the international footprint makes that valuable rather than theoretical, since clearance spans the United States, Europe and China and reach is claimed across 116 countries with correspondingly varied localisation rules.

What is absent is the hosted side. No cloud or infrastructure provider is named, no region is stated, no residency commitment is made, no tenancy model is described for a platform serving hundreds of customers, and no continuity position was located.

Nothing states whether the on premise mode eliminates cloud dependency entirely or still requires it for management and updates, which is the question that determines whether it satisfies a strict residency requirement.

Ask which provider hosts the cloud service and where, whether on premise deployment is fully independent, and how tenants are segregated.

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, with every route terminating in a contact form.

The omission is more surprising here than for most vendors because the customer is a developer. The company sells a development kit and a data platform to organisations building their own products, and that audience must model cost of goods before committing engineering effort. Competing developer facing infrastructure in adjacent categories routinely publishes per unit rates precisely because the buyer cannot start without one.

The unit is also inferable in principle and never stated. Reusable sensors are hardware with a purchase or lease cost and a replacement cycle, adhesives are consumable, the data platform is a recurring service, and the development kit may be licensed separately. A customer deploying a thousand patients faces very different economics under per sensor, per patient, per data volume or per seat pricing, and nothing indicates which applies.

The two markets served compound it, since a clinical trial sponsor running a fixed duration study of 3,000 subjects and a hospital at home programme running continuously have opposite consumption profiles.

One fragment of commercial disclosure does exist. A published product warranty indicates hardware terms are documented somewhere, which is more than most vendors here provide.

Ask for the unit of charge, sensor purchase against lease, platform licensing basis, and how trial and clinical deployments price differently.

Broad by geography, by parameter and by use case, with depth per setting unevidenced.

Geographic reach is the strongest element and is backed by regulatory rather than commercial evidence. Sensors hold clearance in the United States, the European Union and China, which is an unusual combination in this index and represents three distinct regulatory regimes with different requirements. Brand reach is claimed across 116 countries with more than 400 customers.

Parameter coverage is wide for a sensor company: continuous electrocardiography with heart rate variability, temperature, oxygen saturation, blood pressure, respiratory rate and activity from its own devices, extended by third party glucose and sleep monitors ingested through the platform.

Use cases span ambulatory cardiac monitoring, hospital at home, general remote patient monitoring, telehealth and decentralised clinical trials. That last one is a genuinely different buyer with different requirements around data integrity and audit, and the company addresses it explicitly rather than treating research as an afterthought.

What is not evidenced is depth. Nothing states how the customer base divides between clinical care and research, which parameters carry real deployment volume, or how many customers operate at scale rather than in evaluation. A platform sold to developers will have a long tail of small integrations, and no material distinguishes those from substantial deployments.

Ask for the split between clinical and research customers, and how many deployments exceed a meaningful patient volume.