Skip to end of metadata
Go to start of metadata

Attendees: Brian Reinhold, Ralf Herzog, Marti Velezis, Stefan Karl, George Dixon, John Rhoads, Michael, Hans Buitendijk, Martin Rosner, Bob Dieterle, Asim Muhammed, Erik Moll, Ana Kostadinovska, Myron Finseth, Kathy Walsh


Topics:

  • Updated spreadsheet at end of meeting:
  • Confirmed that the reference to DeviceDefinition in Device should be 0..1.
    • Since there is only one element in the "group" I removed that level, so just have deviceDefinition 0..1 Reference(DeviceDefinition) in the spreadsheet now.
  • Confirmed that we can use udiCarrier as the name for the data set in the spreadsheet.
  • Confirmed that manufacturer, deviceName, and modelNumber can be in Device as it enables "fuzzy" identification of a device when other data is not available.  This would also enable the data to be populated according to a profile when other identifying data is or could be used, but for convenience this data is populated instead as it is the only data needed.
  • Confirmed that partNumber needs to be included as this is not the same as modelNumber.
  • The feedback on specialization is to consider it an extension as it appears to apply just to PHD.  This will be further discussed during the HCD call tomorrow.
    • A key question to consider whether this is different then would be documented on a DeviceDefinition is whether the cardinality varies.
  • We updated the questions for property whether a timing element is needed.  That requires input from II and Medication, while considering that to date, changes of that type of information typically used Observation.  We need to clarify how DeviceMetric would relate to that.  However, that would not need to be addressed/resolved immediately. 
  • Confirmed that we do not need the usedFor construct, which was removed.
  • We agreed that for the core resource we need just url 0..1, but will add an extension that would allow for:
    • networkAddress
      0..*

      url
      1..1uri

      purpose
      1..1CodeableConcept
  • We agreed that the core resource needs a basic, overall status and reason, but that the additional status/state attributes are of interest to specific devices only.  Those were moved to the extensions.
    • operationalQualificationStatus
      0..1CodeableConceptpassed test | failed test
      Indicates whether the instance is ready for operational use after maintenance or manufacturing.
      equipmentState
      0..1CodeableConceptThe status that the equipment was in at the time that the transaction was initiated.
      controlState
      0..1CodeableConceptThe current state of control associated with the equipment.  An equipment can either work autonomously ('Local' control state) or it can be controlled by another system, e.g., LAS computer ('Remote' control state).  
      alertLevel
      0..1CodeableConceptThe highest level of the alert state (e.g., highest alert severity) that is associated with the indicated equipment (e.g., processing event, inventory event, QC event).  
  • There was not much support for a lastSystemChange date/time.  However, Bob Dieterle was not on the call at that time to provide his rationale.  We put it into the extensions in case metadata and/or provenance/history cannot handle the intended purpose, and then if there is more clarity putting it into the core definition.
  • For deviceComponent merge, we agreed to accommodate the common case in the core resource (parent 0..1) and then have an extension if further timing is needed:
    • part of
      0..1
      The device that this component is part of.

      parent
      1..1Reference(Device)The parent device

      startDate
      0..1DateTimeThe start date/time the component was part of the parent

      endDate
      0..1DateTimeThe end date/time the component was part of the parent
  • With that we got to the end of the list with two open topics on the Device side:
    • how to address specialization (to be discussed at HCD call tomorrow)
    • anything else missing that we did not catch (other than DeviceMetrics/property discussion).
  • Next steps:
    • Vote on acceptance of Device attributes to be what we want for Device in R4 and adjust the definition of Device to focus on the instance of a device.
    • Review DeviceDefinition columns to look for anything glaring missing and vote on putting that into Draft for R4 (FMM0).
    • Update FHIR R4 build.
  • No labels