OHDSI Home | Forums | Wiki | Github

Improve LOINC representation in OMOP Vocabulary (Athena) (link parts to lab tests)

General
#1

In LoincPartLink.csv this loinc code LOINC 14682-9 — Creatinine [Moles/volume] in Serum or Plasma (CID http://athena.ohdsi.org/search-terms/terms/3020564)
has several parts defined and linked
e.g.,
COMPONENT Creatinine (LP14355-9) (CID http://athena.ohdsi.org/search-terms/terms/40775801)

image
image1190×287 11.3 KB

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)

Measurement hierarchy and LOINC place in it
#2

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?

Better and more use of labs in future OHDSI studies
Make relationships vocabulary non-specific
#3

@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?

#4

@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.

#5

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?

Measurement hierarchy and LOINC place in it
#6

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.

image
image1948×1090 163 KB

1 Like
Better and more use of labs in future OHDSI studies
Measurement hierarchy and LOINC place in it
#7

@aostropolets Anna, this is just what I’ve sought. Thank you so much!!

#8

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.

If you would download LOINC and go to file LoincPartLink.csv it will be clear what I mean. More details in the corresponding github issue here https://github.com/OHDSI/Vocabulary-v5.0/issues/251

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.

#9

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.

1 Like
#10

@Vojtech_Huser, @Christian_Reich, @aostropolets, @Alexdavv, @Polina_Talapova

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:

Potential_Reltionship_id
Potential_Reltionship_id392×711 135 KB

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.

Few examples under the cut

12227-5
12227-51335×304 276 KB
20121-0
20121-01333×782 513 KB
39420-5
39420-51335×490 389 KB

So as it seems to me that we came to the point where we need to decide together which LOINC Parts should be included in CDM.

1 Like
#11

@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.

The results may be the following:

1
11316×126 7.03 KB

6
6910×107 6.89 KB

4
41363×141 7.12 KB

2
21335×161 9.44 KB

5
5793×128 5.73 KB

3
31555×143 8.87 KB

1 Like
#12

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 :slight_smile: :slight_smile:

2 Likes
#13

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.

We need to think this through.

#14

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?

1 Like
#15

(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

e.g., here

a quote from the release notes also relevant

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.

and a nice part of primary model section

image
image1723×358 55.5 KB

#16

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.

http://rpubs.com/vojtech_huser/loinc3

preview

image
image968×669 49.9 KB

#17

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.

#18

Sounds like silence means there aren’t. Let’s just get those in, and then we continue. We still need an CDM issue.

#19

Yes there is one additional attribute: Consumer name.
It is listed in the issue I filed LOINC: link LOINC parts to the concepts they help define (LoincPartLink.csv file) · Issue #251 · OHDSI/Vocabulary-v5.0 · GitHub
Picture below.

Ad needing CDM issue. I though it would be more of a vocabulary issue. Not CDM.

image
image1014×613 83 KB

#20

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

t