EPR EXCHANGE SYSTEMS: DEVELOPMENT OF A CONCEPTUAL DATABASE MODEL USING DESIGN SCIENCE

EPR EXCHANGE SYSTEMS: DEVELOPMENT OF A CONCEPTUAL DATABASE MODEL USING DESIGN SCIENCE

Research proposal master thesis, MSc Technology and Operations Management University of Groningen, Faculty of Economics and Business

June 21, 2013

STEFAN ALEXANDER POST Student number: 2066610 email: s.a.post.1@student.rug.nl

Supervisor/ university Dr. H. Balsters Co-assessor/ university

Dr. ir. D.J. van der Zee

Supervisor/ field of study Dr. M. van der Linde

Nij Smellinghe Hospital Drachten, Dutch Association for Cardiology

EPR EXCHANGE SYSTEMS: DEVELOPMENT OF A CONCEPTUAL DATABASE MODEL USING DESIGN SCIENCE

Abstract For sixteen years it has been attempted to establish an electronic patient

record (EPR) exchange system in the Netherlands. However, currently developed systems fall

short in at least three aspects: privacy assurance, scalability and suitability regarding

healthcare providers’ workflows. Business requirements have previously been insufficiently

addressed. Meanwhile the need for an EPR exchange system has not diminished; legislation

and the current political climate forces hospitals to centralize treatments and exchange

greater volumes of information. This research is part of a larger project that systematically

analyses the issue from a business point of view. The eventual aim is to provide a proof-of-

concept for an EPR exchange system design that can be implemented on a national scale, in

the Netherlands. As part of the project, this research presents conceptual database models

that enable the exchange of EPR according to business processes as described by domain

experts.

TABLE OF CONTENTS

1 Introduction ... 1

2 Literature review ... 2

2.1 Why do we need a HCII? ... 3

2.2 Legislation and standards ... 4

2.3 Requirements ... 6

3 Methods ... 6

3.1 Type of research ... 7

3.2 Research framework ... 7

3.3 Multi-stage project ... 9

3.4 Data gathering & analysis ... 9

3.5 Database model and specification method ... 10

3.6 Evaluation ... 11

4 Results ... 13

4.1 Reading ORM ... 14

4.2 Information retrieval ... 17

4.3 Person ... 18

4.4 Login ... 19

4.5 Read permission verification ... 20

4.6 Patient registration ... 22

4.7 Relational view, verbalization and verification ... 22

5 Discussion ... 23

6 Conclusion ... 25

7 References ... 25

Appendix I: Stakeholder analysis and CSFs ... 30

Appendix II: Patient Data Exchange Systems within Regional Hospitals (TOM) ... 35

Appendix III: Theme Poster on Patient Data Exchange Systems ... 37

Appendix IV: ORM model change-log ... 39

Appendix V: ORM model evaluation form ... 49

Appendix VI: BPMN models ... 54

Appendix VII: Relational view of the ORM model ... 57

Appendix VIII: Evaluation results ... 58

1 INTRODUCTION

In the past decades the Dutch healthcare sector has been subject to structural changes and new legislation. There is a general political agenda to push for centralization of healthcare, and volume norms for complex care have been put into effect. The resulting exchange of patients between healthcare providers creates an urgent need to exchange patient data effectively and efficiently. In response the Dutch government, health insurance providers and other stakeholders have made efforts to develop an electronic patient record (EPR) as a cornerstone of a national healthcare information infrastructure (HCII). The goal of this HCII is relatively simple: we would like to be able to transfer correct patient records, to any desired recipient, at any time.

Through legislation and under the threat to be cut off from funding, healthcare providers are forced to centralize and adopt electronic patient record exchange systems (EPRES). However, the current EPR and related exchange systems leave much to be desired.

The EPR has been subject to criticism by the general public as well as experts; in 2012 alone nearly four hundred

Dutch newspaper articles included references to the EPR. Previously the issue of developing an EPRES has often been approached from a solution driven perspective (i.e. the potential of IT). And to their credit, EPRES systems that have been developed can be considered a technological success. Strategically however, the development projects have failed (Van Twist et al., 2012). Current systems fail to meet the business needs in primarily three aspects: failing to ensure privacy, a lack of scalability and a mismatch between the operation of the developed systems and healthcare providers’

workflows. The privacy issues are the most hotly debated, as a natural result from the fact that the concerned stakeholder group, the patients, is by far the largest. Accessibility of patient data, electronic data security and legislation are of primary concern. Current solutions also seem to be lacking in scalability; while present solutions are sufficient for the exchange of EPR between two or three healthcare institutions, they are unsuitable for implementation on a national scale. Finally, healthcare providers, i.e. the users of the developed systems, feel they were not given enough opportunity to contribute to the development process and as a result they are given a tool that does not fit in their workflow and working environment. As such stakeholders have indicated that the business requirements were not given due consideration during the development of EPRES.

Rather than to continue along the beaten path, this research is part of a larger project which systematically analyses the issue of developing an EPRES using design science, starting from a business perspective. This system can then later be used to support a larger HCII. The

1 A search on LexisNexis Academic for articles in Dutch newspapers including the keywords “elektronisch patiëntendossier OR EPD OR zorginfrastructuur” published between 1-1-2012 and 1-1-2013 yielded 387 unique articles.

aim of the project is to capture the business requirements and produce conceptual models of a suitable EPRES. At the very least, these conceptual models will address the current problems concerning privacy, scalability and workflow.

Due to the scope and limited resources available, the project has been divided into three stages. The first stage is performed by Stephana (2013), in which functional requirements are inventoried and captured in business process models using Business Process Modelling Notation (BPMN). The research before you encompasses the second stage, in which the BPMN models are systematically translated into conceptual database models using ORM (Object-Role Modelling) techniques. The conceptual database models serve as blueprints for a technical database design realized in the third stage, which is performed by Hijlkema (2013) and which emphasizes on technical rather than functional requirements. The content of the various stages is further elaborated in section 3.3.

Unfortunately because of the limited time available a fully functional working prototype could not be realized. However, the final design offers the functionality required to enable the process of data retrieval, as part of EPR exchange processes in the business environment.

The general research question driving the project is: ‘What are the business requirements for an EPRES?’ The question which this research addresses is a related sub question, namely: ‘What information is minimally required for the operation of an EPRES within the business environment?’ In answering these questions and through the development of a conceptual EPRES design, we also hope to contribute to the general body of literature on EPR and HCII systems and provide new insights.

The remainder of this paper is structured as follows: chapter 2 will describe the background of the EPR/HCII and surrounding problem; chapter 3 will discuss the methodology, encompassing research approach, scope, data collection and analysis tools;

chapter 4 explains the model and result of this research; while section 5 provides further discussion; Chapter 6 finishes up with the conclusion.

2 LITERATURE REVIEW

For any development project the questions why, how and what should be central.

‘Why’ a HCII is desired is already known, but fundamentally important and will be discussed

in paragraph 2.1. Furthermore, there are some known aspects on ‘how’ we would like to

exchange patient records; previous research holds some indication, certain laws are

applicable and a consensus has been reached to apply two interoperability standards. These

will be the focus of paragraph 2.2. The final paragraph of this section focuses on what is

currently missing and is used to provide some direction for the start of this project.

2.1 Why do we need a HCII?

As previously indicated, the healthcare sector in the Netherlands has been subject to structural changes. One of these changes is the implementation of ‘shared care’. Shared care implies that patients’ treatments are divided into stages, each performed by different health-care providers. Additionally, volume norms aimed at centralization of complex care have been introduced to force hospitals to specialize in some treatments, while discarding the availability of other treatments. Hospitals that fail to adhere to these demands have been forced to close. International studies have pointed out that centralization of complex treatments can yield more efficiency medical care (Forshaw et al., 2006) and reduced mortality rates (Al-Sarira et al., 2007; Langer, 2007; Stitzenberg, Sigurdson, Egleston, Starkey,

& Meropol, 2009; van Heek et al., 2005). While government initiatives clearly show a desire for centralized healthcare (Borst Eilers, 1996; van Twist et al., 2012), a 2005 study by van Heek and colleagues indicated that centralization in the Netherlands is not as developed compared to some other countries. A key reason behind this fact was indicated to be the lack of public awareness on the benefits of centralized care (Van Heek et al., 2005).

Regardless, despite the benefits of centralization it is not without cost: patients will have to travel more often as well as further (Stitzenberg et al., 2009) and, of importance to this research, it brings the need for a new patient record exchange system or HCII.

In 1996 the Dutch minister Borst-Eilers of Health, Welfare and Sports first introduced the use of an EPR as a cornerstone of the new infrastructure to be developed (Borst Eilers, 1996). However, the introduction of exchange systems has only seen success in small scale implementations (Van Twist et al., 2012) and the implementation of a national EPR exchange system in the Netherlands remains a hotly debated topic to this day. Privacy concerns, contradicting views on what the EPR is and what the EPR is not and who the owner of the EPR should be, resulted in the rejection of a bill to implement the national EPR exchange system by the senate in April 2011.

Though formal regulation has previously been rejected and national implementation is

yet to be successful, practitioners are still confronted with the same circumstances: they are

forced to specialize and thus have a need to exchange information. While the senate has

requested the ministry of Health, Welfare and Sports to withdraw from involvement with

the HCII, healthcare providers have taken it upon themselves to continue development of an

information infrastructure. For this purpose, they have founded the Association of

Healthcare providers for Healthcare communication, the VZVZ. (In Dutch: Vereniging van

Zorgaanbieders voor Zorgcommunicatie). Since January 2012, the VZVZ is legally held

responsible for the exchange of all patient data through the HCII (Nictiz, 2013a). Currently,

stakeholders including the current Dutch minister Schippers of Health, Welfare and Sports,

still wish to see the improvement in current solutions and the successful implementation of

a national HCII. As minister Schippers put it, “We currently have a tilt-cart, I hope to proceed towards an Opel and someday to end with a Rolls Royce.” (Redactie Volkskrant, 2012)

2.2 Legislation and standards

While the realization of a national HCII has yet to be accomplished, since 1996 some advances have been made that assist in converging to a solution. While stakeholders may disagree about the form and implementation of the HCII, consensus has been reached on some matters concerning privacy, legislation and interoperability.

Given the environment in which the HCII is implemented, it is subject to previously established legislation. For starters, it should adhere to Art 7:446 up to and including 7:468 BW; ‘Law concerning agreement on medical treatment’. (In Dutch: ‘Wet op de geneeskundige behandelingsovereenkomst’, WGBO). Notably Art 7:448 section 3 BW and 7:454 up to and including 7:458 BW, specifically apply to patient records in general and Art 7:457 section 2 and 7:458 BW are especially relevant for the transfer of patient records as can be expected to be performed in the context of an EPRES (Ministerie van Veiligheid en Justitie, 2013). In the more general context of handling personal and identifiable data, Art 10 of the Dutch constitution and the Data Protection Act (Wbp) also apply. More recently, and to benefit of exchanging EPR in the healthcare sector, in April 2008 the ‘Use of the social security number in healthcare act’ came into effect. (In Dutch: ‘Wet gebruik burgerservicenummer in de zorg’.) This made it easier to identify and relate EPR of a patient across multiple systems and assist in integrating health records. Finally, while not yet part of formal legislation, the VZVZ enforces that patient records are allowed to be exchanged through the HCII only if, a patient has explicitly given consent to make his or her records available to the EPRES (Nictiz, 2013b).

As a means of ensuring patient confidentiality and privacy from a technical perspective, a number of standards concerning data security have also been agreed upon and modified for use in the healthcare sector. These include the original standard NEN 7510, as well as custom developed and healthcare specific standards NEN 7511, 7512 and 7513; all which relate to the personal data security and access logging of EPRES.

In addition to privacy and legislative concerns, an EPRES is also subject to issues of interoperability. Within the healthcare sector however, many definitions of ‘interoperability’

exist. In their research Gibbons and colleagues (2007) identified one hundred definitions of

interoperability and categorized them into three types according to their focus: Definitions

concerning Technical Interoperability, which focuses mainly on the transfer and integrity of

electronic data and not its meaning, Semantic Interoperability which focuses on ensuring

that information is understood by the recipient in an exchange and Process/Social

Interoperability which focuses on the successful use of exchanged information. A definition

by Brown & Reynolds (2000) seems to cover all these aspects:

“Interoperability with regard to a specific task is said to exist between two applications when one application can accept data (including data in the form of a service request) from the other and perform the task in an appropriate and satisfactory manner (as judged by the user of the receiving system) without the need for extra operator intervention. The above definition implies the following:

The ability to communicate data (connectivity).

The data received by the receiving system is sufficient to perform the task and the meaning attached to each data item is the same as that understood by the creators and users of the sending and receiving systems

The task is performed to the satisfaction of the user of the receiving system.”

(Brown & Reynolds, 2000) As previous research has indicated, standards are a necessity for achieving interoperability in healthcare (Atalag, Kingsford, Paton, & Warren, 2010; Richesson &

Krischer, 2007). There are multiple standards available and adopted worldwide, with gaps and overlap between them. Comparative reviews of standards have not indicated any clear winner and the combined use of standards can result in better coverage of domain requirements. (Atalag et al., 2010; Eichelberg, Aden, Riesmeier, Dogac, & Laleci, 2005;

Richesson & Krischer, 2007). It was suggested by Eichelberg and colleagues (2005), that it could not be expected that institutions would universally accept a single standard, thus that EPR exchange and interoperability will only be possible at a semantic level.

It is fortunate then, that an agreement has been reached on a national level for the use of two standards in the Dutch healthcare sector. These two standards are IHE XDS (Integrating the Healthcare Enterprise, Cross-Enterprise Document Sharing) and HL7 v3 messaging with CDA r2 (Health Level Seven, Clinical Document Architecture). IHE XDS’

contribution to interoperability lies mostly in technical interoperability:

“Cross-Enterprise Document Sharing (XDS) is focused on providing a standards-based specification for managing the sharing of documents between any healthcare enterprise...

…this is managed through federated document repositories and a document registry to create a longitudinal record of information about a patient within a given clinical affinity domain.”

(IHE, 2011) The emphasis of HL7 CDA on the other hand emphasises more on resolving semantic interoperability:

“The HL7 Version 3 Clinical Document Architecture (CDA®) is a document markup standard

that specifies the structure and semantics of "clinical documents" for the purpose of exchange

between healthcare providers and patients. It defines a clinical document as having the

following six characteristics: 1) Persistence, 2) Stewardship, 3) Potential for authentication, 4) Context, 5) Wholeness and 6) Human readability.”

(Health Level Seven International, 2005) 2.3 Requirements

Achieving interoperability for a HCII, requires using a common EPRES architecture. The requirements for such an architecture “consist of both domain specific, somewhat technical functional requirements and non-functional requirements informed mostly by economic political and social health IT drivers.” (Atalag et al., 2010)

However there are also other requirements in addition to architectural requirements and compliance with the before mentioned legislation. Previous attempts at implementation of an EPRES in practice have been viewed with dissatisfaction. The users of the developed systems (i.e. healthcare providers) indicate that the capabilities and operation of such systems do not meet with the demands from practice and do not fit into their workflows.

The primary concern of healthcare providers is to practice medicine and treat patients. Their skill for utilizing computers varies greatly. While healthcare providers have the desire to exchange information, and they acknowledge the potential for IT solutions in this regard, they feel that their characteristics and requirements as target users were not given due consideration in the development process. Another general business requirement that is currently not addressed is the scalability of EPRES. Currently developed systems can work when they are implemented by a limited number of institutions to exchange patient records.

However, for each additional entity that joins the HCII, the overhead and system capacity requirements increase exponentially and are thus not suitable for implementation on a national scale. The result is a solution that as an artefact may be technically flawless, but fails in its practical application in the business environment; a perfect failure.

This mismatch between design and practice does not seem to be uncommon:

literature reveals a number of cases of IT implementations in healthcare, where the IT solution did not address the needs of practice (Buntin, Burke, Hoaglin, & Blumenthal, 2011;

Niazkhani, Pirnejad, van der Sijs, & Aarts, 2011; Ploem & Gevers, 2011; Wentzer, Böttger, &

Boye, 2007). More generally, causes of software development project failures can often be attributed to inadequate requirements planning (Dvir, Raz, & Shenhar, 2003; McConnel, 2004; S. Robertson & J. Robertson, 2006). Through recent case studies some of the previously neglected business requirements have been addressed and alternative solutions have been explored (Dijkstra, 2013; Haarsma, 2012; Kalmann, 2013; Wijma, 2013). However, domain experts have indicated that the work is inconclusive and demands further study.

3 METHODS

The previous chapter has pointed out that currently not all business requirements are

met by developed EPRES. While the matter of scalability is clear, problems that the users

experience are still to be investigated and clarified. Beyond that, there may be other business requirements that are currently unknown. One of the stakeholders, a cardiology department at the Nij Smellinghe Hospital Drachten (NSD) in the Netherlands, expressed the willingness to share domain knowledge with researchers. They would gladly help to provide insight in the business requirements, driven by the desire to develop a solution in a collaborative effort. As such, ideally the project should yield proof-of-concept of an EPRES design that satisfies all key stakeholders and their critical success factors (CSF’s). Due to limited resources available, the key stakeholders considered in this research are:

the users of the system (i.e. healthcare providers);

the developers of the system;

IT support staff, to be responsible in part for maintaining the system to be developed.

3.1 Type of research

The desired outcome of this research is to create utility rather than discover a truth. A HCII is desired by many stakeholders, but currently developed systems fall short. This indicates a practical-knowledge problem: there is a gap between the way stakeholders currently perceive the world, and the way they would like to perceive the world. Research that addresses practical-knowledge problems is commonly called design research.

In terms of general research type definitions gathered by Karllson (2009), this research could also be designated as action research: “Action research aims to contribute both to the practical concerns of people in an immediate problematic situation and to the goals of science by joint collaboration within a mutually acceptable ethical framework.” (Rapoport, 1970) The term action research is also used by Wieringa and Heerkens (2007), who describe a number of research methods used to perform requirements engineering research. The key characteristics that they attribute to action research are that the researcher is commonly responsible for the design of technology, the evaluation of the developed technology, the evaluation of the development techniques and possibly improving the design of these techniques.

3.2 Research framework

Solving practical problems is often considered applied science or engineering rather

than fundamental science because solutions to specific problems are not generally

applicable and do not contribute to theory. In order to introduce a scientific and

methodological rigor into a practical context Van Strien (1986; 1997) proposed the use of the

regulative cycle (Figure 1). The cycle consists of five stages, design problem,

diagnosis/analysis, design solution, validation and implementation, which can also be

divided into smaller parts.

The design problem phase answers the following questions:

1. Who are the stakeholders?

2. What are the goals for each stakeholder?

3. What are the Critical Success Factors (CSF) for each goal?

The Diagnosis/Analysis phase focuses on the following:

1. What are possible causes of the difficulty resolving a CSF?

2. What are the quality attributes of CSFs?

3. What are the CSF interdependencies?

Design solutions phase:

1. Which alternative solutions are available?

2. Can we assemble old solutions to build a new solution?

3. Can we invent a new solution completely from scratch?

The implementation phase should deliver an artefact, a man made construct, according to the designed solution. Finally the validation phase holds the following questions:

1. How to design test methods for each CSF?

2. Were all CSFs met?

3. Is there a trade-off between CSFs?

4. How scalable is the solution/implementation?

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

(H Balsters, 2012)

3.3 Multi-stage project

The scope of the project is quite ambitious; from requirements to implementation of a prototype. As mentioned in the introduction earlier, the workload is therefore distributed and the project is divided into multiple stages. The first stage is performed by Stephana (2013). In the first stage, the goals, functional CSFs and other functional business requirements are inventoried, and these are captured in business process models. During the second stage business process models are translated into a conceptual database model, offering the conceptual blueprint for a technical database design to be realized in stage three. The third stage is performed by Hijlkema (2013), who translates the conceptual database model into a technical database design, including SQL database structures. Part of this process is establishing technical CSFs and other technical requirements. In addition, Hijlkema has also created conceptual user interface designs, incorporating functionality necessary to support the business process, and finally provides suggestions on implementation of the EPRES.

As aforementioned, the scope of this research is limited to the second stage of the larger project. Since the second stage concerns itself with a direct translation of the business process models from the first stage, the activities regarding the establishment of stakeholders, CSFs and other requirements are not repeated here again. The stakeholder analysis from the first stage has been included in Appendix I: Stakeholder analysis and CSFs.

A reference for the original project outline and the different stages of the project can be found in Appendix II: Patient Data Exchange Systems within Regional Hospitals (TOM) and Appendix III: Theme Poster on Patient Data Exchange Systems. However, since the start of the project, it has become apparent that additional subsequent stages are necessary to address all the aspects of an EPRES, more on this will be discussed in chapter 5.

Due to the outcome dependencies of the different stages, the project as a whole will be performed in a collaborative and incremental fashion. Concepts and intermediate results are shared with researchers responsible for other stages, as well as stakeholders, to provide both early input and a means to verify intermediate results. This continuous processing and evaluation allows for greater responsiveness towards potential changes in the business environment, provides opportunity to spot problems early in the design process while they are still easily rectifiable.

3.4 Data gathering & analysis

A large part of the input for this research comes from the fruits of the first stage; the

business requirements as inventoried by Stephana (2013). The first stage provides the goals

and CSFs for each considered stakeholder, as well as give an indication of the quality

attributes and causes for difficulties to resolve CSFs. Other previously performed studies at

the NSD can also serve as input. These studies contribute the following: insight in the

workflow and current practices (Dijkstra, 2013; Haarsma, 2012); previously established

requirements (Dijkstra, 2013; Haarsma, 2012; Kalmann, 2013; Wijma, 2013); preliminary process designs (Dijkstra, 2013); preliminary database design solutions (Kalmann, 2013;

Wijma, 2013). It should be noted that with regard to requirements and business process designs, the work by Stephana is considered to be leading, as it contains corrections, as well as a refinement and expansion of previous work.

In addition to documented sources, domain experts are considered key sources of information. Their input is necessary to determine the quality attributes of CSFs and they provided insight into alternative solutions. The input from experts also served for clarification and verification of written facts and requirements. Finally, experts were consulted for evaluation of conceptual models as explained in section 3.6. The domain experts include: experts active in the environment where the EPRES is to be implemented (e.g. users and maintenance support); experts on database technology and an expert on software engineering. Data has been obtained by means of discussion of the business environment and concept models with the before mentioned experts, attendance of an internal presentation by EPR exchange solution providers, written correspondence and survey-style model reviews.

The need for input from domain experts is judged on a case by case basis. All received data is processed in the context of this research; that is to create a suitable and complete database model that fulfils all the CSFs. For this purpose, the analysis of the data should at least provide an answer to the central question ‘which information is minimally required for the operation of an EPRES within the business environment?’

3.5 Database model and specification method

There are several common modelling approaches that can be used to generate visual database specifications. The most commonly used are UML (Unified Modelling Language), Barker ER (Entity Relationship Modelling) and ORM (Object-role Modelling). While UML is a general software specification language, ORM and Barker ER are specifically developed for conceptual database modelling. Both Barker ER and ORM lend themselves to incrementally building database models, where ORM is the more recently developed modelling approach.

The modelling of features as attributes in Barker ER limits the constraints that can be

specified. In addition Barker ER also lacks support for advanced constraints found in ORM in

general (Halpin, 2004). Furthermore, ORM is a fact-based modelling language and is found to

be more expressive and offers greater clarity. This makes it easier to communicate database

models with domain experts. When comparing ORM to UML, UML representations are more

compact and UML is more widely adopted. However, as previously indicated UML is less

suitable for conceptual database modelling. Fortunately ORM can be used in conjunction

with UML and ORM models can be transformed into UML class diagrams (Halpin, 2000). A

recent article by Doesburg and Balsters (2012) presents an algorithm that enables such a

transformation.

A discussion with a modelling expert pointed out that a high dependency of current ORM tools on Microsoft Visual Studio is something organizations may prefer to avoid.

However when developing critical systems, large organizations such as the European Space Agency (ESA) and Boston Scientific have chosen to use ORM. Neither Barker ER nor UML is fact-based and are thus far harder to evaluate from a business perspective (H. Balsters, 2008; Halpin & Bloesch, 1999). The use of ORM over other methods yields practical benefits too; structured methods and tools are available to translate BPMN models to ORM models and to transform an ORM model into natural language texts. These attributes improve workflow and allow for greater ease of model validation by non-technical domain experts.

With regards to the regulative cycle, alternative models should be provided if possible, to allow for the exploration of multiple solutions during the design phase. The highly iterative character of the design process meant that solutions were created and discarded almost continuously. Each discussion and evaluation with both experts and other researchers brought about numerous changes and refinements that have been documented in a change-log found in Appendix IV: ORM model change-log. For reference purposes, previous iterations of the models are also stored in the original ‘.orm’ format and are available on request. The ORM models also serve as the artefact to be delivered and evaluated in this research.

3.6 Evaluation

Evaluation in this research is performed for both the input and output of the research, which are the business requirements and the resulting ORM models. Requirements specifications are the foundation in (software) product development, when the requirements are inadequate the consequences affect the remainder of the project (Brooks, 1987; Dvir et al., 2003; McConnel, 2004; S. Robertson & J. Robertson, 2006). Thus prior to their use for implementation, it is worthwhile to subject requirements specifications to verification (are they correct?) and validation (are they justifiable?). At present automated evaluation methods appear to be lacking. Works such as that of Durán and colleagues (2002) show that unambiguity and completeness are highly subjective knowledge properties that cannot be automatically evaluated. As such it is deemed most suitable that the evaluation of the requirement specifications is performed in collaboration with domain experts. The creation and evaluation of the requirements was performed in a number of steps and different forms, where the works of Sakthivel (1991), Walia & Carver (2009) and Robertson

& Robertson (2006) served to provide insights and guidance.

Initial requirements were gathered from previous research and interviews with

stakeholders. Following current trends, the requirements were then subjected to an

evaluation based on key performance indicators (KPI’s). What a product or process is

supposed to accomplish is the primary concern for establishing KPI’s (Beal, 2013; Kronz,

2006; Parker, 2012). In the given context of requirement specifications, KPI’s are thus established concerning:

1. Quantifiability – the quality of being measurable;

2. Feasibility - capable of being accomplished or brought about; possible, and used or dealt with successfully; suitable;

3. Accuracy – conformability to fact and precision;

4. Completeness – having all necessary or normal parts, components, or steps.

5. Ambiguity – the possibility of interpreting an expression in two or more distinct ways;

6. Validity – the quality of being purposeful, justifiable, well grounded.

KPI’s themselves should also be quantifiable in order to provide meaningful feedback and comparison. This was done by applying KPI’s in a form containing ‘Yes/No’ questions related to the requirements. For example: ‘is the requirement x quantifiable?’ Each requirement was individually assessed in a structured discussion. Every question answered with ‘No’ required the related requirement to be improved upon or in some cases discarded.

The requirements that had been improved were presented to domain experts for further evaluation and refinement as part of the first stage of the project. The resulting BPMN models that were used as input for ORM models were evaluated in a series of discussion with both domain experts and among researchers.

ORM models were evaluated in a slightly different fashion. Initial iterations of the models were checked against the BPMN models with the help of a modelling expert. For evaluation done by domain experts, the capability to systematically transform ORM models into natural language was used to make the models insightful for those unable to read ORM models. The textual description of the model in natural language consists of a number of fact statements and related constraints. Each statement and constraint was again checked using a number of KPI’s.

1. Feasibility - capable of being accomplished or brought about; possible, and used or dealt with successfully; suitable;

2. Accuracy – conformability to fact and precision;

3. Completeness – having all necessary or normal parts, components, or steps.

4. Ambiguity – the possibility of interpreting an expression in two or more distinct ways;

5. Validity – the quality of being purposeful, justifiable, well grounded.

Note that the factual nature of the statements inherently makes them measurable; a database implementation of the model either adheres to the fact statements or it does not.

The statements were incorporated in a survey style form as presented in Appendix V: ORM

model evaluation form. This has several advantages: 1. the structured form allowed

individual domain experts to evaluate the model in the same fashion and based on the same

criteria; 2. data could rapidly be aggregated and compared from multiple evaluations; 3.

evaluation results are stored in an accessible format for reference purposes. The evaluation form also includes a textual representation of the model described in chapter 4.

The evaluation form was send to three domain experts and three other project members that worked on the EPRES. The evaluation was performed by two project members and two domain experts; a specialist in hospital IT implementations and a hospital operations manager. The first evaluation performed by a domain expert led to some discussion about the conceptual design. This discussion provided more feedback than the responses filled out in the evaluation form. Domain experts indicated that the abstract nature of the fact statements in the form, made it difficult to interpret them without additional context and insight into the design of the EPRES. As such the researcher was present during the second evaluation performed by a domain expert, to provide context and describe the general model. As such the evaluation form was not used by domain experts as intended; namely to perform individual evaluations. However, it did allow a structured review of the model to ensure that every fact statement was addressed and nothing was overlooked.

4 RESULTS

The models produced by this research are a direct translation of the processes described in the BPMN models created by Stephana (2013), see Appendix VI: BPMN models.

Each process requires information that serves at input and produces an output. The input must be either entered by a user during the process or can be retrieved from existing data.

Establishing which input is required also answers the main research question of this paper, namely: ‘What information is minimally required for the operation of an EPRES within the business environment?’ The necessary input has been established through both discussion with domain experts and careful deductions about what is required to ensure functionality.

Stakeholders have expressed a desire for insight and accountability concerning the use and exchange of medical data. Therefore each action performed by a user is logged and the outputs of processes are recorded in appropriate tables. Furthermore, the outputs can be used as feedback for the user and can serve as input for consecutive processes.

The following sections will describe each process, the inputs and outputs and the

resulting database models. The processes are listed in a generally reverse-order,

emphasising the original goal of the EPRES: ‘To be able to transfer correct patient records, to

any desired recipient, at any time.’ This goal is accomplished when the recipient is able to

view information that is stored in the system.

4.1 Reading ORM

The development of ORM models takes place in seven steps laid out in the Conceptual Schema Design Procedure (CSDP), the first of which will be explained here to make the models displayed in later sections more insightful. The following is a short summary of the CSDP as laid out by Halpin & Morgan (2008).

The creation of an ORM model starts with establishing elementary facts. An elementary fact is a simple assertion, which cannot be split into smaller units of information.

These facts are statements that are deemed true by the users in the business environment.

Elementary facts assert that objects play roles. Objects can be values or entities. Values are constant and self-identifying. Entities can change over time and are referenced to in a database. Often entities are identified by means of an associated value.

To avoid ambiguities in the absence of context, all objects must be clearly identified by definite descriptions. This includes the indication of which type the object belongs to. A type is a set of all possible instances. ORM makes a distinction in the representation of value- types and entity-types as shown in Figure 2 and Figure 3

respectively. When referring to entities a reference mode should be provided to prevent ambiguity. Figure 4 shows a concise form of indicating a value-type in brackets as the reference mode for an entity. These can be general, popular (preceded by ‘.’) or a unit of measurement (followed by ‘:’).

The concise form is preferred unless the reference schemes are to be illustrated explicitly.

Most entity designators have three components:

Entity type (e.g., Person, Age)

Reference mode (e.g., surname, years) Value (e.g., Doe, 22)

An elementary fact also includes a role which the objects play. To continue with the use of Person and Age as object types we could formulate the following elementary fact:

‘Person has Age’. The visual representation of this statement in ORM is shown in Figure 5.

Figure 5 a basic elementary fact in ORM

If reference modes are added, one ends up with ‘The Person with surname Doe has Age 22 years since day of birth.’ Figure 6 and Figure 7 show the concise and expanded ORM representation including reference modes respectively.

Figure 2 ORM representation of a value type

Figure 3 ORM representation of an entity type

Figure 4 concise form of entity type references

Figure 6 an elementary fact including concise reference modes

Figure 7 expansion of the reference modes model including, with explicitly indicated value-types

Note that the general reading direction of predicate text (e.g. is identified with, identifies) is generally read from left to right and top to bottom. Inverse readings are separated by a ‘/’.

After the visual representations of facts are created the next step of the CSDP is trimming the model and combining entity-types where possible. An understanding of this process is not required in order to read the model and therefore the explanation of this step is omitted. However, part of the trimming process involves establishing subtypes which are worth addressing. Subtypes that share a common supertype have similar characteristics but also possess some distinct characteristics. They can be overlapping or mutually exclusive.

E.g. a person or a city are both entities-types that can be referred to with a name but are mutually exclusive, women and managers are both people and can overlap. In ORM subtypes are indicated by means of an arrow pointing towards the supertype as shown in Figure 8.

Figure 8 ORM representation of super and subtypes. Arrows point from the subtype towards the super type.

The fourth step of the CSDP involves applying uniqueness constraints as they are derived from reality. Since only binary facts involving to two objects are present in the EPRES conceptual database models, the explanation will be limited to applying uniqueness constraints to a binary fact. Uniqueness constraints limit the possible populations. For those familiar with Barker ER, Table 1 shows both the ORM and Barker ER visual representation of basic constraints.

The last CSDP step discussed in this short overview is the application of mandatory constraints. When a role is mandatory this is indicated by a dot ‘●’. Table 2 gives an overview of the three mandatory constraints that could be applicable to a binary fact. Note that it is possible to combine uniqueness constraints and mandatory constraints. Other ORM notations will be explained as they occur in figures displaying the conceptual database models. As a final remark: ORM is an attribute free, fact-based modelling language.

Attributes commonly associated with ER modelling however, can be represented in ORM.

This is done by assigning roles between objects as had been done with a Person and Age in the example (age could have been an attribute in ER). For an extensive overview of ORM and the CSDP, please refer to chapters 3 up to and including chapter 7 of ‘Information Modeling and Relational Databases’ by Halpin & Morgan (2008).

Table 1 Basic uniqueness constraints in ORM and Barker ER representation form

ORM representation Barker ER representation

n:1

It is possible that more than one A has the same B.

1:n

It is possible that some A has more than one B.

1:1

For each B, at most one A has that B.

m:n

In each population of A has B, each A, B combination occurs at most once.

Table 2 Mandatory constraints applied to binary facts

ORM representation Barker ER representation

Each A has some B.

For each B, some A has that B.

Each A has some B.

For each B, some A has that B.

4.2 Information retrieval

The final task in the BPMN models is viewing information. This is a task that the users of the EPRES (recipients in the context explained above) should themselves perform, rather than the EPRES. However, the system is responsible for retrieving and displaying the information to the user. It would be infeasible for the EPRES to always display all the data it contained and furthermore this is deemed undesirable by stakeholders. Thus a selection of data must be retrieved and displayed upon request (the output). This implies the need for two inputs for the system, namely: 1. that information should be displayed and; 2. which selection of information should be displayed. In the proposed model, these inputs are captured within a read request. A read request in itself is an indication that information should be retrieved. A read request also provides information, at a higher level, about which selection of information should be provided. Each read request indicates the patient (see section 4.3), whom the EPR should be related to. As will be explained in later sections, the processes that can grant a read request need information concerning who initiated the read request. In the model the person initiating the request is indicated by ‘Login-Grant’, which is further explained in section 4.4. In addition for traceability purposes and improved accountability, the instance at which a read request is made is recorded and a read request is assigned a number for ease of identification. However, as is apparent from the BPMN models, stakeholders also wish to regulate the access of information. Currently BPMN models indicate three processes that can grant a read request and allow data retrieval: 1.

confirmation of a treatment relationship; 2. permission granted by the patient; 3. an urgent

access request. These are further elaborated in section 4.5. The resulting data retrieval section of the ORM model is displayed in Figure 9.

Figure 9 ORM model for granting a read request and allowing data retrieval.

The double uniqueness constraint applied to ‘ReadRequest results in ReadRequest-Grant if successful’ indicates that ReadRequest-Grant is identified through its originating ReadRequest. The ‘exclusive or’ constraint represented by indicates that a ReadRequest-Grant must be the result of exactly one of the indicated options. The external uniqueness constraint indicates that for each read request the combination of Instant and Login-Grant is unique.

4.3 Person

While legislation has made it possible to identify someone through his or her social security number (BSN), this method is not always applicable. Infants do not have a BSN for some time after birth, during which they may still receive treatment in a hospital. In addition foreign visitors and illegal immigrants also do not possess a BSN and issues with BSN exist. As such an alternative identification scheme is required when a BSN cannot be used to identify a person. This identification scheme consists of the combination of birthname (surname at time of birth), birthdate and biological sex. Since theoretically any person could be identified in this manner this is taken as the primary method for identification of a person in general.

People with a BSN however, can be considered as a subgroup that is identified with a BSN.

Figure 10 displays the identification schemes in ORM. In Figure 10, note that Persons who

are of the subtype ‘Patient’ may also be part of the subtype ‘PersonWithBSN’. The same

goes for health care professionals, who may also be registered as a patient. They are not

exclusive. However, since health care professionals require a BSN to practice medicine in the

Netherlands they are a subtype of PersonWithBSN rather than Person in general.

Figure 10 Double identification scheme of a person in ORM.

The double external uniqueness constraint indicates that the combination of Birthname, BiologicalSex and Birthdate is unique for each person, and that the combination is used to identify a person.

4.4 Login

The login procedure for the EPRES is in fact only an elaborate process for establishing who is performing user interactions with the system and verify that person’s identity. ‘Login- Grant’ as shown on the right in Figure 11, is the system’s indication that it has verified that the user who performs any subsequent actions, is indeed the healthcare professional that owns the account. The relationship between a healthcare professional and account was previously displayed in Figure 10.

The means of verifying user-identity currently takes place in a traditional form, that is:

the user enters an account ID and password. The system then checks whether or not it has a

record of matching data and based on this derives a check result. Given the characteristics of

the business environment, in the long term it would be preferable if faster and/or more

reliable means for verifying a user’s identity were developed. (See also chapter 5.) For

traceability of an account’s use, and potential misuse, the instances at which login attempts

occur are also registered. In addition, database will hold tables containing both data on

successful and unsuccessful logins.

Figure 11 The ORM model presenting the login procedure.

The equality constraint indicates that a Password-Entry can only be compared to a Password that is associated with an Account.

4.5 Read permission verification

As indicated in section 4.2, a read request can be granted to allow data retrieval by three distinct processes. The most common process is likely that of verifying a treatment relationship. As such, the other two processes are a fall-back processes that are only offered to the user if a treatment relationship cannot be verified. Stakeholders have indicated that treatment relationships are the preferred basis for granting or denying access to a patient’s record. While access is more open in current practice, when administrative issues would be solved, a treatment relationship based system would be the ideal. A treatment relationship is a relationship between two persons, a healthcare professional and a patient, and is established by mutual agreement at an instance in time. As Figure 12 indicates, it would be theoretically possible for multiple treatment relationships to exist between the same persons. However, only one treatment relationship can be established between those two persons at a single instance.

Figure 12 ORM model of a treatment relationship

The exclusion constraint indicates a person cannot participate in the same treatment relationship as both the HealthCareProfessional and Patient, as the patient should be ‘another’ (Art 7:446 BW).

The actual check for a treatment relationship with regards to data retrieval is shown in Figure 13. It checks whether a relationship exists between the two persons related to the read request (e.g. the healthcare professional making the request and the patient whose EPR is requested). From data concerning treatment relationships it then derives the result, either confirming that a relationship exists and allowing data retrieval, or refusing the read request.

Figure 13 ORM model of the treatment relationship check

In the interest of saving (sometimes critical) time and/or reduce immediate administrative burden for the user, requirements state that there should be two other options that would allow a data retrieval. The first is that the user can indicate that the read request is urgent and immediate access is required or it could endanger the patient’s health.

In this case the user is granted immediate access and data is retrieved. However, urgent access requests are recorded in a separate table for later evaluation so that potential misuse of the function can be reprimanded. Figure 14 displays the urgent access request in ORM.

Figure 14 ORM model of urgent access

Lastly, at the suggestion of stakeholders it should be possible for the patient personally

to grant someone permission to view his or her data if a treatment relationship could not be

verified by the system. Administrative issues should not obstruct treatment if the patient

explicitly gives consent. The process of verifying patient permission is currently implemented

in a fashion similar to that of a login, where the patient enters or provides a key code to

verify that he or she is indeed the patient and wishes to permit access. Figure 15 shows the

ORM model of verifying patient permission.

Figure 15 ORM model of verifying patient permission

4.6 Patient registration

The patient registration process precedes those related to data retrieval. Legislation and other regulations demand that a patient’s data can only be accessible through the EPRES if a patient has given explicit consent to make his or her data available. To this end as the BPMN model indicates, whenever a person is registered as a patient his or her consent status should be recorded. The expression of this process in the conceptual database model is given in Figure 16.

Figure 16 ORM model of patient registration

The subtype constraint indicates that any Person that is registered as a patient should also indicate/have a consent status for exchange of his or her medical records by means of the exchange system.

4.7 Relational view, verbalization and verification

The ORM tool used in this research also allows for generating a relational view that displays how data is related and the various tables that exist. The relational view can be found in Appendix VII: Relational view of the ORM model. As previously mentioned in section 3.5, ORM is a fact-based modelling method. The visual models can be translated in series of textual fact and constraint statements that have been used in the evaluation form.

The majority of the feedback from the evaluation has already been implemented in the

models presented in this research. The evaluation form can be found in Appendix V: ORM

model evaluation form. This form presents fact statements as they were found in version 0.6

of the conceptual database models, whereas this chapter has described version 1.0 of the model. Remaining issues are discussed in chapter 5. The evaluation results themselves can be found in Appendix VIII: Evaluation results, for reference purposes.

5 DISCUSSION

The model as developed primarily addresses one of the key problems indicated earlier;

it addresses the mismatch between system operations and healthcare providers’ workflows.

It does so by translating the ideal processes as indicated by stakeholders into a database model. Architectural design choices can also have an impact on the usability and performance of the system, which may or may not affect user workflow. The architectural design is however not part of this stage of the project, but will be addressed in a later stage.

Additionally, support processes that could potentially affect the workflow still need to be addressed; BPMN models currently do not indicate how access rights, accounts, passwords and patient can be created or manipulated.

The issue of ensuring privacy is partly addressed by the ORM model; each access request is subjected to a number of checks, requires user identification and user activity is logged. Due to resource constraints however, the data security standard NEN 7510, as well as healthcare specific standards NEN 7511, 7512 and 7513, could not be investigated. It is currently unknown whether or not information contained in these standards could have contributed to the ORM model. The security of the system is also greatly dependent on the implementation of the database model, which is not addressed here.

Furthermore, the model does not directly affect the scalability of the system. The scalability is mainly influenced architectural design choices.

Two additional issues also remain from the feedback from domain experts: 1. The login makes use of an separate EPRES account. It is unclear who should be responsible for maintaining accounts and performing related administrative actions. While it has been suggested by a domain expert to use an UZI pass for login (CIBG, 2013), another expert advised that this will encounter the same, if not more administrative problems. Separate UZI passes would have to be issued for the use in the EPRES, and it may be that administrators of the EPRES would not be allowed to request UZI passes for users. 2. Treatment relationships are currently not registered in many local HIS. The registration itself is also an issue that first needs to be thoroughly investigated before it can be solved. The current design as it is would not be able to operate effectively in the practical environment as long as treatment relationships cannot be verified.

Finally, domain experts also indicated another major issue of concern which currently

obstructs the implementation of a national EPRES and even gives rise to problems on a local

scale; interoperability. The issue of interoperability has already been briefly addressed in

section 2.2, with regards to standards. While HL7 Reference Information Models (RIM)

standards have been investigated, time constraints prevented its implementation into the ORM models presented in this research. It should be mentioned however, that the use of HL7 RIM could greatly assist in establishing and verifying treatment relationships and thus support the EPR exchange process. Additionally HL7 RIM could assist in relating data across various local Hospital Information Systems (HIS). However, as domain experts have indicated EPR should contain ‘information’, rather than ‘data’. In this context information is defined as data which is presented in a way that it can be correctly interpreted, taking on an unambiguous meaning. While HL7 Clinical Document Architecture (CDA) improves semantic operability, it still is flexible enough that it can allow ambiguous documents. It provides guidelines indicating which data should be provided in an EPR and how it should be structured, however it does not enforce a certain format for data entered. The author remains responsible for ensuring that the data is entered in an unambiguous way that it is always correctly interpreted. This complicates associating similar data across multiple systems. In addition CDA does not distinguish between different users, while stakeholders require that different users are able/allowed to view different sets of information. But even if these standards did fully address this issue, their adoption is still rather limited. Propriety formats and vendor lock-ins also make it difficult to extract data from a HIS and greatly hinder the adoption of standards and, by extension, the exchange of medical data. Even within a hospital, systems and equipment do not adhere to the same standards and formats.

As domain experts indicated, data formats and presentations must be established and agreed upon on a national level, and de jure standards may be required to ensure full interoperability. Fortunately, even if this could not be achieved, previous research has indicated that standards continue to be developed and harmonized (Atalag et al., 2010;

Richesson & Krischer, 2007). Perhaps in the future a ‘complete’ standard will be developed and adopted by enough healthcare providers to overcome this issue. With respect to interoperability, the ORM models as such currently do not yet provide a complete specification for the data structures necessary for achieving the goal of exchanging EPR. They may need to be adjusted to adhere to a chosen standard. They do however, enable an exchange process as it is desired within the business environment and provide a basis for further expansion and development. Conversely, should a prototype system prove successful, the underlying models may contribute to the development of standards.

For further development of the models however, it would be beneficial to involve

additional stakeholders. The VZVZ is currently responsible for maintaining the Dutch HCII; its

expertise and past experiences could provide valuable insights in nearly every aspect of

developing an EPRES. In addition the successful implementation and use of the EPRES

depends entirely on the acceptance of patients, whose data resides within the system and

the government as legislative body. Finally, should the EPRES see a successful practical

implementation, then the healthcare inspection (IGZ) is also likely to become an important user and should become involved sooner or later.

6 CONCLUSION

This research is part of a larger project that was started on the premise of tackling three major issues that prevent the successful implementation of a HCII in the Netherlands:

failing to ensure privacy, a lack of scalability and, a mismatch between the operation of the developed systems and healthcare providers’ workflows. The emphasis in doing so is to determine the business processes and requirements. In the stage of the project addressed by this research, business requirements have been translated into a database model by means of ORM modelling techniques. In doing so, this research has addressed two of the major problems: 1. the model incorporates the information minimally necessary to enable an EPR exchange process according to the workflows in the business environment and; 2. it incorporates processes designed to maintain confidentiality of patient records. The model contributes to the development of a prototype exchange system to be created in later stages.

A literature review and discussion with domain experts have however indicated another fourth major issue to be resolved. Current HIS suffer greatly from a lack of interoperability. This issue is currently not addressed by the ORM models, though some interoperability standards do relate to the data structures and formats. The interoperability issue between healthcare information systems is certainly worth further investigation and there is a growing body of literature on the subject. It is a problem that dedicated international organizations struggle to solve. With further development, the ORM models in this research and the larger project that it is part of, may offer insights in the business processes and data structures that could potentially contribute to the development of an interoperability standard and the body of literature on the subject.

7 REFERENCES

Al-Sarira, A. A., David, G., Willmott, S., Slavin, J. P., Deakin, M., & Corless, D. J. 2007.

Oesophagectomy practice and outcomes in England. The British journal of surgery, 94(5): 585–91. http://www.ncbi.nlm.nih.gov/pubmed/17443856, March 9, 2013.

Atalag, K., Kingsford, D., Paton, C., & Warren, J. 2010. Putting Health Record

Interoperability Standards to Work. electronic Journal of Health Informatics, 5(1): 1–

17.

Balsters, H. 2012. Design Methods  : Building utility-driven Artifacts Part 2.

Balsters, H. 2008. Introduction to Information Systems-2. South-Jordan: Neumont University.