This page is part of the FHIR Specification (v0.11: DSTU 1 Ballot 3). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions

Resource DeviceLog - Content 4.21

A set of raw data produced by a device.

The resource name as it appears in a RESTful URL is [root]/devicelog/

There are 4 device related resources

• Device - an administrative resource that tracks individual devices and their location. Primarily used for attribution of actions to devices
• Device Capabilities - Defines what observations a device will provide when another system connects to it
• Device Log (this resource) - A raw report from a device at a point in time. Must be paired with the correct Device Capabilities resource in order to be processed
• Device Observation - A report of observations from a device

The device capabilities and log resources are used when communicating with a device, either directly or indirectly. When a channel is opened with the device, or its proxy, it first sends the Capabilities resource, and then a series of log resources. The FHIR JSON format is used in this case. (TODO: What's the communication protocol?) The application that receives the log resources may choose to merge the log with the capabilities statement to create a device observation, which is suitable for wider use within a EHR/Clinical record context. The application that receives the log resources may choose to merge the log with the capabilities statement to create a device observation, which is suitable for wider use within a EHR/Clinical record context. The Device Capabilities and Device Log resources may be used in a RESTful context, but in many contexts this will not be very useful - the data should be converted to a Device Observation for normal RESTful use in a patient care context.

Structure of the Device Log 4.21.0.1

A medical device emits a series of these device log resources on a regular basis. A device log is simply a list of items with a key, a value, and a set of flags. The only way to understand the contents of the resource is to match the device log to the device capabilities that provides the context for interpreting the data in the device log. The device log can identify the appropriate Device Capabilities resource explicitly, but generally this is omitted, and the applicable resource is the one that is sent prior to any device log resources being sent. The system receiving the data must keep track of the appropriate Device Capabilities resource.

Some devices may be configured to know the identity of the subject of the observations, so the device log also includes the subject. However many simple devices do not know the identity of the subject well, or even at all, and the subject information must be provided or completed by the recipient of the device logs based on local context.

The device log is a low level resource suitable for direct communication with devices. The data from the device is usually converted to a Device Observation for general use in a patient care context. This process is described further below.

Resource Content 4.21.1

<DeviceLog xmlns="http://hl7.org/fhir">
 <!-- from Resource: extension, narrative, and contained -->
 <instant value="[instant]"/><!-- 0..1 When the data values are reported -->
 <capabilities><!-- 0..1 Resource(DeviceCapabilities) Explicit reference to the capabilities --></capabilities>
 <subject><!-- 0..1 Resource(Patient|Group|Device) Subject of the measurement --></subject>
 <item>  <!-- 0..* An item of data -->
  <key value="[string]"/><!-- 1..1 Reference to device capabilities declaration -->
  <value value="[string]"/><!-- 0..1 The value of the data item, if available -->
  <flag value="[code]"/><!-- 0..* Information about the quality of the data etc -->
 </item>
</DeviceLog>

Alternate definitions: Schema/Schematron, Resource Profile

Terminology Bindings 4.21.1.1

Converting Device Logs to Device Observations 4.21.1.2

A device log has little context, and does not have the full context to support integrating the data into the patient record. The usual process for feeding the data from the device log resource into the patient record is to convert it to a Device Observation.

To convert the data from a Device Log to a Device Observation:

• Locate the matching Device Capabilities resource (may be referred to explicitly in the log, but is also sent explicitly by the machine each time a system connects to it)
• Use the key values on the device log to identify the relevant metric or facet for each item
• Use the information for the metric or facet to build a set of observation resources (see below)
• Create a device observation that provides the device context for the observations
• Fill out the missing information (device identity, subject, etc.). This information may be explicit in the device capabilities and device log resources, but the simpler the device, the more likely it must come from local context/configuration
• Submit the device observation to the patient record

Converting a Data Item to an Observation

Between the Device Item and the matching Device Capabilities information, the following information is provided:

• metric or facet code - the code for the observation
• data item value
• data type
• additional information to complete the data type
• a set of flags

The following table describes how to convert from value to the correct data type:

    <valueQuantity>
      <value value="[data item value]" />
      [ (if appropriate from flags) <comparator value="??" /> ]
      <units value="[units]" />
	    [ (if UCUM code provided)
        <system value="http://unitsofmeasure.org" />
        <code value="[UCUM]" />
      ]
    </valueQuantity>
   

    <valueCoding>
      <system value="[system]" />
      <code value="[data item value]" />
    </valueCoding>
   

    <valueString value="[data item value]"/>
   

The following table summarizes the interpretation of the possible flags

Generally, as a rule of thumb, metrics and facets are components of the observation.

Search Parameters 4.21.2

Search Parameters for RESTful searches. The standard parameters also apply. See Searching for more information.