-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Comments
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. |
Same issue for heart rates.
… On Mar 27, 2018, at 10:26 AM, Alistair Johnson ***@***.***> wrote:
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.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#412 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADQQCynGv0xo50MvHM39hMDX-qLCcGXrks5tikwygaJpZM4S8uFK>.
|
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. |
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? |
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 |
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!)
The text was updated successfully, but these errors were encountered: