Using existing software to build a virtual community for telemedicine

Transcription

1 Using existing software to build a virtual community for telemedicine P.G. Hoekerd Telematics MSc. final thesis June 2013 University of Twente Biomedical Signals and Systems group Graduation committee Dr. Ir. B.J.F. van Beijnum Prof. Dr. Ir. H.J. Hermens Dr. Ir. M.J. van Sinderen

2 Abstract In the recent years, the field on telemedicine has become an interesting area for research. Telemedicine is considered one of the solutions to maintain the current level of healthcare despite the aging population. Another application in the field of telemedicine is to help people to do more exercises, which will decreases chronic diseases and increase the standard of living. When doing research in the field of telemedicine, new applications will be developed. For these applications to be used optimally, they should be incorporated into a single platform. This would allow the applications to collaborate, and offer a single point of access to the user. Therefore there is the need for a platform which can be extended with applications used for research in the field of telemedicine. In this platform, users are put into different groups, each group having a specific goal. Within each group, different users can have different roles. An online group with a specific goal and guided by policies can be considered a Virtual Community. Virtual Communities are particularly effective for telemedicine applications concerning group therapy; studies have shown that for chronic diseases requiring lifestyle changes, group therapy is an effective approach. A virtual community is typically carried out on a web based platform. There are three distinctly different directions which can be taken to acquire a platform which can be used to extend with telemedicine functionality. The first approach is to build a platform from scratch, which has the disadvantage of requiring much work developing it. Another approach is to join an existing hosted platform, which has the disadvantage of being completely reliable on the provider of this platform. A final approach is to use an existing software platform, and host this platform ourselves. This approach has none of the disadvantages mentioned above, and this research takes this approach and investigates the possibilities, as well as the advantages and disadvantages of the existing software platform which can be used. In this research, advice about the platform used to build a Virtual Community for telemedicine is given. This advice consists of two parts; advice is given about both which platform is most suitable to be used as a platform to be extended with telemedicine applications, as well as advice about the advantages and disadvantages of using that platform compared to building one from scratch. To be able to provide the advice about the suitability of a platform, first a set of requirements for this platform is composed by investigating previous researches. Next, research is done into existing platforms and a list of potential platforms is composed by first defining several search directions, creating a set of search terms based on these directions, and using these terms to search online. Using the requirements, the existing platforms are analyzed, and the most suitable platforms are taken. To be able to provide advice about the suitability of the remaining platforms, a case study is done. First, a typical scenario of a telemedicine application is defined. Using this scenario, a set of use cases is defined, which are implemented for the taken platforms. The required work and results are used to make a final statement about the most suitable platform, as well as a statement about how suitable the approach taken to use an existing platform is and the suitability of this most suitable platform. ii

3 Table of Contents 1 Introduction Motivation Background Problem Statement Research question Approach Thesis Structure Requirements Introduction Scope & Existing papers Approach Requirements from previous research papers Additional requirements Summary Conclusion Platform selection and evaluation Introduction Search directions Platform selection Round 1: Quick evaluation Round 2: Priority A evaluation Elgg Dolphin WordPress BuddyPress Mahara Anahita Drupal Commons Oxwall Liferay GateIn Summary Discussion Conclusion Platform analysis Introduction Approach Multi Criteria Analysis iii

4 4.3.1 Priority based linear additive multi criteria analysis MCA conclusion Multi Criteria Analysis discussion Conclusion Case study Introduction Case study description Scenario Use cases Summary Drupal case study Development environment Use cases Liferay Development environment Use cases Summary Development environments Evaluation per use case Summary Conclusion Conclusion, discussion and recommendations Conclusion Discussion Recommendations Terminology Bibliography Appendices Appendix A: Primary and secondary sources Appendix B: Search results Appendix C: Requirement evaluation results Appendix D: Analysis results List of figures Figure 1: MVC platform component overview... 2 Figure 2: General approach... 7 Figure 3: Evaluation approach Figure 4: Search approach iv

5 Figure 5: Platform composition summary Figure 6: Quick evaluation summary Figure 7: Elgg Figure 8: Dolphin Figure 9: WordPress Figure 10 :Mahara Figure 11: Anahita Figure 12: Drupal Figure 13: Oxwall Figure 14: Liferay Figure 15: GateIn Figure 16: Priority A requirements evaluation summary Figure 17: MCA approach Figure 18: Priority based MCA Figure 19: Platform score per priority Figure 20: Platform analysis summary Figure 21: Drupal module file structure Figure 23: A Simple hello world use case in Drupal Figure 22: Drupal use case 1 implementation Figure 25: Drupal roles Figure 24: Drupal use case 2 implementation Figure 26: Drupal use case 4 implementation, getting group users Figure 27: Drupal use case 4 implementation, getting user roles Figure 28: Drupal use case 5 implementation Figure 29: Drupal use case 6 implementation Figure 30: Drupal use case 7 implementation Figure 31: File structure of a Liferay project with 1 portlet Figure 32: A simple Liferay portlet Figure 33: Liferay use case 1 implementation, view.jsp Figure 34: Liferay use case 4 implementation, getting group id Figure 35: Liferay use case 4 implementation, display users and roles Figure 36: Liferay use case 5 implementation, developer code Figure 37: Liferay use case 5 implementation, complete code Figure 38: Liferay use case 6 implementation, Liferay portlet.xml Figure 39: Case study evaluation summary Figure 40: Elimination results List of tables Table 1: MVC component description... 3 Table 2: Unmodified requirement from previous researches Table 3: Redefined requirement from previous researches Table 4: Merged requirement from previous researches v

6 Table 5: Split requirements from previous researches Table 6: Additional requirements Table 7: Base platform requirements Table 8: Platform selection search terms Table 9: Potential platforms Table 10: Community builders & CMS with community builder extension Table 11: Enterprise portals Table 12: Abbreviated requirements Table 13: Elgg priority A evaluation Table 14: Dolphin priority A evaluation Table 15: WordPress priority A evaluation Table 16: Mahara priority A evaluation Table 17: Anahita priority A evaluation Table 18: Drupal priority A evaluation Table 19: Oxwall priority A evaluation Table 20: Liferay priority A evaluation Table 21: GateIn priority A evaluation Table 22: Platform roles evaluation Table 23: Platform number of bug reports Table 24: Dominance analysis Table 25: Drupal and Liferay dominance analysis Table 26: Per requirement dominance analysis Table 27: Use case summary Table 28: Case study use case results vi

7 1 Introduction 1.1 Motivation In the upcoming years Western Europe will have the problems of an aging population; the labor force will decrease, while the number of elderly people will increase. By 2050, for the Netherlands, the number of elderly people (69+) relative to the labor force (20 69) is expected to have increased from 16% to 37% [1], an increase of over 125%. Since elderly people generally need more healthcare, the total amount of required healthcare will increase, whereas the labor force being able to provide this healthcare will decrease due to the decreasing workforce. Therefore if the current level of healthcare is to be maintained in the future, healthcare must be delivered more efficient. One way to potentially increase the efficiency of healthcare is by delivering it from a distance, a concept also known as telemedicine. A possible scenario in telemedicine is to use remote monitoring to monitor patients at home where they would be monitored in a hospital at this moment. By not requiring a hospital bed, hospitals can treat more patients with the same amount of resources, thus increasing the efficiency of healthcare. With remote monitoring, like most healthcare, multiple parties are involved. Some of the typical parties are doctors and patients, but also nurses and other healthcare personnel, as well as relatives and friends can play a role. These parties all serve a common goal, to improve a patient s health; the exact definition of this goal depends on the situation. So there is a group of people who are interacting to achieve a common goal, each party with a certain role. This is more or less the definition of a Virtual Community (VC) as defined by [2] quoted by [3] which is defined as An online community is a group of people, who come together for a purpose online, and who are governed by norms and policies. Since this is a Virtual or Online community for remote monitoring, which is a part of telemedicine, this scenario can be considered a VC for telemedicine. Studies have shown that for some scenarios treatment using a group approach is more effective than treatment using an individual approach [4]. One of these scenarios is when a patient has to make lifestyle changes as a result of a chronic disease, or when recovering from a disease. A VC can be used to provide support in several ways. It can be used to provide informational support by providing information, either from healthcare professionals or from other patients. It can also be used to provide emotional support via forums where one can share experiences, or via (instant) messaging services. There are several VC s around that offer these 2 types of support [5] [6]. A more interesting type of support from a biomechanical engineering point of view is instrumental support. Instrumental support is defined in [7] as: Instrumental support involves the provision of tangible aid and services that directly assist a person in need. It is provided by close friends, colleagues and neighbors. These services can be in the form of ICT services, and the tangible aid in the form of ICT solutions. It is possible to have devices equipped with sensors that gather (medical) data, which can then be used to provide instrumental support. For example when used over a longer period of time, progress can be tracked, and this progress can be used to motivate a patient. In that case, the service is a progress tracking service and the tangible aid the motivation from peers. Another possible use of this data is when used in a group context, gathered data can be shared among peers, and peer pressure can be used to motivate a patient into making the required lifestyle changes. Finally, instrumental support can be used to give real time 1 of 95

8 feedback to a patient by a health care professional. By giving immediate feedback, possible errors can be corrected as soon as possible, thus increasing the efficiency of an exercise. 1.2 Background This section gives some background information required to understand the scope of this research. First, the different components of a MVC for telemedicine are given; the terms of these components are used later in this report. Next, the definition of mobile in Mobile Virtual Community used in this research is given. Component overview This section describes the components of a platform for MVC for telemedicine. The terms used for these components are used later in this report, and this section explains the role of each component, and the interactions between them. Figure 1: MVC platform component overview Figure 1 shows the components of a MVC for telemedicine. It consists of 3 tiers; a client tier, services tier, and data access tier. It is a modified version of the 3 tier design ( [8]quoted by [9]) commonly used in software engineering. Within each tier, several components are defined. There can be multiple instances of each component within the MVC for telemedicine, unless mentioned otherwise. 2 of 95

9 Name Description Client tier This tier consists of the clients using the MVC for telemedicine. Service tier This tier consist of components that process and present data from the data tier to the client tier, as well as processing acquired biomedical data from the mobile devices at the client tier. Data access tier The data access tier is responsible for storing and retrieving any data used by the web tier. Fixed client A fixed client is a client on a fixed connection using a PC or laptop. A fixed client uses a browser to connect to the web tier. Generally speaking, a fixed client will not send biomedical data. Mobile Client A Mobile client is a client on a mobile connection using a mobile phone or tablet. A mobile client generally connects to the web tier using a dedicated app, but a browser can also be used. Web presentation The web presentation services consist of the MVC access platform, and any other services website related to the MVC, but not integrated in the MVC access platform. Data acquisition The data acquisition services consist of components that provide functionality to services process acquired data. It can communicate with the base platform for user authentication. MVC access The MVC access platform is the presentation component of the web service. When platform a client uses a browser to connect to the platform, this component is viewed. In a typical MVC for telemedicine, there is only MVC access platform. The research focuses on this component. Base platform The base platform will be extended with the newly developed extensions. The base platform provides functionality typical for any MVC, not functionality specific for a MVC for telemedicine. The base platform functionality includes, but is not limited to, user and community management. It can also offer functionality to offer informational support, such as a Wikipedia extension or a built in forum. In a typical MVC for telemedicine, there is only one base platform. Developed Developed extensions are newly developed applications specifically designed to extensions add telemedicine functionality to a MVC. These extensions extend the base platform, and do not work independent from the base platform. Data acquisition The data acquisition service collects biomedical data from the sensors of the service mobile devices. Not necessarily part of the MVC access platform. By not being part of the MVC access platform, better scalability and easier development can be achieved. Uses generally uses WSDL/SOAP, REST/JSON or other web services to communicate with the mobile clients. Standard The standard database is general purpose database required and used by the base database platform, and can be used by the developed extensions if required. In a typical MVC for telemedicine, there is only one standard database. Medical database A medical database is a database specifically designed to store medical data. For example, this can be a secure database, or a database with functionality for storing medical data. External data Any data source outside the scope of the project. External data sources are usually source accessed using web services. MVC website In a typical low performance environment, these elements run on one machine. Not connected from a logical point of view. Table 1: MVC component description 3 of 95

10 Mobility To send the acquired data from a mobile device to a VC, the VC must be reachable from this mobile device. Furthermore, a possible scenario is to have the VC platform give live feedback during exercises. Exercises are almost never done in front of a PC or laptop; whereas it is likely a person doing exercises has the possibility to carry a Smartphone. By making the platform reachable by Smartphone, live feedback can be given. Ideally, the platform must be able to be reached from anywhere, at any time. If the platform is indeed reachable from anywhere at any time, the platform becomes a Mobile Virtual Community (MVC). It is assumed the mobile device has the ability to reach the VC platform from anywhere anytime, in other words, it has a mobile internet connection. However, while the assumption is true most of the time, it is not a strict requirement. Guaranteeing a connection 100% of the time introduces new requirements on the connection, for example automatic fallback to another type of connection, which are outside the scope of this project. 1.3 Problem Statement In the introduction several scenarios were described in which instrumental support was given. It did however not describe how this support should be given. To discover how this support should be given, research has to be done. Part of this research consists of developing new applications to extend the functionality of the MVC for telemedicine. There are various possibilities for new applications, ranging from applications that run solely on the MVC base platform, like an application to share experiences, to applications that gather (medical) data from sensors on a mobile device, and send this data to the MVC application. Since the goal of these applications is to research the options to offer support in an MVC, a research base MVC platform is required to deploy and test these newly developed applications. At this moment it is not clear what type of platform should be used to deploy these applications on. This leads to the goal of this research: To provide advice about the base platform used to develop applications in the field of Mobile Virtual Communities for telemedicine to researchers interested in developing these applications There are several approaches for developing a base platform, each approach with its advantages and disadvantages. Build a MVC from scratch Building a MVC from scratch is the most straightforward approach. Its advantages are clear, when all the code is self created, there is full control over every aspect of the developed code. With the goal of the MVC platform in mind, which is to support the development of new MVC applications, it is possible to make design choices specific for a MVC for telemedicine at the core of the MVC platform. The main disadvantage of developing a complete MVC from scratch is the amount of work required to develop a complete platform. Since this platform will only be used to develop and test new applications, the cost to build this platform would be relatively high. Extend existing MVC software One of the main advantages of using an existing platform instead of designing one from scratch is that it has the potential to safe work in development. This existing platform can either be a generic MVC or a MVC for telemedicine. In either case, a MVC for telemedicine platform shares some features with the existing platform, like user management and grouping. If it would be possible to re use those features, developing a MVC will be less costly. 4 of 95

11 There are however some disadvantages. Since medical information is being used, which is sensitive information, security is an issue. Any security issues in the existing platform will also be in the MVC platform. Therefore, investigating the security of the existing platform will be important. Another disadvantage could be the lack of backwards compatibility. Since security is an issue, keeping the platform up to date is mandatory. When the base platform is updated, it is desirable that all developed extensions will continue to work. Thus backwards compatibility is desirable. One final thing to consider is that it is very unlikely that a platform will meet all the requirements. Therefore it will be likely that changing existing code will be mandatory. As more and more changes are being made, maintaining the platform will become more costly, up to the point where maintenance of an existing platform will become more expensive than developing one from scratch. Throughout the development of the platform this should be kept in mind, and actions be taken accordingly. Joining an existing MVC for telemedicine A final approach can be to join an existing MVC platform or service, either one specifically designed for telemedicine, or a more generic one. This approach requires the least amount of work, since a fully working MVC will be joined. This approach however has some disadvantages which make it unsuitable to be used. Primarily, the complete reliability on the provider of this existing MVC makes it unsuitable. If the provider makes any changes, or ceases to exist, any developed extensions must be changed as well. Another disadvantage is the access of this provider to the potentially sensitive medical data stored by the developed extensions. This data can be used for data mining or sold to 3 rd parties, which is undesirable. While these issues can be solved with a good contract with the service provider, this approach is still undesirable. Finally, hosted virtual communities are usually not open source, and can thus limit the development of applications. The conclusion can be drawn based on the qualitative arguments given that joining an existing MVC service or platform is an unsuitable approach, and the disadvantages of developing a MVC from scratch most likely outweighs the advantages. Thus, the 2 nd approach, extending existing MVC software is most likely the best option. The previously mentioned goal of this research will be made more specific based on this approach taken. The goal of this research is now: To provide advice about the most suitable existing mobile virtual community builder platforms which can be used as a base platform to be extended to develop applications in the field of MVC s for telemedicine to researchers interested in developing these applications 1.4 Research question The previous section defined the goal of this research. From this goal the following research question is derived: Which existing platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine? Sub questions To be able to answer the main research question, Which platform is most suitable to be used as a base platform for a Mobile Virtual Community for telemedicine?, several sub questions need to be answered first. The first aspect that needs to be answered, before determining which platform is most suitable, is what makes a platform most suitable. To be able to do so, the requirements of a MVC for telemedicine need to be determined. This leads to the first question: 5 of 95

12 RQ1: What are the requirements of a MVC for telemedicine? Doing a full research to find the requirements of a MVC for telemedicine such as a case study or interviews is beyond the scope of this research. Fortunately, previous researches have been done on the topic of MVC s for telemedicine. This leads to the following question: RQ2: What resources are available to determine these requirements? Since it is not unlikely the scope and goal of this research differs from the resources, it is possible some requirements are more relevant or less relevant. This leads to the following question: RQ3: How relevant are the requirements mentioned in the research literature? To answer the question which platform is most suitable, first a list of platforms from which the most suitable platform can be chosen needs to be composed. It is possible there are several distinctly different directions to look for possible platforms for a MVC for telemedicine. These directions also depend on the requirements found earlier; platforms from some directions cannot be used to fulfill the requirements. This leads to the following question: RQ4: What are possible directions to look for the base platform? In each direction, several platforms will be available from which the most suitable platform can be chosen. To be able to find the most suitable platform, a list of all potentially suitable base platforms must be composed. This leads to the following question: RQ5: Which platforms are available as a possible base platform for the MVC for telemedicine? Once these platforms have been determined, an evaluation must be done to determine which platform is most suitable. In this research, two evaluations will be done. The first evaluation will be done by taking the previously determined requirements, and use these to evaluate the found platforms. The second evaluation will do a more thorough analysis, and do a case study to determine how well they can be used to be extended with telemedicine functionality. For the first evaluation, to be able to give a statement about which platform is most suitable, first a method must be found to objectively evaluate the platforms. For the second evaluation, first the use cases to be used need to be determined. This leads to the following two research questions: RQ6: Which method should be used to evaluate the platforms using the requirements? RQ7: Which use cases should be used to evaluate the platforms in the case study? As mentioned before, the platform will be used to build extensions to provide telemedicine functionality. Earlier in the research, the advantages of the platforms are already researched. When developing new code, often limitations and problems of the platforms arise which were not clear at the beginning. To avoid giving incorrect advice based on the requirements alone, an evaluation is done to find these limitations and problems. This leads to the following research question: RQ8: Which problems arise when developing extensions with telemedicine functionality on this platform? 6 of 95

13 Finally, by using the results from applying the method to be used to evaluate the platforms using the requirements and the results of the case study, the following question can be answered: RQ9: According to the requirements and case study, which platform is most suitable to be used as a base platform? The research questions will be addressed in this research in numerical order, with the exception of RQ1, which will be answered after the resources of RQ2 are determined. In this section the main research question and several sub questions were given. How these questions will be answered will be described in the approach in the next section. 1.5 Approach This section gives the approach used in this research. First the general approach will be described, which shows the different phases of the research. This is followed by a more detailed description about these phases of the approach. General Approach Figure 2 gives a schematic overview of the approach used in this research: Figure 2: General approach This research starts by composing a list of requirements (1). After this list is composed, a list of existing platforms potentially suitable to be used as base platforms is composed (2). Some of the requirements from (1) will be used in the existing platform evaluation to eliminate unsuitable platforms from the list of possible platforms (3). The platforms that were not eliminated are analyzed using all requirements at (4). A set of real life use cases is composed at the case study at (5), aimed to analyze one or more platforms in detail at (6). The number of platforms analyzed depends on the results of the existing platform analysis (4). Finally, the conclusions are drawn at (7). The overlapping goal of steps 3, 4 and 6 is to decrease the size of the list from step 2 until there is 1 platform left. Each step will more thoroughly investigate a platform compared to the previous step. Since the time spent investigating a single platform will increase each step it is preferred to minimize the number of platforms each step. By using an elimination approach where the number of platforms investigated each step decreases, the total time required is minimized. 7 of 95

14 Requirements phase This research starts by composing a list of requirements to be used for the evaluation and analysis of the existing platforms. No extensive use case composition is done to determine these requirements; instead the requirements are determined by looking into papers with a similar topic. The papers used are researches conducted at this department at the University of Twente. From these papers, the requirements will be taken. However, it is unlikely these papers will have exactly the same goal and scope, so not all requirements will be relevant, and only the relevant requirements will be taken. It is also possible the scope and goal of this research will result into some requirements not mentioned in a previous research. These additional requirements will also be added to the list of requirements. Even after picking only the relevant requirements from the previous researches, not every requirement will be equally relevant. Therefore, every requirement the ones from the previous researches and the ones from our own research will be prioritized on relevance. At the end of this phase, a list of requirements and their priorities is composed, which can be used in the evaluation, analysis and case study phase. At this phase, research questions 1,2 and 3 are addressed. Evaluation phase The evaluation phase starts by composing a list of potential base platforms. During the composition the first set of platforms is already excluded if they are outside the scope of this research and these platforms will not be mentioned in this report. One or more evaluation steps will be used to decrease the size of this list, until the list only consist of platforms that can be used as a base platform. These platforms will be analyzed in the analysis phase. At this phase, research questions 4 and 5 are addressed, and research question 6 is partially addressed. Analysis phase In the analysis phase, a Multi Criteria Analysis (MCA) will be done to determine which platform is most suitable to be used as a base platform. Each requirement will be given a grade depending on how well the platform meets this requirement. The method(s) used in the MCA will give each platform a score. Based on this score, the conclusion of the MCA will be drawn. This result will be verified by checking the values and methods used. At this phase, the remainder of research question 6 is addressed and research question 9 is partially answered. Case study phase Before drawing the final conclusion of this research, which platform is most suitable to be used as a base platform for the MVC for telemedicine, a case study will be introduced to test if the highest scoring platform from the analysis to be used as a base platform is suitable in practice. The goal of this case study is to do a more thorough analysis of the platforms, and to determine if the platforms to build extensions for telemedicine on are suitable. If two or more platforms scored equal in the analysis, the use cases of the case study will be applied to these platforms, and the results of these use cases will determine which platform is most suitable. This phase is implemented by describing a real life scenario, from which the key aspects are taken, which will then be used to derive the use cases, leading to the answer of research question 7. These use cases will then be implemented on a live platform, and the 8 of 95

15 required work and difficulties found are given. Based on these results, research question 8 is answered, along with the remainder of research question 9. Conclusion Based on the results of the results of the analysis phase and case study, the conclusion of the research will be drawn and the research questions answered. Also, a small discussion is done concerning the results of the research and some recommendations are given. 1.6 Thesis Structure Chapter 2 discusses the first phase of this research, the requirements phase. In chapter 3 the list composition of potential platforms and results of the evaluation phase are described. Chapter 4 discusses the results of the analysis phase. In chapter 5, the case study composition and analysis is described. Finally, chapter 6 answers the research questions and draws the conclusion of this research. This chapter also discusses this conclusion and the research done, and provides recommendations where required. 9 of 95

16 2 Requirements 2.1 Introduction This chapter describes the requirements for the MVC for telemedicine and the base platform used to build it. These requirements will then be used in chapters 3 and 4 to evaluate and analyze existing platforms to find the most suitable one. First section 2.2 introduces two papers from which the requirements will be taken. This section also gives the exact scope of the research. Next, section 2.3 describes the approach used for selecting, rewriting and prioritizing these requirements. This approach is carried out and section 2.4 gives the resulting requirements and their priorities. Since the scope of this research is different from these 2 papers, some additional requirements might arise; these are given in section 2.5. Finally, section 2.6 gives a complete list of all requirements with their priorities. 2.2 Scope & Existing papers Existing papers This section gives existing papers in the field of MVC s for telemedicine. If a paper is considered relevant based on its goal and scope, and if the paper has a list of requirements, these requirements are used in this research. The first paper to be explored for requirements is a research done at this university by C. Dulawan [10]. This paper explores how MVC concepts can be applied in doing telemedicine. It is one of the first researches on the concept of MVC s for telemedicine. In the paper, several use cases are introduced, from which requirements are deduced. These use cases, and therefore the requirements, focus on the remote monitoring aspect of a MVC for telemedicine, including monitoring vital signs and sending alarms based on these signs. While vital sign monitoring, being a requirement unique for a telemedicine MVC is outside the scope of this research, some requirements are still useful. The research does not address the concept of using MVC s for group recovery therapy. The second paper to be explored is a requirements analysis deliverable [11] done for the BraveHealth [12] project. The BraveHealth website describes its goal as follow: BRAVEHEALTH proposes a patientcentric vision to CVD management and treatment, providing people already diagnosed as subjects at risk with a sound solution for continuous and remote monitoring and real time prevention of malignant events. One of the components to be developed is a Virtual Community where data from remote monitoring is displayed and various types of support are given. Just like the first paper, a case study is done to discover the requirements. The deliverable is at this moment classified and unpublished. However, since the group where this MSc. thesis research is done is one of the participants of BraveHealth, and thus has access to the deliverable, the requirements can still be used in this research. Especially the BraveHealth deliverable does extensive research to determine the requirements. Another aspect researched in the BraveHealth project, and discussed in [13], is the prediction of user acceptance of the MVC. A questionnaire is given to patients from several focus groups, to determine if and when they would use the MVC. The results of these questionnaires also influenced the use cases used to create the requirements. From these two sources the requirements of the MVC for telemedicine can be acquired. Both sources do a case study from which the requirements are taken, which gives a good base for the determination of 10 of 95

17 the requirements. While this may not result in all the requirements of an MVC for telemedicine, it is a good start. If during the derivation of the requirements it becomes clear some requirements are missing, these requirements are added in section 2.5: Additional requirements. In the next section, the method used to acquire and prioritize these requirements is given. Scope A conclusion from section 1.3 was that extending an existing platform as a base platform is most likely the best approach. It also mentioned two possible directions for a base platform for the MVC for telemedicine; a generic MVC or a MVC specifically designed for telemedicine. MVC s for telemedicine are not widely used at this moment, thus it is unlikely an existing MVC for telemedicine usable as a base platform will be found. Thus, this research will focus on extending a generic MVC as a base platform. The scope on generic MVC s also has an impact on the requirements of the existing base platform and their importance. In the next paragraph existing papers are explored for requirements. These papers are on MVC s for telemedicine and have some requirements unique for the field of telemedicine. Since it is very unlikely requirements unique in the field of telemedicine will be met by the base platform, these requirements will be given either a low priority or removed completely and be deemed outside the scope of this research, which focuses on extending generics MVC s. Another aspect of these papers is developing and deploying mobile applications for this MVC for telemedicine. Since these mobile applications only affect the base platform when communicating with the base platform, any requirements concerning mobile applications besides communicating with the base platform will be considered outside the scope of this research. One final difference in scope is the scale of the project. The BraveHealth project envisioned a large scale application, which also puts requirements on the hardware and software used. This research has a smaller scale, and requirements on the hardware are no longer considered important. 2.3 Approach The previous section gave two resources containing requirements for a MVC for telemedicine. This section describes the method used acquire and prioritize these requirements. From each research, the requirements are looked up and are literally copied into this research. As mentioned in the requirements approach section in section 1.5, not all requirements are equally relevant, and a prioritizing method will be used to denote the importance of each requirement. A two step approach will be used to prioritize the requirements. The first step is to determine if the requirement is at all relevant. A requirement is not relevant if it is outside the scope of this research as defined in section 2.2. If a requirement is relevant, the second step is performed, giving a priority to the requirement. While determining if a requirement is relevant, the motivation why it would be relevant is usually the same as the motivation for the priority of a requirement. Thus, writing both down is redundant and in the report, the result of both steps will be given at the same time. A priority scheme based on the MoSCoW prioritization [14] method will be used to assign priorities to each requirement. The MoSCoW method is a method commonly used in software development for requirement prioritization. Usually, the priorities are determined in consultation with the stakeholders. In this research however, this is not the case. Instead, a motivated estimation of the priority is done for each requirement, and the motivation is given. The MoSCoW method has 4 prioritization levels that can be given to a requirement: M MUST have this. S SHOULD have this if at all possible. 11 of 95

18 C COULD have this if it does not affect anything else. W WON'T have this time but would like in the future. These 4 priorities combined with the step determining if a requirement is relevant leads to the following 5 priorities used in this research: Priority A: Must meet this requirement. These requirements will be used in chapter 3 to evaluate and chapter 4 to analyze existing platforms. Priority B: Should meet this requirement. These requirements will be used in chapter 4 to analyze existing platforms. Priority C: Could meet this requirement, but less important than priority B. These requirements will be used in chapter 4 to analyze existing platforms. Priority D: The MVC for telemedicine should meet this requirement; however, it is not important for the base platform to meet this requirement. These requirements will be used in chapter 5 to help define the scenario from which the use cases are derived. Priority E: This requirement is not relevant (anymore), and will not be adopted in the list of requirements used in this research. Another aspect is to define when a requirement is met, or not met, and what to do if a requirement is partially met. For this research the decision was made that there are three possible options here, either a requirement is met, not met or partially met. To avoid inconsistent results, the decision was made not to further divide partially met requirements, for example into mostly met and mostly not met. Some requirements, due to their definition, can only be met or not met, not partially met. For priority D requirements, which will not be used in the evaluation and analysis but only to help define the setting for the scenario from which the use cases are derived, the decision was made not to define when a requirement is met, since this will not be used. Obviously, requirements with priority E, which are obsolete, do not require the definition when a requirement is met. Before the priorities are given, an operation can be applied to the requirements to make them more suitable for this research. Possible operations are: Redefinition: In some cases a small redefinition of the requirement is preferred to meet the scope of this research, by either adding, removing or rewriting parts of the original requirement. Another possibility for a redefinition is when parts of the requirement are outdated, and need to be updated. If a redefinition is the case, the motivation behind it is given. Merge: If a requirement is present in both researches or if the scope of a previous research is more detailed than this research, multiple requirements can be merged into one more abstract requirement. If a merger is applied, the motivation behind the merger is given. Split: If the scope of this research is more detailed than the scope of the previous researches, it is possible a requirement is split into multiple more granular requirements. Once again, the motivation behind the operation is given when it is applied. 12 of 95

19 2.4 Requirements from previous research papers This section lists and prioritizes the requirements from the previous researches. First the requirements which are taken without any operation are described, followed by the redefined, merged and split requirements. For each of those 4 categories, first the requirements taken from C. Dulawan are analyzed, followed by the requirements from the BraveHealth project. Unmodified requirements This section gives the requirements that did not need a redefinition/merger or split, in other words the unmodified requirements. The following layout is used to describe the requirements, their priority and the motivation behind the priority: Unmodified requirements example Example requirement Motivation behind the priority Requirement fulfilled: When is a requirement fulfilled. Requirement partially fulfilled: When is a requirement partially fulfilled. Requirement not fulfilled: When is a requirement not fulfilled. priority The next table gives the requirements that did not need a modification: Unmodified requirements The platform should allow creation of a sub community. In the introduction, group therapy was mentioned as one of the possible applications for the MVC for telemedicine. To offer effective group support, it must be possible to create the groups to give this support, or sub communities. Without subcommunities, all users would be in 1 community, making it very hard to offer granular support. It is almost impossible to offer group support if the requirement is not met, thus the platform must meet this requirement, giving it priority A. Requirement fulfilled: The platform can create sub communities Requirement partially fulfilled: Requirement not fulfilled: The platform cannot create sub communities The platform should allow creation and management of user profiles. User profiles can improve the social interaction within a (sub) community by allowing users to find other users with the same interests, location or illness. They can also be used to contact a user directly. This allows users to find peers to provide emotional support, which is one of the types of support of a MVC for telemedicine. If this requirement is not met, providing emotional support will difficult, so the platform must meet this requirement, giving it priority A. Requirement fulfilled: The platform can create and manage user profiles. Requirement partially fulfilled: Requirement not fulfilled: The platform cannot create or manage user profiles. The platform should be able to identify who should be alarmed in case of an emergency. Sending an alarm in case of an emergency is one of the requirements mentioned earlier in section 2.2 that are unique for telemedicine and are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. The platform should be able to transfer viewing session without interruption. This requirement refers to the monitoring of vital signs, and being able to view vital signs without interruption. Monitoring vital signs is one of the requirements mentioned earlier in paragraph 2.2 that are unique for telemedicine and are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. The platform should be able to support multiple devices associated with one role. This requirement refers to the monitoring of vital signs, and being able to view vital signs without interruption. Monitoring vital signs is one of the requirements mentioned earlier in paragraph 2.1 that are unique for telemedicine and are beyond the scope of this research. However, for a MVC for telemedicine which can be used for remote monitoring this requirement is still relevant. Therefore it given priority D. These services should at least be present: vital sign delivery service, viewing service and interaction service. It is not useful to put constraints on the minimum of required services at this moment. It should be possible to restrict access to the sub community. In medicine, where information is sensitive, it must be impossible for unauthorized users to view the data shared in this subcommunity. Therefore the platform must be able to restrict access to sub communities, to avoid unauthorized users to access A A D D D E A 13 of 95

20 the data, giving it priority A. Requirement fulfilled: It is possible to restrict access to the sub community to authorized users. Requirement partially fulfilled: Requirement not fulfilled: It is not possible to restrict access to the sub community to authorized users. Access: the BMVCs must be accessible using a desktop, notebook, tablet PCs and SmartPhone. Since all base platforms tested will be web based, and all the devices listed in the requirement should be able to read webpage s, this requirement is a bit superfluous. On the other hand, if a platform does not support one of the devices listed above, it will severely lower its usability. Therefore the platform must meet this requirement, and is given priority A. Requirement fulfilled: The platform is accessible from a desktop, notebook, tablet PCs and SmartPhone. Requirement partially fulfilled: Requirement not fulfilled: The platform is not accessible from a desktop, notebook, tablet PCs or SmartPhone. Translations: There is the need for a translation service. Further decisions are needed so as to determine if this can be done offline or needs to be online (near real time), whether it must be human translation by an authorized translator etc. A translation service can be useful, but since the platform is only intended to be used at this university, at most 2 languages will be used (Dutch and English) and it is no longer mandatory. It could still be useful, since it saves some time in building the MVC that uses multiple languages, for example Dutch and English. However, translating the content into 1 other language is manageable, thus it is given a low priority, priority C. Requirement fulfilled: The platform has a built in translation service Requirement partially fulfilled: Requirement not fulfilled: The platform does not have a built in translation service. Help functionality: users must have the possibility to get help in using the system, either through a context aware help function or via (context aware) help desk. This help functionality is about help in using the system only. If a user does not know how to use the platform, that user will not use all the capabilities of the platform. Having help functionality can extend the users knowledge of the platform and increase the overall usability of the platform. So this is an important requirement. However, since the amount of users will be limited, help can be given outside the platform, making built in help functionality not mandatory. Therefore, since this is requirement is important but not mandatory, the platform should meet it, giving it priority B. Requirement fulfilled: The platform has help functionality services available, and help pages already implemented Requirement partially fulfilled: The platform has help functionality services available, but help pages are available externally or help functionality services are available but not implemented. Requirement not fulfilled: The platform does not have help functionality services available, and no help pages are available externally. Users, especially patients, have full understanding and insight in who is able to read what information about himself or herself, and can exercise control over who is able to see what within the context of a mobile virtual community. This requirement is important, since medical information is privacy sensitive, and a patient has the right to manage this information. Being able to view who is able to read information and exercise control over it is however optional. If the requirement is not met the platform can still be used. Therefore, since it is an important but not mandatory requirement, the platform should meet this requirement, giving it priority B. Requirement fulfilled: Users can read and exercise control over who is able to see what information Requirement partially fulfilled: Information about who can read what information is stored in the database, but is not readily available to the end user and an extension has to be built to makes this read and exercise control over this information Requirement not fulfilled: There is no information available about who is able to see what data. Whenever required, for instance based on an in depth privacy and security analysis, information between endsystems (mobile devices and desktops) is exchanged in a security enhanced application protocol (such as https). Since sensitive medical data may be exchanged, a secure connection is important to guarantee this data cannot be intercepted by a 3 rd party. If this requirement is not met, passwords and sensitive medical information could be intercepted by a 3 rd party, leading to the leakage of privacy sensitive information. Therefore, the platform must meet this requirement, giving is priority A. Requirement fulfilled: HTTPS is supported by the platform, and the pages to be transferred via HTTPS can be customized from the platform. Requirement partially fulfilled: HTTPS is supported, but list of pages to be transferred via HTTPS cannot be customized from the platform. Requirement not fulfilled: The platform cannot be used via HTTPS. Whenever required (again, based on an in depth privacy and security analysis), health related data of patients is stored in a secure manner in the MVC database. Since sensitive medical data may be used and stored, a secure database is important. However, this sensitive medical data can be stored in an external secure database, so it is not important for an existing base platform to meet this requirement. Since it is not crucial but still advantageous for a platform to meet this requirement, the platform could meet this requirement, giving it priority C. Requirement fulfilled: The platform can store data encrypted. Requirement partially fulfilled: There are 3rd extensions available for secure storage. Requirement not fulfilled: The platform does not support secure storage. Using a mobile device(e.g. Tablets) users must be able to be connected to their virtual communities 24/7 This is a requirement on the mobile devices, not on the base platform. Therefore it is not relevant for the requirements, can be removed and is given priority E. A C B B A C E 14 of 95