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.

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.

No SOC 2, ISO 27001, HITRUST or other attestation was located, and no trust centre, security page or status page was found on any retrieved surface. Not Rated reflects absent retrieval rather than an assessed weakness. The scale of the estate makes this the first thing to request: a platform holding a normalised longitudinal record across more than 320 million patients and sharing it across tenants should be able to produce a current attestation and its scope.

No FDA clearance, device authorisation or regulatory pathway statement was located, and the absence is expected for data infrastructure rather than notable. The regulatory surface that does matter here sits elsewhere and is worth asking about instead: information blocking rules, TEFCA participation obligations as that connection is completed, and the state privacy regimes that increasingly govern aggregation and secondary use of health data across jurisdictions.

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.

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. Not Rated is the house convention for absent pricing rather than a low grade. Pricing for this kind of platform commonly varies by patient volume, by subscription to ongoing updates and by consumption route, and those can behave very differently, so establish the unit before comparing it to anything else.

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.