There Are Real Risks Associated With the PCEHR. Here Are A Few!

Ms Roxon’s intervention in the discussions on the PCEHR made me wonder if there was actually a risk analysis of the PCEHR Program.

See here to read her comments I reported a day or so ago:

http://www.health.gov.au/internet/ministers/publishing.nsf/Content/mr-yr11-nr-nr182.htm

Reading the comments really made me wonder if the Minister - or her advisors - grasp the scale of risk associated with  the proposed PCEHR project.

Any large public projects carry substantial risk and large IT projects - and especially health IT projects - seem to be prone to nasty surprises and career ending outcomes.

Among the larger ones that have come seriously unglued we can think of the first attempt by Kaiser Permanente to undertake a major update of its IT infrastructure - that led to a write of in the many hundreds of millions of dollars - and the UK National Program for Health IT’s experience which is till playing out.

A very useful reference regarding all this is found here:

J Am Med Inform Assoc. 2009 May-Jun; 16(3): 291–299.

Health IT Success and Failure: Recommendations from Literature and an AMIA Workshop

Bonnie Kaplan, PhD and Kimberly D. Harris-Salamone, PhD 

The full text is here:

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC2732244/

Here is the Abstract:

Abstract

With the United States joining other countries in national efforts to reap the many benefits that use of health information technology can bring for health care quality and savings, sobering reports recall the complexity and difficulties of implementing even smaller-scale systems. Despite best practice research that identified success factors for health information technology projects, a majority, in some sense, still fail. Similar problems plague a variety of different kinds of applications, and have done so for many years. Ten AMIA working groups sponsored a workshop at the AMIA Fall 2006 Symposium. It was entitled “Avoiding The F-Word: IT Project Morbidity, Mortality, and Immortality” and focused on this under-addressed problem. Participants discussed communication, workflow, and quality; the complexity of information technology undertakings; the need to integrate all aspects of projects, work environments, and regulatory and policy requirements; and the difficulty of getting all the parts and participants in harmony. While recognizing that there still are technical issues related to functionality and interoperability, discussion affirmed the emerging consensus that problems are due to sociological, cultural, and financial issues, and hence are more managerial than technical. Participants drew on lessons from experience and research in identifying important issues, action items, and recommendations to address the following: what “success” and “failure” mean, what contributes to making successful or unsuccessful systems, how to use failure as an enhanced learning opportunity for continued improvement, how system successes or failures should be studied, and what AMIA should do to enhance opportunities for successes. The workshop laid out a research agenda and recommended action items, reflecting the conviction that AMIA members and AMIA as an organization can take a leadership role to make projects more practical and likely to succeed in health care settings.

----- End Quote:

A key section is found here:

What We Know—Lessons from Experience

Participants drew lessons from their research and experiences on how management might improve project success. These included:

• provide incentives, remove disincentives

Users may perceive that they have no time, or that what they are being asked to do moves work to them and away from others. Physicians, for example, would be more engaged if they experienced applications that helped them directly rather than providing disincentives to adopt the system. As an incentive, for example, physicians could get rounds done more easily if patient lists were ready when shifts begin.

• identify and mitigate risks

Determine the social risks, the IT risks, the leadership risks, the user risks, etc, and consider them early and often during the project. These risks and possible ways to mitigate them should become part of new or existing policies and procedures pertaining to the new system and incorporated into training.

• allow resources and time for training, exposure, and learning to input data

Participants described systems where clinicians had never used a keyboard or had exposure to computers, yet training was very limited. Sufficient training and time to learn need to be part of the implementation, and need to be on-going afterward.

• learn from the past and from others

Participants spoke of the need for studies of successes, failures, and how failing situations were turned around. They suggested longitudinal studies, qualitative studies, more focus on health care teams as a whole, and incorporating insights from change management, diffusion of innovation and technology, social science and sociotechnical theory, and multilevel frameworks. Although participants suggested drawing on existing theories and knowledge and also incorporating project management and methodology issues, they advised caution when doing so because of differences between health care and the business settings where models were developed. There also were calls for measurable evidence, including evidence of publication bias concerning project failure, and for various databases to be created

----- End Quote

As I see it we have a system in the PCEHR which pretty much goes against all of this:

First - as noted in the last few days the incentives to use the proposed PCEHR are distinctly lacking (see the News in yesterday’s blog and various Ministerial comments)

Second we note the is no ‘risk assessment’ or ‘risk analysis’ in the PCEHR Concept of Operations.

Third we find the Program / Project being driven by a politically driven rather that pragmatic time frame for delivery.

Last we not the PCEHR spends all of about 2-3 pages of 160 pages in the Concept of Operation on analysis of previous national and international projects - hardly an in-depth analysis.

As well as careful analysis of relevant past experience any IT Project Risk Analysis needs to assess:

1. Strategic Risks - what is out there that can or may impact on the shape and delivery of the project?

2. Budgetary, Cost and Resourcing  Risks - is the budget allocation secure and adequate - with a contingency - to deliver the program.

3. Management Risks - are those charged with delivery of the program experienced and capable to deliver the program. In this case it might also be termed execution risk.

4. Timing Risks - is the project plan and proposed timing structured in such a way as to make delivery reasonably achievable. Have the sequence of activities and their duration been properly planned to make delivery possible?

5. Technical Risks - are all the technologies, Standards etc. all proven and known to work and will the desired outcome be possible from a technical perspective.

6. Cultural Risks - is what is planned suitable for use in the work environment for which it is intended?

7. Security and Privacy Risks - As any IT project needs to address but most especially Health IT projects.

8. Sustainability Risks - What are the plans to continuing support of the outcomes of the project?

It seems to me the ConOps should offer an analysis of all these as well as a few pages on risk mitigation to be used starting with addressing this list at least. Of course all this should have been done before we stated off on this journey.

David.