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 --+ Changes (by dconnolly): * blockedby: 17, 23, 67, 120 = 23 Comment: we addressed enough of #17, #67, #120 for this work -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:29 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by lv): Marshfield has a draft posted: https://pcornet.centraldesktop.com/c4gpc/file/33747295/ -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:26 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by ngraham): I've created a [https://pcornet.centraldesktop.com/c4gpc/folder/4142694/ folder called PCORI CDM Compliance Worksheet] on the PCORNet Central Desktop and uploaded a [https://pcornet.centraldesktop.com/c4gpc/file/33714066/ draft of the compliance worksheet for KUMC]. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:25 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by campbell): As part of report to PCORI for milestones 2.1, 2.5 and 2.7; it seems logical to me that we consolidate our reporting requirements and simplify procedures for creating aggregate GPC stats. I have enclosed a draft revision of the PCORI form for discussion today Jim -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:21 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by nathan.wilson): Attached part I of my comments here: https://informatics.gpcnetwork.org/trac/Project/attachment/ticket/114/Milestone_27_TestSQLv4_nsw_comments_part_i.docx These comments focus mainly on the current selection of LOINC codes which are to be used in the queries. Once I know what the purpose and the expected results are, I will comment on the SQL queries themselves. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:20 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
No, we don't have a proposed demographics hierarchy; at least not in the GPC section of babel. All we have so far is Diagnoses, Meds (Drug Products by VA Class) and LOINC Codes (a mix of labs and other stuff). We seem to be iterating between the overall design issue (#114) and the specific parts (e.g. demographics #67). In this case, it really would be nicer to be further along on the specifics. Meanwhile, as noted in #67, we do have a PCORI demographics term hierarchy, and as far as I know, it suffices for GPC purposes. I'm not aware that we need any finer distinctions w.r.t. age, sex, race, nor ethnicity. Oh... and A leading proposal was to follow i2b2's [demo] ontology. While paths like \GPC\Patient\... are handy for debugging, I'm agnostic about using less mnemonic standardized codes (as we're doing for Diagnoses) as long as I know how to look up the codes. But 29694-4 doesn't give any results when I try to Search by Codes. I lose at search.loinc.org too. 42784-9 looks fine: Ethnic background stated. I was hoping that Jim's proposal would take the form of actual i2b2 queries that he had executed, either as XML in the document or as queries on babel. For some terms, he might have to use something from the UNMC hierarchy or another site and explain how the relevant terms would end up in a shared GPC ontology. -- Dan From: Phillip Reeder [phillip.ree...@utsouthwestern.edu] Sent: Monday, June 16, 2014 12:36 PM To: gpc-dev@listserv.kumc.edu; campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 Regarding specifically the PATIENTS section of document, do we have a proposed hierarchy for the patient demographics? Jim lists a path like: '\LP29694-4\LP7850-3\42784-9\%¹ (Ethnicity) But I¹m not sure where that path came from. I think if it were created on Babel and looked something like: \GPC\Patient\Ethnicity (L) where the ?? Is the code the loinc experts decide on. Then the document would be consistent with the shared hierarchy that everyone is mapping to. For me, working in i2b2, that is more intuitive than the paths/codes that are currently shown in the document. It would look very much like the PCORI terminologies that Dan created a while ago. The same could be done for vitals with a Œ\GPC\Vitals\¹ hierarchy and other data types. Phillip On 6/16/14, 10:08 AM, GPC Informatics d...@madmode.com wrote: #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: 17, 23, 67, | 120 --+--- - Comment (by nathan.wilson): Attached part I of my comments here: https://informatics.gpcnetwork.org/trac/Project/attachment/ticket/114/Mile stone_27_TestSQLv4_nsw_comments_part_i.docx These comments focus mainly on the current selection of LOINC codes which are to be used in the queries. Once I know what the purpose and the expected results are, I will comment on the SQL queries themselves. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:20 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev UT Southwestern Medical Center The future of medicine, today. ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
Two Quick notes from below. The code referenced in the hierarchy path is LP29694-4. LP stands for LOINC Part and is the underlying code for what is referred to as the LOINC Multi-Axial Hierarchy. In order to search this ID you would need the RELMA tool and not the web search interface. 42784-9 looks fine: Ethnic background stated may look fine on the surface, but when you look at what the definition of this code is, you'll see that it is the stated ethnic background of the patient as captured by the NAACCR tumor registry. We know this by looking at the class of the LOINC code under basic attributes in the link below. http://s.details.loinc.org/LOINC/42784-9.html?sections=Comprehensive Nathan From: Dan Connolly [dconno...@kumc.edu] Sent: Monday, June 16, 2014 1:50 PM To: Phillip Reeder; gpc-dev@listserv.kumc.edu; campb...@unmc.edu; Wilson Nathan Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 No, we don't have a proposed demographics hierarchy; at least not in the GPC section of babel. All we have so far is Diagnoses, Meds (Drug Products by VA Class) and LOINC Codes (a mix of labs and other stuff). We seem to be iterating between the overall design issue (#114) and the specific parts (e.g. demographics #67). In this case, it really would be nicer to be further along on the specifics. Meanwhile, as noted in #67, we do have a PCORI demographics term hierarchy, and as far as I know, it suffices for GPC purposes. I'm not aware that we need any finer distinctions w.r.t. age, sex, race, nor ethnicity. Oh... and A leading proposal was to follow i2b2's [demo] ontology. While paths like \GPC\Patient\... are handy for debugging, I'm agnostic about using less mnemonic standardized codes (as we're doing for Diagnoses) as long as I know how to look up the codes. But 29694-4 doesn't give any results when I try to Search by Codes. I lose at search.loinc.org too. 42784-9 looks fine: Ethnic background stated. I was hoping that Jim's proposal would take the form of actual i2b2 queries that he had executed, either as XML in the document or as queries on babel. For some terms, he might have to use something from the UNMC hierarchy or another site and explain how the relevant terms would end up in a shared GPC ontology. -- Dan From: Phillip Reeder [phillip.ree...@utsouthwestern.edu] Sent: Monday, June 16, 2014 12:36 PM To: gpc-dev@listserv.kumc.edu; campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 Regarding specifically the PATIENTS section of document, do we have a proposed hierarchy for the patient demographics? Jim lists a path like: '\LP29694-4\LP7850-3\42784-9\%¹ (Ethnicity) But I¹m not sure where that path came from. I think if it were created on Babel and looked something like: \GPC\Patient\Ethnicity (L) where the ?? Is the code the loinc experts decide on. Then the document would be consistent with the shared hierarchy that everyone is mapping to. For me, working in i2b2, that is more intuitive than the paths/codes that are currently shown in the document. It would look very much like the PCORI terminologies that Dan created a while ago. The same could be done for vitals with a Œ\GPC\Vitals\¹ hierarchy and other data types. Phillip On 6/16/14, 10:08 AM, GPC Informatics d...@madmode.com wrote: #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: 17, 23, 67, | 120 --+--- - Comment (by nathan.wilson): Attached part I of my comments here: https://informatics.gpcnetwork.org/trac/Project/attachment/ticket/114/Mile stone_27_TestSQLv4_nsw_comments_part_i.docx These comments focus mainly on the current selection of LOINC codes which are to be used in the queries. Once I know what the purpose and the expected results are, I will comment on the SQL queries themselves. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:20 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev UT Southwestern Medical Center The future of medicine
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
I appreciate your point about the more abstract nature of a LOINC code Dan, and that these are less intuitive than the metadata hierarchy that you build for your KU research community. When moving into a broader community of shared users however, the trick is to convince everyone to employ the same descriptive characteristics as you have built when identifying a data element to share in response to a query. By agreeing on the reference concept_cd system we will employ, you can build your metadata hierarchies to suit your users and I can do so for mine and yet we can answer each other's question with the correct piece of data from our systems - assuming that we share an understanding of the reference concept model of meaning. Unfortunately there are a few concepts in the PCORI model that do not have a reference standard, but that is a minority of what we need. Jim From: Dan Connolly [dconno...@kumc.edu] Sent: Monday, June 16, 2014 1:50 PM To: Phillip Reeder; gpc-dev@listserv.kumc.edu; Campbell, James R; nwil...@uwhealth.org Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 No, we don't have a proposed demographics hierarchy; at least not in the GPC section of babel. All we have so far is Diagnoses, Meds (Drug Products by VA Class) and LOINC Codes (a mix of labs and other stuff). We seem to be iterating between the overall design issue (#114) and the specific parts (e.g. demographics #67). In this case, it really would be nicer to be further along on the specifics. Meanwhile, as noted in #67, we do have a PCORI demographics term hierarchy, and as far as I know, it suffices for GPC purposes. I'm not aware that we need any finer distinctions w.r.t. age, sex, race, nor ethnicity. Oh... and A leading proposal was to follow i2b2's [demo] ontology. While paths like \GPC\Patient\... are handy for debugging, I'm agnostic about using less mnemonic standardized codes (as we're doing for Diagnoses) as long as I know how to look up the codes. But 29694-4 doesn't give any results when I try to Search by Codes. I lose at search.loinc.org too. 42784-9 looks fine: Ethnic background stated. I was hoping that Jim's proposal would take the form of actual i2b2 queries that he had executed, either as XML in the document or as queries on babel. For some terms, he might have to use something from the UNMC hierarchy or another site and explain how the relevant terms would end up in a shared GPC ontology. -- Dan From: Phillip Reeder [phillip.ree...@utsouthwestern.edu] Sent: Monday, June 16, 2014 12:36 PM To: gpc-dev@listserv.kumc.edu; campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 Regarding specifically the PATIENTS section of document, do we have a proposed hierarchy for the patient demographics? Jim lists a path like: '\LP29694-4\LP7850-3\42784-9\%¹ (Ethnicity) But I¹m not sure where that path came from. I think if it were created on Babel and looked something like: \GPC\Patient\Ethnicity (L) where the ?? Is the code the loinc experts decide on. Then the document would be consistent with the shared hierarchy that everyone is mapping to. For me, working in i2b2, that is more intuitive than the paths/codes that are currently shown in the document. It would look very much like the PCORI terminologies that Dan created a while ago. The same could be done for vitals with a Œ\GPC\Vitals\¹ hierarchy and other data types. Phillip On 6/16/14, 10:08 AM, GPC Informatics d...@madmode.com wrote: #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: 17, 23, 67, | 120 --+--- - Comment (by nathan.wilson): Attached part I of my comments here: https://informatics.gpcnetwork.org/trac/Project/attachment/ticket/114/Mile stone_27_TestSQLv4_nsw_comments_part_i.docx These comments focus mainly on the current selection of LOINC codes which are to be used in the queries. Once I know what the purpose and the expected results are, I will comment on the SQL queries themselves. -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:20 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by nathan.wilson): Quick Question. What is the purpose of each test and what are the expected/anticipated results for each test in the Milestone_27_TestSQLv4 document? -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:19 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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: 17, 23, 67, | 120 --+ Comment (by campbell): Changing routing on ticket 114 to copy GPC-DEV Thanks Nathan G! -- Ticket URL: http://informatics.gpcnetwork.org/trac/Project/ticket/114#comment:18 gpc-informatics http://informatics.gpcnetwork.org/ Greater Plains Network - Informatics ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
It's the other way around: interoperation requires sharing paths (i.e. hierarchies), not codes. -- Dan From: Campbell, James R [campb...@unmc.edu] Sent: Sunday, June 01, 2014 10:40 AM To: Hickman, Hubert B Cc: Dan Connolly; gpc-dev@listserv.kumc.edu; nwil...@uwhealth.org; John Steinmetz Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 I seeso 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.edumailto: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.commailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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.commailto:huhick...@nebraskamed.com] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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
Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
I think we should discuss this...tomorrow? Jim James R. Campbell MD campb...@unmc.edumailto: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.edumailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 10:40 AM To: Hickman, Hubert B Cc: Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto:nwil...@uwhealth.org; John Steinmetz Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 I seeso 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.edumailto: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.commailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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.commailto:huhick...@nebraskamed.com] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil
Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
If each site has metadata with consistent paths the leaf nodes can be mapped to whatever concept code is apropos for a particular site. Note that this metadata can be in addition to other metadata that a site may already have for the concepts - as Russ said an overlay of the metadata for the purposes of interoperability. HH Sent from my iPhone On Jun 2, 2014, at 7:53 PM, Campbell, James R campb...@unmc.edumailto:campb...@unmc.edu wrote: I think we should discuss this...tomorrow? Jim James R. Campbell MD campb...@unmc.edumailto: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.edumailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 10:40 AM To: Hickman, Hubert B Cc: Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto:nwil...@uwhealth.org; John Steinmetz Subject: Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0 I seeso 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.edumailto: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.commailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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
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 this query on our i2b2 platform
To return to the basic issue of developing interoperable datasets within
From: Hickman, Hubert B [huhick...@nebraskamed.com]
Sent: Sunday, June 01, 2014 12:45 AM
To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edu;
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
hlevel4/hlevel
item_name39156-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_iconLAE/item_icon
tooltipClinical measurements \ Body
measurements \ Body weight \ General body weight \ 39156-5: Body mass index
(bmi) [ratio]/tooltip
classENC/class
constrain_by_value
value_operatorGT/value_operator
value_constraint19/value_constraint
value_unit_of_measureratio/value_unit_of_measure
value_typeNUMBER/value_type
/constrain_by_value
item_is_synonymfalse/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 [gpc-dev-boun...@listserv.kumc.edu] on
behalf of Dan Connolly [dconno...@kumc.edu]
Sent: Thursday, May 29, 2014 10:22 PM
To: Campbell, James R; gpc-dev@listserv.kumc.edu; 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]
Sent: Wednesday, May 28, 2014 10:37 PM
To: Dan Connolly; gpc-dev@listserv.kumc.edu; nwil...@uwhealth.org
Cc: m...@wisc.edu; bo...@uthscsa.edu; miller.aa...@mcrf.mfldclin.edu; John
Steinmetz
Subject: RE: [gpc-informatics] #114: Milestone 2.7 GPC
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
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] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edu; 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] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edu; 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 hlevel4/hlevel item_name39156-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_iconLAE/item_icon tooltipClinical measurements \ Body measurements \ Body weight \ General body weight \ 39156-5: Body mass index (bmi) [ratio]/tooltip classENC/class constrain_by_value value_operatorGT/value_operator value_constraint19/value_constraint value_unit_of_measureratio/value_unit_of_measure value_typeNUMBER/value_type /constrain_by_value item_is_synonymfalse/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
Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
I seeso 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.edumailto: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.commailto: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.edumailto:campb...@unmc.edu] Sent: Sunday, June 01, 2014 8:50 AM To: Hickman, Hubert B; Dan Connolly; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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.commailto:huhick...@nebraskamed.com] Sent: Sunday, June 01, 2014 12:45 AM To: Dan Connolly; Campbell, James R; gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; nwil...@uwhealth.orgmailto: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 hlevel4/hlevel item_name39156-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_iconLAE/item_icon tooltipClinical measurements \ Body measurements \ Body weight \ General body
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
hlevel4/hlevel
item_name39156-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_iconLAE/item_icon
tooltipClinical measurements \ Body
measurements \ Body weight \ General body weight \ 39156-5: Body mass index
(bmi) [ratio]/tooltip
classENC/class
constrain_by_value
value_operatorGT/value_operator
value_constraint19/value_constraint
value_unit_of_measureratio/value_unit_of_measure
value_typeNUMBER/value_type
/constrain_by_value
item_is_synonymfalse/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 [gpc-dev-boun...@listserv.kumc.edu] on
behalf of Dan Connolly [dconno...@kumc.edu]
Sent: Thursday, May 29, 2014 10:22 PM
To: Campbell, James R; gpc-dev@listserv.kumc.edu; 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]
Sent: Wednesday, May 28, 2014 10:37 PM
To: Dan Connolly; gpc-dev@listserv.kumc.edu; nwil...@uwhealth.org
Cc: m...@wisc.edu; bo...@uthscsa.edu; 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
Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
The problem is that i2b2 does not query based on a code. It queries based on a path. For example, I may have a path for for Ethnicity of: \GPC\Demographics\Ethnicity\ aka LOINC:21838-8 \GPC\Demographics\Ethnicity\hispanic Ethnicity:Hisp \GPC\Demographics\Ethnicity\hispanic\Dominican Ethnicity:Dom \GPC\Demographics\Ethnicity\hispanic\Mexican Ethnicity:Mex \GPC\Demographics\Ethnicity\hispanic\Puerto Rican Ethinicity:PR \GPC\Demographics\Ethnicity\not hispanic The codes on the right are what appear in my data(Ethnicity:Hisp,Ethnicity:DOM….), not 'LOINC: 21838-8’ So your query for 'LOINC: 21838-8’ would return 0 results where mine using the path of '\GPC\Demographics\Ethnicity\%’ would return the correct count. If you really want to query based on the loinc code, you would have to do something like (not sure if this would work with this syntax), Select count(*) from observation_fact where concept_cd in (Select concept_cd from concept_dimension where path like ( Select path || ‘%' from concept_dimension where concept_cd = ‘LOIN:21838-8’)) Phillip From: Campbell, James R campb...@unmc.edumailto:campb...@unmc.edu Date: Wednesday, May 28, 2014 at 10:37 PM To: Dan Connolly dconno...@kumc.edumailto:dconno...@kumc.edu, gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu, nwil...@uwhealth.orgmailto:nwil...@uwhealth.org nwil...@uwhealth.orgmailto:nwil...@uwhealth.org Cc: John Steinmetz jsteinm...@kumc.edumailto:jsteinm...@kumc.edu 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.edumailto:dconno...@kumc.edu] Sent: Tuesday, May 27, 2014 10:21 AM To: gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu; Campbell, James R; nwil...@uwhealth.orgmailto:nwil...@uwhealth.org Cc: m...@wisc.edumailto:m...@wisc.edu; bo...@uthscsa.edumailto:bo...@uthscsa.edu; miller.aa...@mcrf.mfldclin.edumailto: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 objectionhttp://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.commailto:d...@madmode.com] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edumailto:campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.orgmailto:nwil...@uwhealth.org Cc: m...@wisc.edumailto:m...@wisc.edu; bo...@uthscsa.edumailto:bo...@uthscsa.edu; miller.aa...@mcrf.mfldclin.edumailto: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
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] Sent: Wednesday, May 28, 2014 10:37 PM To: Dan Connolly; gpc-dev@listserv.kumc.edu; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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] Sent: Tuesday, May 27, 2014 10:21 AM To: gpc-dev@listserv.kumc.edu; Campbell, James R; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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 objectionhttp://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] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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. ___ Gpc-dev mailing list Gpc-dev
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] Sent: Tuesday, May 27, 2014 10:21 AM To: gpc-dev@listserv.kumc.edu; Campbell, James R; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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 objectionhttp://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] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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. ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
RE: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
Looks like Jim has prepared new documents for us to discuss... -- Dan From: GPC Informatics [d...@madmode.com] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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 ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
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 objectionhttp://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] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.org Cc: m...@wisc.edu; bo...@uthscsa.edu; 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 ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
Re: [gpc-informatics] #114: Milestone 2.7 GPC harmonizes with PCORI CDM V1.0
I think simply changing the query to be similar to the following would take care of Dan’s objection. We need a demographics tree structure created and added to Babel. Select count(*) from observation_fact join concept_dimension on observation_fact.concept_cd=concept_dimension.concept_cd and concept_dimension.concept_path like ‘\GPC\Demographics\Ethnicity\%’ NOTE: Where '\GPC\Demographics\Ethnicity\’ has the code ‘LOINC: 21838-8’in the common terminology. Phillip From: Dan Connolly dconno...@kumc.edumailto:dconno...@kumc.edu Date: Tuesday, May 27, 2014 at 10:21 AM To: gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu gpc-dev@listserv.kumc.edumailto:gpc-dev@listserv.kumc.edu, campb...@unmc.edumailto:campb...@unmc.edu campb...@unmc.edumailto:campb...@unmc.edu, nwil...@uwhealth.orgmailto:nwil...@uwhealth.org nwil...@uwhealth.orgmailto:nwil...@uwhealth.org Cc: John Steinmetz jsteinm...@kumc.edumailto:jsteinm...@kumc.edu 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 objectionhttp://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.commailto:d...@madmode.com] Sent: Monday, May 26, 2014 9:52 AM To: campb...@unmc.edumailto:campb...@unmc.edu; Dan Connolly; nwil...@uwhealth.orgmailto:nwil...@uwhealth.org Cc: m...@wisc.edumailto:m...@wisc.edu; bo...@uthscsa.edumailto:bo...@uthscsa.edu; miller.aa...@mcrf.mfldclin.edumailto: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 UT Southwestern Medical Center The future of medicine, today. ___ Gpc-dev mailing list Gpc-dev@listserv.kumc.edu http://listserv.kumc.edu/mailman/listinfo/gpc-dev
