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

Difference between revisions of "DeviceCapabilities FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with "{{subst::Template:FHIR Resource Proposal}}")
 
 
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
 
+
'''Replaced by [[DeviceComponent_FHIR_Resource_Proposal]]'''
−
<div class="messagebox cleanup metadata">
 
−
<div style="float: left;">[[Image:OpenHotTopic.GIF|35px| ]]</div>
 
−
<div style="background:#F0F0F0">
 
−
This page documents a [[:category:Pending FHIR Resource Proposal|Pending]] [[:category:FHIR Resource Proposal|FHIR Resource Proposal]]
 
−
</div>
 
−
</div>
 
−
[[Category:FHIR Resource Proposal]]
 
−
[[Category:Pending FHIR Resource Proposal]]
 
  
  
Line 13: Line 5:
  
  
−
=putProposedResourceNameHere=
+
= DeviceCapabilities =
−
 
 
−
<!-- 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) -->
+
FHIR Project Team
−
* 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 -->
+
[http://www.hl7.org/special/Committees/projman/searchableProjectIndex.cfm?action=edit&ProjectNumber=1103 Project Insight 1103]
  
 
==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 capabilities and log resources are used when communicating with a device, either directly or indirectly via a proxy (usually the second). When a channel is opened with the device or it's proxy, it first sends the Capabilities resource, and then a series of log resources. The Capabilities resource describes how the DeviceLog resources are interpreted - they are simply raw data in as concise a form as possible.
  
−
Scope should consider numerous aspects of breadth of scope, including:
+
* The resource is applicable to any device that conforms to ISO 11073-10101.  
−
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
+
* Subjects/disciplines = this covers any kind of device that reports status
−
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
+
* location - any
−
* Delivery environment (Community, Geriatric, Home care, Emergency, Inpatient, Intensive, Neonatal, Pediatric, Primary)
+
* The scope does not include controlling the device, only receiving ongoing data and status information from the device
−
* Locale: Country, region
 
−
 
 
−
As a rule, resources should encompass all of these aspects.
 
−
-->
 
  
 
==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. -->
+
An Act, but it appears that we have never modeled this kind of thing - no suitable structural vocabulary appears to exist.
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
−
<!-- Does the resource meet the following characteristics?
+
* This represents a rendition of the current ISO standard in a simpler to use format. There is already standardised data exchange. This resource represents a desire to have a simpler more accessible format for it
−
 
+
* This resource should be understood as a transient structure separating data and metadata that leads to a device observation
−
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. -->
+
* All kinds of devices that report data (or proxy/facades to them)
  
 
==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
−
Are there any source specifications that you wish to consult but are concerned about access to or expertise to consider? -->
 
  
 
==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?
+
* This resource will reference the "Device" resource so that a capabilities statement may reference an individual identified device.
−
 
+
* The DeviceLog resource may refer to the capabilities statement that describes how it is interpreted
−
What resources do you expect this resource reference and in what context?
 
−
 
 
−
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)
 
−
-->
 
  
 
==Timelines==
 
==Timelines==
  
−
<!-- Indicate the target date for having the resource complete from a committee perspective and ready for vetting and voting -->
+
Ready for ballot for Sept DSTU
  
 
==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

Latest revision as of 20:29, 20 July 2016

Replaced by DeviceComponent_FHIR_Resource_Proposal



DeviceCapabilities

Owning committee name

Health Care Devices (DEV) WG

Contributing or Reviewing Work Groups

FHIR Project Team

FHIR Resource Development Project Insight ID

Project Insight 1103

Scope of coverage

The device capabilities and log resources are used when communicating with a device, either directly or indirectly via a proxy (usually the second). When a channel is opened with the device or it's proxy, it first sends the Capabilities resource, and then a series of log resources. The Capabilities resource describes how the DeviceLog resources are interpreted - they are simply raw data in as concise a form as possible.

  • The resource is applicable to 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

RIM scope

An Act, but it appears that we have never modeled this kind of thing - no suitable structural vocabulary appears to exist.

Resource appropriateness

  • This represents a rendition of the current ISO standard in a simpler to use format. There is already standardised data exchange. This resource represents a desire to have a simpler more accessible format for it
  • This resource should be understood as a transient structure separating data and metadata that leads to a device observation

Expected implementations

  • All kinds of devices that report data (or proxy/facades to them)

Content sources

  • ISO 11073-10101.
  • IHE device profiles

Example Scenarios

  • ECG device
  • wearable glucose monitor
  • wireless heartrate monitor

Resource Relationships

  • This resource will reference the "Device" resource so that a capabilities statement may reference an individual identified device.
  • The DeviceLog resource may refer to the capabilities statement that describes how it is interpreted

Timelines

Ready for ballot for Sept DSTU

gForge Users

Grahame

Retrieved from "https://wiki.hl7.org/w/index.php?title=DeviceCapabilities_FHIR_Resource_Proposal&oldid=123157"