FHIR Chat · Wearable device data

I have a bunch of smartwatch data generated from Garmin. It includes 13 different metrics passively tracked daily, like daily summaries, pulseOx, sleep, stress, automatic activity detection, and recorded activities. I'm looking at the list of FHIR Resources and it seems that Observation is the best/maybe only resource that fits with these. However is the resource enough to cover these 13 categories/does anybody have advice for a beginner in how to get started converting all the data to FHIR? I couldn't find any official extensions or profiles specifically for passive smartwatch data.

Lin Zhang (Feb 11 2021 at 02:27):

A related github repo:
https://github.com/microsoft/iomt-fhir

Lloyd McKenzie (Feb 11 2021 at 03:31):

They will likely all be Observations, with the possible exception of recorded activities which could theoretically live in Procedure. There is a standard profile for pulseOx (https://www.hl7.org/fhir/oxygensat.html). The others would probably be similar. You'll have a separate observation instance for each. If you're capturing regularly sampled intervals, you might look at using the SampledData data type.

Eric Prud'hommeaux (Feb 11 2021 at 08:10):

in oxygensat, should i expect https://www.hl7.org/fhir/oxygensat-definitions.html#oxygensat.Observation.code.coding:OxygenSatCode to give me a set of codings for SpO2 readings?

Eric Prud'hommeaux (Feb 11 2021 at 13:45):

I guess that if a singleton Obs looked like:

{ "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [
    { "system": "http://loinc.org", "code": "59417-6", }
  ] },
  "effectiveInstant": "2013-04-02T10:30:10+01:00",
  "valueQuantity":
    { "value": 12,3, "code": "kPa", "system": "http://unitsofmeasure.org" }
}

that a SampleData analog would look like:

{ "resourceType": "Observation",
  "status": "final",
  "code": { "coding": [
    { "system": "http://loinc.org", "code": "59417-6", }
  ] },
  "effectivePeriod": {
    "start": "2013-04-02T10:30:10+01:00", "end": "2013-04-02T12:00:10+01:00"
  },
  "valueSampledData": {
    "origin":
      { "value": 12,3, "code": "kPa", "system": "http://unitsofmeasure.org" },
    "period": 600000,
    "dimensions": 1,
    "data": "12.3 12.2 12.4 12.4 12.1 12.2 12.4 12.4 12.1 11.9"
  }
}

where the end of the effectivePeriod would equal the start + (data items * period / dimensions)

Eric Prud'hommeaux (Feb 11 2021 at 13:49):

I imagine this isn't meant for structure data, e.g. streaming BP readings

Eric Prud'hommeaux (Feb 11 2021 at 13:54):

(unless the structure was homogeneous so you were able to hide the cardinality of the structure in the dimension. e.g.

"dimension": 2,
"data": "140 90 150 100 150 90"

)

Lloyd McKenzie (Feb 11 2021 at 15:31):

For BP, you'd have an Observation with two components and a sampledData for each.

Eric Prud'hommeaux (Feb 11 2021 at 21:21):

Interesting, instead of an array of tuples, it's two arrays of scalar values

Jeannie Huang (Feb 18 2021 at 22:56):

Lloyd McKenzie said:

They will likely all be Observations, with the possible exception of recorded activities which could theoretically live in Procedure. There is a standard profile for pulseOx (https://www.hl7.org/fhir/oxygensat.html). The others would probably be similar. You'll have a separate observation instance for each. If you're capturing regularly sampled intervals, you might look at using the SampledData data type.

Thanks for your answer Lloyd. If I want to represent resp rate taken at regular 1 minute intervals, can I used the SampledData data type within the resp rate resource? I only see valueQuantity which is just one data point @ http://hl7.org/fhir/R4/resprate.html. Or would the sampledData instead go into the component attribute?

Lloyd McKenzie (Feb 18 2021 at 23:25):

The oxygensat profile isn't set up to allow continuous measurements. I'd do two things:

Submit a change request calling that out and asking either for valueSampledData to be allowed within the profile, or to call out continuous measures as an exception to the requirement to use the profile
Proceed on the basis that the change request is accepted (because it'll have to be one way or the other).

Kevin Mayfield (Feb 19 2021 at 09:12):

For strava import I modeled this as a FHIR Transaction/Message Bundle (roughly based on HL7v2 ORU_R01 unsolicited-observations), with the activity mapping to FHIR DiagnosticReport and the summary values as Observations.

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Wearable device data · implementers

Stream: implementers

Topic: Wearable device data

Jeannie Huang (Feb 11 2021 at 01:34):