Stream: terminology
Topic: loinc major axis property names
Jim Steel (Aug 14 2018 at 00:27):
What is the rationale for the naming of the CodeSystem properties for LOINC's "major axes" (COMPONENT, PROPERTY, TIME_ASPCT, SYSTEM, SCALE_TYP, METHOD_TYP)? Is it only that these were the names of the columns in the main LOINC file in the distribution? Or are they used in external systems as well?
Jim Steel (Aug 14 2018 at 00:30):
The reason for asking is that the LOINC distribution now includes a part file (and a part link file), which seem to be a far better sources of this property data, and the part link file uses different names (and I'd argue aesthetically better names) for them (COMPONENT, PROPERTY, TIME, SYSTEM, SCALE, METHOD)
Jim Steel (Aug 14 2018 at 00:31):
(deleted)
Grahame Grieve (Aug 14 2018 at 00:37):
@Daniel Vreeman
Grahame Grieve (Aug 14 2018 at 00:37):
Agreement with LOINC from our PoV
Jim Steel (Aug 14 2018 at 00:38):
Incidentally, @Grahame Grieve your server (like ours) currently returns part names for those properties, rather than part codes (it was the only thing that was possible until they added the part and part link files)
Grahame Grieve (Aug 14 2018 at 01:14):
hm. I'll add it to my list
Jim Steel (Sep 05 2018 at 05:26):
Another change that might be considered for the LOINC normative CodeSystem properties is changing CLASS to be code-typed instead of String-typed (this code can be harvested from the LoincPartLink file, like the codes for the 6 major axes, whose properties are already code-typed)
Jim Steel (Sep 05 2018 at 05:33):
FWIW, fhir.loinc.org still does that one as a string. It does use loinc part codes for the axis properties, but it does them as Codings rather than codes (as they're defined at http://build.fhir.org/loinc.html)
Michael Lawley (Sep 09 2018 at 07:17):
@Rob Hausam @Daniel Vreeman ?
Rob Hausam (Sep 09 2018 at 15:31):
@Michael Lawley @Jim Steel @Daniel Vreeman I can't speak for LOINC officially, but in the LOINC group value sets work we've looked at this. In principle I agree with Jim that changing CLASS to Coding (or code) would be good, but in practice at present I think we may actually need to go the other way and make all of the property types (including the six major axes) string. The reason for that is that currently LOINC hasn't defined a single part (LP) code for each unique property value "combination" (including the subparts for COMPONENT, SYSTEM and TIME_ASPCT), nor is there an agreed compositional syntax for doing that using the LP codes. Probably the '^' character could be used compositionally in the same way that it is now being used in the string representation, but that hasn't been agreed and it isn't instantiated that way in the fhir.loinc.org server (which is a HAPI instance). If the string representations were used throughout, then regex filters could be reliably used for fully defining the group (and other) value sets intensionally, but right now without that it doesn't quite work. The fully coded approach (either compositional or with unique single LP codes) would be even better, but until we get there the string solution would be the easiest to implement.
Jim Steel (Sep 09 2018 at 23:45):
It seems like a backwards step if LOINC are doing (IMHO) the right thing and moving to codes for properties, and (I suspect) hierarchy amongst those part codes
Jim Steel (Sep 09 2018 at 23:45):
Also, I'm not suggesting we change the FSN
Jim Steel (Sep 10 2018 at 01:02):
Why do we need a code for the unique combinations of parts?
Rob Hausam (Sep 10 2018 at 03:46):
Well, what we need is a full representation of the property value. As I see it, that can be either: (1) a string value, as currently distributed in the main LOINC table; (2) a unique code that fully represents that value (including all subparts), which doesn't currently exist; or (3) a compositional expression which includes multiple codes for the value (including the existing individual codes for all of the subparts), which hasn't been defined or represented anywhere yet. The only one of the three that currently exists and we could just use right now is #1. It wouldn't be particularly hard to do either of the other two, but a decision would need to be made to do it that way and a bit of work would need to be done.
Jim Steel (Sep 10 2018 at 03:47):
I don't follow. Which property?
Jim Steel (Sep 10 2018 at 03:49):
For a given LOINC term, there is at most one Primary LOINC Part (identifiable using a Part code according to the Parts file) for each of the axis properties, right?
Rob Hausam (Sep 10 2018 at 03:53):
in particular, COMPONENT, SYSTEM or TIME_ASPCT, when subparts are present (i.e. the additional parts of the value separated by '^')
Rob Hausam (Sep 10 2018 at 03:54):
these are very important to be represented and computable (via code or regex) when constructing intensional value set definitions
Rob Hausam (Sep 10 2018 at 03:57):
I can't generate complete and accurate intensional group value set definitions (which is what I've been working on recently) unless I can rely on the property values being fully represented
Jim Steel (Sep 10 2018 at 04:01):
Is there an example part? The parts file includes part names with ^ in them, but the part codes are different
Rob Hausam (Sep 10 2018 at 04:02):
What do you mean by "the part codes are different"?
Rob Hausam (Sep 10 2018 at 04:03):
it is true that the parts file includes some part names with '^', but the problem is it doesn't include that for all of them - and the ones that aren't included can't be ignored
Jim Steel (Sep 10 2018 at 04:04):
Doesn't that mean that not all combinations are possible/allowed?
Michael Lawley (Sep 10 2018 at 04:04):
@Rob Hausam can you give an example of a code & property with "the additional parts of the value separated by '^'"?
Rob Hausam (Sep 10 2018 at 04:20):
@Michael Lawley @Jim Steel If you look at COMPONENT for "Amitriptyline [Mass/volume] in Serum or Plasma --trough" (16361-8):
http://fhir.loinc.org/CodeSystem/$lookup?system=http://loinc.org&code=16361-8
you can find "Amitriptyline" (LP14983-8) and the "Challenge" 2nd subpart "trough" (LP20176-1), but there is nothing that represents "Amitriptyline^trough" as a combination
Jim Steel (Sep 10 2018 at 04:22):
Is that not just an additional property called CHALLENGE?
Jim Steel (Sep 10 2018 at 04:28):
Then you can just have both filters within the same include to find terms that have both?
Rob Hausam (Sep 10 2018 at 04:34):
Yes, I think that definitely could work. But currently these subpart values are distributed as subparts of COMPONENT, SYSTEM or TIME_ASPCT, not as a separate property, and they're not represented that way in the canonical LOINC code system. If it is true (and I suspect that it is) that all of the defined subparts can only be used in one way, so that a representation of them as additional separate individual properties is unambiguous and unique, then that is clearly another way to solve the problem. But they're not distributed that way in the LOINC table - so currently you will still have to parse the composite strings in those three major axis properties in order to get the individual subpart property values (until and unless LOINC adds them as separate fields in the distribution). Currently, using the existing full string values as they are already being distributed in the LOINC table will be considerably easier.
Jim Steel (Sep 10 2018 at 04:35):
It will definitely need the Parts and LoincPartLink tables as well as the main table
Jim Steel (Sep 10 2018 at 04:35):
Which are now out of beta (as of loinc 2.64)
Rob Hausam (Sep 10 2018 at 04:37):
Unless there's something there that I haven't yet considered, I think that's necessary but currently is not sufficient.
Rob Hausam (Sep 10 2018 at 04:39):
Maybe LoincPartLink does have it (I should look closer at that). But even if it does, we need to change the canonical LOINC CodeSystem and the official representation in the HAPI server to include them as properties in their own right.
Jim Steel (Sep 10 2018 at 04:42):
the hapi server as in loinc.fhir.org?
Rob Hausam (Sep 10 2018 at 04:42):
yes
Rob Hausam (Sep 10 2018 at 04:43):
actually, fhir.loinc.org
Jim Steel (Sep 10 2018 at 04:43):
sorry, yes
Jim Steel (Sep 10 2018 at 04:43):
There are already some discrepancies between that and the spec, i think
Rob Hausam (Sep 10 2018 at 04:43):
yes, but it's the "official" source
Jim Steel (Sep 10 2018 at 04:43):
Hmm
Rob Hausam (Sep 10 2018 at 04:44):
has Ontoserver fully handled this? - if so, that's a good precedent to follow
Jim Steel (Sep 10 2018 at 04:44):
We've got some stuff built, but its not released yet
Rob Hausam (Sep 10 2018 at 04:45):
so it does everything that I've suggested is needed?
we can look at it and talk to @Daniel Vreeman if that's the case
Rob Hausam (Sep 10 2018 at 04:46):
when you're ready to show it (at least as a preview)
Rob Hausam (Sep 10 2018 at 04:48):
we'll need to work with @Daniel Vreeman and @James Agnew to get everything in sync
Jim Steel (Sep 10 2018 at 04:48):
Yeah, sure
Jim Steel (Sep 10 2018 at 04:49):
I can certainly get our stuff up on our test server
Jim Steel (Sep 10 2018 at 05:00):
I'll just implement the CHALLENGE property first though. Sounds like that might be useful
Rob Hausam (Sep 10 2018 at 05:42):
@Jim Steel @Daniel Vreeman @James Agnew I agree that LoincPartLink appears to contain the necessary level of detail (in 'Primary' properties). Starting with the CHALLENGE property is reasonable, but I think we'll need all of them (including SUPER SYSTEM and TIME MODIFIER, and I'm pretty sure also ADJUSTMENT, COUNT and DIVISORS) to make it fully useful.
Rob Hausam (Sep 10 2018 at 05:55):
In HAPI the terminology uploader (specifically LoincPartLinkHandler and related code for properties) will need to be updated to utilize this data.
Jim Steel (Sep 10 2018 at 06:14):
I assume that's just for Primary parts, not Search parts? The Search ones to me look like some kind of early attempt at hierarchy
Jim Steel (Sep 10 2018 at 06:16):
The Part file stuff still needs some work, I suspect. I found only a small overlap between the Part codes I harvested from the multi-axial hierarchy file and those I harvested from the Parts file.
Jim Steel (Sep 10 2018 at 06:16):
Also, if you're updating to incorporate Part and PartLink files, you may want to look at Answer and AnswerLink files, and perhaps the Group stuff (if you haven't already), which also all have relatively recently come out of Beta
Rob Hausam (Sep 10 2018 at 06:27):
right - most of the work on the intensional group value set definitions has been done, but without the full property representations it isn't fully useable yet
I haven't worked on the answers and answer links, but I think that @James Agnew has all of that working
Jim Steel (Sep 10 2018 at 07:51):
Is the aim for the groups that there will be standard normative intensional ValueSets maintained by Regenstrief and distributed along with the release?
Jim Steel (Sep 10 2018 at 07:54):
The Groups stuff in the distribution looks like it would be hard to parse intensional ValueSets from automatically
Jim Steel (Sep 10 2018 at 07:54):
(extensional would be pretty easy though)
Rob Hausam (Sep 10 2018 at 07:59):
Right - you need additional data that isn't part of the LOINC distribution to accurately generate the intensional definitions. And yes, extensional is pretty straightforward (for both the groups and parent groups).
Daniel Vreeman (Sep 12 2018 at 10:46):
Thanks for the good comments here. I'll try to chime in on 3 relevant points. First, to go way back to the Property naming issue, we discussed this at the LOINC Committee (with input from the HL7/FHIR folks too) and agreed the most straightforward approach was to use the official field names for the main properties, but adopted more fhir-style ones for new/custom. Second, we'd be open to modifying CLASS to be coding if the community would prefer it that way. (Strings can be gleaned from LOINC Table, Part codes have to be gleaned from LoincPartLink table). Third, there are several forces that are leading us in the direction to update the canonical property list to include all of the more detailed part types. The Component, for example, can really have subparts (as defined in the User Guide) but also more fine grained distinctions that aren't well described (e.g. suffixes, divisors, etc). But there are issues: We may not be creating all the Parts we need (e.g. for deprecated terms), not all the link types (PRIMARY vs SEARCH) are being labeled right, etc. So this will take some work to fix, in terms of the LOINC release artifacts, the canonical definition, and of course servers that are implementing it. From the LOINC side, this will be something we're working on in the next year. We will definitely be looking for input/feedback from the FHIR community along the way. The interim challenge is that right now, the only workable strategy for building the most complicated value sets (e.g LOINC Groups) intensionally is with strings. But, my personal preference would be to keep moving forward with the coded part-based approach.
Rob Hausam (Sep 12 2018 at 14:14):
Thanks, Dan. I agree with you that the coded part-based approach clearly is the best strategy in the long run. So if there isn't a compelling reason that requires making the intensional definitions (for group and other complicated value sets) fully operational now, it makes sense to continue to move forward with the coded approach. Changing CLASS to a coded property would seem to be a straightforward initial move to make in that direction.
Michael Lawley (Sep 13 2018 at 01:52):
Thanks @Daniel Vreeman we're really keen to have a usefully complete implementation and using coded values is a much preferred solution to string values.
Can you also comment on the choice to use Coding rather than code - the spec (http://build.fhir.org/loinc.html#props) defines these properties as being code-typed
Last updated: Apr 12 2022 at 19:14 UTC
