Designing an EMR from FHIR-first principles isn't just "use FHIR instead of proprietary formats." Five patterns cover the design decisions that separate FHIR-native from FHIR-tolerant.
Pattern 1: FHIR as internal data model. Resources like Patient, Encounter, Observation used internally, not just as export format. Application queries directly against FHIR store.
Pattern 2: Terminology-first coded fields. Every coded field bound to a FHIR ValueSet. No free-text coded values; validation at write.
Pattern 3: SMART on FHIR as the app platform. Third-party apps integrate via SMART launch; no proprietary API surface.
Pattern 4: Bundle transactions for related writes. Related resources (visit + encounter + observation) written as one Bundle transaction. Atomicity by design.
Pattern 5: Subscription-driven events. Internal event flow uses FHIR Subscription rather than custom event bus. Same infrastructure serves external subscribers.
Anti-patterns
| Anti-pattern | Issue |
|---|---|
| Proprietary internal + FHIR facade | Duplication cost |
| Free-text coded fields | Terminology drift |
| Custom API + SMART export | Ecosystem fragmentation |
| Individual REST writes | Race conditions |
| Custom event bus | Not reusable |
Real-world FHIR-native EMRs
Medplum is the most public FHIR-native EMR platform in 2026. Aidbox supports building on top of a FHIR-native backend. Both demonstrate the pattern.
FHIR-native EMR design is a specific choice. Not all EMRs need it — retrofits to proprietary systems can work. But greenfield builds should embrace FHIR internally, not just at the export boundary.