Medical Data Grids as a Base-Architecture for Interregional Shared Electronic Health Records

Transcription

1 Doctoral Thesis Medical Data Grids as a Base-Architecture for Interregional Shared Electronic Health Records Dipl.-Ing.(FH) Florian Wozak, MSc. UMIT university for health sciences, medical informatics and technology Institute for Health Information Systems Eduard Wallnöfer Zentrum 1 A 6060 Hall Österreich/Austria

2 Abstract Tight cooperation and communication between institutions involved in a patient s treatment process provide for improved quality and efficiency of care. Beside a legal and organizational framework an appropriate technical infrastructure is required to facilitate communication. In order to provide patient centered care multiple institutions are involved in the treatment process, therefore Electronic Health Records should provide medical data in an appropriate representation after successful authorization. Although Electronic Health Records have become subject of intensive research over the past years, it is still unclear which Health Information System architecture is the most appropriate. This work addresses three main goals: (1) Analysis of system and security requirements for Shared Electronic Health Records. (2) Development of a Health Information System (HIS) architecture based on the identified requirements including the comparison of existing architectures as a prerequisite. (3) Implementation of an open source prototype as proof of concept. Standardized software engineering and object oriented methods have been applied for the development of the architecture. Due to partly unclear requirements an iterative software process paradigm has been applied, which allows stepwise integration of designed functionality. Problem centered interview and qualitative content analysis have been used to obtain reproduceable results from interviews with domain experts. Literature analysis and common creativity methods have been applied to support the development process. According to goal 1 system and security requirements of relevant actors in the healthcare system have been derived from previously analyzed user requirements: As a key requirement patients and medical professionals require functionality for accessing and appending data to the Electronic Health Record. Privacy protection is a patient s vital concern, so security features are required to protect medical data from unauthorized access and provide functionality for patients to issue fine grained access permissions. As defined by goal 2 an evaluation of existing HIS architectures revealed that distributed, GRID based architectures are the most adequate technology. A flexible, modular distributed HIS architecture based on Medical Data GRIDs has been designed to provide stepwise integration of desired functionality. A security infrastructure based on two level Role Based Access Controls (RBAC) has been integrated. To provide interoperability with existing systems the proposed architecture is compliant to the IHE XDS Integration Profile. According to goal 3 a working prototype has been designed as proof of concept to demonstrate the applicability of Medical Data GRIDs for Shared Electronic Health Records. This proof of concept demonstrates that the chosen technology supports the major requirements such as user requirements, security, scalability and availabilty. Although the architecture provides technically mature core components a variety of organizational, legal and even technical aspects will still have to be solved until the Electronic Health Record becomes available to the public.

3 Zusammenfassung Durch verbesserte Kooperation und Kommunikation der am Behandlungsprozess beteiligten Institutionen kann eine Steigerung von Effizienz und Qualität bei gleichzeitiger Kostenreduktion erreicht werden. Als Voraussetzung dafür gilt die trans institutionale Verfügbarkeit relevanter medizinischer Daten. Elektronische Gesundheitsakten ermöglichen eine patientenzentrierte orts und zeitunabhägnige Bereitstellung medizinischer Daten für berechtigte Personen und Institutionen. Die drei Hauptziele der Arbeit leiten sich aus der Tatsache ab, dass trotz intensiver Forschung auf diesem Gebiet nicht geklärt ist, welche Health Information System (HIS) Architektur für Elektronische Gesundheitsakten am Geeignetsten ist: (1) Analyse von System und Security Requirements aus zuvor ermittelten User Requirements. (2) Vergleich existierender HIS Architekturen und Entwicklung einer auf die Anforderungen abgestimmten HIS Architektur für Elektronische Gesundheitsakten. (3) Implementierung eines Open Source Prototypen als Proof of Concept. Die Entwicklung der HIS Architektur erfolgt als standardisierter Software Prozess unter Einsatz objektorientierter Methoden. Aufgrund teilweise unklarer Anforderungen wurde ein iteratives Software Prozess Modell gewählt, um gewünschte Funktionalität schrittweise in Kooperation mit beteiligten Akteuren zu integrieren. Zur Gewährleistung der Reproduzierbarkeit von Expertenbefragungen wurden Problem zentriertes Interview und qualitative Inhaltsanalyse eingesetzt. Literatur Analyse und gängige Kreativitätstechniken wurden als unterstützende Maßnahmen im gesamten Entwicklungsprozess mit eingebunden. Ziel 1: Als erster Schritt erfolgte die Ableitung von System und Security Requirements aus zuvor erhobenen User Requirements. Als Hauptanforderung wurde Funktionalität zum orts und zeitunabängigen Zugriff auf die Gesundheitsakte, sowie zum Hinzufügen von Einträgen sowohl für Patienten als auch für medizinisches Personal identifiziert. Hohe Sicherheitsanforderungen zum Schutz medizinischer Daten vor unbefugtem Zugriff, sowie wie die Möglichkeit zur Vergabe von detaillierten Zugriffsberechtigungen wurden ermittelt. Ziel 2: GRID basierte HIS Architekturen erscheinen als Ergebnis einer durchgeführten Evaluierung bestehender HIS Architekturen als am Besten geeignet für Elektronische Gesundheitsakten. Basierend auf den Evaluierungsergebnissen erfolgte die Entwicklung einer flexiblen, modularen auf Medical Data GRIDs basierten HIS Architektur mit 2 Level Role Based Access Control (RBAC) als Security Konzept. Zur Gewährleistung herstellerunabhängiger Interoperabilität ist die entwickelte Architektur kompatibel zum IHE XDS Integration Profil. Ziel 3: Mittels einem als Proof of Concept entwickelten Prototypen konnte gezeigt werden dass Medical Data GRIDs eine geeignete Technologie zur Verfügung stellen um Basisfunktionalitäten für Elektronische Gesundheitsakten zu unterstützen. Trotz technisch ausgereifter Kernkomponenten sind die, für den Einsatz Elektronischer Gesundheitsakten erforderlichen organisatorischen und rechtlichen Rahmenbedingungen zu schaffen, sowie technologische Aspekte, vorwiegend betreffend Berechtigungsmanagement zu lösen.

4

5 Contents I Premises and Introductory Descriptions 1 1 Introduction Subject and Motivation Problem Context Objectives Structure and Outline of this Work Basic Definition and Related Work Basic Definitions Information Systems Electronic Records Electronic Medical Record (EMR) Electronic Patient Record (EPR) Electronic Health Record (EHR) Shared Electronic Health Record (SEHR) Architectures and Architectural Styles of Information Systems Distributed Architectures Service Oriented Architectures GRID Technology for Building Virtual Organizations Anatomy of the GRID Physiology of the GRID Data GRIDs Healthgrids Relevant Technical and Communication Standards in the Context of SEHRs openehr European Norms (EN) and ISO Standards Health Level 7 (HL7) The Clinical Document Architecture (CDA) Integrating the Healthcare Enterprise (IHE) Security Concepts for Shared Electronic Health Records Role Based Access Control (RBAC)

6 IV Contents Attribute Certificates The Austrian e-card Relevant Initiatives and Legal Requirements in the Context of SEHRs Legal Requirements for the Exchange of Patient Data in Austria e-health Action Plan The Austrian e-health Feasibility Study Regional Project Approaches for Implementations of SEHRs in an International Context Sundhed.dk Akteonline.de e-consent based Shared EHR System Architecture Personal Internetworked Notary and Guardian (PING) Historia Digital de Salud del Ciudadano (Diraya) Comparison and Evaluation of Related Implementations Summary Methods General Introduction of Relevant Methods Step Approach for Strategic Project Planning Literature Analysis Brainstorming Methods for Interviews with Domain Experts The Unified Modeling Language (UML 2.0) Object oriented Development Software Process Software Process Paradigms Methods Applied for Developing a HIS Architecture for SEHRs Interviews with Domain Experts Object Oriented Development for the SEHR Architecture Applied Software Process Paradigms Methods Applied in Different Phases of the Software Process Summary II Results 67 4 Requirements for Shared Electronic Health Records Relevant Actors User Requirements User Requirements for Patients User Requirements for Medical Professionals User Requirements for Health Insurances

7 Contents V User Requirements for Scientists User Requirements for Pharmacies User Requirements for Public Authorities Summary of User Requirements System Requirements Domain Requirements Security Requirements Clustering of Security Requirements Summary and Conclusion Comparison of Existing Architectures for SEHRs Definition of Centralized and Distributed Architectures Evaluation Criteria for HIS Architectures Evaluation of Centralized HIS Architectures Evaluation of Distributed HIS Architectures Distributed HIS Architectures as Basis for SEHRs Service Oriented Architectures as Concept for SEHRs Medical Data GRIDs as Concept for SEHRs Summary and Conclusion HIS Architecture for SEHRs Overview of the Architecture GRID Services as Basic Components Document Clearing (DC): Acces Node (AN): Patient Lookup Index (PLI): Patient Lookup (PL): Document Repository (DR): Document Meta Data Index (DMDI): Global Index (GI): Workflows for Common Operations Role Based Access Control (RBAC) for SEHRs Message Level Security for End to End Security Combination of Medical Data GRIDs and IHE XDS Summary and Conclusion Prototype Implementation Description of Prototype Implementation Used Software Environment Application Development Working with the SEHR Summary and Conclusion

8 VI Contents 8 Discussion Summarization of Main Results Discussion of Applied Methods Methods Used Throughout the Entire Work Applied Software Process Paradigms The Software Specification (Analysis) Phase The Software Design and Implementation Phase The Software Validation Phase New Aspects and Lessons Learnt Discussion of Results Discussion of Requirements for SEHRs (Goal 1) Discussion of Architecture Comparison (Prerequisite for Goal 2) Discussion of the Proposed HIS Architecture for SEHRs (Goal 2) Discussion of Prototype Implementation (Goal 3) Summary Conclusion and Outlook 155

9 List of Figures 2.1 Virtual Organizations for Trans Institutional Resource Sharing The GRID Protocol Architecture IHE XDS Actors Step Model for Inquiries of Medical Findings Problem centered Interview Qualitative Content Analysis Spiral Model of the Software Process Requirements Engineering: Activity Diagram Design and Implementation: Activity Diagram Validation: Activity Diagram Identified Actors General Software Architectures Service Layer Overview GRID Services of the HIS Architecture for SEHRs Workflow for Adding a Document to the SEHR Workflow for Receiving a Document from the SEHR Two Level Security Model IHE XDS with Medical Data GRIDs Document Clearing Service Running in Eclipse Web Portal: Patient Selection Web Portal: Time Range Selection Web Portal: Display Patient s Mandate Web Portal: Retrieval of Stays Web Portal: Display of Metadata

10

11 List of Tables 3.1 Domain Experts User Requirements for Patients User Requirements for Medical Professionals User Requirements for Health Insurances User Requirements for Scientists User Requirements for Pharmacies User Requirements for Public Authorities System Requirement: Passive Access to Personal Health Record System Requirement: Active Access to Personal Health Record System Requirement: Access to a Patient s Health Record for Medical Professionals System Requirement: Direct Communication System Requirement: Management of access permissions System Requirement: General Security Requirements System Requirement: Role and Context Based Authorization System Requirement: Common Data Standard System Requirement: Common Transmission Standard System Requirement: Patient identification System Requirement: Interoperability Security Requirements Clustered Security Requirements Security Requirement: Security of Architecture Security Requirement: Software Security Security Requirement: Network Security Security Requirement: User Security Security Requirement: Data Security Summary of Comparison of Existing Architectures for SEHRs

12

13 Part I Premises and Introductory Descriptions

14

15 Chapter 1 Introduction 1.1 Subject and Motivation In an aging society with an increasing number of multi morbid patients, a variety of different healthcare institutions will be involved in a patient s treatment process, each of them specialized on distinct fields. New procedures will be available which will make medical treatment more complex and cost intensive. Already in 1970 Collen analyzed that the quality and efficiency in the healthcare sector can be increased by improved cooperation between institutions involved in the treatment process [1]. Cooperation substantially profits from improved communication between involved healthcare institutions, which demands beside a legal and organizational framework for appropriate technology facilitating the exchange of medical data. The availability of relevant information across institutional boundaries will lead to significant cost reduction by avoiding unnecessary examinations [2] and patient safety can be improved by the reduction of treatment errors [3]. With those benefits in mind, information systems have been developed to facilitate communication, in the beginning mainly paper based and during the last years shifting constantly towards electronic communication. Until 2013 more than 80% of medical data transferred between different institutions are expected to be exchanged electronically [4]. The amount of data being processed or stored will also increase, due to new information technologies and diagnostic and therapeutic procedures [5]. To provide a technical basis for the trans institutional exchange of medical data various applications have been developed, mainly based on standard internet technology which is constantly being improved and available at a moderate price. The development of these applications is a historical process which began as information and communication technology became available. So, until now they were developed using an institution centered approach, which means that applications follow the requirements of the involved institutions rather than focusing on the requirements of the patient. This institution centered approach mainly relies on directed communication, implying that the intended receiver has to be known at the very beginning of the

16 2 Chapter 1: Introduction communication process. The fact that institutions which are involved in the treatment process at a later time can only be determined in the rarest cases in advance, is considered a severe drawback of this communication model. But, to make use of the above mentioned benefits, relevant medical information should be available in appropriate representation across institutional boundaries and independent of their physical location. For this reason a non directed approach is expected to be more adequate, where medical data are provided on demand for institutions involved in the treatment process, whenever needed and after successful authorization. A Shared Electronic Health Record (SEHR) is a Health Information System which makes use of non directed communication flow for providing medical data across institutional boundaries, independent of their physical location. These data are accessible in a SEHR per patient without having to know the institution in which the patient has been treated. Technically, the implementation of SEHRs can be described by the Health Information System (HIS) architecture it relies on, which is the components of a HIS and their interactions (See section 2.3 on page 10). This implies that a directed communication flow between the involved institutions is no longer necessary, which as a result, leads from an institution centered communication model to a patient centered model, where the patient has full access to his personal medical data and can authorize (to a certain extent) access for individuals or institutions. In a SEHR medical data are distributed over the various institutions where a patient has been treated. After successful authentication these data then should be accessible for institutions or physicians involved in the treatment process. Awareness has been created that a shift from institution centered to patient centered Health Information System (HIS) architectures could lead to increased patient satisfaction and cooperation [6]. Furthermore an improved process of recovery and, so in turn, improved quality and efficiency in healthcare is expected. Since the last few years the technical infrastructure and network architectures have slowly begun to adapt to the requirements of a patient centered communication model, leading to a shift from rather departmental or local information systems towards Health Information Systems in a global sense [5, 7]. A variety of HIS architectures evolved during the last years which provide a framework for medical data to be shared or exchanged amongst participating institutions in a SEHR. This work focuses on the development of a network architecture which forms the basis for a trans institutional exchange of medical data with special emphasis on the requirements for the healthcare region Tyrol.

17 1.2 Problem Context Problem Context According to the underlaying architecture Shared Electronic Health Records can be classified in centralized, distributed and hybrid HIS architectures: Centralized HIS architectures mostly follow the style of a client server model; Electronic Health Record Banks with central data repository are one of the most common applications [8, 9]. In Electronic Health Record Banks medical data which are entered by the patient or physician are made available for authorized individuals or institutions. Akteonline 1 is a well known Health Record Bank in German speaking countries [10]. Distributed HIS architectures rely on services which can be distributed among different physical locations and offer specific functionality [11]. In distributed architectures systems can simultaneously act as service provider and service consumer (See section on page 11). Peer to Peer 2 or GRID technologies (See section 2.4 on page 13) are commonly used for building distributed architectures. Hybrid HIS architectures make use of specific central services in a distributed environment. The hybrid approach is implemented in the health@net 3 core architecture (See section 2.9 on page 34). Based on functional requirements for Shared Electronic Health Records, analyzed by Schabetsberger [12, 13] system requirements, which comprise amongst many others security, scalability and high availability can be anticipated. In distributed (or hybrid) HIS architectures services are offered by independent service providers, which in turn can be healthcare, governmental or other institutions. Without the need of central data repositories the above mentioned requirements seem to be better supported by exploiting the benefits of distributed (or hybrid) HIS architectures. The following benefits are expected for the involved institutions: Investment can be kept reasonably low, since medical data can remain stored in or close to the location where they were produced. Large electronic data processing centers with a huge amount of storage capacity, compute power and high network bandwidth can be avoided. Scalability is improved because new systems can be easily integrated without the need of purchasing storage capacity, compute power and upgrading network bandwidth, as it would be required for centralized HIS architectures. Distributed search functions allow the installation of metadata indices, which dedicates search functionality to special services Widely known from various file sharing applications. 3 health@net is a research project between the University for Health Sciences, University for Health Sciences, Medical Informatics and Technology (UMIT) and the University Hospital Innsbruck with the aim to network players of the healthcare sector in order to support cooperate care in the region Tyrol, Austria. The author is a member of the health@net project team.

18 4 Chapter 1: Introduction Security improvements can be achieved by the absence of a single point of failure or attack. In distributed HIS architectures fine grained access control policies can be applied for each service. Today many research projects focus on the development of HIS architectures for patient centered Shared Electronic Health Records, some using centralized architectures [10], others exploiting the benefits of distributed approaches [11]. Since research in the field of distributed HIS architectures started quite recently, applications are slowly entering the market. The replacement of architectures widely used today, which mainly rely on directed communication flow, is not expected to take place within the next few years. Unfortunately the majority of the existing HIS architectures does not appear to be prepared for a patient centered communication. Particularly in the field of distributed HIS architectures many aspects remain unsolved. The following list addresses the most relevant issues for a Shared Electronic Health Record: Problem 1: Patient centered communication models are currently not satisfactorily supported by widely used HIS architectures. Functional and user requirements have been analyzed but systen requirements for Shared Electronic Health Records are still not sufficiently known. Problem 2: It is unknown which HIS architecture best supports the previously analyzed requirements for Shared Electronic Health Records. There is still no experience as to which (presumably distributed) architectures allow medical data to be accessed on demand, following the paradigm of social networks. Since medical data are extremely sensitive a high level of data protection is required. Aspects of security and authorization are currently mostly unsolved for SEHRs relying on (presumably distributed) architectures. Problem 3: A reference implementation of the most promising HIS architecture is expected to facilitate the development of an interoperable productive solution. Interoperability with existing systems can only be proved in realistic test environments. However, a testbed for new technologies as reference implementation with basic functionality does currently not exist. 1.3 Objectives The complexity of the problem makes it impossible to provide an overall solution for all of the analyzed deficiencies. So, trying to solve all the mentioned problems reaches far beyond the scope of this work. The majority of the currently existing drawbacks is likely to be solved

19 1.4 Structure and Outline of this Work 5 bit by bit within the next years. Especially the integration of existing legacy architectures is expected to remain partly unsolved for an even longer period. The aim of this work is to propose a possible solution for those problems, which arise from inefficient communication flow, probably dictated by an inadequate architecture of the Health Information System. Furthermore this work aims at proposing a HIS architecture which can accomplish the requirements analyzed by Schabetsberger [12, 13]. Therefore the following goals have been determined. Goal 1: Technical requirements such as system requirements and models should be derived from functional requirements. Special emphasis has to be placed on covering potentially conflicting requirements of different actors in a technical requirements profile as accurately as possible. Goal 2: Development of a HIS architecture based on the identified requirements and design of corresponding services to support non directed communication flow for a patient centered SEHR. Blueprint of a security model which fulfills legal and organizational requirements for trans institutional exchange of medical data with special focus on the Austrian legal situation. Well established technologies and open standards should form the basis for secure authentication and role and context based authorization. Goal 3: Implementation of an open source reference HIS architecture in the context of the health@net project with integration of existing systems. Evaluation of the developed architecture by defined criteria comprising scalability, security and usability. 1.4 Structure and Outline of this Work This work is divided into two parts comprising nine chapters. Results are described in the second part, whereas the first part outlines how those results were obtained by introducing basics and relevant methods. Introduction: The current chapter introduces the subject matter and outlines problems that are to be solved in this work. Basic Definition and Related Work: Definitions of terms are given, which will be used later in this work, and relevant concepts and standards which the results are based on, are introduced. Methods: This chapter describes software engineering methods applied for developing a HIS architecture for Shared Electronic Health Records.

20 6 Chapter 1: Introduction Requirements for Shared Electronic Health Records: System requirements including security requirements are derived from functional requirements analyzed by Schabetsberger. Comparison of Existing Architectures for SEHRs: Existing architectures for SEHRs are compared and the benefits and drawbacks of each of them are outlined. HIS Architecture for SEHRs: Key section of this work in which a HIS architecture for Shared Electronic Health Records is proposed. Services and interaction are described and visualized using UML models. A detailed description of a distributed, GRID based architecture that best supports analyzed requirements such as interoperability, security and scalability is given. Prototype Implementation: An open source reference HIS architecture is being implemented in the context of the health@net project for evaluation of the proposed architecture. Based on the prototype implementation particularly the applicability of GRID technology for SEHRs is to be verified. Discussion: Validity of methods and proposed architecture are critically discussed. The HIS architecture is compared with other, probably centralized architectures and approaches different from the GRID technology are adumbrated. Conclusion and Outlook: Concluding remarks are made and finally an outlook to future development is provided.

21 Chapter 2 Basic Definition and Related Work 2.1 Basic Definitions In the entire section 2.1 definitions of terms are given, which will be used later on in this work. In different sources in literature some terms are explained with different or even oppositional meaning. To provide easier understanding, terms and definitions used in this work will be explained in this section. Definitions introduced in the following two sections are based on the book Strategic Information Management in Hospitals by Haux [14] Information Systems Information System For healthcare organizations the processing of data and information is a vital task. Therefore each organization has its own customized information system which is unique for the institution. An organization s Information System has developed over time and will constantly be adapted to changing requirements. The task of an information system is to store and process data and information independent of the actors, which can either be machines or humans [14]. An information system is that part of an enterprise that processes and stores data, information and knowledge. It can be defined as the socio technical subsystem of an enterprise, which comprises all information processing as well as the associated human or technical actors in their respective information processing roles [14].

22 8 Chapter 2: Basic Definition and Related Work Hospital Information System Hospital Information Systems are that part of the healthcare enterprise which is concerned with information processing, the actors being either humans or machines. A Hospital Information System is the socio technical subsystem of a hospital, which comprises all information processing as well as the associated human or technical actors in their respective information processing role [... ] The goal of a Hospital Information Systems is to sufficiently enable the adequate execution of hospital functions for patient care, including patient administration, taking into account economic hospital management as well as legal and other requirements [14]. Independent of whether it is provided by humans or technical actors a Hospital Information System has to fulfill a variety of tasks to support patient care and hospital administration. Information transport and information storage are the basic tasks. Medical information and knowledge should therefore be provided on time, at the right location, to authorized staff and in an appropriate and usable form. Knowledge and relevant data should also be provided for scientific analysis and educational purpose. Data which is relevant for accounting must be accessible for the administration however with emphasis to protect medical information from the administrative staff [14, 15]. Health Information Systems (HIS) Health Information Systems are information systems, which provide the basis for a coordinated shared care by changing the focus of care from central hospitals to distributed networks of healthcare institutions that contribute to a patient centered care [14]. The acronym HIS is sometimes referred to as Hospital Information System in literature. In this work the meaning of HIS is Health Information System. As information and communication technology (ICT) entered the medical domain and the first information processing tools were successfully installed in healthcare institutions, their scope was focused on isolated procedures in one healthcare institution. This field of applications is typical for Hospital Information System (See section 2.1.1). The aim to improve the care process while decreasing costs leads to a shift towards better integrated and shared, patient centered care. Therefore diagnostic and therapeutic procedures, as well as administrative tasks, such as accounting and reservation of capacities are no longer bound to specific institutions but are breaking institutional boundaries. [... ] to form Health Information Systems Hospital Information Systems will increasingly be linked with information systems of other healthcare organizations [14].

23 2.2 Electronic Records Electronic Records Definitions introduced in this section are based on the books Strategic Information Management in Hospitals by Haux [14] and Handbuch der Medizinischen Informatik by Lehmann [15] During the last years a variety of different types of electronic (health) records has been developed. In the beginning, when electronic records came into the market they were closely bound to the institution they were operated in. The same shift towards trans institutional interconnection as encountered for information systems also occurred for electronic records. Institutional boundaries are blurring, which leads to patient centered electronic health records, distributed over different institutions. Giving a clear definition of the various electronic record types is not trivial, since different sources in literature actually use controversial definitions. Different understanding in different languages poses a major problem. Particularly in the German language area various types of electronic records exist whose definition can not be directly mapped to the definition used in English speaking countries. Before talking about an electronic record, it is important to clearly define each type of record. This section focuses on the definition of those types of records addressed in this work, and is important for the understanding of the following chapters. Electronic records can basically be classified in patient records and health records. The first comprises all the data and medical documents generated during the care of a patient in a given healthcare institution. Patient records are closely bound to an organization. The latter comprises beside medical data, health relevant and even social data of a patient and is operated in a trans institutional context [14, 15] Electronic Medical Record (EMR) The Electronic Medical Record belongs to the class of patient records as their most advanced representative, seamlessly integrated in the clinical processes. In an EMR all documents are generated digitally, it supports functions for data management, clinical guidelines and relevant data can be integrated into administrative processes such as accounting and finance [15] Electronic Patient Record (EPR) The Electronic Patient Record is a patient centered record which contains disease relevant data for a patient with continuous history. Although the name Electronic Patient Record might cause confusion the EPR belongs to the class of health records, which can in turn be distributed and operated in a trans institutional context [15].

24 10 Chapter 2: Basic Definition and Related Work Electronic Health Record (EHR) The EHR is a patient centered health record which contains all health relevant data for a patient distributed over different institutions. Besides medical data it comprises all health related data including nutrition, physical training and others. In German speaking countries the EHR is commonly known as Elektronische Gesundheits Akte (EGA or ELGA). Electronic Health Records thus should form a lifelong summarization of medical and health related data of a person. The record is accessible for all institutions or individuals involved in the treatment process, independent of location and time and in an appropriate representation. The EPR is a piece of software accessible via the internet and Web technology to create, manage and view a personal record of every health related aspect of a user. A crucial point is that the patient has the sole power of disposition over type, content and usage of his health related data, which can be seen as the differentiating factor between the Electronic Patient Record and the EHR [16] Shared Electronic Health Record (SEHR) A Shared Electronic Health Record is an EHR which is shared between related institutions in a regional or trans regional context, where responsibility is dedicated to a local authority, such as the General Practitioner (GP) [15]. According to the ISO standardization organization a Shared EHR is defined as follows: It will consist of a range of health organizations and clinicians attended by the patient/consumer on a regular or episodic basis. This will typically include one or more primary care clinicians, specialist clinics [... ], hospitals, allied health professionals and alternative/complementary practitioners [17]. 2.3 Architectures and Architectural Styles of Information Systems The architecture describes the components of an information system and their interaction between each other: The architecture of an information system describes its fundamental organization, represented by its components, their relationships to each other and to the environment, and by the principles guiding its design and evolution [18]. The architecture of an information system comprises enterprise functions, business processes and information processing tools together with their relationships.

25 2.3 Architectures and Architectural Styles of Information Systems 11 To cut down complexity an information system architecture can be described using different views. Depending on the focus of interest it can be described from the functional point of view looking primarily at the enterprise functions, from the process point of view which describes the business process or from the technical point of view revealing details of the implementation. Architectures which have certain characteristics in common can be summarized in an architectural style [14, 15] Distributed Architectures In contrast to local computing, distributed computing uses software agents that make calls to other address spaces, possibly on other machines, that run on different hardware platforms with different operating systems. Therefore a communication via network links is necessary, which is less fast and reliable than local computing in a shared memory environment. For the development of distributed systems this unpredictable behavior has to be taken into account [19, 20]. Sommerville gives the following description of distributed architectures: A distributed system is a system where information processing is distributed over several computers rather than confined to a single machine [21]. Client Server Architectures In a client server architecture specific services are provided by servers and are consumed by clients: In this approach the system may be thought of as a set of services that are provided to clients that make use of these services. Servers and clients are treated differently in these systems [21]. Distributed Object Architectures In distributed object architectures functionality is provided by a variety of services. Each service provider can concurrently be a service consumer. Service oriented architectures (See section 2.3.2) are a well known representative of this architectural style. For distributed object architectures: [... ] there is no distinction between servers and clients, and the system may be thought of a set of interacting objects whose location is irrelevant. There is no distinction between a service provider and a user of these services [21].

26 12 Chapter 2: Basic Definition and Related Work Service Oriented Architectures Driven by the expected benefits in security, scaleability and availability a variety of distributed, service oriented architectures (SOAs) has been developed for Shared Electronic Health Records [11, 22]. A SOA consists of distributed systems that form networks of loosely coupled services. A service is a software agent meeting the following criteria: A service is a logical view of business level operations hiding its implementation details and application logic from the user. The SOA provides an abstraction for the internal structure of the software agent including implementation language, process and database layout. Thus, services can be invoked without having any knowledge of how they are internally constructed. Therefore standardized messages are defined, which are then exchanged between the service provider and the service requester. Services are platform neutral and messages can be exchanged and processed independently of the operating system or programming language, the Extensible Markup Language (XML) is a widely used message format. Each service has a publically available service description, comprising it s semantics (what it does) and a machine processable set of metadata (describing the interface and how it can be invoked). Only those details that are necessary to use the service are included in the description. [23, 20]. Web services, defined in the following section are the most common representatives of a service oriented architecture. Web Services Web Service are used in distributed environments for the exchange of information in a text based XML format to provide interoperability of systems, independent of programming language or underlying operating system. Web Services are a standard of the World Wide Web Consortium (W3C) and are defined as follows: A Web service is a software system designed to support interoperable machine to machine interaction over a network. It has an interface described in a machine processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP 1 messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web related standards [20]. 1 SOAP stands for Simple Object Access Protocol.

27 2.4 GRID Technology for Building Virtual Organizations 13 Interfaces of Web services are described in the Web Service Description Language (WSDL), an XML based human and machine readable format. 2.4 GRID Technology for Building Virtual Organizations The definition of Electronic Health Records given in section 2.2 on page 9 describes requirements and basic features of EHR Systems, but no recommendation for implementation is given. (Shared) Electronic Health Records require information systems of each participating institution to be interconnected, which can be achieved either by centralized or distributed systems. In the latter case services are highly distributed between institutions. GRID technology emerged in the beginning of the 21st century to share resources between different organizations mainly used in the field of high performance computing. The term GRID was first introduced in the mid 1990s for a distributed computing infrastructure for advanced science and engineering. Definitions and concepts introduced in this section are based on the book The GRID2 by Ian Foster and Carl Kesselman as well as on their articles The Anatomy of the Grid and The Physiology of the Grid [24, 25, 26]. Originally GRID technologies have been developed for sharing resources, such as computational power and data storage between different scientific communities. Analysis of large volume data sets which demands for huge amounts of compute power and data storage ressources that can be shared amongst different organizations was their first field of application. The federation and analysis of diverse distributed data sets and the coupling of scientific instruments with remote computers and archives are common scenarios for the use of GRID technology for scientific purposes. Besides scientific applications requirements for resource sharing and distributed computing applications arise for industry and commercial settings, including enterprise application integration and business to business partner collaboration over the internet. The same way that Web technology was developed for collaboration in a scientific community and then was adopted for e commerce applications, GRID technology now spreads to the e business sector [24, 25]. Various definitions of GRID exist in literature. In this work a description of the basic concepts and architecture of GRID, given by the founders of GRID computing Ian Foster and Carl Kesselman, is used as definition. Grid technologies support the sharing and coordinated use of diverse resources in dynamic VOs that is, the creation, from geographically and organizationally distributed components, of virtual computing systems that are sufficiently integrated to deliver desired QoS 2 [24]. Virtual Organizations (VOs) are explained in detail in section on the next page. 2 QoS = Quality of Service

28 14 Chapter 2: Basic Definition and Related Work Figure 2.1: Virtual Organizations. An institution can participate in one or more Virtual Organizations by sharing some or all of its resources. Actual institutions are represented as ovals and Virtual Organizations are shown in the upper left and right corner, marked with letters P and Q. The figure indicates that each institution can be member of different VOs. The institution in the left (in blue) participates in P, the right (dotted) in Q and the third is a member of both, P and Q. Access policies and conditions under which sharing occurs are described in quotes. For further details refer to the text. Source: Illustration taken from [25] Anatomy of the GRID Virtual Organizations (VOs) Virtual Organizations, which form the basis of GRID architectures are defined as a set of individuals and/or institutions who share resources amongst each other. Each institution may participate in different Virtual Organizations and share a clearly defined set of resources in a specific VO, so that members may collaborate and achieve a shared goal. (See figure 2.1) This sharing is far beyond simple file exchange and focused on direct access to computers, software, data and other resources required for collaborating in problem solving strategies in science as well as in the commercial sector, such as industry and engineering. Resources can be shared conditionally, which means that end users have full control about what is shared, who is allowed to share and under which condition sharing occurs [24, 25].

29 2.4 GRID Technology for Building Virtual Organizations 15 Figure 2.2: The GRID protocol architecture and its relationship to the Internet protocol architecture. Both, GRID and Internet protocol layers cover the range from network to application, so a mapping between them is possible. For further details refer to the text. Source: Illustration taken from [25]. Architecture description The GRID architecture defines the fundamental system components, their function and interaction required for Virtual Organizations to share resources amongst any potential participant. The GRID architecture is foremost a protocol architecture with the primary goal of enabling interoperability which defines basic mechanisms for negotiating, establishing, managing and exploiting resource sharing relation ships. A standards based open architecture facilitates extensibility, interoperability, portability and code sharing in heterogeneous environments. Similar to the ISO/OSI network model and the TCP/IP stack the GRID architecture defines layered protocols for managing local resources, connectivity, sharing single resources, coordinating multiple resources and applications. Based on those protocols Application Programming Interfaces (APIs) and Software Development Kits (SDKs) can be constructed [25, 24]. In the following the GRID protocol stack is described, which is shown along with the Internet protocol architecture in figure 2.2. Fabric: Interfaces to Local Control The Fabric layer is the lowermost layer of the GRID protocol stack and provides access to the local resources of an organization that can be shared using GRID technology. Fabric components implement the local resource specific operations such as computational resources, storage systems or network resources. Connectivity: Communicating Easily and Securely The Connectivity Layer facilitates communication and exchange of data between resources offered on the underlying Fabric layer. Therefore communication and authentication protocols are needed to securely transfer data over potentially insecure networks and verify the identity of users and resources.

30 16 Chapter 2: Basic Definition and Related Work Resource: Sharing Single Resources Based on the authentication and communications protocols of the Connectivity layer, the Resource layer is responsible for managing the condition under which a resource is shared. Therefore secure negotiation, initiation, monitoring, control, accounting and payment of sharing operations on individual resources is provided. Collective: Coordinating Multiple Resources The Collective Layer provides management functions for the interaction of collections of resources in a global sense. In this layer the sharing behavior of resources such as data replication is implemented, independent of the resources being shared. Applications The topmost layer of the GRID protocol stack is the application layer, which comprises the user applications which operate within a VO. Application Programming Interfaces and Software Development Kits are provided to build customized applications which use the functionality of underlying services and protocols. The protocol stack described above is not an abstract, theoretical description, but implemented in the GLOBUS Toolkit [27, 28] and used in many scientific and commercial products [25, 24] Physiology of the GRID The previous section focused on the resources being shared in Virtual Organizations, this section describes how the GRID actually works. GRID environments are constructed by an extensible set of GRID services aggregated in various ways to meet the requirements of VOs. Functionality is expressed as service, which describes the interaction of the previously explained resources, leading to a service oriented architecture (See section on page 12). A service is therefore defined as network enabled entity that provides some capability. How the GRID works is described as interaction of those services. Interoperability is the major problem addressed by GRID technology, the service oriented architecture allows this problem to be split into two subproblems. In a first step, challenges are analyzed, expressed as services and their interfaces are designed as service interfaces. In the second step, protocols are identified that can be used to invoke a particular service interface. In the following the most important GRID services, described in the Open GRID Service Architecture (OGSA) and implemented in the GLOBUS Toolkit, are outlined. The GLOBUS Toolkit is a community based, open architecture that uses and provides open source services and software libraries to support GRID and GRID applications. GLOBUS relies on and extends Web services [28]. Access to Services In GRID environments all tasks are performed by services, which demands for management tools. The GRID Resource Allocation and Management (GRAM) provides Web service interfaces for initiating, configuring, monitoring and controlling resources that provide specific services.

31 2.4 GRID Technology for Building Virtual Organizations 17 Access to Data Large data sets have to be accessed, integrated or replicated, which can be distributed over different institutions that collaborate in Virtual Organizations. Protocols are therefore provided to effectively and securely transfer data sets between institutions. Service Discovery and Monitoring Particularly in distributed environments that operate in a trans organizational context, service discovery is important to find services or resources that offer the desired functionality. Service monitoring helps to diagnose problems that are likely to occur in distributed environments due to network or component failure. Security Security concerns are important especially when resources and/or users span multiple organizations and locations. Owners of resources shared in Virtual Organizations must have fine grained control over what is shared under which conditions and who may access the resources. Besides encrypted data transfer aspects of authentication, authorization, access control and billing are absolutely vital. Security is a crucial aspect in GRID services and addressed in a variety of protocols. The high level security system combines techniques which comprise amongst many others establishing identity, applying policy, and tracking actions to protect resources and limit the impact of break in at end systems. GRID technology addresses problems that occur when multiple organizations collaborate, and offers tools to facilitate interoperation, that reaches far beyond the exchange of data in distributed environments [26, 28] Data GRIDs Data GRIDs are designed to handle and move large scale data sets within Virtual Organizations and between different institutions. High energy physics is one of their initial field of application, where terabytes or even petabytes of data, acquired in instruments such as the Large Hadron Collider (LHC), are transferred via highspeed network links. In Data GRIDs basic GRID protocols and services are use to build high level tools that provide for fast, efficient and secure transfer of large volume data. Data GRIDs are defined as: Data Grid is an emerging technological paradigm for the seamless access, via virtualized middleware, to heterogeneous and distributed ensembles of data storage resources [29]. Besides effective file transfer Data GRIDs provide high level tools for the management of replicated data sets distributed over different systems. Tools for handling replicated data sets are provided by two services, the Replica Location Service (RLS) and the Data Replication Service (DRS). A distributed registry is provided by the RLS for discovering sites where copies of desired

32 18 Chapter 2: Basic Definition and Related Work data reside. Web service interfaces for the management of files and data sets, distributed across different sites are provided by the DRS. Data Grids cover efficient file transfer and replica management in heterogeneous environments by the use of basic GRID protocols and services, but independent of the content of the transferred or replicated data. Since particularly the handling of medical data has special requirements and is closely bound to their contents, Healthgrids are introduced in section 2.5 with the aim to adopt GRID technology for the use in the healthcare domain. 2.5 Healthgrids The idea of exploiting the benefits of GRID technology in healthcare is not new, GRID services are expected to provide new opportunities for working on heterogeneous and distributed resources as they are usually found in healthcare institutions. The Healthgrid Association founded in the beginning of this decade, has the aim to outline the concepts, benefits and opportunities of GRID technology to decision makers and CIOs in the healthcare sector. The overall goal is to improve quality, cost efficiency and access to health related data for patients and health professionals. Definitions and concepts introduced in this section are based on the summary of the Healthgrid whitepaper and the article Interoperability and HealthGRID from Bescos [30, 31]. According to the Healthgrid Association Healthgrids are defined as follows: Healthgrids are Grid infrastructures comprising applications, services or middleware components that deal with the specific problems arising in the processing of biomedical data. Resources in Healthgrids are databases, computing power, medical expertise and even medical devices. Healthgrids are thus closely related to ehealth [30]. Five distinct fields of application have been analyzed where Healthgrids are seen as opportunity to provide access to distributed, dynamically assembled medical data sets in trans institutional context, huge scale analysis of medical data and many others: Medical imaging and image processing: Analysis, storage and processing of large volume data acquired by imaging devices. Modeling the human body for therapy planning and computer assisted interventions: Computational intensive simulation of organs and the construction of virtual atlases for therapy planning based on previously acquired images. Pharmaceutical GRIDs: Data mining and knowledge management as well as the development of algorithms in the process of drug development with high computational complexity.

33 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 19 Genomic Medicine GRID: The connection of bio Informatics and medical Informatics for realizing the concept of genomic medicine demands for the integration of various distributed data sets and for sophisticated algorithms in the field of genomics and proteomics, which can be supported by GRID technology. Although the Healthgrid association has been founded years ago, the shift from GRIDs to Healthgrids is still in it s initial phase. Security and accountability are the main issues which are still unsolved. A lot of effort has been placed on security in GRID development, however according to the authors of the Healthgrid whitepaper GRID security features are sufficient for addressing computational problems in healthcare. Security issues are still not adequately solved for using GRID technology to build a generic platform for all e-health actors. Particularly in a virtual federation of personal data distributed over different, independent institutions privacy issues are still insufficiently solved. The Healthgrid whitepaper published by the association summarizes the current status of GRID technology with special emphasis on healthcare related aspects. A critical view on today vastly unsolved issues such as protection of patient related data and auditing is given [30, 31, 32]. 2.6 Relevant Technical and Communication Standards in the Context of SEHRs Many different standardization organizations on a national, European and international level have proposed different standards for Electronic Health Records with the aim to facilitate interoperability between different record types. Definitions introduced in the entire section 2.6 are based on the article A survey and analysis of Electronic Healthcare Record standards by Eichelberg [33] and the full version of the standard published by the respective standardization organization. Some of the here described standards focus on the entire Electronic Health Record, others only on parts, such as document storage formats or data exchange. Data types and information models may be converted between the most prevalent standards, however moderate effort is needed. In the following, the most relevant standards and initiatives concerned with the implementation and operation of Shared Electronic Health Records are described openehr openehr is an international non profit organization with the aim to improve healthcare in the information society by making the interoperable, life long Electronic Health Record a reality. The openehr specification is not a standard as such, but relies on, and extends common standards such as ISO, HL7 and CEN. The specification is developed and maintained by the openehr Foundation, which is a non profit organization with the aim to: [... ] enable the development of open specifications, software and knowledge resources for health information systems, in particular electronic health record (EHR) systems. It publishes all its specifications, and builds reference implementations of them, as open source software. It also develops archetypes and a terminology for use with EHRs [34].

34 20 Chapter 2: Basic Definition and Related Work The fundamental concept introduced by the openehr initiative is the archetype concept to construct future proof Health Information Systems [35]. Archetypes define valid information structures, which are basically constraints of all theoretically possible data types. The archetype model is a two level methodology to separate a general model that is static over time (Information Level) from healthcare and application specific content which is subject to frequent changes (Knowledge Level). Archetypes can be used as starting base for developing Health Information Systems and are conceptually similar to HL7 CDA Templates. Archetypes can be regarded as instances in object oriented programming languages and can be modified using graphical tools, without the need to change database scheme, reference or archetype models [33, 35]. Classification and Evaluation of Applicability for SEHRs Most emphasis has been placed on developing OpenEHR in Australia and thus it is the most widespread in this country. OpenEHR is an EHR data standard, which provides flexible means for defining interoperable Electronic Health Records. The concepts of dividing the rather static Information Level model from the dynamic Knowledge Level model which can be subject to frequent changes, is expected to provide for a future proof data standard for Shared Electronic Health Records. In contrast to the Clinical Document Architecture (CDA) introduced in section on page 23 OpenEHR is a more generic approach, but less widespread in clinical applications. Fortunately, data structures of OpenEHR and CDA are currently being harmonized, which makes the process of choosing the correct standard less critical. OpenEHR is a data standard and does not regulate how medical data are to be transmitted between institutions participating in a SEHR. Thus, for Shared Electronic Health Records with interoperability as one major goal, both, data standards and transmission standards have to be applied. IHE Integration Profiles introduced in section on page 27 could provide adequate recommendations for the implementation of a HIS architecture, which in turn leads to standardized transmission of medical data such as via Web service invocations European Norms (EN) and ISO Standards On a European level standards for EHRs are proposed by the European Committee for Standardization (CEN 3 ). The European Norm (EN) series, proposed by the CEN/TC 251, which is the technical committee on Health Informatics of the European Committee for Standardization is an important standard for Electronic Health Records in Europe. The aim of the TC 251 is to enable interoperability and compatibility between different, indepen- 3 French: Comité Europééen de Normalisation.

35 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 21 dent Health Information Systems by providing standards for a modular design. Requirements comprise an information structure that supports clinical and administrative procedures as well as technical methods to ensure a high level of interoperability, security and quality [33]. In 2001 the standard was revised due to limitations discovered during implementation, the new version is now planned to be introduced into the international ISO/TC 215 EHR standard. The ISO standard now comprises five parts: 1. Reference Model 2. Archetype Interchange Specification 3. Reference Archetypes and Term Lists 4. Security Features 5. Exchange Models The first part, which is currently the only stable one, consists of four packages that describe aspects relevant for the exchange of EHR extractions between Health Information Systems. In the packages data structures, demographics that provide a minimal data set to identify persons, software agents and devices, access control as policies and messages for EHR communication are defined. Archetypes are the second important building block. As explained in section on page 19 archetypes describe clinical concepts as constraint rules restricting possible data types, values and relationships of EHR components. In Part 2 the Archetype Description Language (ADL) is defined as formal language for describing Archetypes related to the EHRcom reference model, Part 3 will contain a library of archetypes for different clinical purposes [33]. The revised standard is still under development, so it is unclear whether the above mentioned drawbacks concerning implementation have been resolved. However, due to harmonization with HL7 and the openehr archetypes, improved usability and acceptance over the pre standard is expected [33]. Classification and Evaluation of Applicability for SEHRs As the above described standards are European Norms which have been developed in Europe most implementations originated in European countries. Based on the limitations discovered in the European standard ENV 13606, the revised version is expected to offer important recommendations for a Shared Electronic Health Record. Particularly Part 4 (Security Features) and 5 (Exchange Models) should support the development

36 22 Chapter 2: Basic Definition and Related Work of interoperable SEHRs. Unfortunately those parts are only at the time of writing a pre standard, which means that the standard might change in the future and implementations in clinical applications are currently rare. After the ISO/TC 215 becomes a stable standard it could provide both, a data and a transmission standard. Part 1 (Reference Model) is fortunately harmonized with CDA (See section on the facing page) and OpenEHR (See section on page 19), which makes the selection of the data standard less critical Health Level 7 (HL7) HL7 is an organization accredited by the American National Standards Institute (ANSI) for creating standards in the healthcare sector. The name HL7 refers to the highest level of the ISO/OSI network model the application level, which is responsible for communication between applications. HL7 is an international community of healthcare subject matter experts and information scientists collaborating to create standards for the exchange, management and integration of electronic healthcare information [36]. HL7 Messaging Standards HL7 defines a Messaging Standard used for the exchange of messages in clinical settings for patient administration and transmission of results, for example. Therefore a variety of data types, as well as message and event types are defined. Currently three versions exist, where version 1 and 2 rely on text messages in a sequential representation and version 3 uses XML for more structured messages. Version 3 (V3) addresses drawbacks found in previous versions mainly caused by its flexibility with too many optional data elements, which lead to a variety of vendor specific implementations reducing interoperability. V3 is based on a reference (e.g. data) model, that limits optional parts and provides for improved interoperability and the ability to certify vendors conformance. Version 3 uses an object oriented development methodology and a Reference Information Model (RIM) (See section 2.6.3) to create messages [36]. The Reference Information Model The HL7 Reference Information Model (RIM) is the root of all information models and structures developed for the HL7 V3 and thus the ultimate source of all information content, that provides a static view of the information needed by the standard. The RIM is an abstract model expressed in the Unified Modeling Language (UML) (See section on page 45) with HL7 specific

37 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 23 extensions including class and state machine diagrams and is accompanied by use case models, interaction models, data type models, terminology models and others, to reflect the requirements of the HL7 standard. The HL7 RIM is also the information model which the Clinical Document Architecture (CDA) (See section 2.6.4) relies on. Classification and Evaluation of Applicability for SEHRs HL7 was originally developed as message based standard in North America for the exchange of medical data within the boundaries of an institution. As up to version 2 in HL7 neither a data model nor transmissions are standardized, limited applicability for cross institutional exchange of medical data is expected. However, since HL7 is widely used in clinical applications it might be of importance in connecting Hospital Information Systems to a SEHR architecture. HL7 version 3 provides a data model which the Clinical Document Architecture (CDA) (See section 2.6.4) originates from. For this reason the HL7 Reference Information Model (RIM) is expected to provide a flexible data standard for Shared Electronic Health Records The Clinical Document Architecture (CDA) The Clinical Document Architecture, which is not a full EHR standard, since it only defines the format of clinical documents for exchange, has been developed by the HL7 organization as: [... ] document markup standard that specifies the structure and semantics of clinical documents for the purpose of exchange. A clinical document is a documentation of clinical observations and services [... ] A CDA document is a defined and complete information object that can include text, images, sounds, and other multimedia content [37]. CDA documents are encoded in XML and serve the purpose to be machine interpretable while remaining readable for humans. They derive their machine processable meaning from the HL7 Reference Information Model (RIM) (See section on the facing page) and use the HL7 Version 3 data types. CDA documents contain a header and a body. The header is entirely structured, whereas the body is only partly structured and may contain free text. The specification is available in two versions, whereby Release 2 (2.0) has been approved as ANSI standard in May CDA Release 1 The Release 1 is organized into three levels, in each level iteratively more structure to the document is added [38].

38 24 Chapter 2: Basic Definition and Related Work Level 1 The document header is derived from the HL7 RIM and defines the semantics of each entry in the document. Level 1 only defines a standardized header, but allows freetext in the body, for that reason Level 1 documents are only interoperable for human readable content. Level 2 Level 2 introduces constraint rules for the structure and content of the document and thereby increases machine interoperability. As opposed to Level 1 a fine grained structure of the content is provided. Level 3 An entirely structured document that is fully machine readable is only possible with CDA Level 3. The semantics of each entity is expressed as unique code in a coding system or vocabulary such as SNOMED [39] or LOINC [40]. CDA Release 2 The basic model of CDA with structured documents of different granularity remains essentially unchanged. Although Release 2 does no longer distinguish levels, it is fully compatible with Release 1. Through this approach the migration of free text to structured documents is expected to be facilitated. CDA Templates are introduced as constraint rules similar to levels of Release 1 to define different granularity of structuring. Unconstrained CDA documents correspond to Release 1 Level 1 documents. Section level Templates, which apply constraint rules for each section of the document correspond to Release 1 Level 2. Entry level Templates containing data types of each element correspond to Release 1 Level 3. The basic improvement of Release 2 is that header and body are fully RIM derived and provide much richer assortments of entries that can be used in CDA sections. So the content can be formally expressed to the extent that is modeled in the RIM. In listing 2.1 on the next page a basic Release 2 CDA document is shown. A CDA document starts with the <ClinicalDocument> element, in which the header, that provides metadata about authentication, the patient, involved providers and others, is included. The body is included in the <structuredbody> element and contains the clinical report, that can either be structured or a document of any format included as BASE64 encoded binary data. The structured body can be divided into recursively nestable document sections, wrapped by the <section> Element. The section can contain a single narrative block (free text), wrapped by the <text> and any number of CDA entries and external references. The narrative block provides for human readability and can be rendered by the application using XML Stylesheets. Machine readability is facilitated by the structured content encoded in a common coding scheme, wrapped by the <observation> element. A coding scheme or a code system can be declared for each observation. The CDA format is currently implemented by many vendors, partly facilitated by the existing experiences with HL7. Although the CDA is strictly speaking not an EHR standard, since it only specifies the document format, if forms an important part of the EHR. The Clinical Document Architecture is currently being harmonized with equivalent structures in EN and openehr. CDA is a subset of the EN Reference Model, which makes EN most likely compliant with CDA Release Two [33, 37].

39 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 25 1 <ClinicalDocument> 2 {... CDA Header... } 3 <structuredbody> 4 <s e c t i o n> 5 <t e x t>...</ t e x t> 6 <o b s e r v a t i o n>...</ o b s e r v a t i o n> 7 <substanceadministration> 8 <supply>...</ supply> 9 </ substanceadministration> 10 <o b s e r v a t i o n> 11 <e x t e r n a l O b s e r v a t i o n> </ e x t e r n a l O b s e r v a t i o n> 13 </ o b s e r v a t i o n> 14 </ s e c t i o n> 15 <s e c t i o n> 16 <s e c t i o n>...</ s e c t i o n> 17 </ s e c t i o n> 18 </ structuredbody> 19 </ ClinicalDocument> Listing 2.1: Basic CDA document. The CDA document is composed of header and body, which can contain sections with free text and observations encoded in a common coding scheme. For further details refer to the text. Classification and Evaluation of Applicability for SEHRs As the Clinical Document Architecture is based on the HL7 Reference Information Model (See section on page 22) which originated in North America, CDA also has its origin in those countries. However in Europe many applications rely on this standard, so the CDA is expected to be recommended as EHR standard for Austria. According to the Austrian e-health feasibility study introduced in section on page 34, the Clinical Document Architecture is the preferred data standard for a Shared Electronic Health Record. CDA seems to be a fairly advanced data standard that has been approved in clinical applications and which provides for interoperable Electronic Health Records. Human and machine readability of CDA documents is seen as the basic advantage of this standard. As Release 2 allows for semantic interoperability where structure and content can be constrained by templates, most benefit for SEHRs is expected by this version. CDA furthermore offers different levels of structuring, where at least section level templates, which are expected to provide machine interoperability are seen as reasonable for SEHRs. Fortunately openehr, the CEN and ISO/TC 215 standard are currently being harmonized, which facilitates a later conversion of the data model between each of them. As CDA is only a data standard, which does not define how documents are to be transmitted,

40 26 Chapter 2: Basic Definition and Related Work a transmission standard is needed to define ways of exchanging medical data. Integrating the Healthcare Enterprise introduced in section provides a variety of transmission standards which could be used together with CDA for building interoperable Shared Electronic Health Records in a trans institutional context Integrating the Healthcare Enterprise (IHE) The IHE is a non profit initiative founded in 1998 with working groups in North America and Europe with the aim to stimulate integration of health information systems. IHE is an initiative by healthcare professionals and industry to improve the way computer systems in healthcare share information. IHE promotes the coordinated use of established standards such as DICOM and HL7 to address specific clinical needs in support of optimal patient care. Systems developed in accordance with IHE communicate with one another better, are easier to implement, and enable care providers to use information more effectively [... ] [41]. IHE is strongly supported by industry and leading manufacturers in the healthcare sector such as Agfa, Philips Medical Systems and Siemens Medical Solutions. New standards are not developed by the IHE, but the initiative selects and recommends appropriate standards for specific use cases. IHE Actors and Transactions IHE Actors are information systems that produce, manage or act on information, where an information system can support one or more actors. The actions carried out by actors are referred to as transactions, which are message based exchanges of infomation based on established standards such as HL7, DICOM or Web services. Technical Framework The Framework is based on well established standards and defines restrictions and specific implementations of those standards to facilitate system integration and appropriate sharing of medical information to support optimal patient care. The Technical Framework provides a fully implementable set of specifications for standards based transactions amongst systems for specific workflows and integration capacities. Integration Profiles The Profiles provide a set of IHE actors and transactions for specific use cases and offer a convenient way to implement functionality defined in the Technical Framework without the need of detailed knowledge about actors and transactions. Therefore actors and transactions are specified which are required for specific workflows or communication scenarios.

41 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 27 Relevant IHE Integration Profiles A variety of IHE Integration Profiles exists, which can be implemented independently to support interoperability in specific clinical settings. This section addresses the most relevant profiles for a Shared Electronic Health Record. The complete specification of profiles along with their actors and transactions is published by the IHE organization in the IT Infrastructure Technical Framework [42]. Cross Enterprise Document Sharing (XDS) The XDS Integration Profile provides a standards based specification for managing and sharing medical documents between healthcare enterprises and therefore specifies actors and transactions relevant for a SEHR. Procedures for storage, registration, distribution and institution independent retrieval of medical documents are addressed by this Profile. Independent healthcare institutions willing to cooperate by using a common set of policies are defined as clinical affinity domains, whereby a specific institution can belong to one or more domains. Policies for patient identification, how their consent to electronic data processing is obtained, access control and structure of clinical infomation is defined within a clinical affinity domain. Documents in XDS are content neutral and can be of any format, either textual (independent whether structured of free text) or multimedia content. For a clinical affinity domain an infrastructure consisting of five different actors for document storage, registration and patient identification is proposed by the XDS Integration Profile to create a longitudinal record of patient information in the context of a Shared Electronic Health Record (See figure 2.3 on the next page). In the following paragraph the IHE XDS actors are explained in short: Document Source Documents are produced and published at the Document Source. This actor sends documents along with metadata to the Document Repository, where documents are persistently stored and metadata published to the Document Registry actor in a second step. Document Consumer The Document Consumer actor searches for specific documents in the Document Registry and retrieves selected documents from one or more Document Repository actors. Document Registry Document specific metadata are registered in the Document Registry along with a link to the physical location of the document at Document Repository each time a document is published in a clinical affinity domain. The Registry actor is queried by the Document Consumer for documents meeting specific criteria and responds with the link to the requested Document at the Repository after enforcing access policies.

42 28 Chapter 2: Basic Definition and Related Work Figure 2.3: The IHE XDS Integration Profiles specifies 5 relevant actors for sharing clinical information between healthcare enterprises (light blue boxes). Documents are produced in the Document Source and stored in the Document Repository, their metadata are published to the Document Registry. A unique patient identifier is obtained by the Patient Identity Source. Documents are accessed by the Document Consumer. Interactions with actors are defined as Transactions (black arrows with dark blue caption). For further details refer to the text. Source: Illustration taken from [42]. Document Repository The Document Repository is responsible for the persistent storage of documents and for registering metadata at the Document Registry actor. Stored documents are accessible by the Consumer actor via a link that is published to the Registry. Technically the link consists of an URI with a globally unique identifier based on the OSI Object Identification (numeric form) as defined by the ISO 8824 standard. Patient Identity Source The Identity Source actor is responsible for providing a unique identification for patients and facilitates the validation of identifiers. For the interaction of the above described actors the IHE XDS Integration Profile specifies a large set of transactions, which comprises operations for providing and registering documents

43 2.6 Relevant Technical and Communication Standards in the Context of SEHRs 29 and document sets, querying the Registry for specific documents and retrieving documents from the Repository. A detailed description of the transactions can be found in the IT Infrastructure Technical Framework [42]. Audit Trail and Node Authentication (ATNA) The purpose of the ATNA Integration Profile is to provide patient information confidentiality, data integrity and user accountability. In this Profile, a Protected Health Information (PHI) is defined as a patient identifiable information record, which may be accessed by users or exchanged between systems. The key features of the ATNA Profile are authentication of the user, audit record generation (events with PHIs involved are recorded and transmitted to a repository for later analysis) and authentication of nodes during communication. Therefore all systems that are members of the secure domain must implement a Secure Node actor for the ATNA Profile. Cross Enterprise User Authentication (XUA) The XUA profile provides facilities for secure user authentication in a trans institutional context and extends the Enterprise User Authentication Profile (EUA) defined in the IT Infrastructure Technical Framework [42]. This Profile provides user authorization mechanisms based on the Extensible Access Control Markup Language (XACML) especially applicable for affinity domains specified in the XDS Integration Profile (See section on page 27). The XUA Integration Profile is an extension of the IHE IT Infrastructure Technical Framework specification and is still not fully integrated in the specification. Modifications of transactions defined in the XDS Profile are specified in the XUA Profile to provide for secure user authentication across institutional boundaries. A detailed specification of this Profile is given in the IHE IT Infrastructure Technical Framework Supplement [43]. Classification and Evaluation of Applicability for SEHRs The IHE initiative was founded by various manufacturers primarily of the radiology sector, for devices and systems such as the Radiological Information System (RIS) and the Picture Archiving and Communication System (PACS). Particularly in radiology, Digital Imaging and Communications in Medicine (DICOM) is a well established data standard, which virtually every vendor relies on. So the primary goal of IHE is not to standardize the data format, but rather the way the devices communicate with each other. So, as opposed to the previously mentioned standards IHE provides recommendations for transmission of data independent of their format. The Cross Enterprise Document Sharing Profile (XDS) is a rather new Profile which provides detailed recommendations for communication between institutions involved in a SEHR. For that reason the XDS Profile along with an appropriate data standard is particularly suitable for Shared Electronic Health Records.

44 30 Chapter 2: Basic Definition and Related Work Unfortunately since this Profile is rather new, implementations in clinical applications are fairly rare and it is not certain that the most important communication scenarios are covered by XDS. On the other hand, since applications are only approved IHE conformant after compliance to the Profile has been proved, a high level of interoperability is expected to be achieved. 2.7 Security Concepts for Shared Electronic Health Records Role Based Access Control (RBAC) Role Based Access Control (RBAC) was developed in the late 1990 as a concept to assign effective permissions for access control based on the role of an individual, which is generally the profession of a person. Roles are assigned specific permissions, so Role Based Access Control is the decision of permissions based on the role a user is assigned to. Permissions assigned to a role tend to change less frequently than assignment of users to roles do. Therefore management of permissions based on roles is simpler than on individual permissions. Sandhu describes RBAC as follows: A role is chiefly a semantic construct forming the basis of access control policy. With RBAC, system administrators create roles according to the job functions performed in a company or organization, grant permissions (access authorization) to those roles, and then assign users to the roles on the basis of their specific job responsibilities and qualifications [44]. For SEHRs Role Based Access Control is particularly important since different actors as identified in section 4.1 on page 69 such as patients, medical professionals, pharmacists and scientists require different levels of access permissions, which can easily be modeled in RBAC by assigning an appropriate role to each actor Attribute Certificates Attribute Certificates are used for role and context based authorization. They specify certain attributes of a user such as group membership in a digital certificate. Attribute Certificates addressed by RFC 3281 are defined as follows: X.509 public key certificates (PKCs) [... ] bind an identity and a public key. An attribute certificate (AC) is a structure similar to a PKC; the main difference being that the AC contains no public key. An AC may contain attributes that specify group membership, role, security clearance, or other authorization information associated with the AC holder [45].

45 2.8 Relevant Initiatives and Legal Requirements in the Context of SEHRs The Austrian e-card Since the end of 2005 virtually every Austrian citizen with a valid social insurance status is equipped with an electronic health insurance card (e-card). The e-card serves as cryptographic chip card for verifying the entitlement to benefits of the Austrian health insurance system. No medical data are stored on the chip card. A definition of the e-card and the e-card system is given by the e-card operating company SVC 4 : The Main Association of Austrian Social Security Institutions has been entrusted by law with the introduction and operation of the Electronic Administration System. The aim of this is to support administrative processes between insured people, employers, doctors and hospitals as well as Social Security Institutions. The first step has been the replacement of health insurance vouchers by a smart card [... ] The main characteristic of the Austrian e-card is its keycard principle. Consequently, the smart card does not contain software functions, it only holds identification data which represent the access key for applications. 2.8 Relevant Initiatives and Legal Requirements in the Context of SEHRs Legal Requirements for the Exchange of Patient Data in Austria For the exchange of medical data across institutional boundaries several Federal Laws exist in Austria which should ensure the highest possible degree of privacy. In this section the most relevant acts are mentioned and a legal framework is introduced for the exchange of patient data according to those laws. Trans institutional exchange of medical data in Austria is affected by the following Federal Laws including their amendments: Bundesgesetz über den Schutz personenbezogener Daten Datenschutz Gesetz (Federal Act on data protection). Privacy regulation for electronic data processing [46]. Bundesgesetz über elektronische Signaturen Signatur Gesetz (Federal Act on digital signatures). Regulation for digital signatures and trust centers as Trusted Third Parties (TTP) in a Public Key Infrastructure (PKI) [47]. Bundesgesetz über Regelungen zur Erleichterung des elektronischen Verkehrs mit öffentlichen Stellen E Government Gesetz (Federal Act on Provisions Facilitating Electronic Communications with Public Bodies) Regulation for secure authentication exchange of data with public bodies [48]. 4 German: Sozialversicherungs Chipkarten Betriebs und Errichtungsgesellschaft m.b.h.

46 32 Chapter 2: Basic Definition and Related Work Bundesgesetz über die Ausübung des ärztlichen Berufes und die Standesvertretung der Ärzte Ärztegesetz (Federal Act on medical professionals). Regulation on the professionalism of medical doctors [49]. Bundesgesetz über die Allgemeine Sozialversicherung Allgemeines Sozialversicherungsgesetz ASVG (Federal Act on social insurances). Regulates general social insurance, health insurance and retirement pension insurance for citizens employed in Austria [50]. Bundesgesetz, mit dem das Bundesgesetz über Krankenanstalten und Kuranstalten geändert wird Gesundheitsreformgesetz. (Federal Act on Reformation of existing laws related to healthcare). Amendment and extension of health related acts to support electronic data processing in healthcare [51]. Bundesgesetz betreffend Datensicherheitsmaßnahmen beim elektronischen Verkehr mit Gesundheitsdaten und Einrichtung eines Informationsmanagement Gesundheitstelematikgesetz (Federal Act on Health telematics). Regulates minimum standards for data protection for the electronic exchange of health related data [52]. Trans institutional exchange of medical data is only possible in compliance with the above mentioned Federal Acts. In figure 2.4 on the facing page a 4 step model for trans institutional inquiries of medical findings is represented which has been worked out as legal requirement for automated, reciprocal medical inquiries amongst health service providers. The adherence to the applicable law is guaranteed by the following four steps, where the written consent of the patient is a strict prerequisite. In the case of an inquiry the first step amongst the communicating partners is the identification of the patient. If this allocation could be made, then a list of the patient s visits at the concerning health service provider can be requested and transmitted. In a third step the summarizing document pertaining to a certain visit, e.g. in form of a doctors or patients letter, can now be requested and transmitted. In step 4 further medical data (e.g. related reports or images) can be requested and transmitted [53].

47 2.8 Relevant Initiatives and Legal Requirements in the Context of SEHRs 33 Figure 2.4: Graphic representation of the 4 step model for medical inquiries. Through fully or partially automated sequential step by step handling of these four levels a reciprocal medical inquiry between health service providers under preservation of data protection regulations can be realized. For further details refer to the text. Source: Illustration taken from [53] e-health Action Plan By the end of April 2004 the European Commission developed the e-health action plan to deliver better quality of healthcare by making use of information and communication technologies (ICTs). e-health seamlessly integrates in the European Strategy for eeurope for building modern public e-business services. The plan sets out a roadmap for the use of new technologies and services to achieve better quality in healthcare and optimum interaction between healthcare professionals and the general public. Therefore a stepwise approach is defined to identify amongst many others a common approach for patient identification, interoperability standards and Electronic Health Records. The aim of the action plan is to have a Europe wide e-health strategy developed by the end of this decade, which allows to measure the impact of e-health technologies on the quality and efficiency of services, as well as overall productivity. To achieve this goal Member States are called upon to develop national and regional e-health strategies [54]. For this reason a national e-health initiative was founded in Austria in 2005.

48 34 Chapter 2: Basic Definition and Related Work The Austrian e-health Feasibility Study In accordance to the requirements of the European e-health action plan the e-health Initiative (EHI) was founded in 2005 by the Austrian Federal Ministry for Health as a strategy to organize the development of the health system towards an integrated patient centered care on a long term basis. In May 2006 a feasibility study concerning the implementation of an Electronic Health Record in the Austrian healthcare system was mandated by the EHI and their results were presented by the end of January The aim of the feasibility study 5 was the provision of a basis for decisions concerning the implementation of a nation wide Electronic Health Record. The feasibility study comes to the result that an Electronic Health Record should be implemented in Austria following a stepwise approach. The study gives clear recommendation about technology and standards to be used. Thus, the IHE XDS Integration Profile is proposed as transmission standard to ensure vendor independent interoperability between different systems. The Clinical Document Architecture (CDA) is proposed as data standard. For authorization an e-health Directory Service (ehvd 6 ) is to be installed which offers a directory of all services providing healthcare including their assigned roles. The feasibility study furthermore comes to the result that a legal framework for an Electronic Health Record currently does not exist in Austria and has to be created in order to comply with national data protection laws [55]. 2.9 Regional Project health@net The health@net project was founded in 2002 as a research project between the University for Health Sciences, Medical Informatics and Technology (UMIT) and the Tyrolean Hospital Holding Company(TILAK 7 ) with the below mentioned goals. Health@net now has 17 project members and several partners on a national level such as the Leopold Franzens University Innsbruck, the Vienna Hospital Holding Company(KAV 8 ) and the Austrian GRID [13]. The goal of health@net is to build up a regional, consistent and comprehensive healthcare network, which replaces the paper based transmission of documents and thus eliminates the media cracks of medical documents which have to be transferred to other healthcare facilities. This results in the overall goal of establishing a regional, trans institutional patient centered Shared Electronic Health Record to provide relevant medical information on demand and after successful authorization. Therefore, a strategy for a stepwise implementation has been worked out, where as a first step discharge letters are transmitted to existing Austrian healthcare net- 5 Commonly known in Austria under the German term ELGA Machbarkeitsstudie. 6 Commonly known in Austria under the German term e-health Verzeichnis Dienst. 7 German: Tiroler Landeskrankenanstalten GmbH. 8 German: Wiener Krankenanstaltenverbund.

49 2.10 Approaches for Implementations of SEHRs in an International Context 35 works via cryptographically secured messages and simultaneously made available in an improved layout via a secure Web portal. Steps two and three encompass the development of a Shared Electronic Health Record in a trans institutional context by the use of distributed network architectures [56] Approaches for Implementations of SEHRs in an International Context International projects with the aim to implement a trans institutional, patient centered Shared Electronic Health Record are described as related work in this section. A variety of international projects currently exists, claiming to provide a solution for SEHRs, the most common ones with appropriate results of implementation published in literature are introduced here. Although European and international standards for communication in healthcare exist (See section 2.6 on page 19), none of the implementations of the following projects mentioned below is entirely compliant with those standards. This is particularly true for transmission standards. A potential reason might be that applications have not been designed with interoperability with other records in mind or that existing standards insufficiently covered their requirements. Especially transmission standards such as IHE Integration Profiles introduced in section on page 26 are rather new and the lack of experience in implementation could be a possible reason for them not being used. Those applications however generally stick to well established Web standards such as Web services Sundhed.dk In 2003 the Danish Pharmaceutical Association developed a Web portal known as Sundhed.dk 9 10 based on a SEHR infrastructure for improving the quality and access to healthcare in Denmark. The idea behind the Web portal was to bridge the gap between the country s government controlled healthcare system, private physicians, pharmacies and other organizations, and create an interactive site where patients and clinicians could communicate and access vital healthcare information. The Sundhed.dk portal was honored with The Wall Street Journal Europe s prestigious European Innovation Award, which recognizes new ideas, methods or technologies that improve quality of life or enhance productivity [57]. 9 The Danish word Sundhed stands for healthcare. 10

50 36 Chapter 2: Basic Definition and Related Work Akteonline.de In 2001 the development of an Electronic Patient Record (EPR) started in Germany with the aim to give the patient the possibility to manage his personal medical record via the internet independent of place and time. Akteonline is a comprehensive EHR which comprises medical data in a provider oriented view, which logically groups clinical information added by a particular healthcare provider, and non professional information such as wellness and diet related data. Patients can register at the Akteonline Web portal 11 and either manually enter medical information or have relevant data directly transmitted via secure links to the record by selected hospitals that are connected to the infrastructure. Akteonline uses a centralized architecture for data storage in the CDA format with high availability measures implemented. A modular extensible architecture is built as a multi layered Java Web application. A variety of articles have been published in the context of Akteonline, the portal was honored with national and international awards amongst them, the e-health Award 2001 for an Innovative and advanced ehealth Concept for the hospital [9, 10, 58] e-consent based Shared EHR System Architecture A distributed EHR architecture has been developed by the Technical University of Braunschweig to support electronic consent of patients to EHR operations. In an initial project the system is deployed in the Braunschweig Medical Center, two further hospitals and several practices. The architecture is highly distributed and uses separate registry and repository services for documents and corresponding metadata. The patient has full control over trans institutional transmission of his medical data via an electronic consent, which is a digitally signed artefact issued by the patient. This artefact is furthermore used to determine actual access permissions by evaluating structural roles [59] Personal Internetworked Notary and Guardian (PING) As opposed to the above mentioned projects the PING approach is a reference implementation for a SEHR without a publically useable Web portal (a prototype Web portal solution has been successfully tested). The aim of the PING project is to give patients full control over their medical data in a lifelong Shared Electronic Health Record. Existing standards and technologies including the Web and public key cryptography are used to ensure privacy and give the patient the possibility to allow access for other authorized parties. The PING approach uses a modular distributed open source architecture, where documents can 11

51 2.10 Approaches for Implementations of SEHRs in an International Context 37 be stored at arbitrary location in a standardized XML based format. Different layers are defined for data storage and communication. A communication protocol (Ping talk) is introduced for the exchange of medical data via Web service like XML messaging. A prototype implementation developed in Java Servlets has been successfully tested. Since 2004 the Canadian National Research Council is adopting PING as a model for a personally controlled health record. The prototype called CitizenHealth is implemented for Canadian citizens with diabetes. Evaluation revealed that the architecture is appropriate for the given requirements and can be used in a larger context [60, 11] Historia Digital de Salud del Ciudadano (Diraya) The Diraya project, which etymologically signifies knowledge, was initialized by the Andalusian Ministry of Health Servicio Andaluz de Salud (SAS) to provide a citizen s personal electronic health record in Andalusia. Diraya aims to integrate all available medical information of a user in different systems to increase accessability and improve quality of care. The EHR provided by Diraya consists of different components, which are available for authorized healthcare professionals in different contexts, such as modules for user authentication, managing appointments and access to clinical data. Diraya is based on a vastly centralized architecture for storing different sets of medical data, for managing user data and unique patient identifiers. XML based interfaces are used for inter module communication as well as for connecting external systems of different healthcare providers to the Diraya EHR. Diraya is deployed all over Andalusia and due to strong support from the Ministry of Health widely used in the healthcare sector. The system which was designed to provide comprehensive medical information for healthcare professionals, but not for the patient himself, covers 100% of Andalusian citizens with health insurance and 96,76% of the registered population by January 2004 [61, 62] Comparison and Evaluation of Related Implementations Projects introduced in the sections before claim to offer solutions for Shared Electronic Health Records. As far as functionality is concerned the Danish Sundhed.dk is considered the most comprehensive implementation. The record covers needs of important healthcare actors as well as citizens/patients, which facilitates, for example, the online arrangement of appointments. However, data protection and security seems not to be a big concern. The e-consent based Shared EHR System Architecture is a highly distributed and patient centered approach which supports the pull paradigm (fetch information as required) for message

52 38 Chapter 2: Basic Definition and Related Work exchange instead of the still commonly used push paradigm (transmitting data to the receiver). However, this project is still in an early phase. Akteonline is a rather patient centered solution, where each citizen/patient can manage his own record. Although departments of the Münster University Hospital 12 directly feed selected medical data to the record, generic, standardized integration with clinical applications is considered poor. For that reason medical data has to be entered manually, which is expected to result in low end user acceptance. As opposed to Akteonline, Diraya is entirely targeted towards healthcare institutions, without providing access for patients. Applications in different healthcare institutions are seamlessly integrated in the record. Sundhed.dk and Akteonline have a publically available Web portal, whereas Diraya modules are integrated in Information Systems of Hospitals and medical specialists or General Practitioners (GPs). As PING provides a reference implementation of an architecture a Web portal is not operated by public facilities. An analysis of available literature about the above mentioned projects did not reveal sufficiently detailed information on implementation necessary for their classification on the basis of the architectural style. Nevertheless a basic distinction can be accomplished: All projects have in common that they use high level communication based on Web technology. Diraya and Akteonline rely on a rather centralized architecture. PING however is based on a distributed architecture with centralized core services. Unfortunately, due to the lack of technical literature the architectural style of Sundhed.dk can only be guessed. The record seems to be based on a distributed architecture with some centralized services. Non of the projects make use of combined medical data and transmission standards as introduced in section 2.6 on page 19 to support interoperability. For that reason data exchange between those applications is considered vastly impossible Summary In this chapter the basic concepts and relevant standards, which are necessary for understanding the following parts of this work were introduced. Electronic Health Records were defined, followed by an introduction to distributed architectures including GRID technology. In the second part of this chapter relevant technical and communication standards are described and an overview of existing projects in this field of research is given. 12 German: Universitätsklinikum Münster.

53 Chapter 3 Methods Developing Health Information System architectures is a complex task, which includes the analysis and comparison of existing approaches with the aim to provide a solution that ideally entirely covers the requirements of all involved stakeholders. However, the more actors are involved, the more the likelihood of controversial requirements of different stakeholders increases. The challenging task is to design a flexible HIS architecture which best supports the requirements of each actor while not conflicting with other actors or legal and organizational conditions. The aim of this chapter is to introduce and describe the relevant methods which have been applied for developing a HIS architecture for Shared Electronic Health Records, which is a large part of the results of this thesis. This chapter has two main sections, in the first a general introduction of relevant methods is given (See section 3.1), in the latter the chosen methodology for developing a HIS architecture for SEHRs as software process is explained (See section 3.2 on page 52). 3.1 General Introduction of Relevant Methods Step Approach for Strategic Project Planning Every project requires careful and target oriented planning, this also applies to this work. Project plans have to be adjusted to the aims of the project and it s progress has to be constantly monitored. The 5 Step Approach introduced here is used to develop project plans with the target split up into concise work packages and milestones. The 5 Step Approach describes the following aspects: 1. Subject and Motivation 2. Problem Context 3. Objectives

54 40 Chapter 3: Methods 4. Tasks 5. Work Packages and Milestones Each project should start with an introduction, where organizational, personal, financial and legal basic conditions are mentioned. Particularly the project team members and the project leader should be introduced. Subject and Motivation In the first part the subject, e.g what the project is about, should be outlined, in order to describe the impact of the project on its environment. Why the project has been initiated and particularly the expected benefit is characterized as motivation. Problem Context Based on the motivation problems, which should be addressed by the project can be analyzed. Problems can be devided into sub problems and should be described in a short and clear manner. Objectives In a third step goals of the project can be derived from previously analyzed problems. At least one goal should be extracted to provide a solution for the problems. Tasks For each goal a task is defined which describes how this specific goal can be reached. Therefore work packages outline the detailed steps that are necessary to complete the task. Each task must be derived from an objective analyzed in the previous step, where one goal can be addressed by one or more tasks. Work Packages and Milestones As a last step work packages are derived from the tasks which comprise a detailed description as to how the tasks can be completed in order to meet the objectives of the project. In this step the workflow is analyzed along with the necessary tools and methods, and deadlines are extracted for each work package [14, 63] Literature Analysis The literature analysis is seen as a special form of analysis of existing data concerning a specific topic, which is an analysis that should reveal available data that contain relevant information on the subject of interest. A literature analysis is carried out when literature on a specific topic or problem is being searched or analyzed. The aim of the analysis is to gain as many relevant statements as possible concerning the topic of interest. Ideas for solving the specific problem can be extracted from the selected

55 3.1 General Introduction of Relevant Methods 41 literature. Furthermore literature analysis helps to argue why a particular solution has been selected or disapproved. Useful sources of literature are books, articles in scientific journals or technical reports. Nowadays search and retrieval of literature is supported by information technology and is therefore no longer limited to the search in conventional library catalogs, which increases search and filter functions. The process of searching literature can be supported by electronic data bases that can either be accessed locally, for example, via CD ROMs or remotely via the World Wide Web [64]. Medline 1 is a well known literature database where articles of relevant international medical journals are indexed. Technical articles in the field of software engineering and networking technology are indexed and provided by the Institute of Electrical and Electronics Engineers 2 (IEEE) Brainstorming Brainstorming was developed in 1953 by Alex F. Osborn in the USA with the aim to find ideas and potential solutions for a given topic. The name brainstorming indicates that the brain is intensively searched for ideas. A brainstorming session should be free of barriers which are usually encountered in traditional conferences. The vital aspect of brainstorming as a group activity is that the process of thought is not interrupted, and ideas are shared amongst the participants as soon as they are generated. Therefore modus operandi are defined which should encourage creativity and relieve common group dynamic barriers. Brainstorming is based on team work (synergistic effect) and free association (lateral thinking) and uses paper and pen as accepted media. On one hand the group has to be big enough to exploit the group dynamic phenomenon, but on the other hand small enough to facilitate communication between each of the members. The following rules are defined for brainstorming: Each participant is encouraged to contribute his knowledge even if it seems not to be relevant for the given problem. Associations could be generated in the team. Ideas of team members must not be constrained. The creative process should remain problem oriented, following a potential solution might prevent from finding alternatives. Divergent views with low consensus can stimulate the finding of new, creative ideas. Evaluation of ideas comes after the session. In the session solely ideas should be generated

56 42 Chapter 3: Methods In hierarchically structured groups the superior should not mention his expected or favored solution as team members could follow this approach rather then being creative and finding new ideas. Quantity before quality since ideas should be produced. Criticism during the session is to be avoided. There is no individual, but a collective copyright on ideas since brainstorming is the process of generating and expanding ideas. In brainstorming unstructured material is generated which has to be structured in a next step. In this phase criticism is allowed and necessary. After similar ideas have been clustered they can be sorted by criteria such as feasibility. Ideas can be sorted, for example, in immediately realizable, realizable later on, realizable after modification and not realizable. This phase ideally results in a list of proposals [65, 66] Methods for Interviews with Domain Experts Interviews with domain experts must follow a well approved methodology for the results to be reproduceable. Mayring describes standardized methods introduced in qualitative social research. In the following sections a short overview of methods relevant for evaluation of interviews with domain experts is given. Methods described here are based on the book Einführung in die qualitative Sozialforschung by Philipp Mayring [67]. Problem Centered Interview The term problem centered interview was first introduced by Andreas Witzel in the beginning of the 1980s as summarization of open, semi structured interviews [68]. The respondent should be able to answer in a natural way similar to an open conversation. However, a specific problem is addressed which the interviewer introduces and which then should remain the major focus of the conversation. A major benefit of the problem centered interview is its openness, where the respondent should feel respected and be able to answer freely. Based on those benefits main application areas are theory guided research with specific questions where the subject is partly understood. Fundamental ideas of the problem centered interview are: The problem centered interview makes use of a natural language formulated by the respondent to elicit the question in subjective background. A relationsip of trust between interviewer and interviewee is therefore necessary.

57 3.1 General Introduction of Relevant Methods 43 Figure 3.1: The five phases of the problem centered interview are shown as UML Activity Diagram. Interview phase (4) and recording (5) are carried out simultaneously. For further details refer to the text. Research is concentrated on precise social problems whose objective aspects have been previously analyzed. Although the interview should follow a previously elaborated guideline, respondents should be able to respond freely without being constrained by any predetermined alternative answers. Problem centered interviews are sequentially carried out in five phases as shown in figure 3.1. Initially in the analysis phase the problem is described and thoroughly analyzed to identify aspects to be identified in the interview. In the second phase (construction of guideline) the interview guideline is created comprising main topics and initial questions of the interview in reasonable order. Thirdly, in the pilot phase the interview guideline is tested and modified if necessary. Furthermore interviewers have to be trained. In the fourth phase (interview phase) interviews are carried out, which basically consist of three parts. 1. Initial Questions: Introduction to the topic. The interviewer should find out whether the topic is actually relevant for the interviewee and which subjective impact it has. 2. Guideline Questions: Questions identified as most relevant and included in the interview guideline. 3. Ad hoc Questions: Due to it s openness the problem centered interview can reveal aspects not covered in the guideline which can be of major importance. For that reason the interviewer can spontaneously ask questions not covered by the guideline.

58 44 Chapter 3: Methods Figure 3.2: The four phases of the Qualitative Content Analysis are shown as UML Activity Diagram. The analysis follows an iterative approach where categorization system and/or coding rules can be refined during classification. For further details refer to the text. The last phase describes the recording of the interview, which is of course carried out simultaneously with the interview phase. Voice recorder or written protocols are commonly used in this phase [67]. Qualitative Content Analysis Qualitative Context Analysis was developed in the 1950s with the fundamental idea of systematically analyzing texts by stepwise classification of their attributes in a theory guided categorization system. This categorization system is in turn being derived from the text which is subject of the analysis. Qualitative Content Analysis can be applied for systematic theory guided analysis of textual material. This is considered a major advantage: Textual material can be classified and evaluated according to a previously elaborated theory. Basic forms are: Summarization: Content is aggregated and core ideas are extracted. Explication: Unclear parts of the text are explained, if necessary using further material from external sources. Structuring: Filtering and classification of certain attributes of a text to predefined categories. Structuring is the key activity of the Qualitative Content Analysis where a categorization system is constructed in a granularity so that textual material can be unambiguously assigned to a

59 3.1 General Introduction of Relevant Methods 45 category. In a first step categories are created by analyzing the material and coding rules are defined which should allow unambiguous assignment of text passages to a category. In a second step text passages are marked which correspond to a specific category. In a last step the so classified material is aggregated and processed for further use. As shown in figure 3.2 on the preceding page the Qualitative Content Analysis is an iterative process where categories and coding rules can be revised if they turned out to be inadequate [67] The Unified Modeling Language (UML 2.0) In 1997 the first version of an object oriented modeling language was accepted as standard by the Object Management Group (OMG) as Unified Modeling Language (UML). According to the OMG modeling is the designing of software applications before coding. A model plays an important role in software development, and can be seen as analogy to blueprints and other plans used for constructing buildings or aircrafts [69]. The OMG s Unified Modeling Language (UML) helps you specify, visualize, and document models of software systems, including their structure and design, in a way that meets all of these requirements [69]. With UML virtually any type of application can be modeled, independent of programming language, underlying operating system or hardware platform. UML is flexible enough to model distributed applications that use just about any type of middleware currently available. Therefore in UML 2.0 thirteen different types of diagrams are available which can be divided into three categories: 1. Structure Diagrams: Represent the static structure of applications including Class Diagram, Component Diagram, Structure Diagram and many others. 2. Behavior Diagrams: Represent general types of behavior by Use Case Diagram, Activity Diagram, and State Machine Diagram. 3. Interaction Diagrams: Represent different aspects of interactions including Sequence Diagram, Communication Diagram, and many others. Interaction Diagrams are derived from more general Behavior Diagrams. In 2004 the UML version 2.0 was released, to add support for modeling beyond classes and objects. Version 2.0 adds capability for architectural models, business process models and many more, relevant for information technology and even other disciplines. Nested Classifiers are an extremely powerful concept added in UML 2.0. Classifiers are building blocks such as classes,

60 46 Chapter 3: Methods objects, state machines which can be nested inside a component. This allows for different levels of abstraction to be added. Thus, an overview activity diagram can be constructed from detailed views of relevant operations [69] Object oriented Development According to Sommerville object oriented (OO) systems consist of interacting objects which maintain their own local state and communicate with other objects using interfaces [21]. Models produced in the software process (See section 3.1.7) are illustrated in object oriented representation, generally as UML models, as introduced in section on the previous page. Object oriented development uses object oriented methods throughout the development process, from software design to software advancement: Object oriented Analysis Object oriented models of the application domain are developed for identifying requirements, where objects reflect the entities and operations associated with the target domain. Objects and operations have to be identified and described typically as UML diagrams. Medical documents are, for example, considered as objects and adding them to the record as operations in the domain of SEHRs. Object oriented Design Detailed, object oriented models of the software system are constructed, reflecting the identified requirements. Described objects are closely related to the solution of the given problem which will later be implemented as software. Therefore a mapping between objects generally describing requirements and objects used for later implementation is necessary. A medical document, for example, comprises a variety of closely related objects, such as metadata and access permissons. Object oriented Programming The software design is implemented in an object oriented programming language such as Smalltalk, C++, Java and many others. As long as interfaces remain stable, the interior behavior of objects can be transparently changed, as well as the representation of data since it is typically concealed inside the objects [21] Software Process In this section a general introduction is given of relevant software engineering methods described by Sommerville, Balzert and Hoffer [21, 70, 71]. In section on page 55 the software process for developing a HIS architecture for Shared Electronic Health Records by applying those methods is described in detail. A variety of partly intuitive approaches seem to be applicable to transform requirements of different actors to a fully developed HIS architecture. The most promising approach is to consider

61 3.1 General Introduction of Relevant Methods 47 a HIS as a software product, however a very complex one, with a large set of requirements and actors involved. The basic advantage is that standard software engineering methods can be applied, which have been approved in highly complex software products such as operating systems and control systems for critical applications like aircrafts and medical devices. Necessary steps in the development of a software product are referred to as software process. Based on the above mentioned advantage the development of a HIS architecture for Shared Electronic Health Records is modeled as a software process. Although different approaches and methods can be found in literature, they have basic activities in common. A detailed description of common software engineering methods is given by Ian Sommerville, which will be used as reference for the software development process for the HIS architecture [21]. According to Sommerville a software process can be divided into four main phases: 1. Software Specification: Expected function and requirements for the software as well as a description of usage must be described. 2. Software Design and Implementation: The software which should fulfill those requirements must be designed. 3. Software Validation: The software must be validated to ensure that functionality is compliant with the requirements. 4. Software Evolution: The software must be adapted to comply with potentially changing requirements. The software process is described by Hoffer as systems development life cycle (SDLC) which comprises two more initial steps at the very beginning of the process. Project identification and selection and project initiation and planning are to be carried out before the analysis phase starts [71]. Developing the HIS architecture in a standard software process provides a structured guideline for each step, which significantly breaks down complexity and, as a result, reduces the danger of developing a software product which is not compliant with the requirements of the involved actors. The procedure for developing the HIS architecture following the above mentioned phases is explained along with selected methods in section on page 54. Software Specification Requirements engineering is seen as crucial phase in the software development process, since flaws in this phase immediately cause problems in design and implementation.

62 48 Chapter 3: Methods According to Sommerville software specification is a collection of methods used to analyze desired functionality and requirements of a software product, which results in a document known as Software Requirements document 3 [21]. This process comprises four basic activities: 1. Feasibility Study. 2. Requirements Elicitation and Analysis. 3. Requirements Specification. 4. Requirements Validation. In an initial step a feasibility study is carried out to assess whether a software system can be developed that supports the overall goals of the stakeholders while not breaking organizational, legal, technical or financial constraints. The output of a feasibility study is a summarizing document referred to as feasibility report. In the second step developers along with the actors and later users of the software define the field of application, desired features and offered services of the system. In the third step after requirements have been analyzed, they are described and classified, which is known as requirements specification. The key activity of this phase is translating requirements gathered in the previous phase to a document which defines a set of requirements. Therefore user requirements 4 are collected and generally described in an unstructured way. System requirements are then derived from user requirements and should give a detailed description of the functionality that must be present to support the user requirements. Requirements can be furthermore classified in functional, non functional and domain requirements. Functional requirements describe services or functionality that is expected of the system. A functional requirement of a Shared Electronic Health Record is, for example, that a patient should be able to access his medical documents. Non functional requirements have no direct impact on the function or service provided by the system, but are vital aspects to make the system work and support functional requirements in the desired way. Security, scalability and response time are typical non functional requirements. Only authorized physicians should, for example, be allowed to access a patient s medical documents. Domain requirements can either be functional or non functional requirements or constraints to one of them in order to reflect the situation a system is operated in. Compatibility with existing systems is a typical domain requirement. A SEHR should, for example, support medical communication standards such as HL7 or DICOM. 3 Commonly known as Pflichtenheft in German speaking countries. 4 Commonly known as Lastenheft in German speaking countries.

63 3.1 General Introduction of Relevant Methods 49 As a last step the software requirements document is validated by the stakeholders to ensure that the expected functionality has been fully analyzed and is entirely covered by the system requirements specification. Software Design and Implementation The aim of the design phase is to develop a software architecture from given requirements [70]. Different procedures for design and implementation exist, where a methodical approach uses structured methods which are composed by various notations and rules for software design. The use of standard notation is an expected benefit to obtain structured and reuse able documentation, which in turn can help to keep development costs low [21]. The following common tasks have been identified for the design of a software architecture: 1. System Organization 2. Control Styles 3. Modular Decomposition Styles Each system can be decomposed into basic subsystems, where each subsystems is again an independent software system (1.). Subsystems can be described as blocks in a block diagram. Interactions of the subsystems analyzed in the previous step are described in details (2.). Subsystems can be further devided into modules (3.). This step is virtually identical with the first step on a lower level, except that components of modules are generally smaller than systems. The resulting document of this phase is an architectural model which comprises system models in graphical representation as well as describing text [21]. After the system design has been completed, the implementation follows where each system component specified in the architectural model is implemented as one or more programs [70]. As implementation starts decisions related to programming language have to be taken. Software Validation Software verification and validation should not only follow the implementation phase but rather be carried out continuously during the software process, starting in the analysis phase. The importance of validation is stressed by the fact that up to 40% of the development costs for complex software systems are spent for integration and testing [21]. The differentiation between validation and verification is important. Formulated as questions the first is: Are we developing the right product? and the latter: Are we developing the product correctly?

64 50 Chapter 3: Methods Various tests such as software inspection and integration tests are carried out as accompanying measures during software development. Before a software is released final acceptance testing is carried out, where all involved actors test the system and accept it or not depending on how the system fulfills their requirements. Extreme Programming Extreme Programming which is an approach, that closely links development with validation radically differs from the introduced testing procedure. Each code section is tested and corrected immediately after writing. Better communication, higher productivity and higher quality of code are expected benefits of extreme programming [21, 70, 71]. Software Evolution Software Evolution is the process of adapting the software to changing requirements. Different strategies can be identified: In an evolutionary paradigm the advancement phase is an essential part of the software process. Software advancement generally directly results in the next version of the prototype. This process continues either until the requirements of stakeholders are satisfactorily covered or requirements have been understood to an extent which makes requirements specification possible Software Process Paradigms Each software process follows a process paradigm, which is a very abstract description of the interaction of its main steps, introduced in section on page 46. A variety of software process paradigms evolved over the past 20 years. Basically linear or evolutionary paradigms can be distinguished, where the first requires each phase to be completed before the next can start. In the latter mentioned those phases are carried out iteratively [21, 70] Evolutionary Process Paradigm An evolutionary process paradigm facilitates the iterative refinement of requirements. In this process paradigm a first prototype implementation is being developed based on an initial set of requirements. Those requirements are then redefined and addressed by the next version of the prototype. This step is iteratively repeated until the required functionality is implemented. In the evolutionary approach the main steps Specification, Implementation and Validation are concurrently being carried out for each version. The evolutionary process paradigm seems to be the most adequate approach when requirements are either not fully clear, well understood or possible designs are complex and require a concrete implementation to be evaluated. However, this approach faces its limitations with a large number

65 3.1 General Introduction of Relevant Methods 51 Figure 3.3: The software process for developing a HIS architecture for SEHRs which follows an evolutionary paradigm can be represented as spiral model. Development starts in the center with the specification phase (upper left sector). In clockwise rotation implementation (upper right sector), validation (lower right sector) and operation (lower left sector) follow. A seamless transition is encountered between operation and specification of the next release. For further details refer to the text. of stakeholders involved. Drawbacks are expected since documentation in intermediate versions is easily being neglected and the structure of software suffers by constant changes [71, 21]. Instead of describing the evolutionary paradigm as linear model where each phase gives feedback to its predecessor, the software process can be represented as spiral model, which has originally been proposed by Boehm [72]. In figure 3.3 the evolutionary software process is represented as simplified version of the spiral model. The spiral model is considered as meta model which allows different paradigms to be used in each phase. Each winding describes an evolution of the process, which means that each winding produces a new prototype until the system is ready for productive use. The spiral is divided into four sectors, where the upper left represents the specification phase. Implementation, validation and operation phase follow in clockwise rotation. In the operation phase the specification of the next version starts in a seamless transition.

66 52 Chapter 3: Methods Waterfall Process Paradigm In the waterfall model, introduced by Royce [73] each of the main phases are carried out subsequently, where each phase requires the previous to be completed. The waterfall model implies that requirements and desired functionality can be entirely elaborated at the very beginning of the software process. Each phase produces one or more documents which can be reviewed by the involved actors. Due to the rigid definition of phases a reaction on changing requirements is seen as problematic [21]. 3.2 Methods Applied for Developing a HIS Architecture for SEHRs In this section methods introduced in section on page 46 are applied for designing the software process which the development of the HIS architecture for SEHRs follows. A detailed description of the process from requirements engineering, implementation and testing to software evolution is given Interviews with Domain Experts Knowledge of domain experts is important for designing a HIS architecture for Shared Electronic Health Records. Domain experts have been primarily consulted for: 1. Identifying system requirements from given user requirements. 2. Solving questions concerning new technologies and security. 3. Evaluating whether user requirements are satisfactorily covered. The problem centered interview introduced in section on page 42 was used as standardized, semi structured methodology to obtain reproduceable results from discussion with domain experts. Although listing all domain experts would be beyond the scope of this work, in table 3.1 on the facing page organizations or research groups are described which have been consulted as domain experts: During the interview with domain experts protocols were created which, in a second step, were analyzed and evaluated according to the Qualitative Content Analysis introduced in section on page 44. The aggregated expert knowledge was then integrated into the respective phase of the software process where additional expert knowledge was required.

67 3.2 Methods Applied for Developing a HIS Architecture for SEHRs 53 Expert TILAK a KIS b Team: Management team of the Clinical Information System in the Innsbruck University Hospital Sozialversicherungs Chipkarten Betriebs und Errichtungsgesellschaft m.b.h (SVC): e-card operating company Österreichische Datenschutzkommission: Austrian data protection experts Allgemeines Rechenzentrum Innsbruck: General data processing center Innsbruck Austrian GRID Domain Data standards, conversion of non structured data Security, patient identification, accounting and billing Security, high availability of services High availability of services, service deployment, service configuration GRID technology, security, user authentication, data replication Leopold Franzens University Innsbruck Security, service implementation, distributed architectures UMIT Institute for Information Systems distributed architectures, data replication, service integration, indexing algorithms Österreichische Ärztekammer: Austrian Medical Association Data standards, validation of actors, user and domain requirements a German: Tiroler Landeskrankenanstalten GmbH. b German: Klinisches Informations System: Clinical Information System. Table 3.1: Domain experts selected for the problem centered interview Object Oriented Development for the SEHR Architecture Object oriented development as introduced in section on page 46 has been chosen for design, implementation and evolution of the HIS architecture for Shared Electronic Health Records. The selection was motivated by the advantages of object oriented design: Object oriented systems are thus easier to change since objects are independent. They can be modified and functionality can be added without affecting other objects as long as interfaces remain stable. For SEHRs this is a vital aspect as it allows for fast reaction on changing requirements. Complex systems such as Shared Electronic Health Records can be easily understood because objects can often be mapped to real world entities of the target domain such as medical documents. For each prototype objects can be reused that have been previously created and so design, programming and validation costs can be reduced [21, 70]. For closely binding actors to the development process extreme programming methods (See section on page 50) had been applied where requirements were widely unclear. This provides more flexibility than the strict object oriented approach, so that those requirements can be elaborated during the design and implementation process together with the involved actors. Java has been selected as object oriented programming language since it is platform independent

68 54 Chapter 3: Methods and thus provides for interoperable systems. Java is considered more adequate than C++ for designing systems with high security requirements since, amongst many others, pointers are replaced by references and therefore the potentially incorrect use of pointers which can easily lead to security leaks can be avoided. Furthermore, boundaries of buffers are automatically checked, which reduces the danger of Buffer Overflows [74] Applied Software Process Paradigms The majority of the involved actors are not familiar with Shared Electronic Health Records and so expected functionality and requirements for an architecture can not easily be defined in advance. For that reason an evolutionary process paradigm, introduced in section on page 50 was chosen as the basic methodology for designing the HIS architecture for a Shared Electronic Health Record. This decision is motivated by the above mentioned benefits of the evolutionary process paradigm when requirements are partly unclear. To limit expected drawbacks of this methodology, detailed requirements have been elaborated for critical parts of the architecture (core components). Those parts have then been specified using a waterfall like paradigm as introduced in section on page 52. Formal software development based on mathematical models is considered as possible alternative to the chosen evolutionary paradigm. This approach relies on a formal software specification in a language with formally defined vocabulary, syntax and semantics. System specification, analysis and proof of specification, transformal development and program verification can be derived by mathematical transformations from the initial formal specification. Due to the underlying mathematical models, errors in specification can be easily identified and system specification can be presented in an unambiguous way. Although formal specification is expected to provide for fewer errors in software, the following drawbacks have been identified: Formal specification is a time consuming process, formal methods have a limited scope where user interfaces and interactions, for example, are not satisfactorily covered and formal methods suffer from poor scalability where the development effort tremendously increases as the size of the project grows [21, 75]. Furthermore the formal specification depends on clearly defined requirements. Those requirements for a HIS architecture were not entirely clear in advance and so were continuously refined during development. Using the formal approach the models would have to be constantly revised, which is expected to be a very time consuming process. Nevertheless selected critical parts of the HIS architecture with highest degree of reliability required should be specified for future productive releases using formal methods.

69 3.2 Methods Applied for Developing a HIS Architecture for SEHRs Methods Applied in Different Phases of the Software Process The chosen evolutionary software paradigm represented as simplified spiral model in figure 3.3 on page 51 comprises Specification, Implementation, Validation and Operation as four main phases of the software process (see section on page 46). In the following sections methods used in those phases for developing a HIS architecture for Shared Electronic Health Records are described. Analysis Phase: Requirements Engineering The process of analyzing requirements for a HIS architecture for Shared Electronic Health Records has been carried out according to a well approved software engineering methodology introduced in section on page 47. However, some modifications have been applied to reflect the requirements of the medical domain. In figure 3.4 on page 58 the process of requirements engineering is described as UML activity diagram. Feasibility Analysis In an initial step the feasibility analysis was combined with a process of finding potential actors and stakeholders with their different interests in a patient centered Shared Electronic Health Record. As opposed to common software projects in industry and commerce this research project lacks a clearly defined contractor. So in this phase actors with potential interest on a SEHR had to be identified. The identification of actors was carried out by the health@net project team using Brainstorming as creativity method (See section on page 41). Initially identified actors are represented in figure 4.1 on page 70 and have been published as results by Schabetsberger [12, 13]. As the process of finding involved actors is absolutely vital for later steps, the identified actors were validated in problem centered interviews with domain experts listed in table 3.1 on page 53 as described in section on page 52. Requirements Elicitation and Analysis After involved actors were identified the requirements elicitation and analysis was carried out as the next step in the software process resulting in a system model. As requirements and functionality desired by different actors were completely unclear, an analysis was carried out by Schabetsberger [12, 13] to find an initial set of desired functionality for each stakeholder, called functional requirements. The results of this analysis were taken as starting base for identifying user requirements as described in section on page 47. The so identified requirements have been textually described and UML Use cases (See section on page 45) have been chosen as object oriented approach to develop a simplified system model of the SEHR. Each functionality desired by a specific actor has been modeled as a set of use cases along with interaction with the system. UML Sequence Diagrams have been

70 56 Chapter 3: Methods added as extension to Use Cases in order to provide a clear understanding of the operations that are carried out by the actors. Requirements Specification Starting from the initial requirements, user requirements were derived. An analysis of those initial requirements (See section on the preceding page) revealed that they already, to a large extent, comply to what is considered as user requirements in software engineering. To obtain a final set of user requirements initial requirements were detailed, categorized and assigned to the previously identified actors. The so obtained user requirements describe functional and non functional requirements of a system in a non technical way that is easy understandable for the end user as proposed by Sommerville [21]. Functional, non functional and domain requirements have been collected simultaneously to a requirements pool. Functional requirements were obtained by extending the user requirements to describe desired functionality of the SEHR in details along with input output operations and exceptions. Non functional and domain requirements such as security, scalability and adherence to medical standards have been obtained by literature analysis as introduced in section on page 40. Therefore a PubMed search was carried out and documents of medical standards were analyzed. In a next stepsystem requirements where then derived from the previously created requirements pool. As the derivation of system requirements is a complex process which demands for expertise in a variety of different fields, such as software and security engineering, usability and medical communication protocols, an iterative approach was chosen to constantly refine system requirements. In the first phase of this iterative process, basic system requirements were extracted from the requirements pool which were then discussed with the domain experts listed in table 3.1 on page 53 to be continuously refined. Problem centered interview (See section on page 42) and Qualitative Content Analysis (See section on page 44) were chosen as methods for obtaining reproduceable results as described in section on page 52. In each session newly discovered aspects were added to the requirements pool and were in the next iteration refined to system requirements. To cut down on complexity in a first prototype requirements of patients and medical professionals have been addressed, whereas functionality desired by other actors such as social insurances or medical researchers will be integrated into future versions of the architecture. Different approaches for structuring of system requirements are known, such as graphical representation in UML like model or formal mathematical descriptions [76, 21]. In a form based approach requirements are collected in a structured representation in tabular forms. Functional requirements for SEHRs are not entirely new, many of them have been discovered for related systems on a more narrow view, such as for Clinical Information Systems or telemedical applications. Similar requirements concerning security and response time can, for example, be

71 3.2 Methods Applied for Developing a HIS Architecture for SEHRs 57 found in electronic transfer of radiological images in a point to point connection between two hospitals [77]. Many of those requirements have been successfully covered by implementations already published in literature. A thorough analysis of the existing literature is a crucial step in this phase to identify functional requirements that have successfully been mapped to system requirements with approved validity. As a variety of a SEHR s functional requirements are common in health care communication, dependent system requirements have already been elaborated and published in literature. In the requirements specification phase the analysis of existing literature, extraction of published system requirements and their adaptation for SEHRs has been a key activity. Existing literature was analyzed using the literature analysis as introduced in section on page 40. System requirements were generally not clearly distinguishable in analyzed literature, so for their identification a Qualitative Content Analysis as described in section on page 44 was carried out. This is considered a vital aspect to reduce the risk of identifying inappropriate system requirements. Interoperability with existing systems has been identified as a crucial functional requirement, so existing standards have to be applied whenever possible. Medical communication standards (See section 2.6 on page 19) are considered domain requirements. Some of the standards such as the IHE XDS Integration Profile, introduced in section on page 27 give clear advice for implementation. So to achieve compliance with those standards the advice was incorporated as a system requirement of the final HIS architecture. Requirements Validation and Requirements Document In the last step, requirements were validated and after successful validation a detailed, structured document was elaborated known as requirements document, comprising system requirements and use cases as system models to form the basis for the design and implementation phase. Requirements validation is a critical task to ensure that the developed HIS architecture is compliant with user requirements. In the validation phase domain experts listed in table 3.1 on page 53 were consulted using the problem centered interview as described in section on page 52 to approve that system requirements fully cover user requirements and that they were correctly constructed. Although requirements were carefully analyzed, the author expects that additional requirements will be found during the implementation phase of the software. The chosen evolutionary process paradigm (See section on page 54) turned out to be appropriate so as to be able to react on changing requirements, since the requirements document can be iteratively adapted as new requirements are identified. Two drawbacks of this approach have been described in literature: The software process is not visible and progress can not be easily measured by the project management. The more severe deficiency is that systems are often poorly structured and documentation is partly missing [21]. Influenced by those drawbacks the author expects a potential danger of this approach: Rapidly changing requirements of different actors could turn the software process into following a moving target which again seems to impair the structure of the system. To limit those effects, system requirements of core features analyzed in the previous phase have been frozen and will be adapted after experience has been gained with the first productive release.

72 58 Chapter 3: Methods Figure 3.4: UML activity diagram which describes requirements engineering as the first step of the software process. 4 phases have been identified: Feasibility Analysis (Yellow), Requirements Analysis (Green), Requirements Specification (Red) and Requirements Validation (Blue). For further details refer to the text.

73 3.2 Methods Applied for Developing a HIS Architecture for SEHRs 59 Design and Implementation Phase The design and implementation process of a HIS architecture for SEHRs follows well approved software engineering methodologies introduced in section on page 49. The design phase follows a straight line process with little feedback. In figure 3.5 on page 61 the design phase is shown as UML activity diagram. Structuring of the System Based on the requirements profile introduced in section on page 55 a software architecture has been developed. In the context of a Health Information System the software architecture represents the technical view of the HIS (See section 2.3 on page 10). System requirements have been analyzed and assigned to possible subsystems. Theoretically an architecture can be arbitrarily designed to best support those requirements. However, the creativity in the design process was constrained by the vital domain requirement to use well established medical standards whenever possible. Amongst many standards and recommendations in the context of EHRs the IHE XDS Integration Profile was selected (See section on page 26). Although the XDS Profile is not a standard in the strict sense, it makes excessive use of existing standards. At the time of writing the XDS is the only specification which gives clear recommendations for implementation including Web technology as communication technology. For that reason IHE XDS is expected to be the most adequate for designing an architecture for a Shared Electronic Health Record. The software architecture is described as block diagrams. The SEHR system was subdivided into various subsystems which were then assigned to the five IHE actors. A big challenge is expected in the design of subsystems which have to, on the one hand support the requirements of the involved actors, as well as on the other hand comply with the IHE XDS Integration Profile. For representation of the architectural model a distributed system model has been selected, which describes how data and processes are distributed over a large number of systems. This approach is described by Sommerville and Balzert as distributed object architecture [21, 70]. In contrast to Client/Server architectures this is a more general approach where system components are represented as objects which can concurrently act as service provider and consumer. Decomposition into Modules Subsystems can be further decomposed into modules. Decomposition can either be carried out as object oriented decomposition or follow a function oriented pipelining model. In the latter the system is decomposed into functional modules, which process received input data in some way and forward output data to the next module in the chain. The UNIX shell is a representative of function oriented pipelining where the output of one command can be piped to the input of another command. For the implementation of the HIS architecture of a SEHR object oriented models have been

74 60 Chapter 3: Methods chosen because objects are only loosely coupled and the implementation of an object can change without influencing other objects. Therefore interfaces are specified in the design process for inter object communication which should remain stable for one version. Objects can so be reused in modules with similar tasks. Potential drawbacks of the object oriented model is that changes of the interface of one object can affect a large number of objects that use this interface [21]. By the evolutionary process paradigm selected for the design of the HIS architecture side effects of changing interfaces can be kept low by defining interface stability as a non functional requirement: Interfaces can not change within a prototype. In the next version of the prototype interfaces are adapted for all objects in the design process. Reference architectures are an alternative approach for designing an architecture. Reference architectures represent an idealized architecture of a system which comprises all functionality required for a specific domain. Reference architectures are considered as a route to implementation and act as base, against which systems can be evaluated [21]. The architecture proposed by the IHE XDS Profile (See section on page 27) can be considered as reference architecture. As described in section on the previous page recommendations of XDS have been incorporated as system requirements. Implementation in Programming Language After modules were identified and the definition of interfaces was agreed on, modules were implemented in Java as object oriented programming language. Immediately after implementation the validation phase started, which produced feedback for implementation as deficiencies were identified.

75 3.2 Methods Applied for Developing a HIS Architecture for SEHRs 61 Figure 3.5: The design and implementation phase is described as UML activity diagram. This phase follows a straight line process. Feedback from discussion with domain experts is generally provided to the requirements specification of the next version. If severe defects of requirements are identified they are immediately revised. For further details refer to the text.

76 62 Chapter 3: Methods Validation Phase Software verification and validation (which is described here as validation phase) is seen as a vital process for delivering a HIS architecture for Shared Electronic Health Records which follows the requirements of the different actors as closely as possible. Although the validation phase is described after design and implementation it is a continuous process which starts in the analysis phase and ends in the software advancement phase. In figure 3.6 on page 64 the validation phase is described as a UML activity diagram. The validation phase is divided into six steps which are carried out applying the software engineering methods introduced in section on page 49. A graphical representation of this process is given in figure 3.6 on page 64: 1. validation of requirements, 2. validation of architecture, 3. software inspection, 4. unit tests for each module, 5. integration and interface tests and 6. final acceptance tests. As described in section on page 57 the software requirements document was immediately validated after creation (1.). The thorough validation of the requirements document approves that functional and user requirements of the involved actors are satisfactorily covered. Although the software process follows an evolutionary paradigm where requirements are being continuously adapted during development, a key functionality had to be agreed upon which would remain stable until the final version is released. The architecture was validated (2.) to support both, the specified requirements and the IHE XDS Integration Profile. In this step the architecture description was discussed with the domain experts listed in table 3.1 on page 53 using the problem centered interview as described in section on page 52 as a standardized method to obtain reproduceable results. Deficiencies identified in the architecture specification were either corrected instantly if they were expected to cause malfunction or were added as requirements for the next prototype if identified as feature enhancements. The source code was inspected (3.) immediately after writing in various peer review sessions with involved developers. Fine grained unit tests have been defined for each module on the level of objects to discover incorrect behavior of the components (4.). The methodology used resembles the extreme programming approach introduced in section on page 50. Unit tests were developed during

77 3.2 Methods Applied for Developing a HIS Architecture for SEHRs 63 or shortly after writing and modules were not finalized before unit tests were successfully and entirely completed. After the development of modules had been completed, including successful unit tests, they were integrated into subsystems and their interactions were tested (5.). Interfaces were tested as described in section on page 49 to find defects caused by incorrect interface design. Exception handling and expressiveness of error messages was tested by calling interfaces with intentionally incorrect data. Each prototype passed through a final acceptance by the identified actors shown in figure 4.1 on page 70. As described in (2.) on the preceding page issues that might cause malfunction were corrected instantly, whereas issues that extend functionality were incorporated in the analysis phase for the next prototype.

78 64 Chapter 3: Methods Figure 3.6: The validation phase is described as a UML activity diagram. In each step feedback is provided with two alternatives. If defects are identified, the error is corrected immediately (orange). If requests for new functionality are identified they are collected as requirements for the next version. For further details refer to the text.

79 3.3 Summary 65 Software Evolution Phase Software evolution is an essential process in developing a HIS architecture for SEHRs. On the one hand new functionality must be continuously added and on the other hand existing functionality has to be adapted to meet changing requirements. Particularly the evolution phase is expected to profit from the evolutionary approach introduced in section on page 54 and represented as simplified spiral model in figure 3.3 on page 51. According to this model, enhancements of existing functionality or requests for new features, discovered in virtually any phase of software process, were added to the specification phase of the next prototype, indicated by the next winding of the spiral. 3.3 Summary In the first part of this chapter relevant methods for developing a HIS architecture for Shared Electronic Health Records are introduced. Basically the 5 Step Approach for Strategic Project Planning, creativity methods and the problem centered interview along with Qualitative Content Analysis are introduced as general methods, independent of the technology. The Unified Modeling Language (UML 2.0) and common software engineering techniques are described as the technical basis for designing the HIS architecture. Those methods are applied in the second part of this chapter in the software process for developing the HIS architecture. The procedure from requirements engineering, design and implementation to validation and advancement is described in detail. Based on the methods introduced here an architecture for a Shared Electronic Health Record is implemented. Details of the implementation are described as Results in the following chapters.

80

81 Part II Results

82

83 Chapter 4 Requirements for Shared Electronic Health Records In this chapter requirements for Shared Electronic Health Records are described. In the first part functional and user requirements are outlined, summarizing the results of Schabetsberger [13, 12]. In the second part system requirements are specified following the methods introduced in chapter 3 on page Relevant Actors An in depth literature analysis was carried out along with discussions with domain experts in order to identify actors that expect improved efficiency and potential cost reduction by advanced communication as facilitated by Shared Electronic Health Records. The identified actors can be clustered into three groups which are represented in figure 4.1 on the next page as UML Use Case diagram: 1. Patient: In a patient centered SEHR the patient (or citizen) is an important actor, who presumably requests full access to his medical data in a form of representation understandable for him. 2. Medical Professionals: This group comprises General Practitioners (GP s), established specialists, physicians in hospitals and rescue services, who probably need different types of data in customized representation. 3. Indirectly Related Actors: Pharmacies, health insurance companies, researcher and public authorities, who are not directly involved in the care process have vastly distinct interests on certain kinds of medical data in different levels of granularity and representation. Data protection and anonymization plays an important role here, since not all of those actors should have access to all parts of the record. Although actors have been carefully analyzed, new actors might be found in the near future which makes an adaptation of functional, and as a consequence, system requirements necessary.

84 70 Chapter 4: Requirements for Shared Electronic Health Records Nursing services could for example be identified as new actor with different requirements than medical staff. Figure 4.1: Actors of the healthcare sector have been identified as major stakeholders for Shared Electronic Health Records. They have in common a substantial interest in accessing medical data in a representation adequate for their needs. For further details refer to the text. 4.2 User Requirements The analysis of user requirements was initially carried out by Schabetsberger [12, 13], who collected so called functional requirements for Shared Electronic Health Records. In the following sections they are summarized as user requirements for the actors identified in section 4.1 on the preceding page. RequirementIDs for user requirements start with a capital letter U, followed by an underscore. Actors are identified by the second capital letter.

85 4.2 User Requirements User Requirements for Patients User requirements for patients as the major actors were analyzed and are represented in table 4.1 on the next page. ReqID Requirement Description U P 1 U P 2 U P 3 U P 4 U P 5 U P 6 U P 7 U P 7.1 U P 7.2 U P 7.3 U P 7.4 U P 7.5 U P 8 U P 9 Access to personal health record Support for change of physician Forward of parts of record Adding personal entries to record Summary of treatment expenses Electronic ordering of drugs Privacy and data protection 4 Eye Principle Delegation of access permissions Hiding parts of the record Emergency access Audit and logging Feedback of clinical trials Resource management Patients want to access their personal health related data independent of location and time in an understandable representation. Patients should be able to consult a physician of their choice. Patients want to give access to parts of their record to specialists. Secure Mailboxes should improve communication between patient and physicians. Patients would like to add entries such as pain, blood pressure, diabetes diaries and living will. Patients should be able to list costs caused by their medical treatment. Drugs should be ordered electronically and delivered to the patients home. Pharmacies should therefore be able to access prescriptions. For end user acceptance by patients privacy and security is absolutely vital. National, European and international data protection laws have to be observed. Only the owner (e.g. patient) or the producer (e.g. physician) should be able to access parts of the record. The owner can grant (and/or revoke) fine grained permissions to individuals (delegation and proxy access). The patient should be able to hide certain parts of the recored (e.g. stays in psychiatric wards) even from himself. Retraction should require media crack such as written letter. In case of danger to life physicians must have full access to a patient s record overriding the 4 Eye Principle. The patient must be informed by postal notification. Access to the record must be fully traceable, where unauthorized access should be automatically detectable. Patients expect to be informed about results of clinical trials they participated in as far as these are relevant (e.g. newly discovered risk factors). Patients would like to get information about free resources in healthcare institutions and should be able to book them. Therefore calendar functions are considered helpful. continued on next page...

86 72 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... ReqID Requirement Description U P 10 U P 11 U P 12 Backup functionality Online refund of cost Communication with medical specialist Patients should be able to make a personal copy of their medical data. Requests for cost refund of special treatment should be transmitted online to the patients health insurance. Patients would like to consult a medical specialist via a secure communication medium such as . Table 4.1: User requirements for Shared Electronic Health Records identified for patients. Source: Schabetsberger [12, 13] User Requirements for Medical Professionals User requirements for medical professionals were analyzed and are represented in table 4.2 on the facing page. Although only physicians are mentioned in this description requirements apply to the entire group of medical professionals. ReqID Requirement Description U M 1 Access to health record of a patient Physicians expect access to relevant information of a patients record. Information should be searchable and in an appropriate representation. U M 2 Emergency access Physicians want to override access permissions in case of danger to life. U M 3 Direct Secure communication for consultation of a colleague/specialist. U M 4 communication Monitoring and alerting Physicians should be able to monitor predefined parameters of patients equipped with mobile devices. They should be alerted as soon as critical changes occur. U M 5 Clinical guidelines Decision Support by clinical guidelines is expected. U M 6 Quality reports Cost reports caused by complications should be generated automatically. U M 7 U M 8 U M 9 Transmission of accounting Electronic ordering of drugs Anonymized reports Physicians would like to electronically submit accounting information. Physicians should be able to order drugs electronically. Additionally to quality reports (U M 6 ) customizable anonymized reports should be supported (e.g. Regional incidence of certain diseases). continued on next page...

87 4.2 User Requirements 73 continued from previous page... ReqID Requirement Description U M 10 U M 11 U M 12 U M 13 U M 14 Electronic prescription Data import from existing or mobile systems Resource management Privacy and data protection Organizational, legal and financial framework Drugs should be prescribed electronically. Data acquired by proprietary systems or mobile devices should be imported to the record after successful authorization. Physicians would like to electronically arrange appointments for the patient or book resources (e.g. beds in hospitals). For end user acceptance by physicians privacy and security is absolutely vital. National, European and international data protection laws have to be observed. Physicians expect a legal basis for using information of the record particularly when avoiding duplicate examinations. Table 4.2: User requirements for Shared Electronic Health Records identified for medical professionals. Source: Schabetsberger [12, 13] User Requirements for Health Insurances User requirements for health insurance were analyzed and are represented in table 4.3. Restricted access to medical data (U I 4.1 ) is to be added as security requirement. ReqID Requirement Description U I 1 U I 2 U I 3 U I 4 U I 4.1 Submission of accounting data Statistics and quality reports Overview of service and costs Privacy and data protection Restricted access to medical data Health Insurance companies want to electronically submit/receive insurance or accounting relevant data Statistical analysis of treatment process and diseases in particular regions. Insurances would like to be able to add information about consumed services and costs to the record of a patient. Protection of medical and accounting data is of vital interest. National, European and international data protection laws have to be observed. Insurances should only have access to medical data to the extent needed for accounting. Statistics must be anonymized. Table 4.3: User requirements for Shared Electronic Health Records identified for health insurances. Source: Schabetsberger [12, 13].

88 74 Chapter 4: Requirements for Shared Electronic Health Records User Requirements for Scientists Analyzed user requirements for scientists are represented in table 4.4. Special emphasis has to be placed on data protection, so scientific analysis should only be carried out with anonymized data, where the individual can not be identified. Particularly for feedback of clinical trials (U S 3 ) patients must be re identifyable. Pseudonymization is used for this purpose, which is a type of anonymization based on injective mapping such as random permutations [78]. Re identification of pseudonymized data should be possible if, for example, a new risk factor relevant for the patient is discovered in a clinical trial. However, re identification must be restricted to such cases, which is introduced as new security requirement in (U S 4.1 ). ReqID Requirement Description U S 1 Clinical trials Scientists request access to (pseudo) anonymized medical data of patients as well as search and data mining functionality. U S 2 Alerting Predefined data items should be monitored automatically in a large number of records at regular intervals to discover epidemics or pandemia in an early stage. U S 3 U S 4 U S 4.1 U S 5 Feedback of clinical trials Privacy and data protection Restricted re identification Anonymized analysis Scientists expect to inform patients about results of clinical trials they participated in as far as these are relevant (e.g. newly discovered risk factors). Medical data must be (pseudo) anonymized for clinical trials. Protection of medical data and anonymity in scientific analysis is of vital interest. National, European and international data protection laws have to be observed. Re identification of the patient when pseudonymized data is processed should only be possible if directly relevant for the patient s health. Besides clinical trials analysis of predefined anonymized data items (e.g. to discover incidence of diseases in a region) should be possible using search and filter functions. Table 4.4: User requirements for Shared Electronic Health Records identified for scientists. Source: Schabetsberger [12, 13] User Requirements for Pharmacies Analyzed user requirements for pharmacies are represented in table 4.5 on the next page. To avoid confusion with requirements of patients (P), RequirementIDs for pharmacies are numbered using capital letter A according to the German word Apotheke which stands for pharmacy. Security requirements are to be added (U A 5.1 and U A 5.2 ) to, on the one hand, prevent pharmacies from accessing medical data not intended for them. On the other hand certain medical information such as known allergy to antibiotics must be accessible for checking incompatibilities.

89 4.2 User Requirements 75 ReqID Requirement Description U A 1 U A 2 U A 3 U A 4 U A 5 U A 5.1 U A 5.2 Electronic prescription Submission of accounting data Electronic ordering of drugs Anonymized reports Privacy and data protection Access restricted to particular data Access to data relevant for constraint checking Pharmacies should have access to a patient s prescription. Alerting is requested if contraindications are detected. Pharmacies would like to electronically submit accounting data to health insurances. Information about drugs ordered and fetched by the patient should automatically be added to his record. Pharmacies would like to carry out anonymized analysis spanning multiple records. Protection of medical data is of vital interest. National, European and international data protection laws have to be observed. Pharmacies should only be able to access prescription relevant data and not the entire health record. Access to those data necessary for checking incompatibilities or contraindication with prescribed drugs. Table 4.5: User requirements for Shared Electronic Health Records identified for pharmacies. Source: Schabetsberger [12, 13] User Requirements for Public Authorities User requirements for public authorities were analyzed and are represented in table 4.6. To avoid confusion with requirements of patients (P), RequirementIDs for public authorities are numbered using capital letter H according to the German word Hoheitliche Institutionen. ReqID Requirement Description U H 1 U H 2 Anonymized reports Privacy and data protection Public authorities and civil defense request anonymized reports to govern the healthcare system by implementing regional or trans regional actions. Protection of medical data is of vital interest. National, European and international data protection laws have to be observed. Table 4.6: User requirements for Shared Electronic Health Records identified for public authorities. Source: Schabetsberger [12, 13] Summary of User Requirements User requirements have been described for the actors defined in section 4.1 on page 69. Overlapping requirements can be clearly identified. Electronic prescription is, for example, a feature requested by patient, pharmacies and medical professionals. Although those features have partly

90 76 Chapter 4: Requirements for Shared Electronic Health Records distinct characteristics for different actors, they have much in common, which is expected to facilitate implementation. Security requirements are obviously a big concern for all actors. Security has to be carefully analyzed due to partly contradicting functional requirements. Patients, for example, expect health insurances not to access their medical data. However, insurances need a particular subset of a patient s medical data for accounting. Providing a security model which satisfactorily solves those issues is a big challenge and is also addressed in this work. 4.3 System Requirements Based on the user requirements (See section 4.2 on page 70) a detailed requirements profile was elaborated. A requirements pool for collecting user, functional, non functional and environment specific requirements as well as system requirements are results of the intermediate steps introduced in the software process in section on page 55 and depicted in figure 3.4 on page 58. The requirements profile is a comprehensive document whose full inclusion would reach far beyond the scope of this work. For that reason system requirements representing core functionality are exemplified in this section. System requirements specified here directly correspond to main components of the architecture, so their description is expected to facilitate understanding of the later developed architecture while not providing too many details (See chapter 6 on page 111). User requirements can not be directly mapped to system requirements. Generally a specific user requirement is covered by multiple system requirements and a collection of system requirements, in turn, supports a particular user requirement. In the following a short definition of terms used in system requirements is given to provide a clear understanding for the reader. Actor: Individual or institution acting on behalf of a person interacting with the Electronic Health Record. Patients or physicians are, for example, defined as actors. Although an interaction is always carried out via software systems, an actor is here defined as physical person. This definition differs from the IHE Interaction Profiles where actors explicitly are defined as software systems (See section on page 26). Document: A document is the smallest unit of medical information. Documents can logically be grouped to document collections similar to folders in a file system. A collection is a more abstract definition than folders and collections defined by the IHE XDS Interaction Profile (See section on page 27). Document Collection: A document collection or collection is a virtual group of documents which logically belong together. Collections can be grouped by arbitrary criteria such as producer, time range, or disease. A user defined folder is an example of a simple collection.

91 4.3 System Requirements 77 Interaction: Interactions are operations carried out on systems of the record when using them. Typical interactions are adding and accessing documents. Producer: A producer is the actor who generates a document. Resource: Resource are bookable entities with constrained capacity or time of availability. Hospital beds and appointments with physicians are, for example, defined as resources. As a key requirement for a patient centered Shared Electronic Health Records patients expect access to their personal health record. Two different types of access have been identified: On the one hand patients request passive access to the record for viewing stored documents and on the other hand patients would like to actively add data to the record, such as blood pressure measurements or a pain diary. System requirements analyzed for the first are represented in table 4.7 on the following page and for the latter in table 4.8 on the next page. It is considered vital for patients who after all have no profound medical knowledge that medical contents are presented in a readable and understandable form. To a large extent active access for a patient to his personal Electronic Health Record comprises the management of access permissions (See table 4.13 on page 84). Patients must be able to issue fine grained permissions for other actors to access well defined parts of their record. Data protection and privacy is of course of major concern for all actors and required by national and international laws and regulations as described in section on page 31. Therefore security requirements were carefully analyzed and two different types of system requirements were identified. General security requirements are listed in table 4.12 on page 83, requirements for defining access permissions in table 4.11 on page 82 and requirements for Role and Context based Authorization in table 4.13 on page 84. Furthermore in section 4.4 on page 89 security requirements are categorized and discussed in detail to provide a clear understanding of security issues. Passive access to personal health record (view) ReqID S 1 Links to U P 1, U P 2, U P 5, U P 10 Description Patients want their personal medical data to be collected in an Electronic Health Record (EHR). The EHR should be accessible independent of location and time via standard Web technology. Information is displayed in a representation which is understandable for the patient e.g. by the use of dictionaries. The record supports user defined document collections. Information can be displayed in structured or grouped representation by date, producer, disease or as a user defined collection. The EHR supports download of selected documents or collections as archives for backup purposes. continued on next page...

92 78 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects Passive access to personal health record (view) High. Functional requirement. Specific to patients. Selected data from health record. Authentication data. Web portal or patients personal management software. Electronic health record. View of health record in requested representation e.g. Web site in portal. Web browser or patients personal management software. Personal Electronic Health Record. User account. Patient must be identified and authorized to access EHR. User preferences e.g. views or folders are saved to EHR. None. Table 4.7: The table above describes system requirements identified for patients to access their personal Electronic Health Record to view stored data. Active access to personal health record (append) ReqID S 2 Links to U P 2, U P 3, U P 4, U P 6, U P 7.5, U M 4 Description Patients would like to add personal data to their EHR. Appended information should be accessible for the patient and authorized actors. Patients can import external documents of proprietary records. Data acquired by mobile devices should be added semi automatically after authorization and confirmation of the patient. Particular parameters can be marked for monitoring, in case of critical changes physician/patient/rescue service is notified. Electronic orders can be placed by the patient, including ordering of drugs and booking of resources. Data added can not be deleted but marked as inactive and excluded from display. Audit logs are displayed in a format readable for patients. Access attempts from actors in a customizable period of time can be listed. Potential unauthorized access attempts are clearly marked. Priority High. Type Functional requirement. Specific to patients. Input Data added by patient or imported from other record or mobile device. Origin Mobile device. Web portal. Proprietary record. Output Document or data item to be saved in the record. Target Patient s personal Electronic Health Record. Requires Personal Electronic Health Record. User account. Input data. Precondition Patient must be identified and authorized to access personal health record. Imported data must be in adequate format. Postcondition Appended data is stored to the record. Side effects None. Table 4.8: The table above describes system requirements identified for patients to add entries to their personal Electronic Health Record.

93 4.3 System Requirements 79 Medical professionals require passive and active access to a patient s Electronic Health Record. System requirements were therefore analyzed and are represented in table 4.9 on the following page. Relevant documents should be accessible from within the application a physician is currently working on and reading a patients documents should not interrupt the workflow. Relevant documents produced by medical professionals should be seamlessly and automatically integrated in the record after they have been approved as correct and final. This definitely means that not all documents produced in healthcare institutions should be added to the record as a primary protection against information overload. Only relevant documents required by other healthcare actors in the treatment process should be added. According to the current legal situation in Austria (See section 2.8 on page 31) a consent of the patient is not required when documents are added, but as soon as information is received the patient s consent however is a strict prerequisite. A big challenge has been identified here: As described above medical professionals require only relevant information to be presented and not to be flooded with information less relevant for a particular case. In the opinion of the author the definition about what is relevant in a specific case can not solely be solved by technology. In the HIS architecture technical means have to be created to filter the displayed information by its relevance, but what is relevant for a particular case or disease has to be defined by medical professionals and regulated by organizational means. Passive and active access to patient s health record (view/append) ReqID S 3 Links to U P 2, U P 3, U M 1, U M 2, U M 4, U M 10, S 4 Description Medical professionals require access to relevant documents of their patients in treatment. A customizable view of documents is requested, where each physician can define document types relevant for a specific patient. Similar to patients, medical professionals expect structured views grouped by user definable criteria such as case or collections created by the patient. In case of emergency, physicians require a simple mechanism for accessing all relevant documents of a patient. In emergency access all documents should be accessible but predefined filter criteria should apply so that only information relevant for emergency situations (e.g. current medication and list of relevant diagnoses) is displayed. Physicians want to consult a colleague while accessing the same data basis (S 4 ). Documents produced by a medical professional or institution should be seamlessly integrated in the record as far as they are not defined for internal use only. In case of changes or updates of documents the previous version is to be marked as invalid and excluded from display. continued on next page...

94 80 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects Passive and active access to patient s health record (view/append) High. Functional requirement. Data added by medical professional. Clinical Information System. GP s system. Web portal of medical professional. Document or data item to be saved in the record. Patient s personal Electronic Health Record. A Patient s Electronic Health Record. Authorization of patient to access record. Physician must be authorized to access a patient s EHR. Data added must be in adequate format. Appended data is stored to the record. None. Table 4.9: The table above describes system requirements identified for medical professionals to access a patient s Health Record after successful authorization. Medical professionals as well as patients require a secure link to communicate with each other; Patients for online consultation, physicians typically for second opinion. Communication partners must therefore be presented the same view of the record. Privacy protection and access control is of major concern here: Physician A wants to consult physician B for a second opinion about patient P. Patient P must therefore authorize physician B to access the same parts of the record as physician A does. An option for the patient to give a general consent for online consultations and second opinion carried out by the physician is to be implemented as an alternative to simplify this procedure. Direct communication ReqID S 4 Links to U P 3, U P 12, U M 3 Description The EHR should support direct communication (actor to actor). For online consultation a secure link between actors is to be established. Documents or collections can be shared for communication partners during a session. A consent of both partners is required. Search functions are provided to find communication partners. Direct communication is to be integrated in Web portals, GP s systems CIS and Patient s personal management software. Priority Medium. Type Functional requirement. Input Communication partner. Data to be shared. Authorization. Origin Web portal. Patient s personal management software. GP s system. Electronic Health Record. Output Messages or data stream of communication. Target Web portal or information system of the communication partner. continued on next page...

95 4.3 System Requirements 81 continued from previous page... Requires Precondition Postcondition Side effects Direct communication Personal Electronic Health Record. User account. Communication partner. Consent of communication partners. Access permissions to documents for communication partners are withdrawn after communication ended. None. Table 4.10: The table above describes system requirements identified for direct communication of medical professionals among each other and with patients. Patients can decide who may access their medical data. Not all patients are expected to either be able or willing to manage access permissions. A restrictive model where the patient must grant access on any piece of information before it becomes accessible would tremendously impair functionality of the SEHR system. Therefore default permissions are introduced, which apply if no action is taken by the patient. Default permissions only allow access to documents according to the 4 Eye Principle where a treatment relationship between patient and physician must be present (See section 2.8 on page 31). Management of access permissions ReqID S 5 Links to U P 2, U P 7.1, U P 7.2, U P 7.3 Description Patients can (but must not) issue access permissions per document or folder. Default permissions apply if no action is taken. In this case physicians currently involved in a patient s treatment process are granted access to medical documents. Patients can grant access permissions for defined documents or folders to specific physicians for a restricted period of time (overrides 4 Eye Principle). Specific documents or stays can be hidden even from the patient himself. Patients can define a proxy person and in turn become a proxy person to act on the behalf of someone else. For granting access permissions a secure token is passed to the respective actor (e.g. physician or proxy) defining resources (e.g. documents) to be accessed and expiry date. Access is logged for later audit, which particularly applies for unauthorized access attempts. continued on next page...

96 82 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects Management of access permissions High. Functional requirement. Specific to patients. Documents or folders to be shared. Actor to be permitted (recipient). Expiry data. Restrictions. Web portal or patient s personal management software. Electronic Health Record. Policy and secure token. Electronic Health Record. Permitted actor. Personal Electronic Health Record. User account. Permission to share documents or folders. Recipient. Recipient is identified. Recipient receives secure token. Access to resources is granted. Access permissions are withdrawn after expiration. Hidden data can not be viewed which might affect treatment process. Table 4.11: The table above describes system requirements identified for patients to manage access permissions for their personal Electronic Health Record. General security requirements ReqID S 6 Links to All functional security requirements. Description Medical data must not be disclosed to unauthorized parties. Classical security requirements apply as follows: Medical data in transfer is to be protected from modification and must not be visible for unauthorized parties (confidentiality, integrity). Interactions must be traceable (authentication, non repudiation). Components (e.g. services) must be resistant against denial of service ((D)DoS) attacks (availability). Secure authentication between components is required to prevent Man In The-Middle attacks. Secure user authentication is required for auditing and prevents unauthorized access to medical data. Compromised components should not lead to disclosure of medical data which can be assigned to an identifiable patient. Therefore patient identification must be separated from other components. End to End security between components/applications is required which should not end at network or transport level. continued on next page...

97 4.3 System Requirements 83 continued from previous page... General security requirements Priority High. Type Non functional requirement. Input N/A. Origin Health record s core components. Output N/A Target Health record s core components. Requires Security infrastructure of SEHR architecture. Security model. Precondition N/A. Postcondition N/A. Side effects Authentication conflicts with anonymity. Pseudonymization is required to ensure anonymity when required. Table 4.12: The table above describes general security requirements to ensure the highest possible degree of privacy and data protection. Role and context based authorization assigns active access permissions to actors based on their role and the context of requested information [79]. Pharmacists (role), as an example, must have access to prescriptions (context), whereas other medical information should only be accessible for the patient himself and for actors assigned the role of medical professional. System requirements for role and context based authorization are outlined in table The definition of roles and the assignment of individuals to specific roles is seen as a challenge which has, in the opinion of the author, to be solved by organizational means.

98 84 Chapter 4: Requirements for Shared Electronic Health Records Role- and context based authorization ReqID S 7 Links to U P 7.1, U P 7.5, U M 1, U I 4.1, U A 5.1 Description Access requests have to be authorized by both, owner (e.g patient) and actor with access request (e.g. Physician). Access permissions should follow a role and context based approach. Roles define which potential permissions can generally be assigned to user groups. Physicians, for example, generally can get access permissions to parts of a patient s record. The context describes actual access permissions which arise from the current relationship between the actors. A particular physician might, for example, only access a patient s document if he is currently involved in the treatment process, which means that the actual context is treating physician. Role and context based permissions should be configurable as requirements might change over time. Priority High. Type Non functional requirement. Input Secure user authentication token. Security policy. Origin Health record s core components. Web portal or patient s personal management software. Output N/A Target Health record s core components. Storage location of documents. Requires Security infrastructure of SEHR architecture. Security model. Security policies. Secure user authentication. Precondition Actor is unambiguously identified. Postcondition Access attempt to resource is logged for auditing. Side effects None. Table 4.13: The table above describes system requirements identified for role and context based authorization as access control mechanism. For reasons of interoperability in a trans regional context data standards and transmission standards are required to facilitate communication between heterogeneous systems. The first regulates syntax and semantics of transmitted data, whereas the latter regularizes interfaces between communicating applications. Motivated by the Austrian e-health Initiative an e-health feasibility study 1 supported by the Austrian government was carried out. A clear recommendation of the study is to use the Clinical Document Architecture (CDA) (See section on page 23) as data standard and the IHE Cross Enterprise Document Sharing Profile (XDS) (See section on page 27) as transmission standard. In the opinion of the Author this decision is reasonable and a large step towards interoperable Shared Electronic Health Records in Austria. An analysis carried out by the health@net project team came to the same result and proposed CDA Release 2 as data standard and IHE XDS 1 Commonly known in Austria under the German term: e-health Machbarkeitsstudie.

99 4.3 System Requirements 85 as transmission standard. Those results were published before the feasibility study had been started [53, 80]. System requirements for data standards are outlined in table 4.14 which additionally describes requirements for converting documents in proprietary format to the internally used data standard. Requirements for transmission standards are described in table 4.15 on the following page. Common data standard and conversion ReqID S 8 Links to S 1, S 2, S 3 Description Medical data (e.g. documents and images) must be in a standardized format accessible for participating systems. Documents must furthermore be in structured human and machine readable format. This provides for automated classification of documents. The standard should also support metadata in documents such as producer and producing institution. Document formats internally used in an institution should not be affected. Documents must therefore be converted at the producing institution to a standardized format all participants have agreed on. Priority High. Type Non functional requirement. Input Original document in proprietary format. Origin Clinical Information System. GP s system. Mobile device. Output Document in standardized, structured human and machine readable format. Target Health record s core components. GP s system. Mobile device. Requires A widely used medical data standard for structured documents. Systems for document conversion. Precondition Proprietary documents can be enriched with sufficient metadata needed for the structured format. Postcondition Document is converted to standardized, structured human and machine readable format. Side effects None. Table 4.14: The table above describes common data standards and conversion routines as system requirements for interoperable SEHR systems.

100 86 Chapter 4: Requirements for Shared Electronic Health Records Common transmission standard ReqID S 9 Links to All system requirements. Description For interoperability with other records and Health Information Systems transmission of medical data must be standardized as far as possible. Ideally participating systems should support the same types of interfaces. Transmission standard should be independent of data standard, so that different document types can be transparently transmitted. A transmission standard must support general security requirements (S 6) and provide means for integrating authorization information (S 7). Priority High. Type Non functional requirement. Input Document to be transferred. Authentication information. Origin Clinical Information System. GP s system. Mobile device. Output Document after transfer. Target Health record s core components. GP s system. Mobile device. Requires A widely used medical transmission standard. Precondition Documents must be in adequate format. Security policy permits transmission. Postcondition Transmitted document is not altered in any way. Side effects None. Table 4.15: The table above describes a common transmission standard as system requirement so that medical data can be transmitted via standardized communication paths between systems in a SEHR. A common unique identification of patients is required to unambiguously assign any piece of medical information to a specific patient. In Austria a common patient index, known as Master Patient Index (MPI) is currently not available. Nevertheless each citizen is identifyable via the social security number 2 (SSN) and a unique identification number assigned for the use by governmental institutions 3. Both sources can be used as provider for unique patient identification. Limitations of the social security number however are that not all Austrian citizens have a social insurance and therefore not every citizen has an assigned SSN. System Requirements for patient identification are outlined in table 4.16 on the next page. 2 The social security number has become unique just recently. 3 Commonly known in Austria under the German term Zentrales Melde Register.

101 4.3 System Requirements 87 Patient identification ReqID S 10 Links to All system requirements. Description Patients must be unambiguously identifiable and documents must be assigned to a unique patientid. For security reasons Patient demographic data (e.g. name and date of birth) should not be used in documents and be replaced by the PatientId. For pseudonymization the PatientId can be replaced by an arbitrary value to ensure anonymity (S 3 ). The PatientId must not be visible for actors and transparently be converted to demographic data after proper authorization. Priority High. Type Non functional requirement. Input Patient demographic data. PatientId. Origin Clinical Information System. GP s system. Mobile device. Output Health record s core components. Patient demographic data. PatientId. Target Clinical Information System. GP s system. Mobile device. Requires Health record s core components. Patient demographic Data. PatientId. Precondition Patient can be identified by an unambiguous token (e.g. Austrian e-card). Postcondition Demographic data are mapped to PatientId. PatientId is mapped to demographic data. Side effects Pseudonymization can and should prevent from unauthorized identification of the patient. Table 4.16: The table above describes system requirements identified for a common patient identification which is necessary for assigning medical content to an unambiguously identified patient. For medical applications a variety of data standards and transmission protocols such as HL7 and DICOM has been developed which have been in use for many years. Those protocols must be supported by SEHR systems to facilitate interoperability with existing medical applications. System requirements for common medical protocols are outlined in table 4.17 on the following page. Interoperability and support of common medical protocols ReqID S 11 Links to N/A Description Interoperability with common HIS is desired. Clinical Information System and GP s systems must seamlessly integrate in the EHR. This means that medical professionals can search for patients in their proprietary systems and retrieved documents should be transparently displayed there. Common medical protocols (e.g. HL7, DICOM) should be supported when adding and retrieving medical documents. continued on next page...

102 88 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... Interoperability and support of common medical protocols Priority High. Type Domain requirement. Input Search parameter for specific patient. Origin Clinical Information System. GP s system. Mobile device. Output Documents or collections retrieved for respective patient. Target Clinical Information System. GP s system. Mobile device. Requires Patient s personal Electronic Health Record. Proprietary system with compatible interfaces. Precondition Physician is authorized to access documents. Postcondition Documents are integrated in proprietary system and displayed. If required they can be saved until expiration. Side effects None. Table 4.17: The table above describes system requirements identified for interoperability between different systems in a SEHR or even different SEHR systems, potentially delivered by different vendors Domain Requirements For SEHRs a variety of requirements specific to the medical domain were identified which are described in alphabetic order in the list below: Availability The SEHR system has to be highly available and failures of specific components must not affect overall availability. According to the proposal of the Austrian e-health Feasibility Study (See section on page 34) availability of 99.5% is a vital requirement. Document Location Medical documents should reside in the institution where they were produced and they should be accessible independent of location or time. The Austrian e-health Feasibility Study (See section on page 34) proposes a distributed storage of documents in the producing institutions. Response Time The time between request and response has to be kept as short as possible. A reasonable value is 1 second after which the first results should be displayed to the end user. Scalability The SEHR system has to be able to cope with rising amounts of data to be transferred and with an increasing number of patients.

103 4.4 Security Requirements Security Requirements For any type of application which processes medical data security and privacy protection is of major concern (See section 2.8 on page 31). Particularly for Shared Electronic Health Records operating in a trans institutional context measures have to be taken to avoid disclosure of medical data to unauthorized individuals or institutions. Functional requirements for authentication and access control as outlined in table 4.13 are by far not sufficient enough for secure SEHR systems. For critical systems such as SEHRs both functional and non functional requirements have to be considered, whereas many of these are common for all types of IT systems and only a few are system or domain specific [21]. However, security requirements for medical applications are much higher than for other systems, especially concerning authorization and access control [79]. The 4 Eye Principle as described in section is, for example, a domain specific security requirement for SEHR systems which incorporates complex authorization aspects. A variety of non functional requirements as discussed above has to be considered in order to prevent unauthorized access and manipulation of medical data. In the following fundamental non functional security requirements, common for all types of IT systems are described. Those measures which evolved from long experience with information security have been published by governmental institutions in Austria 4 and Germany 5 [81, 82]. The core statement of the mentioned handbooks, is that security can not solely be guaranteed by technical means, but rather that organizational security concepts and policies that provide measures to reduce security risks to an acceptable level are in fact absolutely vital for systems with high security requirements. The Austrian IT Security Handbook proposes seven classes of security measures: 1. Edificial and Infrastructural Measures 2. Human Resources Measures 3. IT Security Management 4. Security in System Development 5. System Security 6. Maintenance of Security for Production Systems 7. Disaster Recovery and Business Continuity Planning 4 In Austria as IT Sicherheitshandbuch : IT Security Handbook. 5 In Germany as IT Grundschutz Handbuch : Basic (Data) Protection Handbook.

104 90 Chapter 4: Requirements for Shared Electronic Health Records (1.) Describes security measures for the building in which IT systems are operated in, such as structural fire protection, physical access control and emergency power supply. Awareness for security has to be created by the employees and they have to be instructed about security measures (2.). IT Security Management (3.) is a management process to appoint security goals of an enterprise. In this process security risks and threats are analyzed, requirements defined and security measures proposed. Security requirements have to be considered in the design phase of a software system and are thus an integral part of the entire software process (4.). This comprises an analysis of security requirements in the design phase, generation of secure code and documentation in the implementation phase, as well as evaluation of security in the validation phase. Security measures for authorization and access control, network configuration, and protection against malware such as viruses and Trojan horses are classified as System Security (5.) This also comprises network security measures for protection of transmitted data such as Virtual Private Networks (VPNs) and Transport Layer Security (TLS) based on common cryptographic protocols and algorithms. The IT security process is rather a dynamic than a static process, therefore additional measures are required to maintain a high level of security after applications have been deployed in production environments (6.). Maintenance, software updates and Incident Handling as reaction to security relevant events are crucial activities. The aim of (7.) is to guarantee the availability of core applications and IT systems within a predefined range of time and provide measures to recover from disasters. Continuous backups and strategic planning for recovery are important points. All those aspects are vital for secure SEHR systems, however Security in System Development and System Security have been identified as directly related to the HIS architecture and will therefore be discussed in detail. Firesmith identified and published 12 vital items in engineering security requirements [83] which are outlined along with a short description in table 4.18 on the facing page. Depending on the type of system possibly not all of them apply [21]. ReqID Requirement Description Sec 1 Sec 2 Sec 3 Sec 4 Sec 5 Identification Requirements Authentication Requirements Authorization Requirements Immunity Requirements Integrity Requirements A system shall identify its users and external applications before interacting with them. A system shall verify the identity of its users and external applications before interacting with them. Specifies the access and usage privileges of authenticated users and client applications. A system shall protect itself from infection by unauthorized undesirable programs (e.g., computer viruses, worms, and Trojan horses). A system shall ensure that its data and communications are not intentionally corrupted via unauthorized creation, modification, or deletion. continued on next page...

105 4.4 Security Requirements 91 continued from previous page... ReqID Requirement Description Sec 6 Sec 7 Sec 8 Sec 9 Sec 10 Sec 11 Sec 12 Intrusion Detection Requirements Nonrepudiation Requirements Privacy Requirements Security Auditing Requirements Survivability Requirements Physical Protection Requirements System Maintenance Security Requirements A system shall detect and record attempted access or modification by unauthorized individuals. A system shall prevent a party from denying having participated in all or parts of the interaction. A system shall keep its sensitive data and communications private from unauthorized individuals and programs. A system shall enable security personnel to audit the status and make use of its security mechanisms. A system shall survive the intentional loss or destruction of a component. A system shall protect itself from physical assault. A system shall prevent authorized modifications (e.g. defect fixes, enhancements, updates) from accidentally defeating its security mechanisms. Table 4.18: In the table above security requirements identified by Firesmith [83] are outlined and a short description is given Clustering of Security Requirements For mapping the identified items to SEHR systems the author of this thesis proposes a classification according to their domain. The performed clustering is expected to facilitate their assignment to the field of responsibility as different institutions are involved in development and later operation of a SEHR architecture. As an example network security can be dedicated to network management teams in the involved institutions. The major advantage of this clustering is that each class can be modeled as non functional system requirement which provides a higher level of abstraction. The clustering facilitates the understanding of security requirements by the involved actors represented in figure 4.1 on page 70 and other persons involved in the development process who do not have profound knowledge in security engineering. The clustering reduces the effort for requirements validation. Proposed classes can furthermore be perfectly integrated in the requirements document. The comparison of architectures in chapter 5 on page 97 makes use of the identified classes to evaluate centralized and distributed architecture on the basis of compliance to security requirements. The following five classes have been identified, but multiple assignments of items to classes are possible.

106 92 Chapter 4: Requirements for Shared Electronic Health Records Security of Architecture (ArchSec) The system architecture must be designed to support security to an extent required by the applications. The decision whether the architecture should be centralized or distributed is of major concern. Both, client server and distributed object architectures have their particular advantages and drawbacks for designing secure systems. If a distributed architecture has been chosen the composition of services and their interactions influences overall security. Software Security (SwSec) The system must be securely implemented. This basically comprises checking of input data for validity, measures for avoiding code injection (e.g SQL injection for database applications), information hiding where possible such as usage of private member variables. Network Security (NwSec) Data in transfer must be protected from unauthorized access or manipulation. Encrypted transfer and Service to Service authentication for avoiding Man in the Middle attacks are basic concepts of network security. The author believes that Firewall friendliness contributes to network security within institutions participating in a SEHR. This means that the HIS architecture should use commonly open ports such as HTTP (Port 80) or HTTPS (443) without requiring dynamic port(ranges) to be opened by the network administrators on enterprise firewalls. User Security (UsrSec) User Security is a measure to ensure that a user can only access data he is allowed to access. As reliable identification and authentication are prerequisites for role and context based authorization it is a major goal to prevent users from forging their identity. Therefore secure authentication (comprises identification) mechanisms are required. Data Security (DataSec) Unauthorized access and manipulation of medical data has to be prevented. This firstly requires concepts to withdraw the power from system administrators to arbitrarily gain access to medical data. Secondly effects of potential system compromise must be limited in a way that data illegally accessed by attackers can not easily be assigned to a particular patient. Therefore patient demographic data such as name, address date of birth,... must be separated from medical data. In section on the next page the clustering of security requirements is described. Security requirements outlined in table 4.18 on the preceding page are assigned to the elaborated classes described on the previous page. As clearly shown in section on the facing page the classes Security of Architecture and Network Security have the most items assigned to them. An interpretation of the author is that those classes comprise basic security concepts which are absolutely mandatory for higher level features such as User Security. Authorization and access control mechanisms are considered ineffective and can easily be bypassed if the HIS architecture is insecurely designed. Medical data insufficiently protected during transfer also renders higher level security concepts useless.

107 4.4 Security Requirements 93 Security Requirement Security Class ArchSec SwSec NwSec UsrSec DataSec Sec 1: Identification X X Sec 2: Authentication X X Sec 3: Authorization X Sec 4: Immunity X X Sec 5: Integrity X X Sec 6: Intrusion Detection X X Sec 7: Nonrepudiation X X Sec 8: Privacy X X Sec 9: Security Auditing X X Sec 10: Survivability X X Sec 11: Physical Protection Covered in the IT Security Handbook Sec 12: System Maintenance X X Table 4.19: In the table above security requirements were assigned to the identified classes. Classes and requirements follow an n : m relationship, where each class can be supported by 1... n requirements and each requirement in turn can be assigned to 0... m classes. In table 4.20 on the next page security requirements for a HIS architecture to support the class Security of Architecture are described. ReqID Links to Description Security of Architecture ArchSec SwSec A secure architecture must avoid single point of failure or attack. The architecture must be largely immune against denial of service attacks, so if one component fails it must still be usable. A single point of attack is to be avoided, which is, if a specific component is compromised, the attacker must not be able to access any piece of information which resides outside this component. Services have to authenticate themselves and verify that the particular request of the calling service is allowed. The matrix which service may invoke another is to be configured as policies which can be changed during runtime. continued on next page...

108 94 Chapter 4: Requirements for Shared Electronic Health Records continued from previous page... Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects Security of Architecture High. Non functional security requirement. N/A N/A N/A N/A Securely designed services. The design of the architecture has to be validated for compliance to security requirements. The architecture has to be securely implemented. Security flaws in the architecture endanger overall security. Table 4.20: The table above describes security requirements for the class Security of Architecture. In table 4.21 security requirements for secure software development to support the class Software Security are described. ReqID Links to Description Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects Software Security SwSec ArchSec Software has to be securely implemented and tested for potential flaws. Input has to be validated and code injection to be avoided. Measures have to be taken that sensitive information is not disclosed in case of exceptions or system failure. To facilitate code audit in terms of security a well documented source code has to be produced High. Non functional security requirement. Requirements document and definition of subsystems, modules and interfaces. Specification phase of the software process. Source code in chosen programming language. Deployment on production servers. Securely designed architecture and components. The specification of the components has to be validated for compliance to security requirements. The software has to be deployed on secure production systems. Security flaws in the software endanger overall security. Table 4.21: The table above describes security requirements for the class Software Security. In table 4.22 on the next page security requirements for secure communication between networked nodes to support the class Network Security are described.

109 4.4 Security Requirements 95 ReqID Links to Description Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects NwSec Network Security Medical data transferred via potentially insecure networks have to be protected against unauthorized access or manipulation. Transmitted data have to be encrypted during transfer. End to End security is required to continuously protect medical data from the application of origin to their destination. Systems where medical data are processed and reside on have to be protected against network attacks and denial of service attacks. Intrusion detection/prevention measures and security audit of system log files is required. Systems must be operated behind firewalls with only required ports opened. High. Non functional security requirement. N/A N/A N/A N/A Securely designed network architectures inside institutions participation on the SEHR. Network links with sufficient bandwidth between involved institutions exist. Secure link between institutions is established. An insecure network architecture endangers overall security. Although End to End security is ideally guaranteed by communicating applications secure network links are still required. Table 4.22: The table above describes security requirements for the class Network Security. In table 4.23 security requirements for secure user authorization and access control to support the class User Security are described. ReqID Links to User Security UsrSec See system requirements (S5 and S7.) Table 4.23: The table above describes security requirements for the class User Security. In table 4.24 on the next page security requirements for preventing stored medical data to be mapped with patient demographic data to support the class Data Security are described.

110 96 Chapter 4: Requirements for Shared Electronic Health Records ReqID Links to Description Priority Type Input Origin Output Target Requires Precondition Postcondition Side effects DataSec Data Security Medical data must be protected against unauthorized access or manipulation. Produced data must be assignable to the producer, the institution and the exact time they have been produced for reasons of nonrepudiation. The link to a patient s demographic data has to be removed as early as possible and replaced by an internally used unique ID. In case of successful system compromise the attacker obtains quasi useless information since the patient context can not be established. Measures have to be taken to prevent system administrators from illicitly accessing medical data. High. Non functional security requirement. Original medical data. Subsystems which produce or change medical data. Data to be saved to the record with security features added. Health record s core components. N/A N/A N/A None. Table 4.24: The table above describes security requirements for the class Data Security. 4.5 Summary and Conclusion In this section requirements for implementing a HIS Architecture for Shared Electronic Health Records were outlined. Starting from identified actors and the analysis of functional requirements initially carried out by Schabetsberger [12, 13], user, system and security requirements have been elaborated. During the analysis of those requirements particularly for engineering security requirements knowledge of domain experts identified in table 3.1 on page 53 was required. Experts were therefore consulted using the problem centered interview as standardized methodology for obtaining reproducible results. Although requirements have been carefully analyzed the author expects that some of them will change in the future probably caused by different legal constraints and also because new user requirements will have to be considered, which could lead to a dramatic change in system and security requirements. The chosen evolutionary software paradigm as described in section on page 54 is expected to be well suited to cope with changing requirements since they can easily be incorporated in the next prototype and finally in the productive release. In the following chapter those requirements are taken as basis for the comparison of existing HIS architectures and their applicability for Shared Electronic Health Records.

111 Chapter 5 Comparison of Existing Architectures for SEHRs In this chapter architectural styles of HIS architectures are compared and evaluated with regard to their applicability for Shared Electronic Health Records. The evaluation focuses on the two fundamental styles centralized and distributed architectures. As introduced in section 2.3 on page 10 an architectural style is a summation of architectures with certain characteristics in common. This evaluation is a vital aspect for developing the HIS architecture for SEHRs since both, centralized and distributed architectures have their advantages and also drawbacks. It is, according to Problem 2, currently not known which architectural style best supports the requirements analyzed in chapter 4 on page Definition of Centralized and Distributed Architectures As a first step a definition of centralized and distributed architectural styles has to be given. According to Sommerville a distributed system is a system where information processing is distributed over a number of different computers rather than on a single machine (See section on page 11) [21]. Since, corresponding to this definition, virtually any HIS architecture is a distributed system, a more fine grained classification is needed. Data manipulation such as storage and processing are core functions of SEHR systems, so the author proposes the following classification of HIS architectures on the basis of data manipulation: Centralized HIS architectures: These are HIS architectures which require centralized services for manipulation of medical data. This particularly means that a few services provide data manipulation functionality for a larger set of clients. A clear distinction between servers and clients is possible.

112 98 Chapter 5: Comparison of Existing Architectures for SEHRs Figure 5.1: In (A) a client server architecture is shown. Each client machine (C1... Cn in blue) can run multiple client processes (cp1... cpn). Each server machine (S1... Sn in green) can run multiple server processes (sp1... spn). In (B) a distributed object architecture is described which allows mutual communication between objects (Object 1... Object n) via their interfaces (Iface(O1)... Iface(On) in orange) and a Middleware (light yellow in the center of figure B). For further details refer to the text. Distributed HIS architectures: These are HIS architectures without the need of centralized services where data manipulation is decentralized and dedicated to the institutions which produce medical documents in a patient s treatment process. Subsystems can concurrently act as service provider and service consumer, so a distinction between servers and clients is not possible. The first, centralized HIS architectures, exactly match the definition of client server architectures given in section on page 11, which is summarized as a few servers providing services for a larger number of clients. A server is thereby in the strict sense a process which provides a specific service, where a single machine can host multiple server processes. In figure 5.1 the differences between generic centralized and distributed architectures are shown. For the second group, distributed HIS architectures, an exact mapping to the definition of distributed object architectures, given in section on page 11 has been identified, which is in short objects that concurrently provide and make use of certain functionality. Objects communicate via their interfaces and a middleware. As an example, in a centralized HIS architecture medical data reside on a single, potentially replicated server which is responsible for an entire healthcare region. In a distributed HIS architecture medical data remain stored in the institutions where they have been produced and can be accessed from other institutions. Haux describes architectures with a central component for data manipulation as DB 1 architectural style and those with multiple, distributed components as DB n style on the logical tool layer of the 3LGM metamodel. 3LGM comprises three layers where the first, the domain layer

113 5.2 Evaluation Criteria for HIS Architectures 99 focuses on enterprise functions, the logical tool layer as second layer focuses on the application components and the third describes physical data processing components [14]. Regarding the logical tool layer centralized HIS architectures can be compared to the DB 1 architectural style and distributed HIS architectures to the DB n style. However, this definition has originally been defined for Hospital Information Systems and focuses on application components containing databases. Although, for that reason, the given definition can not be transfered to Health Information Systems in a trans institutional context, it helps to map the identified classes to the terminology used in medical informatics to facilitate understanding for the reader. 5.2 Evaluation Criteria for HIS Architectures The process of selecting the most adequate HIS architecture for Shared Electronic Health Records requires criteria to be selected against which the architectures are compared. Bosch describes that the architecture of a system influences performance, robustness, distributability, and maintainability of systems [84]. Summerville identifies the following five vital non functional system requirements which have to be considered when selecting the system architecture [21]: 1. Performance: Communication between subsystems influences performance. 2. Security: Security depends on whether critical operation can be carried out at a single system or if multiple systems are involved. 3. Safety: Safety is, as an example, the prevention of documents from being corrupted or even worse assigned to a wrong patient in case of unwanted system behavior. The effort for protection depends on whether critical operations can be carried out within a single system or if multiple systems are involved. 4. Availability: Redundancy of subsystems influences availability. 5. Maintainability and Scalability: Maintainability depends on whether self contained components can be easily changed. Maintainability is directly related to scalability which means that rising data volumes can be handled easily. In section 5.3 on the following page centralized, and in section 5.4 on page 102 distributed architectures are analyzed according to the above mentioned criteria for their adequacy for SEHRs. The analysis furthermore takes into account system requirements described in section 4.3 on page 76 along with their domain requirements (See section on page 88). As security is of utmost importance, the comparison of architectural style focuses on the clustered security requirements identified in section on page 91. The class software security can not be analyzed separately for centralized and distributed architectures. It provides information about whether the software is securely implemented and this is common for both, distributed and centralized architectures.

114 100 Chapter 5: Comparison of Existing Architectures for SEHRs 5.3 Evaluation of Centralized HIS Architectures Centralized HIS architectures have mainly been used as the development of Electronic Health Records started. Web based systems using the widespread client server architecture, such as Akteonline in Germany, Diraya in Andalusia (Spain) and common health record banks are well known representatives of centralized HIS architectures [8, 10, 61, 62] (See also section 2.10 on page 35). Although centralized architectures might physically consist of multiple redundant, replicated servers there is logically only one server communicating with a number of clients. For that reason the author describes a single server in the context of centralized architectures. Performance of Centralized HIS Architectures According to Sommerville performance critical systems should localize critical operations within a small number of subsystems with as little communication as possible between them [21]. This is especially true when subsystems have to communicate via potentially slow network links. Centralized HIS architectures with a central subsystem for data manipulation have a clear advantage as far as performance is concerned, since the only communication via a potentially slow network link is between server and clients. Compliance to the domain requirement of a response time lower than 1 second is expected to be easily achieved. However, as multiple clients concurrently access the SEHR system compute power, input/output (IO) throughput of storage media and network bandwidth of the central server might turn into a bottleneck. Security of Centralized HIS Architectures For security critical systems a layered structure of the architecture is proposed by Sommerville where security critical operations should be carried out in the innermost layer [21]. A centralized architecture allows, as a benefit, medical data to be stored in a central system. This system can provide the necessary security layers. In contrast to standard software systems for SEHRs virtually any operation such as adding and retrieving documents, authentication and access control is security critical. The fact that the entire record is stored on one central server however has a severe disadvantage. This central system is at risk to become a single point of attack. If it is compromised the attacker can access the entire medical history of each patient who s data are stored in the record. Security of Architecture Hereby a conflict with the class security of architecture has been identified which requires the single point of attack to be avoided: [... ] if a specific subsystem is compromised the attacker must not be able to access any piece of information which resides outside this subsystem (See section 4.4 on page 89).

115 5.3 Evaluation of Centralized HIS Architectures 101 Network Security Network communication, as a benefit of centralized architectures, has only to be secured between the server and clients. For preventing Man in the Middle attacks mutual authentication between clients and central server is required, which means that each client has to provide credentials for authentication to the server. Eavesdropping the communication with the central server, as a severe drawback, can furthermore reveal coherent parts of a patient s medical record since the only communication occurs between the server and clients. User Security User management, authentication and access control can be centralized which facilitates adding actors and the handling of access permissions. Since documents reside on the same system that manages user accounts, access permissions to documents can, as a benefit, be easily mapped to the actors. From an actors point of view medical institutions have to, as a drawback, trust a central organization to which they have to relinquish their documents. Patients must trust one central organization to correctly handle their access permissions. Data Security As a benefit data which reside on a central server can be easily protected by security features of the central server. In centralized architectures each user can be assigned a cryptographic token (e.g public/private key pair) which can be used for encryption/decryption of personal data. However, the data security requirement of removing the link between documents and patient demographic data can not be easily achieved if both reside on a central server. In case of system compromise there is a high risk that documents can be merged with patient demographic data, which is contradictory to the security requirements of the class data security. Safety of Centralized HIS Architectures According to Sommerville safety related operations should be carried out by one or a small number of subsystems [21]. In a centralized architecture the number of subsystems which could cause malfunction is low and relevant protection mechanisms can be easily applied. A disadvantage of the centralized architecture is that malfunction of the cental server potentially affects the entire electronic health record and so documents of all patients who have their information stored in a SEHR system. Availability of Centralized HIS Architectures Sommerville proposes an architecture with redundant components to be integrated which can be updated and replaced during operation if availability is a concern [21]. High Availability can not be guaranteed in centralized architectures if data manipulation occurs only on one central server. This system is considered as single point of failure and the entire SEHR system will become unavailable if it fails. Therefore the central server should at least be replicated to redundant machines with identical setup. A common failure in the replicated subsystem, such as software malfunction still results in

116 102 Chapter 5: Comparison of Existing Architectures for SEHRs complete system failure. This is because in centralized architectures diversity as requirement for high availability remains partly unaccomplished. Diversity means that a certain functionality can be covered by different components which have been differently designed. Maintainability and Scalability of Centralized HIS Architectures Changes in centralized architectures require the central system to be updated, which is expected to negatively influence availability, even if replicated services are used since they have to be updated with as little delay as possible to maintain compatibility and provide the same functionality. This process is facilitated if the central server is modularly designed and composed of self contained components [21]. Scalability suffers from centralized architectures. Large data processing centers are needed that concentrate huge amounts of compute power and require high network bandwidth. The hardware and network links of the cental server have to be continuously upgraded as the number of documents and managed actors increases. The operation of data processing centers is a cost intensive task. Compliance to Domain Requirements The domain requirements identified in section on page 88 are covered by the above analyzed criteria with the exception of Document Location. In a centralized architecture documents can not remain located in the institution where they have been produced. 5.4 Evaluation of Distributed HIS Architectures In the last years as research in the field of distributed systems proceeded and commercial, as well as open source applications became ready for operation, distributed architectures entered the field of Shared Electronic Health Records. Distributed object architectures (See section on page 11) form the basis of distributed HIS architectures used by well known SEHR systems such as Sundhed.dk and PING [57, 60, 11] (See also section 2.10 on page 35). Performance of Distributed HIS Architectures Response time of distributed architectures is expected to be generally higher than that of centralized architectures since queries traverse multiple subsystems and communication between them via potentially slow network links is necessary. Search functions can be carried out very inefficiently if a query for a specific piece of information has to be sent to every subsystem and only a small number of positive results are retrieved. If, for example, every subsystem of each institution has to be queried for a specific document of a particular patient, response time is expected to be very high. Given the premise that the requested document solely resides in one institution, queries to remaining institutions will return

117 5.4 Evaluation of Distributed HIS Architectures 103 negative results and unnecessarily inflate response time and network usage. For that reason distributed, hierarchic indices, which provide a mapping between patient identifiers and institutions holding respective documents can dramatically increase performance and so lower response time since unnecessary queries can be saved. Distributed indices are a common approach to improve response time for searches in distributed architectures such as Peer to Peer networks. [85, 86]. A benefit can, however, be achieved by smart replication of documents and indices, where each request is balanced and an optimal service is selected by predefined criteria such as lowest network roundtrip time or workload of the respective machine. This particularly helps improving performance of index services, for document locations performance could also be increased but a contradiction to the domain requirement document location (See section on page 88) has been identified. Security of Distributed HIS Architectures Since in a distributed HIS architecture information is spread amongst a variety of subsystems security is much more complex than if a single server was used. Security and access control features have to be implemented across different subsystems which generally reside on different machines. This separation, however, offers the possibility to provide a layered structure as proposed by Sommerville [21] by encapsulating security relevant information in different subsystems. Security of Architecture As medical documents reside on multiple subsystems the danger of a single point of attack is absent. In case of a compromised subsystem only data which reside on the particular system are disclosed to the attacker. An additional security benefit can be achieved by mutual authentication between subsystems. On the one hand Man in the Middle attacks can be prevented and on the other hand policies can be applied to decide whether a specific service may be invoked by a particular calling service. Network Security As excessive communication between multiple subsystems is necessary when an operation with the SEHR system is carried out, transmitted data via each connection are, as a drawback, prone to eavesdropping. Howeverver eavesdropping attacks between two subsystems will, in contrast to the centralized architecture, only reveal parts of the documents which ideally do not have any patient context assigned. End to End security is required to set up a secure channel between applications and not only network nodes to protect transmitted medical data. User Security User security is much more complex for distributed HIS architectures than for centralized ones. Management of access permissions has to be seamlessly integrated into all subsystems which participate in the SEHR. Since user data and access permissions are not managed by a single system profound mechanisms are to be implemented which allow authorization to be correctly handled. As a benefit neither medical institutions nor patients have to trust a single organization to manipulate documents and access permissions. Institutions keep full control over their

118 104 Chapter 5: Comparison of Existing Architectures for SEHRs documents and patients might be able to choose between different providers as entry points to their personal Electronic Health Record. Data Security As far as data security is concerned the distributed HIS architecture has clear advantages. A smart composition of subsystems allows data to be separated in a way that only useless information without a patient context is disclosed to an attacker even if a subsystem is under his full control. A distributed HIS architecture allows patient identification and handling of demographic data to be dedicated to specialized subsystems which provides for patient demographic data to be removed from documents in an early stage and replaced by an internally used Id. A large number of subsystems has to be under the control of an attacker to obtain usable patient related data. In a distributed HIS architecture the power of system administrators can be cut down. Each administrator can only gain access to a particular subsystem under his control. Safety of Distributed HIS Architectures In contrast to centralized HIS architectures malfunction of a particular subsystem, as a clear advantage, does not affect data of the entire SEHR system if the architecture is designed to be fault tolerant. A potential disadvantage is that protection mechanisms have to be applied which must be seamlessly integrated into a large number of subsystems for monitoring and ensuring correct operation. Availability of Distributed HIS Architectures Distributed architectures do not rely on a central system, so the failure of a subsystem does not affect the entire SEHR system. In case a subsystem becomes unavailable only those parts of the record are affected which reside on the respective system. Index services required for search operation should therefore be replicated and have a limited scope, so that if an index service and its replicas become unavailable only those parts of the SEHR are affected which are in the field of responsibility of the index service. Maintainability and Scalability of Distributed HIS Architectures Maintainability is generally expected to be facilitated by distributed HIS architectures. Subsystems can be changed and upgraded independently during operation as long as interfaces remain stable. Changes in interfaces require a more complex upgrade procedure if communication with other subsystems is directly affected. However, a configuration and version management is required to ensure that compatibility is maintained also if subsystems run different software versions. High scalability is a clear advantage of distributed systems. As the number of documents or actors increases, subsystems can be easily plugged to cope with higher load. If replicated index services are used they can be upgraded to newer hardware and higher network bandwidth one by one without significantly reducing overall performance and availability.

119 5.4 Evaluation of Distributed HIS Architectures 105 Compliance to Domain Requirements The domain requirements identified in section on page 88 are entirely covered by the above analyzed criteria. Particular attention should be given to the domain requirement response time. In distributed architectures the danger of exceeding acceptable limits for response time is evident. In table 5.1 on the following page results of the above described evaluation of centralized and distributed HIS architectures for Shared Electronic Health Records according to the criteria defined in section 5.3 on page 100 are summarized. Criteria Centralized Architectures Distributed Architectures Performance Low response time. Efficient queries. Possible bottleneck by compute power, IO throughput and network bandwidth. Moderate response time. Very inefficient queries without index services. Time consuming communication between subsystems. Security Single point of attack. Eavesdropping reveals large coherent parts of record. Easy management of access permissions but actors must trust central system. Easy encryption of data with an actors key(s). In case of compromise easy merge of documents with demographic data. Only data of compromised system disclosed to attacker. Communication between subsystems prone to evaesdropping, but only non coherent parts of the record disclosed to attacker. Complex management of access permissions, but actors must not trust central system. Even with subsystems under full control of attackers no merge of documents with patient demographic data. Layered security infrastructure is easy to implement. continued on next page...

120 106 Chapter 5: Comparison of Existing Architectures for SEHRs... continued from previous page Criteria Centralized Architectures Distributed Architectures Safety Small number of subsystems prone to failure. Records for all actors affected by malfunction of central system. Complex integration of protection and monitoring mechanisms in all subsystems. Malfunction of subsystem has only local scope. Availability Single point of failure. Replication does not protect from complete system failure caused by software malfunction. Entire system not affected by failure of a subsystem. Effects of subsystem failure minimized by replication and limited scope of index services. Maintainability Downtime of centralized systems during changes and updates. Large compute centers with expensive hardware and high network bandwidth needed. Complex upgrade and migration scenarious. Subsystems can be changed without affecting overall availability. Subsystems easily pluggable to handle higher load or number of documents. Domain requirements No local storage of documents in institution where they have been produced. Evident danger of exceeding response time of 1 sec. Table 5.1: Summary of Comparison of Existing Architectures for SEHRs. In the table above evaluation results of centralized and distributed HIS architectures for SEHRs are summarized. 5.5 Distributed HIS Architectures as Basis for SEHRs Although centralized HIS architectures have their advantages mainly in performance and ease of implementation, a distributed HIS architecture has been chosen for developing a Shared Electronic Health Record based on its clear advantages in security, availability, and scalability. A distributed object architecture as described in section on page 11 is the most generic approach of describing a distributed HIS architecture. In the following sections service oriented architectures (SOA) and Medical Data GRIDs are described as higher level architectures based on this concept. The SOA paradigm directly builds

121 5.5 Distributed HIS Architectures as Basis for SEHRs 107 Figure 5.2: Service Layer Overview. The bottom layer represents the distributed object architecture as base architecture. The middle layer represents Web services as service oriented architecture which builds on the distributed object architecture. The topmost layer describes GRID services which rely on Web service technology shown in the middle layer. From bottom to top each layer introduces a higher level of abstraction to hide the complexity of communication between objects. For further details refer to the text. on distributed objects, where modern Medical Data GRIDs make use of SOA and so provide a still higher level of abstraction to hide complexity of communication between objects from the programmer. This interrelationship between distributed objects, SOA and GRID services is represented in figure Service Oriented Architectures as Concept for SEHRs A service oriented architecture (SOA) as introduced in section on page 12 uses services as the building blocks for applications where a service can be used by multiple applications and the provision of the service thus becomes independent of the application which uses it [87]. Web Services are the most common representatives of SOAs (See section on page 12). Independent components for document storage, patient identification and distributed indices

122 108 Chapter 5: Comparison of Existing Architectures for SEHRs for search functions with clearly definable application range are required for SEHRs. Using the SOA paradigm components can be implemented as services. Developers are not concerned with inter service communication and can focus on the implementation of the business logic. Web services can be used for implementation and source codes for invoking the interfaces can be automatically generated from the service description. Since Web services use the Simple Object Access Protocol (SOAP) as an XML based communication protocol, performance is expected to be negatively influenced by the relatively large overhead of the SOAP protocol and the computational power needed for operations on XML documents [88]. Standard Web services lack some functionality required for SEHRs such as transactions, reliability and security features beyond transport layer security as provided by common application servers via the Transport Layer Security Protocol 1 (TLS). A variety of those features, however, have become well accepted business standards which are maintained by the Organization for the Advancement of Structured Information Standards (OASIS) [89]. They can be easily integrated to extend standard Web services. With the above mentioned enhancements Service Oriented Architectures based on Web services are considered well suited for building Shared Electronic Health Records Medical Data GRIDs as Concept for SEHRs High level GRID services as described by Foster and provided by the GLOBUS toolkit build on standard Web service technology with integration of common OASIS extensions for transaction, reliability and Web service security [24, 25, 26, 27, 28] (See also section 2.4 on page 13). A Shared Electronic Health Record can be considered a Virtual Organization (VO), which consits of a number of individuals and institutions sharing resources amongst each others. Each institution can thereby participate in different VOs and share a clearly defined set of resources in a specific VO. Virtual Organizations as defined here, are the building blocks of modern GRID technology (See section on page 14). In terms of SEHRs medical documents are denoted as resources. As with medical documents data rather then computational power are shared, data GRIDs provide many features such as secure, fast and reliable transfer as well replication services for large scale data sets required by Shared Electronic Health Records. Data GRIDs, however, have originally been designed without respect to the applicability for medical applications. As a result functionality mainly required by Shared Electronic Health Records, such as advanced access control mechanisms and constraints in data location, as analyzed in chapter 4 on page 69 is not covered by Data GRIDs. GRID applications especially adapted for the medical domain are known as Health GRIDs (See section 2.5 on page 18), but concrete recommendations or reference implementations for 1 TLS is the successor of the well known Secure Socket Layer Protocol (SSL).

123 5.5 Distributed HIS Architectures as Basis for SEHRs 109 SEHRs are currently missing. For that reason the author defines Medical Data GRIDs as Data GRIDs specialized for medical applications in order to share documents and other medical data in Virtual Organizations. Medical Data GRIDs therefore belong to the domain of Health GRIDs. The following extensions for Medical Data GRIDs are introduced which are not covered by the original definition of Data GRIDs: 1. Authorization: Role and Context based access control. 2. Data Replication: Data must remain in the institution where they have been produced. 3. Support of medical standards: Medical transmission standards have to be supported. Based on those extensions the definition of Data GRIDs given in section on page 17 can be constrained as follows to meet requirements for SEHRs (See chapter 4 on page 69): Medical Data GRID is an emerging technological paradigm for the seamless access to medical data for a patient centered Shared Electronic Health Record with special focus on legal and organizational requirements of the environment they are operated in, via virtualized middleware, to heterogeneous and distributed ensembles of data storage resources. Medical Data Grids were chosen as distributed, service oriented architecture for the implementation of a Shared Electronic Health Record. This decision is motivated by the opportunities for data sharing amongst heterogeneous institutions, offered by Virtual Organizations, which is expected to facilitate trans institutional exchange of medical data as required for Shared Electronic Health Records.

124 110 Chapter 5: Comparison of Existing Architectures for SEHRs 5.6 Summary and Conclusion In this chapter different architectural styles were evaluated for their applicability for Shared Electronic Health Records. Centralized and distributed architectures were analyzed in detail. Although centralized architectures provide specific advantages such as low response time, they reach their limitations regarding security, scalability and maintainability. Medical Data GRIDs which belong to the category of distributed object architectures and incorporate the SOA paradigm have been chosen as most adequate architectural style for the implementation of a Shared Electronic Health Record. Amongst the evaluated architectures Medical Data GRIDs are the most advanced approach for facilitating trans institutional data sharing in the heterogeneous environment of healthcare institutions by integrating them into Virtual Organizations. In the next section the Medical Data GRID architecture is described along with interactions of GRID services for the SEHRS and respective workflows. Special emphasis is placed on the security model which is developed to support complex authorization and access control requirements by developing a Role Based Access Control mechanism.

125 Chapter 6 HIS Architecture for SEHRs A Health Information System architecture for Shared Electronic Health Records based on Medical Data GRIDs is described in this chapter. Workflows for the most relevant operation on the SEHR are detailed as UML sequence and interaction diagrams. Role and Context Based Access Control mechanisms are developed and described in detail as well as the interfaces to existing systems. The main challenge is to reconcile the advantages of Medical Data GRIDs with conformity to well accepted standards, particularly the IHE XDS Integration Profile, which has been recommended as transmission standard for SEHRs in Austria (See section on page 34). 6.1 Overview of the Architecture Based on the requirements analyzed in chapter 4 on page 69 the HIS architecture has been developed as Medical Data GRIDs, which turned out to be the most promising architectural style in an evaluation described in chapter 5 on page 97. The software process outlined in section on page 54 describes the identification of subsystems, which are then subdivided into modules as first steps in the development phase. A clear distinction between subsystems and modules is, according to Sommerville, not always reasonable [21]. As Medical Data GRIDs rely on a service oriented architecture [23, 26, 28], each component can be considered as GRID service and implemented accordingly. A distinction between subsystems and modules is for that reason, in the opinion of the author, not reasonable. For the SEHR to provide the required functionality the following four groups of GRID services have been identified, which can be considered as subsystems in terms of the software process described in section on page 54: 1. Document Storage: Service group responsible for storing documents. 2. Distributed Indices: Service group providing search functions. 3. Patient Identification: Service group providing unambiguous patient identification. 4. External System Integration: Service group providing access for external systems.

126 112 Chapter 6: HIS Architecture for SEHRs Those service groups cover core functionality of the HIS architecture for SEHRs and GRID services of those groups are described in detail in section 6.2. The architecture is by design fully distributed without requiring centralized components for the reasons identified in section 5.5 on page 106. Heterogenous environments in which the HIS architecture is designed to be operated in, can however require centralized services to be integrated, which renders a fully distributed architecture into a hybrid architecture. A centralized metadata index, which might be required in certain countries, can for example, be a central component that can be integrated into a hybrid architecture. Governmental services and legacy systems are other expected central components which can be easily integrated into the architecture due to its modular design. 6.2 GRID Services as Basic Components Based on the service groups described in the previous section, GRID services depicted in figure 6.1 on the next page have been identified to support system and security requirements. In the following, basic functionality of the GRID services is described in the order of the workflow as outlined in section 6.3 on page 120 for adding documents to the record. Interfaces of each service are outlined in a simplified form that facilitates understanding of basic functionality. Additional Interfaces not directly related to the core functionality of the services are intentionally omitted.

127 6.2 GRID Services as Basic Components 113 Figure 6.1: GRID services of the HIS architecture for SEHRs. All services shown in the illustration are distributed and can be located in different institutions. External systems (in green) only connect via the Document Clearing (DC) and the Access Nodes (AN) (in yellow). Documents are stored in Document Repositories (DR) (in red). Distributed indices are provided by the Document Meta Data Index (DMDI) and the Global Index (GI) (in orange). A unique PatientId can be obtained by Patient Lookup (PL) and Patient Lookup Index (PLI) (in blue). For further details refer to the text Document Clearing (DC): In order to support medical data standards (Requirement S 8 table 4.17 on page 88), particularly the Clinical Document Architecture (CDA), which has been proposed for Austrian Electronic Health Records, documents have to be initially converted to this format (See section on page 23 and section on page 34). DC services are one of two gateways for external systems to provide medical documents, which should be made available for the SEHR architecture. As a variety of those systems are legacy systems developed years ago, it can not be assumed that the relatively modern CDA format is natively supported. For that reason the DC is basically responsible for converting proprietary formats to the internally used CDA and furthermore to

128 114 Chapter 6: HIS Architecture for SEHRs hide the complexity of adding and registering documents for external systems. The DC is customizable to support virtually any document formats used in a particular institution. DC Interfaces Since the Document Clearing service is, as a gateway, connected to existing clinical subsystems it must, according to system requirement S 11 (See table 4.17 on page 88), support common, well established medical communication protocols. For that reason the DC supports beside the GRID service interface an HL7 interface (See section on page 22). Via those interfaces an HL7 or DICOM message with a document attached can be sent to the DC, which is then converted to CDA for further processing. The DC GRID service supports the following basic interfaces 1 : public DocumentId provideandregisterdocumentset(srcdocument, DocumentMetaData, PatientData); For converting a source document in proprietary format to CDA and later adding it to the SEHR. public boolean retryfaileddocument(documentid srcdocid); For resubmitting a document after manual intervention. The DC provides a mechanism for manual intervention if documents can not be automatically converted to CDA and added to the SEHR. In many cases these failures are caused by missing/incorrect Social Security Number (SSN), misspelled demographic data or corrupted source document. In this case the document is transferred along with corresponding metadata to a temporary ErrorDirectory with a management interface attached which allows manual change of demographic data. The document can then be resubmitted via the interface retryfaileddocument() Acces Node (AN): Access Nodes (ANs) are the second gateway to access the SEHR architecture from external systems. All external requests are routed through Access Nodes. In terms of the HIS architecture for SEHRs Web portals for patient access are considered external systems, as are Clinical Information Systems (CIS) of participating institutions that connect to the architecture. ANs hide the complexity of the internal architecture from external systems and thus offer standardized interfaces, which is expected to reduce development effort. Access Nodes provide a security layer allowing fine grained control whether requests of a particular external system (e.g. Web portal) should be permitted or rejected. 1 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

129 6.2 GRID Services as Basic Components 115 The modular design of the HIS architecture based on Medical Data Grids provides flexibility for participating institutions and reduces development effort for customization for participating institutions to an acceptable limit. Each institution with a local CIS has to minimally operate two services: The DC is responsible for adding documents and the AN for retrieving any other information from the SEHR. AN Interfaces As all requests to internal services are routed via Access Nodes as gateways, ANs provide the following basic interfaces 2 necessary for external systems to access the SEHR: PLIPatientCriteria findpatient(plisearchcriteria, PLIPatientCriteria); Encapsulation of PLI invocation for obtaining a unique PatientId (See section on the following page). public DocumentMetaData[] querypatientrecord(patientid, PatientRecordQuery); For obtaining document metadata for a given patient. public byte[] getdocument(docuri, PatientRecordQuery); For receiving the document identified by its URI from the corresponding Document Repository (DR). This interface encapsulates the invocation of the DR for external systems (See section on page 117). Receiving documents from the SEHR is a multi stage process, according to the Austrian legal situation, introduced in section on page 31. The PatientId received in the first step is needed to acquire metadata of available documents (DocumentMetaData). Metadata of each document contain, amongst many others, the location (docuri) of a document at the corresponding Document Repository. The URI is needed for the last step, for receiving the CDA document. PatientRecordQuery defines the search pattern for searching documents of a specific patient. A date range to retrieve only documents of the last year is an example of a common pattern Patient Lookup Index (PLI): A reliable source for unique Patient identification is a vital requirement for SEHRs. The Patient Lookup Index (PLI) provides a unique PatientId for given patient demographic data and vice versa. PLIs can use different identity sources to identify a patient. Those sources however can not be directly accessed but only via the Patient Lookup service (PL), introduced in the next paragraph. This encapsulation provides for scalability and maintainability. 2 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

130 116 Chapter 6: HIS Architecture for SEHRs An internally used PatientId provides additional security since patient demographic data are not required for the described services. The re identification, which is the mapping of the internally used unique MPID to patient demographic data such as name and date of birth must only be carried out after successful authorization. Special emphasis is placed on security to prevent unauthorized re identification of patients. PLI Interfaces The PLI service basically supports one interface 3 PatientId: for obtaining a patient s internally used public PatientData findpatient(patientdata, PatientLookupOptions); For obtaining a unique PatientId for a patient with given demographic data. Demographic data are provided via PatientData and search options such as restrictions via PatientLookupOptions. PatientData are received with the unique PatientId attached along with completed and confirmed demographic data Patient Lookup (PL): The Patient Lookup (PL) provides an abstraction of different patient identity sources for PLIs. As long as there is no, at least European, Master Patient ID (MPID), each country or even healthcare region has to provide its own patient identification. The PL service combines different ID sources to obtain a higher chance for unambiguously identifying a patient. In the region Tyrol for example the PLs can combine Austrian, German and Italian identity sources and hide the complexity of querying those eventually completely differently crafted sources from the PLIs. Each new identity source can be easily plugged via a corresponding PL service. PL Interfaces The PL has basically one interface 4 to obtain a unique patient identification from a specific source: public PatientData lookuppatient(patientdata, PatientLookupOptions); For identifying a patient on the basis of his demographic data. 3 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted. 4 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

131 6.2 GRID Services as Basic Components 117 For finding a patient PatientData are provided to the PL service as demographic data along with PatientLookupOptions specifying search relevant options such as ID sources to be used and whether a new PatientId should be created if the patient does not exist in the registered identity sources. PatientData are returned with the unique PatientId (MPID) attached along with demographic data completed to the extent that can be obtained from the identity source Document Repository (DR): Converted CDA documents reside on the Document Repository (DR) which is generally designed to be located in every institution that produces medical documents. Small institutions and General Practitioners (GPs) can however use a common repository. Documents on a DR can not be searched, for retrieving a document the exact (Uniform Resource Identifier) URI is required. Searchable metadata are published to a two layered distributed index hierarchy described in section on the next page and section on page 119. This concept enhances security and performance, the first because an abuser must know the exact location of a document, which can only be obtained via the distributed indices which acts as security layer, the latter dramatically reduces load since otherwise every DR in a Virtual Organization (VO) would have to be queried when documents for a specific patient are requested. The DR service is furthermore responsible for registering searchable metadata in the two layered distributed index hierarchy described in section on the next page and section on page 119. This facilitates document searches without querying each DR for particular documents. Document Repositories can be implemented as physical or virtual DR. This concept is useful if the DC provides non structured, even binary documents such as discharge letters in arbitrary format (e.g PDF) along with metadata. CDA Release 2 documents without templates applied allow for binary content to be added as NonXMLBody. Physical DR services store the non structured content directly in the CDA document. Virtual DR services only have a pointer to the original non structured document, which can reside on any backend system stored in the CDA. The original non structured document is dynamically retrieved from the backend as the DR returns the CDA document. DR Interfaces The Document Repository is a rather simple service which supports two interfaces 5 : public DocumentId adddocument(srcdocument, DocumentMetaData, PatientId); For adding a document to the SEHR. 5 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

132 118 Chapter 6: HIS Architecture for SEHRs public byte[] getdocument(documentid); For retrieving a document via its URI. For adding a document DocumentMetaData such as producing institution and assigned physician as well as a unique PatientId are required. The unique DocumentId is returned after the document has been added. DR services can only be called from DCs (See section on page 113) for adding documents and from ANs (See section on page 114) for retrieving documents Document Meta Data Index (DMDI): The Document Meta Data Index (DMDI) is the first part of a two layered distributed index hierarchy. Metadata of each document, such as producing institution, department and creation date are located on the DMDI. Generally a DMDI service is assigned to a particular DR. Smaller institutions however can share a common DMDI. Along with the metadata a link to the physical location of the document at the corresponding DR is stored as URI. Searches for documents are carried out via DMDI service, which returns metadata and URIs of the documents. Per document access permissions are important metadata which the DMDI service holds. This service enforces role and context based access control on a per document basis. The DMDI only returns the URI of the requested document if the request is permitted. DMDI services are designed to support replication for reasons of load balancing, stability and availability. To facilitate replication write operations are carried out by a Master DMDI (md- MDI), which can be replicated to an arbitrary number of Slave DMDIs (sdmdi) for read only operations. DMDI Interfaces The DMDI service is a rather complex service which basically supports two interfaces 6 : public DocumentMetaData[] querypatientrecord(patientid[], PatientRecordQuery); For finding document metadata and a link to the document for a specific patient. public DocumentId indexdocument(patientid, PreviousDocumentId, DocumentMetaData, DocumentRepositoryData); For registering metadata of a document in the index hierarchy. The DMDI service furthermore provides interfaces for managing replicas of a document in different repositories and metadata of the assigned repositories. 6 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

133 6.2 GRID Services as Basic Components Global Index (GI): The Global Index (GI), which works as a service discovery unit is the second part of a two layered distributed index hierarchy. The GI stores a mapping between PatientId and DMDI services which have 1... n documents indexed. The GI helps to easily identify those DMDIs which hold documents of a particular patient. The GI dramatically reduces load since only DMDIs are queried which actually have indexed documents for a specific patient. The concept of distributed indices is commonly known as Super Peers in distributed peer to peer networks to reduce network load and increase search speed [85, 86]. Either a small number of replicated GIs can be used within a VO which have their complete data stock replicated or GIs can be structured hierarchically in larger VOs where each service has a domain assigned. The lowest layer of such a hierarchy could be for example a healthcare region such as Tyrol, the next higher layer e.g. Austria and the top layer e.g Europe. Requests are in that case directed from the top layer to the next lower layer until a particular patientid can be resolved. A similar concept is used in the well known Domain Name Service (DNS) protocol. GI Interfaces The GI service supports the following basic interfaces for adding a mapping between patientid and DMDI services which have documents indexed for the given patient 7 : public void addmpid(patientid, DMDIId); For registering a DMDI service which has data for a given patient indexed. public PatientGlobalData getglobaldata(patientid); For getting the list of DMDI services which have data for a given patient indexed. public void adddmditompid(patientid, DMDIId); For adding a mapping between Master DMDI and assigned slave DMDIs to a Master Patient ID (MPID) (See section on page 115). public void removedmditompid(patientid, DMDIId); For removing a mapping between Master DMDI and assigned slave DMDIs to a MPID. For registering a DMDI service in the index hierarchy a mapping between PatientId and DMDIId as unique identifier for each DMDI is provided. PatientGlobalData contains a list of DMDI services which have metadata to a given patient indexed. 7 Simplified Parameters. Notation based on Java, only datatypes listed and Exceptions omitted.

134 120 Chapter 6: HIS Architecture for SEHRs Figure 6.2: For adding a document the original document is received by the DC, converted to the internally used CDA format and then stored on the DR and registered in the distributed index hierarchy of DMDI and GI. Unique patient identification is provided by PLI and PL services. For further details refer to the text. 6.3 Workflows for Common Operations In this section the most common interactions with the SEHR for adding and retrieving documents as well as for setting access permissions are described. The workflow for adding a document is described in figure 6.2 as UML sequence diagram. The document which originates from an arbitrary external system is retrieved in proprietary format from the DC, converted to CDA after a unique PatientId had been obtained and stored at the Document Repository. The DR is responsible for registering the document in the two layered distributed index hierarchy on DMDI and GI. The diagram clearly indicates that external systems solely require interaction with a Document Clearing service for adding documents. The workflow for retrieving a document is described in figure 6.3 on the next page as UML sequence diagram. Generally Web Portals or Clinical Information Systems are external systems that connect to SEHR for retrieving documents. Therefore initially a unique patient identification is required which is obtained in a first step via the PLI service. Document metadata are then searched in the two layered distributed index hierarchy to find matching documents, which are as a final step retrieved from the Document Repository. The diagram clearly indicates that external systems solely require interaction with an Access Node for retrieving documents.

135 6.4 Role Based Access Control (RBAC) for SEHRs 121 Figure 6.3: For receiving a document in a first step a unique PatientId is obtained from demographic data. In a second step the GI service is invoked to find DMDI services for the given PatientId. From those DMDI services document metadata are in a third step retrieved. Finally the document is fetched from the DR. All interactions from the external system are routed via the AN as gateway. For further details refer to the text. 6.4 Role Based Access Control (RBAC) for SEHRs As medical data require a high level of data protection which is addressed by national and international laws and regulations (See section 2.8 on page 31), special emphasis has been placed on a security infrastructure which complies to the security requirements analyzed in section 4.4 on page 89. Well known information security techniques to ensure confidentiality, integrity, availability and authenticity are mandatory but identified security requirements demand for a more compulsory security concept which provides for, amongst many others, patient controlled access permissions and their delegation. Therefore a hierarchic two level security model has been elaborated. The security model supports role based access control introduced in section on page 30 which can be configured during service runtime via policies. The two layers are described in figure 6.4 on the next page. For each layer the same mechanism is applied to obtain actual permissions: Each service is

136 122 Chapter 6: HIS Architecture for SEHRs Figure 6.4: Two Level security model. In the external level (red) static service roles are checked and encryption/decryption is handled. In the internal level (grey) dynamic user roles are checked. For further details refer to the text. configured with a set of policies. As the service is called, an inspection is carried out whether the call confirms to the local policies and, only if this is the case, the requested service can be invoked. For each request a state is extracted which is compared to local policies. If an adequate policy can be found where that actual state matches the target state, a positive acknowledgment is generated and access is granted. Static Service Role Checks Static service role checks are, as the outermost layer (red layer in figure 6.4) responsible for preventing unauthorized service invocation and Man in the Middle attacks by mutual authentication. In a Medical Data GRID architecture theoretically each service could invoke and use an arbitrary SEHR service which has been discovered. Clearly defined workflows as described in section 6.3 on page 120 allow restrictions for service to be applied. This improves security since a DR service can for example only be invoked from DC and AN services but never from GI, DMDI or PL(I) services. Static service role checks also ensure that only services registered in the architecture can be invoked, which means that their identity can be proved based on digital certificate transparently included in every request. Whether a service may be invoked by another or not can be configured via policies. In the outer layer decryption of incoming requests and encryption of outgoing responses as well

137 6.4 Role Based Access Control (RBAC) for SEHRs 123 as requests to other services are handled. The outer layer as a summarization safeguards that each service can only be called by registered and entitled services. User Role Checks User, system and security requirements which particularly deal with giving the patient the possibility to control access permissions for his documents (U P 7.1, U P 7.2, U P 7.4, S5, S7 and UserSec analyzed in chapter 4 on page 69) are implemented as user role checks. User role checks as the inner layer (grey layer in figure 6.4 on the preceding page), are carried out after static service role checks succeeded and comprise two sub levels: Level 2A: Static user role checks. Level 2B: Dynamic user role checks. User roles are defined by the profession of the respective user. Professional, Pharmacist and Scientist are defined user roles. Currently Patient, Medical For each user a digital user attribute certificate (See section on page 30) is issued for defining his role. Additionally, in Austria the e-health Directory is accessible as governmental service 8 which defines roles in the healthcare sector [90]. In a SEHR different user roles are allowed to carry out different operations on the record. A medical professional, for example, may generally access medical documents, whereas a pharmacist is only allowed to access prescription relevant data. Scientists, however should be able to access medical data, but only in a pseudonymized version. Those rules are rather static and for that reason checked in Level 2A as static user role checks. Level 2A comprises checks of static user roles against a given set of policies. Information about a user s role is generally fetched from a user s attribute certificate and in Austria additionally from the e-health Directory, which is however not available in neighboring states in the same healthcare region such as Germany and Italy in the region Tyrol. For that reason attribute certificates are required. Level 2B comprises checks of dynamic user roles which basically originate from the current relationship between actor and patient. Level 2B checks are required for the delegation of access permissions to treating physicians and affiliates and for enforcing the 4 Eye Principle. This requires the consent of the patient to be verified. Technically this verification is generally based on an attribute certificate with temporary validity, so that a given consent will expire after a predefined period of time. For Austrian citizens the consent is verified based on the certificate on the e-card (and the associated pin code) introduced in section on page The e-health Directory is operated by the Bundesministerium für Gesundheit und Frauen.

138 124 Chapter 6: HIS Architecture for SEHRs 6.5 Message Level Security for End to End Security The two layered RBAC approach provides security on a per message level, which is the continuous protection of a message from the originating service to the destination service independent of transport layer and intermediate network nodes. For that reason message level security is needed for End to End Security as required in S 6 (See table 4.12). Transport level security as a well known approach for secure data exchange in the internet only provides for protection between communicating network nodes. As modern GRID services rely on Web service technology, Web service security extensions for content protection on a per message basis are applied as defined by the OASIS 9 standardization group [89]. GRID service security primarily uses Web Service Security (WS Security) [91] for transmitted SOAP messages as message level security. However, transport level security is offered [92, 93]. The combination of message level security and the two layered RBAC approach introduced in section 6.4 on page 121 provides for End to End security as required by the above mentioned system and security requirements. 6.6 Medical Data GRIDs in Combination with the IHE XDS Integration Profile In the design phase of the architecture by the end of 2004 the IHE XDS Profile (See section on page 27) was released in the IHE IT Infrastructure Technical Framework Supplement Over the past two years XDS became a quasi standard for Electronic Health Record Applications in Austria and other European Countries which provides for vendor independent interoperability. System requirement S 11 in table 4.17 on page 88 defines interoperability and support of medical communication protocols. For that reason at least in Austria, the IHE XDS Integration Profile has to be supported. Medical Data GRIDs and the XDS Profile are however not a contradiction. The architecture can easily be adapted to support XDS, which is considered a proof of the flexibility and adaptability of the designed architecture. The XDS Integration Profile and Medical Data GRIDs already have vital concepts and even a few services in common. The profile uses a distributed architecture with Document Source and Document Consumer, Document Repository, Document Registry and PatientId Source as Actors 10. The five XDS Actors basically correspond to the four service groups described in section 6.1 on page 111. The main difference is, that XDS, although it is based on a distributed object architecture, 9 OASIS: Organization for the Advancement of Structured Information Standards. 10 Note: IHE terminology for Actors is different form that introduced for system requirements in section 4.3.

139 6.6 Combination of Medical Data GRIDs and IHE XDS 125 Figure 6.5: (A) represents the IHE XDS architecture. In (B) Medical Data GRID services are used to implement IHE Actors. The two layered distributed index hierarchy of GI and DMDI is transparently integrated to the Document Registry which is according to the XDS Profile a central service for each affinity domain. EHD, ZMR and HI are identity providers in Austria. For further details refer to the text. requires a central index service (Document Registry) for each affinity domain. At the time of writing, a profile for interconnecting different affinity domains was currently only available as draft version for public comment [94]. The central registry causes the XDS architecture to suffer from drawbacks of centralized systems such as single point of failure and attack as analyzed in section 5.3 on page 100. Virtualization is a major benefit of Medical Data GRIDs, which is the integration of a larger number of different physical systems into a smaller number of virtual systems. This concept allows the integration of the two layered distributed index hierarchy to one virtual Document Registry for each affinity domain. The virtual Document Registry transparently forwards queries to the distributed indices GI and DMDI and behaves as a central registry for other services. In figure 6.5 original IHE XDS actors (A) and the implementation with Medical Data GRIDs is shown(b). The transparent integration of the two layered distributed index hierarchy to the Document Registry combines the advantages of a fully distributed architecture with the compliance to medical standards as identified in S 11 (in table 4.17 on page 88). A drawback however is that response time is increased when calls to the virtual Document Registry have to be mapped to the underlaying services GI and DMDI. The IHE XDS actors Document Source and Consumer as well as Patient Id source are also covered by GRID services with little implementation effort. The service group Patient Identification consisting of PL and PLI services serves as XDS actor Patient Id Source. Therefore the

140 126 Chapter 6: HIS Architecture for SEHRs PLI service implements XDS interfaces and transparently forwards requests to the PL service which then receives the unique identification from connected identity providers. As indicated in figure 6.4 on page 122 DC and AN act as external interfaces of the XDS architecture. The Document Clearing (DC) service transparently translates XDS transactions for adding documents in GRID service calls to the Medical Data GRID architecture. XDS transactions for the retrieval of medical data are transparently encapsulated by the Access Node (AN) which is responsible for querying the two layered distributed index hierarchy and retrieving documents from the repositories. To support vendor independent interoperability the virtual Document Registry can be accessed from external systems and documents can be fetched from the according Document Repository. Opening the architecture to external IHE XDS actors however requires to abandon the concept of clearly defined gateways for adding and retrieving documents as provided by AN and DC services. 6.7 Summary and Conclusion In this chapter a HIS architecture for Shared Electronic Health Records has been described using Medical Data GRIDs as fully distributed architectural style. GRID services have been designed to support the requirements analyzed in chapter 4 on page 69 with special emphasis placed on security and scalability. For reasons of interoperability the IHE XDS Integration Profile is supported. The adaptation of the Medical Data GRID architecture in order to achieve compliance with XDS was supported by the modular design of the architecture. XDS actors have entirely been designed as Medical Data GRID services. Virtualization enables the Document Registry to appear as central service as required by the XDS integration Profile, while it provides a logical abstraction of the two layered distributed index hierarchy formed by Document Metadata Index (DMDI) and Global Index (GI). In the next chapter a prototype implementation of the IHE XDS compliant HIS architecture is described which provides basic support for the most important requirements.

141 Chapter 7 Prototype Implementation According to the spiral model of the evolutionary process paradigm chosen for building a HIS architecture for Shared Electronic Health Records (See section on page 54), requirements are constantly refined on the basis of prototypes with iteratively enhanced functionality as identified by the involved actors. In this chapter the first version of an open source prototype following the architectural style of Medical Data GRIDs according to the requirements analyzed in chapter 4 on page 69 is described. This prototype version of course lacks certain functionality but demonstrates that main requirements for SEHRs can be covered by the developed HIS architecture. Conformance to the IHE XDS Integration Profile will be verified in an IHE Connectathon, which is an event organized by the IHE organization where vendor independent interoperability of healthcare IT solutions is proved and attested by the IHE. The prototype implementation serves two purposes: 1. Intermediate step in the evolutionary software process paradigm for requirements analysis. 2. Proof of concept of the applicability of Medical Data GRIDs for SEHRs. 7.1 Description of Prototype Implementation When prototype implementation started in 2004 the GLOBUS Toolkit emerged as most promising GRID middleware for implementation of a Medical Data GRID based HIS architecture for Shared Electronic Health Records. This decision was motivated by the modern, service oriented approach of the GLOBUS middleware [24, 27, 28]. UNICORE as the second major GRID middleware primarily provides a workflow task management environment across multiple sites, rather than an infrastructure for GRID enabled application development such as GLOBUS does, using the modern SOA approach [95]. At the time the prototype implementation started, the GLOBUS Toolkit was available in version

142 128 Chapter 7: Prototype Implementation 3, which partially integrated the SOA concept but version 4 was already under development which was expected to fully incorporate the SOA paradigm by being entirely Web service based. An evaluation of the upcoming version 4 however revealed that the GLOBUS Toolkit makes excessive use of existing OASIS standards. Particularly those aspects relevant for Medical Data GRIDs such as reliable transfer and security features are, to a major extent, covered by the OASIS standards WS Security [91] and WS Reliability [96]. Based on those facts the health@net development team faced a predicament: On the one hand the current version 3 of the GLOBUS Toolkit is stable but will shortly become obsolete, on the other hand the new version 4 of the Toolkit is cutting edge technology, not even released and difficult to estimate when it will become stable enough. So, as a temporary solution for the implementation of the first prototype version, well established Web service technology was chosen with the above mentioned OASIS standards integrated to implement the functionality of Medical Data GRIDs as designed in the architecture specification (See chapter 6 on page 111). As soon as version 4 of the GLOBUS is well established and stable enough, next prototype versions or the final release will be based on this promising toolkit for developing GRID applications. During developing an extreme programming like approach as introduced in section on page 49 was chosen as rapid software development methodology to closely integrate testing in the development process. This methodology supports the evolutionary software process paradigm as actors are involved in the design and implementation process Used Software Environment Decisions concerning development of Medical Data GRID applications (e.g GRID services) have carefully considered the later migration to the version 4 of the GLOBUS Toolkit. For that reason the same underlaying technology as used in version 4 was applied. In the following paragraphs a short description of programming language, Integrated Development Environment (IDE) and relevant applications including their version is given: Programming Language Java was chosen as programming language primarily to facilitate the later migration to GLOBUS Toolkit 4 which provides native support for Java. Furthermore Java is platform independent and perfectly supports Web service technology [97]. Sun s Java was used in the version Java TM 2 Platform Standard Edition 5.0 Development Kit (JDK 5.0) [98]. IDE Eclipse version 3.1 was used as Integrated Development Environment due to its excellent support for Java and Web service development [99]. Application Server Apache Tomcat in version was used as application server to host Web service applications. Tomcat is natively written in Java and so provides for platform

143 7.1 Description of Prototype Implementation 129 independent services which increases interoperability and maintainability as preferred operating systems can be used [100]. Web Service Framework and OASIS extensions Apache Axis in version was used as Web service framework to provide an abstraction for Web service calls for the Java programming language. From a Web service description in WSDL java classes (client stubs) can be automatically generated by Axis which hides complexity of Web service calls behind a method invocation of the client stub. On the other hand Web service descriptions in WSDL can be automatically created from existing Java classes and interfaces. Axis is furthermore responsible for transparently serializing Java objects to SOAP messages in XML and vice versa (See also section on page 12). Web Service Security for Java (WSS4J) was used as Java framework for implementation of the OASIS standard for WS Security. WS Security provides for End to End security by message level security as described in section 6.5 on page 124. Database PostreSQL was used as relational database in version for persistant storage. In the prototype implementation CDA documents (which are XML documents) are also stored in the database, however as document size increases they will have to be swapped out to the file system for performance reasons Application Development Basic functionality of services described in chapter 6 on page 111 as Medical Database GRIDs are implemented as Web services. In the first version of the prototype only basic functionality is provided which is necessary to support basic requirements and allows an estimation if, and to which extent, Medical Data GRIDs are adequate as base architecture for Shared Electronic Health Records. Although the first prototype is implemented as a research project, development has been carried out in tight cooperation with two major hospital holding companies (Innsbruck University Hospital and Vienna Hospital Holding Company). An implementation in a production environment facilitates estimation of interoperability aspects which occur as the HIS architecture is deployed in different institutions. Furthermore real data can be used instead of generated, potentially unrealistic test data. However, since medical data are used for testing, their careful anonymization is strictly required.

144 130 Chapter 7: Prototype Implementation Working with the SEHR For testing the HIS architecture medical data must be added by Document Sources, stored in the repositories, registered in the distributed index hierarchy and finally queried and retrieved by Document Consumers. Although in distributed architecture such as medical Data GRIDs an arbitrary number of service instances can exist. To facilitate implementation each service has only one instance, so each service exists only once. In the following two sections working with the SEHR is described for adding and retrieving documents. Working with Document Sources for Adding Documents According to the IHE XDS Integration Profile documents are produced by the Document Source actor. In the Medical Data GRID architecture the Document Clearing (DC) service provides interfaces to the original source and to the Document Repository (DR). The prototype version of DC has been deployed at the Innsbruck University Hospital. In figure 7.1 on the facing page a screenshot of the running DC application is shown. DR and distributed indices have been deployed in different network segments of the Leopold Franzens University Innsbruck 1. This deployment allows the simulation of a heavily distributed architecture as required for later productive use. Medical documents of the Innsbruck University Hospital designed for external use had been transmitted to the Document Clearing (DC) service for a predefined time via the HL7 interface. After conversion to the internally used CDA format they have been stored and registered in the architecture according to the workflow described in figure 6.2 on page 120. Initially approximately 120 documents have been received and added to the record. Since medical documents had been stored outside the protected network of the Innsbruck University Hospital, special emphasis has been placed on privacy. The DC was implemented to support configurable automatic anonymization by entirely removing patient demographic data from CDA documents. As the Document Repository is implemented as a virtual DR non structured documents (e.g. discharge letters in PDF) never leave the protected environment of the Innsbruck University Hospital (See section on page 117). The documents added by the Document Source are available in the prototype architecture and can be retrieved by the Document Consumer as described in the next section. 1 The Leopold Franzens University (LFU) is a project partner in the health@net project.

145 7.1 Description of Prototype Implementation 131 Figure 7.1: Screenshot of the Document Clearing Service running inside the Eclipse IDE in the protected network of the Innsbruck University Hospital. The screenshot shows the debug output from the CDA conversion algorithm. For further details refer to the text. Working with Document Consumers for Receiving Documents Document Consumers provide applications which present the content of a Shared Electronic Health Record to end users, which might either be patients or medical professionals. In the prototype implementation a Web portal application has been developed for end users to access documents in the SEHR. Technically there is only little difference in a Web portal application for patients and medical professionals, with the only exception that patients require functionality for setting access permissions for their documents. Interactions with core services such as Document Repository and distributed index hierarchy are therefore basically the same for patient and medical professional Web portal applications.

146 132 Chapter 7: Prototype Implementation For that reason a Web portal for medical professionals has been developed in the first prototype implementation to evaluate search and retrieval functions of medical documents. The Access Node (AN) serves as gateway to the HIS architecture for the Web portal. End users can query and retrieve documents from the SEHR after successful login via the Austrian e-card as authentication token. Retrieval of documents via the Web portal is compliant to the 4 step model for inquiries of medical findings which is the legal foundation for accessing medical documents of a patient in Austria as described in section on page 31. In the first prototype only those documents can be retrieved via the Web portal which have been previously added by the Document Source. As described in figure 7.2 to figure 7.6 on pages the retrieval of documents follows the workflow described in figure 6.3 on page 121 which requires the correct interaction of all involved services AN, PLI, PL, GI, DMDI and finally DR. As described above, the Document Repository is implemented as virtual DR, where an anonymized test document is added as non structured content of the CDA document. In figure 7.2 on the next page the entry page for selecting a patient is shown, figure 7.3 on page 134 shows the subsequent page for querying documents of a specific patient in a given period of time. Patient identification can be directly obtained via a patient s e-card or entered manually. In this first step of the 4 step model the MPID is obtained via the XDS actor Patient Id Source, implemented by PL and PLI as Medical Data GRID services.

147 7.1 Description of Prototype Implementation 133 Figure 7.2: Screenshot of the Web portal for patient selection. Required fields for test patients can be automatically completed by clicking the e-card applet. In regular operation patient identification can be obtained via the patient s e-card. For further details refer to the text. According to the legal requirements in Austria (See section on page 31) the consent of a patient is required for accessing medical documents. As the verification of the consent is not fully implemented in the first prototype a paper based mandate has to be signed by the patient which authorizes the medical professional to access documents. In figure 7.4 on the following page the printable form of the mandate is shown. As in this prototype version only anonymized documents are available, this step can be safely skipped without violation of privacy regulations. In figure 7.5 on page 135 the retrieval of stays 2 along with a summary of available documents is shown as the second step of the 4 step model. Required information is therefore retrieved via the two layered distributed index hierarchy. Step three of the 4 step model is shown in figure 7.6 on page 135 where detailed metadata of selected documents are displayed and a link for document download is presented. Metadata are obtained from the DMDI service and the document is finally retrieved from the virtual DR service. Step three is defined for discharge letters, detailed medical findings such as laboratory results or radiological images can be retrieved in step four, which is not implemented in the first prototype version.

148 134 Chapter 7: Prototype Implementation Figure 7.3: Screenshot of the Web portal for selection of the time range in which documents should be retrieved. Additionally an Institution can be selected. The text field with light blue background shows the formulated query as debug output. For further details refer to the text. Figure 7.4: Screenshot of the Web portal with patient s mandate in printable version. In the first version of the prototype (dynamic) user role checks are not implemented. For privacy protection patients have to sign a mandate to express their consent. For further details refer to the text.

149 7.1 Description of Prototype Implementation 135 Figure 7.5: Screenshot of the Web portal with received stays for the given patient. In this version of the prototype each document which is currently a discharge letter represents a terminated stay. For further details refer to the text. Figure 7.6: Screenshot of the Web portal with metadata of the selected document displayed. The document can be downloaded via the link. For further details refer to the text.