This wiki has undergone a migration to Confluence found Here

Difference between revisions of "DeviceDefinition FHIR Resource Proposal"

From HL7Wiki
Jump to navigation Jump to search
(migrate to Confluence)
Line 50: Line 50:
  
 
==Scope of coverage==
 
==Scope of coverage==
The DeviceDefinition is an adminsitrative resource that includes all relevant attributes to define the kind of device that can be referenced by multiple Devices to provide information that does not change for an instance.
+
This is a specialized resource that defines the characteristics and capabilities of a deviceDevices include durable (reusable) medical equipment, implantable devices, as well as disposable equipment used for diagnostic, treatment, and research for healthcare and public health, as well as devices such as a machine, cellphone, computer, software, application, etc. 
  
The DeviceDefinition can also be used for catalogs or other use cases where the reference to a device is generically to a type of device, not a specific instance of a device.  This may include procedures or observations where the specific device is not known or not relevant.
+
The DeviceDefinition resource is used to describe the common characteristics and capabilities of a device of a certain type or kind, e.g., a certain model or class of a device such as a x-ray model or personal wearable device model, whereas a Device resource documents an actual instance of a device such as the actual x-ray machine that is installed or the personal wearable device being worn
 +
 
 +
The DeviceDefinition is typically used catalogs, publications, or other use cases where the reference to a device is generically to a type of device, not a specific instance of a device.  For example, a catalog of orderable devices, or the mapping of device specific test codes and result values to industry standards.
  
 
Example device definitions include specifications for an x-ray machine, implantable devices, lab analyzers, etc.
 
Example device definitions include specifications for an x-ray machine, implantable devices, lab analyzers, etc.
 
Note that with the acceptance of this proposal, the Device resource scope will be reduced to just the instance related attributes.
 
  
 
<!-- 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%"
 
<!-- 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%"
Line 75: Line 75:
  
 
==Resource appropriateness==
 
==Resource appropriateness==
 +
The DeviceDefinition resource contains the "catalog" definition of a device - whether that definition is authored by the manufacturer or a regulatory entity and allows defining valid hierarchical device configurations (devices as part of other devices).
 +
 +
Device vs deviceDefinition: The Device resource is meant to refer to a physical instance of a device - hence having attributes like lot number, patient, location, operational status which the DeviceDefinition resource does not have.
 +
 
Separating the DeviceDefinition from Device enables more clear distinctions and use considering a number of use cases primarily focus on Device, while others focus on DeviceDefinition.  Furthermore, there will be many more Device instances than there will be DeviceDefinition instances.  The DeviceDefinition would be used in catalogs and go through independent updates from the Device instance.
 
Separating the DeviceDefinition from Device enables more clear distinctions and use considering a number of use cases primarily focus on Device, while others focus on DeviceDefinition.  Furthermore, there will be many more Device instances than there will be DeviceDefinition instances.  The DeviceDefinition would be used in catalogs and go through independent updates from the Device instance.
  
Line 91: Line 95:
  
 
==Expected implementations==
 
==Expected implementations==
Implementations of catalogs, e.g., LIVD as well as implementations needing to reference devices will all directly or indirectly use this device.
+
Implementations of catalogs, e.g., LIVD as well as implementations needing to reference device definitions.  The LIVD implementation guide adresses Lab device manufacturers to document recommended mapping of test codes and result values used on their devices using proprietary/local code systems to (inter)national vocabularies such as LOINC and SNOMED.
  
 
<!--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. -->
Line 97: Line 101:
 
==Content sources==
 
==Content sources==
  
*HL7 FHIR Device, DeviceComponent, and DeviceMetrics
+
*HL7 FHIR Device and DeviceMetrics
 
*HL7 V2 EQU and DEV segments
 
*HL7 V2 EQU and DEV segments
  
Line 105: Line 109:
  
 
==Example Scenarios==
 
==Example Scenarios==
 +
 +
Ordering supplies using SupplyRequest would typically reference DeviceDefinitions rather than specific devices.
 +
 +
Ordering DME would typically reference DeviceDefinitions rather than specific devices.
 +
 +
Standard vocabulary mappings for devices typically define common mappings based on device models, thus DeviceDefinition rather than for each individual device.
  
 
<!-- 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.) -->

Revision as of 15:10, 12 November 2019



DeviceDefinition

Owning Committee Name

Orders & Observations YourWorkGroupName

Committee Approval Date:

Please enter the date that the committee approved this Resource proposal

June 12, 2018 - http://confluence.hl7.org/display/OO/OO+Conf+Call+Minutes+-+Device+-+20180612

Contributing or Reviewing Work Groups

Healthcare Devices

  • Work Group Name
  • or link
  • or "None"

FHIR Resource Development Project Insight ID

PI 952

Scope of coverage

This is a specialized resource that defines the characteristics and capabilities of a device. Devices include durable (reusable) medical equipment, implantable devices, as well as disposable equipment used for diagnostic, treatment, and research for healthcare and public health, as well as devices such as a machine, cellphone, computer, software, application, etc. 

The DeviceDefinition resource is used to describe the common characteristics and capabilities of a device of a certain type or kind, e.g., a certain model or class of a device such as a x-ray model or personal wearable device model, whereas a Device resource documents an actual instance of a device such as the actual x-ray machine that is installed or the personal wearable device being worn

The DeviceDefinition is typically used catalogs, publications, or other use cases where the reference to a device is generically to a type of device, not a specific instance of a device. For example, a catalog of orderable devices, or the mapping of device specific test codes and result values to industry standards.

Example device definitions include specifications for an x-ray machine, implantable devices, lab analyzers, etc.


RIM scope

There does not appear to be a DeviceDefinition concept in the RIM, rather only the Device instance is referenced The Common Product Model touches on elements, but not all.


Resource appropriateness

The DeviceDefinition resource contains the "catalog" definition of a device - whether that definition is authored by the manufacturer or a regulatory entity and allows defining valid hierarchical device configurations (devices as part of other devices).

Device vs deviceDefinition: The Device resource is meant to refer to a physical instance of a device - hence having attributes like lot number, patient, location, operational status which the DeviceDefinition resource does not have.

Separating the DeviceDefinition from Device enables more clear distinctions and use considering a number of use cases primarily focus on Device, while others focus on DeviceDefinition. Furthermore, there will be many more Device instances than there will be DeviceDefinition instances. The DeviceDefinition would be used in catalogs and go through independent updates from the Device instance.


Expected implementations

Implementations of catalogs, e.g., LIVD as well as implementations needing to reference device definitions. The LIVD implementation guide adresses Lab device manufacturers to document recommended mapping of test codes and result values used on their devices using proprietary/local code systems to (inter)national vocabularies such as LOINC and SNOMED.


Content sources

  • HL7 FHIR Device and DeviceMetrics
  • HL7 V2 EQU and DEV segments


Example Scenarios

Ordering supplies using SupplyRequest would typically reference DeviceDefinitions rather than specific devices.

Ordering DME would typically reference DeviceDefinitions rather than specific devices.

Standard vocabulary mappings for devices typically define common mappings based on device models, thus DeviceDefinition rather than for each individual device.


Resource Relationships

  • Device
  • Composition
  • ObservationDefinition
  • Etc.


Timelines

September 2018 inclusion in FHIR R4.


gForge Users

Eric Haas, Jose Costa Teixeira


When Resource Proposal Is Complete

When you have completed your proposal, please send an email to FMGcontact@HL7.org

FMG Notes