For the pmnencounter table, It assumes ENCTYPE is in the INOUT_CD field of the visit_dimension. Not the case for us. Also, where are DISCHARGE_STATUS,DISCHARGE_DISPOSITION, ADMITTING_SOURCE supposed to come from? Are these added into the visit_dimension table somewhere in the SCILHS process? I have them in my observation_fact table, but the query seems to think they should be in the visit dimension or something. I can't see how that query would run on SQL server either.
Is there some additional code somewhere to add these into the visit dimension that I'm missing? I'm stuck. Phillip From: <Larose>, Eric R <[email protected]<mailto:[email protected]>> Date: Wednesday, February 10, 2016 at 1:13 PM To: Phillip Reeder <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: RE: SCILHS i2b2 to CDM on Oracle Thanks for your feedback Phillip. #2 got me digging a little deeper. I had mapped these to our local codes like needed, but the script to generate the CDM doesn't fully utilize the metadata table for its logic (the IN vs. LIKE issue you mentioned). It is making some assumptions as to how these local mappings are being filled. It looks like what we currently have for race and sex ended up with a NI for all of the records. I've yet to discuss with Laurel, but we will likely be updating the local mappings with this in mind and re-run. For SQL server it didn't generate any errors when running (that I had seen anyways), but it definitely didn't produce the results that we want for those. Good catch! Thanks, Eric LaRose x93591 From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Phillip Reeder Sent: Wednesday, February 10, 2016 12:13 PM To: [email protected]<mailto:[email protected]> Subject: SCILHS i2b2 to CDM on Oracle Has anyone else attempted the SCILHS i2b2 to CDM code on Oracle? I'm focusing on the demographics table to start with have run into a few things I wanted to share. #1) SCILHS relies on the patient_dimension for the demographics, not the observation_fact. Just something to be aware of, not really a problem as long as you have the patient_dimension built out. #2) The demographics ontology has some rows that use the IN for the operator and some rows that use like. But the code only works for the race/sex where it is using "IN" as the operator. I added a where race.c_operator='IN' , sex.c_operator='IN' , hisp.c_operator='IN' where necessary to avoid the oracle error. #3) For Hispanic, the code is only looking at the race_cd. This only give you 'Yes' or 'No-Information' as values. I think it would make more sense to move the ethnicity information to an ethnicity_cd column. Anyone else working with the i2b2 to CDM on Oracle code? Just wondering if there are any other changes you've had to make to get it working. Thanks, Phillip ________________________________ UT Southwestern Medical Center The future of medicine, today. ________________________________ The contents of this message may contain private, protected and/or privileged information. If you received this message in error, you should destroy the e-mail message and any attachments or copies, and you are prohibited from retaining, distributing, disclosing or using any information contained within. Please contact the sender and advise of the erroneous delivery by return e-mail or telephone. Thank you for your cooperation.
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
