When health IT teams say "we need a FHIR solution," what they actually need falls into four categories. Distinguishing between them prevents solution-shopping in the wrong aisle.
Category 1: FHIR-enable a legacy system
Goal: Existing EHR/HIS/LIS exposes a FHIR API. Solutions: sidecar FHIR facade (HAPI on top of legacy), HL7v2-to-FHIR pipeline, or vendor-provided FHIR module.
Category 2: Build a FHIR-native application
Goal: New application built on FHIR from day one. Solutions: Aidbox, Medplum, HAPI FHIR JPA — pick based on stack fit.
Category 3: Consume FHIR data
Goal: Third-party app reads FHIR data (patient facing, clinician facing, analytics). Solutions: SMART on FHIR client SDKs, Bulk Data IG pipeline consumers.
Category 4: Comply with regulatory FHIR requirements
Goal: Meet CMS-0057, ONC certification requirements. Solutions: Purpose-built compliance platforms, Inferno conformance testing, Da Vinci IG implementations.
Category confusion pitfalls
| Wrong assumption | Reality |
|---|---|
| "We need a FHIR server" | Category unclear — 1, 2, 3, or 4? |
| "We need FHIR compliance" | Category 4 typically |
| "We need to integrate systems" | Category 1 with FHIR + potentially engines |
| "We're building a new app" | Category 2 |
Time-to-value by category
| Category | Typical timeline |
|---|---|
| FHIR-enable legacy | 3-9 months |
| Build FHIR-native | 6-18 months |
| Consume FHIR data | 1-3 months |
| Regulatory compliance | 6-24 months |
FHIR "solutions" cover a broad problem space. Categorize the actual need, then pick a solution in that category.