Our plans are a little rough in this area. We have a closely related ticket scheduled for our March 16 release, but it's assigned to me, and I'm struggling to fit ETL development time in between project management stuff. The ticket was opened May 2015 and it has slipped releases 9 times since then. :-/
-- Dan ________________________________ From: Phillip Reeder [[email protected]] Sent: Wednesday, February 10, 2016 3:55 PM To: Dan Connolly Cc: Larose, Eric R; [email protected] Subject: Re: SCILHS i2b2 to CDM on Oracle I'd vote to go ahead and make the required schema and ETL changes. But I don't want to do so if the GPC/KUMC/etc are not going to do the same. The alternative would be for someone to maintain a GPC fork of the code. Or create some additional SQL to create a view with those schema changes. What's the KUMC timeline for trying this out? Phillip Sent from my iPhone On Feb 10, 2016, at 2:54 PM, Dan Connolly <[email protected]<mailto:[email protected]>> wrote: At HackathonThree<https://informatics.gpcnetwork.org/trac/Project/wiki/HackathonThree> we considered our evaluation of the SCILHS approach (#381<https://informatics.gpcnetwork.org/trac/Project/ticket/381>) and decided yes, it looks good. We considered the patient dimension stuff (e.g. Sep 18 comment<https://informatics.gpcnetwork.org/trac/Project/ticket/191#comment:15>). On the one hand, the entire “SCILHS i2b2 CDM Documentation v2.0.2.pdf” document was available to any of us who wanted to look before we made our decision, but I don't believe we considered this INOUT_CD stuff in particular, so we could look at it as new information that we could use to reconsider the decision (ref: decision process<https://informatics.gpcnetwork.org/trac/Project/wiki/DataRepositoryManagement#design-process>). Any preferences? As to KUMC, we plan to give the SCILHS code a whirl and open specific issues as and when we find them... preferably upstream in the i2p-transform<https://github.com/SCILHS/i2p-transform> repository. -- Dan ________________________________ From: [email protected]<mailto:[email protected]> [[email protected]<mailto:[email protected]>] on behalf of Phillip Reeder [[email protected]<mailto:[email protected]>] Sent: Wednesday, February 10, 2016 2:37 PM To: Larose, Eric R Cc: [email protected]<mailto:[email protected]> Subject: Re: SCILHS i2b2 to CDM on Oracle Dan/Russ, >From a GPC perspective, are we adopting this as the new standard? It involves >modifying our i2b2 ETL processes and adding columns to tables. I want to make >sure everyone is on board. Phillip Sent from my iPhone On Feb 10, 2016, at 2:07 PM, Larose, Eric R <[email protected]<mailto:[email protected]>> wrote: Our Encounter Types were in our INOUT_CD, so those worked correctly for us. This would definitely be frustrating if not the case. Those other columns are mentioned about being added in the “SCILHS i2b2 CDM Documentation v2.0.2.pdf” document on the MSSQL side. Not sure if these directions were in Oracle instructions or not. For us, we don’t have discharge information, so these were going to be null values for use anyway. Mapping Encounters We anticipate sites will need to ETL additional encounter information to meet PCORI requirements. We expect this data, except for DRGs, will be stored as additional columns in the visit_dimension table . This is detailed in the SCILHS_Encounter_ETL_Guidance_v11.xslx spreadsheet. See especially the red columns (new columns) and the yellow columns (existing columns, but potentially new data required). SQL code to add the columns (in MSSQL format) is below: ALTER TABLE [dbo].[VISIT_DIMENSION] ADD [DRG] varchar(50) NULL, [DISCHARGE_STATUS] varchar(25) NULL, [DISCHARGE_DISPOSITION] varchar(25) NULL, [LOCATION_ZIP] varchar(25) NULL, [ADMITTING_SOURCE] varchar(25) NULL, [FACILITYID] varchar(25) NULL, [PROVIDERID] varchar(25) NULL Thanks, Eric LaRose x93591 From: Phillip Reeder [mailto:[email protected]] Sent: Wednesday, February 10, 2016 1:19 PM To: Larose, Eric R; [email protected]<mailto:[email protected]> Subject: Re: SCILHS i2b2 to CDM on Oracle 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. ________________________________ 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
