1upHealth vs Aidbox

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.

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.

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

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