Aidbox vs Medplum

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.

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.

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

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