# Advanced Pulse Oximetry System for Remote Monitoring and Management

Authors: Ju Geon Pak; Kee Hyun Park
Journal: Journal of Biomedicine and Biotechnology
 (2012)

---

## Abstract

Pulse oximetry data such as saturation of peripheral oxygen (SpO2) and pulse rate are vital signals for early diagnosis of heart disease. Therefore, various pulse oximeters have been developed continuously. However, some of the existing pulse oximeters are not equipped with communication capabilities, and consequently, the continuous monitoring of patient health is restricted. Moreover, even though certain oximeters have been built as network models, they focus on exchanging only pulse oximetry data, and they do not provide sufficient device management functions. In this paper, we propose an advanced pulse oximetry system for remote monitoring and management. The system consists of a networked pulse oximeter and a personal monitoring server. The proposed pulse oximeter measures a patient’s pulse oximetry data and transmits the data to the personal monitoring server. The personal monitoring server then analyzes the received data and displays the results to the patient. Furthermore, for device management purposes, operational errors that occur in the pulse oximeter are reported to the personal monitoring server, and the system configurations of the pulse oximeter, such as thresholds and measurement targets, are modified by the server. We verify that the proposed pulse oximetry system operates efficiently and that it is appropriate for monitoring and managing a pulse oximeter in real time.


---

## Body

## 1. Introduction

Nowadays, various personal health devices (PHDs) are released on a continual basis in recognition of the necessity for healthcare technologies at home. A PHD is a device that measures data on the health of its user, for instance, a pulse oximeter, activity monitor, or medication reminder. Among the various PHDs, the pulse oximeter, which measures pulse oximetry data (e.g., saturation of peripheral oxygen (SpO2) and pulse rate), has become one of the most important PHDs for early diagnosis of heart disease [1, 2].However, some of the existing pulse oximeters are not equipped with communication capabilities, and consequently, the continuous monitoring of patient health is restricted. Moreover, even though certain oximeters have been built as network models, they focus on exchanging only pulse oximetry data and they do not provide sufficient device management functions.Meanwhile, in a situation, where networked PHDs are being applied to various u-health services, the standardization of diverse PHDs is very important to guarantee interoperability between u-health services [3, 4]. As a result, ISO/IEEE 11073 [5] was proposed to define how personal health data should be exchanged between a PHD and a monitor and what format should be used for the data.Despite the ISO/IEEE 11073 Committee efforts to standardize various PHDs, many existing PHDs are nonstandard. Many manufacturers of PHDs for u-health service providers still use their own protocols, and consequently their PHDs cannot be regarded as interoperable. This causes increases in maintenance costs and prevents an integrated u-health service.In this paper, we propose an advanced pulse oximetry system for remote monitoring and management. The system consists of a networked pulse oximeter and a personal monitoring server. The proposed pulse oximeter measures a patient’s pulse oximetry data and transmits the data to the personal monitoring server. For the proposed system to support remote monitoring and management functions, we implement a PHD agent and manager on the basis of our previous design study [6]. The PHD agent is placed in the pulse oximeter, and the PHD manager is placed in the personal monitoring server.The PHD agent converts pulse oximetry data and operational errors that occur in the pulse oximeter to an ISO/IEEE 11073 message format and transmits them to the personal monitoring server. In the proposed system, the pulse oximeter measures SpO2 and pulse rate and detects four operational errors: sensor_disconnected, sensor_off, signal_non-detected, and signal_inadequate. The PHD manager extracts the pulse oximetry data and operational errors from the received messages. It also manages two components of the system configuration of the pulse oximeter: the thresholds for SpO2 and pulse rate and measurement targets.We verify that the proposed pulse oximetry system operates efficiently and that it is appropriate for monitoring and managing a pulse oximeter in real time; the average response time for transmitting pulse oximetry data or errors is 251 ms.The rest of this paper is organized as follows: Section2 introduces the ISO/IEEE 11073 standard as background information. Section 3 describes the pulse oximetry system in detail. Section 4 presents the results of implementation and evaluation of the system. Finally, Section 5 draws conclusions and discusses some future directions for research.


## 2. ISO/IEEE 11073

ISO/IEEE 11073 was proposed on May 2006, to guarantee interoperability between various PHDs. It specifies how personal health data should be exchanged between a PHD and a monitor and what format should be used for the data. The 11073-20601 Optimized Exchange Protocol [5] was proposed to define the communication procedure and interoperable transmission format. Figure 1 shows the communication procedures between PHD (or agent) and manager. Communication procedure can be divided into four phases as follows.(i)
Association Phase. In this phase, an agent sends an association request message including association information (e.g., system ID and configuration ID) to a manager to establish a session. The manager analyzes the message and checks the configuration of the agent. If the manager can recognize the configuration, the manager responds with an “accepted” parameter (i.e., the association was accepted). In this case, the operation phase is initiated. Alternatively, if the manager does not recognize the configuration, the manager responds with an “accepted-unknown-config” parameter (i.e., the association was accepted but the configuration needs transmitted). In this case, the configuration phase is initiated.(ii)
Configuration Phase. During this phase, the agent sends its configuration to the manager. The manager stores the configuration and responds with an “accepted” parameter to prompt the agent into the operation phase.(iii)
Operation Phase. During this phase, the agent transmits personal health data and device information to the manager. The personal health data are transmitted periodically or whenever the agent takes health data from a PHD. In contrast, device information is transmitted at the request of the manager, which sends a “Get” method to retrieve the device information.(iv)
Disassociation Phase. If the agent or manager does not have any more messages to transfer, this phase is initiated to release the established session. During this phase, association release request and response messages are exchanged, with a “disassociation” reason.Figure 1
Communication procedure.The ISO/IEEE 11073 Standard also specifies device specialization protocols considering the characteristics of each PHD, such as 11073-10404 (pulse oximeter) [7], 11073-10407 (blood pressure monitor) [8], 11073-10408 (thermometer) [9], and 11073-10417 (glucose meter) [10]. Each specialization protocol details how a PHD works and acts as a description for creating a specific type of agent.Among the protocols, 10404 describes pulse oximeters in detail. This protocol defines objects to represent data that are measured or estimated by pulse oximeters (e.g., SpO2, pulse rate, and pulsatility). Of these, SpO2 and pulse rate are mandatory objects. Figure 2 depicts the standard messages for transmitting SpO2 and pulse rate.Figure 2
Standard message for transmitting SpO2 and pulse rate.Despite the ISO/IEEE 11073 Committee efforts to standardize various PHDs, many existing PHDs are nonstandard. Many manufacturers of PHDs for u-health service providers still use their own protocols, and consequently their PHDs cannot be regarded as interoperable. This causes increases in maintenance costs and prevents an integrated u-health service.


## 3. Proposed Pulse Oximetry System

In this section, we describe the proposed pulse oximetry system in detail. The system consists of a networked pulse oximeter and a personal monitoring server. The proposed pulse oximeter measures a patient’s pulse oximetry data and transmits the data to the personal monitoring server. For the proposed system to support remote monitoring and management functions, we implement a PHD agent and manager on the basis of our previous design study [6]. The PHD agent is placed in the pulse oximeter, and the PHD manager is placed in the personal monitoring server.The PHD agent converts pulse oximetry data and operational errors that occur in the pulse oximeter to an ISO/IEEE 11073 message format and transmits them to the personal monitoring server. The PHD manager extracts the pulse oximetry data and operational errors from the received messages. It also manages the system configuration of the pulse oximeter.


### 3.1. Pulse Oximeter

The pulse oximeter is developed to measure patient pulse oximetry data. The pulse oximeter architecture is shown in Figure3.Figure 3
Architecture of the pulse oximeter.(i)
SpO2 Sensor. This measures SpO2 and pulse rate using an infrared LED, a red LED, and a light sensor photo (PIN) diode. Infrared light and red light are passed through the user’s finger the PIN diode.
(ii)
Amplifier. This amplifies the input signal.
(iii)
Analog Filter. This decoupled the high-frequency noise.
(iv)
ADC. This converts a continuous signal to discrete signal.
(v)
MCU. This controls all system functions. It calculates SpO2 and pulse rate and stores these in memory.
(vi)
Bluetooth Module. This module is used to communicate with external devices.
(vii)
PHD Agent.
(a)
Session Handler. This manages a communication session with a PHD manager. It maintains connections with the manager until a session completed.
(b)
Message Handler. This generates and analyzes the exchanged messages according to the 11073 Standard. It constructs a message from measured pulse oximetry data and operational errors.
(c)
Memory Handler. This extracts pulse oximetry data, errors, and system configurations from the memory of pulse oximeters. The extracted data, errors, and configurations are passed to the message handler.The processes for converting pulse oximetry data into an 11073 message are shown in Figure4. The stored pulse oximetry data are extracted and converted into an 11073 message by the memory handler and message handler of the PHD agent. The values of SpO2 and pulse rate from the memory are inserted into “Basic-Nu-Observed-Value” fields and the measured time is inserted into “Absolute-Time-Stamp” fields. The values of “obj-handle” are assigned as 1 and 10 for SpO2 and pulse rate, respectively.Figure 4
Process of message transformation.


### 3.2. Personal Monitoring Server

The personal monitoring server analyzes, collects, and displays the pulse oximetry data and operational errors sent by the pulse oximeter. It also manages the system configuration of the pulse oximeter. The architecture of the personal monitoring server is shown in Figure5. The architecture of the PHD manager placed in the personal monitoring server is similar to that of the PHD agent except for a user interface module. The user interface module displays the pulse oximetry data to the user graphically. It also displays patterns or changes in data over a specific period of time. PHDs are usually small, with limited memory and LCDs, so a method that measures a user’s health data on a PHD but collects and displays those on a device that has better performance is more efficient.Figure 5
Architecture of PHD manager.


## 3.1. Pulse Oximeter

The pulse oximeter is developed to measure patient pulse oximetry data. The pulse oximeter architecture is shown in Figure3.Figure 3
Architecture of the pulse oximeter.(i)
SpO2 Sensor. This measures SpO2 and pulse rate using an infrared LED, a red LED, and a light sensor photo (PIN) diode. Infrared light and red light are passed through the user’s finger the PIN diode.
(ii)
Amplifier. This amplifies the input signal.
(iii)
Analog Filter. This decoupled the high-frequency noise.
(iv)
ADC. This converts a continuous signal to discrete signal.
(v)
MCU. This controls all system functions. It calculates SpO2 and pulse rate and stores these in memory.
(vi)
Bluetooth Module. This module is used to communicate with external devices.
(vii)
PHD Agent.
(a)
Session Handler. This manages a communication session with a PHD manager. It maintains connections with the manager until a session completed.
(b)
Message Handler. This generates and analyzes the exchanged messages according to the 11073 Standard. It constructs a message from measured pulse oximetry data and operational errors.
(c)
Memory Handler. This extracts pulse oximetry data, errors, and system configurations from the memory of pulse oximeters. The extracted data, errors, and configurations are passed to the message handler.The processes for converting pulse oximetry data into an 11073 message are shown in Figure4. The stored pulse oximetry data are extracted and converted into an 11073 message by the memory handler and message handler of the PHD agent. The values of SpO2 and pulse rate from the memory are inserted into “Basic-Nu-Observed-Value” fields and the measured time is inserted into “Absolute-Time-Stamp” fields. The values of “obj-handle” are assigned as 1 and 10 for SpO2 and pulse rate, respectively.Figure 4
Process of message transformation.


## 3.2. Personal Monitoring Server

The personal monitoring server analyzes, collects, and displays the pulse oximetry data and operational errors sent by the pulse oximeter. It also manages the system configuration of the pulse oximeter. The architecture of the personal monitoring server is shown in Figure5. The architecture of the PHD manager placed in the personal monitoring server is similar to that of the PHD agent except for a user interface module. The user interface module displays the pulse oximetry data to the user graphically. It also displays patterns or changes in data over a specific period of time. PHDs are usually small, with limited memory and LCDs, so a method that measures a user’s health data on a PHD but collects and displays those on a device that has better performance is more efficient.Figure 5
Architecture of PHD manager.


## 4. Implementation and Evaluation Results

In this section, we present the results of the implementation and evaluation of the pulse oximetry system. The pulse oximetry system is comprised of a networked pulse oximeter and personal monitoring server. Figure6 shows the prototype of the pulse oximeter. This prototype uses the finger-type SpO2 sensor obtained from APK Technology and is loaded with ATmega 128-16AC MCU and a Bluegiga WT12 Bluetooth module.The prototype of the pulse oximeter.
(a)
(b)In the proposed system, the pulse oximeter measures SpO2 and pulse rate using the finger-type SpO2 sensor and stores the measured pulse oximetry data in memory. The PHD agent within the pulse oximeter extracts the stored pulse oximetry data and detects four operational errors: sensor_disconnected, sensor_off, signal_non-detected, and signal_inadequate. Table 1 lists these operational errors and the corresponding codes. If an error occurs in the pulse oximeter, the corresponding code is inserted into “Enum-Observed-Value-Basic-Bit-Str” attribute of the “Device and sensor annunciation status” object, then the PHD agent transmits the object using a “Remote Operation Invoke ∣ Confirmed Event Report” method. Through this mechanism, the operational errors that occur in the pulse oximeter are reported to the personal monitoring server.Table 1
Operational errors detected and reported by the PHD agent.
Error
Error code
Description
sensor_disconnected
0x0000
Sensor is disconnected from the pulse oximeter
sensor_off
0x0001
Sensor is connected, but not connected to the patient
signal_non-detected
0x0010
Signal cannot be detected
signal_inadequate
0x0200
Signal is inadequate to produce a meaningful resultThe PHD agent converts the stored pulse oximetry data and the detected errors into an 11073 message and transmits the message to the PHD manager via Bluetooth. The reason to use Bluetooth is a data transfer rate. Although Zigbee might be more suitable for a single signal transmission in terms of transmission range and network latency [11, 12], we plan to use the pulse oximeter to a remote management system. In the system, the pulse oximeter will be managed by a management server remotely. To achieve this, the pulse oximeter is required at a high data transfer rate. Moreover, smartphones that support Zigbee have not been released on the market thus far.The PHD manager was implemented on an LG LU2300 smartphone (now called an Optimus Q) that is based on Android 2.2. In addition, SQLite [13], which is an embedded SQL database engine, is used for storing pulse oximetry data. It extracts pulse oximetry data and operational errors from the received messages. It also manages two components of the system configuration of the pulse oximeter: thresholds for SpO2 and pulse rate and measurement targets. The pulse oximeter operates according to the modified system configurations. Table 2 lists the manageable system configurations of the pulse oximeter. For example, if the PHD manager transmits a “Remote Operation Invoke ∣ Set” method with a specific value and targets the attribute “MDC_ATTR_LIMIT_CURR-Min_SpO2,” this reflects an attempt by the medical staff to change the lower threshold for SpO2 to a desired value. The system configurations can be extended according to the management scenarios or target PHDs using the configuration phase described in Figure 1.Table 2
System configurations of the pulse oximeter managed by PHD manager.
Configuration
Value
Description
MDC_ATTR_LIMIT_CURR
Min_SpO2
Integer
Lower threshold for SpO2
Max_PulseRate
Integer
Higher threshold for pulse rate
Min_PulseRate
Integer
Lower threshold for pulse rate
MDC_ATTR_MSMT_TARGET_OBJ
Measurement target
0x0000
SpO2 but no pulse rate is measured
0x0001
Pulse rate but no SpO2 is measured
0x0002
Both SpO2 and pulse rate are measuredFigure7 shows the screen of the PHD agent for 11073 messages exchanged between the PHD agent and the PHD manager during a session. In Figure 7, the PHD agent sends 11073 request messages (represented as “Send-PackageNum(1, 3, 5)”) and the PHD manager sends response messages (represented as “Receive-PackageNum(2, 4, 6)”). The figure shows that the PHD agent first sends the association request message and the PHD manager responds with the “accepted” parameter. After that, the PHD agent sends the event report message to transmit the measured SpO2 and pulse rate, and the PHD manager responds to the report. Finally, the PHD agent sends the association release request message and the PHD manager responds to the request. Based on this figure, the PHD agent and PHD manager exchange 11073 messages properly.Figure 7
11073 messages exchanged between PHD agent and PHD manager.Figure8 shows three screenshots of the PHD manager. The patient can monitor pulse oximetry data through the GUI. In Figure 8(a), the pulse oximetry data transmitted from the PHD agent is displayed on the screen of the smartphone. The PHD manager provides a function to alert users to the detection of a low- or high-limit violation based on the predetermined threshold. A green background represents a normal level and a red background represents an abnormal level. Based on Figure 8(a), the SpO2 of 97% is a normal level, but the pulse rate of 107 beats/min is an abnormal level. The PHD manager also identifies patterns or changes in pulse oximetry data over a specific period of time, as shown in Figure 8. Based on Figure 8, the PHD manager receives pulse oximetry data from PHD agent and displays these properly.Screenshots of PHD manager.
(a)
SpO2 and pulse rate
(b)
SpO2 graph
(c)
Pulse rate graphThe proposed pulse oximetry system is a client-server system. For this reason, its response time is an important consideration. Hence, we evaluate the response times of the pulse oximeter for each phase, as shown in Figure9.Figure 9
Communication times of pulse oximeter.As shown in this figure, the pulse oximeter requires an average of 6 s during the association phase, while requiring 251 and 119 ms during the operation and disassociation phases, respectively. Such a large difference exists in the communication times because the communication time during the association phase includes the Bluetooth connection time. However, it does not significantly affect the system performance because the association phase is experienced only once, and a Bluetooth connection is established only when the physical connection between the pulse oximeter and the personal monitoring server is disconnected. The evaluation confirms that the proposed system is appropriate for monitoring and managing a pulse oximeter in real time.


## 5. Conclusion and Future Work

In this paper, we proposed an advanced pulse oximetry system for remote monitoring and management. The system consists of a networked pulse oximeter and a personal monitoring server. For the proposed system to support remote monitoring and management functions, we implemented a PHD agent and manager. The PHD agent within the pulse oximeter extracts the stored pulse oximetry data, detects operational errors, and transmits them to the personal monitoring server. The PHD manager within the personal monitoring server analyzes, collects, and displays the pulse oximetry data sent by the pulse oximeter. It also manages system configurations of the pulse oximeter. The PHD agent reports the detected operational errors using the “Remote Operation Invoke ∣ Confirmed Event Report” method, and the PHD manager manages system configurations of the pulse oximeter using “Remote Operation Invoke ∣ Set” method. The determined errors and system configurations can be extended according to the management scenarios or target PHDs using the configuration phase. We also presented the results of the implementation and evaluation of the pulse oximetry system. The results confirmed that the proposed system is appropriate for monitoring and managing a pulse oximeter in real time.As future work, we plan to apply the product to other u-health services. We also plan to apply various protocols to connect between the personal monitoring server and health service providers.



---

*Source: 930582-2012-08-09.xml*