Stream: IG creation
Topic: Found multiple matching profiles...
Jean Duteau (Jan 13 2021 at 17:58):
I'm pretty sure that I know the answer to this one, but I thought I'd ask to make sure.
I have two AdverseEvent profiles that differ only on the AdverseEvent.event binding. Each profile defines a different value set for that binding. I made the binding extensible because new vaccination or immunization-related events can be added. By doing this, I'm pretty much guaranteed that no validator will be able to determine the proper value set, correct? I then made them required bindings but I still get the same warning. This time I believe it is because my value set is using MedDRA codes and the IG Publisher validator doesn't know about MedDRA so it can't determine if the code I gave it is in either value set.
Assuming that the validator could determine that the code was valid, is this a valid way to differentiate two profiles - a required binding value set on one element?
Lloyd McKenzie (Jan 13 2021 at 23:15):
If the two value sets are from distinct code systems, you could slice based on system. Slicing by value set only works if the terminology server can expand the value set
Jean Duteau (Jan 13 2021 at 23:16):
yeah, they aren't. they are different axes of the same code system. i was able to get it to work because there is some additional constraints that I hadn't thought of at first blush.
Patrick Werner (Feb 07 2022 at 11:32):
I think this is a bug. We encountered a similar issue in the CG IG: http://build.fhir.org/ig/HL7/genomics-reporting/qa.html
Patrick Werner (Feb 07 2022 at 11:34):
Found multiple matching profiles for Task/usage-1a among choices: http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/followup-recommendation, http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/medication-recommendation
Patrick Werner (Feb 07 2022 at 11:37):
These are the profiles: http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-medication-recommendation.html & http://build.fhir.org/ig/HL7/genomics-reporting/StructureDefinition-followup-recommendation.html
Patrick Werner (Feb 07 2022 at 11:38):
both are having a different bindings to distinct Loinc answer lists.
Patrick Werner (Feb 07 2022 at 11:42):
So the validator should be able to differentiate @Grahame Grieve
Rob Hausam (Feb 07 2022 at 13:42):
It's probably worth pointing out that AdverseEvent.event (and similarly AdverseEvent.code in R5) is non-repeating. So this is exactly the same situation, for the same reason, that we have encountered in IPS. So you are not supposed to be able to slice on a non-repeating element. There is a way that the validator is perfectly happy with that, though. And I think you should be able to slice on a non-repeating element - precisely to allow a choice of different sets of constraints. And if the discrimination is on the value set binding and the bindings are required and the value sets are completely disjoint (even if they are from the same code system) then this should work (but that's often too high a bar, and with open slicing we still run into a lot of validation "noise"). But, with that said, using the extension for additional bindings as discussed here may ultimately be the way to go for this.
Kevin Power (Feb 07 2022 at 15:33):
In the case @Patrick Werner is talking about:
- We have an extension that we constrain to only be a reference to one of the two Task profiles he links above
- We have an example that uses this extension, and it refers to an instance of a Task with a 'meta.profile' that lists one of our profiles
- We get a warning on the example:
Found multiple matching profiles for Task/usage-1a among choices: http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/medication-recommendation, http://hl7.org/fhir/uv/genomics-reporting/StructureDefinition/followup-recommendation
(where Task/usage-1a is a Task instance that has has 'meta.profile' of our 'medication-recommendation' profile)
So I am trying to understand what this warning is telling us?
Patrick Werner (Feb 07 2022 at 15:54):
It seems, that the validator isn't able to expand and match the Loinc AnswerLists.
Patrick Werner (Feb 07 2022 at 15:57):
Yes, thats the problem: https://tx.fhir.org/r4/ValueSet?url=http://loinc.org/vs/LL4049-4 is not found
Patrick Werner (Feb 07 2022 at 15:57):
could the Loinc Answerlists be added to tx.fhir.org ?
Rob Hausam (Feb 07 2022 at 16:40):
Yes, @Patrick Werner, I'm sure that support for the LOINC answer lists can be added to tx.fhir.org. I thought there was another recent request for and discussion on that, but I'm not locating anything about it at the moment. It's just a matter of determining who will do it and when it can get done. It might be a relatively straightforward addition to make - but I haven't tried to verify that yet.
Patrick Werner (Feb 07 2022 at 16:53):
As these AnswerLists are already existing on the Loinc FHIR Server, i think the easiest way would be LOINC creating a answerlist package?
Rob Hausam (Feb 07 2022 at 16:59):
Maybe. But I'm not sure that is necessary or makes the most sense, as all of the codes and relationships are in the LOINC distribution and we just need the terminology server LOINC importer tool to process and include them in the FHIR code system representation.
Patrick Werner (Feb 07 2022 at 17:12):
good point. Is the importer tool java based? and could you point me to its source?
Grahame Grieve (Feb 07 2022 at 19:56):
not java. The source you're referring to is here:
Grahame Grieve (Feb 07 2022 at 19:57):
https://github.com/HealthIntersections/fhirserver/blob/master/library/ftx/ftx_loinc_importer.pas
Grahame Grieve (Feb 07 2022 at 19:57):
tx.fhir.org should support LOINC answer lists. I thought it did already
Kevin Power (Feb 07 2022 at 21:36):
I wasn't sure how to do a query to confirm more broadly, but I did a quick look for about 5 of the 20 some LOINC answer lists we used, and none were found on tx.fhir.org
Kevin Power (Feb 07 2022 at 22:50):
No idea if I know what is going on, but is this going to be case sensitive?
https://github.com/HealthIntersections/fhirserver/blob/master/library/ftx/ftx_loinc_importer.pas#L754
image.png
And, does this process the downloadable files from LOINC? The answer lists seem to be in this accessory file page:
https://loinc.org/downloads/accessory-files/
https://loinc.org/download/loinc-answer-file/
When I download, this, here is what I see as the contents:
image.png
Looks like the code is looking for 'answerList.csv' but the download has 'AnswerList.csv' ? No idea if this is the problem, but I was curious enough that I had to look for a bit.
Jose Costa Teixeira (Feb 07 2022 at 23:03):
Thanks for searching. Since the TX server is running on windows (unless that has changed) this should not really matter
Jose Costa Teixeira (Feb 07 2022 at 23:03):
(I think @Grahame Grieve can confirm or correct)
Kevin Power (Feb 07 2022 at 23:15):
Didn't really expect it to be that easy :smile:
Grahame Grieve (Feb 08 2022 at 00:04):
the import happens on windows at the moment
Patrick Werner (Feb 08 2022 at 13:28):
i checked tx.fhir.org, i didn't find a single LL AnswerList through the ValueSet Endpoint. @Grahame Grieve should we file a bug in the issue tracker?
Kevin Power (Feb 08 2022 at 19:56):
https://github.com/HealthIntersections/fhirserver/issues/184
Rob Hausam (Feb 08 2022 at 23:07):
I just talked with Dan Vreeman yesterday and mentioned this - not surprisingly, it's something that he has some interest in :). Thanks for submitting the issue @Kevin Power.
Patrick Werner (Feb 11 2022 at 14:00):
I just got this error in another IG: Error @ Observation.component[0].code (line 40, col20): The code "LP7386-8" is not valid in the system http://loinc.org; The code provided (http://loinc.org#LP7386-8) is not valid in the value set 'EkgLeads' (from http://tx.fhir.org/r4)
Patrick Werner (Feb 11 2022 at 14:00):
It seems that LP codes aren't imported/supported at the moment. @Rob Hausam do you like this as a separate Issue? OR should i add this to Kevins Issue?
Grahame Grieve (Feb 11 2022 at 19:09):
I thought that they were. It should be the same issue anyway
Rob Hausam (Feb 11 2022 at 20:48):
I'm also surprised that LP code isn't showing up. But I was able to do a $lookup on LP15099-2 (Sodium [Moles/volume] in Serum or Plasma). I was also able to successfully $lookup LL891-3 (UA_crystals) as well as one of the answers in that list, LA12817-5 (Calcium oxalate crystals). So this doesn't seem to be a general issue for all of the codes of a particular "type".
Last updated: Apr 12 2022 at 19:14 UTC
