Skip to end of metadata
Go to start of metadata

Field

Value

Title

DOF-44 Provenance Resource Use

Key

DOF-44

Type

New Feature

Summary

Provenance Resource Use

Description

Consider the use of a Provenance resource to capture "intermediaries" between the source device and the end "data at rest" point.  This could include gateways or similar systems that simply "relay" information from one subnet to another.

Created

Thu, 21 Nov 2019 10:57:01 -0500

Updated

Wed, 4 Mar 2020 08:37:41 -0500

Reporter

Todd Cooper

Assignee

Stefan Schlichting

Status

To-Do

Resolution

Unresolved

Resolved


Comment


created

Thu, 21 Nov 2019 12:20:42 -0500

author

todd.cooper

text

Consider:
<ul>
<li>Physio Monitor with "plug-ins" to add modalities</li>
<li>A ventilator (standalone device) is plugged into the monitor</li>
<li>The monitor displays some of the vent's parameters (e.g., resp rate)</li>
<li>The monitor also makes all the vent data available through its interface </li>
</ul>

How is this represented:
<ol>
<li>In BICEPS</li>
<li>In DoF </li>
</ol>

In (2) it would be pretty clear to have a vent MDS.parent point to a top level MDS (with null .parent); but would there be a sibling (contained) physio monitor MDS pointing to the same top level parent?


In (1) BICEPS would support sibling MDSs in the same MDIB::MdDescription BUT how do you then reflect the architectural reality?


Same for "gateways" .... in fact is the "top level MDS" above analogous to a gateway device and should it take on that type label?


If you are doing a FHIR search and want to find all the ventilators of a certain make / model / serial #, but they are not top level MDSs, will it be smart enough to search all MDS Device instances (contained or otherwise) to return the correct information?  Hopefully so ... 


  |