• No results found

Validation of a process-driven database design method: Validation of the to-be electronic health record- system database models and the process-driven database design method

N/A
N/A
Protected

Academic year: 2021

Share "Validation of a process-driven database design method: Validation of the to-be electronic health record- system database models and the process-driven database design method"

Copied!
116
0
0

Bezig met laden.... (Bekijk nu de volledige tekst)

Hele tekst

(1)

method: Validation of the to-be electronic health

record-system database models and the process-driven database

design method

University of Groningen Faculty Economics and Business

&

A large teaching hospital in the Netherlands

Master Thesis Technology and Operations Management Groningen, February 2014

First Supervisor: Dr. H. Balsters Co-assessor: Dr. Ir. W.H.M. Alsem

Erik Spits Fongersplaats 177 9725LK Groningen Student number: S2068419

(2)

design method

2

Abstract

Fact-based business process modeling is a new method, which allows the modeler to create a process driven database. This method fills the gap between process modeling and database modeling, by linking these two modeling approaches.

This method has been tested, but not yet validated. In this research fact-based business process modeling has been successfully used which contributes to the validation of the method for similar practices. Evaluation of validation, through application of this method in an electronic health record (EHR)-system development is the main objective of this research. The research covers three parts: Developing process models in business process modeling and notations; translating these process models in database models, using object-role modeling, and; the validation of the processes and database models, by validating the generated database models. The third part is covered in this research paper.

For the validation research a to-be electronic health record-system is designed, by using the fact-based business process modeling method. The process and database models are translated to this to-be system by user interface mockups. Validation is based on the outcomes of an evaluation of fulfillment of critical success factors among end-users.

(3)

design method

Table of Contents

Abstract ... 2 Preface... 5 1. Introduction ... 5 2. Research questions ... 6 2.1. Research background ...6

2.1.1. Research part 1: Business process model development (Hoekstra, 2014) ... 7

2.1.2. Research part 2: Database model development (Fischer, 2014) ... 7

2.1.3. Research part 3: Validation of the database model ... 7

2.2. Overall research questions ...8

2.3. Paper specific research questions ...9

3. Theoretical background ... 10 3.1. Design research ...10 3.2. Requirements engineering ...12 3.2.1. Functional requirements... 12 3.2.2. Non-functional requirements ... 13 3.3. Process modeling ...13 3.4. Data modeling ...14 4. Methodology ... 14

4.1. Methodology validation of the models ...15

4.1.1. Validation questions embedment and implementation ... 16

4.2. Validation approach part 3 of the overall research ...16

4.2.1. Step 1: Receiving and interpreting the process and data models ... 17

4.2.2. Step 2: Translate step 1 into UI-mockups using Microsoft Access ... 17

4.2.3. Step 3: Validation of the models ... 17

4.2.4. Step 3A (optional): Looping the obtained feedback ... 17

4.2.5. Step 4: Second validation; comparing the data model to the TBGM ... 18

4.2.6. Step 4A (optional): Looping the obtained feedback (final validation) ... 18

5. Results ... 19

5.1. Step 1 and 2: Creation of the UI-mockups ...19

5.1.1. Implications of the BPMN for the UI ... 19

5.1.2. Implications of the ORM for the UI ... 21

5.2. Step 3: Validation of the process and data models (validation of the UI-mockups) ...24

(4)

design method

4

5.4. The FB-BPM method for designing a to-be EHR-system ...28

6. Conclusion ... 29

7. Discussion ... 30

Appendix I Project description ... 31

Appendix II Identified stakeholders, critical success factors and business requirements (Hoekstra, 2014) ... 34

Appendix III Process and database validation examples ... 36

Process validation using UI-mockups example ...36

Database validation using UI-mockups example ...37

Appendix IV Received Data: BPMN and ORM models... 39

Received process models in BPMN ...39

Received data models ORM ...42

Received relational database models in ORM ...48

Appendix V Examples of model interpretations and translations ... 55

Example of BPMN interpretation and translation ...55

Conclusion BPMN interpretation and translation ... 56

Example of ORM interpretation and translation ...57

Example of UI interpretation and translation ...62

Appendix VI Feedback discussion ... 68

Appendix VII Improved UI based on feedback from end-users ... 70

Appendix VIII Validated UI-mockups ... 76

Appendix IX Explanation of the LBGM and the TBGM... 101

The LBGM ...101

The TBGM ...102

Appendix X Comparing the ORM with LTHN’s database ... 103

Appendix XI Glossary ... 108

Appendix XII Figures list ... 109

Appendix XIII Tables list ... 113

(5)

design method

Preface

First of all, I would like to thank the people whom are very dear to me and helped me in achieving this research. I would like to thank M. Kaufmann for his input on my preview, my brother for his help and input, but most of all my dad for the inspiration and drive to complete this research (paper). Even though he did not always understand the subject at hand as well as I did, he still managed to motivate me and inspire me when it was needed.

Furthermore I would like to thank J.W. Bruintjes for reading my paper and providing me with comments.

Also, I would like to thank my mother for her kind words and M. van den Eijnden, as she had to put up with me, even when I was having and giving her a hard time, during this research.

Finally, I would like to thank S. Hofman and I. Veldman for their moral support, by for instance reminding me that a break once in a while can clear the mind and give energy to follow through.

1. Introduction

This research paper aims to validate a database model created by using a new method to integrate data and processes, called fact based business process modeling (FB-BPM). The FB-BPM method combines fact-oriented modeling or fact-based modeling (FBM), with business process modeling and notation (BPMN) and requirements engineering, to create a process-driven database (Balsters, 2013). The benefits of this process-driven database are the abilities to not only get the process visible and being able to communicate the process in the universal BPMN (Russel & ter Hofstede, 2010), but also to model a business process from the perspective of an end-user of the database (Balsters, 2013).

A process model is basically a complex flowchart, which is written in the universal process modeling language of BPMN. A process model takes not only the process in account, but also the stakeholders as well as the actions and interaction between the stakeholders.

(6)

design method

6

the process with the end-users. This is possible because of the completeness and preciseness of ORM.

The FB-BDM method has been tested before during a combined research (Stephana, 2013) (Post, 2013) (Hijlkema, 2013) in a local Dutch hospital, but has never been validated in a broader environment. This research aims to validate and if necessary improve the method on a larger scale, at a large teaching hospital in the Netherlands (LTHN). The validation consists of creating mockups of the start of a new internal electronic health record (EHR) at the LTHN. The start contains the process from the entry of a patient’s referral and all of the associated process steps, concerning the triage process. The triage process is the basic process involving assessing the level of treatment the patient needs. The processes’ main (triage) decision is whether the patron needs patient-level or professional-level information, or both (Elichko, 2012) in order to treat the patient.

The overall FB-BPM validation research consists of three parts, of which this paper covers the final part. The first part consists of creating the process model in BPMN (Hoekstra, 2014). Within this first part, the stakeholders are identified along with their critical success factors (CSF’s). The second part of the validation consists of creating DBM, based on the process model by using ORM (Fischer, 2014). The final part consists of the validation of the created DBM, which is the focus of this paper.

Section 2 focuses on the research background and questions of the overall research, as well as the research questions, related to this research paper. The 3rd section of this paper covers the theoretical background and elaborates on requirements engineering, process modeling and data modeling. Section 4 elaborates on the methodology of this research in which the step-by-step validation of the data models will be elaborated. The 5th section of this paper represents the results of this research. Section 6 entails the conclusion and the final chapter finishes this paper with the discussion section.

2. Research questions

2.1. Research background

(7)

design method

validating the process model, creating the data model and validating the data model and by doing so, also validating the process model and the FB-BPM method. Figure 2.1 provides an overview of the overall research and the appropriate parts.

Validation of FB-BPM to design a to-be EHR-system in a medical care environment

Part 1: Designing process models (using BPMN) by

Hoekstra

Part 2: Using the process models to design a DBM (using ORM) by Fischer Part 3: Validation of DBM (using UI mock-ups) By Spits Feedback loop on the process models

Feedback loop on the DBM

Figure 2.1 - Overview of the research and the three parts

2.1.1. Research part 1: Business process model development (Hoekstra, 2014)

The researcher will use interviewing techniques to identify the stakeholders (especially end-users), the goals and the critical success factors (CSF’s) in order to get insights on the process. This process will then be translated into a process model, by using the standard in BPM, the BPMN.

When the first processes are translated into a BPM process model, they will be used as input for the next parts of the research.

2.1.2. Research part 2: Database model development (Fischer, 2014)

The developed process model is translated to a database model (DBM) by using ORM. ORM allows the modeler to constantly adapt the model, by adding attributes to the model, so each time the designer receives updates and more information on the BPM and DBM; it is easily adjusted, without having to start all over. This DBM is validated in the third part of the research.

2.1.3. Research part 3: Validation of the database model

(8)

design method

8

earlier identified end-users (see section 2.1.1) whom will be interviewed about the correctness and completeness of the UI, in terms of process and data. The UI-mockups validate the DBM by looking at the structure of the individual UI-mockups, whereas the flow between these individual UI-mockups validates the process model. The received feedback is used to improve the process model and/or database model by looping the feedback back to the specific part of the overall research.

Apart from the validation of the data model, the data model of the to-be EHR-system will also be compared with LTHN’s own data model, the TBGM (Dutch: Technisch BedrijfsGegevens Model; English: Technical Business Data Model) (see Appendix IX) The TBGM and the LBGM (Logical Business Data Model) are developed in collaboration with the “Erasmus Hospital” and is a project to integrate the databases of both hospitals, to share data. This is one of the key elements of an EHR.

The comparison of the TBGM and the process-driven database model is the final validation step of the data models and the FB-BPM method, which generates a discussion about the relevance and cause of the differences between these two models. Any missing relevant processes or incorrect data aspects are looped back to the first part of the research just like the previous validation.

2.2. Overall research questions

The combination of the three research papers, aims to answer the following overarching research question:

“How to validate the correctness of data models supporting an EHR?”

For the overall research the following sub-questions are identified based on the project description (see Appendix I):

1. What is the state of art concerning exchange of medical patient data within the LTHN? 2. Who is currently exchanging data, what data is exchanged and how is the data exchanged?

3. What are the constraints on patient data exchange?

(9)

design method

6. How can we systematically derive a data model from the process model?

7. How does the existing TBGM data model of the LTHN compare to our derived data model?

These sub-questions are specific for the overall research and not for this research paper, except for the seventh question (sections 2.1.3 and 4.2.5). The combination of the three research papers will relate to and answer these previous research (sub)questions. For more details on the received project description, see Appendix I.

2.3. Paper specific research questions

Looking at the proposed research questions and the validation questions (section 3.1); they need to be more relevant to the objective of this paper. The adjustment should entail not only the validation of the DBM and the method, but also the aspect of creating a to-be EHR-system with this method. The research question for this paper is the following:

“How to validate the correctness of the DBM created by applying the FB-BPM method?”

Looking at the sub-questions of the overall research, they too require adjustments, in order to fit the research objectives of this paper. The last three sub-questions are concerned with “how to” questions. In extent of the sub-questions in the previous section, the first relevant “how” question would be the following:

“How to validate a previously created data model (the “TBGM”) within the context of a to-be designed EHR-system at the LTHN?”

After the method is applied to the to-be EHR-system, it is relevant to validate this new model to the previous model, that the LTHN created itself (the TBGM), for completeness and correctness

(10)

design method

10

“Who is needed to approve and acknowledge the EHR?”

The next question relates to identifying the requirements for the validation. “Which criteria should be met for the validation of the DBM?”

As a final question, this paper will compare the current model that the LTHN proposed, the TBGM, to evaluate the created to-be EHR-system and discuss the differences. This sub-question is related to sub-question 7. The question should validate and compare the to-be EHR-system to the current data model of the LTHN:

”How does the data model of the to-be designed EHR-system within the context of the LTHN, compare to the already existing data model of the LTHN’s, called the TBGM?”

3. Theoretical background

In this section of the paper, the theoretical background within the overall research and this research paper is addressed and elaborated. This is done by first examining the research on design research and requirements engineering, since the functional design of an EHR-system is first and foremost about getting the requirements of the system right, before implementing the system. In the second and third place, process modeling and data modeling will be examined, and in that specific order. The idea is that a particular method of requirements engineering, coined as FB-BPM, will be suited to construct the functional design of an EHR. The FB-BPM method starts from validated process models (capturing the intended usage of the system from the perspective of each stakeholder), and in a logical fashion derives a data model from such a process model. By capturing both the relevant process- and data-properties of the system, the claim (Balsters, 2013) is that FB-BPM offers a full treatment -on the conceptual level- of the functional requirements needed for an EHR-system (Balsters, 2013).

3.1. Design research

(11)

design method

A stakeholder can be defined as a person or organization who influences a system’s requirements or who is impacted by that system. (Glinz & Wieringa, 2007) These stakeholders each have goals for the design problem, which may or may not be similar to each other. The goals can be defined as a desired change in the current state of the world (Balsters, 2003). These goals of the stakeholders can be achieved by successfully meeting the critical success factors. A critical success factor can be defined as a success factor that has to be met, any other solution not resolving that factor will fail to attain the original goal (Balsters, 2003).

Within the design research, van Strien (1997) identified a regulative cycle that is applicable for the design methods (Figure 3.1). This cycle consists of five phases: design problem, diagnosis/analysis, design solution, implementation and validation. The dotted line indicates, the optional input after the validation, as the validation could be positive (i.e.: no improvement necessary). This cycle can be alternated, during the design research, as some phases are not applicable (Balsters, 2013).

Design Problem

Validation

Diagnosis/

Analysis Design Solution

Implementation

Figure 3.1 - Regulative cycle (van Strien, 1997)

Each of these phases are associated with specific questions (Balsters 2013) (Wieringa & Heerkens, 2006), of which the validation phase is relevant for this research paper. A correct validation implies answering these questions.

Validation:

1. How to design test methods for each critical success factor?

2. Did we meet all of the critical success factors, and if not what are the trade-offs? 3. How scalable is the solution?

4. How well does the solution perform?

(12)

design method

12

It is important to note, that these questions are not explicitly answered in this research, but by completing the validation, these questions are answered. Also, these questions are used in the validation process and to formulate more relevant research questions (see section 2.3). The embedment of these questions is elaborated in section 4.1.1.

This cycle with the relevant validation questions is used in the methodology section 4 of this paper (Figure 4.1). The validation is only a success when these questions are addressed and answered properly.

3.2. Requirements engineering

Requirements engineering is an important topic within design research. Requirements engineering can be seen as a system engineering discipline concerned with discovering the stakeholders of a system of concern, finding their business needs and goals, and documenting these concerns in a manner that is amenable for analysis, communication, and subsequent implementation (Young, 2004). Within the requirements engineering the critical success factors and the functional requirements are identified. These critical success factors are necessary for a complete and correct validation. Moreover, requirements engineering is a process in which a most diverse set of product demands from a most diverse set of stakeholders has to be considered and thus requirements engineering is generally thought of as the most critical and complex process within the development of embedded systems (Parviainen & Tihinen, 2007).

Requirements engineering is typically the starting point of system-development, where the activities related to the purpose, the stakeholders, scope of the system and actors are identified, to create a requirements specification (Vieira, Ferreira, Borbinha & Gaspar, 2012). These specifications are usually documented in a document, which contains individual requirement statements, requirement specifications, which must contain contextual information, like system goals, scope of the requirements and the description of stakeholders involved. These requirements can be divided into two categories: Functional (section 3.2.1) and non-functional requirements (section 3.2.2).

3.2.1. Functional requirements

(13)

design method

requirements could be: Create an overview of all the required process steps. It is a requirement that the stakeholder needs and thus is a goal of the system. The goals and the stakeholders are the main focus in the functional requirements.

These functional requirements are validated, in the steps of the methodology (section 4.1) by implementing and addressing the validation phase questions (section 3.1).

The functional requirements are formulated as “The ‘system’ shall do <…>”.

3.2.2. Non-functional requirements

The non-functional requirements focus on “what shall the system be?”, which are also known as quality attributes (QA’s). These QA’s are related to the scalability of the design, for example: “How easy to implement must the solution be?” The questions are more about the quality of the solution, instead of method questions (e.g.: How is it done?). Non-functional requirements are concerned with the quality which depends on the critical success factors of the goals.

The non-functional requirements are formulated as “The ‘system’ shall be <…>”. 3.3. Process modeling

In simple terms processes are sets or sequences, of activities which result in the accomplishment of a task, or the achievement of an outcome (Buchanan & McMenemy, 2011). The following three benefits are identified for process modeling (Bandara, Gable & Rosemann, 2005) Documentation benefits: through a common, basic language that can be readily understood by stakeholders (based on shared vocabulary); design benefits: through understanding current processes, exploring new scenarios, and planning for implementation, and; use benefits: through visualization of workflow and scenarios. Also, process modeling helps in understanding what (software) systems are expected to do (Mili, Tremblay, Jaoude, Lefebvre, Elabed & El Boussaidi, 2010), which corresponds with the functional requirements (section 3.2.1). Mili et al. (2010) also describe three reasons for using BPM, namely: Describing a process, analyzing a process, and enacting a process.

(14)

design method

14

the processes, to the technical developers responsible for implementing the technology that will perform those processes, and finally, to the business people who will manage and monitor those processes, thus creating a standardized bridge for the gap between the business process design and process implementation.1 (www.omg.org, 2011)

The business process model designed in the first part of this research, is presented in BPMN (Hoekstra, 2014), which is used in the second part of the overall research, to create a database model (Fischer, 2014).

3.4. Data modeling

A data model defines the structure and meaning of data and address the properties related to the definition of data. Data models support data and computer systems by providing the definition and format of data. Data models will normally consist of entity types, attributes, relationships, integrity rules, and the definitions of those objects (West & Fowler, 1999).

The literature discusses many kinds of database modeling languages, like Object-Role Modeling (ORM). During the overall research Fischer will be applying the ORM language and method to create a database model (see section 2.1.2).

ORM is a powerful language and method for designing a database model at conceptual level and over the last few years, ORM has become the most popular fact-oriented approach when it comes the data modeling (Halpin & Bloesch, 1998) (Halpin & Morgan, 2008). ORM simply uses objects (entities and values) that play roles (parts in relationships) to picture the world.

Another advantage of ORM over other approaches is the preciseness, expressiveness and validation it offers as an audit function. ORM allows the designer to develop a DBM in a unique language which is easy to validate, which is a huge benefit within this research.

For further information on data modeling and ORM, see the research paper of the second part of the overall research (Fischer, 2014).

4. Methodology

The regulative cycle can be alternated, during the design research, as some phases are not applicable (Balsters, 2013). During the overall research, the regulative cycle (van Strien, 1997)

(15)

design method

will be applied and alternated, as the implementation phase is not part of the research scope. The three parts of the research entail the following phases, as shown in Figure 4.1.

Part 3: Validation of data models and FB-BPM method

Part 2: Development of data models Part 1: Development of process models

Design Problem

Validation

Diagnosis/

Analysis Design Solution

Implementation

Figure 4.1 - Applied alternated regulative cycle

The design solution will be validated directly after the design solutions, which in this research are the data models, based on the process models. After the validation the feedback loop can be applied as input for the design problem and the sequential phases, as well as the design solution phase.

Since this paper focuses on the third part of the research, the questions related to the valuation according to van Strien (1997), will be embedded in this paper. Within requirements engineering the validation of the designed DBM, the methodology for validation will be developed and identified.

4.1. Methodology validation of the models

(16)

design method

16

4.1.1. Validation questions embedment and implementation

Not all of the validation questions from section 3.1 are answered at the end of this research, since the validation involves mockups, but not an actual to-be EHR system, therefore the actual system cannot be tested on scalability and performance, which are the third and fourth validation questions.

The first, second and fifth questions are answered during the validation interviews during step 3 (section 4.2.3), since end-users, each with their own goals are involved. Since the process model is designed according to the stakeholders and their CSF’s, the validation also includes the CSF’s identified by Hoekstra (2014). When the end-users confirm the models, the CSF’s are met. For an overview of the CSF’s see Appendix II.

By using the proposed validation methods, the first validation question is covered. If the mockups are (more than) sufficient, the method and the mockups have met all of the critical success factors. Also, the third step of the methodology could encounter new critical success factors. Once they are encountered, it is possible that they are or are not met. If they are not met, they will be looped back (see section 4.2.4).

4.2. Validation approach part 3 of the overall research

The third part starts when then the first part of the overall research is set into motion. During the first part the critical success factors are identified by the researcher Hoekstra. These critical success factors are used later on in this validation research. The critical success factors are presented by creating UI-mockups (see section 4.2) which will represent not only the critical success factors but also the data models, in a visual form.

It should be noted that the steps are repeated every time new input is available, provided by the other two researchers. As discussed earlier, the input will not be provided at the end, but every time new correct input according to the designers is available for the third part of the validation research.

(17)

design method

validating the premature DBM, the modelers could work-out kinks earlier in the process, making the end DBM more complete and correct.

4.2.1. Step 1: Receiving and interpreting the process and data models

Once there is input available from (one of) the other two researchers, the third part of the research is set in motion, by interpreting the information that is presented will be used to create UI-mockups, in the next step. This step also implies making rules for making UI-mockups based on the models. This is a necessity, since these rules prevent errors and makes the UI-mockups design method and thus the validations, more reliable and legit

4.2.2. Step 2: Translate step 1 into UI-mockups using Microsoft Access

Every time additional input is available, the previously created UI-mockups need to be improved or extended, to fit the additional information and to design an up-to-date UI. These mockups will be designed using a database tool, called Microsoft Access. This is a database designing software, which can provide a clear overview of the UI-mockups. Furthermore, Access was also successfully used by Hijlkema (2013) when testing the FB-BPM method in the local hospital.

4.2.3. Step 3: Validation of the models

When the UI-mockups are designed, they will be presented to the end-users which have been identified in the first part of the overall research. The end-users will be interviewed, which provides feedback for the previous two parts of the research. The validation of the DBM also implies a validation of the process models and the validation of FB-BPM (see section 2.1). The process (model) is validated by presenting the flow of the UI-mockups, whereas the structure and content of the UI-mockups validate the database (models). Appendix III provides examples of the process and the database models validation-approach, using UI-mockups. If the end-users validate the mockups, it implies that database model, process model and the FB-BPM method is validated.

Step three will also be referred to as the ‘validation-interviews’

4.2.4. Step 3A (optional): Looping the obtained feedback

(18)

design method

18

feedback implies adjustment on the database models the feedback is looped to the second part. When the process and data models are improved, the input triggers step 1 and 2 of this research, to adjust the screens to the improved process and data models. This process is repeated until the model is successfully validated by the end-users. The feedback is analyzed and the root cause of the occurred flaw is identified. The flaw can be caused by the method or by the application of the system. The first indicates a necessary adjustment of the method, whereas the latter one does not, as the root cause is not within the system.

If no feedback is received that indicates an adjustment requirement for the data model, step 3A is ignored, which automatically triggers step 4, completing the first validation step.

4.2.5. Step 4: Second validation; comparing the data model to the TBGM

As a final validation step, the designed data model by Fischer (2014) will be validated a second time, by comparing the model with the TBGM. The second validation is to identify errors, which cannot be identified using the UI-mockups. Since the end-users already validated the data model, it is not likely to find any required adjustments for the models at this point.

This validation does not only validate the database and the FB-BPM method, it also validated the TBGM. When the TBGM and the ORM designed database show a significant resemblance the models are both validated, to the extent that entail the same data, but are created using different methods.

At the end of this validation, a list of pros and cons can be designed, identifying the applicability of this method for EHR systems in this environment (see section 5).

Step four will also be referred to as ‘validation-comparison’.

4.2.6. Step 4A (optional): Looping the obtained feedback (final validation)

(19)

design method

Part 3: Validation of the process models, data models and the FB-BPM method

Part 2: Developing the data models Step 1: Receiving and interpreting the process and database models Step 2: Translating step 1 into UI-mockups using Microsoft Access Step 3: Validation of the process and

data models Step 4: Second validation, comparing data model to the TBGM Part 1: Developing the

process models

Step 3A (optional): Looping the feedback of the validation

Step 4A (optional): Looping the obtained feedback (2nd validation)

Figure 4.2 - Methodology overview

In this research, the validation-interviews and validation-comparison aim to confirm the validity of the database model development based on process driven database modeling. This confirmation also implies a contribution to the validation of the overall use of FB-BPM in this type of applications.

5. Results

After completing the first two steps of this research (see Appendix IV), the following section will focus on the results of steps 3 and 4. Section 5.2 will represent the results of step 3 and section 5.3 will focus on the 4th step.

5.1. Step 1 and 2: Creation of the UI-mockups

5.1.1. Implications of the BPMN for the UI

(20)

design method

20 Figure 5.1 - Simplified example of used BPMN elements

1. Start-point (e.g.: of the triage process): Start of the process

2. Type-I tasks: Requires actions/input from user, which results in new data/input for the database

3. Type-II tasks: Requires actions from user, which does not result in new input/data from the user, so no influence on the database,

4. Type-I gateways: Interpretation of the inputs, using a defined set of roles, which are part of the database and executed by the system, which influence the process route.

5. Type-II gateways: Interpretation of the inputs, using a defined set of roles, which are not part of the database or the UI-mockups and executed by the user, which influence the process route.

6. Data objects: Transfer of external data from/to system, 7. End-points (e.g.: of the triage process): End of the process.

(21)

design method

and the process, since these tasks do not entail new data-input. A type-II task implies a single UI-screen, and can therefore not be combined, in any way.

The BPMN exception-rule for combining to one screen, is that the involved tasks cannot have multiple inputs. This is an exception, because different inputs for a task, implies that multiple process routes come together to one task/screen. However, this exception-rule can be ignored, when the multiple inputs are input from a type-II task. Ignoring this exception-rule makes sense, since the type-II tasks do not automatically imply a different process route, with different data input.

The end-point of the process in this BPMN is not data driven, but is translated as a UI-screen, as it is output of the previous task and represents a text, indicating the end of the process, for the referral.

The other elements are not represented as screens in the UI-mockups. A type-I gateway decision is executed by the system, which requires user input. In fact, the input of the user (and system) determines the output of the gateway, which is represented in the UI-mockups. Type-II gateways are not represented in the UI’s at all, since these decisions are made by the user outside of the system and not by the system. In this BPMN there are only two of type-II gateway:”referral in process?(yes/no)” and “Employee … logged in?” which the user determines (after a successful login) by looking at the current screenshot. The start-point of this process starts outside of the EHR-system and thus had no UI-screen. After the first login of the “healthcare administration port-specialism” the referral can be entered in the EHR-system. The “data object” elements are information that is send to or received from an external source of the system (e.g.: patient or referrer). They do not represent screens in the UI, but are translated inside of the screens by text (when it is output of the EHR system) or data (when it is input for the system).

Examples of these rules and implications of the BPMN translations for the UI-mockups are provided in Appendix V.

5.1.2. Implications of the ORM for the UI

(22)

design method

22

there are elements which have less influence on the UI. The elements which are relevant are only those that the user gets to “see” from the system, e.g.: input fields. The aspects which the UI does not cover are validated at step 4 (see section 5.3).

The database created by Fischer (2014) in ORM consists of object types (entity and value types), fact types (predicates, roles), constrains, relationships and combinations of these (Halpin 2005, Halpin, 2009) See Figure 5.2.

Figure 5.2 - Graphical symbols of the ORM 2 Notation (Halpin, 2005)

1- Entity type (e.g. person) (depicted by rounded square); 2- Value type (e.g. name) (depicted by dotted rounded square); 5- Entity type, displayed in multiple places (depicted by shade);

6- (Unary) predicament (e.g. person enters) (depicted by (single) small rectangle, with description);

13- Fact type is derived and stored (depicted by double stars);

15- Internal uniqueness constraint (depicted by thin purple line above a predicament); 26- Subset constraint.

These symbols, combined with the symbols of Figure 5.3 and the second set of Figure 5.5, are used in the in ORM designed database model. For this research and creating UI-mockups, the important elements of the ORM are the input of the end-user, which are value types in ORM. The other elements of the database are strictly relevant for the system and the database, and not represented in the UI.

(23)

design method

Figure 5.3 – Examples of: No constraints, mandatory constraints and value constraints (M, F) (in ORM) (Halpin, 2005; Halpin, 2009)

These user-input constraints are relevant for the UI, as it could constraint the user when input is required.

Figure 5.4 – Examples of: No constraints, mandatory constraints and value constraints (in UI)

The format of the input is also traceable in the ORM called the ‘reference mode’, e.g. denoted as “.number”, which indicates the input consists of numbers only. This is not directly visible in the UI, since it is a mockup, but is usually identifiable by the input description (e.g.: input “telephone number”).

The BPMN elements which are relevant for the DBM are traceable in ORM (e.g. Figure 5.5). Every entity type which is “followed by” another is a representation of a BPMN element (entity type) with a connector (“followed by”). Using this rule with the BPMN-rules, entity types can be linked to the correct screen. The input for the DBM is identified by a value type. These values are system or user driven.

(24)

design method

24

Figure 5.5 - Gateway in: BPMN, ORM and UI (Hoekstra, 2014; Fischer, 2014)

Another addition to the screens is a button, indicating the “finalization” of the purpose of the screen. In case of a gateway, the user gets two options (see Figure 5.5). By pressing the button, the user goes to the next screen in the EHR-system, but since these are mockups, the next screen is presented by the researcher during the validation.

An interpretation of the screen’s purpose according to the BPMN and the ORM, indicates the screen title.

Examples of these implications of the ORM translations for the UI-mockups are provided in Appendix V.

5.2. Step 3: Validation of the process and data models (validation of the UI-mockups)

(25)

design method Table 5.1 – Feedback of the validation overview with end-users

Sheet Feedback on process Feedback on DBM Feedback on UI only

4 Referral and attachment should be auto numbers

4 Link referral and attachments

19 Contacting the referrer twice on same issue: missing information

26 GP data is filled in automatic, after entering the name and residence

30 Referral reason is missing

31

Clinical yes/no might be redundant; “Clinical internal yes/no” missing

39, 52, 94

“Determiner (sub-)

specialism” is redundant, but not in DBM

43/44 “Link attachments” should be “link additional attachments”, since

the attachments should are linked early in the process (sheet 4)

52A Multiple input for

“Additional research” should be available

60 Unclear what “specialism required” is;

Referrer should be filled in already (not mandatory)

95A Redundant, since the doctor does not need authorization

The feedback received in step 3 triggers step 3A, and thus the feedback is looped back to the researchers Hoekstra and Fischer.

The feedback received from the interviews, indicates that in the UI’s where not flawless during the validation interviews. It is of importance to identify whether the root cause of these flaws is the method itself, or the method appliance, which determines if the method needs improvement or not.

(26)

design method

26

all of the feedback received, was an application flaw from the method and not a flaw caused by the method itself.

The “issues” on sheet 19 and 30 are disregarded, since it is solved, without adjusting either the process, database or mockups. These issues are solved after a more thorough examination and explanation of the content. The issue of sheet 30 is resolved, because of the fact that the “referral reason” is already on the referral.

The other feedback implies a need for change in the process, database models and/or mockups, and thus the mockups need improvement, to the end-users’ requirements. The UI-mockups which are affected by this feedback are presented in Appendix VII, including their adjustments. The adjustments are part of step 3A, which indicates following steps 1, 2 and 3 again, concerning the received feedback, as the models are adjusted.

After adjusting these specific sheets in the UI-mockups according to the received feedback, the mockups are again presented to the involved stakeholders, to validate the improved versions. The second time the mockups are presented, the flow, the structure of the UI is validated, and therefore the models and method are validated.

5.3. Step 4: Second validation, comparing the data model to the TBGM To further validate the FB-BPM model and method, the database is compared to the TBGM, (see Appendix IX) LTHN’s cluster database model. Comparing the ORM database with the TBGM is conducted with the support of two experts on the TBGM. During this comparison four immediate issues occurred, as the databases are not so easily compared to one another. Not only does this compare the ORM designed database, by also the TBGM database, since the two different approaches with the same results indicate validation.

First of all, the language was not only different in official language (i.e.: Dutch and English), but most of all in terms of used jargon. A patient in the ORM is a person in the TBGM, but a person in the TBGM is not necessary a patient as for instance an employee is also a person. Also, the interpretation of each element causes difficulties, as one element entails other properties then others

(27)

design method

aspects, which are not triage process related (e.g.: pay-role aspects). This issue causes the TBGM to have more triage irrelevant information than the ORM database, indicating that the ORM is less complete by default. Therefore comparing which aspects are missing in the ORM does not result in an invalidation of the designed database. The ORM can, however be tested by checking if the TBGM is missing aspects, that the ORM covers but not vice versa

A third issue for comparing the databases is the current state both of the databases are in. The ORM is basically a complete database for the triage process, but the TBGM is in a work-in-progress state. This indicates for obvious reasons that not all the database aspects are covered in the current TBGM yet. This being said, it is important to realize, that the database is not finished yet, as these aspects are possibly to be covered at a later moment. Therefore, missing aspects are not by definition a “missing” aspect, as it might be acknowledged future work.

The final main difference between the databases is the structure of the both databases, as the ORM is process driven and the TBGM is data driven. The attributes of the TBGM are differently grouped and linked to one another, compared to the ORM designed database. Since the ORM is process driven, the new data stored in the database is replaces the old data. For example, when a patient moves to a new address, the new address is stored in the database, replacing the old data. These comparison issues are reduced by identifying the process-driven database attributes and trying to identify these in the TBGM, as well. If they are found in the TBGM, they are relevant, if not, they are redundant or not yet entailed in the TBGM.

(28)

design method

28

5.4. The FB-BPM method for designing a to-be EHR-system

After the validation of the method and the models, the FB-BPM method is reviewed, for creating a to-be EHR-system. The research has led to a list of pros and cons which are depicted in Table 5.2. These pros and cons are identified by analyzing the results, in terms of advantages and disadvantages.

First of all, the method provides an audit function, since every process-driven action and data by the end-users is stored in the database. The method and database are based on the process, which results in data which can be “followed” through the process. This is an important aspect, since the EHR-system is very privacy-sensitive, since all of the personal, medical, patient data is stored into one database. Not only can the data be audited but the user as well.

Secondly, the method proves to be useful for this type of application, as long as the processes are structurally the same. In the case of the triage process, the research shows no signs of giving any problems to this extent with the three involved (sub-)specialism.

Also, as the LTHN concerns a large academic hospital environment, in which the validation took place, it is unlikely for smaller hospitals to have context related issues, which the LTHN does not face. Therefore the method can also be used for creating an EHR-system in smaller hospital environments.

As a final advantage of the method, the database is constructed from the patient on out. The patient (represented by the referral) gathers more and more data throughout the process, creating a more data rich body. This implies that all of the data is embedded in the patient/referral and thus keeps the data linked to one place.

(29)

design method

Table 5.2 - Pros and cons list for using the FB-BPM method for an EHR-system design method

Pros Cons

Audit function The triage process is complex, and thus takes time to design (process and database) models Usable for all users within the triage process,

as long as they have the same kind of processes Usable for smaller environments

Data is stored into one “body”( patient/referral)

6. Conclusion

In this research, the validation-interviews and validation comparison results confirm the validity of the database model development based on process driven database modeling. Based on the successful applications of the data modeling it contributes to the validation of the overall use of fact-based business process modeling in this type of applications as well.

As the results of the validation steps indicate, the UI-mockups have been validated. During the validation-interviews the end-users had some feedback remarks. These end-users’ feedback are identified as non-method related issues, which indicates the method is validated, by confirming both the process and database models. By comparing the designed ORM database model with the clustered TBGM database in terms of triage related attributes, the database model and FB-BPM method are validated a second time which in conclusion validates the method for creating an EHR-system.

The validation method proved to be suitable, as the ORM is mostly covered during the UI-mockup validation and comparison. Because the end-users have validated the UI-mockups, they there is no reason to assume that the validation did not cover all of the CSF’s nor any new CSF’s, which implies the validation questions are answered positive.

(30)

design method

30

7. Discussion

The validation of the process model, database model and the FB-BPM contains several limitations, which are discussed in this section.

First and foremost, the validation of the database model is limited to the aspects, that the UI-mockups represent and the comparison of the TBGM. This could result in the validation of only segments of the database model and not the entire database model. Aspects which are not taken in account could have been overlooked. However, the researcher does not expect any problems, since most of the database model is covered in the two validation methods, but still, this limitation should be taken in account. Moreover, since the TBGM consists of more data than just the EHR-database, the TBGM is not fully validated as it is validated to the extent of the data which the process-driven database entails. That being said, there is no result which implies that the TBGM is incorrect.

Secondly, the list of pros and cons might not cover the entire spectrum of the FB-BPM method’s positive and negative applications, with respect to creating an EHR-system. The presented aspects are the ones as a result of this research, but further research might suggest more positive and/or negative applications. Moreover, this research limits the pros and cons list for the method to designing a to-be EHR-system. Further research could result in more applications for using this FB-BPM method for creating database models.

Another limitation to the overall research is the scope. Boundaries had to be set, like any other research. Future research could involve a larger or different scope. The to-be EHR-system is not complete, as this research focuses on the triage, including setting an appointment with the patient. However, for the validation of the method for creating an EHR-system this scope is sufficient, as it validated by different stake-holders.

(31)

design method

Appendix I Project description

Theme: An Electronic Patient Record (EPR) system within the LTHN large teaching hospital in the Netherlands

Project: Validation of the logic business data model of the LTHN Supervisor: Dr. H. Balsters

Prerequisites: Systems design, Business modeling, Basic IT-skills (process- and data modeling, databases), affinity with engineering systems

Situation

At the LTHN (large teaching hospital in the Netherlands, a large migration project is in progress to replace the current Hospital Information System (HIS) with an advanced Electronic Patient Record (EPR) system. Currently it is being investigated how to migrate some fifty source databases into one central target database system. This central database is a prerequisite for an EPR system such as developed at the LTHN.

This migration process is an extremely complex operation; not only is the overall size of the source data involved overwhelming, but in the process one has to also figure out which source data is relevant to the target system, and subsequently one has to figure out how to integrate and map the source data to the target system in a consistent manner. In the source systems, data may be redundant with respect to the to-be designed target system; the data may also be incorrect or out of date. Hence the migration process also offers an opportunity to cleanse existing data. Since hospital-oriented systems also lay a huge emphasis on reliability and safety, such a migration process has to be managed in a controllable fashion, meaning that each step in the migration process has to be meticulously defined and validated.

In the migration process we distinguish functional aspects and technical aspects. Functional aspects concern the desired functionalities of the system, while technical aspects concern the implementation of the functional aspects into a technically working system. Our theme concerns the design of a logical and technical model based on process analyses to fulfill the functional needs of a patient admission process in a EPR system.

(32)

design method

32

for the relationships between the various business processes and information objects within a hospital environment. The LTHN has expressed the need to validate the correctness of the LBGM. In order to keep the scope of our validation project under control (our resources are limited: three students, simultaneously working within a period of three months), we shall confine the model to a part of the EHR system; those parts of the data model that are involved in the process of triage and routing of patients that are referred to the hospital for a specific medical problem.

Problem

Information about the patient is captured in so-called Hospital Information Systems (HIS). In order to cater to a hospital with a large diversity in users, a HIS tends to be very complex, even when one, for example, confines the system to, say, patient admittance within the hospital. These systems also deal with very privacy-sensitive medical patient data. As a result they are strictly locked-down to prevent unwanted leaks of these types of data.

(33)

(ISO-design method

) standard for modeling business processes. FBM stands for Fact-Based Modeling, and constitutes an ISO-standard for data modeling. In summary, we can state that our university wishes to investigate how data is currently entered and exchanged, what the requirements for an entry and exchange system are, and how to design a patient data entry and exchange system based on these requirements, resulting in a data model that could facilitate an EPR system. Once we have derived an FBM data model supporting patient admittance as part of the LTHN EPR, we can compare our FBM data model with the existing LBGM data model to validate correctness of (part of) the LBGM.

Project Description

Our research aims at solving the following question:

“How to validate the correctness of data models supporting an EPR?” This leads us to the following sub-questions:

What is the state of the art concerning the entry and exchange of medical patient data within the LTHN?

Who is currently entering and exchanging data, what data is entered and how is the data exchanged?

What are the constraints on patient data entry and exchange?

What are the requirements of a functional design of a LTHN EHR-system according the admittance process?

How can we code these requirements into a process model?

How can we systematically derive a data model from the process model?

How does the existing LBGM data model of the LTHN compare to our derived data model? Organization

(34)

design method

34

Appendix II

Identified stakeholders, critical success factors and

business requirements (Hoekstra, 2014)

For more details on the stakeholders, their CSF’s and requirements see the research paper of Hoekstra (2014).

Table II.1 - Indentified stakeholders triage process (Hoekstra, 2014)

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

Table II.2 - CSF's per stakeholder (Hoekstra, 2014)

Stakeholder Critical Success Factors

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

 The EHR-system must be able to extract information for the medical administration.

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.

(35)

design method Table II.3 - (Non-)Functional requirements per stakeholder (Hoekstra, 2014)

Stakeholder Functional and non-functional requirements

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

 The system shall do support the workflow of the triage procedure.  The system shall do support easy transfer and retrieval of patient data.  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.

(36)

design method

36

Appendix III Process and database validation examples

Process validation using UI-mockups example

Consider the following simplified process example: An end-user (a bank account card holder) wants to withdraw money from his/her account at an ATM.

At the starting point the end-user will enter his/her bank card after which the card is permitted or not permitted. When the card is permitted, the end-user is asked to enter his/her pin. Once the end-user entered the right pin (within three tries) he/she enters the preferred amount of money to withdraw and if the account has sufficient credit, that same account’s balance will change and the bank card is returned and the money is given, which concludes the transaction. Each process step can be translated to an UI-mockup sheet. The course of these sheets represents the process (see Figure III.1).

Correct and complete process (all the required process steps are correct, present and available)

User Interface sheet

1: Enter Card UI sheet 4: Pin correct

UI sheet 2: Card

permitted UI sheet 3: Enter pin

UI sheet 5: Enter amount of money to withdraw UI sheet 6: credit sufficient UI sheet 7: (balance

changed) Take out card UI sheet 8: Take out

money

Figure III.1 - Process example (correct and complete)

(37)

design method

Incomplete process (not all the required process steps are present and/or available)

User Interface sheet

1: Enter Card UI sheet 4: Pin correct

UI sheet 2: Card

permitted UI sheet 3: Enter pin

UI sheet 5: Enter amount of money to withdraw UI sheet 6: Credit sufficient UI sheet 7: (balance

changed) Take out card UI sheet 8: Take out

money

Figure III.2 - Process example (incomplete)

Database validation using UI-mockups example

When the structure of a UI-mockup is incorrect or incomplete, the database model is incorrect or incomplete.

Enter pin:

The local bank

Figure III.3 - UI-mockup example sheet 3 (correct and complete)

(38)

design method

38

Another error of an incorrect database/mockup occurs when for example, the name of the account holder is displayed on the third UI sheet, since the name of the account holder should be displayed on the second sheet (Figure III.4)

The local bank

Welcome mr. Doe

Enter pin:

Figure III.4 - UI-Mockup example sheet 3 (incorrect)

(39)

Appendix IV

Received Data: BPMN and ORM models

Received process models in BPMN

(40)

40 Figure IV.2 - Process model login process (A.) (Hoekstra, 2014)

(41)

Figure IV.4 - Process model login process (C.) (Hoekstra, 2014)

(42)

42 Received data models ORM

(43)

Figure IV.7 – DigiRefChck (Fischer, 2014)

(44)
(45)

Figure IV.10 – RefCoupl (Fischer, 2014)

(46)

46 Figure IV.12 – RefEval (Fischer, 2014)

(47)
(48)

48 Received relational database models in ORM

Figure IV.15 – Login (Fischer, 2014)

(49)
(50)
(51)
(52)
(53)

Figure IV.21 – RefEval (Fischer, 2014)

(54)
(55)

design method

Appendix V Examples of model interpretations and translations

Example of BPMN interpretation and translation

The following figures depict a part of the process in BPMN by Hoekstra (2014), which is translated to UI screens and flows.

Figure V.1 - Part of the process in BPMN, including the unfolded view of ‘login’ and ‘request missing data’ (Hoekstra, 2014)

This example depicts nearly all of the used elements, of which the BPMN is built, only a start- and end-point are missing.

When looking at Figure V.1, two new “elements” are presented, which in fact are no elements, but folded elements (i.e.: “A” and “E”). Looking at the rules, the flow and amount of screens can be determined. A step-by-step approach is provided, starting at “A. Login” on the left (Figure V.1). These screens are structured in the next stage, by interpreting and translating the ORM from Fischer (2014).

The login (A.) gives only one UI-screen, since it entails only one sequence of type-I tasks: “2. Insert username and password”.

(56)

design method

56

These two tasks imply the next two individual UI-mockups screens. The next element is a type-I gateway and implies no screen. Following the upper process route (“no” direction at gateway 8.) the next element is a type-I task (9.), followed by another type-I task (E.1.). These two tasks can be combined to one UI-screen, even though E.1. has multiple inputs, since the other input(s) are from a type-II task, which ignores the exception-rule. Just like before, a gateway implies no UI-screen, the login (A.2.) implies one screen as does the type-II task (E.3.). Type-II task “10.” results just like before in a single screen. The next two type-II tasks (11. and 12.) cannot be combined to one screen in the UI, since “12.” has multiple inputs. Therefore “11.” and “12.” imply two separate screens in the UI. Both the (receiving and send) data objects imply no screens for the UI.

The flow is not only decided by the tasks, but especially by the in- and output of the gateways, as it potentially changes the process flow. Depending on the output, the process remains on the happy flow/path (default scenario/flow, featuring no exceptional or error conditions) or not. The connectors (arrows) in the BPMN indicate the path of the process and thus the flow of the screens.

Conclusion BPMN interpretation and translation

The following elements provide screens within the UI (Table V.1) and have the following flow, with the green lines indicating the happy flow (Figure V.2):

Table V.1 - Overview of screens in UI

Screen 1 Screen 2 Screen 3 Screen 4 Screen 5 Screen 7 Screen 8 Screen 9 Screen 10 Yes Yes No No Screen 6 Yes No

Figure V.2 - Flow of the UI-screens

(57)

design method Example of ORM interpretation and translation

Identifying the relevant ORM part to the BPMN part is done by following the process with the ORM next to the process and relating the process, and the data needed for the relevant BPMN elements (see section Appendix V).

The database-model is process-driven, which makes the ORM traceable and linkable to the BPMN and vice versa. Considering the process flow of the BPMN, it starts with login and continues with the assess ability check, and ends with patient check.

Figure V.3 - ORM part corresponding with BPMN (login to referral assess ability check) (Fischer, 2014)

(58)

design method

58 Figure V.5 - Login in ORM (Fischer, 2014)

Looking at the first part of the selected ORM and BPMN, they start with login (see Figure V.3). The login in ORM is presented in Figure V.5 and requires a mandatory user entry of an username and a password. The screen’s purpose is to login, since it is a login screen, so this should be resembled in the title, as well as the button. Therefore at this stage the login screen is depicted as follows, based on the ORM:

Figure V.6 - UI-mockup screen (login) based on ORM and BPMN

(59)

design method

Figure V.7 - UI-mockup screen (referral selection) based on ORM and BPMN

The third screen of this part of the BPMN is the “Check if the referral is administrative assessable” screen (Figure V.8). According to the ORM, this screen indicates a discussion/gateway, which the BPMN confirms.

Figure V.8 - UI-mockup screen (Assessable check) based on ORM and BPMN

(60)

design method

60

Figure V.9 - UI-mockup screen (request missing info) based on ORM and BPMN

The fifth and sixth screens are the previously determined ‘login’ (Figure V.6) and ‘referral selection’ (Figure V.7) screens, as are screens seven and eight, respectively.

(61)

design method

Figure V.10 - UI-mockup screen (Register missing info) based on ORM and BPMN

Since the ORM is nearly the same, the screens are similar. Adding additional UI text and description in the next stage (see next section) the screen will have more context and make more sense.

The final screen, of this part of the BPMN and ORM, is the ‘patient check’ screen. This screen requires three user inputs, which are all mandatory; date of birth, surname and gender. Gender has a value constraint ‘m/f’ for male or female. This implies the next content/structure of the screen, based on the ORM (Figure V.11).

Referenties

GERELATEERDE DOCUMENTEN

databases maar wat nu indien je het programma PHP wilt behouden en een andere database engine

• The final author version and the galley proof are versions of the publication after peer review.. • The final published version features the final layout of the paper including

In this paper the effect of input band width on column efficiency and minimum detectable concentration is studied for two sampling systems suitable for high speed

Next, after describing the corresponding centralized problems of the different SP tasks, we rely on compressive linear estimation techniques to design a distributed MDMT-based

“In the new EHR system we build a sociotechnical system with specifications validated by the end users to attain an information system in order to support the end user when needed.”

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

We consider how scholarship and artistic practice entangle: scholars attempt to document and research a field, and artists interrogate the database structure in

gegevens die dit archief bevat zouden een goede basis kunnen vormen voor een streekroman, of een. verhandeling over de industrieële ontwikkeling, en het in- vesteringsklimaat in