Validation of a Process-driven Database Design method for an Electronic Health Record-system:

Validation of a Process-driven

Database Design method for an

Electronic Health Record-system:

developing the process models

Master Thesis Technology and Operations Management

2

Validation of a Process-driven Database Design

method for an Electronic Health Record-system:

developing the process models

University of Groningen

Faculty Economics and Business

Master Thesis Technology and Operations Management

Groningen, January 2014

First Supervisor: dr. H. Balsters

Co-assessor: dr. ir. W.H.M. Alsem

Sjoerd Gerrit Hoekstra

Rhaladijk 14

9064DD Aldtsjerk

Student number: 2234165

3

Abstract

Practice reveals that there is no systematic link between a business process and associated business data in database design. A new general method is developed to systematically map basic business process models using Business Process Modelling Notation to create data models using Fact-Based Modelling called Process-driven Database Design. This method is validated by means of a project which is divided into three parts. This research is about the first part of the project: developing the process models. The second part of the multi-stage project is about the translation of process models to data models. The last part validates the data models at the end-users by using user-interface mock-ups and by comparing the data models and user-interface mock-ups with the so-called “Logisch Bedrijfs Gegevens Model”. This Logisch Bedrijfs Gegevens Model is a data model which is previously developed in the same context at the case company, a large teaching hospital in the Netherlands. By comparing the data models, the Logisch Bedrijfs Gegevens Model can also be validated.

4

Table of contents

Preface ... 6

1 Introduction ... 7

1.1 Introduction of the subject... 7

1.2 Research objective and questions ... 8

1.3 Academic relevance... 9

1.4 Structure of the thesis ... 9

2 Theoretical background ... 10

2.1 Requirements engineering ... 10

2.2 Business process modelling ... 11

2.3 Database design ... 14

2.3.1 Entity-Relationship modelling ... 15

2.3.2 Object-Oriented modelling ... 15

2.3.3 Fact-Based modelling ... 16

2.4 Process-driven Database Design ... 16

2.4.1 Developing the process models ... 16

2.4.2 From process models to data models ... 17

3 Methodology ... 19

3.1 Research type ... 19

3.2 Research framework ... 19

3.3 Overarching project overview ... 21

3.3.1 Developing the process models ... 21

3.3.2 From process models to data models ... 22

3.3.3 Validating the data models... 22

3.4 Research design ... 23

3.4.1 Step 1. Develop a general overview of the process ... 23

3.4.2 Step 2. Stakeholder analysis ... 23

3.4.3 Step 3. Develop the process models ... 23

3.4.4 Step 4. Validating the process models ... 24

3.4.5 Step 5. Adapt results and method ... 24

4 Results ... 25

4.1 Process overview ... 25

4.2 Stakeholder analyses ... 26

5

4.2.2 Analyses ... 27

4.2.3 Critical Success Factors and business requirements ... 30

4.3 Developing the process models ... 32

4.3.1 Developing the preliminary process models ... 32

4.3.2 Validating the preliminary process models ... 36

4.3.3 Feedback from user-interface mock-ups ... 39

5 Discussion ... 41

5.1 Process-driven Database Design ... 41

5.1.1 Development of the process models ... 41

5.1.2 Process-driven Database Design questions ... 42

5.2 Performed research ... 43

6 Conclusion ... 45

6.1 Research conclusions ... 45

6.2 Limitations of the research ... 45

6.3 Recommendations for further research ... 46

7 References ... 47

Appendix I: Theme poster on Patient Data Exchange Systems with Regional Hospitals ... 50

Appendix II: Theme case description ... 52

Appendix III: BPMN Appendix ... 54

Appendix IV: Feedback user-interface ... 73

Appendix V: Process models (BPMN diagrams) ... 74

I.First process model ... 74

II.Second process model ... 75

III.Third process model ... 76

IV.Provisional process model ... 77

6

Preface

This thesis is the final project of my study Technology and Operations Management at the University of Groningen.

The project was challenging, but since we had a good project group, consisting of students, lecturers and staff of the LTHN (large teaching hospital in the Netherlands), it became a great project. First I want to thank Roy Fischer and Erik Spits for their input during the discussions we had during the project, these discussions gave a lot of input for my part of the project. I also want to thank all persons of the LTHN for their input during the project.

7

1 Introduction

Traditionally, database research has focused on the essentially static view of a database as a collection of state descriptions. Furthermore, systems analysis and design methods for databases seem to suffer from a lack of knowledge about their application domain (Jarke & Shalev, 1984). New methods are developed to design databases on the basis of the business processes. This thesis is about such a new method called Process-driven Database Design.

1.1 Introduction of the subject

The primary measure of success of a software system is the degree to which it meets the purpose for which it was intended. There are a number of inherent difficulties in this process (Nuseibeh & Easterbrook, 2000). Nuseibeh and Easterbrook (2000) state that software engineering still lacks a mature science of software behaviour on which to draw, requirements engineers need such a science in order to understand how to develop the software. Insfran et al. (2002) developed a requirements engineering-based conceptual modelling approach to improve the software production process. Practice, however, often reveals that there is no systematic link between a business process and associated business data (Balsters, 2013a). Balsters (2013a) developed a general method to systematically map basic business process models, using Business Process Modelling Notation (BPMN), to create data models, using Fact-Based Modelling (FBM), which is called Process-driven Database Design. This method has recently been coined as Fact-Based Business Process Modelling (Balsters, 2013a). Wieringa and Heerkens (2006) state that validation is lacking for a lot of software engineering papers. To ensure this method is useful and correct this new method has to be validated, this validation is performed in this project.

The Process-driven Database Design method is already applied (Moes et al. 2012, Hijlkema 2013, Post 2013 & Stephana 2013), but it is not systematically validated in a comprehensive situation. In this paper the concept of the Process-driven Database Design method is investigated in literature; all three parts are discussed, the method is aimed at requirements engineering and employs business process modelling and database design. Then the method will be used in practice, if the result, a database system that satisfies the needs of the users, it can be concluded that the method is valid since an end-user exactly knows what data is needed. If necessary, the Process-driven Database Design method will be improved during this project to ensure validity.

8 of the database system, called the Logisch Bedrijfs Gegevens Model (LBGM). The LTHN has expressed the need to validate the correctness of the LBGM, since reliability, safety and privacy are so important in a hospital. Since there are no standard approved methods to validate the design of a database system, this study will investigate how the database system, designed using Process-driven Database Design, will differ from the current LBGM. With these results, the LTHN can validate the correctness of their LBGM.

Due to the limited resources, only the triage process of the EHR-system will be investigated. This is the process which takes place before a regular patient makes an appointment at the LTHN. This thesis is mainly about the first part of the method, developing the process models. The second and third part will be done by two fellow Ma-students of the RUG; their part will consist of a conceptual database design (performed by Fischer, 2014) and the validation using mock-ups of user-interfaces (performed by Spits, 2014).

1.2 Research objective and questions

The research objective of the overarching project is:

Validate a proposed general method of Process-driven Database Design in the context of designing a database supporting an EHR-system at the LTHN.

The research objective for this thesis is thereby only focussed on the development of the process models and the corresponding questions of the method. This leads to the following general research question:

How can process models be derived from business processes in the context of designing a database supporting an EHR-system at the LTHN?

To answer this general research question, several questions have to be answered. These sub-questions are listed below. The first two deal with the development of the business process models and the last one is aimed at the validation of the method.

- Who is currently exchanging data, what data is exchanged and how is the data exchanged? - What are the constraints/requirements on patient data exchange as a process?

9

1.3 Academic relevance

The academic relevance of the overarching project comes from a lack of a method to systematically design EHR-systems (Balsters, 2013c). When the overarching project is completed, the extent to which the method Process-driven Database Design is generally applicable in the context of an EHR-system is clear; more specifically, it is clear if it is applicable for EHR-EHR-systems in other hospitals. The academic relevance of this thesis is to internally validate the first stage of the method Process-driven Database Design; the part of deriving the process models from business processes in such a way that the required data for the data modeller becomes available.

1.4 Structure of the thesis

10

2 Theoretical background

As mentioned in the introduction, the Process-driven Database Design method has not been validated in practice. The method is aimed at requirements engineering, and employs a technique based on transforming user requirements as offered in a Business Process Model (BPM) to requirements pertaining to the data needs of each stakeholder with respect to that business process. These data needs, based on data-use processes, are captured in a so-called Fact-Based Data Model. The method is coined as Fact-Based Business Process Modelling (FB-BPM).

In this chapter the theoretical background of these three parts will be described. Section 2.1 gives a review about existing literature on the theory and practise of requirements engineering which is used in conjunction with the Process-driven Database Design method. Concepts in requirements engineering are, hence, supplemented with concepts taken from business process modelling and database design (cf. sections 2.2 and 2.3). The section on business process modelling is described more in depth, since that is the main part of this thesis. The last section, section 2.4, describes the Process-driven Database Design method; parts of section 2.1, 2.2 and 2.3 are used to show how the method is applied.

2.1 Requirements engineering

According to Van Lamsweerde (2000), requirements engineering (RE) can be described as follows; “RE is concerned with the identification of the goals to be achieved by the envisioned system”. These goals are operationalized into services and constraints. RE is also concerned with the assignment of responsibilities for the resulting requirements to agents such as humans, devices, and software. The approach introduces techniques to clearly specify functional requirements and a process to systematically decompose these high-level requirements into a more detailed specification that constitutes the conceptual schema of the desired system. Having such a precise link allows tracing of changes in the user requirements in the conceptual schema, and consequently, in the final software product (Insfran et al. 2002).

According to Selvakumar and Rajaram (2011) RE can be classified into Functional Requirements (FR) and Non Functional Requirements (NFR); FR deals with the requirements that affect the functionality of the system and NFR deals with the requirements that constrain the system.

11 maintainability (Selvakumar & Rajaram, 2011), i.e. quality attributes (Wieringa & Heerkens, 2007). Here can be seen that NFR describes the “How” question.

To capture the requirements of the stakeholders, a technique that can be used is described in the following section.

2.2 Business process modelling

A business process model describes tasks and the ordering of these tasks: what work is performed and when it is performed (Bridgeland & Zahavi, 2009). Nowadays, there exists a wide variety of process modelling notations. Some notations have been around for decades and other notations have been proposed more recently (Aalst, 2012). Jun et al. (2009) identified eight methods with distinct differences:

 Stakeholder diagrams  Information diagrams  Process content diagrams  Flowcharts

 Swim-lane activity diagrams  State transition diagrams  Communication diagrams  Data flow diagrams

The modelling methods represent very often semantically identical aspects of a system (Jun et al., 2009). At present, Business Process Model and Notation (BPMN) is the internationally accepted (ISO-)standard in the frame of business processes and workflow modelling languages (Chinosi & Trombetta, 2012 and Balsters 2013a). BPMN is developed to provide a graphical notation in order to represent a business process as a Business Process Diagram (BPD). It is understandable by business users, ranging from the business analysts who sketch the initial drafts of the processes to the technical developers responsible for actually implementing them, and finally to the business staff deploying and monitoring such processes (Chinosi & Trombetta, 2012).

A BPMN model exists of five main categories of elements to build diagrams (Object Management Group, 2011) which are described below.

Flow objects: are the main graphical elements to define the behaviour of a business process. There are three flow objects; Events, Activities and Gateways (Chinosi & Trombetta, 2012).

12 Connection objects: provide ways of connecting various objects to each other. There are four connecting objects; Sequence flows, Message flows, Associations and data associations (Object Management Group, 2011).

Swim-lanes: give the capability of grouping the primary modelling elements. Two ways can be distinguished; pools and lanes (Object Management Group, 2011).

Artefacts: are used to provide additional information about the process that does not affect the flow (Chinosi & Trombetta, 2012). The current set of artefacts includes group and text annotation (Object Management Group, 2011).

BPMN is rich on elements, which means that it is not the easiest language to work with. For that reason, and to stay an Object Management Group (OMG) standard, BPMN is constantly undergoing revisions and extensions to make it easier to use (Recker, 2008).

To keep the BMPN diagrams clear, only the basic elements of BPMN are used in this research. With basic elements is meant, only the conceptual and database driven elements. When the implementation-oriented elements are left out, only seven elements remain. These elements are explained below. The explanations per element are based on BPMN 2.0 (Object Management Group, 2011).

Pool

A pool is used to show a process, within a pool several participants can be used which can lead to subdivisions (see lane).

Lane

A lane is a subdivision within a pool. Lanes are used to organize participants within a process. Start/End event

The start event indicates where the process starts.

13 Activity

An activity, in this case a task, is used to show which work is done at that point in the process.

Sub-process

A sub-process is a compound activity that is included within a process. Within this sub-process there is a finer level of detail of that part of the process. Gateway

Gateways are used to show the divergence of sequence flows. Sequence flow

The sequence flow is used to show the order in which activities will be performed in a process.

In order to keep the BPMN diagrams better understandable for the end-users and to show Fischer (2014) and Spits (2014) how the data flows, the following elements are also used.

Data object

Activities can require or produce information, this information is shown by a data object.

Message flow

The flow of the information which is shown in a data object can be represented by a message flow.

14 For the development of the process models, a method called “Systems thinking” is used. Systems thinking can be used to describe processes, analyze processes and to structure processes whereby problems can be solved (In ‘t Veld, 2006). The goal of the method is to map the business processes using the steady-state model. In ‘t Veld (2006) defines the steady-state model as follows; It is a model of a system state, which is created when the behaviour of the system is repeatable in time, and if that behaviour is in the one time period similar to that in the other time period. In order to develop the model, the system approach is used. According to In ‘t Veld (2006), the system approach works as follows; a system (black-box) is opened and the interactions and functions of the different sub-processes are studied. This can be repeated until the required elements are found, in other words; each time a black-box is opened a lower aggregation level is reached.

The steady-state model can be divided into three phases; first the input is encoded in such a way that the input can be transformed, in the second phase the actual transformation is performed, and in the third phase the output is decoded in such a way that it can be used outside the system (In ‘t Veld, 2006).

The central theme of systems thinking is abstraction and generalization, this means that the system needs to be defined first before looking at the various components of the system (In ‘t Veld, 2006).

2.3 Database design

To design a database, a formal model of the application area or Universe of Discourse (UoD) should be built (Halpin, 1998). Haplin (1998) states that it requires a good understanding of the UoD and a means of specifying this understanding in a clear, unambiguous way. Halpin & Morgan (2008) identify in general three different modelling approaches: Entity-Relationship modelling, object-oriented modelling and fact-based modelling. These three approaches are shortly discussed below.

15 2.3.1 Entity-Relationship modelling

The ER model and its accompanying ER diagrams are widely used for database design and systems analysis (Song & Froehlich, 1994). The model pictures the world in terms of entities that have attributes and participate in relations (Halpin & Morgan, 2008). Relationships are depicted as named lines connecting entity types; only binary relationships are allowed, and each half of the relationship is shown either as a solid line or as an broken line (Halpin & Morgan, 2008). A fork or “crow’s foot” at one end of a relationship indicates that many instances of the entity type at that end may be associated with the same entity instance at the other end of the relationship (Halpin & Morgan, 2008).

ER diagrams are incomplete because the move from the data use case to the model is not obvious (Halpin & Morgan, 2008). Halpin (1998) clarifies this by stating that ER diagrams are further removed from natural language, cannot be populated with fact instances, require complex design choices about attributes, lack the expressibility and simplicity of a role-based notation for constraints, hide information about the semantic domains that glue the model together, and lack adequate support for formal transformations. Song & Froehlich (1994) state that errors are made by modelling indirect or redundant relationships and inappropriately modelling object types as relationships rather than entities.

2.3.2 Object-Oriented modelling

Object-oriented (OO) modelling is mainly used for designing object-oriented program code, but it can also be used for database design, this approach encapsulates both data and behaviour within objects (Halpin & Morgan, 2008). Unified Modelling Language (UML) is a standardized format for creating OO models (Rahimi & Haug, 2010). According to Rahimi and Haug (2010) UML is the de facto standard for OO modelling.

UML uses class diagrams to specify static data structures, these class diagrams may be used to specify operations as well as low level design decision specific OO code (Halpin & Morgan, 2008). According to Halpin & Morgan (2008) UML class diagrams resemble an extended version of ER. Entity instances are assumed to be identified by internal object identifiers; therefore UML does not require conceptual identification schemes for its classes (Halpin & Morgan, 2008).

16 more than one role in the association. This weakness carries over into its verbalization of constraints and derivation rules.

2.3.3 Fact-Based modelling

The most popular Fact-Based (/Fact-Oriented) modelling approach to data modelling is Object-Role Modelling (ORM) (Halpin, 1999). The problems of UML can be remedied by using the Fact-Based approach where communication takes place in simple sentences, each sentence type can easily be populated with multiple instances, and attributes are eschewed in the base model (Halpin, 1999). A domain expert should always be able to verbalize the information content in natural language sentences, the modeller transforms that informal verbalization into a formal yet natural verbalization that is clearly understood by the domain expert (Halpin & Morgan, 2008).

In contrast to ER, ORM makes no use of attributes; all facts are represented in terms of entities or values playing roles. This attribute free approach has advantages for conceptual analysis, including simplicity, stability, and ease of validation (Halpin & Morgan, 2008). Should it be necessary or convenient, ORM also offers procedures for mapping to attribute-based structures, such as those of ER and UML (Doesburg & Balsters, 2012).

According to Halpin & Morgan (2008) ORM is significantly richer than ER and UML in its capacity to express business constraints on the data, as well as being far more orthogonal and less impacted by change. Besides this they also state that ER and UML often fail to express constraints on, or between, attributes in contrast to ORM.

2.4 Process-driven Database Design

As mentioned earlier, the method is aimed at requirements engineering, and employs process modelling and database design. Hence, in this section it will be explained how the Process-driven Database Design method is developed using these theory’s described in section 2.1, 2.2 and 2.3. The starting point is from the process of the user of the database, from that perspective (the business processes) the database will be developed; the aim of this method is to get data in sync with the processes (Balsters, 2013a).

The method consists of two parts, the first part is developing the process models and answering the fact-type identification questions and the second part is to design the actual database using the information from the first part.

2.4.1 Developing the process models

17 1. Which entities are involved in the event as participants?

2. At what instant (timestamp) does the event happen? 3. How do we identify the event?

4. What do we have as input for the event? 5. What do we have as output for the event?

To get an answer on these specific questions, the support of a domain expert is needed (Balsters, 2013a). The questions are used to develop the process models, data-use processes (DUP), and the database design for each end-user separately. The objective is to derive a complete and minimal data model that fits each DUP (Balsters, 2013a).

By using the framework of starting from a BPMN model, and posing such event-identifying questions, a data model supporting the business process can be created. The business process is seen as the context in which the business data is offered its place (Balsters, 2013a).

To ensure the input quality of the second part of the method, the process models are build using BPMN process modelling. End-users can read the process models because they can simply follow the connectors, with this quality check the process models are validated so the input of the second part is guaranteed.

2.4.2 From process models to data models

For the design of the database, Fact-Based modelling is used. Main reason for this is that facts and rules may be verbalized in a language easily understandable by non-technical domain experts, besides that, fact-based models are attribute-free, treating all facts as relationships (Balsters, 2013a). The rules are written in ORM-Logic driven English (OLE). The ORM models are derived from the BPMN/DUP-models (Balsters, 2013a).

The BPMN-ORM procedure is performed as follows (Balsters, 2013a):

1.

Create a BPMN-task and specify the associated ORM event

2.

Find the minimal model that realizes the desired ORM event using our fact-type identification method

3.

Create the next BPMN-task

4.

Transform that task into a subsequent ORM event

5.

Find the minimal extension to the previous ORM model fragment that defines that subsequent ORM event

18

7.

At the end a complete corporate database has been created, associated to the original business process

An example of an ORM event is shown below in figure 2.1. The complete corporate database can be transformed to a relational database using NORMA (Balsters 2013a).

19

3 Methodology

In this chapter the methodology is described. First the type of research is stated, and second, the research framework is discussed. The third section gives an overview of the overarching project, and in the fourth part, the methodology of this research is described.

3.1 Research type

The goal of the research is to create utility instead of finding the truth which means it is about Design Research (/Science). According to Balsters (2013b), design research aims at solving practical-knowledge problems, this is a difference between the way stakeholders experience the world and the way they would like to experience it (Wieringa, 2007). Van Strien (1997) developed the regulative cycle of practical problem solving to fill the gap between theory and practice. It is an approach toward practice which is both scientific and realistic. The cycle consists of five process phases; design problem, diagnosis/analysis, design solution, implementation and validation (figure 3.1). According to Wieringa and Heerkens (2007) and Karlsson (2009) this type of research is commonly called “Action Research”.

The regulative cycle is used as the basis of the research framework which will be discussed in the next section.

3.2 Research framework

As described in the last section, the regulative cycle of Van Strien (1997) consists of 5 phases. Based on these phases, Balsters (2013b) developed questions which should be answered in each phase to complete it. Part of these questions originate from the engineering cycle of Wieringa and Heerkens (2007). The questions per phase are described below;

20 1. Design problem phase:

- Who are the stakeholders?

- What are the goals of each stakeholder?

- What are the Critical Success Factors (CSF’s) for each goal? 2. Diagnosis/ Analysis phase:

- What are possible causes of the difficulty resolving a CSF?

- What are the quality attributes of CSF’s and what are the restrictions of them? - What are the CSF interdependencies?

3. Design solution phase:

- Which alternative solutions are available?

- Can we assemble old solutions to build a new solution? - Can we invent a new solution completely from scratch? 4. Implementation phase

5. Validation phase:

- How to design test methods for each CSF? - Are all CSF’s met?

- Is there a trade-off between CSF’s?

- How scalable is the solution/implementation?

- How well does the solution/implementation perform relative to previously established CSF quality attributes?

- Have we encountered new CSF’s in the implementation result?

Very often the correctness of a design solution can be validated without having to implement that solution first (Balsters, 2013b). This is also the case for this research.

21 The adapted regulative cycle of Van Strien (1997) shows an extra validation and no implementation. Due to the limited resources, only part of the EHR-system is designed so implementation is not possible. The extra validation is directly after the diagnosis/ analysis phase to make sure the input for the design solution phase is correct. The design solution is validated by using mock-ups of the user-interface which supports the database.

3.3 Overarching project overview

Now the research framework is clear, the allocation of the individual researches will be described in the subsections below. To visualize these individual parts in the research framework of the overarching project, an overview of these parts is given in the adapted regulative cycle in figure 3.3. Before the overarching project is described, the scope has to be clear. As explained earlier, due to the limited resources only the so-called triage process will be investigated. This process starts when a referral is received at the LTHN, and it ends when the appointment is made. This triage process will be investigated on three different (sub-)specialism’s of the LTHN.

3.3.1 Developing the process models

The first part is divided into two steps, first the relevant source data for the database system has to be found, and second the data has to be validated. In the research framework these steps belong to the design problem phase, diagnosis/ analysis phase and validation phase. By means of structured interviews with end-users of the three (sub-)specialism’s information about the database will be gathered. This information will be transformed to process models and these models are validated again by the end-users. The exact approach of this part of the project is described in section 3.4.

22 3.3.2 From process models to data models

During the second part of the project, the output of the first part, mainly process models, are converted into data models using FBM. In the research framework it is the design solution phase. The method that will be used for this transformation is the FB-BPM method. These data models can be used to make user-interface mock-ups and the models can be compared with the existing data models which are developed using the LBGM method which all takes place in part 3 of the project. This part, part 2, of the project will be performed by Fischer (2014).

3.3.3 Validating the data models

The third part of the project is the validation of the data models made in part 2 in co-operation with the end-users. This will be done by designing mock-ups of user-interfaces by using the data models and process models. Besides this validation with the end-user, the data models of the Process-driven Database Design method are compared with the data models of the LBGM method. This part will be performed by Spits (2014).

If it appears that data is missing during the validation, the cycle starts again at the design problem phase.

23

3.4 Research design

In this section the research design is given of this part, the first part of the overarching project, about developing the process models. Besides developing process models the aim is to validate the first part of the method Process-driven Database Design. This means that all steps are critically examined by analyzing the method for missing steps and non-contributing steps during the use of the method. With these results, the method can be improved.

3.4.1 Step 1. Develop a general overview of the process

In order to map the processes, first a general overview of the process has to be made. Then it becomes clear which processes should be investigated and the boundaries can be clearly set. To develop a general overview, existing documentation about the processes can be used. This general overview will be used as a starting point for the use of the system approach. When the general overview is completed, the stakeholders and end-users can be identified whereby the next step can be entered. The selected three (sub-)specialism’s are chosen to check the differences in processes between tinkers and doers.

3.4.2 Step 2. Stakeholder analysis

In this step the stakeholders of the selected part of the system are analyzed. The questions are derived from the first two phases of the regulative cycle:

 Who are the stakeholders?

 What are the goals of each stakeholder?

 What are the Critical Success Factors (CSF’s) for each goal?  What are possible causes of the difficulty resolving a CSF?

 What are the quality attributes of CSF’s and what are the restrictions of them?  What are the CSF interdependencies?

In the end of this step, the questions above will be used to capture the functional and non-functional requirements. These requirements will be used during the development of the process models. 3.4.3 Step 3. Develop the process models

24 The questions that are used to derive the data for the data modeller, come from the Process-driven Database Design method of Balsters (2013a):

 Which entities are involved in the event as participants?  At what instant (timestamp) does the event happen?  How can the event be identified?

 What is the input for the event?  What is the output for the event?

During the interview sessions, the answers on all questions should be given to get enough information to proceed to step 4.

Before proceeding to step 4, the process models are discussed with the data modeller to check which information is missing. Based on this discussion, if necessary additional questions can be made. 3.4.4 Step 4. Validating the process models

The process models are validated by the same end-users as used earlier. During this validation the process models and answers on the questions are discussed, and if needed, adapted. During this meeting also the exceptions of the processes will be discussed (what can go wrong?). By getting a clear picture of possible exceptions the data model can be designed in such a way that it can handle these exceptions. Based on Karlsson (2009) and Balsters (2013c) the main questions for the validation are:

 Are all CSF’s met?

 Is there a trade-off between CSF’s?

 Is the process model completely and correctly displayed in the process models? If not, how does it have to be adapted?

 Is the data which is used at every event complete and correct? If not, how does it have to be adapted?

3.4.5 Step 5. Adapt results and method

25

4 Results

This chapter describes the results of the steps which are described in section 3.4. First a general process overview is given of the triage procedure. Second the stakeholder analysis is described. After that, the process models are given of the triage procedure. The method Process-driven Database Design is critically examined during all steps.

4.1 Process overview

First an overview of the project is made to clearly set the boundaries. Figure 4.1 shows a general process model of the triage procedure on a high aggregation level. Up to and including the gateway the input is encoded to make the input suitable for transformation. The triage, which can be done by the healthcare administration and doctor, is the transformation; the input is transformed to the desired output. In the last activity, the output is decoded in order to ensure that the output can be used outside the system.

Based on this process model, the stakeholders of the triage procedure can be identified and analyzed.

26

Table 4.1 EHR stakeholders

4.2 Stakeholder analyses

Before starting the interviews, it is investigated who the actual stakeholders of the triage procedure are. There are internal stakeholders and external stakeholders for an EHR-system. Some internal stakeholders are also actual end-users of the EHR-system for the triage procedure. These stakeholders have to answer more questions than stakeholders who are not an end-user for designing the process models, since they exactly know how the process flows.

4.2.1 Stakeholders

Based on Stephana (2013) and an interview with a project member of the EHR-system at the LTHN a list of stakeholders came out for a fully working EHR. This list is shown in table 4.1.

EHR stakeholders Internal 1. Doctor a. Medical student b. Co assistant c. Doctor assistant d. Medical specialist 2. Nurse a. Nurse in education b. Normal/ specialist nurse 3. Healthcare automation

4. Management staff

5. Healthcare administration; appointments, planning, etc. 6. Medical administration; facility, declarations, etc. 7. Researchers

External

8. Patients

9. Referrers (Parties in the healthcare chain; general practitioner, not-academic medical specialists, etc.)

10. EHR-system supplier

11. Government; regulations and understanding of operations 12. Paramedics (inclusive pharmacist)

27 Because the triage procedure is only a part of the EHR-system, the list of actual stakeholders is a lot smaller. The stakeholders which are concerned with the triage procedure are listed in table 4.2. Triage procedure stakeholders

Internal

1. Doctor

a. Doctor assistant b. Medical specialist

2. Healthcare administration; appointments, planning, etc. 3. Medical administration; facility, declarations, etc. External

4. Referrers (Parties in the healthcare chain; general practitioner, not-academic medical specialists, etc.)

5. Government; regulations and understanding of operations

When the main goals for each stakeholder are known, the risk of failure is reduced, and it will increase the willingness of the stakeholders to corporate with the development of a new EHR-system (Boonstra & Goovers, 2009). Based on the list of stakeholders in table 4.2 an analysis is carried out, which is described in subsection 4.2.2.

4.2.2 Analyses

In this subsection each stakeholder is analyzed. The doctor and the healthcare administration are actual end-users of the system within the triage procedure, that is why they are also used during the development of the process models (Balsters, 2013b).

4.2.2.1 External stakeholders

This subsection describes the analysis of the external stakeholders of the EHR-system. Referrers

Parties outside the hospital in the healthcare chain, in this case referrers, are very important for the triage procedure. These are the people who give the input for this process, so they have an important stake in the process. Examples of such parties are general practitioners and not-academic medical specialists. The main goals of the referrers are; they must have the ability to send a referral to the hospital and they have to be kept informed about the process of the patient in the hospital.

28 This last goal means for example, that if the LTHN cannot perform a treatment which is described in the referral, the referrer should be informed about this fact.

Government

According to Stephana (2013) the CBP (in Dutch: College Bescherming Persoonsgegevens), Ministry of VWS (in Dutch: Ministerie van Volksgezondheid, Welzijn en Sport), NICTIZ (in Dutch: Nationaal ICT Instituut in de Zorg), and IGZ (in Dutch: Inspectie voor de Gezondheidszorg) are the agencies which have a stake in an EHR-system. Each of them look from a different perspective to the EHR-system. These agencies take also care of the interests of the patients, in particular the authorization for healthcare staff to see the patient data.

The goals of these agencies can be summarized within the following points; security, privacy and hospital performance.

Security

Stephana (2013) described security standards that are related to the security of personal data, authorization, and access logging of EHR-systems. These standards are NEN 7510, NEN 7511, NEN 7512 and NEN 7513. In the LTHN there are no written procedures for security.

Privacy

From the view of the patient, privacy is very important. They do not want their personal information visible for people who have nothing to do with it. The role of the CBP is to coordinate and execute the privacy laws in the Netherlands (Stephana, 2013). Stephana (2013) describes the following laws pertaining privacy; WGBO (in Dutch: Wet Geneeskundige Behandelingsovereenkomst), WPB (in Dutch: Wet Bescherming Persoonsgegevens), and WBSNZ (in Dutch: Wet gebruik Burgerservicenummer (BSN) in de zorg).

Hospital performance

The Ministry of VWS and the IGZ regulates the quality of healthcare by supervising the healthcare industry. In order to increase the quality of complex care, hospitals need to meet volume requirements to counteract revoking their license for certain treatments (Stephana, 2013). With this goal, the healthcare costs can decrease and the quality increases.

4.2.2.2 Internal stakeholders

29 Medical administration

The medical administration arranges mainly the facilities and declarations. This stakeholder is less involved in the processes in which the patient is present, but more in the supporting processes. This means that the medical administration only needs data from the triage procedure to perform its task. In other words, the goal of the medical administration as a stakeholder of the triage procedure is to get enough information to perform their tasks. This kind of information is mainly about the appointment data of the patient.

Healthcare administration

The healthcare administration has a supporting task for the doctors. In the triage procedure this is clearly evident. To the extent that the healthcare administration can assess a referral they will do that, and for the substantive assessment part they cannot do, they will send the referral to a doctor. In the triage procedure the healthcare administration has mainly four tasks, first they need to register the patient, second they have to determine to which (sub-)specialism they have to send the referral. The third task is to assess the referrals if they are able for it, otherwise they have to send it to a doctor, and the fourth task is to plan the appointment.

There are also two exceptions in their part of the process. If a referral is not assessable because there is some substantive information missing they have to request it at the referrer or at another source. The other exception is that the healthcare administration has to inform a referrer if the referral does not belong to the LTHN.

Doctors

Within the stakeholder Doctor, two types are described. In the LTHN there are different levels of doctor which results in different tasks. For the triage procedure, only the doctor assistant and medical specialist occur. Within their role of doctor in this process, there is no difference between these two types, hence they are described as one stakeholder.

The main goal of a doctor in the triage procedure is to assess the referrals. In this assessment he normally captures a time limit where a patient should be seen in the hospital, and where the patient has to report himself based on an agenda code.

30 Overall goals for healthcare staff

At the end, there are also some general goals for healthcare staff. Dijkstra (2012) described these main goals as follows:

 Reduction of mistakes in healthcare  Easy transfer and retrieval of patient data  Improved performance

 Easiness of the system

4.2.3 Critical Success Factors and business requirements

In this subsection the CSF’s are defined based on the goals of the stakeholders. After defining these CSF’s, they are translated to business requirements which can be used for the development of the process models.

4.2.3.1 Critical Success Factors

In this subsection the critical success factors are described per stakeholder.

Stephana (2013) made a list of CSF’s for a national EHR-system based on literature from Balsters (2013b), Boonstra & Goovers (2009), Scott et al. (2005), Malloch (2007), Mäenpää (2009), laws and regulations (WGB, WGBO, WBPG and NICTIZ) and previous performed studies of Dijkstra (2012), Haarsma (2012) and Wijma (2012). This list is adapted and supplemented for the EHR-system in the LTHN based on discussions with project members of the EHR-system department.

Doctors and healthcare administration are grouped in this list because they are both users of the EHR-system within the triage procedure so their CSF’s are overlapping.

Referrers

 The EHR-system must have the same receiving options as the current system.

 The EHR-system must take no more time for the triage procedure than the current system. Government

 The EHR-system must be safe; it must meet the laws and regulations.  The EHR-system must support audits.

Medical administration

31 Healthcare administration and doctors

 The EHR-system must fit the current workflow.  The EHR-system must be easy to understand and use.

 The EHR-system must only contain patient information which is clear for all healthcare staff.  The EHR-system must only contain complete and correct information.

4.2.3.2 Business requirements

To use the CSF’s of all stakeholders, they are translated to business requirements, in other words; the CSF’s are described in a way that they can be used in the EHR-system.

As described in section 2.1, there are functional requirements (FR) and non-functional requirements (NFR). The FR are expressed in the form “the system shall do <requirement>”, while the NFR are expressed in the form “the system shall be <requirement>”.

Referrers

 The EHR-system shall be able to receive referrals via fax, by letter and via “ZorgDomein” (the digital interface for general practitioners).

 The triage procedure shall do not take any longer than 10 working days. Government

 The user shall do a login, each time the procedure starts.

 The user shall be terminated if the user ends the session, or after a period of inactivity.  The system shall do an authorization check, to check if the user is authorized for the process

and to check if the user is authorized for that particular (sub-)specialism.  The system shall do work in a way that all regulations and laws are followed.

 The system shall do log information; the responsible person and time for each activity in the triage procedure, to support audits.

Medical administration

 The system shall be able to extract appointment data of patients for declarations, so it has to log all this information.

Healthcare administration and doctors

32  The system shall be designed in a way that there are no interpretation errors possible.  The system shall be designed in a way that it can only contain complete and correct

information.

 A patient shall be able to be identified by patient number, or as an alternative by a combination of surname, gender and birth date and a combination of gender and birth date.  The system shall be able to communicate with ZorgDomein, email and (sub-)specialism

specific systems to transfer data.

4.3 Developing the process models

Based on the workflow of the end-users of the system and the business requirements, the process models are developed. In this section the development process of the models and the process models themselves are described. The development process of the models includes the validation process and answering the Process-driven Database Design questions. These process models are made on a lower level of aggregation than the process model in figure 4.1 to show the actual proceedings of the EHR-system.

The first part is used to develop the preliminary version of the process models and the second part is used for validating the preliminary version of process model to come to the final version of the process models. The questions that will be used, are described in section 3.4.

4.3.1 Developing the preliminary process models

33 Now it is known what the pool and lanes are, a first design of the triage procedure can be made on the basis of existing documentation and an interview with a doctor, which is also a member of the EHR-system department. This doctor knew the processes of the healthcare administration whereby the whole triage procedure became clear. For the first version, the priority lays on the business flow more than the Process-driven Database Design questions.

During the development of the process models, the stakeholder goals, CSF’s and business requirements are implemented in the process models. The process models needs to conform the business requirements; the CSF’s are translated to events in the process, and the stakeholder goals are met at the end of each lane which means that all goals are met at the end of the triage procedure.

The output of this first interview is given in appendix V.I.

34 Since the basics of the process are defined, these preliminary results are forwarded to the second stage of the overarching project. This means that Fischer (2014) starts building ORM models by using the process model which is given in appendix V.I.

Starting the second stage of the overarching project in an early stage has an advantage; early feedback on the process models can be used during the following interviews so that the output of the first stage of the overarching project can be made complete for the second stage.

After the feedback of Fischer (2014) and with the process models as a first version, employees of three different (sub-)specialism’s were interviewed. During these interviews the first version of the process model was discussed to extract the workflow on these healthcare administration (sub-) specialism’s.

Based on these interviews the process model in appendix V.II was created.

After discussing the results (appendix V.II) with Fischer (2014) it became clear that the focus of the business process was still an aggregation level too high. To translate process models to ORM models there are more details needed. This means the process model needs to be developed on a lower aggregation level and the Process-driven Database Design question should be used at that level. This change in level of detail does not mean only the process which is related to the EHR-system has to be captured. If that was the case, the process steps which do not require the EHR-system should not be included in the process model; it can result in an incoherent process model whereby the end-user does not recognize the business process anymore. This means, the end-end-user cannot validate the process model. To prevent this problem, the process model has to be developed on the aggregation level which shows the EHR-system steps, but including the process steps that do not require the system. These steps are given another colour to recognize them and are applied from appendix V.IV. To put this into practice, the Systems thinking approach needs to be supplemented with an additional question to derive the right data for the data modeller; Which elements of the process model are related to the EHR-system?

The section below describes how the Process-driven Database Design method questions are evaluated to get enough information for the second stage of the overarching project.

35 After interviewing the doctor and healthcare administration employees, it did not became clear how each event should be identified. That is why this question was passed on to a technical domain expert, in this case a member of the EHR-system department, and he also could not give an answer on the question. He made clear it was a decision the data modeller should make. In this case the question is not answered in this part of the overarching project, since Fischer (2014) makes the data models.

 At what instant (timestamp) does the event happen?

After the interviews with the end-users, it became clear this question did not mention anything for the process. That is why this question was also passed on to the technical domain expert. After discussing the question it became clear that it was not a question that can be asked to the end-users and technical domain experts, but it is related to the data modeller. Each event has to be logged, a way to log an event is to use a combination between time and another different data type. In other words, the instant should only be added to the ORM models to log events.

 What is the input for the event?/ What is the output for the event?

These two questions about the input and output of the event should be supplemented in terms of a more detailed question:

 Additional question: Which data is needed for the event?; Which data is (CRUD) Created/Read/Updated/Deleted?

By answering this question, it is getting clear what data is changed in every event; in other words, it describes which data is created, read, updated and deleted in each event.

 Which entities are involved in the event as participants?

This is an important question, but it is hard to answer by an end-user. The question can be answered by the technical domain expert, he knows exactly which entities are involved in the event as participants.

 Additional question: How can the participants be identified?

36 4.3.2 Validating the preliminary process models

After designing the first process models and reformulating the Process-driven Database Design questions the validation of the process model is performed according to the questions given in section 3.4.

The first evaluation is performed by means of an interview with the same doctor which was used for the first process model and a technical domain expert. This has a particular reason, parts of the triage procedure will be automated in the to-be EHR-system which are currently not-automated. By evaluating the preliminary process models with him first, the process model can be adapted to the to-be situation.

Based on the preliminary process models, the reformulated questions and the input of the doctor and technical domain expert, the process model was supplemented. The process model is shown in appendix V.III.

During the validation of the process model of appendix V.III, it became clear that the login procedure was not fully correct. Besides that, it became also clear that the process model was getting too large, which was partly caused by the returning login procedures. To keep the process diagram readable BPMN provides abbreviation facilities in the form of sub-processes. These sub-processes work as a black-box, in this case the login procedures are kept in these black-boxes. These procedures are in each lane exactly the same, the sub-process has just to be developed once and it can be used multiple times. In terms of systems thinking, the login procedures are shown on a higher aggregation level as the activities around it to keep the triage procedure readable.

These login procedures are explained below. Login procedures

As described earlier, the government sets requirements for a login procedure because of the privacy. Since the LTHN has no information about the restrictions of a login procedure, there are some assumptions made.

 The triage procedure consists of two stages, the pre-triage and triage. To execute a procedure, the employee who logs in has to be authorized for that stage of the process. Within this authorization also the role of the employee is checked.

 As soon as the referral has a (sub-)specialism, the employee must be authorized for the same (sub-)specialism to work on it.

37 A. Login healthcare administration portal specialism

The first login only requires a normal check on username a password and an authorization check if the employee is authorized for the healthcare administration pre-triage. Since the referral does not have an (sub-)specialism assigned, only these two check are performed.

B. Login doctor portal specialism

The login procedure for a doctor portal specialism is the same as for an employee of the healthcare administration, only in this case the role is different; the role which is checked in this login procedure is doctor pre-triage.

Figure 4.3 Login healthcare administration portal specialism

38

Figure 4.5 Login healthcare administration (sub-)specialism

Figure 4.6 Login doctor (sub-)specialism

C. Login healthcare administration (sub-)specialism

The login procedure of the healthcare administration (sub-)specialism requires just like the first two procedures a normal check on username a password and an authorization check if the employee is authorized for the healthcare administration triage. But there is a third one added, since the referral has an (sub-)specialism assigned, it is checked if the account has the same (sub-)specialism as the referral.

D. Login doctor (sub-)specialism

39

Figure 4.8 Request additional patient data

The last step in developing the process models is the evaluation at the healthcare administration employees of the three (sub-)specialism’s. During this interview only minor additions were done based on the process model and questions. After these interviews the provisional version of the process model is created. This version of the process model of the triage procedure is used for the first version of the data models and user-interface mock-ups and is shown in appendix V.IV.

4.3.3 Feedback from user-interface mock-ups

The feedback of the user-interface mock-ups gave a few substantive points in which the process models should be adapted (Appendix IV). These minor changes did not result in changing the method.

It was also noted that just like the login procedures, the information request loops could be put in sub-processes, to keep the process model better readable. So these different processes are also shown on a higher aggregation level as the activities around it.

These information request loops are shown below. E. Request missing data

F. Request missing patient data

40

Figure 4.10 Request additional data

G. Request patient permission

H. Request additional data

The process model (appendix V.V) shows the final version of the process after the implementation of the feedback of the user-interface mock-up validation. The BPMN appendix which describes the answers on the Process-driven Database Design method questions of the final process model can be found in appendix III.

41

5 Discussion

In the first part of this chapter the method Process-driven Database Design will be discussed based on the results of chapter 4. In the second part of this chapter the research at the LTHN will be discussed.

5.1 Process-driven Database Design

In the first part of this section the development of the process models will be discussed. The second part will be used to discuss the questions of the Process-driven Database Design method which are used to derive the right information for the second part of the overarching project.

5.1.1 Development of the process models

During the development of the process models, the system approach was used several times to come to the right aggregation level. In this case it was the aggregation level which showed the steps of the EHR-system. At this level, it is notable that each end-user has its own lane. Besides that, it is notable that the CSF’s are translated to events and that the end of a lane corresponds with the stakeholder goals. In this way, the stakeholder analysis can be used to verify the process models.

By using the Systems thinking approach to derive the process models, existing process models can be used as a starting point for the development of an EHR-system. The method can be used to search for the right aggregation level which is needed to derive the right data for the data modeller.

It became also clear that not all events were related to the EHR-system. That is why an additional question was added before the Process-driven Database Design questions could be used. The additional question is: “Which elements of the process model are related to the EHR-system?”. Events that only required the user-interface are displayed in orange, and events that did not require the EHR-system and user-interface are displayed in red in the process models in order to make clear what is important for the other two parts of the overarching project.

Repeating processes, which require loops, take a lot of space in a process model which causes a difficult to read process model. These kind of processes can be displayed in sub-processes, it is meant that such processes are displayed on a higher aggregation level; the sub-processes are black-boxes. The overall process model stays better readable, and after reading the sub-process once, it is clear how the other sub-processes work in the overall process model.

The research was conducted to receive an answer on the following research question:

42 This was shown in chapter 4 and discussed above. In the next subsection, the questions of the Process-driven Database Design method are discussed to completely answer the research question. 5.1.2 Process-driven Database Design questions

The current method contains five questions (Balsters, 2013a) for each event in the process model. As given in chapter 4, it became clear some questions were missing and some questions could not be answered by end-users and technical domain experts. These questions are discussed below.

Which entities are involved in the event as participants?

Based on the findings during the research it became clear that the answer of this question can be derived from the technical domain expert.

Additional question: How can the participants be identified?

Participants have to be logged to make them identifiable, this has to be registered. This question had to be answered by the data modeller since a technical domain expert could not give an answer on the question. But in other cases it is likely that a technical domain expert can answer this question, for this reason this question is listed for the end-users and technical domain expert, and for the data modeller if it is not answered by the end-users and technical domain expert.

How can the event be identified?

Just like the identification of the participants, it became clear this question was also for the data modeller in the case at the LTHN. But this question stays also on the question list of for the end-users and technical domain expert, since it is quite possible that they can give the answer.

At what instant (timestamp) does the event happen?

This question is mainly used to make events and participants identifiable. So this is most of the time not a question for an end-user. This is also a question for the data modeller in the LTHN case but is stays on the question list, for the same reason as the questions above.

What is the input/ output for the event?

43 To derive the right data for each event for the data modeller, an additional question is supplemented. With this question it becomes clear which data is (CRUD) Created/Read/Updated/Deleted.

Now all questions are discussed, a new overview of questions can be given. These questions are listed below. A general rule for these questions is; Questions that cannot be answered by end-users and technical domain experts have to be answered by the data modeller.

Adapted Process-driven Database Design questions o How can the event be identified? o What is the input for the event? o What is the output for the event?

o Which entities are involved in the event as participants? o How can the participants be identified?

o Which data is needed (CRUD) for the event?

o At what instant (timestamp) does the event happen?

During the discussions with the technical domain expert the scalability of the method was mentioned. It became clear that the method so far works, making the process models and finding the answers on the questions. But when the method is used on a larger scale the terminology could cause problems. If process models are not developed using similar terms, there is a chance that different terms are used for similar data. When the work is passed on to the data modeller, the terms will differ in the data models which causes problems in the database.

5.2 Performed research

In this section, the performed research in the LTHN will be discussed.

The scope of the research was only on the triage procedure. Within this procedure three different (sub-)specialism’s are approached. The choice for only this procedure was based on several points; it is now performed within several different systems and it is also performed in a different way for each (sub-)specialism. If this procedure is generalizable and it can be supported by one system, it can be proved that it also applies for the other procedures.

44 the other healthcare processes. The second critical point is that only three different (sub-) specialism’s are approached which is only a very small part of the complete hospital. At the selection there is taken into account that the extremes of departments (thinkers, doers and in between) are chosen to get a good picture of reality.