Aidbox vs Zus Health

Aidbox

Graded on the FHIR REST API of an Aidbox instance the owner runs. Monthly releases, two-year LTS lines, SMART on FHIR, AccessPolicy rules and AuditEvent logging are documented, and a free development licence needs no sales call. Aidbox has no rate limiting of its own, its MCP module is alpha, and no terms of service were found on the website.

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.

Aidbox

1. Ask the operator for a Client with an AccessPolicy limited to the task. Don't rely on the public MCP policy, which the docs mark unsafe
2. Use If-None-Exist on creates and conditional update on identifiers so retries don't duplicate records
3. Use _elements and _count to keep responses small, and follow the Bundle's paging links
4. Throttle yourself. Aidbox applies no rate limit, so a burst lands on the customer's database
5. Don't load real patient data into an instance on a development licence

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