1upHealth vs Zus Health

1upHealth

Self-serve Dev Portal sandbox clients and a demo health plan let an app test the CMS Patient Access, Provider Access and Payer-to-Payer FHIR APIs, backed by HITRUST and SOC 2 Type 2. No rate limits, error formats or dated releases are documented, and the Patient Access OAuth step needs the member in a browser.

Zus Health

FHIR R4 over an aggregated patient profile drawn from CommonWell, Carequality, Surescripts, Quest and ADT networks, with published rate limits, a 99.5 per cent SLA and a dated changelog. Accounts and sandboxes are provisioned by Zus on request, with no public prices, no named security certification and no SDK.

1upHealth

1. Hand the Patient Access sign-in to the member, who must authorise in the health plan's auth app
2. Exchange the authorisation code within five minutes, and refresh before the 15-minute token expires
3. Email payer-patient-access@1up.health with the client ID to get the app synced to the demo environment
4. Expect only claims and coverage resources from some payers, and read /r4/metadata first

Zus Health

1. Cache the access token for its hour. More than 200 token requests an hour per App Client returns 429
2. Request Patient History at most once per patient per 24 hours, and poll the job status endpoint
3. Use conditional create by identifier so a retried write doesn't duplicate a resource
4. Send Zus-If-Match with the resource's ETag on PUT and PATCH
5. Set _count up to 500 on searches, since the default page is 10