FHIR Chat · sampledData and vitals · Orders and Observation WG

Stream: Orders and Observation WG

Topic: sampledData and vitals


view this post on Zulip Lloyd McKenzie (Apr 09 2019 at 21:00):

Sometimes when capturing vital signs a number of measurements are captured at regular intervals. For example blood pressures, pulse rates, etc. Normally we recommend the use of the SampledData data type for such situations. However, right now the vital signs profiles don't support the use of this type. Are we comfortable saying that blood pressure, pulseox, etc. cannot EVER be captured using SampledData and must always have each measurement captured as a separate Observation? (Because that's what we're doing right now with the mandatory profiles...)

view this post on Zulip Eric Haas (Apr 09 2019 at 21:02):

Am cross posting to implementers.

view this post on Zulip Eric Haas (Apr 09 2019 at 21:06):

to see if CURRENTLY an issue.

view this post on Zulip Lloyd McKenzie (Apr 09 2019 at 21:18):

As mentioned there, the profile needs to allow what's permitted ever. If we say "this can only be a Quantity" and go normative, it can't ever be anything else. And these profiles are candidates to normative in R5.

view this post on Zulip Richard Townley-O'Neill (Apr 10 2019 at 01:18):

I think that prohibiting the use of sample data for blood pressure, etc. is a bad idea.

view this post on Zulip John Rhoads (May 05 2019 at 13:29):

@Richard Townley-O'Neill Strongly agree. In devices, it is sometimes natural for multiple sampled periodic vital signs to "travel together", as in patient-worn devices that sample more frequently than they transmit, for monitors that queue up samples until they can be validated by a clinician, for devices responding to retrospective data queries, and so on. Requiring these data to be rejiggered as individual observations doesn't seem beneficial in all cases.


Last updated: Apr 12 2022 at 19:14 UTC