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
