Stream: implementers
Topic: SampledData and vitals profiles
Eric Haas (Apr 09 2019 at 21:05):
see this comment (based on a related tracker) seeking input on whether is an issue TODAY
Lloyd McKenzie (Apr 09 2019 at 21:12):
Well, if the profiles go normative, it will be a breaking change to change it ever, so it's a question whose answer requires a forward looking view.
Michele Mottini (Apr 10 2019 at 10:02):
I would allow it. We started collecting data from wearables in our apps and returning / handling those as individual observations is not going to cut it (you run into the billions data points....)
Stefan Karl (Apr 10 2019 at 12:52):
There may be two reasons for using SampledData for blood pressure and other vital signs:
- (Invasive) blood pressure can be viewed as waveform data with samples every few milliseconds. Looking at the example this seems to be what SampledData was intended for. Not sure if this falls into the Vital Signs category, as it is not a "Blood pressure panel" with systolic and diastolic values.
- Collecting measurements at short time interval (e. g. every second) will create huge number of observations. There are complaints that FHIR is creating too much overhead for these kind of applications. If SampledData is the answer, then we need it for representing vital signs.
Eric Haas (Apr 10 2019 at 16:56):
The Consumer Wearables I've seen are sending data as a individual data points. Are there any sending as a sampled data? I think the in hospital devices or regulated wearable may send as a sampled data. It is not clear to me how an end user ( I am thinking of a patient looking at her data) would use it alongside individual measurements. Would need to perform some statistics on it to be able to view alongside a point measurement.
Options:
- send it all let the receiving app figure out how to deal with it.
- make sampled_data out of scope for the vitals profile use case ( only interested in single point data ) if you want to send a record of a data stream then perform some statistics on it and send that. In other words let the sending server figure out how to deal with it.
Lloyd McKenzie (Apr 10 2019 at 17:41):
The vitals profiles aren't just for wearables - it's for absolutely everything. What I'm hearing is that systems are going to need to be able to send and consume sampled data, so the international profiles need to allow for that. It's possible that the US Core profiles could constrain it out if they believe it falls outside of their scope, but it can't be out-of-scope for the UV profiles.
Eric Haas (Apr 10 2019 at 19:04):
I am not convinced it will be helpful to making the firehose of data bigger. Do I as a consumer of this data want to mash together a 16 hr trace of bp with a single wellness visit bp. It has to be managed somewhere and I am just asking the where and how, otherwise it becomes useless.
Lloyd McKenzie (Apr 10 2019 at 19:29):
It's a question of how it's useful to capture data. If you're measuring blood pressure intraarterially multiple times a second, you don't want those as separate Observations. So they're going to be captured as SampledData. On the other hand, when you query for a patient's historical blood pressures, you may not actually want those sorts of high-frequency results. Are there different LOINC codes for the high frequency measurements? Could we explicitly allow them too?
John Silva (Apr 10 2019 at 20:24):
Seems like a good discussion to have with the folks that deal with high-volume real-time data like those on the IHE PCD committee and the IEEE 11073 folks. In an inpatient setting vital signs are captured at a relatively high frequency (with high fidelity) to help make real-time, patient-critical decisions and for things like alarming. Maybe a FHIR repository doesn't want or need to store this high-frequency data but there are definitely systems that can generate it. (As far as viewing current, real-time/high-frequency data -- there are ways to address that -- when you look over a longer period of time you can do some 'rounding' or sampling to show trends and then when you zoom in, show the detail, minute-level data, for example.)
Michele Mottini (Apr 11 2019 at 08:50):
Yes, wearables send individual data points, and currently we are storing and rendering them as separate Observation - but it results in way too many of them, we should store and render them as sampled data to be manageable
Last updated: Apr 12 2022 at 19:14 UTC
