This wiki has undergone a migration to Confluence found Here

Difference between revisions of "Device-DeviceComponent Merge"

From HL7Wiki
Jump to navigation Jump to search
Line 1: Line 1:
 
The Orders and Observations workgroup is discussing changes to the Device resource on [http://confluence.hl7.org:8090/display/OO/Device+Resource+Harmonization this] page. One of these changes is about merging the Device and DeviceComponent resources and using them for a harmonized Personal Health Device (PHD) and Point-of-Care Device (PoCD) model.
 
The Orders and Observations workgroup is discussing changes to the Device resource on [http://confluence.hl7.org:8090/display/OO/Device+Resource+Harmonization this] page. One of these changes is about merging the Device and DeviceComponent resources and using them for a harmonized Personal Health Device (PHD) and Point-of-Care Device (PoCD) model.
 +
 +
==Merged Device Resource Proposal==
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 124: Line 126:
  
 
; partNumber
 
; partNumber
: This is an entry from DeviceComponent.productionSpecification. Creating an inline element separates kind from instance and allows to make it a search parameter.
+
: This is an entry from DeviceComponent.productionSpecification. Creating an inline element separates ''kind'' from ''instance'' and allows to make it a search parameter.
  
 
; version
 
; version
Line 144: Line 146:
  
 
; parameterGroup, measurementPrinciple
 
; parameterGroup, measurementPrinciple
: Add as extensions to the VMD and Channel profiles.
+
: Add as extensions to the VMD and Channel Device profiles.
  
 
; languageCode
 
; languageCode

Revision as of 15:15, 3 April 2018

The Orders and Observations workgroup is discussing changes to the Device resource on this page. One of these changes is about merging the Device and DeviceComponent resources and using them for a harmonized Personal Health Device (PHD) and Point-of-Care Device (PoCD) model.

Merged Device Resource Proposal

Device DeviceComponent Merged Device
identifier [0..*] Identifier identifier [0..*] Identifier identifier [0..*] Identifier
udi [0..1] BackboneElement udi [0..1] BackboneElement
status [0..1] code status [0..1] code
operationalStatus [0..*] CodeableConcept statusReason [0..*] CodeableConcept
type [0..1] CodeableConcept type [1..1] CodeableConcept type [0..1] CodeableConcept
specialization [0..*] CodeableConcept
partNumber [0..1] string
lotNumber [0..1] string lotNumber [0..1] string
manufacturer [0..1] string manufacturer [0..1] string
manufactureDate [0..1] dateTime manufactureDate [0..1] dateTime
expirationDate [0..1] dateTime expirationDate [0..1] dateTime
model [0..1] string model [0..1] string
version [0..1] string productionSpecification
– specType
– componentId
– productionSpec
[0..*]
[0..1]
[0..1]
[0..1]
BackboneElement
CodeableConcept
Identifier
string
version
– type
– component
– value
[0..*]
[0..1]
[0..1]
[0..1]
BackboneElement
CodeableConcept
Identifier
string
lastSystemChange [0..1] instant
source [0..1] Reference(Device)
parent [0..1] Reference(DeviceComponent) parent [0..1] Reference(Device)
patient [0..1] Reference(Patient) patient [0..1] Reference(Patient)
owner [0..1] Reference(Organization) owner [0..1] Reference(Organization)
contact [0..*] ContactPoint contact [0..*] ContactPoint
location [0..1] Reference(Location) location [0..1] Reference(Location)
url [0..1] uri url [0..1] uri
note [0..*] Annotation note [0..*] Annotation
safety [0..*] CodeableConcept safety [0..*] CodeableConcept
parameterGroup [0..1] CodeableConcept
measurementPrinciple [0..1] code
languageCode [0..1] CodeableConcept
property
– type
– valueQuantity
– valueCode
[0..*]
[1..1]
[0..*]
[0..*]
BackboneElement
CodeableConcept
Quantity
CodeableConcept
property
– type
– valueQuantity
– valueCode
[0..*]
[1..1]
[0..*]
[0..*]
BackboneElement
CodeableConcept
Quantity
CodeableConcept

Added or changed Elements

statusReason
Captures the reason for an inactive status, e. g. not-ready, standby, or disconnected. Device.status and Device.statusReason together describe the more detailed status information available in DeviceComponent.operationalStatus. The value set shall cover the entries from DeviceComponentOperationalStatus except "on" and "entered-in-error", as well as additional entries proposed in GF#15346.
specialization
New element for multi-purpose PHDs. As an alternative, change Device.type cardinality to 0..* according to GF#15596.
partNumber
This is an entry from DeviceComponent.productionSpecification. Creating an inline element separates kind from instance and allows to make it a search parameter.
version
Many devices have multiple revisions, e. g. for hardware, software, and firmware. Within a device there may be parts with individual revision, e. g. boot loader, operating system, and application software modules with independent versioning. The complex version element can capture these revisions in a flexible way. Device.version.type value set shall cover the "revision" entries from DeviceSpecificationSpecType with preferred or example binding.
parent
Links Device resources together to represent a structured device. Empty parent indicates the top-level resource.
property
Additional properties for PHDs.

Missing Elements

lastSystemChange
Do we really need it or is it covered by Resource.meta.lastUpdated?
source
The top-level Device resource can be determined by following the parent hierarchy.
parameterGroup, measurementPrinciple
Add as extensions to the VMD and Channel Device profiles.
languageCode
Use Resource.language instead as proposed and accepted in GF#15341.

(Return to DoF home page)