Device-DeviceComponent Merge

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)