Beyond Medical Informatics

It’s been over a month since I last written for the blog.

My life as a CIO has been very busy. The past few weeks much more so. Some of my recent activities (I’ll write about them soon) include:

• Continuing development and design of TMC PRIME—the EMR platform we are developing.
• TMC Quality Fair Week where we had a booth that featured TMC PRIME.
• Implementation of Google Apps—Yes, TMC is now on GMail!
• Initial wrap-up of 2011 projects for Year-To-Date IT accomplishments (in preparation for budget planning).
• Initial project planning for next year’s budget.
• Initial brainstorming for restructuring of IT Department.

The last one has been in my mind for several months now—probably since I started work as CIO. I found our IT organizational structure to be rigid and unwieldy. I had a hard time responding to critical IT requirements and situations. Projects were not managed or monitored well. Some projects slip through the cracks of proper implementation.

Then it dawned on me. For several years, the main IT project was the hospital information system (SHAMAN). This system started out small but has since become the workhorse of hospital operations. And the IT department was almost exclusively organized around this application—to the detriment of other IT projects.

I shared this with my IT managers:

We have an IT department that is structured to support a single software.

That can’t be. We need to change that. We have other IT projects aside from SHAMAN, like:

• HL7 Integration Platform
• Clinical Data Repository Platform
• Clinical Documentation Platform
• Business Intelligence
• Document Management Systems

Our users also have other IT plans like:

• Improved charge capturing using mobile devices
• Improved medication management
• Online surveys and patient feedback forms
• Research and patient registries

So, I pose this challenge to my IT management team.

Let’s build an IT organization that supports the whole organization including the network of clinics and hospitals we serve.

It will not be easy. Our initial thoughts focus on the following areas:

• Strengthen the IT management team with focus on strategic planning, initiatives and relationship-building.
• Build project management and systems analysis core competencies among the staff.
• Build technical core competencies for the core technologies used.
• If possible, outsource some IT services, e.g. technical support, specialized programming.

Let’s hope we succeed.

Next year will be an exciting year!

This article, ONC releases five-year strategic health IT plan, provides some goals to get a National Health IT plan started. The goals include:

• Achieve adoption and information exchange through meaningful use of health IT
• Improve care, population health and reduce healthcare costs through the use of health IT
• Inspire confidence and trust in health IT
• Empower individuals with health IT to improve their health and the healthcare system
• Achieve rapid learning and technological advancement

These goals are definitely something we can use in the Philippines. I think the ICT4Health efforts have similar goals.

The best next step is to formulate an action plan for each goal.

On a more personal note, these goals are not "confined" to the national level. With their broad practical application, even hospitals and other organizations can adopt these goals.

Seems like my 5-year strategic Health IT plan for The Medical City is off to a good start.

Dr. John Halamka shares his top 10 leadership principles for surviving as a CIO via Life as a Healthcare CIO: A Customer Emotion Dashboard.

10. Select your change and what not to change
9. Identify those who will lose
8. Acknowledge their loss
7. Over Communicate
6. Be Honest and Consistent
5. Consensus is not essential
4. Embrace conflict
3. Focus on your detractors
2. The last two minutes of the meeting are the most important
1. You cannot please everyone

Our IT department will have to face daunting challenges in 2011. Our IT services need to transform and improve. Tips No. 10 and No. 7 are important.

Once all strategic and operational plans are set, I will over-communicate like hell.

“Over-communicate, over-engage, over-inform.” That’s my new motto.

Early adopters of EMR and other Healthcare IT applications are keys in promoting EMR adoption. This is what an article calls the ‘social contagion’ theory.

Here’s the article: Doctors tech adoption influenced by social circle – American Medical News.

Hospitals will find this part useful:

The Management Science study ran statistical models and mathematical equations involving 3,989 hospitals to determine which would be the influencers and which would be influenced. One conclusion was that smaller hospitals’ use of EMRs was more likely to influence bigger hospitals’ use, rather than the other way around.

Much of the issue came down to resources. A smaller hospital might hear of a larger hospital’s success with an EMR system, but it might not have the resources to purchase one. However, researchers said a larger hospital has the financial resources to act if a smaller hospital had paved the way.

This concept might work for the Philippines. Sometimes, smaller hospitals in provinces are more aggressive for Healthcare IT growth. Their successes should be documented and broadcast to influence bigger hospitals.

Even HIT adoption among individual physicians is not immune to the ‘social contagion’:

The authors surveyed the physicians and residents to determine what social factors influenced use of the EMR, looking at the effect of professional relationships, "a friendship network based on personal intimacy," and "a perceived influence network" based on doctors’ perceptions of how other people affected their decision to adopt.

The study’s finding that personal relationships were the biggest influence on EMR adoption echoed the results of past studies on physician adoption of other technology. This was one reason researchers said they were confident in their results despite a small sample size.

I will have to consider the ‘social contagion’ concept during HIS implementations. The EMR project teams should identify physician champions not only for their ability to appreciate the use of technology but also for their ability to influence peers and colleagues.

Many HIT4Dev proponents fixate on a comparative set of HIT applications between more advanced countries and developing countries. They emphasize finding free and open source alternatives as a way to bridge the gap.

It’s too simplistic to think of the gap as a list of software applications. That’s like the proverbial blind men and the elephant. Software is just a small part of the problem.

The gap is less about the WHAT and more about the WHY. It is less about having applications but more about being ready for them. Some of the things to look into include:

• what they have (technology, applications)
• what they do (processes, operations, activities)
• what they are (culture, values, advocacies)

Understanding the endpoint—the destination—increases awareness of the problem. But bridging the gap involves studying the gap itself—the journey.

The script should NOT be “They have an EMR. Let’s get ours too.” Instead, it should be “They have an EMR. Do we need one? Are we ready for it?”

Asking what others have is a good start. But more important questions should come in:

• how different is their situation?
• what problems did they encounter and solve along the way?
• what opportunities were presented to them?
• what caused the failures?
• what contributed to the successes?
• what were their strengths and weaknesses in each stage of the journey?
• how did they manage change?
• where are we right now?
• where do we start?

This exercise should lead to answers that generate both long-term goals and short-term targets. It should identify the next steps. You’d find out that the “major major” task is more about creating a mindset that’s ready for change and less about implementing software. It is more about engaging stakeholders in discussions about their problems rather than pushing open source solutions. It is more about understanding where you are in the journey and less about focusing what others have in the destination.

The HIT4Dev gap is an important problem to address. Getting to the right solutions starts by asking the right questions.

—

Comments? Objections? Violent reactions?

I’d like to hear your thoughts on this matter. Post them below. Thanks!

Recent email discussions got me thinking about the challenges of implementing Healthcare IT for developing countries (HIT4Dev). The basic assumptions of HIT4Dev include the following:

• The US (and other western countries) are more advanced in HIT concepts and implementations.
• Because of this, they are models for HIT implementations.
• Compared to these models, the developing countries lag behind.
• There is a palpable gap.
• HIT for developing countries (HIT4Dev) try to bridge this gap.

Here are 5 tips to help meet the challenges of bridging the gap and implementing HIT for developing countries:

1) Know what can work for developing countries.

With so much HIT updates today, it’s challenging to identify the ones applicable for Philippine settings. Not every technological advancement is relevant. Many implementations and applications brought about by US regulations may not hold true for the Philippines.

A good example would be the US HIPAA regulations. The concepts behind HIPAA are legitimate, yes, but direct compliance does not provide immediate or relevant impact to local implementations as of yet. It would be a foolish waste of resources to work on that given other areas for improvement.

2) Know why it worked.

Don’t stop knowing the “What”. The biggest lessons from successful HIT implementations in other countries are in the “Why”. Understanding and insight are the best tools in bridging the gap.

Being a copycat is a sure recipe for failure. Know what factors and concepts made it work. Know the conditions wherein it will NOT work. Get a clear handle of the ‘because’ of HIT implementations and activities, e.g. “Let’s do this BECAUSE…”, “Let’s not do that BECAUSE…”

3) Identify relevant target results.

After a thorough study, ask yourself these questions:

• What tangible results can I get out of the implementation?
• What specific deliverables provide the most relevant impact?
• What measures of success matters to the local users and stakeholders?

Get the successful US model and break it down into workable and relevant targets. As the saying goes, “You eat a whole elephant one bite at a time.” Just make sure the bite is something you can chew and use.

4) Understand ALL the components of the gap.

Understand that the gap is not specific to Healthcare IT because clinical applications do not exist in a vacuum. There are technological advancements, organizational dynamics, societal changes and governance structures that contribute towards the gap. These other things matter.

Focusing on clinical applications without understanding the non-clinical environment in which it thrives is a big mistake. Many HIT4Dev teams make that mistake.

5) Go beyond funding as the solution.

“If we only had funding, this problem would be solved.” How many times have we heard that?

People who think that way when trying to bridge the gap are simpletons.

The simplest problems are those where funding is the solution. They are easy to solve. But many problems are not that simple. Pouring money into a problem does not solve itself.

Take money out of the picture when solving problems. And you’ll find the real solutions worth funding.

—

Comments and violent reactions? Do you have other tips for HIT4Dev teams? 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.