This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "DeviceObservationReport FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
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>
Line 13: Line 12:
  
  
=PutProposedResourceNameHere=
+
=DeviceObservationReport=
 
 
<!-- Resource names should meet the following characteristics:
 
* Lower camel case
 
* U.S. English
 
* Domain-friendly
 
* Short
 
* Clear
 
* Unique
 
* Avoid non-universal abbreviations (e.g. URL would be ok)
 
* Be expressed as a noun
 
* Be consistent with other similar resources
 
-->
 
  
 
==Owning committee name==
 
==Owning committee name==
  
<!-- The name of the committee that is proposed to have responsibility for developing and maintaining the resources. -->
+
[[Health Care Devices (DEV) WG]]
[[YourCommitteeName]]
 
  
 
==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) -->
+
* [[Orders & Observations WG]]
* Work Group Name
 
* or link
 
* or "None"
 
  
 
==FHIR Resource Development Project Insight ID==
 
==FHIR Resource Development Project Insight ID==
  
<!-- Please specify the id of your work group’s PSS for doing FHIR work.  (If submitted but not yet approved, just write “pending”.) The link to the PSS template can be found here: http://gforge.hl7.org/gf/download/docmanfileversion/6832/9398/HL7FHIR_DSTUballotPSS-20120529.doc -->
+
unknown
  
 
==Scope of coverage==
 
==Scope of coverage==
  
<!-- Define the full scope of coverage for the resource.  The scope must be clearly delineated such that it does not overlap with any other existing or expected resource. The scope will be used to govern "what is the set of potential applications to consider when evaluating what elements are 'core' – i.e. in the 80%"
+
The device observation report is used when working with data captured from a device. The device emits data which is converted to a device observation report, and applications that with to present views of the data coming from the machine (e.g. ICU monitoring systems, virtual device views, etc) access the device data by using the resource.
 
+
The resource is applicable to data produced by any device that conforms to ISO 11073-10101.
Scope should consider numerous aspects of breadth of scope, including:
+
Subjects/disciplines = this covers any kind of device that reports status
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
+
location - any
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
+
The scope does not include controlling the device, only receiving ongoing data and status information from the device
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
 
* Locale: Country, region
 
  
As a rule, resources should encompass all of these aspects.
+
Note: this device is a combination of DeviceCapabilities, DeviceLog, and DeviceObservation. All those resources will be dropped in favor of this one - this represents greater clarity around how the use case unfolds after experience using these resources at the connectathon.
-->
 
  
 
==RIM scope==
 
==RIM scope==
  
<!-- 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. -->
+
Observation / Component observations with Device as performer
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
<!-- Does the resource meet the following characteristics?
+
* represents data captured from the device, for monitoring programs
 +
* there is a need to share data from the resource with such programs with a high degree of fidelity to the device logical structure so FDA regulations can be met
 +
* data from the device needs to be kept and shared
  
Must
 
* Represents a well understood, "important" concept in the business of healthcare
 
* Represents a concept expected to be tracked with distinct, reliable, unique ids
 
* Reasonable for the resource to be independently created, queried and maintained
 
 
Should
 
* Declared interest in need for standardization of data exchange</span>
 
* Resource is expected to contain an appropriate number of "core" (non-extension) data elements (in most cases, somewhere in the range of 20-50)
 
* Have the characteristics of high cohesion & low coupling – need to explore whether coupling is good some places, not elsewhere – layers from Bo’s document
 
-->
 
  
 
==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. -->
+
* WestHealth are working on this
 +
* any collection of data from consumer devices (many applications in progress for this, some looking at FHIR)
 +
* Several other data analytics services interested in using FHIR to collect this data
  
 
==Content sources==
 
==Content sources==
  
<!-- List all of the specifications (beyond those in the "standard" (FHIR_Design_Requirements_Sources) list of source specifications) that you’re planning to consult
+
* ISO 11073-10101.
 
+
* IHE device profiles (PCD-01)
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
+
* Existing Device resources
  
 
==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.) -->
+
* ECG device
 +
* wearable glucose monitor
 +
* wireless heartrate monitor
  
 
==Resource Relationships==
 
==Resource Relationships==
  
<!-- What are the resources do you expect will reference this resource and in what context?
+
Uses:
 
+
* Device to identify the actual device from where the data comes
What resources do you expect this resource reference and in what context?
+
* Observation for the actual observations (Device Observation links a set of observations with a device and provides a structure for how they relate to each other)
 
 
Note: These may be existing resources or "expected" resource
 
  
Reference to resources is really only relevant at the "same or higher level" (Bo – fix this wording)
+
Used By:
-->
+
* nothing directly at the moment.
  
 
==Timelines==
 
==Timelines==
  
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
+
* draft already exists (http://hl7.org/implement/standards/fhir/devicedata.htm)
 +
* completion (from existing resource defintions): End-October
  
 
==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.) -->
+
Grahame, Micahel Ekaireb

Revision as of 23:08, 3 October 2013



DeviceObservationReport

Owning committee name

Health Care Devices (DEV) WG

Contributing or Reviewing Work Groups

FHIR Resource Development Project Insight ID

unknown

Scope of coverage

The device observation report is used when working with data captured from a device. The device emits data which is converted to a device observation report, and applications that with to present views of the data coming from the machine (e.g. ICU monitoring systems, virtual device views, etc) access the device data by using the resource. The resource is applicable to data produced by any device that conforms to ISO 11073-10101. Subjects/disciplines = this covers any kind of device that reports status location - any The scope does not include controlling the device, only receiving ongoing data and status information from the device

Note: this device is a combination of DeviceCapabilities, DeviceLog, and DeviceObservation. All those resources will be dropped in favor of this one - this represents greater clarity around how the use case unfolds after experience using these resources at the connectathon.

RIM scope

Observation / Component observations with Device as performer

Resource appropriateness

  • represents data captured from the device, for monitoring programs
  • there is a need to share data from the resource with such programs with a high degree of fidelity to the device logical structure so FDA regulations can be met
  • data from the device needs to be kept and shared


Expected implementations

  • WestHealth are working on this
  • any collection of data from consumer devices (many applications in progress for this, some looking at FHIR)
  • Several other data analytics services interested in using FHIR to collect this data

Content sources

  • ISO 11073-10101.
  • IHE device profiles (PCD-01)
  • Existing Device resources

Example Scenarios

  • ECG device
  • wearable glucose monitor
  • wireless heartrate monitor

Resource Relationships

Uses:

  • Device to identify the actual device from where the data comes
  • Observation for the actual observations (Device Observation links a set of observations with a device and provides a structure for how they relate to each other)

Used By:

  • nothing directly at the moment.

Timelines

gForge Users

Grahame, Micahel Ekaireb