Beyond Medical Informatics

For 2012, these are SOME the things we will be working on here at The Medical City:

Telemedicine

We are looking at improving and expanding the healthcare services of The Medical City including the satellite clinics and provincial hospitals (TMC Iloilo and TMC Angeles).

MID OMRI

OMRI is the document management system for our medical records. This is were scanned images of previous patient charts are stored and managed by the Medical Information Department (MID). We plan to improve the interface, features and security of the program to allow access into the system from the various nursing units and clinical areas.

ICARUS Medication Management

The ICARUS system is our medication management system that uses barcode technology. It is deployed in all nursing units. Full compliance is a bit challenging. Poor Wi-fi coverage for the handheld units also need to be addressed. This year, ICARUS will have to be "re-implemented" to get more units to adopt the system and increase compliance.

Once ICARUS is "re-implemented", we can work with NSO for more IT projects that improve nursing workflows.

Laboratory Information System

Plans for this year include fully implementing the Microbio, Blood Bank and Histo-Cyto modules. We may need to look into building another system for Blood Bank to handle donor management.

HL7 integration of the system with SHAMAN (ADT and OMG) and PRIME (ORU) is also planned for this year.

PRIME Phase 1 Roll out

PRIME stands for Patient Records and Integrated Medical Exchange. It is our clinical data repository and electronic medical records platform. We just finished development December 2011 and we plan to roll this out in the ambulatory units within the year. First pilot implementation is at Wellness. Wellness should be working with the system by February 2012.

Roll out of the clinical documentation feature to the other ambulatory units should commence by mid-Feb or March 2012.

PRIME Phase 2 Development

There is still more to be done with PRIME. We have just touched the surface for what we need in clinical documentation and electronic medical records. Phase 2 will incorporate the clinical research agenda of the hospital.

PRIME Results Integration

We need to integrate the following systems with each other: SHAMAN, MUSE (ECG System), Laboratory Information System (LIS), OMRI, ICARUS Medication Management and PRIME.

—

This blog post is to help disseminate information among doctors and clinicians of TMC.

As always, I welcome comments, suggestions and questions. I also encourage active participation of clinical units in our efforts.

Thanks!

Hey, I almost missed this one! I recently found out that HL7 version 2.7 came out in May 2011. As an HL7 advocate and implementer in the Philippines, I should have kept tabs on this.

Version 2.7 represents HL7′s latest development efforts to the line of Version 2 Standards that date back to 1989. Due to its widespread use, Version 2 will, no doubt, continue to play an integral part in healthcare messaging, even with the HL7 Version 3 Normative Edition. HL7 is committed to supporting and extending Version 2 in parallel with Version 3, providing continuity for current installations.

The changes look interesting. Read more about it at the HL7 version 2.x site.

(Now, try saying HL7 version 2.7 seven times…)

—

I welcome HL7-related questions for HL7 implementations and integration projects here in the Philippines. Just send me an email!

I gave a talk at the recent Hospital Build Asia 2011 conference in Singapore. I also stayed for the other topics. Two topics I found interesting were clinical data repositories and integration/interoperability standards.

Here are some of the lessons I learned. These are NOT verbatim content. They are from my memory and personal interpretations of the presentations.

Clinical Data Repositories (CDR)

• It had different names during the conference, e.g. Vendor Neutral Architecture, Common Data Repository, Carestream product, but they all shared the same concept.
• They implement an information exchange (IX) software to accept all incoming data.
• The information exchange (IX) software can be a middleware, integration platform, custom software or integration engine. Most common software used here in Singapore is Cloverleaf.
• The IX is setup for both international standards and customized interoperability protocols.
• CDR implementations can either handle clinical data and reports only (text) while others can implement redundant DICOM repositories.

Integration and Interoperability Standards

• In Singapore, even for the National EHR implementation, there are no HL7 v3 implementations.
• Most commonly implemented standards include HL7 v2.x and DICOM.
• But there are a lot of customized XML schemas implemented for documents not available in HL7 v2.x.
• They did not focus on "ideal standards". They avoided theoretical concepts in discussions of standards because it would be almost impossible to force compliance. Plus, they don’t have time to wait for everyone to comply to their "ideal standards" recommendation.
• Instead, they did a survey among hospitals, vendors and other stakeholders for interoperability standards available and/or ready for implementation.
• They also avoided theoretical discussions of implementations. Instead, they’d recommend putting viable ideas through proof-of-concept (POC) activities to provide more tangible better results.
• Decisions are made based on currently available data and results of POC activities.

That’s it. There were other lessons learned about other topics but I focused on these two because they were most useful to my current project plans.

I will be giving a short lecture on Interoperability and HL7 v2.x.

Here are more details:

Principle of Interoperability and Introduction to HL7 v2.x
May 5, 2011 Thursday 5:30pm-8:00pm GMT+8 (Manila, PH)
Exist Techbar at 5/F Orient Square Building, Ortigas Center

Find more information here: http://info.exist.com/interoperability-hl7/

Thanks!

My team and I are now working on HL7 capabilities for The Medical City (TMC). Let me just share the tools I use for HL7 integration work. I’m sure other people will find the list useful.

Most of my work involves HL7 v2.x.

Integration Engine

• Mirth Connect – I primarily use Mirth Connect for integration testing and implementations.

Basic Editing Tools

• Notepad++ – For direct editing of HL7 text files.

XML Editing Tools

XML is an important part of using Mirth Connect. Both editors are free.

• XML Marker
• Exchanger XML Editor

HL7 Editors

• HL7 Tool – A rather rudimentary HL7 tool for editing HL7 text but it works!
• HL7 Inspector – Allows viewing of HL7 v2.x messages in tree structure.
• QuickViewHL7 – Another HL7 v2.x tree viewer with added features.

It also goes without saying that the team should have the right reference materials (HL7 documentation and Application Connection Sheets) during implementation.

I’d be happy to hear about the tools you use.

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?

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.