Public Sector Health Information Systems


Avoiding eHealth Failure: Design-Reality Gap Techniques

  1. Assess Gaps
  2. Determine Action
  3. Generic Action
  4. Specific Action
  5. Example

"How can I make my e-health project more likely to succeed and/or less likely to fail?"

This page offers one approach to answering this question.

A gap exists for all e-health projects between the design assumptions/requirements and the reality of the client health organisation.  The larger this gap between design and reality, the greater the risk that the project will fail.  If you can reduce the gaps between design and reality, you can reduce the risk of e-health failure.  This page looks at various ways of reducing those design-reality gaps.  Follow this link for further explanation about design-reality gaps (and some related case examples).

Step 1. Assess Design-Reality Gaps

The first step in reducing the chances of failure is to assess two things.  First, the individual design-reality gaps on each of seven 'ITPOSMO' dimensions: information, technology, processes, objectives & values, staffing & skills, management systems and structures, and other resources.  Second, the total design-reality gap (obtained from adding the seven individual gaps).

Follow this link for guidance on how to assess design-reality gaps.

Step 2. Determine Action

If you have a significant overall design-reality gap, you should take action since you may be heading for failure.  If you have a significant design-reality gap on a particular dimension, you should take action since this may cause you problems.  Assessing whether a gap is 'significant' is a matter for discussion, debate and judgement.  However, an overall gap of more than about 20, and an individual dimension gap of more than about 5 could give cause for concern.

"Taking action" means either:

  1. Changing the design of the e-health project to make it more like reality, and/or
  2. Changing current reality to make it more like the assumptions/requirements within project design.

Selected techniques will, of course, depend on which dimension(s) the gap occurs.  Take the example of a financial gap along the 'other resources' dimension.  This gap could be reduced by scaling-down the project remit and thereby reducing cost (design change).  Or it could be reduced through public-public or public-private collaboration that increases the supply of available finance (reality change).

A sample of gap reduction techniques is presented in more detail below.  Some techniques are generic: they relate to one or more ITPOSMO dimensions.  Other techniques are specific: they relate to one specific dimension.

In selecting a technique for a particular project, practitioners should ensure that the technique is not only desirable but also feasible.  There is no point considering techniques that could reduce risks in theory, but not be implemented in practice.

Step 3a. Generic Gap Reduction Techniques to Reduce the Risk of eHealth Failure

i. Legitimising and mapping current reality .  To succeed in e-health - and to properly identify design-reality gaps - you have to understand current reality.  Yet this may be difficult to achieve.  eHealth leaders can help by 'legitimising reality': by encouraging stakeholders to express the difference between prescriptive models of what they should be doing, and real depictions of what they are actually doing.

Techniques for exposing and mapping organisational realities play a role here.  Self- and third party observation helps expose realities.  Use of soft systems tools such as 'rich pictures' helps map realities.  Prototyping helps both, particularly helping users to understand their real information needs.

ii. Customisation to match realities .  Public healthcare organisations too readily try to install ready-made digital solutions that have been designed for private health providers.  The problem is that private sector and public sector remain fundamentally different.  Solutions designed for the former do not necessarily match the realities of the latter.

To combat such problems, managers of public e-health projects must be competent enough and confident enough to demand designs that match their organisation's unique reality.  The keywords for such projects must be 'customised' not 'off-the-shelf'; 'adapt' not just 'adopt'.

In many cases, this will require national and/or sectoral and/or in-house e-health development capacities to be strengthened.  This will also affect selection of software vendors and developers. One key criterion will be their demonstrable willingness and ability to understand client contextual realities and to customise e-health systems accordingly.

iii. Client-vendor relationship management .  The squeeze on public sector skills and cash means that public e-health projects are increasingly outsourced to the private sector.  This can exacerbate the traditional gulf between developers and clients, by stirring in an additional clash of culture and values.  Gaps between vendor design and client reality readily emerge.

To reduce these design-reality gaps, much more attention needs to be paid to active management of the client-vendor relationship.  Successful e-health projects are adopting innovative approaches to build mutual understanding and shared objectives.  Gap reduction techniques include vendor shadowing of key client staff, joint team-building events, joint profit sharing and open book accounting.

For public healthcare organisations, this heightened focus on supplier relationship management means the development of new skills and roles, including relationship building, contract facilitation, contract monitoring and vendor development.  It also means a renewed emphasis on other roles that must remain in-house such as strategic management, business analysis and change management.

iv. Step-by-step: modularity and incrementalism .  The bigger and bolder the e-health project, the greater the risk of failure.  Developers must reconfigure such projects to limit the extent of change (i.e. of design-reality gap) at any given time.

Stretching project time horizons is one technique.  There is also a growing consensus behind modularity (supporting one business function at a time) and incrementalism (providing stepped levels of support for business functions) within public e-health projects (see figure below).

v. 'Hybrids' and 'tribrids' .  Design-reality gaps often arise in e-health because of a 'two tribes' mentality that afflicts many healthcare organisations.  IT designers understand technology but not the realities of healthcare delivery.  Public officials and health workers understand the realities of healthcare but not the technology.  To close these gaps, projects need to develop and use 'hybrid' professionals, who understand both perspectives.  We might even call them 'tribrids' (see figure below), because they combine three aspects: understanding the technology and the business of healthcare and the role of information in healthcare.

vi. Scope limitation: KISS and automation .  eHealth projects sometimes fail because they try to change too many things at once.  One way to address such over-large design-reality gaps is to cut down the scope and ambition of the project design; sticking with the valuable design motto 'KISS': Keep it Small and Simple .  One way to incorporate KISS is by trying to freeze all except the technology dimension.  How?  By simple automation of existing activities.  The intention is to retain the same information, same processes, same management systems and structures, etc., but merely change them from manual to computerised operations.  In other words, you attempt to create no design-reality gap (no change) on most ITPOSMO dimensions.  Although criticised in hindsight as being insufficiently bold, simple automation can be a very good - and successful - way to institutionalise new technology in a particular aspect of public healthcare operations.

vii. Reality-supporting not rationality-imposing applications .  There is a continuum of e-health applications, as shown in the diagram below.  At one extreme, there are 'rationality-imposing applications', such as decision support systems.  These include in their design a whole series of assumptions about the presence of rational information, processes, objectives and values, management structures, etc.  These rationalities must either be present in the organisation as a pre-condition for successful implementation of this application, or they must be imposed.  In many healthcare organisations, the introduction of such applications will not succeed because of the large gap between the application's required rationalities and current organisational realities.

At the other extreme, there are 'reality-supporting applications' such as word processing or email.  By comparison with rationality-imposing applications, reality-supporting applications require fewer rational pre-conditions or impositions. They can therefore work successfully in a wider variety of healthcare organisational situations.  eHealth projects will therefore be more likely to succeed if they focus on 'reality-supporting' rather than 'rationality-imposing' applications.

Step 3b. Dimension-Specific Gap Reduction Techniques to Reduce the Risk of eHealth Failure

i. Information dimension .

ii. Technology dimension .

iii. Process dimension .

iv. Objectives and Values dimension .

v. Staffing and Skills dimension .

vi. Management Systems and Structures dimension .

vii. Other Resources dimension :

Real-World Example

Recommended generic and specific gap closure techniques are provided for the following real-world case of e-health: Computerising a Central Asian Epidemiology Service.


Page Author: Richard Heeks. Last updated on 19 October, 2008.
Please contact with comments and suggestions.