This wiki has undergone a migration to Confluence found Here
Difference between revisions of "DeviceAlert FHIR Resource Proposal"
Jump to navigation
Jump to search
(migrate to Confluence) |
|||
| Line 1: | Line 1: | ||
<div class="messagebox cleanup metadata"> | <div class="messagebox cleanup metadata"> | ||
| − | <div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> | + | Current Version: https://confluence.hl7.org/display/FHIR/DeviceAlert+FHIR+Resource+Proposal<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> |
<div style="background:#F0F0F0"> | <div style="background:#F0F0F0"> | ||
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]] | This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]] | ||
| Line 55: | Line 55: | ||
--> | --> | ||
The DeviceAlert resource is used to represent the status of a simple alarm condition check that a medical device is able to detect. It represents a single alarm only, and alarm can be one of the following type: | The DeviceAlert resource is used to represent the status of a simple alarm condition check that a medical device is able to detect. It represents a single alarm only, and alarm can be one of the following type: | ||
| − | * Physiological alarm (for example: Low SpO2) | + | |
| − | * Technical alarm (for example: Fluid line occlusion) | + | *Physiological alarm (for example: Low SpO2) |
| − | * Advisory alert (for example: Alarm of undocumented timeout prior to a surgical procedure) | + | *Technical alarm (for example: Fluid line occlusion) |
| + | *Advisory alert (for example: Alarm of undocumented timeout prior to a surgical procedure) | ||
Note: | Note: | ||
| Line 87: | Line 88: | ||
<!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | <!--Key resources are justified by CCDA, for resources not deemed "key", what interest is there by implementers in using this particular resource. Provide named implementations if possible - ideally provide multiple independent implementations. --> | ||
| − | * Center for Medical Interoperability will be in collaboration with Dräger Medical to work on the resource definition for the DeviceAlert. | + | *Center for Medical Interoperability will be in collaboration with Dräger Medical to work on the resource definition for the DeviceAlert. |
| − | * Center for Medical Interoperability is going to work on a prototype ACM system around this DeviceAlert resource. | + | *Center for Medical Interoperability is going to work on a prototype ACM system around this DeviceAlert resource. |
==Content sources== | ==Content sources== | ||
| Line 95: | Line 96: | ||
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? --> | Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? --> | ||
| − | * ISO/IEEE 11073 | + | *ISO/IEEE 11073 |
| − | * IHE PCD Technical Framework (ACM profile, PCD-04) | + | *IHE PCD Technical Framework (ACM profile, PCD-04) |
==Example Scenarios== | ==Example Scenarios== | ||
<!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource. They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) --> | <!-- Provide a listing of the types of scenarios to be represented in the examples produced for this resource. They should demonstrate the full scope of the resource and allow exercising of the resources capabilities (full element coverage, inclusion & omission of optional elements, repeating and singleton repeating elements, etc.) --> | ||
| − | * Low SpO2, a physiological alarm from a patient monitoring device. | + | *Low SpO2, a physiological alarm from a patient monitoring device. |
| − | * Fluid line occlusion, a technical alarm from an infusion pump. | + | *Fluid line occlusion, a technical alarm from an infusion pump. |
| − | * An advisory alarm of undocumented timeout prior to a surgical procedure. | + | *An advisory alarm of undocumented timeout prior to a surgical procedure. |
==Resource Relationships== | ==Resource Relationships== | ||
| Line 116: | Line 117: | ||
--> | --> | ||
Uses | Uses | ||
| − | * [http://hl7.org/implement/standards/fhir/device.html Device] | + | |
| − | * [http://hl7.org/implement/standards/fhir/patient.html Patient] | + | *[http://hl7.org/implement/standards/fhir/device.html Device] |
| − | * [http://hl7.org/implement/standards/fhir/location.html Location] | + | *[http://hl7.org/implement/standards/fhir/patient.html Patient] |
| − | * [http://hl7.org/implement/standards/fhir/observation.html Observation] | + | *[http://hl7.org/implement/standards/fhir/location.html Location] |
| − | * [[DeviceComponent]] | + | *[http://hl7.org/implement/standards/fhir/observation.html Observation] |
| + | *[[DeviceComponent]] | ||
Potentially used by | Potentially used by | ||
| − | * [http://hl7.org/implement/standards/fhir/list.html List] (DeviceAlertList profile) | + | |
| + | *[http://hl7.org/implement/standards/fhir/list.html List] (DeviceAlertList profile) | ||
==Timelines== | ==Timelines== | ||
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting --> | <!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting --> | ||
| − | * This proposal will not be addressed in the current DSTU cycle. It is provided as guidance to our intended overall architecture for device communications and will be implemented in the future. | + | *This proposal will not be addressed in the current DSTU cycle. It is provided as guidance to our intended overall architecture for device communications and will be implemented in the future. |
==gForge Users== | ==gForge Users== | ||
Latest revision as of 15:04, 31 October 2019
Current Version: https://confluence.hl7.org/display/FHIR/DeviceAlert+FHIR+Resource+Proposal
This page documents a Pending FHIR Resource Proposal
Contents
- 1 DeviceAlert
- 1.1 Owning committee name
- 1.2 Contributing or Reviewing Work Groups
- 1.3 FHIR Resource Development Project Insight ID
- 1.4 Scope of coverage
- 1.5 RIM scope
- 1.6 Resource appropriateness
- 1.7 Expected implementations
- 1.8 Content sources
- 1.9 Example Scenarios
- 1.10 Resource Relationships
- 1.11 Timelines
- 1.12 gForge Users
DeviceAlert
Owning committee name
Contributing or Reviewing Work Groups
FHIR Resource Development Project Insight ID
TBD
Scope of coverage
The DeviceAlert resource is used to represent the status of a simple alarm condition check that a medical device is able to detect. It represents a single alarm only, and alarm can be one of the following type:
- Physiological alarm (for example: Low SpO2)
- Technical alarm (for example: Fluid line occlusion)
- Advisory alert (for example: Alarm of undocumented timeout prior to a surgical procedure)
Note:
For the initial scope, this DeviceAlert resource is only applicable to the alarm condition produced by any medical device that implements or derives from the ISO/IEEE 11073 standard.
RIM scope
TBD
Resource appropriateness
This DeviceAlert resource is solely used to communicate a single alarm that produced by any medical device that implements or derives from the ISO/IEEE 11073 standard. If there is a need to communicate multiple alarms are triggered from the same medical device, refers to the DeviceAlertList profile for a more appropriate usage.
Expected implementations
- Center for Medical Interoperability will be in collaboration with Dräger Medical to work on the resource definition for the DeviceAlert.
- Center for Medical Interoperability is going to work on a prototype ACM system around this DeviceAlert resource.
Content sources
- ISO/IEEE 11073
- IHE PCD Technical Framework (ACM profile, PCD-04)
Example Scenarios
- Low SpO2, a physiological alarm from a patient monitoring device.
- Fluid line occlusion, a technical alarm from an infusion pump.
- An advisory alarm of undocumented timeout prior to a surgical procedure.
Resource Relationships
Uses
Potentially used by
- List (DeviceAlertList profile)
Timelines
- This proposal will not be addressed in the current DSTU cycle. It is provided as guidance to our intended overall architecture for device communications and will be implemented in the future.
gForge Users
TBD
