Compressing Medical Records for Storage on a Low-End Mobile Phone

Transcription

1 Honours Project Report Compressing Medical Records for Storage on a Low-End Mobile Phone Paul Brittan pbrittan@cs.uct.ac.za Supervised By: Sonia Berman, Gary Marsden & Anne Kayem Category Min Max Chosen 1 Requirement Analysis and Design Theoretical Analysis Experiment Design and Execution System Development and Implementation Results, Findings and Conclusion Aim Formulation and Background Work Quality of Report Writing and Presentation Adherence to Project Proposal and Quality of Deliverables Overall General Project Evaluation Total marks: Department of Computer Science University of Cape Town 2011 ~ i ~

2 Abstract In the rural and developing parts of Africa patients are often charged with keeping their own personal medical records due to the number of different doctors they need to visit. A solution was proposed where these patients could keep their medical records safe and secure on their mobile phone. This project aims to implement a system, where a patient can obtain their electronic medical record from a medical practitioner on their mobile phone. Once on the mobile phone the record is then compressed and encrypted for storage. This report goes into the details of the project that focuses on the compression and storage of the medical records; looking at the performance of different lossless data compression algorithms and storage options on a mobile device. This report looks into finding the most efficient way to compress the records giving the limited resources on the mobile phone. By implementing LZ77 and DEFLATE compression algorithms in an application on an android phone we were able to test each algorithms performance. This was done by monitoring how much of the mobile phone s resources (such as CPU and RAM) were used during execution. From the results of the performance tests it was clear that the DEFLATE algorithm, a fully optimized java import class, was the most efficient in compressing the medical records and thus will be used in the final implementation of the project. Acknowledgments I would like to thank my supervisors for all their input and guidance during the course of the project, giving special thanks to Sonia Berman for all the time she gave and the last minute feedback as well as to Gary Marsden who always had time to meet with me and point me in the right direction. Thanks to my friends and family who supported and encouraged me when I was feeling overwhelmed. Lastly, I would like to give a big thank you to my girlfriend, Sarah Palser, for believing in me and for all her encouragement. If we knew what it was we were doing, it would not be called research, would it? (Albert Einstein) ~ ii ~

3 Contents Abstract... ii Acknowledgments... ii List of Figures:... v Chapter Introduction: Research questions: Performance comparisons of compression algorithms Comparison of different storage techniques for the medical record Testing and Evaluation System overview The Key Success Factors Outline... 3 Chapter Background Electronic Medical Records Existing EMR systems in rural areas Organisational and user issues Data security and confidentiality Lossless Compression algorithms Lempel-Ziv Lempel-Ziv-Welch Prediction with Partial Match Burrows-Wheeler Transform Burrows-Wheeler Transform Evaluation of Algorithms... 8 Chapter Design Design Aims Design Constraints Design Process Medical Data System Architecture System Interface ~ iii ~

4 3.2.4 Algorithms Storage options Software and Hardware needed for implementation Design Summary Chapter Implementation: Main LZ LZW DEFLATE Performance Implementation summary Chapter Testing & Evaluation: Introduction Test Methodology Independent and dependant variables Testing Design Results CPU Usage Memory Usage Compression Ratios Evaluation of results Chapter Conclusion: Future Work References Appendices Appendix A Appendix B ~ iv ~

5 List of Figures Figure 1 - Diagram of separate components that were implemented by each group member... 2 Figure 2 - Example of LZW Compression... 7 Figure 3 - Results from Compression Ratio Test... 9 Figure 4 - Results from Static Memory Test... 9 Figure 5 - Results from Completion Time (Web) Tests... 9 Figure 6 - Results from Completion Time (Text) Tests... 9 Figure 7 - Application s Start Screen Figure 8 - Application s Main Menu Figure 9 - Layout of View Record Screen Figure 10 - Android Platform Distribution Figure 11 - Application s Class Hierarchy Figure 12 - LZ77 Compression Pseudo Code Figure 13 - LZ77 Decompression Pseudo Code Figure 14 - LZW Compression Pseudo Code Figure 15 - LZW Decompression Pseudo Code Figure 16 - CPU usage for LZ77 when compressing 1000kB file Figure 17 - CPU usage for DEFLATE when compressing 1000kB file Figure 18 - CPU usage for LZ77 when decompressing 1000kB file Figure 19 - CPU usage for DEFLATE when decompressing 1000kB file Figure 20 - Average Memory Usage for LZ77 compression Figure 21 - Average Memory Usage for DEFLATE compression Figure 22 - Average Memory Usage for LZ77 decompression Figure 23 - Average Memory Usage for DEFLATE decompression Figure 24 - Compression Ratios achieved with LZ Figure 25 - Compression Ratios achieved with DEFLATE Figure 26 - CPU usage for LZ77 when compressing 500kB file Figure 27 - CPU usage for LZ77 when decompressing 500kB file Figure 28 - CPU usage for LZ77 when compressing 800kB file Figure 29 - CPU usage for LZ77 when decompressing 800kB file Figure 30 - CPU usage for DEFLATE when compressing 500kB file Figure 31 - CPU usage for DEFLATE when decompressing 500kB file Figure 32 - CPU usage for DEFLATE when compressing 800kB file Figure 33 - CPU usage for DEFLATE when decompressing 800kB file ~ v ~

6 Chapter 1 Introduction The advancements in mobile technologies and mobile computing power have caused an increase in the popularity of mobile devices. Mobile devices are now being used for everyday tasks such as communication through s or instant messages and daily scheduling with the help of calendars. With this increase, usage of mobile devices has been broadening through industries such as Healthcare, Insurance and Field Services [1]. To keep up with all the data that needs to be stored on a mobile device or transferred quickly across a network, there needs to be a way to efficiently compress and decompress the data without losing the information. Lossless data compression is a set of data compression algorithms that allows the original data to be reconstructed from compressed data [2]. This project aims to investigate using lossless data compression for the storage of medical records on mobile phones. The original idea for this project was proposed by Simelela, an NGO dealing with rape victims, in which the aim was to aid these victims with revealing certain medical information when reporting their case, by storing their medical records on a mobile phone. Over and above this, patients in developing countries are often responsible for storing and transporting their own paperbased medical records, which can lead to the loss or damage of these documents. Therefore storing these records on a mobile phone will make the process more convenient for both patients and medical practitioners. This project involves designing and implementing an application that the patients can use to store and transfer their medical records between the necessary doctors and hospitals. The application consists of a number of different components such as a graphical user Interface, security in the form of encrypting the medical records and finally compressing the medical records for efficient storage on a mobile device. When developing applications for mobile phones, it is important to be aware of and deal with the restrictions on the capabilities of these devices [11]. In this paper the focus will be on compressing the medical records for storage on a mobile phone. This will be done by implementing various compression algorithms and comparing their performance when executed on a mobile phone. My partner Shelley Petzer [ will be focusing on the security component. She will be investigating a secure transfer medium for getting the records onto the mobile phone and encrypting the medical records once on the phone. 1.1 Research questions There are two key research questions that will be investigated in this document. The first is whether there is a difference in energy consumption while using different compression algorithms on a low end mobile phone. The second is to see if there is an improvement in storing the medical data on the phone s SIM card rather than the mircosd card Performance comparisons of compression algorithms Due to the limitations of a low end mobile phone, it is important to analyse the performance of the compression algorithms. This is firstly to assess whether it is plausible and secondly to find the most suitable choice for compressing a medical record on a mobile phone. This will involve the investigation of several algorithms in order to find an algorithm that reduces the storage space required by the mobile phone, whilst minimising the resources, such as CPU and memory, which it requires to execute. ~ 1 ~

7 1.1.2 Comparison of different storage techniques for the medical record For the medical records to be stored in internal memory, they will need to undergo a series of lossless data compressions. This will be done so that they can be stored within the limited storage space available on mobile phones. These compressions are computationally intensive and may exceed the processing power on standard mobile phones. Therefore research will be conducted to assess whether using internal memory is a feasible option. If internal memory storage is not successful, another approach will be to investigate storing the records on a mircosd card in the mobile phone. With the advances in mobile technology, the available memory on mircosd cards is sufficient for storing the records at a low cost. 1.2 Testing and Evaluation In order to test these hypotheses a system needs to be created that will allow for the most suitable compression algorithm to be found and to test which storage method is the most practical. The system will need to be able to run different compression algorithms and then store the compressed file in the appropriate place. To test the algorithms a series of performance tests were run at the same time as the implemented algorithm. The tests allowed for the monitoring of the dependant variables such as CPU, memory and execution time used by that algorithm while using different independent variables like buffer size, algorithm and file size. The result from these tests will then be analysed and converted into graphs for the easy evaluation of their performance relative to each other, so that a conclusion that answers the research questions can be drawn. 1.3 System overview The prototype will be designed to have two separate components. The first part deals with security and involves securing the transmissions between the medical database server and the mobile phone. This will also involve encrypting and decrypting the data on the mobile phone. This part of the project is highlighted in green in figure 1 and will be completed by my project partner. The second component involves compressing and decompressing the records on the mobile phone and then efficiently storing these records. This part of the project will be covered in this paper and is highlighted in blue in figure 1 below. The user Interface is not in the scope of this project and is left for future work (see section 6.1). The components are designed to be as separate as possible to allow for individual testing of each component and therefore linked only by the data that is passed between them. However, the components can easily be integrated together to form a complete application. Compression/Decompression and Storage Encryption/Decryption Figure 1 - Diagram of separate components that were implemented by each group member ~ 2 ~

8 1.4 The Key Success Factors The success of the project will be judged by the three components. Firstly, the ability to store the medical record on the mobile phone using the best possible medium of storage, whether it be using mircosd cards or the internal memory of a mobile phone. Secondly, to create a prototype that efficiently encrypts and compresses the medical records on the mobile phone within the limited resources available and finally, to secure the transmission between the medical database and the patient s mobile phone that is both efficient and cost effective. 1.5 Outline This document outlines the development and testing of different lossless compression algorithms on a mobile phone. It also contains the necessary sections for analysing the research. Chapter 2 outlines current research on electronic medical records, their advantages and disadvantages as well as giving some examples of electronic medical records in developing countries. It also provides background information on commonly known lossless data compression algorithms and a quick comparison of them. Chapter 3 covers the design plan for the application that was implemented. It gives details into the different aspects of the system and gives justification on the design choices. The different aspects include the medical data that was used to test the system, the system s architecture, the basic system interface and finally the software and hardware needed for implementation. The structure of the application that was implemented and the classes involved will be discussed in Chapter 4. Focusing on how the program works, the methods that were used and the data structures that were implemented in each class. Chapter 5 describes the testing process and how the results were obtained. Starting with the test methodology which explains how the algorithms were tested, the chapter then goes on to show the results and finally evaluating the results to form a conclusion. Finally Chapter 6 contains the overall findings and conclusions of this work as well as suggestions for future work. ~ 3 ~

9 Chapter 2 Background 2.1 Electronic Medical Records The growing use of electronic medical record (EMR) systems in Europe and the United States has been focused on the idea that this can help to improve the quality of health care. Decision support systems (DSS) are becoming important tools in reducing medical errors [12]. has become very important and commonly used in healthcare systems today, and access to medical data like online journals is also increasing. Even in developed nations, the development of EMR systems is still an uncertain and challenging assignment, calling for the corresponding of local needs to available technologies and resources. There is much less experience with creating EMR systems for the developing world. Requirements, priorities and local constraints are less understood and are more varied. Some environments in the developing world are similar to a European or US healthcare environment and therefore can use similar software but other environments have very limited resources [12]. It is highly unlikely, therefore, to find a single EMR architecture and implementation that will fit all environments and needs. A handful of projects in developing countries have now met the test of actual implementation in such settings and are in day-to-day use. Advantages of EMR systems [12]: Improvement in legibility of clinical notes Decision support for drug ordering, including allergy warnings and drug incompatibilities Reminders to prescribe drugs and administer vaccines Warnings for abnormal laboratory results Support for programme monitoring, including reporting outcomes, budgets and supplies Support for clinical research Management of chronic diseases such as diabetes, hypertension and heart failure Disadvantages in implementing EMR systems [12]: User problems: Lack of user training Poor initial design limiting capabilities and expansion potential Systems are difficult to use or too complex Lack of involvement of local staff in design and testing of systems Lack of systems and staff training to ensure data quality and completeness Lack of perceived benefit for users who collect the data Dependence on one individual champion Technical problems: Lack of back-up systems in event of computer loss Poor system security leading to viruses and spyware Unstable power supplies and lack of battery back-up Poor or inadequate data back-ups Lack of technical support staff and/or system difficult to maintain Existing EMR systems in rural areas AMRS, Kenya [13] Indiana University School of Medicine and Moi University School of Medicine have been collaborating for over 15 years. In February 2001, this collaboration led to the Mosoriot Medical Record System (MMRS). The MMRS was installed in a primary care healthcare centre in rural Kenya. ~ 4 ~

10 In November 2001, the MMRS software was adapted to support the AMPATH (Academic Model for the Prevention and Treatment of HIV/AIDS) project and renamed to AMRS. The system is designed to have two networked computers running Microsoft (MS) Access TM, powered by a UPS with solar battery back-up. For the AMPATH project, the network has expanded to seven networked computers linked to a single MS Access database. In the MMRS, patients are registered in the system upon arrival, travel through the clinic with a paper visit form, and present the visit form as they depart. Clerks then perform the registration and transcribe visit data. AMRS data are collected on paper forms at each visit, delivered to a central location for data entry, and then returned to the patient s paper chart. MMRS provides both patient registration and visit data collection functions. Data are collected on all patients seen in the medical clinic, including their laboratory results and medications. AMRS supports comprehensive HIV care as well as mother-to-child transmission prevention, while serving as a rich database for quality improvement and answering research questions. The growing AMRS and MMRS databases serve both clinical and research needs, generating clinical summary reports for providers and providing a centralised source of data for epidemiological research The HIV-EMR system, Haiti [14] Since 1999, Partners in Health (PIH) has run a community based HIV treatment programme in Haiti with its sister organisation Zanmi Lasante, expanding to seven public health clinics in an area with virtually no roads, electricity or telephone service. Based on the PIH EMR that was implemented in Peru, satellite-based internet access at each site supports and web communication. Open source web system backed by an Oracle database (the same as the PIH EMR) with an additional offline client for data entry and review. The system is bilingual with English and French. With data entry doctors enter case histories and medications directly, whereas technicians enter laboratory results and pharmacists enter stock records. History, physical examination, social circumstances and treatment are also recorded. Decision support tools provide allergy and drug interaction warnings, and generate warning s about low CD4 (cluster of differentiation 4) counts. An offline component of the EMR was developed to overcome unreliable internet communications in some sites. This allows data entry and case viewing when the network is down, and has proven to be reliable and popular with clinical staff. The HIV EMR shows the feasibility of implementing a medical record system in remote clinics in a remote area with virtually no infrastructure and limited technical expertise Careware, Uganda [15] A team at the US Department of Health and Human Services has developed a medical record system to support HIV treatment via the Careware system. The system is designed to have a stand-alone database built with MS Access. It provides comprehensive tools for tracking HIV patients and their treatment, including clinical assessment, medications and billing data. It is widely used in health centres and hospitals in the US, and has recently been internationalised and deployed in Uganda in October Careware is an example of a US-based stand-alone EMR that is being adapted to developing country environments. An internet-accessible version that is under development will allow local data entry offline Organisational and user issues Data quality and completeness are critical to the success of any information system. Achieving high standards is a particular challenge in sites with limited computer literacy and experience. It is important to design systems that are easy to use and have good instructions and training. The system should collect the minimum data necessary for the task, and data items should be structured and coded where possible to simplify data checking and optimise reuse [12]. This does not mean that free text must be excluded; doing so prevents the system from capturing any data that do not fit the normal pattern. Such data will either be lost or recorded in hard-to-locate paper records. Structured data such as laboratory test results might benefit from double entry. In some projects ~ 5 ~

11 physicians and other staff enter data directly. This has the advantage of avoiding transcription errors, and also allows order entry systems to be deployed to check for potential medical errors. A well-trained local data manager is fundamental in maintaining data quality [12]. Maintaining regular communication with users through a data manager and meetings can also prove to be important in maintaining data quality. Prompt and effective help to users is a vital factor in generating support and ensuring widespread use of an EMR system. Low literacy contributes to inconsistent spelling of patients names and addresses. Search tools can be used to match similar names and age, gender and address, and either merge the two records or the details to the users for advice. Use of patient ID cards has also been helpful in several projects in Africa. A WAN system can be valuable in enforcing a single unique identifier across sites Data security and confidentiality Views of medical data security and confidentiality vary in different developing countries. In some countries the use of electronic databases is treated with great suspicion, in other countries the staff think nothing of ing sensitive medical data. Patients can face serious risk if their communities discover their HIV status or other sensitive medical information [12]. It is imperative that healthcare providers protect this information using data encryption, which is key aspect of Shelley Petzer s component in this project. 2.2 Lossless Compression algorithms Lossless data compression and decompression algorithms can be efficiently implemented on a mobile device, even with the hardware limitations such as low processing power, static memory and battery life [1]. Lossless data compression has many advantages on a mobile device, such as reducing the network bandwidth required for data exchange, reducing the disk space required for storage and minimizing the main memory required [3]. This section describes four commonly used lossless compression algorithms used today. Lempel-Ziv 77(LZ77) and Lempel-Ziv-Welch (LZW) which use dictionary methods to reference the upcoming data in order to match the exact data that has already been encoded. Prediction with Partial Match (PPM) which is a statistical data compression algorithm based on context modelling and prediction [3] and Burrows-Wheeler Transform (BWT) which on its own does not reduces the size of the data, it only makes the data easier to compress [4]. These algorithms are then compared using benchmark tests to find which one is optimal for implementing on mobile devices Lempel-Ziv 77 The Lempel-Ziv 77 (LZ77) lossless compression algorithm is used as the foundation for compression tools, such as GZip [5]. The algorithm is asymmetric, with time and memory, because encoding is much more demanding than decoding. The LZ77 algorithm uses data structures like binary trees, suffix trees and hash tables which provide fast searching without the need for high memory [6]. LZ77 compresses data by replacing sections of the data with a reference to matching data that has already passed through both the encoder and decoder [3]. No searching is needed when decompressing the data because, the compressor has issued an explicit stream of literals, locations, and match lengths [7]. The process becomes even more efficient if the window is stored entirely in the cache, so that retrieving a match is fast no matter where it occurs in the window [7]. The LZ77 algorithm works by maintaining a current pointer into the input data, a search and a look-ahead buffer. Symbols that are found before the current symbol make up the search buffer, whereas symbols that appear after the current symbol are placed in the look-ahead buffer. The buffers make a window which shows the section of input currently being viewed. As the current pointer moves forward the window moves through the input. While symbols are found in the look-ahead buffer, the algorithm looks in the search buffer for the longest match [7]. Instead of send off of the matched symbols, they are encoded with the offset from the current pointer, the size of match and the symbol in the look-ahead buffer that is following the match. The encoder and decoder must both keep track of the last 2KB or 4KB of the most recent data. The encoder needs to keep this data to ~ 6 ~

12 look for matches, while the decoder needs to keep it to understand the matches the encoder refers to. The LZ77 provides option to increase the window to improve performance. With a larger window there are improvements in the speed in which matches are found but to the cost of memory Lempel-Ziv-Welch The Lempel-Ziv-Welch (LZW) algorithm was introduced for cases in which a match cannot be found using LZ77. Instead of the sliding buffers, LZW uses a separate dictionary which is used as a codebook [8]. From the input stream the compressor builds its dictionary from the input data. When a group of symbols is found the dictionary is then checked. The longest prefix that matches the input is encoded and the unmatched symbol which follow are then added to the dictionary, see Figure 2 below for an example of LZW compression. The decompressor will then build a dictionary so that it can receive the indices that refer to the same symbol that are in the compressor s dictionary. Input Stream: AAAABAAABCC Encoded String Output Stream New Dictionary Entry A AA AA AAA A AB B BA AAA AAAB B BC C CC C Figure 2 - Example of LZW Compression This algorithm provides a quick build up of long patterns that can be stored, but there are multiple downfalls. Until the dictionary is filled with large commonly seen patterns, the resulting output will be bigger than the original input. Since the dictionary can grow without bound, LZW must be implemented so it deletes the existing dictionary when it gets too big or finds a way to limit memory usage [7]. This algorithm has no communication overhead and is computationally simple. Since both the compressor and the decompressor have the initial dictionary, and all new entries into the dictionary are created based on entries in the dictionary that already exists, the decompressor can recreate the dictionary quickly as data is received. To decode a dictionary entry the decoder must have received all previous entries in the block [5] Prediction with Partial Match Prediction with Partial Match (PPM) is a changing statistical data compression algorithm that uses context modelling and prediction [9]. It uses a fixed context statistical modelling algorithm, which predicts the next character in the input data. The prediction probabilities for each preceding character in the model are calculated from frequency counts which are updated regularly. The symbol that occurs is encoded in relation to its predicted probability, using arithmetic coding. Although PPM is simple, it is also computationally intensive [3]. An arithmetic encoder can use the probabilities to code the input efficiently. Longer contexts will improve the probability, but will take more time to calculate. To deal with this, escape symbols are created to slowly reduce context lengths. This creates a downfall were encoding a large string of escape symbols can use up more space, which would of been saved by the use of large contexts. Storing and searching through each context is the reason for the large memory usage of PPM algorithm [7]. With the PPM algorithm a table is built for each order, from 0 to the highest order of the model. After parsing the input into substrings, the context for each substring is the characters that come before the sub-string. The table keeps count of the frequency of each substring that has been found for the given context [10]. ~ 7 ~

13 When the PPM algorithm is used, it searches the highest-order table for the given context. If the context is found, the next character with the highest frequency count is returned as the prediction. If there are no matches to any entries in the table, the context is reduced by one character and the next lowest-order table is searched. This process is repeated until the context is matched or the Zeroth-order table is reached. The Zeroth-order table simply returns the most common character seen in the training string [10] Burrows-Wheeler Transform The Burrows-Wheeler Transform (BWT) is a reversible algorithm that is used in the bzip2 compression algorithm [4]. On its own, BWT does not reduce the size of the data, it only formats the data so it becomes easier to compress by other algorithms. When a string of characters is transformed using the BWT the size of the characters remain the same, the algorithm just calculates the order that the characters appear in. If the input string has multiple substrings that have a high frequency of appearing, then the transformed string will have multiple locations in which a character will recur several times in a row. This helps with compression, since most compression algorithms are more effective when the input contains sets of repeated characters. After the BWT is completed, the data is then compressed by running the transformed input through a Move-to-Front encoder and then a run-length encoder. The BWT takes advantage of symbols which are located further on in the string, not just those that have passed. The biggest problem is that the BWT requires the allocation of RAM for the entire input and output streams and a large buffer is needed to perform the required sorts [5]. Even though BWT-based compression could be performed with very little memory, common set-ups use fast sort algorithms and data structures that need large amounts of memory to supply speed [7]. Regardless of memory issues, algorithms that implement the BWT compress files at a high compression ratio Burrows-Wheeler Transform The Burrows-Wheeler Transform (BWT) is a reversible algorithm that is used in the bzip2 compression algorithm [4]. On its own, BWT does not reduce the size of the data, it only formats the data so it becomes easier to compress by other algorithms. When a string of characters is transformed using BWT the size of the characters remain the same, the algorithm just calculates the order that the characters appear in. If the input string has multiple substrings that have a high frequency of appearing, then the transformed string will have multiple locations in which a character will recur several times in a row. This helps with compression, since most compression algorithms are more effective when the input contains sets of repeated characters. After the BWT is completed, the data is then compressed by running the transformed input through a Move-to-Front encoder and then a run-length encoder. BWT takes advantage of symbols which are located further on in the string, not just those that have passed. The biggest problem is that the BWT requires the allocation of RAM for the entire input and output streams and a large buffer is needed to perform the required sorts [5]. Even though BWT-based compression could be performed with very little memory, common set-ups use fast sort algorithms and data structures that need large amounts of memory to supply speed [7]. Regardless of memory issues, algorithms that implement BWT compress files at a high compression ratio. 2.3 Evaluation of Algorithms Four comparison tests were run on tools that implement the algorithms [7]. LZO and Zlib were used to test the Lempel-Ziv 77 (LZ77) algorithm, Compress was selected to test the Lempel-Ziv-Welch (LZW) algorithm, PPMd (also known as winrar) was used to test t Prediction with Partial Match (PPM) algorithm and finally bzip2 was chosen to test the Burrows Wheeler Transform (BWT) algorithm. When benchmark comparison using traditional metrics are run on the above tools, the follow graphs are produced. ~ 8 ~

14 Figure 4 - Results from Compression Ratio Test Figure 3 - Results from Static Memory Test Figure 6 - Results from Completion Time (Web) Tests Figure 5 - Results from Completion Time (Text) Tests Analysing the graphs produced by benchmark tests shows that the algorithm that gives the best compression ratios is PPM followed by BWT. These ratios, however, come at a great cost to both time and memory, and these are resources that are not in abundance on mobile devices. The fastest of the four algorithms in both text and web is LZO, which uses the (LZ77) algorithm. Even though LZO is quick and uses the least static memory, it does provide the worst compression ratio when compressing and decompressing text. From these results, the LZ77 algorithm was chosen to be the algorithm that was implemented. Based on a design similiar to LZO, a lossless data compression/decompression application for a mobile device is being designed that is quick, requires low processing power and memory. These three attributes will also help preserve the battery life of the mobile device by not requiring a large amount of time and processing power to complete. Although LZO has a weak text compression ratio, it does provide a good web compression, which will help in compressing XML formatted files and if the user needs to download and update alot of data across the network. ~ 9 ~

15 Chapter 3 Design 3.1 Design Aims As discussed in the Chapter 1 the aim of this project is to investigate whether a medical record can be securely and effectively stored on a mobile device. That is, can a mobile device with its limited specifications handle complex compression and encryption algorithms? The implementation of the proposed design is an integrated system, which allows for a medical record to be securely transferred from a central database on a computer to the mobile device. Once on the device the system will then compress and encrypt the record for safe storage. This is to allow medical patients to keep their own medical records safe and be able to easily transfer the electronic record between doctors. Measuring the effectiveness of this system in terms of how well it handles the algorithms, will answer the research question previously stated. This means that the experimental design is important in achieving the project aims. To this end, a system was designed such that a set of tests could be run and results evaluated. The test process that will be run on the implemented system is described in detail in Chapter 5.2 of this report Design Constraints The system that is being designed needs to consider the limited resources that are available on a mobile device, as well as the location for which the application is being designed. Since the application is being designed for a rural or developing area with a low income rate, the application needs to run on a simple, inexpensive phone. The people who will be using the application will not have the highest technological literacy so the application needs to be user friendly and easy to use. Therefore the main design goals for the system are that it needs to be quick, able to compress large data files and have a simple easy to use interface all within the small about of CPU and memory that is available. 3.2 Design Process Before a testable system can be implemented it needs to go through a design process, so that we know exactly what needs to be implemented and how it will all fit together. The process, through which the design of the system was constructed, consisted of the analysis of mhealth and openmrs medical systems already in place as well as others that were discussed in chapter 2. As well as meeting with Cell-Life which is a company that aims to improve the lives of people infected and affected by HIV in South Africa through the appropriate use of mobile technology. The different aspects of the system will be discussed in this section, which also justifies the choices that we made while designing the system Medical Data Before designing the system we needed to know exactly what the input for the system would be. To avoid the process of acquiring ethical clearance and trying to get sensitive information from real patients, we decided to use pseudo medical records. These pseudo medical records are created by piecing together parts from other anonymised medical records. They provide the data that we need without compromising the privacy of a patient. The first attempts at getting pseudo medical records came from openmrs. Seeing as openmrs is already an established medical service, the records that they have would have provided us with data that is in a standard medical format and provided good data to test out system. However the medical records were contained in a mysql database and could only be accessed with the openmrs web service. After downloading the web service we found that it requires a lot of coding with java ~ 10 ~

16 jdbc to extract specific elements from the database. This attempt was proven to be fruitless since we needed a large data file such as personal history to test our system, whereas openmrs only provided small details on request. After the first attempt was unsuccessful we then set up a meeting with Sarah Brown [sarah@celllife.org] and Simon Kelly [simon@cell-life.org] from Cell-Life to try get a better understanding of what is needed in a medical record and to see if they knew of any pseudo medical records that we could use for this project. Cell-Life is a non-profit organisation that provides technology-based solutions for the management of HIV and AIDS and other infectious diseases such as TB. Cell-Life's primary function is to address health-related logistical challenges in developing countries, such as the provision and distribution of anti-retroviral treatments, continuous patient monitoring and evaluation, and collection and communication of relevant data. This is achieved through the use and development of software supported by existing technologies such as mobile phones and the Internet. Cell-Life has had a lot of experience working with medical records on mobile devices since they have been running since Sarah informed us that the key data elements that a medical record must have are basic personal identifiers. These key elements include: Patient folder ID, Date of birth, gender, first and last names. This data is essential because using those key items the Doctor/Nurse can identify the patient and retrieve the needed data. She also stated that the most import data to keep would be medical history as well as blood results. The reason for this is that the doctor can easily see from the history and blood results what is wrong with the patient and what the patient has been treated for. Simon who is a developer for Cell-Life informed us that using XML format would be to our advantage. Since XML is the best format for transferring medical records between the computer and mobile device and with the tags in XML, it would be easy to search through and store the different section of the record. Both Cell-Life developers had concerns about storing the medical records on the limited space of a SIM card. Due the fact that the more information stored helps the doctors with their diagnostics, combine with the fact that in developing countries a lot of households would share one phone, there needed to be a way to securely store multiple records on the phone. From the information obtained from Cell-Life we were able to find Records For Living. Records for living are an online service that provides the user with the ability to create and store Personal Health Records securely online. Personal Health Records (PHR) is an online copy of the user s medical information, collected from all of the user s doctors and hospitals. The PHR is also customisable to allow other information to be added that doctors are usually unaware of such as dietary habits, patient s symptoms and reactions to medications. To keep patients confidentiality we would not be using real medical records, but rather samples that are provided on the site. We obtained two samples records from Records For Living a 500kb, 800kb and with that we artificially generated a 1mb record by adding in extra data to the fields. The reason for obtaining different size files is to see how our system works with bigger input data System Architecture As described in section 1.3 of the Introduction chapter the system is divided into two projects that are integrated to form the complete system. The first project was designed and implemented by Shelley Petzer and deals with security components. This involves finding a secure way to transfer the medical record from the computer to the mobile device via Bluetooth. The reason for using Bluetooth is that it doesn t cost anything to transfer the data across this medium unlike 3G or GPRS. Bluetooth was also chosen for the fact that nearly all low range phones come standard with Bluetooth. Shelley s project will also look into encrypting the medical records on the computer and mobile phone using different encryption algorithms. The second part of the project which will be discussed in this paper deals with the compression and storage components. Once the medical record has been transferred to the phone the system will compress the medical records using ~ 11 ~

17 different compression algorithms. The algorithms that were chosen for this system where based on the results found in 2.3 of the background chapter, this is discussed in more detail in section Another component to this project is storage on the mobile devices either on the SIM, SD card or on the devices internal memory. The design for this component is discussed in more detail in section The way the two projects will be integrated is by the data that is passed between the two projects. The system is designed so that the medical record comes from the medical professional s computer in XML format, it will then be encrypted in to a byte array and transferred on to the mobile device. On the mobile device the byte array is decrypted back to XML for compression. The reason for the decryption once on the mobile device is that the record can then be verified with the digital signature, this allows for us to check that the record was sent correctly. The XML is then pasted to the compression section in which it is compressed into a zip format. The zipped file is then passed to Shelley s encryption class which encrypts the zipped file for storage using a different key. The system is also designed so that encrypted medical records stored on the phone can be decompressed and decrypted back on to the computer System Interface The first concept of the project involve creating a system where a users can use a mobile device to view and securely store their medical records and if need be send them to another device. So an interface was designed to allow the user to easily navigate through the medical record as well as send off the necessary data. Figure 7 - Application s Start Screen Figure 8 - Application s Main Menu ~ 12 ~

18 The diagrams above show first concept design to the interface menus. The start screen Figure 7 gives the user the ability to login in to their account. This is to deal with the issue that more than one family member will use the mobile phone. Once logged in the user can choose to view their record or send and receive a record to a doctor. Figure 9 - Layout of View Record Screen Figure 9 above shows the layout when the user is viewing the record. Since mobile devices have small screens the information needs to be displayed as big as possible. To navigate the different sections of the medical records buttons are placed at the bottom of the screen. The user can then horizontally scroll through the buttons until they find their desired selection. However since this project is an experimental project to test the different algorithms on a mobile device, the user interface design was outside the scope of this work. Since we will have no user testing and only need an interface to run and test the various algorithms, a simple interface was designed. This basic interface that would need to be implemented to satisfy our goals would contain one main screen and a six buttons, which would allow us to compress and decompress a medical record using different algorithms. The plan to make this system into a working product for users is still in the pipeline and based on the result of this project will be discussed in section future work. ~ 13 ~

19 3.2.4 Algorithms The algorithms that were chosen to be implemented in this project were based on the results from the evaluation that was done in 2.3 of the background chapter. Since the project is being developed for low ranged phones we ll be using the dictionary compression algorithms to test compression on a mobile device. Even though the dictionary algorithms LZ77 and LZW did give the worst compression ratios, they did run faster than the other algorithms by at least three seconds while using the least amount of static memory as seen in Figure 2.3 in chapter 2. These properties of these algorithms are beneficial since there are limited resources on the phone and we want to make sure that the system does not kill the battery from being too resource heavy. The algorithms implemented in this project are LZ77, LWZ and DEFLATE. LZ77 & LZW are commonly known lossless data compression algorithms that were discussed in the background chapter. DEFLATE was chosen to be implemented since this algorithm is newer and uses a combination of LZ77 and Huffman coding to achieve compression. Huffman coding uses a specific method for choosing the representation for each symbol, resulting in a code, sometimes called prefix-free codes, that is, the bit string representing some particular symbol is never a prefix of the bit string representing any other symbol. The prefix code expresses the most common source symbols using shorter strings of bits than are used for less common source symbols. Huffman was able to design the most efficient compression method of this type: no other mapping of individual source symbols to unique strings of bits will produce a smaller average output size when the actual symbol frequencies agree with those used to create the code. DEFLATE is a good algorithm to test because using Huffman coding on top of LZ77 should yield better compression ratios, and will also tell us how this will affect the performances on the mobile device Storage options Medical records and other personal information need to be stored within the limited resources of mobile device. For the system we needed to find a way to store the data in such a way that it is easy to access but also provide the necessary security for the sensitive information. The options that we came across in our research were the phones internal memory, the SIM card and the SD card. At first we thought that ideally the records should be stored on the internal memory of the mobile device. This way the record can t be transferred from one phone to another without the user s knowledge and can only be accessed by someone with the correct permission. The downside to this option and the reason that we didn t go with internal memory is that it only works it the mobile device is on or in a working condition. If the mobile devices battery dies there is no way to access or get the data off the phone until it is charged, as well as if the phone breaks that information could be lost. As a result we then looked into card options. The SIM card provides a good solution since it not removed or swapped around as often as the SD card. A Meeting was arranged with Hugo Roux an employee of Clickatell that has experience working with SIM cards. He informed us that although there is a lot of security on the SIM cards the data is hard to access due to the fact that there are multiple service providers and each of them uses different ways to encode the data on their SIM cards. It then becomes difficult to create software that can handle all forms of encoding that are used. The service providers are also very strict when it comes to accessing the SIM card and only allow for about 10kb of data to be stored. This makes SIM cards not a viable option since we will be storing files that are going to be bigger than 100kb. So the option that we will implement in the system is storing the medical records on the SD card. This provides an easy way of storing the data and if the phone battery dies or the phone breaks the SD card can be removed and the user can still have access to their medical record. It also provides another way of transferring the medical record to the doctor in case Bluetooth is not operational in that area. The only concern we had with using SD cards is that in developing areas SD cards are often ~ 14 ~

20 swapped to share files like photos and music. This means that sensitive information could be accidentally leaked if all the contents of the card were copied to another. We have solved this problem with Shelley s encryption, so even if someone gets access to the encrypted file it can only be read by our system and that users pin Software and Hardware needed for implementation The system will be implemented on a mid-tier mobile phone. This type of device was selected for the reason that the application is designed to mainly be deployed in developing areas where there is a low income rate. These devices are affordable and provide the needed specifications to run the complex encryption and compression algorithms that are necessary Hardware The phone that was going to be used for the first implementation of the system was a Samsung E250. The Samsung E250 mobile was introduced in 2006 as an entry level version of the Samsung D900, it had similar features but at a lower cost. This phone was chosen because it has good performance powered by an ARM9@230MHz processor, 10MB internal memory and has support for SD cards. The Samsung E250 also came with Bluetooth 2.0 with stereo A2DP and was affordable selling at around R350. While still in the process of setting up the Samsung E250 for development, we learnt of a new entry-level android smart phone that was being sold for $100 (around R700) the IDEOS. The Huawei U8150 IDEOS runs Android 2.2 and is powered by a 528MHz processor with256mb RAM. It features a 2.8" touch screen, Bluetooth 2.1 and has a microsdhc card slot. With the knowledge of this new smart phone being released we decided to change our target phone to the IDEOS. The reason for this is that although the IDEOS does cost more, the trend is moving towards smart phones being released at very low prices making then much more affordable. This means that entry-level phones with good performance will be released and replace the mid-tier phones of today, so looking to develop for the future we made the switch Software For programming the application on the Samsung E250 we planned to use Java ME. Java ME is a Java platform designed for embedded systems, such as mobile devices. Java ME was designed by Sun Microsystems, which is now a subsidiary of Oracle Corporation. The platform replaced a similar technology PersonalJava. Java ME devices implement a profile. The most common of these are the Mobile Information Device Profile aimed at mobile devices. Profiles are subsets of configurations, of which there are currently two: the Connected Limited Device Configuration (CLDC) and the Connected Device Configuration (CDC). The Connected Limited Device Configuration (CLDC) contains a strict subset of the Java-class libraries, and is the minimum amount needed for a Java virtual machine to operate. CLDC is basically used for classifying myriad devices into a fixed configuration. A configuration provides the most basic set of libraries and virtualmachine features that must be present in each implementation of a J2ME environment. Designed for mobile phones, the Mobile Information Device Profile includes a GUI, and a data storage AP. Applications written for this profile are called MIDlets. Almost all new mobile phones come with a MIDP implementation. The IDEOS runs Android 2.2, Android is a software framework for mobile devices, developed by The Open Handset Alliance, and released by Google. It consists of an operating system, certain applications, as well as a Software Development Kit (SDK). The core of the Android OS is based on a Linux kernel. The SDK allows Android developers to develop Android applications using the Java programming language. Android is an Open Source platform, and hence allows anyone to develop Android applications for Android devices. Moreover, since Android is based on a Linux kernel, it supports the running of Linux binaries and scripts. Java ME and Android were chosen because they ~ 15 ~