HeartSciences

This grade reflects a distinction the company's marketing does not make. What a facility can buy today is an ECG reporting and management platform, and the AI available through it is a third party algorithm from Bunkerhill Health, separately indexed here. HeartSciences' own AI-ECG algorithms, impaired cardiac relaxation and low ejection fraction, are not cleared and not commercially available. A buyer purchasing MyoVista Insights in 2026 is buying ECG workflow software plus access to someone else's cleared model.

The company is a delivery layer rather than a decision maker, and it is precise about that.

What is commercially available is an electrocardiogram reporting and management platform plus a marketplace that surfaces third party algorithm results inside it. The first algorithm available is a cleared model detecting reduced left ventricular ejection fraction from a routine twelve lead recording. The clinical determination belongs to the clinician reading the study, and the algorithm is assistive by its own cleared indication. Nothing here acts autonomously on a patient.

The company's precision about its own position is creditable and unusual. It states plainly that its own algorithms are not cleared and are not available, rather than blurring pipeline into product. Records elsewhere in this index have been graded down for exactly that blurring.

Held at B because the platform's own role in the loop is undescribed. A marketplace sits between an algorithm and a clinician and makes choices about how a result is presented, whether uncertainty or confidence is shown, whether a result is displayed as a flag or a number, and what happens when a developer withdraws or updates a model mid deployment. Those presentation choices shape how a clinician weighs the output, and none of them is published.

Ask how algorithm results are rendered, and what a site is told when a listed model changes version.

On a marketplace, model transparency stops being a question about the vendor's models and becomes a question about its listing standard. Neither is answered.

The company's own algorithms are not available. Its impaired cardiac relaxation model was deliberately held out of the device submission to complete further validation against revised echocardiography guidance, and its low ejection fraction model remains in pre submission work. Separating an unvalidated algorithm out of a submission rather than pushing it through is good practice and the record credits it elsewhere.

That leaves the marketplace, and this is the substantive gap. When a platform distributes other companies' models into clinical workflow, the transparency a buyer receives is whatever the platform requires before listing. Nothing published describes listing criteria: what evidence a developer must supply, whether clearance is a condition or merely the case so far, whether performance data is surfaced to the buying institution, whether independent validation is required, or what obligates a developer to disclose a model update.

The platform itself is described only at concept level: cloud native, device agnostic, centralised data management.

Ask what the listing standard is, and what performance evidence accompanies each algorithm at the point of purchase.

The platform holds cardiac studies with patient identity attached, which is protected information in full, and nothing describes what happens to it. Securities filings describe centralised data management and assert that the architecture supports data governance, which is a positioning claim rather than a stewardship commitment, and the distinction matters because the sentence reads like an answer.

Nothing was retrieved on retention periods for studies or derived results, de identification, whether customer data is used for model development, or what is returned or deleted at termination. The training question is live rather than theoretical, because the company has algorithms in its own development pipeline, so a platform accumulating cardiac studies while building its own models has an obvious interest in that corpus and nothing states whether customer data is available to it for that purpose.

The marketplace raises the sharper question. Surfacing a third party algorithm's result inside the platform means a patient study, or something derived from it, reaches an organisation the ordering institution did not select and may never have assessed, and whether the recording is transmitted to the developer, processed within the platform, or handled some other way, and what terms bind that party, is not described anywhere public. Ask where the recording goes when an algorithm runs, who else holds it, and for a sub processor list covering every listed developer.

Thin, and the company is candid about the stage. The platform has been in phased rollout since May 2025 at early adopter reference sites, with the company describing itself as engaged in commercial discussions and expecting to announce initial customer deployments as they progress. No named customer, deployment count, or outcome data was retrieved. A multi center clinical study supporting the impaired cardiac relaxation algorithm has completed recruitment but supports a product that is not yet available.

A cloud repository of cardiac studies, and the marketplace adds a data flow nobody describes.

The platform holds electrocardiogram data with patient identity attached, which is protected health information in full. Securities filings describe centralised data management and assert that the architecture supports data governance, which is a positioning claim rather than a stewardship commitment.

Nothing was retrieved on retention periods for studies or derived results, de identification, whether customer data is used for model development, or what is returned or deleted at termination. The company has algorithms in its own pipeline, which makes the training use question live rather than theoretical: a platform accumulating cardiac studies while developing its own models has an obvious interest in that corpus, and nothing published states whether customer data is available to it for that purpose.

The marketplace raises the sharper question. Surfacing a third party algorithm's result inside the platform means a patient study, or something derived from it, reaches an organisation the ordering institution did not select and may not have assessed. Whether the recording is transmitted to the developer, processed within the platform, or handled some other way, and what contractual terms bind that party, is not described anywhere public.

Ask where the recording goes when an algorithm runs, and who else holds it.

No published position was located across two differently phrased searches.

No business associate agreement, addendum, role statement, subcontractor flow down, breach notification timetable or review cadence was retrieved.

The role is straightforward on the face of it. The health system or practice is the covered entity, and a platform holding and managing its electrocardiogram data is a business associate with direct liability.

The marketplace complicates the chain in a way a buyer should resolve explicitly rather than assume. Where a third party algorithm operates on a patient study, that developer is handling protected health information too. The instrument governing it might be a subcontract flowing down from the platform's own agreement, or a direct agreement between the institution and the developer, and those allocate responsibility very differently. If a listed developer suffers a breach, which party notifies the institution, and on what timetable, follows entirely from that structure.

Nothing published indicates which model applies, and the marketplace is described as a route for developers who do not want to build their own distribution, which suggests the platform intends to sit in the middle of that relationship rather than beside it.

Ask who contracts with the algorithm developer, and for the flow down terms in writing.

The security claim is inherited from the cloud provider, which is a pattern this index has recorded before and does not credit.

The published position is that the platform is built on a secure and modern Amazon Web Services technology stack meeting the highest data security and compliance standards. That describes the infrastructure provider's certifications, not the company's own. Amazon holding attestations says nothing about how this vendor configures its environment, manages access, handles secrets, tests its code, or responds to an incident. This index has logged the same shape previously, where a vendor cited its cloud providers' attestations in place of its own, and named it as a form of certification non transfer.

No SOC 2 report of either type, no HITRUST, no ISO 27001, no trust centre, no penetration testing statement and no vulnerability management description was retrieved for the company itself.

Securities filings treat cybersecurity as a market positioning argument, contending that cloud architecture supports better security than the on premise systems the platform aims to replace. That may well be true and it is an argument rather than an attestation.

The listing does provide one thing a private peer would not offer: an annual report obliged to describe cybersecurity risk management. Read that rather than the marketing.

Ask what independent assessment the company itself has undergone.

The status is genuinely mixed and the company reports it clearly, which is to its credit even though the grade is low. Cleared and available: none of its own. The Bunkerhill ECG-EF algorithm distributed through the marketplace is FDA cleared, but that clearance belongs to Bunkerhill. Submitted, not cleared: the MyoVista wavECG device, filed for 510(k) in December 2025.

In development: the impaired cardiac relaxation algorithm, deliberately pulled from that submission to revalidate against revised American Society of Echocardiography guidelines on diastolic dysfunction, and the low ejection fraction algorithm still in pre submission. Separating device and algorithm submissions is sound regulatory strategy and the company explains why. Under this index's product maturity rule, none of the company's own algorithms qualify as shipping capability.

No governance framework, bias testing statement, monitoring commitment or model update policy was retrieved, and the marketplace structure makes the omission consequential rather than routine.

Electrocardiogram interpretation is a well documented place for subgroup variation. Waveform morphology differs systematically by sex, and reference ranges that were derived predominantly from one population perform differently in others. Body habitus affects signal quality. An algorithm inferring a structural cardiac finding from surface electrical activity is exactly the kind of model where performance can vary across groups without that being visible in an aggregate accuracy figure.

The governance question here is therefore not only what the platform does with its own models, of which none are commercially available, but what it requires of the models it distributes. A marketplace that lists an algorithm is making it available to community hospitals, critical access hospitals and primary care practices that have no capacity to evaluate subgroup performance independently. Whether the platform obliges developers to publish it, surfaces it to the buyer, or monitors real world performance after listing is unaddressed.

Ask whether subgroup performance is a listing requirement, and what post deployment monitoring exists across sites.

One act of restraint deserves credit before the gap. The company's impaired cardiac relaxation model was deliberately held out of its device submission to complete further validation against revised echocardiography guidance, and a further model remains in pre submission work.

Separating an under validated algorithm out of a submission rather than pushing it through is good practice and it costs a company time and revenue, so it is evidence about how the organisation behaves when the two conflict. The gap is the marketplace.

When a platform distributes other companies' models into clinical workflow, the transparency a buyer receives is whatever the platform requires before listing, so the listing standard becomes the vendor's own disclosure obligation rather than a matter for each developer.

Nothing published describes it: what evidence a developer must supply, whether clearance is a condition of listing or merely the case so far, whether performance data is surfaced to the buying institution at the point of purchase, whether independent validation is required, or what obligates a developer to disclose a model update.

This index has now recorded the same absence on four separate platforms hosting third party clinical models, which makes it a structural feature of the marketplace model. The platform itself is described only at concept level. Ask what the listing standard is, and what performance evidence accompanies each algorithm when an institution buys it.

Interoperability is the product thesis rather than a feature, and there is third party evidence behind it.

The company's own filings frame the opportunity in these terms: existing electrocardiogram management systems rely on on premise or proprietary architectures that are difficult to integrate and maintain, and the platform is positioned as the interoperable alternative with centralised data management. That is a coherent argument rather than a claim, and the device agnostic ingestion supports it, since studies from any manufacturer's equipment enter the same system.

The external validation is Epic Toolbox designation, which is granted to products meeting the record vendor's recommended integration practices. That is a review passed rather than an integration asserted, and it is the same standard credited elsewhere in this index.

Held at B rather than A on specificity. No interface standard is named, no conformance documentation is published, no supported version list exists, and no data export path is described. One record system is evidenced; what happens at a site running something else is not stated. For a platform selling to community hospitals, critical access hospitals and primary care practices, the record systems in that segment are varied and mostly unaddressed here.

Ask which record systems beyond the one named are supported today, whether results return as discrete data or as documents, and what the export path is.

Cloud only, with the provider named and nothing else about location.

The architecture is described consistently in the company's own filings: a cloud native, device agnostic platform delivered as software as a service, positioned deliberately against the on premise and proprietary electrocardiogram management systems it aims to displace. Amazon Web Services is named as the underlying infrastructure.

Device agnosticism is the substantive point and it deserves credit. Electrocardiogram estates are typically multi vendor and accumulate over years, and a management platform that ingests from any manufacturer's carts removes the usual constraint that the software must match the hardware. For a critical access hospital running mixed equipment, that is the difference between adoption being possible and not.

What is absent is everything a residency review asks for. No region, no statement of whether processing remains in country, no tenancy model, no indication of whether customer data is logically or physically separated, no subprocessor list, and no backup or recovery posture. Naming a cloud provider is not a residency answer.

Cloud only also means there is no configuration in which studies remain inside the institution, which is a straightforward consequence of the model rather than a criticism, and should be understood before adoption.

Ask for the region, the tenancy model and the subprocessor list.

Better than most in this index on structure, which matters more than a rate card here. The marketplace is described as a recurring SaaS model, positioned as a commercial route for AI-ECG developers to reach clinical users without building their own distribution. The company also states the reimbursement pathway explicitly: assistive AI-ECG assessments are eligible under the Hospital Outpatient Prospective Payment System at APC 5734. Naming the payment classification lets a buyer model revenue offset directly, which very few vendors here enable. Held back from A because no price is published.

Tightly bounded to cardiology and specifically to the 12-lead resting ECG, with a deliberate emphasis on reach: the marketplace is positioned to make cleared AI-ECG algorithms available to facilities of every size, from integrated health systems down to community hospitals, critical access hospitals, and primary care practices. Extending algorithm access below the large health system tier is the substantive access argument, since that is where cardiology imaging is least available.