Beyond Medical Informatics

Health IT work is not easy. Projects are aplenty and deadlines pile up. Most days are manageable, but some days we try our best to get any semblance of control. On rare occasions, work can feel overwhelming, not only for us but also for our teams and our organization.

When this happens, I take time to sit back, relax and rethink work priorities. I have 2 questions that help me get grounded.

• What’s the problem?
• What needs to be done?

When I can, I share these 2 questions with my team to help them cope with the amount of work we have in our projects. A quick 5-minute run-through of these questions at the start of a task or activity puts the mind in the right focus.

The Why

The first question answers the ‘Why’ aspect of the task, project or activity. Of course, it doesn’t always have to be a problem. Here are several variations of the question:

• What specific problem are we trying to solve?
• What opportunity are we trying to take?
• What technological advantage are we trying to maximize?
• What change do we want to start?
• What business goal are we trying to achieve?
• What is the core purpose of the next task?
• Why the hell are we doing this?

The important point is that you know WHY you are doing something. When you know WHY, you have the much-needed ‘clarity of purpose‘ for the work. This clarity helps identify priorities that should be considered–and items that should be discarded.

The What

The second question answers the ‘What’ aspect of the job. It identifies the outcome and helps set specific tasks and deliverables. Here are several variations:

• What needs to be done?
• What is the specific outcome of this task?
• What is the output of this activity?
• What does ‘done’ look like?
• What’s the deliverable?
• What should I have at the end of this task?
• What the heck should I do next?

This process gives me what I call the ‘clarity of process‘ or the ‘clarity of product‘. It is basically an exercise of outcomes visioning. The more concrete or tangible the outcome, the better. Knowing how the end looks like can give us a good idea how to start.

===

In my future posts, I’ll share a real-life sample of this process and other questions that come after this exercise.

How do you keep projects moving in the right direction? How do you maintain focus? What advice can you give? Please post them below. Thanks!

Sometimes people fall in love with one technology, methodology or framework. This can get very frustrating. In one of my projects, one integral team member could not find it in himself to detach from his proposed solution. We spent 3 precious weeks discussing possible options and he spent the same 3 weeks defending his approach. We were at a stalemate.

I had to force my decision on the team to abandon the proposal and look for a different approach.

It’s hard to admit you are stuck. Sometimes you just don’t realize it. Here are possible clues to see if you’ve fallen in love with your idea/solution/technology:

• People endlessly ask you to be open-minded about other approaches or solutions.
• More than 50% of project activities involve changing your mind, helping you identify things you haven’t considered and making you realize there might be other possible solutions.
• You find yourself defending your idea in most meetings AND you are NOT even slightly considering the other options presented.
• People consistently say your idea is NOT wrong, it’s just inappropriate for this problem.

Sir Thomas Robert Dewar (1864 – 1930) once said that “minds are like parachutes, they only function when they are open.”

Here are practical ways to get unstuck:

• Realize that there are very few problems in this world with one and only one solution. There are also very, very few solutions with one and only one way of execution or methodology.
• Get more data. Describe the problem as detailed as possible. Find out if your solution answers all possible scenarios.
• Get a lot of feedback. Foster a culture where people can give you feedback or test your idea.
• Allow people to prove you wrong—AND really consider their input.
• Brainstorm for other ideas. Do not criticize initial recommendations, ideas and suggestions.
• If you find yourself constantly ‘force-fitting’ your solution to different scenarios of the problem, it might be time to drop it and find another solution.
• Consider your solution wrong. What are the implications? What possible ways are there to attack the problem?

Closing our minds to a single solution closes opportunities for a more successful project implementation. Don’t have a big ego. It takes courage to admit we are wrong. It takes even greater courage to admit other people may be right.

Be brave. Be open.

===

Do you have similar experiences with project teams? How did you get your team ‘unstuck’?

During my lecture on eHealth Project Management, I mentioned that getting the right people improves chances for project success.

Here’s the quick advice: Get the right team members assigned to the right tasks according to their strengths. Get the right employees trained not only for current projects but also according to their career paths and the future needs of the organization. Get the right stakeholders and sponsors involved in the project.

When buildling a team, I look for specific characteristics from individual members. Beyond the basics of the job description, e.g. a programmer should know how to program, I make sure they have the ‘right stuff‘, which includes:

• Ability to adapt to change: A person that’s too rigid or structured in thinking may not belong in a field where change is constant.
• Good communication skills: Communication is key to better collaboration.
• Problem-solver: Many Healthcare IT projects are IT solutions to real world problems, which makes problem-solving skills essential.
• Results-oriented: Understand the goal, find a way and do it.
• Independent thinker and worker: I have no time to babysit people. They need to think and work for themselves most of the time.
• Insatiable thirst for learning: This is very critical to me. Team members should always make an effort to improve themselves in different areas of their responsibilities–or maybe even beyond.

Healthcare IT projects often involve a lot of research and development (R&D). The team should be competent, agile and resilient. I make sure I have individuals who thrive in challenging situations.

What if you can’t get the right person or the right team?

Then, be the right person. Train to be the right team.

During our Laboratory Information System (LIS) implementation, we had to consider HL7 integration with our legacy Hospital Information System (HIS). We looked for experienced HL7 consultants in the Philippines. We even tried looking for programmers with possible HL7 experience. But after several futile attempts, we realized we had no choice: learn HL7 or try other integration methods.

We started by reading online materials, especially the official HL7 documents. We experimented, explored and examined. We became ‘HL7-hungry’, devouring all relevant HL7-related materials we can find. We also worked on Mirth, an open source HL7 interface engine. Eventually, I became the hospital’s internal HL7 consultant and we became the hospital’s first competent HL7 integration team. The bi-directional HIS-LIS HL7 integration was a success. Right now, we are looking into other integration areas using HL7.

I was fortunate to have a good team. We eventually became the right team needed for the job. But not everyone is as fortunate. Not everyone can get the right people. Not everyone can be the right team.

What if you are assigned to manage a project with existing team members? What if you do not have control over who gets on the team?

First, make sure the right people are assigned to the right task according to their strengths. This is a Peter Drucker concept worth repeating. Many employees want to contribute but many find themselves in the wrong positions doing the wrong things. Know your people, know what needs to be done and find the right fit.

Second, make it easy for your team to be the right team. Open avenues for learning and improvement. Open your mind to different training possibilities. Nurture a learning environment. Sometimes, on-the-job training and unorthodox learning methods work best for some people.

Finally, if all else fails, the ‘reverse advice’ is appropriate: get the wrong people off the team. I don’t mean firing them or asking them to quit their jobs. There are ways to do this without being drastic. One way is to transfer them to another team or project. Another way is to assign them responsibilities or tasks peripheral or not critical to the project’s core objectives. The important thing is not to let their incompetence get in the way of the team’s progress.

People move the project forward. The right people move it in the right direction.

—

What people challenges did you encounter when building your team? How did you get the right people involved in your projects? How do you handle problematic or incompetent team members? Please share your experiences.

Here’s a list of news, links and articles about Medical Informatics, Healthcare and IT that I found interesting this past week (May 17 – 23, 2009) .

AMIA Podcasts and Media
Podcasts and materials may not be so new but I just found out about this online resource this past week. It’s from the American Medical Informatics Association Website.

 Quest, Microsoft platform allows shared lab results
The 2 companies “created an infrastructure allowing patients and doctors to share diagnostic lab test results online”. I know some local laboratories have been doing this for some time now. They allow patients to create user profiles so they can access their results online. In the US, they have to adhere to HIPAA laws. Here in the Philippines, we don’t have any local HIPAA counterpart. Should there be one? I personally have my hesitations.

VA plans EMR-based project to study treatment effectiveness
The real value of electronic medical records is in improving clinical outcomes. However, the process of getting clinical outcomes involves comprehensive data capture, storage and analysis that only computerization can provide. Sometimes it can be a chicken-and-egg thing. That’s why buy-in from hospital management can be difficult if computerization is still in its early stages. Good thing there are studies—done and ongoing—that can help provide evidence. I’m excited to see the results of this one.

Patients willing to forgo some health IT privacy for availability
It’s always give-and-take. Here in the Philippines, unless one is a public figure, patients are not so concerned about privacy issues. I guess in a country where the basic delivery of primary care is still an ongoing challenge, healthcare IT privacy is the least of our concerns.

—

Is there an interesting Healthcare IT-related link you’d like to share? Please post them below. Thanks!

During the open forum of my talk on eHealth Project Management, I was asked to cite experiences with IT vendors from the perspective of a consultant of a major hospital. I focused my answers on two areas: working with IT vendors and tips on choosing an IT vendor. Let me elaborate further in this post.

Two General Categories

If the hospital follows the long-term strategy of "Build + Buy", IT vendors often fall under two general categories:

1. Software Development: These include companies that provide contractual employees, consultancy for in-house software development or outsourced application development. This engagement is for custom-built software such as hospital-specific clinical and research applications.
2. Product/Service Providers: These include vendors of administrative software, e.g. financial and inventory systems, and ancillary systems, e.g. PACS and laboratory information systems. Others may provide services for hardware support and software acquisitions.

Working Relationship

When working with IT vendors, I find it best for the hospital management and/or IT department to do the following:

• Treat them as partners. Make it easy for them to help you solve your problems.
• Make them accountable for their product–AND their promises. Honesty, integrity and truthfulness are essential ingredients for an excellent working relationship.
• Do not believe all their promises. Even with a good working relationship, understand that they are still in the business of selling.
• Pay on time. Help the company thrive.
• Make referrals. Help the company grow.
• Give feedback of their services. Help the company get better.
• Do not adapt their vision for your company. Come up with your own. Despite their good intentions, you know your company much better.
• Identify success and/or acceptance criteria during development or implementation. These items should be specific and measurable. This helps everyone look at the same direction.

Choosing an IT Vendor

Document and understand your hospital and project needs before going through the process of vendor evaluation. It is easy to be distracted by ‘product or service peripherals’. Come up with a standard for evaluation and stick to it.

Beyond that, here are some qualities I look for in the company and in its people:

• Excellent listening skills: They’re not only selling a product/service, they hear what you need and are sincere in helping you solve your problems.
• Experience, knowledge and skills: They should know their product and their customers. They should know what they are doing.
• Willing to learn: I admire organizations who invest in their people. They constantly strive to be better.
• Ability to walk away from a project: I like vendors who can say ‘No’ to a project. It shows honesty, integrity and an understanding of their company’s or product’s limitations and capabilities. The opposite of this would be vendors who promise to have or do everything.
• Accept defeat graciously: When other vendors are chosen, they still stick around and help with other projects. It reflects an organizational culture that wants to build relationships and not just a client base.

No healthcare organization is an island. Having the right IT partners can help the organization succeed in its process improvement, modernization and computerization efforts. The key is to choose wisely and maintain excellent working relationships.

These are just from my own limited experience. I’m sure there are more—and better—recommendations out there.

—

What’s your experience with IT vendors? Are they good or bad? How do you deal with the bad ones? What are your recommendations? Let me hear from you.

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.

"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?