The LP concepts seems to be imported into Athena - very good.
In order to determine what other lab test have a component of creatinine the relationships from LoincPartLink.csv would be very useful to have in Athena OMOP Vocabulary CONCEPT_REALTIONSHIP table.
The LP concepts (present in Athena) are not linked to their lab test they help define. (not good at all)
Why are they not added? (not visible in athena browser) neither for the Loing Part concept or the main LOINC concept.
This forces me to use the raw LOINC CSV files in addition to Athena OMOP vocab (when I would rather rely solely on the Athena OMOP Vocab).
Can they be added in next cycle of ETL of LOINC?
(I did study this folder briefly here Vocabulary-v5.0/LOINC at master ¡ OHDSI/Vocabulary-v5.0 ¡ GitHub)
(We seem to use LOINC/SNOMED CT Expression Association and Map Sets File and the file LoincPartLink is much better I think) (and I also filed a github issue about this)
So I heard from Anna that this is on radar for the vocab team. For organizing lab tests into groups, that is very helpful. When do you think the result would be released into Athena?
@Vojtech_Huser
Unfortunately, recent activities were aimed to LOINC - SNOMED relationships.
Ok, letâs prioritize this multiaxial hierarchy issue you have mentioned.
Not so easy to say when. Around 1 month sounds good for you?
@Vojtech_Huser, Iâm sure that is not difficult to implement. Thanks to @Alexdavv, he called my attention to this issue. It is possible to materialize all changes including LOINC to SNOMED mappings in two weeks.
I am not quite understanding the solution. Our typical design is that there is a standard vocabulary that you map to, and there are classification hierarchies that help you use that vocabulary.
In this case, the source vocabularies have concepts that are lower granularity than LOINC and donât exist in LOINC. Mapping them to the hierarchy is not what we normally do, I think, and it would mean the hierarchy would also be a standard vocabulary.
And I thought LOINC was supposed to create lower granularity groups, but not sure where that is.
So is the solution to make LOINC and SNOMED both standard, where SNOMED is also the hierarchy, or add brand new OHDSI concepts to cover lower granularity, or to create OHDSI concepts for parts of LOINC terms (e.g., concept measured) and make them also standard?
I feel that we have some sort of confusion here.
Initial post is related to adding components of individual LOINC tests. E.g. creatinine [moles/volume] in plasma has several components: substance (creatinine), system (plasma), unit and so on. Having this information in OMOP will be useful and LOINC already has it in its files, so we just need to name the relationship_ids and put the components and relationships into the system.
Apart from that, there is a problem with SNOMED and LOINC being two standard vocabs for measurements with no connections between them. So now, you canât use a single ancestor (as for example in Condition domain) to get all lab tests from LOINC and SNOMED.
A possible solution is to link them together in a single hierarchy where SNOMED concepts will typically be parents (as they are usually broad and non-granular) and LOINC concepts will be children. LOINC groups (classification concepts) will be probably on top of that.
To responde to George: Anna said it well in her reply at the beginning. The point of this thread was to get something that LOINC gives us in the defining files of LOINC into the vocabulary.
I agree with her saying:
Initial post is related to adding components of individual LOINC tests. E.g. creatinine [moles/volume] in plasma has several components: substance (creatinine), system (plasma), unit and so on. Having this information in OMOP will be useful and LOINC already has it in its files, so we just need to name the relationship_ids and put the components and relationships into the system.
In the second part of Annaâs response - she talks about something what is beyond this thread. (but related). To keep it simple, I will not respond to that second part.
The idea of adding LOINC dimensions (Component, Property, Time, System, Scale, Method) has been percolating for a while, @Christian_Reich . I support it wholeheartedly.
We have done this for LOINC/HL7 Clinical Document Ontology.
This will support analysis of test results along those dimensions.
It may also help automation and improvement of mapping of the source data to LOINC. Rather than mapping to a specific LOINC code, one would map to the known dimensions first. If a specific LOINC code is found at the intersection of those dimensions, use that LOINC code. If not, we could create pre-coordinated OMOP concepts that will link to the respective dimensions. This way the granularity of the source data will be preserved. We use this approach for mapping to the LOINC document codes.
Recent investigation on LOINC attributes showed that there are 38 PartTypeName that connect LOINC parts and LOINC concepts. All of the LOINC Parts can be found in LOINC Accessory files. However, LOINC PartTypeName are not equal in their usefulness. Here is the list of Loinc Parts:
38 PartTypeName are united under 7 LinkTypes. The comprehensive guide to LinkTypes can also be found inside LOINC Accessory files. To summarize it a little:
Primary LinkType: identifies the key six Parts that comprise the LOINC Fully Specified Name. For every LOINC term we will have 5 (or 6 if Method is specified) Parts that represent the full contents of the corresponding field in the LOINC Table. Includes: COMPONENT, PROPERTY, TIME, SYSTEM, SCALE, METHOD
DetailedModel: identifies the more detailed compositional subparts defined by the official LOINC semantic model. In cases where we have not defined a âsubâ Part in the LOINC semantic model, we reuse the main Properties because they correspond exactly in meaning.
For us that means that there are a lot of duplicate records of PrimaryLinkType
Syntax Enhancement: identifies more detailed Parts that represent useful pieces of the LOINC term name that are not officially part of the semantic model. Historically, many of these linkages have not been obvious to most LOINC users. The main purpose of these links is further decompose the structure of the LOINC name into defined fragments. Behind the scenes, they are used for several things, including synonym linkages, language translation, and linking descriptive text
Semantic Enhancement: identifies relationships that enhance semantics of the LOINC term by providing additional sub-typing and/or special linkages to external ontologies and vocabularies. These linkages are not officially part of the LOINC naming model that defines a term
Metadata: identify accessory term attributes that are coded but not part of the concept model (a.k.a. the structured term name)
Radiology: identifies the specialized properties defined by the LOINC/RSNA Radiology Playbook
DocumentOntology: identifies the specialized properties defined by LOINC Document Ontology
All of the Not PrimaryLinkedType look redundant, but they store potentially precious information for CDM users.
@zhuk, to built links from Lab tests to key LOINC attributes as Component, Property, Time, System, Scale, and Method, will be enough to use Primary LinkType and DetailedModel .
Primary LinkType gives us target codes for such relationships as:
âHas componentâ
âHas propertyâ
âHas time aspectâ
âHas systemâ
âHas scaleâ
âHas methodâ
DetailedModel defines ancestry for those LOINC Attributes which have less granular ancestors.
This is hilarious. I have not said a thing in this debate, but still @rimma assumes I have a strong opinion, and that opinion ought to be against useful changes. I must have built some reputation of a hardline party ideologue or defender of the doctrine
But since I am already accused of the crime I may as well commit it and add my opinion.
Usually, we want to introduce changes through use cases, which will guide what we do and how we do it. @Vojtech_Huserâs âWhy are they not added?â or @aostropoletsâs âHaving this information in OMOP will be usefulâ probably fall short of that. From the above, I think the use cases listed are:
Enable querying MEASUREMENT records for clinically useful information (@Vojtech_Huser and @aostropolets), which include COMPONENT and SYSTEM, and maybe TIME, but not PROPERTY, SCALE or METHOD. The combination of them all create the perceived âoverly detailedâ LOINC concepts, which makes it hard to map to them and to utilize them. In other words, I want to say âgive me all patients with a fasting blood glucose >140 mg/dLâ, and there are a dozen or so LOINC concepts which could be included here.
Create a consistent hierarchy between SNOMED and LOINC (@rimma), and while we are at it also CPT4.
I definitely âwholeheartedlyâ support them both. In order to support them, as a first step we need @Polina_Talapovaâs relationships. But we should also consider something like what @aostropolets suggests. We may even think of adding a âLOINC Extensionâ and create our own precoordinated Concepts that contain the things we really need to query for. Doesnât look like either the LOINC Group or LOINC Hierarchy Concept Classes do the trick, though they seem to be attempts at the same thing.
The measurement hierarchy and the additional relationships to LOINC attributes are two separate things. Attributes may facilitate hierarchy creation, but thatâs not the reason why @zhuk asked about them.
The relationships have been requested by several people, including gents and ladies in this thread, and I donât have any good explanation for not adding them.
So, to re-state the question: are there any other attributes of interest besides those that have already been mentioned?
(interim short reply)
Zhuk and Polina - thank you for looking into the release files.
To complement the discussion, examples in the release notes are ilustrative
Historically, the published connections between LOINC terms and LOINC Parts have been incomplete and imprecise. We have undertaken a major overhaul to refine and enrich our LoincPartLink.csv file.
We have enhanced our model of how LOINC terms relate to LOINC Parts, recognizing the need for overlapping linkages for different purposes. The first key aspect of this effort is clearly labeling the specialized aspects of our names into defined relationships. The second key aspect is labeling pieces of the LOINC term name (especially Components ) in such a way to makes linkages to other extant terminologies more straightforward.
Here is answer to Christianâs call for use cases.
It is an R session and output with the loinc part file where thanks to parts to tests relationships, I can better understand all tests where component measured is HIV RNA.
Looks like all you do is load the file. I canât see any querying for HIV.
But I agree, this is the use case I mentioned above: Ability to query for a set of Measurements with some commonality. The question is should we create some hierarchy from these with precoordinated attributes. Right now, LOINC gives us the leaves (all attributes), and some awkward LOINC Groups and LOINC Hierarchies.
I would not try to create a hierarchy from the LOINC Parts knowledge. I would simply keep it as relationships.
It is similar to how clinical drugs are linked to ingredients. (LATER EDIT: well those do). There are some relationship that donât drive any hierarchy but for power user (in SQL) they can provide value
