Skip to article frontmatterSkip to article content

FHIR Interoperability

JupyterHealth Exchange is built on FHIR (Fast Healthcare Interoperability Resources), a modern standard for healthcare data exchange. This decision reflects a commitment to interoperability, future-proofing, and alignment with the broader healthcare technology ecosystem.

The Healthcare Interoperability Challenge

Healthcare data exists in countless formats across different systems:

This fragmentation creates significant barriers:

What is FHIR?

FHIR (Fast Healthcare Interoperability Resources), developed by HL7 International, is a next-generation standard for healthcare data exchange designed specifically for modern web-based systems.

Core Principles

Web-Native Design:

Modular Resources:

Flexibility Through Profiles:

FHIR’s Evolution from Previous Standards

FHIR builds on decades of healthcare standards work:

HL7 v2 (1987):

HL7 v3 / CDA (2000s):

FHIR (2011-present):

FHIR learned from its predecessors: keep what works (strong clinical modeling) while embracing modern development practices (REST, JSON, OAuth).

FHIR Resources Used in JupyterHealth Exchange

JupyterHealth Exchange uses FHIR resources as the foundation for its data model:

Patient

Represents study participants who contribute health data.

Key Fields:

In JHE: Maps to the Patient Django model with additional fields for study enrollment and consent management.

Practitioner

Represents researchers, clinicians, or staff who access patient data.

Key Fields:

In JHE: Maps to the Practitioner Django model, linked to organizations and studies with role-based permissions.

Organization

Represents institutions, departments, laboratories, or research groups.

Key Fields:

In JHE: Supports multi-level hierarchies (e.g., University → Department → Lab), with membership and access control tied to organizational relationships.

Group

Represents a collection of entities, used for studies in JHE.

Key Fields:

In JHE: The Study model maps to FHIR Group, allowing researchers to define cohorts of patients for specific research projects.

Observation

Represents measurements, test results, or assessments—the core health data.

Key Fields:

In JHE: Used to store wearable and device data. The valueAttachment field contains Base64-encoded Open mHealth JSON, allowing JHE to store rich device data while remaining FHIR-compliant.

Device

Represents medical devices or apps that produce observations.

Key Fields:

In JHE: The DataSource model maps to FHIR Device, representing apps like iHealth, Dexcom CGM, or Apple Health.

CodeableConcept

A data type (not a full resource) representing coded concepts with text descriptions.

Structure:

In JHE: Used extensively for data type taxonomy (blood glucose, blood pressure, etc.) using Open mHealth schema identifiers like omh:blood-glucose:4.0.

FHIR Version Considerations

FHIR has evolved through several versions over the years. JupyterHealth Exchange tracks modern FHIR releases to benefit from:

Maturity and Stability

Recent FHIR versions represent years of real-world implementation experience. Many core resources have reached “Normative” status, meaning they’re stable and unlikely to have breaking changes.

Device and Wearable Data Support

Modern FHIR includes enhancements for device-generated data:

This aligns with JHE’s need to store rich wearable data.

FHIR includes a Consent resource with:

While JHE currently implements consent in its own models, the FHIR Consent resource provides a potential migration path for standards alignment.

Broad Ecosystem Support

Modern FHIR is supported by:

Technical Implementation in JupyterHealth Exchange

Using FHIR required solving several technical challenges:

Challenge 1: Naming Conventions

Challenge 2: Validation Approach

Challenge 3: Flexible JSON Storage

Example query building a FHIR Patient resource directly in SQL: JHE constructs FHIR-compliant JSON directly in database queries using PostgreSQL’s JSON functions. This approach builds the complete FHIR Patient resource structure (with resourceType, identifiers, names, etc.) at the database level, allowing efficient querying while ensuring FHIR-compliant output without additional application-layer transformation.

Benefits of FHIR for JupyterHealth Exchange Users

For Researchers

Standard Data Access:

Example: A researcher can use the same Python script to query JHE and a hospital’s FHIR API:

import requests

# Query JupyterHealth Exchange
jhe_response = requests.get(
    "https://exchange.example.org/fhir/r5/Observation?patient=123",
    headers={"Authorization": f"Bearer {token}"},
)

# Query Hospital FHIR Server (same API!)
hospital_response = requests.get(
    "https://hospital.example.org/fhir/r5/Observation?patient=789",
    headers={"Authorization": f"Bearer {hospital_token}"},
)

# Parse both the same way
jhe_observations = jhe_response.json()["entry"]
hospital_observations = hospital_response.json()["entry"]

For Healthcare Providers

EHR Integration:

Potential Use Case: FHIR’s SMART App Launch framework could enable providers to launch research dashboards directly from EHR systems like Epic or Cerner.

For Platform Developers

Rich Ecosystem:

For the Project

Future-Proofing:

Trade-offs and Considerations

FHIR adoption isn’t without challenges:

Complexity

FHIR is comprehensive, which means:

JHE’s Approach: Use a subset of FHIR resources and fields, focusing on what’s needed for research data exchange.

Performance Considerations

FHIR’s flexibility can impact performance:

JHE’s Approach: Use raw SQL for complex queries, pre-build JSON in database where possible.

Version Management

FHIR versions evolve:

JHE’s Approach: Track modern FHIR releases, document any deviations from standard, maintain compatibility where possible.

Beyond FHIR: The Health Data Standards Ecosystem

JupyterHealth Exchange doesn’t use FHIR in isolation—it exists within a broader ecosystem of health data standards, each serving different purposes.

FHIR + Open mHealth: Current Integration

JHE combines FHIR’s structural advantages with Open mHealth’s device data schemas:

The Pattern:

This hybrid approach gives JHE:

Learn more in Open mHealth Data Standards.

Real-World Impact

FHIR adoption enables real research scenarios:

Scenario 1: Multi-Site Study: A diabetes researcher at UCSF wants to collaborate with colleagues at Stanford and UC Berkeley. All three institutions run JupyterHealth Exchange instances. Because all use FHIR APIs:

Scenario 2: EHR Integration: A cardiologist wants to combine hospital EHR data (lab results, medications) with patient wearable data (activity, heart rate). JHE’s FHIR compliance means:

Scenario 3: App Development: A developer wants to build a patient-facing dashboard showing their contributed data. Using FHIR means:

Learn More

FHIR Resources:

Related JupyterHealth Exchange Documentation:

Community:

Summary

JupyterHealth Exchange uses FHIR because it:

While FHIR adds some complexity, the benefits—especially for a platform designed to break down data silos—far outweigh the costs. By combining FHIR’s structural power with Open mHealth’s device data expertise, JupyterHealth Exchange creates a best-of-both-worlds solution for research data exchange.

Explanation
Conceptual Overview
Explanation
Open mHealth Data Standards