ROOK vs Zus Health

ROOK

Graded on the REST API. A public OpenAPI file, a free Sandbox from the self-serve portal, published plan prices and a dated changelog. Credentials are one client UUID and secret per environment with no scopes, 429 handling isn't documented, the API is meant for occasional queries rather than bulk reads, and no SOC 2 report or security contact was found.

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.

ROOK

1. Send HTTP Basic auth with client_uuid as the username and the secret key as the password, plus a User-Agent header, or the WAF returns 403
2. Use https://api.rook-connect.review for Sandbox and https://api.rook-connect.com for production. Each has its own credentials
3. Read health data from the data webhook. Use the API only for occasional queries, and stay under 60 requests a minute
4. Deduplicate summaries on document_version and datetime. ROOK resends a summary with a higher document_version when it changes
5. Call POST /api/v1/user_id/{user_id}/data_sources/revoke_auth to end a connection. Some providers take hours to stop sending data

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