This wiki has undergone a migration to Confluence found Here
Device-DeviceComponent Merge
Revision as of 14:39, 3 April 2018 by Stefankarl (talk | contribs)
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.
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 profiles.
- languageCode
- Use Resource.language instead as proposed and accepted in GF#15341.