We understand and respect the bias against the proliferation of narrowly defined resources in FHIR, and '80-20' thinking, but when there is a pervasive, distinct, and important entity and concept in medical informatics, it calls for an appropriately tailored FHIR representation
We argue that alerts from devices are such an entity and concept
- They are pervasive in acute-care settings and may need urgent attention. However their very pervasiveness must be managed as it can be a serious patient safety concern, through competition for clinician attention from less significant or entirely insignificant alarms, and the well-known phenomenon of 'alarm fatigue'
- they are subject to distinct processing needs
- they require clear and distinctive supporting content and context to be adequately processed
- they are subject to distinct regulatory requirements
Device alerts are
from semi-autonomous entities (devices) - once set up for a particular patient based on clinical judgment of, say, what is a concerningly high or concerningly low heart rate for the patient's state, the device goes on measuring and comparing with the thresholds and issuing an alert
DeviceAlert resource would be
clearly bounded from other resources that are related but have a broad scope and similar but not precisely equivalent use cases, for example, Flag, Communication, and Detected Issue. The distinctions from other resources that this proposal is based on.
DeviceAlert is a general signal of a clinical or technical issue detected by a device, and is subject to multiple distinct uses (clinical decision support, notification dispatching, 'significant event' archiving, retrospective analysis for processing improvements, ...)
Device alert data handling is a distinct, naturally-delimited transaction scope requiring distinct methods of risk analysis with attention to distinct base standards of, for example, ISO, IEC, IEEE, and consequently, special data requirements
The representation must accommodate precise information such as the source, priority or severity, alert kind, duration, current state, multiple signals from the originating device and elsewhere (such as mobile devices), correct location of the patient, and of other signaling devices or systems.
There is existing practice in medical informatics for this information scope in HL7 V2, such as IHE DEV Alert Communication Management Integration Profile. Some have argued that the common REST-based FHIR-server-based paradigm is ill-suited to use in this context, but of course, FHIR also supports messaging. In any case, device alert data should have a well-fitting FHIR representation
Device Alert handling is
A result of a risk management process for ensuring safety, effectiveness, and security
Device Alerts have
Links to Device, DeviceMetric, and Patient, and Observation, which show the nature, source, and priority of the event but has additional data requirements particular to alerts from devices.
DeviceAlert content is dictated by standards that are not applicable to other kinds of observed data
Actions and responses to device alerts are common and expected in important uses of devices including
data expected, for example in IHE Patient Care Device Alert Communication Management profile.
Corresponds closely to the single concept of an event or state in a device that requires action or recording.
To add from other page(s): Relation to existing FHIR resources:
Observation
Flag
AdverseEvent
How fr to go with use cases: focus mainly on the DeviceAlert as a "record", or be more inclusive of near-real-time communications aspect
--------------
Alarms and notifications from electronic medical devices (collectively termed device alerts) are substantially unlike anything else in medical informatics.
Since FHIR is, increasingly, the preferred form for some classes of information systems to exchange information, there should be an appropriate native FHIR encapsulation for important content and context for a device alert.
<devices can and do spew out potentially overwhelming numbers of such alerts. A current technology>
<signals at the patient location, at another clinician location, to a specific individual with fallback if that person is unavailable >
< a party of the cumulative patient record that carries information distinct from periodic measurements>
<existing FHIR resources do not fit the content and context needs of device alerts>
Why existing FHIR resources are not suited to purpose for alerts from devices
Functional interdependence of the alert and the capabilities and settings of the device
Heart rate can be gotten in many different ways
Alerts from devices have distinct requirements due to their nature and the purposes they have in healthcare information systems. They are ubiquitous in monitoring and therapeutic devices in acute care, to the point where they can be a nuisance and even a source of patient safely risk if not properly managed.
DeviceAlert is a general signal of a clinical or technical issue detected by a device, and is subject to multiple distinct uses ('significant event' archiving, notification dispatching, clinical decision support) - this is not tied to only one.
Device alert data handling is a distinct, naturally-delimited logical scope with distinct base standards of, for example, ISO, IEC, IEEE and special data requirements not present in existing FHIR resources.
Links to Device, DeviceMetric, and Patient, and Observation, which show the nature, source and priority of the event.
The representation must accommodate information such as the source, priority or severity, alert kind, duration, current state, multiple signals from the originating device and elsewhere (such as mobile devices), correct location of the patient and of other signaling devices or systems.
-----------
80-20 Rule
cf. Davinci Alerts, Flag,
Why not some extension of something to do this?
Centrality of risk management
Needs to be purpose-built and fitted to the content requirements
Context
- (alarm limit settings) is rather complicated, and totally necessary - "it all flies in formation" and you must be able to probe to the significant facts that distinguish one alert from another
- inherent capabilities of the particular device
- algorithms within the device that do or do not result in an alert
- body site
- body position
---------
DeviceAlert would be clearly bounded from other resources that are related but have a broad scope and similar but not precisely equivalent use cases, for example, Flag, Communication, and Detected Issue. The distinctions from other resources that this proposal is based on are:
- Flag -
- Communication -
- Detected issue -