Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect units for 'Length in cm' and 'Length Calc Inches' #412

Open
1 task done
EmmaRocheteau opened this issue Mar 27, 2018 · 5 comments
Open
1 task done

Incorrect units for 'Length in cm' and 'Length Calc Inches' #412

EmmaRocheteau opened this issue Mar 27, 2018 · 5 comments

Comments

@EmmaRocheteau
Copy link

EmmaRocheteau commented Mar 27, 2018

Prerequisites

Description

The valueuom column (units) for 'Length in cm' and 'Length Calc Inches' must be incorrect. The issue can be demonstrated with this query:

select d.label, ce.itemid, ce.value, ce.valueuom, ce.charttime
from chartevents as ce
inner join d_items as d on ce.itemid = d.itemid
where subject_id = 10 and d.label in ('Length Calc Inches', 'Length in cm');

EDIT: I can see from your demographics query that it is not an issue there, however it might be confusing for people who aren't using that particular script to obtain height (like me!)

@alistairewj
Copy link
Member

Ah, from your edit I guess you figured out that length is usually used for neonates and so 40cm is a reasonable value. I agree it is confusing having both neonates and adults in the same database and we continue to discuss the best approaches to simplify it for users.

@pszolovits
Copy link
Contributor

pszolovits commented Mar 27, 2018 via email

@EmmaRocheteau
Copy link
Author

No this is still an issue. If you run the query I put there, you can see that 'Length in cm' has units of inches, and the value looks like it is in cm. 'Length Calc Inches' has units of cm, and the value appears as though it is in inches. The reason it is not an issue in the demographics/heightweight script is because you don't use the units column to filter the data in the case statement - you do it by itemid instead, and since the label description corresponds with the correct unit this is not an issue for you. Anyone who tries to use valueuom (units) to filter the data will get spurious results, as I did.

@alistairewj alistairewj reopened this Mar 27, 2018
@alistairewj
Copy link
Member

Ah I see. Yes, that is a pretty common issue. It seems that for a lot of data in CareVue the units were sort of ad-hoc added.

We are always unsure of when to modify raw data to support easier use of the data, because any incorrect assumptions we make will propagate to every analysis that uses MIMIC, but perhaps this is a good example of where we should intervene. Have you found any other units which are inconsistent/worth modifying?

@EmmaRocheteau
Copy link
Author

Not yet, but I will let you know if I do!

I think in this case it shouldn't affect most people if you assume that many people are using your heightweight script to extract that information. It would be quite an easy bug to fix if people have published code elsewhere that takes the mistake into account.

I think if you decide not to modify it, perhaps it would be a good idea to bring it to light on the documentation so people are aware to take extra care when relying on the units column

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants