EPR exchange system

(1)

RIJKSUNIVERSITEIT GRONINGEN

EPR exchange system

Prototype development using design science

Master thesis, MSc Technology Operations Management University of Groningen, Faculty of Economics and Business

15-8-2013

JOHANNES HIJLKEMA, s1435159

j.hijlkema@student.rug.nl Supervisor/university dr. H. Balsters Co-assessor/university

dr. ir. D.J. van der Zee

(2)

Abstract

Government initiated specialization in healthcare results in patients receiving care at several locations. Their data needs to be visible at these locations as well. Current practice by exchanging data through regular mail or fax results in inconsistent, incomplete or outdated patient data and consequently in less than optimal treatments.

A design science approach is used to design an Electronic Patient Record Exchange system (EPRES) that facilitates digital exchange of patient data. Focal points in the design process were reliability, security and scalability.

An architectural design is suggested that uses a database federation with a uniform view to exchange patient data. This centralized solution with locally stored data satisfies the requirements by using database technology to exchange data.

Conceptual design for a user interface for the EPRES, fully based on BPMN and ORM models, provides a natural and intuitive way for users to validate that their requirements have been incorporated into the design. This proves to be an indirect validation for the models the design is based on; acting as a double validation method for both types of models.

(3)

Management summary

This master thesis is the result of the research performed at the hospital Nij Smellinghe Drachten (NSD). Quantity norms in healthcare cause hospitals to specialize in certain treatments. Due to this specialization patients no longer receive all types of care at their regional hospital and need to travel to specialized hospitals. The patient data, stored in various hospitals, needs to be available at these locations as well. To take advantage of ICT, an electronic patient record exchange system (EPRES) is needed.

In an iteratively manner, a team of three students carried out the design of this EPRES. Stephana (2013) translated the functional requirements into process models so the system suits the workflow of the hospital. Post (2013) takes these functional requirements and translated these into data models that incorporate the business rules in the form of data constraints.

My research, using the process models and data models as input, focused on the design of a prototype; the data structure and user interface of the EPRES. Based on this, the research question was formulated as follows: What database structure and user interface is needed to facilitate patient data exchange between two hospitals as such that data can be correctly and completely transferred?

To design an artifact that helps the stakeholders to change the world to a state as they want to perceive it, design science was used. Starting with the requirements of the users as the focal point, the design for the EPRES had to facilitate correct and secure data exchange as well as offering a scalable architecture. The best way of integrating the heterogeneous data sources found in hospitals proved to be a database federation that offers a uniform view on the data. This architecture met the demands for correct and secure exchange of information as well as offering great scalability.

The decentralized data sources in the database federation allow the hospitals to retain control on their data and to continue to use their own hospital information systems (HIS). The centralized uniform view provides read-only data access and requires only a single connection for each participating hospital in the EPRES. This, combined with the advantages of database technology - multi-user support, data integrity enforcement and support for additional data sources – warrants a scalable solution. When the number of hospitals (data sources) in the system increases, the complexity of the system does not and system performance is unaffected.

(4)

Access to the data residing in the uniform view is provided by means of a Web application. This application is solely used to view the data. Business logic is separated from the Web application and stored at the database server. This eliminates the need for entire queries to be communicated from the application to the database and makes the logic independent of the used application type.

A conceptual design for the user interface (UI), in the form of screen sequences, was made based on the process models by Stephana (2013) and data models by Post (2013). The Web application follows the (sequence of) activities in each process that requires EPRES functionality, ensuring a fit with the workflow. The content of each screen is based on the data models.

Validation of the BPMN and ORM models by domain experts is difficult because domain experts have no in-depth knowledge of the modelling techniques. The conceptual UI design that is based on the BPMN and ORM models proved to be an easy way to see if all requirements had been incorporated into the design. Validation of the conceptual UI design, fully based on the models, thereby gives an additional validation. This is a called a double validation and ensures all requirements are incorporated into the design.

(5)

8. Solution validation ... 39 8.1. Test methods ... 39 Functional demands ... 39 Technical demands ... 39 8.1.1. Functional tests... 39 8.1.2. Literature review ... 40 8.1.3. Other CSFs ... 41 8.2. Quality attributes ... 42 9. Implementation recommendations ... 45 9.1. Successful IS... 45 9.2. Successful implementation ... 46

9.2.1. What defines success? ... 46

9.2.2. Factors influencing implementation outcomes ... 47

9.2.3. Striving for synergy ... 48

9.3. Best practices from ChipSoft and Forcare ... 48

9.4. Lessons learned from the failed nationwide EHR ... 50

9.5. Final recommendations ... 51

9.5.1. Quality factors ... 51

9.5.2. System use factors ... 52

9.5.3. Synergy ... 53

10. Discussion ... 54

11. Conclusion ... 56

12. Glossary ... 57

13. References ... 59

Appendix A – Project descriptions ... 64

Appendix B – BPMN models ... 65

(8)

Appendix D – ORM relational view ... 78

Appendix E – SQL Server DDL ... 81

Appendix F – SQL Server database diagram ... 92

Appendix G - UI design and database operations ... 94

Appendix H – Stored procedures and functions (T-SQL) ... 104

Appendix I – Interview questions (Dutch) ... 115

(9)

1. Introduction

Cost reduction and quality improvements in healthcare mandated by the Dutch government causes hospitals to move from providing all types of healthcare services towards providing only select services in which they are able to meet the minimum required number of patients per time frame, i.e. specialization. As a consequence of this specialization, patients aren’t able to receive all types of healthcare operations in the closest regional hospital, but have to travel to specialized hospitals. To facilitate patients travelling to different hospitals to receive care, patient data has to be exchanged by means of a patient data exchange system.

Patient data is recorded in a Hospital Information System (HIS). These systems are very complex and deal with privacy sensitive medical data. The heterogeneity and diversity of HISs, combined with the variety of

stakeholders and activities, make it difficult to create a shared homogeneous computer system. Furthermore, the exchange of patient data is difficult in terms of; information exchange, standards used for the exchange, access modes and HIS security (El Azami, Cherkaoui Malki & Tahon, 2011).

The process of exchanging patient data has to deal with this complexity and more importantly, guarantee privacy. For patient data to be exchanged successfully, the transfer of data has to be properly authorized and the correct data should be transmitted without errors. Furthermore, the data exchange system should have a scalable architecture to allow other hospitals to join the network in the future. By overlooking these points, together with the focus on technological aspects instead of the requirements of the users, has caused the implementation of patient data exchange systems to fail (H. Balsters, personal communication, March 19, 2013).

This research focuses on patient data exchange for two regional hospitals, Nij Smellinghe Drachten (NSD) and Medisch Centrum Leeuwarden (MCL). Currently, patient data is exchanged through applications: data is exported and sent by e-mail, burned CD-ROM, fax or by regular mail. This results in inconsistency of patient data, fragmented patient data, patient data not viewed by the correct person or communication of incorrect patient data. In turn, this causes specialists to base decisions on incorrect or incomplete data which ultimately results in a patient not receiving the best treatment.

To eliminate these problems, these two hospitals want to exchange patient data in way that ensures the exchange of up to date patient data, in an easy, safe and reliable way. The solution should be created with the user

requirements as the main focus, use database technology for the exchange and needs to provide access to the most recent information, ensure the privacy of patient data, correct authorization of specialists and restrict access to data based on user privileges.

(10)

the construction of a design to solve a practical problem in an iterative way. Design science uses the following structure: problem investigation, solution design, solution validation, solution validation, implementation and implementation validation.

The objective of this research is to provide a technical design for a patient data exchange system between hospitals and does so with the requirements of the users as the main focus. This technical design will serve as a proof of concept to show that a patient data exchange system can be developed into a working prototype and that this part can be scaled-up to a complete system.

The total research project on the patient data exchange system is divided into three sub projects, with each project focusing on a specific part of the total project. Stephana (2013) will perform research on stakeholders, their goals and critical success factors and generates process models (Appendix B). Post (2013) takes these process models as input for his research and as a result will be delivering the data models (Appendices C and D). My research takes these process and data models and use these to design a prototype, the database structure and user interface, of the patient data exchange system (Appendices F and G).

The overall project is performed in an iterative way, parts of the process models that are complete, will be validated and passed on to be used to complete the data models for that part, these are then validated and in turn passed on to be processed into parts of the data structures and user interface. In this step-by-step fashion the whole system will be constructed. Specific project descriptions can be found in Appendix A.

The research question of this paper, in order to reach the aforementioned objective, is as follows: What database structure and user interface is needed to facilitate patient data exchange between two hospitals as such that data can be correctly and completely transferred?

(11)

2. Background

The goal of the Dutch government to increase quality and reduce costs entails that hospitals are only allowed to carry out procedures in which the amount of procedures performed yearly exceeds the quantity norm set by government (Inspectie voor de Gezondsheidszorg, 2010). This leads to specialization of hospitals and patients need to travel to hospitals in order to receive the needed care, as opposed to receiving all necessary care in their regional hospital previously. Since patient travel, their data has to travel with them as well. Therefore a patient data exchange system is needed.

This chapter explains the background of the problem of data exchange between hospitals. At first the situation regarding patient data exchange between NSD and MCL is explained. After that the concept and difficulty of interoperability in healthcare will be discussed. Next, standards development organizations and communication standards in healthcare are described. Problems with database integration are elaborated after that. Finally, legislation that is of influence on a patient data exchange system is covered.

2.1. Patient data exchange NSD and MCL

Currently patient data exchange between NSD and MCL is handled by exchanging an export of the data that is present in the HIS. This export is then exchanged by means of e-mail, or a CD-ROM/DVD posted with regular mail or handed to the ambulance transporting the patient.

This way of exchanging patient data causes problems due to inconsistent, incomplete or outdated patient data. Also patient data might not reach the correct specialist due to the current way of exchanging information. In turn, this causes the patient not to receive optimal care which might impair patient health, resulting in complications or even death. NSD and MCL would like to have a patient data exchange system in which patient data can be exchanged in an easy, safe and reliable way.

2.2. Interoperability in healthcare

To facilitate data exchange, sources of data have to be connected. Herein lies the difficulty of designing a patient data exchange system. Healthcare revolves around communication, most care processes involve exchanging information. Communication and the information flow involve many people in different departments across hospitals and diverse subject matter. Required for communication and information exchange is interoperability. A definition of interoperability by the IEEE: “The ability of two or more systems or components to exchange information and to use the information that has been exchanged”

(12)

 Semantic interoperability;  Process interoperability.

Technical interoperability focuses on the delivery of the data, not on its meaning. This type moves data from system A to system B over a distance. Semantic interoperability deals with understanding the information that is being transmitted; system A and system B understand the data in the same way. Semantic interoperability is at the core of what is usually meant with healthcare interoperability. Process interoperability deals with integrating computer systems in the actual work setting; it enables the business processes at the organizations that

incorporate system A and system B to work together. All these types are interdependent and are all needed to deliver significant business benefits.

To provide a good level of healthcare, the right information has to be available at the right time. This can be realized by using standards that enable computer systems to exchange information in a safe, secure and reliable way (Benson, 2009).

The next sections discuss solutions to the semantic interoperability problems. Technical interoperability is, due to the availability of the internet or other dedicated forms of communication, not an issue for this research. Process operability will be ensured by designing a user interface that is based on user requirements. Therefore only semantic interoperability will be relevant for this research.

2.3. Standards Development Organizations

Healthcare interoperability is based on the application of standards. ISO/IEC defines a standard as: "a document, established by consensus and approved by a recognized body, that provides, for common and

repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context" (ISO/SEC:2, 2005). A recognized body is an internationally

recognized standards development organization such as ISO, CEN, BSI, ANSI and accredited organizations such as Health Level Seven (HL7) (Benson, 2009).

2.3.1. Integrating the Healthcare Enterprise (IHE)

(13)

like DICOM and HL7 are to be used by ISs to complete a set of well-defined transactions that accomplish a particular task. At the same time, the framework provides a common human vocabulary that professionals and vendors can use to discuss further problems of this nature (Siegel et al., 2001).

2.3.2. Health Level Seven (HL7)

HL7 is a consortium that creates standards for the exchange, management and integration of electronic healthcare information for clinical and administrative purposes. The world's most widely used standards for healthcare interoperability are produced by HL7. In turn, most of the leading suppliers use and support the development of HL7 standards (Benson, 2009).

2.4. Communication standards in healthcare

Communication standards, or syntactical standards, ensure a correct transmission of data between different ISs. Examples are DICOM (Digital Imaging and Communications in Medicine) and HL7. These standards ensure semantic interoperability and because they are open, are widely accepted (Sunyaev, Leimeister, Schweiger & Krcmar, 2008).

2.4.1. HL7 Version 2 & 3

Several versions of HL7 haven been developed, the first formal version being HL7 Version 2. The core concept behind the HL7 Version 2 specifications is the notion that an external event, a trigger event, occurs and is recognized by a healthcare computer application. After recognizing the event, this application sends a specific message based on that trigger event through the network to one or more receiving applications. It is important to note that HL7 does not specify the communication protocol, only the trigger event and the message. HL7 Version 2 messages are delimited ASCII (American Standard Code for Information Exchange) strings divided into segments, with fields residing within these segments. Difficulties with version 2; the standard is not easily implemented and requires rigorous conformance testing, led to the development of HL7 Version 3 in 1997 (Beeler, 1998).

(14)

2.5. Heterogeneous database integration

Semantic interoperability comes down to integrating the heterogeneous data sources that are present. Several authors mention the problems that arise from heterogeneity in databases (Kamel & Zviran, 1991; El Azami et al., 2011; Viangteeravat, Anyanwu, Nagisetty, Kuscu, Sakauye & Wu, 2011). A barrier to heterogeneous database integration is the existence of diversity in the data. This amounts to differences in: names, relationships between data, aggregation levels of data storage and data types the information is stored in. An example of heterogeneity in databases can be seen below in Figure 1. This phenomenon leads to conflicts that can be classified as: Name conflicts, which typically involve homonyms (different facts denoted by the same name) and synonyms (different names used for the same fact).

Structural conflicts, which arise when the same facts are described differently in two databases. Scale conflicts, which involve the use of different units of measure.

Conflicts in application semantics, where in one database a relationship between two entities is characterized as one to one while it is characterized as one to many in another (Kamel et al., 1991). Conflicts like the ones stated above have been researched before and a solution is offered in the form of a database federation (Grimson, Grimson, & Hasselbring, 2000; Balsters & Halpin, 2007; Balsters & Haarsma, 2009).

2.6. Database federation

The term database federation refers to architecture in which middleware, consisting of a relational database management system (DBMS), provides uniform access to a number of heterogeneous data sources. The data sources are federated which means they are linked together into a unified system by the database management system (Haas, Lin & Roth, 2002).

Ideally, the data sources should be combined automatically and the resulting federation should provide the desired real-time overview, outlining the business data needs. The federation is said to be virtual as the federation constitutes a view on a collection of existing local databases.

The resulting federation does not involve altering these collaborating sources; the great advantage of not having to change these local sources is that existing applications on those systems can also be left unchanged (Balsters & Halpin, 2007).

2.7. Legislation

(15)

Figure 1 – Example of heterogeneity in databases

2.7.1. WBGO

The WBGO specifies the rights of the patient. The implications of these on the patient data exchange system are listed below.

 In order to provide the best care, patient data should be exchanged by means of ICT if it is possible, unless the patient explicitly made apparent that he/she doesn’t want this. The system should be able to incorporate this preference of the patient.

 The care provider should be able to include a statement given by the patient in the patient's record. The system should provide an option to include a patient’s statement.

 When the patient files a request for deletion of his/hers record, the data has to be deleted within 3 months. The system should be able to facilitate this.

 When requested, the care provider should provide as soon as possible insight in, and a hard copy of the patient record. The patient has to be able to look into his/her record.

 The last part concerns professional confidentiality. Patient data should only be viewed by the appropriate care provider, or in case of legality (for instance when patient has given permission) and necessity. Violation of these points should be traceable by means of an audit trail.

2.7.2. WBP

The WBP specifies how personal data should be protected. This has the following implications for the patient data exchange system:

 Data processing should be transparent, someone has to be aware of the fact that his/her data is being processed and for which purpose.

 Personal data should only be collected for explicitly defined and justified purposes. DATABASE 1

Patient ID First Name Last Name Blood Type

P0123 John Smith AB+

P1134 Kelly Doe A-

DATABASE 2

Patient number Name Patient Number Blood

14 John Smith 14 AB+

(16)

 There has to be a justified reason for the processing of personal data: permission by the patient, execution of an agreement in which the patient is involved or a legal obligation (e.g. WBGO).

 Quality of data: the data should be sufficient, to the point and not excessive in relation to the purpose for which the data is being processed. Data has to be accurate and in case of inconsistencies these should be repaired.

 Data has to be secured. Every possible technical and organizational measure should be taken to ensure the security of patient data.

2.7.3. Wbsn-z

(17)

3. Methodology

The difference between the way stakeholders currently exchange patient data and the way they would like to exchange patient data, constitutes a practical problem (Wieringa, 2007). This applies to the situation of patient data exchange between NSD and MCL. Stakeholders want a patient data exchange system that allows patient data to be exchanged in an easy, safe and reliable way.

This project focuses on designing a proof-of-concept of a patient data exchange system in which a scalable solution facilitates correct information transfer with proper authorization. To reach this goal a design science approach is used. The design science approach uses the regulative cycle (Figure 2) with a chain of phases to understand the problem, perform an analysis, design a solution, implement it and validate the solution to see if the initial problem has been solved (van Strien, 1997). Additionally, solutions can be validated without the need for implementation, marked by the arrow between Design Solution and Validation.

3.1. Overall project

The overall project will be executed by a team of three students that research different parts of the project. The total project follows the regulative cycle and each individual research project focuses on a specific element in this cycle. The execution of the overall project will be done in an iterative manner: when parts of the deliverables are finished and validated then they will be passed on to the next step. Piece by piece the solution will take form (Figure 3).

Step 1: Design Problem

Stephana (2013) will complete the Design Problem phase and delivers process models in the Business Process Model Notation (BPMN) format (Appendix B). These process models are the result of the identification of the requirements from the stakeholders and cover the part of correct information exchange.

Step 2: Diagnosis and Analysis

Post (2013) will carry out the Diagnosis and Analysis phase and the process models serve as input for his research. The end result of that phase will be data models and these will contain the authorization part of the solution (Appendices C and D).

Step 3: Design Solution

My research will execute the Design Solution phase of the total project and the main focus is to provide a

scalable solution. The data models serve as input for my research on the needed architecture and data structure of the EPRES. The process models developed by Stephana (2013), and data models by Post (2013) are used as input to design the user interface for the patient data exchange system.

(18)

Figure 2 - Regulative Cycle with design validation (Adapted from Van Strien, 1997)

Process models Data models Final solution

Design Problem Diagnosis & Analysis Design Solution

Figure 3 - Iterative execution of the overall project

Process step Executed by Input Deliverables Focus

Design Problem Stephana Stakeholder

requirements BPMN process models Correct information exchange Diagnosis & Analysis Post BPMN process models

Data models Authorized information exchange

Design Solution Hijlkema BPMN process

models and data

Data structure and user interface

Scalability of solution Design Problem Diagnosis & Analysis Design Solution

(19)

3.2. Subproject Design Solution

As mentioned before, for the total project the regulative cycle will be used in which this subproject executes the Design Solution phase. Figure 4 shows the steps that will be followed to complete this subproject. The required solution is based on the process and data models, but needs to be researched separately as well. To accomplish this, to identify this specific problem area, the stakeholders, their critical success factors (CSFs) and difficulties regarding the realization of these CSFs, a number of steps of the Regulative Cycle will be used as well: Design Problem, Diagnosis and Analysis, Design Solution and Validation phase. Just like in the Regulative Cycle, the steps in the sub project have an iterative character; the solution is created in a step by step fashion.

Step 1: Design Problem

During the Design Problem phase the problem will be investigated. This includes mapping the stakeholders, their goals and CSFs with respect to the data structure and user interface, authorization and scalability. Interviews with domain experts from companies ChipSoft and Forcare will be held to gain information from domain experts about patient data exchange systems, as well as problems that can be encountered during implementation of such systems and possible solutions to counter them. Recorded semi-structured interviews will be used. The recordings are transcribed and these transcriptions are then asked to be validated.

Step 2: Diagnosis and Analysis

The Diagnosis and Analysis phase consists of determining causes for the difficulties in resolving the CSFs of the stakeholders. These causes are then tested by means of quality attributes. These quality attributes are amongst other: accuracy (correct), security (authorization), scalability, performance (quick), cost (expensive) and specify to what extend the solutions has to meet these attributes. The CSFs are ranked according to priorities and the effect of (not) realizing these CSFs on stakeholders is analyzed.

Step 3: Design Solution

Possible solutions for the problem are determined in the Design Solution phase. Because the aim of this research is to deliver a proof of concept, art solutions need to be considered. The result of this phase is a state-of-art solution for the exchange of patient data between the regional hospitals in Drachten and Leeuwarden. The solution, data structures and user interface, will be developed in an iterative way, building it incrementally when pieces of the process and data models are finished.

Step 4: Validation

(20)

As a result of this research the validation of the user interface (UI) by the domain experts of NSD proved to be an extra validation for the BPMN process models of Stephana, 2013 and data models by Post (2013). This double validation, using a UI that is fully based on process models and data models, ensures that all the

requirements are modelled and incorporated into the final design. Therefore, this validation approach should be included in the methodology of this research.

Deliverables

Besides this rapport, the deliverables at the end of the project will be: 1. Prototype design

a. Design for the UI;

b. Conceptual data model for the patient data exchange system; c. List of operations of UI-requests to the database.

2. Recommendations for implementation

The structure of the remainder of this rapport is as follows. The Design problem phase is set out in chapter 4. This is followed by the diagnosis and analysis of the problem in chapter 5. Chapter 6 lists the available options and chapter 7 discusses the final design. The solution is validated in chapter 8. Recommendations on the implementation of the EPRES are given in chapter 9.

Design Problem (Chapter 4)

Diagnosis & Analysis (Chapter 5)

Design Solution (Chapters 6 & 7) Validation

(Chapter 8)

(21)

4. Design problem

4.1. Stakeholders

Stakeholders include those individuals, groups, and other organizations who are affected by the design problem and who have the ability to influence it (Savage, Nix, Whitehead & Blair, 1991).

In IS development, several stakeholders can be distinguished: users, indirect users, system professionals and managers (Venable, 2009). The stakeholders that can be classified as users and indirect users are discussed by Stephana (2013).

She describes the stakeholders that have functional demands for the patient data exchange system. These functional demands have been translated to a functional description of the business process by Stephana (2013) and to constraints on the database (to reflect the business rules) by Post (2013). My research focuses on the technical requirements of this system and the incorporation of these into the design.

This chapter will shortly summarize the stakeholders with functional demands. After the stakeholders with functional demands, the stakeholders with regard to the technical elements of a patient data exchange system – the system professionals – are being discussed.

4.2. Stakeholders, goals and CSFs with functional demands

As stated above, Stephana (2013) described stakeholders with functional demands that are incorporated in the EPRES design through her work and that of Post (2013). This section lists a summary of these stakeholders, goals and CSFs.

Stephana (2013) describes the following stakeholders: healthcare staff, hospital (IT) management, patients, health insurance agencies and governmental organizations. These stakeholders will be discussed below together with their goals and CSFs.

Healthcare staff

Healthcare staff are the main users of the EPRES system and include the hospital’s medical specialists (Stephana, 2013).

Goals of the healthcare staff are: reduction of mistakes in healthcare, easily transfer and retrieval of patient data, improved performance and easiness of the system (Dijkstra, 2012).

CSFs of healthcare staff (Stephana, 2013):  Fit with the current workflow;

(22)

 Ability to share files;

 Patient information is clear to all healthcare staff;  Information is complete and accurate.

Hospital (IT) management

Management is concerned with the quality of care, efficiency of work processes and total costs of their organization (Boonstra & Govers, 2009).

The main goals of hospital (IT) management are: reduction of costs in healthcare, improved service to patients and improved quality of care.

CSFs of Hospital (IT) management (Stephana, 2013):  System safety, i.e. meet WBP legislation;  Unauthorized access is prohibited;

 The system should distinguish between competences of users to get access to data, only authorized access based on the competences of the user is allowed;

 The system should be reliable and data storage should be reproducible;

 The system must have audit trails and should provide access to these audit trails;  The system must have a shared ownership of the central registry;

 The system should be flexible (i.e. scalable) in the number of attached healthcare providers. Patients

Patients are not part of the actual research but nonetheless are the most important stakeholder (Stephana, 2013). Patients need to approve the fact that their confidential personal information is stored inside this central

database.

The main goal of the patient is the maintenance of their privacy. Furthermore the patient would like to have improved service provided by the hospitals (Dijkstra, 2012).

CSFs of the patients (Stephana, 2013):

 Explicit consent is needed before patient data can be exchanged;  Unauthorized access is prohibited;

 The system does not provide access to health insurance agencies;

(23)

Health insurance agencies

Health insurance companies are one of the largest clients of hospitals in the Netherlands. They have an interest in the exchange of medical patient data because of their aim to reduce healthcare costs.

They want to exchange medical data in order to control and reduce cost for medical treatments (Stephana, 2013). CSF of the Health insurance agencies (Stephana, 2013):

 The system must be able to provide access and give insights into treatment programs of hospitals. Governmental organizations

Several governmental organizations are involved with the implementation of an EPRES. These are: board of protection of personal data (Dutch: College Bescherming Persoonsgegevens; CBP), Ministry of Health (Dutch: VWS), NICTIZ; the National IT Institute for Healthcare in the Netherlands and the Healthcare inspection agency (Dutch: Inspectie voor de Gezondheidszorg; IGZ) (Stephana, 2013).

CBP

This organization is responsible for the protection of personal data and privacy issues and has a coordinating and executional role to protect privacy according to the Dutch legislation (CBP, 2013).

IGZ

The Ministry of Health tasked a subdivision for supervising the healthcare industry; IGZ. IGZ regulates the quality of healthcare of all healthcare providers. Quantity norms (Dutch: volumenormen) are specified to increase the quality of high complexity care. Hospitals failing to meet these norms risk having their license revoked (Stephana, 2013).

NICTIZ

NICTIZ, the National IT Institute for Healthcare in the Netherlands, is the coordination point and information centre for IT and innovation in the healthcare sector in the Netherlands (NICTIZ, 2013). This organization developed the architecture for the nationwide EPD called AORTA.

Overall goals

The goal of these governmental organizations combined is to protect the privacy of the patients, reduce the healthcare costs, reduce mistakes and ensure the EPRES meets legislation (Stephana, 2013).

Overall CSFs

The CSFs of the governmental organizations are (Stephana, 2013):  Wbsn-z legislation compliance of the system;

 WBP legislation compliance of the system;

(24)

 WBGO compliance of the system.

4.3. Stakeholders with technical demands

This section discusses the stakeholders with technical demands. This part briefly describes each stakeholder, the goals are discussed after that and the final section specifies the CSFs per stakeholder.

Management of ISs

This stakeholder is responsible for the management of the patient data exchange system and constitutes a system professional. Since an IS offers functionality from software and databases, and from hardware with

accompanying basic software and means of communication, three roles can be distinguished within this discipline (Looijen, 2000): application management, functional management and technical management. These three roles will be discussed separately below.

Functional application management

Functional application management is responsible for maintaining the functionality of the system. This is the focal point considering the use of the system. Functional management supports the use of the functionality of the system, evaluates system usage and reacts to bugs and requests for new functionality that may lead to changes in the system (Looijen, 2000).

Application management

Application management is responsible for maintaining the application software and databases. Application software means all the software of the system except basic software (e.g. operating system), DBMSs and programming tools. When changes have to be implemented in the application software because of maintenance, application management is responsible for the implementation of these changes as well as testing them. This also applies to the databases with regard to data modelling and database structures (Looijen, 2000).

Technical application management

Technical application management is responsible for maintaining the operation of the IS consisting of hardware, software and databases, which should be available non-stop. From this perspective technical management aims at all technical aspects of the operations of the system. It monitors the service levels, reacts to anomalies and executes changes resulting from wishes from users and technological developments. Necessary changes in this regard should always have led from system usage (Looijen, 2000).

ICT developers

(25)

4.4. Goals

This section describes the goals the stakeholders want to achieve with regard to the technical elements of patient data exchange system.

Functional management: The goal of functional management is to support the use of the system as best as possible. This means that the system provides the functionality that the users in the organization need and that the users are trained in the use of the system.

Application management: Application management makes sure that the technical elements of the system, the software and the databases, keep supporting the functionality of the system to the users. This means implement changes to the system in case of needed maintenance and testing.

Technical management: Technical management wants to keep the system operational, this means that the hard- and software are kept in working order to make sure that the system is able to function and be available to the users.

ICT developers: After the design of the patient data exchange system, ICT developers build and implement the system.

4.5. CSFs

The CSFs of the stakeholders that have to be fulfilled in order for the system to be successful, are mentioned in this section.

Functional management

 The system is user friendly;

 Users can be easily trained in using the system;  The system is flexible.

Application management

 Changes to the system can be easily implemented;  System workings are transparent and well documented;  The system is scalable;

 The system is flexible;

 The system has a low response time. Technical management

 System is reliable;

 Problems can be solved within reasonable amount of time;

(26)

ICT developers

 The system meets the requirements;

 System is realized within the specified time frame and budget.

Table 2 summarizes the goals and CSFs per stakeholder mentioned above and is divided into functional and technical requirements.

Stakeholder Goals CSFs

FUNCTIONAL REQUIREMENTS (source: Stephana, 2013) Healthcare staff - Reduction of mistakes

- Easy transfer/retrieval of patient data

- Improved performance - Easiness of the system

- Fit with the current workflow

- An easy to understand and use system - Ability to share files

- Patient information is clear to all staff - Information is complete and accurate Hospital (IT)

management

- Reduction of costs

- Improved service to patients - Improved quality of care

- System safety

- No unauthorized access

- Distinguish between user competences - The system should be reliable

- Audit trails have to be present and accessible

- Shared ownership of the central registry - The system should be flexible

Patients - Maintain privacy - Improved service from

hospitals

- Explicit consent for data exchange - Unauthorized access is prohibited - No access to health insurance agencies - Access to their own data

- The system must be safe Health insurance

agencies

- Exchange medical data to control and reduce cost

- Access to the system and provide treatment programs insights

Governmental organizations

- Protect privacy of patients - Reduce healthcare costs - Reduce mistakes - Ensure compliance to

legislation

- Wbsn-z compliance of the system - WBP compliance of the system - WBGO compliance for participating

hospitals

(27)

TECHNICAL REQUIREMENTS Functional management - Maintain functionality of system - User friendly - Easy training - Flexibility Application management

- Maintain software and database

- Maintainability - Transparent workings - Scalability

- Flexibility

- Low response time Technical

management

- Maintain operation of system - Reliability

- Problems can be solved within reasonable amount of time

- Scalability

- Low response time

- Compatibility with current infrastructure ICT developers - Build system - System meets requirements

- System realized within time frame and budget

(28)

5. Problem diagnosis & analysis

This section describes the causes of the difficulties in resolving the CSFs of the stakeholders with regard to the technical demands. First, the causes are described, after that the criteria applied to these causes are discussed and finally the CSFs are ranked to see in which order these CSFs have to be treated to achieve a properly working solution.

5.1. Causes

Beside the technical demands, the causes of difficulty of resolving functional demands as described by Stephana (2013) will be summarized. First these will be listed, followed by the technical demands that are analyzed in detail.

5.1.1. Causes functional demands

The causes of difficulty in realizing functional demands are (Stephana, 2013):  compliance to Dutch legislation (WBGO, WBP and Wbsn-z);

 adherences of security standards to ensure patient data security (NEN 7510);  permission of patients is needed for the exchange of their data;

 patients should have access to their own data;

 access that bypasses authorization checks and patient permission should be offered in case of an emergency;

 complexity of IS implementation. 5.1.2. Causes technical demands User friendliness

People have to work with the system; the system should therefore fit their needs and workflow of the

organization. User requirements are not always incorporated in an IS and the users have to change their way of work to fit the characteristics of the system.

Maintainability

The components of the IS need to allow easy maintenance since future updates will be required. The way the system is constructed and documented will be of influence on the maintainability of the system.

(29)

administrative tasks like user administration has to be carried out when the system is developed? This leads to decisions whether some or all disciplines of application management will be organized in a centralized or decentralized fashion or if application management is outsourced to a third party. Depending on the expertise and departments present in the hospitals this can take many forms.

Complexity

Complexity of business processes and corresponding complexity of information and communication technology has increased over time (Looijen, 2000). This complexity makes the development and management of ISs ever more complicated.

Scalability

From a technical point of view, the biggest problem in interoperability between hospitals is the heterogeneity of data sources (Hammer & McLeod, 1993). The scalability of the solution depends on the ability of the system to handle additional connections to other hospitals. The system therefore has to be able to smooth data from multiple locations – current, as well as future locations – and present the data in a uniform way without duplicates or inconsistencies. A solution that works for a small number of locations might not be suitable for a higher number (e.g. increase complexity of necessary connections or performance degradation of the whole system).

Flexibility

The system should be flexible to accommodate future developments in healthcare and technology. If the system is seen as being out-of-date and a poor match against current care practices, it will not be used (UK Institute of Health Informatics, 2001).

Response time

The system should respond quickly following user interaction. Requested information should be made visible quick without delays. Complexity of the system and the number of connections to other hospitals can be of influence on the response time. Response time is highly dependent on the CSFs scalability and complexity. Reliability

Reliability is the degree in which the usage can depend on the IS with regards to correctness, completeness, timeliness and authorization of data processing and information supply. The reliability of all the components should at a level that together a reliable functioning overall IS is achieved (Looijen, 2000). An IS can be made up of many different components (e.g. used brand, technology, version) which means that reliability depends on many individual factors as well as the interaction between these components.

Compatibility

(30)

hardware and software. The solution has to be able to interconnect with the different types of infrastructure present.

Building the system

After the system has been designed the system will be developed by a specialized ICT company. This is only one part of the systems development life cycle (SDLC). SDLC comprises of a sequence of stages: analysis, design, development, and implementation (Davis & Olson, 1985). Normally, the total cycle will be carried out by the ICT development organization. For this project the first two steps (analysis and design) will be carried out by means of research projects by students. The last two steps, development and implementation of the system, will be carried out by the ICT company. ICT developers might be reluctant to build a system that is not designed in-house.

5.2. Criteria applied to causes of CSFs

This section discusses the criteria that apply to the solution. These criteria specify to what extend the solution has to meet certain quality attributes. First the demands for an EPRES are briefly set-out to frame the problem and the criteria that need to apply to the solution for the problem.

The required specialization in healthcare in order to reduce cost and improve quality cause patients to be referred to different hospitals, depending on the treatment that is required. Patients will have to travel to receive care and their patient records need to travel with them as well. The overall requirements of the EPRES are that that the system should be reliable, secure and scalable. In addition to these, easiness of use, performance, and cost of the solution will be discussed.

The solution has to be reliable. This means that the system should supply the correct information, at the right place and at the right time. To facilitate this means that the architecture should be reliable: little or no disruption in the service are allowed. Patient data should be retrievable at any moment, this holds especially in case of an emergency.

Since patient data is strictly personal, only those specialists that have a treatment relationship with the patient are allowed to view the data. Furthermore, since patient data from multiple hospitals is available at one single point of retrieval, very good security measures have to be used.

(31)

the Netherlands are considering cooperating with NSD and MCL (Balsters, personal communication, May 28, 2013).

The performance of the system should be such that information is quickly retrieved and made visible to the user that is requesting this information. When information retrieval takes a long time, it interferes with the process of providing care and result in users that get frustrated and avoid the system in the future.

The system has to be easy to use. Hospital staff should be able to work with the system without much needed training. The UI should be visibly pleasing and support the activities of the hospital staff.

Cost of the system should be in line with the benefits that the system delivers. Due to better informed specialists and the lesser amount of time that is spent on information exchange, operational costs are reduced. The cost of the system should be proportional compared to the expected benefits.

5.3. CSFs ranking

To achieve a properly working solution, a certain order dependency of CSFs is present. For instance, without a properly working technical infrastructure the functional aspects of the system can’t function. Below the order dependencies of the CSFs are listed. On top of the list are the CSFs that have the most priority in being realized, the lowest priority CSFs being at the bottom of the list.

1. Reliability 2. Scalability 3. User friendliness 4. Response time 5. Flexibility

6. Compatibility with current infrastructure 7. Building the system

8. Maintainability 9. System complexity

(32)

6. Design solution

This chapter examines the options that are available to design a patient data exchange system. These options are the components from which the final solution can be assembled. An application consists of several components that form the overall architecture of the system: data sources, a database and a user interface.

6.1. Database characteristics

Databases use a DBMS that facilitates the processes of defining, constructing, manipulating, and sharing databases among various users and applications (Elmasri & Navathe, 2010: 5). The characteristics of database systems are:

 Self-describing nature of a database system; the database system stores not only the database itself but also a definition of the database structure and data constraints (DBMS catalog).

 Insulation between programs and data, and data abstraction; because a database system uses a catalog, changes to the data structure means that in most cases applications that access the data can remain the same. Data abstraction allows for this independence, a DBMS provides a conceptual representation of data that does not include many of the details of how the data is stored or how the operations are implemented.

 Support of multiple views of the data; a database typically has many users, each of whom may require a different perspective or view of the database. A view may be a subset of the database or it may contain virtual data that is derived from the database files but is not explicitly stored.

 Sharing of data and multi-user transaction processing; the database system provides a set of functions to ensure that data is updated in a controlled manner in the case of several users wanting the update the data. Access to the database is handled by means of transactions. Transactions are executed in isolation from other transactions and either all the database operations in a transaction are executed or none are (Elmasri et al., 2010).

6.2. Architecture

(33)

Each type of architecture determines the number of connection required to communicate with other hospitals. The single central repository and centralized index systems require only one connection for each hospital that is connected. For the decentralized data storage, a point to point connection is needed with every hospital that is present in the network. The formulas below express this mathematically. The total number of connections in case of point to point connections, with participants, is expressed in formula (i):

(i)

In contrast, formula (ii) expresses the total number of connection required for a centralized architecture with participants:

(ii)

To summarize, the number of point to point connections needed for a decentralized architecture increase exponentially as the number of connected hospitals grows. For a centralized architecture, type (1) and (2) in Figure 5, the number of connections is equal to the number of hospitals, making the architecture much less complex.

6.3. Database federation

A database federation, as discussed in section 2.6, provides uniform access to a number of heterogeneous data sources. Current practice shows there are in essence three approaches to achieve federation: data warehousing, common architecture and message-based (Grimson et al., 2000: 51). These approaches and the types of architecture they rely on are discussed below.

Data warehousing

Data warehousing allows data from various systems to be integrated and homogenised in a data warehouse. The data warehouse is a new database structure that contains all the data that is present at the connected sources (Grimson et al., 2000). This approach has worked well in healthcare to integrate data in a single repository (architecture type 1). However, a drawback is that data in the systems needs to be moved from the source to the warehouse and data is duplicated in the warehouse (Grimson et al., 2000; Haas et al., 2002). This solution is

A B D C A B D C A B D C (1) (2) (3)

(34)

intended to support applications in which read-only access to the data is required (Grimson et al., 2000). When the warehouse becomes an operational system with read and write access, the typical problems of maintaining data consistency with the replicated data inside the hospital arise (Hasselbring, 1997).

Common architecture

Federated DBMS technology is used with the common architecture approach. Federated database systems depend on a common canonical model into which the underlying data models can be mapped in order to present a uniform view of the data at the federation layer (architecture type 2). This effectively means agreeing on common data model so that data in the connected sources has a predefined place in the overall model. The combined data of all connected hospitals is presented in a uniform view – data presented in a uniform format - allowing data retrieval with only a single query instead of multiple queries that are needed to retrieve data from multiple sources. It is recommended to base the common data model on approved healthcare standards (Grimson et al., 2000).

Message based

The message-based approach uses a set of standard messages that allow different HISs (architecture type 3) to exchange messages carrying data (e.g. using the HL7 standard). Exchanging information this way has worked well and has been effective. However, when the number of possible interactions between systems increases, then the limitations of scalability become apparent (Grimson et al., 2000).

6.4. User Interface

To interact with the database, an application program that interfaces to this data is needed. This application program provides a user interface (UI) at the front-end, and interfaces with a database at the back-end. Usually an application program includes a front-end component that deals with the user interface, a back-end component that communicates with a database and a middle layer which contains business logic; code that executes specific requests for information and enforcing rules.

(35)

6.5. Overview

This section gives an overview of the possible solutions that can be created with the technology discussed above. Each solution is rated based on the requirements for an EPRES; correctness of data, security and scalability and populated according to the characteristics found in literature. Table 3 shows an overview of the solutions discussed above.

The common architecture in the form of a federated database with a uniform view is the solution that scores best on the three requirements mentioned earlier. With scalability as the main focus of this research, the federated database and data warehouse are the options that satisfy this criterion best. A solution that relies on message based exchange might suffice for an initial number of hospitals. However, when additional hospitals want to join the network, problems with scalability and increased complexity become apparent. A weak point of the data warehouse involves data consistency; this violates the correctness of data criterion for the EPRES.

Furthermore, the federated database with uniform view allows for taking advantage of the features of a DBMS for data integration (Elmasri et al., 2010; Haas et al., 2002):

 a database engine that hides the physical location of the data and only needs to know what data is requested;

 protection of data integrity;

 availability of all the tools already developed: applications that have been developed for relational databases can be used without modification.

The design and properties of the final solution, based on the federated database with uniform view, will be elaborated in the next chapter.

server HTTP

data

web server and application server

database server network

(36)

Solution Correctness of data Security Scalability

Data warehouse - + +

Common architecture (federated database with a uniform view)

+ + +

Message based + + -

(37)

7. Final design

The solution builds on the design of a database federation for two locations, designed by Balsters (2012). Figure 7 shows the architecture for the proposed solution. This architecture shows the sources of data, the EPRES system as a federated database and the common data models that influence it. Furthermore it shows the user interface that presents the data to the user and the common process and data models that guide the UI screen sequence and screen content.

Data is divided into local data and virtual data. Local data denotes data that is stored in het local HIS of each hospital. Virtual data is the composite data of all data sources homogenised into a uniform view. When changes occur in the local data, the virtual data will be updated immediately to match these changes.

The arrows in Figure 7 indicate the relationships between the elements of the architecture. Dashed arrows with a white tip indicate an influence between components. Continuous arrows with a black tip indicate the origins of the data elements. All the parts of the architecture will be individually discussed in a top-down fashion according to the lay-out of Figure 7.

7.1. Common process model

The common process model represents the workflow of the processes that are required for the exchange of patient data. For each process (e.g. register patient) a BPMN model was created by Stephana (2013). BPMN defines a model which is based on a flowcharting technique tailored for creating graphical models of business process operations. A BPMN model is a network of graphical objects, which are activities (i.e., work) and the flow controls that define their order of performance (White, 2004: 1).

Figure 8 displays such a BPMN model and shows the process of viewing patient data in case of an emergency. The model shows the begin state, the sequence of activities, control points and the user or system that is

executing the activity. In Stephana (2013) additional information about the creation of these BPMN models can be found.

Furthermore, the processes of the Health insurance agencies and Healthcare inspection (IGZ) are also represented as BPMN models to show future possibilities of the EPRES. Since these process models and

(38)

NSD data MCL data common data model

NSD view MCL view

Federated data EPRES common process model

NSD view on EPRES MLC view on EPRES User interface User interface User interface vir tu al d at a lo ca l d at a

(39)

7.2. Common data model

The common data model specifies how the structure of the federated database and the individual views of NSD and MLC data are organized. The process models made by Stephana (2013) were used by Post (2013) to create the data model of the database by translating the process models to Object-Role Modeling (ORM) models. These models in turn, generate the data model of the database. This ensures that the data model fits the workflow and its data requirements. The creation of ORM models is discussed below.

7.2.1. ORM

It is well recognized that the quality of a database application depends critically on its design. To help ensure correctness, clarity, adaptability and productivity, information systems are best specified first at the conceptual level, using concepts and language that people can readily understand. Designing a database involves building a formal model of the application area or universe of discourse (UoD). To do this properly requires a good understanding of the UoD and a means of specifying this understanding in a clear, unambiguous way (Halpin, 2001: 1).

Database schemas don’t show semantics and suppress information. For instance, two identical tables with the columns person, person and date might incorporate different meanings of the data. Table 1 might contain data which stores ‘person married person on date’. While the other table, table 2, contains data that stores ‘person murdered person on date’. These semantics can’t be deducted by looking at the tables themselves. ORM models however, do provide this kind of information (Balsters, personal communication, .May 21, 2013).

Object-Role Modeling (ORM) simplifies the design process by using natural language, as well as intuitive diagrams which can be populated with examples, and by examining the information in terms of simple or elementary facts. By expressing the model in terms of natural concepts, like objects and roles, it provides a conceptual approach to modelling (Halpin, 2001: 1).

Figure 9 shows the global sequence of how to derive ORM models. By examining sample data and deriving facts from it (steps 1 and 2), ORM models (ORM schemas and relational model) can be created (steps 3 and 4). Explanation of the content of ORM models will be discussed hereafter.

(40)

Step 3: ORM schema

Step 4: ORM relational view

Patient Patient

PatientNr* 1025 PatientNr* 1056

Name* John Smith Name* Kelly Doe

Smokes Yes Smokes No

Allergies Penicillin Codeine

Allergies Step 1: sample data

Reference schemes: Patient(.nr); PatientName(); Drug(.name)

Fact types: Patient has PatientName

Patient smokes.

Patient is allergic to Drug [allergy]

Constraints on the data:

Each Patient has exactly one PatientName

(41)

Based on the ORM schema map a relational view can be automatically generated that incorporates these entities, facts and constraints. The work of Post (2013) provides further information on this type of conversion. The ORM schema models and relational view made by Post (2013) are visible in Appendices C and D respectively.

7.3. User interface

Based on the BPMN and ORM models, a conceptual design for the user interface (UI) was created. This design is represented as a screen sequence. The BPMN models that incorporate the EPRES component (represented as a swimlane) guide the sequence of the screens: the activities and flow controls in these models determine which functionality the UI should deliver to the user at each step in the process. The ORM models guide the content of these screens in terms of data that needs to be visualized or input by the user.

Furthermore, the processes of the Health insurance agencies and Healthcare inspection (IGZ) are also represented as BPMN models to show future possibilities of the EPRES. Since these process models and

corresponding screen designs lie beyond the scope of this research, they were not validated and are only included for illustrational purposes. For the viewing data of treatments by Healthcare inspection BPMN model (Figure B6 in Appendix B), a design is included to show a possible representation of the EPRES UI for this process.

7.3.1. UI design guidelines

The UI design follows the guidelines expressed by Galitz (2002). Three steps are used: 1. know your client;

2. understand the business function; 3. principles of good screen design.

Step 1 is achieved by using rapid prototyping in which the proposed design is shown to future users and their feedback incorporated into the next version. The next step, step 2, is achieved by using the BPMN and ORM models to guide the design process in terms of needed functionality and screen sequence. The final step will be used as overall guidelines during the design process. Guidelines that were used are amongst others: orderly and clean appearance, consistency, distinctive colour use, symmetry, grouping of similar information and the use of clear messages.

7.3.2. Overall layout

EPR exchange system