Beyond Medical Informatics

(This is Part 2 of a modified version of a loooooong comment I posted in the FB group page of the Philippine Medical Informatics Society. Read Part 1 here.)

Making national policies on the Health IT tools and frameworks without identifying the target results and objectives is a mistake.

This mistake of a centralized level/policy of mandating technology is evident in recent news articles shared with the FB group. Here are quotes:

From Dismantling the NHS National Programme for IT | Media Centre (bold emphasis mine):

In a modernised NHS, which puts patients and clinicians in the driving seat for achieving health outcomes amongst the best in the world, it is no longer appropriate for a centralised authority to make decisions on behalf of local organisations.  We will continue to work with our existing suppliers to determine the best way to deliver the services upon which the NHS depends in a way which allows the local NHS to exercise choice while delivering best value for money.

The Department of Health said:

“The exchange of information between patients and clinicians and across the NHS is a fundamental part of how we are centring care on patients and making sure innovation and choice are fully supported.  The NPfIT achieved much in terms of infrastructure and this will be maintained, along with national applications, such as the Summary Care Record and Electronic Prescriptions Service, which are crucial to improving patient safety and efficiency.  But we need to move on from a top down approach and instead provide information systems driven by local decision-making.  This is the only way to make sure we get value for money and that the modern NHS meets the needs of patients.”

Sir David Nicholson, Chief Executive of the NHS, said:

“A modernised NHS needs information systems that are driven by what patients and clinicians want.  The NPfIT has provided us with a foundation but we now need to move on if we are going to achieve the efficiency and effectiveness required in today’s health service.  Restoring local control over decision-making and enabling greater choice for NHS organisations is key as we continue to use the secure exchange of information to drive up quality and safety.”

The Managing Director for Informatics at the Department of Health, Katie Davis, said:

“There are two important things we must achieve – the development of a vibrant marketplace for healthcare IT and clarity that we no longer manage delivery centrally unless there is a single, clear requirement across the NHS.  We have a great opportunity to build a new way of working which helps patients and clinicians gain the best value for public money.  I am instituting a full review of all Department of Health informatics applications and services to ensure that everything we do is compatible with these aims.  Later this autumn, I will announce what work will continue, alongside a framework for providing IT support to the NHS as it modernises.”

From Government to scrap NPfIT NHS IT programme today – ComputerworldUK.com (bold emphasis mine):

Health Secretary Andrew Lansley put the blame on the previous government. “Labour’s IT programme let down the NHS and wasted taxpayers’ money by imposing a top-down IT system on the local NHS, which didn’t fit their needs.

…

“We will be moving to an innovative new system driven by local decision-making. This is the only way to make sure we get value for money from IT systems that better meet the needs of a modernised NHS.’

I’m sure many of you are starting to see the point I am making: Having a clear set of results is MORE IMPORTANT than a clear set of tools. A centralized policy on goals and objectives that allow CHOICES in implementation tools is better than a centralized policy on tools and standards without clear goals.

But what about the HIT Standards Committee in the US? Why do they have that?

Well, the point of a policy is to create a call to action.

When government creates policies for target results and goals, what is the call to action? It is to stimulate problem-solving towards a common objective. It is about EFFECTIVENESS.

When government mandates processes, e.g. standards, technology and terminology, what is the call to action? It is to control proliferation of many solutions. It is about EFFICIENCY. When it comes to interoperability, the US is at this point for their HIEs.

So, what kind of policies does the country need most right now? Problem-solving or control?

Better yet, let’s go through our sample Health IT continuum (from Part 1) as a thinking exercise:

• What does a Health IT project for a single MD practice need? Problem-solving or control?
• What does a Health IT project for a group practice need? Problem-solving or control?
• What does a Health IT project for a small hospital with disparate systems need? Problem-solving or control?

How about a network of hospitals? A chain of ambulatory clinics? A network of government hospitals? A national EHR implementation? What do these Health IT projects need in the Philippine context? Problem-solving or control?

Go through each level and think:

• Have we identified common goals and results for each?
• Do we have the right information to start mandating a specific set of standards for each level of implementation?
• If we do have a National Set of HIT Standards or Framework, is this applicable for all levels of implementation?
• Finally, do we have a clear set of goals and results identified at the national level so that a National Standard or Framework makes sense?

I don’t think so.

Mandating the tools without first identifying the project objectives is like ordering a carpenter to bring only a hammer without first allowing him to ask, "What is it that you want to build? What do you want to achieve?"

Always, always, always use the right tools for the job. But show me the job first before I start gathering my tools.

(This is Part 1 of a modified version of a loooooong comment I posted in the FB group page of the Philippine Medical Informatics Society. Here is Part 2.)

Premise:
Some members of the group proposed that a National Health IT Framework with official standards, technology and IT systems design would improve the Healthcare IT situation of the Philippines. They compared how US HIT is in a mess because it did not have these national frameworks when they started working on their Health IT systems.

My short version reply:
The US situation statement is an oversimplification. And a source of wrong thinking. Everyone needs to get out of that thinking that IT-specific policies will ‘correct’ what’s wrong with the state of Health IT in the Philippines.

My long version reply:

Health IT implementations come in different sizes but should still reside in a continuum of complexity. Small scale implementations can start from 1-user EMRs to small hospital settings. Large scale implementations can go from hospital networks to national implementations.

The “IT Perspective” would be to look at the technology needs (frameworks, standards, etc.) that each level of implementation requires. But the “Management Perspective” knows that the critical factor is to identify the different goals, objectives and desired results for each level.

Here’s a good mental exercise at this point. What would be the goals and desired results of:

• a single doctor EMR system?
• an LIS-HIS integration project?
• a Cancer Center EMR?
• a clinical data repository for a network of hospitals and clinics?
• a National EHR implementation similar to Singapore?

Each one would have different goals, priorities and objectives as compared to the others.

My short version reply was about common misconceptions of the role of policies in Health IT. We compared the PH scenario with US scenario. And this is where most get it wrong.

Many advocated the creation of national level “IT Perspective” policies, e.g. what standards we should follow, what format, what technology, what system etc. But the US national policies did NOT start like that. They were crafted from a “Management Perspective”. They identified and mandated a set of results and goals. Here are over-simplified samples:

• Medicare required better clinical documentation. EFFECT –> This lead to boom in EMR and medical transcription. (Did they say how hospitals should implement it? Not really.)
• Health insurance required more accurate diagnosis codes. EFFECT –> This lead to adoption of DRGs, ICD9-CM, CPT. Will need software to manage.
• Joint Commission identified goals for different areas. EFFECT –> Different implementations possible to achieve results. Some use IT. Some do not. Using IT proved easier.
• HIPAA mandated security and privacy goals. EFFECT –> Mostly achieved by EMR software. (There is no HIPAA-compliant software, only HIPAA-compliant organizations. Organizations looked into IT to comply with regulations.)
• ARRA/Meaningful Use/HITECH defined goals—and incentives!—in use and adoption (NOT the technology or interoperability standards). EFFECT –> Increased rate of EMR adoption.

There are plenty more stories and samples from the history of Health IT in US and other countries that drive the point. Basically, they FIRST identified the RESULTS they wanted to achieve at the level they wanted to implement. The did not go and create a policy for standards and technology without first identifying the need for it.

Let me emphasize: Having a clear set of results is MORE IMPORTANT than a clear set of tools.

(Please proceed to Part 2 Conclusion.)

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.