Stream: implementers
Topic: Device alarms
Radu Craioveanu (Jul 20 2019 at 14:21):
looking for thoughts on creating a digital representation for Device generatated Alarms using FHIR resources.
Michele Mottini (Jul 20 2019 at 17:20):
Alarms for things like dangerous high or low values ? Probably Observation
Radu Craioveanu (Jul 24 2019 at 17:51):
how do we best map a Device Alarm to FHIR ?
Lloyd McKenzie (Jul 24 2019 at 22:37):
Recommendation above was Observation
Stefan Karl (Jul 25 2019 at 14:52):
Seems there is no adequate representation. An alarm resource is listed on top of the list of Outstanding Issues. There is a proposal for a DeviceAlert FHIR resource since a while. The Devices-on-FHIR WG recently started work on this topic again.
Jose Costa Teixeira (Jul 25 2019 at 21:18):
Depends. Alarm for "low battery" may be not obvious or may be missing. But alarm like "SPO2 below limit" should be an observation
Jose Costa Teixeira (Jul 25 2019 at 21:20):
The same thing reported by a person on a software or by a device is the same resource because they are the same thing
Jose Costa Teixeira (Jul 25 2019 at 21:23):
@Stefan Karl is this ok (use same resource for human-reported or device-reported results) or do you think there is a justification for expecting a different resource? I presume not, just want to be safe
Lloyd McKenzie (Jul 25 2019 at 22:42):
A battery being low is still an Observation. It's just about the device rather than a patient.
John Silva (Jul 26 2019 at 00:21):
Actually, if that monitor (or device) is connected to a patient it is about both the device and the patient! (If the device is beeping because of leads off and isn't connected to a patient, I probably don't care -- unless the noise is bothering someone ;-) )
Eric Haas (Jul 26 2019 at 00:54):
use the focus element which references Device and subject references Patient.
Jose Costa Teixeira (Jul 26 2019 at 07:28):
A battery being low is still an Observation. It's just about the device rather than a patient.
Thanks @Lloyd McKenzie for asserting that. I do not think the DeviceAlert resource proposal makes sense then as it is scoped now. And I do not know if we need a DeviceAlert then.
Jose Costa Teixeira (Jul 26 2019 at 07:30):
I think that "battery dead" or "maintenance needed" could be a grey zone, but I am glad there is no gray area. The other things like "SPO2=86", "100 steps today", "10ml of drug injected"
Stefan Karl (Jul 26 2019 at 12:07):
For a human-reported "SpO2 below limit" I'd expect an Observation with valueQuantity and interpretation code "L", "LU" or "LL".
A device-reported alarm has additional characteristics, mostly driven by the IEC 60601-1-8 Alarm Standard:
- Alert type (technical/physiological/advisory)
- Alarm priority (low/medium/high)
- Alarm limits (if applicable)
- Alarm signal (audible/visual, local/remote)
- Latching and reminder signals
- Signal inactivation state (alarm/audio pause, alarm/audio off, acknowledged)
- Operator confirmation
Coding of physiological alarms is often made by a tuple of codes: physiological source ("SpO2") and event code ("below limit").
Observation doesn't fit very well. Of course you can add anything by extensions, but this will result in many different implementations. I think the proposal is still valid, but should be revised. We may consider if it should be a more generic "Alert" resource also for human-reported alarms that need more than a simple interpretation code or textual entry.
John Silva (Jul 26 2019 at 12:08):
@Jose Costa Teixeira -- "battery low" or "needs maintenance" could be for a device inventory and maintenance use case and not (directly) for patient care. Would that make a difference?
Lloyd McKenzie (Jul 26 2019 at 14:52):
Observation is in no way constrained to patient care. In principle, Observation could be used to help manage hospital elevator maintenance.
John Silva (Jul 26 2019 at 14:54):
And the hospital cafeteria's customer feedback ;-)
Lloyd McKenzie (Jul 26 2019 at 14:55):
That's absolutely related to patient care :)
Last updated: Apr 12 2022 at 19:14 UTC
