The flow of events in self-managing a device in the framework is shown in Figure 4. Self-management involves sensing or monitoring parameters from the device or the system to be managed and then analyzing the parameters to find out whether a corrective action is required. Intelligent algorithms and decision trees are used to decide if a management action is required and then to arrive at the most effective decision to act on the inputs. The decision is then executed by the execution engine in a feedback loop to effectively manage the device or the system without the need for user intervention.

Figure 4: Flow of events in self managing a system
click image for larger view
 

The proposed health-monitoring framework can be efficiently self-managed by building limited self-managing capabilities in each building block and shifting major intelligence and decision-making capabilities to the PC.

The PC makes the control decisions based on status inputs from the connected BFE and AGG devices and then instructs the devices to perform certain self-management functions.

Following are the advantages of this self-management approach:

• BFE devices may not have high computational capability. Hence, they can send their status information to the PC and use the processing power of the PC to make optimal self-management decisions.
• The PC is the central hub of information gathering and it is aware of the status of all devices in the network. Hence, the PC is better equipped to make optimum decisions by considering the status of the entire platform as a whole, rather than the status of a single device.

The BFE and the AGG devices should have limited self-managing capability in order to manage themselves in case the communication link to the PC fails. Such devices can have fail-safe mechanisms and recovery algorithms to put the device in a safe state in the absence of PC connectivity.

Figure 5: Self managing framework for health monitoring
click image for larger view
 

Figure 5 shows a self-managing framework for health monitoring. Each BFE device connected to the patient self-manages itself to some extent and can also be managed by its WBAN AGG device and by the back-end PC/server. The management scope of a BFE device is limited to itself. The management scope of an AGG device is limited to itself and also to manage all the BFE devices in the WBAN of that particular patient. The PC is the central hub of information gathering and does the system-level management, making decisions based on inputs from all the devices in the system. The management scope of PC extends to itself, all AGG devices in its network and all the associated BFE devices. The PC also interacts with other servers that are remotely connected via the Internet link. The remotely connected hand-held devices and servers can be used to manually manage the BFE and AGG devices connected to the network after secure authentication. The PC manages and communicates with the BFE devices in the network via the intermediate AGG devices.

The self-managing capabilities of different blocks of the framework are described below.

Self-managing the BFE device

The self-managing capabilities of the BFE device may vary according to the type of the device. An ECG BFE device may self-manage itself differently than a SpO2 BFE device. Typically, a BFE device can exhibit the following self-management capabilities:

• Device to patient binding. This involves binding all the BFE devices and the AGG device connected to a patient to a unique patient-ID and a unique Personal Area Network (PAN) identification (ID) number. The PAN-ID of each WBAN is closely coupled to the Patient-ID (i.e., the patient registration number assigned to the patient by the hospital). The unique Patient-ID and the patient history may be programmed in a small Radio Frequency ID (RFID) wrist strap attached to the patient, when the patient is admitted to the hospital. The BFE devices may have RFID reading capability to read the Patient-ID and be associated with the unique Patient-ID, when they are brought into close contact with the patient's RFID wrist strap. Once each BFE device and AGG device gets associated with the Patient-ID, all the connected devices can form a unique PAN-ID for the patient.

  Alternatively, each BFE device may have the capability to autonomically identify a patient based on some biometric technique. Data packets sent by the BFE devices to the AGG device and to the PC are tagged with the unique Patient-ID in order to bind them to the patient's individual database.

• Network association. All the BFE devices and the AGG device connected to a patient are programmed to have a unique PAN-ID for their network. As mentioned above, the PAN-ID can be programmed into the BFE devices and AGG device before connecting them to a patient. When the BFE device is turned ON, it looks for beacons sent by the AGG device to check the AGG device's PAN-ID and gets itself associated with the network if it matches with its own PAN-ID. The AGG in turn identifies the newly joined BFE device, determines the type (i.e., ECG, SpO2 etc.) of the BFE device and intimates the same to the PC. The PC dynamically adjusts the Graphical User Interface (GUI) on its screen to effectively optimize the screen space to display the signals from the newly networked BFE device.
• Self-configuration. When a BFE device is turned ON it automatically configures itself to a default state. It also checks the attached sensors and re-configures itself for its mode of operation. For example, for an ECG BFE device, there are two modes of operation: diagnostic and monitoring. In diagnostic mode a 10 lead cable is used to sense the ECG signals and the ECG signals are digitized at 500 samples per second per lead. However, in the monitoring mode, a 3 or 5 lead ECG cable is used to sense the ECG signals and the ECG signals are digitized at a sampling rate of 200 samples per second per lead. At start-up, the BFE device can identify the type of ECG cable connected at its input and automatically adjust its mode of operation, the number of channels to be sampled, the sampling rate per channel, and it can reserve the bandwidth required for the wireless data transfer.
• Self-calibration and self-check. At power ON or when requested by the PC, the BFE device can also execute self-calibration and self-check routines to dynamically adjust its settings for maximum accuracy. For example, an ECG device may input a fixed reference voltage to its Analog to Digital Converter (ADC), convert it to a digital representation, and then adjust its gain and offset errors to compensate for the errors in the ADC. Similarly, a SpO2 device may calibrate its optical sensor characteristics, whereas, a NiBP BFE device may calibrate its air pressure sensor and self-check its air release solenoid valves and the air pump for proper operation.

• Power management. The BFE device can dynamically turn OFF the idle peripherals when not in use. For example, the BFE device microcontroller can turn OFF its communication ports, data acquisition, and control peripherals when not in use in a particular mode of operation. Battery capacity monitoring can be done at periodic intervals by the BFE device and the battery capacity information can be sent to the PC via the AGG device.

  The BFE device can reduce the clock frequency of its microcontroller and related peripherals if too much computing is not required by the BFE device sensor. Very low data rate BFE devices such as body temperature sensors can enter sleep state between periodic measurements, whereas, the medium data rate devices such as SpO2 may turn OFF the wireless transmitter's RF circuitry between data transmissions in order to conserve battery power.

  The BFE device may either execute certain power management functions autonomically or execute them when instructed by the PC. For example, when the battery voltage falls below a certain threshold value, the PC may instruct an ECG BFE device to reduce the ECG sampling rate, and the PC may interpolate the sub-sampled ECG data for proper visual representation. Alternatively, depending on the status of other sensors attached to the patient, the PC may instruct the ECG BFE device to reduce the number of ECG signals to be sampled and reduce the amount of wireless data transmission to conserve battery power.

  Near the end of battery capacity, the PC and the BFE device may issue audio and visual alerts to inform the hospital staff to change the battery. The BFE device also intimates to the PC its decision to turn OFF to a safe state when the battery capacity reaches 0%.

• Fail-safe mechanisms. It is very important for the BFE device to have intelligent algorithms to handle alerts in case of malfunctions and put the BFE device in a safe state to avoid patient injury.

  Some important malfunctions could be microcontroller/
  hardware malfunction, sensor malfunction and communication failure.

• Hardware malfunction. These types of malfunctions can be induced by failure of electronic components or can be due to effects of electromagnetic interference (EMI). EMI can cause the BFE device microcontroller to enter a runaway state that can be very dangerous. This can be mitigated by ensuring that, in the case of malfunction, a watchdog timer running inside the microcontroller device either resets the microcontroller or puts the microcontroller and associated hardware in a known safe state.

  In the case of BFE devices such as a NiBP device, the blood pressure is measured by occluding the brachial artery by inflating a cuff tied to the patient's arm. If the air inside the cuff is not released due to hardware malfunction, the blood flow to the patient's hand stops and may cause serious tissue damage. Hence, it is very important to have either a redundant microcontroller or some standby mechanical devices (such as normally open solenoid air release valves) to ensure air release even in case of power or hardware failure.

• Sensor malfunction. The BFE device also needs to handle situations when the sensors connected to the BFE device malfunction or when they get disconnected from a patient. For example, for an ECG BFE device, the number of electrodes connected to a patient may vary from three to ten. The BFE device needs to continuously monitor the impedance of each electrode and generate an alert in case the electrode gets disconnected from the patient. The BFE device sends the sensor status to a PC periodically, and the PC can generate an alert in case of malfunction. Apart from generating an alert it may also be necessary to stop displaying the waveform of the disconnected ECG lead to avoid the doctor misinterpreting the noise picked up by the disconnected electrode as a valid ECG signal. The ECG BFE device may, however, continue to monitor the ECG signals from other electrodes.

  In another case, an air leak may be present in the cuff tied to the patient's arm for blood pressure measurement. The NiBP BFE device needs to monitor the rate of increase in cuff pressure once the air pump starts pumping air into the cuff. If the cuff pressure does not increase at the required rate an air-leak alert is transmitted to the PC.

• Communication failure and communication errors. The BFE device also needs to handle situations when the sensors and its hardware components are functioning normally but when the communication link to the AGG device or the PC fails. In such cases the BFE device is neither able to send the physiological data and its status to the PC, nor is it able to receive autonomic control messages from the PC. In such a scenario, the BFE device may save the patient's data in its local memory for transmission to the PC when the communication link is re-established. If the BFE device does not have sufficient memory to store data for long periods of disconnection, it may save the status of the last few minutes using a circular memory buffer. In case of communication failure, the BFE device keeps on looking for the periodic beacons sent by the AGG device in order to check the PAN-ID and re-establish the network connection.

  Communication errors may be introduced in the communication link between the BFE device, the AGG device and the PC due to the presence of other networks operating on the same wireless frequency. A typical example can be the interference of Wi-Fi (802.11b) in a Zigbee (802.15.4) network since they both operate in the same frequency band of 2.4 GHz. In another scenario, two patients may be connected with BFE devices that use the same frequency channel for communication to their respective AGG device. When such patients come in close proximity, their networks conflict with each other causing errors in communication. The BFE-AGG body area network needs to have a robust interference detection and mitigation algorithm by which a conflicting BAN would dynamically sense and change its operating frequency channel in case of interference from a similar network.

  In case the BAN is not able to mitigate the interference, robust error detection techniques should prevent the BFE device from executing wrong commands received from either the AGG device or the PC.

Self-managing the Aggregator device

The AGG device serves as a communication link between the WBAN formed by the BFE devices and the backend PC/server. The AGG device has a low-power wireless interface like 802.15.4 or a low-power Bluetooth* to network the BFE devices and also a long range, high data rate interface like Wi-Fi to interface with the back-end PC. The AGG device may or may not have a local LCD display and control keypad. A typical example for an AGG device could be a PDA. The self-managing capabilities of the AGG device may be similar to that of the BFE devices.

The AGG device manages the BAN and allows BFE devices to join or leave the BAN seamlessly. Automatic BFE device discovery, device type identification, and BAN networking are the responsibility of the AGG device. The AGG should have sufficient capabilities to manage the BAN efficiently even in the absence of the communication link to the PC and have sufficient memory for storage of patients' physiological and status data over extended periods of operation.

Another important function of the AGG device is data encryption/decryption for network security.

Autonomic Platform Management (APM) by the PC

The PC or server is the central hub of data collection from multiple WBANs of multiple patients. The PC aggregates data from multiple patients, processes the data, stores them in specific formats and also makes the data available to multiple remote terminals for display. The PC also makes the patients' data available to the doctor at any place and at any time by transmitting important patient data to hand-held devices like mobile phones and PDAs. The PC also has the capability to issue control commands to any BFE device in its network to change its operating parameters. The PC also manages the shared resources like printers, fax equipment, etc., which are connected to it.

Since the PC is the central hub of information aggregation from BANs, user inputs from GUIs and information from remote terminals, it is better equipped to make self-management decisions for the entire health-monitoring framework. Also, since the PC has tremendous computation capacity it is better suited to run complex decision trees to arrive at the best management decision.

A single PC can be used to cater to the processing needs of multiple patients in a ward of the hospital. Multiple wards of the hospital can be connected to a server to further aggregate data from the entire hospital and to send/receive messages to hand-held devices.

The self-managing capabilities of the PC/server, shown by the APM layer in Figure 3, can be as follows.

• Network management. The PC forms a network of the AGG devices and dynamically changes the network topology as patients get transported in and out of the wards for tests and operative procedures. The PC is also aware of the devices in the BAN of each AGG device. The PC enables automatic device discovery, device association and disassociation algorithms, and automatic device-to-patient binding. Each patient is associated with a unique PAN-ID, and all devices in the BAN of the same patient have the same PAN-ID. The PC binds the real-time data of each patient to the patient's respective backend database.

  Apart from managing the networking of AGG and BFE devices, the PC also manages the shared resources on its network like printers, scanners, fax machines, etc.

• BFE device control. Since critical patients have different monitoring requirements as compared to non-critical patients in recovery, the PC can re-configure the BFE devices in different operating modes and change the device settings depending on the level of monitoring required.

  The PC is better equipped to handle self-management functionality of the health-monitoring platform as a whole. The PC may run complex bio-signal processing algorithms and based on the results may instruct the BFE device to execute certain self-management tasks. For example, the PC may analyze the ECG signal for the presence of baseline drift and may send a message to the ECG BFE device to restore the ECG baseline to ground by re-charging an AC coupling capacitor in the BFE device hardware. Similarly, if very small amplitude ECG signals are being sensed by the electrodes, it can instruct the BFE device to increase the amplification of the BFE device's programmable gain amplifier hardware.

  For a NiBP BFE device the PC may instruct the device to take blood pressure measurements either at programmed intervals or autonomically when certain thresholds are exceeded or under manual control.

  The PC can also perform autonomic power management of the devices connected on its network. The PC can turn ON or turn OFF the BFE devices or keep them in SLEEP state. The PC can wake the sleeping devices at appropriate times, instruct them to take a measurement and put them to SLEEP again. Also, the PC can extend the battery life of a device by dynamically changing the device parameters and settings. For example, the PC can instruct an ECG BFE device to reduce the number of leads to be sampled or reduce the sampling rate per lead, depending on the quality of ECG required.

• Autonomic GUIs. The PC can autonomically adjust the screen space to display a number of vital signal waveforms and numerical data from a number of patients. The screen can be automatically partitioned and re-adjusted to accommodate the data from new devices that join the network, and the screen space can be made free and utilized in a better manner when the BFE devices leave the network. When the screen space is limited, and displaying all parameters from all patients is not possible, the PC should give weight to critical parameters such as ECG readings.

• Managing alerts. The PC is the central computing resource for the entire health-monitoring framework and needs to process alerts coming from almost all devices attached to the network.

  Broadly, the alerts can be classified as alerts generated by the patient's physiological status, device status, and communication errors.

• Alerts due to patient's physiological status. The PC processes the physiological signals and parameter data from the patient and checks if any of the programmed limits are exceeded. For example, the PC computes the heart rate by identifying and counting the number of ‘R' waves in the patient's ECG per minute. In case the heart rate crosses the programmed limits, the PC may request the NiBP BFE device to take frequent blood pressure measurements and may also power ON a defibrillator machine in case the patient needs to be administered an electrical shock to restore normal heart rhythm. The PC can also intelligently identify irregular heart rhythms called arrhythmias and keep a log of these with a time stamp. In some critical conditions, the PC can automatically send the abnormal physiological data to a doctor's mobile phone/PDA for diagnosis and also trigger audio-visual alarms locally.

• Device status alerts. The PC monitors the status of the BFE and AGG devices and manages the alerts generated due to low battery, sensor failure or disconnection, component failure, calibration errors, etc. For example, if the patient condition is not critical, under low battery conditions the PC may instruct an SpO2 BFE device to intermittently monitor the blood oxygen saturation at 1-minute intervals, rather than monitoring it continuously. This allows the LEDs inside the SpO2 finger probe and the associated circuitry to sleep between measurements, thereby extending the battery life. For sensor disconnection the PC can raise appropriate audio-visual alarms and/or page the hospital staff on duty.

  In the case of component failure or calibration errors the PC can compensate for the error by software correction or instruct a device like the NiBP to measure blood pressure using the redundant pressure sensor. Once an error is detected and flagged by the PC, the PC also monitors whether the error has been corrected and removes the error flag accordingly. Alternatively, the user may manually acknowledge the error and put the PC in a mute state for a certain amount of time within which the user is expected to correct the error.

• Fail-safe mechanisms. Since the PC is the central computing resource for the health-monitoring platform, it is necessary to build reliability into the PC platform. Reliable hardware design, a reliable low-latency hard real-time OS, a reliable networking stack and application software are necessary to build a medical-grade PC. The PC should be immune to the EMI generated by other medical equipment in its vicinity and should also have low EMI emissions. The PC should have a battery backup to remain operative in case the mains power supply fails. The PC should have the capability of self-monitoring, preventive maintenance, and have redundant processing cores and configurable logic to heal itself in case of component failure. The storage media and the Internet broadband link should be robust. The aggregated patient data and the network status information should also be copied in a central archive so that in case of malfunction, a standby PC should be able to take over the monitoring functionality of the failed PC without loss of data.

Bluetooth is a trademark owned by its proprietor and used by Intel Corporation under license.