Demystifying Smart on FHIR: Building Smart on FHIR App

FHIR (Fast Healthcare Interoperability Resources), developed by HL7, plays a pivotal role in addressing the critical issue of data interoperability in healthcare systems. The need for FHIR arises from the inherent challenges faced when organizations with different EHR systems or departments utilizing diverse software solutions attempt to communicate and share patient information.

01.The Interoperability Crisis: Why Healthcare Needed FHIR

Before FHIR, healthcare systems operated in isolated silos. A 2019 study by the Office of the National Coordinator for Health Information Technology (ONC) found that only 48% of hospitals could electronically send patient data to outside providers, and only 35% could receive and integrate external data into their EHR systems. This fragmentation had profound consequences:

02.How FHIR Ensures Interoperability: Architecture and Design Principles

FHIR revolutionizes healthcare interoperability through three fundamental design principles that set it apart from previous standards:

GET /Patient/123
GET /Observation?patient=123&category=vital-signs
POST /MedicationRequest
PUT /Appointment/456

{
  "resourceType": "Patient",
  "id": "example",
  "name": [{
    "family": "Smith",
    "given": ["John", "Q"]
  }],
  "birthDate": "1974-12-25"
}

FHIR Resource Structure: Deep Dive

Each FHIR resource follows a consistent structure that balances flexibility with standardization:

{
  "resourceType": "Patient",
  "id": "pat-12345",
  "meta": {
    "versionId": "2",
    "lastUpdated": "2024-01-15T09:30:00Z",
    "profile": ["http://hl7.org/fhir/us/core/StructureDefinition/us-core-patient"]
  },
  "identifier": [
    {
      "use": "official",
      "system": "http://hospital.org/mrn",
      "value": "MRN123456"
    },
    {
      "system": "http://hl7.org/fhir/sid/us-ssn",
      "value": "123-45-6789"
    }
  ],
  "active": true,
  "name": [
    {
      "use": "official",
      "family": "Smith",
      "given": ["John", "Robert"],
      "prefix": ["Mr."]
    }
  ],
  "telecom": [
    {
      "system": "phone",
      "value": "(555) 123-4567",
      "use": "home"
    },
    {
      "system": "email",
      "value": "john.smith@email.com"
    }
  ],
  "gender": "male",
  "birthDate": "1974-12-25",
  "address": [
    {
      "use": "home",
      "line": ["123 Main St", "Apt 4B"],
      "city": "Boston",
      "state": "MA",
      "postalCode": "02101",
      "country": "US"
    }
  ],
  "maritalStatus": {
    "coding": [{
      "system": "http://terminology.hl7.org/CodeSystem/v3-MaritalStatus",
      "code": "M",
      "display": "Married"
    }]
  },
  "contact": [
    {
      "relationship": [{
        "coding": [{
          "system": "http://terminology.hl7.org/CodeSystem/v2-0131",
          "code": "C",
          "display": "Emergency Contact"
        }]
      }],
      "name": {
        "family": "Smith",
        "given": ["Jane"]
      },
      "telecom": [{
        "system": "phone",
        "value": "(555) 987-6543"
      }]
    }
  ]
}

FHIR Search and Query Capabilities

FHIR's search capabilities go far beyond simple record retrieval, enabling sophisticated queries across related resources:

// Find all observations for a patient
GET /Observation?patient=123

// Find vital signs from last 7 days
GET /Observation?patient=123&category=vital-signs&date=ge2024-01-08

// Find lab results with specific LOINC code
GET /Observation?patient=123&code=2339-0&_sort=-date&_count=10

// Chained search: Find observations for patients in a specific location
GET /Observation?patient.address-city=Boston&category=laboratory

// Reverse chained search: Find patients who have diabetes diagnosis
GET /Patient?_has:Condition:patient:code=http://snomed.info/sct|73211009

// Get patient and include all their conditions
GET /Patient/123?_include=Patient:general-practitioner

// Get condition and include the patient
GET /Condition?_include=Condition:patient

// Get patient and reverse-include all observations about them
GET /Patient/123?_revinclude=Observation:patient

03.What is SMART on FHIR? Bridging Data Access with Security

FHIR solved the data interoperability problem—healthcare systems can now exchange structured clinical data in a standard format. But a critical piece was still missing: How do third-party applications securely access this data?

Enter SMART on FHIR (Substitutable Medical Applications, Reusable Technologies), developed in 2010 by a team at Boston Children's Hospital and Harvard Medical School. SMART adds three crucial layers on top of FHIR:

The "Write Once, Run Anywhere" Promise for Healthcare

Before SMART on FHIR, healthcare apps required custom integration for each EHR vendor—sometimes even for each hospital using the same vendor. A diabetes management app might need:

• Custom Epic integration using Epic's proprietary Interconnect platform ($50,000-$200,000 per integration)
• Different Cerner integration using Cerner's APIs and authentication model
• Yet another integration for Meditech, Allscripts, athenahealth, etc.
• Ongoing maintenance as each vendor updates their proprietary systems

SMART on FHIR changes this paradigm completely. A SMART app authenticated against one EHR will work with any SMART-compliant EHR, just like a web app works in any standards-compliant browser. This has profound implications:

SMART App Launch Flows: How Apps Get Patient Context

SMART defines two primary launch workflows that handle authentication, authorization, and context passing:

04.OAuth 2.0 and OpenID Connect: The Security Foundation

SMART on FHIR leverages OAuth 2.0 for authorization and OpenID Connect (OIDC) for authentication, providing enterprise-grade security that healthcare regulators require.

OAuth 2.0 in Healthcare Context

OAuth 2.0 solves a critical problem: How can a third-party app access patient data without the app ever seeing the user's EHR credentials?

05.How SMART Builds on Top of FHIR: Architectural Layers

SMART on FHIR creates a complete application ecosystem by adding authentication, authorization, and application launch capabilities to FHIR's data access layer. Understanding how these layers interact is crucial for implementing SMART applications.

SMART Scopes: Fine-Grained Permissions

SMART defines a granular scoping system that controls exactly what data an application can access and what actions it can perform:

// Scope format: [user|patient|system]/[Resource].[read|write|*]
//
// User scopes - access data the user can see
user/Observation.read          // Read observations in patient chart user is viewing
user/Patient.read             // Read patient demographics
user/MedicationRequest.*      // Full access to medications

// Patient scopes - access data for authenticated patient only
patient/Observation.read      // Patient reads their own observations
patient/AllergyIntolerance.*  // Patient manages their allergy list
patient/*.read                // Patient reads all their clinical data

// System scopes - backend services (no user present)
system/Patient.read           // Backend system reads any patient
system/Observation.write      // Backend system can write observations