mimic-code icon indicating copy to clipboard operation
mimic-code copied to clipboard

Labevents without values

Open Mauvila opened this issue 3 years ago • 4 comments

The following are minutiae, so please don't spend much time looking into them: I noticed some inconsistencies regarding lab events, specifically regarding various lab events that have no data in the "value" or "valuenum" fields but which nevertheless have values in the comments field.

For example, with lab itemID 51652, "HIV 1 viral load" in blood, there are many inconsistencies related to labevents. For example, many "value" and "valuenum" fields are null. Many of these values have comments which have the value of "DETECTED". Most of these "DETECTED" rows (with no values) seem to have "flag" field values of "abnormal", but some have neither "value", "valuenum", nor "flag" values.

My questions are:

  1. On rows with comments that read "DETECTED" but without values / flags (eg labevent_id 40242163), how were these presented in the source EHR lab screen? If they were identified as abnormal in the original EHR, is there a missing data column that would identify them as such? If the absence of "abnormal" flag indicates normal, is there a reason why some rows with "DETECTED <1.3" [log] values (ie about 20 copies) have abnormal flags and some don't?
  2. Why are the comments for these lab values partially redacted? For example, comments frequently read "DETECTED <1.3*. PERFORMED USING THE ___ HIV-1 TEST V2.0. FOR RESULTS PRIOR TO ___ SEE MICROBIOLOGY TAB." It seems the specific test is redacted, but the version number is not. But given the "version 2" part, I would guess these tests are "COBAS AmpliPrep/COBAS TaqMan". If the goal is to redact the actual assay brand/type, shouldn't the version number also be redacted? (Although I'm guessing you are going to say that the de-identifier interpreted the assay name as possible PPI and redacted it for that reason.)

Mauvila avatar Aug 20 '20 23:08 Mauvila

  1. I'll try to grab a screen cap of how this looks, but usually if the value is empty, then the lab name appears next to an empty cell in the front end. A footnote number is next to the lab, and the footnote is the lab comment. I'm not sure what triggers an abnormal flag.
  2. Yep, our deid removes company names (even though they're not PHI) but I guess you can infer from the context which assay this is. Not a big deal either way.

Also worth noting that if the entire lab comment is three underscores, then the entire lab comment was deid'd and may have some info (e.g. the lab value, or something like that). The deid approach only retained content 95% of the time, the other 5% might have clinically relevant content that was scrubbed. A lot of these comments are just communication though (NOTIFIED XXX AT DATE/TIME.).

alistairewj avatar Aug 21 '20 14:08 alistairewj

Interestingly, I was comparing Mimic III and Mimic IV labevents for various ItemIDs, and it seems that (for at least some lab itemid values) that someone essentially moved the value from the 'value' column (where it was in Mimic III) to the 'comments' column (where it is in Mimic IV). For example, you can look at labevents for ITEMIDs 50827 and 50828.

I can't imagine that ALL of these instances are being represented in the front end by a footnote that requires clicking on to view the value--that seems very tedious. I'm wondering if the EMR would, in some cases where the 'value' column was null, populate the result box with contents from the 'comments' column instead. I'm not sure why they would do this, but if true, it would mean that some of the labevent values are actually in the comments column.

Mauvila avatar Sep 21 '20 01:09 Mauvila

Hm, you're right, in the front end the values for 50827 (Ventilation Rate) appear in the normal location; not as a comment. The raw source of the data changed between MIMIC-III and MIMIC-IV; originally it was from the lab and now it is from a central data lake. I looked through the code for the MIMIC-III labevents and we didn't do any parsing of comments to extract values, so the data must have already been in the value column. I guess the central data lake doesn't have the same movement of data.

I think it makes sense for us to move some of these values from comments to value if we can think of a few simple rules to do so.

alistairewj avatar Sep 21 '20 22:09 alistairewj

In the process of trying to map lab itemids to LOINC codes, I seem to run into more and more instances of this phenomenon.

In regards to rules for transferring the comments column to the value column, I would look at how the front end treats the various labevent rows where where the value is NULL but comments is NOT null, just to see if any of these still use a footnote type of notation to refer to the comments. If none, maybe it's ok to move the comments to the value column. (It's very hard to judge the content of the comments column on my end because it seems a whole LOT of the comments have been replaced with underscores by deid).

If (in the front end) there are at least SOME lab values (that meet previously mentioned criteria) that refer user to look at comments (ie footnotes), there is probably a hidden datum somewhere that tells the front end how to treat these values. I would imagine this behavior (either footnote or replace-value-with-comments) would be uniform for a given ITEMID. If not, maybe the front end is doing this based on the length of the comments for that row.

Mauvila avatar Sep 22 '20 07:09 Mauvila