Università degli Studi di Pavia

Transcription

1 Università degli Studi di Pavia Facoltà di Ingegneria Corso di Laurea Magistrale in Ingegneria dei Servizi DESIGN, DEVELOPMENT AND PROTOTYPING OF AN APP FOR ACCESSING THE PATIENT HEALTH RECORD RELATORE Chiar.mo Prof. Gianmario Motta CORRELATORE I Ing. Loredana Gazzaniga CORRELATORE II Dott. Daniele Sacco LAUREANDO Alberto Vanini ANNO ACCADEMICO

2

3 i

4 1 Preface This work is the result both of my internship at ASL (Azienda Sanitaria Locale) of the province of Pavia, and of the research studies at the Service Engineering Laboratory of University of Pavia. The work was conducted with the supervision of Prof. Gianmario Motta, Loredana Gazzaniga (director of the information system department), and Daniele Sacco (Ph.D. student at Service Engineering Laboratory). Collaborations with Lombardia Informatica s.p.a. were fundamental. ii

5 2 Abstract Lo scopo della tesi è stato quello di realizzare un prototipo per un applicazione Android adibita alla gestione ed alla consultazione del Fascicolo Sanitario Elettronico Lombardo. L idea che sta dietro al progetto è quella di mettere al centro del Sistema Sanitario Nazionale (SSN) il cittadino, fornendogli un sistema integrato in grado di supportarlo durante l esecuzione del processo di cura, dalla compilazione dei documenti per la prenotazione di una visita medica o di un esame, fino al ritiro del susseguente referto. La realizzazione dell applicazione è cominciata con una ricerca finalizzata alla definizione dello stato dell arte del fascicolo sanitario elettronico, e con un analisi della situazione AS-IS del Sistema Informativo Socio Sanitario Lombardo (SISS), dalle quali sono emerse le criticità a cui i sistemi di consultazione del FSE vanno incontro, le principali delle quali sono legate ad una scarsa usabilità, causata dall implementazione di un sistema di autenticazione forte obbligatoria secondo la legge Italiana, e da un basso livello di diffusione ed utilizzo, poiché essi vengono generalmente progettati per la fruizione tramite sistemi desktop, nonostante il rapporto tra essi ed i dispositivi mobile penda ormai in favore di questi ultimi. Per superare questi ostacoli è stata definita una soluzione TO-BE che prevede: l utilizzo di tablet e smartphone per cercare di incrementare il bacino di potenziali utenti, e lo sviluppo di un nuovo sistema di autenticazione per l accesso al SISS, che garantisca un autenticazione di tipo forte e che si coniughi all implementazione e utilizzo su dispositivi mobile. Per il sistema di autenticazione si è scelto di basarsi sulla tecnologia QR-Code poiché adatta all integrazione con tablet e smartphone e di facile utilizzo per l utente, mentre l autenticazione forte è stata ottenuta tramite un uso congiunto della scansione del QR-Code, l inserimento di una password, ed il seriale del dispositivo sul quale l APP è stata installata. iii

6 Grazie al nuovo sistema di autenticazione è stato possibile superare le barriere di sicurezza previste dalla legge per accedere al sistema informativo sanitario Lombardo, ed interfacciarsi con le funzioni e i servizi da esso forniti, indispensabili per lo sviluppo del sistema integrato per l assistenza end-to-end durante il processo di cura del cittadino, oggetto di questo progetto di tesi.. iv

7 v

8 PREFACE... II ABSTRACT...III CHAPTER MOTIVATION INTRODUCTION OBJECTIVES METHODOLOGY THESIS STRUCTURE... 4 CHAPTER FOUNDATION NATIONAL HEALTH SYSTEM Model Definition Western National Health System Models THE ITALIAN HEALTH SYSTEM Organization Financing Delivery of Services Positioning the SSN E-HEALTH AND ELECTRONIC HEALTH RECORD, A LITERATURE REVIEW E-Health Building blocks of e-health The Electronic Health Record Electronic Health Record vs. Personal Health Record The Italian Solution, the Hybrid FSE Examples of PHR Systems Considerations CHAPTER CONTEXT: THE LOMBARDY CASE SISTEMA INFORMATIVO SOCIO SANITARIO (SISS) Overview Actors System Evolution Conceptual Framework SISS Architecture THE ELECTRONIC HEALTH RECORD vi

9 3.2.1 FSE Content FSE Implementation CHAPTER CONCEPT SISS-MOBILE OVERVIEW Purpose of the System SISS-Mobile Stakeholders Overall Vision BUSINESS ARCHITECTURE AS-IS Situation Driver Analysis Fit-Gap Analysis To-Be Solution QR-Code Authentication Method USE CASES Authentication Citizen/GP Data Management FSE Booking Management Payment CHAPTER PROOF OF CONCEPT SISS-MOBILE ARCHITECTURE SISS-MOBILE IMPLEMENTATION Web application Business Layer Action Layer Utility Layer Persistence Layer Back end QR-Code Validation Device Management Authentication Engine DB Communication Component Mobile application Persistence Layer Communication Layer Presentation Layer vii

10 Implemented Use Cases TESTING Unit Testing Validation Testing CHAPTER CONCLUSIONS CHAPTER REFERENCES CHAPTER APPENDIX SISS-MOBILE WEB SERVICE WSDL viii

11 Chapter 1 1 Motivation 1.1 Introduction In the last years there has been an increasing interest in the IT-Health relationship, leading to the introduction of a neologism to describe this trend: e-health. The term e-health stands for electronic health, namely the application of Information Technologies in health care and the implementation of digital services for both government and citizens. This interest is motivated by the fact that investments in Information and Communication Technology (ICT) could generate significant improvements both in terms of quality of care and cost containment. e-health can in fact contribute to significant savings for the National Health Systems, thanks to the adoption of the Electronic Health Record and the consequently dematerialization of documents, but also thanks to the development of tools and services for online booking and payment of health services. Referring to the Italian scenario, we noticed that current services related to e- health are not very well established, indeed strategies of this type have been carried 1

12 out brilliantly by only few regions, one of which is Lombardy that is considered the first of the class because of its health information system (SISS, Sistema Informativo Socio Sanitario). However, even in Lombardy, the citizen is often put in second place because most of medical processes are not oriented to the citizen, but to the health care system itself. In fact, Italian citizens are the one who must move from one office to another in order to recover the administrative documentation required to start the process of care, to book a health service and of course to withdraw its referral. This inevitably leads to an inefficiency of the process of care from the point of view of both quality and execution time, as shown in Figure 1.1 that depicts the position of the citizen within the services offered by the Italian health system. The actual position is characterized by a low perceived quality of the care process and high execution time (which means that the time required to complete the process of care is very long, because of the waste of time derived from the displacements of the citizen). Figure Citizen position within the services offered by the Italian health system The motivation that led us to start this thesis project was precisely to develop a system to manage the health care process. It follows a stakeholder-oriented approach, focusing on the objectives and needs of the citizen, and placing him in command of the process. This kind of system will leverage the position of the citizen of Figure 1.1 2

13 to an optimal level, characterized by a high perceived quality and a high level of execution time, that can be substantially reduced by avoiding the waste of time due to the movement of citizen from one healthcare facility to another. The solution we propose in order to accomplish the shift from one quadrant to the other is to develop an integrated mobile application that allows the citizen to manage his own care process anywhere and at any time. It uses an authentication method based on QR-Code technology, by providing access to the electronic health record, therefore to the health data contained in it (including citizen s medical referrals), and to booking and payment services. 1.2 Objectives The main purpose of our work is to develop a stakeholder-oriented integrated mobile system for the management of citizens healthcare processes. Specifically, this system should allow the user to access to his Electronic Health Record in a situation of complete mobility. In order to achieve our intent, we defined three main objectives to fulfill: State of the art analysis of the ICT-Healthcare linkage within national health systems worldwide, by focusing on the Electronic Health Record, in order to understand whether and how it is used and what are the main issues related to its implementation and how to overcome them. Analysis of the Lombardy region situation, focusing on the access to electronic health record, and the consequent definition of a new authentication method. It shall be suitable for use on mobile devices and shall guarantee the minimum security levels required by health systems. Development of a mobile application that implements the authentication method previously defined, and the back-end systems needed for its operation. 1.3 Methodology In this section we explain the methodology and the scientific approach we have applied to the work within this thesis. Our methodology is based on four classical scientific components: thesis, theory, application and demonstration, as shown in Figure

14 Our Research Motivation State of Art Concept Proof of Concept Scope SRL WebApp Drivers Mobile APP Server Figure Research methodology By following these logical steps we ensure a clear problem formulation, a wide and accurate scientific research, a proper solution to the problem, and finally the validation of our results. 1.4 Thesis Structure The main purpose of this section is to provide the reader a high-level overview of the structure of the thesis. Chapter 1: after a brief overall introduction of the project, this section aims to specify the drivers of the thesis, the followed methodology and its structure; Chapter 2: this section is reserved both to a presentation of the National Health Systems with a focus on the Italian positioning within this context, and to an accurate systematic literature review aiming on one end to provide an effective overview about the e-health topic and on the other one to define what is the actual state-of-the-art of the Electronic Health Records (EHR), in particular which are the main challenges regarding its adoption and fruition; Chapter 3: In this chapter we present the case of the Lombardy Region, providing an overall description of its information system (i.e. the SISS, 4

15 Sistema Informativo Socio Sanitario, in italian) and the implementation of the electronic health record; Chapter 4: the chapter proposes the concept of the project in form of a deep architectural description of the mobile application we propose, together with its enabling systems (back end and web application); Chapter 5: this section provides a step-by-step description on how it was realized the system proposed and which kind of tests were conducted on it; Chapter 6: this chapter presents final conclusions and future developments. 5

16 Chapter 2 2 Foundation In order to define the context of the thesis project, will be presented an overview of the National Health Systems with a focus on the European Countries. After that there will be two sections dedicated to the delineation of the state-of-the-art on the Health- ICT relationship with a focus on the Electronic Health Record. 2.1 National Health System According to the World Health Organization [1], which is a specialized agency of the United Nations (UN) that is concerned with international public health, a national health system can be defined as [2]: A health system consists of all organizations, people and actions whose primary intent is to promote, restore or maintain health. This includes efforts to influence determinants of health as well as more direct health-improving activities. A health system is therefore more than the pyramid of publicly owned facilities that deliver personal health services. It includes, for example, a mother caring for a sick child at home; private providers; behavior change programs; vector-control campaigns; health insurance organizations; occupational health and safety legislation. It

17 includes inter-sectorial action by health staff, for example, encouraging the ministry of education to promote female education, a well known determinant of better health. Like every other system, even the National Health System has its own goals and outcomes that the World health report 2000 [3] defined as: improving the health status of the population and the health equity. This should be obtained in the most responsive and financially fair way as possible. Alongside those two main objectives [3] pointed out that a national health system should have also a series of important intermediate goals concerning: the access and coverage for effective health interventions during the care process and the quality of its activities. Performance is instead understood as the achievement of those objectives in relation to the invested resources, which, in turn, implies another goal, that is efficiency. According to a recent study [4], in order to achieve these goals, all health systems have to carry out four core functions, regardless of their organization: To deliver personal and population-based health services To finance those services (through revenue collection, fund pooling and purchasing) To generate all the necessary resources (human resources, technologies and facilities) required to produce health services To manage the system (health policy formulation, regulation and business intelligence) in order to maximize the likelihood of achieving the system goals Model Definition In order to analyze and compare different national health care systems it is necessary define a health system model. This can be done through different points of view. Indeed, some authors focuses on the system of the allocated resources (e.g. beds, medical and nursing staff, programs activated) [5]; others see the National Health System as a network of actors and functions (e.g. financing, legislation, resource allocation, service delivery functions) [6], this point of view is also known as Functional Perspective ; the WHO instead focuses on health-related performance indicators [1]. 7

18 According to the Functional Perspective a health system can be divided into three functional layers [7]: Planning and Monitoring: it includes the system planning activities, the resource identification (economical, professional, organizational etc.), the rules definition (Country and Regional laws, regulation etc.) and the resulting monitoring activities; Assistance: it ensures the management of citizen s health; Delivery: it is the functional layer that delivers the health service thus including all the territorial facilities of service (e.g. hospitals, clinics, outpatients, laboratories, pharmacies etc.). For our purposes, i.e. to give an overview of some of the major Western National Health Systems, we choose the functional perspective approach because it is more process oriented and let us provide better contextual information instead of a set of indicators to be compared with each other. Figure 2.1 summarizes the functional layers of the model. Planning and Monitoring System planning Resources identification (economic, professional, organizational) Rules (Country and Regional laws, regulations ) Monitoring Assistance Ensures the management of citizens' health Delivery Delivers the health service Includes the territorial facilities of service (hospitals, clinics, outpatients, labs, pharmacies) Figure Functional model layers 8

19 2.1.2 Western National Health System Models Western National health systems reflect two main models [7]: Private-Pension Fund (U.S Matrix): where the access to health services is related to the economic availability of individuals, who generally use forms of social security coverage (health insurance); Universal (European Matrix): where the health is a fundamental right of citizens, who have the right to enjoy all the services included in Essential Levels of Care (LEA) 1 established at national level. The American healthcare system is mainly based on the private sector, both in the financing offering through insurance and in the provision of services: there is however a significant public insurance component funded by the Federal Government. The most widespread insurance channel is associated to the work: companies enroll their employees in an associative entity called HMO (Health Maintenance Organization), which acts as a liaison with health care providers (hospitals, doctors, etc.) on a prepaid basis. HMO provides services under the constraint of having to make use of a limited number of general practitioners, hospitals and specialist facilities that are affiliated with or owned by the same HMO. A minority of population, such as independent professionals, activates individual private insurance by enrolling in HMO or in the classic reimbursement insurance (much more expensive), otherwise they are served by public assistance programs, like Medicare [8] and Medicaid [9]. Medicare is the National program of care for elderly people (over sixty-five years old), it is a universalistic program, so this mean that is independent from income. Medicaid is instead a program managed by individual States (with a federal subsidy that covers 60% of costs) addressed to certain groups of low-income population (families with children, pregnant women, elderly and handicapped). 1 Essential Levels of Care (LEA) are the performances and services that the National Health System has to provide to all citizens for free or upon the payment of a fee. 9

20 The lack of a national system of protection makes the care network very fragmented and produces the presence of a substantial number of citizens without any form of insurance (in 2008 the 18% of the population under the age of 65)[7]. Figure Comparison between European and American health systems A different model is adopted in most of the European Countries, which have committed to the principles of universal access, equity and solidarity as core values of European societies [4]. The key element of the European model, which is also in common between all Nations, is the Public Funding. This financing is accompanied by citizen contributions depending on their income, or by mandatory or supplementary insurance (e.g. France and Germany). The contribution paid by citizens varies according to national guidelines, in fact it can goes from a minimum percentage of the total healthcare expenditure (like it happens in the United Kingdom), to a very high one, as in the case of the solidaristic French model [7]. Generally the government of the system is based on three layers: 10

21 1 National bodies (with legislative and financial powers) Territorial government bodies (responsible for the regional management and the healthcare delivery) Social security bodies and insurance companies A common need of the European model is to contain the growing spending, partly due to the greater support and assurance of the weaker groups of population. Typically, national governments are moving towards a greater supportive contribution of citizens and an increasing local autonomy, especially with regard to the planning and administration of health services [7][4]. 2.2 The Italian Health System Inside this section will be presented an overview of the Italian health system, in which will be examined the specific approach to the organization, financing and delivery of health services. After that there will be a section devoted to profiling the positioning of the Italian health care system compared to that of some of the major European Countries (Germany, France and United Kingdom) and of the best in class for what concern the health-ict pairing (The Netherlands, Sweden). This analysis is aimed to pinpoint the differences between the Italian s health system and the one of countries belonging to the same continent and adopting the same health system model Organization The Italian health care system (Servizio Sanitario Nazionale (SSN)) is a universal public system that guarantees health care to all citizens. SSN is based on three territorial layers, namely: national layer, regional layer, and local layer [7]. The National Layer is responsible for ensuring the general objectives and fundamental principles of the national health care system, besides it is also responsible for the supervision, direction and control of clinical and scientific research activities [78]. The central government controls the distribution of tax 11

22 revenue for publicly financed health care and defines a national minimum statutory benefits package to be offered to all residents in every region for free or upon payment of a fee (ticket), the so-called Essential Levels of Care (livelli essenziali di assistenza, or LEAs). The national layer is composed by the Department of Health and other central bodies such as the High Council of Health, ISS (Istituto Superiore di Sanità, in Italian), ISPESL (Istituto Superiore Prevenzione e Sicurezza sul Lavoro, in Italian) and AIFA (Agenzia Italiana del Farmaco, in Italian). The Regional Layer is the most important one because the 20 regions and the 2 autonomous provinces have responsibility for the organization and delivery of health services through local health units (ASLs, azienda sanitaria locale, local health enterprise ) and hospitals, besides they are required to achieve the country s healthcare objectives (defined inside the National Layer) ensuring the LEAs. However, each Region has the right to provide additional health care services, but only if they have the necessary budget and as long as they also deliver the basic package; moreover, they enjoy significant autonomy to determine the macro structure of their health systems [79]. The Regional level is composed by the regional Health Department. The Local Layer is composed by the ASLs (today 143 [93]), which are managed by a CEO chosen by the governor of the region and they are responsible for organizing and providing of healthcare services within their territorial areas through public facilities or accredited private facilities, besides they are also responsible for ensuring the delivery of the Essential Levels of Assistance (LEA). The local health enterprises have (a) a public juridical personality, (b) organizational, administrative, fiscal, financial, managerial and technical independence. The three layers previously described (National, Regional and Local) represent the territorial component of the health system, instead the operative component, which is the one that provide and deliver the benefits and performances, is constituted by the Hospital System, which in turn is made up by: Hospital Enterprises (Azienda Ospedalieriera (public hospital)); National Institutes for Scientific Research (Istituto di Ricovero e Cura a Carattere Scientifico), they are public or private hospitals of excellence with 12

23 the purpose of biomedical research and management of health services (they respond directly to the Minister of Health); Outpatient facilities for diagnosis and treatment (they are either independent or included inside the hospital enterprises). In Italy the facilities making up the hospital system have very heterogeneous features and dimension, moreover there is a considerable variation between the north and south in the quality of health care facilities and services provided to the population, with significant cross-regional patient flows, particularly to receive high-level care in tertiary hospitals. Picking the Lombardy Region case as an example, Figure 2.3 shows how Lombardy is organized from the point of view of the territorial and operational components. Figure Lombardy Region territorial and operational organization 13

24 From the picture it can be seen that the Lombardy Region defines and allocates a certain budget for each department (e.g. Mobility Department, Agricultural Department), among which there is also the Health Department, which in turn will split the budget between all the ASLs. Each ASL has the duty to reallocate the assigned budget among all the facilities, within its area of jurisdiction, that make up the operational component (e.g. Hospitals, Nursing Home, Outpatients). When a citizen will have the need to go to one of those health facilities for care, he ll pay the ticket (if it is required), than the facility will store the money derived from that ticket and subsequently will report to its reference ASL the amount of money received, in order to make sure that they will be subtracted from the budget that the local healthcare enterprise will allocate for the very same facility Financing One of the main problems related to the financing of the Italian health system concerns the volume of public health care expenditure, in fact even if it is one of the lowest among European Countries, it still remain a problem both at national and regional levels, mainly due to the existence of a large public deficit [78]. The SSN is primarily financed at national level through general taxation, subsequently, the money collected in this way, are distributed among the regions, but the latters are also allowed to generate their own additional revenue by levying additional regional fees. These regionally levied extra-taxes are necessary for instance to raise sufficient money to provide additional LEAs services, but they also lead to interregional financing differences [2][79]. Instead, the funds needed to finance the basic package of LEA services are instantiated by the State. The criteria by which the State distributes these resources to the regions are set annually, and they depend on several variables such as population size and age demographics. In Italy both inpatient care and primary care are free at the point of use, and are two main types of out-of-pocket payment: The first type is called a cost-sharing, it concerns a contribution that patients have to pay to support some types of tests, medical examinations or to purchase pharmaceutical products. This contribution can vary from region to region and it also depends on the patient's income, age, chronicle diseases or disability. In addition, since 2007, it is expected a co-payment in the event of unjustified 14

25 access to hospital emergency departments, which varies in relation to the region and the emergency-color classification (e.g. the yellow and red cases are free for charge) [78][79]. The second type consists of the direct payment by citizens to purchase private health care services and over-the-counter drugs [78]. In Italy there are also forms of private health insurance, but they are not widely used because of the near universal coverage, in fact only about 15% of the population has some form of private health insurance [80], although they are stipulated primarily to obtain access to private facilities, best amenities, shorten waiting lists and to have a wider choice of doctors and specialists [81] Delivery of Services As we have seen, the delivery of health services is primarily managed at the local level, and thus by the local health units (ASL), which are responsible for a range of complementary services such as health promotion and prevention activities, food safety, and veterinary medicine. In Italy the primary care is delivered through general practitioners (GPs), pediatricians and physicians, who are paid a capitation fee based on the number of people (adults or children) registered on their list [79]. Another task that falls to the ASLs, along with the public or private accredited facilities that have entered into agreements with them, is to offer outpatient services. These services can be accessed, based on their typology, by the citizens either through a GP referral or through the CUP (Centro Unico di Prenotazione, in Italian) thanks to which they can directly book a healthcare performance [2][79]. Citizens can choose to receive medical care or hospital care also by health facilities that are not part of the area of expertise of their reference ASL. In this case the ASL to which the patient belongs, shall provide for the payment of the costs he incurred during the course of treatment, by paying the ASL to which the chosen providers belonged. This process is called inward mobility, while if the ASL is paid by another one, is called outward mobility [2][78]. Medicines can be purchased in public and licensed private pharmacies, but since 2007 the drugs that do not require a GP s prescription, can be sold even outside them, for instance you can find those medical products among the shelves of supermarkets or in parapharmacies [78]. 15

26 2.2.4 Positioning the SSN A common need of the European model is to contain the spending growth, partly due to a greater guarantee and coverage of the weakest groups of the population. In general governments are moving towards greater solidarity contribution of citizens and an increasing local autonomy, especially in the planning and administration of health services [7]. This decentralization strategy brings to significant changes in both National governments and regional bodies. In fact the latters will have an increase operating and decision-making power, while the States will see their position changes from being directly responsible for the management and delivery of health services, to be responsible for the issuing of national laws and policies and the management and monitoring of private accredited healthcare providers who will have to deliver the services. The quintessence of that scheme is represented by the Dutch healthcare system [20]. The Italian Health System, together with the Swedish one, is instead part of the socalled NHS developed countries [78][84][85][90] because it is mainly derived from the U.K. model. In fact, those two systems share the organizational, financial, and delivery model with only slightly differences, mainly due to the different National laws and policies. This is also confirmed inside a recent study about mapping of the European health systems, in which they are divided into three clusters according to a certain number of characteristics, such as the total health expenditure, the share of public and private funding and the level of inpatient/outpatient healthcare [83]. Cluster 1 consists of Austria, Belgium, France, Germany and Luxembourg (which are all social insurance countries). This type can be described by a high level of total health expenditure and also a high share of public funding. The share of private out-of-pocket funding is moderate. The high level of health expenditure is translated into a moderate level of inpatient and a high level of outpatient healthcare. Countries of this cluster are also characterized by a high level of autonomy of self-employed doctors and high freedom of choice for patients. Cluster 2 covers Denmark, Great Britain, Sweden (which are all early developed NHS countries), Italy (late developed NHS) and Ireland (no fully institutionalized NHS in 2001). This type is characterized by a medium level of 16

27 total health expenditure. The share of public health funding is high, and private out-of-pocket funding is moderate. Compared to Cluster 1 the level of inpatient healthcare providers is similar but the outpatient provider level is particularly low. The access to doctors is highly regulated, and doctors face strict regulation regarding their income chances. Cluster 3 includes Portugal, Spain (which are late developed NHS countries) and Finland (with a NHS introduced in the 1960s). This type is characterized by a particularly low level of total health expenditure (per capita) that is (except for Finland) related to the weaker economic position of these countries. Private out-of-pocket payments are on a high level and institutional indicators show a high control of patients access to medical doctors. The inpatient index is low and the outpatient index is at a moderate level. Since GPs receive in general a fixed salary, income chances are even more highly restricted than in Cluster 2. However, despite the implemented health system model or the cluster membership, most European countries have achieved universal (or near-universal) coverage 2 of health care costs, either throw a public or private scheme, for a core set of services, which usually include consultations with doctors, tests and examinations, and hospital care like shown in Figure 2.4 [81]. From the chart we can see that Italy for what concern the primary care has a 100% of public coverage together with UK and Sweden, instead France and Netherlands and specially Germany have a lower percentage of public coverage, so their citizens will have to stipulate contracts with private health insurance companies. 2 Coverage for health care is the share of the population receiving a defined set of health care goods and services under public programs and through private health insurance. 17

28 Figure Public and private health coverage (adapted from [81]) The basic healthcare coverage, whether provided through public or private insurance, usually covers a defined set of benefits, in many cases with cost-sharing [80]. To avoid the personal sustaining of these costs, citizens of different countries, for instance Germany and France, establish forms of private insurance, which offer them services that goes to cover any holes left by the basic healthcare coverage (complementary insurance)[84][86][87]. However this is not the only reason for patients to sign this kind of insurance, in fact, for instance in the Netherlands, are present private insurance capable to add additional services to the essential package offered by the basic coverage (supplementary insurance) [82], or they can provide both faster access and larger choice of providers (duplicate insurance). Italy belongs to the latter category, in fact almost the 15% of Italian citizens have a private 18

29 % of GDP insurance contract that allow them to access to private facilities and other amenities [78] [79] [81]. Regarding the health system related expenditure, it can be seen from the charts below that in Italy for our health we spend little and we invest even less. According to [80][81] in Italy total health spending accounted for 9.2% of GDP (Gross Domestic Product) in 2011, slightly below the OECD average (9.3%). Health spending as a share of GDP is much lower in Italy than in other major European Countries like the Netherlands (11.9%), France (11.6%) and Germany (11.3%), moreover, except for France, since 2009 the trend has been steadily downhill for all the considered nations, and Italy is bringing up the rear Italy U.K. France Germany Netherlands Sweden Figure Percentage of gross domestic product spent on healthcare Italy ranks below even in the OECD average in terms of health spending per capita, with a spending of 3012 USD in 2011, compared with an OECD average of 3339 USD. Health spending in Italy grew, in real terms, by an average of 2.2% per year between 2000 and The growth rate slowed down slightly to 1.8% in 2010 and dropped more markedly by -1.6% in 2011[80][81]. We can also notice that the grew rate of most of the other analyzed country follows a negative trend since

30 USD per capita (France, Sweden, UK) while in others (Netherlands and Germany) it remains stationary. In 2011 the only Country that seems to reverse the trend with regard to investments in healthcare is France. The public sector is the main source of health funding in all European OECD countries. In Italy the 77.8% of health spending was funded by public sources in 2011, above the average of 72.2% in OECD countries, but it was relatively low if compared to several Nordic countries (Denmark, Iceland, Norway and Sweden) and the United Kingdom with a share of public spending over 80% [81] Italy U.K. France Germany Netherlands Sweden Figure Healthcare spending per capita The impact on the quality of what was considered, until a few years ago, among the best healthcare systems in the world [3] is obvious and alarming. In just three years the Italian Healthcare System has slipped down from the fifteenth to twenty-first place for quality, among the health systems analyzed by the Health Consumer Powerhouse [88]. The Euro Health Consumer Index (EHCI) has become an industry standard of modern healthcare since the start in The 2012 edition ranks 34 national European health care systems on 42 indicators, covering five areas, called sub-disciplines, which are key to the health consumer: 20

31 Patients rights and information Accessibility of treatment (waiting times for treatment) Medical outcomes (clinical results) Prevention/Range and reach of services provided Pharmaceuticals The results of that report are summarized in Figure 2.7, where it can be seen that Italy (with 623/1000 points) is not only more and more detached from the traditional benchmarks such as France, Germany, United Kingdom and the Netherlands (best in class), but now it finds itself even behind some countries of Eastern Europe (Czech Republic, Slovenia and Croatia). Figure Euro Health Consumer Index (EHCI) final ranking result [88] 21

32 Figure 2.8 drills down the summary results according to the five sub-disciplines and it emerges that despite the fact that Italy still has a good ranking on some fundamental parameters, as Outcomes (11 place) and Patient rights and information (11 place), it has a very low rating on Prevention, Range and reach of services provided (26 place), Pharmaceuticals (22 place) and Accessibility (22 place). These indexes denote a progressive deterioration of the system, fated to show its effects in the next few years with serious repercussions not only in terms of health, but also to costs and therefore the sustainability of the system itself [89]. Figure Euro Health Consumer Index (EHCI) sub-disciplines ranking [88] In order to overcome this situation and find a solution, Italian government should look at the best performing healthcare systems, such as the Netherlands with its reliable and efficient system, and try to copy and learn from them. Besides, according to [89] the key to sustainability resides in digital innovation, and clever use of digital technologies is essential and brings to relevant paybacks, giving significant economic and quality benefits. In fact, thanks to the digitization it would be possible to reduce costs, errors, and ensure greater governance to all the stakeholders, citizens included. Digital innovation can be pursued mainly through the so-called Electronic Health (e-health) and its sub-areas, such as (a) the Electronic Health Record/Patient Health Record, (b) e-prescriptions, (c) and telemedicine. This concept is approved and sustained directly by the European Commission through an Action Plan about the e-health topic drafted in 2012 [34], in which there are described the overall goals and the suggested infrastructures, policies and best practices in order to reach those goals. Following this European Commission s Action Plan, Member States of the European Union (EU) committed themselves to 22

33 develop a national or regional roadmap for e-health. Among them it s present also the Italian government, which through the Ministry of Health, defined its e-health strategy [92]. It should be noted that even various non-union European countries also followed this vision [91]. 2.3 E-Health and Electronic Health Record, a Literature Review Our objective within this section is to give a comprehensive view of the e-health topic and especially of the Electronic Health Record. Our research question is: What is e-health and how the Electronic Health Record can contribute to improve the quality of the health care system performances from its stakeholders point-ofview? This question is than be refined into the following Research Questions (RQs): RQ1: what is the e-health and how it is implemented inside the European context? RQ2: what is the actual state-of-the-art of the Electronic Health Records (EHR)? RQ3: which are the main challenges regarding the EHR adoption and fruition? From this SLR we expect: An overview on the e-health topic and its sub-areas; An overview on the state of art on EHR; The identification of gaps in current research, solutions, trends and future research and suggestion to the community of researcher and practitioner; Recommendations about e-health and EHR best practices that arise from SRL E-Health Over the last years, we have witnessed an increasing use of Information and Communication Technologies (ICT) in the healthcare domain that led to a remarkable maturation of the health informatics field, both in terms of service 23

34 delivery and quality of care processes [29][94]. This digital innovation process [89] led in turn to the establishment of a new field, called e-health that according to the European Commission and the epsos project (European Patients Smart Open Services) [16][34][43] can be defined as: E-Health means using digital tools and services for health. E-Health covers the interaction between patients and health-service providers, institution-to-institution transmission of data, or peer-to-peer communication between patients and/or health professionals. Examples include health information networks, electronic health records, telemedicine services, wearable and portable personal health systems and many other information and communication technology (ICT)-based tools assisting disease prevention, diagnosis, treatment and follow up. From this definition we can figure it out that e-health is not limited to the simple management and analysis of patients clinical data, but it also promote the communication and cooperation between all the stakeholders involved in the treatment and health care process of the patients, in order to provide better health services with an increase quality and efficiency and an overall cost reduction [41][105]. In fact, it has to be noted that the costs of health care are rising rapidly in most industrialized nations and there is concern that despite high levels of spending, the quality and efficiency of care are suboptimal [30][31]. Furthermore, there is substantial variation in patients experiences and outcomes, even among a group of high-income industrialized nations [32]. That s why e-health in general and Electronic Health Records (EHRs, it is the major application of e-health and it will be presented in the next section) in particular, are increasingly viewed: As tools for improving the quality, safety and efficiency of health systems and consequently reduce costs [33]; As tools for improving the access to health advice and treatment for patients, thus improving the quality perceived by the patient [13][34]; Furthermore, precisely because of the above-mentioned the benefits, some researches suggest that focusing on the development of e-health strategies could be a potential solution for overcome national healthcare crisis, such as the one that is afflicting USA [42]. 24

35 However, despite the good promises regarding e-health, they remains largely unfulfilled, as expressed by Estonian President Toomas Hendrik Ilves:"We know that in healthcare we lag at least 10 years behind virtually every other area in the implementation of IT solutions. We know from a wide range of other services that information technology applications can radically revolutionize and improve the way we do things" (May 2012). That s why since 2004 European Commission started drafting Action Plans [35][34] and targeted policy initiatives aimed at fostering widespread adoption of e- Health technologies between European Countries [16] Building blocks of e-health After seeing what e-health is, we are now going to explain what are its components. Referring to [34][91][92] we can identify the major building blocks that make up the e-health Platform. Specifically they can be divided into three categories: E-Health Applications (or Priority Areas) Common Denominators and pre-requisites Enabling Components Figure Priority areas and common denominators of e-health [92] 25

36 As we can see from Figure 2.9 the major e-health Applications, which are a common need/goal through almost all nations, are: EHR: There will be a section in SLR dedicated to this specific topic, so for now we give only a little definition in order to let the reader understand what we are talking about. The Electronic Health Records are a collection of digital documents regarding citizens health care (e.g. referrals, hospital diminishing letters). Booking Services: They are made up by web portals or call-centers in which the citizen can check the waiting times of different facilities end eventually book an exam. Telemedicine: it is the delivery of healthcare services through the use of ICT technologies. Telemedicine can be used for the home monitoring of patients, provide diagnostics services at distance or even send images (e.g. X-Ray) throughout an health information network linking hospitals, laboratories, pharmacies, primary care and social services. E-Prescription: it is the digital version of the classic prescription and it is transferred from the healthcare provider to a pharmacy in which the patient will be able to retrieve his medicines. E-Certificates: it represents the digital signature of a document by a health care operator. All the previously mentioned application could not exits without the following pre-requisites: Dematerialization of Health Documents: since e-health operates in a digital environment, in order to foster the interchange of papers, all the health documents, either the one produced during the care process or the already archived, must be digitalized, which means that all paper documents should ideally be reduced to 0%. Harmonization of e-health solutions: all the national and regional systems should be integrated and the communications should follow the same standards. 26

37 Standards are also present in the latter category of enabling components together with tools that allow a certain and unambiguous identification of patients and healthcare operators through a unique key. This is necessary in order to keep track of each episode of care arising from the patient-national health system interactions and to identify each health operator and set/read their authorizations (e.g. what documents can be accessed by GP according to the citizen s will) The Electronic Health Record Now let s focus on the most important e-health application: The Electronic Health Record (EHR). We have seen that e-health can help improve the healthcare process by improving its quality, efficiency and security by providing a timely access to digital healthrelated documents and giving the chance to share them among the appropriate stakeholders [13]; and now we ll explain that it is possible thanks to the Electronic Health Record, which some authors consider the next big thing within the medical care domain [52]. There is not a unique and official definition for the EHR, thus almost every nation and region of the world gave its own definition. For instance the Italian definition established at national level is gave through [10] and states as follow: The Electronic Health Record is a set of digital data and documents relating to health and social health generated by present and past clinical events, relating to the patient. But every region that started the implementation and development of the EHR defines it in a slightly different way [12][13]. In order to provide a comprehensive and standard definition we gathered a good number of different definitions [49][50][51] and merge them together to derive a definition by aggregation: The Electronic Health Record is the place in which every digital document related to the citizen s health should convey. This place could be either a physical repository in which a copy of each document has to be stored, or a logical repository in which keep track of the link of all the single documents generated during the care process and stored within the health-facility database that produced it. 27

38 Electronic Health Record vs. Personal Health Record In literature there is an almost infinite number of acronyms regarding the Electronic Health Record (e.g. EHR, PHR (Personal Health Record), MHR (Medical Health Record), Patient Summary, EMR (Electronic Medical Record)) and even if they seems all interchangeable words, this is not the case. However all those acronyms can be gathered into two main groups: PHR (Personal Health Record) and EHR (Electronic Health Record). PHRs and EHRs are actually two heads of a same line and substantially differ from each other, as we can see from the Table 2.1 in which we analyze their main differences. EHR PHR Owner Single healthcare provider Citizen Content Time Span Receiver Interoperability Uploading Rights Security Accessibility Data and clinical documents generated by single care providers Time in which the patient is inside the provider facility Healthcare provider operators + citizen Within the provider information system Only certified healthcare operators Ensured by the care provider itself All the healthcare operators that works for the provider Data and documents (even not strictly health-related), clinical and well-being information generated by different care providers Lifelong All healthcare operators who treat the citizen + citizen Maximum Citizen Non institutional servers / Citizen s pc Citizen Table 2.1 Comparison between EHR and PHR The EHR is created when a citizen goes to a hospital or to another healthcare provider facility, which opens a medical record in which all the documents generated 28

39 during the treatment process and those related to the citizen s hospitalization will convey and will be stored. The EHR has a temporal window restricted to the period in which the citizen is patient within the health facility; in fact it is created when the patient started his hospitalization and than it is destroyed when the citizen is discharged [53][54]. The electronic health record is obviously generated and updated only by qualified health operators; it is sharable between all the operators within the same provider s network and the security of all the digital documents that make up the EHR is guaranteed by the security system of the provider s information system network [14]. The patient can have access to the documents within his record by asking them to the dedicated counter inside the hospital, but he can be able to access only to a few referrals (e.g. the patient can not have access to the clinical diary) in order to bring them for instance to a specialist [54][55]. In brief we can state, according to [14], that Electronic Health Records are a planning tool used by the professional healthcare operators in order to support the care process, from patient hospitalization to results management. The other head of the line is represented by the Personal Health Record. It represents the digital version of a drawer in which the citizen collects all the healthrelated documents that were produced during his life (e.g. referrals, diminishing letters, X-ray), but they can also belong to another family member or to a friend [53]. These documents can be digital natives or made digital by the user (e.g. scanning or taking a picture of them), they can be generated by different healthcare providers or even by anyone of them, this is the case in which the citizen uploads into his PHR for instance a web-page describing a disease he thinks he has or an homeopath s prescription. Personal Health Records are typically managed by web-applications or personal computers, and the citizen is totally free to manage this tool as he wants, furthermore the PHR has not a predefined temporal window, but it exists until the citizen is interested in uploading documents and keep it up-to-date [57][60]. Since PHR is personal, it is accessed by the owner and by all the people that citizen wants, besides the interoperability is maximum because all the files are essentially PDFs or images. One of the main issues of the PHR is that all its content is at complete discretion of the citizen, who typically is not a healthcare operator or has not a deep knowledge of the health domain [58]; another problem is that the record is stored inside a tablet or pc with no security standards implemented on it, while a big advantage of the PHR, like we mentioned before, is that it collects everything regardless of the healthcare provider that produced the document. This is a key feature in environments like the U.S.A. Health System, in which there are several 29

40 hospital networks that work in a standalone fashion because they are private organizations, so they tend to store all the clinical documents (i.e. their EHRs) inside their repositories and not to share them with other healthcare actors. A recent study [64] highlighted how low is the EHR adoption rates and especially how the USA is behind many others industrialized nations regarding the exchange of health-related data between different operators in ambulatory care [65]. Hence, thanks to the PHR a citizen can have all those documents gathered in a single place, so they are available in a timely manner whenever the user will need them [14]; this is why some USA organizations with the aim of improving the customer satisfaction and creating stickier relationships with their patients, implemented PHR systems [20][21]. However even the PHR has significant drawbacks, the major of which consist of the non-certification of the loaded documents, which in turn implies that a healthcare professional would not relying in the information contained in the PHR The Italian Solution, the Hybrid FSE Italy started its journey towards e-health and in particular towards the Personal Health Record in 2007, when several regions (e.g. Lombardy, Tuscany and Emilia- Romagna) began to implement regional PHR systems by following the national guidelines about the topic, which were published the same year [10]. The idea behind the Italian version of the PHR is to take the best from the EHR and PHR and create a unique kind of health record named FSE (Fascicolo Sanitario Elettronico, in italian) and defined from [14] a sort of lifelong EHR. The Lombardy region is one of the most advanced regions in Italy regarding the development of the regional healthcare and social service information system [59][61], and in 2010, the Lombardy region started the development of a full lifelong EHR. From Table 2.2 we can immediately notice that FSE fits between EHR and PHR because first of all the owners are all the subjects involved in the citizen s treatment process; in fact the document produced by whatever healthcare provider remains inside its repository, but whereas it is uploaded inside the FSE, it is available for an online consultation by the citizen plus by all the potential GPs that should provide him medical assistance (if they were entitled to access to FSE data); in fact the citizen has the right to decide which documents should be included and who can 30

41 access them, besides he can also upload documents by his own inside a designated area called notebook. These features make the FSE very similar to PHR because in one place we have a collection of documents generated by a multitude of different providers. FSE got another two big benefits from PHR: the lifelong existence and the wide range of receivers. Regarding the interoperability we can say that is wider than that of the EHR, but like as it happens in the former system, only qualified health operators manage the uploaded information, hence it respect the reliability constraint and it lives inside a secure environment guaranteed by the Regional health information system. EHR FSE PHR Owner Single healthcare provider Multiple healthcare providers Citizen Content Data and clinical documents generated by single care providers Data and digital clinical documents generated by multiple providers Data and documents (even not strictly health-related), clinical and well-being information generated by different care providers Time Span Time in which the patient is inside the provider facility Lifelong Lifelong Receiver Healthcare provider operators + citizen Multiple healthcare providers operators + citizen All healthcare operators who treat the citizen + citizen Interoperability Within the provider information system Maximum in the regional context Maximum Uploading Rights Only certified healthcare operators Only certified healthcare operators Citizen Security Ensured by the care provider itself Regional health information system Non institutional servers / Citizen s pc Accessibility All the healthcare operators that works for the provider Multiple healthcare providers Citizen 31

42 operators + citizen Table Comparison between EHR, FSE and PHR The introduction of the FSE raised several issues regarding the privacy of healthcare and access polices, so in 2009 the Italian Authority for Privacy drafted a document in which were specified how data could be accessed and/or hidden [56]. The concept of the Italian FSE is unique, thus even during the literature review we weren t able to find another running Hybrid PHR system, nor at regional or national level [14]. The closest thing to the FSE may be the Patient Summary (PS)[15]. It is carried out by the European epsos project that we previously mentioned [16] which also gave the official definition contained inside the Table 2.3. A Patient Summary (PS) is a concise clinical document that provides an electronic patient health data set applicable both for unexpected, as well as expected, healthcare contact. A PS provides a health professional with essential information needed for healthcare coordination and, in case of an unexpected need, for the continuity of care, or when the patient consults an health professional other than his regular contact person. The epsos PS is a standardized set of basic health data containing the following information: General Information about the patient (e.g. name, birth date, gender, etc.). A Medical Summary consisting of the most important clinical patient data (e.g. allergies, current medical problems, medical implants, or major surgical procedures during the last six months). A list of the current medication including all prescribed medication that the patient is currently taking. Information about the Patient Summary itself (e.g. when and by whom the Patient Summary was generated or updated). Table 2.3 Patient Summary, epsos definition The PS is contained within the PHR, it is intended to be sharable among all the European medical operators, and the information within it, is generated and/or updated by qualified health operators [15][44] and this should overcome the 32

43 reliability issue. Unfortunately even this project, which at the moment is only in the pilot phase on some nation but at regional level (e.g. the Lombardy region is between them), is facing with several barriers regarding in particular (a) the high amount of money that Countries should invest, even if the European Commission sustained inside one of its annual reports [19] that the socio-economic gains to society will eventually exceed the costs; (b) and the resistance of GPs who should create and keep up-to-date the PS. The epsos project however, thanks to its guidelines, is helping to standardize the infrastructure of the national health systems of member countries [91], and this will serve to overcome the interoperability issue between systems Examples of PHR Systems During these years there has been increasing attention paid to the potential of personal health records and currently PHR-based systems are being used mainly in Europe and USA [14]. Research has shown that PHR systems are developed mainly by: Governments Healthcare institutions Companies belonging to the Health-ICT business area Large multinational companies One of the major examples of PHR systems developed by a government can be found in the United Kingdom, where the National Health System (NHS) proposed HealthSpace, which however closed on March 2013 [17]. HealthSpace was a free, secure online personal health organizer that implemented also booking services and it was available to all people who lived in England after an registration. The web portal was mainly focused on offering services to the population rather than collects health documents, however it was also possible to access to the Summary Care Record (SCR), which is the English-version of the PHR, which still exists despite the HealthSpace closure due mainly to infrequent use but also because it wasn t in line with the new e-health strategies that the UK government began to follow [46]. Those strategies are related (a) to the communication and the education of patients in order to provide them better access to health and care information (b) and to an idea of 33

44 Health Ecosystem where different types of services are merged together in a single place (e.g. Booking an exam, pay a performance, contact the GP) [18]. Another example of good EHR system can be found in Spain, more precisely in the Region of Andalucía, where it was developed and delivered the Diraya health information system [45]. Diraya is a patient EHR and e-prescribing system very similar to the Lombardy s one (described in section 3.1), in which we can find a regional-level interoperable EHR that collects and hold information about citizens patient summary, referrals, medications prescribed and dispensed, contacts with healthcare (e.g. hospitalization, visits to GP medical office) [19][47]. As an example of EHR system developed by healthcare institutions we can mention the HealthConnectOnline system implemented by an American healthcare provider called Kaiser Permanente [22]. HealthConnectOnline is a web portal that reflects the UK idea of ecosystem ; in fact it can be used: As a PHR, thus you can upload personal health-related documents, download laboratory referrals, and examine your patient summary that stores information about allergies and immunizations; As an appointment booking tool; As a communication platform, because the system links patients and GPs through communications; As a prescription management tool; The Kaiser Permanente platform is one of the most advanced health care systems and is collecting positive evaluations from both the critics and the users 3 4, as demonstrated by the high percentage of use and diffusion. An example of PHR solutions developed by Companies belonging to the Health- ICT business area is given by the Lifesensor [23]. It is a web application that allows users to store and manage a wide range of health-related documents, from single information to describe the current health status to laboratory images and 3 InformationWeek < (last access ) 4 New York Times (2013) < > (last access ) 34

45 referrals. A peculiarity of this system is that it is not directly linked to healthcare providers repositories, which is mean that Lifesensor cannot have access to the citizen s EHRs, but the information inside the user s account could be viewed, modified or added by authorized healthcare operators. Lifesensor is available only in a few European countries such as Germany, Austria and Bulgaria. The last category consists of very large companies that want to invest in the development of EHR solutions, such as Google and Microsoft. Google in 2008 started the delivery of a PHR system called Google Health [25] that was free of charge and linked to your Google account. Google entered into agreements with certain healthcare providers in order to automate the process of creating and updating the so-called Google Health Profile, which included laboratory results, medications and allergies; besides citizens could also manually load health documents within their account. Unfortunately on January 2012 the project was terminated and all the accounts passed to Microsoft [14][27]. There are many opinions regarding the reasons why Google closed the project: some people think that it is due to the limited use of the service by users and its inability to meet their needs and expectations regarding the automate updating system [26]; others think that it is mainly due to the lack of reliability of the information contained within the Google Health Profile detected by doctors and the low number of healthcare providers that joined the project [27][28]. However, as we mentioned before, Microsoft incorporated all the Google Health Profiles within its system called HealthVault [24], which allows users to create a patient summary, upload the desired documents, and share it all with the authorized stakeholders using special devices and applications for smartphones Considerations From the SLR emerged that the development of EHR solutions topic is very hot, in fact a lot of Nations are moving toward this direction meeting, however, always the same barriers we described above, which if not addressed and solved can also lead to great failures, the most excellent of which was the Google case [25]. The biggest obstacles are mainly related to the lack of use of existing PHR systems (delivered primarily through web portals) by citizens and the lack of attention paid by physicians regarding the information contained in those records, which do not consider reliable the information uploaded by patients, as they have no knowledge of the healthcare domain [58]. Moreover the majority of systems do not enjoy a high degree of interoperability, but they work only in certain local contexts. An interesting 35

46 model to cope with the reliability issue is the one that has been developed by Italy, where within the FSE are made available to the patient and GPs all the health-related documents that have been produced during the citizen s life, which can be considered reliable as they are not loaded by the patient himself, but by certified healthcare operators or providers. The goodness of this approach can be confirmed by its rapid and widespread diffusion in the Lombardy region [14]. In order to overcome obstacles related to the interoperability issue, we should instead look at the standards defined at European level within the epsos project [16] for the exchange of a subset of information contained within the PHR. With regard to the utilization percentage of PHR systems, a solution could either be based on the new approach of the UK National Health Service about education and communication with patients; or the development of mobile APP and then move towards what is called m-health [14][36][37]. The decision to focus on the development of smartphones and tablets application is motivated by the fact that in 2013 approximately six billion people in the world have access to a mobile device [38], which are characterized by an excellent level of user-friendliness, connectivity, and a resolution such as to ensure the displaying of data-intensive clinical images [39][40]. This solution has been adopted with a good success by American private healthcare organizations, such as Kaiser Permanente [22] and MTBS 5, which have developed, for their customers, APPs that integrate: communication services between doctor and patient, booking and payment of examination, and consultation of the PHR 6 7, but those APPs only work inside their provider s hospital network and the information are not shared with other providers. Within the Apple App Store or Android Play Store you can find numerous application in the healthcare category, and among these there are also applications for the creation and consultation of the PHR 8 9, but they are not able to solve reliability issue aforementioned. In Italy 5 (last access ) 6 (last access ) 7 (last access ) 8 (last access ) 9 (last access ) 36

47 instead there are only APPs that allow you to download laboratory referrals, and these have been developed by several ASLs (Local Healthcare Unit) In this situation, our idea of developing a mobile application for the consultation of the Italian FSE seems excellent, as would solve most of the identified issues, in fact: It would ensure access to reliable data, as they are loaded by qualified health operators; It would potentially be accessible and used by every citizen, even by elderly ones, as would exploit a more user-friendly and intuitive device than the PC; It would ensure a maximum level of interoperability both within the Regional layer (Lombardy region) and the National Layer (last access ) 11 (last access ) 12 (last access ) 37

48 Chapter 3 3 Context: The Lombardy Case 3.1 Sistema Informativo Socio Sanitario (SISS) Overview SISS is the acronym of the Italian Sistema Informativo Socio Sanitario and it is a regional healthcare information system that links all the healthcare providers, operators, social services and citizens within the Lombardy Region, and also provides full access to clinical data and health-related documents generated during the citizen s process of care. The System is claimed to be Patient-Centric, however, as we will see later, the access to digital services that would enable the citizen to obtain an improvement of the offered services and the quality of care is not very user-friendly and as a result, the usage percentage of the online services (through the web portal of social and health services to the citizen) are still low. In fact, the system was primarily designed and developed to increase the efficiency and effectiveness of the governance of the social health system at the regional level, to simplify internal processes of the Local Health Units (ASLs) and try to reduce costs.

49 Today the SISS is made up of a number of computer systems that are gradually evolving according to a precise "e-health" strategy, i.e. the increased use of Information and Communication Technologies (ICT) for a digital and organizational innovation. The cornerstone of this strategy is the CRS-SISS platform developed by the Lombardy Region, upon which all the new health services are implemented, and the legacy ones have been integrated. The system is accessed through two cards fitted with microprocessor: the yellow "Regional Service Card" for citizens (CRS, from the Italian Carta Regionale dei Servizi), and the blue SISS Card for healthcare operators who works in Lombardy. With the CRS card, the citizen always brings with him the key to access to all his health and administrative information; moreover he may authorize healthcare operators to access them at any time. With the SISS card instead, the healthcare operators (e.g. GP) can "access" to the system by means of computer workstations (configured with the SISS) and view all the data regarding each citizen (FSE containing the patient clinical history), make pharmaceutical and specialist prescriptions, forward a hospitalization request or upload medical reports and referrals Actors The Italian health system expects that the organizational management of health services is a responsibility of the Regions, which in turn expect that the provision of those healthcare services to the citizens is a ASLs responsibility. In Lombardy the healthcare organization consist of: Local Health Units (ASL); Hospitals, either private or public, and their workers (hospital physicians, nurses, specialists etc.); General Practitioners (GPs) Laboratory Pharmacies 39

50 Figure 3.1 presents the major Lombardy healthcare actors and their interaction within the system. We can see that Country and Region play mainly administrative tasks (budget definition and health-care related performances monitoring), another task of the Region is to send to citizens home the CRS-Card for free, which will be used to access both the SISS and healthcare services provided by regional healthcare operators. Figure 3.1 Lombardy Region healthcare actors Another thing we can notice is that the citizen is at the center of the system because the former is designed in such a way that the patient has to move between an actor and the other with the aim to receive the demanded health care assistance. In fact for instance, the citizen in case of a medical need will have to go to his GP, who will visit him and as a result of that visit, the general practitioner will give him a prescription, with which the patient will choose to go either to a specialist or to a hospital in order to carry out the required tests. In the case where the citizen goes to a specialist, this last will provide a medical report to the citizen, who will have to take it back to the GP; otherwise the specialist could rely on a private laboratory, which 40

51 will send the medical report directly to the patient's GP. The private laboratories may also be used by hospitals when the citizen applies to them instead of to a specialist. However a citizen can go to a hospital without medical prescriptions in case of health emergencies but he cannot go directly to a specialist. The ASLs in this context perform management and monitoring functions System Evolution In 1999, the CRS-SISS project started with the requirements definition and a feasibility analysis, which in the following year led to the implementation of an on site pilot project in the Lecco District (covering about citizens). During the subsequent years, the project was expanded until it covered up all citizens of Lombardy (2005). In 2008 the system begun its integration and interfacing with the private healthcare provider, whereas in 2009 have been made available some online services for citizens (such as booking an exam, view citizen s personal data and information about his GP). In 2010 in response to a Italian government initiative and thus by following the country s guidelines [10], Lombardy region introduced the socalled FSE (Fascicolo Sanitario elettronico, in Italian) that, as we have seen before, it can be considered a middle ground between the PHR and EHR models [62][14]: in fact even if healthcare data are owned by the citizen and he is the one deciding who have the right to access to his FSE, data contained within it are uploaded by different qualified healthcare operators. The aim of the Italian FSE is therefore to make healthcare data always available when needed and accessibly by every healthcare provider or operator, regardless of who uploaded the documents. 41

52 1999 Project equirements definition and feasibility analysis 2000 On site pilot project in the Lecco District 2002 Project financing and beginning of the expansion to all Districts 2004 Two milion citizens involved in the CRS-SISS system 2005 All Lombardy citizens involved in the CRS-SISS system 2008 Healthcare private sector interfacing 2009 Delivery of some online services to the citizens 2010 The FSE was introduced Table 3.1 Evolution of the Lombardy SISS system Conceptual Framework The conceptual framework behind the development of the CRS-SISS system was based on a set of working hypotheses: The system should provide a maximum level of integration among all the regional healthcare providers; The system should promptly collect the data generated by different healthcare providers during the various citizen s care pathways (as shown in Figure 3.2), besides it should allow the reorganization of these data according to various "views. In fact, any data collected by the SISS during the execution of the citizen s healthcare process should have a double meaning and be qualified both as clinical and administrative data, which will populate both a regional data warehouse and the FSE. In this way it would be generated the knowledge needed to run all the clinical and administrative processes; 42

53 The system should rely on standardized healthcare providers Information Systems and electronic health records (EHR); The integration scenario should be implemented without destroying the current IT solutions implemented at local level, but conversely it should be drafted interoperability guidelines in order to provide a set of requirements to which those IT solutions should comply with; The documents shared and exchanged within the system should comply to a standard format; Figure SISS operation framework From these working hypotheses emerged an abstract architectural model (showed in Figure 3.3) based on the exploiting of a middleware able to integrate all the different Information Systems of the healthcare providers. Each healthcare provider (e.g. Hospitals) should in turn develop and make available a central repository, which will collects all the documents generated within the facility from local repositories, belonging to each department. The documents contained within the repositories should be standardized, in order to improve the efficiency of the sharing process and the communication between providers and integration middleware, besides to avoid 43

54 erroneous or duplicated data, both the hospital repository and the departmental ones should be synchronized with a central citizen registry, which at regional level keeps track and up-to-date all the administrative data and the links to the health-related documents of each citizen. For this reason the Lombardy region also drafted a set of integration guidelines, in which there were described different scenarios of integration so as to provide the healthcare providers with both a standard model regarding the generation and storage of documents, and the communication process with SISS. FSE Services for Citizens Dematerialization Governance SISS PLATFORM Integration with HC Providers Hospital LHU GP Private HC Pharmacy Others Figure SISS abstract architectural model In the upper side of Figure 3.3 we can see the pillar upon which the CRS-SISS is built: FSE, the lifelong Electronic Health Record [14] is the information foundation for the establishment of the so-called Health Network. This aims to revolutionize the healthcare processes by following a "Patient Centric" philosophy, where healthcare professionals are dynamically connect around the patient and his medical history, the data are generated and collected on the 44

55 basis of clinical care pathways followed by the citizen within the regional health "network", and are made available whenever and at any time to suit the specific clinical circumstances related to the individual and his care pathways. The Lombardy FSE will be analyzed inside the section 3.2 of this chapter. Services for Citizens, in this category are present all the services aimed to simplify the relationship between the citizen and the facilities of health services. In particular, the SISS makes available a range of services with the aim of improving health services and to minimize the number of contacts between the healthcare providers and the citizen as well as the time required to perform the very same related administrative requirements (e.g. online booking and payment services). The majority of those services are provided to the citizen via a web portal called portal of social and health services to the citizen [66]. Dematerialization, the dematerialization and the conservation in a digital format of health records is seen as one of the main keys to reduce healthcare expenditure, to improve the efficiency of socio-health internal processes and simplify them. Many activities relate to the development of the so-called e- prescription, which represent the transition from paper to electronic prescribing. Governance, for the Lombardy region the services within this category represent the hearth of the CRS-SISS system, in fact they allow the region to make analysis and forecasts of epidemiological trends and to manage and forecast healthcare expenditure trends (through business intelligence software and decision support systems), or to manage and monitor the administrative data flows. The CRS-SISS system through the above-mentioned pillars can achieve its four strategic objectives: Reducing the distance between citizens and Local Health Authorities (ASLs); Improving the quality of the diagnosis and treatment processes; Improving the planning and government of health expenditure; Improving the efficiency and simplify the internal processes of Public Administration. 45

56 3.1.5 SISS Architecture The CRS-SISS system is based on SOA architecture [48][95] and provides services through Web Service and J2EE (Java 2 Enterprise Edition). From the architectural point of view we can distinguish different elements that compose the SISS (Figure 3.4), and they can be split up into three logical levels: Central Domains; SISS Extranet; Members Applications; The highest level is represented by the Central Domains, which are computer facilities where the applications that make up the SISS reside. Here are stored and managed the administrative and clinical data of all citizens, but they are divided into two repositories, because the central repository of clinical data should not physically store the clinical electronic documents (CEDs) that would be generated during the process of care, but only an index made by (a) an URI that points to the local repository in which the original document is stored; (b) information about the pointed document (e.g. if it still exists) (c) an anonymous identification number that links the document to the patient. The middle level is represented by a connective infrastructure, called Extranet, which constitutes the communication platform between the Central Domains (first level) and the SISS members (third level). The Extranet is a virtual private network (VPN) made up by the so-called Integrated Center of Management (ICM) that ensures the connectivity and the exchange of information among the actors through a public network, thanks to the use of encryption software. The SISS Extranet is based on the geographical distribution of a number of providers that enable Healthcare facilities and Healthcare operators to use the exposed services. These actors operate within the SISS with two distinct roles: Service Provider: they provide services related to the activation and maintenance of the application connection" to the SISS of the member, through remotely or home interventions; Network Provider: they provide services related to the activation and maintenance of the "network connection" to the member s CGI. 46

57 Figure SISS architecture The third and final level is represented by the SISS Members, which comprise the healthcare facilities (e.g. ASLs and Hospitals) and the healthcare operators (e.g. GPs, Pharmacies etc.) who use the services exposed by the SISS. Each member is connected to the SISS system through two kind of access point called: Delegated Socket: that only allows a member to use the SISS services; Application Socket: that allows a member to expose services. According to those previously defined sockets types, members can be divided into two macro-categories: Active Members: who are those that expose and use services (e.g. ASL, CD ); Passive Members: who are those that exclusively use the SISS services (e.g. GP, Pharmacies). 47

58 In the CRS-SISS context a particular member is constituted by the Regional Call Center, which is connected to the system via an application socket that allows operators to manage some processes, such as the booking of healthcare performances and the suspension of the citizen s card. 3.2 The Electronic Health Record The Italian implementation of the electronic health record (EHR) is called FSE (Fascicolo Sanitario Elettronico, in Italian) and it represents a virtual medical record that collects and makes available all the clinical information and documents relating to a citizen, in order to give an integrated and contextualized vision of the health history of a specific individual. The clinical electronic documents (CEDs) that populate the FSE are linked to each other and shared by different health subjects (both public and private) and they could be produced by different healthcare operators and providers within the territory of the Lombardy Region. The FSE or lifelong EHR [14] will exist for the entire duration of the patient s life, and it will manually or automatically updated whenever the citizen will have to face a process of care throughout the regional health network. The aims of the FSE are to make available to authorized parties, when and where necessary, those deemed relevant clinical information on an individual, in order to support the physician, who is treating at that moment the citizen, with all the clinical information needed to determine his current and past state of health (it has to be noted that the FSE can be accessed even outside Lombardy, so even the foreign physicians who are treating the patient can benefit from the FSE), thus contributing to improve either the real time decision taken by the doctor (even in case of emergency), and the effectiveness and efficiency of care. In fact for instance, since all the examinations are stored in the FSE, it may not be necessary to repeat an exam during emergency care, thus you would save both in terms of time and money. The importance and confidentiality of the data processed within the Italian FSE arise security and privacy issues that need to be continually aligned with the most stringent rules established by the competent bodies (Authority of Privacy), which are responsible for the issuance of appropriate guidelines on the handling of personal data [56]. The citizen is the owner of the FSE and is also the one who has the right to establish the access policies; in fact data contained inside the lifelong EHR are available only to those healthcare professionals identified, via a profiling system 48

59 contained within the blue card-operator, as "doctors who are treating the citizen". This may be an implicit insertion (e.g. GP, hospital doctor who is treating the hospitalized patient), or explicitly requested by the citizen (e.g. a specialist to whom the patient wants to provide access to his FSE record) FSE Content The content of the FSE was defined in national guidelines [10] and it is represented in Figure 3.5, where we can see also that the creation of the Italian lifelong EHR can only take place after that the citizen gave his consent to the processing of personal data, at this point a new record will be created and added to the Central Domains repository (belonging to the first level of the SISS implementation architecture discussed in section 3.1.5) and after that, it will be updated with the indexes of all the citizen-related CEDs stored inside the local repository of the regional healthcare provider facilities. 49

60 Figure FSE content (simplified version) As we can notice from the picture, the FSE has several sections: Citizen s demographic information, they represent the patient s master data, they are uploaded from the Central Domains repository and synchronized with the Italian Ministry of Finance. Citizen s administrative information, they can only be updated by the CRS- SISS system and they consist of all the administrative information regarding the citizen, such as the master data of his GP or the exemptions to which citizen is entitled (e.g. handicap or chronicle illnesses). Electronic Clinical Documents, they are all the digitally signed CEDs that were generated from healthcare operators during the execution of a clinical process. Public and private health facilities are equipped with tools that on one side allow the conservation of the electronic clinical document (inside their local departmental repositories), on the other allow the publication into the FSE of the index that points to the generated CED. Today the clinical electronic documents in the FSE are: (a) laboratory reports, (b) letters of discharge, (c) 50

61 outpatient referrals, (d) emergency care reports, (e) diagnostic reports. In addition, the FSE is thought to be able to collect and make available X-Ray images, but there are some discussions about their quality and resolution. Another feature regarding the storing of CEDS is that they are no longer saved exclusively in a text format (still image of the document) but also in a structured one. This means that clinical documents in addition to being accompanied by their "image" will also have a corresponding HL7 CDA2 document (which is an international standard for the representation of clinical data in xml format)[96] that contains their values. Patient Summary, it is another important feature to promote the continuity of care and the management of emergency situations. It summarizes the clinical history of the patient and its content, which comprises all the information needed to define the current health status of the patient, all his allergies and prescriptions, is exclusively created, updated and managed by the GP [10]. Uncertified Data, they are documents and information loaded directly by the user through the appropriate function within the web portal section called Notebook. The National guidelines do not provide precise information on what to include within this area, but they suggest that the citizen should add information related to his lifestyle, diet, or any other document that the citizen consider relevant. Since those information are uploaded by the user, they are the only ones considered uncertified, because they might contain errors [60]. Pathology Networks, the SISS Network also provides forms of collaboration for the exchange and sharing of clinical information limited to a specialized and well-defined context. Thanks to these specific care networks, different specialists belonging to several structures within the Lombardy territory can collaborate in the process of care of a specific pathology, realizing a sort of virtual inter-provider departments, called Pathology Networks, designed to optimize the patient s process of care. The patient's medical history produced as part of a Network of Pathology is uploaded into the FSE. Some examples of Pathology Networks are: oncology, hematology, epilepsy and neurology. 51

62 3.2.2 FSE Implementation The Fascicolo Sanitario Elettronico bases the identification of the citizens, and the retrieval of their demographic, administrative clinical data, on the repositories of the Central Domains: the repository of Social and Healthcare Administrative Data, which is synchronized with the demographic database of the Ministry of finance, and the repository of Clinical Data, which stores and collects all the links to the clinical electronic documents (CEDs) generated by different healthcare providers within the Region, according to the flow described in Figure 3.6. Figure FSE population and content generation flow As we can see from the above picture, each CED is generated and stored locally in the provider s repository who have created it and than its link is uploaded into the FSE; more precisely each document is subject to the following process flow, also described in Figure 3.7: Preparation and signature of documents: The specific Departmental Information System (e.g. LIS or RIS) generates the clinical document and submits it for digital signature. The SISS digital signature process is based on the public key cryptography standard (PKCS#11)[63] and it is implemented through the Blue SISS Card, the one owned by the healthcare professionals operating in Lombardy. 52

63 Archiving of clinical documents in hospital repository: The digitally signed document, along with its consultation authorization, is than collected from the Hospital Information System and archived within its central hospital repository, which is connected to the SISS through the integration middleware layer. Publication in the FSE: Finally, the hospital repository sends a message to the SISS, through the integration middleware, in order to include the logical link to the CED into the FSE. Preparation and signature of documents The specific departmental system (e.g. LIS or RIS) generates the clinical document abd submits it for digital signature Archiving of clinical documents in hospital repository The system archives the document, along with the consultation authorisation Publication in FSE The hospital repository publishes the document into the SISS Figure 3.7 Clinical electronic document lifecycle Each document is classified according to its typology (e.g. Radiology, Lab, etc.) and it is qualified by context attributes and metadata (date, ward, issue, etc.). CEDs can be retrieved either chronologically or based on a medical specialty; additionally, in order to enable a search for documents based on clinical events (e.g. an Hospitalization), the CEDs are grouped together in accordance with the clinical event that generated them. The lifelong PHR is capable to manage documents both in textual and structured formats, in fact each CED is usually a digitally signed PDF and it should be produced either as a document in textual format or as a structured one following the 53

64 HL7-CDA2 standard format [96], but today the only documents inside the FSE that follow this standard are: Laboratory Reports Letters of Discharge Patient Summary As we have mentioned before, since healthcare professionals digitally sign all the CEDs inside the FSE and since those documents are completely interoperable across the region, the FSE implementation can easily overcome the major issues, emerged from the Systematic Literature Review, that afflict the PHR systems, i.e. the reliability and interoperability issues. 54

65 Chapter 4 4 Concept 4.1 SISS-Mobile Overview Nowadays there is a growing interest and need towards computerization of health data and digitization of healthcare processes. In fact citizens would like to see this idea realized in order to have services that could help them and assistance them during their clinical processes especially from an administrative point of view. This would enable an individual to save time either by avoiding queues at the counters or by eliminate the need to go to several different offices in order to retrieve documents, prescriptions or reports. Currently citizens can rely on a variety of systems, which are predominantly web based, and call centers that could help them to manage their healthcare processes by allowing them to: Book an exam; Pay the ticket; View health reports;

66 However the majority of these services is provided by different organizations and is delivered through different places, which this means that there is no type of integrated system, except for rare cases. In Lombardy for instance citizens have the CRS-SISS platform, which provide a web portal called Portal of Social and Health Services that integrates almost all the functions needed to minimize the patient contacts with healthcare facilities, but it is not provided any form of online payment. However, the utilization percentage of those online services is very low, primarily because a lot of people don t even know that they exist, and if they do, they cannot easily access to them since they are not user-friendly and they can only be accessed through a PC/Web Browser, thus it is not available anywhere and at any time. The accessibility methods might not seem like a problem, but you have to take into account the fact that most of the people who need medical care are elderly people, so it is not said that they are familiar with these technologies. This represent the reasons that led us to develop an integrated mobile system that integrates all the already existent services provided by the SISS system and allow the citizen to consult and manage his FSE through a new and user-friendlier authentication method, based on the exploitation of QR-Code technology [97][98][99], that at the same time ensures the level of security and privacy required by the Italian law Purpose of the System In general, the purpose of the SISS Mobile system is to manage the citizen s health data, going to assist him in his care process, providing him services ranging from simple consultation of administrative information, such as visiting hours of his GP and the location of the doctor's ambulatory, to the integrated management of the examinations booking process and the subsequent withdrawal of referrals. Obviously this system must be accessible by the patient regardless of where he is located, and in every moment of the day, besides SISS Mobile must be a usable system, i.e. it should have simple and customized interfaces based on the type of user/usage. In order to reach all the previously defined objectives, during the concept and design phase we outlined a set of goals to pursue, which are described in the following Figure

67 SISS Mobile Goals End-to-End Assistence Usability Accessibility Mobility- Ubiquity The System should follow and assist the patient during each phase of his care process System interfaces should be simple and customized on the basis of the type of user/usage The system should provide an authentication method to the CRS- SISS without the use of the smart-card The system should be accessible from any location and device (primarly smartphone and tablet) Figure 4.1 SISS Mobile goals SISS-Mobile Stakeholders The purpose of SISS-Mobile once again is to target healthcare need of end users, assist them during their personal care lifecycle, integrate information and services sources and finally to build and integrated healthcare assistance service. In order to achieve its objectives, we have identified three main classes of stakeholders that the SISS-Mobile system interacts with: CRS-SISS system, healthcare providers and citizens. CRS-SISS System: it is the one that produces and exposes services that allow you to manage and to interact with the citizens and healthcare providers data, which are stored inside the SISS central repository. Healthcare Providers: they are all the SISS members that we saw inside the section related to the description of the SISS three-layer architecture: Business Members (e.g. ASLs, public or private hospitals) and Healthcare Operator Members (e.g. GP and pharmacies). In this context their purposes are to 57

68 provide to the citizens their login credentials to have access to the SISS, and generate the clinical data that feed the SISS central repository. Citizen: they are the end-users of the application Overall Vision The previously defined objectives and stakeholders led us to the following using scenario (Figure 4.2) that describes, at a high level of abstraction, the interactions that occur between the system and its stakeholders. Figure SISS Mobile overall operation framework First of all the user will have to go to an authorized center, which at the moment are the ASLs and the regional hospitals, with a valid ID Card and his CRS smartcard, in order to request his login credential for the access to the online services. Here he will receive a copy of the QR-Code and its temporary password that the citizen will have to use during his first access to the APP (path 1a ), but if the citizen already has the access credentials, he can use them to login into the dedicated website, in 58

69 which he can both view the QR-Code and manage his devices. Otherwise it should be delivered also a fully digitized enrollment procedure (path 1b ), in which the user can send via Certified a scan of his identity document and his CRS, in order to receive the login credentials and the QR-Code. This former approach should help to increase the usage and diffusion percentages of the online services, as it do not requires that the citizen should physically visit one of the authorized centers, but he can do everything from the comfort of home. After the acquisition of access credentials, the user must download the APP from the store of his smartphone or table, and on first use of the application, he must "enable" it by scanning the QRcode, then he will be asked to insert the temporary password provided on the enrollment phase and afterwards he will be able to choose a personal password that will be used during the authentication procedure of subsequent accesses to the APP (path 2 ). Once the abilitation phase is completed, the APP will be "tied" to the device on which it is installed; as a result subsequent authentications will be possible only through that device and the user will only have to enter the chosen password. Once authenticated (path 3 ), the citizen can: access the clinical documents contained within his FSE, view his administrative information and those relating to his GP, book an examination and even pay a ticket. 4.2 Business Architecture In order to define a target application architecture that suits our overall concept (TO-BE), we ll first have to analyze what is the current situation (AS-IS), what are the activities that the citizen has to perform to gain access to the currently delivered online services and what the former are providing AS-IS Situation Since we are going to design and develop a mobile application that is intended to be User-Oriented, in this section we ll analyze the services that nowadays are provided to the citizens through the use of ICT Technologies in order to obtain the criticalities that are facing these solutions, and than to solve them in the TO-BE situation. 59

70 The only service that falls into the category is the The portal of social and health services to the Citizen [66] that is a website that integrates all the services exposed by the CRS-SISS system, which are targeted to the citizen Driver Analysis Our analysis will be driven by the goals we want to achieve with the development of the SISS-Mobile APP, which are defined into the section 4.1.1, and for the sake of clarity re-presented below: End-to-end assistance during the healthcare process; Accessibility to the SISS online services; Mobility-ubiquity to access to the SISS services anywhere and at any time; Usability to break down the barriers that prevent elderly people from using digital services End-to-end assistance In order to understand the assistance coverage through digital services during the whole process of care, we have produced the following hierarchical diagram of Figure 4.3, which elicits all the online services that a citizen can use and manage. We see that they are divided according to four macro-categories: Citizen Data Management: This service allows the citizen to browse the details of his personal data (e.g. name, address, residence, etc.), those relating to possible exemptions from participation to the health care spending and he can also print the PIN relative to his CRS smartcard. In this way patients can verify the correctness of their data if necessary notify errors to their ASL. FSE (lifelong Electronic Health Record): This service allows the access to the FSE, in which is possible to view or download all the clinical electronic documents (CEDs) belonging to the patient. This service in turn is divided into: o View Health Documents: here a citizen can view and download all his referrals and clinical reports. Besides, the citizen consulting the report through this service fulfills the obligations of withdrawal and is therefore exempt from the withdrawal of the paper report. 60

71 o View Healthcare Contacts: in this section the patient is allow to view and download all documents relating to health events that were recorded (hospitalizations, specialist visits, emergency department events, childhood vaccinations for those born from 1990 onwards, etc.). o Notebook Service: here the citizen can upload or view all the documents it deems relevant to determine his state of health, for instance you can save scan reports of documents not included into the FSE or create a diary of the most important events of your health history; o Prescription: this feature allows the citizen to browse the specialist, pharmaceutical or hospitalization prescriptions recorded in the SISS. o Vaccination: With this feature you view all the vaccinations carried out by a citizen. Booking Management: this service allows the citizen to make online reservations either for examinations or specialized tests and view or cancel appointments already booked. To use the service the patient will need to have a SISS prescription made by the doctor. The SISS prescription is the one that contains the IUP code (Identificativo Univoco della Prescrizione, in Italian. It is a unique identifier of the prescription) in the upper left corner. With the Check Agendas service it is possible to consult the performance (or agendas) provided by the hospitals and check the average waiting time to perform the searched performance. General Practitioner Management: With this service the citizen can change his pediatrician or family doctor and consult information regarding their business: contacts (telephone number), outpatient address, and office hours. 61

72 Citizen s Portal Citizen Data MGNT FSE Booking GP MGNT Master Data View Health Documents Healthcare Contacts Booking Request Cancel Booking GPMaster Data Change GP Print PIN Prescriptions Vaccinations Print Report Check Agendas Search GP Exemptions Details Select GP IUP Notebook Load Document View Document Figure Online services provided by the citizen's web portal of Lombardy Region Criticalities Relying on the description of the features offered by the SISS of the previous section, we can state that with their range of services are able to assist the citizen for almost the whole process of care delivery (from a medical need to the digital withdrawal of the related referral), however it is not present any form of communication between the patient and his GP apart from a phone call, which seems to low considering that we are living in the era of social networks and other Web 2.0 technologies. Another criticality that is immediately evident is that there is not the chance to pay a test, an examination or a ticket through the web. In addition to these two main issues we can state that there are also some little efficiency issue regarding the Booking functionality that could prevent to get an end-to-end assistance. In fact the citizen cannot book every prescription, but only those that have been uploaded inside the SISS Central Domains (CD) by the 62

73 physicians who generated them. Furthermore, if a prescription contains more than one performance to perform, it cannot be processed by the online service. In both this cases the citizen will have to book his prescriptions by calling the toll-fee regional call center. Another issue regarding the booking package is related to the Check Agendas service; in fact not all the healthcare providers expose their agendas or the average waiting time for exams, and even when they do it, those data are not reliable because they are not up-to-date Accessibility For accessibility we mean the easiness with which a user can access the online services provided by the SISS, therefore within this section will be analyzed the existing authentication methods. You can choose from four types of authentication methods that, on the basis of the security level provided, allow the citizen to access to different services, which in turn provide social-health information of a different degree of confidentiality, as depicted in Figure 4.4. The three authentication methods are: Authentication with UserID and Password ; Authentication with UserID, Password and One Time Password (OTP); Authentication with CRS Smartcard, Smartcard Reader and PIN ; Plus there is a fourth authentication method that is exclusively used to get access to the booking service without having requested any password or PIN code: Authentication with UserID, Fiscal Code and IUP Code. During our analysis, however, we will not take into account the last exposed authentication method, as it does not guarantee access to the portal of the citizen itself, but to a separate service, reachable through a link inside the information area of the web portal. 63

74 Figure Current citizen s web portal authentication methods and services delivered The UserID that the citizen has to use in order to authenticate himself, consists of the authentication number of the CRS placed on the back of the smartcard. In the following section all these four authentication methods will be deeply analyzed and it will be also explained what the authentication components (UserID, Password and OTP) represent and how a citizen can obtain them Authentication with UserID and Password This type of authentication is available only if the citizen has requested the login password at the counters of the regional hospitals that are qualified to issue that password. The process flow regarding the activities to be performed in order to gain access to the SISS online services following this kind of authentication is showed in Figure 4.5. We can see that a citizen can authenticate himself by using a combination of the UserID and a password, which can be obtained by going to any hospital of the region with a valid CRS. The operator, after identifying the citizen will ask him to sign the Request form for Credentials and to provide the mobile phone number 64

75 where he will receive the second half of the temporary password. The operator at the end of the operation releases to the citizen a sheet containing the instruction for the online access to the services, and the first-half of the password, while the second half will arrive with a text message. The citizen, in the Authentication with UserID and Password section of the web site, will have to insert the UserID and the password, which if this is the citizen s first access to the service will be the concatenation of the two halves received during the Credential Request Phase. This password can only be used during the first access since it will be prompted to enter a new one immediately after the authentication Criticalities Since this method requires only the insertion of UserID and Password, it can be considered the most direct and user-friendly one to access the portal of the citizen. However it does not allow the viewing of the most relevant clinical data because it does not provide a strong authentication, which is an authentication method based on the joint use of two or more authentication factors (e.g. things that the user knows, things that the user has or things that constitute the user himself); in fact after a login performed using this authentication method a citizen will only have access to the Citizen Data Management, Booking and GP Management services, but the consultation of his FSE will be forbidden. Moreover, the UserID and Password authentication method forces the citizen to goes in person to a hospital in order to receive his temporary password for the access to the online services. 65

76 Figura Figure Authentication with UserID and Password process flow 66

77 Authentication with UserID, Password and OTP This type of authentication is available only if the citizen has requested the login password at the qualified counters of regional hospitals and has provided them the mobile phone number on which he will receive, via SMS, the throwaway code of the one time password. The process flow regarding the activities to be performed in order to gain access to the SISS online services following this kind of authentication is showed in Figure 4.6 where we can see that the flow is very similar to the previous one (Figure 4.5), in fact the two authentication methods share either the parts regarding the obtaining of the access credentials and the first part of the login process. In order to access to the services delivered through web portal of social and health services, the citizen must go in the Authentication with UserID, Password and One Time Password section of the web site, where he will first have to insert the UserID and password, which even in this case, if this is his first access to the service, the password will be the concatenation of the two halves received during the Credential Request Phase; then the citizen will have to wait that the SISS sends to him a text message on his mobile phone with the OTP code. The received one time password will be valid for three minutes, and then the citizen will need to repeat the authentication procedure Criticalities This type of authentication grants you a strong authentication, thus the citizen is allowed to take advantage of every service delivered through the web portal, FSE included. Nevertheless it share with the first authentication method that we have seen, not only some activities of the process flow, but also its credential acquisition issue. Besides you will often need to repeat the authentication procedure several times due to non-receipt of the text message containing the access code (OTP). 67

78 Figure Figura Authentication with UserID, Password and OTP process flow 68

79 Authentication with CRS Smartcard, Smartcard Reader and PIN For this type of authentication a citizen will need more things than in the other two methods. In fact, in addition to the CRS smartcard will also need to have (a) the corresponding PIN code, which is obtainable at the qualified office of any ASL; (b) a smartcard reader and (c) the CRS Software that is compatible with your operating system. The process flow regarding the activities to be performed in order to gain access to the SISS online services following this kind of authentication is showed in Figure 4.7. We can notice that after a first phase of preparation of the working environment, in which the citizen will have to download and install the card reader drivers and the CRS Software Manager, the user can access to the services by going in the Authentication with CRS Smartcard, Smartcard Reader an PIN Code section of the web site and then simply insert the PIN code when the system will demand it Criticalities Even if this authentication method would seem to grunt us the simplest and most intuitive way to get access to every feature available on the citizen s web portal, actually it hides several technical and usability issues. In fact, first of all there is very limited presence of smart card readers in citizens home, furthermore even if a citizen has a smartcard reader or asked it to the Lombardy Region, he will face many difficulties during the installation of the device driver, and especially during the CRS Software Manager installation, because the procedure is not intuitive or user-friendly at all. Besides, this software is not compatible with all the browsers, but only with Windows Explorer; for the other browsers (e.g. Mozilla Firefox or Safari) is available a plug-in, which, moreover, does not work too well either. Another issue is that the smartcard readers are linked to the PCs and it doesn t exist a way in which they can be plugged into another device either because the absence of a USB socket or the absence of drivers. 69

80 Figure Authentication with CRS Smartcard, Smartcard Reader and PIN process flow 70

81 Mobility-Ubiquity With the word " Mobility and Ubiquity " we mean the ability to access the services provided by the CRS-SISS Platform in a situation of full mobility, i.e. wherever you are and at any time of the day. As we have seen in the previous section, in order to access to the whole set of services delivered through the Portal of the Citizen website, a user must perform a login via a strong authentication, which is granted only by two methods of authentication: (a) the Authentication with CRS Smartcard, Smartcard Reader and PIN Code and (b) the Authentication with UserID, Password and OTP. The use of one of the methods implies that the system cannot guarantee access to all the functionality of the web portal (especially the access to the FSE) in a situation of full mobility because: With the (a) process of authentication we are forced to use a personal computer, accordingly, not relying on other types of devices (e.g. smartphones or tablets), a mobile access becomes impossible; Even if the authentication process (b) solves most of the problems relating to the mobile access, since it can be viable on any kind of device with a web browser implemented on it, the use of the phone both as a token for the generation of the OTP and the as a device through which access to the SISS, makes the whole procedure complicated and cumbersome. Moreover, the use of a mobile device to gain access to the Portal of the Citizen services has implication related also to the Usability Driver of the subsequent section Usability For Usability we mean that the interfacing to the system should be simple and customized either on the basis of the type of user and on the features that the citizen want to exploit. In the previous sections we have seen that the only way that the citizen has to interface and interact with the CRS-SISS System is via the web portal, so this implies that in order to access to the Portal of Social and Health Services to the Citizen you have to go through a Web Browser, which, since currently the website it is not optimized for the supporting of small-size screens, could lead to problems of usability and viewing on smartphones and tablets. Besides, especially in a situation of full mobility, not having a direct access to the services of the Portal of the Citizen, but always needing to pass through Google in order to find the link to the 71

82 site, could generate frustration in the end-user. Another criticality we found is linked to the use of digital devices in relation to citizens age; in fact, smartphones, PC and tablets are widely used by younger people, but they can easily become a barrier for elderly ones, especially if they have to struggle to adapt to interfaces that have not been designed according to the function that they should offer to the end-user Fit-Gap Analysis After having analyzed the current system on the basis of the selected driver and highlighted its criticalities, in this section we will focus on the changes that should take place in every driver in order to take him from the current situation to an ideal one. This process is called Fit-Gap Analysis (FGA) and we will execute by drawing a table (Table 4.1) that summarizes the changes of each driver on the three columns asis, to-be (changes) and actions needed to fill the gap. End-to-end assistance Driver As-Is To-Be Actions The system does not provide to the citizen a complete coverage during the whole healthcare process, but only in certain phases (providing him assistance to retrieve information on his GP, and telematics services regarding e-prescription, booking and referral withdrawals). Inefficiencies of the booking system due to both technical issues in managing the e- prescription and consequently its booking, and to the not generation of SISS The system provides services that are able to assist the citizen during his whole healthcare process. Optimized booking system that is able to manage all the generated e- prescription. Every GP generates the SISS prescriptions and uploads them into the SISS central repository. Barriers for the release of the access credentials to citizens have been pull down. To integrate a payment service into the system. To develop a communication system that allows the exchange of messages between patients and their GPs. To redesign and optimize the booking system package in order to allows it to manage every kind of e- prescription and thus overcome the issues emerged inside the section To provide incentives to the GPs in order to make sure they will always generate the SISS 72

83 Accessibility Mobility-Ubiquity Usability prescriptions by the GPs. Barriers in releasing the access credentials for the online services to the citizens. Absence of an authentication method capable of providing access to all the citizen s health data, in a relatively simple way and that is suitable to be employed in a mobile device. The access to the whole set of services provided by the CRS-SISS Platform is not guaranteed in a situation of full mobility because, as we have seen in section , it mainly relies on the use of PCs. Low level of system usability mainly due to the forced use of the web browser, and poor design of its interfaces. The web pages are Introduction of an authentication method capable of providing access to all the citizen s health data, in a relatively simple way and that is suitable to be employed in a mobile device. Extend the range of devices able to access the whole set of services provided by the CRS-SISS Platform in a situation of full mobility. Improved system usability Optimized interfaces according to their content and offered services. Greater prescriptions and then upload them into the SISS central repository. To increase the number of authorized centers to issue the access credentials. To make available to the citizen a service used to release the access credentials in a complete computerized way, through certified . To design and develop an authentication system based on the exploitation of the QR-Code technology that can grant a strong authentication, which is needed in order to access to sensitive health data. To design and develop a dedicated APP capable of directly access all the functionalities provided by the Citizens' Portal. The graphics and layouts through which you can access the APP content (which we defined in previous table field) will be 73

84 not optimized for the viewing on small-size screens. The use of PCs and other devices can represent barrier for elderly people, who are the main users of health services. involvement of elderly people in digitalized healthcare processes. optimized for the viewing on small screens. The application should be developed on various platforms, including the Smart-TV Table SISS Mobile Fit Gap analysis From the FGA is evident that our idea of developing a smartphone application, which integrates all the functionalities that are provided by the SISS Portal of Social and Health Services to the Citizen, and will be accessible through a new and userfriendlier authentication method that exploits the QR-Code technology, is more than justified To-Be Solution In this section we will describe the solution we propose in order to overcome the issues emerged both during the systematic literature review and the as-is situation analysis. Once again, our idea is develop an integrated mobile system that integrates all the already existent services provided by the SISS system and allow the citizen to consult and manage his FSE through a new and user-friendlier authentication method, based on the exploitation of QR-Code technology, that at the same time ensures the minimum level of security and privacy required by the Italian law. In fact, the proposal of a new authentication system is essential, both to gain access to the health data contained within the SISS repositories that are mandatory to develop the APP, thus solving the actual mobility related issues, and to provide a method for the access to the SISS services less "heavy" than those currently in use and that is more suitable to be used on mobile devices, which is essential in order to obtain a solution that will break down the issues related to usability and the overall low utilization percentage of digital health services that emerged during the SLR. From the point of view of the security offered, the authentication system that we propose would be an acceptable middle ground between the most secure OTP and the classic userid + password authentication. With our QR-Code Authentication Method, the application, in order to work, it must be enabled by binding it to the citizen s account and to the 74

85 device on which it is installed. This, as we will see in detail inside the following section, will be performed during the first access to the APP through the scan of the QR-Code, and then it will be possible to access to the SISS services simply by opening the SISS-Mobile APP and inserting the password you chosen during the activation phase. The SISS-Mobile application and its related authentication method ideas were presented to Lombardia Informatica S.p.A. [100], which is the company responsible for the development and implementation of the CRS-SISS system, and they supported us by providing the access to some healthcare documents for testing purposes, and some information and constraints regarding the privacy and security policies that our APP should ensure, plus some information on the SISS-Mobile integration with the SISS, which we ll discuss later during this chapter QR-Code Authentication Method As mentioned before we presented our overall concept to the Lombardia Informatica (LI) management group, this was made primarily to understand if the development of the SISS-Mobile APP was feasible from a technical point of view and if it could have been integrated into the SISS Platform. They have responded affirmatively, pointing out the minimum requirements to be met to comply with the privacy and security constraints. In particular LI told us that in order to have access to the SISS health data our QR-Code based authentication method would have to ensure: A strong authentication; An encryption system to encode the data within the QR-Code; A system for the remote disabling of the APP authorization to access to the SISS data (to deal with problems that may arise in case of theft or loss of the device where you installed the application); Having acquired more details about the mobile system that we wanted to develop, we have reworked the project and divided our authentication system into the following building blocks: 75

86 QR-Code Content; Device Activation; Device Deactivation; Login Phase; QR-Code Content The first thing to do is to define what will be contained within the QR-Code. Figure SISS Mobile QR-Code content As we can see from Figure 4.8 the QR-Code is made by three elements: Security Code: it is the string that we will see if we scan the QR-Code with a QR-Code scanner application. The security code is an encrypted string generated from the combination of the Temporary Password and the QR-Code Serial. The encryption algorithm that we used is the AES (Advanced Encryption Standard) [70][71], which is a block cipher algorithm with secret key that was chosen as the standard for U.S. federal information processing since December The key is required for decoding, and it will be saved in the SISS repository in order to ensure maximum safety. QR-Code Serial: each QR-Code must be unique and associated to only one citizen; hence the QR-Code Serial represents the alphanumeric string that is used to uniquely identify the QR-Code and the citizen associated with it (QR- Code Serial (X)=Citizen (X)). Temporary Password: it is the password provided to the citizen during the enrollment phase, when he gets his access credentials. The temporary password 76

87 will be used only during the first access to the APP in order to activate the user s device, after that it will be changed Device Activation After viewing what is contained inside the QR-Code, we will describe the core process of our authentication method, which is the Device Activation Phase shown in detail in Figure 4.9. In fact, our key-concept is to achieve the strong authentication through the joint use of the QR-code, the password and the serial of the device on which the APP is installed. For the sake of clarity we will divide the whole process into several sub-phases: In the first phase the citizen must have obtained the QR-Code and installed the SISS-Mobile application into his device, then he will have to scan the QR-Code. The APP will read the Security Code and will send it to the server together with the Device Serial. The server will receive the Security Code and it will perform a search in its database in order to verify both the authenticity and the status ( Blocked or Active ) of the scanned QR-Code and, if everything was ok, to identify the associated citizen. At this point the server knows the identity of the user, so it can be able to have access to all his data, which will be used later in the process, and check if the received Device Serial is already bind to his account. This phase ends with the display of an error message inside the mobile application or with the request from the server of the user's Temporary Password. In this phase will be executed the password validation. This is achieved by (a) generating a new Security Code using as input the received Temporary Password and the QR-Code Serial associated with the identified user, and (b) the subsequent comparison with the Security Code received in the second phase. If the two codes will be equal, then you can proceed to the next phase, otherwise the server will increment the counter for the password attempts failed, and at the fifth failed attempt it will block the QR-Code Serial. At this point the citizen will need to generate a new QR-Code. 77

88 The server will now ask the user to enter (a) a New Password to be used for the next login and for the activation of another device (instead of the Temporary Password used in phase 2), and (b) the device details, i.e. the user must assign a name to the device that he is activating in order to be able to recognize it and manage it within the WebAPP. In this sub-phase the user enters the required data and send them to the server through the APP, which automatically sends also the Device Serial. The server now will update its database with all the information received, including a New Security Code, which is generated from the QR-Code Serial associated with the citizen and the New Password he has just chosen. This, as we shall see, it would be completely hidden to the citizen, hence he will not have to generate or use a different QR-Code during the following activation phases. This New Security Code will be only used by the server during the activation process of another device (instead of the Received Security Code used in phase 3). The phases described above were referring to the first-ever activation of a device that the citizen is running after getting his QR-Code. In fact, if the citizen after activating a first device (for example a smartphone) would also activate a second one (for example a tablet), he should perform a slightly different flow, which will be presented below. The first phase remains the same, in fact the citizen will scan the same QR- Code than before, which as we said earlier it should not be changed. In this phase the behavior of the server will not change, but the citizen will have to enter the New Password that he has chosen during the previous device activation process, instead of the Temporary Password provided at the time of the release of the QR-Code. The server this time will generate the Security Code for the comparison using as input the received New Password and the QR-Code Serial associated with the identified user, and then it will compare it with the one that it has stored in its database during the previous phase number 6. If the two codes will be equal, then you can proceed to the next phase, otherwise the server will 78

89 increment the counter for the password attempts failed, and at the fifth failed attempt it will block the QR-Code Serial, as was happening before. In this phase the server will only ask to the citizen to enter the Device Details. This sub-phase it is identical to the phase number five of the previous flow. In this last phase the server will update its database with all the information received, without generating any other New Security Code. A key feature of this authentication system is that passwords are not saved in the database, but they are contained within the Security Codes on which it has been applied the AES encryption algorithm. Besides the validation process, which is obtained through the generation of a test Security Code and its subsequent comparison with the original one, is not reversible. 79

90 Figure Device Activation process flow 80

91 Device Deactivation Disabling a device is needed to cope with possible theft or loss of the device itself; in fact, in this scenario a third people could attempt to access to the citizen s health data by trying to find out his password, or if he entered in possession of the citizen s QR-Code and its Temporary Password he could also try to activate an his own device with will access to the citizen data. So it is mandatory to provide both a method to block the access to the SISS services from a specific device and a method to block the QR-Code. We solve this problem by providing two different methods by which a citizen could block a specific device from gaining access to the CRS-SISS Platform: Through the WebAPP that would be integrated inside the citizen s personal area of the web portal of the citizen: in this case the citizen will only have to select the device he wants to disable and click to the button Deactivate ; in this way the WebAPP will update the server database by changing the device status flag and setting it to Inactive. By calling the Toll-Fee Regional Call Center: in this case instead, the user will have: (a) to call the Call Center, (b) to identify himself and (c) to provide the device s name he wants to disable (in case the citizen does not remember the device s name, it will be possible disable them all and/or block the QR- Code serial matched to him); then the Call Center operator will set the device status flag of the indicated device to Inactive, or he will disable the QR- Code Serial by setting his Status flag to Blocked Login Phase Obviously in this section it is assumed that the citizen has already performed the device activation phase. Even in this case we have divided the process flow (shown in Figure 4.10) into different sub-phases: Here the citizen will access to the APP and he will select his account, also providing his Password. Note that the user must select his account because the application will be designed for the management of multiple accounts. 81

92 The SISS-Mobile APP will now read (a) the Password entered by the citizen, (b) the Device Serial, (c) the UserID (which is an identification number, saved at local level, that is needed in order to let the server identifies the citizen that is sending the access request), and then it will send all this information to the server. In this phase the server will perform the user authentication by validating the received data. In fact, first of all the server will check into his database to find a citizen linked to the received UserID, then it will generate a Test Security Code using the received Password and the QR-Code Serial associated to the user s account as inputs. This Test Security Code is compared with the one stored into the DB in order to see if they are equal. If they are equal, it will also perform a comparison between the device serials bound to the citizen s account in order to find a match with the received one. If this happens, then the server would control the activation flag of the corresponding device which, if found to be active, would end the authentication procedure by giving a positive outcome. 82

93 Figura 3 Figure Login phase process flow 83

94 Privacy and Security Requirements We have seen in the previous sections that Lombardia Informatica told us that in order to have access to the SISS health data our QR-Code based authentication method would have to ensure: A strong authentication; An encryption system to encode the data within the QR-Code; A system for the remote disabling of the APP authorization to access to the SISS data (to deal with problems that may arise in case of theft or loss of the device where you installed the application); In this section we will evaluate if previous constraints have been met. It is evident that the last two points have been met, as (a) we have added the ability to disable the service both through the WebAPP and through the call center, (b) we used the AES encryption algorithm to protect the security code contained within the QR-Code. The first point on the other hand does not appear so clearly in that first of all we should explain that a strong authentication is an authentication method based on the joint use of two or more authentication factors which typically are: Things that the user knows; Things that the user has; Things that constitute the user himself (e.g. fingerprints); Table 4.2 Privacy and security requirements compliance 84

95 From Table 4.2 it can be concluded that the proposed solution meets the requirements of security, since both phases are based on two Authentication Factors. 4.3 Use Cases In order to properly describe the SISS-Mobile Use Cases (UC) we decided to exploit the Unified Modeling Language (UML). UML is a general-purpose visual modeling language that is used to specify, visualize, construct, and document all the characteristics of a software system [67]. It is used to understand, design, configure, and control information about such systems. It is intended for use with all development methods, lifecycle stages, application domains, and media. It has static, dynamic, environmental, and organizational parts. In our treatment we will focus on the static aspect of the SISS-Mobile system with the definition of the relevant objects and to its implementation, as well as the relationships among the objects. Finally the UML specification does not define a standard process but is intended to be useful with an iterative development process. For the description of the static aspects of our project we use a Use Case Diagram. The purpose of a use case is to define coherent behaviors without revealing the internal structure of the subject. The definition of a use case includes all the behavior it implies: the main sequences of actions, different variations on normal behavior, and all the exceptional conditions that can occur, together with the desired outcome [68]. UML Use Case diagram describes functions and services offered by the system and how actors interact with them. After the representation of all the Use Cases related to the System implementation, they will be explained through Jacobson Card. Jacobson provides an UML tool able to describe in detail a use case by providing a short description of it, the involved stakeholders, the pre-conditions and post-conditions, a process flow in which the use case is subdivided, eventual exceptions, frequency, priority and a risk level [69]. The Following Use Cases were derived from the SISS services provided through the Portal of Social and Health Services to the Citizen described in Figure 4.3, since our goal was to provide all the functionality offered by the web portal and add new ones in order to increase the quality and efficiency of the assistance during the healthcare processes. 85

96 SISS-Mobile Use Cases: UC1: Activate App UC2: Login UC3: View Citizen Data UC4: View GP Data UC5: Change GP UC6: View Referrals UC7: View Prescription UC8: View Healthcare Contacts UC9: View Vaccination List UC10: Notebook UC11: Load Document UC12: Delete Document UC13: Book UC14: View Booking UC15: Cancel booking UC16: View Agendas UC17: Pay Ticket The interactions between these Use Cases and their actors are shown in Figure Figure 4.11 SISS Mobile use case diagram 86

97 The elicited UCs were then be divided, according to their features, into five groups: Authentication Patient/Doctor Data Management FSE Booking Management Payment Each group will then be described individually with the use of Jacobson Cards, in which we will assume that there are no connection errors and that the citizen has given his consent to the processing of personal data, which is necessary for the generation of the FSE. Use Cases UC1 UC2 UC3 UC4 UC5 UC6 UC7 UC8 UC9 UC10 UC11 UC12 UC13 UC14 UC15 UC16 UC17 Authentication X X Patient/Doctor Data MGNT X X X Groups FSE X X X X X X X Booking MGNT X X X X Payment X Table 4.3 Use cases groups definition 87

98 4.3.1 Authentication Figure Authentication group, use case diagram UC1 Activate APP Description Actors Precondition Post Condition The User accesses the section related to the APP habilitation, scans the QR-Code and finally enters the provided temporary password User, System The user is in possession of the QR-Code and has downloaded and installed the SISS-Mobile APP The user can proceed to the display of his personal health information Normal Scenario 1.1 User Clicks on the link Activate APP 1.2 System Activates the camera of the device 1.3 System Displays a screen showing what the camera is taking 1.4 User Frames the QR-Code and scans it 1.5 System Reads the data contained within the scanned QR-Code 1.6 System Performs the validation of the read data 1.7 System Asks to the user to insert the temporary password 1.8 User Enters the temporary password 1.9 System Performs the validation of the received password 88

99 1.10 System Displays a screen with a form for choosing a new password 1.11 User Enters the new password 1.12 User Enters the confirmation password 1.13 User Clicks on the OK button 1.14 System Shows a summary screen 1.15 User Clicks on the Confirm button 1.16 System Shows the Main Screen of the APP Exception Frequency Priority Risk The data within the QR-Code are incorrect; The user has already activated the APP; The user has entered an incorrect confirmation password Low High High Table Activate APP Jacobson card UC2 Login Description Actors Precondition Post Condition The user goes to the login screen, enters the password he chose during the registration phase and accesses the SISS-Mobile APP. User, System UC1 The user can proceed with the interaction with APP and access his healthcare data Normal Scenario 2.1 User Goes to the Login screen 2.2 System Displays a screen containing the login form. 2.3 User Enters the password 2.4 User Clicks on the Login button 2.5 System Performs the validation of the received password 2.6 System Shows the Main Screen of the APP 89

100 Exception Frequency Priority Risk The user enters an incorrect password; The device from which the user is trying to authenticate himself is blocked Medium-High High High Table Login Jacobson card Citizen/GP Data Management Figure Citizen/GP Data Management group, use case diagram UC3 View Citizen Data Description Actors Precondition Post Condition The user goes to the section in which he can view his personal data and those relating to possible exemptions User, System UC1, UC2 The user has been able to view/edit the desired information Normal Scenario 90

101 3.1 User Clicks on the Manage Citizen/Doctor Data button 3.2 System Displays the Manage Citizen/Doctor Data screen 3.3 User Clicks on the View Citizen Data button 3.4 System Shows the screen that contains the citizen s data 3.5 User Clicks on the OK button 3.6 System Shows the Main Screen of the APP Exception Frequency Priority Risk The user chooses to view the screen related to citizen s exemptions; The user realizes that some of the displayed information is incorrect Medium-Low Medium Low Table View Citizen Data Jacobson card UC4 View GP Data Description Actors Precondition Post Condition The user goes to the section in which he can view information related to his General Practitioner User, System UC1, UC2 The user has been able to view the desired information Normal Scenario 4.1 User Clicks on the Manage Citizen/Doctor Data button 4.2 System Displays the Manage Citizen/Doctor Data screen 4.3 User Clicks on the View GP Data button 4.4 System Shows the screen that contains information regarding the GP and his medical office 4.5 User Clicks on the OK button 4.6 System Shows the Main Screen of the APP Exception Frequency The user is not assigned to a GP Medium-Low 91

102 Priority Risk Medium Low Table View GP Data Jacobson card UC5 Change GP Description Actors Precondition Post Condition The user goes to the section in which he can view information related to his General Practitioner User, System UC1, UC2, UC4, the user is adult The user has been able to view the desired information Normal Scenario 5.1 User Clicks on the Change GP button 5.2 System Displays a search form in which the user can fill in the fields 'GP Name' and 'GP Surname' or choose the district and browse the available GPs 5.3 User Fills out the form and clicks on the 'Search' button 5.4 System Presents the outcome of the search 5.5 User Selects the desired GP 5.6 System Shows a confirmation box 5.7 User Clicks on the Confirm button Exception Frequency Priority Risk The GP that the user was searching for does not appear among the proposed solutions; The user have already made the GP change within 30 days; The user does not intend to confirm the GP change Low Medium Medium Table Change GP Jacobson card 92

103 4.3.3 FSE Figure FSE group, use case diagram UC6 View Referrals Description Actors Precondition Post Condition The user accesses the FSE section, where he can view and download his healthcare documents User, System UC1, UC2, having done one or more examinations at healthcare facilities that publish referrals into the FSE The user has viewed and/or downloaded the healthcare document correctly Normal Scenario 6.1 User Clicks on the FSE button 93

104 6.2 System Displays a screen that contains the services provided within the FSE category 6.3 User Clicks on the View Healthcare Documents button 6.4 System Shows a chronologically ordered list of available referrals 6.5 User Selects one of the available referrals 6.6 System Shows a summary screen containing the operations that the user can perform on the selected document 6.7 User Clicks on the View Healthcare Document button 6.8 System Shows the selected healthcare document Exception Frequency Priority Risk The user does not want to see any documents; Issues in viewing/downloading the required report due to unavailability of the healthcare facilities repository within which the report resides; The report to which the user want to access is obscured; The user decides to make the report available to the GP, who in first place had blocked access Medium Medium - High Medium Table View Referrals Jacobson card UC7 View Prescriptions Description Actors Precondition Post Condition With this feature the user is able to view his specialist, pharmaceutical or hospitalization prescriptions that were recorded into the SISS User, System UC1, UC2, prescriptions recorded into the SISS The user has correctly viewed the desired prescription Normal Scenario 7.1 User Clicks on the FSE button 7.2 System Displays a screen that contains the services provided within the FSE category 94

105 7.3 User Clicks on the View Prescriptions button 7.4 System Shows a list of the available prescriptions 7.5 User Selects one of the available prescriptions 7.6 System Shows a screen containing the prescription details Exception Frequency Priority Risk The user does not want to see any prescription detail; Medium - Low Medium Medium Table View Prescriptions Jacobson card UC8 View Healthcare Contacts Description Actors Precondition Post Condition The user by accessing this section can view the list of the contacts with the healthcare facilities that were registered into the SISS User, System UC1, UC2, healthcare contacts recorded into the SISS The user has correctly viewed the desired healthcare contact information Normal Scenario 8.1 User Clicks on the FSE button 8.2 System Displays a screen that contains the services provided within the FSE category 8.3 User Clicks on the Healthcare Contacts button 8.4 System Shows a list of the available healthcare contacts 8.5 User Selects one of the available list items 8.6 System Shows a screen containing the healthcare contact details Exception Frequency Priority The user does not want to see any prescription detail; The details of the selected healthcare contact are unavailable Medium - Low Medium - High 95

106 Risk Low Table View Healthcare Contacts Jacobson card UC9 View Vaccination List Description Actors Precondition Post Condition The user with this feature is able to view the vaccinations carried out by himself User, System UC1, UC2 The user has correctly viewed the list of the vaccinations he had perform Normal Scenario 9.1 User Clicks on the FSE button 9.2 System Displays a screen that contains the services provided within the FSE category 9.3 User Clicks on the View Vaccination button 9.4 System Exception Frequency Priority Risk Shows a chronologically ordered list of vaccinations, stating: the pathology, the date of disbursement and a description of it The user is born before 1990 and therefore his vaccinations are not recorded into the SISS system Low Low Low Table View Vaccination List Jacobson card UC10 Notebook Description Actors The Notebook use case allows the user to view documents he has uploaded into the FSE User, System 96

107 Precondition Post Condition UC1, UC2 The user has correctly viewed the desired document Normal Scenario 10.1 User Clicks on the FSE button 10.2 System Displays a screen that contains the services provided within the FSE category 10.3 User Clicks on the Notebook button 10.4 System Shows a list of documents that the user has already upload into the FSE 10.5 User Clicks on the View Detail icon 10.6 System Shows a screen containing the details of the selected document and the corresponding scanned image Exception Frequency Priority Risk The user does not want to see any document detail; The document list is empty Medium Medium - Low Medium - Low Table Notebook Jacobson card UC11 Load Document Description Actors Precondition Post Condition The Load Document use case allows the citizen to upload into the FSE any useful information that can support the doctors who are treating him during their anamnestic assessment User, System UC1, UC2, UC10 The user has correctly uploaded the desired document into the FSE Normal Scenario 11.1 User Clicks on the Load Document icon 11.2 System Displays a screen that contains a form regarding the document s details 97

108 11.3 User Fills out the form 11.4 User The user clicks on the Browse button to inspect the file system in order to find the.pdf/.txt document to load 11.5 User Selects the desired document 11.6 System Displays a summary screen containing the information about the document that will be uploaded 11.7 User Clicks on the Confirm button 11.8 System Loads the document into the FSE Exception Frequency Priority Risk The user tries to upload a document with an unsupported extension; The user cancels the upload operation Medium Medium Medium Table Load Document Jacobson card UC12 Delete Document Description Actors Precondition Post Condition The Delete Document use case allows the citizen to delete a document the was previously loaded into the FSE User, System UC1, UC2, UC10, UC11 The user has correctly uploaded the desired document into the FSE Normal Scenario 12.1 User Clicks on the Delete Document icon 12.2 System Displays a confirmation box 12.3 User Clicks on the Delete Confirmation button 12.4 System Removes the selected document from the FSE Exception Frequency Priority The user cancels the delete operation Low Medium 98

109 Risk Medium - Low Table Delete Document Jacobson card Booking Management Figure Booking management group, use case diagram UC13 Book Description Actors Precondition Post Condition The user accessing the Booking Management area can make a reservation of a specialist examination. User, System UC1, UC2, a SISS prescription was issued, the user has the recipe RUR code The user has been able to make a reservation properly Normal Scenario 13.1 User Clicks on the Booking Management button 13.2 System Displays a screen that contains the services provided 99

110 within the Booking Management category 13.3 User Clicks on the Booking Request button 13.4 System Shows a search form in order to gather the prescription to book 13.5 User Fills out the search form 13.6 System Proposes the facilities that deliver the performance within the province chosen by the user 13.7 User Selects a facility from the list 13.8 System 13.9 User System Asks the user to enter the date from which he wish to make an appointment and the RUR code Enters the required information and clicks on the Confirm button Offers a range of dates and times in which the performance can be delivered User Selects the desired appointment System Displays a summary screen containing the information about the appointment User Clicks on the Confirm button System Logs the reservation Exception Frequency Priority Risk The user does not find the desired prescription; The user enters an incorrect RUR code; The user does not intend to conclude the booking process Medium Medium Medium - High Table Book Jacobson card UC14 View Booking Description Actors The View Booking use case allows the user to view the data regarding a booked appointment and/or redo the reservation User, System 100

111 Precondition Post Condition UC1, UC2, UC13 The user has correctly viewed the data relating to the appointment and/or re-made the reservation. Normal Scenario 14.1 User Clicks on the Booking Management button 14.2 System Displays a screen that contains the services provided within the Booking Management category 14.3 User Clicks on the View Booking button 14.4 System 14.5 User 14.6 System Exception Frequency Priority Risk Displays a screen containing the list of booked appointments The user clicks on the Details icon located next to each list item The system presents the details of the selected appointment The user wants to redo the reservation Medium - Low Medium Medium - High Table View Booking Jacobson card UC15 Cancel Booking Description Actors Precondition Post Condition The Cancel Booking use case allows the user to cancel a previously booked appointment User, System UC1, UC2, UC13, UC14 The user has correctly cancelled the desired appointment Normal Scenario 15.1 User Clicks on the Cancel Booking button within the booking details screen 15.2 System Displays a confirmation box 15.3 User The user clicks on the Confirm Cancellation button 101

112 15.4 System The system records the cancellation of the appointment Exception Frequency Priority Risk The user does not confirm the cancellation of the appointment Low Medium Medium - High Table Cancel Booking Jacobson card UC16 View Agendas Description Actors Precondition Post Condition The View Agendas use case allows the user to consult the performances (or agendas) provided by the healthcare facilities and the related average waiting time (AWT) User, System UC1, UC2 The user was able to find out both which healthcare facility provides the performance he needs and how much he will have to wait to get an appointment Normal Scenario 16.1 User Clicks on the Booking Management button 16.2 System Displays a screen that contains the services provided within the Booking Management category 16.3 User Clicks on the View Agendas button 16.4 System Displays the screen containing a search form 16.5 User Enters the performance typology 16.6 User Specifies the search mode by selecting the province or the healthcare facility name 16.7 User Clicks on the Search button 16.8 System Exception Displays the list of facilities that deliver the searched performance in the selected province and the related AWTs The resulting list of facilities is empty 102

113 Frequency Priority Risk Medium Medium - Low Low Table View Agendas Jacobson card Payment Figure Payment group, use case diagram UC17 Pay Ticket Description Actors Precondition Post Condition The user pays the ticket using a credit card or a prepaid card User, System UC1, UC2, the user must perform a health service that requires the payment of the ticket The user has paid the ticket Normal Scenario 17.1 User The user selects the payment method to use to complete the transaction: Credit Card, Prepaid or Paypal 17.2 System Displays a screen that contains a form to be filled with 103

114 all the details of the prepaid card (Visa, Mastercard, American Express) or a form for entering mail address and password Paypal 17.3 User Clicks on the Continue button 17.4 System 17.5 System Informs the user that the transaction was completed successfully Asks the user if he want to store card information for future payments 17.6 User Clicks on the OK button 17.7 System Adds the card information to the user's account Exception Frequency Priority Risk The card information is invalid Medium - Low Medium - Low High Table Pay Ticket Jacobson card 104

115 Chapter 5 5 Proof of Concept Starting from what has been said in the previous chapter on Concept, we have developed a working prototype of the SISS Mobile APP, also developing the architectural components required for its operation. This chapter is fully devoted to a description of how our application was implemented, beginning with the description of the system architecture and coming to the presentation of the results of the tests that were performed on it. 5.1 SISS-Mobile Architecture To define the architecture of the SISS-Mobile we looked at the SISS system. The latter, as we have seen, is based on the SOA principles, hence in order to facilitate their future integration, we build our To-Be Architecture as a web service, made by the following components, also shown in Figure 5.1: SISS: this component represents the services delivered by the CRS-SISS Platform, through the Portal of Social and Health Services to the Citizen, that our application would use. It will interact only with the SISS-Mobile APP because at the moment Lombardia Informatica could not grant us a direct

116 access to the SISS web services, so our only way to access those services is to interface with the WebAPP of the citizen s portal. WebAPP: it is a web application that should be integrated within the Portal of Social and Health Services to the Citizen, more precisely inside the citizen s personal area, to which the user will have access after being authenticated. The main objectives of this component are: (a) to manage the QR-Code lifecycle: from its generation to its disuse because of the need to generate a new one (e.g. for security reasons), and (b) to manage the devices associated to the citizen s account (it should be possible: display names, serials and flags of the bound devices; unbind a device; Deactivate/Activate a bound device). Server: this component represents the back-end of the system and it will expose all its modules functionalities through web services. This component is the one entitled to handle the logic behind the implementation of the authentication system and processes the data received by the mobile APP. Besides, through its Device MGNT module, it responsible for the procedure regarding the binding of user s devices. The server also maintains a database that stores the entire domain of user data that is going to simulate the SISS central repository. Mobile APP: this component represents the front-end of the system. Its purpose is to communicate first with the server in order to perform the authentication and login phases, and then with the SISS component in order to gather all the required information. This component also maintains a local database in which are stored the information regarding the citizens accounts. All these components will be described in detail during the next sections regarding the Implementation Phase. 106

117 Figure 5.1 SISS Mobile application architecture 107

118 5.2 SISS-Mobile Implementation In this section we ll describe how each component of the system architecture of Figure 5.1 was implemented and what was the motivation behind the choices we made during this development process Web application The WebAPP has been developed using the Apache Struts 2 framework [101][102] and we said before, its main objectives are to manage the QR-Code lifecycle and to manage the citizen s devices activation status. In order to carry out these tasks our WebAPP will also have to communicate with the database that contains all the citizens data, which is located in the SISS Central Domains (for more information see the section 3.1.5). However, since for the realization of this prototype will not have access to such databases, we created a local database that simulates the data contained in the SISS central domain repository by using the MySQL Workbench 6.0 [103]. This DB will be also accessed by the web services exposed by the server, but this will be discussed in the section dedicated to the server. Figure 5.2 shows the components that make up the application. Figure WebAPP components, abstract class diagram 108

119 Since Struts Framework uses the Model-View-Controller (MVC) architectural pattern [104], we decided to follow this concept by dividing our components according to it. In fact, within the it.unipv.siss.action package (Action Layer) are presents all the functions that the user can interact with, which in turn will interface with the classes contained within the package it.unipv.siss.business (Business Layer) that will implement the logic behind those actions, and in order to accomplish them, it will also interact with the it.unipv.siss.persistence (Persistence Layer) package, which represents the bridge between the WebAPP and the database. Both the action layer and the persistence layer can exploits some utility functions provided by the classes within the it.inipv.siss.utility (Utility Layer). Figure WebAPP, simplify class diagram The overall class diagram is presented in Figure 5.3, but for the sake of simplicity we omitted the relationships between classes inside different packages and we replaced them with an arrow that connects the two packages in which those classes are contained. Then we will focus on the individual classes that make up the diagram, 109

120 analyzing them one by one, giving a brief description and pointing out their main features Business Layer The Business Layer represents the core of the WebAPP because it is the component responsible for the implementation of the logic behind the services provided through the Action Layer, by which it is invoked, and it also represent the only component capable of interacting with the Persistence Layer, thus to interact with the Database. This layer is composed by the following classes: IUserProfileManager UserProfileManagerFactory DBUserProfileManager UserProfileDTO IUserProfileManager <<Interface>> IUserProfileManager + updateuserprofile(userprofiledto) : void + generateqrcode(string) : ByteArrayOutputStream + getuserprofile(int) : UserProfileDTO Table 5.1 IUserProfileManager class IUserProfileManager is the main object of the Business Layer since it is the interface that defines all the functions that the WebAPP must provide. It is made up by the following methods: 110

121 getuserprofile: this method, based on the integer provided as input, returns a UserProfileDTO, which is an object that represents the data relating to the citizen s account contained inside the database. generateqrcode: this method will create a QR-Code containing the string passed as input, in our case this string will be the Security Code. updateuserprofile: thanks to this method will be possible to update the citizen s account data inside the DB, so it would also be possible to save the generated Security Code DBUserProfileManager DBUserProfileManager - instance : DBUserProfileManager - DBUserProfileManager() + getinstance() : DBUserProfileManager + updateuserprofile(userprofiledto) : void + generateqrcode(string) : ByteArrayOutputStream + getuserprofile(int) : UserProfileDTO Table 5.2 DBUserProfileManager class DBUserProfileManager is the class that implements the previously defined interface. It follows the Singleton pattern and in order to complete the functions performed by its methods updateuserprofile and getuserprofile it relies to the userprofiledao class within the Persistence Layer, while for the generation of the QR-Code exploits an open source library called Zebra Crossing (ZXing) [72] UserProfileManagerFactory - instance : UserProfileManagerFactory - UserProfileManagerFactory() UserProfileManagerFactory 111

122 + getinstance() : UserProfileManagerFactory + getelement() : IUserProfileManager Table UserProfileManagerFactory class UserProfileManagerFactory is the class needed to generate a DBUserProfileManager object; it follows the Singleton and Factory patterns and implements only the methods needed to create and get the instance (this happens through the private constructor and the getinstance method) and the method that is capable to return a DBUserProfileManager object UserProfileDTO UserProfileDTO - id : int - fiscal_code : String - name : String - surname : String - qr_serial : String - qr_serial_status : String - attempt_number : int - security_code : String - security_code_mod : String - aes_key : String - dev_number : int - dev1_name : String - dev1_serial : String - dev1_status : String - dev1_login_att_num : int - dev2_name : String - dev2_serial : String - dev2_status : String - dev2_login_att_num : int 112

123 - dev3_name : String - dev3_serial : String - dev3_status : String - dev3_login_att_num : int + UserProfileDTO() + UserProfileDTO(int, String, String, String, String, String, int, String, String, String, int, String, String, String, int, String, String, String, int, String, String, String, int) + Setter + Getter Table 5.4 UserProfileDTO class UserProfileDTO is the class that maps the citizen s information contained within the database. It consists of a set of attribute, each of which corresponds to a column in the database, and their setters and getters. This class is instantiated every time it is necessary to make an access to the DB Action Layer The Action Layer is directly linked to the front-end of the WebAPP, as it implements all the functionality that can be used by end-users. All the classes within this layer it will be invoked based on the actions that the user will cast by browsing application website and that the Struts framework will intercept. This layer is composed by the following classes: GenerateQRCodeAction DisplayQRCodeAction UserDeviceListAction DeactiveDeviceAction ActiveDeviceAction ViewUserPageAction 113

124 GenerateQRCodeAction GenerateQRCodeAction - qr_out : ByteArrayOutputStream - encodedimage : String - id : int - userdto : UserProfileDTO - passwordtmp : String + execute() : String + getqr_out() : ByteArrayOutputStream + setqr_out(bytearrayoutputstream) : void + getencodedimage() : String + setencodedimage(string) : void + getid() : int + setid(int) : void + getuserdto() : UserProfileDTO + setuserdto(userprofiledto) : void + getpasswordtmp() : String + setpasswordtmp(string) : void Table 5.5 GenerateQRCodeAction class GenerateQRCodeAction is the class responsible for generating the QR-Code and show it to the citizen through the standard output (PC screen). When instantiated, this class will first invoke the UserProfileManagerFactory class to get the UserProfileDTO related to the user, then it will invoke the classes contained within the utility layer in order to generate the QR-Code Serial and a Temporary Password; then with these two data it will invoke the SecurityCodeManagent class to create the security code, which will be encoded according to the AES encryption algorithm thanks to the AESEncoder class. Finally the encrypted Security Code will be saved into the database by using the appropriate method within the DBUserProfileManager class, along with the key needed to decrypt it. 114

125 DisplayQRCodeAction DisplayQRCodeAction - encodedimage : String - id : int - userdto : UserProfileDTO - passwordtmp : String - qr_out : ByteArrayOutputStream + execute() : String + getqr_out() : ByteArrayOutputStream + setqr_out(bytearrayoutputstream) : void + getencodedimage() : String + setencodedimage(string) : void + getid() : int + setid(int) : void + getuserdto() : UserProfileDTO + setuserdto(userprofiledto) : void + getpasswordtmp() : String + setpasswordtmp(string) : void Table 5.6 DisplayQRCodeAction class DisplayQRCodeAction is the class that is responsible to show to the citizen the QR- Code generated by the GenerateQRCodeAction class; to do so this class will have to access the database to retrieve the Security Code through the class DBUserProfileManager and after that it will have to invoke the generateqrcode method in order to obtain the ByteArrayOutputStream, which makes up the QR- Code image, and show it on the screen. 115

126 UserDeviceListAction UserDeviceListAction - userdevices : List<UserDeviceDTO> - id : int + execute() : String + getuserdevices() : List<UserDeviceDTO> + setuserdevices(list<userdevicedto>) : void + getid() : int + setid(int) : void Table 5.7 UserDeviceListAction class This class allows the user to see a table with all the devices that he has already activated and bound to his account. Information with which the table is populated is gathered by invoking the DBUserProfileManager class. The Citizen if select a device from that table he has the opportunity to choose whether to deactivate or reactivate it, this action will be performed by invoking either the DeactivateDeviceAction or the ActivateDeviceAction classes DeactiveDeviceAction DeactiveDeviceAction - id : int - dev_name : String + execute() : String + getid() : int + setid(int) : void + getdev_name() : String + setdev_name(string) : void Table 5.8 DeactiveDeviceAction class 116

127 This class allows the user to deactivate a device from those associated with his account and displayed via the UserDeviceListAction. To disable a device the DeactiveDeviceAction class will have to retrieve the UserProfileDTO by calling the DBUserProfileManager class, to change the activation status flag of the device selected by the user, and finally to update the record inside the database thanks to the DBUserProfileManager class ActiveDeviceAction - id : int - dev_name : String + execute() : String + getid() : int + setid(int) : void + getdev_name() : String + setdev_name(string) : void ActiveDeviceAction Table 5.9 ActiveDeviceAction class The ActiveDeviceAction class works just like the previous one, except for the fact that it allows you to reactivate a device that was previously disabled ViewUserPageAction ViewUserPageAction - id : int - userdto : UserProfileDTO + execute() : String + getid() : int + setid(int) : void + getuserdto() : UserProfileDTO 117

128 + setuserdto(userprofiledto) : void Table 5.10 ViewUserPageAction class This class shows just the user page, from which the citizen can choose whether to generate the QR-Code, View it, or enable/disable a registered device Utility Layer The Utility Layer implements all the classes that perform functions to support the Business an Activity layers, among which we find: QRSerialGenerator PasswordTMPManagement SecurityCodeManagement AESEncoder QRSerialGenerator QRSerialGenerator - instance : QRSerialGenerator - randomserial : SecureRandom - QRSerialGenerator() + getinstance() : QRSerialGenerator + generateqrserial() : String Table 5.11 QRSerialGenerator class QRSerialGenerator follows the Singleton pattern and it is the class responsible for generating the QR-Code Serial. This happens by generating a random number through the use of the java.security.securerandom library, which ensures us to obtain a unique serial code. 118

129 PasswordTMPManagement PasswordTMPManagement - instance : PasswordTMPManagement - PasswordTMPManagement() + getinstance() : PasswordTMPManagement + generatepasswordtmp(int) : String Table 5.12 PasswordTMPManagement class PasswordTMPManagement follows the Singleton pattern and it is the class responsible for generating the Temporary Password. This is done through the generatepasswordtmp method, which it will create a random password of N characters, where N is the integer value entered as input. Even this class exploits the method for the generation of a random number of the java.security.securerandom library SecurityCodeManagement SecurityCodeManagement - instance : SecurityCodeManagement - SecurityCodeManagement() + getinstance() : SecurityCodeManagement + encode(string, String, String) : String + decode(string, String) : List<String> Table 5.13 SecurityCodeManagement class The SecurityCodeManagement follows the Singleton pattern and it is the class responsible for generating the Security Code that will be contained inside the QR- Code. This is done thanks to the encode method, which it will combine the QR-Code Serial and the Temporary Password in order to form a single string, which will be encoded according to the AES algorithm based on the key passed as input to the 119

130 method. The decode method is used instead to decrypt the Security Code passed as input together with the key, in order to extract both the QR-Code Serial and the User Password. The AES encryption and decryption phases will be executed by invoking the AESEncoder AESEncoder - instance : AESEncoder - AESEncoder() + getinstance() : AESEncoder + encrypt(string, String) : String + decrypt(string, String) : String + generatekey() :String AESEncoder Table 5.14 AESEncoder class The AESEncoder follows the Singleton pattern and it is the class responsible for implementing the AES encryption algorithm by using the javax.crypto library. This class is composed by three methods: generatekey is the method by which an encryption/decryption key is generated; encrypt is the method that allows you to encrypt the string that you have passed as a parameter input together with the encryption key; decrypt is the method that that allows you to decrypt the string that you have passed as a parameter input together with the encryption key Persistence Layer The Persistence Layer implements the connection to the database containing user data, this connection was made by using the Hibernate framework [73]. Hibernate is an ORM (Object-Relational Mapping) that manages the data persistence on the database through the representation and maintenance of a relational database of a 120

131 system of Java objects. We choose Hibernate because of its ease of integration with Struts. This layer is made up by two classes: HibernateUtil UserProfileDAO HibernateUtil HibernateUtil - sessionfactory : SessionFactory - buildsessionfactory() : SessionFactory + getsessionfactory() : SessionFactory Table 5.15 HibernateUtil class This is a standard Hibernate class to establish the connection with the database. The connection is made thanks to the SessionFactory object, which can be built using the BuildSessionFactoryMethod and called by other classes through the getsessionfactory method UserProfileDAO UserProfileDAO - instance : UserProfileDAO - UserProfileDAO() + getinstance() : UserProfileDAO + getall() : List<UserProfileDTO> + read(int) : UserProfileDTO + update(userprofiledto) : void + write(userprofiledto) : void Table 5.16 UserProfileDAO class 121

132 UserProfileDAO is a Singleton class that establishes a connection to the database by calling the getsessionfactory method of the HibernateUtil class. This class provides a set of methods that allows you to perform CRUD operations on the database. getall: it returns a list of all the UserProfileDTO contained into the DB. read: it returns the UserProfileDTO identified by the integer number provided as input. update: it accepts a UserProfileDTO object as input and update the database voice that match with the identification number contained inside that object. write: it adds to the DB the UserProfileDTO object provided as input Back end The SISS-Mobile Server represents the back-end of the system, and it is the component within which has been implemented both the business logic for the operation of our authentication method based on the use of the QR-Code technology (for more details see section ), and for the citizen login phase. These components will be exploited by the smartphone application, which will communicate with the server using SOAP messages, as the latter exposes the services provided by web services, with the exception of the component used for the communication with the database, which will be called from the methods of the other components during their execution. This was done both to avoid the exposure to third parties of methods for accessing and modifying the citizens health data, and to promote further integration with the existing services for the access to the SISS central repository. The SISS-Mobile Server, in turn, is composed by four subcomponents, which are logically divided according to the functionalities they provide: QR-Code Validation: the purpose of this sub-component is to provide services that will allow the SISS-Mobile APP to determine whether the QR code scanned by the user is authentic and if the password entered by the latter, during the device activation phase, is correct. 122

133 Authentication Engine: it provides services that enable the mobile application to provide a login system in order to allow the citizen to have access to the CRS-SISS Platform services. Device Management: the purpose of this component is to provide services for the management of the devices lifecycle, in particular it enables the APP to activate a new device and/or to understand if a device is already bound to the citizen s account. DB Communication: it is used by the other components in order to get the access, both with reading and writing privileges, to the database where all the citizens data are stored. Inside the following sections we ll provide a detailed description of each subcomponent and their exposed methods, while the full WSDL file was attached as an Appendix QR-Code Validation Once again, this component provides services capable to determine: Whether the QR code scanned by the user is authentic and still active, through the ValidateQRCode method; Whether the citizen has entered the correct password during the device activation phase, through the AbilitationPasswordCheck method ValidateQRCode This method receives as input the Security Code read by scanning the QR-Code, and then it will search the database to see if there is a match with it. The DB access is done by invoking the getusertablebysecuritycode method within the DB Communication component. At this point, if the database search gave a positive result, which means that the received Security Code was authentic, the ValidateQRCode method will check the flag relating to the QR-Code activation state in order to see whether it is Blocked or not. Based on the result of this check the WS response will be a string with one of the following values: 123

134 Valid, the QR-Code is authentic and still active. Valid1Activation, the QR-Code is authentic, still active and this is the first time that the citizen activates a device. The latter information will be used by the AbilitationPasswordCheck method in order to establish which Security Code must be used for the comparison required during the device activation phase. Blocked, the QR-Code is authentic but is no longer valid. NotValid, the QR-Code is not authentic AbilitationPasswordCheck This is the method that has the responsibility to perform the password validation during the Activate Device process that we described in section (within the sub-phase 3). The AbilitationPasswordCheck method receives as input the Security Code and the password entered by the citizen, it calls the ValidateQRCode method to see if this is the first device activation performed by the user, because depending on that it has to change its behavior: The AbilitationPasswordCheck method will generate a Test Security Code from the Password received (which in this case is the temporary password provided to the citizen during his application for the access credential), the QR- Code Serial and the AES Security Key. The last two parameters are saved in the database. This phase changes based on the fact that the citizen is performing his first device activation or not, in fact: o If this is the first time that the user performs a device activation, the WS will compare the Test Security Code with the received one in order to see if they are equal. o Otherwise, the WS will compare the Test Security Code with the Security Code generated according to the password that the user chosen during the first device activation phase, which is stored within the DB. 124

135 This is why the AES Security Key is needed: since all the Security Codes are encrypted, in order to compare two of them we shall encrypt the Test Security Code with the same key used to encrypt the other. If the comparison will give a negative result, it will mean that the user did not enter the correct password, so the method will increment a counter on the number of failed attempts. At the fifth failed attempt the WS will set the flag regarding the QR-Code state of activation to "Blocked". Based on the result of the Security Code comparison, the Web Service response will be a string with one of the following values: PasswordOK, if the password entered by the user is correct. PasswordKO, if the password entered by the user is NOT correct. SerialBlocked, if the citizen has entered for the fifth time an invalid password Device Management This component provides services related to the devices management during the device activation procedure, through the following exposed methods: registerdevice, this allows the SISS-Mobile APP to bind a new device to the citizen s account. isdeviceregistered, to determine whether a device is already bound to the user s account RegisterDevice RegisterDevice is the method responsible for the insertion of a new device among those already associated with the citizen s account. This method requires three input parameters: UserID, this is the citizen identification number used to identify the database row regarding the citizen, on which it will be inserted the details of the device to bind. 125

136 DeviceSerial, it is the unique identifier that distinguishes one device to another. The DeviceSerial is gathered by the SISS-Mobile Application. DeviceName, it is the name chosen by the user in order to identify its device within the WebAPP. The RegisterDevice will invoke the DB Communication component in order to retrieve the information related to the citizen identified by the UserID parameter; once it obtained those information it will be able to verify if the user has already bound three devices (which is the maximum number of devices that a citizen can associates to his account), and if the user has already registered the device identified by the DeviceSerial parameter, this latter check is done by invoking the isdeviceregistered method. If none of these situations will occur, then the information regarding the device that the user is trying to register, (DeviceSerial and DeviceName) will be saved into the database by calling, once again, the DB Communication component. Based on the result of the previous operations, the Web Service response will be a string with one of the following values: DeviceRegistered, if the device registration process was successful. DeviceAlreadyRegistered, if the device that the citizen is trying to register has already been bound to his account. MaxDeviceNumReached, if the user has already registered three devices isdeviceregistered This method, based on the UserID and DeviceSerial passed as input, determines whether the given user has already registered the specific device, which is done by invoking the DB Communication component. The isdeviceregistered method will return: True, if the device is already bounded to the citizen s account. False, if the device is NOT bounded to the citizen s account. 126

137 Authentication Engine This is the component that deals with the implementation of the business logic related to authentication phase that we saw in section The Authentication Engine is composed by two web services: authenticateuser, it is the core method of the component, in fact it allows the SISS-Mobile APP to determine whether the login credentials provided by the citizens are correct or not. changepassword, this method allows the user to change the Temporary Password during the device activation phase AuthenticateUser This method requires three input parameters: UserID, this is the citizen identification number used to identify the database row regarding the user who is trying to perform the login phase. Password, it is the password that the citizen chose during the device activation phase. DeviceSerial, it is the unique identifier that distinguishes one device to another, and in this context it will be necessary to determine whether the device from which the user is trying to login is tied to his account and it is not been blocked. First of all the WS calls the DB Communication component in order to performs a search in the DB to find the citizen who corresponds to the received UserID. Then it checks if the DeviceSerial corresponds to one of the devices associated to the citizen s account and if it is still active. If all is fine, the authenticateuser method generates a Test Security Code from the Password received, the QR-Code Serial and the AES Security Key, like it happens with the AbilitationPasswordCheck method, and finally it compares the Test Security Code with the Security Code generated according to the password that the user chose during the device activation phase, which is stored within the DB. At this point if the comparison is successful, the citizen can be considered authenticated, otherwise the method will increment a 127

138 counter on the number of failed attempts and when this counter reach the fifth failed attempt, the method will set the device activation status flag to Blocked. Based on the result of the previous operations, the Web Service response will be a string with one of the following values: AuthenticationOK, if the authentication process was successful. PasswordKO, if the citizen entered a wrong password. SerialDeviceKO, if the device from which the citizen is trying to perform the login it has not been bound to his account. DeviceBlocked, if the device from which the user is trying to access has been blocked in the past, or if it has been blocked due to reaching of the threshold for the failed attempts granted ChangePassword This method simply allows the user to change the Temporary Password during the device activation phase. It requires two input parameters: UserID, this is the citizen identification number used to identify the database row regarding the user who is trying to change the Temporary Password. Password, it is the New Password that the citizen has chosen to replace the temporary one. The changepassword method relies on the DB Communication component in order to update the citizen s password inside the database DB Communication Component This component, unlike the others, does not expose its methods through web services, but it is invoked by them in order to access and edit the citizens records within the database. The DB Communication component consists of a single class that provides the access to our MySQL Database. 128

139 MySQLAccess - DB_DRIVER : String - DB_CONNECTION : String - DB_USER : String - DB_PASSWORD : String + getdbconnection() : Connection + getusertablebyid(int) : UserTable MySQLAccess + getusertablebysecuritycode(string) : UserTable + updateattemptnumber(int, int) : void + updateloginattemptnumber(int, int, int) : void + updateqrserialstatus(int, String) : void + updatesecuritycodemod(int, String) : void + updatedevicestatus(int, int, String) : void + adddevice(int, int, String, String, String) : void + updatedevicenumber(int, int) : void Table 5.17 MySQLAccess class The MySQLAccess class objective is to implement a connection with the database where are stored all the citizens data and perform some CRUD operations on it. This connection is realized by using the java.sql library, to which are dedicated the class attributes and the getdbconnection method. The UserTable object represents is the class that maps the citizen s information contained within the database. It consists of a set of attribute, each of which corresponds to a column in the database and it is equal to the UserProfileDTO class that we saw during the description of the implementation of the WebAPP Mobile application SISS-Mobile is the Android application that represents the front-end of our system. We chose to build our application on Android OS, which is an open source operating system for mobile devices that has been released under the open-source Apache Software License [74], because it was developed on the Linux kernel, which 129

140 provides the developer with the low-level access to the hardware control functions, such as it can allow you to take the control of the smartphone s camera in order to perform the QR-Code scan, besides all Android applications are developed in Java. The strengths of this OS are its flexibility and the high level of customization. In Android each process is performed thanks to an instance of the Dalvik Virtual Machine (DVM), i.e. a Java virtual machine optimized for mobile devices. Among the libraries that are natively provided there are also the SQLite library, which were used in the project in order to build a local DBMS for the storage of the citizen s account information. One of the design choices that we made was to run the business logic on the SISS- Mobile Server, as a result, our prototype will only provide a graphical interface through which the user can launch the necessary commands in order to complete the use cases. These commands will then be intercepted by our SISS-Mobile APP, which will take care of calling the needed web services in order to complete the operation requested by the citizen. With this idea in mind, we can think of breaking down the SISS-Mobile APP implementation in 3 layers: Presentation Layer Communication Layer Persistence Layer We ll begin by presenting the Persistence and Communication layers because they provide the services on which the Presentation Layer relies Persistence Layer This is the layer on which is build the local DBMS for the storage of the citizen s account information. This is done by the AccountsDBAdapter class, which through the use of the android.database.sqlite libraries was able to create an instance of a database in the smartphone local memory, and provide public methods that perform CRUD operations on that DB. 130

141 AccountsDBAdapter + KEY_ROWID : String + KEY_NAME : String + KEY_SURNAME : String + KEY_FISCALCODE : String + KEY_ACCOUNT_ID : String - DATABASE_CREATE : String - DATABASE_NAME : String - DATABASE_TABLE : String - DATABASE_VERSION : int - mdbhelper : DatabaseHelper - mdb : SQLiteDatabase + AccountsDbAdapter(Context) + open() : AccountsDBAdapter + close() : void + createaccount(string, String, String, String) : long + deleteaccount(long) : boolean + fetchallaccounts() : Cursor + fetchaccount(long) : Cursor + fetchaccountbyaccountid(int) : Cursor + updateaccount(long, String, String, String, String) : boolean Table 5.18 AccountsDBAdapter class The first five static attributes (ROWID, NAME, SURNAME, FISCALCODE, ACCOUNT_ID) represent the DB columns that contain the citizen s data plus the ACCOUNT_ID column that represent the user s identification number of the central database (this data will be passed by the WS during the last stages of the device activation process). mdbhelper and mdb are the objects necessary for the operation of the android.database.sqlite libraries that must be instantiated in order to create the DB and a connection with it (through the open() / close() methods), while the remaining are the methods that provide the CRUD operations Communication Layer This is the layer that implements the communication between the APP and the web services exposed by the SISS-Mobile Server. This is done by the CallWebService class, which through the use of the ksoap2 library, creates and sends the SOAP messages to target WS and than handles their response. 131

142 AccountsDBAdapter + NAMESPACE : String + URL : String + invokevalidateqrcodews(string) : String + invokeabilitationpasswordcheck(string, String) : List<String> + invokechangepassword(int, String) : void + invokeregisterdevice(int, String, String) : String + invokeisdeviceregistred(int, String) : boolean + invokeauthenticateuser(int, String, String) : List<String> Table 5.19 AccountsDBAdapter class The NAMESPACE and URL attributes are mandatory to identify the web service location, in fact the URL is the url on which the WSDL resides, while the NAMESPACE is the defined namespace within the WSDL Presentation Layer As we previously mentioned this is the layer that implements the graphical user interface (GUI) and that allows the citizen to move from one screen to another in order to achieve his goals. Since these goals are nothing more than the use cases implemented, we will describe this layer starting from an overall view of the transitions from one screen to another and then we will go into detail by showing how we have implemented each use case Navigation Diagram A navigation diagram is a chart that represents the relationships between each application screen and how the user can interact with them. Figure 5.4 shows the navigation diagram of the SISS-Mobile APP, an arrow from one screen A to another screen B implies that screen B should be directly reachable via some user interaction in screen A. As we can see, when the user starts the application, he will be found within the main screen, from which he can access both to the screens related to device activation process, or to the list of the citizens accounts for which the current device 132

143 has been previously bound. This screen can be also accessed after completing the device registration process. Once the user has selected the desired account, he will be moved inside the login screen, where he is prompted to enter the password in order to gain access to the protected area of the application, i.e. the one containing healthcare data. From the SISS-Mobile Main Menu the user can go in both screens for consulting his personal data or the information about his GP, or access to his FSE, in which he will find the links to two kind of list: Referrals list, where the user can select a referral in order to see it in a larger version. Healthcare contacts list, where the user can have a look of all his interactions with the healthcare system. With regard to backward navigation we decided to allow each screen child to be able to go back to its screen parent, besides from the main screens (FSE, Patient / GP Data and SISS-Mobile Main Menu) you can always go directly back to the Home screen. 133

144 Figure SISS Mobile APP navigation diagram 134

145 Implemented Use Cases In order to develop a working prototype of the SISS-Mobile APP and to prove that our solution is feasible, we have selected and implemented a subset of use cases that are necessary to perform the authentication procedure through the QRCode-based method we designed, and to access to some health document contained within the FSE, thus the implemented use cases are: UC1 UC2 UC3 UC4 UC5 UC8 Activate APP Login View Citizen Data View GP Data View Referrals View Healthcare Contacts Activate APP As we can see from Figure 5.5 to perform the activation procedure of the SISS- Mobile APP, and then to associate the device to the user account, you have to start from the Home screen. Inside the java code that implements this screen there are two "button-listeners", used to intercept user actions, so depending on the button that the user clicks the control will be passed to either to the screen where are listed the user's account, or to the register device screen. The former is composed by three vertical linear layouts and a listener for each button. In order to register the device the user will have to scan the QR-code, and this will happen when the button depicting a little QR-Code is pressed. This event will trigger the listener, which will activate the smartphone's camera and will capture the QR-Code content thanks to the use of the ZXing library. When the methods of the ZXing return the control to our class, it will invoke, through an asynchronous call, the ValidateQRCode web service, passing as input the content of the QR-Code, namely the Security Code. The response obtained from the web service will then be mapped into a case-switch, which depending on that response, it will start an AlertDialog, informing the user about the result of the scanning operation. If everything was ok, the user can now enter his password and click on the Confirm Button. At this point a validation system will check that the citizen has entered the password and that he has scanned the QR-Code, and if the answer is OK, it will call the AbilitationPasswordCheck web service passing as 135

146 inputs the Security Code and the Password just read. Even this time the response will be mapped into a case-switch, which in case of errors will invoke the appropriate AlertDialog, otherwise if the WS has confirmed that the user has entered a valid security code and the correct password, our class will invoke the web service isdeviceregistered to see if the device the user is trying to activate is already activated and bound to his account. The input that the WS expects to get is the device serial. However, we cannot simply provide the IMEI, MEID, or ESN of the phone (which are the most famous device identifiers) because the APP could run also in non-phone devices, which don t have those serial numbers. So according to [75] we thought to track the installation of the SISS-Mobile APP by generating a Universally Unique Identifier (UUID) the first time the APP runs after installation. Hence, the Register Device (a) class will gather this UUID from the DB within the smartphone application and will pass it as input to the WS. If everything was ok the control passes to the Register Device (b) screen. Here the citizen is able to change his temporary password and to provide a name for the device is going to register. Even in this case is present a validation system that checks if the user has compiled all the fields, and if the New Password, which must be entered two times, it s the same both times. After this validation, the web service RegisterDevice is invoked through an asynchronous call, and a new UserAccount is created within the local DB by calling the Persistence Layer. This account stores both user master data and his identification number in the central database. After that, the control is passed to the Accounts List screen, where the user can perform the login. 136

147 Figure SISS Mobile APP activation precedure 137