Device-DeviceComponent Merge

From HL7Wiki
Revision as of 12:15, 22 May 2018 by Stefankarl (talk | contribs) (Completing UDI; adding specialization elements)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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. This proposal has been worked out in the Devices on FHIR project.

Merged Device Resource Proposal

Device DeviceComponent Merged Device
identifier [0..*] Identifier identifier [0..*] Identifier identifier [0..*] Identifier
udi
– deviceIdentifier
– name
– jurisdiction
– carrierHRF
– carrierAIDC
– issuer
– entryType
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
BackboneElement
string
string
uri
string
base64Binary
uri
code
udi
– deviceIdentifier
– name
– jurisdiction
– carrierHRF
– carrierAIDC
– issuer
– entryType
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
[0..1]
BackboneElement
string
string
uri
string
base64Binary
uri
code
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
– type
– version
[0..*]
[0..1]
[0..1]
BackboneElement
CodeableConcept
string
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

Device and DeviceComponent definitions are from FHIR R4 ballot #1 (3.3.0). Green fields mark elements added to the merged Device resource. Yellow fields mark changed elements.

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 requested in 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)