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
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.
design method
Table of Contents
Abstract ... 2 Preface... 5 1. Introduction ... 5 2. Research questions ... 6 2.1. Research background ...62.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
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
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.
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
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
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?
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
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
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?
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
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.
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)
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
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.
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
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)
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
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.
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
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.
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.
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)
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.
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
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.
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.
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.
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.
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.
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.
(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
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.
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.
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)
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)
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)
Appendix IV
Received Data: BPMN and ORM models
Received process models in BPMN
40 Figure IV.2 - Process model login process (A.) (Hoekstra, 2014)
Figure IV.4 - Process model login process (C.) (Hoekstra, 2014)
42 Received data models ORM
Figure IV.7 – DigiRefChck (Fischer, 2014)
Figure IV.10 – RefCoupl (Fischer, 2014)
46 Figure IV.12 – RefEval (Fischer, 2014)
48 Received relational database models in ORM
Figure IV.15 – Login (Fischer, 2014)
Figure IV.21 – RefEval (Fischer, 2014)
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”.
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
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)
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
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
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.
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).