# Development of Novel eHealth Services for Citizen Use
— Current System Engineering vs. Best Practice in HCI

Isabella Scandurra, Jesper Holgersson, Thomas Lind, Gunilla Myreteg

► To cite this version:

Isabella Scandurra, Jesper Holgersson, Thomas Lind, Gunilla Myreteg. Development of Novel eHealth Services for Citizen Use – Current System Engineering vs. Best Practice in HCI. 14th International Conference on Human-Computer Interaction (INTERACT), Sep 2013, Cape Town, South Africa. pp.372-379, 10.1007/978-3-642-40480-1_24. hal-01501755

HAL Id: hal-01501755

https://inria.hal.science/hal-01501755

Submitted on 4 Apr 2017

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
# Development of Novel eHealth Services for Citizen Use –
Current System Engineering vs. Best Practice in HCI

Isabella Scandurra¹, Jesper Holgersson², Thomas Lind¹ and Gunilla Myreteg¹

¹ Uppsala University, ² University of Skövde, Sweden

{Isabella.Scandurra, Thomas.Lind}@it.uu.se,
Jesper.Holgersson@his.se, Gunilla.Myreteg@fek.uu.se

**Abstract.** Many new public eHealth Services are now being developed. Often a conventional customer-vendor process is used, where the customer is a public authority, e.g. a county council, and the vendor a commercial actor, e.g. an IT development company. In this case study the engineering process regards a novel eHealth service aiming to provide patients with online access to their electronic health record. A complicating factor in conventional customer-vendor processes for public e-services is that “the future user could be anyone”. In the light of best practice in Human-Computer Interaction, this study examines the joint effort of the customer and vendor when developing novel services for citizen use. The results include delimiting factors, recommendations for public authority customers and proposed new actions for the research agenda.

**Keywords:** user participation, public e-health services, e-government, electronic health records, system development methods, collaborative design, Scrum.

## 1 Introduction

In present study, health information is brought to the citizen via online public eHealth services on home- or mobile devices. One expectation of public eHealth services in general is to make patients more involved in their own health and empowered in their relationship with caregiver organizations [1]. Consequently, many new eHealth services with the aim to provide citizens with health information are currently being developed in Western Europe by both public healthcare providers and industry. One example is to provide patients with online access to their own electronic health record (EHR). Such a service can be seen as a public e-service which is a part of the e-government imperative. To date, main goals with e-government have been to reduce costs and time needed to provide services to citizens [2]. As a result, public e-services have mainly been developed from an internal government perspective, and external user considerations have been given little attention [3]. Studies show that neither public authorities nor citizens benefit from the introduction of such public e-services [2].
It is evident that increased knowledge of external user needs is essential for suc-
cessful deployment of public e-services [4] and there is a growing interest for citizen
centeredness when developing public e-services in both governmental strategic doc-
uments [5] as well as in research [3]. However, it must be noted that user participation
in public e-service development is challenging to put into practice. Public e-service
development most often has to deal with a heterogeneous target group, i.e. all citizens
[6]. Furthermore, citizens cannot be obliged to participate; their participation is volun-
tary, and performed besides their ordinary duties. Finally, procurement legislation and
slim customer-vendor processes hamper use of user-centered requirement analyses.
Consequently, and also due to traditional patterns, the process to develop public e-
services is often based on conventional system engineering where future users are not
involved in the development process. Public eHealth services provide no exceptions.

Present study adheres to Cooperative design [7, 8] as one of the Human-Computer Interaction (HCI) research theories that regards system development with user partic- ipation and that considers design a social process [9]. From research literature we know that usability aspects should be brought in early in the development process [9, 10]. Previous research also presents several methods to engage users in the future, like role playing and future workshops [9, 11]. Other methods to bring future needs analy- sis into system development are iterative prototyping and scenario-based design [8]. The latter is a well-used model in Participatory Design, also known as the Scandina- vian tradition, developed since the 1970’s. [7]

The degree of user participation may vary. Regardless of activation degree, in co-
operative design developers and practitioners/users are seen as active cooperating
partners aiming to reduce uncertainty and risk in development of novel systems where
no detailed conception of exactly which future needs should be supported and in
which way [9, 11]. Also in User-Centered Design (UCD) [12, 13] active participation
of users is preferred; there are however other methods and techniques to apply when
potential end-users are not accessible, such as personas to shape future users [14],
inspection methods to evaluate an interface [15] and use of representatives for real
users [10, 13, 16]. In the light of best practice from the HCI domain, the purpose of this
study was to investigate the actual development process of the customer and vendor
when developing novel eHealth services for citizen use: How did customers from a
county council and IT-developers from industry collaborate to jointly develop a pub-
lic e-service for a third party, i.e. patients or citizens? To what extent were best prac-
tice-methods from HCI used in the development of this novel public eHealth service?

## 2 Methods and Materials

The studied project SUSTAINS<fnref n="1" />, is a European Union (EU) financed collaboration
that aims to develop and deploy different regional eHealth services on 16 sites in 11
European countries by 2014. At the start of SUSTAINS in 2012, the majority of the
partners had already initiated some development and results are now emerging. The

<footnote n="1">¹ SUSTAINS http://www.sustainsproject.eu/, retrieved 2013-05-15</footnote>
County Council of Uppsala (LUL) in Sweden is coordinator of the EU-project and subject to this case study. The clinical eHealth services in LUL enable patients in the county to access and read their EHR, containing medical notes, drug prescriptions, medical lab results, diagnoses and referrals [1].

Development of these public e-services was performed in 2011-12 in a customer-vendor setting. LUL (the customer) was the initiator of this development and owner of the resulting eHealth services. The IT Company (the vendor) engaged in development of the eHealth services at LUL had previously been assigned to develop some of the predecessors of this current version. In November 2012 the eHealth services were made available to all, approx. 200 000 patients within LUL, following a minor launch in August limited to LUL employees (also considered patients) for testing purposes. Recently (in March 2013) a national strategy decision was made to deploy LUL eHealth services nationally; to provide all Swedish citizens with online access to their EHRs. This fact increased the interest to further study how novel eHealth services reach a heterogeneous target group, spread over an entire country, of different ages, education, health status and interests to use the services or to participate in the development process.

## The study: Research Team Evaluators and Methods

An action research project (DOME<fnref n="2" />) was created by 16 nationally spread researchers to perform independent studies with multidisciplinary perspectives on the SUSTAINS EU-project. The four authors are members of DOME and each with an expertise in research areas related to eHealth: health informatics & HCI (IS), e-government & cooperative design (JH), IT & deployment processes (TL), organizational change & management control (GM).

When the research project was initiated (August 2012), the SUSTAINS project had already established a customer-vendor organization and current version of eHealth services was being developed. The selected data collection method was therefore to perform semi-structured interviews with SUSTAINS members from both sides. Three roles from the customer; project manager, project owner and medical advisor, were matched to the vendor's development manager and two usability experts. Six interviews explicitly regarding the development process (table 1) were recorded and followed up by complementary questions and answers by face-to-face contact, phone as well as e-mails containing project documentation, requirements and system overviews from the vendor.

<table><caption>**Table 1.** Respondents from the customer-vendor organization of SUSTAINS.</caption><thead><tr><td>Respondents</td><td>Reference in text</td><td>Affiliation</td><td>Length of interview</td></tr></thead><tbody><tr><td>Project Manager</td><td>R1</td><td>Customer</td><td>60 min</td></tr><tr><td>Project Owner</td><td>R2</td><td>Customer</td><td>120 min</td></tr><tr><td>Medical Advisor</td><td>R3</td><td>Customer</td><td>90 min</td></tr><tr><td>Development manager</td><td>R4</td><td>Vendor</td><td>90 min</td></tr><tr><td>Usability expert 1</td><td>R5</td><td>Vendor</td><td>90 min</td></tr><tr><td>Usability expert 2</td><td>R6</td><td>Vendor</td><td>60 min</td></tr></tbody></table>

<footnote n="2">² http://www.it.uu.se/research/hci/dome/index.php?lang=1, retrieved 2013-05-15</footnote>
The recorded material was transcribed and analyzed by all four researchers using a content analysis model where the development process of the system was described according to the Systems Development Life Cycle (SDLC) [17]. This model describes the development process as constituted of three phases: initial; with various analyses, intermediary; system is realized, and finally; system is put to practice.

## 3 Results: Current System Engineering vs. Best Practice in HCI

The actual process of SUSTAINS development is compared to best practice methods and key principles in HCI and displayed in table 2. The initial phase (1) of SDLC concerns preliminary analyses, systems analyses, and requirements specifications (future users are identified and the project is defined with regard to its scope and expected outcome), the intermediate phase (2) deals with systems design and systems development (the system is realized), and the final phase (3) concerns integration, testing, installation and deployment (the system is put to practice).

<table><caption>**Table 2.** Initial (1), intermediate (2) and final phase (3) of SUSTAINS and Best practice in HCI</caption><thead><tr><td>Current system engineering process</td><td>Best practice in HCI (a selection of key principles)</td></tr></thead><tbody><tr><td>(1) A type of "Knowledge in the head": customer representatives had previously studied pilot projects in Denmark, Estonia and the United States, as well as experiences of a predecessor of SUSTAINS, implemented at a private practice in LUL. These experiences were not systematically documented nor reported in the form of a systems analysis or similar. Future users were generally identified as inhabitants in the county. System specification existed in terms of an EU-consortium negotiation of a list of 12 features that should create the basis for the novel eHealth system. "Black box-approach": There were no specified goals other than realizing the features listed by the EU-consortium. The scope was defined in terms of planned launch date, first access in summer of 2012, and a final launch in autumn of 2012. Neither users, nor developers were actively involved in the initial analyses of the novel eHealth services.<br>(2) Communicating mental models: The vendor's development team got involved and started by designing a prototype based on the 12 features. It needed to be redesigned with respect to a user perspective. Usability experts were called to assist; they performed a heuristic evaluation, a conceptual model and created 3 personas; an old demented woman and</td><td>a) Identify main target groups for the intended service, b) categorize future users/most frequent users [9]. c) Analyze thoroughly potential users to elicit user requirements in terms of functionality and usability [7, 12]. d) Use requirements and project goals to steer development [9-11, 16] e) Stated goals and expected outcome are basic tools to create formative and summative evaluations [10, 18]. f) Participation of real users is preferred to decrease uncertainty and risks related to system acceptance, and a number of methods are presented in Introduction [7-9].<br>g) Actively involve future users in design activities. The degree of user participation may vary, h) from an advisory role as a part of design team [7], using e.g. future workshops [11] i) to a more representative role during testing, prototyping and similar user-centred</td></tr></tbody></table>
Current system engineering process (Cont'd)

her relatives, a disabled child and his parents, and a
woman with multiple diagnoses. Results were deliv-
ered to the customer that accepted to rebuild the
prototype. *Changing requirements:* The vendor used
Scrum; an agile software development framework
[19]. The development manager (i.e. scrum master)
took the task to turn vague specifications into practi-
cally solvable requirements of the novel system. The
Scrum process used iterations of three weeks, each
ending with a customer demonstration using personas
to get feedback for improvements and acceptance of
each functionality. Users were not systematically
incorporated in development activities but a focus
group test day with patient organizations was a man-
datory step in the EU-project. It is not clear wheth-
er/how this day was analyzed to improve the services.
The vendor managed to simulate user participation
when the customer assumed the role of user repre-
sentative using each of the personas during demos.

(3) *Practice in practice* Only a few tests were carried out by the customer. The launch in August 2012 giving access to employees in LUL was a non-systematic test as each employee was free to use the system in the way she wanted. There was no systematic way of collecting reactions or questions from the users apart from a provided e-mail address as an option to feed back experiences. This option was sparsely used by the employees and no end-user education was provided. At service launch in November 2012, the same feedback system was used.

Best practice in HCI (a selection of
key principles)

activities [9, 10, 13, 16]. j) use *mock-ups*
[9] *user scenarios and prototypes* to
trigger discussion around possible
future technologies. k) Incremental
development or *iterative prototyping* is
advocated to gradually establish under-
standing between users and developers.
(l) When potential end-users are not
accessible other UCD-methods like
*inspection methods* with guidelines
[15], user representatives or (m)
*personas* [14] should be applied.

n) Actively involve future users in evaluations and tests regarding GUIs as well as workflows and functionality [13] o) Active user participation in these stages increases the likelihood for successful deployment. If real users are not accessible, there are other formative and summative evaluations to perform; with or without usability experts [12, 18]. p) *End-user education* is important.

4 Discussion and Conclusion

**The SUSTAINS case:** Analysis of current case has shown that HCI best practice was not followed by the customer for any of the three phases. Overall, the project applied a scarce amount of user participation. “The users’ needs were known to some extent by the aid of a survey conducted in 1999 and by the experiences made in the private general practice” (R2) Instead of an inventory among patients today, the customer (particularly the project owner) tried to take on the role of a future end-user based on the reasoning that it was future end users’ needs which were of importance: “An average patient of today cannot know what she needs and demands from a future eHealth service system, as her views on and ideas of health and health systems will change,
along with her own behavior". Moreover, no stated project- or effect goals made de-
velopment and evaluation difficult. The logic was, that "if a stated goal is invalid
according to a future user it will not matter if the system can fulfill the goal or not".
According to HCI best practice, that uncertainty can be decreased using different user
centered methods and techniques.

The vendor was only involved in the intermediate phase of the project regarding
development of the services from specifications provided by the customer. Fortunate-
ly, the customer was supported by the vendor in handling some end-user issues and
the moving targets. Use of an agile development method brought the common under-
standing of expected results forward as the customer collaborated closely with the
vendor's development team in frequent sprint demos. Further, an initial inspection
evaluation led to redesign of the entire prototype as well as creation and use of three
personas during development and sprint demos [19]. The usability aspects could be
further refined, in many cases usability was neglected by the system's owner: "As far
as I remember no one was responsible for usability aspects" (R5). "We have made no
usability testing of the system" (R6) and currently "no one knows whether the eHealth
services are useful or only an online service" (R5).

**Recommendations to public authority customers:** Although research has long advocated cooperative design methodologies, current public e-service projects are still technology-driven, instead of focusing on potential user needs. Use of existing and modified methods and techniques from the field of HCI as referenced here are of great value. In order to grasp this knowledge, it may be wise to incorporate HCI experts, not only from the vendor, but also internally, to establish a proper know-how of how to involve users to gain value out of the participation. In industry, usability experts are engaged in other projects, and only when called for their knowledge will be available for e-Government projects. It is therefore important to build in usage considerations early in planning and procurement documents, as well as working towards leaving conventional customer-vendor processes in favor of cooperative and agile methods. When HCI knowledge lacks at the customer end, which is not rare in healthcare, the developer must be given a mandate to handle these issues. In current case, the customer was led into development methods and processes selected by the vendor, in order to jointly develop a public e-service. In our opinion this project was saved by applying evolutionary prototyping, a thorough inspection evaluation and use of personas, where the customer meritoriously played user representatives using the 3 personas during iterative demos. However, working with future user-methodologies in a cooperative manner increases the likelihood for successful deployment according to best practice.

**Proposed new actions for HCI research agenda:** By this study we inform the HCI domain where practice really is standing, and we propose a call for action, to support public authorities/public care providers by leading them towards a collaborative and user-centered development environment in an action research setting.

Constructive evaluations of novel eHealth services need to be performed, not only
usability tests in a user context in current project, but in all projects. HCI researchers
could assist e.g. in a triple helix-constellation with public sector and industry to build
e-services that meet future users' needs and possibly saving resources in the society.
Moreover, defined goals are needed. In this case e.g. how the system is intended to
contribute to the patients' well-being, how or how much the system should ease the
pressure on different services provided by healthcare today, or what impact the new
eHealth services should have on the workload of certain clinical staff. Support from
research in creating e.g. efficiency goals would benefit public e-service projects.

There is a need for educational projects to educate the customer to handle devel-
opment processes with public user (citizen or patient)-centered perspectives. HCI
researchers would also do well as mediators between customers, users and developers.

Neglecting future users and usability aspects is not unique for the studied project,
on the contrary. There are recognized delimiting factors that e-government initiatives
are associated with and that the HCI community could study and propose e.g. guide-
lines for. Compared to e-services developed by commercial actors, public e-services
must encompass both economic and democratic values at the same time as public
administrations are regulated by laws to a large extent [20]. Being a public administra-
tion also brings the responsibility to provide e-services that provide clear benefit to
the citizens since there is seldom an option to select another similar public e-service;
they simply do not exist [21]. At last, users of public e-services are citizens with cer-
tain constitutional rights. Public e-services cannot exclude any user groups although
they are not a majority of the users, instead all future users must be considered, taking
into account different disabilities, geographical limitation, and language issues [22].
These delimiting factors make user participation in public eHealth service develop-
ment a challenging and complex activity and best-practice methods are needed to
support public e-service development. Future work is to further examine which HCI
methods, and to what extent HCI methods, can support the process of empowering
patients and making them more involved in their own health.

Acknowledgments

The DOME-project is financed by VINNOVA (2012-02233), Swedish Agency for
Innovation Systems. SUSTAINS is supported by the European commission (No
297206). Special thanks go to the respondents at LUL and the development company
EVRY that invited us to a Triple helix environment for future work.

References

1. Atzori, W. and Ünver, Ö. SUSTAINS User Requirements Recommendations, Report D4.1v1,2013. 2013-05-15;Available from: http://www.sustainsproject.eu/.

2. Anthopoulos, L.G., Siozos, P.S., Tsoukalas I.A., *Applying participatory design and collaboration in digital public services for discovering and re-designing e-Government services*. Government Information Quarterly, 2007. 24: p. 353-376.

3. Axelsson, K., Melin U., and Lindgren I., *Exploring the importance of citizen participation and involvement in e-government projects - practice, incentives and organization*. Transforming Government: People, Process and Policy, 2010. 4(4): p. 299-321.
4. Melin, U., Axelsson K., and Lundsten M., *Talking to, not about, Entrepreneurs – Experiences of Public e-service Development in a Business Start Up Case*, in *eChallanges*, P. Cunningham, Cunningham, M, Editor. 2008.

5. Commission of the European communities, *i2010 eGovernment Action Plan: Accelerating eGovernment in Europe for the Benefit of All*, C.o.t.E. communities, Editor. 2006: Brussels.

6. Henriksen, Z.H., *The diffusion of e-services in Danish municipalities*, in *EGOV 2004*, Traunmüller, Editor. 2004, Springer-Verlag Berlin Heidelberg p. 164-171.

7. Schuler, D. and Namioka A, *Participatory Design Principles and Practicies*, Editors. 1993, Lawrence Erlbaum Associates Inc.: London.

8. Bardram, J.E., *Scenario-based design of cooperative systems: Re-designing an hospital information system in Denmark*. Group Decision and Negotiation, 2000. 9: p. 237-250.

9. Greenbaum, J. and Kyng M, *Design at work: Cooperative design of computer systems*, Editors. 1991, Lawrence Erlbaum Associates: New Jersey. p. 3-24.

10. Constantine, L. and Lockwood L, *Software for Use: A practical guide to the Essential Models and Methods of Usage-Centered Design*. 1999: Addison-Wesley.

11. Jungk, R. and Müllert N., *Future Workshops: How to create desirable futures*. 1987, London: Institute for Social Interventions.

12. Norman, D., *Cognitive engineering*, in *User-Centered System Design: New Perspectives on Human Computer Interaction*, D. Norman and S. Draper, Editors. 1986, Association for Computing Machinery: NY. p. 378-382.

13. Gulliksen, J., Göransson B, & Cajander Å et al., *Key principles for user-centred systems design*. Behaviour and Information Technology, 2003. 22(6): p. 397-409.

14. Mulder, S. and Z. Yaar, *The User Is Always Right: A Practical Guide to Creating and Using Personas for the Web*. 2006: New Riders Press.

15. Nielsen, J., *Heuristic Evaluation, Usability Inspection Methods*. 1994, New York: John Wiley & Sons.

16. Beyer, H. and Holtzblatt K., *Contextual Design. Defining Customer-Centered Systems*. *San Fransisco*. 1998, San Fransisco: Morgan Kaufmann Publishers.

17. Avison, D., Fitzgerald, G. (2006) *Information Systems Development*. McGraw Hill Higher Education.

18. Brender, J., *Handbook of evaluation methods for Health Informatics*. 2006, USA: Elsevier Academic Press.

19. Cajander Å, Larusdottir M and Gulliksen J. Existing but not Explicit – The User Perspective in Scrum Projects in Practice. In *INTERACT 2013 LNCS Proceedings, INTERACT 2013, Cape Town, South Africa*

20. Karlsson, F., et al., *Exploring user participation approaches in public e-service development*. Government Information Quarterly, 2012. 29(2): p. 158-168.

21. Lindgren, I. and G. Jansson, *Electronic services in the public sector: A conceptual framework*. Government Information Quarterly, 2013. 30(2): p. 163-172.

22. van Velsen, L., et al., *Requirements engineering for e-Government services: A citizen-centric approach and case study*. Government Information Quarterly, 2009. 26(3): p. 477-486.