IN
DEGREE PROJECT MEDICAL ENGINEERING, SECOND CYCLE, 30 CREDITS
STOCKHOLM SWEDEN 2016,
The Knowledge- and Adoption Level of Standards for Technical Interoperability among Providers of Healthcare Information Systems
ANNA HAGMAN
This master thesis project was performed in collaboration with Medtech4Health and Swedish Medtech
Supervisor: Håkan Nordgren
The Knowledge- and Adoption Level of Standards for Technical Interoperability among Providers of Healthcare Information Systems
Kunskaps- och Tillämpningsnivån av Standarder för Teknisk Interoperabilitet hos Leverantörer av Vårdinformationssystem
ANNA HAGMAN
Master of Science Thesis in Medical Engineering Advanced level (second cycle), 30 credits Supervisor at KTH: Björn-Erik Erlandsson
Examiner: Mats Nilsson School of Technology and Health TRITA-STH. EX 2016:73 Royal Institute of Technology
KTH STH
SE-141 86 Flemingsberg, Sweden
Abstract
This thesis was one of the deliverables of StandIN. The purpose of StandIN was to propose a common framework including standards for technical interoperability. The goal of this thesis was to structure and analyze information about the knowledge- and adoption level of the standards among providers of healthcare information systems (HIS’s). Moreover, it aimed to evaluate different aspect that might affect the adoption.
The target group was providers of HIS’s used in Swedish county councils and regions. The information was gathered through a survey and semi-structured interviews, and stored in an Excel database. From the database, Pivot tables and charts were created in order to show the knowledge- as well as adoption level of the different standards. The results were thereafter compared to theory about interoperability and standard adoption.
It was clear that the knowledge level varied for the different standards. In addition, the adoption level was very low - except from CCOW and HL7 v2. Least adopted were domain- specific standards. The results also indicated a trend for only adopting parts of standards.
Moreover, many providers stated that they performed specific integrations rather than followed common standards. This seemed to be due to the choice of standards being too wide, and the actual adoption not being consistent among the different providers. According to the providers, an introduction of a national framework based on uniform and consistent international standards was an awaited solution to the problem.
A future extension of this thesis would be to perform a similar study involving the customers.
The database could also be used to do clustered analyses of the adoption state in different county councils and regions. Moreover, it could be used to analyze the development of standard adop- tion over time.
Keywords: StandIN, healthcare information systems, healthcare informatics, interoperability, technical interoperability, standards, interoperability framework
Sammanfattning
Den här uppsatsen var ett utav delresultaten i StandIN, ett initiativ till att ta fram ett gemen- samt ramverk med standarder för teknisk interoperabilitet. Den här uppsatsen syftade till att strukturera och analysera information om kunskaps- och tillämpningsnivån för de tilltänkta stan- darderna.
Målgruppen var leverantörer av vårdinformationssystem som används i Sveriges landsting och regioner. Informationen samlades in genom en enkät samt semi-strukturerade intervjuer, och lagrades sedan i en Excel-databas. Pivot-tabeller och -diagram skapades för att visualisera kunskaps- och tillämpningsnivån, och resultaten jämfördes sedan med teori om interoperabilitet och standardtillämpning.
Det var tydligt att kunskapsnivån skilde sig för de olika standarderna. Tillämpningsnivån var generellt sett väldigt låg, bortsett från CCOW och HL7 v2. Minst tillämpade var domänspecifika standarder. Det var också tydligt att centrala leverantörer inte tillämpade samma standarder, vilket troligtvis påverkar de kompletterande systemen.
Många leverantörer gjorde snarare specifika integrationer, än följde gemensamma standarder.
Anledningen var att valet av standarder var för brett, och att den faktiska tillämpningen av stan- darder inte var konsekvent mellan olika leverantörer. Enligt leverantörerna skulle ett nationellt ramverk med enhetliga och internationella standarder vara en efterlängtad lösning på problemet.
En fortsättning på denna uppsats är att använda databasen till att göra klusteranalyser för tillämpningsnivån av standarder hos system i olika landsting och regioner. Databasen skulle också kunna användas till att analysera utvecklingen av kunskap och tillämpning över tid.
Keywords: StandIN, vårdinformationssystem, medicinsk informatik, interoperabilitet, teknisk interoperabilitet, standarder, ramverk
Acknowledgements
I would like to thank Håkan Nordgren, both for inviting me to your network and for your invaluable support. You have truly inspired me both personally and professionally. (And thank you for trying to prevent me from saying yes to this project, you made me realize that I really wanted the challenge.)
I would like to thank Björn-Erik Erlandsson for excellent supervision throughout the thesis.
Thank you for sharing your knowledge and expertise. I do, and will continue to, value your opinions.
I would like to thank Hilkka Linnarsson who carefully made sure that I felt involved in the StandIN project, by continuously providing me with information. I would also like to express a special thank you to Lars Jerlvall. Your input and information have been crucial for the quality of my work.
I would like to thank Swedish Medtech and Johan Lidén for all support in the execution of the thesis. Moreover, I am very thankful to the entire StandIN group. Thank you for sharing your expertise - I am truly inspired by your never-ending dedication to create a better Swedish healthcare. Thank you for letting me be a part of your excellent work.
I would like to express my gratitude to all of you who participated in the survey and interviews.
Your contribution was essential.
I would also like to thank my wonderful family and my amazing friends. You have not always understood what I am doing - but still you have been listening and contributed with unceasing support.
Lastly I would like to thank Sander Riedberg, my biggest supporter and love. Throughout the spring you have, without resistance or complaint, been participating in endless discussions about my work. Thank you for never stopping to believe in me.
Anna Hagman
Stockholm, May 27th 2016
Table of Contents
1 Introduction 1
1.1 Background . . . 1
1.2 Objectives . . . 2
1.3 Demarcations . . . 2
2 Theory 3 2.1 Interoperability . . . 3
2.2 Standards . . . 5
2.2.1 Standard Development Organizations . . . 5
2.2.2 Standards for Health Informatics and Interoperability . . . 5
2.2.3 Standards for Technical Interoperability . . . 6
2.3 Standard Adoption . . . 7
2.3.1 Inconsistencies Among Standards . . . 7
2.3.2 Level of Establishment . . . 8
3 Method 9 3.1 Literature Review . . . 10
3.2 Selection of Standards . . . 10
3.3 Database . . . 10
3.4 Data Collection . . . 11
3.4.1 Survey . . . 11
3.4.2 Interviews . . . 12
3.5 Data Analysis . . . 13
4 Results 15 4.1 The Knowledge Level of the Standards . . . 15
4.2 The Adoption Level of the Standards . . . 17
4.3 Importance of Adopting Standards for Technical Interoperability . . . 19
4.4 Importance of Factors for Standard Adoption . . . 19
4.5 Importance of Factors for Framework Adoption . . . 19
4.6 Interview Answers . . . 20
4.7 Drop-out Analysis . . . 21
5 Discussion and Conclusion 23 5.1 Discussion of Methodology . . . 23
5.2 Discussion of Results . . . 24
5.3 Future Outlook . . . 26
5.4 Conclusion . . . 27
Table of Contents
6 References 29
Appendix A1
Appendix A: Interoperability Frameworks . . . A1 Appendix B: Standard Development Organizations . . . B1 Appendix C: All Standards Considered within the StandIN project . . . C1 Appendix D: Summary of Standards for Technical Interoperability . . . D1 Appendix E: Answers to the Interview Questions . . . E1
xii
List of Figures
2.1 EIF’s different levels of interoperability [10]. . . 3
3.1 Overview of processes included in the method. . . 9
3.2 Entity relationship diagram. . . 11
3.3 Relational table diagram. . . 11
4.1 A Pivot chart showing the knowledge level for each standard. . . 15
4.2 A UML diagram showing the knowledge level. . . 16
4.3 A Pivot chart showing the adoption level for each standard . . . 17
4.4 A UML diagram showing the adoption level. . . 17
4.5 The importance of following standards for technical interoperability. . . 19
4.6 Factors affecting the introduction of new standards for technical interoperability. . . 19
4.7 Factors affecting the introduction of a new framework for technical interoperability . 20 1 eEIF’s different levels of inteoperability [11]. . . A2 2 The refined eEIF model [13]. . . A3
List of Tables
2.1 Standards for technical interoperability considered for the StandIN framework. . . . 6 1 SDOs developing health informatic standards . . . B2 2 All standards considered within the StandIN project. . . C2Nomenclature
e-Health The transfer of health resources and healthcare by electronic means
e-Health Ecosystem Different interconnected parts, including governance policies and regulations, financing models, technology infrastructure, services, and stakeholders
Convention A formal agreement for common concerns
Electronic Health Record (EHR) An electronic version of a patient’s medical history Framework A collection of standards, conventions, and applications Interoperability To what extent data can be exchanged and interpreted Standard A common solution to a recurrent problem. Issued by a
standardization body
Standard Development Organization (SDO) An organization issuing standards
Technical Interoperability Planning of technical issues involved in linking computer systems and services.
Chapter 1
Introduction
This chapter presents the background to the thesis, as well as the research questions and demar- cations. Thereafter a chapter with a theoretical background is detailed, followed by the method and results. Last, a thorough discussion about the findings is given.
1.1 Background
In Sweden the general healthcare is provided by 21 different county councils and regions [1]. All of them apply healthcare information systems (HIS’s) within multiple domains (e.g. electronic health records (EHR), medical images or laboratory information) and for different purposes (e.g. decision- and communication support), in order to make the healthcare more efficient [2].
Most of the county councils use the same provider for each domain, however, the many domains contribute to an inhomogeneous set of systems [2,3].
In order to utilize the HIS’s effectively, the different systems need to be interoperable. Inter- operability is usually described as the ability of systems, organizations, or processes to cooperate and communicate through common regulations [4]. In other words, it means that the right information is available at the right time and at the right place, independent of the systems’
provider.
HIS’s are not stand-alone devices [5], rather they are technical devices operating in a larger sociotechnical field. Therefore, achieving interoperability is not simple. In order to attain inter- operability one needs to examine the software and hardware of the HIS’s, but also the people and organizations interacting with them. Additionally, one must consider the external environment in terms of standards and regulations [6, 7].
Although standard compliance is intended to entail benefits for both customer and providers, studies show that standardization is not always effective due to conflicting imperatives [7, 8].
Some are concerned that the divergent collection of competing and overlapping standards might even worsen the interoperability [9].
Many projects have been initiated in order to solve parts of these problems [10–18], further elaborated in Appendix A. However, there is no common Swedish framework describing how to consistently combine international standards in order to provide seamless exchange of informa- tion. To address this issue, a digitization project called StandIN was initiated [19]. The project was financed by the Swedish authority VINNOVA, and performed through Medtech4Health. The project aimed to improve the Swedish eHealth ecosystem by proposing a solution to the interop- erability problem in general, and technical interoperability in particular. The goal of the project was to create a common framework including uniform and international standards for technical interoperability [20, 21].
Chapter 1 Introduction
1.2 Objectives
Early in the project it was found that there was neither information about the knowledge, nor the adoption, of standards for technical interoperability. Since interoperability requires consis- tently applied standards at the provider site, an evaluation of the standard establishment among providers of HIS’s was urged. This thesis was initiated in order to fill that gap of information.
The aim was to collect and structure information regarding standard knowledge and adoption among providers of HIS’s used in Sweden. The goal was to perform systematic analyses of the current state and the future outlook. The expected outcome was an identification of underlying objectives for standard adoption and resistance, and hence valuable input to the continued design and implementation of the framework. Below follows the research questions:
• What is the knowledge level for each standard in the StandIN framework for providers of HIS’s used in Swedish county councils and regions?
• What is the adoption level for each standard in the StandIN framework for providers of HIS’s used in Swedish county councils and regions?
• How important are different factors when introducing new standards for technical interop- erability?
• What are the patterns and discrepancies of standard adoption within different HIS do- mains?
1.3 Demarcations
The following demarcations have been applied:
• Focus was put on providers that delivered HIS’s to Swedish county councils and regions.
• Only the standards considered for the StandIN framework were investigated.
• The selection of standards was done in late March, hence the investigated standards and the final standards in the StandIN framework do not possess full conformity.
• The county council Kalmar was not included in the study, as they were not part of the SLIT investigation (performed by the IT directors of the Swedish county councils and regions) [2].
2
Chapter 2
Theory
This chapter covers the theoretical background. It includes definitions of the different levels of interoperability, as well as a section about health informatics standards in general and standards for technical interoperability in particular. Moreover, it presents theory about standard adoption.
2.1 Interoperability
According to the European Interoperability Framework (EIF), further elaborated in European Interoperability Framework (EIF), interoperability can be defined on four general levels; (1) legal, (2) organizational, (3) semantic, and (4) technical [10]. Legal interoperability implies an aligned legislation, whilst organizational interoperability includes integration of healthcare processes.
Semantic interoperability means that the exchanged information must be correctly understood by all users, i.e. it handles the exact meaning and formats of the information. Lastly, technical interoperability includes the linking issues between the HIS, i.e. different technical specifications.
Agreements on technical interoperability can thus include e.g. interface, security, data formats, and communication protocols [10] [22]. The different levels of interoperability are shown in Figure 2.1 [10].
Figure 2.1: EIF’s different levels of interoperability [10].
Chapter 2 Theory
According to the Healthcare Information and Management Systems Society (HIMSS), HIS interoperability is measured as to what extent HIS’s and/or devices can exchange data and information. It also includes to what extent the shared data and information can be interpreted.
In order for two HIS’s to be interoperable, the receiving systems must be able to correctly present the data from the sender [23].
Technical interoperability is a precondition for interoperability on the other levels. This implies that rules for how the information can be made available, and when needed be exchanged between different HIS’s, have to be specified. However, when defining the technical prerequisites the legal, organizational, and semantic preconditions must be taken into consideration [17]. This implies complex inter-dependencies between the different layers. With this said, interoperable HIS’s require solutions on all interoperability levels [24].
In order for HIS’s to work seamlessly in all sociotechnical perspectives, there is a need for both level-specific and cross-level interoperability solutions. As aforementioned, Appendix A includes a summary of different initiatives which have been applied both nationally and internationally, with the purpose to enhance interoperability.
4
2.2 Standards
2.2 Standards
A standard is a technical specification that contains a collection of requirements, specifications, guidelines, or characteristics that aims to make sure that products, materials, processes, and services are used correctly for the intended purpose [25, 26].
A standard is approved by a recognized standardization body, and compliance is often not mandatory [27]. However, compliance has many benefits since it provides suggestions on how to solve common issues. Moreover, it enables people, organizations, and systems to cooperate even though they might be disassociated [4]. For instance, using power outlets or following traffic signs are two examples on standard utilization.
2.2.1 Standard Development Organizations
A standard development organization (SDO) is an organization issuing standards and specifica- tions by following certain predefined requirements, procedures and rules [10].
There are many different kinds of SDOs, which operate on international and local levels, and develop different types of standards. Some SDOs profile within a certain area, whilst others develop a broad range of standards [4]. Appendix B: Table 1 tabulates SDOs that develop standards for different HIS interoperability purposes.
SDOs for healthcare informatics are often divided into four general areas: (1) official and formal SDOs (e.g. ISO TC 215 and CEN TC 251), (2) eHealth specific SDOs (e.g. DICOM), (3) SDOs developing standards that are used for eHealth purposes (e.g. IEEE and GS1), and (4) profiling organizations (e.g. IHE and Continua). Some provide standards that are very specific, whilst others issue standards applicable for an entire enterprise [4].
2.2.2 Standards for Health Informatics and Interoperability
Traditionally, the healthcare system has been composed of loosely coupled units, where the pa- tients have received care from primary, secondary, and tertiary care settings. The communication and coordination among these setting used to be poor, and there has been little coordination and sharing of information between the different settings [4]. Health informatics standards are useful when one wants to minimize inefficiencies and ineffectiveness due to these diversities.
In the outset health informatics standards were applied in specific departments, with a pur- pose to address local requirements. However, the need for reusing information in multiple systems enforced additional standards for collection, manipulation, and transmission of information. In other words, a need for standards which could ensure that information could be seamlessly and securely shared between independent HIS’s emerged [4].
It is important to recognize if an interoperability standard only applies to specific software applications or to the sociotechnical system as a whole. It is also necessary to understand if they are descriptive or imperative, i.e. describes what is provided, or includes how activities should be performed [24].
Chapter 2 Theory
2.2.3 Standards for Technical Interoperability
Many of the standards with a focus on the other interoperability levels do not define the technical infrastructure or technical prerequisites, e.g. middleware frameworks, routing, or transformation of messages and transaction identifiers. These aspects might be mentioned or referenced in e.g. semantic standards for reference models [24]. However, appropriate standards for technical interoperability is vital in the development and integration of interoperable HIS’s.
The standards addressing technical interoperability often include a description of how to present information, define elements and operations, and invoke operations or services. Some also specify the syntax of interface signatures or document- and message types, as well as structures, security conventions, and data network communication [24].
Different standards for technical interoperability are intended to support different domains, e.g. infrastructure or security. There are also different conventions, designed to provide solutions on how to solve common problems with the means of combined standards. Table 2.1 lists a collection of standards (and some conventions). All of them cover technical interoperability for different domains, and were considered relevant for the StandIN project. For simplicity, both standards and conventions will henceforth be referred to as standards.
Standard/Convention Class SDO
CCOW Infrastructure HL7
CDISC Clinical research CDISC
Continua Home Care Continua
FHIR Infrastructure HL7
HL7 v2 Infrastructure HL7
HL7 v3 Infrastructure HL7
IHE Profiles IHE
ISO 12052 - DICOM Imaging DICOM/ISO
ISO 12967-3 - HISA-3 Infrastructure ISO
ISO/TS 13606-4 Security ISO
ISO 13606-5 Interface ISO
ISO 18812:2003 Laboratory ISO
ISO 21091:2013 Directory ISO
ISO/IEEE 11073 Medical Technology ISO
ISO/TS 22600:1-3 Security ISO
UDI Identification FDA
Table 2.1: Standards for technical interoperability considered for the StandIN framework.
If the reader is not familiar with the tabulated standards, please study the summaries of their contents in Appendix D before reading any further.
6
2.3 Standard Adoption
2.3 Standard Adoption
Despite the great repository of standards, the HIS interoperability problem remains. One reason may be that many of the standards are developed by different SDOs, meaning that the standards might not be compatible with each other [28]. This might also lead to overlaps in their contents.
Moreover, there are few complete standards covering entire areas.
Another problem is that many standards have not been available for a very long time, and therefore they might not be fully established. Additionally, their contents and purposes are evolving so quickly that the descriptions risk to be outdated in less than a year [4]. Others think that there is a fear for introducing new standards that are not yet proven to give distinct benefits [29]. Moreover, factors such as medical device regulation and health policies have introduced non- technical barriers to standard adoption. This have lead to negative effects on the motivation for compliance with technical standards [30].
The aforementioned problems imply a challenge for organizations when deciding what stan- dards they should pay attention to, which they should embrace, and which they should fully adopt [24]. These problems are elaborated more thoroughly in the following sections.
2.3.1 Inconsistencies Among Standards
In a white paper published by European Telecommunications Standards Institute (ETSI), some examples of inconsistencies within and among interoperability standards are discussed. Some of the problems include [22]:
• Incompleteness, i.e. that the specifications are not complete. Moreover, some aspects imperative to interoperability might be missing.
• Inadequate interfaces, i.e. that interfaces are inadequately identified or not defined clearly enough.
• Poor handling of options, i.e. that the standards comprise too many options, or options that are not described clearly enough. This might lead to unexpected consequences if a certain option is chosen. Moreover, there might be inconsistencies or contradictions among different options.
• Lack of clarity and system overview, i.e. in cases when standards are combined in larger contexts, they are not always clearly specified and cross-referenced, which makes it hard for the implementer to achieve an accurate overview of the system.
The e-health Stakeholder Group has written a report (2014) as a request from the European Commission. The authors discuss inconsistencies in standards for HIS interoperability, and argue that there is a lack of recognition and application of relevant standards. In addition, they state that standards are developed inconsistently in different EU countries, which most probably affects the understanding and sustainability. Moreover, they describe the lack of a consistent vocabulary, both among disciplines and over time. The authors also claim that there is a lack of coordination between the customers and providers of the HIS’s, and that there is a political gap regarding adoption to uniform standards and profiles [31].
Chapter 2 Theory
2.3.2 Level of Establishment
It is believed that early adopters, i.e. the ones implementing a standard before it is fully de- veloped, envision that compliance to a standard will entail organizational or technological ad- vantages. The early majority instead follow the standard development, but do not participate.
However, they seem to be open for a rapid implementation if needed. The late majority worry about the discontinuity of the development, hence they prefer already established standards.
They only introduce new standards when being under pressure from e.g. society. A last group involves traditionalists. They resist new standards, often due to a lack of knowledge and re- sources [24, 32].
Some aspects that affect how fast one will adopt new standards are (1) the expected advan- tages for the implementer, (2) the compatibility with already existing solutions and architecture, and (3) the complexity of the introduction [24].
A previous example of an evaluation of standards’ maturity level is a report by the Interop- erability Standards Advisory process. The report represents a model, by which the Office of the National Coordinator for Health Information Technology (ONC), coordinates the identification, assessment, and determination of interoperability standards. It describes the adoption level for each standard by assigning it a qualitative value (from low to widespread adoption) [33].
The purpose of the ONC paper is to provide a public list of standards and implementation specifications, which can be used in order to fulfill health information interoperability needs.
Moreover, it aims to provide decision support when there is a competition between different standards and implementation specifications. Thereby it offers a list of the best available stan- dards. Further, it aims to reflect limitations, preconditions, as well as dependencies among referenced standards and implementation specifications [33].
8
Chapter 3
Method
This chapter describes the methodology. The thesis was divided into five main phases; literature review, selection of standards, creation of a database, data collection, and data analysis. The dif- ferent processes are shown in Figure 3.1. The figure also indicates that the different phases were performed iteratively, where continuous input from both the StandIN group and the academic supervisor was considered. The different phases are described more thoroughly in the following sections.
Figure 3.1: Overview of processes included in the method.
Chapter 3 Method
3.1 Literature Review
An extensive literature study was performed to give a theoretical substance to the thesis. The literature review comprised information from relevant books, peer-reviewed papers, as well as trustworthy online sources such as websites of well-established organizations.
Information was also collected from the common platform the Projectplace [34], where the StandIN group gathered all documents relevant for the project. The information included lists of selected standards, summaries of their contents, and different architectural models. All relevant standards chosen by the StandIN group were studied (see Appendix C: Table 2). The standards covering technical interoperability (see Table 2.1) were studied in more detail. For each standard both content and relations to other standards were investigated.
The literature review also covered research about different initiatives for how to improve HIS interoperability, including projects on both European and Swedish levels. In addition, research about factors affecting the adoption of new standards was considered.
3.2 Selection of Standards
The selection of standards was done in collaboration with the StandIN group. The process was done iteratively and during a long time, where both selection and elimination of standards were considered carefully.
In order for a standard to be included it had to cover clinical information. Moreover, it had to have a focus on technical interoperability, as well as be relevant for the StandIN project. The relevancy was determined through five criteria; it had to be (1) up-to-date or under development, (2) future-proof, i.e. not believed to be replaced in the near future, (3) applicable for healthcare purposes, i.e. not a general protocol, (4) possible to map to important standards for semantic interoperability, and (5) international, i.e. not tailored to a specific country or region. Moreover, it was determined that widely used conventions should be included in the framework.
Appendix C: Table 2 shows the original selection of standards. Table 2.1 tabulates the standards included in this thesis.
3.3 Database
Due to the amount and type of data, a relational database was set up in Microsoft Excel 2013 on a Windows software. Other options, such as different SQL alternatives, were considered. However, Excel provided all tools necessary to create a simple but comprehensive relational database.
First, an entity relationship (ER) diagram was created in Draw IO [35], see Figure 3.2. The different entities were county councils and regions, HIS’s providers, their systems, and standards.
All of them had multi-dependent relations to one another. The attributes of each entity are shown in the diagram, and the primary keys are underscored.
The ER diagram was further developed into a relational model, also created in Draw IO [35], see Figure 3.3. Each entity in the ER diagram had a corresponding table in the relational diagram. Due to the multi-dependencies, three additional tables were created. One table included information about which county councils and regions that were using specific providers. The second and third tables comprised information about the knowledge- as well as adoption level of the different standards. The primary and foreign keys of the different tables are indicated in the model. The relational database was completed by linking the primary and foreign keys by using the Data Model Toolbox in Excel.
10
3.4 Data Collection
Figure 3.2: Entity relationship diagram.
Figure 3.3: Relational table diagram.
3.4 Data Collection
The information about what county councils and regions that were using different systems was initially gathered for the SLIT investigation [2]. The information was however considered relevant to include in the database, and was provided through the common platform at the Projectplace [34]. The rest of the information was collected through a survey and interviews, further described below.
3.4.1 Survey
An online survey was designed through the website Webbenkäter [36]. The aim of the survey was to gather information about the as-is knowledge and adoption of the StandIN standards, as well as future plans of standard introduction. The questions were formulated to collect measurable data that later on could be used for statistical analyses.
Chapter 3 Method
The design of the survey was performed iteratively, including continuous quality checks with experts within the area. In addition, a test group of students answered the survey before it was handed out, in order to assure that the data was possible to analyze.
The target group of the survey was providers of HIS’s used in Swedish county councils and regions, chosen with regards to the SLIT demarcations [2]. The target group thus only included a selection of providers for specific types of systems. The investigated standards can be seen in Table 2.1.
The survey comprised two parts; (1) specific questions for each standard, and (2) general questions about factors affecting the adoption of the standards. Part (1) covered if the providers (a) knew the standard, and (b) already had, or had plans on, adopting it. The response options of both (a) and (b) were of nominal type. If the answer to (b) was no (i.e. the standard was not yet adopted, and there was no plan on introducing it), a logic loop was initiated. This resulted in a question about the major reason for non-compliance. These options were also of nominal type.
Part (2) comprised three general questions about standard and framework adoption. The first question (a) included how important the providers thought it was to follow standards for technical interoperability. The second (b) comprised the importance of different factors when introducing a new standard. The factors evaluated were economic benefits (i) short-termly and (ii) long-termly, as well as market benefits (iii) in Sweden and (iv) internationally. The third question (c) included the importance of different factors when introducing a new framework.
The factors evaluated where if the framework (i) was compliant with the as-is architecture, (ii) covered future-proof standards, (iii) strengthened the power of innovation, (iv) was required from the customers, and (v) if the customers were willing to pay for demanding adherence to the standards. All answer options in part (2) were of ordinal type.
The survey was sent out by email. If the receiver did not have enough competence, he or she was told to forward the survey to the right person. There was no restriction on how many persons from each company that could answer the survey, instead it was up to the participants to decide how to best cover the different systems. The survey was conducted in Swedish, hence all answers and results in this thesis were translated into English.
3.4.2 Interviews
The follow-up interviews were set up in order to gather more information, since the data collection was not yet saturated. The purpose of the interviews was to complement the survey data with more reasoning, hence they followed a subjectivist approach - commonly applied in healthcare informatics when one wants to investigate attitudes, beliefs, and preferences. The question type was decided to be semi-structured with predetermined but open questions, a recommended approach when one wants to give the interviewee a degree of freedom in their answers [37]. The interviews sought to illuminate, rather than judge, the perspective of the participants.
The number of interviewees was decided to be 4-6 persons, selected out of the ones who had completed the survey. The chosen interviewees included both small and large providers, in order to cover potential differences (a large provider was defined as a provider having systems in more than 50 % of the county councils and regions). The interviews lasted for approximately 15 minutes, and were all performed over phone.
12
3.5 Data Analysis
3.5 Data Analysis
The data from part (1) of the survey was exported to Microsoft Excel 2013 and put into the tables in the relational database. If a provider had given more than one response, the different answers were combined, i.e. each provider was only represented once in the database. Thereafter Pivot tables were created, including all tables in the Data Model. The Pivot tables were used to select and filter data from the different tables. Thereafter Pivot charts were created to visualize the results. The following analyses were performed:
• Standard knowledge among providers.
The tables KnowledgeStandard and Standard were selected. In the Pivot table the stan- dards were put on the axis, whilst the value (yes, partly, or no) was put in the legend. The count of providers was placed in the values cell. In the filter cell SDO and Standard Class were placed. Thereafter a Pivot chart was inserted. The filter entities enabled clustered analyses for different SDOs and types of standards.
A UML model was created in Draw IO [35], in order to map the standards along a line of knowledge. The model included the standards as well as and their associations, in order to visualize their inter-dependencies.
• Standard adoption among providers.
The tables AdoptionStandard and Standard were selected. The Pivot table and chart were created as previously described. Also, a UML model was created, showing the standards along a line of adoption.
• Factors affecting standard adoption.
The data from part (2) of the survey was not stored in the database, instead it was gathered directly from the web tool. Since the answers were of ordinal type, the different alternatives were assigned a numerical value (1-3). Thereby the arithmetic mean and standard deviation for each option could be calculated. This was performed for question (a)-(c), and resulted in three different tables indicating the importance of the different factors.
• Interview questions
Keywords from each interview were written in order to see similarities and discrepancies.
Also, the main conclusions were summarized in narrative text, including paraphrased text and not verbatim quotations.
• Drop-out analysis
The drop-out analysis included an assessment of the providers that did not participate in the study, as well as the ones that did not complete it.
Chapter 4
Results
This chapter includes some results derived from the database. It also presents the remaining results of the survey, i.e. the analyses of the answers from part (2). Furthermore, it comprises narratives from the interviews.
4.1 The Knowledge Level of the Standards
In figure 4.1 the green bars correspond to full knowledge, whilst the yellow ones correspond to partial knowledge. The red bars indicate a lack of knowledge.
Figure 4.1: A Pivot chart showing the knowledge level for each standard.
Figure 4.2(a) shows a UML diagram of the standards as entities, ordered along a line of how many percentage of the providers that knew the different standards. Figure 4.2(b) shows the used numbers. The lines between the entities indicate that two standards are inter-referenced.
The entities were placed after the number of providers that had full or partial knowledge about the standards, with no logic in the top-down direction.
Chapter 4 Results
(a) The entities represent each standard and are organized from the left (100%
knowledge) to the right (0 % knowledge). The diagram also shows the inter- dependencies between the standards.
(b) The knowledge level for each standard. One column in- dicates both partial- and full knowledge, whilst the other only indicates full knowledge.
Figure 4.2: A UML diagram showing the knowledge level.
Below follows some observations, sorted by the associated SDOs.
• CDISC: Only 29,4 % had full or partial knowledge about CDISC. The provider that fully knew CDISC was a big international provider. Three out of four that had partial knowledge were big vendors in Sweden. The fourth provider had PACS, RIS, and Clin. Phys. systems.
• Continua: All big providers possessed full or partial knowledge about Continua. The ones that did not recognize the standard were all providers of domain-specific systems.
• DICOM: The two respondent who did not recognize DICOM provided ancillary systems.
The rest knew it either fully or partially.
• FDA: Only 11,8% of the providers had full knowledge about UDI. These were big vendors with a big diversity of systems. The 35,3 % that had partial knowledge about UDI were also big vendors, except from one which provided ambulance systems.
• HL7: All providers had full or partial knowledge about CCOW and HL7 v2. Also HL7 v3 and FHIR could be considered well known. The one provider that did not recognize HL7 v3 provided ambulance systems. The providers that did not recognize FHIR were both small vendors.
• IHE: The two providers not recognizing IHE were small vendors. The rest knew it either fully or partially.
• ISO: The knowledge level for the ISO standards differed, but in general it was low. The most well known ones were the ISO 13606 standards. However, there seemed to be a gap between providers having full and partial knowledge. Approximately 60% recognized HISA-3, but there was no obvious pattern among the ones having and not having knowledge.
The least known standards were ISO/IEEE 11073 and ISO 18812. There were no patterns between the providers recognizing ISO 11073, whilst all providers which knew ISO 18812 had systems in the laboratory domain.
16
4.2 The Adoption Level of the Standards
4.2 The Adoption Level of the Standards
Figure 4.3 shows the number of providers that had adopted each standard. The green, yellow, and red bars corresponds to yes, partially, and no. The pale blue bars indicate that a provider had plans on introducing the standard, whilst dark blue means that the provider did not know if they applied the standard or not.
Figure 4.3: A Pivot chart showing the adoption level for each standard
Figure 4.4(a) shows a UML diagram with the standards ordered along a line of adoption, as well as their inter-dependencies. Figure 4.4(b) comprises the used numbers. The entities in the UML diagram correspond to the column with full or partial knowledge.
(a) The entities represent each standard and are organized along a line starting from the left with 100% knowledge. The diagram also shows the dependencies between the standards.
(b) The adoption level for each standard. One column in- dicates both part- and full knowledge, whilst the other only indicates full knowledge.
Figure 4.4: A UML diagram showing the adoption level.
Chapter 4 Results
In general the adoption level was low, i.e. most of the standards were only implemented by a few providers. Below follows some observations, sorted by the associated SDOs:
• CDISC: There was a high unawareness among the providers if they complied with CDISC standards or not. Only two providers had adopted them fully or partially, and they were both big vendors within multiple domains. One provider for RIS, PACS and Clin. Phys.
systems had plans on adopting those standards.
• Continua: The five providers that had adopted the entire or parts of the standards were all big providers with multiple types of HIS’s. In general the adoption level was low. No provider had plans on introducing it in the near future.
• DICOM: DICOM was one of the most adopted standards. There was no pattern between partial adoption and provider domain. Moreover, the few providers that were not compliant with DICOM included both large and small vendors.
• FDA: The adoption level of UDI was the same as the knowledge level. There was also a high unawareness among the providers if they were applying it or not.
• HL7: CCOW and HL7 v2 were the two most adopted standards (76,5 % each). Slightly more than 50 % were using the entire or parts of HL7 v3, and FHIR was just as widely used.
Moreover, all five providers not using HL7 v3 planned to introduce FHIR. One provider of ambulance systems planned to adopt HL7 v3.
• IHE: Two providers did not apply any profiles, one of them was a large provider and the other a small one. The four providers which had adopted the IHE fully were all international vendors. The ones who were applying it partially or had plans on introducing IHE profiles had systems in various domains.
• ISO: The adoption level of the ISO standards was very low. There was a gap between the adoption of ISO 13606 part 4 and 5, and it was slightly more common that both of them were adopted (6/10) than only one of them (4/10). The least adopted standards were ISO 18812 and ISO/IEEE 11073 (11,8 % respectively), and the same providers were applying both standards.
Many providers only applied parts of most of the standards, also including well-known stan- dards such as CCOW, HL7 v2 and DICOM. However, the large providers had adopted standards, both fully and partially, to a larger extent in comparison to small providers. The same applied to providers of core systems (such as EHR systems), in comparison to providers of ancillary systems. Slightly more than 50 % of the providers had adopted more than half of the standards, and most of them were large providers. Moreover, 20 % had adopted more than 75 % of the standards. More than half of the providers had adopted FHIR, two of them fully and the rest partially. Both providers that had adopted FHIR fully were international vendors. There were neither a connection between the size of the provider, nor the type of the provided systems, and the adoption of FHIR.
18
4.3 Importance of Adopting Standards for Technical Interoperability
4.3 Importance of Adopting Standards for Technical Interoperability
Figure 4.5 shows the results from the question How important is it to follow standards for technical interoperability? The figure shows the answer options with belonging weight in brackets, as well as the number of answers for each alternative. The arithmetic mean (Ø) and the standard deviation (±) are indicated to the right.
One can see that the great majority thought it was important to very important to follow standards for technical interoperability.
Figure 4.5: The importance of following standards for technical interoperability.
4.4 Importance of Factors for Standard Adoption
Figure 4.6 shows the results from the question How important are the following factors when introducing a new standard? All providers thought it was important or very important that an introduction of new standards entailed market benefits in Sweden. Market benefits interna- tionally was also important, however, the arithmetic mean was lower in comparison to Swedish benefits. Moreover, the standard deviation was greater for international benefits, which indicated a larger spread of opinions. Moreover, the providers thought it was more important with long term- than short term cost efficiency (Ø=2,57 to Ø=1,96).
Figure 4.6: Factors affecting the introduction of new standards for technical interoperability.
4.5 Importance of Factors for Framework Adoption
Figure 4.7 shows the results from the question How important are the following factors when introducing a new framework with standards for technical interoperability?
The most important factor was that the framework included standards that were future- proof. The standard deviation was largest for the framework’s ability to strengthen the power of innovation. The mean indicated that it was important to very important, however, a significant amount of providers did not think it was important at all.
Furthermore, the majority thought it was important or very important that the customers required a common framework, and even more important that they were willing to pay for the standards.
Chapter 4 Results
Figure 4.7: Factors affecting the introduction of a new framework for technical interoperability
4.6 Interview Answers
The answers to the interview questions are summarized in Appendix E. Bellow follows some of the key outcomes:
• All interviewees valued interoperability. Four out of five providers said that they were not compliant with many of the investigated standards, however they thought that common standards for interoperability would enhance the e-health ecosystem. The fifth interviewee stated that their interoperability was good, and that the key was adoption of relevant international standards.
• Four out of five providers only wanted to introduce the parts of the standards that applied to their systems, which often resulted in partial adoption. One stated that they only introduced what was required from their customers, another said that the standards were only used as an inspiration.
• The interviewees had no opinion about different SDOs. However, some believed that the reason to why HL7 standards (including FHIR) were more recognized was that they were better established internationally. One provider thought that there were inconsistencies between the different SDOs.
• The more established a standard was, the more interesting it got for the providers. One interviewee stated that the establishment of a standard depended on its ease of use. Others said that the establishment depended on the customer demand.
• All providers thought it was important that the standards were international. This was due to current or potential integrations with international systems, or a presence on the international market.
• All interviewees said that the customer requirements decided what standards to introduce.
Some thought that common recommendations on standards would facilitate the communi- cation between customers and providers. One interviewee said that a common framework would make it easier for all providers to get a market share.
20
4.7 Drop-out Analysis
4.7 Drop-out Analysis
The target group comprised 20 different providers. The number of fully completed surveys was 23, where two providers gave three responses each. In other words, 17 different providers answered the survey, i.e. 85 % of the target group. The number of initiated but not completed surveys was two, i.e. 10 %. The number of not started surveys was one, i.e. 5 %. The two providers that did not fulfill the survey said that they did not have the required knowledge in order to give accurate answers. The provider not participating at all did not give an explanation.
Chapter 5
Discussion and Conclusion
This chapter includes a discussion about the chosen methodology, as well as the derived results.
It also comprises a final section about the future outlook, i.e. recommendations on what should be further investigated.
5.1 Discussion of Methodology
A study must meet certain criteria in order to be credible, e.g. relevancy, validity, reliability, and repeatability. Since the state of the art indicates that there is indeed a gap of information regarding standard knowledge and adoption, the results of this thesis is highly relevant. Also, the fact that the results are one of the StandIN deliverables strengthens the argument.
Furthermore, the methodology holds a high validity, as the gained results clearly answers the research questions. Also, the investigated literature [37] shows that subjectivist approaches, such as semi-structured interviews, have provided valid results in similar studies. Even though one might argue that a pure objectivist study would entail a higher validity, it would not entail the right information. Since the aim was to also gather beliefs and preferences, an objectivist data collection would not have been enough in order to assure validity.
There is always a risk for collection of subjective, i.e. untruthful, data. In surveys and interviews, it is therefore imperative to hold a qualitative objectivity. Hence, it was made sure that the observer did not add any personal interpretations. Moreover, it was presumed that the participants’ answers were fundamentally truthful. Inevitably, the results might reflect opinions and perceptions rather than pure information, which in turn might affect the accuracy. However, since the results are not indented to be generalized, the results still give a valid as-is picture of the investigated area. Furthermore, the drop-out rate is small (15 %) which further contributes to the validity of the results.
The survey was iteratively designed and included continuous quality checks with both indus- try and academia, entailing a high reliability of its design. Also, the test group increased the reliability of the questions, as it confirmed that they were interpreted as intended.
Part (1) of the survey, including questions with nominal answers, can be considered straight forward for yes and no, whilst partly implies a degree of freedom. One way of reducing that would have been to implement a follow-up question about what parts of the standard that were known. Instead this was covered in the interviews, since the survey was intended to be as short as possible. Moreover, an investigation of the specific parts of the standards was not part of the research questions. In order to further increase the reliability, one could however continue to investigate the consistency in how different participants perceive the questions.
Chapter 5 Discussion and Conclusion
The persons who answered the survey all had knowledge about technical and regulatory issues.
However, it is hard to assure that the participants covered the knowledge and adoption level for the entire company. Thus there is a risk that the answers reflect specific and not the general knowledge and adoption level. In order to make the results more accurate, one could extend the survey to cover particular systems instead of asking about the provider in general. However, since there is no existing information about the investigated topic, the gathered information still fills the current gap.
The second part of the survey comprised questions with ordinal answers, which enabled numerical analyses. Even though the number of participants was too low to evaluate cause and effect, it was large enough to indicate patterns. In addition, an inclusion of more providers would not have been relevant due to the demarcations of the study. Furthermore, the number of interviewees was enough in order to saturate the study.
The survey is possible to re-publish in order to collect the same data, entailing a high re- peatability of the data collection. Moreover, the design of the database is transparent, which implies that it could be remade in either Excel or other tools. The Excel database is also easy to modify to store more providers, or to include more details. For instance, it is possible to add more tables, e.g. a table including information about what county councils and regions that are applying different standards.
The Pivot tables and charts were good means for representation of complex data, and made it possible to filter and combine data that otherwise would have been difficult. One drawback with the Excel database is that composite keys are not allowed, meaning that the look-up tables must have unique keys. In this case it was not a problem, but if one wants to add tables with such properties one must use another database tool.
5.2 Discussion of Results
It is clear that the knowledge level of the standards is not uniform - rather it varies from 100
% of recognition to known by only a few percent. Despite the in general low recognition, one can see some distinct patterns. For instance, the HL7 standards are more known in comparison to standards from other SDOs. Since all interviewees stated that they did not have a strong preference for any particular SDO, one can assume that it is not the SDO per se that decides the knowledge level of a standard. According to some of the interviewees, the difference more likely depends on the HL7 standards being more well-established internationally, or that the customers require them to a larger extent.
The fact that FHIR is among the most known standards, even though it is still a draft standard for trial use, advocates that there is still a correlation between the SDO and the standard knowledge. Therefore one can assume that the hype of FHIR is somewhat supported by previously successful standards developed by HL7 (see e.g. HL7 v2 in Figure 4.3).
ISO 18812 is the least known standard, followed by CDISC and UDI. In Figure 4.2 one can see that they either lack or have few associations with the other standards. A presumption could be that core standards, with many inter-dependencies, might be a reason to the low recognition level. However, this is contradicted by the ISO 11073 standard, which is neither well-known even though it is one of the standards with most associations. With that said, a standard which is referenced in, or required by, other standards might ease its integration with other standards.
However, it does not directly affect its establishment.
24
5.2 Discussion of Results
Similar to the knowledge level, and presumed from literature [31], there is a distinction between the adoption of standards from different SDOs. For instance, the adoption of HL7 standards are in general a lot higher than ISO standards. As previously concluded, according to the interviews it depends on the HL7 standards being better established and thus more commonly required by the customers.
If considering the ONC investigation [33], one can indeed see that the different HL7 standards possess a high level of adoption. According to the ONC report, also the ISO 11073 standard is recommended - even though it is assigned the lowest level of adoption. This implies that a low adoption level does not entail that a standard is not relevant. Further, this thesis indicates that it is common to only apply particular IHE profiles. This is also seen in the ONC paper, i.e.
that the adoption level differs for the different profiles. This is logical, since the different profiles are designed to support different domains - and hence different interoperability issues. How- ever, further investigations are needed before one can evaluate cause and effect of international establishment and Swedish adoption.
A factor of concern is that the investigated standards are of different type and complexity, i.e. they cover both comprehensive and domain-specific standards. This means that some of them are essential for all systems, whilst others are not. According to the results, this is one of the reasons to why some of the standards are not widely used. For instance, many providers cannot see how ISO 18812 would be necessary for their systems. The same applies to CDISC and ISO/IEEE 11073, which are all domain-specific standards.
In both literature [22,24] and the survey results, it appears that a harmonization with the as- is architecture is of great importance. This leads to the conclusion that the motive for adopting domain-specific standards must be clear - otherwise the providers will not see the benefits of compliance. Nonetheless, even though all standards might not be relevant for all providers, it is still imperative to possess knowledge about them. The present knowledge gap indicates that more education within standard content and compliance must be provided to be able to successfully implement a larger framework.
Another factor of concern is the trend of only adopting parts of a standard. According to the results, the main reasons to partial adoption are high costs and demands for resources. Therefore the providers choose to only comply with mandatory parts. This implies a risk for not achieving full interoperability, as standards are not intended to be used in pieces. If providers modify the standards in order to fit their own system, the efficiency of integration with other systems will suffer.
To achieve and maintain an interoperable e-health ecosystem, all providers must understand the effects of partial adoption. Moreover, they need to be transparent in their compliance in order for the customers to be aware of potential constraints. Hence the customer needs to know if a system from a specific provider is possible to seamlessly merge with already existing ones.
Moreover, transparency is essential to increase the degree of freedom for healthcare providers, e.g. when deciding what systems to buy in upcoming procurements. If a national framework with standards promotes partial adoption, it will be of utmost importance to highlight which parts that are musts, and which that are optional.
Considering literature [24, 32], one could assume that there would be different groups of providers, categorized by pace of adoption. In order to assess the early and late adopters of the target group, it is interesting to analyze the survey results about FHIR - as it is not yet an established standard. The results indicate that two providers had adopted FHIR fully, both of them being international vendors. More than 40 % of the providers had adopted parts of FHIR, however, there were no discrepancies between small and large, or core and ancillary, providers.
This means that no clear correlations could be found between the providers’ type of system and early adoption. Neither a correlation to the size of the provider was present.
Chapter 5 Discussion and Conclusion
Nonetheless, the information from the follow-up interviews emphasizes that the adoption of FHIR rather depended on it being sought-after on the international market. Hence, providers that do, or plan to, distribute their systems internationally have a higher tendency to adopt FHIR.
Except from FHIR, the results show that less than 50 % of the providers had adopted more than half of the standards - most of them being large providers. Also, less than 20 % of the providers were compliant with more than 75 % of the standards. This further emphasize that few providers are early adopters. According to both literature [24, 32] and the interviews, providers of ancillary systems do not want to adopt standards prior to the large providers. This is reason- able, hence if they shall benefit from implementing new standards, the core systems need to be compliant.
Further, the results show that the large providers, as well as the providers of core systems (such as EHRs), did not apply standards consistently. For instance HL7 v2 and DICOM, two fundamental standards, were not adopted similarly among core providers. This entails problems, as these providers perform many integrations with ancillary systems. Hence, if the core providers do not apply uniform standards, the providers of ancillary systems will not be able to optimize their implementations - since an adoption inhomogeneity in the core systems will require specific integrations. Further, the interview results emphasized that small providers may benefit from common standards, as it would make it easier to get a market share - both in Sweden and inter- nationally. In other words, common standards could be advantageous in upcoming procurements for all providers, in addition to being beneficial for the customers.
5.3 Future Outlook
Inevitably, it will be challenging to introduce a framework comprising standards with a low recognition and adoption level. Also, the involvement of standards from different SDOs will lead to potential gaps and overlaps. This enforces that the framework covers how to consistently combine the standards. Additionally, this study clearly shows that customer demand affects the compliance at the provider site. Thereby the success will highly depend on a good communication between the providers and customers.
One should also take the information in Table 4.5, 4.6, and 4.7 into consideration, as they highlight aspects important for the providers. For instance, one should emphasize how adoption of consistent standards can lead to market benefits both in Sweden and internationally. One should also motivate how the framework can be harmonized with the as-is architecture, but still consist of future-proof standards. This implies a need for a governance body who can continue to manage the framework.
Nevertheless, a consistent adoption of standards would improve the current state at the customer site, hence it would clarify what should be required from the providers. It would also decrease development costs for the providers, as well as entail market benefits internationally.
Moreover, it would increase the power of innovation, especially for small vendors.
In order to assess how the StandIN project affects the Swedish e-health ecosystem, one could continue to gather data about standard knowledge and adoption on a yearly basis. The data could be stored in the already existing database, and hence be used to visualize development and trends. That information would also make it possible to further elaborate why some of the standards possess a resistance. Furthermore, it would be interesting to see if the providers which had plans on introducing FHIR have adopted it yet, and if the ancillary providers have complied with them.
26
5.4 Conclusion
The database could also be used to perform clustered analyses of the adoption state in each county council and region. Since the database comprises information about the divisions, one could for instance see how they differ in standard adoption. Moreover, if the database was supplemented with information for specific systems, and not the provider in general, more thorough domain analyses would be possible. That would also facilitate the identification of technical interoperability barriers between particular systems.
Another extension would be to investigate the standard knowledge and adoption at the cus- tomer site, i.e. do a similar assessment for the county councils and regions. That data could thereafter be mapped to the providers’ data in order to indicate conformity and contradictions.
5.4 Conclusion
The lack of knowledge about, and the low adoption of, the different standards are alarming. The results from this thesis clearly shows that most providers rather do specific integrations than follow common standards, and hence it highlights that nationwide technical interoperability is far from accomplished. This does not only imply technical, but also organizational problems - both at the provider and customer site. In addition, the providers’ competition power risks to decrease on the global market. In the end of the day, this might lead to an erosion of the Swedish power of innovation, as well as a reduced selection of HIS’s in upcoming procurements. In order to achieve an interoperable e-health ecosystem, robust solutions where providers and customers reach a consensus are required. According to the results, a framework based on uniform and consistent international standards seems to be an awaited solution to the problem.
Chapter 6
References
[1] Sveriges Kommuner och Landsting. http://skl.se/tjanster/kommunerlandsting.431.
html, Accessed: 2016-03-11.
[2] Lars Jerlvall and Thomas Pehrsson. eHälsa i Landstingen, Inventering på uppdrag av SLIT- gruppen. June 2015.
[3] Patrik Sundström. Bättre vård och omsorg med stöd av digitala tjänster.
http://skl.se/tjanster/omskl/inriktningochverksamhet/prioriteradefragor/
battrevardochomsorgmedstodavdigitalatjanster.4831.htmlAccessed: 2015-12-10.
[4] Hammond, Jaffe, Cimino, and Huff. Biomedical Informatics, Computer Applications in Health Care and Biomedicine, Chapter 7: Standards in Biomedical Informatics. Springer, fourth edition edition, 2014. ISBN 978-1-4471-4473-1, DOI 10.1007/978-1-4471-4474-8.
[5] Hayrinen, K., K. Saranto, and P. Nykanen. Definition, structure, content, use and impacts of electronic health records: A review of the research literature. International Journal of Medical Informatics 77(5):291-304., 2008.
[6] Committee on Patient Safety and Health Information Technology; Institute of Medicine.
Health IT and Patient Safety: Building Safer Systems for Better Care. The National Academies Press, 2012. ISBN 978-0-309-22112-2.
[7] P Buckle, PJ Clarkson, R Coleman, J Ward, and J Anderson. Patient safety, systems design and ergonomics. Applied ergonomics, 37(4):491–500, 2006.
[8] Carl J Reynolds and Jeremy C Wyatt. Open source, open standards, and health care information systems. Journal of medical Internet research, 13(1):e24, 2011.
[9] Rachel L Richesson and Christopher G Chute. Health information technology data standards get down to business : maturation within domains and the emergence of interoperability.
Journal of the American Medical Informatics Association, 2015.
[10] European Union. European interoperability framework, EIF - towards interoperability for european public services. 2011. ISBN 978-92-79-21515-5, doi:10.2799/17759.
[11] European Union. eHealth EIF eHealth European Interoperability Framework, European Commission – ISA Work Programme. DG Connect, 2013. ISBN 978-92-79-30348-7 DOI:
10.2759/14325.
