Which standard covers what?
IEEE 1752.1-2021, built from the Open mHealth work, defines standard JSON Schema representations for sleep and physical activity measures, minimum metadata and surveys. Heart rate is not in 1752.1; cardiovascular, respiratory and metabolic measures belong to the separate P1752.2 project, which is still a proposed standard, so the Open mHealth heart-rate-2.0 schema fills that gap today. FHIR R4 Observation is the clinical-side target, and Apple HealthKit and Android Health Connect are where the phone data usually starts.
| Standard or source | What it covers | Units | Time handling |
|---|---|---|---|
| IEEE 1752.1-2021 (Active, published Sep 16, 2021) | Sleep, physical activity, minimum metadata, surveys; open-source JSON Schemas (Apache 2.0) | Shared units-of-measure utility schema | Time point and time interval utility schemas |
| Open mHealth heart-rate-2.0 | Heart rate, optional descriptive statistic and relationship to activity or sleep; references SNOMED CT 78564009 "Pulse rate" | beats/min | effective_time_frame |
| FHIR R4 Observation + heart rate profile | Measurements about a patient or device (Normative from v4.0.0); heart rate uses LOINC 8867-4 | UCUM /min | effective[x] (dateTime, Period, Timing or instant), separate issued |
Apple HealthKit heartRate | Quantity samples of the user's heart rate; discrete aggregation; samples may be condensed or coalesced | count/time | Per sample |
Android Health Connect HeartRateRecord | A series record holding a list of samples, with metadata; aggregates for average, max, min and count | Beats per minute | startTime/endTime Instants plus optional zone offsets |
Sources: IEEE SA: IEEE 1752.1-2021; IEEE Xplore, doi:10.1109/IEEESTD.2021.9540821; IEEE 1752 schema repository; Open mHealth heart-rate-2.0 schema; HL7 FHIR R4 Observation; HL7 FHIR R4 heart rate profile; Apple HealthKit heartRate; Android HeartRateRecord; Health Connect data types. Fitbit and Garmin APIs are left out until we have checked their docs.
How is a 1752.1 data point structured?
Each instance is a header plus a body. The header names the schema the body follows; a data point has one body and a data series has an array of them. The minimum metadata falls into five groups: data point, source, acquisition and processing, attribution, and privacy. Schema folders in the repository cover metadata, physical activity, sleep (for example total sleep time, sleep episode, wake after sleep onset, sleep onset latency and time in bed), environment, survey and utility types.
Sources: IEEE 1752 schema repository; IEEE P1752 working group slides, Apr 2022; IEEE SA: IEEE 1752.1-2021.
Worked mapping: one heart-rate sample (illustrative)
This example is ours, not an official mapping; we did not find a published Open mHealth to FHIR mapping to cite. It shows the fields that change: the unit string moves from beats/min to the UCUM code /min, a LOINC code is added, and the time stays a full timestamp with its offset.
Open mHealth heart-rate-2.0
{
"header": { "schema_id": { "namespace": "omh", "name": "heart-rate", "version": "2.0" } },
"body": {
"heart_rate": { "value": 62, "unit": "beats/min" },
"effective_time_frame": { "date_time": "2026-10-27T07:15:00-07:00" }
}
}FHIR R4 Observation (heart rate profile)
{
"resourceType": "Observation",
"status": "final",
"code": { "coding": [ { "system": "http://loinc.org", "code": "8867-4" } ] },
"effectiveDateTime": "2026-10-27T07:15:00-07:00",
"valueQuantity": { "value": 62, "system": "http://unitsofmeasure.org", "code": "/min" }
}A real Observation also needs a subject and the vital-signs category, and device details can go in Observation.device; check the profile page before you ship.
Sources: Open mHealth heart-rate-2.0 schema; HL7 FHIR R4 heart rate profile; HL7 FHIR R4 Observation.
Common pitfalls
- Time zones. Health Connect stores an Instant and an optional zone offset; FHIR
effective[x]takes a dateTime or Period. Keep the offset all the way through, or daily summaries land on the wrong day. - Samples vs. summaries. HealthKit may condense or coalesce samples, Health Connect stores a series inside one record, and Open mHealth uses
descriptive_statisticfor summaries. Record which one you have before you compare numbers. - Units.
beats/min, count/time and/minmean the same thing but are not the same string; map them explicitly. - Device metadata. 1752.1 has a minimum-metadata header, Health Connect has a
metadatafield and FHIR usesObservation.device. Carry the source device through, because accuracy depends on it.
Sources: Android HeartRateRecord; HL7 FHIR R4 Observation; Apple HealthKit heartRate; Open mHealth heart-rate-2.0 schema; IEEE SA: IEEE 1752.1-2021.
Related resources
Frequently asked questions
What is IEEE 1752.1?
IEEE 1752.1-2021 is the IEEE Standard for Open Mobile Health Data. It defines standard representations of sleep and physical activity measures, minimum metadata and surveys as open-source JSON Schemas under Apache 2.0. It was published on September 16, 2021 by the IEEE EMBS Open Mobile Health working group.
Does IEEE 1752.1 cover heart rate?
No. Cardiovascular, respiratory and metabolic measures are the scope of the separate P1752.2 project, which is still a proposed standard. The Open mHealth heart-rate-2.0 schema is available in the meantime.
How do I represent wearable heart rate in FHIR?
Use an R4 Observation that follows the heart rate vital-signs profile: LOINC code 8867-4 and a valueQuantity in UCUM with code /min, or a dataAbsentReason when there is no value. Put the time in effective[x] and keep the time zone offset.
Scope it in 30 minutes
Book a scoping call and we'll name the smallest engagement that moves you forward. Most teams start with the fixed-scope Initial Audit.
Book a 30-min scoping callPrefer to write? Send a short note.