Future Health IT: Clinicians Thrash Informaticians

A classic problem experienced by system architects and software engineers like myself when dealing with clinicians is this: while jealously guarding highly granular taxonomies of specialties and skills within their own profession, physicians tend to lump everyone in the realm of IT into a single category - "programmer", and all  IT projects into a single level of difficulty - "easy".  At the same time, they consider the requirements inherent in their domain to be utterly unique and impenetrable to anyone with less wisdom and acumen than they. Clinicians have an equally jaundiced view, on the whole, of IT professionals.

Reading an entry in Colin Jervis' blog, Future Health IT: Clinicians Thrash Informaticians, I stumbled on a situation that addresses this problem head-on from both sides. Over across the Pond, the Brits have been Minding the Gap between the worldviews of clinicians and informaticians.  A debate between the two groups happened at a meeting of the BCS London and South East Health Informatics Group at the Health Care 2006 conference. I see a lot of parallels with the worldview clash over here in the New World.

The thesis being argued about in the debate is this: "...real innovation using ICT in healthcare delivery is driven by clinicians rather than informaticians.". (FYI, you Yankees and others looking a bit puzzled: ICT is an acronym for "Information and Communication Technologies", akin to IT as the term is used in the US.) Colin's blog entry offers some fascinating insights and has links to some other posts of similar value, including a guest post by Dr. Simon Dodds responding to Colin's debate position. Dobbs is a vascular surgeon whose guest post goes to the real problem that remains unseen behind the pie fight.  There's also an entry in the official blog of HC 2006 which gives a bit more detail on Dr. Dodd's point of view as presented in the original debate.

The NIBM syndrome - "Not Invented By Me" - is particularly rampant among surgeons (no effense intended, Dr. Dodds, you may be the sole exception), but all specialties suffer from it to some degree.

There are individuals who don't fit the pattern, of course; I work with a family doc who is comfortable with modifying and recompiling the Linux kernel as need arises. But there are many who can't seem to come to grips with the fact that informatics is different from and sometimes just as complex as surgery. Moreover, the requirements of healthcare informatics differ from other domains primarily in terms of content - the complexity of data structures and standards adherence mandates in medicine are no worse than those in the automotive industry, and if anything less complex and challenging than even the more mundane corners of the aerospace industry, e.g., designing and building a new jumbo jet.

As I intimated earlier, in my view Dr. Dodds hits the nail on the head when he accuses IT professionals of putting clinicians in a Catch-22 situation:

With my clinical head on I rant about the informaticians that never actually come and see what frontline healthcare delivery entails, never experience for themselves what the problems are, or help tease out the information requirements from the rest of the process (i.e. write the information requirement specification), then offer simple, workable, quick, cheap options based on existing technology, then help choose the most viable options, then quickly design and build prototypes that are usable, then test options and find those that actually work better than what we were doing before, then implement the best seamlessly so we never really even notice it's there (until it goes away and we suddenly realise we can't do without it).

To make an analogy across the battle lines, what Dr. Dodds is accusing us of is keeping our eyes on the chart and ignoring the patient. There is a historical view of IT requirements gathering which says, "get everybody together in a room and have them tell us what their requirements are, and 6-9-12 months later we will deliver what they ask for, And Nothing Else." (I call this the Soup Nazi approach, after the Seinfeld character who had stringent requirements for people in the ordering line of his little shop.) This works surprisingly well when designing point-of-sale software for candy shops, which is about the level of difficulty one faces in undergrad and master's level computer science programs,but fails to scale well to more complex domains.

Clue #1 for the clueless IT professional: NOBODY knows what their requirements are. Too much tacit knowledge is involved, especially in complex domains like healthcare. I just spent six months going around from lab to lab within our academic health center talking with and observing in situ the folks who will use the tissue banking and assay data management extensions we are designing for our clinical research data management system, and I think I understand what the requirements are finally - not all of them, but enough to deliver a workable system that will get us to the stage where we need the next clue.

Clue #2: Interventions such as probing for requirements actually change the requirements, and delivering that first workable system change the requirements even further, WITHOUT EXCEPTION. Read my lips - NO SYSTEM THAT GETS BUILT MEETS THE REAL REQUIREMENTS, because the ground keep shifting underneath your feet. Again - WITHOUT EXCEPTION.

Ahem. Excuse the shouting. I feel strongly about this as you may see.

Clue #3 for the clueless IT professional: your customer has NO IDEA what is possible right now with existing technology, never mind what will be there after another turn or two of the Moore's Law and Metcalfe's Law cranks. And frankly, in all likelihood, neither do you, or you would be in a cutting-edge entrepreneurial company making twice what you make now.

You over there, the clinician with the smug smile on your face after listening to all this. You, too, are more often part of the problem rather than the solution. Clue #4 is for the clueless clinicians - most IT professionals are already wearily aware of this one. The reason most systems fail is political - stubbornly unrealistic expectations and lack of emotional investment on the part of the customer. If you want an IT solution that works, you must be its CHAMPION - I didn't say sponsor, or advocate, I said CHAMPION.

It's a classic bacon-and-egg problem: the egg on the plate represents interest on the part of the chicken; the bacon represents commitment on the part of the pig. You can't be a chicken if you want your system to succeed in the face of cultural inertia, and cultural inertia is as inevitable a stabilizing force in social systems as the gyroscopic effect is in the physical realm.

OK, this is admittedly easier when you are working with IT professionals who are not clueless, just as designing, building, and delivering the system is easier when you have a clueful and committed customer. It's a delicate balance, a dance that requires a dynamic tension and occasional shifts in who is leading and who is following.

What IT needs to better serve the clinical is an anthropological approach to balance technical acumen. Culture is key in system design. Get in there, as Dr. Dodds say, and find out what the situation is like on the ground. Get to know your end user where they live and work.

What clinicians need to learn is to respect and trust their informaticians - they too have worked hard to master complexity in their own realm. There are numerous specializations within IT, and you, the clinician, would do well to learn what they are so you ask the right questions of the right person. And frankly, most of the questions you are likely to ask should be directed at systems analysts and architects, not programmers, so find out who these persons are in your organization and what are their titles, and get to know them before you have an emergent need. Friends come in handy from time to time, in IT as well as in medicine.

When everybody lives up to these responsibilities, the dance will be more graceful and fewer toes will get mashed in the process.

Comments

[Carol Kirshner]

You raise some very interesting points. I agree that the average clinician has little idea of what technology can do for them. Unless they are personally interested in technology/informatics, then it is unlikely that they have the time or the inclination to study it enough to understand the complexity.

One must also understand the true motivators for clinicians. I'd like to think that in most cases, patients are a priority. Next, we have the looming threat of malpractice and liablity issues. In general, this causes clinicians to keep good practice and ethical behavior in the back of their mind at all times. Lastly, one must remember that for most clinicians time is either money or an opportunity to relax, recharge, and be with family.

Its funny, the one thing that IT consultants and clinicians share is the motivation of "Billable time."

Thanks for the interesting post! It gives me a lot to think about.

[Simon Dodds]

Hi,
I smiled and even laughed out loud when I read this fantastic comment and I am delighted that my views are stirring up discussion - that after all is the purpose of debate. So what do we have here? A pretty classic paradigm mismatch, a necessary simplification of reality masquerading as a conflict of views. In reality we are in heated agreement but don't always see it. IT professionals and health professionals are not so different from each other - so when one of the "Them" causes you distress just stop to think how one of "Us" might do so without intending to. I actually believe the conlict arises from a deeper source - that of confusing innovation and implementation. It is easy to tell which is which - if the specification keeps changing then it is innovation and the customer is on a learning curve; if you try to implement at this stage you'll waste a lot of time (and money); when the specification stops changing then start implementing, but only what the user has demonstrated that they need - this also saves a lot of time (and money). The principle is basically Lean Thinking for software development - (1) only add value for the user and (2) keep the solution as simple as possible and (3) strive for perfection. Do that and you deliver a successful solution in half the time (and half the cost); and your clinicians will think you are a genius and want you to be your friend. Now wouldn't that be a happier place to live?

Dr Simon Dodds
UK

[Hunscher]

My dear Dr. Dodds,

At last, someone who Gets It! I'm so glad someone sees the humor in all this.

Your Lean Thinking formula sounds oddly similar to (1) Above all, do no harm, and (2) All other things being equal, the simplest solution is the most likely solution. (3) is common to the two lists. All this, of course, being the three most important lessons one learns in medical school.

The irony of all this is that I am neither "Them" nor "Us" - I am a sociologist by training, a social worker and policeman for brief stints, and a logger for nearly a decade before I got into my now 24-year careen in IT. I am a stranger in not one, but two strange lands when I go to work at my local academic health center.

I almost agree with your innovation vs. implementation, though my bar for the term "innovation" is a bit higher than what you seem to be positing. Most development I have seen that works as you describe is much more like Small-Is-Beautiful author EF Schumacher's "muddling through to success" than the cutting-edge projects I have witnessed in informatics research labs and entrepreneurial startups.

Schumacher's approach is the healthiest and most successful approach to problems where one is feeling out the requirements. Most of the "innovation" that happens in such circumstances is actually the discovery and taking into account of previously tacit knowledge or unintended consequences of one's assumptions. Regardless of definitional quibbles, though I think we both celebrate success whenever we see it and agree on the ingredients in the recipe, even if we differ over "aubergines" versus "eggplants". If the dish is tasty, economical, and nutritious, terminology be damned. Do more of whatever you did to make it happen, and I am (we are?) both happy with the result.