Healthcare Interoperability and FHIR: A Practical Architecture Guide for Enterprise Health Systems

Every hospital CIO has heard some version of the same complaint: the EHR has the data, the lab system has the data, the imaging system has the data, and none of them will talk to each other without a six-figure interface engineering project. HL7 FHIR (Fast Healthcare Interoperability Resources) was built to fix exactly this problem, and since the ONC's Cures Act Final Rule made FHIR-based API access a regulatory requirement for certified health IT, interoperability has moved from "nice to have" to "mandatory architecture constraint." This guide is written for the technical decision-makers — CTOs, engineering leads, and enterprise architects — who have to translate that mandate into a system that actually works.

Table of Contents

• Why Interoperability Failed Before FHIR
• FHIR Fundamentals: Resources, Profiles, and Implementation Guides
• Reference Architecture Patterns
• The API Gateway and Security Layer
• Data Mapping: Where Most Projects Actually Fail
• SMART on FHIR and App Ecosystems
• Regulatory Drivers: ONC, CMS, and TEFCA
• Common Implementation Mistakes
• How Halkwinds Approaches FHIR Architecture
• FAQs

Key Takeaways

• FHIR standardizes the data model and the transport layer, but it does not standardize clinical meaning — profiles and implementation guides (like US Core) do that work, and getting them wrong is the most common cause of failed interoperability projects
• A FHIR-conformant API sitting in front of a legacy data model is still a legacy system — the architecture decision that matters most is whether FHIR is a translation layer or the canonical internal representation
• SMART on FHIR turns interoperability from a batch data exchange problem into an application platform problem, which is why it has become the default pattern for both provider-facing and patient-facing health apps
• TEFCA (Trusted Exchange Framework and Common Agreement) is changing the interoperability conversation from point-to-point integrations to network participation, and enterprise architecture decisions made today should account for it

Why Interoperability Failed Before FHIR

HL7 v2 messaging, still the backbone of most hospital interface engines, was never designed as a strict standard — it was designed as a flexible message format that every vendor implemented slightly differently. Z-segments, optional fields used inconsistently, and ambiguous coding systems meant that every interface between two systems required custom mapping work, even when both systems claimed v2 conformance. CDA documents (the C-CDA standard used for care summaries) solved document exchange but not queryable, granular data access. The result was an industry where "interoperability" meant a fax machine with better formatting, or at best a point-to-point HL7 v2 feed that took months to build and broke on every vendor upgrade.

FHIR Fundamentals: Resources, Profiles, and Implementation Guides

FHIR represents clinical and administrative data as discrete resources — Patient, Observation, Condition, MedicationRequest, Encounter, and roughly 150 others — exposed over a RESTful API using JSON or XML. This alone is a significant architectural shift from message-based integration: instead of subscribing to a feed of HL7 v2 ADT messages, a consuming application queries GET /Patient/123/Observation?category=laboratory and gets back exactly the resources it asked for.

The part teams consistently underestimate is that base FHIR resources are intentionally generic. A Patient resource on its own does not specify which identifier system to use, which value sets are acceptable for race and ethnicity, or which extensions carry US-specific data. US Core — the implementation guide mandated by ONC certification — constrains base FHIR into something two US health systems can actually interoperate against. Building to bare FHIR instead of US Core (or a relevant international core, or a specialty-specific IG like Da Vinci for payer data exchange) is one of the most common sources of "FHIR-compliant but not actually interoperable" systems.

Reference Architecture Patterns

Three architecture patterns dominate enterprise FHIR implementations, each with different tradeoffs:

• FHIR facade over legacy data: A translation layer sits in front of the EHR's proprietary data model and converts queries into FHIR resources on the fly. Fast to stand up, but every query pays a translation cost, and the facade can only expose what the underlying system's data model actually supports.
• FHIR-native data store: Clinical data is persisted directly as FHIR resources in a document or resource-oriented database (HAPI FHIR on a relational or document store is the most common open-source implementation). This eliminates translation overhead and makes the API the source of truth, but requires either replacing core clinical systems or maintaining a synchronized secondary store.
• Clinical data repository (CDR) with FHIR export: Data from multiple source systems is aggregated into a CDR, normalized, and exposed through a FHIR API layer. This is the dominant pattern for health systems with multiple EHRs from M&A activity, or for population health and analytics use cases that need a unified longitudinal record.

The right choice depends heavily on whether the driving use case is regulatory API compliance (facade is often sufficient), a genuine data platform investment (FHIR-native or CDR), or both.

The API Gateway and Security Layer

FHIR APIs in production need an API gateway layer that most implementation guides gloss over: OAuth 2.0 / OpenID Connect authorization (typically via SMART's authorization framework), rate limiting per consuming application, audit logging of every resource access for HIPAA accounting-of-disclosures requirements, and consent management that can restrict resource visibility per patient authorization (42 CFR Part 2 substance use disorder data being the most operationally painful example). Treating the FHIR API as "just another REST API" without this layer is a common cause of both security findings and failed information-blocking compliance reviews.

Data Mapping: Where Most Projects Actually Fail

The FHIR specification and the API gateway are rarely where interoperability projects fail. The failure point is almost always semantic mapping — translating a source system's local codes (a lab's internal test codes, a legacy system's free-text medication fields, a homegrown problem list) into the standard terminologies FHIR resources expect: LOINC for labs, RxNorm for medications, SNOMED CT for conditions and procedures, ICD-10-CM for diagnoses. This mapping work is clinical informatics work as much as it is engineering work, and it does not scale by adding more engineers — it requires clinical informaticists validating that codes map correctly, and a governance process for handling the codes that do not map cleanly.

SMART on FHIR and App Ecosystems

SMART on FHIR extends the base specification with a standard authorization pattern that lets third-party applications launch inside an EHR session (or independently, for patient-facing apps) and request scoped access to specific resource types. This is the technical foundation that makes an "app store" model for clinical applications possible — a diabetes management app, a prior authorization tool, or a clinical decision support module can be built once against the SMART on FHIR standard and deployed across any conformant EHR, rather than requiring a custom integration per vendor. For health systems and health tech vendors building provider-facing or patient-facing applications, SMART on FHIR conformance is rapidly becoming table stakes rather than a differentiator.

Regulatory Drivers: ONC, CMS, and TEFCA

Three regulatory threads are pushing FHIR adoption from optional to mandatory. The ONC Cures Act Final Rule requires certified health IT to expose FHIR-based APIs and prohibits information blocking. CMS interoperability rules require FHIR Patient Access and Provider Directory APIs for payers covering Medicare Advantage, Medicaid, and ACA marketplace plans. TEFCA, administered through Qualified Health Information Networks (QHINs), is building toward a national network-of-networks model where FHIR-based queries can traverse participating networks rather than requiring bilateral agreements between every pair of organizations. Architecture decisions made now — particularly around consent management and query response formatting — should be evaluated against where TEFCA participation is headed, not just today's point-to-point requirements.

Common Implementation Mistakes

• Treating FHIR conformance testing (Touchstone or equivalent) as a one-time certification event rather than a continuous validation step in the CI/CD pipeline, which lets conformance drift as source systems change
• Underinvesting in terminology mapping and governance, producing a technically valid FHIR API that returns clinically unusable or unmappable data
• Building bespoke authorization logic instead of adopting SMART's standard authorization framework, which breaks compatibility with the growing ecosystem of SMART-conformant applications
• Ignoring bulk data export (FHIR Bulk Data / Flat FHIR) for population-level use cases and forcing analytics workloads through resource-by-resource REST queries, which does not scale

How Halkwinds Approaches FHIR Architecture

We treat FHIR architecture decisions as data platform decisions, not API compliance checkboxes. That means starting with the actual downstream use cases — regulatory API exposure, a longitudinal patient record, population health analytics, an app ecosystem — and letting the use case determine whether a facade, a FHIR-native store, or a CDR pattern is the right investment. Our healthcare software development practice pairs engineers with clinical informaticists on terminology mapping specifically because that is where we see most interoperability budgets quietly get consumed. Our CareAxis platform was built around exactly this kind of EHR integration and data connectivity work. If you are scoping a FHIR implementationInteroperability architecture decisions also shape your HIPAA compliance posture and data security controls — they are not independent workstreams. If you are scoping a FHIR implementation or evaluating whether your current interoperability architecture will hold up under TEFCA participation, talk to us about an architecture review.

Frequently Asked Questions

Is FHIR the same thing as an EHR API?

Not exactly. FHIR is the specification for how healthcare data is structured and exchanged. Most major EHR vendors expose FHIR-based APIs as their primary integration mechanism today, but the underlying data model, the specific resources supported, and the implementation guide conformance vary by vendor — "the EHR has a FHIR API" does not guarantee it exposes the resources or data granularity a given use case needs.

Do we need to migrate off HL7 v2 to adopt FHIR?

No. Most health systems run HL7 v2 and FHIR in parallel for years. V2 remains efficient for high-volume real-time transactional messages like ADT feeds, while FHIR is typically adopted first for API-based query access, patient access requirements, and app integration use cases. A full v2-to-FHIR migration is a multi-year undertaking that few organizations pursue as a single project.

How long does a FHIR API implementation typically take?

A facade-pattern implementation exposing US Core resources over an existing EHR can be production-ready in 3–6 months with an experienced team. A FHIR-native data platform or a multi-source CDR with FHIR export is a 9–18 month program depending on the number of source systems and the state of existing data governance.

What is the difference between US Core and other FHIR implementation guides?

US Core is the baseline implementation guide required for ONC certification in the United States and constrains the most commonly used resources (Patient, Observation, Condition, and similar). Specialty implementation guides layer on top of US Core for specific use cases — Da Vinci for payer/provider data exchange around prior authorization and quality measures, for example. A production system typically conforms to US Core plus whichever specialty IGs its actual use cases require.

Can a small or mid-size health system realistically build FHIR-native infrastructure, or is that only for large systems?

Open-source FHIR servers (HAPI FHIR being the most widely deployed) have significantly lowered the barrier — the harder and more expensive part is rarely standing up the FHIR server itself, it is the terminology mapping, data governance, and security layer around it. Mid-size systems more often succeed with a scoped facade implementation targeting specific regulatory and integration requirements rather than a full FHIR-native rebuild.