Agenda

Elliot Silver's question: relating observed values from a device, say, PEEP in a CPAP device, to a PEEP setting for that value in the Observation resources on FHIR

Attendees

Todd Cooper Stefan Karl Martin Hurrell Koichiro Matsumoto Bjoern Andersen John J. Garguilo Brian Reinhold Tom Kowalczyk John Rhoads 

Meeting notes

Note:  Condolences to our Japanese colleagues - especially Koichiro Matsumoto  - for the sad loss of life there this last weekend.  You are all in our thoughts and hearts.


The background to this discussion is in a Zulip thread "#devices > Device settings" which you should read to make the following intelligible, including the most recent entry indicating the current preferred approach is the following:

Elliot Silver3:41 PM

We had a chance to discuss on today's O&O call. My approach, for now, will be a variation on:

    1. Use the existing hasMember or derivedFrom or (less cleanly) component elements to reference from clinical observation to the settings in effect. The chief downside to this is that the semantics of those elements is really right for this use.

Clinical Observation.hasMember of a "settings set" Observation, which hasMember of the individual settings Observations.

Note that if you start at the top of the thread you will see that the above approach is one of several that Elliot suggested, but that there were other options and considerations that were included in the discussion and that became the background for the exchanges in this DoF PoCD Subgroup meeting.

General Considerations include:

  1. HL7 (and IHE) Devices WG approach for all device informatics solutions is to harmonize the semantic content representation to the highest degree possible 
    1. Harmonization is rooted in the ISO/IEEE 11073 Health Device Communication standards, especially the nomenclature standards (11073-10101) and information model standards (11073-10201 & 11073-10207 & 11073-20601, and the emerging 11073-10206 tailored for simple IoT sensors)
    2. Implementation Guides & profiles for these health devices are based on use of the nomenclature / terminology + a basic information model that provides containment relationships from over all medical device systems down to the various parameters and waveforms that they contain 
    3. Device interoperability capabilities include basic connectivity, to metrics exchange, to alarm / alert management, to device-external control 
    4. Harmonization spans paradigms from device-to-device 11073, to HL7 V2 messaging, to HL7 FHIR representations, mapping the standardized semantic content to the technology appropriate for the implementation / care context 
    5. By striving for isosemantic content representation, the information persisted in a server database can support the multiple paradigms, whether for information sourcing (e.g., from a ventilator to a gateway server) or for accessing (e.g., requesting a report on patient-device specific values for a specific period of time)
    6. NOTE:  Though there may be MANY alternatives for exchanging health device information and services in 11073, V2 or FHIR, taking the above approach ensures that overall computability of the content is achieved and maintained, though sometimes more "optimal" approaches may be available for specific applications 
  2. Two broad categories of devices are supported by these standardized informatics:
    1. Point-of-Care Devices (PoCD) - typically for acute care contexts and that must scale from simple to very COMPLEX devices (e.g., a pulse oximeter to a ventilator or multiparameter physiologic monitor)
    2. Personal Health Devices (PHD) - typically for home / mobile applications and that are relatively simple (e.g., weighing scale, thermometer, 3-lead ECG) 
  3. Given (1) and (2) above ...
    1. Both PoCD and PHD health devices can provide setting values + physiological measurements 
      1. Note:  Currently only the PoCD standards also support alerting/alarm and external control functions
    2. ISO/IEEE 11073-10101 nomenclature indicates whether a device "setting" is included in the semantic 
    3. The information model standards above are harmonized; however, they are differentiated based on whether a PoCD device is being used (and thus scalability from simple to complex is a core requirement) or PHD device is being used (where keeping the implementation footprint simple and small is a core requirements)
    4. See the FHIR IG discussion below for more information on the differences and device setting representation specifics 

FOR THIS DISCUSSION (per the Zulip thread):  Don't reinvent the wheel unless it is absolutely necessary, and then only to the degree required, harmonizing to the greatest degree possible with existing health device standards & profiles

Comment from John Rhoads - the approach identified in the Zulip thread excerpted above has tacit use-case-specific assumptions that leave messy problems about how the two related data items are actually obtained and correlated and made available to be put in the Observation resource instance. The following discussion is based on the pragmatics of how device data are obtained and propagated. On the HL7 Devices on FHIR (DoF) home page, there are a couple of FHIR Implementation Guides in publication or under construction that are based on the ISO/IEEE 11073 device data models and nomenclature, and in the widely-used device profiles in the IHE Devices Domain Technical Framework.  How to best represent health device settings in FHIR differs based on whether relatively simple PHD devices are being utilized, or the more complex/scalable PoCD devices or ... both!   

NOTES: 

    1. For the purposes of this discussion, representing the relationship between a setting metric and a related physiological metric, consider:  Maximum PEEP & Actual PEEP 
    2. All device information is ultimately represented in instances of FHIR Observation, regardless of their type (e.g., measured value, setting, derived value, enumerated selection, etc.)
  • FHIR Personal Health Device IG (PHD)
    • FHIR IG maps from the ISO/IEEE 11073-20601 PHD standard to FHIR Device & Observation resource profiles
    • Settings when mapped to FHIR are indicated by the nomenclature only (i.e., looking at a term definition will include whether it is a measurement / observation or a setting or other type of value).
      • Note that the 11073-20601 PHD information model includes a settings flag in the MetricSpecSmall attribute;  however, this is not currently mapped to any FHIR semantic
      • Given the fact that the PHD FHIR IG does not leverage the DeviceMetric resource (it would add significant overhead without attendant benefit), a profile extension could be added in the future to the Observation resource to add support for this MetricSpecSmall attribute settings flag
    • 11073-20601 states that setting metrics must be communicated before observation metrics 
    • For setting-measurement inter-object relationships between two instances of the Metric object, the PHD FHIR IG maps:  Metric::Source-Handle-Reference to Observation:DerivedFrom Reference 
    • Note:  For PHD devices, these inter-Metric relationships are specified in the device specialization standards (e.g., 11073-10424 SABTE, though their specification may not be consistently and extensively defined)
    • When mapping proprietary PHD devices, relations/references between observations are seldom clear. In that case if one knows that in the FHIR representation a reference is needed, this can be added at the time of the mapping.
    • Some of the 20601-based specializations were developed before FHIR was thought of and references between observations were rare as PHD data tended to be mapped to PCD-01 messages which were often complete expressions of all the data in a connection.
    • Because of FHIR several specializations have been updated to include references so they can be mapped to FHIR and maintain their relationships.
  • FHIR Point-of-Care Device IG (PoCD)
    • FHIR IG maps from the ISO/IEEE 11073-10201 "Classic" Domain Information Model + 11073-10207 SDC (Service-oriented Device Communication) BICEPS "SOA" model to FHIR Device, DeviceMetric & Observation resource profiles
      • 11073-10201 & -10207 define a strict containment hierarchy (see SDC mapping examples in the PoCD FHIR IG here) 
        • Medical Device System (MDS) (1..*) Virtual Medical Device (VMD) (1..*) Channel (1..*) Metric (1..*) which can be Numeric / Enumeration / Waveform ... 
      • To represent this MDS::VMD::Channel containment hierarchy, the PoCD FHIR IG leverages the FHIR Device.parent element
      • To represent the METADATA for Metric objects, the FHIR DeviceMetric resource was defined, and includes
      • To provide the VALUE for Metric instances, FHIR Observation profiles are utilized as in PHD, though with additional data element mappings
    • Settings are indicated by both DeviceMetric category as well as the 11073-10101 nomenclature value
      • Note also that for PoCD devices, setting nomenclature is located in a different "partition" from other values such as physiological measurements (or alerts or controls etc.). The numeric nomenclature code for a physiologic observed value and the corresponding code for the setting nomenclature code for the setting with the same meaning differ only in the partition part of the code (the high-order 16 bit-word of the 32-bit), so that is easy to find either one from the other by simply swapping the partition part of the code.
    • For setting-measurement inter-object relationships between two instances of the Metric object, the PoCD FHIR IG maps (using the -10207 SDC model): 
      • AbstractMetricDescriptor/Relation to Relation extension to DeviceMetric resource in the FHIR PoCD IG.


        Relation allows the modelling of relationships between a metric and other containment tree entries. Related containment tree entries are defined in Entries, whereby the flavor of a relationship can be set up in Kind.

      • Note that this general "relation" between two or more metric instances includes "Kind" type presets: Recommendation, Presetting, Set of Summary Statistics, Effect on Containment Tree Entries, Derived from Containment Tree Entries, Other 
      • If one of these defined types does not accurately represent the relationship, an extension can be added to define additional types using nomenclature codes
    • NOTE:  If an observation is from a PoCD device, then it's Observation.device element will reference a DeviceMetric instance; PHD devices will populate this with their related Device instance.  

Additional Topics / Issues

  1. Should the extension for PoCD mentioned above be explicitly included in the draft PoCD IG?
  2. For PoCD, Observation.derivedFrom is duplicative to the metadata (list) included in the Observation's associated DeviceMetric instance; however, 
  3. Should a normalized device information representation be specified especially for when PHD data may be persisted in a database that is also created in support of PoCD devices (one as a subset of the other)? 
  4. Should examples be added to how Observation.derivedFrom or similar might be integrated with the DeviceMetric.relation extension?
  5. Should examples be provided for how to address questions such as "How do I find the Max PEEP settings for Fred, along with his Actual Peep physiological measurements for Tuesday last week?"



  • No labels