Stream: implementers
Topic: Periodic vs Aperiodic Observations?
John Silva (Jun 12 2018 at 15:59):
How would you suggest representing the concept of periodic vs aperiodic values in a FHIR Observation, without using an extension?
(There is a concept for 'periodic' in SNOMED, but not one for 'aperiodic'. An example of this is Heart Rate; typically bedside monitors send this as a periodic data, e.g. every 30 seconds, but heart rate from a Pleth device is an aperiodic data value that is only sent when the clinician specifically takes this measurement.)
Jose Costa Teixeira (Jun 12 2018 at 17:29):
Depends on what you want.
if you are talking about "heart rate" and not "today's heart rate for Mr X", then you are looking at definitions, not observations.
observationdefinition does not have any good attribute for this
activitydefinition.timing may cover it
John Silva (Jun 12 2018 at 18:07):
@Jose Costa Teixeira - I'm looking for a way to represent this in the "observation instances", because any particular observation (measurement) could have been periodic, e.g. 'essentially continuous' from a monitor, or aperiodic, as when a clinician takes a pleth reading and the pleth returns the "heart rate" value (bpm). Also, this is not specific to "heart rate", I used this as an example. Another example is SpO2, where this could come as a continuous (periodic) measurement from a monitor but it could also come aperiodically from a Lab test result.
Jose Costa Teixeira (Jun 12 2018 at 19:22):
Do you mean
- This observation is of a periodic kind, so similar ones may follow or precede it,
- This observation is periodic, so similar ones follow/precede it
?
Jose Costa Teixeira (Jun 12 2018 at 19:40):
@John Silva Actually I don't see any of the two cases i mention as being covered. you may need an extension, unless @Eric Haas i am missing something - is there a way to convey these cases?
Grahame Grieve (Jun 12 2018 at 22:52):
I don't understand how this information is relevant to a point in time observation?
Eric Haas (Jun 12 2018 at 23:17):
I kind of agree with GG, but I would think this could be handled in the terminology as a pre or post coordinated concept or as an extension. If it were some sort of device measurement then settings could be discoverable through the deviceMetric.
John Silva (Jun 13 2018 at 09:54):
It's relevant to our 'use case' so we need a way to handle this. At this point I'm leaning towards simply adding a category property with a code to indicate 'periodic' vs 'aperiodic', maybe not the best thing but we don't want to use an extension. @Eric Haas - the data sometimes comes from a device but, as in the example of SpO2, not always (it can come from a device or a lab result). I could infer the periodic/aperiodic value from the source device, e.g. a monitor vs a lab system, but that might not be sufficient. There are situations where a value from a monitor can be either periodic or aperiodic, e.g. heart rate from an a-line vs. heart rate from a pleth device, blood pressure from an a-line vs blood pressure via a cuff reading.
Lloyd McKenzie (Jun 13 2018 at 12:09):
What's your reason for not wanting to use an extension?
Grahame Grieve (Jun 13 2018 at 13:07):
and you still haven't explained why beyond 'it's relevant'
John Silva (Jun 13 2018 at 15:31):
Because our internal FHIR server doesn't support extensions; it's a 'minimalistic' implementation
John Silva (Jun 13 2018 at 15:32):
The "it's relevant" is about all I can say because the use case may be "proprietary information"
Grahame Grieve (Jun 13 2018 at 22:03):
well, then, you really need to add extension support, because there's not much we're going to be able to say about something that's proprietary information.
Last updated: Apr 12 2022 at 19:14 UTC
