Skip to article frontmatterSkip to article content

Open mHealth Data Standards

While FHIR provides the structural foundation for JupyterHealth Exchange, Open mHealth schemas provide the standardized format for the actual wearable and device data. Together, these two standards create a powerful combination for health data interoperability.

The Wearable Data Fragmentation Problem

Personal health devices and wearables collect valuable data, but each manufacturer uses different formats:

Proprietary Formats:

The Challenge:

The Cost: A researcher studying diabetes with glucose monitors might need to:

  1. Write a parser for Dexcom data

  2. Write a different parser for Abbott FreeStyle data

  3. Write yet another parser for Medtronic data

  4. Normalize timestamps, units, and field names across all three

  5. Maintain all parsers as manufacturers update their formats

This data wrangling can consume more time than actual analysis.

What is Open mHealth?

Open mHealth is an initiative to create open data standards for mobile health data. It provides standardized JSON schemas for common health data types collected by wearables and personal devices.

Mission and Goals

Core Mission: Make sense of patient-generated health data

Key Goals:

Adoption and Support

Open mHealth is used by:

IEEE 1752 Data Schema Structure

JupyterHealth Exchange uses IEEE 1752, the standardized evolution of Open mHealth schemas. Every data point follows a consistent structure with two main components:

Header (Metadata)

The header contains metadata about the data point using IEEE 1752 standard:

{
  "uuid": "aaaa1234-1a2b-3c4d-5e6f-000000000002",
  "schema_id": {
    "namespace": "omh",
    "name": "blood-pressure",
    "version": "4.0"
  },
  "source_creation_date_time": "2025-01-01T01:02:01-08:00",
  "modality": "sensed",
  "external_datasheets": [
    {
      "datasheet_type": "manufacturer",
      "datasheet_reference": "iHealth"
    }
  ]
}

Key Header Fields:

Body (Actual Health Data)

The body contains the actual measurement, structured according to the specific schema:

{
  "effective_time_frame": {
    "date_time": "2024-10-25T14:30:00-07:00"
  },
  "systolic_blood_pressure": {
    "value": 122,
    "unit": "mmHg"
  },
  "diastolic_blood_pressure": {
    "value": 77,
    "unit": "mmHg"
  }
}

Key Body Characteristics:

Supported Schemas in JupyterHealth Exchange

JupyterHealth Exchange includes validation for several Open mHealth schemas:

Blood Pressure (omh:blood-pressure:4.0)

Measures arterial blood pressure.

Fields:

Example Use Cases:

Blood Glucose (omh:blood-glucose:4.0)

Measures blood sugar levels.

Fields:

Example Use Cases:

Heart Rate (omh:heart-rate:2.0)

Measures cardiac rhythm.

Fields:

Example Use Cases:

Physical Activity (omh:physical-activity:2.0)

Records exercise and movement.

Fields:

Example Use Cases:

Step Count (omh:step-count:3.0)

Daily or periodic step counts.

Fields:

Example Use Cases:

Body Weight (omh:body-weight:2.0)

Body mass measurements.

Fields:

Example Use Cases:

Sleep Duration (omh:sleep-duration:3.0)

Sleep period length.

Fields:

Example Use Cases:

How JupyterHealth Exchange Uses Open mHealth

JHE integrates Open mHealth within the FHIR framework through a clever hybrid approach:

The Integration Pattern

FHIR Observation Structure (the envelope):

{
  "resourceType": "Observation",
  "id": "63416",
  "status": "final",
  "code": {
    "coding": [{
      "system": "https://w3id.org/openmhealth",
      "code": "omh:blood-pressure:4.0"
    }]
  },
  "subject": {"reference": "Patient/40001"},
  "device": {"reference": "Device/70001"},
  "valueAttachment": {
    "contentType": "application/json",
    "data": "<base64_encoded_open_mhealth_json>"
  }
}

Open mHealth JSON (the content): Stored in Base64-encoded format within the valueAttachment.data field.

Why This Hybrid Approach?

FHIR Provides:

Open mHealth Provides:

Together They Enable:

Schema Validation in JupyterHealth Exchange

JHE validates data at multiple levels to ensure quality and consistency:

Three-Tier Validation

Tier 1: FHIR Structure Validation

Tier 2: Open mHealth Outer Schema

Tier 3: Open mHealth Specific Schema

Validation Example Flow

When a blood pressure observation is uploaded:

  1. FHIR Validation: Is it a valid Observation resource?

  2. Patient Check: Does the referenced patient exist?

  3. Device Check: Does the referenced device exist?

  4. Consent Check: Has patient consented to share blood pressure data?

  5. Outer Schema: Does it have a valid header and body?

  6. Blood Pressure Schema: Does the body match blood-pressure:4.0 schema?

  7. Store: Save to database if all checks pass

If any validation fails, the entire upload is rejected with a specific error message.

Benefits for Different Users

For Researchers

Device Agnostic Analysis:

Researchers can write device-agnostic analysis code that extracts values from the standardized Open mHealth structure. Whether the blood pressure reading comes from an Omron device, a Withings cuff, or any other manufacturer, the analysis code accesses the same fields (systolic value, diastolic value, timestamp) and applies the same clinical logic, making the code portable and reusable across different data sources.

For Device Manufacturers and App Developers

Clear Integration Path:

Broader Reach:

For Patients

Device Choice Freedom:

For Healthcare Systems

Research Integration:

Real-World Scenarios

Scenario 1: Multi-Device Study

A researcher studying metabolic health wants participants to use:

Without Standards: Write three separate parsers, normalize three different timestamp formats, convert three different unit systems.

With IEEE 1752 in JHE: The CommonHealth app (or similar data aggregator) transforms all three proprietary formats into standardized IEEE 1752 JSON before uploading to JHE. Single analysis pipeline processes all data types regardless of source device.

Scenario 2: Device Failure Mid-Study

A participant’s blood pressure monitor breaks mid-study. They switch from an iHealth BP5 to a Withings device.

Without Standards: Data discontinuity. May need to analyze pre-switch and post-switch data separately.

With IEEE 1752 in JHE: Seamless transition. Both devices’ data is transformed to omh:blood-pressure:4.0 schema by the data collection app. Analysis pipeline doesn’t change.

Scenario 3: Cross-Study Meta-Analysis

Three different institutions run diabetes studies, each using different CGM devices.

Without Standards: Months of data harmonization work to combine datasets.

With IEEE 1752 in JHE: Direct data combination. All glucose data is stored in omh:blood-glucose:4.0 schema format regardless of original device.

Extending Open mHealth in JupyterHealth Exchange

JHE is designed to be extensible for new data types:

Adding a New Schema

To support a new Open mHealth schema:

  1. Add Schema File: Place the JSON schema in data/omh/json-schemas/

  2. Register Schema: Add schema reference to validation system

  3. Create CodeableConcept: Add data type to database

  4. Test: Upload sample data and verify validation

Example: Adding oxygen saturation support:

Custom Schemas

Organizations can also create custom schemas for proprietary devices:

{
  "schema_id": {
    "namespace": "org.example",
    "name": "custom-biomarker",
    "version": "1.0"
  }
}

While custom schemas reduce interoperability, they enable bleeding-edge research with novel devices while maintaining the Open mHealth structure.

Open mHealth Ecosystem Tools

Available Resources

Schema Repository:

Data Visualization:

Sample Data:

Integration Libraries

Libraries exist for multiple languages:

Comparing Open mHealth to Other Standards

Open mHealth vs. Proprietary Formats

AspectOpen mHealthProprietary
InteroperabilityHigh - works across devicesLow - vendor specific
DocumentationPublic, comprehensiveOften limited
ValidationJSON Schema availableVaries by vendor
CommunityOpen source, 6000+ devsVendor controlled
CostFree, open standardMay require licensing

Open mHealth vs. FHIR Observation

AspectOpen mHealthFHIR Observation
PurposeDevice data formatClinical observation record
GranularityVery detailed for wearablesFlexible for many uses
AdoptionWearable/device communityHealthcare systems
ValidationJSON SchemaFHIR validators
Best ForPatient-generated dataClinical and device data

JHE’s Approach: Use both together. FHIR for structure and healthcare compatibility, Open mHealth for device data richness.

Open mHealth Standards Evolution

Emerging Data Types

The Open mHealth community continues to develop schemas for new device types:

FHIR and Open mHealth Convergence

The FHIR and Open mHealth communities are collaborating on:

Research Opportunities with Standardized Data

Consistent data formats enable advanced research:

Learn More

Open mHealth Resources:

Related JupyterHealth Exchange Documentation:

Standards Organizations:

Summary

Open mHealth provides the crucial missing piece for wearable data interoperability: standardized schemas that normalize data across different device manufacturers. By combining Open mHealth’s device-focused standards with FHIR’s healthcare system compatibility, JupyterHealth Exchange creates a comprehensive solution for research data exchange.

Key Takeaways:

This hybrid approach—FHIR for structure, Open mHealth for content—represents the best of both worlds for health data interoperability.

Explanation
FHIR Interoperability
Explanation
Data Flow