• Revision: v1.1.1

  • Revision Date: 2022-01-18

  • Group Prepared By: Medical Devices Working Group

Revision History

Revision Number

Date

Comments

V10r00

2011-10-25

Adopted by the Bluetooth SIG Board of Directors

v1.1

2020-12-15

Adopted by the Bluetooth SIG Board of Directors.

v1.1.1

2022-01-18

Adopted by the Bluetooth SIG Board of Directors.

Version History

Versions

Changes

v1.0 to v1.1

Incorporated BLS_1.1_PS.

Incorporated issue ID12813, ID13580, ID14601, ID14602, ID14673, ID 14818.

v1.1 to v1.1.1

Incorporated erratum E16461.

Acknowledgments

Name

Company

Tetsu Nishimura

Murata

Robert Hughes

Intel Corporation

Jason Hillyard

Wicentric

Amit Gupta

CSR

Erik Moll

Koninklijke Philips N.V.

Javier Espina Perez

Koninklijke Philips N.V.

Felix Bootz

F. Hoffmann-La Roche AG

Wolfgang Heck

F. Hoffmann-La Roche

Craig Carlson

F. Hoffmann-La Roche

Hideki Kondo

Omron Healthcare Co., Ltd.

Use of this specification is your acknowledgement that you agree to and will comply with the following notices and disclaimers. You are advised to seek appropriate legal, engineering, and other professional advice regarding the use, interpretation, and effect of this specification.

Use of Bluetooth specifications by members of Bluetooth SIG is governed by the membership and other related agreements between Bluetooth SIG and its members, including those agreements posted on Bluetooth SIG’s website located at www.bluetooth.com. Any use of this specification by a member that is not in compliance with the applicable membership and other related agreements is prohibited and, among other things, may result in (i) termination of the applicable agreements and (ii) liability for infringement of the intellectual property rights of Bluetooth SIG and its members. This specification may provide options, because, for example, some products do not implement every portion of the specification. All content within the specification, including notes, appendices, figures, tables, message sequence charts, examples, sample data, and each option identified is intended to be within the bounds of the Scope as defined in the Bluetooth Patent/Copyright License Agreement (“PCLA”). Also, the identification of options for implementing a portion of the specification is intended to provide design flexibility without establishing, for purposes of the PCLA, that any of these options is a “technically reasonable non-infringing alternative.”

Use of this specification by anyone who is not a member of Bluetooth SIG is prohibited and is an infringement of the intellectual property rights of Bluetooth SIG and its members. The furnishing of this specification does not grant any license to any intellectual property of Bluetooth SIG or its members. THIS SPECIFICATION IS PROVIDED “AS IS” AND BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES MAKE NO REPRESENTATIONS OR WARRANTIES AND DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING ANY WARRANTIES OF MERCHANTABILITY, TITLE, NON-INFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR THAT THE CONTENT OF THIS SPECIFICATION IS FREE OF ERRORS. For the avoidance of doubt, Bluetooth SIG has not made any search or investigation as to third parties that may claim rights in or to any specifications or any intellectual property that may be required to implement any specifications and it disclaims any obligation or duty to do so.

TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, BLUETOOTH SIG, ITS MEMBERS AND THEIR AFFILIATES DISCLAIM ALL LIABILITY ARISING OUT OF OR RELATING TO USE OF THIS SPECIFICATION AND ANY INFORMATION CONTAINED IN THIS SPECIFICATION, INCLUDING LOST REVENUE, PROFITS, DATA OR PROGRAMS, OR BUSINESS INTERRUPTION, OR FOR SPECIAL, INDIRECT, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY OF LIABILITY, AND EVEN IF BLUETOOTH SIG, ITS MEMBERS OR THEIR AFFILIATES HAVE BEEN ADVISED OF THE POSSIBILITY OF THE DAMAGES.

Products equipped with Bluetooth wireless technology ("Bluetooth Products") and their combination, operation, use, implementation, and distribution may be subject to regulatory controls under the laws and regulations of numerous countries that regulate products that use wireless non-licensed spectrum. Examples include airline regulations, telecommunications regulations, technology transfer controls, and health and safety regulations. You are solely responsible for complying with all applicable laws and regulations and for obtaining any and all required authorizations, permits, or licenses in connection with your use of this specification and development, manufacture, and distribution of Bluetooth Products. Nothing in this specification provides any information or assistance in connection with complying with applicable laws or regulations or obtaining required authorizations, permits, or licenses.

Bluetooth SIG is not required to adopt any specification or portion thereof. If this specification is not the final version adopted by Bluetooth SIG’s Board of Directors, it may not be adopted. Any specification adopted by Bluetooth SIG’s Board of Directors may be withdrawn, replaced, or modified at any time. Bluetooth SIG reserves the right to change or alter final specifications in accordance with its membership and operating agreements.

Copyright © 2011–2022. All copyrights in the Bluetooth Specifications themselves are owned by Apple Inc., Ericsson AB, Intel Corporation, Lenovo (Singapore) Pte. Ltd., Microsoft Corporation, Nokia Corporation, and Toshiba Corporation. The Bluetooth word mark and logos are owned by Bluetooth SIG, Inc. Other third-party brands and names are the property of their respective owners.

1. Introduction

The Blood Pressure Service exposes blood pressure and other data related to a non-invasive blood pressure monitor for consumer and professional healthcare applications.

1.1. Conformance

If conformance to this specification is claimed, all capabilities indicated as mandatory for this specification shall be supported in the specified manner (process-mandatory). This also applies for all optional and conditional capabilities for which support is indicated.

1.2. Service dependency

This service is not dependent upon any other services.

1.3. Bluetooth Specification release compatibility

This specification is compatible with any Bluetooth core specification [1] that includes the Generic Attribute Profile (GATT) and the Bluetooth Low Energy Controller portions of the core specification.

1.4. GATT sub-procedure requirements

Requirements in this section represent a minimum set of requirements for a Blood Pressure Sensor (Server). Other GATT sub-procedures may be used if supported by both Client and Server.

The table below summarizes additional GATT sub-procedure requirements beyond those required by all GATT Servers.

GATT Sub-Procedure

Requirements

Notifications

C.1

Indications

M

Read Characteristic Descriptors

M

Write Characteristic Descriptors

M
Table 1.1. GATT sub-procedure requirements

C.1:

Mandatory if the Intermediate Cuff Pressure, the Enhanced Intermediate Cuff Pressure, or the Blood Pressure Record characteristic is supported, otherwise excluded for this service.

M:

Mandatory

1.5. Transport dependencies

This service shall operate over LE transport only. For BR/EDR (and HS) the Health Device Profile [2] is to be used.

1.6. Byte transmission order

All characteristics used with this service shall be transmitted with the least significant octet first (i.e. little endian). The least significant octet is identified in the characteristic definitions in [3].

1.7. Language

1.7.1. Language conventions

The Bluetooth SIG has established the following conventions for use of the words shall, must, will, should, may, can, is, and note in the development of specifications:

shall

is required to – used to define requirements.

must

is used to express:

a natural consequence of a previously stated mandatory requirement.

OR

an indisputable statement of fact (one that is always true regardless of the circumstances).

will

it is true that – only used in statements of fact.

should

is recommended that – used to indicate that among several possibilities one is recommended as particularly suitable, but not required.

may

is permitted to – used to allow options.

can

is able to – used to relate statements in a causal manner.

is

is defined as – used to further explain elements that are previously required or allowed.

note

Used to indicate text that is included for informational purposes only and is not required in order to implement the specification. Each note is clearly designated as a “Note” and set off in a separate paragraph.

For clarity of the definition of those terms, see Core Specification Volume 1, Part E, Section 1.

1.7.2. Reserved for Future Use

Where a field in a packet, Protocol Data Unit (PDU), or other data structure is described as "Reserved for Future Use" (irrespective of whether in uppercase or lowercase), the device creating the structure shall set its value to zero unless otherwise specified. Any device receiving or interpreting the structure shall ignore that field; in particular, it shall not reject the structure because of the value of the field.

Where a field, parameter, or other variable object can take a range of values, and some values are described as "Reserved for Future Use," a device sending the object shall not set the object to those values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous; however, this does not apply in a context where the object is described as being ignored or it is specified to ignore unrecognized values.

When a field value is a bit field, unassigned bits can be marked as Reserved for Future Use and shall be set to 0. Implementations that receive a message that contains a Reserved for Future Use bit that is set to 1 shall process the message as if that bit was set to 0, except where specified otherwise.

The acronym RFU is equivalent to Reserved for Future Use.

1.7.3. Prohibited

When a field value is an enumeration, unassigned values can be marked as “Prohibited.” These values shall never be used by an implementation, and any message received that includes a Prohibited value shall be ignored and shall not be processed and shall not be responded to.

Where a field, parameter, or other variable object can take a range of values, and some values are described as “Prohibited,” devices shall not set the object to any of those Prohibited values. A device receiving an object with such a value should reject it, and any data structure containing it, as being erroneous.

“Prohibited” is never abbreviated.

2. Service declaration

The Blood Pressure Service is recommended to be instantiated as a «Primary Service».

The service UUID shall be set to «Blood Pressure Service». The UUID value assigned to «Blood Pressure Service» is defined in [3].

3. Service characteristics

The characteristic requirements for an instance of the Blood Pressure Service are shown in Table 3.1. Unless otherwise specified, only one instance of each characteristic is permitted within each instance of this service.

An Enhanced Blood Pressure Service instance is a Blood Pressure Service instance that supports at least one of the following enhanced feature elements defined in this specification:

The requirements for these feature elements are marked as conditionally mandatory in the tables in this section.

Characteristic Name

Requirement

Mandatory Properties

Optional

Properties

Security Permissions

Blood Pressure Measurement

M

Indicate

N/A

None

Blood Pressure Measurement - Client Characteristic Configuration descriptor

M

Read, Write

N/A

None

Intermediate Cuff Pressure

O

Notify

N/A

None

Intermediate Cuff Pressure - Client Characteristic Configuration descriptor

C.1

Read, Write

N/A

None

Blood Pressure Feature

M

Read

Indicate C.5

None

RACP

C.2

Indicate, Write

N/A

None

Blood Pressure Record

C.3

Notify

N/A

None

Enhanced Blood Pressure Measurement

C.2, C.4

Indicate

N/A

None

Enhanced Intermediate Cuff Pressure

O

Notify

N/A

None
Table 3.1. Blood Pressure Service characteristics

C.1:

Mandatory if Intermediate Cuff Pressure characteristic is supported, otherwise excluded for this service.

C.2:

At least one of the following items shall be supported by an Enhanced Blood Pressure Service instance:

C.3:

The Blood Pressure Record characteristic shall be supported when the RACP characteristic is supported.

C.4:

The Enhanced BP Measurement characteristic shall be supported when User Facing Time is supported, otherwise optional. See Section 3.3.1.9.

C.5:

The Indicate property shall be supported for the Blood Pressure Feature characteristic if the device supports bonding and if the value of the Blood Pressure Feature characteristic can change over the lifetime of the device, otherwise excluded for this Service.

M:

Mandatory

O:

Optional

Note

Note 1: Properties not listed as Mandatory, Conditional or Optional are Excluded.

Note 2: Security Permissions of “None” means that this service does not impose any requirements.

Where a characteristic can be indicated and/or notified, a Client Characteristic Configuration descriptor must be included in that characteristic as required by the Core Specification [1], Vol 3, Part G, Section 3.3.1.1.

3.1. Blood Pressure Measurement

The Blood Pressure Measurement characteristic shall be used to send Blood Pressure measurements. Included in the characteristic are a Flags field (containing units of Blood Pressure and used to show presence of optional fields), the Blood Pressure Measurement Compound Value field and, depending upon the contents of the Flags field, Time Stamp (time of the measurement), Pulse Rate, User ID and Measurement Status fields.

3.1.1. Characteristic behavior

When the Client Characteristic Configuration descriptor is configured for indications and a Blood Pressure measurement is available, this characteristic shall be indicated while in a connection.

If a Blood Pressure measurement is available, the Client Characteristic Configuration descriptor is configured for indications, and a connection is not currently established, the Server shall become connectable to allow the Collector to create a link.

The Blood Pressure Measurement characteristic contains time-sensitive data; thus the requirements for time-sensitive data and data storage defined in Section 3.8 apply.

It is implementation dependent what happens when indications are enabled for both the Blood Pressure Measurement characteristic and the Enhanced Blood Pressure Measurement characteristic:

  • Enabling the second characteristic for indications may result in an Error Response with Error Code Client Characteristic Configuration Descriptor Improperly Configured.

  • When both indications are successfully enabled, the Server may send measurements once using one of the characteristics or twice using both characteristics.

Collectors should enable indications on only one of these characteristics.

3.1.1.1. Flags field

The Flags field is included in the Blood Pressure Measurement characteristic.

Reserved for Future Use (RFU) bits in the Flags field shall be set to 0.

3.1.1.2. Blood Pressure Measurement Compound Value field

This Blood Pressure Measurement Compound Value field is composed of three subfields: Systolic, Diastolic and Mean Arterial Pressure (MAP) and is included in the Blood Pressure Measurement characteristic.

If a value for Systolic, Diastolic, or MAP subfields is unavailable (e.g., due to an invalid result from a computation step or missing data due to the hardware’s inability to provide a valid measurement), the special short float value NaN (see Section 4) defined in ISO/IEEE 11073-20601 [4] shall be used in each of the unavailable subfields.

If the unit of the Blood Pressure Measurement is in mmHg, bit 0 of the Flags field is set to 0. Otherwise, the unit is kPa and bit 0 of the Flags field is set to 1.

3.1.1.3. Time Stamp field

The Time Stamp field is optional, but shall be included in the Blood Pressure Measurement characteristic if the device supports storing of data.

If the Time Stamp field is present in the Blood Pressure Measurement characteristic, bit 1 of the Flags field is set to 1; otherwise bit 1 of the Flags field is set to 0.

The value of the Time Stamp field is derived from a source of date and time at the time of measurement. If the Time Stamp feature is supported, a source of date and time is mandatory.

The date and time of the device may be updated by various means such as via a simple user interface on the device or via the Current Time Service [5].

The time stamp field is defined to use the same format as the Date Time characteristic defined in [3]. However, a value of 0 for the month or day fields shall not be used for this service. A value of 0 for the year field (meaning unknown year) may be used for devices not supporting the year value in their real-time clock. It is left to the implementation to ensure the user sets the correct date and time before the Blood Pressure Sensor is used.

3.1.1.4. Pulse Rate field

The Pulse Rate field may be included in the Blood Pressure Measurement characteristic if the device supports pulse rate measurements.

If a value for the Pulse Rate field is unavailable (e.g. due to an invalid result from a computation step or missing data due to the hardware’s inability to provide a valid measurement), the special short float value NaN (see Section 4) defined in ISO/IEEE 11073-20601 [4] shall be used.

If the Pulse Rate field is present in the Blood Pressure Measurement characteristic, bit 2 of the Flags field is set to 1; otherwise bit 2 of the Flags field is set to 0.

3.1.1.5. User ID field

The User ID field shall be included in the Blood Pressure Measurement characteristic if the device supports multiple users.

If the User ID field is present in the Blood Pressure Measurement characteristic, bit 3 of the Flags field is set to 1; otherwise bit 3 of the Flags field is set to 0.

The values used for User ID shall be unique per Server, but are otherwise left to the implementation. For example, if the Server supports two User IDs to distinguish between two users, the Server may use User ID 1 and 2 or User ID 35 and 97 or other unique combinations.

Special User ID value of 0xFF represents “unknown user”.

3.1.1.6. Measurement Status field

The Measurement Status field may be included in the Blood Pressure Measurement characteristic if the device supports measurement status flags.

If the Measurement Status field is present in the Blood Pressure Measurement characteristic, bit 4 of the Flags field is set to 1; otherwise bit 4 of the Flags field is set to 0.

Reserved for Future Use (RFU) bits in the Measurement Status field shall be set to 0.

3.1.2. Characteristic descriptors

3.1.2.1. Client Characteristic Configuration descriptor

The Client Characteristic Configuration descriptor shall be included in the Blood Pressure Measurement characteristic.

3.2. Intermediate Cuff Pressure

The Intermediate Cuff Pressure characteristic may be used to send Current Cuff Pressure values to a device for display purposes while the measurement is in progress.

3.2.1. Characteristic behavior

The Intermediate Cuff Pressure characteristic may be notified frequently during the course of a measurement so that a receiving device can effectively update the display on its user interface during the measurement process. The update rate is defined by the Server and should not be greater than a rate necessary to provide an acceptable user display on the Client. Typical update intervals range from 0.25 seconds to 2 seconds.

When the Client Characteristic Configuration descriptor is configured for notifications and an intermediate Cuff Pressure value is available, the Server shall send a notification of this characteristic while in a connection.

If an Intermediate Cuff Pressure characteristic is available, the Client Characteristic Configuration descriptor is configured for notifications, and a connection is not currently established, the Server shall become connectable to allow the Collector to create a link. If there is a delay in connection and several Intermediate Cuff Pressure characteristic values are pending, only the last cached value should be sent once the link is established. This avoids a poor user experience where the display rapidly changes with out-dated real-time values.

To avoid transmitting unnecessary data, the Time Stamp and Pulse Rate fields should not be used in the Intermediate Cuff Pressure characteristic.

Once the measurement process is complete and a stable Blood Pressure measurement is available, the Server shall stop notifications of the Intermediate Cuff Pressure characteristic and, if indications are enabled, shall indicate the Blood Pressure Measurement characteristic.

It is implementation dependent what happens when notifications are enabled for both Intermediate Cuff Pressure characteristic and the Enhanced Intermediate Cuff Pressure characteristic:

  • Enabling the second characteristic for notifications may result in an Error Response with Error Code Client Characteristic Configuration Descriptor Improperly Configured.

  • When both notifications are successfully enabled, the Server may send measurements once using one of the characteristics or twice using both characteristics.

Collectors should enable notifications on only one of these characteristics.

3.2.1.1. Flags field

The Flags field is included in the Intermediate Cuff Pressure characteristic.

Reserved for Future Use (RFU) bits in the Flags field shall be set to 0.

3.2.1.2. Intermediate Cuff Pressure Compound Value field

This Intermediate Cuff Pressure Compound Value field is composed of three subfields: Current Cuff Pressure and two unused subfields and is included in the Intermediate Cuff Pressure characteristic.

The two unused subfields shall be set to special value NaN (see Section 4) as defined in ISO/IEEE 11073-20601 [4].

The Current Cuff Pressure subfield may contain special short float value NaN (see Section 4) as defined in ISO/IEEE 11073-20601 [4] to report an invalid result from a computation step or missing data due to the hardware’s inability to provide a valid measurement.

If the unit of the Current Cuff Pressure is in mmHg, bit 0 of the Flags field is set to 0. Otherwise, the unit is kPa and bit 0 of the Flags field is set to 1.

3.2.1.3. Time Stamp field

The Time Stamp field may be included in the Intermediate Cuff Pressure characteristic, but is not recommended in order to avoid sending unnecessary data.

If the Time Stamp field is present in the Intermediate Cuff Pressure characteristic the same requirements apply as in Section 3.1.1.3.

3.2.1.4. Pulse Rate field

The Pulse Rate field may be included in the Intermediate Cuff Pressure characteristic if the device supports pulse rate measurements, but is not recommended in order to avoid sending unnecessary data.

If a value for the Pulse Rate field is unavailable (e.g. due to an invalid result from a computation step or missing data due to the hardware’s inability to provide a valid measurement), the special short float value NaN (see Section 4) defined in ISO/IEEE 11073-20601 [4] shall be used.

If the Pulse Rate field is present in the Intermediate Cuff Pressure characteristic, the same requirements apply as in Section 3.1.1.4.

3.2.1.5. User ID field

The User ID shall be included in the Intermediate Cuff Pressure characteristic if the device supports multiple users.

If the User ID field is present in the Intermediate Cuff Pressure characteristic, the same requirements apply as in Section 3.1.1.5.

3.2.1.6. Measurement Status field

The Measurement Status field may be included in the Intermediate Cuff Pressure characteristic if the device supports measurement status flags.

If the Measurement Status field is present in the Intermediate Cuff Pressure characteristic, the same requirements apply as in Section 3.1.1.6.

For requirements in relation to bits in this field and bits in the Blood Pressure Feature characteristic, see Section 3.3.1.

3.2.2. Characteristic descriptors

3.2.2.1. Client Characteristic Configuration descriptor

The Client Characteristic Configuration descriptor shall be included in the Intermediate Cuff Pressure characteristic.

3.3. Blood Pressure Feature

The Blood Pressure Feature characteristic shall be used to describe the supported features of the Blood Pressure Sensor.

3.3.1. Characteristic behavior

When read or indicated, the Blood Pressure Feature characteristic gives a value that is used by a Collector to determine the supported features of the Blood Pressure Sensor. Indications shall be supported if the Blood Pressure Sensor supports bonding and the supported features of the Blood Pressure Sensor can change.

The Blood Pressure Feature characteristic shall be static during a connection.

When the Client Characteristic Configuration descriptor is configured for indications and the supported features of a Blood Pressure Sensor have changed, the Blood Pressure Feature characteristic shall be indicated to any bonded Collectors after reconnection.

3.3.1.1. Body Movement Detection Support bit

If the Body Movement Detection feature is not supported, the Body Movement Detection Support bit shall be set to 0 and the Body Movement Detection Flag (from the Measurement Status field of the Blood Pressure Measurement characteristic) shall be set to 0. Otherwise the Body Movement Detection Support bit shall be set to 1 (Body Movement Detection feature supported) and the Body Movement Detection Flag shall be used to show whether or not movement was detected during a given measurement.

3.3.1.2. Cuff Fit Detection Support bit

If the Cuff Fit Detection feature is not supported, the Cuff Fit Detection Support bit shall be set to 0 and the Cuff Fit Detection Flag (from the Measurement Status field of the Blood Pressure Measurement characteristic) shall be set to 0. Otherwise the Cuff Fit Detection Support bit shall be set to 1 (Cuff Fit Detection feature supported) and the Cuff Fit Detection Flag shall be used to show whether or not improper fit of the cuff was detected during a given measurement.

3.3.1.3. Irregular Pulse Detection Support bit

If the Irregular Pulse Detection feature is not supported, the Irregular Pulse Detection Support bit shall be set to 0 and the Irregular Pulse Detection Flag (from the Measurement Status field of the Blood Pressure Measurement characteristic) shall be set to 0. Otherwise the Irregular Pulse Detection Support bit shall be set to 1 (Irregular Pulse Detection feature supported) and the Irregular Pulse Detection Flag shall be used to show whether or not an irregular pulse was detected during a given measurement.

3.3.1.4. Pulse Rate Range Detection Support bit

If the Pulse Rate Range Detection feature is not supported, the Pulse Rate Range Detection Support bit shall be set to 0 and the Pulse Rate Range Detection Flags (from the Measurement Status field of the Blood Pressure Measurement characteristic) shall both be set to 0. Otherwise the Pulse Rate Range Detection Support bit shall be set to 1 (Pulse Rate Range Detection feature supported) and the Pulse Rate Range Detection Flags shall be used to show whether or not a pulse rate within range was detected during a given measurement.

3.3.1.5. Measurement Position Detection Support bit

If the Measurement Position Detection feature is not supported, the Measurement Position Detection Support bit shall be set to 0 and the Measurement Position Detection Flag (from the Measurement Status field of the Blood Pressure Measurement characteristic) shall be set to 0. Otherwise the Measurement Position Detection Support bit shall be set to 1 (Measurement Position Detection feature supported) and the Measurement Position Detection Flag shall be used to show whether or not an irregular measurement position was detected during a given measurement.

3.3.1.6. Multiple Bond Support bit

If the Blood Pressure Sensor supports multiple bonds, the Multiple Bond Support bit shall be set to 1. Otherwise it shall be set to 0.

3.3.1.7. E2E-CRC Support bit

If the Blood Pressure Sensor supports E2E protection of Blood Pressure Records with an E2E-CRC, the E2E-CRC Support bit shall be set to 1; otherwise, the E2E-CRC Support bit shall be set to 0.

3.3.1.8. User Data Service Support bit

If the Blood Pressure Sensor supports the User Data Service, the User Data Service Support bit shall be set to 1; otherwise, the User Data Service Support bit shall be set to 0.

3.3.1.9. User Facing Time Support bit

If the Blood Pressure Sensor supports Device Time and User Facing Time reporting based on DTS [6], the User Facing Time Support bit shall be set to 1; otherwise, the User Facing Time Support bit shall be set to 0.

3.4. Enhanced Blood Pressure Measurement

The Enhanced Blood Pressure Measurement characteristic shall be used to send Enhanced Blood Pressure measurements. Included in the characteristic are a Flags field (containing units of Blood Pressure and used to show presence of optional fields), the Blood Pressure Measurement Compound Value field, and depending upon the contents of the Flags field, Time Stamp (base time of the measurement), Pulse Rate, User ID, Measurement Status fields, and User Facing Time (user facing time of the measurement).

The same requirements as for the Blood Pressure Measurement (see Section 3.1) apply, with the additions provided in the subsections below.

3.4.1. Characteristic behavior

No additions.

3.4.1.1. Flags field

The Flags field is extended with the following:

  • Bit 5 is defined as the User Facing Time Flag;
    only when this bit is set, the User Facing Time field is included in the characteristic.

  • Bit 6 is defined as the Epoch Start 2000 Flag;
    the value of this bit determines the Epoch Start time used in time stamps.

3.4.1.2. Blood Pressure Measurement Compound Value field

No additions.

3.4.1.3. Time Stamp field

The Time Stamp field is optional but shall be included in the Enhanced Blood Pressure Measurement characteristic if the Blood Pressure Sensor supports storing of data or if the Blood Pressure Sensor supports the Record Access Control Point.

If the Time Stamp field is present in the Enhanced Blood Pressure Measurement characteristic, bit 1 of the Flags field is set to 1; otherwise, bit 1 of the Flags field is set to 0.

The value of the Time Stamp field is derived from a source of date and time at the time of measurement. If the Time Stamp feature is supported, a source of date and time is mandatory.

The date and time of the Blood Pressure Sensor may be updated by various means such as via a simple user interface on the Blood Pressure Sensor, via the Device Time Service [6], or via the Current Time Service [5].

The time stamp field uses a uint32 to represent the time in seconds since the epoch start time. The epoch start time is defined by the Epoch Start 2000 Flag in the Flags field.

It is left to the implementation to initialize the time source correctly before a Blood Pressure Sensor is used.

3.4.1.4. Pulse Rate field

No additions.

3.4.1.5. User ID field

No additions.

3.4.1.6. Measurement Status field

No additions.

3.4.1.7. User Facing Time field

If present, the User Facing Time field represents the user facing time in seconds since the epoch start time. The epoch start is on January 1 of 1900 or 2000 at 00:00:00, depending on the value of the Epoch Start 2000 flag.

User facing time takes into account time zone, DST adjustments, and manual adjustments of the time displayed to a user.

When this field is present, the Time Stamp field shall also be present and the Time Stamp field shall contain the corresponding UTC reference time as maintained by the server.

This field may only be included in a measurement when the User Facing Time Support flag in the Blood Pressure Feature characteristic is set to 1.

3.5. Enhanced Intermediate Cuff Pressure

The Enhanced Intermediate Cuff Pressure characteristic may be used to send Current Cuff Pressure values to a device for display purposes while the measurement is in progress.

The same requirements as for the Intermediate Cuff Pressure characteristic apply, with the additions below.

3.5.1. Characteristic behavior

No additions.

3.5.1.1. Flags field

The Flags field is extended with the following:

  • Bit 5 is defined as the User Facing Time Flag;
    only when this bit is set, the User Facing Time field is included in the characteristic.

  • Bit 6 is defined as the Epoch Start 2000 Flag;
    the value of this bit determines the Epoch Start time used in time stamps.

3.5.1.2. Intermediate Cuff Pressure field

The Intermediate Cuff Pressure field in the Enhanced Intermediate Cuff Pressure characteristic is not a compound field but a simple field containing one value.

The Intermediate Cuff Pressure field may contain special short float value NaN (see Section 4) as defined in ISO/IEEE 11073-20601 [4] to report an invalid result from a computation step or missing data due to the hardware’s inability to provide a valid measurement.

If the unit of the Intermediate Cuff Pressure is in mmHg, bit 0 of the Flags field is set to 0; otherwise, the unit is kPa and bit 0 of the Flags field is set to 1.

3.5.1.3. Time Stamp field

The Time Stamp field may be included in the Enhanced Intermediate Cuff Pressure characteristic, but this is not recommended in order to avoid sending unnecessary data.

If the Time Stamp field is present in the Enhanced Intermediate Cuff Pressure characteristic, the same requirements apply as in Section 3.4.1.3.

3.5.1.4. Pulse Rate field

No additions.

3.5.1.5. User ID field

No additions.

3.5.1.6. Measurement Status field

No additions.

3.5.1.7. User Facing Time field

The User Facing Time field may be included in the Enhanced Intermediate Cuff Pressure characteristic, but it should not be included to avoid sending unnecessary data.

If the User Facing Time field is present in the Enhanced Intermediate Cuff Pressure characteristic, the same requirements apply as in Section 3.4.1.7.

3.6. Record Access Control Point

A Record Access Control Point (RACP) characteristic is included in the Blood Pressure Service specification as an optional characteristic with associated procedures.

The RACP enables one or more collectors to retrieve Blood Pressure Records.

If the User Data Service [7] is used in combination with the Blood Pressure Service, the Blood Pressure Records will be retrievable on a per-user basis. See [8] for more details.

Records can be retrieved using sequence numbers. The use of time for filtering is an option, but this is optional, as it is not considered the most robust approach in the presence of time faults that cause discontinuities in the time line of the Blood Pressure Sensor.

See [3] for the definition of the RACP characteristic.

3.6.1. Record definition

In the context of the Blood Pressure Service, a record is a Blood Pressure Record.

3.6.2. RACP requirements

3.6.2.1. RACP Op Codes, operators, and operands

Table 3.2 shows the detailed requirements on Blood Pressure RACP Op Codes, Operators, and Operands. Where “Time Filter” is used in the table, a Base Time or a User Facing Time filter can be used.

Op Code

Op Code Requirement

Operator

Operator Requirement

Operand

Operand Require-ment

Filter Type

Filter Parameters

Report Stored Records

or

Report Number of Stored Records

M

All records

M

No Operand Used

N/A

Less than or equal to

O

Sequence Number

<maximum filter value>

C.1

Time Filter

<maximum filter value>

O

Greater than or equal to

M

Sequence Number

<minimum filter value>

M

Time Filter

<minimum filter value>

O

Within range of (inclusive)

O

Sequence Number

<minimum filter value>, <maximum filter value>

C.1

Time Filter

<minimum filter value>, <maximum filter value>

O

First record

O

No Operand Used

N/A

Last record

O

No Operand Used

N/A

Delete Stored Records

O

All records

C.2

No Operand Used

N/A

Less than or equal to

O

Sequence Number

<maximum filter value>

C.1

Time Filter

<maximum filter value>

O

Greater than or equal to

O

Sequence Number

<minimum filter value>

C.1

Time Filter

<minimum filter value>

O

Within range of (inclusive)

O

Sequence Number

<minimum filter value>, <maximum filter value>

C.1

Time Filter

<minimum filter value>, <maximum filter value>

O

First record

O

No Operand Used

N/A

Last record

O

No Operand Used

N/A

Abort Operation

O

Null (0x00)

C.3

No Operand Used

N/A

Responses

Op Code

Op Code Requirement

Operator

Operator Requirement

Operand

Operand Requirement

Number of Stored Records Response

C.4

Null (0x00)

C.4

uint16 containing number of records

C.4

Response Code

M

Null (0x00)

M

Request Op Code, Response Code Value

M
Table 3.2. Blood Pressure RACP Procedure requirements

C.1:

If this Operator is supported, this Operand is mandatory for this Operator. See also detail 1 below.

C.2:

If this Op Code is supported, this Operator is mandatory for this Op Code. See also detail 1 below.

C.3:

Mandatory if the Abort Operation Op Code is supported, otherwise excluded.

C.4:

Mandatory if the Report Number of Stored Records Op Code is supported, otherwise excluded.

M:

Mandatory

O:

Optional

Further RACP procedure details:

  1. The same Operator and Operand combinations shall be supported for the Report Stored Records and the Report Number of Stored Records Op Code. The supported combinations for the Delete Stored Records Op Code may be different.

  2. Filter parameters for Filter Type Sequence Number are uint16 sequence number values.

  3. Time Filter can be the Base Time filter or the User Facing Time filter as defined in Table 3.3.

  4. Filter parameters for Filter Type Base Time and Filter Type User Facing Time are 4-byte second values as specified for the Base Time in the Device Time characteristic in [6].

  5. When a Filter Type is supported, the same combinations of Operand and Operator shall be supported as for the Sequence Number Filter Type.

  6. Response Code values for the RACP can be found in [3].

3.6.2.2. Filter types

The RACP shall support filtering on sequence numbers.

Filtering on base time or User Facing Time may be supported as well but implies inspection of the content of the Blood Pressure Records. The Server will return records that have a time stamp that matches the filter conditions. The records are sent to the Client via notifications on the Blood Pressure Record characteristic.

The filter types for the Blood Pressure Service RACP are listed in Table 3.3.

Operand Filter Type Value

Filter Type Description

0x00

Reserved for Future Use

0x01

Sequence Number

0x02

Base Time (optional)

0x03

User Facing Time (optional)

0x04 – 0xFF

Reserved for Future Use
Table 3.3. Operand filter type values

The Base Time filter and User Facing Time filter options are provided to allow a mechanism for reporting records with a given date or time (or a range of dates and times). Because the Blood Pressure Sensor time may not be monotonically increasing, the records returned may have non-increasing sequence numbers.

3.6.3. RACP behavioral description

The Record Access Control Point shall be used to control notifications for stored Blood Pressure Records, as well as perform actions related to stored records, such as deleting them. Procedures are triggered by a Write to this characteristic value that includes an Op Code specifying the operation as defined in Table 3.2.

In a multiple-bond case, the handling of the Control Point shall be consistent across all bonds (i.e., there is a single database that is shared by all Collectors).

In case the User Data Service is used in combination with the Blood Pressure Service, there is a database (set of records) per registered user/user ID value and a database (set of records) for all non-registered user ID values.

3.6.3.1. Report Stored Records procedure

When the Report Stored Records Op Code is written to the Record Access Control Point, the Blood Pressure Sensor shall notify stored records using the Blood Pressure Record characteristic. Once all data records for a given request have been notified by the Sensor, the Sensor shall indicate the Record Access Control Point with a Response Code Op Code and a Response Code Value in the Operand set to Success (see Record Access Control Point in [3]).

If during the record transfer a new record becomes available (i.e., after the Report Stored Records procedure is initiated), the Sensor may include this new record in the measurement transfer.

If the Sensor does not locate any records matching the conditions set by the Operator and when present, the Operand used, the Sensor shall indicate the Record Access Control Point with a Response Code Op Code and a Response Code Value in the Operand set to No Records Found (see RACP in [3]).

If the operation results in an error condition, this shall be indicated using the Response Code Op Code and the appropriate Response Code Value in the Operand for the error condition (see Section 3.6.4).

If the Sensor needs to interrupt its data transfer before completion for any reason except in the event of an Abort Operation request, the Sensor shall indicate the Record Access Control Point with a Response Code Op Code and a Response Code Value in the Operand set to Procedure not completed (see RACP in [3]). In the event of an Abort Operation command, the procedure terminates immediately without the RACP indicating the Response Code Op Code for this procedure.

3.6.3.2. Report Number of Stored Records procedure

When the Report Number of Stored Records Op Code is written to the Record Access Control Point, the Blood Pressure Sensor shall calculate and respond with a record count in uint16 format. The response is indicated using the Number of Stored Records Response Op Code.

If the Sensor does not locate any records matching the filter criteria of the request, the Sensor shall indicate the Record Access Control Point with a Number of Stored Records Response Op Code and the Operand set to 0x0000.

If the operation results in an error condition, this shall be indicated using the Response Code Op Code and the appropriate Response Code Value in the Operand for the error condition (see Section 3.6.4).

3.6.3.3. Delete Stored Records procedure

When the Delete Stored Records Op Code is written to the Record Access Control Point, the Blood Pressure Sensor shall delete all stored measurements. Deletion of records may be a permanent deletion of records from the patient database. The Sensor shall indicate this characteristic with a Response Code Value of Success if the records were successfully deleted from the patient record database (see RACP in [3]).

If the operation results in an error condition, this shall be indicated using the Response Code Op Code and the appropriate Response Code Value in the Operand for the error condition (see Section 3.6.4).

3.6.3.4. Abort Operation procedure

When the Abort Operation Op Code is written to the Record Access Control Point, the Blood Pressure Sensor shall stop any RACP procedures that are in progress and shall make a best effort to stop sending any further data.

Once all RACP procedures have been stopped, the Sensor shall indicate the Record Access Control Point with a Response Code Op Code and a Response Code Value in the Operand set to Success (see RACP in [3]).

If the operation results in an error condition, this shall be indicated using the Response Code Op Code and the appropriate Response Code Value in the Operand for the error condition (see Section 3.6.4).

3.6.4. RACP error handling procedures

If the Blood Pressure Sensor is unable to complete a procedure defined in Section 3.6.3, for any reason not covered elsewhere in this section, the Sensor shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Procedure not completed (see RACP in [3]).

If the Sensor is unable to process the Abort Operation procedure for any reason not stated elsewhere in this section, the Sensor shall indicate the RACP with a Response Code Op Code and Response Code Value in the Operand set to Abort unsuccessful (see RACP in [3]).

If a request with an Op Code other than Abort Operation is written to the RACP while the Sensor is performing a previously triggered RACP operation (i.e., resulting from invalid Collector behavior), the Sensor shall return an error response with the Common Profile and Service error code of Procedure Already In Progress (see [1]).

If the Op Code that was written to the RACP requests record indications and the Client Characteristic Configuration descriptor is not configured for indications, the Sensor shall return an error response with the Common Profile and Service error code of Client Characteristic Configuration Descriptor Improperly Configured (see [1]).

If the Operator that was written to the RACP is not supported by the Sensor, the Sensor shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Operator Not Supported (see RACP in [3]).

If the Operator that was written to the RACP is invalid, the Sensor shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Invalid Operator (see RACP in [3]).

If the Op Code that was written to the RACP characteristic is not supported by the Sensor, the Sensor shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Op Code Not Supported (see RACP in [3]).

If an Operand that was written to the RACP characteristic is not supported by the Sensor, the Sensor shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Operand Not Supported (see RACP in [3]).

3.6.5. RACP procedure timeout and failure

In the context of the RACP characteristic, a procedure is started when a write to the RACP characteristic is successfully completed. When a procedure is complete, the Server indicates the RACP characteristic with the Op Code set to the corresponding Response Code.

An RACP procedure may consist of multiple characteristic notifications of the Blood Pressure Record Characteristic value followed by an indication of the RACP. When the Blood Pressure Sensor transmits an indication of the RACP characteristic, the response is considered to have timed out if the acknowledgement is not received within the ATT transaction timeout, defined as 30 seconds in the Core Specification Volume 2 Part F section 3.3.3 of [1]. If a timeout occurs, the Sensor shall stop sending any further indications and notifications related to the operation and consider the procedure to have failed.

If the connection to the Collector is lost, the procedure shall be considered to have failed and shall not resume upon the next connection.

3.7. Blood Pressure Record

Within the context of the Blood Pressure Service, a Blood Pressure Record is a container for another characteristic to which a Sequence Number, the other characteristic’s UUID, and optionally an E2E-CRC are added. Segmentation information is provided in the Segmentation Header field. This supports Blood Pressure Records that exceed the size limits of the ATT protocol.

For the Blood Pressure Service, the characteristics that are supported in the Blood Pressure Record are:

  • Enhanced Blood Pressure Measurement

  • Enhanced Intermediate Cuff Pressure

  • Time Change Log Data – from the Device Time Service

The Blood Pressure Sensor reports these characteristics in a single ATT message or in multiple ATT messages depending on the length of the contained characteristic. This segmentation is indicated by the Segmentation Header field. Figure 3.1 illustrates this.

Examples of the BP Record characteristic
Figure 3.1. Examples of the BP Record characteristic

The data to be transported consists of the UUID of the Recorded Characteristic, the value of the Recorded Characteristic, and the optional E2E-CRC. If the total size of this data is greater than (ATT_MTU-4), it is necessary to send multiple notifications of the Blood Pressure Record characteristic to send all of the data.

When the Blood Pressure Record characteristic is configured for notifications via the Client Characteristic Configuration descriptor, and a new record is ready for sending, this characteristic shall be notified as described in the sequel of this section.

The number of notifications that needs to be sent to convey the data to be transported shall be calculated by dividing the size of the data to be transported by (ATT_MTU-4) rounded up to the nearest integer. N represents this number in the steps below:

  1. If N=1, the First Segment and Last Segment bits of the Segmentation Header field shall both be set to 1;

    if N>1, the First Segment bit of the Segmentation Header field shall be set to 1 and the Last Segment bit shall be set to 0.

  2. The Sequence Number Fields shall be set to the current value of the sequence number maintained by the server.

  3. Up to (ATT_MTU-4) octets of the data to be transported shall be used to fill the notification message.

  4. The Blood Pressure Record characteristic shall be notified.

  5. If the value of the Last Segment bit is 1, end the procedure at this point; otherwise, continue to step 6.

  6. The First Segment bit of the Segmentation Header field shall be set to 0.

  7. If the number of octets remaining to be sent can be sent in one more notification of the Blood Pressure Record, the Last Segment bit of the Segmentation Header field shall be set to 1; else, it shall remain set to 0.

  8. The value of the Rolling Segment Counter shall be incremented by one.

  9. The next few octets of the contents of the data to be sent shall be used to fill the notification message, in order, consisting of up to (ATT_MTU-4) octets.

  10. Repeat from step 4.

When the service is initialized (e.g., upon connection to the client), the Rolling Segment Counter may be set to any number in the range 0 to 63. The Rolling Segment Counter should then be incremented continuously without being reset each time the above procedure is used. Once the Rolling Segment Counter reaches 63, it shall roll over to 0 the next time it is incremented.

In general, Enhanced Intermediate Cuff Pressure values should not be included in Blood Pressure Records because these values only have meaning during the measurement process. However, the inclusion of Enhanced Intermediate Cuff pressure values in Blood Pressure Records is permitted and can be useful, for example, for research purposes.

3.7.1. Characteristic behavior

When the Blood Pressure Record is enabled for notifications, this characteristic shall notify when executing the Report Stored Records procedure.

3.7.1.1. Segmentation Header

The first field of the characteristic contains the Segmentation Header. This field contains a First Segment flag, a Last Segment flag, and a 6-bit unsigned integer Rolling Segment Counter. The Rolling Segment Counter is increased for each segment of a record and rolls back to 0 after 63 has been reached.

3.7.1.2. Sequence Number

The Sequence Number field is a Mandatory field that contains a 16-bit unsigned integer with a sequence number of the record. The sequence number starts at 0 and loops back to 0 after 65536 records (per user).

3.7.1.3. UUID

The UUID field is a Mandatory field that contains the UUID of the recorded characteristic value.

3.7.1.4. Recorded Characteristic data

The Recorded Characteristic Data field is a Mandatory field that contains a segment of or a complete characteristic value.

3.7.1.5. E2E-CRC

The E2E-CRC field is an optional field that contains the CRC over all the data of a message.

The corresponding flag in the Blood Pressure feature signals its presence.

When present, the E2E-CRC field is included in a single-message record and in the last message of a multi-message record. The E2E-CRC field is not included in the non-last messages of a multi-message record.

3.8. Requirements for time-sensitive data

The following Blood Pressure Service characteristics can contain time sensitive data and are considered time-sensitive characteristics:

  • Blood Pressure Measurement

  • Intermediate Cuff Pressure

  • Enhanced Blood Pressure Measurement

  • Enhanced Intermediate Cuff Pressure

  • Blood Pressure Record

For these characteristics, the following requirements apply:

  • If the time stamp feature is not supported:

    The value of the time-sensitive characteristic shall be discarded either if the connection does not get established or if the indication is not successfully acknowledged by the Client in a timely manner as decided by the implementation.

  • If the time stamp feature is supported:

    It is strongly recommended that the value of the time-sensitive characteristic be stored if either the connection does not get established or if the indication is not successfully acknowledged by the Client during the connection.

For basic scenarios, the Blood Pressure Sensor should be able to store at least 100 data measurements. Multi-user devices should be able to store that number of measurements per user supported.

If the maximum storage capacity in the Server is reached, the Server should overwrite the oldest measurement data first when writing the new measurement data. For multi-user devices should purge the oldest data for a given user to make room for the most recent data for that user.

When transmitting stored data, the oldest data shall be sent first followed by the next oldest data (in FIFO order) until all stored data has been transferred.

As an alternative to a simple FIFO queue of measurements, the Record Access Control Point can be supported. This allows multiple collectors to retrieve measurement data in a more controlled manner. If the Record Access Control Point is supported:

  • It is mandatory to include time stamps in the Enhanced Blood Pressure Measurements that are reported via the Blood Pressure Record characteristic.

  • It is implementation dependent what a Sensor does when both notifications on the Blood Pressure Record and indications on one or more of the Enhanced Blood Pressure Measurement characteristic or Blood Pressure Measurement characteristic are enabled. Possible sensible behavior includes:

    • A Sensor may stop sending such indications to avoid sending measurements with the same time stamp twice and store them in the data set for RACP usage.

    • A Sensor may send such indications only for measurements completed during a connection and may choose not to include a time stamp in such measurements.

  • Similarly, it is implementation dependent what a Sensor does when both notifications on the Blood Pressure Record and notifications on one or more of the Enhanced Intermediate Cuff Pressure characteristic or Intermediate Cuff Pressure characteristic are enabled. Possible sensible behavior includes:

    • A Sensor may send such notifications only for measurements during a connection and may choose not to include a time stamp in such measurements. This is the recommended normal behavior.

    • A Sensor may stop sending such notifications to avoid sending measurements with the same time stamp twice and store them in the data set for RACP usage.

4. Special values

4.1. Special short float values

The following special short float values are defined in IEEE 11073-20601 [4].

Special Short Value

Value

NaN (not a number)

0x07FF

NRes (not at this resolution)

0x0800

+ INFINITY

0x07FE

– INFINITY

0x0802

Reserved for future use

0x0801
Table 4.1. Special short float values

NaN is used to report an invalid result from a computation step or to indicate missing data due to the hardware’s inability to provide a valid measurement, perhaps from sensor perturbation.

NRes is used to report that the value cannot be represented with the available range and resolution, possibly resulting from an overflow or underflow situation.

5. Acronyms and abbreviations

Acronym/Abbreviation

Meaning

BR/EDR

Basic Rate / Enhanced Data Rate

FIFO

First-In-First-Out

GATT

Generic Attribute Profile

HS

High Speed

LE

Low Energy

MAP

Mean Arterial Pressure

NaN

Not a Number

NRes

Not at this Resolution

RFU

Reserved for Future Use

UUID

Universally Unique Identifier
Table 5.1. Acronyms and abbreviations

6. References

Bibliography

[1] Bluetooth Core Specification v4.0 or later

[2] Health Device Profile v1.0 or later

[3] GATT Specification Supplement v1.1 or later

[4] ISO/IEEE 11073-20601:2016 Health informatics - Personal health device communication – Part 20601: Application Profile - Optimized exchange protocol – 2016 edition or later, including published corrigenda and amendments - https://www.iso.org/standard/66717.html

[5] Current Time Service Specification v1.0 or later

[6] Device Time Service Specification v1.0 or later

[7] User Data Service v1.1 or later

[8] Blood Pressure Profile v1.1