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

Difference between revisions of "DeviceObservation FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(Created page with " {{subst::Template:FHIR Resource Proposal}}")
 
Line 12: Line 12:
 
<!-- For additional guidance on considerations for resource creation, refer to [[FHIR Resource Considerations]] -->
 
<!-- For additional guidance on considerations for resource creation, refer to [[FHIR Resource Considerations]] -->
  
 
+
=DeviceObservation=
=putProposedResourceNameHere=
 
 
 
<!-- 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 -->
+
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%"
+
This resource describes a set of observations made on a subject by a device, where the observations are entered directly into the patient's EHR. The scope includes observations made by devices on patients, other devices, and locations, and covers all disciplines, locales, and delivery environments. The device is intended particularly to be used for devices that are fixed to patients and provide data directly into a patient's EHR.
  
Scope should consider numerous aspects of breadth of scope, including:
+
The scope of this resource does not include diagnostic reports, which although partially or entirely generated by machines, are subject to the diagnostic service process. There may be some lack of clarity which resource to use with regard to POC testing devices that are managed by a diagnostic service but affixed to the patient. For this reason, the actual observations that are made are the same between the two cases - the difference is one of attribution; a device observation is used when the attribution of the data is made against the device, not the diagnostic service, and also that the Device Observation is only to be used where there is no interpretation prior to entering the data in the EHR.  
* Subject: Human vs. non-human vs. non-patient (e.g. lab bench medicine)
 
* Disciplines: Environmental Health, Palliative, Respiratory, Psychology, Maternity, Clinical Research
 
* 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.
 
-->
 
  
 
==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 observation that is either a battery or a cluster where attribution (performer) is a device
  
 
==Resource appropriateness==
 
==Resource appropriateness==
  
<!-- Does the resource meet the following characteristics?
+
* Devices contribute observations to the EHR directly
 
+
* the provenance (primarily kind, identity and status of the device) may be relevant to the interpretation of the data  
Must
+
* resource is very focused - a container of a group of observations that provides information about how they are grouped and gathered
* 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. -->
+
* devices or proxies/gateways that gather data and provide it to EHRS
 +
* repositories that record patient related observations and make it available for review
  
 
==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? -->
+
* HL7 v2 profiles (IHE and others)
 +
* vital signs section of CCDA
  
 
==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.) -->
+
* vital signs
 +
* 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 could be referenced in any context where patient related observations may be used. Typically, these will be higher level resources (level3+ in Bo's stack)
 
+
* this resource refers to the following other resources:
What resources do you expect this resource reference and in what context?
+
** The standard subject cluster (Patient | Device | Location)
 
+
** The source device
Note: These may be existing resources or "expected" resource
+
** The Observation Resource for the actual observations in the set
 
 
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 -->
+
This resource will be ready for DSTU ballot in Sept
  
 
==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

Revision as of 00:04, 6 June 2013


DeviceObservation

Owning committee name

Health Care Devices (DEV) WG

Contributing or Reviewing Work Groups

FHIR Project Team

FHIR Resource Development Project Insight ID

Unknown

Scope of coverage

This resource describes a set of observations made on a subject by a device, where the observations are entered directly into the patient's EHR. The scope includes observations made by devices on patients, other devices, and locations, and covers all disciplines, locales, and delivery environments. The device is intended particularly to be used for devices that are fixed to patients and provide data directly into a patient's EHR.

The scope of this resource does not include diagnostic reports, which although partially or entirely generated by machines, are subject to the diagnostic service process. There may be some lack of clarity which resource to use with regard to POC testing devices that are managed by a diagnostic service but affixed to the patient. For this reason, the actual observations that are made are the same between the two cases - the difference is one of attribution; a device observation is used when the attribution of the data is made against the device, not the diagnostic service, and also that the Device Observation is only to be used where there is no interpretation prior to entering the data in the EHR.

RIM scope

An observation that is either a battery or a cluster where attribution (performer) is a device

Resource appropriateness

  • Devices contribute observations to the EHR directly
  • the provenance (primarily kind, identity and status of the device) may be relevant to the interpretation of the data
  • resource is very focused - a container of a group of observations that provides information about how they are grouped and gathered

Expected implementations

  • devices or proxies/gateways that gather data and provide it to EHRS
  • repositories that record patient related observations and make it available for review

Content sources

  • ISO 11073-10101.
  • IHE device profiles
  • HL7 v2 profiles (IHE and others)
  • vital signs section of CCDA

Example Scenarios

  • vital signs
  • ECG device
  • wearable glucose monitor
  • wireless heartrate monitor

Resource Relationships

  • this resource could be referenced in any context where patient related observations may be used. Typically, these will be higher level resources (level3+ in Bo's stack)
  • this resource refers to the following other resources:
    • The standard subject cluster (Patient | Device | Location)
    • The source device
    • The Observation Resource for the actual observations in the set

Timelines

This resource will be ready for DSTU ballot in Sept

gForge Users

Grahame