This page is part of the Application Data Exchange Assessment Framework and Functional Requirements for Mobile Health (v0.1.0: STU 1 Ballot 1) based on FHIR R4. . For a full list of available versions, see the Directory of published versions

System Attributes

System attributes describe dynamic attributes of a system to one of its clients. While dynamic and changeable, these are often infrequently altered. Features in this category enable other systems to determine metadata about the system and its current state.

Concepts that would be expressed as system attributes include device identity, software and/or firmware versions¹. They may also include information about the current system state (e.g., the current charge level of the battery used to operate the system, the current position of the device in GPS coordinates, the most recent ambient tempurature measured, et cetera). Attributes are different from recorded measurements because they can be queried. When the queried attribute is stored with a timestamp and other metadata, it effectively becomes a measurement.

The ability to upgrade a device by “installing new firmware” is nothing more than changing the software that it runs. Generally the distinction is made that “it’s soft” if it can be easily changed, and “firm” if it requires a special mode of operation to change it. But it’s all stored in some form of memory that is very likely rewritable.

Feature: The Mechanism to Obtain the System Configuration is Documented.

The means by which a system configuration can be inspected is documented.

Configuration includes the system identifier, software version, and other configurable system attributes (e.g., units).

Scenario: The Means to Access System Configuration Shall be Documented

GIVEN

a <System>

AND

<Documentation> for it

WHEN

the <Documentation> is examined

THEN

the means by which the <Configuration> can be examined for <System> is documented.

Feature: Device Can be Identified

The device that performs a measurement **SHALL** be uniquely identified.

Each type of device has attributes with regard to precision, accuracy and quality which can impact the interpretation of measurements taken by the device. Knowledge of the device helps greatly in interpreting the results.

Scenario: Device Identifier is Unique

The device identifier shall be unique within the namespace defined by the system
(Device + App + Infrastructure).

The point of this assessment is that the mechanism by which devices are identified be sufficient demonstrate that identifiers are unique.

GIVEN

A <Device> that performs a measurement

AND

an <App> that records a measurement

AND

<Infrastructure> that reports a measurement

AND

An <Identifier> for that <Device>

WHEN

The mechanism for assigning <Identifier> is examined

THEN

<Identifier> is uniquely assigned to <Device>

Scenario: The Device Has a Unique Device Identifier (UDI)

The device should have a UDI.

The [Unique Device Identification System](https://www.fda.gov/medical-devices/unique-device-identification-system-udi-system/udi-basics) (UDI System) enables users of device related data to identify the devices providing measurements and enables analysis of device data with regard to issues, errors, accuracy, et cetera.

NOTE: The UDI need not be the primary identifier for the device

GIVEN

A <Device Record>

WHEN

The <Device Record> is examined

THEN

The <Device Record> contains a UDI for the device

Feature: Network Address

The network address of a device **SHOULD** be reported.

The network address can be the physical network address (e.g., MAC address) or other identifier
assigned to uniquely identify the device on a network (wired or unwired)

Scenario: Network Address Can be Accessed

GIVEN

A <Device Record>

AND

a <Network Address>

AND

an <App> running on <App Runner>

WHEN

The <Device> is connected to the <App> and <App Runner>

THEN

<Network Address> can be discovered

Feature: Network Address

The network address of a device can be discovered.

Scenario: Network Address Can be Accessed

GIVEN

A <Device Record>

AND

a <Network Address>

WHEN

The <Device Record> is examined

THEN

<Network Address> can be found in <Device Record>

Feature: Battery Charge

The level of battery charge for a device **SHOULD** be reported.

Reporting the battery charge level for a device enables an App to alert
a user that the device needs recharging.

Scenario: Battery Charge Can be Accessed

GIVEN

A <Device Record>

AND

a <Charge Level>

WHEN

The <Device> is connected to the <App> and <App Runner>

THEN

<Charge Level> for <Device> is reported by <App>