Patent Application Serial No. 09/292,157 entitled"Physiological Sensor Device"and filed April 15,1999; and U. S. Patent Application Serial No. 09/292,158 entitled"Portable Signal Transfer Unit"and filed April 15,1999; U. S. Patent Application Serial No. (not yet assigned) entitled"Portable Remote Patient Tele-monitoring System Including an Electronic Patch"and filed on the same date as the present application (Attorney Docket No. NEXT-0019); and U. S. Patent Application Serial No. (not yet assigned) entitled"Data Center for Portable Remote Patient Tele-monitoring System"and filed on the same data as the present application (Attorney Docket No. NEXT-0026), the contents of each of which are hereby incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION Field of the Invention The present invention relates to systems and methods for remotely monitoring and capturing human patient physiological data. In particular, the present invention is directed to a portable data logger for collecting, logging, and storing patient data that is recorded and broadcast from a patient data sensing device.

Description of the Prior Art It is known to provide systems such as those disclosed in U. S. Patent Application Serial No. 09/292,159 entitled"Portable Remote Telemonitoring System"and filed April 15,1999; U. S. Patent Application Serial No. 09/292,159 entitled"Physiological Sensor Array"and filed April 15,1999; U. S. Patent Application Serial No. 09/292, 157 entitled"Physiological Sensor Device"and filed April 15,1999; and U. S. Patent Application Serial No. 09/292,158 entitled"Portable Signal Transfer Unit"and filed April 15,1999, for collecting patient physiological data. Generally, in existing systems a sensor band, which is typically worn by the patient, senses patient physiological data, which may be referred to as a health parameter, and transfers the data to a transfer unit which also may be worn by the patient but in any event is kept within a few feet of the sensor band. The transfer unit transfers the data via wireless transmission to a base station where the data is collected The patient data may be viewed and analyzed at the base station unit and/or transferred to a central monitoring station for review by a medical care provider.

Generally, in existing systems, patients with a sensor band and signal transfer unit are free to move about within a defined distance of the stationary base station.

For example, data may be transmitted to and collected at the stationary base station while the patient moves about his or her house. Existing signal transfer units typically have the capability to store between 30 minutes and 2 hours of patient physiological data. Thus, when a patient moves beyond the defined distance from the base station, the physiological data is buffered at the signal transfer unit until the patient returns to within the predefined distance, at which time the buffered data is downloaded to the base station. However, if the patient remains outside the predefined distance for a period exceeding the buffer capacity of the transfer unit, the first buffered physiological data is overwritten by the later received data and is therefore lost. Thus, if the patient leaves the house to go to work or to the store, and remains outside the house beyond the buffer capacity of the transfer unit, a portion of the transmitted patient data does not reach the base station unit. Such losses of patient data negatively impact the efficacy of the monitoring session.

In existing systems, the base station unit is the patient's primary interface with the collected data, i. e. the patient data may be displayed and analyzed at the base station. However, the base station unit is not portable, i. e. it is difficult or awkward to move the base station unit to accommodate patient relocation. For example, when a patient that is being monitored goes to work, it is awkward, if not impossible depending on the work environment, to transport the base station unit to the work site to continue to collect data. For those periods that the patient is not in close proximity to the base station unit, the patient cannot view and analyze the data that is being collected. Thus, in existing systems a patient must stay in close proximity to the non-mobile base station in order to view the data that is being collected.

Accordingly, there is a need in the art for a data collection device for use in systems that are more adaptable to patient living conditions. Specifically, there is a need for a data collection device that has sufficient data storage capacity to allow a patient to move about freely while collecting physiological data and that provides the capability to view the physiological data as it is collected.

SUMMARY OF THE INVENTION Briefly, the present invention meets these and other needs in the prior art by providing a portable data logger (PDL) for collecting and viewing patient physiological data and for uploading monitoring session data from a monitoring station. Generally, the PDL is a mobile device, about the size of a pager, which collects, stores, and displays patient data that is radio transmitted from a sensing device attached to the patient. The PDL can detect patient data transmitted from a sensing device that is within a predefined distance, such as, for example 15 meters. Thus, a patient that is being monitored with the sensing device may move about freely within the predefined distance of the PDL without fear of data being lost. Because the PDL is small and lightweight, it can easily be transported by the patient to work, to the store, or virtually anywhere the patient may desire. This allows the patient to go about a daily routine while continuing to collect data.

Furthermore, the PDL has a display unit upon which the patient data may be displayed. Thus, the inventive PDL provides patients with great flexibility by affording an extended uninterrupted monitoring capability and capability to view patient data in real time as it is received.

In addition, the PDL has an interface for communicating with a monitoring station such as either a base station unit or a remote monitoring station unit. The interface is two-way, allowing for transfer of patient data to the monitoring station and for uploading monitoring session data from the monitoring station. The monitoring session data comprises data related to a particular monitoring session. For example, the monitoring session data may comprise a schedule for taking additional data measurements or a schedule for exercise or medication. The PDL may issue reminders to the patient based upon the monitoring session data.

For monitoring scenarios conducted over a limited time frame, say for example 24 hours, patient data can be accumulated on the PDL. Thereafter, the PDL can be returned to the health care professional (HCP) who may interface the PDL with a remote tele-monitoring station (RMS) for analysis of the data. If the monitoring is ongoing or extends over a long period of time, however, the collected patient data may exceed the storage capacity of the PDL. Accordingly, the PDL is designed to interface with a base station unit (BSU). The base station unit is a substantially stationary device which has a more extensive memory capacity than the PDL. The PDL may be periodically docked with the base station unit and the patient data that has been collected by the PDL downloaded to the base station. The base station unit provides an interface wherein an HCP can program patient reminder information as well as auxiliary measurement schedules. When the PDL is interfaced to the BSU, this information is uploaded to the PDL. The auxiliary measurement schedule causes the PDL to periodically prompt the patient to follow the schedule and take the appropriate auxiliary measurements.

According to another aspect of the invention, the PDL includes a receiver unit for receiving physiological data from a sensing device, an electronic memory device for storing the physiological data, and a display unit for displaying the physiological data.

The portable data logger also includes an interface for transferring the physiological data to the base station and for receiving monitoring session data from the base station. The portable data logger further includes a processing unit operable to transmit the physiological data to the display unit for display and operable to process the monitoring session data received by the interface.

BRIEF DESCRIPTION OF THE DRAWINGS The above and other objects and advantages of the invention will become more apparent and more readily appreciated from the following detailed description of presently preferred exemplary embodiments of the invention taken in conjunction with the accompanying drawings of which: FIGURE 1 is a schematic drawing of a physiological monitoring system incorporating a portable data logger according to the invention ; FIGURE 2 is a perspective view of a portable data logger according to the invention; FIGURE 3 is a block diagram of a portable data logger according to the invention; FIGURE 4 is a block diagram of an electrical architecture of a portable data logger according to the invention; FIGURES 5 is a block diagram of a printed circuit board for use in a portable data logger according to the invention; FIGURE 6 is a schematic diagram of an antenna for use in a portable data logger according to the invention; FIGURE 7 is a schematic diagram of a radio receiver unit for use in a portable data logger according to the invention; FIGURE 8 is a flow chart of the high level process for receiving physiological data packets at a portable data logger according to the invention; FIGURE 9 is a flow chart of a process for unpacking data packets in a portable data logger according to the invention; FIGURE 10 is a block diagram of the major functional components of a user interface for a portable data logger according to the invention; FIGURE 11 is an exemplary default screen for display on a portable data logger according to the invention; FIGURE 12 is an exemplary main menu screen for display on a portable data logger according to the invention; FIGURE 13 is an exemplary signal menu screen for display on a portable data logger according to the invention; FIGURE 14 is an exemplary ECG signal screen for display on a portable data logger according to the invention; FIGURE 15 is a diagram of a state machine for controlling the transfer of data between a portable data logger and a base station unit; and FIGURES 16A-16C is a flow chart of a process for transfer of data between protocol levels during communication of data between a portable data logger and a base station unit.

DETAILED DESCRIPTION OF THE PRESENTLY PREFERRED EMBODIMENTS A system and method with the above-mentioned beneficial features in accordance with a presently preferred exemplary embodiment of the invention will be described below with reference to FIGURES 1-16. Those of ordinary skill in the art will appreciate that the description given herein with respect to those figures is for exemplary purposes only and is not intended in any way to limit the scope of the invention. All questions regarding the scope of the invention may be resolved by referring to the appended claims.

Figure 1 provides an overview of a system for monitoring patient physiological data in which a PDL in accordance with the present invention may be employed. As shown, the system comprises sensing unit 100 which is adapted for gathering physiological data, which might also be referred to as health parameter data, from a patient. Sensing unit 100 may comprise on-body sensor 110, Sp02 sensor 112, and transmitter 114. On body sensor 110 is typically worn on a patient's chest and has inputs thereon for measuring various vital signs such as heart rate, respiration, respiration pattern, temperature, patient body motion, and electrocardiogram (ECG). Sp02 sensor 112 measures the saturation of hemoglobin with oxygen. Sensors 110 and 112 also record an evaluation of the quality of the signals that is being collected from the patient. For example, if the signal representing the patient body motion is weak, sensor 110 memorializes this in the data that it collects. Sensors 110 and 112 feed data to transmitter 114 which communicates the various vital signs to portable data logger (PDL) 120 via radio link 115. Further details regarding a sensing unit operable for use with the present invention can be found in co-pending U. S. Patent Application Serial No. (not yet assigned) entitled"Portable Remote Patient Tele-monitoring System Including an Electronic Patch" (Attorney Reference No. NEXT-0019) the contents of which are hereby incorporated by reference in their entirety.

Generally, PDL 120 operates to store patient data gathered by sensing unit 100. Upon receipt from transmitter 114, PDL 120 compresses and stores the data. PDL 120 has sufficient memory to store in excess of 24 hours of patient data. PDL 120 also provides the capability to view the patient data. The data can be viewed in real time as it is received and can also be viewed as a compilation over time.

PDL 120 has an interactive user interface including input buttons, an audio output, and display unit. The interface is used by various operators such as patients, health care professionals (HCP), or engineers to interact with PDL 120. For example, a monitoring session may require a patient to take additional physiological readings other than those collected by sensing unit 100. Accordingly, monitoring session data such as an auxiliary measurement schedule identifying the types and collection times for these additional measurements may be developed and loaded in the memory of PDL 120 from base station unit (BSU) 124. PDL 120 sounds and displays reminders to indicate to a patient when these measurements need to be taken. Using buttons on PDL 120 the patient can enter the results of the auxiliary measurements or simply indicate that the activity has been completed. PDL 120 might also receive monitoring session data that causes PDL 120 to issue reminders to notify patients to undertake certain activities such as administering drugs, eating, or exercising. PDL 120 is programmed to provide an interface to HCPs and engineers as well.

Radio link 115 between sensing unit 100 and PDL 120 has certain physical limits. For example, the link might significantly degrade when the distance between PDL 120 and sensing unit 100 is greater than 15 meters. Accordingly, PDL 120 is operable to provide a warning, such as a beeping noise, or a notation on the display unit, to notify a patient when he or she is nearing the limit. The beeping becomes louder and more frequent as the limit is approached.

PDL 120 has the capability to store up to 24 hours of patient data. For monitoring scenarios requiring 24 hours or less of patient data, PDL 120 can be employed to collect the data and thereafter returned to an HCP. HCP may interface PDL 120 with RMS 128 so as to download the data for analysis. However, for extended monitoring scenarios that exceed the memory capacity of the PDL 120 or that require additional interaction with en HCP, it may be necessary to interface PDL 120 with BSU 124.

Generally, BSU 124 eexists as an interface between the data gathering of sensing unit 100 and PDL 120 and a remote monitoring station (RMS) 128. Patient data is collected by sensing unit 100 and stored on PDL 120. Upon downloading to BSU 124, this data can be accessed by HCP's either at the BSU 124 or remotely from RMS 128.

Likewise, monitoring session data such as auxiliary monitoring schedules and reminders that may be generated by an HCP at BSU 124 or RMS 128 can be uploaded to PDL 120 from BSU 124.

BSU 124 typically has interfaces for auxiliary physiological monitoring equipment such as, for example, blood pressure testing devices. Thus, a patient may be reminded to take an auxiliary measurement according to the auxiliary measurement schedule uploaded from BSU 124. The patient goes to the area of BSU 124 and uses the auxiliary measuring device. The patient data is automatically input and stored in BSU 124 via its interface with the auxiliary monitoring equipment.

Thus, BSU 124 comprises a user interface, inputs for auxiliary measurement devices such as blood pressure testing machines, and a docking station for interfacing with PDL 120. The docking station provides a bi-directional interface between BSU 124 and PDL 120 for exchange of data. Further details regarding a BSU 124 operable for use with the present invention can be found in co-pending U. S. Patent Application Serial No. (not yet assigned) entitled"Portable Remote Patient Tele-monitoring System Including an Electronic Patch"and filed on the same date as the present application (Attorney Docket No. NEXT-0019) the contents of which are hereby incorporated by reference in their entirety.

An HCP may interact with the patient data and provide directives for patients via RMS 128. Generally, RMS 128 is a computing station programmed to interact with BSU 124. As shown, RMS 128 may communicate with BSU 124 over communication link 130. Communication link 130 may be a direct connection, a public switched telephone network, and/or the Internet. An HCP located at RMS 128 can review the patient data downloaded from PDL 120 as well as prepare auxiliary measurement schedules to be uploaded to PDL 120. Further details regarding a RMS 128 operable for use with the present invention can be found in co-pending U. S. Patent Application Serial No. (09/292, 159) entitled"Portable Remote Tele-monitoring Station"and filed April 15, 1999, the contents of which are hereby incorporated by reference in their entirety.

Additional details regarding the system and system components described with reference to Figure 1 can be found in co-pending U. S. Patent Applications entitled "Portable Remote Patient Tele-monitoring System Including an Electronic Patch" (Attorney Reference No. NEXT-0019) and"Data Center for Portable Remote Patient Tele- monitoring System" (Attorney Reference No. NEXT-0026), the contents of which are incorporated herein by reference in their entirety.

Figure 2 is a perspective view of PDL 120 in accordance with the present invention. As shown, PDL 120 comprises buttons 154 and display 156, which in a preferred embodiment is a liquid crystal display (LCD). These provide the primary human interface to PDL 120. PDL 120 further comprises BSU connector 155 which mates with a corresponding connector area located on BSU 124 to provide a data transfer interface.

A top-level block diagram of PDL 120 is shown in Figure 3. PDL 120 comprises receiver 150 for receiving and decoding physiological data from sensing unit 100. Patient data is transferred to processing unit 152 where the data is compressed, time stamped and stored in memory. Patient data might additionally be viewed on display 156 as it is received. Processing unit 152 operates with buttons 154 and display 156 to provide a man machine interface whereby PDL 120 can be configured and data accessed. Base station unit interface 158 is similarly controlled by processing unit 152 and provides the communications link between PDL 120 and BSU 124.

Figure 4 is a block diagram of the overall electrical architecture of PDL 120. As shown, PDL 120 comprises a receiver printed circuit board (PCB) 170 and a control PCB 172. Receiver PCB 170 provides signal reception, down conversion, demodulation and unpacking of the data received from sensing unit 100. In one embodiment of the invention, a receiving antenna is integrated onto receiver PCB 170.

Patient data is transferred from receiver PCB 170 to control PCB 172 where the data undergoes error detection and correction prior to being compressed, time stamped, and stored in memory 180. Control PCB 172 regulates the charging of battery 182 through charger interface 184. Battery 182 may be any one of numerous battery types and in one embodiment is a lithium ion battery. Control PCB 172 detects events from buttons 154 and interfaces with display unit 156. Control PCB 172 also regulates BSU interface 158.

Figure 5 is a block diagram of control PCB 172. As shown, control PCB 172 comprises micro-controller 200. Preferably, micro-controller 200 includes on-chip flash memory, on-chip RAM, at least two serial ports, and at least three 8 bit input/output ports. Any one of several micro-controllers from the H8S family of 16 bit controllers sold by Hitachi provides these features but preferably micro-controller model number H8S2357 is employed.

Micro-controller 200 is in electrical communication with receiver processor 202. Receiver processor 202 accepts patient data and performs various pre-processing activities on the data such as preamble detection, clock alignment, and data synchronization. In one embodiment, processor 202 is a model PIC 16LC620A manufactured by Arizona Microchip.

Memory card 206 provides memory storage to controller PCB 172.

Memory card 206 preferably has capacity for at least 64 MB of compressed data and consumes power only when it is used. In one embodiment, memory card 206 is a model MMC64 manufactured by Sandisk Corporation.

Input device controller 208 provides an interface between buttons 154 and micro-controller 200. LCD controller 210 similarly provides an interface between micro- controller 200, static random access memory (SRAM) 212, and LCD display 214. In one embodiment of PDL 120, LCD display 214 is model number G241DO1R000 and LCD controller 210 is a model number SED1374, both manufactured by Seiko.

Real time clock (RTC) 216 is also connected to micro-controller 200 and provides a system clock reference. In an embodiment of PDL 120, RTC 216 is a model number DS1302 manufactured by Dallas Semiconductors.

Controller 200 is also connected to universal asynchronous receiver- transmitter (UART) 218. UART 218 handles the asynchronous serial communications between PDL 120 and BSU 124. In an embodiment of PDL 120, UART 218 is a model OX16C50 manufactured by Oxford semiconductors.

Controller PCB 170 further comprises re-chargeable battery 220 and battery charging circuit 222. Generally, when PDL 120 is not docked to BSU 124, battery 220 powers PDL 120. When PDL 120 is docked to BSU 124, battery 220 is charged through battery charging circuit 222. In one embodiment, charger circuit 222 is a model TEA1102 manufactured by Phillips.

Referring briefly to Figure 1, communication between sensing unit 100 and PDL 120 is made via a uni-directional radio link. Sensing unit 100 operates to transmit data and PDL 120 simply receives the data. Receiving unit 150 establishes that data is being received, synchronizes with sensing unit 100, and accepts incoming data.

Figure 6 provides a schematic of antenna 250 for use in PDL 120 to receive signals from sensing unit 100. Antenna 250 is a magnetic loop antenna and may be located on receiver PCB 170. Antenna 250 is preferably positioned in PDL 120 away from metal objects that might degrade its performance.

Antenna 250 is connected to a receiver circuit 252, which is embodied in receiver PCB 170. Figure 7 is a block diagram of an embodiment of receiver circuit 252.

Receiver circuit 252 operates as a conventional superheterodyne receiver modified for operation at 868 Mhz. An intermediate frequency (IF) has been chosen for receiver circuit 252 to minimize potential mutual interference with services, such as GSM and Band V, that operate in nearby frequencies.

As shown, receiver circuit 252 comprises SAW filter 254 connected to amplifier 256 which outputs to SAW filter 258. SAW filter 258 provides a first input to integrated mixer 260. Oscillator 262 provides a second input to mixer 260 which generates an IF of 89MHz. LC circuit 264 limits image frequency noise in the signal which serves as a first input to mixer 268 contained in integrated circuit 266. A second local oscillator 270 operating at 78.3 MHz provides a second input to mixer 268. Mixer 268 outputs a 10.7 MHz frequency signal which is passed through amplifier 272 and limiter 278. Filters 274 and 276 remove adjacent channels with the SAW filter bandwith.

The resulting signal is input to demodulator 280 which employs external quadrature detector 282. Data slicer 284 formats the output into a squared data stream. Voltage source 286 with a 70 dB dynamic range is provided for alignment and signal quality measurements.

Sensing Unit-PDL Interface Figure 8 is a high-level flow chart of the process for receiving patient data.

It should be noted that while in a presently preferred embodiment receiver 150 is an FM radio receiver, the scope of the invention comprises other data transmission and receiver technologies. For example, Bluetooth wireless technology developed by the Bluetooth Special Interest Group could also be employed to communicate data from the sensing unit 100 and PDL 120.

Prior to beginning to collect physiological data, sensing unit 100 and PDL 120 may interface to identify that the sensing unit is operational. It is possible to determine the correct operation of the sensing unit before it is applied to a patient so as to avoid unnecessary applications of the sensor 110 due to hardware failure. When sensing unit 100 is powered-up, it sends packets indicating the results of self-tests. The self-test packets have the same length as normal data packets and are sent with the same frequency as normal packets for a period of approximately ten seconds. The self-test packets identify whether the sensing unit is operational. Table 1 provides details regarding the composition of the self-test packet.

Table 1-Self-test packet Field Length Remark (bits) E-patch identifier 8 E-patch status info 2 Packet type 3 value is 100- identifier Hardware Version No. 16 Software Version No. 16 Protocol Version No. 16 ROM parity check 8 see Table 2 result RAM read/write check 8 see Table 3 result Battery charge state 8 see Table 4 Sensor statuses 8 A bit field, see Table Reserved 8 Reserved8 Reserved 8 Reserved 8 Reserved 8 Reserved 8 Unused 243 The ROM parity check result takes one of the values defined in Table 22.

Table 2-ROM parity check result field Value Meaning Remark 00000000 Test failed 00000001 Reserved Etc etc 11111110 Reserved 11111111 Test passed The RAM read/write check result takes one of the values defined in Table 3.

Table 3-RAM read/write check result field Value Meaning Remark 00000000'Test failed 00000001 Reserved Etc Etc 11111110 Reserved 11111111 Test passed The battery charge status may be derived from actual measurement of the state of charge, or by timing the amount of time the sensing unit 100 has been connected. The values have the meanings defined in Table 4.

Table 4-Battery charge state field Value Meaning Remark °10 Battery completely The E-patch will not discharged necessarily ever send every one of these value. It may only be useful to send one of e. g. 0,50, and 100, to indicate empty, part and full charge status In, Battery 1% capacity Etc Etc 9910 Battery 99% capacity 100lo Battery fully charged 1011o Reserved Etc Etc 25510 Reserved The sensor statuses field is a bit field where the bits have the significances defined in Table 5. In each case the bit being set indicates that the corresponding sensor is available.

Table 5-Sensor statuses field Bit Meaning Remark 0 ECG connector 1 available 1 ECG connector 2 available 2 ECG connector 3 Flying lead connector available 3 Respiration sensor available 4 Sp02 sensor available 5 Reserved 6 Reserved 7 Reserved I PDL 120 receives the self-test packets and displays the results of the test, i. eX whether sensing unit is operational. Thus, it is possible for the operator of PDL 120 to determine whether or not sensing unit is operational without physically attaching sensing unit 100 to the patient.

In the presently preferred embodiment, patient data received at receiver 150 is processed on a packet by packet basis. Referring to Figure 8, at step 300, a packet of patient data is received at receiver 150. Each packet has associated therewith a received signal strength indicator (RSSI). The RSSI is used to determine whether sensing unit 100 is too far away from PDL 120 or located in a position where data is not clearly communicated to PDL 120. Acceptable RSSI values may be established, typically by an engineer via the PDL 120 interface. At step 302, it is determined whether the RSSI for the packet is above an acceptable minimum level. If the RSSI value is acceptable, at step 304, the packet is"unpacked"according to the procedures described below with reference to Figure 9. At step 306, the data from the packet is time stamped, compressed, and stored by processing unit 152. Thereafter, processing continues at step 300.

However, if it is determined at step 302 that the RSSI is not acceptable, at step 308 the data packet is discarded. At step 310, a communication is made to processing unit 152 to sound a notification or alarm to notify the patient that the signal from sensing unit 100 is weak and soon may be lost. It should be noted that if multiple packets in a row are determined to have an unacceptable RSSI value, the alarm becomes louder in order to bring greater attention to the matter. After requesting that the alarm be sounded, processing continues at step 300.

Data packets that are transmitted by sensing unit 100 and received at receiver 150 are formatted according to a defined protocol which may be referred to as the sensing unit-PDL protocol. Generally, the protocol includes three levels. Level 3 defines the format of the physical data, i. e. the length and identity of the data fields. Level 2 addresses error handling. Specifically, level 2 introduces the following: interleaving of packets to distribute the effect of error bursts caused by fades and interference, forward error checking (FEC) information to enable PDL 120 to recognize and correct errors in transmission, and scrambling of data to avoid the transmission of long sequences of ones or zeroes. Level 1 adds a preamble and synchronization sequence to the layer 2 packet to ensure synchronization of the receiver clock. Further details regarding the format of data transmitted by sensing unit 100 are described in co-pending U. S. Patent Application No.

(not yet assigned) entitled"Portable Remote Patient Tele-monitoring System Including an Electronic Patch" (Attorney Reference No. NEXT-0019), the contents of which are incorporated herein by reference in its entirety.

Upon receipt of data from sensing unit 100, it is necessary to"unpack"the data packets according to the defined sensing unit-PDL protocol. Figure 9 provides a flow chart of the"unpacking"process. As shown, at step 320 the preamble and synchronization data that was inserted as part of level 1 of the sensing unit-PDL protocol is removed from the data packet. At step 322, the data in the packets is unscrambled to reverse the scrambling that was implemented prior to transmission. At step 324, a cyclic redundancy check (CRC) is implemented to detect errors in the packet. If an error is detected, at step 326, it is determined whether the error can be corrected. If the error can be corrected, at step 328 the error is corrected and processing continues at step 330. If the error cannot be corrected, at step 332, the packet is discarded and a counter identifying the number of discarded packets is incremented at step 334. The discarded packet data may be accessed by an engineer for purposes of analyzing operation of the communications link.

At step 330, the sensing unit identifier included in the data packet is checked to determine whether the packet was received from the appropriate sensing unit. If not, at step 336 the packet is discarded and at step 338 a counter of packets received from an invalid sensing unit is incremented. If PDL 120 receives a predefined number of consecutive packets from the incorrect sensing unit, a visual and/or audible alert notifying the patient may be made.

If at step 330 the sensing unit identifier indicates the packet is from a valid sensing unit, at step 340 the data in the packet is de-interleaved to reverse the interleaving executed at sensing unit 100. Any readings that are not available during the de- interleaving because the packets that contained them have been discarded as invalid are marked as unavailable.

At step 342, the data in the packet is extracted according to layer 3 of the protocol that was used to prepare the data for transmission from sensing unit 100. During the processing corresponding to step 342, the data is time stamped and compressed. In one embodiment, PDL 120 has sufficient memory to store up to 24 hours of logged and compressed data.

User Interface Buttons 154 and display 156 provide PDL 120 with an interactive man- machine interface. As illustrated in Figure 10, the interface 348 has been designed to serve three primary user types: engineering personnel 350; HCPs 352; and patients 354.

Generally, engineering interface 350 provides a mode for persons performing engineering maintenance to interact with PDL 120. An engineer can view information useful for analyzing whether PDL 120 is operating correctly. Specifically, an engineer may be able to view a PDL identifier, the current bit error rate (BER), and the current packet error rate (PER). An engineer might also be able to configure the PDL with the RSSI value below which the PDL will alert the patient to the low signal level as well as the RSSI value above which the PDL will cease alerting the patient to the low signal level. The PDL 120 interface also allows the engineer to clear the memory and reset the PDL.

PDL 120 provides an interface 352 for HCPs as well. An HCP can view physiological patient data at any time sensing unit 100 is applied to the patient and the patient is within range of PDL 120. Patient data that can be displayed includes ECG information, respiratory rate, heart rate, and Sp02 level. In addition, the HCP preferably may view schedules of auxiliary sensor measurements. The schedule information might include the following: measurement number; total number of measurements; measurement type; window number; window start time; and window end time. HCPs can also view status information including the identity of the PDL, the percentage of free memory, the date and time the PDL was last turned on, radio strength, and battery capacity.

Of course, patient interface 354 is also provided. Generally, patients may display real time patient data including ECG information, respiratory rate, respiratory pattern, temperature, heart rate, patient motion and Sp02 level. Patient interface 354 also may comprise an indication of the quality of the signals that are being collected by the sensing unit. For example, if the signal for patient temperature that is being collected by sensing unit is intermittent or weak, this is indicated on the PDL display unit. Also, patients can view schedules of auxiliary measurements including the following information: measurement number; total number of measurements; measurement type; window number; window start time; and window end time. The PDL interface also provides a notify feature whereby the patient is alerted to perform an operation such as administering medicine, taking an auxiliary measurement, exercising, or eating. Buttons 154 provide a mechanism by which users can respond to alerts and input auxiliary measurements. When not displaying alerts, status messages, or patient data, PDL 120 displays the current date and time.

Figures 11 through 14 are exemplary screens that might be displayed on PDL 120. Figure 11 represents a default screen that is displayed when other operations do not require use of the display. As shown, a date and time are displayed as well as an indicator of the battery strength. A"happy face"indicates that PDL 120 is operating correctly and within range of sensing unit 100.

Figure 12 represents a main menu screen which a PDL 120 operator may use to access various functionality. The main menu comprises listings that provide for accessing additional screens. Specifically, the exemplary main menu screen provides access to screens for performing the following: viewing patient signals, viewing summary data, observing status information, observing actions, accessing an engineering menu, and accessing a patient menu.

Figure 13 represents an exemplary screen for selecting patient signals to view on PDL 120 display. As shown, the exemplary screen provides for selecting to view signals received over ECG lead 1, ECG lead 2, and ECG lead 3, as well as to view the respiratory signal. Figure 14 represents an exemplary screen that is displayed if ECG signal 1 is selected from the main menu. As shown, a graph is provided representing the signal received over the ECG lead 1. Additionally values for patient heart rate, respiratory rate, and hemoglobin are displayed.

PDL-BSU Interface Generally, the interface between PDL 120 and BSU 124 is a bi-directional link that is established by aligning PDL's connector 155 with a corresponding connector area on BSU 124. The interface is used to transmit patient physiological data from PDL 120 to BSU 124 and transmit monitoring session data from BSU 124 to PDL 120. The patient physiological data includes the data sensed by sensing unit 100. The monitoring session data includes data related to the monitoring session such as auxiliary measurement schedules and reminders.

The interface between PDL 120 and BSU 124 is defined using a three-layer protocol. Layer 1 establishes the physical interface between PDL 120 and BSU 124.

Layer 2 provides a state machine for controlling the transfer of data between PDL 120 and BSU 124. Layer 3 establishes the data packet message format.

Layer 3 of the PDL to BSU protocol establishes a format for messages transferred between PDL 120 and BSU 124. A general format for layer 3 messages is summarized in Table 6.

Table 6-General Message Format Bytes Description 1 Message Type 2 Total message length (bytes), includes length of this header. O.. n Message Contents As shown, each message comprises the following: a message type identifying which of several enumerated types is being made; a message length which identifies the total length of the message; and the actual message contents.

Thus, there are several different message types that have been defined in the system. These message types may be categorized by whether they are messages sent from PDL 120 to BSU 124, or messages from BSU 124 to PDL 120. The enumerated message types are listed in Table 7.

Table 7-Message types Value PDL to BSU BSU to PDL 1 Acquired Data 2 Live Data 4 Configuration Data 5 Status 6 Aux. Measurement Schedule 8 Aux Schedule Extension Aux Schedule Extension 9 Reset 10 New Configuration 11 Date and Time 12 Start Live Data 13 Stop Live Data As shown, for communications between PDL 120 and BSU 124, five message types have been enumerated. These include the following: acquired data; live data; configuration data; status; and auxiliary schedule extension. For communications from BSU 124 to PDL 120, seven message types have been enumerated. These include: auxiliary measurement schedule; auxiliary schedule extension; reset; new configuration; date and time; start live data; and stop live data.

The"acquired data"message type represents the data that has been acquired by sensing unit 100 and stored in PDL 120 since the last download. The message format for the"acquired data"message type is defined in Table 8.

Table 8-Acquired data Message Field Bytes Remarks Message Type 1 Acquired Data Message Length (bytes) 1variable Acquired data block Variable The"acquired data"message consists of an identification byte, a message length byte, and a variable amount of acquired data. The maximum length of the acquired data block is 93 bytes which sets the maximum length for the message at 95 bytes. Of course, a shorter acquired data block results in a shorter message length.

The"live data"message consists of data that is presently being received from sensing unit 100. This message corresponds to situations where PDL 120 is docked in BSU 124 and a live view of the data is being viewed on BSU 124. The format for the "live data"message type is enumerated in Table 9.

Table 9-Live data Message Field Bytes Remarks Message Type 1 Live Data Message Length (bytes) 1 variable Start Time End Time 6 It should be noted that the"live data"message includes a time stamp for each record indicating when the data was collected.

The"configuration data"ìnessage type provides information identifying how PDL 120 is presently configured. The message format is enumerated in Table 10.

Table 10-Configuration data message Field Bytes Remarks Message Type 1 Configuration Data Message Length (bytes) 1 Variable Auxiliary Measurement Schedule variable Aux Schedule Extensions 1 E-patchrecognized 1 PDL Identity 4 Patient Identifier 4 As shown, the"configuration data"message type contains information identifying the PDL, the sensing unit with which PDL operates, and the patient who is being monitored.

Also included is the auxiliary measurement schedule field that identifies the current schedule for auxiliary measurements. In the case that the entire schedule does not fit in the single message, the"auxiliary schedule extension"fieldis used to identify the number of "auxiliary extension"messages to follow that will complete the schedule.

The"auxiliary schedule extension"message contains data representing an extension to the"auxiliary measurement schedule"field of the"configuration data" message type. The"auxiliary schedule extension"is transmitted after the"configuration data"message if the entire auxiliary measurement schedule did not fit in the"configuration data"message. Table 11 lists the different fields of the message.

Table 11-Auxiliary Schedule Extension Message Field Bytes Remarks Message Type 1 Aux Schedule Extension Message Length (bytes) 1 Variable Auxiliary Measurement variabl Schedule e Aux Schedule Extensions 1 If an auxiliary measurement schedule is so long that it requires more than one extension message, further extension messages can be sent. The Aux Schedule Extensions field contains the number of further extensions to follow. If the extension is the last or only one, then the value of this byte is zero.

The last message type that is defined for transfer from PDL 120 to BSY 124 is the"status"message type. The"status"message type provides information regarding the sensing unit (referred to as the E-patch) and PDL 120. The status information related to sensing unit 100 is received by PDL 120 from sensing unit 100 itself. Table 12 lists the fields that are part of the"status"message type.

Table 12-Status Message Field Bytes Remarks Message Type 1 Status Message Length (bytes) 2 value 70 E-patch information available 1 see description E-patch identifier 1 see Gen III Air Interface Protocol 302-DES-001 E-patch status info 1 see Gen III Air Interface Protocol 302-DES-001 E-patch Hardware Version No. 2 see Gen III Air Interface Protocol 302-DES-001 E-patch Software Version No. 2 see Gen III Air Interface Protocol 302-DES-001 E-patch ROM parity check result 1 see Gen III Air Interface Protocol 302-DES-001 E-patch RAM read/write check result 1 see Gen III Air Interface Protocol 302-DES-001 E-patch Battery charge state 1 see Gen III Air Interface Protocol 302-DES-001 E-patch Sensor statuses 1 see Gen III Air Interface Protocol 302-DES-001 I TimelastE-patchstatusinforeceived | 6 | Seetablel3 Time last E-patch self-test packet received 6 see table 13 PDL Identifier 4 PDL Status information1 PDL Hardware Version No. 2 PDL Software Version No. 2 PDL ROM parity check result 1 PDL RAM read/write check result 1 PDL Battery charge state 1 PDL Patient Identifier 4 PDL Logger Memory Available 4 PDL last turned on time 6 see table 13 PDL last docked time 6 see table 13 PDL last undocked time 6 see table 13 BER 2 in parts per ten thousand PER 2 in parts per ten thousand RSSI 2 10 bit Table 13 provides the format for the fields of Table 12 that require time values.

Table 13-Time format Name Description Start Bit Length in Bits t 0.. 999 milliseconds 0 10 s 0.. 59 seconds 10 6 i 0.. 59 minutes 16 6 h 0.. 23 hours 22 5 d 1.. 31 days 27 5 o1.. 12 months 32 4 y 0.. 4095 years 36 12 Level 3 of the PDL to BSU protocol also defines the message types that are transferred from BSU 124 to PDL 120. These message types include the following: auxiliary measurement schedule; auxiliary schedule extension; reset; new configuration; data and time; start sending live data; and stop sending live data.

The"auxiliary measurement schedule"message type includes information defining a schedule for auxiliary sensor measurements. The information is uploaded to PDL 120 so that PDL 120 can generate the appropriate alerts to remind the patient. If the schedule is too long to be contained within a single message, the remainder of the schedule is sent in one or more"auxiliary schedule extension"messages. Table 14 enumerates the fields that are contained in the"auxiliary measurement schedule"message.

Table 14-Auxiliary measurement schedule message Field Bytes Remarks Message Type 1 Aux. Measurement Schedule Message Length (bytes)'1 Variable Auxiliary Measurement Schedule Variable Aux Schedule Extensions1 The"auxiliary schedule extensions"field indicates the number of extension messages that will follow. If none are required, the field is set to zero.

The"auxiliary schedule extension"message is employed when an auxiliary measurement schedule does not fit into a single"auxiliary measurement schedule" message. In those instances, after the"auxiliary measurement schedule"message is transmitted, the"auxiliary schedule extension"message is transmitted with the remainder of the schedule. If the schedule is so long that it requires more than one extension message, further extension messages may be sent. Table 15 enumerates the specific fields of the"auxiliary schedule extension"message.

Table 15-Auxiliary Schedule Extension Message Field Bytes Remarks Message Type 1 Aux Schedule Extension Message Length (bytes) 1 Variable Auxiliary Measurement variabl Schedule e Aux Schedule Extensions1 The Aux Schedule Extensions byte contains the number of further extensions to follow. If the extension is the last or only one, then the value of this byte is zero.

The"reset"message causes PDL 120 to be reset which clears all memory and configuration details. The format of the"reset"message type is defined in Table 16.

Table 16-Reset Message Field Bytes Remarks MessageType 1 Reset Message Length (bytes) 1 value 2 The"new configuration"message type configures PDL 120 to operate with a new sensing device 100 and/or a new patient identifier. The format of the"new configuration"message is defined in Table 17.

Table 17-New configuration message Field Bytes Remarks Message Type 1 New Configuration Message Length (bytes) 1 value 7 E-patch recognized 1 Patient identifier 4 The"date and time"message type updates the real time clock of PDL 120.

The clock may need resetting at the beginning of a monitoring session or if it drifts too far during operation. Table 18 enumerates the format of the"date and time"message type.

Table 18-Date and Time Message Field Bytes Remarks Message Type. 1 DateTime Message Length (bytes) 1 value 8 Time 6 The"start live data"message type instructs PDL 120 to start sending live data to BSU 124. During the period that live data is being transferred from PDL 120 to BSU 124, transfer of stored data is halted.

The live data request is implicitly canceled if the linlc between BSU 124 and PDL 120 is lost. Once the link is re-established, PDL 120 does not send more live data unless it receives another"start live data"message from BSU 124. Table 19 lists the various components of the"start live data"message.

Table 19-Start Live Data Message Field Bytes Remarks MessageType 1 Start Live Data Message Length (bytes) 1 Value 2 The"stop sending live data"message type instructs PDL 120 to stop sending the stream of live data to BSU 124. Table 20 lists the various components of the "stop live data"message.

Table 20-Stop Live Data Message Field Bytes Remarks Message Type 1 Stop Live Data Message Length (bytes) 1 value 2 Layer 2 of the PDL-BSU interface protocol models a state machine for transferring data between PDL 120 and BSU 124. It is presumed for the purpose of the state machine model that BSU 124 is a"master"and PDL 120 is a"slave."The protocol models four different states: link down; link verification; link established; and link shutdown. Figure 15 provides a diagram illustrating the conditions necessary for movement between these states.

"Link down"is the initial state and exists when PDL 120 is first seated in BSU 124. BSU 124 initiates communication by sending a"welcome"message across the interface to PDL 120 which, as the slave, simply waits for a message. PDL 120 acknowledges the"welcome"message by sending a response. If BSU 124 does not receive a response within a prescribed time, a"welcome repeat"signal is transmitted.

BSU 124 remains in the link down state until acknowledgement is received from PDL 120.

When the acknowledgment has been received, the"link verification"state is entered.

In the"verification"state, BSU confirms that PDL 120 is the correct PDL device. Upon entering the"verification"state, BSU 124 transmits a command to PDL 120 to send identification information. PDL 120 responds by transmitting"identities" information comprising its own identifier and the identifier of the sensing unit from which it is receiving data.

The behavior of BSU 124 upon receipt of the"identities"information depends upon how BSU 124 is being used. In the scenario that BSU 124 is in a patient's home and being used with a single PDL, upon receipt of the"identities"infonnation BSU 124 checks the identity information to insure that it corresponds to the expected PDL. In the scenario that BSU 124 is being used in an environment such as a hospital where multiple PDL's may be attached thereto, BSU 124 confirms that the"identities" information identifies one of the expected PDL's. If BSU 124 determines that the identity information does not represent an expected PDL, BSU 124 re-enters the"link downstate and begins sending"welcome"messages as described above. PDL 120 will re-enter the "link down"state when it receives a"welcome"message from BSU 124 If BSU 124 accepts the identity of PDL 120, BSU 124 enters the"link established"state. It remains in this state until it loses contact with PDL 120. PDL 120 enters the"link established"state as soon as it sends the"identities"message to BSU 124.

It remains in the"link established"until it loses contact with BSU 124 or until it receives another welcome from BSU 124.

In the"link established"state, data is transmitted between PDL 120 and BSU 124. Thus, in the"link established"state, layer 2 of the protocol communicates with layers 3 and 1 to send and receive data. Figures 16A through 16C provide a flow chart depicting the operation of layer 2 of the protocol while in the"link established"state. As shown, upon entry into the"link established"state, at step 370, layer 2 notifies layer 3 that it is ready to receive data. At step 372, layer 2 waits for a data message from layer 3. At step 374, it is determined whether the wait has been too long, i. e. a predetermined value "link-timeout"has been exceeded. If so, at step 376, layer 2 enters the"link shutdown" state.

At step 378, data is received from layer 3. At step 380, the data is formatted for transmission to layer 1. Generally, layer 3 data messages are no more than 95 bytes long. Upon receipt of the message by layer 2, a byte containing the layer 3 message length is added to the message. If the layer 3 message length is less than 95 bytes long, padding bytes are added to make the message 96 bytes long, including the length byte.

Thereafter, layer 2 calculates a CRC word for the 96 bytes and appends the CRC to the block resulting in a length of 98 bytes. Layer 2 also adds a one-byte sequence number to the start message. The sequence number indicates the type of message. The defined message types and sequence numbers are defined in Table 21.

Table 21-Message type/sequence numbers Binary Value Meaning- 00000000 dummy message 00001010 data block, sequence number zero 00000101 data block, sequence number one 10100110 ACK message 10101001 Replay (NAK) message At step 382, the formatted layer 2 data message is stored for possible re- transmission. At step 384, the layer 2 message is transmitted to layer 1 of the protocol. At step 386, two timers, the"retry-timer"and the"link-timeout"timer are reset and layer 2 begins waiting for a response.

If at step 387, a response is not received before the"link-timeout"timer expires, at step 389 layer 2 of the protocol enters the"link shutdown"state (See Figure 15). If at step 387 the"link-timeout"timer has not expired, at step 388, it is determined whether the"retry-timer"has expired. If not, at step 390 a"retry"counter is incremented.

If at step 392 the re-try limit is not exceeded, the data is re-transmitted from layer 2 to layer 1 at step 394. If at step 392 the re-try limit was exceeded, at step 396 the communication link between PDL 120 and BSU 124 is presumed to have failed and layer 2 enters the"shutdown"state (see Figure 15).

If at step 388, a response is received prior to the"retry-timer"expiring, it is determined at step 400 whether the response message was a"replay"request. If so, at step 402, layer 2 re-transmits the original message to layer 1.

If at step 400, the response message from layer 1 was not a"replay"request, at step 404 it is determined whether the response was an"acknowledge"request. If so, at step 406, another data message is requested from layer 3.

If at step 404, the response message from layer 1 was not an"acknowledge" request, it is determined at step 408 whether the request was a"dummy"message. If so, at step 410 the"link-timeout"timer is reset.

If at step 408, the message from layer 1 was not a"dummy"message, it is determined at step 412 whether the request was a data block. If so, at step 414 it is determined whether the message is the same as the last block previously received. If so, at step 416, the block is discarded and an acknowledgement is sent to layer 1.

If at step 414, the message is not the same as the last block previously received, at step 420, the CRC of the message is checked to determine whether the block is error free. If the CRC indicates there is an error in the message, at step 422 the data packet is discarded and a"replay"request is sent to layer 1.

If at step 420, the CRC indicates the message block from layer 1 is error free, at step 424 the data packet is stripped of its CRC and message type indicator. At step 426 the message is forwarded to level 3 for processing. At step 428 an"acknowledge" message is forwarded to level 1.

Thus, while layer 2 is in the"link established"state, data is transferred between layers 1 and 3 through layer 2 as defined in Figures 16A-16C. As described above with reference to Figure 16, layer 2 will leave the"link established"state and enter the"link shutdown"state if the"link-timeout"timer or the"number of retries"counter is exceeded.

As shown in Figure 15, upon entry to the"link shutdown"state, layer 2 informs layer 3 whether the last message received from it has been successfully sent. This allows layer 3 to reset any pointers to unsent data to the correct values. Layer 2 thereafter enters the link down state.

Layer 1 of the PDL-BSU protocol is the physical interface level. This layer simply transmits packets received from layer 2 to UART 218 and similarly passes packets received from UART 218 to layer 2. Physically, the interface is a three-wire link wherein one line is used to transmit data, another is used to receive data, and a third wire provides ground. Software handshaking is used to prevent over-runs Although an exemplary embodiment of the invention has been described in detail above, those skilled in the art will readily appreciate that many additional modifications are possible in the exemplary embodiment without materially departing from the novel teachings and advantages of the invention. For example, although PDL 120 has been described above as a specialized device for performing a set of specific functions, PDL 120 might also be modified to operate as part of a pager or wireless phone.

In such an embodiment, the pager or phone would operate as described above to gather patient data and would provide the additional two-way communications capabilities traditionally associated with pagers and phones. Thus, an HCP would have direct access to the patient and the data being collected from the patient using the pager and phone capabilities. The wireless phone and pager may be web enabled so as to facilitate transfer of data to and from PDL 120. Using the two way communications of either the pager or the phone, an HCP can monitor the physiological data being gathered and interact with the patient in real time. For example, an HCP might remind the patient of the need to take a prescribe medicine at specified time. Furthermore, the two way communications apparatus of a pager or phone, including their respective antennas, may be used to transfer patient physiological data to and from a base station unit and/or a remote monitoring station. The physiological data can be transferred from the pager or wireless telephone being used by the patient to collect data, to another pager or wireless phone that may be used, for example, by an HCP. Additionally, while the communication link between sensing unit 100 and PDL 120 is described above as being implemented with an FM radio connection, this link could alternatively be made using other wireless technologies such as the Bluetooth wireless technology developed by the Bluetooth Special Interest Group. All such modifications are intended to be included within the scope of this invention as defined in the following claims.