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

General Requirements

The Clinical Vital Signs Category describes requirements supporting additional data needed for accurate interpretation of device measurements in a clinical setting.

Feature: A Time Stamp or Time Period is Recorded for Each Measurement

The time stamp or time period SHALL be recorded and reported for each measurement taken

Note: These requirements are checked for each vital sign, physical activity or sleep measure for which the system is being assessed. If the requirement fails for ANY measurement, the requirement is considered to not be met.

Scenario: Vital Signs Have a Time Stamp

GIVEN

a <User>

WHEN

a <Measurement> of the <User> vital signs is performed or recorded

THEN

that <Measurement> has a time stamp indicating when it was taken.

Scenario: Physical Activity or Sleep Has a Time Period

GIVEN

a <User>

WHEN

a <Measurement> of the <User> physical activity or sleep is performed or recorded

THEN

that <Measurement> has a time period indicating when it occured.

Feature: Multiple User Support

A given device SHALL be able to be used by more than one user.

Users from the same family may share a device to take similar measurements (e.g., blood pressure) using an App on their personal device.

Scenario: Record a Measurement for Multiple Users w/ Re-pairing

It’s expected that devices will be able to be shared across users and apps but that some setup or configuration may be needed when transferred between users (e.g., pairing the device with the platform on which the app is running). Many smaller devices can only be paired with one system at a time.

GIVEN

A <Device> that performs a measurement,

AND

<User1>

AND

<User2>,

AND

an <App> that runs on both user’s devices.

WHEN

The <Device> has been recognized by <App> on <User1>’s device

AND

The <Device> has been recognized by <App> on <User2>’s device

THEN

The <Device> can take a measurement for <User1>

AND

The <Device> can take a measurement for <User2>

BUT

The <Device> may need to be configured (e.g., paired with) <AppRunner1> or <AppRunner2> before taking the measurement.

Scenario: Record a Measurement for Multiple Users W/o Re-pairing

Ideally, a device should be able to be paired with a small number of other systems to enable it to be used by different people or with different systems (e.g., a smart phone or a tablet). This should not require repairing (though it may require activating an already paired connection).

GIVEN

A <Device> that performs a measurement,

AND

<User1>

AND

<User2>,

AND

an <App> that runs on both user’s devices.

AND

<AppRunner1> for <User1> that runs <App>

AND

<AppRunner2> for <User2> that runs <App>

WHEN

The <Device> has been recognized by <App> on <User1>’s device

AND

The <Device> has been recognized by <App> on <User2>’s device

THEN

The <Device> can take a measurement for <User1>

AND

The <Device> can take a measurement for <User2>

BUT

The <Device> doe not need to be configured (e.g., paired with) <AppRunner1> or <AppRunner2> before taking the measurement.

Feature: Multiple Device Support

An app SHALL be able to collect data for a given patient from multiple (possibly identical) devices and identify the device from which they were collected.

Background: Multiple Device Support

The following sections describe further support requirements for similar and different devices. The steps below apply to both cases.

GIVEN

An app <App> that supports a device <Device1> of a particular <Type>

AND

<MeasureSet1> that were acquired through <Device1>

THEN

Previously recorded <MeasureSet1> still exists

AND

can be distinguished as having come from <Device1>

Scenario: Replacement Device

Patients may replace a broken, failed, lost or otherwise non-functional device with a new device of a similar type, not lose their existing data maintained in the app, and yet also be able to distinguish which device took which measurement.

WHEN

The user acquires <Device2> of the same type <Type>

THEN

<App> can acquire new measurements <MeasureSet2> from <Device2>

AND

Those measures in <MeasureSet2> can be distinguished as having come from <Device2>

Scenario: Alternative Device

A user should be able to acquire and use a similar or different kind of device to work with an application to enable data collection under different circumstances or in different environments.

For example, blood pressure can be measured on the arm using a traditional pneumatic cuff, or on the wrist using a different type of device. The former may be used at home, and the latter when traveling because it is smaller and easier to carry (but may be less accurate, or more difficult to use). The main idea here is that an app can work with multiple devices with no user intervention after initial configuration.

WHEN

The user acquires device <Device2> of the same type <Type> or a different type <Type2>

THEN

<App> can acquire new measurements <MeasureSet2> from <Device2>

AND

<App> can acquire new measurements <MeasureSet3> from <Device1>

AND

Measures in <MeasureSet3> can be distinguished as having come from <Device1>

AND

Measures in <MeasureSet2> can be distinguished as having come from <Device2>

Feature: User Manual Entry

An App SHOULD allow for manual recording of data from external sources.

Users of a device or app for tracking a particular type of measurement may also want to keep track of externally generated measurements for the purposes of verifying device calibration, keeping general track of what the device helps them monitor, or for other reasons.

Scenario: Manual Entry of a Measurement

GIVEN

an <App>

AND

<Infrastructure>

AND

a <User>

WHEN

an external <Measurement> is available to the <User>

THEN

the <User> can record <Measurement> in the <App>

AND

the <Infrastructure> can report that <Measurement>