The Trouble with ICD-10 CM on UMLS

The UMLS metathesaurus is a convenient downloadable database of commonly used medical terminology systems.  It includes SNOMED CT, RxNorm, LOINC, among many others.  The ICD-10 CM representation is not that great, however.  This is mostly due to its inability to adequately represent ICD-10 CM's attributes.

For example, this is a diagnosis from the ICD-10 CM tabular file:

<diag>
          <name>C41.0</name>
          <desc>Malignant neoplasm of bones of skull and face</desc>
          <inclusionTerm>
            <note>Malignant neoplasm of maxilla (superior)</note>
            <note>Malignant neoplasm of orbital bone</note>
          </inclusionTerm>
          <excludes2>
            <note>carcinoma, any type except intraosseous or odontogenic of:</note>
            <note>maxillary sinus (C31.0)</note>
            <note>upper jaw (C03.0)</note>
            <note>malignant neoplasm of jaw bone (lower) (C41.1)</note>
          </excludes2>
      </diag>

(From 2019 ICD-10 CM tabular data)

Note the 'excludes2' elements. These are considered 'attributes' of the code.  Pay attention to the line:

 carcinoma, any type except intraosseous or odontogenic of:

This is the first line in 'excludes2', and it modifies the interpretation of all the subsequent lines.  (I have to admit that I'm not completely sure how to interpret this 'excludes2' statement, but I feel it means that ALL carcinomas are excluded unless it is a carcinoma relating to one of the specified codes, and even then, only if the tumor is intraosseous or odontogenic.)

Now let's look at the UMLS representation of ICD-10 CM via an SQL query:

Query:

SELECT s.ATV from mrsat s WHERE (s.SAB='ICD10CM') AND (s.ATN='excludes2') AND (s.CODE='C41.0');

Results:

• maxillary sinus (C31.0)
• carcinoma, any type except intraosseous or odontogenic of:
• malignant neoplasm of jaw bone (lower) (C41.1)
• upper jaw (C03.0)

What we get is a list of lines from the original ICD-10 tabular XML.  Note that, however, the ORDER of the lines is not preserved.  Each line is a different database attribute, and there is no way to record the order of attributes in UMLS.   The 'excludes2' statement from the ICD-10 CM specification really only makes sense if taken as a whole (in the correct order), as the first line says to exclude all carcinomas EXCEPT for the things that follow.

If you were to use the UMLS version of ICD-10 CM for this, you might reach the conclusion that a diagnosis from the "upper jaw" code (C03.0) is excluded when in fact it may be exactly the opposite.

The UMLS solution would be for the entire 'excludes2' to be taken as a single string, and added to the the UMLS database as a single attribute (ie a single database row).  This would need to be done for 'excludes1' as well.  In terms of string length, it would seem that UMLS specifies the ATV column as a TEXT type in the generated MySQL scripts (meaning it can handle longer strings).  In their documentation, they note that "a few" attribute values are over 1,000 characters.  This suggests that the other relational databases would also use types representing long strings.

An even better solution would be for ICD-10 CM to represent its data in a more machine-friendly manner that is not dependent on the first line of the attribute section for interpretation.  See earlier post.

ICD-10 CM data - machine hostile

ICD-10 CM is more than just codes and their descriptions; the codes have associated data (such as which codes are excluded when the code is present).  One of the main data files is called the 'tabular list', which organizes the data by the code (as opposed to the code's description).

The tabular list is distributed in both a human readable PDF file as well as a machine readable XML file.  While I should say that it is fortunate that there is an XML file, it does not go far enough in terms of being 'machine-friendly'.  The data inside the XML file is still reliant on human interpretation.



Problem #1: It doesn't give us the codes directly, but rather puts them in a human readable string

The first thing to notice is that it doesn't give us the codes directly.  It gives us human text, and in round brackets (parentheses), it lists the code.  So from the get go, the programmer is forced to parse the last round-bracket-enclosed string.

As an example of what I'm talking about, let's look at the 'excludes1' data for the code G02 (Meningitis in other infectious and parasitic diseases classified elsewhere):
<excludes1>
          <note>candidal meningitis (B37.5)</note>
          <note>coccidioidomycosis meningitis (B38.4)</note>
          <note>cryptococcal meningitis (B45.1)</note>
          <note>herpesviral [herpes simplex] meningitis (B00.3)</note>
          <note>infectious mononucleosis complicated by meningitis (B27.- with fourth character 2)</note>
          <note>measles complicated by meningitis (B05.1)</note>
          <note>meningoencephalitis and meningomyelitis in other infectious and parasitic diseases classified elsewhere (G05)</note>
          <note>mumps meningitis (B26.1)</note>
          <note>rubella meningitis (B06.02)</note>
          <note>varicella [chickenpox] meningitis (B01.0)</note>
          <note>zoster meningitis (B02.1)</note>
        </excludes1>

Of course, sometimes they forget one of the brackets (see the 2019 excludes1 data for C30.0):

 other and unspecified malignant neoplasm of skin of nose C44.301, C44.311, C44.321, C44.391)

 Or both brackets (see 2019 excludes1 data for R29.891):

congenital (sternomastoid) torticollis Q68.0

 It would appear that this data is not only intended for humans, but it was written directly by humans.

Solution #1: have a dedicated element for the codes


Problem #2: multiple ways of specifying multiple codes

Inside the brackets, there may be multiple codes, separated by a comma, by 'and', or by both.  It may include a range of codes, separated by a hyphen. Or it may have some random text.  Look at the example above (for the excludes1 items for G02).  Note the line that says:

 infectious mononucleosis complicated by meningitis (B27.- with fourth character 2)

 First of all, this is an error on their part--they mean 'fifth' instead of 'fourth'.  Had it actually been 'fourth', they could have just said 'B27.2'.  (And the 'with meningitis' diagnoses under B27 all have a fifth character of '2'.  The fourth character specifies the type of virus.)  So let's pretend it actually said 'fifth'.  This is not an easy thing to parse.  It would have been much easier for everyone involved to have them list the actual codes (in this case, 'B27.02, B27.12, B27.82, B27.92').

Solution #2: list the actual codes involved instead of relying on ranges and other random designations.  Each code can have its own element, or maybe just put them in a comma separated list.


Problem #3: sometimes they don't even give codes, they just use English.

For the code E87.2 (Acidosis), there is an 'excludes1' statement that reads:

diabetic acidosis - see categories E08-E10, E13 with ketoacidosis

So basically, instead of giving us a code list that reads: 'E08.1, E09.1, E10.1, E13.1',
they give us some English.   I should mention this 'excludes1' statement is likely in error as well, as there is now a DM type 2 DKA code (E11.1), added in 2018 I believe. 
 
Solution #3: less English, more codes


Problem #4: the ICD-10 tabular data makes me expand the codes by the seventh character rather than just giving the expanded codes to me

I've got way too much boring stuff to say about this, especially how they will do things such as giving us the seventh character definitions, but in the note, specify in complex English which of the actual codes these should be applied to.  And how they give us the seventh character definitions but then override them for certain children.

Solution #4: still give us the seventh character definition data, but also expand the codes for us.  And only give the seventh character definition data on the actual codes it applies to.  The bloat in the XML file will easily be tolerated.



Misc:
Sometimes they end codes inside the round brackets with a hyphen (e.g. 'E78.-').  I believe this indicates that there are additional characters in the code.  But as far as I can tell, this is redundant, as if the code is a branch (ie has child codes) as opposed to a leaf (ie a billable code), then it is assumed to apply to all the children of that code.



As negative as I have been in this post, let me just say that I am appreciative of the fact that there is an XML file.  Other systems (I'm looking at you, MS-DRG) are way worse in terms of being machine not-so-friendly.

ICD-10 CM excludes - what the heck?

I spoke about ICD10-CM 'excludes' lists in a previous post.  This post is intended to point out how absurd these lists are.

If you look at E87.2 (acidosis), and look at all the excluded diagnoses of it and its parent elements, you will see a list that looks like:

•     Diabetic acidoses (reasonable; what's not reasonable is that it doesn't actually list the codes, but requires a human to interpret them; very luddite of them)
•     Diabetes insipidus
•     Familial periodic paralysis
•     Ehlers-Danlos syndrome
•     Marfan's syndrome
•     etc

 Just to emphasize how ridiculous this 'excludes1' list is, note that it is saying that someone with DI cannot have a diagnosis of acidosis coded.  Same with someone with Marfan's syndrome or Ehlers-Danlos syndrome.  As if these diagnoses were mutually exclusive. 

I guess (in these cases) we are supposed to treat 'excludes1' like 'excludes2'. (See this post).  It would make more sense for them to just make these items 'excludes2'.

ICD-10 - excludes1 vs excludes2 : 6 vs half a dozen

ICD-10 CM codes have 'excludes' annotations; these are notes that specify which codes are excluded by the presence of the code in question.  The specification divided the excludes list into two parts:

• Excludes1 : a list of diagnoses which will never be present at the same time as the diagnosis in question.  For example, if the diagnosis in question is "Diabetes mellitus type 1", one of the excludes in this section is "Diabetes mellitus type 2", as one can never have both type 1 and type 2 diabetes. 
• Excludes2 : a list of diagnoses that indicates diagnoses that cannot be part of the diagnosis in question.  For example, K22.11 - "Ulcer of esophagus with bleeding" has an excludes2 value of "bleeding esophageal varices (I85.01, I85.11)".  This means that a single esophageal bleed cannot be coded as both a an ulcer and a varix.  But if a patient has both conditions (ie the conditions are not related to one another), then it is ok to code both.

These definitions were clear, but upon objections to some 'Excludes1' diagnoses, the CDC issued this advice circa late 2015:

If the two conditions are not related to one another, it is permissible to report both codes despite the presence of an Excludes1 note. For example, the Excludes1 note at code range R40-R46, states that symptoms and signs constituting part of a pattern of mental disorder (F01-F99) cannot be assigned with the R40-R46 codes. However, if dizziness (R42) is not a component of the mental health condition (e.g., dizziness is unrelated to bipolar disorder), then separate codes may be assigned for both dizziness and the mental health condition. In another example, code range I60-I69 (Cerebrovascular Diseases) has an Excludes1 note for traumatic intracranial hemorrhage (S06.-). Codes in I60-I69 should not be used for a diagnosis of traumatic intracranial hemorrhage. However, if the patient has both a current traumatic intracranial hemorrhage and sequela from a previous stroke, then it would be appropriate to assign both a code from S06- and I69.

 (Source: 4^th Quarter 2015 issue of Coding Clinic for ICD-10-CM and ICD-10-PCS)

In keeping with the previously mentioned advice, in the ICD-10 2017 guidelines, there was an additional paragraph added to the 'Excludes1' section that reads:

An exception to the Excludes1 definition is the circumstance when the two conditions are unrelated to each other. If it is not clear whether the two conditions involving an Excludes1 note are related or not, query the provider. For example, code F45.8, Other somatoform disorders, has an Excludes1 note for "sleep related teeth grinding (G47.63)," because "teeth grinding" is an inclusion term under F45.8. Only one of these two codes should be assigned for teeth grinding. However psychogenic dysmenorrhea is also an inclusion term under F45.8, and a patient could have both this condition and sleep related teeth grinding. In this case, the two conditions are clearly unrelated to each other, and so it would be appropriate to report F45.8 and G47.63 together.

(Source: ICD-10-CM Official Guidelines for Coding and Reporting FY 2017)

So, to summarize the definitions of the 'excludes' items (following the new definitions), 

• Excludes1: a list of diagnoses that cannot exist with diagnosis in question, unless the conditions are unrelated.
• Excludes2: a list of diagnoses that cannot exist with diagnosis in question, unless the conditions are unrelated.

So now you know the difference.

EHRs and Daylight Saving Time

So I had noticed that whenever it was time to "fall back" for daylight saving time, our hospital's EHR would have downtime.  I always had assumed this was sort of a coincidence, or maybe that the downtime was a 'change the battery in your smoke detector' kind of event.  But then I read a brief article in Becker's (https://www.beckershospitalreview.com/ehrs/daylight-saving-time-stumps-ehrs-5-things-to-know.html).  And it occurs to me that my hospital's EHR has been shutting down during the fall back overlap because it is unable to handle daylight saving time change.

A quick review of areas that use daylight saving time (DST): at some point during the spring, the clocks will "spring forward" and skip over the entire 1 AM hour, going from 12:59 to 02:00.  This is the 'GAP', and represents the start of DST.  This does not seem to cause a problem with EHRs.

On the other hand, at one point during the fall, the clocks will "fall back".  When the clocks hit 2 am, they go back to 1 am.  In other words, 1:59 AM is followed by 1:00 AM.  This is the 'OVERLAP', and represents the end of DST. This is when apparently many Epic and Cerner systems schedule a downtime.  Per the article, those systems that don't have downtime have the expectation that any observation/result value entered in during that time won't persist.

There is really no excuse for this.  There are a number of software libraries relating to time that can adequately deal with this.  Java version 8 integrated a modified version of the Joda-Time library, which makes this type of issue fairly trivial.  (FYI, the solution in Java speak is to make the timestamps for observations and other important values based on an 'Instant' rather than a 'LocalDateTime'.  The 'Instant' can be represented by the number of milliseconds that have elapsed since Jan 1, 1970 00:00:00 GMT.  There is no ambiguity here.  The EHR software should convert the Instant into a LocalDateTime for display.  And when there is an overlap, the software can even append the time with either 'DT' or 'ST'.  If the EHR is receiving external messages in local time (which it really should not be), it can convert these to instants using the current time zone.

And to put things into perspective, Tesla has software than can essentially drive a car for you.  This is an incredibly intricate system that utilizes state of the art image recognition coupled with complex algorithms to decide the automobile's next move.  EHRs cannot handle inpatient diabetes management, despite discrete structured data (blood glucose values).  And they apparently can't handle daylight saving time changes.

Progress Notes and the Enlarging Assessment/Plan Sections

Problem:

I have seen a common pattern popup over the last ten years in daily inpatient progress notes, specifically the assessment and plan section. This only occurs in copy-and-paste notes, and I don't have a good name for it at the present time.

Here is a fictional example of a partial A/P:

Day 1:
GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib

Day 2:
GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.  
    -PPI q12h for now

Day 3:
 GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.   GI also performed EGD, small ulcer in fundus, no active bleeding.  
    -PPI q12h for now

Day 4:
  GI Bleed 
    -has been going on for at least a week before admission
    -GI requests holding anticoagulation for a-fib
    -GI performed colonoscopy, no clear source of bleed.   GI also performed EGD, small ulcer in fundus, no active bleeding.  
    -PPI q12h for now
    -patient had hematemesis, and GI performed another EGD, noted a large duodenal ulcer, cauterized



Essentially, the previous progress note is copied into the current one, and additions (with some slight alterations of previous details) are made.  Now imagine this pattern goes on for 11 or more days. On day 21, the A/P section for the progress note is insanely verbose. 

I am not a fan of this style for a few reasons.
1. Assessment and plan are sort of mixed together randomly (which is not unique to this pattern)
2. The bigger culprit: CLUTTER!

This pattern junks up the assessment and plan with a lot of repeat, old data.  In handwritten notes, the plan would be a line or two or three.  It would not recap every single development.  One of my colleagues tells interns/residents not to type anything that they would not have written by hand in the pre-EMR days, and this is good advice.

But there IS a very beneficial aspect to this note style.  For anyone who has had to write a discharge summary on a patient they had for only a brief part of the patient's overall stay, this sort of sums everything up for them. 

So how does an EMR handle progress notes while making things easy for the provider who writes the discharge summary?

Solution 1:

One possible solution: for the A/P each day, the provider only puts what is relevant for the current day.   The EMR would recognize the A/P for each problem, and could provide the provider with a summary of care for each problem (ie a compilation for the plans for that section of each daily progress note).

Summary example:
Problem : GI bleed
Day 1: 
Unclear source; has been going on at least a week before admission.
-holding anticoagulation
-GI will perform colonoscopy

Day 2:
Colonoscopy without clear source of bleed. 
-will monitor
-PPI IV q12h

Day 3:
EGD with small ulcer in fundus, unclear if this is source of bleed.
-will continue to monitor
-PPI IV q12h

Day 4:
Patient had episode of hematemesis, and GI performed another EGD.  Noted large duodenal ulcer, cauterized.  
-will continue PPI q12h
-will monitor


So while the summary may be longer when compared to an individual progress note, it is much more clear regarding the assessment and plans for each individual day.  And the progress notes for each day are not cluttered.

Solution 2:

This would still employ a "clutter-free" progress note, but it would involve another document...a wiki-style perpetually edited "Summary of Stay" document.  This is essentially a Discharge Summary document that is started when the patient enters the hospital, with each problem having its own section.  Every day (as needed), the document is edited to include the recent developments.  When it is time to discharge the patient, the discharging provider has to simply make a few cosmetic edits to the document.

SNOMED vs ICD-10

Meaningful use dictates that EMRs use SNOMED as the vocabulary for problem lists (as opposed to ICD-10).  This is absolutely reasonable, as ICD-10 is NOT useful for general things such as problem lists.  For example, ICD-10 only has following diagnoses:
E87.2 Metabolic acidosis
E87.2 Respiratory acidosis

Notice anything?  The acidosis diagnoses all have the same code.  That's right.  There is just one code for acidosis: respiratory acidosis, metabolic acidosis with elevated anion gap, metabolic acidosis with a normal anion gap.

But ICD-10 does have multiple codes for dealing with parrot attacks:

W61.01 Bitten by parrot
W61.02 Struck by parrot
W61.09 Other contact with parrot

Now, if that wasn't enough, ICD-10 has codes for interactions with macaws, a type of parrot.
W61.11 Bitten by macaw
W61.12 Struck by macaw

And there are codes for other "psittacines" (ie parrots):
W61.21 Bitten by other psittacines
W61.22 Struck by other psittacines


While SNOMED has simple, to-the-point codes, ICD-10 has very "pre-coordinated" codes, such as I13.2, "Hypertensive heart and chronic kidney disease with heart failure and with stage 5 chronic kidney disease, or end stage renal disease".  And for billing reasons, this code is OFTEN the principal diagnosis for inpatient admissions.  While this type of code may help with DRG assignment/billing, it is not practical for patient care.  In fact, any diagnosis name with an "or" in it is potentially a bad thing to use.

That's why we use SNOMED, a rational, level-headed diagnosis vocabulary.