Advanced Pulse Oximetry System for Remote Monitoring and Management

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.


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 (SpO 2 ) 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 SpO 2 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 SpO 2 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: Section 2 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.

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-unknownconfig" 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.
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., SpO 2 , pulse rate, and pulsatility). Of these, SpO 2 and pulse rate are mandatory objects. Figure 2 depicts the standard messages for transmitting SpO 2 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.

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.

Pulse Oximeter.
The pulse oximeter is developed to measure patient pulse oximetry data. The pulse oximeter architecture is shown in Figure 3. (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.  The processes for converting pulse oximetry data into an 11073 message are shown in Figure 4. 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 SpO 2 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 SpO 2 and pulse rate, respectively.

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 Figure 5. 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.

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. Figure 6 shows the prototype of the pulse oximeter. This prototype uses the fingertype SpO 2 sensor obtained from APK Technology and is In the proposed system, the pulse oximeter measures SpO 2 and pulse rate using the finger-type SpO 2 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,

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 result 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. The 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 SpO 2 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 SpO 2 ," this reflects an attempt by the medical staff to change the lower threshold for SpO 2 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. Figure 7 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 SpO 2 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 8 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 SpO 2 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. The 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 Figure 9.
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.

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.