FHIR integration succeeds based on seven design decisions made in the first month. Getting these wrong forces re-work.
1. Integration surface: REST, Bulk, or both. REST for point-of-care; Bulk for analytics. Most deployments need both.
2. Auth model: SMART launch, Backend Services, or custom. SMART covers most cases. Custom auth adds maintenance cost.
3. Terminology scope: US Core baseline or expanded. US Core is the floor. Da Vinci profiles extend for payer/provider workflows.
4. Versioning: R4, R4B, or R5. US Core references R4; new deployments should support R4B backport of SubscriptionTopic.
5. Data model: FHIR-native or FHIR-tolerant. Native uses FHIR as internal model. Tolerant maintains proprietary + facade.
**6. Conformance testing: Inferno in CI or manual.** In-CI catches regressions.
7. Terminology infrastructure: bundled, standalone, or managed. Bundled simpler; standalone more capable.
Rework cost when wrong
| Decision | Cost |
|---|---|
| Integration surface | 3-6 months |
| Auth model | 4-8 months |
| Terminology scope | 2-4 months |
| Versioning | 6-12 months |
| Data model | 12-24 months |
| Conformance | Slow trickle |
| Terminology infra | 3-6 months |
Common decision mistakes
1. Choosing REST-only without bulk plan. 2. Custom auth vs. SMART. 3. US Core skipped for custom profiles. 4. R5 chosen prematurely. 5. Manual conformance testing.
Seven decisions in month one shape the next three years. Invest the time upfront.
