Generic Health Sensor Profile

Abstract

This document specifies the profile for the Generic Health Sensor (GHS). The Generic Health Sensor Profile (GHSP) specifies how to use the Generic Health Sensor Service (GHSS) to communicate health-related observations from different types of Personal Health Devices (PHDs) and of other Generic Attribute Profile (GATT) services to support the exchange of device information, battery, and power status information, and how a device can be used by multiple users. The profile enables new Bluetooth-based sensor types to be added to a healthcare infrastructure without the need to update the infrastructure.

Version: v1.0
Version Date: 2023-06-13
Prepared By: Medical Devices Working Group

Version History

Version Number	Date (yyyy-mm-dd)	Comments
v1.0	2023-06-13	Adopted by the Bluetooth SIG Board of Directors.

Acknowledgments

Name	Company
Erik Moll	Koninklijke Philips N.V.
Barry Reinhold	Lamprey Networks

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 © 2022–2023. 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 Generic Health Sensor Profile and Service specifications (GHS) define a protocol by which Personal Health Device (PHD) data can be exchanged using Bluetooth technology. GHS communicates the semantic data contained in the Abstract Content Information Model (ACOM) defined in IEEE 11073-10206 [11] using GATT.

The Generic Health Sensor Profile (GHSP) specifies how to use the Generic Health Sensor Service (GHSS) to communicate health-related observations from different types of Personal Health Devices (PHD). GHSP specifies usage of other GATT services to support the exchange of device information, battery, and power status information, and how a device can be used by multiple users.

In conjunction with ACOM, GHS provides a unified, extensible approach to PHD communications and can be used in place of services and profiles written for specific medical device types. GHSS is also applicable to other types of PHDs and to PHDs that have content not defined in an open standard that want to operate in a standardized health infrastructure if they can be modeled following ACOM.

1.1. Conceptual model

Existing Bluetooth medical device profiles and services allow several common device types to exchange clinically accurate information; however, each type of sensor device is modeled and defined independently, requiring significant time in specification development, and resulting in a deployment infrastructure where new sensor device types require corresponding infrastructure upgrades because of different methods of exchanging content. The primary objective of GHS is to define a protocol that decouples the exchange protocol from the device type, allowing new device types to enter the market using this protocol. To achieve this decoupling, GHS is designed as an extensible exchange mechanism for abstracted device observations.

The extensibility of ACOM and GHS is achieved by specifying how to exchange self-describing components in a compositional framework. The term compositional framework, as used here, denotes a system in which a set of base components serves as building blocks for constructing more complex representations of devices and device observations. The base components are self-describing in that they contain metadata that allows a collector (a GHS client collecting information from a PHD) to understand and process the components even if the client does not understand the specifics of the PHD.

For medical device observations, the metadata in the observation describes the common concepts by which medical devices report physiological measurements. Examples of these concepts used for measurements include a:

Numeric value, such as the number 30.
Compound value that has more than one closely related components, such as a vector in a Cartesian plane.
Discrete entity, which identifies elements within a defined countable set.
Set of values that is generated by periodic sampling.
Text string that is used when none of the other concepts fits well.

The metadata uses enumerations or numeric values representing enumerations to specify the semantic meaning associated with different elements in the component. The enumerations, called nomenclature terms, capture the clinical understanding of what a medical device is reporting. The nomenclature terms are primarily defined in the IEEE 11073 Working Group and are published in IEEE 11073-10101 [10].

GHS provides the exchange mechanism by which the sensor device communicates the semantic content in ACOM; GHS does not define the model itself. Proper implementations of GHSS and GHSP allow the server’s ACOM to be recreated on the client, which allows the client to populate health-related records on behalf of the sensor device.

1.2. GHS protocol operation

GHS fulfills the role of an exchange protocol defined in IEEE 11073-10206 [11] by moving the information contained in the PHD (fulfilling the server role defined by this specification) to the collector (fulfilling the client role defined by this specification), so that the information in the client is an accurate representation of what was on the server.

The server contains information about the device itself, about time, and about observations that the device has generated. In GHS, the client obtains information about the sensor device by using the Device Information Service (DIS) [3]. Time information is obtained from the Elapsed Time Service (ETS) [8], user identity and settings are obtained from the User Data Service (UDS) [7], and Battery Information is obtained from the Battery Service (BAS) [4].

Observation information is available to the client through GHSS as:

Live observations: These are recorded and transferred, when a client is connected, under server control.
Temporarily stored observations: These are recorded when no client is connected and are transferred under server control when a client connects.
Stored observations: These are retrieved under client control and can be retrieved by multiple clients.

The GHS exchange, from the client’s perspective, progresses through the following steps:

The client sees advertisements from the server and establishes a connection to the server.
When connected, the client uses the supported services as follows:
- The client uses DIS to collect device information if device information is needed.
- The client uses ETS to obtain the current time, sets the time if needed, and enables the current time to be indicated (setting the time can also be done just before disconnecting to avoid time stamps not from the current timeline during the connection.)
- The client optionally uses BAS to obtain battery information and optionally uses UDS to obtain user information.
- The client optionally uses the Reconnection Configuration Service (RCS) [6] to enable the server to disconnect after it completes delivering data or to enable the server to provide a notification when the server is ready to disconnect.
- The client requests stored observations if the server has stored observations that the client is interested in.
  - The client receives the requested stored observations from the server.
- The client enables the server to indicate or notify temporarily stored observations and live observations.
  - The client receives temporarily stored and live observations from the server.
If the server can determine that there are no more observations to exchange, then the server will either disconnect or indicate that there is no more data to exchange to the client, if so configured.
The client disconnects.

1.3. Language

1.3.1. Language conventions

In the development of a specification, the Bluetooth SIG has established the following conventions for use of the terms “shall”, “shall not”, “should”, “should not”, “may”, “must”, and “can”. In this Bluetooth specification, the terms in Table 1.1 have the specific meanings given in that table, irrespective of other meanings that exist.

Term	Definition
shall	—used to express what is required by the specification and is to be implemented exactly as written without deviation
shall not	—used to express what is forbidden by the specification
should	—used to express what is recommended by the specification without forbidding anything
should not	—used to indicate that something is discouraged but not forbidden by the specification
may	—used to indicate something that is permissible within the limits of the specification
must	—used to indicate either: an indisputable statement of fact that is always true regardless of the circumstances an implication or natural consequence if a separately-stated requirement is followed
can	—used to express a statement of possibility or capability

Table 1.1. Language conventions terms and definitions

1.3.1.1. Implementation alternatives

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.

1.3.1.2. Discrepancies

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.

1.3.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.3.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.

1.4. Table requirements

Requirements in tables in this specification are defined as "Mandatory" (M), "Optional" (O), "Excluded" (X), “Not Applicable” (N/A), or "Conditional" (C.n). Conditional statements (C.n) are listed directly below the table in which they appear.

1.5. Conformance

Each capability of this specification shall be supported in the specified manner. This specification may provide options for design flexibility, because, for example, some products do not implement every portion of the specification. For each implementation option that is supported, it shall be supported as specified.

2. Configuration

2.1. Roles

GHS defines two roles: the GHS client and the GHS server. The GHS client corresponds to the Personal Health Gateway (PHG) as used in IEEE 11073-10206 [11]. The GHS server corresponds to the IEEE 11073-10206 [11] Personal Health Device (PHD) and is the device that is equipped with a sensor or sensors and that is generating observations.

The GHS server shall be a GATT server.
The GHS client shall be a GATT client.

2.2. Role and service relationships

A system acting as a GHS client as defined in this specification discovers and uses services from a GHS server as shown in Figure 2.1.

Figure 2.1. Overview of roles and services

2.3. Concurrency limitations and restrictions

There are no concurrency limitations or restrictions defined by this profile.

2.4. Topology limitations and restrictions

The GHS client shall implement the GAP Central role.

The GHS server shall implement the GAP Peripheral role.

There are no further topology limitations or restrictions defined by this profile.

2.5. Bluetooth specification release compatibility

This specification is compatible with Bluetooth Core Specification, v5.4 or later [1] that includes the Generic Attribute Profile (GATT).

2.6. Transport dependencies

There are no known transport dependencies. The rest of this document, however, assumes that the Bluetooth Low Energy (LE) transport is being used.

3. Server role requirements

The GHS server shall instantiate one and only one instance of GHSS [1]. GHSS shall be instantiated as a «Primary Service».

The GHS server shall instantiate one and only one instance of DIS. The GHS server may instantiate at most one instance of ETS, RCS, and UDS. These supplemental services shall be instantiated as «Primary Services».

The GHS server may instantiate one or more instances of BAS. Only one of these instances should be instantiated as a «Primary Service».

Service	Support in Server	Section for Additional Requirements
Generic Health Sensor Service	M	3.1
Device Information Service	M	3.2
Elapsed Time Service	C.1	3.3
Battery Service	O	3.4
Reconnection Configuration Service	O	3.5
User Data Service	O	3.6

Table 3.1. Requirements for the server

C.1:: Mandatory if the server reports time stamps in its observations, otherwise optional. Servers supporting stored or temporarily stored observations shall support time stamps and shall support ETS.

3.1. Generic Health Sensor Service requirements

This section describes additional GHS Server role requirements beyond those defined in GHSS. When making an initial connection to the GHS server to use GHSS [2], these requirements enable a client to know the following information:

The server is a GHS server
The type of specializations that the server supports
The friendly name of the device
If the server supports the UDS
The required level of security

3.1.1. Advertising Data

As required by the Peripheral role of the Generic Access Profile (GAP) defined in Volume 3, Part C, Section 2.2 in [1], the GHS server must support connectable and scannable undirected advertising events. These advertising events include a payload of Advertising Data (AD) of a maximum of 31 octets.

The following subsections under this section put requirements on some of the fields in the Advertising Data and Scan Response Data used by a GHS server. These requirements do not exclude other AD fields. How the AD fields are divided over the advertising event and the scan response is implementation dependent.

3.1.1.1. Service UUIDs AD Type

The use of Service UUIDs AD Type by a GHS server is optional because the Service Data AD Type also includes the GHS Service UUID. When used, the server shall include the GHSS UUID as defined in [12] in the Service UUIDs AD Type field of the AD.

3.1.1.2. Service Data AD Type

The server shall include one or more of the supported specialization or specializations in the Service Data AD Type field of the AD as defined in Table 3.2.

When the server supports UDS, the server shall include one or more User Index values for users for which it has new observations in the Service Data AD Type field of the AD as defined in Table 3.2.

The list of specializations enhances the user experience because the specific health device types following GHSP may be identified by a new client before initiating a connection. The list of User IDs prevents unneeded reconnections by known clients.

The format of the Service Data AD is defined in Table 3.2.

Field	Requirement	Data Type	Size (in octets)	Description
Service UUID	M	uint16	2	The «Generic Health Sensor Service» UUID.
Specialization Count	M	uint8	1	The count of supported specializations being advertised (n). If no specializations are being advertised, then this field has a value of 0.
Specialization Codes	C.1	uint16[n]	n*2	The n MDC term codes of advertised specializations. These 16-bit Medical Device Communication (MDC) term codes come from the communication infrastructure partition (Partition 8) of IEEE 11073-10101 [10].
User Index Count	C.2	uint8	1	The count of registered UDS users with new observations being advertised (m). If there are no new users with new observations, then this field has a value of 0.
User Indices	C.3	uint8[m]	m	The m User Index values of advertised users with new observations.

Table 3.2. Service Data AD

C.1:: The Specialization Codes are present when the Specialization Count is positive, otherwise absent.
C.2:: The User Index Count is present when UDS is supported, otherwise absent.
C.3:: The User Indices are present when the User Index Count is positive, otherwise absent.

Because the size of the Advertising Data is limited, the server may exclude some of the Specialization Codes or User Index values from the Advertising Data some of the time. There is no requirement to always include all supported specializations or all User Index values of users with new observations.

3.1.1.3. Local Name AD Type

The server should include the Local Name containing either the complete or shortened value of the Device Name characteristic as defined in [1] in its AD. This allows the client to display the Device Name to the end user.

3.1.1.4. Example GHS server Advertising Data

An example of the Advertising Data of a GHS server is shown in Table 3.3.

Field	Length (in octets)	AD Type	AD Data
AD Structure 1: Service UUID Data	3	«Incomplete List of 16-bit Service UUIDs» 0x02	«Generic Health Sensor Service» UUID 0x1840
AD Structure 2: Service Data AD Data	8	«Service Data» 0x16	«Generic Health Sensor Service» UUID. 1 specialization, Blood Pressure Monitor, 1 user with new observations, user Index 5 0x18 0x40, 0x01, 0x07 0x10, 0x01, 0x05
AD Structure 3: Local Name	17	«Complete Local Name» 0x09	“ACME BPM 100/100” 0x41 0x43 0x4D 0x45 0x20 0x42 0x50 0x4D 0x20 0x31 0x30 0x2F 0x31 0x30 0x30
Total length	28	–	–

Table 3.3. Example of GHS server Advertising Data

3.1.2. LE GATT Security Levels characteristic

The server should support the LE GATT Security Levels characteristic (see Volume 3, Part C, Section 12.7 in the Bluetooth Core Specification [1]). The client can read this characteristic to know the required security level before accessing any other GHS GATT features on an LE connection. This allows the client to know ahead of time whether there is a need to pair and to initiate pairing in a predictable manner.

If the LE GATT Security Levels characteristic is not included in the GAP Service, then the characteristic may be included in the GHS Service declaration, with the semantics defined in Volume 3, Part C, Section 12.7 of the Bluetooth Core Specification [1] and restricted to the services and characteristics covered by this profile.

3.1.3. Observations

As defined in GHSS, a GHS server may support live observations, temporarily stored observations, and/or stored observations:

Live observations are generated when connected to a client and are sent immediately.
Temporarily stored observations are generated while offline (not connected) and are sent to a client later.
Stored observations are observations stored on the server and are available for retrieval by multiple clients using Record Access Control Point (RACP) procedures.

Temporarily stored observations differ from stored observations in that temporarily stored observations are deleted when sent to a client. To delete stored observations, either the client can invoke an RACP procedure to delete the data or some other external mechanism can be used, such as a user-facing UI. Whether a server supports live observations, temporarily stored observations, or stored observations is an implementation decision. In general, GHS servers that accumulate many offline measurements, such as a glucose monitor, support stored observations.

The transfer of temporarily stored and live observations is server-driven, while the transfer of stored observations is client-driven.

3.1.3.1. Stored observation bundles with multiple time stamps

A server may store observation bundles as described in Section 3.2.1.15.9 in GHSS [2]. The observations in a stored observation bundle may have different time stamps. Servers that store observation bundles with different time stamps for the contained observations may reject RACP transfers using filtering on time. This avoids the server having to filter within a bundle or the server having to decide to include a bundle with some observations not matching the filter criteria.

3.1.4. Observation schedule

A server may support the Observation Schedule descriptors and the Observation Schedule Changed characteristic. The Observation Schedule descriptors are device settings and apply to all users (i.e., use of the UDS consent procedure is not needed).

3.2. Device Information Service requirements

Table 3.4 shows additional requirements beyond those defined in DIS.

The characteristics listed as mandatory and optional in Table 3.4 reflect the mandatory and optional attributes in the System Information class of ACOM.

Characteristic	Requirement
Manufacturer Name String	M
Model Number String	M
Serial Number String	C.1
System ID	C.1
UDI for Medical Devices	C.1, C.2
Firmware Revision String	O
Hardware Revision String	O
Software Revision String	O
Other DIS characteristics	O

Table 3.4. Additional DIS requirements

C.1:: At least one of the Serial Number String, System ID, or UDI for Medical Devices characteristics shall be supported. Any one of these characteristics can be used to fill in the unique system identifier as required by ACOM.
C.2:: When the device has been assigned a UDI for Medical Devices, the UDI for Medical Devices characteristic should be included, otherwise Excluded.

The server should allow access to the Manufacturer Name String and Model Number String characteristics without additional security requirements to allow a client to determine interest in using the server before establishing a secure connection and initiating bonding.

The server should require authentication of a client that reads the Serial Number String characteristic, the System ID characteristic, or the UDI for Medical Devices characteristic because these characteristics uniquely identify a device.

3.3. Elapsed Time Service requirements

The server shall use the same clock for ETS and for time stamps in health observations in GHSS:

The Time Stamp value in a Health Observation body shall match the Elapsed Time value from the Current Elapsed Time when it is read at the same time the observation is generated.
- Observations are from the current timeline when the Time Stamp Is From The Current Timeline field is set to a value of 1.
  - This enables a client to correct time stamps from observations from the current timeline to its own timeline.

When the Current Elapsed Time is updated for a reason other than natural progression of time (the normal way that clock time increases), the server shall update the time stamps of all temporarily stored and stored observations from the current timeline as follows:

When only the Time Zone (TZ)/Daylight Saving Time (DST) offset is changed, no changes shall be made to these observations.
When the Time Value is changed, the server shall follow one of the following update policies for each such observation:
- Policy 1: The Time Stamp Is From The Current Timeline field shall be set to 0 or False.
- Policy 2: The Time Value field is adjusted to reflect the update of the Current Elapsed Time.
  - For example, when the Time Value in the Current Elapsed Time is increased by one hour, the Time Stamp Time Value in the observation shall also be increased by one hour.
The update policy may differ per observation.
- A server may, for example, adjust the time for observations from the last 24 hours and set the Time Stamp Is From The Current Timeline field to a value of 0 for older observations.

3.4. Battery Service requirements

The server may support BAS to provide information on the status of its battery or batteries.

For devices with multiple batteries, the service should instantiate multiple instances of BAS with one instance for the main battery that powers the device (see [4]).

3.5. Reconnection Configuration server requirements

A GHS server supporting RCS [5] should support the Reconnection Configuration server role as defined in the Reconnection Configuration Profile (RCP) [6].

A server should support the Ready for Disconnect feature and the Enable Disconnect procedure as defined in RCS and RCP to support controlled disconnects initiated by the client as well as by the server.

The server should use the Ready for Disconnect feature when the server is ready to disconnect while allowing the client to perform some further procedures before disconnecting.

The server should support the Enable Disconnect procedure to allow the client to tell the server that the client is ready to disconnect.

3.6. User Data Service requirements

This section describes additional requirements beyond those defined in UDS [7] for a GHS server supporting UDS.

UDS allows a GHS server to support multiple patients or users. Each user, after registration as a new user with UDS, has their own set of observations for which a client application needs consent before the server grants access.

A GHS server that supports UDS and Stored Observations should maintain a Record Number sequence per user. The last used Record Number for a user should be increased by one for each subsequent observation for that user.

The User Index value is assigned by the server when a new user is created, and the User Index value is sent to the client when the Register New User procedure is initiated. In observations generated for a user registered with UDS, the Patient field value shall match the User Index.

The GHS server shall maintain the value of the Database Change Increment characteristic separately for each supported User Index.

For GHS servers that support multiple users with UDS, indications or notifications of Health Observations for a specific user, as identified by the User Index and Patient field value, shall not be sent unless the user has given consent via the UDS Consent procedure for that user (i.e., only for the user or patient corresponding to the User Index value).

A GHS server that supports UDS shall transmit observations that are not bound to a user that registered via UDS to a connected client without requiring use of the Consent procedure. The presence and value of the User Index in these observations is implementation dependent. A GHS server may, for example, use User Index 0xFF for an unknown user of a device and allow any client to receive observations with that User Index.

If the user data is deleted (via the Delete User Data procedure), then data corresponding to the User Index value shall be deleted, including all Health Observations for that user.

Table 3.5 lists the recommended UDS characteristics.

UDS Characteristic	Motivation
First Name	Useful in user dialogs
Last Name	Useful in user dialogs

Table 3.5. Recommended UDS characteristics

There are no further requirements on the support of specific UDS characteristics as defined in [7].

4. Client role requirements

The support for roles defined in other profiles are defined in Table 4.1

Profile Role	Section	Support in client
Reconnection Configuration client	Section 4.7	O

Table 4.1. Profile role requirements for the client

Table 4.2 lists the service support requirements for a GHS client. The services supported by a client shall be discovered by the client (see Section 4.2).

Service	Section	Support in Client
Generic Health Sensor Service	Section 4.4	M
User Data Service	Section 4.5	O
Elapsed Time Service	Section 4.6	O
Reconnection Configuration Service	Section 4.7	O
Device Information Service	Section 4.8	M
Battery Service	Section 4.9	O

Table 4.2. Service support requirements for the client

Table 4.3 lists the characteristic and descriptor requirements for a GHS client. The characteristics and descriptors supported by a client shall be discovered by the client (see Section 4.2). When a supported characteristic supports indications or notifications, the Client Characteristic Configuration descriptor (CCCD) shall also be discovered.

Service	Characteristic / Descriptor Requirements	Support in Client
GHSS	Health Sensor Features characteristic	O
	Observation Schedule descriptor	O
	Valid Range and Accuracy descriptor	O
	Live Health Observations characteristic	C.1
	Stored Health Observations characteristic	C.2
	Record Access Control Point characteristic	C.2
	GHS Control Point characteristic	C.1
	Observation Schedule Changed characteristic	O
ETS	Current Elapsed Time characteristic	O
BAS	Battery Level characteristic	O
	Battery Level Status characteristic	O
	Battery Information characteristic	O
	Other Battery Service characteristics	O
UDS	User Control Point characteristic	C.3
	User Index characteristic	C.3
	Registered User characteristic	C.3
	Database Change Increment characteristic	C.3
	Other UDS Data characteristics	O
DIS	Manufacturer Name String characteristic	M
	Model Number String characteristic	M
	Serial Number String characteristic	M
	Firmware Revision characteristic	M
	System ID characteristic	M
	UDI for Medical Devices characteristic	M
	Hardware Revision characteristic	O
	Software Revision characteristic	O
	Other DIS characteristics	O
RCS	RC Feature	C.4
	RC Settings	C.4
	RCCP	C.4

Table 4.3. Characteristic and descriptor requirements for the client

C.1:: Mandatory if the client supports live health observations.
C.2:: Mandatory if the client supports stored health observations.
C.3:: Mandatory if the client supports UDS.
C.4:: Mandatory if the client supports RCS.

4.1. GATT sub-procedure requirements

Requirements in this section represent a minimum set of requirements for a client. Other GATT sub-procedures may be used if supported by both the client and the server.

Table 4.4: summarizes additional GATT sub-procedure requirements beyond those required by all GATT Clients.

GATT Sub-Procedure	Client Requirements
Discover All Primary Services	C.1
Discover Primary Services by Service UUID	C.1
Find Included Services	O
Discover All Characteristics of a Service	C.2
Discover Characteristics by UUID	C.2
Discover All Characteristic Descriptors	M
Notifications	M
Indications	M
Read Characteristic Descriptors	M
Write Characteristic Descriptors	M
Read Characteristic Value	M
Write Characteristic Value	M
Read Long Characteristic Values	C.3
Write Long Characteristic Values	C.4

Table 4.4. Additional GATT sub-procedure requirements

C.1:

Mandatory to support at least one of these sub-procedures.

C.2:

Mandatory to support at least one of these sub-procedures.

C.3:

Optional. Needed when reading a characteristic longer than (ATT_MTU – 1) octets.

The GHSS Health Sensor Features characteristic and some UDS data characteristics may have such lengths.

C.4:

Optional. Needed when UDS is supported for writing a UDS data characteristic longer than (ATT_MTU – 3) octets.

4.2. Service discovery

For the client to discover the services supported by the GHS server, the client shall perform primary service discovery using either the GATT Discover All Primary Services sub-procedure or the GATT Discover Primary Services by Service UUID sub-procedure.

The services listed as Mandatory in Table 4.2 shall be discovered.

The services listed as Optional in Table 4.2 may be discovered.

The client may discover any included services in the discovered services.

4.3. Characteristic and descriptor discovery

The client shall perform either the GATT Discover All Characteristics of a Service sub-procedure or the GATT Discover Characteristics by UUID sub-procedure to discover the supported characteristics listed in Table 4.3.

The client shall perform the GATT Discover All Characteristic Descriptors sub-procedure to discover the supported characteristic descriptors listed in Table 4.3 and the CCCDs of discovered characteristics that support indications or notifications.

The client shall allow additional characteristics and descriptors in the service records of services used with this profile.

4.4. GHSS client role requirements

A GHS client shall support either live health observations or stored health observations or both.

4.4.1. Segmentation

The observations generated by a GHS server may be longer than the ATT_MTU size, therefore GHS uses the segmentation scheme for the Live Health Observations characteristic and the Stored Health Observations characteristic. A client shall support this segmentation scheme and shall reconstruct the original Health Observation Body if all segments are received without error.

4.4.2. Single or bundled observations

A GHS server may send observations individually or in a bundle. A bundle contains one or more fields that are common to all observations in the bundle. An example of a common field is the time stamp. A client shall receive individual and bundled observations without error.

4.4.3. Observation Class Types

A GHS server supports a finite set of Observation Class Types such as Numeric, Simple Discrete, and Sample Array. A client shall receive observations with any of the Observation Class Types specified in GHSS without error.

4.4.4. Observation Types

Each observation contains an IEEE 11073-10101 nomenclature code that tells the client what the observation type is (e.g., an oral temperature observation or a body mass observation). The IEEE nomenclature codes also support private codes so that a manufacturer can support the transport of proprietary data. If the client does not understand an observation type, then the client may skip parsing the rest of the observation. A client should be robust when receiving unknown observation types (e.g., a client may raise an alarm or log an error when this occurs in a medical context).

4.4.5. Live Data Transfer

A client may support both RACP transfers of stored observations and transfers of temporarily stored and live observations. What a client does with the received observations is implementation dependent.

This section covers transfers of live and temporarily stored observations. Section 4.4.6 covers stored data retrieval using RACP.

To receive live and temporarily stored observations, the client shall enable indications and or notifications of the Live Health Observations characteristic as supported by that characteristic via the CCCD. The client shall also enable indications of the GHS Control Point before using the GHS Control Point via the CCCD.

A client should not rely on a server that supports indications and notifications of a characteristic to also support simultaneous enabling of indications and notifications of that characteristic.

A client shall be able to enable indications of the Live Health Observations characteristic and shall be able to enable notifications of the Live Health Observations characteristic. This enables a client to receive live observations from a server that supports either indications or notifications of the Live Health Observations characteristic.

To control the flow of live data, the client shall use the GHS Control Point as follows:

To start sending live and temporarily stored observations, the client shall write the Start Sending Live Observations Op Code to the GHS Control Point.
- After a reconnection, a client needs to start sending live and temporarily stored observations again.
To stop sending live and temporarily stored observations, the client shall write the Stop Sending Live Observations Op Code to the GHS Control Point.

After issuing either the Start Sending Live Observations Op Code command or the Stop Sending Live Observations Op Code command, the client will receive an indication of the GHS Control Point or an ATT_ERROR_RSP.

After live data transfer is started, the client shall accept multiple indications or notifications of the Live Health Observations from a GHS server without error.

4.4.6. Stored Data Retrieval using RACP

The Generic Health Sensor uses the RACP as defined in GSS [9]. The RACP enables multiple clients to collect the same sets of observations.

The client may write to the RACP to request a procedure. A procedure begins when the client writes to the RACP to perform some preferred action and ends when the client receives an RACP indication as a response.

If the Combined Report procedure is performed, then the procedure may include one or more Stored Health Observation characteristic indications or notifications between the write to the RACP characteristic that begins the procedure and the RACP indication that ends the procedure.

When the GHS server supports observation bundles of observations with different time stamps, transfers using time ranges may not be supported (because it would be unclear when and when not to include the bundle in the resulting set of records).

The client shall not attempt to perform any RACP procedure other than the Abort Operation procedure before a previous procedure is complete, otherwise the client will receive an ATT_ERROR_RSP with the error code set to Procedure Already In Progress.

The client shall configure the RACP characteristic for indications before the client requests a defined RACP procedure, otherwise the client will receive an ATT_ERROR_RSP with the error code set to Client Characteristic Configuration Descriptor Improperly Configured.

The client shall configure the Stored Health Observation characteristic for indications or notifications before the client requests an RACP procedure that reports Stored Health Observations, otherwise the client will receive an ATT_ERROR_RSP with the error code set to Client Characteristic Configuration Descriptor Improperly Configured. Indications provide a reliable transport of characteristic values.

The client shall be able to enable indications of the Stored Health Observations characteristic and shall be able to enable notifications of the Stored Health Observations characteristic. This enables the client to receive stored observations from a server that supports either indications or notifications of the Stored Health Observations characteristic.

4.4.7. Record Definition

Within the context of GHSS, a record is a Stored Health Observations Body as defined in GHSS [2].

4.4.8. RACP procedure requirements

The client should support the Op Codes, Operator, and Filter Type combinations as defined in GHSS [2].

4.4.9. RACP behavioral description

The client may write to the RACP characteristic using one of the supported Op Codes in GHSS [2] to request a server to perform a procedure. This shall include an Operator and Operand that are valid within the context of that Op Code as defined in GHSS [2].

The procedures including Filter Types are described in Sections 4.4.9.1 to 4.4.9.5.

The client shall accept the fact that the server may add or delete observations while RACP procedures are taking place and between two successive RACP procedures. For example, the client may perform the Request Number of Stored Records procedure with the Procedure Operator set to All Records to get the total number of records currently stored by the server. However, if the client then performs a Combined Report procedure with the Procedure Operator set to All Records, then the client shall accept receiving a different number of records from this procedure than the server reported in the response to the Report Number of Stored Records. This is because the server may have generated new stored observations or may have deleted stored observations through user interaction in the time between the Request Number of Stored Records procedure and the Combined Report procedure. This is used as an example, but the client shall accept this happening with any RACP procedure.

The client shall also accept the possibility that the server might not provide a continuum in the case of any catastrophic hardware or software error that results in the Record Number being reset, although the server should maintain a Record Number continuum while collecting observations.

Because the server may support multiple bonds, the client shall accept the fact that other clients may change the contents of the server’s observation database. For example, Client 2 may delete records from the server’s database that Client 1 then can no longer retrieve. This will also affect the Record Number continuum.

Because the handling of multiple bonds is vendor-specific, a client shall accept not being able to use all RACP procedures. For example, a server may only allow certain bonded clients (such as a doctor’s computer) to use the Delete Stored Records procedure, while not allowing other bonded clients (such as computers of patients) to use the Delete Stored Records procedure, or vice versa.

When a server supports both RACP and UDS, the client shall use the Consent procedure to retrieve the Stored Health Observations for a specific user (see Section 4.5 for more information).

4.4.9.1. Filter Types

Certain RACP procedures use a Filter Type that is used to determine the portion of the stored records on the server to which the procedure applies. The format of the Filter Type and the RACP procedures that have a Filter Type operand are defined in GHSS [2]. The client may filter using the Record Number filter or the Time filter as supported by the server.

The client may use the Record Number filter to retrieve a specific record or a range of records. The Record Number used is obtained from the Record Number field in the Stored Health Observations Body.

The client may use the Time filter to retrieve records from a specific date and time or a range of dates and times.

The Time filter is provided to allow a mechanism for the client to perform RACP procedures with a given date or time or a range of dates and times. However, because the recorded time value can be corrupted (because of time faults or other problems), the Record Number filter should be used in most cases. For example, the client can use the Report Number of Stored Records procedure to obtain all records that a server has collected since the last record received by the client. The client can do this by using the Record Number filter with the Record Number set to the Record Number of the last Stored Health Observation received by the client and incremented by one.

4.4.9.2. Report Number of Stored Records procedure

To request a server to report the number of stored records, the client shall use the Report Number of Stored Records procedure. To receive the number based on filter criteria, an appropriate Operator and Operand shall be used. Refer to GHSS [2] for Operand requirements when used with a specific Operator; in some cases, no Operand is used.

The client shall wait for the Number of Stored Records Response RACP indication containing the number of stored records available in the server as per the request. The Number of Stored Records Response RACP indication ends the Report Number of Stored Records procedure.

The client may also receive a Response Code RACP indication with the Response Code Value representing an error condition that occurred in processing the request. For general error-handling procedures, see Section 4.10.

The value returned by the Number of Stored Records procedure can, for example, be used for the user interface (UI) on the client or to let the client acquire an estimate of the number of records the client might receive to determine if it has sufficient resources. The client should not rely on this value to determine whether new records are available from the server. The client should request new records by filtering with a Record Number or a Time value incremented from a previous transfer session; however, Record Number is preferred because it is expected to be more robust.

4.4.9.3. Combined Report procedure

To request the transfer of stored records from the server, the client shall use the Combined Report procedure. To receive a selected set of stored records based on filter criteria, an appropriate Operator and Operand shall be used. Refer to GHSS [2] for Operand requirements when used with a specific Operator; in some cases, no Operand is used.

After the server has successfully sent all records for a given request, the server will indicate the RACP with a Combined Report Response Op Code and the Operand set to the number of records reported.

The client may receive a Response Code RACP indication with the Response Code Value representing an error condition that occurred in processing the request. For general error-handling procedures, see Section 4.4.10. The following are descriptions of specific error conditions and procedures that should be used:

If, after initiating a Combined Report, the client receives a Response Code RACP indication with the Response Code Value set to No Records Found (0x06), then this indicates that the server does not have any records that meet the specified criteria.
If, after requesting and receiving stored records, the client receives a Response Code RACP indication with the Response Code Value set to Procedure Not Completed (0x08), then this indicates that the server interrupted its data transfer before completion for an unspecified reason. If this occurs, then the client may reattempt the data transfer using the same Op Code and Operator but should modify the filter criteria in the Operand such that data already successfully received does not need to be retransmitted.
If a condition arises where a client cannot receive the requested data, then the client may request to abort the data transfer as described in Section 4.4.9.5.

4.4.9.4. Delete Stored Records procedure

To request deletion of stored records within the server, the client shall use the Delete Stored Records procedure. To delete a selected set of stored records based on filter criteria, an appropriate Operator and Operand shall be used. Refer to GHSS [2] for Operand requirements when used with a specific Operator.

The client shall wait for the Response Code RACP Indication with the Response Code Value set to Success, indicating successful deletion of records, as per the request, or the client shall wait for the procedure to time out according to the procedure timeout operation described in Section 4.4.11.

A server may support deletion of records only for a specific authorized client.

4.4.9.5. Abort Operation procedure

To abort a procedure initiated by the client, the client shall use the Abort Operation procedure as defined in GHSS [2].

The client shall then wait for the Response Code RACP indication with the Response Code Value set to Success, indicating that the procedure has been successfully aborted, or the client shall wait for the procedure to time out according to the procedure timeout operation described in Section 4.4.11. Although servers must stop the data transfer after they have sent the Response Code Value of Success, the servers may still have some records queued for transfer. The client may choose to process or ignore these additional records but shall allow this lag in the termination of the transfer.

The Request Op Code in the Operand of the Response Code RACP indication is used to determine if a Response Code RACP indication is received in response to an Abort Operation procedure or to the procedure that the Abort Operation is trying to abort. If the Abort Operation procedure is completed successfully, then the server sends the Response Code RACP indication with the Request Op Code in the Operand set to Abort Operation.

The client may also receive a Response Code RACP indication with the Request Op Code in the Operand set to Abort Operation and the Response Code Value representing an error condition that occurred in processing the request. Although in practice not all Response Code Values may be returned for an Abort Operation procedure, a client shall handle all defined Response Code Values in response to the Abort Operation procedure. For a description of specific error conditions and procedures that should be used, see Section 4.4.10. For descriptions of general error conditions, see Section 4.10.

If, after requesting the abort, the client receives a Response Code RACP indication with the Request Op Code in the Operand set to Abort Operation and the Response Code Value set to Abort Unsuccessful, then this indicates that the server cannot process the abort.

4.4.10. RACP error handling

RACP procedures may result in error responses as described in Section 3.4 of GHSS [2]. For requirements on the client for handling Control Point errors, see Section 4.10. This section describes further record error handling by the client.

4.4.10.1. Single record errors

In some circumstances, a received record may be invalid. This may be because of an implementation issue, or a packet error caused for a variety of reasons. For increased robustness, clients should check for invalid records. Examples of checks include:

Checking if the Segmentation Header in the different segments of a multi-message Stored Health Observation contains a first segment, intermediate segments, and a last segment with subsequent Rolling Segment Counter values. If not, then the record is invalid.
Checking if the Length field of an observation matches the length of the record. If not, then the record is invalid.

If an invalid record is detected, then the client may re-request a single record using the RACP with the Operator set to Within Range Of and the Operand set to the Record Number Filter Type with the minimum value of the range and maximum value of the range both set to the Record Number value of the invalid record.

The client may also enable the Stored Health Observations characteristic for indications and not for notifications to use a reliable transport of the segments.

If the record is retransmitted and still found to be invalid after such reattempts as left to the implementation, then the client should discard the invalid record.

4.4.11. RACP procedure timeout

In the context of the RACP characteristic, a procedure is started when the client receives the response to the client’s Write request for the RACP characteristic. The procedure is completed when the RACP characteristic is indicated with the Op Code set to Response Code, Combined Report Response, or Number of Stored Records Response.

An RACP procedure may consist of multiple notifications or indications of the Stored Health Observation characteristic. A procedure is considered to have timed out if a notification or an indication is not received within the transaction timeout of 30 seconds from the start of the procedure or the last notification or indication received as a result of this procedure.

If the link is lost while an RACP procedure is in progress, then the procedure shall be considered to have timed out. To handle this condition, see Section 4.4.11.1.

Therefore, a client shall start a timer, with the value set to the procedure timeout, after the write response is received from the server. The timer shall be restarted after every Stored Health Observation notification or indication received. The timer shall be stopped when an RACP indication is received, and the Op Code is set to Response Code, Combined Report Response or Number of Stored Records Response. If the timer expires, then the procedure shall be considered to have failed.

4.4.11.1. Procedure timeout handling

If an RACP procedure times out (for details of how this may occur, see Section 4.4.11), then no new RACP procedure shall be started by the client until a new link is established with the server.

In the case of a procedure timeout during a Combined Report procedure, the client may consider the received reconstructed records to be valid. However, the client shall assume that the records received during a Combined Report procedure that has timed out are an incomplete set of records based on the filter criteria. The client may then perform the procedure again when a new link is established, adjusting the filter criteria based on the records received during the incomplete transfer.

4.4.12. Using other GHSS characteristics and descriptors

4.4.12.1. Health Sensor Features characteristic

When supported by the server, a client may use the Health Sensor Features characteristic to determine the features that the GHS server supports. The Health Sensor Features characteristic can be read and may support indications. The client can use the value of the Health Sensor Features characteristic to fill in a part of the ACOM System Information.

Note

Note: The indication of the Health Sensor Features characteristic can only carry the first (ATT_MTU – 3) octets of the characteristic value. See Volume 3, Part F, Section 3.4.7.2 of [1]. Consequentially, to read subsequent octets, the client must use a long read.

4.4.12.2. Valid Range and Accuracy descriptor

When the Valid Range and Accuracy descriptors are present on the server, a client may read these descriptors to retrieve the valid range or the accuracy of the observation types as present in these descriptors. This information can be used to render graphs of such observations on an appropriate scale.

4.4.12.3. Observation Schedule descriptor and Observation Schedule Changed characteristic

When Observation Schedule descriptors are present on the server, a client may read these descriptors to retrieve the schedule by which the observations of the types present in these descriptors are generated by the server.

The client may try to update the schedule of the given observation type by writing to this descriptor. The write will fail if the server does not support the update. The client should be able to handle an Out of Range error response that the server will return when the schedule cannot be supported.

When the Schedule Changed characteristic is supported by the server, the client may enable indications on this characteristic to receive information on schedules changed by an action other than this client writing to an Observation Schedule descriptor.

4.5. User Data Service Client role requirements

UDS [7] provides consent-based access to both the GHS Observation characteristics and the UDS characteristics.

A GHS server using UDS may use UDS for some but not all its users. The client shall use the UDS Consent procedure before retrieving observations for the users for which UDS is used (see Section 4.5.8 for more details).

4.5.1. User Data Service characteristics

A client may read and write the value of UDS characteristics. The client shall use the Consent procedure defined in Section 4.5.5.2.2 to access the UDS characteristics exposed by the server.

For UDS characteristics that exceed the negotiated ATT_MTU size (e.g., UTF-8-based characteristics), the client should use the GATT Read Long Characteristic Value sub-procedure and the GATT Write Long Characteristic Value sub-procedure for reading and writing the characteristic value.

Clients may support the caching of UDS characteristic values. Clients that are used in a public environment (e.g., a gym with a fitness machine) should not cache values, but personal clients (e.g., a smartphone, tablet, sports watch, or personal computer) should cache values for later use.

4.5.2. User Index

If a GHS server supports UDS, then the client may read the User Index characteristic to confirm for which user the UDS characteristics are exposed before the client attempts to read or write any UDS characteristics.

4.5.3. Database Change Increment

The Database Change Increment characteristic is used to keep track of updates to UDS characteristics supported by both a GHS server and a client (i.e., updates made either through the UI of the GHS server or through the UI of a client).

If the GHS server supports the Database Change Increment characteristic, then the client may configure the Database Change Increment characteristic for notifications, except for clients that support the User Data Synchronization feature for which notifications become mandatory, as specified in Section 4.5.7.

A notification of the Database Change Increment characteristic alerts the client that a change to at least one of the values has occurred, and the client should read all UDS characteristics that are supported by the client and the server.

If the client supports the User Data Synchronization feature, then the requirements in Section 4.5.7 apply.

If the client does not support the User Data Synchronization feature, then after the client has completed writing a new value to one or more UDS characteristics, the client shall read the Database Change Increment value from the GHS server and write the value incremented by one to the Database Change Increment characteristic of the GHS server.

A rollover of the value of the Database Change Increment characteristic is extremely unlikely over the life of the GHS server, but if a rollover occurs, then this can be handled in an implementation-dependent way. The implementation can, for example, ask the user to confirm the values via the UI.

4.5.4. Registered User characteristic

The GHS server uses the Registered User characteristic to communicate a Registered User Index and Registered User Name via one or more GATT indications to the client. The client can initiate this via the List All Users procedure described in Section 4.5.5.2.4. For the List All Users procedure, the client shall configure the Registered User Characteristic for indications (via the CCCD).

4.5.5. User Control Point characteristic

Before performing a User Control Point procedure, the client shall configure the User Control Point characteristic for indications (via the CCCD).

The client may perform a write to the User Control Point to request a procedure. A procedure begins when the client writes a particular Op Code to the User Control Point to perform some preferred action and ends when the client sends a confirmation to acknowledge the User Control Point indication sent by the GHS server at the end of the procedure. This indication includes the Response Code, Requested Op Code, and Response Value. This indication may also include a Response parameter as defined in UDS [7].

4.5.5.1. User Control Point procedure requirements

Table 4.5 shows the requirements for the User Control Point procedures (Op Codes) in the context of this profile.

Procedure (Op Code)	Requirement
Register New User	C.1
Consent	C.1
Delete User Data	C.1
List All Users	C.2
Delete User(s)	C.2

Table 4.5. User Control Point procedure requirements

C.1:: Mandatory for a client supporting UDS [7].
C.2:: Optional for a client supporting UDS [7].

4.5.5.2. User Control Point behavioral description

The client shall write to the User Control Point characteristic using one of the supported Op Codes in Table 4.5 to request a GHS server to perform a procedure. This may include a parameter that is valid within the context of that Op Code as defined in UDS [7].

4.5.5.2.1. Register New User procedure

To register a new user in the GHS server, the client shall use the Register New User Op Code followed by a parameter value that represents the Consent Code defined by the user as defined in UDS [7].

Clients should cache the Consent Code for later use.

The client shall wait for the User Control Point Indication containing the Response Code with the Response Value set to Success, with a Response parameter value that represents the User Index assigned by the GHS server for the new user or set to an error response value.

The Register New User procedure may time out according to the procedure timeout operation described in Section 4.5.5.2.6.