EHR development in 2026 is not the greenfield it was five years ago. The CMS-0057-F Patient Access, Provider Access, and Payer-to-Payer APIs are live requirements; SMART on FHIR is table-stakes for third-party app support; and terminology binding to US Core is expected out of the box. The interesting work — where teams get stuck — sits below the surface, in the parts that don't fit inside a spec document.
1. HL7v2 ingestion still runs everything.
Despite the FHIR mandate, the majority of clinical data flowing into US EHRs in 2026 still enters as HL7v2 (ADT, ORM, ORU, DFT messages). The HL7v2-to-FHIR IG is the canonical mapping, but production translation ships with edge cases that the IG punts on:
- OBX segment repeats mapping to Observation.component vs. separate Observations. The IG allows both; pick one and be consistent, or downstream aggregation breaks. - PV1-3 (assigned patient location) mapping to Encounter.location. Requires a Location resource lookup; teams that skip this leave location unpopulated. - ADT^A08 update semantics. Whether an A08 replaces or patches the Patient record differs by source system; standardize your policy at the ingestion boundary.
2. Terminology binding is where compliance is won or lost.
US Core mandates specific ValueSets for many code fields — race, ethnicity, condition category, medication codes. The ValueSet definitions reference SNOMED and RxNorm code systems that require licensing (SNOMED CT via the NLM UMLS license) and periodic updates. Teams that hardcode their vocabulary get flagged at CMS attestation when the ValueSet definitions update annually and their bindings drift.
The operational fix is running a terminology server — HAPI's terminology module, Ontoserver, or Aidbox's Terminology service — and validating codes at write time. Ontoserver is the reference implementation used by most national programs; HAPI is the open path if licensing headroom matters.
3. SMART on FHIR launch is the app-integration front door.
SMART on FHIR — specifically the launch spec and scopes model — is how third-party clinical apps connect to your EHR. In practice, the parts that break:
- Launch context: patient, encounter, user context tokens must match the FHIR resources the app queries. If your launch context returns patient: 123 but your FHIR API returns 404 for Patient/123, apps quietly break. - Scopes: patient/*.read vs. patient/Observation.read semantics. Newer SMART v2 uses Observation.rs for read+search. Support both scope grammars during transition years. - Refresh tokens: SMART requires long-lived refresh for background apps; short-lived apps do not need refresh. Get the classification right per app registration.
4. Bulk data is now an active integration surface, not a batch job.
The Bulk Data Access IG is table-stakes for CMS-0057 Payer-to-Payer flows and for population-health analytics. What's changed is that bulk data endpoints see traffic every day, not once a quarter. Rate-limit tuning, chunk sizing, and delete-tracking (all covered in the IG) matter operationally.
What to invest in that isn't obvious
1. A conformance CI harness — run Inferno against your endpoints on every deploy. 2. Terminology server infrastructure, not just terminology code tables. 3. Auth server that supports SMART v2 scopes end-to-end. 4. Observability at the resource-type level (per-endpoint metrics, not just per-service).
EHR development in 2026 has moved past "can we implement FHIR" and into "can we operate FHIR at production quality". The teams that ship well spend disproportionate time on the four items above — everything else is templated.