Using existing software to build a virtual community for telemedicine

feelingmomInternet and Web Development

Dec 7, 2013 (3 years and 9 months ago)

573 views

 
 

Using existing software to 
build a virtual community 
for telemedicine 
 
 
P.G. Hoekerd 
 
University of Twente 
 
Telematics MSc. final thesis 
June 2013 
 
Graduation committee 
Dr. Ir. B.J.F. van Beijnum 
Prof. Dr. Ir. H.J. Hermens 
Dr. Ir. M.J. van Sinderen 
Biomedical Signals and Systems group 
ii 
 
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.   
iii 
 
Table of Contents
 
1
 
Introduction ............................................................................................................................. 1
 
1.1
 
Motivation ........................................................................................................................ 1
 
1.2
 
Background ....................................................................................................................... 2
 
1.3
 
Problem Statement .......................................................................................................... 4
 
1.4
 
Research question ............................................................................................................ 5
 
1.5
 
Approach .......................................................................................................................... 7
 
1.6
 
Thesis Structure ................................................................................................................ 9
 
2
 
Requirements ........................................................................................................................ 10
 
2.1
 
Introduction .................................................................................................................... 10
 
2.2
 
Scope & Existing papers ................................................................................................. 10
 
2.3
 
Approach ........................................................................................................................ 11
 
2.4
 
Requirements from previous research papers .............................................................. 13
 
2.5
 
Additional requirements ................................................................................................ 20
 
2.6
 
Summary ........................................................................................................................ 22
 
2.7
 
Conclusion ...................................................................................................................... 24
 
3
 
Platform selection and evaluation ........................................................................................ 25
 
3.1
 
Introduction .................................................................................................................... 25
 
3.2
 
Search directions ............................................................................................................ 27
 
3.3
 
Platform selection .......................................................................................................... 28
 
3.4
 
Round 1: Quick evaluation ............................................................................................. 31
 
3.5
 
Round 2: Priority A evaluation ....................................................................................... 33
 
3.5.1
 
Elgg .......................................................................................................................... 34
 
3.5.2
 
Dolphin .................................................................................................................... 36
 
3.5.3
 
WordPress – BuddyPress ........................................................................................ 37
 
3.5.4
 
Mahara .................................................................................................................... 38
 
3.5.5
 
Anahita .................................................................................................................... 40
 
3.5.6
 
Drupal – Commons ................................................................................................. 41
 
3.5.7
 
Oxwall...................................................................................................................... 42
 
3.5.8
 
Liferay ...................................................................................................................... 43
 
3.5.9
 
GateIn ...................................................................................................................... 44
 
3.5.10
 
Summary ................................................................................................................. 45
 
3.5.11
 
Discussion................................................................................................................ 46
 
3.6
 
Conclusion ...................................................................................................................... 49
 
4
 
Platform analysis ................................................................................................................... 50
 
4.1
 
Introduction .................................................................................................................... 50
 
4.2
 
Approach ........................................................................................................................ 50
 
4.3
 
Multi Criteria Analysis .................................................................................................... 52
 
iv 
 
4.3.1
 
Priority based linear additive multi criteria analysis .............................................. 52
 
4.3.2
 
MCA conclusion ...................................................................................................... 53
 
4.4
 
Multi Criteria Analysis discussion ................................................................................... 53
 
4.5
 
Conclusion ...................................................................................................................... 58
 
5
 
Case study .............................................................................................................................. 59
 
5.1
 
Introduction .................................................................................................................... 59
 
5.2
 
Case study description ................................................................................................... 59
 
5.2.1
 
Scenario ................................................................................................................... 59
 
5.2.2
 
Use cases ................................................................................................................. 60
 
5.2.3
 
Summary ................................................................................................................. 63
 
5.3
 
Drupal case study ........................................................................................................... 64
 
5.3.1
 
Development environment ..................................................................................... 64
 
5.3.2
 
Use cases ................................................................................................................. 64
 
5.4
 
Liferay ............................................................................................................................. 69
 
5.4.1
 
Development environment ..................................................................................... 69
 
5.4.2
 
Use cases ................................................................................................................. 70
 
5.5
 
Summary ........................................................................................................................ 76
 
5.5.1
 
Development environments ................................................................................... 76
 
5.5.2
 
Evaluation per use case .......................................................................................... 76
 
5.5.3
 
Summary ................................................................................................................. 77
 
5.6
 
Conclusion ...................................................................................................................... 78
 
6
 
Conclusion, discussion and recommendations ..................................................................... 79
 
6.1
 
Conclusion ...................................................................................................................... 79
 
6.2
 
Discussion ....................................................................................................................... 82
 
6.3
 
Recommendations ......................................................................................................... 83
 
7
 
Terminology ........................................................................................................................... 85
 
8
 
Bibliography ........................................................................................................................... 86
 
9
 
Appendices ............................................................................................................................ 90
 
9.1
 
Appendix A: Primary and secondary sources ................................................................. 90
 
9.2
 
Appendix B: Search results ............................................................................................. 92
 
9.3
 
Appendix C: Requirement evaluation results ................................................................ 94
 
9.4
 
Appendix D: Analysis results .......................................................................................... 95
 

List of figures
Figure 1: MVC platform component overview ............................................................................................. 2 
Figure 2: General approach .......................................................................................................................... 7 
Figure 3: Evaluation approach .................................................................................................................... 25 
Figure 4: Search approach .......................................................................................................................... 26 

 
Figure 5: Platform composition summary .................................................................................................. 31 
Figure 6: Quick evaluation summary .......................................................................................................... 33 
Figure 7: Elgg ............................................................................................................................................... 35 
Figure 8: Dolphin ......................................................................................................................................... 36 
Figure 9: WordPress .................................................................................................................................... 37 
Figure 10 :Mahara ....................................................................................................................................... 39 
Figure 11: Anahita ....................................................................................................................................... 40 
Figure 12: Drupal ......................................................................................................................................... 41 
Figure 13: Oxwall ........................................................................................................................................ 42 
Figure 14: Liferay ......................................................................................................................................... 43 
Figure 15: GateIn ......................................................................................................................................... 45 
Figure 16: Priority A requirements evaluation summary ........................................................................... 49 
Figure 17: MCA approach ........................................................................................................................... 51 
Figure 18: Priority based MCA .................................................................................................................... 53 
Figure 19: Platform score per priority ........................................................................................................ 55 
Figure 20: Platform analysis summary ........................................................................................................ 58 
Figure 21: Drupal module file structure ...................................................................................................... 64 
Figure 23: A Simple hello world use case in Drupal .................................................................................... 65 
Figure 22: Drupal use case 1 implementation ............................................................................................ 65 
Figure 25: Drupal roles ................................................................................................................................ 66 
Figure 24: Drupal use case 2 implementation ............................................................................................ 66 
Figure 26: Drupal use case 4 implementation, getting group users ........................................................... 67 
Figure 27: Drupal use case 4 implementation, getting user roles .............................................................. 67 
Figure 28: Drupal use case 5 implementation ............................................................................................ 67 
Figure 29: Drupal use case 6 implementation ............................................................................................ 68 
Figure 30: Drupal use case 7 implementation ............................................................................................ 69 
Figure 31: File structure of a Liferay project with 1 portlet ........................................................................ 70 
Figure 32: A simple Liferay portlet .............................................................................................................. 71 
Figure 33: Liferay use case 1 implementation, view.jsp ............................................................................. 71 
Figure 34: Liferay use case 4 implementation, getting group id ................................................................ 73 
Figure 35: Liferay use case 4 implementation, display users and roles ...................................................... 73 
Figure 36: Liferay use case 5 implementation, developer code ................................................................. 74 
Figure 37: Liferay use case 5 implementation, complete code .................................................................. 74 
Figure 38: Liferay use case 6 implementation, Liferay‐portlet.xml ............................................................ 75 
Figure 39: Case study evaluation summary ................................................................................................ 78 
Figure 40: Elimination results ..................................................................................................................... 81 
 
List of tables
Table 1: MVC component description .......................................................................................................... 3 
Table 2: Unmodified requirement from previous researches .................................................................... 16 
Table 3: Redefined requirement from previous researches ....................................................................... 17 
Table 4: Merged requirement from previous researches ........................................................................... 18 
vi 
 
Table 5: Split requirements from previous researches ............................................................................... 19 
Table 6: Additional requirements ............................................................................................................... 22 
Table 7: Base platform requirements ......................................................................................................... 24 
Table 8: Platform selection search terms ................................................................................................... 29 
Table 9: Potential platforms ....................................................................................................................... 30 
Table 10: Community builders & CMS with community builder extension ................................................ 32 
Table 11: Enterprise portals ........................................................................................................................ 32 
Table 12: Abbreviated requirements .......................................................................................................... 34 
Table 13: Elgg priority A evaluation ............................................................................................................ 35 
Table 14: Dolphin priority A evaluation ...................................................................................................... 37 
Table 15: WordPress priority A evaluation ................................................................................................. 38 
Table 16: Mahara priority A evaluation ...................................................................................................... 39 
Table 17: Anahita priority A evaluation ...................................................................................................... 40 
Table 18: Drupal priority A evaluation ........................................................................................................ 42 
Table 19: Oxwall priority A evaluation ........................................................................................................ 43 
Table 20: Liferay priority A evaluation ........................................................................................................ 44 
Table 21: GateIn priority A evaluation ........................................................................................................ 45 
Table 22: Platform roles evaluation ............................................................................................................ 47 
Table 23: Platform number of bug reports ................................................................................................. 48 
Table 24: Dominance analysis ..................................................................................................................... 56 
Table 25: Drupal and Liferay dominance analysis ...................................................................................... 56 
Table 26: Per requirement dominance analysis ......................................................................................... 58 
Table 27: Use case summary....................................................................................................................... 63 
Table 28: Case study use case results ......................................................................................................... 77 
   1 of 95 
 
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 
   2 of 95 
 
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. 
 
   3 of 95 
 
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 
services 
The web presentation services consist of the MVC access platform, and any other 
website related to the MVC, but not integrated in the MVC access platform. 
Data acquisition 
services 
The data acquisition services consist of components that provide functionality to 
process acquired data. It can communicate with the base platform for user 
authentication. 
MVC access 
platform 
 
The MVC access platform is the presentation component of the web service. When 
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 
extensions 
 
Developed extensions are newly developed applications specifically designed to 
add telemedicine functionality to a MVC. These extensions extend the base 
platform, and do not work independent from the base platform. 
Data acquisition 
service 
The data acquisition service collects biomedical data from the sensors of the 
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 
database 
 
The standard database is general purpose database required and used by the base 
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 
source 
Any data source outside the scope of the project. External data sources are usually 
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 
   4 of 95 
 
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. 
   5 of 95 
 
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: 
 
   6 of 95 
 
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? 
   7 of 95 
 
 
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.  
 
   8 of 95 
 
 
 
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 
   9 of 95 
 
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. 
   
   10 of 95 
 
 
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 patient‐
centric 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 
   11 of 95 
 
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. 
   12 of 95 
 
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. 
 
 
 
   13 of 95 
 
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 requiremen
t
 
priority 
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. 
 
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  sub‐
communities, 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 
p
rofiles.

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 emergenc
y
.

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 
p
resent: 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‐communit
y
.

In medicine, where information is sensitive, it must be impossible for unauthorized users to view the data shared in this sub‐
community. Therefore the platform must
 be able to restrict access to sub‐communities, to avoid unauthorized users to access 
   14 of 95 
 
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. 
A
ccess: 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 of
f

line 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 contex
t
‐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 rea
d
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. 
   15 of 95 
 
User‐Interaction  modes:  the  user  interface  must  support  reques
t
‐response,  solici
t
‐response,  publish‐subscribe,  one‐way  and 
notifications. In other words, all standard interaction modes need to be supported. 

A client will communicate with the base platform in 2 possible ways, by using a browser to view the base platform or by using 
a  dedicated  application  that  uses  web  services.  A  dedicated  application  would  be  custom  made  and  would  not  impose  any 
additional  requirements  on  the  base  platform,  besides  the  availability  of  webservices,  which  is  covered  by  another 
requirement.  In  most  cases,  a  browser  only  supports  request‐response,  making  it  impossible  to  meet  this  requirement,  and 
thus making this requirement obsolete
. Therefore it is given priority E. 
A
lso, mixed (i.e. simultaneous) access must be supported.

This requirement is considered to specific and therefore outside the scope of this research. Thus it is given priority E. 
Various types of support must be supported, for patients the four basic types of support relevant are: informational support, 
instrumental support, emotional support and feedback support. 

Giving various types of support 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. 
Mobile  device:  For  the  access  and  interaction  with  the  Mobile  Virtual  Community  Platform  a  dedicated  mobile  application 
needs  to  be  deployed  on  the  mobile  device  in  use  so  as  to  take  optimal  advantage  of  the  functionalities  supported  by  the 
platform (such as timely notifications and the like).  

While this is an important requirement for a successful MVC for telemedicine, it is not an important requirement for the base 
platform.  Creating  mobile  applications  for  the  MVC  is  outside  the  scope  of  this  research,  which  focuses  on  finding  a  base 
platform to be extended. Deploying a mobile application does not depend on this base platform. Therefore, since it is outside 
the scope of this research, but still useful for an MVC for telemedicine, it is given priority D. 
Mobile  device:  In  order  to  be  implementation  technology  independents,  standardized  protocols  for  the  interaction  and 
communication between mobile device and the Virtual Community Platform are required. 

Web based communication between the mobile device and VC is already standardized. Any non web based communication, 
such as communication between a dedicated mobile application and the base platform will be completely developed by the 
application developers. Therefore, since it is outside the scope of this research, but still useful for an MVC for telemedicine, it 
is given priority D. 
Mobile device: For mobile applications, the interaction / communication must be based on WSDL and SOAP. REST is considered 
a potential candidate for the (near) future. 

One  of  the  functionalities  of  a  MVC  for  telemedicine  is  to  gather  instrumental  data.  This  data  is  acquired  by  a  body  area 
network (BAN) and collected at a mobile device. To communicate between this mobile device and the MVC platform, a SOA 
should be used. By using a standardized protocol, extending and managing extensions built for the MVC become easier. If the 
base platform would already support SOA’s, this would decrease the time required to build these extensions. It is however not 
mandatory to use a SOA for communication between the mobile device and the base platform. Therefore, since it is preferred, 
but not required, the platform should meet this requirement, giving it priority B. 
Requirement fulfilled: The platform has support for SOAP/REST web services, and web service functions available for the core 
functionality of the platform. 
Requirement  partially  fulfilled:  The  platform  supports  custom  SOAP/REST  web  services,  but  no  web  services  are  already 
implemented. 
Requirement not fulfilled: The platform does not support SOAP/REST. 
Mobile  device:  Mobile  application  development  must  be  fully  aligned  with  the  requirements  of  the  other  modules  in  the 
project. E.g. It is known that running C# and Java application components on Windows mobile devices gives poor performance. 

As  mentioned  in  the  scope  definition  in  chapter  in  section  2.2,  any  requirements  concerning  mobile  applications  are 
considered outside the scope of this project. Therefore it is given priority E. 
Mobile  device:  Mobile  Devices  we  use  and  have  used  in  the  past  for  development  testing  and  Telemedicine  trials  are:  HTC 
Smart Phones (various types), QTek and iPAQ. 

As  mentioned  in  the  scope  definition  in  chapter  in  section 2.2,  any  requirements  concerning  mobile  applications  are 
considered outside the scope of this project. Therefore it is given priority E. 
The Virtual Community Platform will run on multiple application / web servers.

The  scope  of  the  research  originally  describing  this  requirement envisioned  a  large  scale  deployment  of  the  MVC  where 
scalability was an issue. This research focuses on finding a base platform to develop new extensions for research on MVC’s for 
telemedicine.  This  research  on  MVC’s  for  telemedicine  is  small  scale,  and  scalability  is  no  longer  an  issue.  Therefore,  this 
requirement has become obsolete, and is given priority E.  
The Virtual Community Platform will be realized using J2EE technolog
y

This requirement was introduced in the original research for 2 reasons, scalability and remote management. In the motivation 
of the previous requirement it was described why scalability is no longer an issue. The reason to require remote management 
has the same motivation; in a large scale environment it improves scalability. Since this is no longer an issue, this requirement 
has become obsolete
, and given priority E. 
The preferred application servers and database 
 
This requirement is moved to the additional requirements.
Servers in use for the software developmen
t
 

This requirement was introduced to specify the hardware of the servers to host the MVC for telemedicine. Since this research 
focuses on a base platform which runs on any x86 PC, this requirement is no longer relevant
, and is given priority E. 
Software Development Environments. 
E
   16 of 95 
 
The base platform does not depend on a software development environment used to build new extensions, and therefore this 
requirement is no longer relevant
 and given priority E. 
Table 2: Unmodified requirement from previous researches 
Redefined requirements 
This section gives the requirements that required a redefinition due to the difference in scope between 
the original research and this research or the fact they were outdated.  
 
The following layout is used to describe the redefined requirements, the reason behind the redefinition, 
the new requirement, its priority and the motivation behind the priority: 
 
Redefined requirements example 
 
Example requiremen
t
 
priority 
Motivation behind the redefinition 
New requiremen
t
 
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. 
 
The following table gives the results of this redefinition: 
 
Redefined requirements
The platform should provide synchronous or asynchronous communication service such as chat service and instant message
for inviting community members to join sub‐community.

This requirement will be made more abstract to not limit the type of communication used to invite community
members.
New requirement: The platform should be able to send invitations to users to join a sub community.
By sending invitations to users the opportunity is given for them to decline the invitation to join a community.
Furthermore, they are notified they can join a sub community. This requirement is not mandatory, since this the
platform will be used on a small scale, and other methods can be used to inform a user to join a sub community.
However, meeting this requirement is still an advantage, and the platform should
meet this requirement, thus giving it
priority B.
Requirement fulfilled: The platform can send invitations to any user to join a sub community.
Requirement partially fulfilled: The platform can send invitations to users to join a sub community, but can only send
them to a specific group of users, or only a specific fixed group of users can send the invite.
Requirement not fulfilled: The platform does cannot send invitations to users to join a sub community.
The platform should provide asynchronous communication service such as email for inviting non‐community members to
join the main community.

This requirement will be made more abstract to not limit the type of communication used to invite community
members.
New requirement: The platform should be able to send invitations to users to join the main community.
By sending invitations to users the opportunity is given for them to decline the invitation to join a community.
Furtermore, they are notified they are invited to join a MVC. This requirement is not mandatory, since this the platform
will be used on a small scale, and other methods can be used to inform a user to join the virtual community. However,
meeting this requirement is still an advantage, and the platform should
meet this requirement, thus giving it priority B.
Requirement fulfilled: The platform can send invitations to any user to join the platform.
Requirement partially fulfilled: The platform can send invitations to users to join the platform, but can only send them to
a specific group of users, or only a specific fixed group of users can send the invite.
Requirement not fulfilled: The platform does cannot send invitations to users the platform.
User Roles: The following user roles must be supported by the BMVC Platform: patient, cardiologist, therapist, nurse, family
member, and friend.

By not limiting the user roles, flexibility will be increased, and does not impose limitations on the platform later on.
Therefore, the requirement is made more abstract to not limit the user roles.
New requirement: Different user roles must be supported by the BMVC platform, including, but not limited to, patient,
cardiologist, therapist, nurse, family member, and friend.
Restricting access to sensitive medical data is an important requirement of the MVC for telemedicine. By introducing
different roles, it becomes easier to manage access control to sensitive data. Therefore the platform must
meet this
requirement, and it is given priority A.
Requirement fulfilled: The platform can create custom roles.
Requirement partially fulfilled:
   17 of 95 
 
Requirement not fulfilled: The platform does cannot create custom roles.
Ease‐of‐use / usability: The user‐interface must be intuitive and easy to use, short learning curve is required.

To meet this requirement, a UI that meets this requirements must be developed. This is not a requirement on the
platform by itself. However, to not be limited in the development of this UI and end up with a UI that does not meet the
requirement mentioned above, the platform must have the ability to fully customize the UI.
New requirement: The platform must have the ability to fully customize the UI
At this moment it is not completely clear what applications will be developed in this project. By having a fully
customizable UI, extension developers will not be limited by the UI later on in the project.
Requirement fulfilled: To our knowledge, every aspect of the UI of the platform is customizable
Requirement partially fulfilled: The platform has some small limitations regarding the customization of the UI.
Requirement not fulfilled: The platform has clear limitations regarding the customization of the UI.
User role, skills, age and gender may affect the user interface requirements. Usability must be evaluated objectively and
quantitatively.

This requirement will be made more abstract; it is very unlikely existing platforms have the ability to change the UI
according to age or skills.
New requirement: : The platform must have the ability to have user specific UI’s
Some of the potential users of the MVC are elderly people with decreased visual abilities. Those users require a user
specific UI with for example increased font size to use the MVC platform more effective. If a platform has the ability to
create custom UI’s per user, an extension can be made to set those custom UI’s according to age/skill, meeting the
original requirement. Therefore this is a requirement that must
be met by the platform, and it is given priority A.
Requirement fulfilled: The platform has the ability to have user specific UI’s.
Requirement partially fulfilled:
Requirement not fulfilled: The platform does not have the ability to have user specific UI’s.
Table 3: Redefined requirement from previous researches 
Merged requirements 
This section gives the requirements that required a merger. A merger was applied when a requirement 
was present in both researches or if the scope of a previous research is more detailed than this research. 
 
The  following  layout  is  used  to  describe  the  merged  requirements,  the  reason  behind  the  merger,  the 
new requirement, its priority and the motivation behind the priority: 
 
Merged requirements example 
 
Example requiremen
t
 
A
?
Example requirement B 
…. 
Priority 
of new 
requirem
ent 
Motivation behind merger 
New 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. 
 
In the next table, the results of the mergers are given: 
 
Merged requirements 
 
 The  platform  should  allow  configuration  of  sub‐community  such  that  preferences  and  constraints  can  be  made 
regarding roles and services. 
 The platform should be able to store the preferences and constraints imposed on the created sub‐community 

Since these 2 requirements are almost equal, they will be merged into the following requirement.
New  requirement:  The  platform  should  allow  configuration  of  sub‐community  such  that  preferences  and  constraints  can  be 
made and stored regarding roles and services. 
In  medicine,  where  information  is  sensitive,  it  is  very  important  to  put  constraints  on  information provided  by  services  and 
who  is  able  to  view  and  modify  this  information.  If  this  requirement  is  not  met,  granular  access  to  roles  and  services  is 
impossible, and unauthorized access to these roles and services could be possible. Therefore the platform must
 be able to put 
constraints on the roles and services in a sub‐community, giving it priority A. 
Requirement fulfilled: The platform has the ability give custom privileges per role within a sub‐community.