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.

Sign up for GitHub

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

Jump to bottom

How to determine IV start/end time? Ambiguity in dose. #347

Closed
lmockus opened this issue Dec 5, 2017 · 27 comments
Closed

How to determine IV start/end time? Ambiguity in dose. #347

lmockus opened this issue Dec 5, 2017 · 27 comments
Labels
mimic-iii

Comments

@lmockus
Copy link

lmockus commented Dec 5, 2017

Hi,

For vancomycin inputevents_mv row_id=429 gives starttime at 8 and endtime at 8:01. How to determine actual administration duration?
In row_id=462 amount is 500. What does it mean? Perhaps this came from half 1g frozen bag or 500mg vial? For row_id=429 the amount=1 dose which is quite ambiguous as well.
In both cases rate=0.

Thanks in advance for any suggestions.

L
@lmockus
Copy link
Author

lmockus commented Dec 5, 2017

My guess it was confusion on my part. It seems that continuous IV in ordercategorydescription implies intermittent iv. And vancomycin is administered only via bolus (rate is always 0). Theoretically "Vancomycin powder for solution for infusion must be administered intravenously. Each dose should be administered at a rate not exceeding 10 mg/min or over a period of time of at least 60 minutes (whichever is longer)."

The goal of my project includes fitting vancomycin PK profiles to compartmental model and therefore any insight on vancomycin administration is appreciated.

Also I found that with itemid=225798 (vancomycin) there non IV administration events (row_id=907304).

So mystery remains:

  • how from 1 dose find out mg administered
  • is administration really bolus
  • is oral administration also recorded in inputevents_mv

Thanks a lot.

L

@alistairewj
Copy link
Member

On the page describing inputevents_mv there is a note:

A bolus will be listed as ending one minute after it started, i.e. ENDTIME = STARTTIME + 1 minute

This is what you're observing - I think vanco is always given as a bolus so you will always see a 1 minute duration.

Regarding the unit of measurement, you just have to deal with what you get. A simple count of the amounts showed that ~95% of the time the amount == 1, likely that they were documenting 1 dose. In the case you mention, presumably they documented 500 implying 500mg, but it appears to us as "500 doses" because the unit of measurement is fixed for the itemid.

One suggestion is to check out the totalamount column as it seems that this varies between 150ml - 2000ml. This column is the total amount of fluid in the container that was administered (for hung IV this is a bag, in this case it's probably a vial).

Oral administration is not recorded in this table, typically. One suggestion I would make is to cross-reference this table with the prescriptions table, which will have prescriptions of vancomycin and perhaps more detail about the formulation. It will require a bit of clever coding to match them up (since prescriptions only has resolution to the day), and be careful about joining on icustay_id (see #345), but other than that should work.

@lmockus
Copy link
Author

lmockus commented Dec 19, 2017

Thanks a lot. I figured an procedure how to find the dose for each IV. Sometimes they use bags, sometimes vials so there is a way to figure out the dose. I can share the mysql query if it is of interest.

I am still concerned about bolus. The recommended way is to IV for 1+ hr no to get red-mans syndrome.

Another concern is that there is inconsistency in vanco levels. For example for patient 16590 the IV of 1000 mg (frozen bag) was administered on 6/6/2181 based on inputevents_mv but vanco levels were 16.1 ug/mL on 6/7/2181 5:35 (based on labevents) and 21.1 ug/mL on 6/8/2181 4:33 - it looks vanco levels grow although there is no IV. There are more cases like this. To make sure that I am not missing dose administration I selected all events from chartevents, inputevents_mv, inputevents_cv, labevents for patient 16590 but wasn't able to explain the apparent increase in vanco levels over 24hr without IV. Fitting the data gave 3L/kg volume of distribution (literature reports 1L/kg as well as experience on data from some other hospital) and very small clearance. Is it possible that some IV data is MISSING?

Thanks for any insight,
L

@alistairewj
Copy link
Member

Absolutely we are very interested in queries for new concepts. We can help make it both MySQL/postgres compliant if you make a pull request.

Regarding the IV, I can't think of a reason why any data would be systematically missing. There is some reorganization of the data going from raw to MIMIC, mainly trying to harmonize ITEMIDs together, but this is a non destructive transform. If this kind of issue happens in a large amount of cases, I'd definitely be interested in a query extracting patients with "missing" IV so that I could investigate the raw data and perhaps discuss a case or two with clinicians at the BI.

Finally, might I suggest cross referencing with the prescriptions table? That table is from the hospital provider order entry system and should have all ordered meds. Prescriptions aren't guaranteed to be administered, but it could she'd some light on the situation you encountered.

@lmockus
Copy link
Author

lmockus commented Dec 21, 2017

Thanks a lot for your reply. Sorry for my long comment.

Since I didn't have success with postgres I rewrote all queries in MySQL. The procedure to determine dose I am talking about is:

if(VI.AMOUNTUOM='mg',
VI.AMOUNT,
if(VI.AMOUNTUOM='dose',
if(VI.FORM_UNIT_DISP='VIAL',
VI.AMOUNTVI.FORM_VAL_DISP
substring_index(VI.PROD_STRENGTH,'mg',1),
if(VI.FORM_UNIT_DISP='BAG',
VI.AMOUNTVI.FORM_VAL_DISP
substring_index(VI.PROD_STRENGTH,'g',1)*1000,0)
),0)
where VI is some join of inputevents_mv and prescriptions. Before joining them I have to "clean" prescriptions by removing ambiguous entries. In other words I matched startime with start date and end date. However there are prescriptions for which startdate=enddate. I don't know how to deal with those. I wanted to match inputevents_mv on 2116-06-12 08:35:00 for patient 99836 with prescriptions and would love to get your input.

I will let you know about more "missing" IV data. So far I have confirmed the one in the previous post.

L

@alistairewj
Copy link
Member

alistairewj commented Dec 21, 2017 via email

@lmockus
Copy link
Author

lmockus commented Dec 22, 2017 •
edited by alistairewj

Cool.
I found more patients for which vanco level from lab events increases while there is no IV in the middle.

For patient 97920 labevents show:

ROW_ID, SUBJECT_ID, HADM_ID, ITEMID, CHARTTIME, VALUE, VALUENUM, VALUEUOM, FLAG
27612422, 97920, 192787, 51009, 2168-06-22 18:30:00, 10.6, 10.6, ug/mL, 
27612481, 97920, 192787, 51009, 2168-06-24 04:58:00, 57.4, 57.4, ug/mL, abnormal

but the latest entry from inputevents_mv is:

ROW_ID, SUBJECT_ID, STARTTIME
3400380, 97920, 2168-06-19 16:24:00

This is a substantial increase in vanco level which can be explained by "missing" IV, entry error...

Based on your comments for prescription dates (end date implies that prescription is valid for all day) the queries to build the dose amount/time are:

  • Remove the patients with ambiguous doses (in vanco_ambig1)
  • determine the amount (see my previous comment)
    As you see I build some intermediate tables (still not an expert) to find patients which are prescribed unambiguous doses. vanco_inputs corresponds to inputevents_mv with patients that have vanco prescriptions.
# VANCO_AMBIG_INIT=rows in VANCO_INPUTS 
# match to 1) multiple precriptions with 
# different doses but are for the same window 
# or to 2) multiple prescriptions that have the 
# same dose but are for different windows or
# to 3) single prescription
# also there are rows which doesn't match 
# 1) implies ambiguous dose

DROP TABLE IF EXISTS VANCO_AMBIG_INIT CASCADE;
CREATE TABLE VANCO_AMBIG_INIT
(
	ROW_ID INT NOT NULL,
#    TIME DATETIME NOT NULL,
#	STARTDATE DATETIME,
#	ENDDATE DATETIME,
	PROD_STRENGTH VARCHAR(120),
    DOSE_VAL_RX VARCHAR(120),
	DOSE_UNIT_RX VARCHAR(120),
	FORM_VAL_DISP VARCHAR(120),
	FORM_UNIT_DISP VARCHAR(120)
) ;
# joining by hadm_id & icustay_id doesn't work
# since prescriptions may use different 
# icustay_id than inputevents_mv
# transfer table shows how patient is
# being transfered and prescription written
# before patient is transferred may be valid
# after patient is transferred
# an example is patient 16590 who changed
# wards while staying in the same care unit
# TSICU
insert into VANCO_AMBIG_INIT
select distinct IE.ROW_ID,
P.PROD_STRENGTH,
P.DOSE_VAL_RX,P.DOSE_UNIT_RX,
P.FORM_VAL_DISP,P.FORM_UNIT_DISP
from VANCO_INPUTS as IE
left join VANCO_PRESCRIPTIONS as P on 
(P.SUBJECT_ID=IE.SUBJECT_ID)
where 
P.STARTDATE<=IE.STARTTIME
and ADDDATE(P.ENDDATE,INTERVAL 1 DAY)>=
IE.STARTTIME; 
# some prescriptions
# were administered on the end date
# row_id corresponds to vanco_inputs

# VANCO_AMBIG=rows in VANCO_AMBIG_INIT
# that correspond to 1) 

DROP TABLE IF EXISTS VANCO_AMBIG CASCADE;
CREATE TABLE VANCO_AMBIG (
	ROW_ID INT NOT NULL,
    primary key (ROW_ID)
) ;

insert into VANCO_AMBIG
select T.ROW_ID from
(select ROW_ID,COUNT(ROW_ID) as c
from VANCO_AMBIG_INIT
group by ROW_ID having c>1) as T;

# VANCO_UNAMBIG=rows in VANCO_AMBIG_INIT
# that corresponds to 2) and 3) 

DROP TABLE IF EXISTS VANCO_UNAMBIG CASCADE;
CREATE TABLE VANCO_UNAMBIG like VANCO_AMBIG_INIT;
alter table VANCO_UNAMBIG
add primary key (ROW_ID);

insert into VANCO_UNAMBIG
select VAI.ROW_ID,VAI.PROD_STRENGTH,
VAI.DOSE_VAL_RX,VAI.DOSE_UNIT_RX,
VAI.FORM_VAL_DISP,VAI.FORM_UNIT_DISP  
from VANCO_AMBIG_INIT as VAI
left join VANCO_AMBIG as VA on
(VA.ROW_ID=VAI.ROW_ID)
where VA.ROW_ID is null;

# VANCO_AMBIG1=patients with ambiguous vanco doses

DROP TABLE IF EXISTS VANCO_AMBIG1 CASCADE;
CREATE TABLE VANCO_AMBIG1
(
	SUBJECT_ID INT NOT NULL,
    primary key (SUBJECT_ID)
);

insert into VANCO_AMBIG1    
select distinct SUBJECT_ID 
from VANCO_INPUTS as VI
inner join VANCO_AMBIG as VA on
(VA.ROW_ID=VI.ROW_ID);

L

@lmockus
Copy link
Author

lmockus commented Dec 23, 2017 •
edited by alistairewj

The query to display the history of IV and labs is:

set @subj=94864;
SELECT STARTTIME as time,AMOUNT as val,AMOUNTUOM as uom FROM INPUTEVENTS_MV
where subject_id=@subj and ITEMID=225798
union
SELECT CHARTTIME as time,VALUENUM as val,VALUEUOM as uom FROM LABEVENTS
where subject_id=@subj and ITEMID=51009
order by time;

For this particular patient it looks vanco levels are rising while there is no IV to support:

time val uom
2179-12-14 08:30:00 1 dose
2179-12-15 05:54:00 15.7 ug/mL
2179-12-16 06:07:00 16.8 ug/mL
2179-12-16 08:00:00 1 dose
2179-12-17 06:01:00 24.7 ug/mL
2179-12-18 05:43:00 7.4 ug/mL
2179-12-20 11:00:00 27.3 ug/mL

There are a lot of such patients - I wrote a script in R to extract those:

1709 1709 4962 4966 16590 19412 22788 29328 29959 30659 40526 42473
42694 44589 47758 48340 48677 48996 49623 50148 50494 50939 51203 53070
53273 53766 54537 54894 55337 55597 56304 57599 58732 58774 58947 59039
59156 60775 61068 62795 62980 63240 63686 64904 64904 65936 66157 66899
66899 67050 67651 68591 68890 68937 69020 70717 72851 73873 76541 79294
79294 82296 86782 87158 87416 91855 92644 92644 93321 94008 94864 96920
97920

L

@lmockus
Copy link
Author

lmockus commented Jan 3, 2018 •
edited by alistairewj

I also found a bunch of patients that have vanco levels before first dose was administered. One of them is 357. The first vanco measurement is recorded in chartevents and labevents on 12/12/2197 7:31. There was no obvious vanco administration before. The first vanco prescription is two years later:

# ROW_ID, SUBJECT_ID, HADM_ID, ICUSTAY_ID, STARTDATE, ENDDATE, DRUG_TYPE, DRUG, DRUG_NAME_POE, DRUG_NAME_GENERIC, FORMULARY_DRUG_CD, GSN, NDC, PROD_STRENGTH, DOSE_VAL_RX, DOSE_UNIT_RX, FORM_VAL_DISP, FORM_UNIT_DISP, ROUTE
2846668, 357, 117876, 0, 2199-12-22 00:00:00, 2199-12-23 00:00:00, MAIN, Vancomycin, , , VANC1F, 043952, 00338355248, 1g Frozen Bag, 1000, mg, 1, BAG, IV

L

alistairewj added a commit that referenced this issue Jan 8, 2018
@alistairewj
investigating vanco, ref #347
9e7f6ae
@alistairewj
Copy link
Member

I finally found some time to look into this. I added a notebook with my work to the repo - see commit above or click here: https://github.com/MIT-LCP/mimic-code/blob/9e7f6aea2ff17086cac51101860d5a70ed5942ef/notebooks/vancomycin-dosing.ipynb

Here's my take.

subject_id 97920

This one is totally as we'd expect:

  • Prescription on the 18th
  • Admitted to the ICU on the 18th (1am)
  • IV infusion on the 18th (9am, 8pm)
  • Prescription on the 19th-21st
  • Measured vanco on 19th
  • IV on the 19th (8am, 4pm)
  • Discharged from the ICU
  • POE/lab measurements continue from 20th onward, but no IV data since they are outside the ICU

subject_id 94864

The only inconsistency is a rise from 15.7 to 16.8 between the 15th/16th morning labs.

  • Admitted on the 10th
  • Prescribed vanco 11th-15th with reasonable rising/falling of measured values
  • Level rises between 15th/16th with no explanation
  • Discharged ICU 18th

Her notes indicate an 8-day course so likely she received vanco between 15th/16th, unsure why it's not documented in the chart.

subject_id 357

Two issues at play here. (1) Patients admitted under the CareVue database system didn't have their antibiotics charted in the flowsheet - as a result you don't see anything in inputevents_cv, (2) I think you have missed a prescription. I have a prescription for vancomycin for this patient on 2198-08-07 to 2198-08-10 which matches their lab data.

Hopefully this explains most patients. Not sure what happened with subject_id 94864 but perhaps it is an infrequent case.

@lmockus
Copy link
Author

lmockus commented Jan 8, 2018 via email •
edited by alistairewj

@alistairewj
Copy link
Member

Happy to support research!

In fact the opposite is true; vanco labs are available outside the ICU. It is the IV delivery that is unavailable outside the ICU. I also noticed that, while the actual numeric value stored in the chartevents data is a duplicate of the labevents data (which we expect, because chartevents sources lab data from the lab database, which is labevents), the label in chartevents gives more information ("Trough", "Peak", and "Random"). Might be useful for your work.

So to recap:

  1. Lab data is available outside the ICU
  2. Prescriptions are available outside the ICU, but have limited time resolution (on the day)
  3. IV administration is available only inside the ICU, but has good time resolution

@lmockus
Copy link
Author

lmockus commented Jan 8, 2018 via email

@alistairewj
Copy link
Member

alistairewj commented Jan 8, 2018 via email

@lmockus
Copy link
Author

lmockus commented Jan 9, 2018 via email

@alistairewj
Copy link
Member

Yes, you're correct about the IV.

I checked chartevents just in case - you're right, all vanco measurements are in labevents. The only addition that chartevents adds is the label sometimes states "Trough", "Random", or "Peak", which can help you infer some things about when the patient was dosed. Otherwise it's a straight duplicate of labevents.

@lmockus
Copy link
Author

lmockus commented Jan 10, 2018 via email

@alistairewj
Copy link
Member

Could you provide more detail on what you're wondering? Is this still related to vancomycin? If not it's worth raising a new issue.

@lmockus
Copy link
Author

lmockus commented Jan 10, 2018 via email

@lmockus
Copy link
Author

lmockus commented Jan 10, 2018

Thanks a lot. I think the vanco investigation script helped immensely with resolving this issue.

L

@lmockus lmockus closed this as completed Jan 10, 2018
@alistairewj
Copy link
Member

Ah, glad it helped! Good luck in your project!

@lmockus
Copy link
Author

lmockus commented Jan 10, 2018 via email

@tompollard
Copy link
Member

Will you be able to help me to figure out why for some patients # of admits
to icu is different from # of dischs from icu? There are lot of patients

@imockus this issue appears to be unrelated to your original question. Please raise a new issue and provide code for reproducing the list of patients that you've found.

alistairewj added a commit that referenced this issue Jan 10, 2018
@alistairewj
fix icu admit/disch fields, ref #347
8764a61
@alistairewj
Copy link
Member

@tompollard I didn't realize it immediately either but I think this is about the https://github.com/MIT-LCP/mimic-code/blob/dedd0faed8273748f0db6034088713d62f226305/notebooks/vancomycin-dosing.ipynb code

I made the assumption in that code that an ICU discharge event in the transfers table would have a prev_careunit of an ICU - but you seem to have found that it's not true. Looking at the patient you highlight:

select hadm_id, event_type
, prev_careunit, curr_careunit
, prev_wardid, curr_wardid
, intime, outtime
 from transfers
where hadm_id = 149357;
hadm_id eventtype prev_careunit curr_careunit prev_wardid curr_wardid intime outtime
149357 admit 45 07-16 19:08:18 07-19 00:25:56
149357 transfer MICU 45 52 07-19 00:25:56 07-22 13:28:58
149357 transfer 36 36 07-22 13:28:58 07-31 16:44:24
149357 discharge 36 07-31 16:44:24

So I guess the admission/discharge/transfer table doesn't include some transfers (either that or the patient magically teleported from ward 52 to ward 36).

Just revised the code to not make this assumption. Things should make more sense now.

@lmockus
Copy link
Author

lmockus commented Jan 10, 2018

Awesome. I will test it out.

Do you want me to open another issue so you have a good history or just be informal?

L

@alistairewj
Copy link
Member

That's ok - no need for a new issue for the solved problem - but if something else comes up it's worth raising a new one.

@lmockus
Copy link
Author

lmockus commented Jan 11, 2018 via email

@alistairewj alistairewj mentioned this issue Mar 30, 2018
Closed
@SSMK-wq SSMK-wq mentioned this issue Oct 9, 2019
Closed
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
mimic-iii
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@tompollard @alistairewj @briangow @lmockus