Thursday, November 17, 2016

The electronic health record problem list - how I'd do it for the third time

I did corporate research and development in clinical software for about 20 years. During that time I couldn’t write about informatics ideas.

In my current job I have more scope. I can’t write about anything specific to my work, but I can share some general thoughts on medicine and health informatics. Like my idle thoughts about how I’d implement an electronic health record problem list if I were doing one for the third time. (Of my two previous efforts I liked the first one best; this proposal is an improvement on it.)

One problem with the patient “problem list” is it’s a “roach motel”. Easy to enter, hard to leave. It gets cluttered up with obsolete junk nobody dares clean out. Another problem is one man’s poison is another man’s wine — orthopods aren’t interested in minor eye disease findings. A third problem is that problem lists are typically assembled from “billing codes” (ICD-9/ICD-10) that are often misleading and a treacherous basis for decision support. Unfortunately, because of the way we use it, ICD-10-CM is worse than ICD-9-CM. A fifth problem is that every minor variant of Diabetes gets its own entry, cluttering the list. Lastly to get real value out of the problem list it should be useful in automated decision support and population health monitoring, but again ICD-10-CM does poorly.

So here’s what I’d do:

  1. I’d base my problem list on a SNOMED subset (wait, I can explain).
  2. The SNOMED subset would be quite small, probably less than 1,500 concepts.
  3. I’d choose the concepts based on the ICD-10-CM codes that are “containers” (non-leaf) for leaf codes. This is far less than the total number of ICD-10-CM codes. I’d also restrict my coverage to those ICD-10-CM “container” codes that map to SNOMED CT Findings.
  4. The only time I’d go finer grained than this high level set would be if I had a decision support rule that needed more definition (most won’t).

Given these constraints the ICD-10-CM back maps are easy to build and maintain. Any ICD-10-CM code associated with an encounter would have a corresponding SNOMED concept. In the UI I’d support displaying all ICD-10-CM codes historically associated with the problem concept — so the detail would be available on request. Clinical rules would be written off the small space of problem list concepts.

I’d give problems an algorithmic lifetime — unless the provider explicitly makes them “sticky”. If a related ICD-10-CM code doesn’t reappear for two years the problem becomes “historic”. All decision support rules that are declined would have an option to say the “problem” no longer applies — that would remove the item.

If a problem were marked “sticky” it could still be removed manually or by the decision support action — but the provider who made it “sticky” would be get a message about the change. They could choose to investigate or ignore it.

I doubt I’ll get a third go round at this problem, but that’s what I’d like to try.

No comments: