Friday, February 04, 2011

Conflating Heavy Coffee Drinkers With Glue Sniffers and PCP Abusers: Why Computer Personnel Should Not Play Doctor

I present a new, true case example of health IT-created problems, with some parallels to this prior health IT information science debacle where I had written:

... What manner of amateurs made and approved the decision to map semantically and often medically imprecise, and often deliberately overstated or misused billing codes to diagnoses, and then display the diagnostic terms to a user - ANY user, patient or "learned intermediary" - in an electronic health record?

Here are the de-identified details:

A clinician participated in a psychiatry team meeting.

The patient was in attendance and had dutifully been reviewing the treatment plan and records. The patient was upset that the Axis I diagnoses included “inhalant abuse.”

In fact, here’s what the patient's EMR-generated record indicated:

“305.90 CAFFEINE INTOXICATION, INHALANT ABUSE, OTHER (OR UNKNOWN) SUBSTANCE ABUSE, PHEN”

[PHEN = phencyclidine, a.k.a. PCP or "Angel Dust" - ed.]


The problem was that individual diagnoses are inexplicably conflated, leaving the user no choice but to select an overly broad, insufficiently "granular" diagnosis code. The EMR diagnosis dataset did not correctly reflect the Diagnostic and Statistical Manual of Mental Disorders (DSM), the "Bible" of psychiatric diagnosis published by the American Psychiatric Association.

(What about all of the people who have a history of “caffeine intoxication” but now also have a history of “inhalant abuse” because of the EMR's forcing diagnostic "blur" onto its users, the clinician wondered?)

The patient understandably interpreted the document as indicating that they had a history of “inhalant abuse,” and wanted it changed. (They probably would also have thought the document indicated they abused Angel Dust if they'd known what "PHEN" stood for.) The patient does have a history of substance abuse, but not inhalant abuse, and the clinician's progress notes reflected these facts.

The patient was upset in part because they didn't want something in the records that was inaccurate and/or could be misconstrued by someone in the future (e.g., law enforcement, the courts, an employer, a spouse, etc.)

The team and the clinician spoke with the patient, apologized for the inaccuracy about a history of “inhalant abuse,” acknowledged that there was no such history in the progress notes, indicated that the “other (or unknown) substance abuse” part was correct (with which the patient agreed), and offered to write a separate update note to reflect exactly what was meant in the diagnostic section. The clinician also indicated that they would follow up with leadership to see that the EMR was corrected so that this type of problem would not continue.

One wonders what other diagnoses were conflated.

The prevention of this type of problem is obvious to those who know even a smattering about medicine and medical information science (e.g., Medical Informatics). There should have been separate entries/options in the EMR such as follows, not one entry with all of them packed together, e.g.:

305.90 Caffeine Intoxication
305.90 Inhalant Abuse
305.90 Other (or unknown) Substance Abuse
305.90 Phencyclidine Abuse

Each diagnosis should be a separate user option, as reflected in the DSM. They should not be “bundled together” into one package as they are, forcing the user to enter incorrect diagnostic information that comes with the "bundle." Clinicians do not think in terms of "diagnostic bundles", nor does medicine work that way. Worst of all, the blurred information may at some time cause clinical or social harm to the victim.

This is a commercially sold EMR in wide use in some practices and even entire municipal health services departments. The conflation of diagnoses codes reflects a major design error for the convenience of the designers/programmers (I can think of no other valid reason).

This "feature" reflects a clear lack of comprehension of medicine and the social/societal implications by the EMR-merchant company of ill conceived blunders such as this.

-- SS

2/7/11

Addendum:
a witness to these affairs indicates that, while the IT department is opaque and doesn’t readily ‘open the curtains’ for clinicians to ‘see’ what’s going on [typical - ed.], in this case faulty vendor design apparently led to implementation “workarounds” that led to the incorrect/bad outcomes. In other words, problems on top of problems led to more problems, in their words.

4 comments:

Unknown said...

Most EMR's that I'm familiar with are configurable for this type thing. The problem is frequently not the EMR or the way it's designed, but sloppy implementation.

InformaticsMD said...

xyrnus said...

Most EMR's that I'm familiar with are configurable for this type thing. The problem is frequently not the EMR or the way it's designed, but sloppy implementation.

This could be interpreted as saying "the vendor's blameless; it's those lame purchasers and stupid doctors who just can't get it right."

That COULD apply to this related case as well - but I don't think so.

I note this on your personal blog about your mother:

Last Thursday my mom was hit by a car. The bastard that hit her was texting and driving. Now, I like to think of myself as forgiving man, but if you get the 37 years old you still haven’t developed any better judgment than this idiot has then I really have no sympathy for you.

Read what happened to mine.

Again, this could be just an anecdotal story about great health IT ruined by the purchasers and "idiot" physician/nurse users.

But I don't think so.

-- SS

Anonymous said...

Blame the users and the implementers, and...blame the patient for checking her records. Then blame the users for not being able to correct the record.

How about this?...get the vendor in there and correct the defect, test it, validate it, and see if it works in reality testing on site. Otherwise, get rid of it and get your money back.

InformaticsMD said...

Anonymous February 5, 2011 11:26:00 PM EST writes:

How about this?...get the vendor in there and correct the defect, test it, validate it, and see if it works in reality testing

That would require hiring the type of very smart, experienced individuals whose paucity creates the IT problems in the first place...and the same on the leadership of the regulatory side.

Can't have no smart old people 'round here.

-- SS