Dan Phillip
I now understand the point you are making about the nature of i2b2 queries. I have more to learn about i2b2, that is clear. When I submit this query on our i2b2 platform To return to the basic issue of developing interoperable datasets within ________________________________ From: Hickman, Hubert B [[email protected]] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; [email protected]; [email protected] Cc: John Steinmetz Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 Let me give a concrete example: Here is the relevant bits of the XML that Dan is referring to - in this case a query for BMI >19, using a slightly modified LOINC metadata table <item> <hlevel>4</hlevel> <item_name>39156-5: Body mass index (bmi) [ratio]</item_name> <item_key>\\Laboratory_Measurements\LP29694-4\LP30604-0\LP29703-3\LP7774-5\39156-5\</item_key> <item_icon>LAE</item_icon> <tooltip>Clinical measurements \ Body measurements \ Body weight \ General body weight \ 39156-5: Body mass index (bmi) [ratio]</tooltip> <class>ENC</class> <constrain_by_value> <value_operator>GT</value_operator> <value_constraint>19</value_constraint> <value_unit_of_measure>ratio</value_unit_of_measure> <value_type>NUMBER</value_type> </constrain_by_value> <item_is_synonym>false</item_is_synonym> </item> The SQL generated by i2b2 is : 23:59:40,713 INFO [stdout] (Thread-540) insert into BlueHeronData.QUERY_GLOBAL_TEMP (patient_num, panel_count) 23:59:40,713 INFO [stdout] (Thread-540) with t as ( 23:59:40,713 INFO [stdout] (Thread-540) select /*+ index(observation_fact fact_cnpt_pat_enct_idx) */ f.patient_num 23:59:40,714 INFO [stdout] (Thread-540) from BlueHeronData.observation_fact f 23:59:40,714 INFO [stdout] (Thread-540) where 23:59:40,714 INFO [stdout] (Thread-540) f.concept_cd IN (select concept_cd from BlueHeronData.concept_dimension where concept_path LIKE '\LP29694-4\LP30604-0\LP29703-3\LP7774-5\39156-5\%') 23:59:40,714 INFO [stdout] (Thread-540) AND ( modifier_cd = '@' AND (( valtype_cd = 'N' AND nval_num < 20 AND tval_char IN ('E','LE')) OR ( valtype_cd = 'N' AND nval_num <= 20 AND tval_char = 'L' )) ) 23:59:40,715 INFO [stdout] (Thread-540) group by f.patient_num 23:59:40,715 INFO [stdout] (Thread-540) ) The SQL snippet in red yields: LOINC:39156-5 - which is BMI. The way the LOINC metadata is built uses the typical LIKE logic to harvest concept_cd values that it then retrieves from the observation_fact table. I think what Dan is hinting at is that at different facilities that same path may yield a different concept_cd that is BMI (KUH|PAT_ENC:BMI in the case of the heron code base). The path above would be enough to pull that off - as long as the local metadata leaf nodes point to the correct concept code, no matter what they may be called. Dan - if I am misrepresenting things, please say so. I am out of town this upcoming week - so will not be on Tuesday's conference call, but thought it worthwhile to give an example from the LOINC metadata. Hubert ________________________________ From: [email protected] [[email protected]] on behalf of Dan Connolly [[email protected]] Sent: Thursday, May 29, 2014 10:22 PM To: Campbell, James R; [email protected]; [email protected] Cc: John Steinmetz Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 How do you come to the conclusion that use of the LOINC standard for observables requires the leaf concept code 'LOINC: 21838-8’in the Concept_Dimension table for clinical observables? Try running a query and looking at the XML representation of it using the debug messages window: you won't see concept codes at all. They just aren't part of the query the way paths are. (I expect we'll be using the i2b2 XML representation to exchange queries between sites, not having seen any alternative.) I maintain that agreement on paths is necessary and sufficient. It's perhaps unfortunate that these paths will include inessential features of the terms (e.g. the hierarchical aspects of LOINC) but I don't see any way around it. -- Dan ________________________________ From: Campbell, James R [[email protected]] Sent: Wednesday, May 28, 2014 10:37 PM To: Dan Connolly; [email protected]; [email protected] Cc: [email protected]; [email protected]; [email protected]; John Steinmetz Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 I appreciate Phillip's view on compromise, but this is pretty fundamental to the employment of the LOINC standard. I think that the choice of concept path by the i2b2 site manager (and the instantiation of the Clinical LOINC ontology in this case) is not a necessary attribute even if a choice of path for Concept_dimension is a sufficient answer to the protocol for data retrieval. LOINC semantics do not employ the hierarchical relationships in definition of the observable concept as does the SNOMED CT concept model and modifying the class hierarchy provided by Nathan for easier browsing of LOINC is not a matter of importance to the conceptual meaning of standard. Nonetheless, use of the LOINC standard for observables does require the leaf concept code 'LOINC: 21838-8’in the Concept_Dimension table for clinical observables. That is a required element for use of LOINC Jim ________________________________ From: Dan Connolly [[email protected]] Sent: Tuesday, May 27, 2014 10:21 AM To: [email protected]; Campbell, James R; [email protected] Cc: [email protected]; [email protected]; [email protected]; John Steinmetz Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 These documents still have SQL queries in them that directly constrain the observation_fact_table: Select Count(*) >From Observation_Fact Where Concept_CD = ‘LOINC: 21838-8’ (Ethnicity) My May 4 objection<http://listserv.kumc.edu/pipermail/gpc-dev/2014q2/000128.html> to this approach stands. i2b2 concept paths are necessary and sufficient; the generated sql from an i2b2 query using standardized paths may (a) indirect via the concept_dimension to map standard codes to local EMR codes; e.g. LOINC codes to local ethnicity codes and (b) may use other dimensions. The HERON ETL code currently results in (a) though not (b). -- Dan ________________________________________ From: GPC Informatics [[email protected]] Sent: Monday, May 26, 2014 9:52 AM To: [email protected]; Dan Connolly; [email protected] Cc: [email protected]; [email protected]; [email protected]; John Steinmetz Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 ----------------------------------------------+---------------------------- Reporter: campbell | Owner: campbell Type: task | Status: accepted Priority: major | Milestone: initial-data- Component: data-stds | domains Keywords: PCORI CDM V1, GPC data standards | Resolution: Blocking: | Blocked By: 23, 67, 120 ----------------------------------------------+---------------------------- Comment (by campbell): During discussion two weeks ago, GPCDEV reached consensus on elements of the GPC standard model to align with PCORI CDM V1. I have revised the reference model presentation, added code sets where applicable to the data domains and updated the test SQL scripts for assessing CDM adherence. At the DSSNI meeting in Washington we were told that finalization of CDM would be issued shortly with response to the 210+ concerns that were submitted. The task force leader further stated that the Enrollment class in CDM was a placeholder for now and not to be concerned about details of implementing that feature of CDM for time being. Jim -- Ticket URL: <http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:14> gpc-informatics <http://informatics.gpcnetwork.org/> Greater Plains Network - Informatics 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. ________________________________ The Nebraska Medical Center E-mail Confidentiality Disclaimer 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.
_______________________________________________ Gpc-dev mailing list [email protected] http://listserv.kumc.edu/mailman/listinfo/gpc-dev
