The following page is to capture the discussion about the "Specialization" element for Device (and Device Definition).
Current JIRA Tickets
- FHIR-38057 - DeviceDefinition and Device should use same "specialization" modelMeeting adjourned early - due to lack of participates for the topics on hand.
- FHIR-38058 - Device specialization assumes a particular model of standards compliance
- FHIR-39084 - Change .specialization to .conformsTo
- FHIR-39242 - Change .specialization to .conformsTo. See ticket FHIR-39084
- FHIR-39053 - Ambiguity when to use .specialization and when .property element
- FHIR-38902 - Consistency between Device and DeviceDefintion resources
Recommendations
Device
| Device Element | Card | DataType | Short Display | Definition | |
| 0..* | BackboneElement | Identifies the standards, specifications, or formal guidances for the capabilities supported by the device. | Identifies the standards, specifications, or formal guidances for the capabilities supported by the device. The device may may be certified as conformant to these specifications e.g., communication, performance, process, measurement, or specialization standards. | |
| 1..1 | CodeableConcept | Identifies the standard, specification, or formal guidance that the device adheres to | ||
| 0..1 | string | Identifies the specific form or variant of the standard, specification, or formal guidance | |||
| 0..1 | Coding | Describes the common type of the standard, specification, or formal guidance communication | performance | measurement | risk class | electrical | material | exchange |
DeviceDefinition
Requires clarification for the DeviceDefinition.classification.type that previously included risk class. Risk class is now part of the conformsTo element.
| Device Element | Card | Proposed DataType | Proposed Description | |
| 0..* | BackboneElement | Identifies the the standards, specifications, or formal guidances for the capabilities supported by the device. | |
| 0..1 | Coding | Describes the common type of the standard, specification or formal guidance communication | performance | measurement | risk class | electrical | material | exchange | ||
| 1..1 | CodeableConcept | Identifies the standard, specification or formal guidance that the device adheres to | |
| 0..1 | string | Identifies the specific form or variant of the standard, specification or formal guidance | ||
| 0..* | RelatedArtifact |
----------------------------------Anything below was used for discussion purposes only------------------------------------------------------
Device
Current State (in Device)
| Device Element | Card | DataType | Current Description | |
| 0..* | BackboneElement | The standard(s) the device supports | ||
| 1..1 | CodeableConcept | Code of the system that identifies the standard that the device adheres to Device Specialization System Type (Example) | ||
| 0..1 | string | Standard version used | ||
| 0..1 | Coding | communication | performance | measurement FHIRDeviceSpecializationCategory (Example) |
Option #1: Changes to element names (in Device) and new proposed definitions (below)
| Device Element | Card | DataType | |
| 0..* | BackboneElement | |
| 1..1 | CodeableConcept | |
| 0..1 | string | ||
| 0..1 | Coding |
Option #2 - Proposed changes (in Device)
| Device Element | Card | DataType | Proposed Description | |
| 0..* | BackboneElement | Identifies the standards or specifications for the capabilities supported by the device. | ||
| 1..1 | CodeableConcept | Identifies the standard or specification that the device adheres to | ||
| 0..1 | string | Identifies the specific form or variant of the standard or specification | ||
| 0..1 | Coding | Describes the common type of the standard or specification communication | performance | measurement | risk class | electrical | material | |
Device Definition
Current State in DeviceDefinition
| Device Element | Card | DataType | Proposed Description | |
| 0..* | RelatedArtifact | The capabilities supported on a device, the standards to which the device conforms for a particular purpose, and used for the communication |
Change to DeviceDefinition
| Device Element | Card | Proposed DataType | Proposed Description | |
| 0..* | BackboneElement | Identifies the standards or specifications for the capabilities supported by the device. | |
| 0..1 | Coding | Describes the common type of the standard or specification communication | performance | measurement | risk class | electrical | material | | ||
| 1..1 | CodeableConcept | Identifies the standard or specification that the device adheres to | |
| 0..1 | string | Identifies the specific form or variant of the standard or specification | ||
| 0..* | RelatedArtifact |
Summary Table
| Option--> | Option #1 - Specialization → conformsTo | Option #2 - Specialization |
|---|---|---|
| Description | Change the name of the element to "conformsTo" | Keep name of element as "Specialization" and updates to the descriptions/comments |
| Discussion | This can be used for any standard (beyond 11073 where the name of the element originated). Need to assess the impact of changing the name for systems that have specialization in production | Used in production (re: 11073 implementation) Need additional examples of standards |
| Proposed changes | Device.conformsTo
DeviceDefinition.conformsTo
Clarify use of conformsTo versus property and DeviceDefinition.classification.type | Device.specialization Clarify use of specialization versus property Add DeviceDefinition.specialization
Clarify use of conformsTo versus property and DeviceDefinition.classification.type |
1 Comment
Javier Espina
The device specialization categories "measurement" and "performance" sound overlapping - at least for devices with the intended use of monitoring / measuring