Beyond Medical Informatics

Note: Here’s the final cut of my talk at the eHealth 2009 conference. I usually draft my talk, create slides, then finalize both talk and slides. During the session, I have a printed copy as a guide. This should be very close to what I discussed that afternoon.

—

Good afternoon!

I’ve been in the field of Medical Informatics for 7 years now. And one of the things I’ve learned is that Medical Informatics and Project Management go hand in hand. Project management is an essential skill of the medical informatics professional. Both tasks can be overwhelming. But they can also be very fulfilling.

Right now, I work as the Medical Informatics Consultant for St. Luke’s Medical Center. Aside from doing long-term strategic planning for clinical applications, I also manage Healthcare IT projects for the hospital. Here is a list of projects I am involved in. In these projects, I am either the project manager, or I supervise the project managers.

I’ve learned a few things about project management along the way. I’ve decided to share 7 of what I think are the most relevant to eHealth projects.

Here they are:

1. Identify the problem.
2. Formulate the success criteria.
3. Get the right people.
4. Communicate.
5. Who does What by When.
6. Use checklists.
7. Do post-implementation reviews.

Let’s go through them one by one.

Before starting any project, the organization should ask itself: Why are we doing this project? What problems are we trying to solve? What opportunities are we trying to take?

This process helps identify the vision, goals and objectives of the project.

I’d also recommend coming up with a problem statement. The problem statement cannot be the absence of a specific IT system. You cannot say that the problem of the hospital is that it does not have an LIS. Identify the business need or opportunity you want to address by doing an IT project. Try to come up with a problem statement that does not have any IT terms in it.

This underscores the point that: The IT project is NOT the project. It is an integral component of a bigger, more comprehensive, organization-wide plan.

All eHealth projects should start with this point of view. Why? Because all eHealth projects are basically healthcare improvement projects that have a strong IT component. The final result, the final benefit of the project lies outside the IT system.

Once you know why you are doing the project, come up with the success criteria. This basically asks the question: how do we know if we’ve succeeded in implementing a solution to the identified problem.

The success criteria are measurable items that identify the project’s business value. This is important for management buy-in. Try to be as detailed as possible. That’s why it’s also important that the success criteria are specific to the organization based on resources, capabilities and people.

Just a quick note on IT vendors: Sometimes working with IT vendors can be tricky or problematic, but I’ve learned it best to treat them as partners. And as partners, both of you should come up with an acceptance criteria specific to the IT or product implementation. You cannot expect the product to solve all of the organizations problems. But you can expect the product to perform or deliver according to an agreed acceptance criteria.

The next one is getting the right people. The project will not move on its own. People move the project forward. And with the right people, success, though not guaranteed, is much easier achieved. So, get the right people assigned to the right positions. Give them the right responsibility according to their strengths. Get them involved. Get them trained.

Investing in the right people is an investment towards successful eHealth projects.

The 4th one is to communicate. Take note that I did not say "draft a communication plan". Communicate. Communicate. Communicate. Have the desire to communicate the vision, goals, objectives, success criteria to the right people. Your communication plan is only as good as your desire to communicate.

So use whatever means possible. Use direct communications. Meetings. Memos. Email. Text. Whatever. If you cannot communicate, you cannot manage. If you cannot manage, your project cannot succeed.

Communication is the key to better ideas, better collaboration and better cooperation.

Project management is nothing more than the concept of managing ‘Who does What by When’. That’s it. A project is a basically a series of activities. Activities are people doing specific tasks by a given deadline.

Now, once you truly understand this concept, you will realize that project management is nothing more than just plain management and leadership.

The problem with current project management methodologies is that there is just too much paperwork. But the paperwork is NOT the project. The project is not the Gantt chart, the WBS, the MS Project file, the monitoring tool, the weekly report or even the overall plan. The project is the series of “Who does What by When”. The project is the management of people doing specific tasks by a given deadline.

Paperwork can be reassuring. And you do need some paperwork (reports, charts and plans) to help manage the project. But all the paperwork in the world will not help a project manager who does not know how to manage his people. All the tools in the world will not help a project manager who does not manage his people.

Lesson 6 is a practical advice. Use checklists. This is something I learned very recently. I try to use checklists for almost every task in the project. Do not rely on a mental checklist. Write the checklist down and distribute. Share your checklists. This will help assure you that people are doing tasks correctly and that they do not miss anything. Use checklists for activities, for specific steps, for specific items that will be used for each step, and even for people who should be there in a specific activity.

The last lesson is to do post-implementation reviews. It is important to document and learn from what went right and what went wrong. Be gentle but be brutally honest with yourself and with your team.

In my post-implementation reviews, I try to practice Hansei. Hansei is a Japanese concept popularized by the Toyota Production System. It is one word that combines the process of acknowledging your mistakes and making a pledge to improve. The process of Hansei is not only to learn from your mistakes but also to make a decision to change your behavior, to act better, to be better next time. Continuous improvement only happens if you practice Hansei.

An important lesson in project management is that even if you’ve outlined all the steps you need to take, even if you planned for all scenarios, even if you said you’d only share 7 lessons, something else always comes up. So, lesson 8, expect the unexpected.

Keep an open mind for change. Change is constant. Always be ready. Remember, change is not the enemy. Unmanaged change is.

And the best way to manage change–is to initiate change.

Thank you.

—

References:
Getting Things Done (David Allen)
Effective Software Project Management (Robert Wysocki)
Manager Tools

—

I will elaborate on each item in the coming days. Comments, questions and feedback are welcome!

I’ve been invited to talk at the eHealth & Telemedicine Philippines 2009. My topic is on "eHealth Project Management". Here is a short summary of my talk entitled "7 Lessons Learned in eHealth Project Management".

Project Management is an essential responsibility of the Medical Informatics professional. The knowledge and skills of good project management are important for successful eHealth implementations. If we think about it, Medical Informatics is one big project!

There’s always something new to learn from each project. I’ve chosen to share 7 of the most important lessons I’ve learned through the years.

1. Identify the problem.
2. Formulate the success criteria.
3. Get the right people.
4. Communicate.
5. Who does What by When.
6. Use checklists.
7. Conduct post-implementation reviews.

I will be giving more details in the talk and in future blog posts. I will also upload the slide presentation on this site after the conference.

See you there!

—

Update [May 08, 2009]: Here’s a transcript of the talk on 7 Lessons Learned in eHealth Project Management.

Google Health was in the news recently. The main issue involved an inadvertent error in ‘using’ billing codes as clinical information after the transfer of a patient data into the online personal health record (PHR). This incident underscores a common misconception about the use and purpose of billing and classification codes in healthcare systems. Codes cannot—and should not—replace clinical data and diagnoses. They can serve handy adjunct information, but they are not integral to the direct patient care processes.

Here are a few more quotes from the original article of The Boston Globe:

"The problem is this kind of information should never be used clinically, especially if you don’t have starting or ending dates" attached to each problem, said deBronkart’s primary care doctor, Daniel Z. Sands, who is also the director of medical informatics at Cisco Systems.

"Claims data is notoriously inaccurate and notoriously incomplete with respect to an expression of the problems a person has," said Dr. David Kibbe, a senior technology adviser to the American Academy of Family Physicians.

I’ve had personal experiences with this misconception. When we reviewed our functional requirements for the admission and billing systems, someone proposed using ICD-10 codes exclusively for admitting and discharge diagnoses. The proposal even involved mandating residents and consultant doctors to write their diagnosis in ICD-10 codes, instead of using full-text narratives.

This erroneous thinking is not so uncommon. Even some Healthcare IT professionals make the same mistake. Some of the local hospital and clinic systems software I’ve evaluated only accept ICD-10 codes for both problem lists and working diagnoses.

Classification codes are very limiting, especially in capturing several types of diagnoses, e.g. working, differential, ‘rule out’, ‘to consider’, etc. Clinicians should not be constrained in their efforts to write down and communicate relevant medical information. A common solution in clinical applications is to use full-text narratives with controlled medical dictionaries and vocabularies. There might be other innovative methods out there. And I’d like to hear about them.

The main use of classification codes such as ICD-10 and ICD-9-CM (in the US) include the following:

• patient billing and claims processing
• statistical collection, processing and analysis of clinical data
• handy search ‘tags’ for computerized medical records
• epidemiological and clinical research studies

When I explain this issue to doctors, this is what I say: ICD-10 codes are best used to ‘pigeon-hole’ specific groups of clinical diagnoses into common and agreed upon categories. This method helps ‘after-the-fact’ users of clinical information (billing departments, claims processing agents, health insurance companies and epidemiological researchers) to manage aggregates of medical data.

Someday we will find better clinical uses of classification codes. The production of ICD-11 is in process, reportedly using Web 2.0 principles. But, at this point, codes are still best treated as ‘pigeon-holes’ rather than true alternatives for free-text diagnoses.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man."
– George Bernard Shaw

Medical informatics is often described as ‘the intersection of clinical medicine and computer science‘. I’ve also used that phrase to define my chosen field. During my early years as a Healthcare IT professional, I carried in my head an image of a 2-circled Venn diagram.

At its most technical core, medical informatics is exactly that—an intersection of two scientific fields. It is the use of information and communication technologies (ICT) for the advancement of clinical medicine and the improvement of patient care.

However, after several years of professional practice and ‘difficult’ project implementations, I realized that most of the challenges in this line of work do not come from the complexities of clinical medicine or the technicalities of computer science. Most of them come from office politics, poor project management, lack of organizational leadership, inappropriate development methodologies and ineffective change management.

Dr. Paul Fontelo, my mentor at the US National Library of Medicine, once said to me during my postdoctoral training: ‘In this field, the science is the easy part; it is the politics of change that is hard.‘ I now realize how I severely underestimated the wisdom of that statement!

Research studies have already pointed out that many Healthcare IT projects fail due to organizational- or management-related issues. Healthcare IT implementations are seldom short-term projects with very little impact to the organization. They should be incremental projects based on long-term strategies. They should aim to improve clinical documentation, streamline process workflows and focus user behavior towards best practices.

So although the science of medical informatics deals with 2 intersecting circles, the art and practice of Healthcare IT demand a disciplined approach to the principles of management and leadership. And that is the third circle–the management of time, resources, organizations and people.

In the daily nitty-gritty of my work, management responsibilities eat up most of my time. Here’s a generalized sampler list of my job description:

• create long-term strategic plans for clinical applications of the hospital
• lead and manage teams during the development and design of clinical applications
• evaluate new technologies and vendor software for possible adoption
• lead the HL7 integration team to ensure interoperability among disparate systems
• initiate and conduct research and development (R&D) activities
• interact, collaborate and coordinate among hospital users, IT development team and hospital management to ensure success of project implementations

Like most doctors, I never had any formal training in management. I had to learn on the job. I had to drive myself to study how to get the right things done, how to manage time, projects, people and resources, how to set priorities, and how to make effective decisions. I learned to love the books and teachings of Peter Drucker, David Allen and Michael Porter.

While the field of Medical Informatics aims for continuous improvement of patient care, the Healthcare IT professional should target continuous learning and relentless application of management principles and organizational leadership. There is no other way to be good at this specialty. It is not enough to want change. We should be ready to expect change, manage change—and even initiate change.

So here’s my piece of advice to those who are just entering the Healthcare IT profession, do not satisfy yourself with the ‘science’ of the job. The secret to success lies in the ‘art’ of becoming a good leader and manager. If you carry only 2 circles in your mind, you are going into battle with 1 weapon short of victory.

—

I’d like to hear from you. What kind of organizational and management challenges did you encounter in your Healthcare IT implementations? What lessons did you learn?