The 21st Century Cures Act and ONC regulations are accelerating FHIR adoption across healthcare. Here's what technology teams need to know about building FHIR-based integrations.
What is FHIR?
Fast Healthcare Interoperability Resources (FHIR, pronounced "fire") is a standard for exchanging healthcare data electronically. Think of it as a RESTful API specification designed specifically for healthcare.
Key Benefits
- Modern - RESTful APIs vs. legacy HL7 v2 messaging
- Granular - Access specific data elements, not entire documents
- Extensible - Support for custom resources and profiles
- Developer-friendly - JSON format, OAuth 2.0 auth, comprehensive documentation
FHIR Basics
Resources
FHIR defines ~150 resource types covering clinical and administrative data:
- Patient - Demographics, identifiers
- Observation - Vitals, lab results, clinical findings
- Condition - Diagnoses, problems
- MedicationRequest - Prescriptions
- Encounter - Visits, admissions
API Operations
Standard RESTful patterns:
GET /Patient/123- Read specific patientGET /Observation?patient=123&category=vital-signs- Search observationsPOST /Condition- Create new conditionPUT /Patient/123- Update patient
Implementation Guide
1. Choose Your FHIR Version
- R4 (4.0.1) - Current mainstream version, widely adopted
- R5 - Latest version, limited adoption
- DSTU2 - Legacy, being phased out
Recommendation: Use R4 unless integrating with systems locked on DSTU2.
2. Understand US Core
US Core Implementation Guide defines constraints on base FHIR for US healthcare:
- Required data elements
- Must-support fields
- Search parameters
- Terminology bindings (SNOMED, LOINC, RxNorm)
3. Implement SMART on FHIR
SMART on FHIR extends OAuth 2.0 for healthcare apps:
1. App registration with EHR
2. User launches app (EHR or standalone)
3. Authorization request with scopes (patient/*.read)
4. User consent
5. Access token with patient context
6. FHIR API calls with token
4. Handle Pagination
Most FHIR servers limit response size. Use pagination links:
{
"resourceType": "Bundle",
"link": [
{ "relation": "next", "url": "https://fhir.example.com/Observation?_page=2" }
],
"entry": [...]
}
5. Error Handling
FHIR uses OperationOutcome for errors:
{
"resourceType": "OperationOutcome",
"issue": [{
"severity": "error",
"code": "not-found",
"diagnostics": "Resource Patient/999 not found"
}]
}
Real-World Integration
For a digital health client, we built a patient engagement platform integrating with Epic via FHIR:
Requirements:
- Pull patient demographics, vitals, and lab results
- Display medication list
- Write patient-reported outcomes back to EHR
Implementation:
- SMART on FHIR app registration
- OAuth 2.0 authorization flow
- US Core conformance
- Sync every 15 minutes with incremental updates
Challenges:
- Identifier matching - Multiple patient identifier systems
- Data quality - Missing or inconsistent data
- Rate limiting - EHR API throttling
- Testing - Synthetic data for development
Results:
- 50K+ patients using platform
- Real-time vitals display in patient portal
- Reduced duplicate data entry for care teams
- SOC 2 Type II compliant architecture
Testing Tools
- HAPI FHIR Server - Open-source FHIR server for testing
- Synthea - Synthetic patient data generator
- Inferno - Automated testing tool for FHIR conformance
- Postman Collections - Pre-built FHIR API tests
Common Pitfalls
- Assuming complete data - FHIR resources may have minimal required fields
- Ignoring profiles - US Core and other IGs add constraints
- Poor error handling - Network issues, timeouts, and data quality problems
- Security shortcuts - HIPAA applies to all PHI access
Resources
Conclusion
FHIR is becoming the standard for healthcare interoperability. Understanding its principles, resources, and implementation patterns is essential for healthcare technology teams. Start with US Core and SMART on FHIR - they're becoming mandatory for many use cases.