Agenda

  1. Device and DeviceDefinition (OO) open issues, including settings
  2. DeviceMetric tickets

Attendees

Javier Espina Perez, Grant Forrest, John Garguilo, Stefan Karl, Tom Kowalczyk, Koichiro Matsumoto, Joe Quinn, Elliot Siver, Marti Velezis, John Rhoads

Meeting Notes

  1. Discussion of: Should the DeviceMetric go the way of the dodo and its present and all future associated attributes go into Device.property?
    1. John Rhoads  put some claims in Device Settings (Device, Device Metric, Observation) trying to support the importance of DeviceMetrics to potential future handling of dynamic attributes, settings, alerts and alarms
    2. The page referenced has JIRA ticks discussing proposed fields to add to DeviceMetric, viz.:

      • FHIR-33534 - Make metric availability an element of DeviceMetric

      • FHIR-33535 - Make technical range an element of DeviceMetric

      • FHIR-33536 - Make resolution an element of DeviceMetric

    3. Device.property would then be a very heterogeneous "et cetera vector" potentially containing unrelated things that would be very different in their meaning and usage patterns. Confusing. Marti Velezis  suggested that contained metric data might better be its own 0..* backbone element in Device
      1. Then what Device instances should and should not host such metric content?
        1. The PoCD IG approach would have it follow the ISO/IEEE 11073-10101 hierarchy with the top-level Medical Device System's Device resource containing one or more Virtual Medical Device (subsystem) resources, in turn containing one or more Channel Device resources, which would under the contained metric approach would then contain a vector of metric backbone elements, which then would be referred to from Observation resources. As Javier Espina  pointed out, this resource is normative and not so easily altered from referring to Device or DeviceMetric in its Device Field. Additionally this would require a way of referring to individual instances of the metric backbone element, which seems an exotic complication. Elliot Silver: see the approach to a somewhat similar problem arising in relation to Provenance  at https://build.fhir.org/extension-targetelement.html
        2. Other approaches than the ISO approach to using such a metric element in Devices might be preferred in other use cases. This is an unknown pending someone putting forward such alternative uses.
      2. Question: what are the relative usage challenges and data management efficiency of a lot of DeviceMetric instances versus the device-metric-like backbone element vector nested in the Device resource be?
      3. Next actions: Marti Velezis and Elliot Silver volunteered to look at that comparison for next Wednesday's meeting 2022-12-07 Wednesday DEV WG and DoF Agenda and Minutes

References

  • No labels