Beyond Medical Informatics

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!

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?

When I have time to get my mind out of my hospital work, I sometimes wonder about national Healthcare IT initiatives. Where are we as a country in terms of Healthcare IT adoption and implementation?

First off, I don’t have the answer. Second, it is not a rhetorical question.

Health IT is now a ‘hit topic’ in US headlines, mainly because of the Health IT component of the US Stimulus Package. In my HIT List for June 20, I posted an article about Sweden launching a national electronic health record. According to Wikipedia, there are other nationwide projects in the UK and Canada.

Well, what about the Philippines?

The National Telehealth Center (NThC) is at the forefront of national telemedicine projects. And it is doing a very good job. But what about Hospital Information Systems (HIS) and Electronic Medical Records (EMR) adoption?

HIS and EMR adoption may be still be very low among Philippine hospitals, both public and private. Administrative, financial and inventory systems might exist but clinically-relevant applications might be sparse. I hear there are several pockets of successful clinical databank implementations, but data integration and interoperability are still monumental challenges.

Beyond a formal study of national EMR adoption, we can start doing benchmark exercises in our own organizations to see how we compare against US standards. It gives management valuable insight into what still needs to be done.

Benchmarking

Here are 2 good online resources to start benchmarking:

1) CDW Healthcare IT Checkup

The site is basically an online questionnaire. It guides the user to answer several questions about the organizational implementation of client technologies, IT infrastructure and clinical applications. Once completed, a conclusion and graph is shown to compare your hospital against CDW’s data on US hospital IT standards.

2) EMR Adoption Model from HIMSS Analytics

From the site: “HIMSS Analytics, the authoritative source on EMR Adoption trends, devised the EMR Adoption Model to track EMR progress at hospitals and health systems. The EMRAM scores hospitals in the HIMSS Analytics Database on their progress in completing the 8 stages to creating a paperless patient record environment.”

The EMR Adoption Model (PDF) and the EMR Adoption Model Descriptions can also be seen accessed, downloaded and studied for uses beyond benchmarking. It gives a rough draft of what is possible, what applications build on each other and what activities need to be done at a certain stage.

The 1st site is relatively new, but the 2nd one provides US benchmark data from as early as 2006.

National Discussion

I think we should start a national discussion on HIS and EMR adoption and implementation. The HIT advocacy by different groups and people are still ongoing, but it may be time to step it up a notch.

Benchmark data allows us to compare against other countries and establish a baseline. But we are not in a race with other countries. We are in a race with ourselves. So, the point of the exercise is not about catching up. It is about imagining possibilities, proposing local and national initiatives, and coming up with ways to improve delivery of care with the help of information technology.

Knowing where we are is NOT as important as knowing where we want to go.

—

Do you have your own online resources (or maybe offline articles and studies) to benchmark your HIT activities?

Do you know of national initiatives to promote HIS and EMR adoption? How do we jumpstart one? How do we improve efforts in HIT advocacy?