HL7 FHIR

HL7 FHIR (Fast Healthcare Interoperability Resources), currently at Release 4 (R4) with R4B and R5 in active deployment, is a standard developed by Health Level Seven International that defines a framework for exchanging healthcare information electronically. FHIR models clinical data as discrete "Resources" — Patient, Encounter, Observation, MedicationRequest, and over 140 others — each with a defined schema, RESTful API surface, and JSON/XML/RDF serialization. The ONC Interoperability Rule (45 CFR Part 170) mandates FHIR R4 as the technical standard for certified health IT, requiring payers and providers to expose FHIR-based Patient Access APIs, Provider Directory APIs, and Drug Formulary APIs. FHIR Bulk Data Access ($/export operations) handles population-level data exports. SMART on FHIR (HL7 implementation guide) provides the OAuth 2.0-based authorization layer for third-party application access.

The engineering reality of FHIR is that the specification is permissive by design — most elements are optional, profiles and extensions are used extensively by each implementer, and "valid FHIR" does not mean "interoperable FHIR." US Core Implementation Guide (currently 6.1.0) constrains which elements must be populated for US regulatory compliance, but every major payer and EHR vendor maintains proprietary FHIR profiles. Conformance validation requires running resources against both base FHIR schemas and implementation-guide-specific StructureDefinitions using validators like the HL7 FHIR Validator or Inferno. Teams routinely underestimate the complexity of FHIR ID management across systems, reference resolution for contained versus absolute references, and versioning — R4 and R4B introduced breaking changes to several resources including MedicationKnowledge and Citation. FHIR search parameters require careful index design; naive implementations serving large patient populations hit performance walls quickly.

FHIR sits at the intersection of multiple regulatory mandates. The CMS Interoperability Rule requires payers to implement FHIR R4 Patient Access APIs by defined deadlines. The information blocking provisions of the 21st Century Cures Act penalize interference with FHIR-based data access. TEFCA builds its QHIN technical requirements on FHIR as the preferred exchange format alongside older IHE profiles. The Da Vinci Project implementation guides (covering prior authorization, payer data exchange, and coverage requirements) define payer-specific FHIR profiles that are now appearing in regulatory mandates. For device manufacturers, FHIR Device and DeviceMetric resources are increasingly referenced in FDA guidance for SaMD data submission. Cross-border FHIR deployments must account for regional data localization — the EU FHIR community has divergent profiles from US Core.

We implement FHIR R4/R4B servers using battle-tested open-source cores (HAPI FHIR, Microsoft FHIR Server) with custom profile validation layers tuned to the specific implementation guides required by each integration. We build FHIR conformance test suites using Inferno and our own assertion libraries that run in CI/CD pipelines, catching profile violations before they reach production. Our SMART on FHIR implementations follow the SMART App Launch 2.0 specification with granular scope management and token introspection endpoints.

Compliance-Native Architecture Guide

Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.