Stream: implementers
Topic: How to represent device events
Dale Nelson (Feb 01 2018 at 13:37):
Am trying to handle operational device events, such as errors, warnings, user-event. These seem like log/audit types of things, but some are appropriate to the patient as well. Consider a portable Insulin Pump: it may issue a stream of log events like Power-on, power-off, cartridge-low, cartridge-empty, battery-low, etc. Have been leaning toward Observations against the Device itself, with Observation.subject=Device. Is there a different appropriate resource for this sort of thing? Thoughts?
Eric Haas (Feb 01 2018 at 20:47):
Use Observation with an empty value and a .dataAbsentReason http://build.fhir.org/valueset-observation-valueabsentreason.html
Richard Townley-O'Neill (Feb 01 2018 at 23:47):
@Eric Haas
I take Observation.dataAbsentReason to be the reason for there being no data, not substitute data when there is no normal data. dataAbsentReason would not have a value of "cartridge-low", that is data, not a reason for a lack of data. dataAbsentReason might have a value of "system message", but then there needs to be an extension to hold the system message, e.g. "cartridge-low".
Richard Townley-O'Neill (Feb 01 2018 at 23:50):
I also tend towards having an observation against the device.
Eric Haas (Feb 01 2018 at 23:54):
I assumed you got an error message instead of data. Is that not the case.... in other words is the machine warning you about somethin in addition to the normal data stream?
Richard Townley-O'Neill (Feb 01 2018 at 23:57):
Eric, I guess I read Dale's post differently.
Dale Nelson (Feb 03 2018 at 20:21):
@Eric Haas @Richard Townley-O'Neill Thanks - I didn't check follow-ups here for a few days; I am trying to handle Richard's description- devices upload streams that may embed operational behavior with or withput data values. Frequently this is conveyed with sensor annumciation bytes that employ positional bit settings to indicate anhything from a "battery is low" to "reading was outside sensor limits" or outright "device failed". Some of these obviously map to a databsentReason, but others are conveying an operational log of device status (e.g. power-on, power-off, glucometer strip was not inserted properly, etc etc).
I am trying to separate concerns, to handle status that can be directly mapped to operational events outside of Observation values. I believe that is best handled by Observations against the device, made by the device. Obviously something other than LOINC for Observation.code.
Mikael Rinnetmäki (Jan 23 2019 at 15:35):
Hi @Dale Nelson, what's your status regarding this activity? We're profiling insulin pump and CGM data in Finnish PHR project. Would appreciate any resources and examples you can share.
Last updated: Apr 12 2022 at 19:14 UTC
