I think we should discuss this...tomorrow? Jim James R. Campbell MD campb...@unmc.edu<mailto:campb...@unmc.edu> Office: 402-559-7505 Secretary: 402-559-7299 Pager: 402-888-1230
On Jun 2, 2014, at 12:25 PM, "Dan Connolly" <dconno...@kumc.edu<mailto:dconno...@kumc.edu>> wrote: It's the other way around: interoperation requires sharing paths (i.e. hierarchies), not codes. -- Dan ________________________________ From: Campbell, James R [campb...@unmc.edu<mailto:campb...@unmc.edu>] Sent: Sunday, June 01, 2014 10:40 AM To: Hickman, Hubert B Cc: Dan Connolly; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org>; John Steinmetz Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 I see....so Dan's point is that the path can be anything as long as it is associated with the correct concept_cd in their concept_dimension table. The leaf is not required to be the code itself. Sorry to be so dense. But whatever the hierarchies set up for the site users to browse the i2b2 hierarchy, interoperation between sites requires that the observation_fact.concept_cd to be the common query element Jim James R. Campbell MD campb...@unmc.edu<mailto:campb...@unmc.edu> Office: 402-559-7505 Secretary: 402-559-7299 Pager: 402-888-1230 On Jun 1, 2014, at 10:16 AM, "Hickman, Hubert B" <huhick...@nebraskamed.com<mailto:huhick...@nebraskamed.com>> wrote: i2b2 uses the concept path to create a set of concept codes. The observation fact table only knows concept codes and does not know about the concept path. So long as the path correctly yields the set of concept codes, we are good to go. As long a site has metadata where the path yields the correct concept codes for that site, we can interoperate just fine, I think. HH ________________________________ From: Campbell, James R [campb...@unmc.edu<mailto:campb...@unmc.edu>] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> Cc: John Steinmetz Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 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 the query above on our i2b2 platform my use case is to find all my patients with a BMI greater than 19. So my expectation is to query all observation_facts for concept_cd = LOINC:39156-5 and to test their Nval_num >19. The SQL example that follows below shows the structure in our database from the load that Hubert has been developing using the modified metadata from Nathan. This conceptualization was the basis of the queries that I included in the PCORI model for testing standardization and they still seem to me to be correct but they apparently cannot be rendered using the i2b2 query tools as Phillip pointed out. I now understand that the nature of the query that i2b2 develops explicitly includes concept_path and that is unfortunate in a way since it means that for interoperability across all sites we must agree not only on concept coding but also on hierarchical metadata. It also means that we cannot deploy standard coding within multiple contexts, such as employing LOINC codes in the field definition of NACCR data since the difference in path changes the query results. This would require multiple i2b2 queries with an appreciation of every context (hierarchy) within which it occurs. In the case of LOINC, the hierarchical construction is somewhat arbitrary and not material to the meaning of the concept definition whereas in SNOMED CT it definitely is. I also now understand a bit better why Dan was concerned about modifying the LOINC class hierarchy that Nathan built. In building our plans for interoperation, it seems that we will have to agree on the operators/tools for queries between sites as well as on the standard ontologies/code sets to deploy to assure that a query can execute at all sites with the same desired result. Dan’s point that “paths are sufficient” assures that i2b2 queries will function for one site but to be sure we have a query that will interoperate, the query must not depend on the concept path as in the example from Hubert. select concept_cd from BlueHeronData.concept_dimension where concept_path LIKE '\LP29694-4\LP30604-0\LP29703-3\LP7774-5\39156-5\% The class hierarchy from Regenstrief that Nathan employed has polyhierarchical features that i2b2 would treat as distinct elements if the i2b2 query is the shared model across sites. Jim ________________________________ From: Hickman, Hubert B [huhick...@nebraskamed.com<mailto:huhick...@nebraskamed.com>] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> 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: gpc-dev-boun...@listserv.kumc.edu<mailto:gpc-dev-boun...@listserv.kumc.edu> [gpc-dev-boun...@listserv.kumc.edu<mailto:gpc-dev-boun...@listserv.kumc.edu>] on behalf of Dan Connolly [dconno...@kumc.edu<mailto:dconno...@kumc.edu>] Sent: Thursday, May 29, 2014 10:22 PM To: Campbell, James R; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> 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 [campb...@unmc.edu<mailto:campb...@unmc.edu>] Sent: Wednesday, May 28, 2014 10:37 PM To: Dan Connolly; gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> Cc: m...@wisc.edu<mailto:m...@wisc.edu>; bo...@uthscsa.edu<mailto:bo...@uthscsa.edu>; miller.aa...@mcrf.mfldclin.edu<mailto:miller.aa...@mcrf.mfldclin.edu>; 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 [dconno...@kumc.edu<mailto:dconno...@kumc.edu>] Sent: Tuesday, May 27, 2014 10:21 AM To: gpc-dev@listserv.kumc.edu<mailto:gpc-dev@listserv.kumc.edu>; Campbell, James R; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> Cc: m...@wisc.edu<mailto:m...@wisc.edu>; bo...@uthscsa.edu<mailto:bo...@uthscsa.edu>; miller.aa...@mcrf.mfldclin.edu<mailto:miller.aa...@mcrf.mfldclin.edu>; 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 [d...@madmode.com<mailto:d...@madmode.com>] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edu<mailto:campb...@unmc.edu>; Dan Connolly; nwil...@uwhealth.org<mailto:nwil...@uwhealth.org> Cc: m...@wisc.edu<mailto:m...@wisc.edu>; bo...@uthscsa.edu<mailto:bo...@uthscsa.edu>; miller.aa...@mcrf.mfldclin.edu<mailto:miller.aa...@mcrf.mfldclin.edu>; 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 Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
