eAgenda
- Document consensus decision in Device - Device Definition Parent/HasPart
Proposal to remove parent from DeviceDefinition; leaving DeviceDefinition.hasPart, and Device.parent
- DeviceMetric vs. Device.property (FHIR-39322, also FHIR-39303, FHIR-20857, FHIR-39357)
- Propose to leave DeviceMetric and Device.property as is, cleaning up definitions as per FHIR-39322
- Rationale
- Need ability to reference specific metrics from Observation; not a good way to do this for an element of a resource
- Observation.device reference(Device | DeviceMetric) is normative; not clear what changes to normative content are allowed
- A device may support hundreds of metrics, representing metrics in Device.property means significant increase in size of Device, challenges managing large lists of properties, and frequent updates to Device whenever any metric changes (not the value of the metric, but any of the information around the metric).
- Does not complicate Device.property leading to potential confusion over which elements to use for simple property values, and which to use to represent metrics (which should not have a value in the Device). Eliminates extraneous elements from use cases that don't require DeviceMetric.
- ...
- specialization/conformsTo
- WGM Agenda development
- Meeting schedule until WGM
Attendees
Stefan Karl, Martin Rosner, Javier Espina, Joe Quinn, John Garguilo, Elliot Silver, John Rhoads (presiding DEV co-chair)
Meeting Notes
VOTE to communicate support for retaining hasPart in DeviceDefinition and parent (only) in Device. (Format: Mover, Seconder: Votes in favor - votes opposed - abstentions) Elliott Silver, Martin Rosner: 4-0-1
VOTE Retain DeviceMetric and do not collapse it into superordinate Device, purpose: mainly for dynamic attributes that are specific to the metric (measured or observed) Moved and Seconded - Elliott Silver, Javier Espina, 6-0-1
Follow-up: Elliot Silver will take ticked back to Orders and Observations with comments / tweaks to associated JIRA items
Held for further consideration:
- Matter of naming and usage for Device.specialization (rename to conformsTo?), though informal consensus of this group at this time is that, although "specialization" is a significant term of art in the personal health devices community, "conformsTo" (a standard) is less obscure to others and, with appropriate text references back to the term's history as "specialization", better serves the overall terminologal need.
- The relation of the concept of a setting, present in DeviceMetric as DeviceMetric.category, but lacking a clear explanation of its relation to the content of, for example, Observation, needs disambiguation and usage notes in collaboration with Orders and Observations.
- also for further study, Elliot said that he has filed a JIRA issue ( FHIR-39389 - Getting issue details... STATUS ) regarding the logic and benefits of conforming DeviceDefinition to knowledge resource pattern esp. having a canonical URL.