Researching the concept of 233607000|Pneumococcal pneumonia(disorder)| I find 8 distinct paths to the root due to the combinatorial possibilities of the polyhierarchy. I suspect that not all the paths are useful for data browsing or aggregation and I suspect a more parsimonious set would improve usability, or am I needlessly worried? Jim
From: Greater Plains Collaborative Software Development [mailto:[email protected]] On Behalf Of Wanta Keith M Sent: Tuesday, February 04, 2014 1:42 PM To: [email protected] Subject: Re: optional columns in i2b2 dimension tables RE: Minutes of GPV-DEV call 20140128 Jim, that is correct about building multiple paths per concept, because of the multiple inheritance/multiple generalization. In a sense, you end up with multiple concepts (based on the number of parents) in the CONCEPT_DIMENSION. UW is also on 1.6. -Keith From: Greater Plains Collaborative Software Development [mailto:[email protected]] On Behalf Of Phillip Reeder Sent: Tuesday, February 04, 2014 1:38 PM To: [email protected]<mailto:[email protected]> Subject: Re: optional columns in i2b2 dimension tables RE: Minutes of GPV-DEV call 20140128 We're on 1.6 at UT Southwestern. Phillip Sent from my iPhone On Feb 4, 2014, at 1:17 PM, "Campbell, James R" <[email protected]<mailto:[email protected]>> wrote: This message was sent securely using ZixCorp.<http://www.zixcorp.com/get-started/> Of the 4 sites that have reported to my query, Kansas and Marshfield are both running 1.5 while we are installing 1.7 and Iowa has 1.6. We are just now experimenting with expanding the schema that comes with 1.7 since SNOMED and LOINC have no explicit paths built for the concept dimension database. I am wondering if anyone has seen any advice on how to deploy ontologies with polyhierarchy such as SNOMED CT? Since the i2b2 path flattens the hierarchy as a key, it would see that one would have to build multiple paths per concept to capture all the semantics or make some pragmatic decision of which path to support. The latter choice would seem likely to lead to inconsistencies in browsing the data once the ETLs are run. Jim From: Greater Plains Collaborative Software Development [mailto:[email protected]] On Behalf Of Phillip Reeder Sent: Tuesday, February 04, 2014 9:58 AM To: [email protected]<mailto:[email protected]> Subject: Re: optional columns in i2b2 dimension tables RE: Minutes of GPV-DEV call 20140128 My understanding is the same as Dan's with regard to the dimension tables. And with regard to modifiers, It looks like the modifier column was in 1.5, but i2b2 didn't know how to use it. "Introduced in Core i2b2 Version 1.6 In Version 1.6 of i2b2 we begin to use the modifier_cd column in the observation_fact table." https://community.i2b2.org/wiki/display/DevForum/Modifiers+in+i2b2+Data+Model I'd like to propose that we standardize on i2b2 1.6. From what I remember, 1.6 seemed to already be running at the majority of the sites. For those with 1.5 or previous, the data should be able to work in version 1.6, they just won't have modifiers. From there, I think we can start deciding what we want to standardize across sites (Demographics, Diagnoses, etc.) and can start deciding if we want to add/remove columns from various dimensions, query on the fact table only, or just query on dimension tables, etc.. Phillip From: Dan Connolly <[email protected]<mailto:[email protected]>> Date: Monday, February 3, 2014 12:43 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: optional columns in i2b2 dimension tables RE: Minutes of GPV-DEV call 20140128 Well, I can only tell you that my reading is borne out by experience with removing optional columns and adding columns of our own. >From >epic_dimensions_load.sql<https://informatics.kumc.edu/work/browser/heron_load/epic_dimensions_load.sql>: alter table NightHerondata.patient_dimension drop (zip_cd) ; ... alter table NightHerondata.patient_dimension add (date_shift number) ; alter table NightHerondata.patient_dimension add (ssn varchar2(45)) ; alter table NightHerondata.patient_dimension add (age_in_years_num_hipaa number) ; alter table NightHerondata.patient_dimension add (birth_date_hipaa date) ; The way I2B2 dynamically builds queries from c_facttablecolumn, c_tablename, c_columnname, c_columndatatype, and c_operator is also suggestive of the reading that says we can add whatever columns we like to the dimension tables. -- Dan ________________________________ From: Greater Plains Collaborative Software Development [[email protected]<mailto:[email protected]>] on behalf of Wilson Nathan [[email protected]<mailto:[email protected]>] Sent: Monday, February 03, 2014 8:26 AM To: [email protected]<mailto:[email protected]> Subject: Re: Minutes of GPV-DEV call 20140128 After reading that documentation I don't think that it states precisely what you think it states? When I read the documentation; it states that there are required and optional attributes, and that there is not a limit to the number of optional attributes you use nor to the code sets and values used to populate these attribute. It doesn't state that you can add columns as you desire, but rather that you can use the existing optional columns if you choose too. Nathan Wilson UW - Madison From: Greater Plains Collaborative Software Development [mailto:[email protected]] On Behalf Of Dan Connolly Sent: Sunday, February 02, 2014 11:53 PM To: [email protected]<mailto:[email protected]> Subject: Re: Minutes of GPV-DEV call 20140128 I think I said that adding columns to the dimension tables such as patient_dimension has been a documented i2b2 technique as far back as 1.3 or 1.4. Double-checking, I find: "The Patient table may have an unlimited number of optional columns and their data types and coding systems are local implementation-specific." -- 3.3 PATIENT_DIMENSION i2b2 Clinical Research Chart (CRC) Design Document Document Version: 1.1 I2b2 Software Release: 1.4 https://www.i2b2.org/software/projects/hivecore/i2b2core-doc-14.zip I don't believe I had anything to say about what the slides said about modifiers (i.e. that they appear in 1.6). -- Dan ________________________________ From: Greater Plains Collaborative Software Development [[email protected]<mailto:[email protected]>] on behalf of Campbell, James R [[email protected]<mailto:[email protected]>] Sent: Tuesday, January 28, 2014 2:43 PM To: [email protected]<mailto:[email protected]> Subject: Minutes of GPV-DEV call 20140128 GPC standard data model JRC: i2b2 documentation reports changes in functionality by version (now 1.7). Will minimum version be required for data standardization? DC: although documentation reports differently, modifiers available in v1.3 ________________________________ UT Southwestern Medical Center The future of medicine, today. The information in this e-mail may be privileged and confidential, intended only for the use of the addressee(s) above. Any unauthorized use or disclosure of this information is prohibited. If you have received this e-mail by mistake, please delete it and immediately contact the sender. ------------------------------------------------------------------------- This message was secured by ZixCorp<http://www.zixcorp.com>(R).
