Zus Health

The grade describes the mechanism, not the quality, and on this index a C here is a factual statement rather than a criticism. Zus does real algorithmic work: probabilistic identity resolution across a national patient index, deduplication, terminology normalisation and, since 2025, LLM summarisation in GPS. But the asset a customer is buying is the network and the record it produces.

The company's own differentiator is stated as being the only FHIR server purpose built for secure cross tenant data sharing, and its headline numbers are coverage of more than 320 million patients and a patient matching success rate. Both are properties of the data estate. Remove the summarisation layer and the product remains substantially what it was and what it was sold as before GPS existed. This is the moat is the dataset pattern this index applies to curated networks and exchanges rather than to model owners.

Verification is built in at the point where it matters. Every summarised point in GPS links directly to the underlying record, described by the company as foundational to trust, and the platform carries detailed provenance at the data layer so a clinician can establish where any element came from and which source contributed it. Access is separately gated on an asserted treatment relationship.

Held at B because no confidence signal, threshold, abstention behaviour or error rate is published for either the summarisation or the matching. One specific gap deserves naming and it is the sharpest question on this record. A roughly 90 percent match rate describes matches that succeed. The dangerous failure is not the miss, it is the FALSE match, where data belonging to a different person is joined to a patient's profile and then summarised as their history.

Nothing published addresses false match rate, detection or remediation. This is the co mingled record problem that Wisedocs solves explicitly for claims files, and it applies with more force here because the record is used to treat.

Better quantified than most on the data layer and silent on the model layer. Two figures are published and one of them deserves credit: a roughly 90 percent success rate for matching a patient to data is an explicit admission that around one in ten attempts does not succeed, and most master patient index vendors publish nothing of the kind.

The second, detecting 33 percent more admissions and discharges than prior vendors, is a comparative claim with the comparators unnamed and the measurement method unstated. Against that, nothing at all is published about the summarisation: no model or model family named, no accuracy or omission measure for GPS, no evaluation methodology.

Provenance is a genuine platform feature and every summarised point links to its source record, which is an output level transparency property, but it tells a reader where a statement came from rather than how often the summary is wrong.

The consent architecture is described in more detail than almost anything else in this index and the design is the right one. Access to third party data is gated on the customer asserting an active treatment relationship for treatment, payment and operations purposes, and where that assertion is absent or false the organisation can still see its own contributed data but not data contributed by third party networks or by other covered entities on the platform.

That is an access control tied to an actual legal basis rather than to a role, which is the correct construction and a rare one: most systems grant access by job title and assume the basis, where this one asks for the basis and scopes the view to it. Two things hold it below the top grade.

The control rests on customer self attestation, which the vendor treats as evidence of the relationship and cannot independently verify, so its strength is the customer's compliance posture rather than the platform's, and a design that is right in principle can still be defeated by an attestation nobody checks. And no retention period, no statement on whether customer or network data trains or improves models, and no de identification posture was located.

The concentration is worth stating plainly rather than as a criticism: the platform is explicitly building toward a cohesive national view of patient identities and medical histories, which is a large and unusual estate for a private company to hold. Ask how attestations are audited, and for retention and the training position.

Scale asserted without a published measure of benefit, which this index grades C. Coverage of more than 320 million patients and connections to the major national networks establish reach, not outcome. No named customer was located on any retrieved surface, no case study with quantified results, and the GPS adopters are described only as early adopters.

One caution for anyone reading the documentation: Celery Health appears there as an illustrative example inside a worked scenario, not as a customer, and should not be recorded as one. The 33 percent admission detection improvement is the only comparative figure available and its baseline is unnamed.

The consent architecture is described in more detail than almost anything else in this index and it deserves credit. Access to third party data is gated on the customer asserting an active treatment relationship for treatment, payment and operations purposes, and where that assertion is absent or false the organisation can still see its own contributed data but not data contributed by third party networks or by other covered entities on the platform. That is an access control tied to an actual legal basis rather than to a role.

Two things hold this at B. The control rests on customer self attestation, which the vendor treats as evidence of the relationship and cannot independently verify, so its strength is the customer's compliance posture rather than the platform's. And no retention period, no statement on whether customer or network data is used to train or improve models, and no de identification posture was located.

The concentration is also worth stating plainly rather than as a criticism: the platform is explicitly building toward a cohesive national view of patient identities and medical histories, which is a large and unusual estate for a private company to hold.

HIPAA compliance is explicitly claimed for the underlying FHIR data store, and unusually the company articulates the legal framework it operates under rather than only asserting compliance, referencing treatment, payment and operations purposes and naming Authorized Activities in its access model. That is more legal specificity than the standard middle rung.

Held at B because no business associate agreement terms are published and nothing addresses the multi party question this architecture creates: data contributed by one covered entity becomes visible to another through the platform, so a buyer should establish the full agreement chain, not just its own contract with Zus.

A second pass again located no attestation and no trust centre, and the search returned the same generic comparison material rather than this vendor's own posture.

One structural fact makes this gap unusually determinate rather than open ended, and it is the reason to ask now rather than later. Participation in the national exchange framework this company is connecting to carries a certification obligation: networks operating under it are required to hold healthcare specific security certification. So the question is not whether this vendor should obtain an attestation as a matter of good practice. The framework it is joining requires one, and completing that connection means completing that certification.

That converts the ask from a preference into a milestone. Establish where the company is in that process, what the target date is, and what scope the certification will cover.

The scale argument from the earlier assessment stands and is what makes it matter. A platform holding a normalised longitudinal record across hundreds of millions of patients, and sharing it across tenants, has an estate where the certification question is about the whole shared substrate rather than one product boundary. Cross tenant sharing in particular is the thing an examination would look hardest at, because the control that separates one customer's view from another's is doing more work here than in a single tenant product.

One point in the company's favour is worth recording. It publishes substantive analysis of the health information regulatory regime under its own name, which demonstrates genuine literacy in the rules it operates under.

Ask for the certification status, its scope, and the tenancy separation model.

No clearance, device authorisation or pathway statement was located, and the earlier assessment was right that the absence is expected rather than notable. This is data infrastructure. It does not diagnose, recommend or generate clinical advice, so no device framework attaches and this axis should not be read as a gap.

What governs instead is a different and substantial body of regulation, and naming it is the point of this row.

Information blocking rules are the first. A company whose business is aggregating and exchanging health records operates directly inside a regime that prohibits practices likely to interfere with access, exchange or use of electronic health information, with defined exceptions a participant must be able to justify. That is a live compliance surface rather than a theoretical one for an aggregator.

The national exchange framework is the second, and it brings obligations beyond participation itself, including a healthcare specific security certification requirement for participating networks. Those obligations arrive as a package.

State privacy law is the third and the fastest moving. Regimes governing aggregation and secondary use of health data now vary materially by jurisdiction, several reach beyond the federal privacy rule, and a platform normalising records across many states is subject to the union of them rather than the intersection.

The vendor demonstrates literacy here. It publishes its own analysis of the information blocking rules and how they interact with the federal privacy rule, under named authorship, which is more engagement with the governing regime than most vendors in this index show.

Ask how the exceptions are documented, and what the position is on secondary use.

One credit and one significant unaddressed exposure. The credit is that the company publishes a matching success rate that is explicitly not 100 percent, alongside provenance and source linking, which is more candour than the norm for identity infrastructure. The exposure is what sits underneath that number.

Patient matching depends on the quality and stability of name, address and demographic data, and match failure is well documented as falling unevenly: it is more common for people with common surnames, for those who have changed names, for people with unstable housing or frequent address changes, and for naming conventions that record systems handle poorly.

A roughly 90 percent match rate with no subgroup breakdown means the roughly one in ten who do not match are not a random ten percent, and the consequence for them is a care team working from an incomplete history while believing it is complete. No fairness, subgroup or demographic performance disclosure of any kind was located, and for identity infrastructure at national scale this is the single most consequential disclosure gap on the record.

One published figure deserves credit for what it admits. A stated match success rate of roughly ninety per cent is an explicit acknowledgement that around one in ten attempts to connect a patient to their data does not succeed, and most identity resolution vendors publish nothing of the kind. A vendor that tells a buyer its own failure share has given them something to plan around, since a clinician needs to know that an empty result may mean no history rather than no match.

The second published figure is weaker: detecting a stated percentage more admissions and discharges than prior vendors is a comparative claim with the comparators unnamed and the measurement method unstated, so it cannot be reproduced or contested. Held at C because nothing at all is published about the summarisation layer.

No model or model family is named, no accuracy or omission measure exists, and no evaluation methodology was located, so the component that decides what a clinician reads is undescribed. Provenance is a genuine platform feature, since every summarised point links to its source record, and it tells a reader where a statement came from rather than how often the summary leaves something out, which for a longitudinal record is the failure that matters. No warranty, indemnity or remediation commitment was located. Ask for the omission rate on clinically significant content, and what a clinician sees when matching fails.

The deepest interoperability record reviewed in this lane and among the strongest anywhere in this index, because everything is named rather than claimed. National networks: CommonWell and Carequality with TEFCA planned, Surescripts for prescription fill data, PointClickCare and Bamboo Health for admission, discharge and transfer alerts.

Eight EHRs and platforms carry pre built integrations and all are named: Epic, athenahealth, Elation, eClinicalWorks, Salesforce Health Cloud, Healthie, Canvas and Medplum. The store is FHIR native with more than 600 FHIR resources behind a single profile, carrying provenance and a terminology service, and consumption routes cover a standalone application, an embeddable interface, REST and GraphQL APIs, webhooks for low latency push, and analysis ready tables in Snowflake, BigQuery and Databricks. Deduplication and normalisation are performed rather than left to the customer.

Hosted multi tenant cloud only, and structurally so rather than by choice: cross tenant data sharing is the central design property of the platform, so a customer hosted or on premise option is incompatible with what the product does. That is a legitimate architectural trade off and should be read as one, not as an omission.

Graded C rather than lower because the delivery model is clearly established, and not higher because no hosting region, residency commitment or data location option was located, and because a buyer has no ability to confine processing to infrastructure it controls.

No price, tier or pricing mechanism is published on any retrieved surface.

Pricing for this kind of platform commonly varies by patient volume, by subscription to ongoing updates and by consumption route, and those behave very differently as usage grows. Establish the unit before comparing this to anything else, because a per query rate and a flat platform fee produce opposite answers at different scales.

Broad by function and user type rather than by clinical specialty, which is appropriate for a data platform. Three distinct user profiles are served with different access routes: care teams through the application or an embedded view, population health and data analysts through analysis ready tables, and developers through APIs and webhooks.

Named use cases span onboarding a new patient without an intake form, medication reconciliation, visit preparation, detecting admissions and discharges as they happen, and population health and risk management. Graded B because the coverage is horizontal across care models rather than deep in any clinical specialty, and no specialty specific behaviour was located.