The following appeared just a few days ago.
Good consultants, bad consultants
- John D. Halamka (Computerworld (US))
- 14 January, 2011 07:46
In 1998 when I became CIO of CareGroup, there were numerous consultants serving in operational roles both there and at its Beth Israel Deaconess Medical Center. My first task was to build a strong internal management team, eliminate our dependency on consultants, and balance our use of built and bought applications. Twelve years later, I have gained significant perspective on consulting organizations -- large and small, strategic and tactical, mainstream and niche.
One of my favorite industry commentators, Robert X. Cringeley , wrote an excellent column about hiring consultants. A gold-star idea from his analysis is that because most IT projects fail at the requirements stage, hiring consultants to implement automation will fail if business owners cannot define their future-state workflows.
I've been a consultant to some organizations, so I've felt the awkwardness of parachuting into an organization, making recommendations, then leaving before those recommendations had an operational impact. I've also known consultants, of course. Some of the ones I've worked with some are so good that I think of them as partners and value-added extensions of the organization instead of as vendors. Here, then, is my analysis of what makes a good or bad consultant , based on my experience both in hiring and in being a consultant.
1. Project scope The Good: They provide work products that are actionable without creating dependency on the consultant for follow-on work. There are no change orders to the original consulting assignment.
The Bad: They become self-replicating. As they build relationships throughout the organization outside their constrained scope of work, they identify potential weaknesses and then convince senior management that more consultants are needed to mitigate risk. Two consultants become four, then more. They create overhead that requires more support staff from the consulting company.
2. Knowledge transfer The Good: They train the organization to thrive once the consultants leave. They empower the client with specialized knowledge of technology or techniques that will benefit the client in operational or strategic activities.
The Bad: Their deliverable is a PowerPoint of existing organizational knowledge without insight or unique synthesis. This is sometimes referred to as "borrowing your watch to tell you the time."
3. Organizational dynamics The Good: They build bridges among internal teams, enhancing communication through formal techniques that add processes to complement existing organizational project management approaches. Adding modest amounts of work to the organization is expected because extra project management rigor can enhance communication and eliminate tensions or misunderstandings among stakeholders.
The Bad: They identify organizational schisms they can exploit, become responsible for discord and cause teams to work against each other as a way to foster organizational dependency on the consultants
.....
The best you can do for your organization is to think about the good and bad comparisons above, then use them to evaluate your own consulting experiences, rewarding those consultants who bring value-added expertise and penalizing those who bring only PowerPoint and suits.
John D. Halamka is CIO at CareGroup Healthcare System, CIO and associate dean for educational technology at Harvard Medical School, chairman of the New England Health Electronic Data Interchange Network, chairman of the national Healthcare Information Technology Standards Panel and a practicing emergency physician. You can contact him at jhalamka@caregroup.harvard.edu.
For the other seven go to the article
http://www.techworld.com.au/article/373384/good_consultants_bad_consultants/
John provides a very useful set of points that I have to say really ring true in distinguishing the good from the bad consultant, and the article is well worth a slow read.
Interestingly on his own blog he also describes the problems he has had making one of the most advanced health systems for IT in the US obtain certification for ‘meaningful use’ of Health IT - so they can get some incentive funds.
This blog is found here:
http://geekdoctor.blogspot.com/2011/01/early-experiences-with-hospital.html
Monday, January 10, 2011
Early Experiences with Hospital Certification
As one of the pilot sites for CCHIT's EHR Alternative Certification for Hospitals (EACH), I promised the industry an overview of my experience.
It's going very well. Here's what has happened thus far.
1. Recognizing that security and interoperability are some of the more challenging aspects of certification, we started with the CCHIT ONC-ATCB Certified Security Self Attestation Form to document all the details of the hashing and encryption we use to protect data in transit via the New England Healthcare Exchange Network.
---- End quote:
This blog makes it clear just how demanding the meaningful use requirements are.
However all is not perfect by any means:
This blog from Scott Silverstein makes that utterly clear:
http://hcrenewal.blogspot.com/2011/01/dr-monteith-hit-testimony-to-hhs.html
Sunday, January 16, 2011
Interesting HIT Testimony to HHS Standards Committee, Jan. 11, 2011, by Dr. Monteith
Psychiatrist-medical informaticist Dr. Scott Monteith was a guest blogger on the complications of "Meaningful Use of EHR's" in the Dec. 21, 2010 post "Meaningful Use and the Devil in the Details: A Reader's View."
He also testified at the Office of the National Coordinator's Health IT Standards Committee Implementation Workgroup which recently had a meeting, Jan. 10-11, 2010, as I wrote about here.
With his permission I am reproducing his testimony to the Committee (which is supposed to also be posted to the meeting website) without further comment. None is needed.
----- End Quote.
There are some worrying comments here and the blog needs to be carefully read. The issues of the safety and utility of EHRs will not go away until agreement that there is a real problem that needs to be addressed.
There are others also taking slightly different slants to the problem.
From: The Hospitalist, January 2011
Health IT Hurdles
Physician understanding, hospital compatibility among many concerns
by John Nelson, MD, MHM, FACP
I rent cars regularly, and only occasionally do I get the same model twice. I’m ready to roll after spending a couple of minutes becoming familiar with a car that is new to me. I adjust the seat and climate control, etc. I resist fiddling with the radio until later. This seems OK to me.
The last time I started clinical practice in a new hospital, I did almost the same thing: I jumped right in and started seeing patients. Other than being provided with my password to the computer system and a dictation code, I had no orientation at all, not even to the hospital floor plan. This, too, seemed reasonable to me at the time. Now I see it differently.
I worry that it will be increasingly difficult, and potentially unwise, for a doctor in any specialty to practice at more than one or two hospitals that don’t share the same electronic health record system.
Levels of Complexity
Years ago, learning a new hospital might not have been a lot more difficult than familiarizing yourself with a new rental car, so there didn’t seem to be much need for a detailed orientation. I’m generalizing here, but if you go back far enough in time, the general idea was that it was almost entirely up to the hospital and its staff to get to know the new doctor and how he or she practiced, rather than the doctor adapting to the hospital’s way of doing things.
While at one time hospitals and their systems might have been as similar to one another as a four-door Chevy is to a four-door Ford, today’s hospitals are far more complex. The appropriate transportation analogy might be one type of airplane to another.
The basics of what keeps a two-seat Cessna and a huge 747 flying are the same, but there are so many critical differences that specific training and certification are required for each. Even an accomplished professional pilot who is an ace in a 747 isn’t automatically certified to pilot a smaller 737. In fact, few professional pilots are certified to fly more than one type of commercial airplane at a time. One way to look at this is that the orientation to the plane is so complex that one person can’t be expected to maintain a high level of familiarity with the systems and operation of more than one at a time.
EHR: A Tipping Point
The complexity and unique attributes of hospitals have been increasing steadily for decades, but it seems to me that electronic health records (EHR) represent a huge increase in complexity. No longer can a doctor simply arrive at the hospital confident in her ability to fly this new plane. She will require a reasonably detailed introduction to the hospital’s EHR as part of an orientation that should ideally take place prior to seeing patients.
I worry that it will be increasingly difficult, and potentially unwise, for a doctor in any specialty to practice at more than one or two hospitals that don’t share the same EHR. If a doctor is not proficient in the use of the EHR at a particular site, two things are likely to happen: First, and most alarmingly, the new doctor would probably unintentionally miss important information in the EHR, or might not have time to contemplate the series of buttons to click to check all potentially relevant information. For example, he might not realize the patient already had a series of blood tests, because accessing them requires some unfamiliar clicks of the mouse.
The other thing that might happen if a doctor is not proficient in the use of the hospital’s EHR is that he might be inclined to consult the hospitalist “just to cover all the bases.” In this case, that might be the same as asking the hospitalist to be involved as an EHR expert, rather than for medical expertise that the patient needs.
I practice at a hospital that recently installed a new information system, and some doctors have joked that if they can’t figure out how to use it, they will just consult a hospitalist to look up historical data, etc. I’m not aware of any study looking at this issue, but I suspect “soft” hospitalist consults increase when a hospital installs a new information system.
More here:
http://www.the-hospitalist.org/details/article/972753/Health_IT_Hurdles.html
The first step will be that we must be open about those things that a not working and proactive in fixing them! While ever the safety, usability, complexity and reliability issues of Health IT are not squarely confronted we will have a ticking time bomb of a problem!
This point was emphasised just a few days in a preview of HIMSS.
EHRs Fail
HDM Breaking News, January 13, 2011
Overall, electronic health records are expected to reduce medical errors, but Dean Sittig has devoted a lot of research to the ways that EHRs themselves can fail. In this session, he'll talk about how to avert those failures by conducting internal audits of clinical information systems and paying attention to red flags, the way physicians do when they examine a patient.
"A finding of 'swollen lymph nodes' during a routine physical examination should be investigated to rule out potentially serious systemic infections," says Sittig, associate professor in the School of Biomedical Informatics at the University of Texas Health Science Center at Houston. "Likewise, there are similar signs and symptoms related to potentially dangerous situations involving implementation and use of EHRs."
More here:
http://www.healthdatamanagement.com/news/HIMSS_EHR_failure-41733-1.html
There are some important lessons also listed here!
I wonder how across these issues those rushing to apply for DoHA’s $55 million are and what plans DoHA/NEHTA have to address these issues. Time will tell I guess.
David.
