FHIR API integration in production healthcare touches five specific points. Understanding what each requires shapes both purchasing and building decisions.
Point 1: Patient-facing app integration. SMART on FHIR launched app reads Patient, Observation, Condition, MedicationRequest for patient view.
Point 2: Third-party clinical apps. SMART-launched clinical tools; read + write scopes; structured resource writes back.
Point 3: Bulk analytics pipeline. Bulk Data IG $export feeds warehouse; nightly sync typical.
**Point 4: CDS Hooks at order-time.** Point-of-care alerts and suggestions.
Point 5: Payer-provider data exchange. CMS-0057 mandated exchanges.
Integration surface characteristics
| Point | Surface | Volume |
|---|---|---|
| Patient portal | SMART REST reads | 100-1000/day |
| Third-party apps | SMART REST reads/writes | 1000-10k/day |
| Bulk analytics | $export |
1 job/night |
| CDS Hooks | REST POST from EHR | 100-10k/day |
| Payer-provider | SMART Backend + REST | 10-1000/day |
Common integration mistakes
1. Missing rate limit handling → 429 cascades. 2. Wrong scopes → 403 errors. 3. Slow terminology → user-visible delays. 4. Bulk export not incremental → nightly window blown. 5. CDS Hooks response too slow → EHR times out.
Rate limiting patterns
1. Per-token limits (typical: 60-100 req/min). 2. Per-scope limits (system > user > patient). 3. Bulk export concurrency (usually 1-3). 4. Retry with exponential backoff on 429.
Testing considerations
1. Test against sandbox with production-like scopes. 2. Test error paths explicitly. 3. Load-test at expected peak × 2. 4. Test with realistic terminology.
FHIR API integration is well-understood in 2026. The five integration points above cover essentially every production deployment.
