This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Alert FHIR Resource Proposal"
Jump to navigation
Jump to search
| (17 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | |||
<div class="messagebox cleanup metadata"> | <div class="messagebox cleanup metadata"> | ||
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> | <div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div> | ||
<div style="background:#F0F0F0"> | <div style="background:#F0F0F0"> | ||
| − | This page documents | + | This page documents an [[:category:Approved FHIR Resource Proposal|Approved]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]] |
</div> | </div> | ||
</div> | </div> | ||
[[Category:FHIR Resource Proposal]] | [[Category:FHIR Resource Proposal]] | ||
| − | [[Category: | + | [[Category:Approved FHIR Resource Proposal]] |
| Line 13: | Line 12: | ||
| − | = | + | =Alert= |
<!-- Resource names should meet the following characteristics: | <!-- Resource names should meet the following characteristics: | ||
| Line 31: | Line 30: | ||
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. --> | <!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. --> | ||
[[Patient Care]] | [[Patient Care]] | ||
| + | |||
| + | (Temporarily managed by FHIR Core with review from Patient care) | ||
==Contributing or Reviewing Work Groups== | ==Contributing or Reviewing Work Groups== | ||
<!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the resource (optional) --> | <!-- Additional work groups that may have an interest in contributing to, or reviewing the content of the resource (optional) --> | ||
| − | + | None | |
| − | |||
| − | |||
==FHIR Resource Development Project Insight ID== | ==FHIR Resource Development Project Insight ID== | ||
| Line 56: | Line 55: | ||
As a rule, resources should encompass all of these aspects. | As a rule, resources should encompass all of these aspects. | ||
--> | --> | ||
| − | An alert is a prospective warnings of things that should be taken notice of when providing care to the patient. They are intended to be displayed to a clinician at the point of providing care, but can be available at other times also. The content of the alert can be anything that is of relevance both clinical and non-clinical. For example "Patient has a big dog at home" is as relevant as "Brittle asthmatic, treat aggressively. Alerts should | + | An alert is a prospective warnings of things that should be taken notice of when providing care to the patient. They are intended to be displayed to a clinician at the point of providing care, but can be available at other times also. The content of the alert can be anything that is of relevance both clinical and non-clinical. For example "Patient has a big dog at home" is as relevant as "Brittle asthmatic, treat aggressively". Alerts may duplicate information captured in other resources - AllergyIntolerance, Observation, Problem, Procedure, etc. The purpose is to flag key information for immediate and/or continuous display to healthcare providers. Detailed information should be captured using the appropriate other resource. For example, in the asthmatic example the clinical content would also be a note against the Problem resource - the purpose of the alert is to ensure that the clinician is aware of it at all times. |
==RIM scope== | ==RIM scope== | ||
| − | + | Observation[classCode=ALRT, moodCode=EVN] | |
<!-- Identify the formal RIM mapping for the root concept of the resource. The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. --> | <!-- Identify the formal RIM mapping for the root concept of the resource. The expectation is that the RIM mapping will be sufficiently precise so as to not overlap with any other resource definition. --> | ||
| Line 76: | Line 75: | ||
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document | * Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document | ||
--> | --> | ||
| + | The alert is a well understood concept, particularly in EMR and EHR systems as it ensures that users are made aware of important information about a patient. | ||
==Expected implementations== | ==Expected 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. --> | <!--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. --> | ||
| + | |||
| + | Any PMS system will likely implement an alerting system. In CCDA, Alerts are grouped with allergies and adverse reactions and so an alert would appear in that section of a CCDA document. However FHIR treats them as a separate resource due to the non-clinical nature of many of the instances. | ||
==Content sources== | ==Content sources== | ||
| Line 86: | Line 88: | ||
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? --> | ||
| + | Existing PMS systems, CCDA, openEHR | ||
==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.) --> | ||
| + | * Record administrative alerts - non payer, drug seeker | ||
| + | * Clinical alerts - brittle asthmatic | ||
| + | * Management alerts - patient is a clinician | ||
==Resource Relationships== | ==Resource Relationships== | ||
| Line 101: | Line 107: | ||
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording) | Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording) | ||
--> | --> | ||
| + | An alert is linked to the patient resource as the subject of the alert, and to a practitioner, patient or device resource as the author of the resource. | ||
==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 --> | ||
| + | Expected to be balloted DSTU in September 2013 | ||
==gForge Users== | ==gForge Users== | ||
<!-- Identify the userids who will require commit access to gForge to maintain the resource. (Ensure all users have registered for gForge.) --> | <!-- Identify the userids who will require commit access to gForge to maintain the resource. (Ensure all users have registered for gForge.) --> | ||
| + | david_hay | ||
| + | |||
| + | ==Issues== | ||
| + | * Added clarification about the specific scope differences between Alerts and things like Problem, AllergyIntolerance, AdverseReaction, Observation, etc. We need to clearly define where one ends and the other begins. | ||
Latest revision as of 05:36, 22 May 2014
This page documents an Approved FHIR Resource Proposal
Contents
- 1 Alert
- 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
- 1.13 Issues
Alert
Owning committee name
(Temporarily managed by FHIR Core with review from Patient care)
Contributing or Reviewing Work Groups
None
FHIR Resource Development Project Insight ID
Pending
Scope of coverage
An alert is a prospective warnings of things that should be taken notice of when providing care to the patient. They are intended to be displayed to a clinician at the point of providing care, but can be available at other times also. The content of the alert can be anything that is of relevance both clinical and non-clinical. For example "Patient has a big dog at home" is as relevant as "Brittle asthmatic, treat aggressively". Alerts may duplicate information captured in other resources - AllergyIntolerance, Observation, Problem, Procedure, etc. The purpose is to flag key information for immediate and/or continuous display to healthcare providers. Detailed information should be captured using the appropriate other resource. For example, in the asthmatic example the clinical content would also be a note against the Problem resource - the purpose of the alert is to ensure that the clinician is aware of it at all times.
RIM scope
Observation[classCode=ALRT, moodCode=EVN]
Resource appropriateness
The alert is a well understood concept, particularly in EMR and EHR systems as it ensures that users are made aware of important information about a patient.
Expected implementations
Any PMS system will likely implement an alerting system. In CCDA, Alerts are grouped with allergies and adverse reactions and so an alert would appear in that section of a CCDA document. However FHIR treats them as a separate resource due to the non-clinical nature of many of the instances.
Content sources
Existing PMS systems, CCDA, openEHR
Example Scenarios
- Record administrative alerts - non payer, drug seeker
- Clinical alerts - brittle asthmatic
- Management alerts - patient is a clinician
Resource Relationships
An alert is linked to the patient resource as the subject of the alert, and to a practitioner, patient or device resource as the author of the resource.
Timelines
Expected to be balloted DSTU in September 2013
gForge Users
david_hay
Issues
- Added clarification about the specific scope differences between Alerts and things like Problem, AllergyIntolerance, AdverseReaction, Observation, etc. We need to clearly define where one ends and the other begins.
