EMeH: Extensible Mobile Platform for Healthcare - CiteSeerX

Proceedings of the Federated Conference on Computer Science and Information Systems pp. 355–361

ISBN 978-83-60810-22-4

EMeH: Extensible Mobile Platform for Healthcare Tomasz Biały, Jacek Kobusiński, Maciej Małecki and Krzysztof Stefaniak Poznań University of Technology Poznań, Poland Email: {tbialy,jkobusinski,mmalecki,kstefaniak}@cs.put.poznan.pl

Abstract—Rapid development of mobile technology and growing number of users open new possibilities in the context of using mobile devices in the healthcare. Despite that, the resources and computing power of these devices are still far less than desktop computers. Thus, one can take into account these limitations when designing applications for such devices. On the other hand, the increasing functionality of mobile devices makes them a real alternative for a traditional PC in certain areas. Nowadays, the mobility becomes one of the most required feature for the information system users. They require to be connected and have access to data all the time at any location. This is also true in the context of hospital environment where the medical staff must collect, update and retrieve various type of data. EMeH Platform is a solution that provides the possibility to create efficient distributed applications based on the SOA paradigm. It offers universal environment that allows to integrate PDAs, smartphones, tablets as well as specialized barcode scanners and RFID readers with the existing hospital information system. Layered and flexible design that reflect real usage scenarios, efficient and economic resource usage and consistent dynamically generated user interface makes EMeH Platform interesting extension to the traditional hospital information systems.

I. I NTRODUCTION

H

EALTHCARE domain is one of the most dynamic and promising field of the IT appliance nowadays. As studies shows the IT infrastructure and software can increase the productivity and revenue of hospitals [1], [2], however, the medical personnel spend more time on data entry at the front of PC instead being with patients. The use of mobile devices in medical information systems creates the possibility of reducing this negative effect [3]. In the recent years the mobile devices became more universal and popular. The PDA, smartphone or tablets offer increasing functionality and power. There are also specialized mobile devices equipped with barcode scanners, RFID readers and GPS receivers. Currently, these devices, though still weaker than desktop PC, have enough power to become interesting alternative to them and can play the role of complex IT system terminals. Implementing the entire functionality of a hospital information system (HIS) as mobile application is pointless due to the imposed limits of the devices, eg. entering of a long text is still inconvenient and time consuming. However, in some cases, the mobility becomes one of the most important feature. Barcode scanners and RFID readers can greatly accelerate the process of collecting data about medical equipment, drugs and patients. The tablets can be used by medical staff to present patient health record (Electronic Health Record, EHR) close to

c 2011 IEEE 978-83-60810-22-4/$25.00

his bed. Emergency situations are the next field where mobility becomes important and useful. As mentioned previously, there are many possible mobile services that can enrich HIS. Typically they are realized as dedicated and separated applications, which makes the process of software development and management more difficult and expensive. The need to create many simple applications raises the idea of using service-oriented architecture (SOA) [4]. According to the SOA, applications will be replaced by web services used by the client’s applications. To minimize the resource requirements imposed on mobile device, such a client application responsible for providing user interface should be implemented using thin-client paradigm. In this paper we describe the EMeH Platform that allows to utilize various mobile devices in the healthcare environment. What is more important the EMeH Platform allows full integration with existing HIS system and follows newest trends in building distributed applications for network environment. The paper is organized as follows. Section II briefly presents current trends on mobile device markets. The concept of the EMeH Platform is described in Section III. Detailed description of the client application is presented in Section IV, while Section V contains a description of the service environment. Related works are discussed in Section VI. Finally, concluding remarks are presented in Section VII. II. M OBILE

PLATFORMS

In the recent years mobile devices market has dynamically developed. Therefore, a number of available mobile platforms and operating systems is considerable. Table I shows summary of the most popular mobile operating systems in the space of last two years. Currently Google Android is the most popular operating system among all mobile platforms. It’s market share has increased four-times last year, thereupon at the moment it has more users than the previous leader of ranking - Symbian operating system. Second mobile platform, which increased it’s market share last year is Apple iOS. All other platforms have lost some of their popularity. Regardless of the rapid development of the most recent platforms, there is a limited group of mobile devices, created precisely for specialized usage and amongst which vast majority are based on operating systems from Windows Mobile family. These devices, called mobile computers (e.g. handheld computers, wearable computers, vehicle-mounted mobile computers) can have various additional modules or peripherals

355

356

PROCEEDINGS OF THE FEDCSIS. SZCZECIN, 2011

TABLE I T OP MOBILE PLATFORMS - G ARTNER , M AY 2011 [5] Mobile platform Android Symbian Apple iOS RIM Blackberry Windows Mobile/Phone 7 Other OS

Market Share 2010 / 2011 [%] 9.6 / 36.0 44.2 / 27.4 15.3 / 16.8 19.7 / 12.9 6.8 / 3.6 4.4 / 3.3

Trend + + -

such as barcode scanners, RFID readers or can be adjusted to heavy duty (rugged mobile computer). This kind of specialized devices can be extensively applicable in modern healthcare systems, hence the client application for the EMeH Platform was created for this mobile platform above all. However, keeping in mind actual statistics, Android version of client application was implemented to reach wider group of users and devices as well. III. G ENERAL C ONCEPT The EMeH Platform was built to verify the capabilities of modern mobile devices in terms of creating e-healthcare [6] platform. E-healthcare associated with mobile devices is commonly called in the literature as mobile healthcare—mhealthcare or m-health [7]. The EMeH Platform is composed of client application for mobile devices and web service environment, which runs medical applications as services. Platform architecture was based on the SOA paradigm, which can be described as a modular, scalable and interoperable approach for building systems architecture. Thanks to these features, the SOA is the appropriate approach for placing a variety of simple applications in distributed network as web services. Basic client application was built using thin-client architecture with adaptive user interface. Furthermore, an effort was made to apply SOA guidelines to mobile devices— special services located at client’s side are also available for created application. The SOA paradigm is a crucial idea, which affected the design of this m-healthcare system. Frequently the infrastructure of medical facilities is expanded and its elements have to cooperate with each other. Hence its necessary to create separated modules with diverse functionalities on various devices and to provide communication between them. The SOA favors modularity of systems and ensures easy scalability. In addition usage of common interface (such as REST [8]) for accessing services assures interoperability of created applications. Such an architecture enables creation of web services which will be available to many users on various devices. Moreover, it is easy to access these services, because users need to install only client applications on their devices. The web service environment was created as a runtime environment for web services to simplify design and deployment of applications. The assumption that every module of the system can be a separate web service in the distributed network, enforces client-server architecture of interaction between mobile devices and applications. Thus, the EMeH Platform can be

Fig. 1.

General system idea

divided into two basic parts: • Client application - created as a thin-client application working on mobile device, • Web service environment - real medical applications consumed by client application and running in prepared runtime environment. General idea of the system is presented in the Figure 1. To communicate with web service, every device needs only client application installed on the device. Main medium of communication between mobile device and web service is wireless network. However, it is possible to use Bluetooth technology or other ones to communicate with certain additional devices (at client’s side) as well. A. Client application Client applications installed on mobile devices act similarly to web browsers, since they are thin clients. What makes difference between them is the fact, that web browsers connect to servers to browse web pages, whereas discussed client applications communicate with web services located on servers dedicated for purposes of medical institutions. Graphical user interface in the client application is generated based on data obtained from services. It determines web services’ ability to control the activity of client application. Client application as a thin client makes it possible to consume various services simultaneously and the effect of such actions depends solely on service creator. Additionally, client applications have the possibility to use services located at client’s side - local services. This kind of service is created as an extra library and extends functionality of client application, therefore it can be called plugin. Plugins allow client application to use device specific peripherals such as barcode scanners, Bluetooth communication modules, RFID reader modules, etc. It is a significant mechanism of easy extending functionality with virtually no restrictions. Moreover, it provides extensions to client application without necessity to reinstall it. This gives web services the ability to command mobile device to do extra operations such as reading barcode after defined user action (e.g. pressing the button) or communicating with other devices using Bluetooth module. Main tasks of client application running on mobile device are invocation of services by sending requests, processing of received responses from services and presentation of processed

JACEK KOBUSINSKI, MACIEJ MALECKI, KRZYSZTOF STEFANIAK, TOMASZ BIALY: EMEH: EXTENSIBLE MOBILE PLATFORM FOR HEALTHCARE

Fig. 2.

Client-Service interaction flow

data to the user. It needs to be emphasized that client application does not interfere with content of presented data in any way, it only affects the way of displaying data on the screen. The general application flow of client application is shown in the Figure 2. Every user action on mobile device triggers invocation of certain service, which in consequence can change the data displayed on device’s screen. Description of mappings between user actions and service invocations is included in responses received by client application. In short, such behavior can be described as a feedback loop. Invocation of service can be parameterized by additional parameters obtained from user interface or provided in preceding responses from services. User actions can be explained as any interaction with client application - for example it can be pressing the button, inserting text into textbox or even changing the orientation of the screen (rotating device). On the other hand, service invoked by client application, in general, returns commands in order to create or modify the graphical user interface, or to send request to some services. Summarizing, the information flow in client application is event-driven - it is triggered and controlled by actions performed by user. B. Services Services are the part of system responsible for data processing. There are two kinds of services: • Web services – installed in runtime environment for web services and located on servers, accessed by client applications using Wireless Local Area Network (WLAN). According to the SOA paradigm, medical applications for the EMeH Platform are designed as web services; • Local services for mobile device – client application can utilize also services located directly on mobile device. This element expands the interpretation of the SOA paradigm through having services located not only on servers, but also as software (especially libraries) working at the client’s side. Figure 3 presents the distribution of services, which can be accessed by client application by sending requests. It shows clear division to local services and web services. Local services can do various operations on mobile device, inter alia scanning barcodes, communicating via Bluetooth module or using GPS receiver. Whereas web services are medical applications situated in runtime environment.

Fig. 3.

Service types

In general, the network communication in general causes many security threats [9]. E-healthcare systems in many instances use confidential data (such as passwords, patient personal data, etc.), hence to protect against intrusive access of unauthorized parties, the system has to provide safe data transfer. To protect from unauthorized access, the EMeH Platform encrypts transfered data using HTTPS protocol with Secure Socket Layer (SSL) certificates. Besides in runtime environment there is an user session state management, which goal is to maintain information about user identity and activities. IV. C LIENT APPLICATION In this section we describe architecture of the client application for the EMeH Platform in detail. Further, we discuss selfupdating application model applied to the client application. A. Client architecture As it was mentioned in the previous section, application running on mobile device is based on the thin client architecture. Thereupon, its work is focused on effective service invocation and proper presentation of received data. However, it’s important to note that while processing responses from services application neither does not interfere, nor modifies the content of these responses, but only transforms them to graphical user interface. There can be distinguished three basic layers of the client architecture: presentation layer, logic layer and communication layer. Each of them is described below. Presentation layer Client application was designed to work with various mobile devices to achieve interoperability in the EMeH Platform. These devices can differ in many ways, starting with screen parameters, such as screen resolution, aspect ratio or pixel density. Apart from screen differences, devices can run on diverse operating systems, what has an influence on methods of user interface generation. To obtain uniform way of defining user interface, client applications use common XMLbased protocol of screen definitions. First client application

357

358

implementations were made for Windows Mobile and Google Android platforms, and both use the same protocol for user interface generation. If the client application sends request to web service, then it expects response containing description of elements, which will be shown on the screen. Web service formats responses in such a way, that it does not rely on mobile device characteristics (screen parameters, operating system, etc.), thus screen definition protocol is platform independent by design. Therefore it is fundamental to transform every response to representation suitable for given device. These operations are performed by client’s presentation layer. Discussed transformation of the response and the whole user interface management itself involves some time overhead noticeable to the user. For that matter, we applied double buffering of user interface, which significantly improves screen content replacement time. It can be described shortly as two image buffers - first for current user interface content (visible to the user) and second not visible at the moment. When response from service is being processed, content of the first buffer is displayed on the screen. While in the background transformation of user interface is in progress. Eventually, when processing finishes, buffers are swapped - second buffer becomes the first one (is visible on the screen), and the first buffer goes into the background. Logic layer Logic layer is a part of the system where messages from services are processed to create user interface. Besides that logic layer manages events fired by user interaction with presentation layer. Message processing means identifying type of response contained in the message and executing adequate operation depending on that type. There are three types of service responses: • response demanding from client application to create new user interface and display completely new data on the screen (whole application window has to be recreated), • response demanding update of certain element on the screen, i.e. change of any attribute of whichever element (for example text or color substitution on chosen label), • response demanding client application to invoke some service with given parameters. The message from service may contain several responses of different types - this allows to receive many screen modification or service invocation orders. Furthermore, messages can include additional data affecting client application behavior metadata. Metadata can show message window, store temporary value on the device or even quit the application. In addition to service response interpretation, logic layer has to acquire the information about events fired by user interactions (when and where was text entered, button pressed, screen touched etc.). It’s essential, because process of sending request from client application to service is executed as a reaction to certain user action - as it was described in the Figure 2. To control how application should react for user


interaction (make decision which services should be called and with which parameters), the logic layer has to monitor every event fired in the presentation layer. It indicates that logic layer is responsible for interpreting user actions, formulating requests to services linked with this actions and transferring required information to communication layer, which connects directly to appropriate services. Communication layer Communication layer is responsible for invocation of services. As it was described in section III-B services are divided into two types: web services and local services. Web services are basically applications deployed in runtime environment for web services, based on the SOA and having the common REST-style interface as an access method. On the other hand local services are services located physically on mobile device. Local services are similar to plugins located e.g. in shared libraries, which can perform operations on client application requests. They can serve as e.g. library for device I/O operations or peripherals management - such as barcode scanners, RFID transceivers, GPS receivers, etc. To attach local service to the client application, one only has to add new entry to the application configuration file. Usage of local service does not require network connection (unless it uses it). Besides standard synchronous invocation of web services and local services, there is a possibility to invoke local services asynchronously, what allows continuous processing without waiting for response from service. B. Update mechanism To spare users and administrators contingent problems related to updating version of application on every single mobile device with the EMeH Platform, a mechanism called Updater was created. It is an implementation of self-updating application model, which utilizes a small update application (Updater) to alter main client application. Every client application before start uses this additional application to connect to specially exposed web service containing all versions descriptions to check whether there are any updates particular for it’s device. If newer version of application or some local services (created for certain device) are available, they are automatically downloaded and installed on mobile device. It guarantees consistency between all client applications on every mobile device working within the EMeH Platform, compatibility with all web services and simple maintenance of versions in network with many different mobile devices. V. W EB SERVICE ENVIRONMENT Runtime environment of web services was created to provide web services with the set of common functionalities. There are two general parts of the environment: • web services, i.e. applications running in runtime environment, • preprocessing modules, providing web services with essential system features, i.e. authentication etc. Figure 4, discussed in detail below, presents these elements with regard to control flow among them (marked with arrows).


B. Web service structure

Fig. 4.

Request processing flow

A. Common preprocessing modules In web service environment, the following preprocessing modules are implemented: • • •

module for controlling version of client application, user authentication module, state recovery module, used e.g. after mobile device failure

Version control module verifies version of application installed on mobile device that connects to the web service environment. It is important, because inconsistent versions of client-side application and web service-side environment can ensue unpredictable errors during communication. Every request sent from client to web services contains information about application version. If application version is not compatible with web service environment version, then client receives a response, which demands necessary updates to be made. Afterwards, the updater application (see: IV-B) on device downloads new version from the server and installs it automatically. After verification of the client application version, the request is advanced to authentication module. SSL certificates are used to assure secure communication between client and services. These certificates, installed on both sides of connection, provide data encryption and identity verification for both client application, and web service environment. To positively pass authentication process, device certificate has to be compatible with corresponding certificate of web service environment. State recovery module serves as mechanism of restoring interrupted user session. Whereas logging to the system, state recovery module checks whether previous user session was terminated properly. Negative result means that there exists high risk, that session was interrupted during users’ work, hence module tries to recover it to the user. What is the most important, session is associated to a specific user - not to device which was used to send requests to web service environment. It gives possibility to quickly end up working on broken device and continue working on another, without losing any effects of work.

Structure of web services working in runtime environment can be divided into three main parts: • REST interface used for communication, • business logic of application, • response generator for client application. Every web service deployed in web service environment can be accessed by clients via REST interface. REST is architecture style for stateless communication using HTTP protocol (or encrypted HTTPS) in the EMeH Platform. According to the REST principles, access to the service is enabled by methods of HTTP protocol: GET, POST, PUT and DELETE, meaning getting, creating, modifying and deleting data respectively. Messages exchanged between clients and web services have structure of XML documents as a result of platform independent protocol described in section IV-A. Business logic is the only element of web service environment which provides certain functionalities directly to client applications. It defines specifications for client application: which events caused by the user of application will be linked to which services (web services as well as local services) and how the result will be presented i.e. which elements will be displayed on the screen. It is neither not dictated in any way, nor limited, and it depends solely on the author’s concept— communication with other available services, databases, filesystem or server software is allowed. In other words, business logic module of web service has strict influence on how client-service interaction presented on Figure 2 will look like. It is important, that all data prepared in business logic need to be passed to the response generator module, because it creates responses for mobile devices using platform independent protocol. This module is responsible for transformation of internal representation of data obtained from business logic of web service into format comprehensible for client applications and based on three types of responses discussed in section IV-A. VI. R ELATED W ORK In the last decade m-healthcare systems have become a popular subject of scientific researches [10], [3], [11]. Wide spectrum of work constitutes systems for continuous monitoring of patients, what can be achieved by wearing special devices [12]. Those systems are based on so-called Body Area Networks [13]. This kind of network is dynamically developing sector of IT, in which mobile devices are used to e.g. monitor of vital signs [14] and report to a doctor every potential threat for patient’s health [15]. Another issue, which is highlighted in the literature is using mobile devices in everyday work of medical staff [16]. Attempts were made to use RFID or barcode technologies to identify patients on hospital wards [17], [18], [19] or medicaments in hospital pharmacy [20]. Mobile devices with the GPS receivers were used to track elderly patients outside hospitals [21], [22]. Wireless access to basic functions of existing hospital information systems is also a big challenge

359

360

[23]. Mobile devices are used as terminals for collecting and viewing patient’s medical documentation [24] or to to prescribe medicines [25], [26]. The SOA assures interoperability [27] and ease of data exchange between separate medical systems [28]. In [29], [30] the SOA-based e-healthcare systems were presented, [31] contains description of the prototype SOA-based m-healthcare system for cellular phones, whereas [32], [33] show attempts to use REST interface in healthcare systems. In the literature there were widely described thin-client architecture [34], [35] and automatic generation of user interface. There also appeared positions about adaptive user interface [36], context-aware user interface [37] and dynamical user interface [38], [35], however none of mentioned was related to medical applications. VII. C ONCLUSIONS This article presents a new m-healthcare platform, which utilizes modern mobile devices for e-healthcare applications. Among basic requirements for distributed system for mobile devices the most important are: modularity, accessibility, scalability and interoperability. Therefore platform was built using service oriented architecture and the access to services was assured by the RESTful interface, which enables stateless communication over HTTP protocol. The EMeH Platform combines features of the systems mentioned in VI. It consists of client application and runtime environment for web services. Client application is a thinclient application with user interface generated dynamically of data received from services. Services can be divided into web services and local services. Web services are applications settled in runtime environment, which ensures common mechanisms for authentication, version control and user session recovery. On the other hand, local services are essentially plugins available on mobile devices. The idea of services located at client’s side arises as an interpretation of the SOA paradigm in terms of a single mobile device. Local services are capable of interacting with e.g. mobile device’s peripherals, such as Bluetooth, RFID or barcode modules, thus can be highly suitable for hospital information systems. Great emphasis was put on ensuring interoperability of the created platform. To use the EMeH Platform on mobile device with other than Microsoft Windows Mobile or Google Android operating systems installed, it is needed to implement new client application for displaying user interfaces (defined by services) in new system specific manner. However, communication protocol and activity of services in web service environment is universal for every mobile platform due to the common RESTful interface of invoking services. The EMeH Platform was implemented as a part of the Hospital Information System Eskulap, Poznan University of Technology, Poland [39]. In web service environment there are already some fully implemented applications, e.g. mobile dispensary in pharmacy or application for monitoring of patients on hospital wards, which currently are being performed acceptance tests in hospitals. On mobile devices there are


available client application versions for Microsoft Windows Mobile 5.0+ and Android 2.2+ operating systems. In the future there will be more client applications implemented to extend the scope of the platform on additional operating systems, such as Apple iOS or Microsoft Windows Phone 7. Besides that, there will be created a new tool for graphical screen definition creation in web services. There will be also implemented more web services for the EMeH Platform, based on existing software of the Eskulap System. Reason is that many of existing applications for desktop computers could be easily extended by the access from mobile devices, such as: laboratory, medical imaging or ambulance service applications. R EFERENCES [1] N. M. Menon, B. Lee, and L. Eldenburg, “Productivity of information systems in the healthcare industry,” Information Systems Research, 2000. [2] N. Oriol et al., “Calculating the return on investment of mobile healthcare,” BMC Medicine, vol. 7, no. 1, 2009. [3] J. H. Wu, S. C. Wang, and L. M. Lin, “Mobile computing acceptance factors in the healthcare industry: A structural equation model,” International Journal of Medical Informatics, vol. 76, no. 1, pp. 66–77, jab 2007. [4] T. Erl, Service-Oriented Architecture: Concepts, Technology, and Design. Upper Saddle River, NJ, USA: Prentice Hall PTR, 2005. [5] R. Cozza et al., “Market share analysis: Mobile devices, worldwide, 1q11,” Gartner, Tech. Rep., may 2011. [6] G. Eysenbach, “What is e-health?” Journal of Medical Internet Research, vol. 3, no. 2, June 2001. [7] R. Istepanian, S. Laxminarayan, and C. S. Pattichis, M-Health: Emerging Mobile Health Systems, ser. Topics in Biomedical Engineering. Springer, 2006. [8] R. T. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, University of California, Irvine, 2000. [9] D. Welch and S. Lathrop, “Wireless security threat taxonomy,” in IEEE Systems, Man and Cybernetics Society Information Assurance Workshop, jun 2003, pp. 76–83. [10] U. Varshney, “Using wireless technologies in healthcare,” International Journal of Mobile Communications, vol. 4, no. 3, pp. 354–368, feb 2006. [11] C. Free, G. Phillips, L. Felix, L. Galli, V. Patel, and P. Edwards, “The effectiveness of m-health technologies for improving health and health services: a systematic review protocol,” BMC Research Notes, vol. 3, no. 1, pp. 1–7, 2010. [12] V. Jones et al., “Mobihealth: Mobile services for health professionals,” in M-Health, ser. Topics in Biomedical Engineering. Springer US, 2006, pp. 237–246. [13] H. B. Li and R. Kohno, “Body area network and its standardization at IEEE 802.15.BAN,” in Advances in Mobile and Wireless Communications, ser. Lecture Notes in Electrical Engineering. Springer Berlin Heidelberg, 2008, vol. 16, no. 4, pp. 223–238. [14] E. Monton et al., “Body area network for wireless patient monitoring,” IET Communications, vol. 2, no. 2, pp. 215–222, feb 2008. [15] V. Gay, P. Leijdekkers, and E. Barin, “A mobile rehabilitation application for the remote monitoring of cardiac patients after a heart attack or a coronary bypass surgery,” in Proceedings of the 2nd International Conference on Pervasive Technologies Related to Assistive Environments. Corfu, Greece: ACM, 2009, pp. 21:1–21:7. [16] Y. C. Lu, Y. Xiao, A. Sears, and J. A. Jacko, “A review and a framework of handheld computer adoption in healthcare,” International Journal of Medical Informatics, vol. 74, no. 5, pp. 409–422, 2005. [17] L. Cheng-Ju, L. Li, C. Shi-Zong, W. C. Chen, H. Chun-Huang, and C. Xin-Mei, “Mobile healthcare service system using RFID,” in IEEE International Conference on Networking, Sensing and Control, vol. 2, Taipei, Taiwan, mar 2004, pp. 1014–1019. [18] A. T. van Halteren et al., “Mobile patient monitoring: The Mobihealth system,” The Journal on Information Technology in Healthcare, vol. 2, no. 5, pp. 365–373, 2004.


[19] D. C. Baumgart, “Personal digital assistants in health care: experienced clinicians in the palm of your hand?” The Lancet, vol. 366, no. 9492, pp. 1210–1222, October 2005. [20] J. M. Rothschild, T. H. Lee, T. Bae, and D. W. Bates, “Clinician use of a palmtop drug reference guide,” Journal of the American Medical Informatics Association, vol. 9, pp. 223–229, 2002. [21] L. Chung-Chih, L. Ping-Yeh, L. Po-Kuan, H. Guan-Yu, L. Wei-Lun, and L. Ren-Guey, “A healthcare integration system for disease assessment and safety monitoring of dementia patients,” IEEE Transactions on Information Technology in Biomedicine, vol. 12, no. 5, pp. 579–586, 2008. [22] S. H. Chew, P. A. Chong, E. Gunawan, K. W. Goh, Y. Kim, and C. B. Soh, “A hybrid mobile-based patient location tracking system for personal healthcare applications,” in 28th Annual International Conference of the IEEE Engineering in Medicine and Biology Society, New York, NY, sept 2006, pp. 5188–5191. [23] B. Lin and J. A. Vassar, “Mobile healthcare computing devices for enterprise-wide patient data delivery,” International Journal of Mobile Communications, vol. 2, no. 4, pp. 343–353, dec 2004. [24] J. Bergmann, O. J. Bott, D. P. Pretschner, and R. Haux, “An econsent-based shared EHR system architecture for integrated healthcare networks,” International Journal of Medical Informatics, vol. 76, no. 2-3, pp. 130–136, March 2007. [25] E. G. Poon et al., “Medication dispensing errors and potential adverse drug events before and after implementing bar code technology in the pharmacy,” Annals of Internal Medicine, vol. 145, no. 6, pp. 426–434, 2006. [26] F. Kart, G. Miao, L. E. Moser, and P. M. Melliar-Smith, “A distributed e-healthcare system based on the service oriented architecture,” in IEEE International Conference on Services Computing, July 2007, pp. 652–659. [27] S. Daskalakis and J. Mantas, “The impact of SOA for achieving healthcare interoperability,” Methods of Information in Medicine, vol. 48, no. 2, pp. 190–195, 2009. [28] J. Brzeziński, S. Czajka, J. Kobusiński, and M. Piernik, “Healthcare integration platform,” in 2011 5th International Symposium on Medical Information Communication Technology, Motreux, March 2011, pp. 52–55.

[29] F. Kart, L. E. Moser, and P. M. Melliar-Smith, “Building a distributed e-healthcare system using SOA,” IT Professional, vol. 10, no. 2, pp. 24–30, mar-apr 2008. [30] W. S. Ng, J. C. M. Teo, W. T. Ang, S. Viswanathan, and C. K. Tham, “Experiences on developing SOA based mobile healthcare services,” in IEEE Asia-Pacific Services Computing Conference, Singapore, dec 2009, pp. 498–501. [31] M. Savini, A. Ionas, A. Meier, C. Pop, and H. Stormer, “The eSana framework: Mobile services in eHealth using SOA,” in European Conference on Mobile Government, 2008. [32] L. Griffin, C. Foley, and E. de Leastar, “A hybrid architectural style for complex healthcare scenarios,” in IEEE International Conference on Communications Workshops, Dresden, June 2009, pp. 1–6. [33] L. W. F. Andry and D. Nicholson, “A mobile application accessing patients’ health records through a REST API,” in 4th International Conference on Health Informatics, 2011, pp. 27–32. [34] R. A. Baratto, L. N. Kim, and J. Nieh, “THINC: a virtual display architecture for thin-client computing,” ACM SIGOPS Operating Systems Review-SOSP ’05, vol. 39, no. 5, pp. 277–290, December 2005. [35] J. Kim, R. A. Baratto, and J. Nieh, “pTHINC: a thin-client architecture for mobile wireless web,” in Proceedings of the 15th international conference on World Wide Web. Edinborough, Scotland: ACM, 2006, pp. 143–152. [36] M. Al-Turkistany, A. Helal, and M. Schmalz, “Adaptive wireless thinclient model for mobile computing,” Wireless Communications and Mobile Computing, vol. 9, no. 1, pp. 47–59, January 2009. [37] T. Butter, M. Aleksy, P. Bostan, and M. Schader, “Context-aware user interface framework for mobile applications,” in 27th International Conference on Distributed Computing Systems Workshops, Toronto, Ont., jun 2007. [38] K. Luyten and K. Coninx, “An XML-based runtime user interface description language for mobile computing devices,” in Interactive Systems: Design, Specification, and Verification, ser. Lecture Notes in Computer Science. Springer Berlin / Heidelberg, 2001, vol. 2220, pp. 1–15. [39] “Eskulap-hospital information system,” Poznan University of Technology. [Online]. Available: http://www.systemeskulap.pl/

361