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 resourcese
"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)
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.
"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.
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