Design principles for achieving integrated healthcare information systems

Abstract

Achieving integrated healthcare information systems has become a common goal for many countries in their pursuit of obtaining coordinated and comprehensive healthcare services. This article focuses on how a small local project termed ‘Standardized pull of patient data’ expanded and is now used on a large scale providing a majority of hospitals, general practitioners and citizens across Denmark with the possibility of accessing healthcare data from different electronic patient record systems and other systems. I build on design theory for information infrastructures, as presented by Hanseth and Lyytinen, to examine the design principles that facilitated this smallscale project to expand and become widespread. As a result of my findings, I outline three lessons learned that emphasize: (i) principles of flexibility, (ii) expansion from the installed base through modular strategies and (iii) identification of key healthcare actors to provide them with immediate benefits.

Keywords

Design principles electronic patient record (EPR) systems integrated healthcare information systems standardized pull of data

Introduction

A common goal for many countries in their pursuit of obtaining coordinated and comprehensive healthcare services is building integrated healthcare information systems.^1,2 These systems are based on a common set of standards for information sharing and data exchange between systems, programs and institutions.^3–5 Their benefits relate to ensuring instant availability of all relevant information to healthcare providers, enabling cross-disciplinary communication and guaranteeing continuity of care, as well as automatic checking for drugs and other interactions.^4,5 Integrated healthcare information systems are conceived primarily as a combination of technological installations (e.g. information systems, networks, communication technologies) of an organization that, together with the human skills component, should be managed strategically.^6–8 In the literature, these systems have been conceptualized as ‘information infrastructures’ that encompass technical, social, organizational and regulatory elements.^9,10 An information infrastructure perspective addresses the challenges associated with systems and solutions that extend beyond the local context, and serves multiple communities with different interests simultaneously.^11–13

Because of their complexity, building integrated healthcare information systems poses a number of challenges.^13,14 Inconsistencies in local definitions and procedures may create fragmentation which makes it difficult to define standards that extend local practices.^3,14 Tensions may also arise between standardization attempts and the wish to obtain a certain level of flexibility in the pattern of use and further changes.¹⁵ Consequently, the question is: How can we design and achieve integrated healthcare information systems? To address this question, I investigate a project that was initiated in 2000 between a few county hospitals in Denmark with the objective of sharing patient information between electronic patient record (EPR) systems. The project was termed ‘Standardized pull of patient data’ (SUP) and the initial objective was to build a pragmatic solution to exchange information between different EPR systems within a county and across county boundaries in Denmark. Over time, the SUP solution developed into a standard used on a large scale by the majority of hospitals, general practitioners (GPs) and citizens across Denmark, with the possibility of accessing patient data from EPRs and other systems.

Considering the success of this project, it is natural to want to investigate how this small-scale project developed and grew into an integrated model of data retrieval between EPR systems. By doing so, we may be able to learn from the case study and thus inform future healthcare integration projects, not only in a Danish context but also in similar contexts. Building on the design theory for information infrastructures as presented by Hanseth and Lyytinen,⁹ we are able to conceptualize which design principles were used to make this project expand. This will draw our attention to a number of lessons learned for future projects, when the aim is to build integrated healthcare information systems that move beyond local boundaries.

In the next section, literature on design principles for building integrated healthcare information infrastructures, as outlined by Hanseth and Lyytinen⁹ and others,^3,16–18 is presented. The design principles are related to a healthcare setting and then the SUP project and its development over time from its initiation in 2000 to its current status is presented. The SUP project is analysed based on the design principles and the usefulness of these principles in terms of the lessons learned for future integrated healthcare information projects is discussed.

Design principles for integrated healthcare information systems

In the literature a number of studies that conceptualize the process of building integrated healthcare information systems is found; however, only a few studies provide normative recommendations on this matter. For instance, Braa et al.³ propose a strategy for developing information infrastructures in the healthcare sector in developing countries. Building on complexity theory, they introduce the concept of ‘flexible standards’ as a key element in a sustainable infrastructure development strategy. One dimension of flexible standards is ‘change flexibility’, which relates to the ability of changing standards through modularization. The other dimension, ‘use flexibility’, refers to the extent to which a standard can support many different activities and tasks simultaneously. The flexibility makes it possible for users to change some of their local practices that are supported by the standard without having to change the standard itself. In a study by Hanseth and Lundberg,¹⁶ the notion of ‘work-oriented infrastructures’ is introduced to emphasize that infrastructures expand in a piecemeal fashion over a long period of time. Changes should be carried out by the user communities to ensure immediate local benefits.⁵ In line with this, Hanseth and Aanestad¹⁷ introduce the notion of ‘bootstrapping’ as a way to guide the navigation and exploitation of technology in healthcare. Technology is defined here as ‘the process of making a tool by means of the tool itself’.¹⁷ Through a case study on telemedicine, the authors conclude that bootstrapping relies on a number of principles: expanding existing solutions, avoiding interfering with existing practices, learning from simpler areas before moving into more complex ones, identifying areas which are considered important for users and motivating more users through successful demonstrations.

One of the more comprehensive and recent attempts to formulate a design theory for information infrastructures is presented by Hanseth and Lyytinen.⁹ The authors distinguish between two generic problems when designing information infrastructures, i.e. the ‘bootstrap problem’ and ‘adaptability problem’, and present design principles to address these challenges. The challenge of the ‘bootstrap problem’, as also presented by Hanseth and Aanestad,¹⁷ addresses how to establish a novel information infrastructure. An information infrastructure only gains value if it reflects a large and diverse user base and components.¹⁴ Initially, the user community is small, which prevents the infrastructure from offering its expected benefits. In order to address the ‘bootstrap problem’, the first design principle is, thus, to ‘design initially for direct usefulness’. As a large user base cannot be expected at the outset, the solution must motivate the initial users by addressing their needs and solving their problems in a way that does not require a complete solution.¹⁸ The design rules relate to a prioritization of immediate use value by being simple to implement and use, as well as to postpone scalability, extension, and completeness of the solution.

The second design principle advises designers to ‘build upon the existing installed base’. Infrastructures do not grow from scratch, but inherit the strengths and limitations from the existing base.¹⁹ In a healthcare context, the installed base is comprised of a number of information systems, paper forms, regulations and procedures. It is important for designers to analyse and exploit existing infrastructures, platforms or communication formats. This implies building gateways to existing information infrastructures and capitalizing on their bandwagon effects. The existing installed base is used to build additional attractors by increasing positive network externalities.

The third principle recommends designers to ‘expand the installed base by persuasive tactics to gain momentum’. The belief is that users come before functionality, implying that the user base should grow before adding new functionality. It also relies on the rule of building and aligning incentives so that users become motivated to use the solution and to develop support communities to enhance feedback and learning.

The challenge of the ‘adaptability problem’ relates to the further growth and expansion. In this process, unforeseen demands, opportunities and barriers may arise, which means that designers need to exploit infrastructural flexibility in order to avoid blind alleys and suboptimal lock-ins. To address this challenge, Hanseth and Lyytinen advise the pursuit of ‘making the IT capability as simple as possible’ as the fourth design principle. This simplicity refers not only to technical and social issues, but also to the information technology (IT) capabilities that should be partly overlapping instead of all-inclusive.

The fifth design principle is to ‘modularize the information infrastructure’ to allow independent incremental change in separate components. The purpose is to separate the layers of infrastructures from each other (e.g. service layers from transport layers) and to exploit gateways to connect different layers or regions. Furthermore, transitions strategies must be developed in order to plan the ongoing adaptation of the infrastructure.

Table 1 presents the two design challenges and the five principles that address them.

Table 1.

Design challenges and principles (inspired by Hanseth and Lyytinen⁹)

Design challenge	Design goal	Design principles	Explanation
Bootstrap problem	Generate attractors that bootstrap the installed base	Design initially for direct usefulness	Persuade the initial small user group through targeting their needs and solving their problems Be easy to use and easy to implement Be directly useful without the installed base
		Build upon existing installed base	Exploit infrastructures, platforms or communication formats already in useEliminate need for designing and implementing new support infrastructuresBuild gateways to existing service and application infrastructuresCapitalize on the bandwagons effects of other infrastructures
		Expand installed base by persuasive tactics to gain momentum	Generate positive network effects by extending the user base before adding new technologyBuild and align incentives to motivate users (e.g. support communities)Ensure that the user base has grown to sustain the added cost of development and learning
Adaptability problem	Make the system maximally adaptive and variety generating to avoid technology traps	Make the IT capability as simple as possible	Make the information infrastructure as simple as possible (both technically and socially)Promote overlapping IT capabilities
		Modularize the information infrastructure	Separate the layers of infrastructuresExploit gateways to connect different layersDevelop transition strategies

I draw on these five design principles to analyse how the SUP solution developed from the initial phase into its current status, i.e. used by a majority of hospitals, citizens and GPs in Denmark. The healthcare context differs somewhat from the one presented by Hanseth and Lyytinen,⁹ who apply the design principles in the analysis of the history of the Internet. However, their framework seems to be of particular relevance as it addresses both the bootstrap and the adaptability problem, thereby providing a more comprehensible framework for conceptualizing integrated healthcare information systems (IS) compared with the existing literature. Through the analysis, I highlight and discuss which specific aspects should be taken into consideration when building integrated IS in the context of healthcare. In this way, the design principles help us pinpoint the main lessons learned from the case study.

Research site and methods

My field study builds on a case study approach^20,21 that involves data collection from the Danish SUP project from its initiation in 2000 until 2010. I focus on how the SUP solution expanded to become a large-scale system, providing a majority of hospitals, GPs and citizens across Denmark with the ability to access data from different EPRs and other systems. In particular, I describe the goals and strategies set up for the project, how it was organized and managed, the timeline of the project, the stakeholders involved, the main actions carried out, and its current status. The purpose here is to provide a detailed background description that relates to the project design and execution, emphasizing the consequences and effects.

I focus mainly on the SUP project, but am well aware that another project also related to integrated healthcare was initiated at the same time in Denmark. In 2000, the Danish National Board of Health worked on developing a national EPR standard called the ‘Basic Structure for EPR systems’ (B-EPR model). The aim was to build a common standard that would facilitate information sharing between the different EPR systems used by the Danish healthcare providers. While EPR systems today are widely used both among GPs and hospitals in Denmark, the B-EPR standardization initiative did not succeed; thus, the standard was abandoned in 2006. The main reason for this abandonment was referred to as a project that was too ambitious and did not take into consideration the local practices. While the story of this initiative has been reported elsewhere,¹³ the purpose of this article is to investigate how the small-scale SUP project developed and grew into an integrated model of data-sharing between EPR systems.

I do not aim to uncover the political issues at stake in Denmark at the time of the study. As the SUP and the B-EPR projects could be considered competing initiatives and with diverse (even contrasting) stakeholder interests, I am not interested in nor am I able to give an account of the political issues involved. The purpose here is to analyse the SUP project based on the design principles outlined for healthcare information infrastructures.

Data sources

To investigate and reconstruct the history of the SUP project, I relied on a variety of data sources. Firstly, it was important to understand the healthcare context in Denmark in which the SUP solution was developed; thus, governmental documents,²² such as national digitization strategies and regulations, were gathered. In these documents standardization initiatives and interoperability issues were discussed, as well as which objectives and strategies were proposed. I also looked up information on the Internet describing the SUP solution and its evolution. The MedComⁱ website, in particular, provides more detailed information about the SUP solution and what later became the e-record. Here, I screened status reports regarding plans and initiatives, as well as reports documenting the goals obtained and the challenges encountered. I also read through minutes from meetings where the plans and status of the SUP project were documented.

Secondly, evaluation reports on standardization initiatives in hospitals, especially in the two counties that first started to use the SUP solution, were reviewed. These reports helped in understanding the challenges encountered in practice when testing the SUP solution and the preliminary results achieved.

Thirdly, two people who had been involved in the SUP project were interviewed. The first person was the architect behind the SUP project who had carried out the design and implementation of the solution. This person was interviewed twice. The purpose of the first round was to get information about the specific design of the SUP solution; the second round asked the respondent to verify my case description. The second interviewee was a member of the Danish Electronic Health Record (EHR) Observatory who had followed standardization initiatives in the Danish healthcare sector since 1999. This respondent was able to give an overall evaluation of the SUP project compared with other initiatives that were in play within the Danish healthcare context. The three interviews lasted for an hour each, were tape-recorded and transcribed verbatim. The interview data mainly provided information about the design, development and implementation of the SUP project, as well as verifying the information I had gathered from a variety of written documents.

Fourthly, the long-standing Danish public debate on healthcare and IT-related issues on TV and radio, in newspapers and on the Internet was followed. The public contributions served to give me an understanding of the development of the SUP project, including the organizational and technological challenges, and concerns that were at stake.

Fifthly, I attended conferences, seminars and workshops on healthcare-related issues from 1999 to 2010, giving me good exposure to ongoing debates and discussions.

Data analysis

The research objective guiding my analysis defined appropriate strategies for how to achieve integrated healthcare information systems based on the SUP project. In the first stage, I sought an overview of the extensive written material. In the second stage, I investigated how the SUP project was handled in terms of the stakeholders involved, timeline, actions carried out and prioritizations. In doing so, I was able to re-construct the timeline and add sufficient detail to the description. In the third stage, I performed a detailed write-up of the project.

Case description: The SUP project

The SUP solution

The purpose of the SUP project was to make registered patient data electronically available between hospitals within counties and across county boundaries in Denmark.^23,24 More precisely, the SUP portal sought to make patient data registered in EPR systems, Patient Administrative Systems (PAS) and other systems on currently and previously admitted patients available in other hospitals in the county.

The extracts of patient data are transferred via a nationwide MedCom XML standard to a SUP database/Internet server where an Internet browser makes it possible for healthcare professionals to gain access to view selected patient information and record data by searching on the patient’s civil registry number. Access to the SUP database can be gained through secure Internet access. The process is illustrated in Figure 1.

Figure 1.

The SUP solution²⁵

The solution covers textual information, such as diagnoses, contacts, patient notes, observations, requisitions, test results, medicine prescriptions, procedures, medicine administration and personal information. Nursing notes, clinical forms and imaging information, however, are not included. The SUP standard is presented as a model for communication that allows data extraction for analysis purposes. It can work with any of the systems in use, but is not an actual data integration solution between systems.

Timeline for the SUP project

The initial idea for SUP was sketched in 2000 by a former consultant physician and employee of the Danish National Board of Health. Based on the draft, the project was initiated in collaboration with two Danish counties and three IT vendors. Later, another county joined the project. In 2003, it became part of the organization, MedCom, where the aim was to scale-up the SUP solution. Figure 2 indicates the timeline of the SUP project.

Figure 2.

Timeline of the SUP project²³

The two counties that initiated the use of SUP had made big investments in implementing first generation EPR systems, and they were considered to be leading in this area. To cohere to the ‘Basic Structure for EPR systems’ (i.e. the B-EPR model) developed by the Danish National Board of Health, the hospitals in the two counties would have to phase out their existing EPR systems or upgrade them. The architect behind the SUP solution argued that ‘they were not interested in scrapping all existing systems that did not cohere with the B-EPR standard set up by the National Board of Health. They had already used a lot of money on their existing EPRs. Now, they were interested in relying on what existed and then gradually work towards something in common’. He then began the process of analysing the existing systems to find common types of events that could represent all data in the existing systems. The analysis indicated 18–20 different types representing the common core: ‘Even though there were big differences between the systems, there was a significant common core. Thanks to the Danish health authorities who in the 1970s introduced the National Patient Registry,ⁱⁱ the basic notions about what goes on in healthcare were already defined’.

Together with the three IT vendors, the next step was to set up a technical solution that would represent the different data types. Based on this solution, the exercise was to determine not only how to move data from one system to another but also to assess what the actual need in practice was for moving data: ‘By talking to different stakeholders, we soon realized that the need to move data from one record to another was limited. Rather, the immediate need was to show data to new care providers. The hope was to get a system that could do both (show and move data), but the primary objective was to represent data in a browser’. With this primary objective, the SUP solution was established and the vendors started to build the functional parts of the system. According to the architect, the vendors experienced the SUP solution as ‘a practical solution which could be realized with a limited amount of resources and which would solve a big problem concerning lack of data integration’. Consequently, SUP was characterized as: (i) a practical solution in terms of functionality; (ii) a relatively cheap solution which could be financed by the two counties and the three vendors involved; and (iii) a way to solve the current problem of data sharing between EPR systems.

The two counties financed the SUP standard and the IT vendors were in charge of building the solution. The task in itself was complex, but it turned out that the SUP solution could solve an existing problem; namely, to meet the basic need of providing access to data in electronic record systems to the extent that the systems had been implemented: ‘We developed a system that for a few million DKK (400 000 USD) was implemented and up and running. It was not a ground-breaking solution but a solution which solved a specific task to access data when a patient is transferred from one ward or hospital to another’.

Pilot test and evaluation of the SUP solution

The SUP solution was not imposed on the counties and there were no specific deadlines; rather, it was considered as a solution for those stakeholders who wanted to share and access patient data, for example hospitals that referred patients to other hospitals. When joining the project, the hospital would have to consider how to make the SUP solution fit the system development already decided upon, as the SUP solution would require the hospital to develop some programs that could extract data.

The SUP solution was tested in two pilot hospitals based on a number of evaluation criteria: the accessibility of data; the relevance of the available data; the overview and extraction of data; the level of correspondence of the data represented in SUP to the original data in the EPR system; the usability (easy-to-use) of the SUP solution; the operation and updates of the SUP solution; and the maintenance of security issues.^24,25

The first hospital that participated in the pilot test did not have a paediatric ward and therefore had to transfer some patients to the paediatric department and/or gynaecological/obstetric department at another hospital. These were often emergency transfers, which meant that the paper documents sent with the patient were often incomplete and that test results would have to be forwarded later. With the introduction of the SUP solution, the receiving hospital was able to access data from the EPR system at the original hospital for the transferred patients through the SUP database. The pilot ran for about a month and continued after the pilot phase at the users’ request.²⁷

In the second pilot project, the usefulness of the SUP solution was tested across the county border between two hospitals. The thoracic surgery department at one hospital had a number of patient exchanges with an organ surgery department at one hospital and a medical/coronary department at another hospital. The pilot project ensured that the surgeons at the thoracic surgery department had reading access to patient record systems from the two other hospitals through the SUP database. The hospitals in this pilot project had three different EPR systems from three vendors. In one hospital, the SUP database was updated every night and, in the other, the secretary manually updated the SUP database for patients who were referred or transferred. Apart from this, the project did not require any changes in data registration and only few minor changes in work procedures. Again, the users’ evaluations were positive and use continued after the pilot period at the users’ request.²⁸ Only a few technical issues had to be solved by conducting further analysis.

The technical scope of the EPR systems used for the tests was reduced compared with the specification of the SUP standard, both in terms of functionality (e.g. related to data presentation and personalization, printing functionality) and information content (only 12 out of 19 types of events), and on a technical basis (updating of the SUP database and security measures). Nevertheless, the users in the pilots emphasized that SUP was significant because it ‘makes it possible here and now to have an operational access to viewing and comparing data across the various information systems, including EPR systems, and thus it contributes to a large degree to solving one of the most significant healthcare information problems [in terms of information sharing and data access]’.²⁸ With the exception of smaller technical issues in the assessment report, the evaluation group stated that ‘the data structure appears simple, logical and in accordance with common clinical practice’.²⁷ As the SUP solution was meant to support various types of analyses, the pilots also tested this functionality. In a test, 1300 records were downloaded in less than 2 minutes. This dataset was then imported into an Excel sheet and analysed.²⁷

The EHR Observatory performed an evaluation of SUP in 2003,²⁵ where it was emphasized that this was not really integration, but standardized extraction to a common database. Overall, the evaluation was positive, although criticism was voiced by one of the interviewees: ‘SUP is not an ideal solution…you can always discuss how readable the information in the SUP database is, but it is better than nothing’.

Further development of the SUP solution

The purpose of the pilot tests was to assess the solution before it was developed and extended. Based on the positive outcome in February 2002, the SUP project presented the ‘proof of concept’ that the solution worked. By using an extraction program, it was demonstrated that the three EPR systems could produce data in accordance with the SUP solution.

In 2003, the organization MedCom decided to establish a national SUP project to coordinate various aspects relating to it. The emphasis was on for example, rules for communication of the SUP XML standards, guidelines and regulation for user and security administration, description of access and content administration,²³ as well as coordinating both vendors and buyers with respect to timelines and milestones for price information and commitment. In the spring of 2003, MedCom established a nationwide secure healthcare intranet, where county-wide intra-networks were connected via a virtual private network (VPN) connection to a national hub, ‘the Health DIX’. This meant secure Internet access to data across SUP servers.

The implementation of SUP advanced gradually. During 2003 and 2004 other counties joined the initial pilot counties and all hospitals within one county were now covered by the system. Two other counties were about to join and negotiations started with the remaining counties. By February 2006 more than 1.25 million patient records were uploaded in SUP; this figure increased to 2 million in April 2006, as it was found that it was not only hospitals which could benefit from using SUP. In January 2007, a large number of GPs were given access and, at the same time, citizens in one county could access their patient information in what was called the ‘e-record’. Finally, in December 2008 the Capital Region (Copenhagen) took on SUP/the e-record to give GPs and citizens access to patient records. By April 2009, 4.3 million Danes had an e-record.

The actual degree of usage varied a lot and was low in some places. In four out of five regions the coverage across both GPs and citizens was almost fully established, although some hospitals had still not joined. Another evaluation study conducted by a consultancy house in 201029 confirmed that the SUP/e-record was valuable in hospitals in terms of supporting acute situations by avoiding mistakes and unnecessary repetition of treatments, and reducing the time spent on sending/copying/faxing information to other units.

With the SUP solution, the technical infrastructure for a sector-wide sharing of patient record information was established across Denmark. The conclusion by the member of the EHR Observatory was: ‘SUP is a practical, improvised solution in a situation where you have different systems that cannot communicate. It is not an ideal solution but it is a practical solution if the alternative is that you cannot see the data’. A representative from MedCom described the SUP solution as ‘an impressive project which provides the possibility of exchanging clinical data’.

Analysis

The theory section reviewed the literature on information infrastructure with specific emphasis on design principles. Following the presentation by Hanseth and Lyytinen,⁹ I identified the following overall design principles to address the bootstrapping and adaptability problems: (i) design initially for direct usefulness; (ii) build upon existing installed base; (iii) expand installed base by persuasive tactics to gain momentum; (iv) make the IT capability as simple as possible; and (v) modularize the information infrastructure. In the following sections, I analyse the SUP project based on these principles. In particular, I introduce aspects that need to be taken into consideration in a healthcare context.

Design principle 1: Design initially for direct usefulness

The SUP solution was developed to address an urgent problem of data exchange between EPR systems, PAS and other systems that contained patient information. The SUP project was initiated by the local health actors in two counties: those who wanted to exchange data between existing systems and those who did not want to implement the national B-EPR standard. As the SUP architect argued: ‘They were interested in relying on what existed and then gradually work towards something in common’. As the first adopters, the two counties confronted high risks, and it was therefore important that the solution was simple and easy to learn. Early on, the needs were analysed and the architect realized that the primary need was not to move data between systems but rather to show data. The SUP solution was described as a pragmatic solution in terms of functionality. It was relatively cheap for the counties to implement the solution and it solved the current problem of data-sharing.

The project targeted a small group of stakeholders (two counties) for whom the objective was to show data, first across systems within a county and, later, across counties. Based on the pilot tests, IT capability was created that became an attractor for system growth. The move from the ‘local’ SUP project to that of the MedCom’s SUP project also implied that other counties wished to join the project (see the timeline in Figure 2). The SUP solution was designed to create direct usefulness and it was relatively simple to use and implement. It was important for the architect to emphasize that the SUP solution was not mandatory, but rather an offer to the hospitals in the counties. The solution was designed so that it required relatively low development costs, both in terms of financial and human resources. There was a direct use value which balanced the stakeholders’ costs to a degree that was sufficient for engagement and further investment.

There was no need to persuade the users to implement the SUP solution; rather, they themselves had raised the need for the solution and could see its immediate and direct benefits. It was especially valuable for hospitals in the periphery to implement SUP when referring patients to other hospitals within the county. In this way, there was a direct use value. Scalability, extensions and completeness of the solution could be postponed as it was not of immediate importance for the two counties and the success of the SUP solution that other counties joined.

Design principle 2: Build upon existing installed base

The SUP solution was designed and built upon the existing installed base in a way that did not require the designing and implementation of new support infrastructures. The architect analysed the information models, practices and PAS/EPR systems already in use and retrieved 18–20 events that could be defined as the common core. Because of the National Patient Registry that exists in Denmark, the basic notions of events and terminology were already in place. In this way, gateways to existing service and application infrastructures were built, such as existing IT systems, terminology and communication standards between the systems already in use in the healthcare sector.

The two counties initially involved were not interested in phasing out their existing systems that did not cohere with the B-EPR standard set up by the National Board of Health. They had already spent a lot of money on their first generation EPRs and were now interested in relying on what already existed and would then gradually work towards something in common. Also, other counties realized the possible benefit of the SUP solution and, gradually, positive network externalities were created where counties heard about the initiative and wanted to join. When it became a fact in 2006 that the B-EPR standard for integrating healthcare information systems was abandoned, the SUP solution was the only viable option that existed. The use of the SUP solution then expanded to also include GPs and citizens.

Design principle 3: Expand installed base by persuasive tactics to gain momentum

The pilot tests provided a ‘proof of concept’ that the SUP solution actually worked. By the use of an extraction program, the three EPR systems could produce data in accordance with the SUP solution. This convinced the participants for further adoption within, and across, counties, and it attracted new users. The SUP solution thus expanded gradually and became a standard once it was taken over by MedCom. We see in the timeline how the different counties joined the project over time as it gained momentum. The ambitions were also raised gradually by first allowing hospital providers to access data in the SUP database. Later on, GPs joined the project and, finally, citizens could access their e-record through the SUP Internet server. In this way, it was ‘users before functionality’, and incentives were built and aligned so that heterogeneous groups of users had a real motivation for using the SUP solution.

Hanseth and Lyytinen⁹ propose developing support communities and flexible governance strategies for feedback and learning. In some sense, this feedback and learning were created through the pilot tests. The evaluation reports from the EHR Observatory and MedCom were used as persuasive tactics to convince healthcare providers that this was a valuable solution in which to invest. There was no time pressure or any obligation to implement the SUP solution, which may also have convinced a high number of counties to join the project, as it was deemed to be for their own benefit. Similarly, MedCom had created a positive image in the Danish healthcare sector and had become very successful with other IT initiatives, such as standards for Electronic Data Interchange (EDI).

Design principle 4: Make the IT capability as simple as possible

This design principle relates to the adaptability problem, where the design goal is to make the system maximally adaptive and variety-generating in order to avoid technology traps.⁹ The principle is to make the IT capabilities of the solutions as simple as possible, and to enable growth based on experience and learning.

The design of the SUP solution was made as straight forward as possible from the outset. The solution required an extraction program and a common SUP Internet server. In a presentation at the EHR Observatory’s 2001 meeting, the graphical description of the combined conceptual solution was represented on a single PowerPoint slide.^30,31 It was easy to explain to healthcare professionals how the SUP solution worked and the server overview was good (also see Figure 1).

Similarly, the investments to implement it were low, which motivated several counties to opt for this solution instead of using alternatives. The hospitals involved in the pilot tests wanted to keep the pilot system for further use, despite its few technical flaws. The technical components were organized modularly through loosely coupled layers which could change independently.⁹ Healthcare providers and GPs accessed one part of the SUP database and had their specific requirements, while citizens accessed their specific parts and had their own requirements.

Design principle 5: Modularize the information infrastructure

The infrastructure was decomposed into separate local applications, with transport and service sub-infrastructures. The infrastructures were loosely coupled and gateways were implemented to connect local applications to the SUP Internet server. As was described in the case study, it was within each hospital that local applications were implemented so that the professionals could access the SUP database. In this way, the components were loosely coupled; if one hospital decided upon changing some of its existing systems (e.g. EPRs and PAS), this would not impact the general use of the SUP database. This was important at a time when many Danish hospitals were in the process of implementing or upgrading EPRs and other systems. Consequently, local changes in different parts of the system were possible without changing the entire infrastructure thus ensuring a certain level of flexibility, both in the patterns of current use in each hospital and county, as well as for future changes.

As illustrated in Figure 2, the timeline of the expansion of SUP in Denmark was carefully planned, especially when MedCom took over the project, thereby expanding the SUP solution into the e-record for the benefit of hospitals, GPs and Danish citizens.

Discussion

Summary of findings

The purpose of this study was to address the question of how to design and achieve integrated healthcare information systems. Drawing on the five design principles presented by Hanseth and Lyytinen in my analysis of the SUP project, it is possible to summarize the main patterns presented in Table 2.

Table 2.

Analysis of SUP project based on design principles

Design principles	SUP solution
Design initially for direct usefulness	The overall aim was to solve an immediate problem of information access between EPR systems and other systems containing patient dataTwo counties initiated the SUP project and experienced immediate usefulness
Build upon existing installed base	SUP relied on existing information models, practices and PAS/EPR systems already in useNo need to phase out existing systemsThrough careful analysis, gateways to existing service and application infrastructures were built
Expand installed base by persuasive tactics to gain momentum	The pilot tests provided a ‘proof of concept’ that the SUP solution worked and that the three EPR systems, by the use of an extraction program, could produce data in accordance with the SUP solutionThe pilot tests convinced the participants for further adoption within, and across, countiesMedCom took over the project and GPs and citizens eventually joined
Make the IT capability as simple as possible	The design of SUP was simple (a need for an extraction program and a common SUP Internet server)Investments were low and no county was forced to join the project
Modularize the information infrastructure	The infrastructure was decomposed into separate local application, transport and service sub-infrastructuresLoose couplings between modules existedGateways were built to connect local applications to the SUP Internet server

The SUP solution was designed initially for immediate usefulness. It built upon the existing installed base, offering an immediate and concrete solution to local clinical problems, which helped it gain acceptance. The designer chose a module-based decomposition and produced a working solution to address the interoperability problem. The SUP solution expanded gradually through pilot tests where new user groups were persuaded by its proof of concept. The solution was independent enough to deliver immediate use value when it was implemented; thus, the benefits justified the investments made by the involved actors. The counties that invested in its development gained a reasonable reward for their investments within a relatively short timeframe by solving a perceived problem.

As mentioned, the context in which the design principles were derived by Hanseth and Lyytinen⁹ (i.e. that of the Internet) is different from the healthcare context related to the SUP project. This implies a discussion of the contextual factors that may have had an influence on the success of the SUP solution and that are specific to this domain. Based on the findings, I now outline three main lessons learned that appear to be of importance when achieving integrated information systems in healthcare.

Lesson 1: Build on design principles to ensure flexibility

If we look at the existing literature, the SUP project definitely proved that it relied on flexibility and immediate benefits. It lived up to the requirements of being the ‘work-oriented infrastructure’ presented by Hanseth and Lundberg,¹⁶ expanding in a piecemeal fashion and ensuring direct, local benefits. In particular, it also lived up to the ‘bootstrapping’ suggestion¹⁷ by identifying what was important for the users involved and by motivating them through successful pilot tests.

Possibly, most importantly, SUP reflected the sustainable solution of ‘use and change flexibility’ suggested by Braa et al.³ It supported existing activities and tasks by addressing the immediate needs of, first and foremost, healthcare providers and, later on, GPs and citizens. Technically, the SUP solution was flexible in the sense that it allowed local changes to happen without impacting the whole infrastructure. In accordance with design principle 5, the SUP infrastructure was decomposed into separate local application, transport and service sub-infrastructures. Loose couplings between modules existed and gateways were built to connect local applications to the SUP Internet server. If one hospital or GP decided to change any of its existing systems or procedures, it would not impact the general use of the SUP database in other settings.

These aspects are very important in a healthcare context, as can be seen in existing studies, and this study confirms the importance of use and change flexibility.³ The study also extends these existing findings by integrating the framework by Hanseth and Lyytinen,⁹ and providing concrete design principles on how to ensure this flexibility with respect to design and use. The empirical data presented through the case study provides a detailed and grounded understanding of how flexibility is thought of, used and brought about in practice.

Lesson 2: Expand from the installed base through modular strategies

Hanseth and Aanestad¹⁷ argue that integrated healthcare IS should expand from existing solutions, relate to existing practices and build from simpler areas before moving into more complex ones. Our study shows that the SUP project was successful in the sense that it actually relied on the systems that already existed, i.e. the installed base. The architect of the SUP solution used a considerable amount of time and resources to analyse the content of existing systems to find common types of events that could represent the data types that were already in place. This preliminary work was paramount in order to design the SUP solution as an integration tool. The architect was able to conduct this analysis based on his professional insights into the knowledge domain. My case study emphasizes the importance of analysing and exploiting existing infrastructures, platforms or communication formats (technical or non-technical). It did not require the healthcare stakeholders to implement new EPR systems or to scrap existing first-generation systems. This was vital in a context where the majority of Danish hospitals had already made huge investments in EPR systems and where the key problem to be solved was integration of the existing systems to allow appropriate data-sharing. The SUP solution is still not presently considered to be the most optimal solution, as it does not enable moving data from one system to another. However, it proves to be a pragmatic solution to an existing problem where no current alternative exists. Consequently, we assume that the context in which the SUP solution gained terrain (i.e. that of an immediate need of integration between existing EPRs, PAS and other systems) played an important role in its success. An awareness of such contextual factors is paramount to our understanding of how an integrated healthcare solution succeeds.

While emphasizing the need to build upon and expand from the installed base, Hanseth and Lyytinen⁹ do not explicitly discuss how ideas actually spread in practice. Our case study provides more empirical data for the reader to get a sense of how the SUP solution grew over time and became the standard for integrating healthcare information. However, we provide only a limited understanding of how the organizing vision of this solution was created, legitimized and mobilized for the actors involved, i.e. including politics and other contextual factors that may have pushed the SUP solution to become a success, while the B-EPR failed. I refer to Aanestad and Jensen¹³ for further discussion on this issue.

Lesson 3: Identify healthcare actors and provide immediate benefits to them

Mantzana et al.⁶ argue that the actors involved in an adoption process in healthcare are crucial, which concurs with the argument presented here. They propose a structured method to identify actors and to include the actors’ differing views. Agreeing on this aspect, I wish to emphasize the importance of identifying healthcare actors in order to provide immediate benefits to them. This is not trivial in a context which is highly politicized and complex in nature, and where stakeholders may already have invested a lot of resources and efforts in existing technologies. In the case study, we showed how the SUP project offered an immediate and concrete solution to local clinical problems, thus helping it gain acceptance. The designer, who was an ‘insider’, chose a problem-based decomposition and produced a working solution for one of the interoperability problems. The solution was independent enough to be able to deliver immediate use value when it was implemented; thus, the benefits justified the investments made by the involved actors.

The SUP solution was a standalone, problem-solving component with standardized interfaces. The two counties that invested in its development got a reasonable reward on their investments by solving a perceived problem. Its design allowed an implementation strategy which did not require every potential stakeholder’s participation, investment and commitment up front. This meant that its implementation and adoption could happen in a decoupled and independent manner. As such, the SUP solution provided direct usefulness where its benefits were realizable within a short timeframe, and where the benefits achieved balanced costs and investments to an acceptable degree for each stakeholder. The direct usefulness of the SUP solution was related to its ability to meet a specific need: it facilitated access to information about patients transferred between hospitals. The solution, centred on a perceived problem, offered a solution to this problem, which motivated the participants sufficiently to realize the solution.

The healthcare sector has many different stakeholders with different needs, convictions and agendas. Mobilization of actors is challenging when building integrated infrastructures in a context where the healthcare system is predominantly governed by comprehensive legislation and annual budgetary allocations.^32,33 The design principles do not take into consideration such contextual and institutional factors. In such a setting, there is a need to address the potential incongruity between multiple/divergent interests, needs and rationalities.³⁴ Consequently, stakeholder mobilization has an inherent political component which needs to be taken into consideration. From this viewpoint, building integrated information systems in healthcare is far from the outcome of rational calculations on whether to adopt it or not. Although the case study shows only a few examples of diverging viewpoints, interests and needs, it is important to take these aspects into consideration, as they may impede or challenge the development of an integrated healthcare infrastructure. I argue that more interviews with key stakeholders are needed if we wish to conceptualize about these matters in future research studies.

Conclusion

This article has analysed what led to the small-scale SUP project developing into an integrated model of data retrieval between EPR systems. I examined the design principles that facilitated this project to expand and become a success. The contribution emphasizes design principles for achieving integrated healthcare information systems that move beyond the local context in which the system was initially designed and implemented. In this way, this study empirically supports the design principles developed by Hanseth and Lyytinen. However, I argue that consideration has to be given, in particular, to the contextual factors of the healthcare sector; accordingly, I have come up with three lessons learned that relate to principles of flexibility, expansion from the installed base through modular strategies, and identification of key healthcare actors to provide them with immediate benefits.

Footnotes

Notes

References

Hartswood

Kennedy

Monteiro

Rouncefield

Martin

. Special issue editorial on integrated health records: practice and technology. Health Informatics J 2008; 14: 75–77.

Mäenpää

Suominen

Asikainen

Maass

Rostila

. The outcomes of regional healthcare information systems in health care: A review of the research literature. Int J Med Inform 2009; 78: 757–771.

Braa

Hanseth

Heywood

Mohammed

Shaw

. Developing health information systems in developing countries: the flexible standards strategy. MIS Quarterly 2007; 31: 1–22.

Ellingsen

Monteiro

. The organizing vision of integrated health information systems. Health Informatics J 2008; 14: 223–236.

Spyrou

Bamidis

Chouvarda

Gogou

Tryfon

Maglaveras

. Healthcare information standards: comparison of the approaches. Health Informatics J 2002; 8: 14–19.

Mantzana

Themistocleous

Irani

Morabito

. Identifying healthcare actors involved in the adoption of information systems. Eur J Inform Syst 2007; 16: 91–102.

Broadbent

Weill

St Clair

. The implications of information technology infrastructure for business process redesign. MIS Quarterly 1999; 23: 159–182.

Browns

Rotherham

Paisley

. Factors associated with success in the implementation of information management and technology in the NHS. Health Informatics J 1999; 5: 136–145.

Hanseth

Lyytinen

. Design theory for dynamic complexity in information infrastructures: the case of building internet. J Inform Technol 2010; 28: 1–19.

10.

Monteiro

Hanseth

. Social shaping of information infrastructure: on being specific about the technology. In: Orlikowski

Walsham

Jones

DeGross

(eds) Information Technology and Changes in Organizational Work. London: Chapman & Hall, 1995, pp. 325–343.

11.

Monteiro

. Scaling information infrastructure: the case of the next generation IP in Internet. Inform Soc 1998; 14: 229–245.

12.

Star

Ruhleder

. Steps toward an ecology of infrastructure: design and access for large information spaces. Inform Syst Res 1996; 7: 111–133.

13.

Aanestad

Jensen

. Building nation-wide information infrastructures in healthcare through modular implementation strategies. J Strat Inform Syst 2011; 20: 161–176.

14.

Martin

Mariani

Rouncefield

. Managing integration work in an NHS electronic patient record (EPR) project. Health Informatics J 2007; 13: 47–56.

15.

Hanseth

Monteiro

Hatling

. Developing Information Infrastructure: The Tension between Standardization and Flexibility. Sci Technol Hum Value 1996; 21: 407–426.

16.

Hanseth

Lundberg

. Designing work oriented infrastructures. Comput Supp Cooperative Work 2001; 10: 347–372.

17.

Hanseth

Aanestad

. Design as bootstrapping. On the evolution of ICT network in healthcare. Method Inform Med 2003; 42; 385–391.

18.

Jensen

Aanestad

. National initiatives to build healthcare information infrastructures. The 5th Mediterranean Conference of Information Systems, Tel Aviv, September 2010.

19.

Ciborra

and Associates. From Control to Drift: The Dynamics of Corporate Information Infrastructures. Oxford: Oxford University Press, 2000.

20.

Yin

. Case Study Research: Design and Methods. Beverly Hills: Sage Publications, 1994.

21.

Walsham

. Doing Interpretive Research. Eur J Inform Syst 2006; 15: 320–330.

22.

Oates

. Researching Information Systems and Computing. 2nd edn. London: Sage, 2006.

23.

MedCom. MedCom IV. Status, Plans and Projects. Report. The Danish Healthcare Data Network; December 2003.

24.

MedCom. MedCom IV – How it Turned Out. Report. The Danish Healthcare Data Network; December 2005.

25.

Andersen

Bernstein

Bruun-Rasmussen

Nøhr

Vingtoft

. Vurdering af MedCom’s SUP projekt. Report. EPJ-Observatoriet; January 2003.

26.

Lidegaard

Vestergaard

Hammerum

. Quality monitoring based on data from the Danish National Patient Registry. Ugeskrift for Læger 2009; 171: 412–415.

27.

SUP Evaluation Report. Evaluering af SUP-pilot projektet på Horsens og Kolding Sygehuse 27-09-2002 Udarbejdet for SUP-Styregruppen, 2002 [Evaluation of the SUP pilot project at Horsens and Kolding hospitals. Drafted for the SUP Board group].

28.

SUP Evaluation Report. Evaluering afd et tværamtslige SUP-pilot projekt 21-01-2003 Udarbejdet for SUP-Styregruppen, 2003 [Evaluation of the cross-county SUP pilot project. Drafted for the SUP Board group].

29.

Deloitte Business Consulting. Gevinstpotentialer. Udbredelse af e-journal [Gain potentials. The diffusion of the e-record] Evaluation Report, MedCom 7-Projekter 5 May 2010.

30.

Olsen

. Fællesprojekt for EPJ integration i Vejle ogViborg Amter [Joint project for EPR integration in Vejle and Viborg counties] Presentation at the EHR Observatory’s conference 27 September 2001.

31.

Olsen

. Analyse af GEPJ [Analysis of B-EPR] PSO Sundhedsinformatik, 2004.

32.

Jensen

Kjærgaard

Svejvig

. Two perspectives on IS adaptation: using institutional theory with sense making. J Inform Technol 2009; 24; 343–353.

33.

Monteiro

. Scaling information infrastructure: the case of the next generation IP in Internet. Inform Soc 1998; 14: 229–245.

34.

Chilundo

Aanestad

. Negotiating multiple rationales in the process of integrating the information systems of disease-specific health programmes. Electronic J Inform Syst Develop Countr 2004; 20: 1–28.