1upHealth vs ROOK

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.

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.

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

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