A Security Oriented Design (SOD) Framework for eHealth Systems

A Security Oriented Design (SOD) Framework for eHealth Systems

Weider D. Yu Lavanya Davuluri Monica Radhakrishnan Maryam Runiassy

Department of Computer Engineering, San Jose State University San Jose (Silicon Valley), California 95192-0180, USA

[email protected]

Abstract— With the advancement in technology and availability of internet access and smart mobile systems, there has been an increasing interest in eHealth related research activities due to the attractive and important benefits that eHealth systems can offer to many. However, the security of the eHealth systems has been a great concern. In this paper, we discuss the pilot design experience and results of a security oriented design framework (SOD). The SOD framework is intended for providing a system development environment template to strengthen development tasks of eHealth related systems. We have selected two major eHealth commonly required features for the pilot experiments. The first feature is to provide capabilities for storing and accessing digitized patient health records. The second feature is to provide scheduling and management in terms of appointments, doctor prescriptions, tests, etc. The paper also discusses the current major concerns in security and privacy and provides some effective security solutions. Keywords— — eHealth, Electronic health records (EHR), Android, security, privacy, cloud.

I. INTRODUCTION

In today’s world, eHealth focuses on providing healthcare in digital records and methods such as Electronic Health Records (EHR) [4], [7]. With security being a major concern in today’s era, our security oriented design framework (SOD) is engineered to meet the needs of eHealth systems. The SOD framework is intended for providing a system development environment template to strengthen development tasks of eHealth related systems. Today’s eHealth systems need to deal with a new and different level of patient-doctor interactions and they pose new kinds of challenges and threats to security and privacy [6]. With increasing number of eHealth systems are being built on mobile, web and cloud platforms, providing effective security and privacy has become a major concern. The SOD framework is particularly designed to focus on the healthcare of elderly people with the emphasis on ease of use. Although there has been substantial improvement in the field of geriatrics, much more remains to be done to meet the needs of the aging population Americans [1].

With the development of this framework, patients can view their records online via web and mobile client devices, without having to visit the hospital each time [2]. The SOD framework mentioned will facilitate scheduling appointments and management of patient data, such as prescriptions, tests, and visiting records. After the implementation of security and privacy using this SOD framework, the eHealth system to be developed will have capabilities in patient’s data confidentiality and privacy along with the overall enhanced quality of healthcare. Patients are able to monitor their specific health needs without compromising the security and privacy of their personal healthcare related data.

II. DESIGN FRAMEWORK SYSTEM ARCHITECTURE

The architecture of the security oriented design framework SOD for eHealth is a three-tiered system: client tier, middle tier and data tier. The main web server and the database server reside in the cloud providing a seamless integration with both web based (workstations, laptops) and mobile based (smartphones, iPads) clients. The three-tiered system architecture follows the layout of presentation layer, business layer and data access layer. The SOD framework architecture diagram is shown in Figure 1.

Fig.1 eHealth Framework Architecture

2014 IEEE 38th Annual International Computers, Software and Applications Conference Workshops

978-1-4799-3578-9/14 $31.00 © 2014 IEEE

DOI 10.1109/COMPSACW.2014.132

122

A. Client-tier

The client tier is designed to have both web and mobile clients [2]. The tier consists of the presentation layer that is the graphical user interface (GUI) component for web and mobile clients.

Web Client: The web client is designed using the Java technology. The users of the web based access to the eHealth system are patients as the end users and doctors and pharmacists as the healthcare providers.

Mobile Client: The mobile client is designed based on the Android mobile software technology platform and caters to the needs of the patients as end users to use the system on the go. Simple Object Access Protocol (SOAP) web services act as the interface between the mobile clients and the eHealth system server hosted on the cloud.

B. Middle-tier

The middle-tier mainly consists of the web server, in this case the Apache Tomcat server where the design framework is hosted. This web server takes HTTP requests from both web and mobile clients, and provides responses to them. Web services are used to interface between the clients and the server. C. Data-tier

The data-tier consists of the database server and the databases which store the hospital and patient data records. In the SOD framework we have both MySQL server and a NoSQL server (which is MongoDB). The database servers are also on the cloud.

Fig. 2 SOD Framework Subsystems

for Web Client Architecture

Web Client GUI: The web client GUI includes all the controls which enable the users of the eHealth system to perform their intended application tasks. The intended users of this system are patients. On the medical staff side, the users include doctors, nurses and pharmacists. The user interfaces for both patients and medical staff categories are different, based on the functionalities which the users are authorized to access.

EHR Management: EHR management is the subsystem which authorizes the users to create, access their digital patient records for updating, based on their editing permissions.

HIS Management: Health Information Systems

(HIS) management enables patients to perform the basic functionalities of an eHealth application. Some of these include: scheduling, viewing, changing and canceling appointments; managing patient prescriptions, and viewing lab results.

Security: This is the most important subsystem as this design framework is particularly designed with an emphasis on security [9-11]. This subsystem includes a variety of security mechanisms like authentication, authorization, and encryption. Because patient confidential data is stored in a public cloud, data storage security is also considered and included.

Network Connectivity: This includes the

communication connectivity protocols like HTTP and web services.

III. IMPLEMENTATION

A. Web Client Implementation

The major implementation of security for the SOD framework is in the middle-tier. Encryption and authentication algorithms are written as servlets and web services which run on the web server. In addition, strict constraints on which users are allowed to access what functionality is also defined and engineered in the servlets program code. Session management, automatic session logout after a given amount of “no activity” on the screen is implemented on the web server. In addition, the middle-tier of the design framework includes the business and data access objects where the main logic of the eHealth system’s functionality, handling requests from the web and mobile clients, providing responses and accessing the database are provided in this tier.

123

In the database tier, we make use of both relational (MySQL) and non-relational databases (MongoDB). MySQL is used for most of the database tables, and MongoDB is a NoSQL database used for storing semi-structured data like patient test results, which do not have a fixed structural format, and the NoSQL database contain image files. In NoSQL database, data is stored as collections and documents which are in the format of JavaScript Object Notation (JSON) key:value pairs. B. Mobile Client Implementation The mobile client is designed based on the Android software technology platform on which the end users can access details, such as medical records and prescriptions. The mobile clients of the SOD design framework have the following functionality:

Patients can login with passwords to their secured accounts.

Patients can view their health records. Patients can check their appointments. Patients can check available medical locations

for appointments.

C. Middle- tier Implementation

The middle-tier consists of servlets. Servlets are implemented using Servlets technology. Servlets are a special type of a Java program that runs within a web server like Tomcat or Jetty [3]. Jetty provides an HTTP server and servlet container capable of serving static and dynamic content either from a standalone or embedded instantiations. Servlets also define get and post methods that all servlets implement to perform redirection and some specified actions. Servlets are small programs running within a web server. They receive and respond to requests from within web clients, and they are usually across HTTP protocols. For our SOD design framework we use a HTTP servlet that extends the javax.servlet.http.HttpServlet. The lifecycle of a servlet defines methods to initialize a servlet and to remove a servlet from the server.

The servlet is constructed and initialized with the init method.

The client calls to the service methods to be handled.

The Destroy method destroys the servlets which will then be cleaned via garbage collection features by JVM.

The servlet classes are all in one package and the JSP (JavaServer Pages) pages talk to the servlet classes by calling the form action method and this in turn communicates with the data from database. D. Data tier Implementation All the data tables for the design framework are stored in relational and non-relational databases. The MongoDB database is used for storing the test results collection and all other tables are stored in MySQL database. Tables are created with the necessary primary keys, foreign keys and not null constraints.

IV. SECURITY DESIGN FRAMEWORK

In the SOD framework, we particularly designed and embedded a special security design sub-framework (shown in Fig. 3) providing the capability of designing security functions [12] to system designers.

Fig.3 SOD Security Framework

The security design sub-framework handles all the security components shown in Fig. 3. Other functional components are built around it. In general a complete eHealth system application [4] can be viewed as an integration of all the components and the UI interfaces shown in Fig. 3. The major security components of the security design sub-framework are described below: A. Security Component – Password Protection

For patient password protection purpose, the storage of patient passwords is implemented by SHA1 hashing algorithm. But storing only hashed password is not secure enough from attacks because identical passwords can have the same hash generated. So a variable ‘salt’ is concatenated to the password and hashed over multiple iterations to make it attack resistant. Apart from the password, other patient confidential details are also encrypted.

124

B. Security Component – Access Control

The eHealth system needs to clearly define its user roles and their access permissions. That makes the viewing and modification of unauthorized data, execution of unauthorized functionality impossible [13]. The security functions at three layers are described below. Presentation Layer: The user cannot navigate to any pages without proper authorization. There is a restricted access at every level. The GUI control buttons and links are displayed in such a manner that only the ones which the user has access permissions to them are displayed to the user. Business Layer: Before executing any functionality, an access control check is made to verify user authorization. In addition, security filters are implemented to ensure that unauthorized access to web pages is prevented by automatically redirecting the user to the login page. Data Layer: We ensure that unauthorized access to databases is prevented. For example, we use MongoDB to store patient test results. This data is password protected and read only for the eHealth application users.

C. Security Component – Session Management

Among all the possible attacks to the eHealth system application, session hijacking is one such vulnerability. A session is started, once a user is authenticated after login procedure. This session is carried on for the entire time till the user logs out. But to prevent session hijacking, automatic logout is implemented. The session is invalidated after logout to prevent further access without logging in again. If the user has logged in for a considerable amount of time and forgets to logout, their session is automatically invalidated by this technique after a period of time.

D. Security Component – Secure Transmission

Another set of possible attacks are session id theft, password theft and man in the middle. In order to avoid these attacks, all pages from login to logout are served only over HyperText Transfer Protocol Secured (HTTPS). No secure page is served over HTTP, instead the request will be automatically redirected from HTTP to HTTPS and the user will be provided a secured session.

E. Security Component – Input Validation

Introduction of malformed data is another popular security threat which occurs in the eHealth application. Though input validation is not the primary method of preventing SQL injection, it can contribute to prevent insertion of malformed data by malicious attackers. JavaScript validations are performed to cover this vulnerability and thus SQL injection can be prevented.

F. Security Component – Preventing SQL Injection

SQL injection vulnerability is created when string concatenation is used to build SQL statements for user controlled data. We use parameterized query construction as opposed to dynamic queries for a safer way of creating SQL statements. This ensures that the SQL query is built first and data is passed as parameters rather than building the query dynamically, which may give a malicious user control over the data manipulation.

V. DESIGN FRAMEWORK TESTING

Testing is an integral part of the software development process and it starts with the development of the system. The main focus of the SOD framework is on security, and that will be taken into consideration during the testing process. Deploying an eHealth system on mobile and cloud platforms need additional testing. The testing process includes verification of both functional and non-functional requirements. The results of the testing process are documented in a test report, which includes details, such as the total number of passed and failed test cases.

Fig. 4 Security tool used for security testing

The tool used for security related testing in the design framework is the Netsparker 2.3.0.18 Community Edition tool. Once the target URL is specified, this tool scans all the web pages and checks for a range of errors and threats. It is platform independent, and it is easy to set up tests using the tool. When an issue is detected, it provides possible remedies

125

to rectify the errors. The Fig. 4 shown above depicts the way the tool detects an error and displays it to the user.

VI. SOD DESIGN FRAMEWORK SYSTEM PERFORMANCE

TESTING

Performance testing determines how responsive an eHealth application system performs under a particular workload environment. This also means subjecting the system to an increasing amount of workloads and continuously enhancing the system till it can perform satisfactorily under heavy workloads to meet the user specified requirements. It can also serve to validate and verify a variety of Quality of Service (QoS) attributes of the system, such as scalability, reliability and system resource (CPU and memory) usage. The performance testing verifies the response time of the eHealth system application developed by using the SOD framework and how the application system scales under different weighted workloads. An eHealth system should be guaranteed to work satisfactorily during the periods of peak system usage with acceptable levels of performance. When the system is executing on the cloud and the web services running on the cloud, it can have better performance in scalability and availability. A. Performance Testing in Cloud Computing

The use of the capability of cloud computing is a recent computing direction. It is important to validate the scalability and performance aspects of the eHealth application system developed from the SOD framework in the cloud computing environment. The measurement validation of response time with respect to the users and patients of the eHealth application system need to be available. The response time measured must be acceptable. When a user or patient tries to access any of the eHealth application system web pages, the web pages must be accessible and available efficiently without any delay or latency related issues. The tool used for performance testing in the SOD framework is JMeter. The load testing of the framework is done with a variety of settings, such as “thread start time”, “time to wait” and “when to start the thread”. Another setting is the “hold time”, which holds the thread execution for a selected period of time in seconds and then resumes the thread execution again. Finally there is the “stop time” specification. Once the tests are run with these settings, the tool generates different graphs through which we can analyze the system performance. The system performance testing data graphs in Fig. 5, Fig. 6 and Fig. 7 show a variety of performance testing results of a prototype application

(called MedCare) of an eHealth application system we built using the SOD framework. Fig. 5 below represents the active threads created with an elapsing period of time. The graph of active threads vs. time is given below:

Fig.5 Performance chart (active thread vs. time)

Fig. 6 shows the performance testing data for response time vs. thread. We ran the performance tests on two of the web pages in the MedCare prototype application - 'home' web page and the 'login' web page. As indicated in the parameters, 30 threads were started at the beginning. It was the test simulating 30 users using the eHealth prototype MedCare. It was adding 5 users to the system every 5 seconds. The prototype was held on the user load for a period of time. Then the prototype began to remove 4 threads every 5 seconds.

Fig.6 Performance chart (response time vs. thread)

From the results of the performance tests conducted, we noticed that the response time was a little higher for actually getting to the prototype MedCare (home web page) than serving the next MedCare web page (which is the login web page) once the user has already been in the eHealth prototype.

126

Fig. 7 shows the performance data for response time over time.

Fig.7 Performance chart (response time over time)

We can see that as the load increases, response time also increases slightly. But the response time is lower for the login web page access than for the home web page access. Basically the overall average response time for the two types of web page access is roughly the same.

VII. CONCLUSIONS

Building an eHealth application system with the smooth integration of cloud and mobile technologies and easy to use UI for elderly patients is the main objective of our SOD framework. Building security into an eHealth application system which contains users’ personal identifiable information and health records is very critical. For elderly users, they are prone to make user oriented errors. The purpose of the design framework is to enable end-to-end strong security layers in the infrastructure of the eHealth application system. These layers include secure storage, secure access, and secure transmission along with taking adequate measures to avoid unauthorized uses of an eHealth application system.

REFERENCES

[1] Caring for Older Americans: The Future of Geriatric Medicine. (2005, March). doi:10.1111/j.1532-5415.2005.53350.x

[2] Clark, L. (2012, June 12). Mobile Apps for Patients

Model Good Strategy. Retrieved July 10, 2012, from content-science.com: http://content-

science.com/expertise/content-insights/mobile-apps-for-patients

[3] Code Conventions for the Java Programming

Language. (1999, April 20). Retrieved from Oracle: http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html

[4] eHealth. (2012, May 30). Retrieved June 12, 2012,

from wikipedia.org: http://en.wikipedia.org/wiki/EHealth

[5] Espen. (2005, April 12). Prototypes vs Simulations.

Retrieved July 7, 2012, from www.espen.com: http://www.espen.com/archives/2005/04/prototypes_vs_s.html

[6] Global Observatory for eHealth. (2009). Retrieved

July 30, 2012, from World Health Organization: http://www.who.int/goe/survey/2009/figures/en/index2.html

[7] Zhang, R., & Liu, L. (2010). Security Models and

Requirements for HealthCare Application Clouds. IEEE 3rd International Conference on Cloud Computing, (pp. 268-275). Miami, Florida. doi:10.1109/CLOUD.2010.62

[8] Ko, J., Lu, C., Srivastava, M. B., Stankovic, J. A.,

Terzis, A., & Welsh, M. (2010, November). Wireless Sensor Networks for Heathcare. Proceedings of the IEEE, 98(11), 1947-1960. doi:10.1109/JPROC.2010.2065210

[9] Kumar, P., & Lee, H.-J. (2012). Security Issues in

Healthcare Applications Using Wireless Medical Sensor Networks: A Survey. Sensors, 12(1), 55-91. doi:10.3390/s120100055

[10] Messmer, E. (2012, April 14). Hospitals seeing

more patient data breaches. Retrieved July 2, 2012, from www.itworld.com: http://www.itworld.com/networking/267820/hospitals-seeing-more-patient-data-breaches

[11] Okman, L., Gal-Oz, N., Gonen, Y., Gudes, E., &

Abramov, J. (2011). Security Issues in NoSQL Databases. IEEE 10th International Conference on Trust, Security and Privacy in Computing and Communications (TrustCom) pp. 541-547.

127