FHIR Chat · Multiple (LOINC) Codes · genomics

Stream: genomics

Topic: Multiple (LOINC) Codes

Patrick Werner (Jan 08 2019 at 16:55):

This topic is meant to capture all derived discussions from: GF#16387 and GF#16408

Bret H (Jan 08 2019 at 16:57):

Andrea - 1..1 for data element (structure) -> LOINC code. And multiple LOINC codes for various HLA results
Bob M - Can add additional HLA LOINC codes when they are conceptually the same
Clem - Live in a dual world
Bob M - Must use the required codes specified in this IG (like Genotype, Haplotype, Gene, etc …), but are free to use additional codes where necessary
Clem - Still a concern to have multiple uses for the codes
Patrick - Might run into mapping issues with V2, but should leverage FHIR where we can and not limit ourselves
Bret - If method is not indicated by the LOINC, should we require it?
Bob M - Perhaps labs will not always have it, so we need to be careful about requiring things (must / should)
Bret - Labs will have a methodology, so can we raise the bar in some way for FHIR.
Kevin: exercised co-chair prerogative to pause extensive discussion that began to wander away from the topic at hand
Andrea: can we continue this discussion during a future call?

Kevin Power (Jan 08 2019 at 19:39):

Anyone want to take a stab at showing some different examples of what it would look like to send multiple codes in different situations? The discussion often comes back to methodology, so the examples should include that. It seems that HLA is typically what is brought up, but do we want to consider other areas in these examples?

Kevin Power (Jan 08 2019 at 19:40):

The examples are needed to address the GF#16408, so they are needed anyway.

Kevin Power (Jan 09 2019 at 16:27):

Might suggest @ Bob Milius or @Andrea Pitkus, PhD, MLS(ASCP)CM, CSM or @Bret H consider putting together the examples?

Bob Milius (Jan 09 2019 at 18:15):

Here's an example for a Genotype Observation for HLA-A

<Observation>
    <meta>
        <profile value="http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/obs-genotype"/>
    </meta>
...
    <code>
        <coding>
          <system value="http://loinc.org"/>
          <code value="84413-4"/>
          <display value="Genotype display name"/>
        </coding>
        <coding>
          <system value="http://loinc.org"/>
          <code value="57290-9"/>
          <display value="HLA-A [Type] by High resolution"/>
        </coding>
    </code>
...
    <valueCodeableConcept>
        <coding>
          <system value="https://glstring.org"/>
          <version value="1.0"/>
          <code value="hla#3.31.0#HLA-A*03:01:01:01+HLA-A*30:01:01"/>
        </coding>
    </valueCodeableConcept>
...
    <component>
        <code>
          <coding>
            <system value="http://loinc.org"/>
            <code value="48018-6"/>
            <display value="Gene studied [ID]"/>
          </coding>
        </code>
        <valueCodeableConcept>
          <coding>
            <system value="https://www.genenames.org"/>
            <code value="HGNC:4931"/>
            <display value="HLA-A"/>
          </coding>
        </valueCodeableConcept>
    </component>
...
</Observation>

Bob Milius (Jan 09 2019 at 18:17):

Here's an example Complex Variant Observation which asks for Presence/Absence for HLA-B:57:01 (Part of HLA-B57 allele family that is associated with Abacavir hypersensitivity reaction (AHSR))

<Observation>
    <meta>
        <profile value="http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/obs-complex-variant"/>
    </meta>
...
    <code>
        <coding>
          <system value="http://loinc.org"/>
          <code value="69548-6"/>
          <display value="Genetic variant assessment"/>
        </coding>
        <coding>
          <system value="http://loinc.org"/>
          <code value="50956-2"/>
          <display value="HLA-B*57:01 [Presence]"/>
        </coding>
    </code>
    ...
    <valueCodeableConcept>
        <coding>
          <system value="https://loinc.org"/>
          <code value="LA9633-4"/>
          <display value="Present"/>
        </coding>
    </valueCodeableConcept>
    ...
    <component>
        <code>
          <coding>
            <system value="http://loinc.org"/>
            <code value="48018-6"/>
            <display value="Gene studied [ID]"/>
          </coding>
        </code>
        <valueCodeableConcept>
          <coding>
            <system value="https://www.genenames.org"/>
            <code value="HGNC:4932"/>
            <display value="HLA-B"/>
          </coding>
        </valueCodeableConcept>
    </component>
    <component>
        <code>
          <coding>
            <system value="http://loinc.org"/>
            <code value="81260-2"/>
            <display value="Complex genetic variant [ID]"/>
          </coding>
        </code>
        <valueCodeableConcept>
          <coding>
            <system value="https://www.ebi.ac.uk/cgi-bin/ipd/imgt/hla"/>
            <code value="HLA-B:57:01"/>
            <version value="3.34.0"/>
            <display value="HLA-B:57:01"/>
          </coding>
        </valueCodeableConcept>
    </component>
...
</Observation>

May Terry (Mar 25 2019 at 19:05):

Hi @ Bob Milius - Thanks for posting this example for Complex Variant Observation on how multiple LOINC codes could be represented. I was hoping to get some clarification on how one would align the answer lists of both codes (69548-6 and 50956-2) as it relates to the valueCodeableConcept. The Genetic variant assessment (69548-6) has answer list LL1971-2 which has present/absent/on call/indeterminate whereas the alternate LOINC code for the HLA-B*57:01 has the answer list LL360-9 which is positive/negative. The valueCodeableConcept aligns with the primary code (69548-6) as "Present" but wouldn't this misalign with the answers for what we really want to answer which is the interpretation for HLA-B*57-01? Would it be possible to enhance this example so that for every alternate code there is an equivalent alternate valueCodeableConcept? I'm still very new to Clinical Genomics so anything that helps me understand this better would be helpful.

Bret H (Mar 25 2019 at 19:14):

The codings in Observation.code define what the observation is about. @May Terry There are very few LOINC codes were the answer is list is more than a preferred list. I would not get hung-up on LA-Codes not being exactly the same as the values in valueCodeableConcept. If the values have the same meaning then the message should be usable, right?

May Terry (Mar 25 2019 at 19:18):

thanks for the quick reply @Bret H - makes sense to ignore or override the answer lists if it's preferred, but as I work through it, should I call it out if I find that one of the answer lists is normative? thanks again!

Bret H (Mar 25 2019 at 19:43):

Absolutely. In LOINC normative lists are part of the definition of the concept, they are avoided by LOINC, but a few LOINC terms have them.

Bret H (Mar 25 2019 at 19:46):

@ Bob Milius would you agree with present and positive having the same meaning in your example?
What are your thoughts?

Bret H (Mar 25 2019 at 19:51):

for folks the binding of the valueCodableConcept is LOINC Answer List LL1971-2 (required). As we required it, the user of the profile can only use values from LL1971-2. Thus, May's question when multiple LOINC codes are used. Myself, the valueCodeableConcept could have been done with a valueset from SNOMED CT. I think this would avoid confusion.

Bret H (Mar 25 2019 at 19:52):

but philosophically, @May Terry this asks for a precedent when using a LOINC code with a normative answer list but for which you wish to use someother system, like SNOMED CT for values. Would your mapping from the LOINC LL list to the list of SNOMED CT codes be valid?

May Terry (Mar 25 2019 at 20:02):

I'd prefer the answer to be SNOMED rather than the LOINC answer list but sometimes we use the answer list if there is no SNOMED equivalent concept IDs. My question was more about semantic alignment of the terms themselves as you noted in the question to Bob. If LL360-9 is positive/negative, would we assume semantic equivalence with present/absent in LL1971-2?

Jamie Jones (Jun 27 2019 at 18:13):

Looking towards resolving these and also addressing GF#20549, I drew up a doc of all the currently 'required' LOINC answer lists in the IG (all of which are either example or preferred on LOINC itself).
https://docs.google.com/document/d/1E-nal_OPhJ8SSaIN_f9XqiLI5lyuGyhTIbUae8MWLMU/edit.

I'd like us to consider moving them all to preferred or extensible, as was mentioned in the January WGM in the session with Grahame but I don't think made it into the notes.

It's also got the 11 current "TBD" LOINCs on there, which we will need to resolve somehow before publication.

Bob Dolin (Jun 30 2019 at 19:08):

@James Jones Hi Jamie. I'm wondering if we can add to your list, what type(s) of LOINC codes we might expect to be used as observation.code for the Genetic Implication and Inherited Disease pathogenicity profiles? Maybe the default code for both profiles should be 53037-8 Genetic variation clinical significance?

Patrick Werner (Jul 02 2019 at 14:23):

We need Observation.code to distinguish between our Observation profiles. So two profiles with the same code are not an option. The simplest would be to have a "static" Observation.code per profile.
Multiple codes per profile is possible but complicates searches for a type of profiled observations

Kevin Power (Jul 02 2019 at 14:25):

And @Bob Dolin - Not sure why I missed this first, but Genetic Implication is an Abstract profile, and not one you would create. Or did you mean a different one?

Bob Dolin (Jul 03 2019 at 14:10):

Hi @Kevin Power . How would I determine that Genetic Implication is an abstract profile? It does not have a red outline in any of the diagrams. It seems maybe there is a subtle difference between the generic 'genetic implications' class and it's 'inherited disease pathogenicity' subtype, either that or I'm not quite sure why we need two classes here?

Kevin Power (Jul 03 2019 at 14:23):

Sounds like a diagram issue - we should fix that. Because that is the easiest. I had logged an issue to make the abstract profile names easier to identify, so we ended up creating a section here that lists them out.

Genetic Implication defines all the attributes and constraints that apply to all of our implications. The Inherited Disease Path profile is a sub-class of Genetic Implication.

Patrick Werner (Jul 03 2019 at 15:51):

and we should set StructureDefinition.abstract to true, this would be the place to express the abstract quality of the StrucDef

Kevin Power (Jul 03 2019 at 23:18):

True, it is set that way, so you could also determine that by viewing the XML or JSON view of the StructureDefinition.

Patrick Werner (Jul 04 2019 at 09:24):

GF#22802

Kevin Power (Jul 04 2019 at 13:14):

I think the only change we need is to fix the diagram? Sorry if my response was not clear, but I am fairly certain the “abstract” element is already set to true in the Structure Definition

Patrick Werner (Jul 04 2019 at 14:41):

Genetic Implication has <abstract value="false"/>

Kevin Power (Jul 04 2019 at 14:54):

Welp wrong again 🤬

Jamie Jones (Jul 08 2019 at 00:47):

I wasn't aware abstract was an actual property in the structure defs, that is interesting

Kevin Power (Jul 08 2019 at 14:33):

I am doing some checking to see where we can define that in the spreadsheet world we are in today, but haven't found anything yet.

Lloyd McKenzie (Jul 08 2019 at 16:19):

We had done it for some of our profiles. Don't have access to a computer to check how though

Kevin Power (Jul 08 2019 at 18:47):

I have looked around and can't find anywhere we could have set it? I don't see any mention of how to define it in the Spreadsheet authoring Wiki pages either. But perhaps I am just missing it. Anyone else have a moment to investigate and see if I am just missing it? @Patrick Werner @James Jones ?

Lloyd McKenzie (Jul 08 2019 at 20:57):

Check the meta tab

Kevin Power (Jul 08 2019 at 21:02):

Yea, that is the first place I looked too. But nothing. And nothing listed in the FHIR Spreadsheet Authoring page either for the Metadata tab?

Kevin Power (Jul 08 2019 at 21:09):

I think I even looked at the code parsing the spreadsheets, and it seems to only 'setAbstract(false);' on the StructureDefinition. I think this is the right spot where I see it hardcoded.

Lloyd McKenzie (Jul 08 2019 at 21:09):

Will dig further when I'm properly online next week

Kevin Power (Jul 08 2019 at 21:10):

Probably a lower priority right now - but thanks @Lloyd McKenzie (and sorry for bugging ya while you are out)

Patrick Werner (Jul 09 2019 at 12:26):

yes abstract is always set to false in the IG builder code. Maybe this could be a good occasion to switch to editing the Structure Definitions directly?
Forge now has R4, Trifolia is getting better as well.

Kevin Power (Jul 09 2019 at 12:28):

I was sort of wondering the same thing but I think we should get published first then look to make a switch. Does that seem ok?

Patrick Werner (Jul 09 2019 at 12:34):

i think so, yes. Probably we should defer my GF to after the release.

Bob Milius (Oct 03 2019 at 15:19):

I added a section in the histocompatibility page to address GF#16387. Please take a look. Looking forward to feedback.
http://build.fhir.org/ig/HL7/genomics-reporting/histocompatibility.html#hla-loinc-and-additional-codings

Jamie Jones (Oct 03 2019 at 16:34):

Content looks great, thanks! A couple typos I can clean up, I'll be pushing some today.

Last updated: Apr 12 2022 at 19:14 UTC