WIRELESS ECG AND PCG PORTABLE TELEMEDICINE KIT FOR RURAL AREAS OF COLOMBIA KIT DE TELEMEDICINA PORTABLE ECG y PCG INALAMBRICO PARA ZONAS RURALES DE COLOMBIA

In this paper we are presenting the first prototype device that measures 4-leads electrocardiogram (ECG) and phonocardiogram (PCG) signals with low cost, high portability and wireless connectivity features in mind. We designed and developed a prototype that measures ECG using a standard ECG cable; we designed and developed a digital stethoscope prototype and also the necessary hardware for both medical signals to be transmitted through Bluetooth to a computer. We present here the hardware design, a new communication protocol for transmission of both signals from the device to the computer, and the software system to enable remote consultations. We designed the prototype with the main purpose of using low cost parts without sacrificing functionality, with the purpose of using it in remote zones of the Caribbean coast of Colombia. We show open issues and prepare a field implementation of the kit in the target zone.


INTRODUCTION
Modern Telemedicine has been used for several decades now. Research about new and better Telemedicine devices has been constant because there has been always room for development costs and functionality improvement. With a constant increase of worldwide population, and always worsening weather conditions, countries are continuously having problems to bring decent health services to remotely located communities. In developing countries, this problem is even worse because remote communities are usually the poorest and accessing them is hard due to lack of good paved roads.
Construction of wireless Electrocardiogram (ECG) devices has been a common topic in Telemedicine in the last decade, thanks to the improvements in technology, especially for wireless communications and portable processing boards. As we will see in the Related Work section, many communication standards have been implemented to transmit the ECG signals out of the devices, so that any monitor implementing the same protocol could plot the signal being received.
Design and implementation of digital stethoscopes for Phono-cardiograms (PCG) on the other side are not much studied compared to ECG monitors. There are many commercial devices that are highly portable as they were built inspired in the old acoustic stethoscopes. Digital ones are needed for telemedicine, as they allow the signal to be transmitted remotely for the specialist to check it or to be saved in a server. However, the prices of these devices make them not so affordable and physicians prefer to acquire the old versions. In this paper we present a digital low cost version that can transmit the signal wirelessly through the same hardware used for the ECG signal acquisition.
The organization of this paper is as follows. In the next section we present what is the current work on medical signal measurements for telemedicine kits and software systems for remote consultations. In the third section we present the hardware design and implementation of our prototype. We then explain the communication protocol especially designed for our prototype. We continue in the following section explaining the telemedicine software (from the kit to the server to the client with the specialized doctor). We design then a field implementation to take the kit to a real setup. We continue with open issues of our work and conclude our work with some discussions. I.

RELATED WORK
Probably the most popular medical signal to be implemented in telemedicine kits is the ECG signal. The prototypes developed in [1] and [2] and [3] aim to perform a real time ECG measurement with wireless transmission. The authors in [1] used an amplification stage based on op amps prior to the transmission. They also implemented an FM modulation-demodulation scheme of the analog signal for wireless transmission (A/D conversion was not implemented in this stage). Signal acquisition was performed using the sound port of a personal computer. Both MATLAB and LABVIEW were then used for the display and digital filtering of the acquired signal. The authors in [2] implemented the amplification stage using an instrumentation amplifier. The output signal was then fed into a filtering stage prior to A/D conversion. They implemented a passive RC low pass filter and a Notch filter based on the UAF42 chip. An ADuC831 acquisition system from Analog Devices was used for A/D conversion. Wireless transmission was performed using the IPμ8930 chipset by Ipsil. It uses the Ipsil Communication Protocol (ICP) to communicate with a PC connected to the same wireless network. A Java application was used for the display of the acquired signal. The authors in [3] used for transmission an FM/FSK modulator. They performed A/D conversion prior to transmission and D/A conversion at the receiver. Then the ECG signal was acquired using the sound port of a personal computer. The paper [4] describes the implementation of a MATLAB GUI for ECG signal visualization and processing. The ECG signal was generated (not acquired from patients) using the MIT-PTB database along with an Arbitrary Function Generator (AFG) Agilent 33220A. It was converted to digital serial data and transmitted using a microcontroller and RS-232 protocol. An amplification and filtering stage were also developed prior to A/D conversion. ECG can also be used for automatic diagnosis of a critical condition. The project presented in [5] shows an implementation of a 3-lead ECG along with a PDA which performs automatic diagnosis for patients, taking into account their personal data and their clinical history, with the possibility to contact a remote emergency station. Other authors have focused their research in wireless electrodes [6], [7], [8], [9]. They pursue the improvement of portability for telemedicine and also make the patient more comfortable with measurement artifacts. The authors in [6] look for the generation of 12-lead ECG information based on a three-pad wireless electrode instead of the usual one pad electrode. It uses a TelosB interface for wireless transmission of the information captured by each electrode. The authors in [7] use a small wearable two-pad electrode for ECG signal acquisition and transmission. It uses the IEEE 802.14.5 protocol for data transmission over the wireless network. Other works focus their research in the encapsulation of the ECG signal acquisition and processing system on a single chip [10], [11]. Commercial available ECG monitors can be found in [8] and [12].
On the other hand a PCG signal and has become useful for medical diagnosis [13], [14]. Therefore there have been several developments regarding electronic stethoscopes which can convert body sounds to digital signals. In [15] a low cost electronic stethoscope was developed with both earphones and a Bluetooth/USB interface for transmission to a personal computer. It uses an electret microphone with an audio codec for A/D conversion. A microcontroller is used for serial data generation prior to transmission. It also has the possibility of flash storage of the signal. The authors in [16] focused their research in an adaptive filter for noise cancelation of PCG signals. They use two electret microphones (one for the signal acquisition and another one for the capture of ambient noise). A DSP board was used for the testing of adaptive noise cancellation algorithms. The same were simulated in MATLAB in order to determine the appropriate parameters that were programmed in the board. In [17] a prototype of an electronic stethoscope with an ultra-low power DSP was developed. They achieved signal filtering and record/playback with no possibility of transmission.
The communication of ECG signals has been a matter of study for many years. The work done in [18] is great compilation of all the different standards used in ECG communication. There are many different formats created depending on the needs. The most used formats are the ones supported by Standard Developing Organizations (SDO). The most common standard is the SCP-ECG [19] which was developed initially as a European standard. It is a binary encoded format that establishes how is the information exchanged between the ECG device and the ECG host system. It has fields to transmit information about the patient to label properly all the signals transmitted. Later in the paper we will show that we built our own communication protocol to compact in the same packets information from both the PCG and the ECG.
Construction of telemedicine kits have been also a matter of extensive research. Thanks to the popularity of embedded systems, the trend has been moving into developing very small devices with ready-to-go platforms like Raspberry Pi [20]. This is usually translated into more signals being transmitted remotely. The architectures of telemedicine systems remain an interesting research topic, an example is the work presented in [21] where the authors presented a tele-health architecture for ECG monitoring. The architecture is sometimes shaped according to variables like the technology resources available, communication links used for the consultations, and user interface requirements. Our work focuses on designing a simple telemedicine server with which our kit can communicate and guarantee that remote specialists can access the signals just measured. Communication protocols used and the design architecture have been simplified for this purpose and will be explained later in the paper.

II. ECG AND PCG HARDWARE DESIGN
In this section we will explain the construction of both monitors into one hardware device with both electronics inside.

A. ECG Hardware Design
As we can see in [1], [2] and [3] the first stage of the hardware acquisition system for an ECG signal is a preamplification stage. This is usually achieved by using instrumentation amplifiers since the raw ECG signal is in the millivolts range. Our pre-amplification stage is based on the application note for the INA128 ECG amplifier with a right leg drive [22]. This differential stage provides the measurement of one lead of the Einthoven's triangle [23].
However more than one lead is necessary when performing diagnosis since each one gives a different point of view of the heart. We realized that an analog multiplexer could help us to measure different leads, by properly selecting the pair of electrodes of the Einthoven's triangle, with little hardware expansion. In our regional market we also found an ECG cable with capability of 5 electrode placement which could measure 9 leads (one at a time with the proper electrode placement) out of the usual 12 that are used for diagnosis. We also implemented a push button selector for changing the measured lead. The output of this stage was an AC signal in the volt range.
After the pre-amplification stage we needed to condition our ECG signal prior to A/D conversion and wireless transmission. We decided to use a dsPIC30F4013 for that purpose. The input signal should have a 0V to 5V range (5V being the supply voltage of the microcontroller). We based our design in a general purpose operational amplifier with the adequate biasing in order to provide both amplification and offset to the input signal [24]. This stage also had a passive filter in order to reduce noise. The resulting ECG signal was visible but very noisy. Passive filtering was not working properly. We decided to implement active filtering with the constraint of little hardware expansion and low cost increase. In our regional market we found an universal active filter (UAF42) with the capacity to implement active filters based on resistors and capacitors connected directly to the IC [25]. We implemented a second-order Butterworth low-pass filter with cutoff frequency of 150Hz and a 60Hz Notch filter based on an application note [26]. Two UAF42 were needed and the resulting ECG signal was ready for A/D conversion. Although ECG signal has bandwidth of 250Hz [24], thus sampling rate according to the Nyquist theorem would be 500Hz. We used as sampling rate 1kHz in order to send ECG and PCG samples with 1ms delay (using RS-232). Furthermore the dsPIC30F4013 has 12 bit A/D conversion resolution which gives 1.22mV of quantization step, more than necessary given that the ECG signal was previously conditioned from the millivolt range to 0V-5V range. Each RS-232 serial sample was fed to an RN-42 Class 2 Bluetooth Module [27]. It works with 3.3V and can transmit RS-232 without conditioning. We used its default transmission rate of 115,200 baud/sec.

B. PCG Hardware Design
The PCG hardware of the system is composed of both a sensor and a circuitry part. Figure 3 shows the custommade stethoscope used for sensing the analog signal from the patient. It has a diaphragm (same used by acoustic stethoscopes) which uses an electronic microphone in order to capture the auscultation sounds from the human heart. This stethoscope ends in a 3.5mm stereo jack that needs to be connected to the Wireless ECG PCG hardware, so the local physician can hear the acoustic signal using headphones. The PCG signal can also be wirelessly transmitted so the remote physician can access its visual information.
The circuitry used for audio pre-amplification was based on a general purpose operational amplifier with the adequate biasing in order to condition the signal. After this stage a passband filter was designed in order to remove DC and high frequency components after the first amplification stage. Then an audio amplifier based on the LM386 IC was used for audio amplification. This IC can handle low ohm headphones and has low power consumption since it is a class AB audio amplifier [28].  As shown in Figure 2, the custom-made stethoscope feeds the analog signal to an electronic circuitry that conditions and wirelessly transmits the PCG signal. Since the PCG signal has 600Hz bandwidth, but relevant heart sound information lies in the 20-115Hz range [17], the chosen sampling rate of 1 kHz suited the PCG signal as well. For this part a conditioning stage was built in order to match the voltage range for A/D conversion of the dsPIC30F4013. Each sample was converted to RS-232 in order to wirelessly transmit the signal using the RN-42 Class 2 Bluetooth module as described in the previous section.

C. Hardware Prototype
Both components were built into a small and portable hardware prototype. We based our design of the prototype in building low cost components from scratch and then we searched for a container that could fit all the components inside and arrange the connectors comfortably. When large budgets are available, the product could be designed taking into account components, usability, materials, size and other variables at the same time to have a finished product after only a few rounds of design.
Three versions of the prototype were built. All of them have a 6 pin port to connect the ECG cable shown in Figure 4. The first one was built with a custom made container that could fit all the parts in the smallest way possible. The container had a size of about 9 inches high by 3 inches width by 2 inches depth. The container was designed so it could fit easily in your hand and be carried around with ease. This first design however was at the end not adequate because the size of the container did not allow more components to be fit in in the case it were necessary. The other problem was that the manufacturing of the custom made container increased the final price of the prototype. We could have decreased the cost of the container but it implied producing hundreds of containers meaning hundreds of telemedicine kits. However we estimate that only a few kits needed to be manufactured and we needed cheaper containers since the beginning.
The second version of the container focused on low budget manufacturing. In fact, a commercial plastic box was used to fit the contents inside. Looking for a combination of low-cost containers with decent design, we changed the box for the design number 3. Figure 5 shows the current and final hardware version. It consists of a box of about 8 inches by 4 inches by 2 inches (the size of a small book). The container can be bought in Colombia for about 9 dollars each. The front was designed and the box modified to fit buttons for the 4 leads we measure, the On/Off button, a 3.5mm connector where the digital stethoscope goes and a 3.5mm connector where the user could plug headphones to listen to the stethoscope sounds. One of the sides fits the 6 pin port for the ECG cable, and the connector for the charger. We have to note that the device sends only one the leads at any time. This means that the user needs to press the button corresponding to the lead he/she wants to see plotted in the software.
The final box was selected due to its nice presentation, its low price and of course the size which had room enough for fitting our components and probably more in the future, but it was still considered a small size to be a portable low cost kit.

III. THE COMMUNICATION PROTOCOL
We explained how the measuring hardware was designed and developed. For the telemedicine kit, we needed to transmit the signals out of the hardware wirelessly, for the computer to upload them to the server. We did not use any of the ECG communication standards explained before, because we needed to transmit both signals at the same time. For this reason, we built our own protocol and explain it now, while comparing it with standards commonly used.
The data frame sent from the device is composed of a reference part (REF), the PCG sample, and the ECG sample, as shown in Figure 6. Since the microcontroller A/D conversion resolution was 12 bits and RS-232 protocol is based on an 8 bit transmission, we decided to transmit 16 bits as shown in Table 1. The first 8 bits of the 12 bit sample were taken as the Least Significant Bits (LSB) part. The four remaining bits were then transmitted placing zeros where information was not available, composing in this way the Most Significant Bits (MSB) part. We also needed a reference in order to synchronize the analog data converted to digital samples with the received information by the host. For this purpose we sent hexadecimal FF as the reference. In binary the following was the data frame structure: The same data frame structure was sent each 1ms in order to plot the ECG and PCG digital signal in the host (the computer connected to the kit) and has the same format available in the server. When the host received an FF, the following 16 bits were PCG data and the  This protocol is itself not comparable to standard ECG transmission protocols. We have to create this to facilitate the output of the signal from the device. Standard ECG protocols endorse meta data that label the information so that it can be properly stored and identified. We do not process any further the data received from the device. However, the computer connected to the device could actually add a standard ECG protocol to the data received from the device and then upload it to the server for other tasks. This is beyond the scope of our paper but this extra development would standardize the telemedicine kit as a whole.
IV. TELEMEDICINE SOFTWARE The software has two sides. One side is in charge of receiving the data from the telemedicine kit, showing it to the user in front of the computer and uploading the data to the server; we call this side the Generator. The side number two is used as client. It is a simplified version of the Generator, and we call it the Client. The software is complemented by the telemedicine server. We will explain in detail how each of them works.

A. The Generator
This software was developed in Java and was setup to run originally in Linux, however it should run under Windows with no problem. Given that the communication between the device and the computer is done using Bluetooth, the software first checks if there is a Bluetooth connection. It should abort execution if no connection is found. Once connection is verified, it shows a screen as shown in Figure 7 (menu options are in Spanish). We show here an open menu tab which lists the devices the software can connect to. For each of them, it needs to pair the Bluetooth connection of the PC with the connection of the device. Once the devices are paired, the software will start showing in a graph the signals being received from the device. We can show in different tabs signals from the ECG, the stethoscope and the pulse oximeter, which is the device complementing our prototype.
The back-end of the software is in charge of delivering the signals to a server to be able to show them to remote specialist in a close to real time fashion. Figure 8 shows the architecture of the solution. The server needs some particular configuration to work: MySQL and an FTP server need to be installed and both servers have to be accessible through an open port in the telemedicine server. This implies that not a regular inexpensive hosting could be used to store our server.
The software in the computer stores in a file the signal data received from each one of the monitors. Every 100 data the file is closed and uploaded via the ftp server available in the server.

B. The Client
The client is a shortened version of the Generator software. It was designed to work with sessions. A session consists of 1 to 3 plots in the interface, depending on the number of signals the user asks the software to plot. A session could be a) real time session, or b) stored offline session. A real time session will plot whatever the server is receiving from the telemedicine kit at that time. This is identified by the software as the most recently updated files available in the server. A stored session is identified by the patient ID. The server could store any number of offline sessions, which can be later retrieved using the ID. When an offline session is selected, it will be displayed as if it were a real time session. The ECG signal for example is plotted at the same rate as if it were being measured. This offline sessions are helpful in case the specialist Internet Internet cannot perform the remote consultation, but is still available to check a patient's signals at some other time.

C. The Server
The server is just a computer with a MySQL and FTP server and it then needs the ports for these applications open. In order to receive files with signals from the sessions it needs the FTP server. The MySQL database will store information from each of the patients that use the telemedicine kit. The database also associates each of the stored session with its corresponding patient ID.

D. Evaluation
In figure 9 we show the signal being received from the telemedicine kit as it is displayed by the software. We received the collaboration from two students from our department who kindly accepted to get their heart monitored. Both students are between 20 and 24 years old, and they do not know of any heart condition that might show up in the signal monitored. Both figures are from lead number 2.
The information the device is providing should be helpful to detect some type of simple heart anomalies. However for some complex heart conditions, it is usually necessary to collect the 12 leads from the heart. V. DESIGN OF A FIELD IMPLEMENTATION This telemedicine kit was designed taken into account very common medical signals. It was designed with the purpose of being used in a real environment. We will explain here the design of an implementation that is expected to take place in a remote location in the Caribbean Coast of Colombia. The implementation has not taken place yet but we expect to take the kit to the hospital during this year and evaluate how useful could this kit for the particular environment.
For the purpose of the field implementation we selected as a remote location a small island called Barú Island, located about 50 miles southwest from the city of Cartagena, in the Caribbean Coast. Barú Island is actually a small peninsula of about 60 km2, with a population of about 10,000 habitants leaving under the line of poverty. The largest town is called Santa Ana with a population of about 5,000 habitants. The peninsula is separated from the main land by a small channel of about 60 meters wide. There is no bridge to cross from main land to the peninsula, so you have to take a ferry to go by car from Cartagena (the closest large city) to Santa Ana. The separation created by the channel is what has created the nickname of Barú Island to this peninsula. The travel might take you about 1 hour to complete and usually is performed with pick-up trucks, buses or trucks because the roads are not paved. Local government is however improving road conditions in certain points of the island. The habitants have to sometimes travel using their motorboats especially during the nights because the ferry works just during business hours. The island has a small hospital that attends certain types of emergencies. Santa Ana receives scheduled visits from different types of medical specialists during the year. However, a gynecologist might for example perform no more than 1 visit every two months to the hospital. Emergencies that cannot be attended in the hospital need to be taken to bigger hospitals in Cartagena. If the emergency is during the night, the person has to be moved using motorboats, regardless of the high risk associated with high tides.
We decided to pick Barú Island for its special conditions as the target of our field implementation. The hospital has worked already on improving communication conditions by exploring contracts with satellite Internet providers. Given the small size of the peninsula, its low population and the very low median income of the people, mobile networks providers have not been interested in investing on the island. Only one provider from the 5 available in Colombia offer connectivity once the bridge across the channel is crossed. The authorities from the hospital have already signed the contract and remote consultations have taken place already with the use of Skype. We consider that our kit can help them to treat patients in places even farther than the small hospital itself. The hospital counts with a non-portable ECG monitor and regular stethoscopes. However, this is the largest healthcare institution in the island, and an important goal would be to take specialized care to remote locations in the island itself.
VI. OPEN ISSUES The main advantage of the telemedicine kit we built is that built it from scratch. This gives us control over how the signals are measured, how the information is sent, the format of the data being exchanged between the device and the computer, the communication channel used and the architecture of the telemedicine consultation itself. We can then easily create the following list of open issues we consider could be developed on top of our telemedicine kit, or as new versions derived from this work. The list is as follows:  The Generator could be ported to a mobile device.
Thanks to the design of our architecture, the kit can be modified to make a mobile phone receive the signals from the monitors and upload them to the server. The connection with the device relies only on a Bluetooth connection. The uploading process however would have to be improved to save bandwidth usage and then improve battery live.
 A simplified telemedicine server. The need for open ports for MySQL and FTP server in the telemedicine server puts some complexity in its design. This leaves out inexpensive hosting. The new design could rely on other uploading techniques, like for example using web services to upload the data. This however needs a careful design because it could affect the performance of the real time task of showing the signal to the specialist.
 User interface: In the next version of the kit the focus could be in the user experience. Some design rules should be followed, taking into account the mobility that user might expect from it. For example we might consider smaller sizes for the device container, or designing it as a wearable device.
 ECG communication protocol: Our kit does not follow any ECG communication standard. This could prevent the kit from being used frequently in locations where it becomes necessary to mix the reports from this device with other medical information from the same patients. Another reason to standardize the communication might be the possibility of running ECG analysis algorithms to detect anomalies. Such algorithms are designed to be used with standardized data.
 Security issues: in this environment, the biggest issue should be the fact that the medical records from patients could fall into the wrong hands. However security here is based on common security principles that can be achieved with existent security standards and protocols. For example we need to secure the communication from the kit to the telemedicine server and from the server to the specialist. This can be done with a regular secure connection over the Internet. The Bluetooth connection from the device to the computer can be considered safe, because the device should only be turned if is going to be paired with its computer.