Health Portal Suggestions for Continued Work

Health Portal Suggestions for Continued Work CSD Fall 2010 Version: 1.0 Identifier: HP-003 Project owners Björn Pehrson Sven Jonsson Amos Nungu Project coach Hans Eriksson Team members Contact ECTS credits Anand Kannan anandk@kth.se 15 cr. Biniam Goshu Mekonnen biniamgm@kth.se 30 cr. Boris Ristov ristov@kth.se 24 cr. Christina Sidiropoulou csid@kth.se 15 cr. Ekaterina Garbaruk garbaruk@kth.se 15 cr. Manxing Du manxing@kth.se 30 cr. Shabnam Sadat Jalalinia ssja@kth.se 15 cr. 12/28/2010

Version history Version Release date Changes Author(s) 1.0 12/28/2010 First version of the document created Boris Ristov 2 (12)

Table of contents 1. Introduction... 4 1.1. Purpose of document... 4 1.2. Scope of document... 4 1.3. Audience of document... 4 2. Suggestions for continued work... 4 2.1. Use feedback from Stockholms Läns Landsting/Vårdguiden... 4 2.2. Provide different localizations... 5 2.3. Extending the functionality of the health portal... 5 2.4. Use the OSIA platform... 6 2.4.1. Reasoning for the current health portal prototype... 6 2.4.2. Description of OSIA... 6 2.5. Centralized vs. decentralized database... 7 2.5.1. Centralized solution... 7 2.5.2. Decentralized solution... 8 2.6. Stronger focus on individual control... 10 3. Alternative approaches... 10 3.1. Using the Drupal CMS... 10 3.2. Using the Indivo PHCR system... 11 3.3. Using the care2x HI system... 11 4. Summary... 11 5. References... 12 3 (12)

1. Introduction 1.1. Purpose of document The purpose of this document is to provide suggestions for succeeding CareNet teams on how to evolve the health portal concept beyond its current prototype stage, if they choose to pursue the concept further. Several suggestions on what can be done to improve it will be provided, and also alternative approaches will be discussed. 1.2. Scope of document This document covers topics related to the health portal and the various ways it can be improved upon or extended. The document will attempt to cover both technical as well as non-technical considerations. The actual implementation of the health portal will not be discussed at great length in this document. 1.3. Audience of document This document is aimed at any succeeding CareNet teams who wish to extend the possibilities of the current prototype to a new level or look into alternative solutions if needed. 2. Suggestions for continued work In this section, suggestions on what can be done to extend the health portal prototype will be presented. 2.1. Use feedback from Stockholms Läns Landsting/Vårdguiden The aim of the current prototype has been to provide a starting point for the continued development of the health portal. The CareNet team has developed a set of features to enable and facilitate communication between caregivers and caretakers, such as appointment calendars and diary entries. In order to provide a comprehensive health portal system that can be established in real production/health-care environments, the system needs to respect regulations and laws surrounding the health-care of the area where the system is to be deployed. Since Sweden will currently act as the main environment where the health portal will be deployed, Swedish regulations and laws need to be considered. Therefore, in the case of Stockholm, Sweden, it is advisable to consult the matter with Stockholms Läns Landsting [1] (SLL, eng. County Council of Stockholm), who are responsible for all the publicly financed health-care services in the county. 4 (12)

Stockholms Läns Landsting is also responsible for the health-care guidance and information in the county, and they offer these services through Vårdguiden. [2] It is advisable to attempt to get them on board, so as to clarify potential outstanding issues in deploying a health portal system in a proper environment. Regarding laws and regulations in Swedish health-care, Vårdguiden provides a summary of applicable laws that aim to protect patients, and in the case of the health portal, it is important to respect laws concerning secrecy and integrity issues. [3] If the plan is to deploy a health portal system in another location in the future, any local laws need to be considered and the system adapted to them. 2.2. Provide different localizations In order to improve the accessibility of the health portal system, and to accommodate the different types of users a real health-care scenario undoubtedly will encompass, it is advisable to look into a solution that provides different localizations. The current prototype is only available in English, but a possible extension is to add a menu choice or a rolling list where the user can choose from a variety of available languages. This will improve the portal s ease-of-use and open it up to a wider audience. 2.3. Extending the functionality of the health portal As with most software platforms, the provided functionality and service continuously evolve over time, providing additional features or making improvements to the user interface. Since the current prototype is built using open-source software such as PHP, the possibilities of adding functionality to the portal is unlimited. Some suggestions on additional features that can be added in the future are: A full-featured contact system or a ticketing system that notifies users if new messages are sent or received, enabling a direct link between caregivers and caretakers. An intranet e-mail solution is also a possibility. A mail notification system that automatically sends generated e-mails to remind users of scheduled appointments, or new messages/replies in the ticketing system. A simple chat protocol that allows logged-in caretakers to have a direct online conversation with their assigned caregivers. A system to handle the test results of patients. A system to handle prescriptions assigned to patients. A proper integration of patient journals into the health portal system, providing easy access to them when needed. A password recovery or resetting system. Currently SHA-1 encryption is used which does not allow for password recovery. Some of the proposed suggestions may require a higher level of programming/scripting knowledge, so it is advisable to have access to sufficient experience in this subject area. 5 (12)

2.4. Use the OSIA platform 2.4.1. Reasoning for the current health portal prototype The current health portal prototype is built from the ground-up using proven open-source software such as PHP and MySQL. The main reasons for not choosing available solutions were: 1) By creating the health portal prototype from scratch, a framework can be developed that is easily extendable and does not use any hard-to-modify solutions. Thus, the difficulty level of modifying the current prototype should be low. It also allows us to maintain specific license rights would we wish to. 2) Discussions were had to make use of a website platform that is currently being developed called OSIA, by Ph.D. student Dan Kopparhed. Since OSIA was to be the platform of choice, the actual portal itself had to be developed using simple PHP and HTML, and then applied on top of the platform. Due to the early nature of the OSIA platform the deployment on top of OSIA was postponed, but the health portal prototype was still developed with OSIA in mind. Therefore, when OSIA is mature enough to act as a stable platform, we recommend future CareNet teams into basing the portal on it. 2.4.2. Description of OSIA OSIA is the developmental name of a new type of platform that will simplify the deployment of various kinds of pages on the Internet. [4] The core feature of the platform is its modularity: the aim with the platform is to provide the option to create, manage and/or mix various types of functionality commonly found on the Internet, such as portals, Content Management Systems (CMS), forums and so on. If the various features are thought of as modules, the user then has the power to enable the modules that are necessary. If the user also needs to extend his/her the functionality of the offered website, new modules can be downloaded and added when needed. This also enables reuse of code and features. The modularity of the OSIA platform also brings forth another feature that improves the ease-of-use and maintenance, What You See Is What You Get (WYSIWYG). Since the various aspects of a site are broken down into smaller pieces, the website administrator(s) can rearrange elements freely in a simple and graphical way. This also allows for a more focused development approach: as an example, when the portal is broken down into smaller pieces, a graphical designer can then worry about the look of the webpage without needing particular technical skills, while someone working on the functionality of the website does not need to worry about the graphical layout. This allows for added flexibility, since development tasks can be divided between team members in a more specific, or direct, way. When this platform realizes its promise, it could prove to be a valuable addition to any health portal. Any additional features that may be requested can be added easily and without requiring strong technical knowledge. 6 (12)

2.5. Centralized vs. decentralized database 2.5.1. Centralized solution The current health portal prototype is using a centralized database, that is, it is stored on the same server as the health portal itself. This setup provides some benefits that will be discussed below: Easier backup scheme: Since the database is stored in one location, performing backups and restoration tasks is simplified. Easier maintenance: Since the central database stores all the user information, any number of devices can be using the health portal. There is no need to worry about local databases in the gateways and how the main server should access them (to retrieve patient information). Figure 1 below illustrates this scheme. The health portal server acts as a normal web-hosting server and provides all the necessary functionality to the end-user, who simply has to connect to the portal like any other page. Figure 1: A simple topology map of a centralized solution. The entire database is stored on the health portal server, which simplifies maintenance but lacks redundancy. 7 (12)

This solution is easy to setup and maintain, but it also has some drawbacks that will be discussed below: Lack of redundancy: Since the database is stored locally, the risk of losing all information in case of an unforeseen consequence is higher. It is therefore advisable to figure out a backup scheme that, for example, stores nightly dumps of the database at an external location. Lower security: Since all the user information is stored locally, there is always a heightened risk of security breaches and the loss of personal information. The aim is to provide a health portal system that stores data securely, but threats on the Internet are always evolving. In the next section, another approach will be discussed that may alleviate some of the issues with the current setup. 2.5.2. Decentralized solution Another approach that may be used is to decentralize the storage of information in the health portal system. The idea is to store all the patient information locally in the residential gateways, and leave only the basic functionality and caregiver information in the main health portal server. In theory, the decentralized solution may provide the following benefits: Improved redundancy: Since all the personal patient information is distributed and stored locally in the residential gateways placed in the homes, a natural form of redundancy is achieved. If the main health portal server would fail, the data stored in the gateways is not lost. Improved security: Since the health portal information is not stored in one place, it is automatically harder for malicious attackers to acquire data, especially the patient data which is the most essential information stored in the system. Additional flexibility: By storing all the private information locally in the residential gateways, it is possible to fine-tune privacy aspects of the health portal, e.g. the user has full control over what kind of data is made available to caregivers. This aspect will be discussed further in section 2.6. Figure 2 on the next page illustrates the decentralized scheme. The health portal system is still hosted on the server, but the private patient information is stored in each individual gateway. Therefore, the main server needs to be aware of the residential gateways that are being used, and how to connect to them. 8 (12)

Figure 2: A simple topology map of a decentralized solution. The database on the health portal server contains general information about caregivers and how to reach all the residential gateways, while the residential gateway databases contain the personal patient information. Therefore, if a doctor needs to retrieve information about a patient, the server needs to contact the targeted residential gateway and acquire access to the requested information. The improved redundancy and security is a welcome addition, but this solution creates a new set of problems: Increased complexity: Since the main server needs to know how to access the local databases, someone will have to maintain a record of all the residential gateways that are in use. This can be achieved if the residential gateways are assigned static IP addresses and are reachable if one knows the necessary information. Thus, some extensions need to be done to the current health portal database so that all this necessary information can be stored. Increased maintenance efforts: The above situation also creates a new problem. Who is responsible for maintaining the records on how to connect to the residential gateways? An efficient solution for retrieving the information stored in the gateways is warranted. Complex backup procedures: While distributing the information storage creates a natural form of redundancy and security, the information stored in the gateways can still be destroyed if an accident occurs. Therefore, comprehensive backup procedures are still needed, but they will be more complex since backups of all gateways need to be done and stored somewhere. 9 (12)

2.6. Stronger focus on individual control Currently, the health portal prototype supports a diary function where a patient can post whatever they like and choose whether or not their assigned caregiver should be able to read it. This concept, that the patient has control of what information should be available to the assigned caregivers, can be extended further to create a differentiating feature. By making use of the decentralized concept that was introduced in the previous section, a step is taken towards providing a portal with a strong focus on individual control. Since the end-user, that is the caretaker, controls what is accessible by the caregivers; privacy can be retained with ease when the caretaker wishes for it. By separating the patient information from the main health portal server, it also makes it harder for unauthorized personnel to get access to that information. The potential for expanding on this area is great, and it is urged that various options are explored that may benefit patients and their right to privacy. 3. Alternative approaches As discussed in section 2.4.1, one of the main reasons for starting the development of the health portal without using an already-established system was to provide compatibility with the OSIA platform. If, for some reason, any succeeding CareNet teams want to make use of other available platforms, some alternatives will be presented in short in the following sections. 3.1. Using the Drupal CMS Drupal is a well-established open-source CMS that is used as the back-end for many types of pages on the Internet. [5] Similar to OSIA, it also allows for extended functionality through the use of addon modules. Thanks to its popularity, there are many dedicated resources discussing the Drupal CMS, so documentation is plentiful. The basic release of Drupal, called Drupal Core, allows for features that can be expected of a health portal system such as user account management, layout customization and maintenance. By using these features there is no need to develop the features from the ground-up, but extensive modification may need to be done to conform the features to a health-care environment. 10 (12)

3.2. Using the Indivo PHCR system One solution that can be investigated is the Indivo personally controlled health record (PCHR) system. It is an actively-developed health information system in conjunction with the Children s Hospital Boston. Not unlike our health portal prototype, this system is free and open-source, and builds upon existing software and standards. [6] The most recent version at the time of writing is the first public beta, which is available on the official website. 3.3. Using the care2x HI system An alternative solution that may be investigated is the care2x hospital information (HI) system. Similar to Indivo, its aim is to provide a fully-featured health-care system that is free and opensource. [7] The project is currently in development, but early builds are available on the official website. 4. Summary As this document shows, there is room to greatly expand the health portal concept into untapped areas. A lot of work has been done in this field to come up with stable, efficient and secure systems, and the interest in developing fully-featured systems that most importantly are free to use is a good sign. 11 (12)

5. References [1] Stockholms Läns Landsting. (undated). [Online]. Viewed 12/28/2010. Available: http://www.sll.se [2] Vårdguiden. (undated). [Online]. Viewed 12/28/2010. Available: http://www.vardguiden.se [3] Vårdguiden. (06/11/2010). Lagar i hälso- och sjukvården. [Online]. Viewed 12/28/2010. Available: http://www.vardguiden.se/sa-funkar-det/lagar--rattigheter/lagar-i-halso--och-sjukvard/ [4] OSIA Wiki. (01/26/2010). What is OSIA? [Online]. Viewed 12/28/2010. Available: http://svn.dakit.se/osiawiki/what_is_osia [5] Drupal. (undated). [Online]. Viewed 12/28/2010. Available: http://drupal.org [6] Indivo The Personally Controlled Health Record. (undated). [Online]. Viewed 12/28/2010. Available: http://indivohealth.org [7] care2x The Open Source Hospital Information System. (11/17/2010). [Online]. Viewed 12/28/2010. Available: http://care2x.org 12 (12)