The Swedish Patient Portal and Its Relation to the National Reference Architecture and the Overall eHealth Infrastructure

Abstract

This chapter presents the evolution of the Swedish patient portal and how it has co-evolved with the eHealth architecture and the overall national eHealth infrastructure. It focuses on the period from 2000 to 2015. The case narrative illustrates the role a broadly and timely agreed upon national reference architecture played for distributed, yet harmonized development of a national eHealth infrastructure and the eHealth innovation made possible by that infrastructure. Our findings support the argument that infrastructure evolvement comes out of the complex interplay between many different actors intertwined in step-by-step cultivation. In Sweden, the infrastructure evolvement is done through the governance of a reference architecture endorsed by all entities contributing to the installed base.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

This chapter presents the evolution of the Swedish patient portal and how it has co-evolved with the eHealth architecture and the overall national eHealth infrastructure. It focuses on the period from 2000 to 2015. The patient portal with related e-services give citizens access to for instance e-scheduling, e-pharmacy, e-referrals, telemedicine, access to personal health information, digital self-services around the clock, Internet-Psychiatry, Electronic Health Record (EHR) logs, e-services that visualize planned care procedures including upcoming encounters, pre-visit form submission, e-communication with their physician or nurse, and secure disclosure of their health data (generated in the public health care system) to third party vendor’s apps and systems.

The case narratives illustrate the role a broadly and timely agreed upon national reference architecture has played during 8 years of distributed, yet harmonized development of a national eHealth infrastructure and the eHealth innovation made possible by that infrastructure. During these 8 years the installed base was organically expanded with new regulations, users, infrastructure components, portals and e-services, proving the importance of the infrastructure as a basis for innovation carried out and utilized by a broad range of stakeholders.

The remainder of the chapter is structured as follows: in the next section the Swedish healthcare model is presented, thereafter an overview of the core components building the Swedish eHealth architecture is illustrated. This section is followed by our narrative of the Swedish case. Next we analyze and discuss the core activities and actors that have evolved the installed base supporting innovation and entrepreneurship. Our findings support the argument that infrastructure evolvement comes out of the complex interplay between many different actors intertwined in step-by-step cultivation. In Sweden the infrastructure evolvement is done through the governance of a reference architecture endorsed by all entities contributing to the installed base. The installed base has evolved through the strategy of extending existing components, through complementing the installed base with new components and through the substitution of existing components with new ones. We also see a reference architecture as a vision-carrying foundation for many years of bottom-up, middle-out, top-down and yet harmonized, infrastructure evolution. More specifically, a shared, well understood and purposeful reference architecture may even be a contributing factor in reducing the probability and implication of “political” games.

Method

Data were collected as an action research study conducted from 2009 to 2015. Nina Sellberg was the R&D manager at the department of eHealth, Stockholm County Council (largest eHealth department in Sweden) between 2010 and 2014 and CTO at 1177 Vårdguiden between 2014 and 2015, with the responsibility of the national citizen platform. She was also appointed project manager of the My Care Pathways project, between 2011 and 2015 and appointed project leader of the development of the New Patient Overview Service implemented in all county councils and municipalities in Sweden from December 2015. Johan Eltes was consulting as head of architecture of My Care Pathways between 2011 and 2013. He was consulting architect at Inera AB between 2006 and 2013 for the development and management of the national reference architecture. He is deputy CTO at Inera AB since 2014, with the responsibility of the national interoperability profiles and the national reference architecture. Data collection included information gathering (a) from central stakeholders at Inera AB, My Healthcare Contacts, and project developers and vendors and, (b) from documents on national eHealth strategies, project management documents, the system specifications and IT architecture documents.

2 Swedish Healthcare

2.1 Overview of the Swedish Healthcare Model

The responsibility for health and medical care in Sweden is shared by the central government, county councils and municipalities. The Health and Medical Service Act regulates the responsibilities of county councils and municipalities, and gives local governments more freedom in this area. The role of the central government is to establish principles and guidelines, and to set the political agenda for health and medical care. It does this through laws and ordinances or by reaching agreements with the Swedish Association of Local Authorities and Regions (SALAR), which represents the county councils and municipalities. Sweden is divided into 290 municipalities and 20 county councils. There is no hierarchical relation (chain of command) across state, county councils and municipalities. The patients have free choice of hospitals, but General Practitioners (GPs) serve as gatekeepers for referrals to hospitals or specialists. The councils’ and municipalities’ autonomy is strong, and they make their own ICT investments. Costs for healthcare of Sweden’s gross domestic product (GDP) is fairly stable and on par with most other European countries. They represent in 2016 about 9.5 % of GDP (OECD 2014, WHO). The bulk of health and medical costs in Sweden are paid for by county council and municipal taxes. Contributions from the national government are another source of funding, while patient fees cover only a small percentage of costs.

2.2 Rationale for Developing the Swedish eHealth Architecture

The rationale for the development of the Swedish eHealth architecture was firstly the National IT Strategy that was taken forward in 2005. This was a work initiated by the Swedish Government with the intention to support (1) Citizens’, patients’ and families’ access to readily available and comprehensive information on health in general and on their own health, (2) Professionals’ access to information across organizational boundaries using effective and interoperable IT integration platforms that ensure patient safety and facilitate health professionals’ daily work, and (3) Healthcare decision makers’ access to relevant information enabling them to monitor and follow up patient safety, quality of care and healthcare performance.

The second rationale for developing the Swedish eHealth architecture was the National EHealth Strategy for Accessible and Secure Information in Health care, 2010. This work was also initiated by the Swedish Government with the intention to support: (1) Citizens, patients, clients and family members with access to quality-assured information on health also including access to clinical documentation from their previous efforts and treatments. Citizens should be offered innovative e-services for the exercise of participation and self-determination on their own terms, (2) Professionals with innovative and integrated decision support systems facilitating their daily work. Access to information across organizational boundaries should build the basis for the decision support systems, and (3) Healthcare decision makers with innovative tools and authority systems to continuously monitor the quality and performance of activities in order to optimize resource allocation. The focus was chosen to secure individual’s integrity in the follow-up and management of work.

The third rationale for evolving the Swedish eHealth architecture was the National Action Plan for eHealth, 2009–2012 and further evolved along the subsequent national action plan for eHealth, 2013–2018. The national action plans were agreed upon by the Swedish public care buyers – the 21 county councils. The county councils organize the national coordination of the action plans through the company Inera AB, which is owned by the county councils¹. The action plans were set up to reach a set of goals: (1) that citizens shall both be able to access all clinical information about themselves and actively participate in their care. This shall result in increased patient empowerment, active participation with smarter eHealth services and collaboration across organizational boundaries – Care Anywhere, (2) professionals with smarter eHealth services and access to all relevant medical information about a patient across organizational boundaries, and (3) infrastructure in place with secured operational maintenance and identification log-in.

The first and second strategies intended to change people’s mindset, promoting a vision of eHealth use. The third strategy is different from the first and second ones as it is not promoting an abstract vision but rather a very clear action plan demanding all county councils to get on board the eHealth train, with a clear structure of what should be done when. This led to a process where a number of national services and solutions were planned and implemented on a larger national scale. The third strategy is followed up in a different way compared to the first two strategies. It is followed up by statistical documentation of eHealth goal fulfilment (see Fig. 14.1), whilst the first two strategies were followed by early adopter success stories.

Fig. 14.1

Visualization of the National Action Plan for eHealth, 2013–2018

2.3 Core Components in the Swedish eHealth Architecture

This section presents the core components of the Swedish eHealth architecture (see also Fig. 14.2). Our account of the architecture is a snapshot from 2015. The presentation of these components aims to help the readers to follow the case narratives presented. The narrative outlines events of importance to the trajectory of the case study, but is confined to the events that are significant to the e-services of the case study. As a consequence, it doesn’t list events related to national eHealth development in areas such as cross-provider referral processes, medical certificate exchange, e-prescription processes, quality indicators, analysis of healthcare-associated infections and birth certificates.

Fig. 14.2

Simplified illustration of the Swedish eHealth Architecture. Examples of missing parts are: Health innovation framework, citizen, care and academic portal

The National Reference Architecture Framework was the first component of the Swedish eHealth architecture to be nationally applied by Inera AB and its owners (the 21 county councils). It has been in operation since 2007. The reference architecture defines a set of architecture principles, architecture patterns and guiding examples that govern nationally as well as regionally funded projects that contribute to the evolution of the Swedish ecosystem of connected eHealth. The reference architecture states six architecture principles: (1) A set of architecture principles govern eHealth projects. (2) The principle of information security, (3) The principle of national functional scope, (4) The principle of loose coupling, (5) The principle of organic/local evolution/contribution to the national ecosystem (6) The principle of federation. It is referred to the installed base as an ecosystem. The fifth architecture principle encourages local and regional organizations to initiate development of missing core components to the Swedish eHealth infrastructure. Thus, many core components have been developed and implemented by regional projects that were neither steered nor funded nationally. Over time they were linked or canonized to the national eHealth architecture, either as a new, an updated or a replaced component. New components are able to be linked when the shared reference architecture framework has been applied during the development work regardless if it has been conducted on a local, regional or national level.

Local, regional and national parties have cooperated, in a case by case way, in evolving the installed base in a successful way through the shared use of the national reference architectural framework. Of course a county council like Stockholm has contributed more than others due to its size and financial capability. When national prioritizations have not been aligned with local and regional needs, a group of county councils, municipalities and solution vendors have been able to join forces to develop solutions on their own for more local and regional use. The principles of national functional scope, secures that the solution can be applied on a national scale in the future. As time passes by, county councils, municipalities and solution vendors continuously negotiate to bring their local or regional solution to a national level, sharing the solution with all publicly funded care in Sweden. Therefore, the core components in the Swedish eHealth infrastructure are owned by various parties although shared through the Swedish eHealth Architecture and coordinated by Inera AB. Examples of such components are clinical APIs (Application Programming Interfaces for access to medical record information), care process services, core integration services, application frameworks and a patient-directed connectivity platform. Whether local and regional component will develop into national components or not depends on how they align with the national action plans for eHealth and the national reference architecture. In practice, there is ongoing collaboration and knowledge exchange between local, regional and national projects over time. Inera AB has implemented a national program office in order to formalize a process for supporting local and regional initiatives with a national ambition. There is currently a dispute between Inera AB and some regions whether ownership (IPR etc.) has to be transferred to Inera in order to get national funding as part of national canonization of a regional solution. This fact may affect the power balance between national, regional and local projects. The Swedish healthcare system evolves through a combination of centralized and decentralized models for ICT innovation (bottom-up, middle-out and top-down). The reference architecture framework is a centralized joint effort of all county councils and municipalities while the ICT development work occurs locally, regionally and nationally.

The second component developed was the national health information exchange (HIE) platform. The concept of a national health information exchange platform is defined by the national reference architecture. It defines a set of strategic service-oriented integration patterns along with a set of platform capabilities required for systematic and manageable instantiation of these patterns. The patterns aim at supporting technical and semantic connectivity requirements while still supporting regional and local evolution of the installed base (primarily the regional ongoing consolidation of health information systems). The patterns are information aggregation, service virtualization and protocol adaption. The protocol adaption pattern is however only applied at the national level when protocol adaption is not possible at the local or regional level. The overarching idea is to represent all local and regional EHR solutions as a single virtual, national EHR system in terms of an API and management via Inera AB. The API is utilized by national, regional and local API clients. The HIE platform makes it possible for an API client to access information and invoke transactions on all EHR systems in Sweden through a single connection point (the HIE platform) and a single API.

The Swedish reference architecture does not rely upon central storage of EHRs. The architecture is service oriented. All transactions and information requests are processed by the source system of the care provider in real-time. Technical and semantic interoperability depends on agreed integration profiles. These are labeled “service contracts” in compliance with OASIS Reference Model. The national HIE platform depends on a couple of utility services: a patient index to support information aggregation and a service routing registry to support a virtual service contract endpoint to resolve the logical address (e.g. an id of a healthcare provider) into the web service end-point address of the regional or local EHR system supporting that logical address (i.e. a healthcare provider). The national HIE platform was first released into production in 2010 by Inera AB. Inera AB has maintained the national health information exchange platform since its release. In October 2015, the monthly service invocation rate was 280,000,000, scattered across 180 national service contracts (integration profiles) supported by 4,500 endpoints (local and regional health information system installations). Roughly 2,000 of the clinical endpoints were connected during 2015, as part of the migration from the legacy EHR viewer (built on a closed/dedicated connectivity architecture) to a new version built to utilize the national HIE platform.

The third category of components developed was national service contracts. A service contract defines the requirements of a service-oriented communication end-point in terms of technical protocol, message formats (request and response messages) and functional and nonfunctional requirements of the interacting parties. The EHRs of the Swedish health care providers implement service-oriented communication end-points in line with these service contracts. The service contracts are based on OASIS WS-I Basic Profile 1.1 for technical interoperability. The messages of the clinical service contracts are designed according to the HL7 green CDA methodology. Security of message transfer between connected nodes is achieved at the transport level, by standardizing on https and mutual authentication (TLS). Message-based security is not used in the national technical interoperability profiles. The portfolio of national service contracts is governed by Inera AB. The service contract portfolio contains about 200 released service contracts (interoperability profiles). They have been developed, verified and applied in production scenarios since 2009. About 25 % of the released service contracts have been developed by Stockholm county council and thereafter handed over to Inera for governance and maintenance. The financing of this development has either been made directly by Stockholm county council or by external funding that Stockholm has applied for. Sometimes the external funding has been channeled through Inera due to administrative reasons although the application has been made by Stockholm county council.

The exchange of healthcare provider information across the HIE platform is regulated through commercial and data control agreements between county councils and Inera AB. The HIE platform and its management has become a hub for both information exchange and data control agreements.

Service contracts comprise API requirements for security, functionality and message structure. This means that beside APIs with code, service contracts contain for instance SLA requirements, e.g. response time, uptime, load, speed and recovery time. Over the period 2009–2011 service contracts were developed to support interoperability domains of scheduling, listing, security and drugs. Hereafter the focus has been on facilitating reuse of clinical data stored in local and regional health information systems. By the end of 2010, 95 % of hospital care and primary care centers were connected in line with the preferred care provider service contracts. Appointment scheduling expanded in a slower process. By the end of 2015, about 50 EHR end point systems support the service contracts for appointment scheduling. In Stockholm county council there are more than 1,500 Electronic Health Record (EHR) systems installed. However, one of the EHR systems holds about 80 % of the clinical data in Stockholm county council.

The ministry of Social Affairs promoted the interconnections of healthcare provider’s systems to clinical service contracts by means of economic incentives and support. At the end of 2015 100 % of the county council’s healthcare providers will be connected to the subset of clinical service contracts (facilitating reuse of clinical data) of most interest to the patient and the healthcare professionals. These are the service contracts covering medication history (ordination, prescription and administration of medications), clinical notes, care contacts, diagnosis and laboratory order outcome. In all there are 21 clinical service contracts covering reuse of all patient related clinical data in an EHR system.

The service contracts cover several areas of information exchange: (1) Re-use of medical records from the complete health care system: Clinical notes, medication history, structured observations, referral outcomes, imaging outcomes, laboratory order outcomes, referral status, immunization history, alert information, ECG outcomes, maternity medical records, care encounters and care plans (2) Care provider/Governmental agency information exchange: e-prescriptions, medical certificates; (3) National Master data Catalogues (unique citizen social security numbers, unique medical professional and healthcare provider identities; and (4) National agencies (Social Insurance (illness certificates) and Ministry of Social Affairs (code systems)).

All healthcare providers work with their preferred EHR systems and work processes in a heterogeneous environment where they can exchange information across organizational boundaries with partners that are supported by completely different EHR systems and work processes. Everyone has access to the information in its own installed technology base and in its own existing work processes. In this way the multiplicity and heterogeneity can remain whilst access to information across organizational boundaries is secured.

2.4 Core Components Developed by Stockholm County Council

In addition to the three components described above, four other core components were developed in parallel by Stockholm county council. They are offered on a national level by Stockholm county council. This means that maintenance is not yet funded by all county councils through Inera and is not yet governed by Inera. It is instead funded and governed by Stockholm county council through a parallel business model with connected county councils, however, negotiations are ongoing regarding ownership and funding in order to have a single coordinated funding and governance structure. The handover of components between local, regional and national levels are conveyed according a complicated organizational arrangement. It had reached a point where it was unclear if de facto-national infrastructure components developed by Stockholm County Council would be canonized into national governance at Inera AB. Meanwhile Stockholm county council has – for future development of nationally applicable solutions – decided to initiate development through the Inera program office. However, since Inera has limited resources to govern initiatives, the board of the 21 county councils has to prioritize which regional projects to govern. In that respect the ecosystem evolution seems threatened by new elements of centralization in conflict with the architecture principle of organic/local evolution/contribution to the national ecosystem.

The fourth component is the Application Framework. This is a generic name for application frameworks supporting development targeted at healthcare, researchers and citizens. The application frameworks consist of downloadable open source code framework and API documentation for simplified development of solutions that depend on web browser and mobile app client access to the HIE platform. Applications require login via strong authentication. Through the application framework, various systems and e-services can reuse for example single-sign-on and context-managing functions. Simplified access to the endpoints of the HIE platform are managed by the Application framework, e.g. ADL, Imaging Outcome, Diagnosis, Care Documentation, ECG, Functional Status, Prescribed Medication, Laboratory Outcome, Care Contacts, Maternity Medical History, Care Plan, Alerts, Medication History, Vaccinations, Care services, Other Examinations, Medication, Form service.

The fifth component is the Application Innovation Portal (HIP – Health Innovation Platform). It is a web-based one-stop-shop for developers of eHealth solutions that want to utilize national and regional infrastructures. The aim of the Health Innovation Platform is to provide information and access to service development kits (SDK) of various infrastructure components, including the application frameworks. The information includes methods, guidelines and complete code samples for service development – in both traditional environment and for mobile solutions for developers and designers. Through the Innovation Platform, developers both within and outside health care get up-to-date and streamlined one-stop-shop access to resources they need to create solutions that access data from medical record systems and other sources in a simple and secure manner according to national rules for access to patient data. The Innovation Platform holds development Kits targeted for the innovation of citizen, healthcare and research services. In short, the Innovation Platform is the software developer’s user interface to innovation resources that boost application development.

The sixth component is the Open Data Platform, a storage- and API platform for open access to data that is made available in line with the European Public Sector Information directive. Open data is made available to support innovation but it is also the means to provide APIs to non-personal healthcare master data required by e-services. This includes care provider master data, such as organizational structure, contact information, opening hours and care offering. Other examples include terminology and quality indicator master data. This offloads the national HIE platform from handling data that is publically accessible. Open data do not contain personal information and thus places no demands on secure access. The Open Data Platform is implemented in a highly scalable cloud infrastructure. Data kept in the Open Data Platform is synchronized (double stored) from the sources and made available via APIs that follow today’s best practice (“RESTFul”). APIs are described on the Application innovation portal.

The seventh component is the Patient-directed Connectivity Platform. This is a platform that offers patients the ability to share EHR information services and applications, and has been part of the national infrastructure since 2014. Social media has evolved far beyond e-services supplied by healthcare information owners. We can see how social services like Twitter, Google, LinkedIn, Runkeeper and Facebook have moved beyond e-services by offering its users the ability to control how information from the user’s account is shared with other services and applications. Information and functions are made available through APIs. Facebook and many other social media services offer its users a dual interface: applications (e.g. the Facebook web application and the Facebook iOS application) and a user-controlled API. The Swedish county councils have a strategy to mirror this duality: The National Patient Portal offer a citizen/patient-controlled API in addition to patient e-services (detailed in the next section). The citizen/patient-controlled API is secured by the OAuth protocol. The use of the OAuth protocol makes sure that the patient is in control of which data is accessible by which app that connects to the Patient-directed Connectivity Platform. Only the patient/citizen can grant a third-party application access to EHR data through the Patient-directed Connectivity Platform. Technically, the platform obtains EHR data “on demand” from the source EHR, via the national HIE platform services. In other words, the patient-controlled API is an infrastructure layered on top of the HIE platform. This is a property it shares with patient e-services. The e-services however – do not depend on user/patient authorization to be able to access the information. They are part of the trusted network and information access of these e-services are – unlike the third party apps – under the responsibility and data control of the county councils.

From a legal perspective, the information is owned by the patient as soon as it leaves this infrastructure component and enters a patient-directed (and authorized) endpoint (third-party application). An organization that offers such an application to its users, must obtain the user’s consent to be able to store or process personal data on behalf of the user. This applies even if the organization is a care provider, since the data – although sourced from an EHR – has become a possession of the user during its journey from the EHR to the app.

3 The Development and Evolution of the Swedish Patient Directed Infrastructure

In the beginning of 2000 Stockholm County Council started a patient portal and a personal health record project. The aim was to enable patients to communicate with their physician or nurse and to refill medications. The long term objective was to achieve patient centered safe and high quality care and prevention. In parallel the Association of County Councils in Sweden took the initiative to establish a public eHealth portal. This was extended in 2006 by the Association of County Councils to also include a patient portal project to offer patient-initiated refill of medications. How these different regional and national projects aligned into one gateway for Swedish citizen’s national patient portal and personal health record will be described in this section (see also Fig. 14.3. for the overall timeline). This is the first phase of the evolution into a Patient Directed infrastructure.

Fig. 14.3.

Timeline of Swedish eHealth Architecture development

3.1 Phase 1: Development of My Healthcare Contacts and Public Web

In the spring of 2000 the Stockholm County Council Executive Board decided to start the project Healthcare Guide. The stated aim for Healthcare Guide was to provide a “secure message feature” between patients and healthcare providers, and this was compared to the increasing use of Internet banks. The secure messaging could be used to share information, send inquiries, communicate and inform patients. It created a digital channel for individual care by offering a network of information and services that promoted the responsibility and participation of citizens in matters of their own health (preventive actions management and self-care); allowed digital interaction between citizens and the health system, providers and professionals; provided information on health care quality in different care areas in particular related to common diseases. Technically the creation of the public web portal started with the requirement on the platform to support x.509 certificates which was the standard for Swedish eID. The digital channel for individual care got the name My Healthcare Contacts after an internal Stockholm County Council name contest. The new platform was managed and owned by Stockholm County Council. In the spring of 2002, the development of My Healthcare Contacts began together with six healthcare centers (four Stockholm county council owned and two privately owned). During the fall 2002, the first pilots were launched with a limited number of forms such as Schedule Appointment, Renew Prescription and Cancel/Reschedule Appointment. There was a high demand for prescription services since it was often difficult to reach healthcare centers by phone. Consultation and prescription over the phone is a medical practice in Sweden. The rollout involved the cooperation and engagement of several local health providers and professionals who worked close to citizens and patients; information and communication campaigns to the public. There was never a conflict with professionals regarding My Healthcare Contacts. A reason for this may be that the e-services offered did not entail profound changes in the role and relationships between doctors and patients, and between doctors themselves. Instead early on results showed increased work processes effectiveness and less need for accessing healthcare centers by phone for renewal of prescriptions or bookings. As the awareness and use of My Healthcare Contacts increased in Stockholm county council the interest in the solution was also increasing from various other county councils. A negotiation process started which resulted in agreements between Stockholm county council and other councils e.g. Västmanland, Skåne and Halland. Through the agreements signed in 2011 all remaining councils join the cooperative development of My Healthcare Contacts led by Stockholm county council.

At that time Inera (which was then named “Sjukvårdsrådgivningen AB”), was offering public national medical related advice to patients – as searchable text on the web and through a phone service operated by healthcare professionals. My Healthcare Contacts (also including a public web site) and Sjukvårdsrådgivningen had become equally large sites by 2010. However, My Healthcare Contacts offered more services than the national site, e.g. Find Care Unit and Compare Queue Time.

A new national project called Healthcare Online started in 2006, where Sjukvårdsrådgivningen wanted to create a national patient service where both the public web and the personal part would be built into a single portal platform. The public procurement that Sjukvårdsrådgivningen had conducted wasn’t able to deliver, and the agreement with the vendor was terminated in the end of 2008.

At the same time, in 2008, Stockholm county council had continued its work to modernize their public site by switching to a supplier who already worked with agile practices and high delivery capability. Meanwhile, the national use of “My Healthcare Contacts” grew as an independent and relatively modular service, by means that its governance was not funded by national finances. Interestingly, by that time Stockholm county council was outperformed by another county council in terms of the number of care units connected to My Healthcare Contacts. Gradually it became obvious that the technical platform would need to be replaced as it got obsolete, but the question was how. Some felt that the entire application should be rewritten. But in the end it was decided not to shift platform. Instead, the strategy was to keep the technical platform for message handling and complement and link it to other more modern and open technology platforms for new functionality and new services. Said and done, My Healthcare Contacts got a new interface with responsive design for adaptation to mobile devices in 2012.

When Sjukvårdsrådgivningen had terminated their agreement with their preferred partner in 2008, the manager at Stockholm county council got a request to collaborate with the national Healthcare Online project. The result from the negotiations was that Stockholm provided a copy of the public web sites code to Sjukvårdsrådgivningen. The site got a new name 1177.se, and was now maintained by Sjukvårdsrådgivningen and not Stockholm. At this time Sjukvårdsrådgivningen was transformed into Inera. Inera was assigned to work with infrastructure including national HIE platforms.

In 2007, CareLink – a national eHealth standardization body owned by the county councils – released the first version of a national reference architecture for eHealth. In 2007 a new national eHealth program office was formed in which counties interacted and cooperated in an organized manner. This national program office function was called CeHis – Center for eHealth. A subsection of CeHis established an architecture governance unit to secure reference architecture conformance across the national eHealth projects coordinated by CeHis. The responsibility of the reference architecture development was transferred from CareLink to this unit. A new version of the reference architecture was released in 2011. The major highlights of the new version of the reference architecture were related to patient empowerment. The result of this work was for example six architecture principles and a set of supporting architectural patterns. It also contributed guiding examples for a list of prioritized eHealth scenarios. Stockholm county council and to some extent Inera initiated projects to establish the the national infrastructure capabilities outlined by the national reference architecture. Stockholm county council funded the majority of these capabilities. After capabilities had been developed and piloted by Stockholm county council they were handed over to Inera for maintenance. Inera receives collective financing from the county councils for this maintenance work. The uptake of the reference architecture among county councils, national projects and vendors on the market increased gradually with the increased awareness of its value to the eHealth ecosystem. In 2013 CeHis was incorporated into Inera AB. The architecture unit of former CeHis was reborn as the department of architecture of Inera AB.

In 2012 Stockholm got the national responsibility for citizen services including both the public web site and the secure digital channel My Healthcare Contacts. In 2014 My Healthcare Contacts was extended with a patient EHR viewer. This work has been funded by both regional and national program offices for development and maintenance. The purpose was to give citizens and patients digital access to the health records of the complete installed base of EHR systems. This was a prioritized goal of the national eHealth action plan for 2013–2018. The primary information data sets to be shared with patients were care contacts, care documentation, vaccinations, referral and lab results, maternity care and diagnosis. Since all parts of the national eHealth architecture are de facto developed there is a mixture of national and non-national budgets supporting its operation and maintenance. The positive outcomes of this mixture point to the key role of organic evolution for the Swedish eHealth ecosystem. The pre-requisites of an organically grown national eHealth ecosystem are captured in one of the architecture principles of the national reference architecture. This principle (i.e. allowing organic development by county councils without relying to central directions by Inera) has been fundamental for the controlled – yet organic – evolution of the national infrastructure. If this development was not opened for many stakeholders the national installed infrastructure would have taken much longer time to develop. In this way many different actor networks in parallel developed the national infrastructure. Sometimes, the principle of organic development contributed to unexpected parallel development of competing solutions. Uppsala County Council and Stockholm County Council developed competing patient EHR viewer applications- both with national ambitions. At the end of 2015 the Uppsala solution had reached a significantly larger user base. Stockholm county council then decided to decommission the “My Care Pathways” viewer eService in favor of the Uppsala patient EHR viewer. This meant that the frontend of My Care Pathways solution was decommissioned but the backend, which had become a central part of the national HIE platform for EHR access, was utilized. One frontend eService that uses this backend is Uppsala Count Council’s patient EHR system. For Swedish county councils to switch from one frontend (viewer eService) to another based on the same backend only requires administration of access rights.

3.2 Phase 2: Establishing and Developing the Patient Directed Connectivity Platform

This section describes how the development and modernization of My Care Contacts was conducted. It started with a presentation of an idea of a Patient Directed Connectivity Platform in late 2011. Work behind the idea was funded by Vinnova, the innovation agency in Sweden. One of the goals of the modernization project was to open up the portal architecture of My Healthcare Contacts to allow e-services to be developed and deployed outside of the portal platform itself. This should be accomplished in a way that independently deployed e-services would bring the same user experience as that of an e-service developed and deployed using the tools and infrastructure of the core portal product of My Healthcare Contacts. This would allow for regional development of national e-services using the development and deployment infrastructure of choice. The concept was labeled “The virtual portal architecture”. The virtual portal architecture is aligned with the 4th national reference architectural principle “Integrations shall be loosely mapped and re-usable for many purposes” and is thus part of the national eHealth architecture.

The modernization project had a substantial budget. It was critical to expand the pace in development of patient e-services beyond what was possible with the portal infrastructure which was available at the time and its vendor lock-in. However, the platform modernization didn’t really happen – at least not in the intended sense. Instead, focus shifted from strategic goals of vendor neutrality and increase of e-service delivery capabilities into the following main priorities:

• A new look-and-feel with support for mobile devices through responsive design

• Development of new e-services

• Governance and policy framework for hosting e-services from multiple sources

The idea of providing patient-controlled APIs along with e-services was scoped out due to resource constraints. The modernization project started in late 2010 and finished in midst of 2012. My Care Pathways was set up in 2011 with a high ambition to create several of the national service contracts, an open architecture for e-service as well as third party connectivity. In this aspect, the new project picked up where the prior modernization project was stopped: among other deliveries it delivered a virtual portal architecture proof-of-concept and a Patient Directed Connectivity Platform. All infrastructure deliveries were aligned with the national reference architecture, catering for future national uptake. This was achieved by tight collaboration with architects of the national program office at Inera. This project delivered both several back-end infrastructure components e.g. the open data API platform, Patient-Directed Connectivity Platform, Application Innovation Portal, Application Framework, Care Process Services and Questionnaire engine and front-end web services and APPs, e.g. national Form service, Survey tool, Notices, Referral status and My Care Pathways.

The Patient Directed Connectivity Platform was developed during 3 months starting in December 2011 with its first live demo on the national eHealth fair in April 2012. The demo third party application was a utility application that re-published appointments as live, subscribable webcal links. The vendor of the utility application offered the patient a live view of appointments directly in the private native calendar application of any mobile device:

Because several appointment/encounter modules of local and regional health information systems were connected to the HIE platform, the Patient Directed Connectivity Platform just had to connect to the appointment scheduling API of the HIE platform as client in order to access patient’s appointments within all connected health information systems. The Patient Directed Connectivity Platform then re-publishes the SOAP APIs as OAuth-secured REST APIs. The third party demo application acts as a client to the OAuth-protected API of the Patient Directed Connectivity Platform. The developers of the third party application used the Application Innovation Portal to learn about and explore the appointment API of the Patient Directed Connectivity Platform. They also utilized the open data platform ÀPI to get access to health care organization master data so that they could display opening hours and contact information of the appointed facility. More e-services and apps are being developed. More importantly there has been a cultural shift where apps are requested by both caregivers, patients and researchers, whereas it before was not considered as safe. Now the focus is what app is needed and how fast and easy can it be designed through the use of the Application Innovation Portal.

Although every relevant piece of the installed base were connected using the national HIE platform and applicable service contracts, information wouldn’t be accessible by the third party application unless (a) each care provider authorizes the Patient Directed Connectivity Platform access to appointment records and (b) the patient uses the patient portal to grant the utility application access to a personal copy of appointment information serviced by the Patient Directed Connectivity Platform.

Both of these requirements have proven to be challenging. The public care providers generally don’t seem to prioritize patient-controlled information access to the same extent as private care providers.

Regarding “b” the national organization holding the policy for connecting applications needs to find a balance between a thriving marketplace and trusting information owners. Several options are discussed for boosting the care provider’s willingness to support the concept of patient-directed connectivity:

• Third-party/care provider match-making forums

• Providing the patient means to digitally request information sharing capabilities from her care provider (as a feature of the patient portal)

• Public quality indicators that allows public ranking of healthcare facilities based on the amount of data that is available for sharing with third-party applications

If the trust problem is solved a number of new possibilities to create value on patients copy of EHR data are foreseen.

A number of workshops and conference presentations have been performed over 4 years of time to inform about the new possibilities. But the main efforts were targeted at the developer community. Public care providers still show very little awareness of the concept and thus do not actively grant the patient directed connectivity platform access to the EHR data through their existing national HIE platform connections.

There is however an agreement between the Ministry of EHealth and the 21 county councils to support the infrastructure as soon as the nationally procured Personal Health Account is launched. The purpose of the agreement is that the PHR will connect to the patient directed connectivity platform. The patients will then be able to direct EHR connectivity to their account of the PHR service. In order for information to actually be available for transfer to the PHR, each care provider need to authorize the patient directed connectivity platform EHR access. Once this has happened, the same EHR information will be available for other third party applications as will (in addition to the national PHR).

Examples on information sets accessible by users of My Care Pathways include: clinical notes, healthcare contacts/appointment, prenatal care records, vaccinations, referral statuses, laboratory results, advice and support related to specific diagnoses, information about health care guarantee (referrals), child health information, living habits. Similar information sets were provided by the service delivered by the Uppsala project.

In 2013 Inera contacted Stockholm county council to negotiate a takeover of the e-service My Care Pathways. Inera wanted to combine this service with the solution provided by the Uppsala county council project. Due to contractual agreement with the financier of My Care Pathways this was not possible as there was commitment on commercialization outside of Sweden. However, Uppsala came to an agreement with Inera.

During the same time My Healthcare Contacts put forward the idea of developing a new national EHR viewer for all care givers in county councils and municipalities in Sweden. It was forwarded through Inera. The idea was granted and the development initiated. My Healthcare Contacts could give this offer due to the work conducted with My Care Pathways. Said and done, the new national EHR viewer for healthcare professionals, accessing information across organizational borders, was designed and internally tested over a period of 6 months. It was thereafter externally tested and verified for 1 year. In the end the e-service My Care Pathways for patients and citizens and the national EHR viewer for caregivers shared to 80 % the same program code. The 15th of December 2015 the new National EHR viewer for healthcare professional was implemented in all county councils and municipalities. The implementation was a cooperation between My Healthcare Contacts at Stockholm County Council and Inera. It was a success project where all parties shared the same vision, aims, working structure and process, no second agendas were applied. During the rollout of the new national EHR viewer for healthcare professional, a new national test process was applied. From the implementation of the new national EHR viewer , the 15th of December, there has in average been 80,000 request for information daily. Its development was smooth, quick and successful and was an example of the installed infrastructures’ flexibility, scaling and reusability. Over this period only one web application error has been reported. Never has it been so quiet around the implementation of a new national e-service with 5,000 connected EHR systems. When the trains run on time this does not generate any headlines in the media. This illustrates the meaning of aligned interests, appropriate test procedures, coming to agreements and following it up with a full commitment. At the same period Stockholm county council through negotiations with Inera decided to decommission and stop the My Care Pathways solution in favor of the Uppsala one. In return the assignment of developing a new platform for My Healthcare Contacts is being negotiated. The results of the negotiations are not finished.

4 Discussion: Cultivation of the Patient Portal and the Overall Installed eHealth Ecosystem

Analyzing the trajectory of the co-evolution of the Swedish patient portal, the eHealth Architecture and the overall eHealth infrastructure we can state that much work has been done within personal health informatics and clinical informatics as well as on integrating these two. In Sweden it is understood that in order to achieve patient centered safe and high quality care these two need to be integrated in an overall SOA architecture. Many different e-services have been developed e.g. e-services that give citizens access to for instance e-scheduling, e-pharmacy, access to personal health information, e-communication with their physician or nurse, and secure disclosure to their health data (generated in the public healthcare system). These services have evolved by the replacement of old components, by complementing existing components and by building new ones. There are today many developments with further extensions of the existing eHealth Architecture. These projects are not restricted to one particular functionality but rather to manifold e.g. focusing on national interoperability issues between clinical information, patient care connectivity services whereas patient’s own measurement are integrated with clinical information through apps and services linked to the EHR.

As has been described in this case, important parts of developing the national information infrastructure were security, safety and confidentiality issues, which are important since the question of trust is a key factor in the establishment of new digital tools. Security, safety and confidentiality is not only involving patients but also all Swedish County Councils and their care providers in an intertwined two-way information infrastructure that is evolving in a step-by-step process extending the installed base over time according to user, also including safety, needs. An important issue to elaborate on, when Sweden has come so far, is the security of the information infrastructure that can handle high volumes of national clinical data visualized through personalized health services.

New components can be linked as the shared reference architecture framework has been applied during the development work regardless of whether they has been developed on a local, regional or national level. Evolving the installed base local, regional and national parties have cooperated in a successful way through the shared use of the national reference architectural framework.

Various strategies and projects and activities have played different roles depending upon their character and timing. Many projects have cultivated the way individuals think about the design, interoperability and innovation of eHealth. Although some e-services did not reach a national implementation they still made an impact on the development of other e-services and infrastructure components. The importance of choosing the relevant marketing and implementation channel is crucial for the spread and usage of e-services. These examples illustrate that factors of quality, costs and functionality are of minor importance. The examples also illustrates that if a strategy has reached a maturity among its stakeholders and if implementation channels are chosen by influence and power anything can work.

In Sweden the eHealth projects have undergone a transformation from being cultural to structural and process oriented when they share the same backend. Overall, the foundation of Swedish eHealth development work is based on complicated organizational arrangements. The national reference architecture has shown itself to be an important stability actor in this work, i.e. something that actors can fall back on and agree on in their discussions. The National reference architecture constitute here a direction of what is correct, even though it is open to interpretation.

To allow different actors to individually or jointly contribute to the applied SOA architecture has led to a distributed development work. The challenges have primarily been related to power factors, i.e. negotiations between different parties at different levels. The county directors’ role and responsibility to steer and control Inera’s work have been more or less exerted over the years. This has of course led to a direct impact on Inera’s prioritization work. In all, steering has become weaker over time.

One conclusion to draw is that if there is a national reference architecture in place, it is something that increases the likelihood of the parties to agree in negotiations. If they have a commitment to fulfill agreements is another issue. Much needs to be matched for the parties shall agree, cooperate, get involved and together successfully reach a goal.

Our findings support the argument that infrastructure evolvement come out of the complex interplay between many different actors intertwined in step-by-step cultivation. In Sweden the infrastructure evolvement is done through the governance of a reference architecture endorsed by all entities contributing to the installed base.