Agenda

Continue Device-DeviceMetric-DeviceDefinition topics (see last meeting: 2022-10-26 Wednesday DEV WG and DoF Agenda and Minutes)

Filter for Device Metric Issues to be reviewed at next week's meeting.  

  • Elliot added the following JIRA tickets for discussion (note they are included in the filter):
    • FHIR-39303 - Clarify scope and usage of DeviceMetric 
    • FHIR-39332 -Align DeviceMetric source/parent to recent changes in Device/DeviceDefinition

Device Association

Participants

Javier Espina Perez, Grant Forrest, John Garguilo, Stefan Karl, Tom Kowalczyk, Koichiro Matsumoto, Joe Quinn, Martin Rosner, Elliot Silver, Marti Velezis, John Rhoads (notes)

Meeting Notes

Do we want to drop parent and switch to hasPart in Device (instance not DeviceDefinition)?

(caution: summary below written by John Rhoads, who is trying to be fair but could be said to have a dog in this fight due to being a fan of the IEEE 11073-10201 Domain Information Model. You are of course free to add different points of view)

  • Is upward linking via "parent" a broken aspect of Device instance? 
    • For "it is broken": it's not consistent with the currently prevailing thinking about DeviceDefinition: it does not provide for reuse of "part" data structures; it does not provide for multiples (and counts) of subordinate DeviceDefinition
    • For "it is not broken": instance attributes (Devices) are affected by different use cases and needs are different than for kind attributes (Device).
      • Device.parent has the advantage of enforcing strict containment hierarchy by not permitting more than one parent, and there is simplicity in maintenance of consistent state that way.  
      • Multiples and counts of Device instances contained by a Device instance. But Device instances have distinct identity and independently determined attributes. 
      • Reusability: If you want to preserve attributes of a Device instance between times it has a parent (say, you are switching a module to a different host device), you are free to persist it in a state where it has no parent, and provide it with the new host as a parent at the appropriate time)
      • Certainly, equivalent logic can be accomplished with hasPart in the superordinate Device, but is there a killer use case in which it is unconditionally better?


  • What should happen to Device.specialization?


References

Confluence pages:




  • No labels