Zus Health

Learned components sit inside a product whose value is the network and the record it assembles. The Generated Patient Summary is a language model summary of the aggregated profile, and identity matching across sources runs through a proprietary universal patient index; terminology crosswalks and clinical logic that orders data by relevance are described as rules.

What a customer buys is access to national networks, pharmacy, admission and lab feeds, a deduplicated FHIR record and the APIs, embedded views and data marts that deliver it. Remove the summary and the product is what it was sold as before GPS was released in beta, and the summary is now offered free to existing customers.

The summary is sold as not missing things while the company's own guidance says it can. A post in Zus's blog describes the Generated Patient Summary as "a smart, AI-powered medical scribe that never misses the big picture", while the GPS release note says the summary "may not capture all relevant details" and that clinicians should validate it against source documentation.

An absolute promise against omission outweighs whatever review mechanism sits beside it, and limiting it to the big picture narrows it to what matters most rather than softening it. The company's real control is the citation on every clinical statement, which opens the source: it lets a clinician check what the summary says, not find what it left out. The product pages' "you will never miss a beat" is addressed to the care team rather than said of the summary. The risk adjustment add-on carries its own scope: its documentation says scores rest on clinical data alone and may be inaccurate, and the service is in public preview.

The summarization approach is documented, and the model is not named. The clinical guide describes the Generated Patient Summary as an AI-backed summary of the aggregated profile, drawing on structured conditions, medications, allergies, immunizations, labs, social and family history, diagnostics and vitals, and on unstructured visit notes, encounter summaries and continuity of care documents; it is regenerated when new data arrives or after five days, is the same for every viewer in between, and cites the source for every clinical statement.

The platform page describes a proprietary universal patient index for identity matching, terminology crosswalks and clinical logic that orders data by relevance. GPS is labeled beta. No model, supplier, version or accuracy measure is published for the summary or the matching.

Data sources are named and the model and hosting providers are not. The documentation names CommonWell and Carequality as networks the platform queries and shares data back to, and the profile page describes pharmacy fill data from 99 percent of U.S. pharmacies, national admission and discharge feeds and lab relationships covering half of U.S. hospitals and physicians. Data contributed by one organization becomes visible to others treating the same patient. No model provider is named for the Generated Patient Summary, no hosting provider is named, and no subprocessor list is published.

Named customers and pilot figures, with the counts missing. Customer stories name Tennessee Oncology, Firsthand, Pair Team (doubled discharge detection) and Author Health (a 17-fold increase in scheduling). The October 2025 risk adjustment release reports pilots at three value-based care organizations, one named (Homeward Health), on Medicare Advantage populations: previously undetected HCC suspects in 72.5 percent of patients reviewed, 1.3 new high-confidence suspect codes per patient, up to $2,070 per patient in newly recognized complexity, and 93 percent of high-confidence suspects and recapture opportunities accepted by expert risk coders.

The denominators are patients reviewed and suggestions made, but neither count is given, the three pilots are pooled with no period, and coder acceptance measures agreement with coders, not whether the codes survive a risk adjustment audit. The home page says the profile prevents hospital stays and acute events, with nothing published behind it.

Access to shared data is tightly defined; what happens to data once it reaches a model is not. The documentation and the patient data privacy policy (March 2025) confine access to treatment, payment, operations and public health purposes: a customer asserts an active relationship with each patient, Zus treats that assertion as evidence, sales and legal teams review each customer's use case, and network partners require reciprocity and a treating provider's identifier.

Those are access controls. Nothing published states how long assembled profiles, contributed data or generated summaries are retained, whether patient data is used to train or improve the matching or summary models, or what is de-identified and by what standard. At stake is a national view of patient identities and histories held by one private company.

HIPAA status is stated and backed by a service privacy document, with the agreement unpublished. The platform page describes a HIPAA-compliant data store, and a patient data privacy policy (last updated March 2025), incorporated into the Builder Terms of Service, sets out the conditions for access to patient data on the platform using HIPAA's definitions, confining it to treatment, payment, operations and public health activities.

The documentation adds that customers must agree to the Builder Terms and have their use case reviewed by Zus's sales and legal teams. No business associate agreement is published. The architecture creates a multi-party question a single agreement does not answer: data contributed by one covered entity becomes visible to another treating the same patient, and to requesters on national networks.

The company presents a SOC 2 Type 2 attestation as its own. The platform page says Zus is SOC 2 Type 2 compliant and that all products are built on a HIPAA-compliant FHIR-native data store with detailed provenance, and a company news item announces HITRUST r2 certification. No report period, auditor, certification date or scope is published, and the site links no trust center or security page. Cross tenant sharing is the design property that matters most here, since the control that separates one customer's view from another's is doing more work than in a single tenant product.

No FDA position is stated, and the platform assembles and presents records rather than recommending treatment. The Generated Patient Summary is described as for informational purposes only, telling clinicians to validate it against source documentation, with a citation on every clinical statement; that is support to a clinician whose basis can be checked.

The risk adjustment add-on suggests suspected diagnosis codes linked to the supporting clinical evidence for a coder or clinician to confirm, which is suspecting with its basis shown rather than a diagnosis made. Answering to the rules that govern record exchange is not a regulatory pathway.

Those rules are real: information blocking provisions, national exchange participation requirements, state laws on aggregation and secondary use of health data, and for risk adjustment, Medicare Advantage audit exposure on submitted codes. The home page also says the profile prevents hospital stays and acute events, an outcome claim with no evidence published behind it.

No governance framework, evaluation or subgroup result is published for the matching or the summary. The exposure sits in identity matching: joining records across organizations depends on name, date of birth and address, and failure falls unevenly, more often for people with common surnames, changed names, unstable housing or frequent moves, and naming conventions record systems handle poorly.

Several named customers serve exactly those groups, including Medicaid members with serious mental illness. A missed match leaves a care team with an incomplete history it may take as complete; a false match joins another person's data to the record, and the summary then presents it as the patient's history.

Mechanisms exist to check an output, and nothing published stands behind one. Every clinical statement in the Generated Patient Summary carries a citation that opens the source record, and the data store keeps detailed provenance showing which network or organization contributed each element. The summary is described as informational, possibly incomplete and to be validated by the clinician.

No warranty, accuracy commitment or remediation is published on the site or in the documentation; any customer commitment would sit in the Builder Terms of Service. Two harms fall outside the customer: a patient whose record has another person's data joined to it through a false identity match, and a patient whose summary omitted something a clinician relied on.

Named integration with record systems and national networks, documented publicly and in production. The Zus Aggregated Profile is available inside athenahealth, Elation Health, Canvas Medical and Healthie, each with its own integration page and clinical guide entry, and through a standalone app, embeddable components, REST and GraphQL APIs, webhooks and analytics data marts.

The documentation describes querying CommonWell and Carequality and sharing a customer's contributed data back to those networks, which makes the exchange bidirectional; public API documentation and a sandbox let anyone inspect it before contracting. Named customers, including Tennessee Oncology, Pair Team and Author Health, use it in production. Breadth remains open. The site does not describe support beyond those four record systems or say whether the record vendors back the write path into them.

Nothing is published about where the platform runs or where data rests. The platform page describes a multi-tenant, FHIR-native data store built for cross-tenant sharing, which fixes the delivery model: a customer-hosted option would defeat the design. But no hosting provider, region, residency commitment or tenancy separation model is stated on the home, profile or platform pages, in the patient data privacy policy or in the documentation read. For a store holding longitudinal records assembled from national networks and shared across organizations, the separation between tenants carries most of the weight.

No price is published. The product is sold through contact, with a public sandbox for developers, and the documentation describes data subscription packages that patients are enrolled in and one-time queries; the release note for the Generated Patient Summary says it is free for existing customers. The pricing unit is not stated, and it could be per enrolled patient, per query, per data package or a platform fee. A per patient subscription on a large panel behaves nothing like per query retrieval, and nothing says whether pharmacy, admission and lab feeds are priced as separate packages.

Coverage is named, with validation behind part of it. The platform serves care teams through its app and embedded views, population health analysts through data marts, and developers through APIs and webhooks, for new-patient intake without an intake form, visit preparation, medication adherence alerts, admission and discharge detection and population health.

Named customer stories validate several of these in specific settings: oncology new-patient preparation (Tennessee Oncology), Medicaid serious mental illness care (Firsthand), complex high-need primary care (Pair Team) and behavioral health scheduling (Author Health). The record also sits on the value-based care page because Zus sells HCC suspecting and risk adjustment factor scoring as a risk adjustment add-on to value-based care organizations for their Medicare Advantage populations. No specialty-specific behavior of the summary is described.