Home dialysis supervision systemfileadmin.cs.lth.se/serg/old-serg-dok/docs-master... · patient at home. Serena® Monitor: The Serena® Monitor is a dialysis machine performing a

Home dialysis supervision system

A Master thesis by: Jonas Klintberg Markus Nilsson

Home dialysis supervision system Jonas Klintberg, Markus Nilsson

1

Abstract This master’s thesis has the purpose to investigate the new possibilities available with telemedicine to simplify the life for the long-term user of Gambro’s Serena® Monitor dialysis machine. More specifically we investigated how the Serena® Monitor can communicate with the patient’s clinic without the need for the smart card that is currently in use. To further help the physician in his diagnosis it would be convenient if parameters from other medical devices such as a blood pressure monitor and a scale also could be gathered. Since there would be some distance between these devices it would be handy if wireless communication could be used to link them together. We built a working prototype, which uses wireless Bluetooth as the technology of choice for communication between the devices in the patient’s home. Since the Serena® Monitor is a medical device that needs to be rigorously tested we concluded that it was unwise to integrate functions for connecting it directly to the outside world. Instead we introduced a small embedded Linux system as a gateway for the external communication, which has both Bluetooth and Ethernet connectivity.


2

Abstract ..........................................................................................................................1 1. Glossary .....................................................................................................................4 2. Introduction................................................................................................................6 3. Environment...............................................................................................................7 4. Approach....................................................................................................................7 5. Research.....................................................................................................................7

5.1 INITIAL RESEARCH ................................................................................................7 5.1.1.1 WLAN....................................................................................................7 5.1.1.2 Bluetooth................................................................................................8 5.1.1.3 RF...........................................................................................................8

5.1.2 Initial conclusions.........................................................................................8 5.2 FURTHER RESEARCH .............................................................................................8

5.2.1 Serial communication ...................................................................................8 5.2.2 The Bluetooth technology .............................................................................9

5.2.2.1 The Bluetooth profiles ...........................................................................9 5.2.3 Strictly limited resources in the Serena® Monitor .....................................10

5.2.3.1 Solutions ..............................................................................................10 5.2.3.2 The gateway .........................................................................................11

5.3 REQUIREMENTS...................................................................................................11 5.4 SOLUTIONS..........................................................................................................11

6. Prototype construction .............................................................................................12 6.1 APPROACH ..........................................................................................................12

6.1.1 First increment............................................................................................13 6.1.2 Second increment ........................................................................................14 6.1.3 Third increment...........................................................................................15 6.1.4 Fourth increment ........................................................................................16

6.2 IMPLEMENTATION ...............................................................................................16 6.2.1 First increment............................................................................................16 6.2.2 Second increment ........................................................................................17

6.2.2.1 Communication issues .........................................................................17 6.2.2.2 Minuscule connector............................................................................18

6.2.3 Third increment...........................................................................................18 6.2.3.1 Routing software..................................................................................19 6.2.3.2 Modifications to GXL..........................................................................19 6.2.3.3 Debugging further................................................................................19

6.2.4 Fourth increment ........................................................................................20 6.2.4.1 The HCI module ..................................................................................20 6.2.4.2 BlueZ debugging..................................................................................21 6.2.4.3 BlueZ on the Linux gateway................................................................21

7. Security ....................................................................................................................22 7.2 REMOTE AND GLOBAL SECURITY.........................................................................22 7.3 SECURITY RECOMMENDATIONS FOR MEDICAL USAGE .........................................23

7.3.1 On site communication ...............................................................................23 7.3.2 External communication .............................................................................23

8. Commercial products ...............................................................................................23 8.3 CONCLUDING REMARKS ......................................................................................24

9. Extensions and improvements .................................................................................24


3

9.1 MEDICAL PERIPHERALS.......................................................................................24 9.2 SECURITY............................................................................................................24

10. Final Conclusions...................................................................................................25 11. References..............................................................................................................26


4

1. Glossary Dialysis: Dialysis is a method for removing waste such as urea from the

blood when the kidneys are incapable of doing so. Peritoneal dialysis: Peritoneal dialysis (PD) does not

require technically advanced equipment. It differs from hemo-dialysis in that the blood is treated without being removed from the body. Instead, the dialysis fluid is introduced into the patient’s abdo-minal cavity through a catheter placed in the lower part of the abdomen. It is the peritoneum that serves as the dialysis membrane. When the dialysis fluid is drained from the abdominal cavity, it contains waste products and excess fluid extracted from the blood. Dialysis fluid, sterile medical lines and in some cases a PD cycler like the Serena® Monitor are used for the treatment that is often managed by the patient at home.

Serena® Monitor: The Serena® Monitor is a dialysis machine performing a PD

dialysis manufactured by Gambro. GXL GXL (Gambro eXternal Logging) is a surveillance tool capable

of monitoring multiple parameters of Gambro’s dialysis machines when they are in operation.

UART: Universal Asynchronous Receiver-Transmitter is a piece of

computer hardware that translates between parallel bits of data and serial bits. A UART is usually an integrated circuit used for serial communications over a computer or peripheral device serial port.

WUART: Wireless UART HCI: Host Controller Interface is a standardized interface between

the host controller and the host together with the communication protocol between them.

RTX healthcare: See www.rtx.dk specifications for their gateways can be found

here http://www.rtx.dk/Default.aspx?ID=79 SPP: Serial Port Profile is a Bluetooth profile which emulates a

UART connection, enabling simple point-to-point communication.

BCSP: BlueCore Serial Protocol is a protocol that specifies how data

is sent between a UART Bluetooth device and the system.


5

Vmware: Vmware is a commercial software product that can create and

run virtual machines, like an emulator. Mini-ITX Mini-ITX is a motherboard form factor developed by VIA.

The motherboard can be used as a moherbord on an ordinairy pc. The motherboard dimensions are only 170mm by 170mm.

AT commands AT commands are basic instructions that were developed for

communication with modems.


6

2. Introduction This master thesis was conducted in the MD-division at Gambro AB in Lund, Sweden. The MD-division has developed a dialysis machine for home use, the product at hand is called Serena® Monitor. The medical information collected from each treatment by the Serena® Monitor needs to be analyzed by a physician in order to ensure that the treatment enrolls as expected. The information collected during the treatments is currently uploaded to a Smart Card that can only store a limited amount of data. Depending on the patient’s condition the Smart Card must normally be brought to the clinic in the interval of one to two months. This amounts to a series of problems, first of all this requires some patients, which are often in poor condition, to travel for hours in order to reach their clinic. This also means that the physicians have a very limited possibility to monitor the patients during the cycles, and thus are unable to detect changes in the patient’s condition. Furthermore this means that the necessary changes to the treatment parameters only can be done in large time intervals. The question was raised at the MD-division if the information exchange between patient and hospital could be done in a more efficient but still secure manner. A further request was that the Serena® Monitor should be able to interface other medical appliances such as a scale or blood pressure meter, the data gathered from these would further help the physician in his decision making regarding the treatment. The communication with the peripherals should be conducted in a wireless fashion to simplify for the patients. This master thesis has the aim to analyze the given scenario, to propose the most favorable solution and construct a prototype to demonstrate the concept. The figure below illustrates the concept of this master thesis, which is to enable the Serena® Monitor to communicate with a remote computer. As seen in this figure the Serena® Monitor should communicate wirelessly.

Figure1. An illustration of the aim of the master thesis. A gateway communicates with several medical devices and with a remote host. The medical devices on this image are from the left, the Serena® Monitor, a blood pressure monitor and a scale.


7

3. Environment The environment at hand consists of the Serena® Monitor dialysis machine and the physician’s software called Gambro Synergy. The Serena® Monitor is at the moment equipped with a serial RS232 port and a Smart Card terminal for external communication, furthermore it runs EDOS as the underlying operating system. The RS232 connection is set up to use the TCP/IP communication protocol. The Gambro Synergy software runs in the Windows environment. The software provides functions to read and display patient data in a readable fashion. The physician also has the option to change treatment parameters and write them to a patient’s Smart Card.

4. Approach The approach is divided into two main phases, research and implementation. During the research phase the aim is to gather as much information as possible and to weigh different proposed solutions against each other to ensure that the most advantageous is chosen. Once a solution path is selected this solution will be implemented in the form of a working prototype.

5. Research

5.1 Initial Research One of the initial requirements was that the Serena® Monitor should be able to communicate with its environment wirelessly so the research phase was initiated with a survey of wireless technologies that would be appropriate. Another requirement was that the system should be able to gather data from external medical appliances, such as a blood pressure monitor and a scale; therefore we had to survey the market and investigate what means of communication that are available with these appliances. Research was also conducted on the hand over technologies, i.e. how could a Bluetooth device be connected to the Internet? The fact that the treatment information is to be sent to the clinic requires a secure way of sending sensitive treatment data. With this in mind research was conducted into possible transfer solutions. We started out with investigating how the Serena® Monitor could communicate with its surroundings in a wireless manner. The research conducted shows that with this restriction the field is narrowed down to three contestants. These three are WLAN(802.11), Bluetooth and conventional RF. The different solutions all have their pros and cons, but all of them can be used with RS232. 5.1.1.1 WLAN The WLAN solution has a number of quite heavy weighing advantages; it is the fastest among the three and has a long range. Since it already communicates with TCP/IP a connection to the internet should be trivial. The WLAN technology is constantly updated but in this field new products tend to be backwards compatible. The fact that the Serena® Monitor already operates with TCP/IP should make the conversion easier than for the rest of the proposals. There is however a quite large downfall to this solution which is that none of the existing medical peripherals that


8

were found during the research were operating via WLAN, this is probably due to the fact that WLAN circuits consumes more energy than competing solutions. 5.1.1.2 Bluetooth The advantages of Bluetooth are that it consumes less energy than WLAN and the Bluetooth circuit is less expensive. These two factors contribute to the fact that a spectrum of wireless medical peripherals communicates via Bluetooth. The handover between Bluetooth and GPRS could be done in two different ways, either by a router that only fills this function or by a modern cell phone. Appliances that hand over between Bluetooth and Ethernet are also available on the market. Unfortunately the maximum transfer speed for Bluetooth is less than a tenth of the WLAN. It can also prove quite a demanding task to modify the Serena® Monitor to a native support of Bluetooth. 5.1.1.3 RF The RF approach has the advantage that similar solutions exist on the market, this will probably simplify the implementation of this approach. The RF also has a good range. Since RF has been around for quite some time, transmission speeds for digital information is slow and encryption has to be done manually.

5.1.2 Initial conclusions After considering the available options that are presented above and after a project meeting with involved parties it was concluded that the Bluetooth solution would serve our purpose in the most satisfying way. The major benefits of the Bluetooth solution were that medical peripherals that communicate via Bluetooth are available of the shelf. Furthermore the Bluetooth solution seems to be the most economical since the Bluetooth modules are available at low cost. A potential drawback of this solution is the rather limited performance, this however is limited due to the fact that the Serena® Monitor will not be able to process the communicated data at a higher rate than the Bluetooth solution provides. If the Serena® Monitor would be equipped with faster means of communication in the future a new specification of Bluetooth is soon available enabling higher transfer speeds.

5.2 Further research Since we chose the Bluetooth approach, we needed further research into Bluetooth and how we could interface it with the Serena® Monitor.

5.2.1 Serial communication Since the Serena® Monitor is equipped with a RS232 serial port, we had to investigate how serial communication operates. The serial data is sent in data blocks, first a leading start bit, then five to eight data bits, an optional parity bit and finally a stop bit. The serial port can operate in a variety of different speeds, from 110 bits/s up to 115200 bits/s. The serial chip consists of two separate circuits, one that transmits and one that receives data, thereby it is able to concurrently send and receive data. The RS232 standard describes voltage levels that define logical zeros and ones. The voltage in the range between 3V and 15V will be interpreted as a logical zero and –3V to –15V as a logical one. The range around zero volts is not defined. Voltage


9

levels of ±5V, ±12V and ±15V are commonly seen depending on the power source available on the device.

5.2.2 The Bluetooth technology Bluetooth is an industrial specification for wireless personal area networks (PAN). A Bluetooth PAN can consist of up to 8 devices, where one acts the role of a “master” and controls the communication; the other devices are “slaves” and only communicate with the master. The master communicates with the slaves in a round-robin fashion and by doing so very rapidly the data transfers seem instantaneous. When a Bluetooth device, the master, is going to establish a connection to another Bluetooth device, the slave, the procedure typically starts with an “inquiry”. The inquiry is an identification request that is broadcasted to all available Bluetooth devices. Every Bluetooth device has a unique address and the identification response contains this address which is vital for establishing the connection. When the address of the slave is known a connection can be attempted, the slave can accept or reject the incoming connection depending on security parameters or built in limitations; some devices can only handle a single connection at a time and when one is established it will reject all succeeding attempts. The security measures available for accepting or rejecting connection attempts are the usage of a passkey, the unique address and user input. The passkey is a shared secret between the two Bluetooth devices; the connecting device encrypts and sends the passkey, if it corresponds with the slave’s it will accept the connection, otherwise reject it. A slave can also be paired with a specific Bluetooth address and will only accept incoming connections from this address. Finally the slave can accept or reject incoming connections depending on user input; devices such as mobile phones can prompt the user to decide whether to accept or reject a connection. Once a connection has been established all traffic is automatically encrypted with a stream cipher, which utilizes a 128 bit key. The data is transmitted on the license-free 2.54 GHz band and in order to avoid collision with other devices operating in the same frequency spectrum it divides the band into 79 channels and changes between them 1600 times per second. The current implementation of Bluetooth handles transmission speeds of up to 723 kbit/s and the upcoming revision of the Bluetooth protocol handles speeds of 2.1 Mbit/s. The range of Bluetooth devices varies depending on the amount of power it consumes, generally Bluetooth products are divided into three classes:

• Class 1; consumes approximately 100mW and has a range of up to 100 meters.

• Class 2; consumes approximately 2,5 mW and has a range of 10 meters. • Class 3; consumes approximately 1 mW and has a range of 10 centimeters,

with a maximum of 1 meter. 5.2.2.1 The Bluetooth profiles The Bluetooth protocol defines a large variety of different profiles. The profiles are a standardized way of communicating different kinds of data and currently there are 25 types, for example there are profiles for picture transfers, print jobs, headsets and serial link replacements. To facilitate the usage of these different profiles, Bluetooth


10

devices has a protocol stack that implements the profiles that are appropriate for the device and translates incoming data into appropriate calls. In order for a Bluetooth device to communicate with another they must be able to use the same profile, a headset using the Headset Profile can for instance not communicate with a printer which uses the Basic Printing Profile. Bluetooth devices that are able to communicate with different devices running different profiles must therefore have a protocol stack that implements all of them. Generally having no protocol stack at all on the Bluetooth chip solves this. Instead it requires the stack to be implemented on the host system. These are called HCI devices and they can communicate with any type of profile as long as the profile is implemented in the software stack.

5.2.3 Strictly limited resources in the Serena® Monitor Our research into how the communication with the remote host should be handled insists that some kind of intelligent gateway is introduced to the setup. There is a spectrum of reasons for this. First of all since the Serena® Monitor is considered a medical device it is highly unwise to hook it up to an external network such as the Internet. The reason being that a lot of security would have to be added to the Serena® Monitor to make it cope with the threats of this context. The Serena® Monitor has been designed to process only the data that originates from the dialysis treatments and thus its resources are very limited. Gambro has made a lot of effort to keep the software that is loaded into the Serena® Monitor as compact as possible. Introducing a firewall and many other security applications would skyrocket the size and complexity of the firmware. Furthermore the CPU would not be able to handle both the communication with the remote host and the medical peripherals surrounding it. 5.2.3.1 Solutions One way of solving this problem would simply be to enhance the memory and improve the processor in the Serena® Monitor but this would also mean that the dialysis machine has to undergo a lengthy development phase to create the necessary resources for data communication and storage. The dialysis machine might even have to be recertified all over again and the certification process for medical appliances is no trivial matter. Even more concerning would be how that since the Serena® Monitor would be connected to the Internet the firewall and the antivirus software had to be certified as well. This solution was dismissed due to its major disadvantages. The second solution would be to introduce an intelligent router or gateway to handle the communication. The Serena® Monitor would then be left untouched and no recertification would be needed. The gateway would be connected to the Internet at one side and to the Serena® Monitor and the medical peripherals at the other. The disadvantages of this solution would be that another device was introduced to the setup and thus adding a degree of complexity, however this downfall was minuscule compared to those of the other solution. We then chose to introduce a gateway into the setup.


11

5.2.3.2 The gateway Once we had decided that we should use a gateway as a communications handler research began to find a gateway that was suitable in our context. Since the physical measurements of the gateway are highly important research was conducted in the field of solutions strictly limited in size. One solution would be to use a Mini-ITX another to run the Mac mini from Apple. Both these small computers can run Linux and serve as a gateway. Our research reviled an even more interesting solution, an on-chip Linux computer with built in Bluetooth functionality only measuring 65x65 mm. According to the suppliers specification the small Linux gateway had a complete plug and play Bluetooth module integrated on the board, which would match our requirements perfectly. The decision was made to proceed with the on-chip Linux computer as our gateway.

5.3 Requirements Initially we were presented with only a few general requirements for the planned system but as the project progressed we were able to derive the following requirements:

• Be able to survey the patient in his home. • Give information about the dialysis parameters. • Wireless information transfer to the Serena® Monitor. • Interaction with various peripherals. • Option to upload a new firmware. • Changes to the Serena® Monitor should be minor. • RS232 interface. • Conversion between RS232 and Bluetooth. • Small footprint. • Complete implementation of the Bluetooth stack. • Modularity in terms of appliance. • Commercial of the shelf components. • Highly configurable. • The Serena® Monitor may not be directly connected to the Internet. • Multiple options for connecting to a remote server. • Secure data transfer. • Ease of use for the patient. • Convenient appearance.

We were able to fulfill most of these requirements in our prototype but some, such as the security aspects, had to be omitted in order to complete the thesis within a reasonable timeframe.

5.4 Solutions After having browsed the market the conclusion was made that the majority of products that support the RS232 to Bluetooth conversion are unintelligent and are solely used as a serial cable replacement. Since this did not comply with our requirements these products had to be neglected. The research also showed that a vast quantity of the remaining products are based on proprietary software and cannot be


12

altered according to our desires. The only products left on the market were small Bluetooth modules intended as building blocks in another product. Since the intent is to extend the Serena® Monitor with Bluetooth support the modularity is suitable although it requires hands on hardware customization in order to operate as desired. We decided to engage in two different prototype solutions, one that simply adds Bluetooth support to the Serena® Monitor, and would additionally require some sort of router to connect to the clinic. This solution only solves half our problem since it would require further software implementation to handle external peripherals. The other prototype solution is an embedded Linux system, which can be extended in almost any desired way. The embedded approach also solves the router/gateway issue since it can be configured to act as one. External peripherals can also be handled in the Linux system. A Swedish retailer was chosen as provider of equipment for both solutions. The decision to choose a local retailer has many advantages, namely faster and cheaper deliveries, easier and more efficient access to active support. Furthermore it also shows that the components are widely available on the current electronics market. As we found out later, the Linux gateway we chose was not the optimal choice since it did not comply with the specifications that were given to us; it lacked a Bluetooth module and that caused us much trouble during our implementation.

6. Prototype construction This master thesis also aims at constructing a working prototype as a proof of concept. The prototype will be highly limited in terms of functionality in order to be constructed within the given timeframe. To simplify the construction of the prototype some security aspects has been omitted. Since the Serena® Monitor is a medical device the security requirements are quite rigid. All medical devices have to be rigorously tested, in terms of functionality and approved concerning electromagnetic fields. None of these issues will be dealt with in this master thesis.

6.1 Approach We decided to divide our work into small increments. By using this approach each step can be seen as a standalone milestone to continue building from. The approach also suites the format of a masters thesis since continuous progress reports must be delivered to the faculty. Gambro AB uses monitoring software called GXL to study vital parameters during an ongoing treatment. The communication between the Serena® Monitor and the PC that runs GXL is currently done via a serial link.


13

6.1.1 First increment The first increment is to provide Bluetooth communication between the Serena® Monitor and a PC by replacing the serial link. This increment is implemented when GXL is successfully run without the serial cable.

Figure2. Wireless communication between the Serena® Monitor and a computer using Bluetooth.


14

6.1.2 Second increment The second increment is to replace the Bluetooth module connected to the PC with the embedded Linux gateway. This is done by first connecting the embedded Linux gateway to the PC, and then wirelessly connect the Linux gateway to the Serena® Monitor. This step is considered done when treatment data from the Serena® Monitor can be successfully retrieved from the Linux gateway.

Figure3. Wireless communication between the Serena® Monitor and the Linux gateway using Bluetooth, wire bound communication between the gateway and the computer.


15

6.1.3 Third increment The third step is to replace the serial link between the PC and the Linux gateway with an Ethernet connection. This step is completed when Gambro’s external logging software (GXL) can be run, and the Serena® Monitor can be monitored real time via the Linux gateway to/from the PC.

Figure4. Wireless communication between the Serena® Monitor and the Linux gateway using Bluetooth, wire bound communication between the gateway and the compute using Ethernet technology.


16

6.1.4 Fourth increment The fourth increment is to communicate with medical peripherals such as blood pressure monitors and scales via Bluetooth. This communication should be between the Linux gateway and the peripherals.

Figure5. Wireless communication between the Serena® Monitor and the Linux gateway using Bluetooth, wire bound communication between the gateway and the compute using Ethernet technology. Blood pressure meter and scale wirelessly connected to the gateway using Bluetooth.

6.2 Implementation

6.2.1 First increment The first increment proved to be relatively easy and was completed successfully by connecting the Bluetooth evaluation boards to the serial ports of the Serena® Monitor and the computer. The communication was then established by using the wireless UART profile that was integrated in the Bluetooth evaluation boards. The communication was successful at low speeds (9600-19200Bps), but at more moderate speeds it proved to be somewhat unpredictable. We also concluded that it is highly important that the speed settings for the Bluetooth modules and the serial port settings in the computer/ Serena® Monitor coincide. When a dialup serial connection was accomplished in a satisfying manner we proceeded to implement the second part of this increment. The second part of the first increment was to run the GXL software with the serial cable replaced with a Bluetooth connection. Fortunately the GXL software had the default speed set to 9600kbs, which coincided with the fact that low speeds proved to be more stable when using a Bluetooth connection. What proved to be complicated in implementing


17

this second part was the communication between the Serena® Monitor and the Bluetooth evaluation board. The problem was that the Serena® Monitor has a Redel connector instead of the normal RS232 DB9, this in turn meant that we were forced to manufacture a suitable cable in order to connect the Serena® Monitor to the Bluetooth evaluation board. The manufacturing of such a cable proved to be quite the predicament since the pin layout was not obvious and that no description could be found. We overcame this problem by trial and error. Once the cable had been produced it was simply a matter of adjusting the speed in the Bluetooth modules to the default GXL communication speed (9600bps). When this was in order the communication was successfully established and GXL was wirelessly run over Bluetooth.

6.2.2 Second increment The second increment to be conquered was to replace the Bluetooth module connected to the PC with the embedded Linux gateway. This increment proved to a lot more challenging than anticipated at first. The quandary was in the communication between the Linux gateway and the computer. The intention was to connect the Linux gateway via a serial cable to the computer. First of all an experimental stripboard card with a proper RS232 DB9 pin out connector had to be produced in order to extract a serial port from the Linux gateway. When the card had been created it was simply a matter of connecting the serial cable between the computer and the experimental stripboard card to enable the communication. This was all in theory and as usual it proved to be more complicated than imagined.

Figure 6. The two experimental stripboard cards to extract the serial ports from the Linux gateway merged into one picture.

6.2.2.1 Communication issues We were able to transfer data between the Linux gateway and the computer but data sent was no were near equal to the received data. Since we formerly experienced nuisance in setting up a serial connection the conclusion was drawn that the underlying problem was the same as previously. The previous problem was that if the speed settings of the Bluetooth and the computer were not identical the communication would fail. After having double-checked the settings we were able to discard this hypothesis, however we were not able to locate the actual problem. After further investigation we could conclude that the Linux gateway operated within the voltage range -3,3V to +3,3V and the computer required the –12V to +12V range.


18

According to the RS232 standard voltages above 3V are interpreted as a logical zero and vice versa. The fact that the Linux gateway was able to produce only +3,3V resulted in the faulty communication. We now had two options:

• Fabricate a converter in order to broaden the voltage range of the Linux gateway to comply with the RS232 standard, –12V to +12V, used by the computer.

• Use the integrated Bluetooth functionality on the Linux Gateway. • Replace the serial link with the Bluetooth module since the module itself

operates within the same range as the Linux gateway. The natural and easiest solution to this problem seemed to be the usage of the onboard Bluetooth module on the Linux gateway. To our great surprise it turned out that the Bluetooth functionality on the Linux gateway had been removed since it was not certified, however the documentation was not updated and thus stating that the particular feature was still implemented, so unfortunately this was not an option. The converter appeared to be the more complicated and the aim for the future was to completely remove the serial link. The evaluation board already converts between these two ranges and it seemed impractical to both convert and reconvert. The choice was made to proceed with the third alternative. As usual it was not at simple as we thought. The pin connector that connected the Bluetooth module to the evaluation board was not a normal pin connector; this in turn meant that Gambro did not have it in stock. The connector was so minuscule that our attempt to build a primitive home made connector failed. The only option was to place an order, it turned out that only one retailer was available in Sweden. 6.2.2.2 Minuscule connector Once the minuscule connector was delivered to us the work proceeded to complete this second increment. The connector was integrated into one of our test cards in order for a Bluetooth module to be connected to a serial port on the Linux gateway. Since the Bluetooth module was equipped with Wireless UART functionality connecting it to the serial port was almost trivial. When working with serial interfaces one must always keep in mind that transmit is connected to receive on the other end of the wire and vice versa. When we were able to recollect this fact the second increment was successfully completed.

6.2.3 Third increment The third increment consists of replacing the serial link between the PC and the Linux gateway with an Ethernet connection. To be able to do this we had to implement a program that could repackage incoming Bluetooth data to Ethernet packages and vice versa. The programming environment available in our small Linux gateway was only able to handle C-code and therefore the program had to be implemented in C.


19

6.2.3.1 Routing software The program we created was pretty basic, it consisted of three threads; a main-thread that started the other threads, a thread that handled the Bluetooth communication and a thread that handled the Ethernet communication. Since data had to be transferred between the two threads we had to ensure mutual exclusion to the common resources. Our previous experience with C-programming was rather limited and we had never implemented multiple threads, therefore we had to browse through a lot of documentation to find the appropriate functions and methods to ensure mutual exclusion. Once we had implemented the program we wanted to validate the functionality by running GXL and since GXL did not support Ethernet connectivity for the Serena® Monitor we rerouted the incoming Ethernet data to the serial port on the computer running GXL. The communication seemed to work, but not fast enough, which caused the communication to be continuously interrupted. We therefore thought that the problem was that our implementation was to slow and that we had to optimise our program. Our first thought was that the buffers used for storing the transmission data were inefficient; therefore we optimised it by implementing ring buffers for the transferred data. Although the performance was notably higher, the problem persisted and we suspected that the problem might lie in the conversion between Ethernet and serial on the computer running GXL. 6.2.3.2 Modifications to GXL To eliminate this uncertainty we modified GXL to enable monitoring over Ethernet. The change in GXL was almost trivial to implement, but to make sure that the enhancements worked as anticipated was rather tricky. The predicament was that in order to run GXL via an Ethernet connection the entire set-up had to be tested at once thus eliminating the divide and conquer approach, which is most commonly used in debugging. The consequence being that it was highly difficult to prophesize where the actual error was when the set-up turned out to be malfunctioning. One conclusion that could be drawn was that the error could be reproduced i.e. the same error occurred at every attempt. 6.2.3.3 Debugging further By using a debug print function in the Serena® Monitor we were able to, on highly lose grounds, conclude that somewhere along the line the information intended for the Serena® Monitor seemed to be duplicated or echoed. In order to isolate the problem or the problems the components had to tested one at the time. We thus decided to rewrite the routing software that was currently run in our Linux gateway. The program was modified in such a way that it no longer routed from a serial port to an Ethernet connection but instead routed between two serial ports. The modifications enabled a new means of testing the system at hand. By connecting a regular PC on each of the two serial ports on the Linux gateway we should, in theory, be able create a serial connection between the two computers. The approach strengthened our suspicions that information somehow was duplicated or echoed by the Linux gateway. In order to be completely certain that the Linux gateway was the sole contributor to our problems we borrowed a professional router that had the required serial to Ethernet routing function. The aim of using this professional router was to ensure that


20

after our modifications GXL was working properly, this however was not completely the case. After a rapid debugging session and some minor changes we got the set-up with the professional router working. The subsequent increment was to replace the professional router with our Linux gateway, to no one’s surprise the problems experienced earlier still remained. We had however gained the valuable insight that the malfunctioning unit was our Linux gateway. At first we had thought that our problem was a performance problem but after a thorough investigation of the routing software we discovered that the serial port was opened in a faulty manner, which resulted in an echo. Once this trifle was handled our third goal was finally reached. GXL could be run over an Ethernet connection, and the Serena® Monitor wirelessly connected with Bluetooth to the Linux gateway.

6.2.4 Fourth increment In order to embark on the implementation of the fourth increment a new Bluetooth module had to be acquired from the supplier. The two previous modules had the SPP firmware, a module that is loaded with a SPP firmware is restricted in such a way that it can only create one connection. This connection has to be pre-defined, if one wishes to connect to another module one must disconnect and reconfigure with a dedicated software package. This fourth increment requires that Bluetooth connections can be set up between multiple modules. This necessitates another firmware, HCI, in the module. The Bluetooth stack has to be implemented in the Linux gateway and not in the firmware of the module. Fortunately there are multiple open source implementations available for Linux, so there was no need for any implementation on our part. The choice was rather trivial since the latest software release aimed for our Linux gateway included a Bluetooth stack called BlueZ. Further investigation into the field reviled BlueZ to be the paramount of open source Bluetooth stack implementations. The previously stated positive facts made our decision effortless, thus BlueZ was chosen as the preferred open source Bluetooth stack. 6.2.4.1 The HCI module In analogy with the Bluetooth standard a module flashed with HCI firmware was acquired from the same supplier as previously. The new HCI module was unfortunately delivered without documentation of any kind, the supplier website also lacked information regarding the module. Several discussions over the telephone concluded that their knowledge of the product was strictly limited. The fact that we could find no one else who seemed troubled by the given problem led us to believe that the usage of such a module was trivial. We decided to go ahead and load BlueZ onto our Linux gateway and connect the HCI module to a serial port. The installation of BlueZ libraries and packages onto the Linux gateway was straightforward, but the utilization was another matter. BlueZ provides plug-and-play support for most USB Bluetooth modules and the majority of Bluetooth products are connected via the USB port. We on the other hand had to connect our HCI module to the serial port of the Linux gateway, which became a problem since the documentation regarding the usage of a serial Bluetooth device with BlueZ is almost non-existent. When we could not get BlueZ to locate our Bluetooth module we contacted the supplier of the module and the Linux gateway in hopes of getting help


21

with our problem. Unfortunately they were unable to help us since the matter at hand was outside their area of expertise. 6.2.4.2 BlueZ debugging We realized that we had to many factors that could be the root of our problem, so we tried to isolate the problem by excluding possible sources of errors. We started with simplifying our environment by using a standard desktop distribution of Linux in VMware instead of our embedded version. BlueZ came bundled with this distribution but even now it could not find our Bluetooth module. Therefore we decided to use a USB module instead since BlueZ has greater support for these. When we plugged in the USB device into the computer we got a hint of what might be a problem; VMware warned that it does not support asynchronous data communication, so when BlueZ still did not find the module we decided to reinstall our Linux distribution directly on the host computer. When the installation was completed we plugged in the USB module into the computer and it immediately worked. We proceeded by trying our serial module but we were still unable to make it function as intended. Therefore we once again contacted the supplier of the module and asked for assistance. To our great surprise they were able to provide some useful information. It turned out that the HCI module, unlike the SPP modules, did not use flow control and that it used BCSP to communicate with the computer. After we altered our BlueZ configuration corresponding to our HCI module it finally worked. 6.2.4.3 BlueZ on the Linux gateway We then returned to our Linux gateway and tried the same procedure, but still got the same error message as we got initially. The error message was very cryptic and we were unable to understand what it meant, so we continued by browsing through the documentation for BlueZ, but found nothing of relevance. Subdued we proceeded with searching the web for an answer and found a mailing list for a system similar to our Linux gateway. Luckily there were users that had tried to use Bluetooth, with different levels of success. From this mailing list we could deduce that we got our error because we had no Bluetooth support in our Linux kernel. We were lucky enough to get in contact with one of the persons that had successfully implemented a Bluetooth solution on his system and he was kind enough to give us instructions on how to rebuild the kernel. After we followed the instructions we finally got the Bluetooth module to work on our Linux gateway, but somehow we had lost the library needed to run threaded programs. In order to get Bluetooth working we had used a new set of development tools for our platform and the library for threads was no longer included by default. The process of including the library was not as straightforward as we could have wished for, but after inquiries on the mailing list we understood the process and got it to work. Now we were able to simultaneously connect to multiple Bluetooth devices with our Linux gateway and our forth increment was completed.


22

7. Security This chapter aims to give a comprehensive overview of the security aspect regarding a home dialysis supervision system. The security can be divided into a number of key issues. These issues regard the threats they cover. The major security concerns in this system would be:

• Listening to the transmitted data • Alter the transmitted data • Direct attacks on the system

First of all one needs to divide the system at hand into two major areas of concern namely the local security at the site were the Serena® Monitor is located and remote security which handles the information exchange between the local site and the remote host. 7.1 On site local security The main security issues that are a concern on site are that someone listens to the data that is wirelessly transmitted via Bluetooth and that they might alter it. Luckily the Bluetooth specification has dealt with this security issue by offering an encryption of the transmitted data and a system called paring (see chapter on Bluetooth technology). The encryption of the transmitted data results in major difficulties for anyone who wishes to eavesdrop and/or alter the broadcasted information. On site one must also consider the physical security of the Linux gateway, it should not be possible without authentication to alter settings in the gateway, even if one is on site. The gateway also has to be encapsulated in a manner that rules out or minimises the risk of interference.

7.2 Remote and global security This aspect of the security is the one that poses the biggest threats since the system is accessible at a larger extent. One must be aware that thanks to the flexibility of the Linux gateway security can be added in many different layers. Adding security results in performance and accessibility losses. This is a compromise that has to be done. The first risk is that a virus or some kind of malevolent software is introduced on the Linux gateway, but since the system at hand is built upon an embedded Linux kernel the software has to be specifically engineered for the gateway to do damage to it. There are a number of measures that can be taken to minimize this already small threat. To enable a secure transfer of data one must encrypt the communication and use authentication of the involved participants. The encryption of the communications channel ensures that unwanted eavesdropping is avoided. The authentication makes certain that only desired parties are allowed to participate in the information exchange. A final and highly limiting, in terms of usability, step would be to set up the gateway only to contact its host and refuse any remote connection attempts. This would have the effect that the gateway could only contact others and not be contacted.


23

7.3 Security recommendations for medical usage When a computer system designed to work in a medical context security is of the highest importance. There are quite a few opinions on what accurate security means; some verges on paranoia while others are a little too ignorant. We will now attempt a recommendation on what would make the best compromise, according to our research, in this case.

7.3.1 On site communication To ensure the local security we would suggest that one takes advantage of the built in security in Bluetooth. Both encryption of the communication and authentication with pairing of the participants would be wise since it eliminates many local threats. Furthermore one must ensure that the electronics of the Linux gateway are encased to minimize the risk of someone tampering with them.

7.3.2 External communication The connection to the remote host also necessitates thorough security. A suggestion would be to use a standardized implementation such as SSL. This solution is currently being used in numerous home-banking solutions, which would vouch for adequate protection. SSL is one of the most wide spread security implementations when it comes to the protection of a point-to-point communication. The advantages of SSL are that it is highly configurable and agile in terms of security and that it is extensively documented thanks to its diverted usage. The fact that SSL is an open standard has resulted in open source implementations, which are free of charge.

8. Commercial products In order to complete the scope of this master thesis the commercially available product on the market has to be examined and investigated in terms of usability within this project. This chapter is devoted to such investigations and examinations. Our aim is to compare the solution, which we have implemented with the solutions available on the open market. We have as previously mentioned chosen a small Linux platform as a router for the medical information that is intended to be exchanged between the Serena® Monitor, different medical peripherals and a remote monitoring computer. The investigation conducted shows that the field of contestants is rather limited. The first commercial variations to the theme are the ones that are incorporated into a greater whole as a complete medical communications package where one is required to send the collected data to a certain clinic for analysis. Since these solutions were extremely restricted in terms of degrees of freedom, configurability and expandability they were promptly discarded. [The details of the products we investigated have been omitted due to a non disclosure agreement with the company in question.]


24

8.3 Concluding remarks The development of the Linux gateway has proved to be a very insightful task; Gambro has learned many vital things when it comes to the implementation of a home patient supervision system. The fact that the commercial market contains solutions that are somewhat similar to the one we have developed does not in any way cripple our master thesis. The aim was to investigate the workload and complications of such a system and construct a prototype. If we had chosen to go with a commercially available gateway we would have been forced to alter and enhance their product. This would probably have been more work and less educational since we only would enhance a commercial product.

9. Extensions and improvements The implemented solution is only a prototype and thus lacks a great deal of testing and security. The developed prototype is merely intended as a proof of concept so little effort has been put into usability. We have chosen to go ahead and implement only one of the many options when it comes to the remote communication. The Linux gateway currently communicates with the remote host via an Ethernet connection. In the future the gateway can easily be extended to communicate via for example:

• GPRS • GSM • UMTS/3G • WLAN • Common phone line

The GPRS and GSM communication are believed to be highly interesting when there is no on site Ethernet connection, while UMTS provides higher speed but a more limited coverage at the current time.

9.1 Medical peripherals In the fourth increment of our solution that can be studied above the aim is to enable communication with medical peripherals. This is only proven in theory and with non-medical equipment since no Bluetooth equipped medical instruments have been available. It must be stressed however that since the functionality has been implemented with other Bluetooth equipped peripherals the difference should be almost nonexistent. Our aspiration is to make a demonstration of our system with a Bluetooth enabled scale or blood pressure monitor but as of this date we have not been able to get a hold of neither.

9.2 Security The developed prototype lacks some of the security that is recommended in the security chapter above. The prototype that we have designed and implemented should be seen as a proof of concept and not a finished product; we have only laid the foundation.


25

10. Final Conclusions We set out to investigate the field of how to construct a home dialysis supervision system and to build a prototype as a proof of concept. Our primary research concluded that the Bluetooth technology was the most appealing in this case and that a gateway was needed to handle the communication. In the beginning we estimated that the major difficulties would be to get the wireless Bluetooth up and running. This proved in retrospect to be a miscalculation. The Linux gateway proved to be more difficult to operate than anticipated and thus the major part of our efforts were put into the gateway. The major difficulties were caused by the faulty specification, which stated that the gateway already had built in Bluetooth support. [Omitted]


26

11. References [1] Http://en.wikipedia.org, September – December 2005 [2] Http://www.gambro.com, December 2005 [3] [Omitted] [4] Brent A. Miller, C. Bisdikian, Bluetooth revealed, 2001 [5] Stephen Prata, Avancerad C, Pagina förlags AB, 1987 [6] Mitchell White, Stephen Prata, Donald Martin, Pagina förlags AB, 1987 [7] http://www.lammertbies.nl/comm/info/RS-232.html, September-November

2005 [8] http://www.wirelessfutures.co.uk, September 2005 [9] http://www.medic4all.com, September 2005 [10] http://www.telcomed.ie/products.html, September 2005 [11] http://www.andmedical.com/and_med.nsf/index, September – December 2005

Documents

Home dialysis supervision systemfileadmin.cs.lth.se/serg/old-serg-dok/docs-master... · patient at home. Serena® Monitor: The Serena® Monitor is a dialysis machine performing a