Keywords

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

1 Introduction

Several ePrescription initiatives were taken in Norway, the first in the early nineties. All failed, but, finally, an ePresecription II was built and widely adopted in the health care sector from 2011 onwards. There is a broad consensus that this solution and the initiativeFootnote 1 behind it has been a great success. However, this success came after a long and painful “birth.” The successful solution was developed with a strong focus on the involvement of GPs in the prescribing process even though the scope was intended to cover the whole chain. Later the solution was modified and extended in a number of ways: hospitals, support of multi-dose dispensing, becoming used as a crucial service for the national summary care record solution, and, hopefully, support for the rest of the primary care sector (i.e. midwives, public health nurses, home nurses, nursing homes as well as dentists).

The installed base, and the approaches for copingFootnote 2 with it, played a major role in the initiative, and was a key source of the challenges the initiative was struggling with up to 2011. During 2011 they changed their approach to coping with the installed base. This change was an unintended result of an ad-hoc solution, a “quick fix,” to a problem that had become urgent – the delayed development of a new EPR system by the vendor of such solutions having the largest market share. This change in the approach to coping with the installed base turned out to be a major contribution to the success of the solution – first the development of a solution that could be adopted by larger user groups and later the development of required of functionalities supporting multi dose dispensing and a major revision of all the involved.

All initiatives, also the latest one, has been based on the EDI paradigm with a strong focus on information sharing through message exchange between applications where the messages are specified and approved as standards and then implemented in the solutions. This approach is based on a classical specification driven approach to software development that implicit assumes that the new solution will be of a stand-alone kind developed from scratch. This contributed to make the initiative’s approach to coping with the installed base schizophrenic: one the one hand the solution was designed as just extensions of existing applications like EPR systems and pharmacy applications (in addition to a central server and a secure network), on the other hand, it did not take seriously into account any challenges related to integrating the additional functionality to the existing installed base. This is true both for the existing applications and the platforms (PC hardware, operating system, network technologies, etc.) the applications were running on.

Methods

Our research approach was a case study conducted in the Norwegian health sector during a period of 7 years, from 2008 to 2015. Data collection included interviews with central stakeholders in the Ministry of Health, the Directorate of Health (who managed the project), and project developers and vendors, some of them several times during the study. In addition, we had access to the written materials of the project. This included the Government Budget documents, the project management documents, the system specifications and IT architecture documents.

Data analysis was conducted in the following steps. First a temporal analysis was done, focusing on the development over time. The identification of key events was done through interviews with central stakeholders and by a systematic analysis of the annual budgets of the Ministry of Health. Then a comprehensive analysis was conducted on the interplay of actors in the long project, such as government authorities, vendors, and users. Finally, we assessed and validated our findings by on-going presentations and discussions with key actors.

2 The Norwegian Health Care Sector

The Norwegian health care sector is primarily publicly funded. Until 2003 (most of) the hospitals were owned and managed by the 19 counties. By January 1st 2003 a reform was implemented. This implied that the government was taking over the ownership of the hospitals and organized them in 5, later four, regional corporations called Regional Health Authorities.

The primary care sector is managed at the municipal level. There are in total 428 municipalities in Norway – of these Oslo is the largest with app. 659,000 citizens and Utsira the smallest with only 203 citizens. GPs are either employed by municipalities or operating a private medical practice. These two groups are roughly of the same size.

Until March 1st 2001 the pharmacy sector was strictly regulated. Only pharmacists were allowed to own and run pharmacies and each pharmacist was allowed to own only one pharmacy. During 2001 the sector was liberalized and within a fairly short period more or less all pharmacies were taken over by large pharmacy groups, five in total, like for instance Boots.

3 Case Narrative

3.1 Establishment and Diffusion of a Solution for GPs

The ePrescription initiative starting 2004 was the most ambitious, well-funded, and professionally managed one among the efforts aiming at developing IIs for information exchange across institutional borders in the healthcare sector in Norway. Table 6.1 provides an overview of the timeline for the initiative.

Table 6.1 Timeline for the Norwegian e-prescription initiative
Full size table

In 2004, the Ministry of Health initiated a pilot study on electronic prescriptions. The background was a report in 2001 from the Office of the Auditor General that raised concerns on the accountability of prescription refunds from the Welfare Administration Agency. The following actors were included in the pilot study: the Norwegian Pharmacist’s Union, National Insurance Administration (NIA), Norwegian Medical Association (representing physicians) and Norwegian Medicines Agency (NMA). The Directorate of Health managed the project.

The ePrescription project was established with direct funding of 40 million Euros from the Norwegian Parliament during 2005–2010. By the end of 2010 around 70 million Euros was spent on the project. During 2006 detailed requirements specifications and an architectural document was written, specifying an ambitious, fully integrated solution. Figure 6.1 illustrates the architecture of the II as it is presented in official project documents. The boxes represent the central data base server in the middle and applications (eight different EPR systems from six vendors used by hospitals and GPs, one pharmacy system used by all pharmacies, the MyPrescription module gives patients access to their prescriptions, and various applications run in three different government institutions). The blue arrows represent 31 different (standardized) messages carrying information between the applications. It illustrates well the basic assumption of the EDI paradigm and ACA: information exchange is taken care of by enhancing existing applications.

Fig. 6.1
figure 1

The ePrescription solution: main components

Full size image

The requirements specification of The Directorate of Health emphasized that the vendors and public agencies involved were responsible for their modules. The programme was organized in five projects. The six main EPR vendors were invited into one of the projects in 2006. Of the three suppliers of EPR systems for hospitals two were too busy to participate. In addition the suppliers of the hospital EPRs demanded a more specific requirement specification before they were willing to start development activities. Eventually, only the biggest vendor within the GP market, Profdoc,Footnote 3 agreed to develop a pilot version of electronic prescription. At this time Profdoc had two different EPR systems in the market and they had started to develop a new version that should replace both. They decided to develop an ePrescription module only for the new version. The ePrescription programme management accepted this. Later the two other vendors of patient record systems for GPs, Infodoc and Hove, also joined the initiative.

In May 2008 the first pilot implementation was inaugurated by the Minister of Health. It was carried out in a small town in the eastern part of Norway, and included the GPs and the local pharmacy. It turned out to be a disaster, and after 4 months a crisis was declared. Said the municipal health manager to the local newspaper; “the system is so slow, and has so many errors and deficiencies, that we will stop the whole pilot”. The local authorities also raised concerns about patient safety. The main reason for the problems was not the ePrescription solution per se, but that the new version of Profdoc’s new EPR system was full of errors and was very unstable. Somewhat unreasonably, the ePrescription project got the blame in an angry press.

The ePrescription Exchange was tested and accepted during 2009, while waiting for the vendors to complete and test their new versions. A new pilot was planned in March 2010, and contracts for large-scale operations were signed. The pilot testing started in Os municipality in Western Norway in June 2010, including two GP offices and one pharmacy. A second pilot started in Larvik in September 2010 including two pharmacies and a handful of GP offices. All GP offices in the pilots were using EPR systems from the same vendor, Infodoc (having app. 25% of the GP market for EPR systems). Infodoc’s solution was the only one being ready for pilots at that time.

Infodoc integrated their patient record solution with the ePrescription II by developing a brand new version of their existing medication module. This new module included the functionality of the old plus those specified as part of the ePrescription programme. It was based on the same logic and user interface as the old one.

At the time the Os pilot was about to start it was uncertain when new EPR system from Profdoc would be ready. Actually, the new owners of Profdoc (CompuGroup Medical) was so unhappy about the progress (or rather lack of) of the development of the new product that they informed that management of the ePrescription initiative that they were considering abandoning the whole project. Profdoc had at that time about 70% of the GP market for patient record solutions. Accordingly, having a solution for Profdoc users was absolutely necessary for the ePrescription initiative to succeed. So the programme management decided to develop a separate prescribing module with the functionality needed by GPs that could be used in combination with the two Profdoc solutions in use. This module, which later was given the name GPM, was running in parallel with, and only loosely integrated with, the EPR systems. That means that the users were filling in prescriptions using this module and all information exchange with other components of the ePrescription II was taken care of by this module and not the ERP systems. (This is explained in more detail below.)

The module was developed during the second half of 2010. The development costs were modest; around five MNOK. Users in lab settings tested the module during the first half of 2011, and real use testing and deployment started in the second half of 2011. Overall the tests were found to have a positive outcome. There were, however, challenges related to the fact that the GPM module was developed to run on later versions of available PC (Wintel) platforms while Profdoc’s existing EPR systems were to a large extent running on old, some very old, ones.

All pharmacies in Norway were using the FarmaPro solution developed by NAF-Data;Footnote 4 NAF-Data started the development of a new version (v 5.0) of their solution in 2005 and planned, just like Profdoc, to implement the ePrescription module for pharmacies only as a part of the new solution. This solution should have been ready for deployment by 2008, but was delayed. In June 2011 it was still uncertain when the solution would be ready for full-scale deployment. At a meeting with the Minister of Health, the Minister made it clear that this uncertainty was beyond what she could accept. For this reason, and based on the positive experience with the GPM module, the management of the initiative decided to adapt this to the needs for users at pharmacies. This decision was, however, reversed. The initiative’ management decided instead to put more pressure on NAF-Data so that they speeded up their development work. And so they did.

The evaluation of pilots concluded that they were successful - in particular user satisfaction was found to be high (PWC 2011). But some new challenges emerged. For instance, the evaluation also concluded that more or less all GPs needed to upgrade their ICT infrastructure – PCs, network bandwidth, and even printers – to be able to run the solution (ibid.). This again raised issues about who was to pay for this.

During 2011 Hove completed the extension of their medication module with the required functionality and its diffusion started. The same happened with the generic GPM module that was combined with Profdoc’s two existing EPR systems. During 2012 Profdoc’s new EPR, later called CGM Journal, was ready for deployment together with an integrated ePrescription/medication module. From early 2011 the ePrescription solution has been deployed at GP offices and pharmacies at a steady speed. By early march 2012 the solution is deployed to about 280 GP offices and 134 pharmacies in 67 (of 428) municipalities distributed over 4 (of 19) counties. More than 1 mill prescriptions were sent. According to the plan the solution would be deployed to GPs and pharmacies in all municipalities by the end of 2013. By February 2013 1.200 GP offices were up and running using the GPM module while around 200 GPs using the new CGM journal solution. During the spring 2014 500–600 CGM customers had converted to the new CGM journal while Hove and Infodoc were taking over about 200 CGM customers during 2014.

The development of the GMP module for GPs, and the adaptation of this to hospitals, represented a change in the project’s approach for how to cope with the installed base, and it was an ad-hoc modification of the architecture to speed up the development. This architectural change did indeed speed up the development activities by decoupling the solution from the ERP systems and their vendors’ other development activities. These modules are seen as temporary solutions that will be used only until the “final” solutions are available. Whether they will be in use only temporarily or permanently remains to be seen.

3.2 The Hospital Sector

The primary healthcare system (the GP level, administrated by municipalities) issues 70% of the prescriptions; the rest is issued by hospitals. These are organized in four health regions, as separate state companies. In the autumn 2009 it became clear that the IT managers in the health regions had made very little preparations for integrating hospital EPRs (which are different from the GPs) with the ePrescription solution. Moreover, they raised comprehensive objections to the architecture of the solution. During some heated meetings in the winter 2009–2010 some kind of compromise was reached: the health regions would follow their own framework for integrating various old and new systems, while making an effort to implement a short-term solution for ePrescription. The South-East Health Region decided to postpone the integration of ePrescription until their preferred permanent solution was ready. This meant integrating the ePrescription solution with their regional chart and medication solution which has been under development for quite a few years and which was not expected to be ready until 2014–2016 (Nasjonal IKT 2009). The western region, however, was keener on adopting the ePrescription solution. Being informed about the existence and positive evaluation of the GPM module, the head of ICT in the western region asked the Health Directorate if they could get access to the module’s software and adapt it to fit their needs, which the programme management gladly accepted. The western region started, then, in the second half of 2012 a project adapting the GPM module to the needs of users in outpatient clinics and hospital pharmacies and to run in combination with the Dips EPR system. Adapting the module was quite straightforward and pilot testing was successful. The main challenges involved were related to the security solution, modification of the GPM module and integration with Dips, and changes to the underlying communication platform. The security solution requires all physicians to sign the prescriptions they produce with an id card. For this reason they had to buy and install hardware that could read the cards and procedures for distribution of such id cards. The GPM module had to be modified a bit and extended with some additional functionality to satisfy the needs of prescription procedures in hospitals. This was primarily related to the prescribing of magistralFootnote 5 drugs. The GPM module was integrated with Dips in the following way: Dips has a menu where programs that can be started from Dips are listed. The GPM module was added to this menu. In addition, Dips transferred the patient id to GPM. Further, Dips added an API to its system that the GPM module could use to get access to information about the patient that may be important when deciding which drugs to prescribe. The prescription is not stored in Dips, but can be retrieved from the Prescription Exchange when needed. However, relevant information from the prescription can by copied from the prescription and pasted into a document that is added to the patient record. In addition, they also had to do some modifications in their communication platform used for the exchange of other kinds of messages (like lab orders and reports and admission and discharge letters). Finally, the version of the PharmaPro solutions used by hospital pharmacies had to be modified.

Deployment of the solution at the largest hospital in the region, Haukeland Hospital in Bergen, started at the beginning of January 2013 and fully implemented at all hospitals in the region by June 2014. Overall, ePrescription has been a great success in the western region. The costs related to the adaptation and integration of the generic module were modest, the deployment process smooth, and the users are very happy with the solution.

The western region’s decision to implement ePrescription based on the generic module was taken against the recommendation of the Dips company. Dips started during spring 2012 a more ambitious project where ePrescription functionality will be an integrated part of their new module for handling of medication within hospitals which will be an integrated part of their EPR system. They argued that it would be better for the region to wait until this tightly integrated module was ready. The western region said they would continuously consider if they should switch to this alternative solution. So far, i.e. by late September 2015, they are very happy with the existing solution, but they plan to have a discussion about whether they should switch “soon.”

Dips’ integrated module was tested out in a pilot at UNN that started in 2014. The further adoption of this solution in the northern region has been very slow. However, it was successful implemented in one of the largest hospitals (called AHUS) in the South-Eastern Region during the first half of 2015. This solution will be adopted by the other hospitals in this region during 2015 and early 2016.

The hospitals in the Middle Region of Norway were using a patient record system developed by Siemens. The management of the region has announced that this solution will be replaced with a different one within the next few years. For this reason the regional management and Siemens have agreed to implement a simplest possible solution (i.e. minimal integration between the EPR system and the module) based on the GPM module. This solution was implemented in a pilot at three hospitals early in September 2015 and was planned to be scaled to the rest of the region later during 2015.

3.3 Adding Multi-dose Dispensing

Multi-dose drug dispensing (MDDD) is a service by which patients receive their medication packaged in bags with one unit for each dose occasion. The packaging is taken care of by machines. This service is intended for patients (mostly elderly) suffering from chronic illnesses for which they need to take several drugs throughout the day on (more or less) permanent basis. (There are about 70.000 such patients in Norway.) The traditional way of dealing with this is by means of a card (called ordinations card) filled in and signed by the patient’s GP. A signed card is usually valid for 1 year. The card is taken care of by the patient herself or institutions responsible for the patients’ home care or a nursing home. It is used as a prescription when the patient is buying drugs in a pharmacy. In addition, most patients are using a cassette containing the pills to be taken during 1 week. This cassette has one column for each day (seven in total) and one row for each time of the day a patient may take drugs (i.e. morning, noon, afternoon, evening). Such a cassette is then filled once a week either by the patient herself or a family member, but mostly by a home nurse or a nurse working in a nursing home. These processes are considered to contain two weaknesses which multi-dose (i.e. machine packaging) and e-prescribing solutions as expected to solve (at least partially). The first is that drugs may be mixed, for instance when the various pills are distributed across the cassette. Secondly, a patient may visit and receive prescriptions from more than one GP and she may be hospitalized for some reason and then being sent home with a number of drugs prescribed for a period. This may case various medication errors. The first of these problems are supposed to be solved by the multi-dose packaging machine and the second by the so-called drugs-in-use functionality in the ePrescription solution. The drugs-in-use functionality means that all (“active”) prescriptions of one patient are compiled into one list. In addition, the GP of a patient taking drugs on permanent basis is given the responsibility of being the “editor” of the patient’s drug-in-use list. That means that if a patient is admitted from hospital with some new prescriptions, the prescriptions are sent to the central database, the drug-in-use list is updated and sent to the GP. The GP then has to take action if necessary. Normally a multi-dose package contains drugs for 2 weeks. That means that in the electronic solution, a patient’s drug-in-use list is sent to the Information System controlling the packaging machine every second week.

In Norway all pharmacies belong to one of the five chains (Boots, Apotek1 Vitus, Ditt apotek or Apotekergruppen). Each of these has one multi-dose machine serving all their pharmacies. The pharmacies started offering multi-dose packaged drugs about 10 years ago (2005).

Implementing support for multi-dose in the ePrescription solution started in August 2012. Specifications were worked out by a project group including the multi-dose project group in the Health Directorate and representatives for GPs and pharmacists. The first version of the specifications was approved by the Change Council (see below) 1 year later. These included modifications in the PrescriptionExchange (PE) module to generate and store the drug-in-use object and functionality for exchange of the new drug-in-use message between the PrescriptionExchange and the EPRs, FarmaPro, and the systems controlling the multi-dose packaging.

The EPR vendors were all hesitant in getting involved in this project, so the implementation started by adding the required functionality to the GPM module in addition to the Prescription Exchange and PharmaPro. The project managed to bring one of the chains of pharmacies, Apotek1, involved early on. A rather small team of actors, those responsible for GPM, PE, FarmaPro and Apotek1’s system, then, succeeded in developing first a prototype and then through a few iterations a well working solution.

Apotek1 has a proprietary solution controlling the packaging machine, so coordination with Apotek1 about the required changes to their system has been rather smooth. Boots was enrolled into the project after the first version of the solution had stabilized. However, they have a system delivered by Visma, which is also delivered to other customers. Compared to Apotek1 this case involved a larger number of actors that had to reach agreement about how to implement the required functionality and the coordination of the implementation has been more demanding. Currently the Boots solution is in test. It was assumed to be approved before Christmas 2015.

Piloting multi-dose (based on version 2.4 of the standardized ePrescription messages) started in Jevnaker municipality in Eastern Norway in May 2014. They started with a small and controlled pilot with a limited number of actors and then gradually scaling up by including municipalities with a larger number of GPs and pharmacies from the autumn 2014. From September to November 2014 about 60 GPs in the municipalities Sandnes, Klepp, Time and Gjesdal were included in the pilot.

Among the EPR vendors Hove was the first to start implementing multi-dose functionality in their System X EPR system. Currently (September 2015) their solution are in “integration test.” Infodoc plans to be ready for a pilot during 2016 while it is still unclear when CGM will adapt their solution (CGM Journal) using the integrated module for prescribing. When the other suppliers of multi-dose dispensing (Vitus, Ditt apotek and Apotekergruppen) will integrate their solutions with ePrescription is still unclear. So at the moment (September 2015) only municipalities using Apotek1 as multi-dose dispenser and GPs using Profdoc’s old EPRs combined with the generic GPM module can participate in the pilots.

The pilots have been evaluated by two master students as their master thesis project (Ertesvåg and Tselischeva 2014). They found that overall the users very satisfied with the solution, however, desirable improvements of the solution were identified.

3.4 Other Developments

In addition to the changes to the ePrescription II mentioned above, a number of smaller changes have been made after the large scale rollout started. This includes a more or less continuous process of making the solution more robust. A number of smaller changes have also been made because of changes in regulations of the prescribing of drugs. This includes changes in the regulation of patient reimbursement for drugs and procedures for how to apply for individual patients to get reimbursed for specific drugs.

One important change is the definition of few new messages and functions that integrate ePrescription with the more recent national Summary Care Record II. These two IIs are integrated in the sense that all data from the PE are also copied to a similar service of the Summary Care Record (SCR) II. So every night all updates of the PE during the last 24 h are copied to the SCR data base. The reason for this copying is that the two IIs are under different jurisdictions. The ePrescription II are only allowed to store prescriptions as long as they are valid (or “active”) while the SCR II stores this information for 3 years.

Some work has also started to adapt the II to new user group. Most important among these are employees of the elderly care sector like home nurses and nurses working in nursing homes. Unfortunately, the regulations established for the ePrescription deny nurses access to the II. However, they are allowed to access the SCR II which also includes the same information about prescriptions. Public health nurses in municipal service and midwives have some rights to prescribe some drugs (for instance contraceptives) and they are planned to be given access to ePrescription. Further, work is going on to provide ePrescription to dentists. Giving these user groups access to ePrescription requires the vendors of the applications they using to be modified for this purpose. Most vendors seem to plan to integrate their solutions to the II by means of the GP module. Visma has already started adapting their Profil solution and will start running a pilot later in 2015.

During 2012 activities started aiming at a major revision of the II with a focus on specifying new version of the standardized messages. The overall scope of the activities was approved in February 2013. This activity is defined as the specification of version 2.5 of the messages. This new version will include modifications representing a huge range of smaller and bigger modification of the functionality of the II based on practical use of the II, corrections of errors discovered, and modifications triggered by regulatory changes. The new version of the message standards are first implemented in the PE and GP modules. PE was scheduled for being able to send and receive version 2.5 messages by October 10 2105. It is not clear when other modules will be modified.

3.5 Operations and Governance

When the full-scale rollout started an operational model and governance structure was established. First of all, the only way of getting access to the II was through connection to the National Heath Network. The PE service was operated by the data center Evry. In the Health Directorate a permanent organization was established for coordinating the maintenance and further development of the II. They also established a governance structure. The main elements of this structure are the Change Council and the Change Forum. The latter were constituted by representatives of the “operational resources” from all actors, i.e. representatives of vendors etc. The Change Council includes representatives from user groups and health care authorities.

4 Concluding Discussion: Installed Base Strategy

The ePresecription II was built and widely adopted in the health care sector. There is a broad consensus that the solution and the initiative behind it has been a great success.Footnote 6 However, this success came after a long and painful “birth.” The first running pilot was operational about 6 years after the initiative started and having spent about 500 million Norwegian kroner (about 55 million Euros) of funding from the Norwegian government. In addition, the vendors involved allocated substantial resources to the initiative not covered by the grant from the government.

The solution being piloted and subsequently adopted was developed with a strong focus on the ordinary prescribing practices of GPs and similar dispensing practices of pharmacies, i.e. the production of a prescription for an individual patient during the patient’s visit and the dispensing of the prescribed drug when the patient visits the pharmacy. Later, the solution was successfully extended with required functionality to support a broader range of practices related to prescribing, dispensing and consumption of drugs, i.e. prescribing in hospitals, support of multi-dose dispensing, becoming a platform for the national summary care record solution, and, hopefully, support for the rest of the primary care sector (i.e. midwives, public health nurses, home nurses, physicians working in nursing homes, and dentists).

We see the approach to coping with the installed base followed by the initiative as a key source of the challenges it was struggling with up until the successful pilots started in 2010 as well the later successful diffusion and extensions of the overall solution (or II). Initially the ePrescription initiative was based on the dominant EDI paradigm with a strong focus on information sharing through message exchange between applications. According to this approach the messages are specified and approved as standards and then implemented in the solutions. This EDI paradigm is based on a classical specification driven approach to software development that implicit assumes that the new solution will be of a stand-alone kind developed from scratch. This contributed to make the initiative’s approach to coping with the installed base a bit schizophrenic: One the one hand the initial design was drawing extensively upon the existing installed base as the overall solution, or II, was designed as just extensions of existing applications like EPR systems and pharmacy applications (in addition to a central server and a secure network). On the other hand, the design did not take seriously into account any challenges related to integrating the additional functionality to the existing installed base. This is true both for the existing applications as well as the platforms (PC hardware, operating system, network technologies, etc.) the applications were running on. This strategy turned out to be problematic for a number of reasons:

  • The number of independent actors (vendors, authorities, health care institutions, professional associations representing various user groups) involved;

  • The complexity of and amount of work needed to modify all applications according to the specifications;

  • A huge number of users are running ole software running on old computing platforms (PC hardware, operating system, networking technology, printer, etc.) which they might have to upgrade (i.e. replace);

  • The level of details the actors had to reach agreement about;

  • The degree of coordination of all activities; etc.

The struggles the initiative was fighting until 2010 clearly illustrates this. Up to that point, Profdoc was the only vendor seriously working on the development of a module supporting GPs’ practices. However, due to the complexity of this module they decided to develop the module only as a part of their new product. And when the development of that product was delayed, the whole ePrescription initiative was stalled. Other vendors and the hospital sector were too busy with other, and for them more urgent, tasks to be seriously involved in the ePrescription initiative. The ePrescription strategy presumed that all stakeholders involved or affected (vendors, GPs, municipalities, government agencies, etc.) had the capacity and willingness to do exactly what they were assumed to – and in a coordinated manner. These assumptions were proven not to be valid.

A key factor leading to the end of failure stories and the “birth” of the successful solution was a change in approach for how to relate to and deal with the installed base. The GPM module represented this change in “installed base approach”. The generic prescription module, GPM, embeds a different strategy for relating to the installed base. It draws equally much on the installed base as a resource, but it is much more loosely coupled to this, and accordingly demands much less modification of the installed base, and accordingly resources to be spent by vendors as well as on coordination among independent actors. Furthermore, this module could be developed by the Health Directorate without the involvement of Profdoc or any other vendor.

The GPM module turned out to have a positive impact on the establishment and evolution of the ePrescription II far beyond Profdoc users. The module was, next, used by the ICT unit of the hospitals in the western region, meaning they could adopt and use ePrescription without waiting for Dips to develop an integrated module. Then the middle region did the same. In this case Siemens did not want to develop a module on their own because they were informed that their product would be replaced with another within a few years. Finally, the module is planned to be used by vendors of patient record systems for home nurses, public health nurses and nursing homes. The generic GPM module has also play a crucial role in the prototyping and piloting of support for multi-dose dispensing and version 2.5 of the messages. The module gave the project group in the Health Directorate opportunities for developing support for multi-dose dispensing through an experimental and evolutionary approach together with users without involving vendors and without being dependent on their engagement from the very beginning. The GPM module then also allows the users to adopt this service before the vendors make changes in the EPR solutions. And the vendors may want to do so until the specifications of a solution that works well have stabilized.

The development of the GPM module was anything but a strategic decision. It was a “quick fix” to an extremely urgent problem. And as such, it did definitively not represent a deliberate change in the initiative’s strategy for how to cope with the installed base. But over time, however, the role that this module could play contributed to a change in the overall development approach. This change happened as those involved discovered the possibilities the module opened up for speeding up the adoption of the II among users of various vendors’ patient record systems. This change of overall approach is most visible in the development (prototyping, piloting) and diffusion of the support for multi-dose dispensing.

The change in architecture and development approach was taking place in parallel, and dependent upon, changes in the organizing and governance structures of the initiative. When the adoption and diffusion of the II were getting momentum, more formal governance structures were established as described above. This happened at the same time as more and more of the development activities were transferred from vendors to the project group in the Health Directorate. We see the combination of these changes (i.e. changes in architecture (flexibility in integration between EPR systems and the prescribing module); development approach (from specification driven to a prototyping/evolutionary approach); and organizing and governance structures) as the key to the (final) success of the Norwegian ePrescription initiative.