Beyond Medical Informatics

Early adopters of EMR and other Healthcare IT applications are keys in promoting EMR adoption. This is what an article calls the ‘social contagion’ theory.

Here’s the article: Doctors tech adoption influenced by social circle – American Medical News.

Hospitals will find this part useful:

The Management Science study ran statistical models and mathematical equations involving 3,989 hospitals to determine which would be the influencers and which would be influenced. One conclusion was that smaller hospitals’ use of EMRs was more likely to influence bigger hospitals’ use, rather than the other way around.

Much of the issue came down to resources. A smaller hospital might hear of a larger hospital’s success with an EMR system, but it might not have the resources to purchase one. However, researchers said a larger hospital has the financial resources to act if a smaller hospital had paved the way.

This concept might work for the Philippines. Sometimes, smaller hospitals in provinces are more aggressive for Healthcare IT growth. Their successes should be documented and broadcast to influence bigger hospitals.

Even HIT adoption among individual physicians is not immune to the ‘social contagion’:

The authors surveyed the physicians and residents to determine what social factors influenced use of the EMR, looking at the effect of professional relationships, "a friendship network based on personal intimacy," and "a perceived influence network" based on doctors’ perceptions of how other people affected their decision to adopt.

The study’s finding that personal relationships were the biggest influence on EMR adoption echoed the results of past studies on physician adoption of other technology. This was one reason researchers said they were confident in their results despite a small sample size.

I will have to consider the ‘social contagion’ concept during HIS implementations. The EMR project teams should identify physician champions not only for their ability to appreciate the use of technology but also for their ability to influence peers and colleagues.

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!

Singapore moves forward with their National EHR Project.

Singapore Awards US$144M EHR Contract

A consortium made up by Accenture, Oracle, and Orion Health has won Singapore’s National Electronic Health Record project, a credible source has told FutureGov.

…

The National EHR project aims to connect all the EMRs in Singapore and achieve the “one patient, one record” vision.

Healthcare IT professionals all over the Asia-Pacific region should watch the progress of this project closely. I know I will. I can only hope we can start something similar in the Philippines.

From: PubMed Advanced Search Page Modified. NLM Technical Bulletin. 2010 May–Jun.

The PubMed Search Builder section of the Advanced Search page will soon be modified to provide users with a more cohesive method to build searches.

This should help make searching easier. I should start upgrading my PubMed searching skills.

—

Found a new e-Journal: Applied Clinical Informatics

ACI (Applied Clinical Informatics)

As the Official eJournal of IMIA and AMDIS, the online journal ACI will publish approximately 100 peer reviewed articles per year. It aims to establish a platform that allows sharing knowledge between clinical medicine and health IT specialists worldwide as well as bridging gaps between visionary design and successful and pragmatic deployment.

…

The core editorial subject matters of ACI are: Clinical information systems (including electronic medical records and systems, personal health records, physician/provider order entry, electronic prescribing, clinical decision support, nursing information systems, patient scheduling and tracking tools, lab information systems, radiology information systems, PACS, GP information systems), administrative and management systems, eHealth systems, information technology development,  deployment, and evaluation, socio-technical aspects of information technology and health IT training.

The target group of ACI is an international and potentially very influential readership, e.g.: Chief Information Officers, Chief Executive Officers, Chief Financial Officers, Medical Informatics Researchers, Nurse Informaticians, Consultants, Public Health Officials, Vendors, IT Safety Healthcare providers, Informatics trainees as well as organizations such as IMIA , AMDIS, AMIA, HIMSS or the equivalent.

I hope I get to read some of the articles. Access is not free so I will have to borrow from some friends.

—

This bit of news caught my eye: California hospital says it’s first to self-implement VistA

I recently found my AMIA 2005 conference notes in one of my old notebooks. One entry read:

WorldVista Insights

• Network is System (for quality improvement)
• Deploy a process not a product
• Feedback loop is path to improvement

(Note: The parenthesis and underlines were also in the notes.)

The first line is cryptic and the third one is self-explanatory. But the second one, despite being 5 years old, remains relevant and is worth repeating.

Deploy a Process NOT a Product

Many IT project teams attack Healthcare IT implementations with a product mindset. This is a legitimate mindset, of course. Why? Because many successful Hospital IT projects start out as product implementations, such as HR or financial systems.

But Healthcare IT applications are different. They are not simply IT projects, they are clinical process improvement projects. Therein lies the difference. Let me expound with these 3 points:

Point 1: The IT product is NOT the project. The software application should integrate with clinical workflows and processes. The IT system does not–and should not–stand alone independent of patient care outcomes.

Point 2: The true project success criteria is outside the IT system. Unless the system helps the healthcare team accomplish ‘offline’ clinical tasks and patient care responsibilities, it is useless.

Point 3: Effectiveness is the key to project success–NOT efficiency. The Healthcare IT project should aim at making the clinician MORE EFFECTIVE in his work. Efficiency is useless unless it delivers the right results. An IT product can only promise efficiency NOT clinical effectiveness. Integrating process improvements with IT implementations can help ensure BOTH effectiveness and efficiency.

There are no shortcuts in Healthcare IT projects. Many failed attempts come from focusing too much on implementing the product rather than improving patient care processes.

As an old IT saying goes: ‘Don’t implement solutions. Solve problems.’

===

What other pitfalls do we encounter in HIT projects? What other mindsets do we have that contribute towards challenging implementations?

Last Nov. 16 to 21, 2009, we visited three US hospitals: Stanford University Medical Center in Palo Alto, CA, Children’s Hospital Boston in Boston, MA and Brigham and Women’s Hospital also in Boston, MA. We chose to visit these organizations because they are Stage 6 Hospitals in the HIMSS EMR Adoption Model.

This was our schedule:

Nov. 16: Arrive San Francisco from Manila
Nov. 17: Stanford University Medical Center
Nov. 18: Flight to Boston
Nov. 19: Children’s Hospital Boston
Nov. 20: Brigham and Women’s Hospital
Nov. 21: Flight to Manila via Boston-Detroit-Nagoya

I know, the trip was undeniably tiring. I had to fight jet lag, mental fatigue and body aches (mostly from the economy airline seats) all throughout the site visits. But overall it was one great learning experience.

Below is a summary of the recurring lessons we gathered from all the hospitals.  Items in bold are lessons that I feel are not so common and therefore need more emphasis.

Don’ts

• Don’t think of Healthcare IT projects as IT projects. They are, at the core, clinical process improvement projects aimed at improving clinical quality and patient safety.
• Don’t expect to achieve anything substantial:
  • in 1 year or less. Successful hospital IT projects take time.
  • without a governance structure.
  • without engaging users at the RIGHT level and RIGHT context.
• Don’t do too many IT projects at the same time. It taxes hospital resources and might cause ‘project fatigue’ among users and staff.
• Don’t force compliance. Forced compliance is not buy-in.
• Don’t be afraid of failure or risks.
• Don’t expect a perfectly-executed and problem-free implementation.

Do’s

• Align IT projects with organizational strategic initiatives. This helps ensure executive sponsorship.
• Create a well-thought out governance structure. Get the right people responsible for decision-making.
• Manage project and resource priorities through the governance structures. Avoid bypassing the decision-making process.
• Build the right teams around project champions. Identify project leaders.
• Make sure users are represented in the governance and decision-making process.
• Engage users at the RIGHT level. Let MDs talk to MDs. Nurses talk to nurses.
• Engage users at the RIGHT context. Understand how the systems interact with their organizational structures, processes and teams. IT systems in hospitals do not ‘work alone’.
• Plan properly. Planning takes time and involves many stakeholders.
• Manage user expectations all throughout the implementation. Involve the project leaders/champions in managing user expectations.
• Do include a ‘stabilization’ stage after implementation. This gives the hospital staff ‘breathing space’ to adopt (and adapt to) the new processes brought by the IT changes.
• Consider staged or phased implementations. This lessens the risk of ‘big bang’ failures, requires lesser implementation resources and avoids ‘project fatigue’ among hospital staff.
• Consider IT projects as collaborative endeavors between IT and users.
• Expect problems. Be ready for them.

My biggest take away from all of these is the importance of governance in hospital IT projects. For these hospitals, the responsibility for project prioritization has moved from the hospital administration and operations to the clinical staff. The clinical staff, therefore, had to work with hospital leadership and IT to create governance structures for their needs.

All three had different governance structures, which means that there is NO silver bullet for the right one. But having a hospital IT governance structure that aligns projects with key strategic initiatives, focuses on patient safety and allows user representation in decision-making increases the chances of success.

—

Do you have other Health IT lessons worth mentioning? What lessons did you learn from your own implementations? Please share them below. Thanks!