Generic Health Sensor Service

When specification content indicates that there are multiple alternatives to satisfy specification requirements, if one alternative is explained or illustrated in an example it is not intended to limit other alternatives that the specification requirements permit.

It is the goal of Bluetooth SIG that specifications are clear, unambiguous, and do not contain discrepancies. However, members can report any perceived discrepancy by filing an erratum and can request a test case waiver as appropriate.

The bits of the Flags field are defined in Table 3.3.

The Supported Observation Types field reports the observation types that a Generic Health Sensor can generate. These observation types are encoded using a code from the IEEE 11073-10101 nomenclature specification [5]. The structure of this field is shown in Table 3.4.

An example of the Supported Observation Types field for a pulse oximeter sensor that reports blood oxygen saturation and pulse rate observations is shown in Table 3.5. This example uses the following 4-byte Medical Device Communication (MDC) codes from IEEE 11073-10101 [5]:

MDC_PULS_OXIM_SAT_O2 = 0x00024BB8

MDC_PULS_OXIM_PULS_RATE = 0x0002481A

The Supported Device Specializations field reports the supported ACOM device specializations that a Generic Health Sensor can generate. These device specializations are encoded using a code from the IEEE 11073-10101 nomenclature specification [5] and a version number. The structure of this field is shown in Table 3.6.

An ACOM device specialization defines a coherent set of observation types that a sensor implementing that specialization supports. The device specialization defines which of these observation types the PHD shall support and which observation types the PHD may optionally support.

Because MDC codes for device specializations are coming from the infrastructure partition, partition 8 in IEEE 11073-10101 [5], these MDC codes can be encoded using a 2-byte term code.

An example of the Supported Device Specializations field for a blood pressure monitor is shown in Table 3.7. This example uses the following MDC code from [5] without the first two bytes that indicate partition 8:

Code = MDC_DEV_SPEC_PROFILE_BP = 0x00081007; Version = 0x01

Table 3.9 defines the values of the Segmentation Header field. The server shall use these values to provide information to the client on the segments to concatenate to get a complete Health Observation Body structure.

The structure of the Health Observation Body is shown in Table 3.10.

Table 3.11 lists the supported ACOM Observation Class Type values.

The Observation Class Type determines the type of value reported by the observation. These value types are defined in Section 3.2.1.15.

The Flags field bits and their functions are defined in Table 3.12.

The Flags field values reflect the presence of the optional fields. When the Flags field is present, the corresponding bit of the Flags field shall be set to a value of 1, otherwise the corresponding bit of the Flags field shall be set to a value of 0.

The Observation Type field contains a 4-byte MDC code from IEEE 11073-10101 [5] that uniquely defines the type of the observation. A few examples are:

The Observation Type field is mandatory for single observations that are not part of a bundle, and the field is optional for observation bundles. For single observations in bundles, either the bundle contains the Observation Type field that applies to all contained single observations, or each single observation contains the Observation Type field.

The code for the Observation Type can come from the metrics partition (partition 2), the PHD disease management partition (partition 128), the PHD health fitness partition (partition 129) or the PHD aging independently partition (partition 130) of IEEE 11073-10101 [5], but codes from other partitions are not excluded. Private codes can also be used and can come from the private partition or from private code blocks in other partitions.

The Time Stamp field contains an Elapsed Time structure as defined in GSS [1], representing the time the observation was observed.

When there is a Measurement Duration, the Time Stamp field represents the start of the measurement.

The optional Measurement Duration field contains the duration of the measurement in seconds, reported as a floating number.

The Measurement Status field is defined as a series of Boolean conditions. See Table 3.13 for the conditions being reported.

The Observation Id field contains a value that can be used in other observations to reference this specific observation.

The value shall be unique in the context of its usage, which is defined as the set of observations transferred from the server to a client during a connection. When observations have references to other observations, these referenced observations shall be communicated first.

The server can use a simple scheme to assign Observation Id values by starting from a value of 0 and incrementing by one for each next Observation Id being used in a generated observation during a connection. Other schemes that assign unique Observation Ids during a connection are allowed as well.

The Observation Id field shall be absent at the top level of an observation bundle (i.e., when the Observation Type is set to Observation bundle, the Observation Id present flag is set to false). The observation values contained in the bundle can have a unique Observation Id (see Section 3.2.1.15.9).

This optional Patient field contains a local identification of the patient or user using the PHD.

This optional Supplemental Information field contains supplemental information that can help in understanding the observation. The field’s structure is defined in Table 3.14. The field can be used to report the body location of the sensor, the meal context of an observation, or other relevant aspects. Only information that can be expressed by an MDC code can be reported.

An example value for a pulse-oximeter reporting a spot-check is shown in Table 3.15.

The Derived From field contains references to other observations from which this observation is derived. To reference an observation, its Observation Id value is used. The structure of this field is shown in Table 3.16.

The Is Member Of field is present in observations that are part of a group of observations. An example would be an exercise session on a fitness machine that reports the type of the session and that includes the individual heart rate observations taken during the session. The Is Member Of field contains the reference to the group observation. The structure of this field is shown in Table 3.16. In most cases, an observation is a member of one group, but the structure allows for membership in multiple groups.

ACOM allows new attributes to be added to defined classes and also allows new classes to be added to the model. To support a new type of attribute in an observation, a Type-Length-Values field (TLV) is supported.

The structure of this field is shown in Table 3.18.

For the Type of a single TLV, an MDC code is used that can come from partition 1 of IEEE 11073-10101 [5], the Object-oriented partition, and that has a Reference Id starting with “MDC_ATTR_”. Codes from other partitions, including private codes for manufacturer-specific extensions, can also be used.

Each TLV field contains a Format Type with a value as defined in Section 2.6.1 GATT Format Types of the Assigned Numbers [2]. The Format Type determines the encoding of the Encoded Value field. There are Format Types for the encoding of numeric values and strings of various sizes. When the Format Type has a value of 0x1B, the encoded value is an opaque structure that is not further defined by GHSS. When the Format Type has a value of 0x1C, the encoded value follows the MDER encoding rules for an ASN.1 defined value as defined in Annex F of [9].

The structure of the TLV field is shown in Table 3.18.

The Observation value depends on the Observation Class Type. The subsections of this section cover the structure for each Observation Class Type.

If the total size of a generated observation is greater than (ATT_MTU-4), then multiple segments shall be sent to transfer a single Health Observation Body (the data to be transported).

When the Live Health Observations characteristic is configured for indications or notifications via the Client Characteristic Configuration descriptor, when the server has received a command to start sending live observations (see Section 3.5), and when a generated health observation is available, then this characteristic shall be indicated or notified per segment as described below.

The number of segments 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:

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 of 0 to 63. The Rolling Segment Counter should then be incremented continuously without being reset each time the above procedure is used. When the Rolling Segment Counter reaches a value of 63, the Rolling Segment Counter shall roll over to 0 the next time it is incremented.

A GHS Server may follow one of the following strategies to report observations:

The structure of the Stored Health Observations Body field is shown in Table 3.30.

This structure adds a 4-byte record number to the Health Observation Body structure. The record number is used for retrieval of the stored observations using the RACP procedures.

The Record Number should start at a value of 0 for the first generated stored observation and should be increased by one for each subsequently generated observation. The record number should be reset to a value of 0 after 2^32 records.

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

A server that is capable of storing a large number of stored observations should support the “Within range of” RACP Operator (see Table 3.31) to avoid having to transfer a large number of records.

Filter parameters for Filter Type Record Number are uint32 record number values.

Filter parameters for Filter Type Time are 6-byte time values as specified in the Elapsed Time in GSS [1].

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

Response Code values for the RACP can be found in GSS [1].

The RACP shall support filtering on record numbers.

The RACP may support filtering on time as well. 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 Stored Health Observation characteristic.

The filter types are uint8 values as listed in Table 3.33.

The Time filter is provided to allow a mechanism for reporting records with a given date or time (or a range of dates and times). Because the server time might not be monotonically increasing, the records returned might have non-increasing record numbers.

The time values used for filtering are the uint48 values used for the Time Value in the Elapsed Time characteristic from GSS [1]. Filtering on time takes only the time value into consideration and ignores the value of flags or an offset in the time stamp of an observation.

When the Combined Report Op Code is written to the RACP, then the server shall indicate or notify records using the Stored Health Observations characteristic. When all records for a given request have been indicated or notified by the server, then the server shall indicate the RACP with a Combined Report Response Op Code and the Operand set to the number of records reported (see Record Access Control Point in GSS [1]).

The server shall report the records in the order they were created.

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

If the server does not locate any records matching the conditions set by the Operator and, when present, that the Operand used, then the server shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to No Records Found (see RACP in GSS [1]).

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

If the server needs to interrupt its data transfer before completion for any reason except in the event of an Abort Operation request, then the server 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 GSS [1]). In the event of an Abort Operation command, the procedure terminates immediately without the RACP indicating the Response Code Op Code for this procedure.

When the Report Number of Stored Records Op Code is written to the RACP, then the server shall calculate and respond with a record count in uint32 format. The response is indicated using the Number of Stored Records Response Op Code.

If the server does not locate any records matching the filter criteria of the request, then the server shall indicate the RACP with a Number of Stored Records Response Op Code and the Operand set to a value of 0x0000.

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

This section is only applicable if the server supports the Delete Stored Records procedure.

When the Delete Stored Records Op Code is written to the RACP, then the server shall delete all stored observations matching the filter criteria. Deletion of records may be a permanent deletion of records from the database. The server shall indicate this characteristic with a Response Code Value of Success if the records were successfully deleted from the database (see RACP in GSS [1]).

Deleting stored observations might lead to holes in the Record number continuum. The server should not renumber records after deleting some records because this makes it more complex for a client to retrieve newly generated records.

If the server does not locate any records matching the filter criteria of the request, then the server shall indicate the RACP with a Response Code Op Code and Response Code Value in the Operand set to No Records Found.

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

This section is only applicable if the server supports the Abort Operation procedure.

When the Abort Operation Op Code is written to the RACP, then the server shall stop any RACP procedures that are in progress and shall make a best effort to stop sending any further data.

When all RACP procedures have been stopped, then the server shall indicate the RACP with a Response Code Op Code and a Response Code Value in the Operand set to Success (see RACP in GSS [1]).

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

The Observation Schedule descriptor has the same structure as the Observation Schedule Changed characteristic (see Table 3.36).

A client that wants to know the observation schedules can read the Observation Schedule descriptors, when present.

When the descriptor supports writing, then a client can write to the descriptor to set the schedule for the specified observation type. If an Observation Schedule descriptor is written with a schedule that the server cannot support, then the write of the descriptor is rejected with a 0xFF – Out of Range error response. If an Observation Schedule Descriptor is written with a changed value of the Observation Type, then the write of the descriptor is rejected with a 0xFF – Out of Range error response.

When a server generates several types of observations normally at the same time, then a server should support an Observation Schedule descriptor for just one of these types of observations with a write property. For the other types of observations, a read-only Observation Schedule descriptor may or may not be supported.

The Valid Range and Accuracy descriptor has the following structure.