CS360 Engineering Blog

Insights, updates, and technical deep dives from the CS360 engineering team.

FHIR: The Future of Healthcare Interoperability

Healthcare data interoperability has been broken for decades. Fragmented systems, proprietary formats, and legacy standards mean billions in wasted spending, duplicated tests, and medical errors.

FHIR—Fast Healthcare Interoperability Resources—is changing how healthcare data is exchanged, and for the first time, making interoperability achievable at scale.

What is FHIR?

FHIR (pronounced “fire”) is a next-generation standard for exchanging healthcare information, developed by HL7 International. Released in 2014 and reaching maturity with R4 in 2019, FHIR fundamentally rethinks how healthcare data should be structured and shared.

The Problem

Legacy standards: HL7 v2 (1987) uses pipe-delimited messages. HL7 v3, while theoretically comprehensive, is practically unusable—RIM-based modeling with heavy XML tooling and a steep learning curve made it too complex for widespread adoption. Both require expensive middleware and months to integrate.

Vendor lock-in: Every EHR has its own API. Custom integrations for each system. Moving between vendors costs millions.

Fragmented data: Specialists can’t access primary care notes. ER doctors can’t see medication lists. Patients can’t access their own data.

The cost: Estimates put healthcare IT integration waste in the tens of billions annually in the US alone.

Why FHIR Changes Everything

Web-native: RESTful APIs, JSON/XML, OAuth 2.0. Any web developer can understand it. No special middleware.

Granular resources: Small, focused units (Patient, Observation, Medication) that can be independently retrieved and linked.

Extensible: Core resources cover 80% of use cases. Extensions handle the rest without breaking interoperability.

Pragmatic: Solves common cases simply. Good enough beats perfect.

What FHIR Actually Solves

FHIR standardizes:

FHIR does not solve:

FHIR makes interoperability technically achievable. Organizational, political, and business challenges remain.

Core Concepts

Resources

Everything in FHIR is a “resource”—a standardized data structure representing a healthcare concept.

FHIR R4 defines ~150 resources:

Clinical: Patient, Observation, Condition, Procedure, MedicationRequest, AllergyIntolerance, Immunization, DiagnosticReport

Administrative: Encounter, Practitioner, Organization, Location, Appointment

Financial: Claim, Coverage, ExplanationOfBenefit

Example Patient resource:

{
  "resourceType": "Patient",
  "id": "example-123",
  "identifier": [{
    "system": "http://hospital.example.org/patients",
    "value": "MRN-123456"
  }],
  "name": [{
    "family": "Smith",
    "given": ["John"]
  }],
  "gender": "male",
  "birthDate": "1980-05-15"
}

Key takeaway: FHIR resources are intentionally small and composable—modeling complex clinical scenarios is done by linking resources, not nesting everything into monolithic documents.

RESTful API

Standard HTTP methods make FHIR approachable:

GET /Patient/123                    # Read a patient
POST /Patient                       # Create new patient
PUT /Patient/123                    # Update patient
DELETE /Patient/123                 # Remove patient
GET /Patient?name=Smith             # Search patients

Sophisticated search capabilities:

GET /Patient?family=Smith&birthdate=ge1980-01-01
GET /Observation?patient=123&code=8867-4
GET /Patient?_count=50&_sort=-birthDate

Advanced features:

In production:

Bundles

Group multiple resources for atomic operations:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "resource": { /* Patient */ },
      "request": {"method": "POST", "url": "Patient"}
    },
    {
      "resource": { /* Observation */ },
      "request": {"method": "POST", "url": "Observation"}
    }
  ]
}

Profiles: Constraining Resources

Profiles add constraints for specific use cases: making optional elements required, restricting value sets, adding extensions.

Major profiles:

US Core: Required for US EHR certification. Mandates specific data elements and terminology (SNOMED CT, LOINC, RxNorm).

IPS (International Patient Summary): Global standard for cross-border patient summaries.

UK Core: NHS requirements with NHS number as primary identifier.

Using profiles:

{
  "resourceType": "Patient",
  "meta": {
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]
  }
}

Profiles Are Where Interoperability Lives (and Dies)

Profiles are the hardest part of FHIR adoption in practice:

Different interpretations: Two vendors can both claim “US Core compliance” but implement optional elements differently, use different code systems, or interpret “must support” inconsistently.

Profile conflicts: A resource might need to conform to multiple profiles (US Core + specialty-specific), and those profiles can have conflicting requirements.

Underspecification: Profiles often leave critical details undefined, forcing implementers to make assumptions that break interoperability.

Reality check: “FHIR-compliant” ≠ “plug-and-play.” Budget time for profile reconciliation, vendor-specific quirks, and extensive integration testing.

Important distinction: Some interoperability failures stem from underspecified profiles; others come from vendors implementing profiles correctly—but differently. Both are valid implementations, yet they don’t interoperate.

Extensions: Adding Custom Data

Extensions add custom data without breaking interoperability:

{
  "resourceType": "Patient",
  "extension": [{
    "url": "http://example.org/fhir/StructureDefinition/preferred-language",
    "valueCode": "es"
  }],
  "name": [{"family": "Garcia"}]
}

Modifier extensions change meaning—systems must understand them or reject the resource (e.g., “data entered in error”).

Best practices:

  1. Use standard extensions first
  2. Define extensions formally
  3. Document thoroughly
  4. Consider profiles if reusing extensions

Anti-pattern: Using extensions to model core clinical data (e.g., diagnoses, vital signs, medications) instead of proper resources. This guarantees downstream consumers will ignore your data. Extensions should extend, not replace, standard resources.

Terminology

Healthcare uses specialized code systems:

LOINC: Lab tests and observations (“8867-4” = Heart rate)

SNOMED CT: Clinical terms (300,000+ concepts)

RxNorm: Medications (“152923” = Metformin 500mg)

ICD-10: Diagnosis codes (“E11.9” = Type 2 diabetes)

CPT: Procedure codes (US billing)

CodeableConcept allows multiple codes:

{
  "code": {
    "coding": [
      {"system": "http://loinc.org", "code": "55284-4", "display": "BP"},
      {"system": "http://snomed.info/sct", "code": "75367002", "display": "Blood pressure"}
    ],
    "text": "Blood Pressure"
  }
}

Terminology Pain Points

Terminology servers: Validating codes, expanding ValueSets, and performing concept lookups require a terminology server. You can’t just validate codes offline against static lists—terminology is dynamic and versioned.

ValueSet expansion: A ValueSet might reference “all SNOMED codes for diabetes.” Expanding that to actual codes requires a terminology server with licensed SNOMED CT content.

Licensing: SNOMED CT requires licensing in many countries. LOINC is free but has usage terms. RxNorm is US-specific. Budget for terminology licensing and maintenance.

Validation complexity: Verifying that a code is valid for a given ValueSet, in a specific version, with proper hierarchy relationships, is harder than most developers expect.

Version pinning: The same ValueSet expanded against different terminology versions can yield different results. Pin terminology versions for reproducibility and audits. SNOMED CT “diabetes” in 2024 vs 2026 may include different codes.

SMART on FHIR

SMART on FHIR enables apps to run against any FHIR server with OAuth 2.0 authorization.

Authorization flow: App launches → Discovery → Authorization → User authenticates → Token exchange → API calls

Scopes:

Use cases: Patient portals, provider apps, EHR-integrated apps, clinical decision support.

SMART Reality Check

SMART on FHIR looks elegant on paper. In production:

Scope limitations: Many EHRs support only read scopes in production. Write scopes are often restricted or require special agreements.

Token lifetimes: Access tokens are typically short-lived (minutes to hours). Refresh tokens may not be available or require additional approval.

Sandbox vs production: Vendor sandboxes behave differently than production environments. APIs available in sandbox may be restricted in production.

OAuth quirks: Most SMART integration failures stem from OAuth implementation differences, undocumented scope constraints, and inconsistent error responses—not from FHIR itself.

Bottom line: Budget extra time for OAuth troubleshooting and vendor-specific authentication quirks. SMART standardizes the protocol, but implementations vary significantly.

When SMART works best: Read-heavy use cases (patient portals, clinical analytics, decision support suggestions) with minimal write requirements and well-scoped access. These scenarios avoid the most common integration pain points.

The Future

Regulatory Momentum

United States: 21st Century Cures Act mandates FHIR APIs for certified EHRs. By 2026, virtually every US EHR has production FHIR APIs.

Global: EU health data space, UK NHS adoption, Australia’s eHealth strategy. FHIR is the emerging global standard.

Emerging Use Cases

Concrete example - Prior authorization workflow:

  1. Provider creates ServiceRequest for procedure
  2. Sends to payer via CoverageEligibilityRequest
  3. Payer’s system queries patient’s Condition, Observation, Procedure history
  4. Automated rules engine (FHIR-based CDS Hooks) approves/denies
  5. Result returned as CoverageEligibilityResponse
  6. If approved, Claim submitted post-procedure

This entire workflow—previously taking days with fax and phone calls—can be automated in minutes using FHIR resources.

FHIR Evolution

R4 (2019): Current stable version, most implementations target this

R5 (2023): Enhanced features, better terminology support

Ongoing: Bulk data export, real-time subscriptions, GraphQL support

The network effect accelerates adoption: more systems = easier integrations = lower costs = faster development.

The Challenges Ahead

As FHIR adoption accelerates, watch for:

FHIR fatigue: Organizations implementing FHIR without understanding their actual interoperability needs, leading to wasted effort.

Extension proliferation: Teams creating custom extensions for everything instead of using standard resources, defeating interoperability.

“FHIR-first” without domain knowledge: Technical teams implementing FHIR without understanding healthcare workflows, resulting in technically correct but clinically unusable integrations.

Profile sprawl: Competing profiles for the same use case, forcing implementers to support multiple contradictory requirements.

FHIR is powerful, but it’s not a silver bullet. Successful adoption requires both technical expertise and deep healthcare domain knowledge.

Getting Started

For Engineering Teams

  1. Understand your use case: What data? Which partners? Which profiles? What regulations?
  2. Choose scope: Start narrow (3-5 resource types), expand incrementally
  3. Pick profiles: US Core (US), IPS (international), specialty-specific
  4. Select tools:
    • C# / .NET: Firely SDK
    • Java: HAPI FHIR
    • JavaScript: fhir.js
    • Python: fhirclient
  5. Validate early: Use official validators, integrate into CI/CD
  6. Test: http://test.fhir.org, vendor sandboxes, local HAPI FHIR

Common Mistakes

  1. Underestimating terminology complexity: Code systems are vast and complex
  2. Ignoring human-readable text: The text element is critical for safety
  3. Poor error handling: Always parse OperationOutcome resources. Example error response: 
    {
  "resourceType": "OperationOutcome",
  "issue": [{
 "severity": "error",
 "code": "required",
 "diagnostics": "Patient.name is required by US Core profile",
 "expression": ["Patient.name"]
  }]
}
  4. Not versioning properly: Use If-Match headers with ETags for updates. Example: PUT /Patient/123 with If-Match: W/"2". Handle 409 Conflict responses when versions don’t match. Many servers ignore versioning entirely—test your vendor’s behavior.
  5. Overlooking security: HTTPS, OAuth 2.0, audit logs, encryption

Conclusion

FHIR is transforming healthcare interoperability with modern web technologies, regulatory backing, and broad adoption.

Why it matters:

Core concepts: Resources, Profiles, Extensions, Terminology, Search, Bundles, SMART authorization

FHIR isn’t perfect—healthcare is complex—but it’s the best path forward. Whether building EHR integrations, patient portals, clinical decision support, or analytics platforms, FHIR provides the foundation.

Understanding FHIR is becoming essential for healthcare engineers.

Start here:

  1. Pick one resource (Patient or Observation)
  2. Pick one profile (US Core if in the US)
  3. Pick one partner (test server or vendor sandbox)
  4. Build a read-only integration first

Even if your end goal requires writes, start with read-only integrations to understand data shape, profiles, and terminology in the real world. Reading Patient and Observation teaches you more about FHIR than weeks of reading specs.

Learn by doing. Understand the fundamentals before tackling complex write operations or multi-resource workflows. Production FHIR integration is learned through experience, not just documentation.

Start learning and help shape the future of healthcare technology.

Resources: