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!

Last Thursday, September 15, 2011, we had an IT Department (ITD) staff meeting. I wanted the IT staff to appreciate what the department accomplished for The Medical City in the past year. This was also an exercise to improve our intra-departmental communications.

After the managers of the different sections of the department—development, SQA, support and technical—shared their activities and accomplishments, I presented possible projects and activities for next year. I also expressed the need to be more focused and proactive to ensure successful implementations.

I also wanted to end the meeting with an inspiring message. So I shared the Serenity Prayer:

Grant us the serenity to accept the things we cannot change, the courage to change the things we can, and the wisdom to know the difference.

I highlighted the three concepts—serenity, courage and wisdom—and then told them that the prayer was wrong.

First off, the prayer got the order of the 3 concepts wrong. Starting with “accepting things we cannot change” is not serenity—it is surrender.

Second, it’s misleading to call it the Serenity prayer when what we need to change the world is courage. It should be the Courage prayer. I wanted my IT Department to have balls!

Lastly, the wisdom part assumed it was easy to know the difference. It is not.

So, how do we know which ones we can change and which ones we cannot?

The answer: We don’t know—and won’t know—until we try.

Therein lies the true wisdom: Going through life with the conviction to MAKE a difference is the only way to KNOW the difference.

So, I rewrote the prayer for our IT Department. I rewrote it matching the order of things we need to continually support the operations of the hospital, contribute towards better patient care and forge the way into the future.

Here it is:

Grant us the wisdom to make a difference, the courage to change the things we can change and the serenity to accept the things we cannot.

Our work in Health IT is not easy. We should first be wise enough and brave enough to challenge the status quo. Serenity should be our last resort.

Amen?

Amen.

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.