Medplum vs ROOK

Medplum

Graded on the hosted FHIR API at api.medplum.com. Rate limits, a RateLimit header and a 99.99 per cent SLA are published, AccessPolicy resources allow read-only clients, and an official MCP server sits in the registry. Its main tool can delete records with no annotation, the status page could not be read, and the privacy policy dates from 2022.

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.

Medplum

1. Use a ClientApplication with an AccessPolicy limited to the resources the task needs, and set readonly where no writes are needed
2. Read the RateLimit header and wait for the reset time after a 429. Writes cost 100 quota points, searches 20 and reads 1
3. Create patients with conditional create (If-None-Exist) or upsert on an identifier so a retry doesn't make a duplicate
4. Pass paths to fhir-request relative to the FHIR R4 base, with no leading slash or /fhir/R4 prefix
5. Use Prefer: respond-async for large bundles. Operations inside the background job don't count against the quota

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