INF5890

Alternative approaches to governance How to integrate the need for learning and multi-level stakeholder coordination in governance?

INF5890

What is governance?

INF5890

governance, n. 1. a. The action or manner of governing (see senses of the vb.);

the fact that (a person, etc.) governs. b. Controlling, directing, or regulating influence; control, sway,

mastery. … 3. The manner in which something is governed or regulated;

method of management, system of regulations. In Pecock often: A rule of practice, a discipline. Obs.

4. a. Conduct of life or business; mode of living, behaviour, demeanour. Also pl. proceedings, doings.

b. Discreet or virtuous behaviour; wise self-command. Obs.

INF5890

govern, v. 1. a. trans. To rule with authority, esp. with the authority of a

sovereign; to direct and control the actions and affairs of (a people, a state or its members), whether despotically or constitutionally; to rule or regulate the affairs of (a body of men, corporation); to command the garrison of (a fort).

b. said of the Deity. †c. To be in command of (a force, an army); to lead (a choir).

Obs. d. To direct and control (a person, the members of a household) with the authority of a superior. ? Obs.

… †6. a. To attend to, care for, look after (a person); esp. to tend or

treat in respect to health. Obs. †b. To tend, treat (plants). Obs.

INF5890

What is governance?

• about meta-management (Boynton et al. 1992; Weill 2004); • about ensuring that stakeholder needs, conditions and options

are evaluated to determine balanced, agreed-on objectives (ISACA).

• about attending to “the broader social contexts of creating the conditions for social coordination” (Olson 2007, p. 269).

• about taking a step back (or up) in order to gain a wider perspective on how we do management and whether or not we could or should do it differently. This includes meta-reflections on both management structures and management processes (Skorve 2013).

INF5890

What is implementation?

INF5890

What is implementation?

• To complete, perform, carry into effect (a contract, agreement, etc.); to fulfill (an engagement or promise).

INF5890

Organizational Implementation

• …the activities that prepare organizations and users for a new system as well as the activities that prepare the system for the transition period during which it enters into operation and takes over from previous systems and artefacts.

– Hertzum 2002

INF5890

Healthcare information systems

• Historically often the result of ”hacking doctors” – Highly specialized – Diffused through the “grapevine” – Many (small) systems – Fragmented/not integrated

INF5890

Visions of integration

• Assumptions – Fragmented systems lead to fragmented care – Integrated systems support continuum of care

• Strategy – Cross context information systems for exchange and reuse of data – Universal/large scale systems (“one size fits all”)

INF5890

New challenges

• New solutions must support the information needs related to… – different patients and patient groups – for different professions – working within different disciplines, – executing different functions – to perform different practices.

• Heterogeneity: No one knows the entire territory – Requires learning! But how…?

INF5890

Public reforms in the information age (Heeks and Bhatnagar 1999)

INF5890

The pilot I

• …time-bound limited-scope and limited-participation project to examine characteristics of a new technology, application, or IT-intensive process in a particular context

- Gogan & Rao 2008

INF5890

The pilot II

• First encounter between system and practice • De facto standard • Primary purpose (though often forgotten): Learning • Food for thought: What defines a successful pilot?

INF5890

The pilot III

• Not always obvious where, when and how to start… • Who should learn what how and why? • A question of prioritizing

– Impossible without prior reflections…

INF5890

How does this relate to IT governance?

INF5890

The Electronic Medical Charts (EMC) Project : Background

• Part of “the Digital Hospital” strategy • Replace the paper based medical charts • Strategic project; hospital wide implementation • The right information in the right place at the right

time • Support “continuum of care”

INF5890

The paper charts

INF5890

The charts and the clinic

“We can’t manage for five minutes without the medical charts. Then the patient would be dead – many would die if we didn’t have this information. So this is essential – that it works”.

- ICU nurse

INF5890

MetaVision

INF5890

Timeline (2004-05)

2004 The health ministry announces Te@mwork as the national strategy for healthcare

IT. The EMC project is conceived at Rikshospitalet under the umbrella of ‘the Digital

Hospital’, and a requirements specification is developed. 2005 A pre-qualification round is completed in cooperation with the hospital’s

procurement department. A project manager is appointed in the hospital’s IT department, and a bid for tender

is initiated.

INF5890

Timeline (2006)

2006 June: A contract for MetaVision is signed with its vendor, IMD soft. Considerable efforts are put into installing the physical infrastructure (PCs, wiring,

etc.), configuring MetaVision according to anticipated requirements (defining parameters and designing user interfaces) and training the users. The clinical department is allocated the task of nominating candidates that would receive additional training, and thus function as super users that could provide additional supervision to others in how to use the new system.

December 5th: a pilot is launched in the thorax surgical department. Problems are encountered that threaten to halt the project.

INF5890

Timeline (2007)

2007 January: a new project manager is hired from outside the hospital. Her evaluation of the pilot results in a 22 page experience document. It points to

several problematic issues, including: • Underestimated complexity of organizational conditions • Lack of clear channels for communication, information and distribution of

decisions and responsibilities • Lack of time allocated to the project. Thorax revokes the paper charts. A second hospital – Ullevål – joins the project.

INF5890

Timeline (2007 cont.)

2007 The project is redefined from an implementation to a development project. The time

schedule is renegotiated and the project is restructured: • The ‘standardization project’ is established with the intention to establish a

shared clinical nomenclature for the MetaVision configuration • A clinical council is established • Different work streams are formalized • Decisions are made collaborative, closer to their execution. A ‘war room’ is

established • Focus is moved from Thorax to Anesthesia.

INF5890

Timeline (2008-09)

2008 Te@mwork is replaced by Teamwork 2.0, down-sizing the level of ambitions. The project is busy standardizing. May: Ullevål stops their project due to budget cuts. October: the Regional Health authority signs a framework agreement for MetaVision. November: the decision is made to merge the two hospitals, effective within two

months. 2009 A successful implementation is completed in Anesthesia, and the project moves on to

the Children’s ICU. A manager is hired for the regional project, but his hands are tied due to the hospital

merger and other regional reorganizations. The merger is a fact, and battles over positions in the new organization take off.

Ullevål gets to appoint a new manager for the EMC project. The regional steering group decides that he should lead the regional project as well.

INF5890

Timeline

2010 January: the projects merge under the governance of a single manager. Project activities are stopped in Rikshospitalet. The regional project organization is reworked into a matrix style model, attuned to

clinical needs rather than technological problems. 2011 A regional pilot is conducted in Ullevål’s ICU and Anesthesia. It goes over

schedule, but is still considered a success.

INF5890

The pilot (2006-07)

• Thorax surgical department – Three units (surgery, intensive care/post op and inpatient) – Very motivated for MetaVision – “If we can make it work there we can make it work anywhere”

• All patients in all units from day one – Maximum complexity – “Day one” set according to project plan rather than readiness

INF5890

Problems during the pilot

• Unready system • Bugs • Logical flaws • Disruption of practices

INF5890

Example of logical flaw

Blood pressure is measured in catheters also used to draw blood samples or give intra-venous fluids. As fluids must be infused with a pressure exceeding the patient’s blood pressure, this has a direct effect on blood pressure measurements at the catheter. When manually registering pressures, the nurse would therefore first stop the infusion, then read the value, before starting the infusion again. MetaVision, however, harvested these values continuously, regardless of any external influences. Thus most values recorded in MetaVision were erroneous. Work around: Double book keeping

INF5890

Example of disruption

“Some of the younger doctors [who were due for surgery later] spent an hour extra every morning because it took so much longer to do the prescriptions. They then had two choices; they could leave the sedated patient waiting in the OR for half an hour, or they could skip the prescription of medication. They chose the latter. When they left before doing the prescriptions, we nurses didn’t have the written prescriptions needed for us to effectuate them. So we only administered what we were certain the patients should have – the rest was put on hold. And the timing is critical, so the doctors became mad that we hadn’t given the medication at the correct time”.

-ICU nurse Work around: N/A → Pilot terminated

INF5890

Internal evaluation (2007)

• Organizational challenges – Tight entanglement with practices – Difficult to maintain operations – Previous experience had limited relevance

• In general: Underestimated complexity

INF5890

Reflections in the clinic • “…the way this was implemented; everything was

suddenly supposed to be completed in one morning, and we were supposed to start with a lot of patients simultaneously. I believe it would have been better to start off more carefully – for instance with a single patient” (nurse).

• “I think the idea of starting with a narrow, but long chain was good. I don’t think I would have rejected that again. I believe that would have been smart – to follow one or two patients all the way through; these are the MetaVision patients” (head of department).

INF5890

What did they learn?

• More complex then assumed • Cant be based on previous experience • The “Thorax approach”

INF5890

Next phase: Anesthesia (2008)

• A “2nd pilot” • Simpler application • “Business” driven pace • Reduced complexity

INF5890

Reflections in the clinic • “Had I known then what I know now, I would have put my foot

down thoroughly when we started, and said that – we will do this, but we will start with anesthesia. We will start with an anesthesia record, and replace the current anesthesia charts. It’s a limited area – it is a solvable task. Then we use all resources on making that good and correctly implemented. With thorough education and such, I am convinced we would have avoided a lot of problems. […] Start with a limited area – and intensive care is a lot more complex activity than anesthesia”

• “We have an unsurpassed documentation of the ORs today that we didn’t have previously”

- Head of anesthesia section

INF5890

What did they learn?

• Start simple • Gain experience (ie. “Learn”) • Improve solution (based on experience) • Increase scope gradually to include more users

Does this sound familiar?

INF5890

Three approaches to the pilot

Pilot Thorax Anesthesia

Strategic approach Big-bang Client-based Region-based

Focus on The IT-system Risk Complexity

Short term goal Change Learning Learning

Diversity Horizontal and vertical Vertical Horizontal

Pace/progress Project driven ”Business” driven ”Business” driven

Usability for Everyone All clinicians All patients

Issues covered Everything and nothing (unfocused)

Bugs, logical flaws and use of terminology. Support for multiple practices in multiple contexts, reuse of information and integration

Bugs, logical flaws and (to some extent) use of terminology. Support for single practice in single context

Issues not covered

Latitudinal diversity and volume; suitability for multiple patient groups. Dependability; one tool for all patients

Longitudinal diversity; support for multiple practices in multiple contexts. Reuse of in-formation and integration

INF5890

What has this got to do with IT governance?

INF5890

Project configurations