All submissions of the EM system will be redirected to Online Manuscript Submission System. Authors are requested to submit articles directly to Online Manuscript Submission System of respective journal.
Mate Beštek1,2* and Peter Eklund3
 
1 IT University of Copenhagen, Denmark
2 National Institute of Public Health, Slovenia
3 Deakin University, Australia
 
*Correspondence: Mate Beštek, National Institute of Public Health, Slovenia, Email: [email protected]

Received Date: Nov 29, 2018 / Accepted Date: Feb 05, 2019 / Published Date: Feb 12, 2019

This open-access article is distributed under the terms of the Creative Commons Attribution Non-Commercial License (CC BY-NC) (http://creativecommons.org/licenses/by-nc/4.0/), which permits reuse, distribution and reproduction of the article, provided that the original work is properly cited and the reuse is restricted to noncommercial purposes. For commercial reuse, contact [email protected]

Abstract

Background: The driving force for information and communication technology in healthcare has been directed towards better-coordinated care but high cost and time consumption in addition to difficulties with cooperation with resident practitioners has hampered progress. Therefore, due to the underestimation of difficulties to manage national eHealth activities, the potential of eHealth in Europe is still to be realized.

Methods: An evaluation of the national eHealth in Slovenia grounded on open platform theory based organizational design principles for eHealth platforms has been conducted. We used a running use case of an eDiabetes digital health intervention as a potential new central service of the national eHealth platform. We discussed all the design principles and also constructed a questionnaire during the process to additionally help with the evaluation.

Results: We have identified a gap that needs to be bridged in order for Slovenia to achieve all the benefits of an open eHealth platform that could become a strategic direction for the future. We constructed a questionnaire that is based on the open platform theory grounded design principles for open eHealth platforms which we used as a helping tool to perform the analysis.

Conclusion: By evaluating the national eHealth in Slovenia against the open eHealth platform organizational design principles, we identified a gap that needs to be bridged to benefit from the positive effects of open eHealth platforms. Being open suggests participation, extension and growth both in terms of demand side users (e.g. patients and doctors) and supply side platform users (e.g. IT companies, HCPs etc.) Shortage of a business model is just one principle that still needs to be met in addition to several others. With this, Slovenia can ground its national eHealth vision and strategy on the results of this analysis.

Keywords

eHealth; Platforms; Open platforms; Open eHealth platforms; Evaluation; Design principles; Organizational design principles

Introduction

The eHealth Action Plan for 2012–2020 states that the promise of eHealth “remains largely unfulfilled” and the vision of a unified, interoperable eHealth Infrastructure in Europe is still not realized [1]. The driving force for ICT in health care has been the trend toward better coordination of care [1, 2]. Implementing national eHealth is an underestimated difficult to manage activity [1, 3] that is high cost and time- consuming. For these reasons it is difficult to cooperate with resident practitioners that are highly burdened due to an ever growing demand for their services. Due to this, an expectation gap occurs between the value of eHealth and the intention to adopt ICT in the healthcare sector [4].

Treating the national eHealth as a platform could allow more effective resource allocation. The primary role of platforms is to establish market functions for eHealth services and to overcome the traditional lock-in from solutions providers. Instead, a platform provides component-based service architecture. As part of the digital transformation process, typical care processes are becoming ever more integrated including not only healthcare but also in different contexts, such as social care and the environment of the patient’s home. Further, such integrated care processes are becoming personalized adaptive care pathways in the healthcare sector [5 ,6, 7] that we can describe as highly distributed, with adaptive integrated care processes spanning different domains (e.g. healthcare and social welfare domains).

To address the question of how to use the component-based services that comprise the national eHealth platform to develop new integrated care information systems, we look into design principles, as presented in [4], in order to address this question during eHealth platform construction.

These design principles are focused on the design of the organization that will offer the eHealth platform. Focusing on general information infrastructure design principles and more technical design principles are not the focus of this paper. Since design science research suggests we cannot obtain a generalized abstract artifact for eHealth platforms, design principles are an adequate means to create a theory in the field of eHealth platforms [4]. Following the ideas from [8] that suggest we can obtain design principles from initiated artifacts, we will use the national eHealth in Slovenia as a case setting in which we will see how well we can operationalize the design principles in this setting. By doing this, we will provide new evidence for supporting existing design principles or support the extension with new principles. We also provide a set of questions that we derived from the design principles and existing evidence to support the operationalization of the measurement of adherence to design principles. Also, we will consider implications of using the design principles as the basis for defining an eHealth strategy.

The focus of this article is, therefore, to revise the national eHealth of Slovenia as a platform, and, therefore, as an information infrastructure and to learn how the existing organization in charge of governance fits the organizational design principles for establishing an eHealth platform. We intend to identify a gap between the implementation and the requirements. By addressing the gap, we will identify a main national strategy on eHealth that will also be a guide to understand better, plan and execute the overall digital transformation of our healthcare system since the national eHealth in Slovenia has been legally defined as the national health information system in Slovenia [9].

This article is structured as follows: in Section 2 we quickly present the main concepts of the eHealth platforms, in Section 3 we present the national eHealth in Slovenia. In Section 4 we show the organizational design principles and use these as a checklist for Slovene national eHealth and by doing so identify the requirements and implementation gap. In Section 5 we elaborate on our results and present the strategy for our future work.

Literature Review

Definition of concepts

We can define platforms as “products and services that bring together groups of users in two-sided networks” [10], where some groups of users represent the demand side and other user groups represent the service providers. In the case of search engines, web surfers (demand) are joined with advertisers (supply). The platform role model [11] describes four main roles of participants that can either be open, meaning structured to encourage participation or closed [10]. Selecting optimal levels of openness is crucial for firms that create and maintain platforms [12] since a platform that is too open is not always the best option [13]. Open platforms are believed to be enablers of the ‘platforms ecosystems concept’. Ecosystems in, general, are inter- organizational networks [14]. In the context of platforms, ecosystems represent the platform and all the applications specific to the platform [15]. The ecosystem metaphor suggests the following systemic behavior as outlined in [4]: (1) the open platform is a dynamic network-based system that supports inter-component interaction. Initiation or interruption of interactions can occur [16, 17]. A central instance does not coordinate the emergence of communications. (2) The ecosystem allows both competition and cooperation between participants at the same time [18, 19]. (3) Components of the platform ecosystem are developing independently from each other but influence one another mutually in their development. This principle can be called co-evolution [20]. The components of the ecosystem can be combined, analogous to the recombination in nature [21]. (4) Participants can principally accede to the ecosystem or leave the ecosystem [22]. Therefore, it is an open system. (5) It is a non-predictable system [20]. Future system characteristics and components and their dynamics can consequently not be foreseen.

In line with the typology of ecosystems research presented in [14], we consider platform ecosystems as socio-technical systems – systems that comprise decision- making social entities like humans (or enterprises) as well as technical-components [23, 24], as cited in [14]. We look at the platform ecosystem as a type of ecosystem in information systems [14] that emerge around a central open platform [25]. A central open platform provides different IT components and rules that connect actors around and to the platform [20, 25] that, together with its boundary resources, play the dominant role when engineering ecosystems [18].

Open platforms as enablers of platform ecosystems can be an information infrastructure with only one platform [4]. Information infrastructure is defined as shared, open, heterogeneous and evolving socio-technical system of IT capabilities (recursive consist of information infrastructures, platforms, applications, and IT Capabilities) [26]. Distributed forms of control over information infrastructures often form the only way to coordinate their evolution and, therefore, they are never changed from above [27] - meaning there is no central coordinator that would be able to do a top-down control. Therefore, we cannot genuinely design them in a traditional sense as in conventional approaches a designer assumes control over the design space [28, 29] as cited in [26].

The blueprint to build a platform to enable ecosystem-effects is a platform strategy [30] that should be able to dynamically orchestrate the coordination, governance, and capabilities renewal processes – the three central processes of open innovation that is supported by platform-based ecosystems [31].

Open innovation was defined by Chesbrough [32] and is about opening the boundaries of organizations into a system of relations with different partners to support innovation. In such a context, platform-based ecosystems appear to be an effective way of managing a portfolio of contributions from varied and independent players for continuous innovation which has recently become a prime innovation approach [31]. Chesbrough [33] presents the future of open innovation as going beyond technology to business models that will embrace both product and service innovation. However, achieving open innovation is not to be considered a trivial task [34]. Open innovation traditionally revolves around a central organization – the supplier that expands into a network in both inwards and outwards. Authors of [35] suggest the opposite view on open innovation, where customers are the focal point. Governments can act as customers and with their legislative power can be the drivers of open innovation. Customer co-creation is also one of the identified gaps in the open innovation literature [36]. By supporting such collaboration, the transformation of value creation and service delivery is possible [37].

Platform ecosystems evolve. We can describe evolution by different network effects, e.g. [38]. Hence, the design of a platform strategy must address the intended effects of an ecosystem [30]. The governance rules and architecture are the control instruments for the establishment of intended network effects in an ecosystem [20], [39]. To understand platform architecture, governance, and evolution, it is essential also to be aware of the concept of the platform lifecycle. The platform strategy, therefore, depends on the lifecycle stage in which a platform currently exists, which is explained concerning dominant design stage (pre- or postidentification of the dominant design), the stage along the S-curve (progression of technology from introduction, ascent, maturity, and decline phase), and the diffusion curve (share of users that have adopted) [40]. From the technical perspective, the platform should provide a basic set of “Seed”-services to initiate these effects [41]. We focus on platforms that exploit network effects by mediating transactions between platform users [10, 11, 42, 43]. A platform comprises of a set of components and rules that coordinate network participant’s activities [44] and include standards, protocols, policies, and contracts [11].

In a recent call to revise eHealth platforms from the perspective of organizational design, [4] propose seven design principles grounded in existing platform theories [4] that we can use as guidelines for establishing platforms – in addition to existing technical considerations [45] and general information infrastructure design principles [26]. The seven design principles are as follows:

1. Open and synergetic business model,

2. Avoiding high entry fees and entry risk,

3. User-oriented price model and risk management of the platform participation,

4. Identifiability of products and services,

5. Reduction of information and knowledge deficits for platform users,

6. Securing restrictions from platform utilization possibilities,

7. Differentiation between platform management and the care management.

National eHealth in Slovenia

The national health system in Slovenia is suffering from fragmentation and poor quality health information which affects the provision of healthcare services and the management of the healthcare system [46] and has been lagging behind the EU28 average in most aspects [47].

The national eHealth system primarily focuses on becoming the health information system. In [46], the Slovene health information system is presented concerning three main components: an eHealth Network, a health portal, and an electronic health record. We focus on providing a view on the national eHealth system that is based on existing platform theory and specific eHealth oriented organizational guidelines for assessing the national eHealth system concerning being an open platform and identifying the requirements and implementation gap with regards to the open dual- sided platform theory [10]. With this, we would like to focus the attention of the national eHealth system towards the platform thinking that would support the platform economy in the healthcare system and with this enable better utilization of resources and as a consequence a more sustainable healthcare system.

Figure 1 depicts the main components of national eHealth system and also the main domain applications that represent different networks, processes, and ecosystems that are supported.

ejbi-document-types

Figure 1: National eHealth components.

The core components of the national eHealth system are supported by a set of technology solutions, standards, and methodologies that we now describe in more detail. Due to space limitations, we omit details about the different applications.

National eHealth System Core Components

Identity Management supports three essential services that are used by the national eHealth system core components and applications including the Identity Assurance Service that holds correct data about employees of the health system, and also holds identification data about patients, the two main user groups that access the national eHealth system. The data is obtained from different official national registries that are governed by different ministries. Technically, the Identity Assurance Service is used for authentication and authorization using the Security Assertions Markup Language (SAML) and OAUTH2 (similar to SAML but focused more on the web applications) to enable federated identity.

Central Registry of Patient Data (CRPD) is the central component of the national eHealth system and is, in fact, an Electronic Health Record. It consists of an interoperable information infrastructure that supports the sharing of data between different healthcare providers (HCPs). It provides essential services like the Demographic service as well as services that support document repositories that can be both unstructured and structured (concerning, e.g. OpenEHR [48] archetypes and templates). Table 1 presents the main document types and their overall number and share as of September 2017, and also the number of patients for each document type. In overall, some 67% of citizens have at least one document in the CRPD.

Table 1: Share and the number of different document types, and number of patients for different document types in the CRPD.

Document Type Share of Documents Number of Documents Number of Patients
Ambulatory result 39.97% 3,113,062 880,404
eReferral 31.84% 2,480,123 939,826
Patient Summary 17.29% 1,346,958 576,012
Hospital Discharge Letter 6.30% 491,039 263,023
Paper Referral 4.58% 356,386 244,551
Privacy Statements 0.01% 1,037 965
100% 7,788,605(#all documents) 1,390,194(#distinct patients)

Knowledge Sources

The national eHealth system supports different knowledge sources, namely terminologies, information models (OpenEHR [48] archetypes and templates), workflows (with limited scope), and also some decision support for the drugs related scenarios like contraindications and interactions. Terminologies like ICD- 10 [49] and SNOMED [50, 51] are used by different applications and are deployed on the Terminology Server. To achieve interoperability that also enables the breaking of existing vendor lock-in-based business models, the national eHealth system is using OpenEHR as an approach towards modeling clinical data in the form of openly available archetypes and templates. Managing cross-organizational care pathways that are adaptive and also personalized, is becoming of utmost importance. The national eHealth system has used Business Process Modeling Notation version 2 (BPMN2) as the basis only for some cases like the triage algorithm in eTriage, and a research project called eCare [52]. Decision support is, generally, not advanced in the national eHealth system and is in use only in the ePerscription where contraindications and interactions are presented to the prescribing doctor so that the best drug is selected and prescribed to the patient.

Boundary Resources

The central components of the national eHealth system are available through different forms of application interfaces (APIs). The lifecycle of these APIs needs to be managed, and lately, the API Management architecture reference implementation that supports all stages of the lifecycle (implemented during the EkoSmart project [53]) is being adopted. The boundary resources will, therefore, be provided through this solution. This includes both technical and documentation specific for different user groups. Boundary resources are primarily used by all the networks that use the national eHealth system platform. They are represented as standard or lightweight web services and even web forms that are integrated into existing solutions.

IT Infrastructure

The national eHealth system is running on two geographically different locations where one is called the primary and the other a recovery location. Data centers consist of typical server elements on top of which a virtualization layer is implemented. This is then used to run over 100 virtual appliances in the primary location that together support the system. The network (zNET) is a physically separate network consisting of about 130 physical routers that are distributed to the largest HCPs and pharmacies. To be able to access the services (except the patient portal), one needs to be included into the network, which does not run over the regular Internet. With this, the basic service availability can be efficiently supported.

National eHealth System Core Applications

The core set of applications that are supported include ePrescription, eReferral, eTriage, TeleStroke, TeleRadiology, Patient Portal, and National Registries (e.g. Patient Summary, National Vaccines Registry), and several small-scale applications.

Case Study for Design Principles for Open eHealth Platform

The eDiabetes Intervention as a Running Use Case

To have a running use case for this paper, we will use a use case of adding a new service to the national eHealth system that will support coordination of care, a platform in itself, and supports interventions targeting patients with conditions like asthma and diabetes, but also obesity, and those that are not sufficiently physically active. The platform would like to bring new services to the national eHealth and make them available to patients and many groups of professionals. We will focus specifically on the diabetes intervention (eDiabetes), described previously [54]. The primary process that eDiabetes intervention supports includes patients at home, nurses that perform the role of care managers, and primary level physicians. A home care protocol has been defined for patients and defines the tasks and frequencies of the tasks. Care managers (nurses) were given tools to monitor the status of diabetes in their group of patients. The intervention was evaluated in a clinical trial that included a network of primary level healthcare providers [55].

Analysis of the Inclusion Process of eDiabetes to the National eHealth System

We now analyze the organizational design guidelines and refer to the eDiabetes use case and by doing so, analyze the national eHealth system concerning design principles for open eHealth platforms that are presented in [5]. The principles are focused on organizational design and not on the technical aspects [45], where authors present the concept of medical application platform and focus on device interoperability, interoperability standards, common components technical architectures, and also lack of regulation and lack of ecosystems for such medical applications; or the general information infrastructure aspects [26]. Table 2 specifies detailed questions we asked ourselves to understand all the seven design principles more precisely and to use them for evaluating an existing eHealth platform.

Firstly, following the [11] platform role model, we define each of the four roles as they exist in the national eHealth. The Ministry of Health (MoH) is the primary provider of funding and, therefore, plays the role of a platform sponsor. With new legislation passed in 2015 [9], the governance of the national eHealth has been transferred from the MoH to the Centre for Healthcare Informatics (CHI) at the National institute of Public Health. Contracted service providers support the activities. The role of the platform provider is, therefore, shared by the CHI and external private providers which could give rise to issues with mismatching goals of public and private organizations and require having an explicit agreement about each party’s goals [56]. The eHealth network of HCPs is connected to the core components through existing systems, e.g. medical record systems and laboratory information systems. The IT providers of central services play a role of supply-side users. The national Health insurance fund participates in the national eHealth platform in the role of a demand-side user since it obtains essential information from the platform.

The eHealth network consisting of all the HCPs are legally bound to using the national eHealth core services. Unfortunately, many factors influence the current incomplete inclusion of all the HCPs [57] that are in the role of the demand-side users together with the patients. In the eDiabetes use case, the service providers want to take on a role of a supply-side platform user.

Open and synergetic business models

Healthcare is an actively regulated industry, and generally, organizations that are part of the public network are not supposed to be competing with one another in the market but in reality they do. Most HCPs in the healthcare system are contracting with the national Health insurance fund – these represent the public healthcare network. The national eHealth is providing core services to all the HCPs, but only those in the public network are obliged to use them. Regulation, therefore, enforces the use of core services. The CHI is in charge of the process of identifying new potential services and bringing them on the national level. This means that an IT provider, the supply side user, can create a new specialized application for a network of HCPs and can integrate with the existing core services of the national eHealth to provide the service to the demand side users. The integration is supported by the boundary resources [58] – namely the APIs. The CHI provides all the documents that specify how such inclusion can be executed together with all the technical documents of the core services to implement the integration. The necessary information is available on a special website, and the more specific documents can be obtained on demand if the new provider meets the preconditions of inclusion to the national eHealth. The preconditions primarily mean that there is a HCP that is requiring access to the national eHealth since HCPs have the legal grounds to do so. Companies therefore cannot become part of the national eHealth if they do not provide services for HCPs.

The financial aspects of the business model are unfortunately not transparent. The Health insurance fund is providing fixed monthly payments to the HCPs so that they can cover the IT costs in their organizations. Also, the MoH is financing the national eHealth which often includes upgrades to the solutions of all the IT providers of HCPs. Adding a new service to the national eHealth, therefore, means that there need to be more funds allocated by the Health insurance fund for the IT budget of all the HCPs. This is possible once a year through the general agreement contract that is signed by the Health insurance fund and all the HCPs.

To summarise, eDiabetes can be included in the national eHealth but due to an unclear business model and several system level issues which in turn hinders innovation we can say, that the national eHealth business model is not open and certainly not synergetic. Table 2 provides all the responses and the overall score as the share of responses that were same as optimal responses for this design principle of 25%.

Avoiding high entry fees and entry risks

In the eDiabetes use case, doctors and patients would need to use an existing national eHealth Identity Provider to use the new services. This brings integration costs to eDiabetes. Also, the integration with the CRPD is also a cost since different health- related data would be stored in the CRPD in the form of a chronic disease summary document. Entry fees for a new supplyside user are in this case present. This design principle scored a 42.86% (Table 2).

Table 2: Detailed questions that a platform evaluator should ask to ensure compliance with the design principles. Also, the authors’ responses are given (attribute A, 1 meaning yes and 0 meaning no) together with the number of responses that are the same as optimal (attribute O). The final score is also given for the core seven design principles. It is calculated as the share of optimal responses given of all the optimal responses. If we use the scores to calculate the average score over all seven design principles, we obtain the result 59,90%. The responses and optimal responses are obtained from cooperation with the National institute of Public Health - especially the CHI.

Design Principles A O A=O Score
1 Open and Synergetic Business Model 2
6 6 6 23.08%
1.1 Is there a business model described for the national eHealth? 0 1 0
1.2 Is it published online? 0 1 0
1.3 Does it describe the concept of how a sustainable and economic business is provided? 0 1 0
1.4 Has the platform provided specified how the return of investment will be provided? 0 1 0
1.5 Is the platform commercialized so that platform provider and platform sponsor can increase revenue? 0 1 0
1.6 Are key performance indicators defined? 1 1 1
1.7 Are they monitored? 1 1 1
1.8 Does the platform follow a business model? 0 1 0
1.9 Does the business model follow the principles of complete openness? 0 1 0
1.10 Does the model support synergies between platform users? 0 1 0
1.11 Does the model support different usage? 0 1 0
1.12 Does the model bring more benefits to the users then disadvantages? 0 1 0
1.13 Is a development strategy of the platform available? 0 1 0
1.14 Are openness and transparency enacted? 0 1 0
1.15 Are the impacts of joining the platform made explicit Is it published online? 0 1 0
1.16 Is innovation based on the platform encouraged? 0 1 0
1.17 Are profit oriented participants accepted to the platform? 1 1 1
1.18 Is it allowed to commercialize solutions for the open platform? 1 1 1
1.19 Do the platform sponsor and provider prevent or interfere with the use and expansion of the platform? 1 0 0
1.20 Are control processes made explicit? 0 1 0
1.21 Does the platform sponsor respect the platform provider his determination on implementing the business model? 0 1 0
1.22 Is the platform provider a private company? 0 0 1
1.23 Do private companies provide software and technology? 1 1 1
1.24 It the platform provider a neutral platform management company? 0 1 0
1.25 Is the information on how the platform sponsor influences platform provider made public? 0 1 0
1.26 Has neutrality of the business model been demonstrated by a third party. e.g. an information system expert? 0 1 0
2 Avoiding High Entry Fees and Entry Risk 3 7 3 42.86%
2.1 Can an independent healthcare network (demand and supply side) design integrated care scenarios? 1 1 1
2.2 Are the costs for these users too high so that they prevent market participation of the platform users? 1 0 0
2.3 Are there investment costs to be covered while accessing the platform (initially)? 1 0 0
2.4 Is there membership fees included at the time of first access to the platform? 0 0 1
2.5 Are direct entry costs formed at the time they arise or are they part of the initial access? 0 1 0
2.6 Is there a risk for the platform user that the platform provider will acquire their ideas and commercialize on their private platform? 0 0 1
2.7 Are there rules available that govern how intellectual property of the platform based solutions can be exploited - either to avoid or to control? 0 1 0
3 User-Oriented Price Model and Risk Management of the Platform Participation 1 3 0 0.00%
3.1 Is there a pricing model for platform participants defined? 0 1 0
3.2 Does the pricing model represent a barrier for platform participation? 1 0 0
3.3 Is the pricing model aligned with usage scenarios? (e.g. A flat rate can be a risk for an integrated care use case if not enough patients can be acquired) 0 1 0
4 Identifiability of Products and Services 6 7 6 85.71%
4.1 Are products and services identifiable on their own so that third parties can identify potential of platforms? 1 1 1
4.2 Are these products and services part of a standardized architecture of participation? 1 1 1
4.3 Do the products and services form the starting point for the targeted acquisition of platform resources? 1 1 1
4.4 Are products and services of third-parties also identifiable on their own? 0 1 0
4.5 Is information channels set up through which platform users can obtain information? 1 1 1
4.6 Is target group-oriented documentation available? 1 1 1
4.7 Is contact information available for the products and services? 1 1 1
5 Reduction of Information and Knowledge Deficits for Platform Users 2 7 2 28.57%
5.1 Are design features of the eHealth platform sufficiently documented? 0 1 0
5.2 Are design features of the eHealth ecosystem sufficiently documented? 0 1 0
5.3 Is the knowledge transfer concept of the platform available or documented? 0 1 0
5.4 Is the platform provider organizing information exchange (e.g. Forums. tutorials)? 0 1 0
5.5 Is the platform provider organizing meetups to facilitate knowledge transfer? 0 1 0
5.6 Are there not only technical resources available but also social resources? Is there somebody available for information exchange and knowledge transfer? 1 1 1
5.7 Is the knowledge transfer concept adapted for different groups of end users (e.g. SW companies, HCPs, patients...) and identify individual knowledge requirements? 1 1 1
6 Securing Restrictions From Platform Utilization Possibilities 6 6 6 100.00%
6.1 Are governance and safeguard rules for platform use implemented? 1 1 1
6.2 Does the platform provider utilize sanctions in the contracts with the platform users? 1 1 1
6.3 Are these mechanisms neutral concerning being open and non-discriminant? 1 1 1
6.4 Is the eHealth platforms security in line with comprehensive security and data protection regulation? 1 1 1
6.5 Are access restrictions regarding security and data protection transparently presented? 1 1 1
6.6 Is there an independent organization available to assess how a potential platform user is in line with different security/data protection restrictions? 1 1 1
7 Differentiation Between Platform Management and the Care Management 4 5 4 80.00%
7.1 Is design and management of new healthcare networks independent of platform provider? 1 1 1
7.2 Do platform participants maintain their independence and agility with regards to market and business changes? What are the decision rights of the platform participants? 1 1 1
7.3 Does the eHealth platform as an IT infrastructure support agile response to changes in healthcare networks integrated care scenarios (their business models)? 1 1 1
7.4 Does the platform provider have technical support in place and administration that supports changes also for the healthcare network managers? 0 1 0
7.5 Can healthcare network management configure by itself the operations of their integrated care scenarios? 1 1 1

User-oriented price model and risk management of the platform Participation

Platform participation contracts are not underpinned with a transparent pricing model for participating in the platform. As has already been mentioned, the members of the eHealth network – namely the HCPs, need to fund participation in the national eHealth platform. In overall, financial aspects are very unclear and are the cause of many issues. Considering eDiabetes, the financial aspects are not apparent and are left to at least negotiation with each HCP which represents a considerable barrier for platform participation. A more viable approach would be to obtain a direct contract with the platform provider which is subject to public procurement. The overall score for this design principle as given in Table 2, is 0%. The main reason for such a result is that there is no pricing model for platform participants defined which in turn represents a barrier for platform participation and is also not aligned with usage scenarios.

Identifiability of products and services

All the core services and applications are described publicly on a special web page. With this, third parties can identify potentials of the platform. Also, documentation is also published (www. ezdrav.si) that focuses on technical aspects but also end users. In the eDiabetes case, the documentation should be included on the mentioned web page. Unfortunately, third party services are not yet described there. Currently, no rules exist about including information about third party services to the primary national eHealth web page. Table 2 overall score of 85.71% suggests the identifiability of products and services, but not for all cases.

Reduction of information and knowledge deficits for platform users

Design features of the platform are not clearly and sufficiently documented. Same holds for the platform ecosystem and knowledge transfer. The platform provider organizes only occasional meetings that only report the state of affairs. However, the national eHealth provides social resources that offer support with information exchange and knowledge transfer on demand for different user groups, namely HCPs, patients, and IT companies. For the eDiabetes case providers, this means high resource consumption to understand the platform and becoming a participant. Even if social resources are available, these are, generally, very few which represents a high risk for the eDiwwne people at the CHI which does not enable normal operation.

The Table 2 score for this design principle is 28.57% which does also suggest a poor transfer of knowledge.

Securing restrictions from platform utilization possibilities

Ensuring security compliance of the eDiabetes services would not be an issue after implementing the core authentication and authorization services of the national eHealth. The eDiabetes has obtained positive feedback from the Data Protection Officer during the design, development, and evaluation in a clinical setting that it is in line with the data protection regulation in Slovenia. However, this process would need to happen again before production use since now there will be no patient consents available as they were during evaluation. Obtaining a green light from the Data Protection Officer is a time-consuming process that can represent a high risk in case the eDiabetes providers are not competent enough with this legislation – not only in Slovenia but now also on EU level due to General Data Protection Regulation. Table 2 overall score of a 100% suggests high security focus.

Differentiation between platform management and the care management

Design and management of new healthcare networks can be done independently of the platform provider as long as the members of the network have the legal grounds for participating in the national eHealth.

In the case of eDiabetes, the healthcare network consists of primary level physicians who are involved in managing patients with Diabetes. Here we assume, that eDiabetes is not used as part of the MoH policy tools set and, therefore, the network is fully independent and agile in changing eDiabetes as needed. The national eHealth can keep up with any smaller changes but otherwise focuses on providing core services that should not change too much. Tight coupling with the national eHealth is, therefore, not a right approach for eDiabetes. Support for the eDiabetes healthcare network managers would have to be done by the eDiabetes providers, most likely directly or through the already mentioned forum. Table 2 overall score for this design principle is 80% which still leaves room for improvement but shows a considerable maturity of this principle.

Conclusions and Future work

After analyzing the national eHealth from the perspective of organizational design guidelines by using the inclusion of eDiabetes services use case as the basis, we can see, that we were able to identify issues that inhibit the national eHealth to support the platform economy concept. The national eHealth can include new services, but the cost covering mechanisms are complex and represent a high entry barrier for services that are not introduced by the MoH.

We have used the detailed questionnaire depicted in Table 2 to evaluate all the served organizational design principles and also defined the optimal responses to give a numerical value or the score to the national eHealth concerning each organizational design principle. With the average score overall design principles of 51,46% and median value even lower at 42,86%, we could conclude, that the national eHealth is not compliant with the principles in a sufficient manner to be labelled an open eHealth platform - a basis for a platform economy. The national eHealth is fully compliant only with the sixth design principle on security and data protection. The identified requirements and implementation gap could be used as a basis for future governance strategy to at least reduce this gap, if not close it altogether. This would primarily include the definition of the business model (DP1) which is currently unclear and also the pricing model (DP3) for platform participation. This work needs to be a joint contribution of all the primary stakeholders of the national eHealth but mainly of MoH, National institute of Public Health, and the national Health insurance fund. The next step from here would be enabling continuous knowledge transfer (DP5) and lowering the platform entry costs (DP2).

To sum up, innovative and even clinically validated web-based support tools for patients with diabetes, cannot be included in the national eHealth. Moreover, since innovation is the foundation of a sustainable healthcare system together with its healthcare information system, our results can be used for increasing the importance of innovation in healthcare once again. One of the prime tasks is aligning the goals of public organizations and private companies for participation in the national eHealth since this mismatch hinders open innovation of platform-based ecosystems [56].

The work presented here is based on the idea of measuring the level of adherence to organizational design principles and questions are presented that could potentially help to operationalize the measurement. However, the discussion should be opened about other principles that could be added. Also, more specific questions may be necessary to analyse some principles. The set of questions used in this work was developed by the authors to clarify understanding of the applied design principles. Our future work would include using the questions in other settings – namely different similar organizations in other countries. By doing this, we could also provide newly identified design principles or refine existing ones.

The main contributions of this paper are (1) new evidence for supporting existing organizational design principles, (2) a detailed questionnaire that has the potential to be useful for measuring the adherence to the design principles, and (3) an example of evaluating existing eHealth infrastructures concerning organizational design principles which can be used by other evaluators.

Competing Interests

No competing interests.

Authors’ Contribution

Both authors contributed equally.

References