Device Alerting (DEVAL) Project – Overview
The HL7 PSS-2005 Device Alerting DEVAL project, is focused on the exchange of medical device alarm and alert information using HL7 FHIR.
Project deliverables include a proposed new FHIR resource: DeviceAlert, and an implementation guide specifying how device alerting should be achieved within a FHIR-based ecosystem.
<github>
<DeviceAlert>
<Device Module>
<confluence pages consolidation>
STOPPED RENOVATION HERE 2023.09.09
References
Draft DeviceAlert rationale mockup
Draft DeviceAlert element definitions mockup
Draft DeviceAlert structure mockup
Module: Devices (Current JIRA Tickets and Device Module Content - DRAFT FOR REVIEW)
Old placeholder proposal migrated to Confluence from wiki: DeviceAlert FHIR Resource Proposal
- Resources should have a clear boundary; one that matches one or more logical transaction scopes
- 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.
- Resources should differ from each other in meaning, not just in usage (e.g., each different way to use a lab report should not result in a different resource) and a distinct body of existing practice
- 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 transaction scope with distinct base standards of, for example, ISO, IEC, IEEE and special data requirements
- 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.
- Resources need to have a natural identity
- The concept would be seen as self explanatory by people familiar with monitoring.
- Resources should be very common and used in many different business transactions
- Device alerts are certainly very common, to the point of being a nuisance when misdirected.
- Resources should not be specific or detailed enough to preclude support for a wide range of business transactions
- Resources should be mutually exclusive
- Generated from a device not an information system.
Mention that it is aligned with standards of regulatory significance like IEC 60601-1-8, IEEE 11073 DIM
A result of a risk management process for insuring safety, effectiveness, and securityThere are ways of managing this information in HL7 V2, such as IHE Alert Communication Management
- Resources should use other resources, but they should be more than just compositions of other resources; each resource should introduce novel content
- DeviceAlert content is dictated by standards that are not applicable
- Resources should be organized into a logical framework based on the commonality of the resource and what it links to (see resource framework below)
- Links to Device, DeviceMetric, and Patient, and Observation, which show the nature, source and priority of the event.
- Resources should be large enough to provide meaningful context; resources that contain only a few attributes are likely too small to provide meaningful business value
- Contains significant unique content, comparable to other device-related resources
- Resources should reflect general usage
- 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.
- if most systems treat something as a single concept, that suggests a single resource; if most systems treat something as a distinct concepts, then that suggests multiple resources
- Corresponds closely to the single concept of an event or state in a device that requires action or recording.
- if two different uses of a "resource" would result in wildly different interpretations of what constitutes "core" then that suggests two resources might be appropriate.
- Discuss in relation to Observation, Flag
- There is a bias towards fewer resources rather than more
Relevant existing FHIR resources
"A flag is a warning or notification of some sort presented to the user - who may be a clinician or some other person involved in patient care. It usually represents something of sufficient significance to warrant a special display of some sort - rather than just a note in the resource. A flag has a subject representing the resource that will trigger its display. This subject can be of different types, as described in the examples below:
- A note that a patient has an overdue account, which the provider may wish to discuss with them - in case of hardship for example (subject = Patient)...
...The purpose of a Flag is to alert practitioners to information that is important to influence their interaction with a Patient prior to detailed review of the record...
...In line with its purpose, a flag is concise, highlighting a small set of high-priority issues among the much larger set of data in the chart. "
JR Comment: a device alert falls within the broad scope of "flag", but what is needed is a carrier for the specific content important to the automated processing of a device alert typically resulting in near real-time notification of a person, typically a clinician in the patient vicinity able to respond.
JE Comment: the scope and usage as well as boundaries of "flag" are focused on highlighting selected relevant information from a patient record, whereas device alerts are not typically extracted from or recorded in the patient record.
JE Comment: the scope and usage of "flag" is focused on display of the warning or notification, whereas device alerts may also use other types of signal manifestations: audible (e.g. beeping patterns), tangible (e.g. vibration of handheld alert communicator).
"Indicates an actual or potential clinical issue with or between one or more active or proposed clinical actions for a patient; e.g. Drug-drug interaction, Ineffective treatment frequency, Procedure-condition conflict, etc."
JR Comment: Device alerts are not necessarily clinical issues (technical advisories are within scope) and are differently processed and directed from detected issues.
"A clinical or business level record of information being transmitted or shared; e.g. an alert that was sent to a responsible provider, a public health agency communication to a provider/reporter in response to a case report for a reportable condition...
...The purpose of a Communication resource is to surface that data was shared to track adherence to guidelines or protocols or to provide business documentation of actions taken. Communication can also be used as part of an information exchange to provide context about the information sharing occurring...
...Flag resources represent a continuous ongoing "communication" alerting anyone dealing with the patient of certain precautions to take or issues to be aware of. The flags are continuously present as an ongoing reminder. This is distinct from Communication where there is a specific intended sender and receiver and the information is delivered only once."
JE Comment: Device alerts are not necessarily (or even usually) targeted at a specific intended receiver. In addition, device alerts are not sent with the purpose of "adherence to guidelines or protocols or to provide business documentation of actions taken".
"Measurements and simple assertions made about a patient, device or other subject...
...At its core, Observation allows expressing a name-value pair or structured collection of name-value pairs. As such, it can support conveying any type of information desired. However, that is not its intent. Observation is intended for capturing measurements and subjective point-in-time assessments. It is not intended to be used for those specific contexts and use cases already covered by other FHIR resources."
JE Comment: Device alerts are not "intended for capturing measurements and subjective point-in-time assessments".
DaVinci Profile of MessageHeader
Messaging
Search
Subscriptions
Confluence reference pages on resource principles and process
Section of FHIR Confluence Space devoted to information for people doing FHIR-related design work: Designers
The following relevant pages are in that section:
It is also worthwhile browsing the titles of the other pages in the FHIR Confluence "space", especially in the space's subdivisions marked "Designers", "Implementers",
and "Individuals Interested in FHIR IG Development"
DEV Resource Process References
An example Resource Proposal:
Outline
1 Owning work group name:
2 Committee Approval Date:
3 Contributing or Reviewing Work Groups:
4 FHIR Resource Development Project Insight ID:
5 Scope of coverage:
6 RIM scope:
7 Resource appropriateness:
8 Expected implementations:
9 Content sources:
10 Example Scenarios:
11 Resource Relationships:
12 Resource Boundaries:
13 Timelines:
14 gForge Users:
15 When Resource Proposal Is Complete:
16 FMG Notes
e