The Practicalities of Project Management, Deployment and Adoption

From SystemsWiki

Jump to: navigation, search


Learning Objectives

This section is essentially where ‘the rubber hits the road’ where we explore just what is needed from non-technical managers to facilitate and confidently oversee the optimum delivery of Health IT systems and what it is a manager needs to be monitoring and expecting from the technical staff to have some comfort that things are proceeding as needed and desired. Overall what is needed is a very healthy level of scepticism of what one is being told by technical staff and a level of curiosity about what is actually being done, and why. This is not to suggest technical staff are deliberately attempting to mislead but to recognise that their perspective and goals may not necessarily be aligned to those of the organisation overall. It is the role of senior technical management to ensure that this misalignment is minimal at worst and ideally non-existent. From a management perspective it is also vital to be very clear the Health IT implementations are by no means risk free. There is a very large, and often very depressing literature, concerning the failure of major Health IT projects which emphasises just how hard these projects can be to deliver on time and on budget and to avoid even total project failure!

  • The following articles provide a flavour for the various ways ‘Big IT’ can fail and emphasises the need for quality management in delivery of major projects. Some pointers are hopefully offered in the next few sections.
  • Catalogue of Catastrophe

Blog site: Why Projects Fail

  • Why big IT projects crash

Financial Times, September 18 2013

  • IT's biggest project failures -- and what we can learn from them


  • Catalog of major I.T. projects which have failed to deliver.

Blog Site Source:

  • With the clear awareness of the risks of failure of IT projects what follows discuss the various things that might be considered to minimise the risks.

Just to really emphasise how important it is to take the risk of failure seriously one only has to consider the various problematic programs in Australia - including the PCEHR Program and the Victorian HealthSMART Program. In recent times we have seen a major problematic Health IT implementation in the US with the great difficulties experience with the site which was intended to assist citizens to locate the best health insurance plans under the US Affordable Care Act (Obamacare). What follows is a practically orientated discussion around which managers must do during the planning, selection, implementation and use of Health IT.

Health IT Strategy

The first thing with the deployment of Health IT is to have a develop a Strategic Plan that identifies the full range of beneficial opportunities that can result from Health IT and to then prioritise them and to then, while developing a business case, ensure what is emerging is fully aligned with the organisations overall strategy.

  • In broad terms a Health IT Strategy needs to address the following:

1. An overview of the current organisational strategy and plans. 2. An assessment of the capabilities, strengths and weaknesses of currently implemented Health IT and associated infrastructure and a gap analysis of additional areas that need to be addressed. 3 A design for the Strategic Governance, Sponsorship and Consultation which will required to progress the plan. Ideally a cross discipline committee, chaired by the CEO, would be responsible for the development of the plan - possibly assisted by expert consultants. 3. An opportunity analysis with ranking of priorities as well as envisaged benefits. 4. An assessment of the organisational capabilities and maturity with respect to Information Technology implementation and use. 5. An overview project implementation and sequencing plan for the intended sub-projects typically over say a three or five year window. 6. A resourcing plan for the strategy. 7. A high level cost benefits plan and then more detailed cost benefit plans for each of the different project proposals. 8. An detailed project charter, implementation, resource and benefits realisation plan for each project proposal.

  • There are some very useful articles available to assist in any local process. This article has links to a very useful summary and a range of recent sample plans:
  • Ten Practices for Health IT Strategic Planning

Jan 01, 2013 12:05 am | posted by Satish Gattadahalli | Healthcare and health information technology (health IT) are undergoing transformative change at an unprecedented pace. Strategic planning has become a major discussion point among CIOs, CTOs, CMIOs, and IT Directors. Whether it is implementing enterprise-wide electronic health record (EHR) systems, working toward compliance with the “meaningful use” EHR Incentive Program, enabling patients’ involvement through PHRs, transitioning to ICD-10, establishing insurance exchanges, becoming an accountable care organization, or even deploying a medical home, healthcare executives are confronted with a confluence of high-priority initiatives. It is imperative to view health IT strategically from an IT management perspective. Based on developing and institutionalizing health information and health IT strategic planning for large-scale integrated healthcare organizations, lessons learned can be distilled to 10 practices. Following these practices will equip the CIO, CTO, and CMIO to not only develop a Health Information and HIT Strategic Plan, but provide clarity on operationalizing the plan and managing information and IT strategically within their organization as well.

  • Read the full 10 points here:

  • The following quite recent paper provides a slightly different way to reach similar objectives.

Principles and Framework for eHealth Strategy Development Richard E Scott1,2, BSc (Hons), PhD; Maurice Mars1, MB ChB, MD ABSTRACT Significant investment in eHealth solutions is being made in nearly every country of the world. How do we know that these investments and the foregone opportunity costs are the correct ones? Absent, poor, or vague eHealth strategy is a significant barrier to effective investment in, and implementation of, sustainable eHealth solutions and establishment of an eHealth favorable policy environment. Strategy is the driving force, the first essential ingredient, that can place countries in charge of their own eHealth destiny and inform them of the policy necessary to achieve it. In the last 2 years, there has been renewed interest in eHealth strategy from the World Health Organization (WHO), International Telecommunications Union (ITU), Pan American Health Organization (PAHO), the African Union, and the Commonwealth; yet overall, the literature lacks clear guidance to inform countries why and how to develop their own complementary but locally specific eHealth strategy. To address this gap, this paper further develops an eHealth Strategy Development Framework, basing it upon a conceptual framework and relevant theories of strategy and complex system analysis available from the literature. We present here the rationale, theories, and final eHealth strategy development framework by which a systematic and methodical approach can be applied by institutions, subnational regions, and countries to create holistic, needs- and evidence-based, and defensible eHealth strategy and to ensure wise investment in eHealth. (J Med Internet Res 2013;15(7):e155) doi:10.2196/jmir.2250 Here is the link to the full paper The obvious bottom line - you need a plan first and then action can follow.

Elements of Project and Change Management

  • (Planning, Funding, Governance, Leadership, Clinician Involvement)

The basics of project management in the Health IT domain are well discussed in the references provided at the end of this section. At least one of these resources should be carefully reviewed as part of the work undertaken for the course if the student is not fully acquainted with the basics of the project management discipline.

  • In the context of Health IT project management there are a few general aspects which can make such projects rather more difficult than in other industries. These include:
  • 1. Both hospital and even larger practice system implementations do need careful planning given the complex nature of operations within a health entity and the large number of stakeholders who have an interest - and may have concerns - about what is being done.
  • 2. Even the apparently most simple project can come unstuck for a range of unexpected reasons and following a structured methodology - despite seeming potential overkill - will very often turn out to have been very sensible. Before implementation begins it is important to ask just what might / could go wrong and how can the consequences of anything actually going wrong be mitigated (Risk Management).
  • 3. If at all possible all projects should be divided into ‘bite-sized’ incremental chunks which are taken successively and each one is properly completed and signed off before the next is begun.
  • 4. Before any system is used in a ‘live’ setting it must be carefully and fully tested. This can be difficult due to time pressures on key users but must never be compromised.
  • 5. Given the complexity of the stakeholder relationships involved in a system implementation or transition the leadership, executive sponsorship and governance aspects should all be sorted out and documented in advance - also with all other aspects of the project. An approach involving development of a ‘Project Charter’ which covers the why, who, what, when, how, resourcing, leadership and sponsorship for the project can be invaluable in assuring that all those involved are ‘on the same page’.

Wikipedia provides a useful summary for the rationale involved in using a Project Charter here:

  • 6. Inevitably in Health IT projects there are issues that arise around obtaining the involvement and co-operation of senior clinical staff. It needs to be recognised that senior clinical involvement in and support of a project can often be difference between success and failure. It is also vital such clinicians be properly trained and this may need to be done is a carefully selected environment at suitable times with appropriate incentives for attendance provided. Nursing staff can be invaluable allies in a successful project, and their involvement is critical in all clinically related projects.
  • 7. Management recognition of just how difficult some projects can be should result in a low threshold for being prepared to deploy professional project support and management (from well referenced experts) when there is any doubt regarding the internal organisational capabilities to execute well.
  • 8. Structured change management and benefits realisation plans should be part of the project plan and be properly resourced.
  • 9. General project management methodologies often do not really absorb many of the health system’s cultural issues. The references provided below do seem, to me, to strike a sensible stance and are important reading.
  • This is a useful summary paper:

Project Management Characteristics and Education for eHealth Students Norm Archer McMaster eBusiness Research Centre, DeGroote School of Business, McMaster University, Hamilton, Canada Downloadable from this link.

  • Other presentations that may also be useful include:

  • This one on how to avoid failure is a good browse: More elements of the topic are discussed in the recommended text book in Chapters 6 and 7 as well as most of Part 4 of the Recommended Textbook. The areas discussed in this very brief summary above are also covered very comprehensively in the 19th Unit of a degree level Health IT course developed for the US Government’s Office of the National Co-ordinator For Health IT - which is freely available and licenced under the Creative Commons Licence.. The whole course is available for download from this link after a very simple registration.


  • When considering issues related to privacy of patient information the key element to bear in mind is that patient’s trust in their healthcare providers is, in part, related to the unwritten expectation going all the way back to Hippocrates. (See Section 7 for more coverage).
  • From a practical perspective meeting that expectation has at least two elements.
    • The first is that there are clear legal obligations placed on healthcare providers (which can be confusing due to there being overlapping state and Federal laws). Obviously then all staff involved in the handling of patient information need to be educated on just what the legal requirements are in their particular workplace. Additionally there must be regular updating of staff expertise in the area.
    • The second is that organisations must develop policies, plans and procedures which are protective of a patient’s privacy while conforming with the law. The reasons for doing this are both for compliance and for clarity as to what is needed.

To that end an organisation must develop procedures which address how information is collected, what information is collected and then how is it maintained and then possibly destroyed after an appropriate period.

  • This table from Victoria Health provides useful insight into the areas that need to be addressed:

Health and Information Privacy Principles This table sets out a summary version of some key Privacy Principles from the two Victorian Acts, as published by the Health Services Commissioner and the Victorian Privacy Commissioner respectively. These do not set out the full set or form of the Principles, and are intended for quick reference only. The Principles in full can be found in the respective Acts.

Health Privacy Principles Summary

Information Privacy Principles Summary

  • 1. Collection

Only collect health information if necessary for the performance of a function or activity and with consent (or if it falls within HPP1). Notify individuals about what you do with the information and that they can gain access to it. Collect only personal information that is necessary for performance of functions. Advise individuals that they can gain access to personal information.

  • 2. Use and Disclosure 2. Use and Disclosure

Only use or disclose health information for the primary purpose for which it was collected or a directly related secondary purpose the person would reasonably expect. Otherwise, you generally need consent. Use and disclose personal information only for the primary purpose for which it was collected or a secondary purpose the person would reasonably expect. Use for secondary purposes should have the consent of the person.

  • 3. Data Quality 3. Data Quality

Take reasonable steps to ensure health information you hold is accurate, complete, up-to-date and relevant to the functions you perform. Make sure personal information is accurate, complete and up-to-date.

  • 4. Data Security and Retention 4. Data Security

Safeguard the health information you hold against misuse, loss, unauthorised access and modification. Only destroy or delete health information in accordance with HPP4. Take reasonable steps to protect personal information from misuse, loss, unauthorised access, modification or disclosure. 5. Openness 5. Openness Document clearly expressed policies on your management of health information and make this statement available to anyone who asks for it. Document clearly expressed policies on management of personal information and provide the policies to anyone who asks. 6. Access and Correction 6. Access and Correction Individuals have a right to seek access to health information held about them in the private sector, and to correct it if it is inaccurate, incomplete, misleading or not up-to-date.*

  • [In the public sector individuals already have this right under Freedom of Information]. Individuals have a right to seek access to their personal information and make corrections. Access and correction will be handled mostly under the Victorian Freedom of Information Act.

7. Identifiers 7. Unique Identifiers Only assign a number to identify a person if the assignment is reasonably necessary to carry out your functions efficiently. A unique identifier is usually a number assigned to an individual in order to identify the person for the purposes of the organisation's operations. Tax File Numbers and Driver's Licence Numbers are examples. Unique identifiers can facilitate data matching. Data matching can diminish privacy. IPP 7 limits the adoption and sharing of unique numbers. 8. Anonymity 8. Anonymity Give individuals the option of not identifying themselves when entering transactions with organisations where this is lawful and practicable. Give individuals the option of not identifying themselves when entering transactions with organisations if that would be lawful and feasible. 9. Transborder Data Flows 9. Transborder Data Flows Only transfer health information outside Victoria if the organisation receiving it is subject to laws substantially similar to the HPPs. Basically, if your personal information travels, your privacy protection should travel with it. Transfer of personal information outside Victoria is restricted. Personal information may be transferred only if the recipient protects privacy under standards similar to Victoria's IPPs. 10. Transfer/closure of practice health service provider 10. Sensitive Information If you're a health service provider, and your business or practice is being sold, transferred or closed down, without you continuing to provide services, you must give notice of the transfer or closure to past service users. The law restricts collection of sensitive information like an individual's racial or ethnic origin, political views, religious beliefs, sexual preferences, membership of groups or criminal record. 11. Making Information available to another health service provider If you're a health service provider, you must make health information relating to an individual available to another health service provider if requested by the individual. For Information about the health records Act For Information about the Information Privacy Act Health Services Commissioner 30th Floor, 570 Bourke Street Melbourne Victoria 3000 Telephone: 1800 136 066 Website: Victorian Privacy Commissioner Level 11, 10-16 Queen Street Melbourne Victoria 3000 Telephone: 1300 666 444 Website:

Source:,-guidelines-and-legislation/health-and-information-privacy-principles Any organisation handling private health information needs to think carefully about and then respond with relevant written policies and procedures. There is a useful example which addresses many of the points available for Ramsay Healthcare - Australia’s largest private hospital chain. See:

  • Privacy Victoria offers an approach to developing a privacy policy. See:

  • The Royal Australian College Of General Practice also offers some useful guidelines.

  • In early 2014 a revised national privacy regime is being implemented and all managers should make sure they are aware of the implications of the changes (they were legislated in late 2012)

This page discusses the main changes.

  • As a final practical point it is necessary to ensure clothing, rooms, other physical infrastructure and layouts of consulting rooms etc. are privacy protective with sound proofing, screen positioning and so on.

Data Protection and Security

  • From a practical perspective there are two key issues.
    • The first is that systems that are used to handle health information are designed and implemented from the ground up to properly secure and protect health information.
    • The second is around the procedures, policies and training that must be both developed, implemented and refreshed regularly to stay on top of emerging problems and exposures.
  • Considering first the issues around intrinsic software security it has to be said that most are in the hand of their software providers and implementers to ensure they keep track of and patch vulnerabilities as they are discovered and that implementers configure systems with proper attention to security risks. The best that management can do is ensure there are contractual obligations in the software maintenance contracts the oblige the provider to address any issues that arise. As far as system implementation is concerned, again, the implementation contract should explicitly ensure such issues as security are reviewed and approved. Issues such as network security and so on need to be formally addressed.

The second area of interest is actually operationalizing what is widely referred to as a ‘security culture’ where information assets are properly valued and it is understood that they must be appropriately managed. This area is one where senior management must lead and sponsor relevant efforts to develop and maintain optimal security. In doing this there will need to be a very clear recognition that virtually all studies have shown that the source of most problems is human error or malevolence and as such any policies must do what is possible to mitigate the risks.

  • No matter what the size of the organisation it is important to have a security policy for the information assets which is based on a weighted risk analysis which aims to ensure all the reasonably foreseeable risks are fully mitigated and that contingency is in place for the very unlikely. The objectives of the policy will include the following:
  • 1. Preserve the privacy and confidentiality of patient and other sensitive information and to ensure there is no unauthorised access to private information.
  • 2. Ensure there is no corruption or loss, or loss of access to, relevant patient and operational information.
  • 3. Ensure there is prompt restoration of business operations after major issues - e.g. flooding, fire, major power outage and so on. (what is known as business continuity planning)

From these objectives then will flow what needs to be done technically and from a training and cultural perspective to achieve the objectives. Managers should also bear in mind there is a compliance and legal aspect to providing appropriate security and data protection and this should not be underestimated. Most especially it is important to be asking about how information that is on detachable and moveable media. In 2013 it is unacceptable that information is not properly protected by appropriate encryption. Not encrypting sensitive data on USB sticks, laptops and DVDs etc. is simply unacceptable. *Managers need to ask specifically just what the organisational policy is in this area. With this background what follows are links to a range of resources which the reader should download / review to obtain an understanding of what is expected.

  • For smaller organisations (e.g. GP practices etc.) there are the following.
    • 1. From the Royal Australian College of General Practice. There is invaluable information here with templates as well as detailed information on the relevant standards.

    • 2. From the US Office of the National Co-ordinator for Health IT. CyberSecurity 10 Best Practices for the Small Health Care Environment

    • 3.From eHealth Ontario there is a good discussion found here: For larger more complex organisations (e.g. Hospitals) we have the following. 1. From Healthcare Information and Management Systems Society (HIMSS) we have: This page offers a range of relevant resources and toolkits This .pdf is especially relevant. 2. Again from eHealth Ontario we have a large organisation approach. Review of these will provide a very good starting point for management action in this important area.

Incentive Use

  • Both the Australian and the US Governments have been so convinced of the value of increasing participation that they have been prepared to provide considerable financial incentives for adoption and use of Health IT - especially in General / Ambulatory Practice.
  • In Australia we have had the so called Practice Incentive Program (PIP) which has been administered by Medicare and which has provided what is a blended payment to a practice for a certain level of technology use. Since beginning over a decade ago every year or two the requirements for receiving the (not inconsiderable) payments have gradually increased from essentially just having a computer on the surgery disk to meeting a range of messaging and information requirements as well as having relevant security etc.

In the US there has been a program called ‘Meaningful Use’ which has done a similar thing. There the practitioner has to use a certified EHR system and to use a progressively enhanced functionality. Interestingly in the US while the incentives have involved billions of dollars the program has a sting in the tail in the form of a reduction of Medicare Payments coming ins a year or two for those practices who are not using certified software to a certain standard. A real ‘carrot and stick’ approach!

  • So far both programs appear to have achieved their usage and adoption goals. However just what is scale of benefits that have flowed in terms of improved clinical outcome etc. is a good deal harder to determine. There is, however, no doubt sufficient funds can change clinician behaviour and this is a lesson worth remembering.

Procurement and System Selection Approaches and Issues

  • After a strategic plan has been developed, and appropriate projects have been identified the next step is to action the plan.

In 2014 there are very few who are actually developing the Health IT that they are implementing meaning that virtually all organisations have to go through a range of selection and procurements to obtain the technology support they need. This means that the old discussion relating to buy vs. build is not essentially moot, and that the focus will most often be on a system selection process followed by an actual procurement.

  • The principles of how all this should be conducted are reasonably well known. The steps are as follows.
    • 1. Form a dedicated project team, who work to develop an overall specification for what is to be procured. This needs to consider the overall situation of the entity with respect to its present architecture and situation to ensure it is possible to optimise what is procured. Integrated vs. Best of Breed application considerations need to be reflected upon at this point as if an integrated solution is desired there will be constraints on what could be acquired.

Specification development should be ideally informed by all the relevant stakeholders, however this can be difficult without some actual software to review.

    • 2. Conduct market testing and possibly and Expression of Interest process to prove that potentially viable solutions exist.
    • 3. Develop a formal tender document to be given to potential suppliers which covers the functionality desired, the current technical environment, anticipated levels of use, desired contractual and support terms and so on. In developing the tender document there needs to be an evaluation strategy for the tenders developed - to be used when the tender responses are received.
    • 4. Once tenders are received they are evaluated against the pre-set criteria. If relevant there need to be site visits to assess the software in operation and use, and a comparative review of the software by a range of relevant potential users.
    • 5. Once a tentative selection is made the next step is to negotiate guarantees, contract terms and conditions, the proposed implementation plans and timetables, potential cost and software variations etc.
    • 6. With all that done then a project team of users, professionals and the vendor staff can be formed, resourced and actually begin work.
    • 7. The last step - after implementation and go-live - is a post implementation review to ensure what was promised was actually delivered and that the application is working as expected.

Obviously these processes need to be tailored for organisational size and complexity and can be made much more or less rigorous depending on circumstances, the scale of the budget involved and the risks.

  • There are a two useful resources that may be useful to review.
    • First a US centric but sensible tool kit is found here: How Do I Assess and Procure the Health IT Functionalities and Tools?

    • Second an interesting article on a complex major procurement project in Canada.

Business Process Re-engineering And Workflow Redesign

Throughout this unit I have been making the point that Health IT is a potential enabler of improved health outcomes and as such is a tool and not an objective in itself. The goal in all implementations is not only to improve but to optimise the quality, safety, cost and efficiency of the patient care that is delivered. In order to achieve this outcome there is often the need for a fair bit of lateral thinking and consideration of a wide range of potential options. The issue is first to re-imagine how things might be done and then more importantly to convince those in the present workplace that what is proposed would actually be an improvement. This can turn out to be a very considerable challenge against a background of ‘this is the way we do things around here’ conservatism! If this is done well things can proceed smoothly, done badly can be a managerial nightmare. It is also important to appreciate that the desired levels of optimisation can rarely be obtained without a fairly structure planning and envisioning process. This link points to the generalised approach that is typically used to undertake such planning: The article makes clear the centrality and importance of IT in such undertakings. Also of use in this context is the following review: E-health: applying business process reengineering principles to healthcare in Canada Michael Bliemel and Khaled Hassanein* DeGroote School of Business, McMaster University, 1280 Main Street West, Hamilt on, Ont., L8S 4M4, Canada Fax: +1 905 521 8995 E-mail:

  • E-mail:

Abstract: Healthcare in Canada is facing many problems. The most publicised symptoms are excessive waiting times for patients, lack of access, high cost of delivery and medical errors. e-health has been introduced as a potential solution for such problems. This research will explore the area of e-health and the technologies as well as the concepts that are included under its large umbrella. Bearing in mind that e-health is more than a set of technological applications, a business process reengineering (BPR) framework will be used to examine the application of particular BPR principles to address specific problems that are plaguing the Canadian healthcare system. The framework identifies the e-health technologies and processes that could best support the effective application of these BPR principles with in a healthcare environment, as well as the key barriers impeding their implementation. The full paper can be downloaded here: The overall lesson I think should be taken from this is that before any new systems are procured or implemented careful consideration needs to be given as to just what improvement might be possible. The reverse is possible as well. As a friend once said: “Automating a bad practice leads to a more effective and more dangerous bad practice”. It is vital this always be borne in mind when planning new Health IT.

Review Questions

  • 1. Obtain a copy of the Health IT Strategy for your organisation and, using what you have learned and read in this section, provide a critique of the quality and value of your organisation’s plans.
  • 2. How would you rate the quality and efficacy of the privacy, data protection and it security policies of your organisation?
  • 3. Considering a health-care organisation you know well what opportunities can you identify for IT enabled BPR.

Return to HI Homepage

Questions & Comments to Geoff McDonnell
Personal tools