Meetings

Date

Meeting

Link to notes




2023-01-18WGM - OO Q42023-01-16-20+WGM
2023-01-20WGM - OO - Q1 2023-01-16-20+WGM

Status: Completed


For final action on this issue, refer to the following JIRAs: FHIR-32271

Note - Option 4 below with modifications were accepted.

Recommendation

HasPart in DeviceDefinition and Parent in Device

  • Remove parentDevice from DeviceDefinition resource
  • No change to hasPart backbone in DeviceDefinition resource
  • No change to Device resource

Topic for Discussion

  • Develop and discuss options 
  • Rule out any options that pose issues for implementation

Discussion Notes

JIRA Ticket - FHIR-32271  DeviceDefinition.parentDevice and DeviceDefinition.hasPart allow same concept to be modeled in two ways

Previous disposition included: 

  • Remove parent/parentDevice from device/deviceDefinition and use hasPart in both device/deviceDefinition. (quantity remains on deviceDefinition).  Ensure search parameters are updated appropriately.

Discussion from WGM

  • We should align on the same approach for Device and DeviceDefinition parent element (renamed for consistency with Device) allows easy identification of top-level devices when there is no parent device/deviceDefinition; on the other hand, the idea of a top-level device is hard to define because anything could later be incorporated into something else.
  • hasPart allows identification of child parts by quantity, without having to link to the same child part multiple times.
  • having a parent link makes it difficult to reuse the same component in different devices
  • Neither approach presents a better match for the FHIR principal of new points to old. We should not have multiple links because two-way traversal is handled by include/revInclude
     

History of change to DeviceDefinition.hasPart

  • FHIR-30505

    • Rationale:  A model of medical device may include other medical devices as parts. Is is in most cases useful to answer the question "What are the devices parts of the current one?", rather than to answer the question "What device embeds the current one?"  The data element parentDevice enables to answer the second question, not the first one. Moreover, a screw is a device that may be part of the composition of multiple devices. It is more important to know what are the screws used in the current device than the other way round.

    • Disposition included the following:  comment on hasPart: this element is not to be used to represent other relationships across devices than "has part". Other relationships are to be handled with the .relatedDevice element exclusively. (2021-03-01 08:28)

    • June 2021 - applied in the build
  • hasPart includes .count that was needed to identify the number of child devices in the parent
 

Options



Parent (only) on Device and Device DefinitionHasPart (only) on Device and Device DefinitionParent and HasPart on Device Definition (current state)HasPart in DeviceDefinition and Parent in Device
Description

Device.parent allows the instance of a device to reference its parent (0..1)

DeviceDefinition.parentDevice allows the kind of devices to be associated to (0..1 ) parent device definitions. 

(Note - need to rename DeviceDefinition.parentDevice to DeviceDefinition.parent if it is retained on DeviceDefinition)

Device does not currently include hasPart.

DeviceDefinition.hasPart includes a "count" attribute as well as Reference(DeviceDefinition)

No change to Device resource will be made.

This option would require DeviceDefinition to include an explanation when hasPart is used and when .parentDevice is used.


(Note - need to rename DeviceDefinition.parentDevice to DeviceDefinition.parent if it is retained on DeviceDefinition)

Remove parent from DeviceDefinition as there is no real good use/reason to have it when hasPart supports all the use cases and only have parent in Device as that is the only direction needed for devices as a particular device can only be part of another device at any point in time. 
Pros


Enforces that Device instances are only a component of a single parent Device.

Allows swapping in new component Devices without modifying the parent Device

Updates to components are recorded as changes to the parent.

Supports currently known use cases.

Enforces that Device instances are only a component of a single parent Device.

Allows swapping in new component Devices without modifying the parent Device

Cons

DeviceDefinition.hasPart.count will be removed, removing support for a device being able to be defined for use in multiple other devices (a LIVD requirement).  There is no other alternative than as that effectively would be a hasPart.

This is a breaking change in Device if the Device.parent element was removed.Confusing as to when to use parent vs. hasPart when effectively parent is not needed, thus Device would still be accessed differently.Inconsistent access paths
Use Cases 

Add POCD Use Cases here

Add Pharmacy/Medication Admin Use Cases here 



Add Laboratory Use Cases here

Add Laboratory Use Cases here




Recommendation

Working GroupRecommendation
DEV WG

2022/12/14:

Voted within WG to:

  • to keep Device.parent and DeviceDefinition.hasPart
  • to remove DeviceDefinition.parent

Although there is value in consistency, it was felt that parent suits the Device use better, since it prevents a single component from being placed in multiple parent devices, while hasPart suits DeviceDefinition better, since it permits reuse of component definitions across multiple parent definitions. hasPart also allows specifying a count of components, which is appropriate to DeviceDefinition, while Device need to know the actual components.

Detailed proposed changes (not voted on):

  • DeviceDefinition
    • remove parentDevice
    • remove parent SearchParameter
    • update hasPart short to "Definitions of component parts (devices) of this device"
    • update hasPart definition to "The definitions of component devices which are direct parts of the presently defined device. A device may be composed of subordinate real or virtual component devices (e.g. a mechanical part, or an electronic "channel"). The current DeviceDefinition may reference the DeviceDefinitions of component parts. Note the component DeviceDefinitions may be used standalone in some use contexts, or may be reused across multiple parent devices."
    • update hasPart comment to:
An example of the hasPart relationship would be blood pressure, oximeter, and temperature modules which can be plugged into a vital signs monitor. The vital signs monitor DeviceDefinition would have a hasPart element for each of the separate module DeviceDefinitions, each with a count of 1.
DeviceDefinition describes the device-component relationship from the device to the component; Device describes the relationship from the component to the parent device. Both approaches allow traversing the hierarchy in either direction, but the approach adopted by each resource type offers benefits to the expected uses of that resource type."
    • add a search parameter for hasPart (name to be deterimined, as hasPart may be confusing with `has` search operator)
  • Device
    • update parent short to "Encompassing device of which this device is a component"
    • update parent definition to "The immediate next higher-level or encompassing device that the present device is a part of. A device may be a real or virtual component (e.g. a mechanical part or an electronic "channel") of another device. In some uses a device may be standalone, while in other uses it is part of another device; in all cases a particular device instance is only part of one parent device at any point in time." 
    • update parent comment to:
An example of the parent relationship would be blood pressure, oximeter, and temperature modules which can be plugged into a vital signs monitor. These modules are represented as separate Devices with, when connected, their parent elements all referencing the vital signs monitor Device.
Device describes the device-component relationship from the component to the parent device; DeviceDefinition describes the relationship from the device to the component. Both approaches allow traversing the hierarchy in either direction, but the approach adopted by each resource type offers benefits to the expected uses of that resource type.
OO/HCP WG

Use Cases Inventory

Note: the use cases below were identified, but not yet linked to any of the options listed above.  

POCD

  • Central Venous Catheter - multi-lumen (2-5 lumens)
  • Endo bronchial tubes - 2 tubes bonded together
  • Glucose meter may connect to multiple data managers in the healthcare facility
  • Ventilator or Patient Monitor that is composed of several sensors and/or actuators (may be devices themselves) - collect measurements and alerts, calculate and/or summarize parameters
  • Transport Monitor - acts a fully independent patient monitoring device during transport and becomes part of a Bedside Monitor when clicked onto it

Lab-related

  • Module with 2 ISE electrodes
  • Container with multiple reagents - and possible test/test kits it is used with

Miscellaneous

  • Devices that send the observation to two or more other devices (note - the gateway may pass these individually to multiple endpoints - need to differentiate the device parts from other elements in the device resource)

Supporting Information


Figure: POCD Profiles Diagram

https://build.fhir.org/ig/HL7/uv-pocd/profiles.html



Comparison of Device parent vs. hasPart design (with DeviceDefinition using only hasPart)

With the parent approach, Lead1 can only be associated with a single EEG at a time, and moving the lead to another EEG is recorded as a change to the lead. This models reality in that a part can only be in a single place at one time; it is also more robust since it is a single change.

With the hasPart approach moving a lead to another EEG is a change to both the originating and destination EEGs. It is possible that, through an error, etc., two EEGs could have the same lead as a part. This models reality in that moving a part from one device to another is a change to the parent device, not to the part.



If we go with DeviceDefinition.hasPart (only) and Device.parent, potential changes include:


1 Comment

  1. Grant Forrest

    Martin Hurrell asked me to remind the group that if Use Cases from anesthesia are being sought, there is a wealth of them in the Anesthesia DAM which gained approval in Feb 2022.
    Intraprocedure Domain Analysis Project
    For a detailed exposition of non-communicating "invasive" devices in terms of their parts and relationships, in particular needles, tubes and catheters, please see this post:
    https://www.lunariaclinical.co.uk/2022/02/15/invasive-devices-on-fhir/