Beyond Medical Informatics

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!

I’ve been working with HL7 for the past 3 years. And although I am not an expert (yet), I know enough to have successfully integrated several systems, including legacy ones, using HL7 version 2.x.

Project sponsors and stakeholders often have many misconceptions about HL7—what it is, what it does, and what it can do. Below are some of the common misconceptions I’ve encountered.

Misconception 1: HL7 is a software.

“How do we install HL7? Is the software free? Where can we download it?”

HL7 is NOT a software. It is a messaging standard. Something like a common language among systems so they can understand each other.

For the non-IT side of the healthcare business, IT is about software and hardware. If HL7 is not hardware, then it must be software. Otherwise, why all the fuss about it?

Correcting this misconception involves impromptu lectures about system communication and messaging protocols. About integration and interfaces. About stand-alone systems sharing information.

Still, HL7 integration commonly involves software. Some of these software can be interface engines, messaging platforms and file managers. We use Mirth Connect as our HL7 interface engine.

Misconception 2: Integration is easy with HL7.

“I thought you were using HL7. Why are you still having integration problems?”

Healthcare IT integration projects will always be challenging. HL7 makes it easier but NOT easy.

Choosing HL7 is like going to a grueling negotiations meeting with an agreement to talk in English. It’s a good starting point, but it doesn’t guarantee a win.

Decisions, processes and activities in HIT integration projects can include database preparations, staging tables, data dictionaries, field-to-field mapping and data migration. The integration may use HL7, but critical errors in these other areas can kill a project.

Misconception 3: HL7 compliance is a sign of quality software.

“If it’s HL7-compliant, it must be good!”

Project clients, vendors and even Healthcare IT professionals can have this misconception. HL7 addresses the need for a common protocol between systems. It does NOT address the features, functions and usability of the software itself.

HL7 compliance doesn’t even mean seamless integration. It just means the software has methods of handling HL7 messages—hopefully both incoming and outgoing. Sometimes, those HL7-compliant systems can be the most challenging to work with because their compliance is based on strict usage and formatting standards of specific segments and fields. They become too compliant to their own HL7 implementation, they become inflexible when working with other systems.

***

I had to deal with plenty of misconceptions—and even misgivings—about HL7 in my projects. I’ll share some more in future posts. And maybe include some lessons learned.

On another note, a lot of successful local HIT integration projects use customized protocols. Why? Because HL7 is not that well understood. So there are lots of opportunities for HIT standards education and advocacy. And that’s a challenge I’m ready to take head on.

===

What misconceptions (and misgivings) about HL7 have you encountered? How did you deal with it? What are the challenges in educating people about HIT standards?