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
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. 15 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, 9 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 9 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. 3 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, 16 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. 5 In line with this, Hanseth and Aanestad 17 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’. 17 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.
9
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,
17
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.
14
Initially, the user community is small, which prevents the infrastructure from offering its expected benefits. In order to address the ‘bootstrap problem’,
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
Table 1 presents the two design challenges and the five principles that address them.
Design challenges and principles (inspired by Hanseth and Lyytinen 9 )
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, 9 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 approach20,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, 13 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, 22 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 i 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.
The SUP solution 25
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.
Timeline of the SUP project 23
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, ii 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. 27
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. 28 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]’. 28 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’. 27 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. 27
The EHR Observatory performed an evaluation of SUP in 2003, 25 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, 23 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, 9 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
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 9 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. 9 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. 9 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.
Analysis of SUP project based on design principles
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 9 (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, 16 expanding in a piecemeal fashion and ensuring direct, local benefits. In particular, it also lived up to the ‘bootstrapping’ suggestion 17 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. 3 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. 3 The study also extends these existing findings by integrating the framework by Hanseth and Lyytinen, 9 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 17 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 9 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 13 for further discussion on this issue.
Lesson 3: Identify healthcare actors and provide immediate benefits to them
Mantzana et al. 6 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. 34 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.