FHIR Chat · modeling loinc · implementers

Stream: implementers

Topic: modeling loinc


view this post on Zulip Josh Mandel (Oct 29 2016 at 05:14):

http://build.fhir.org/loinc.html#alist shows hows a set of LOINC answer codes can be represented as a ValueSet, using an example of platelet morphology choices. But I can't see any way to say "and this value set is associated with LOINC code 11125-2. Is there a way to define this linkage, or do consumers have to somehow intuit it?

view this post on Zulip Grahame Grieve (Oct 29 2016 at 09:10):

Dan Vreeman and I were talking about that on Wednesday night. I'll be updating LOINC page in the next 48 hours with out answer

view this post on Zulip Josh Mandel (Oct 29 2016 at 15:10):

Ha, awesome! (I should say: I have an unrelated use case for this general kind of link, so i'm hoping your solution isn't LOINC-specific :-))

view this post on Zulip Grahame Grieve (Oct 29 2016 at 20:06):

hmm it is. what's your case?

view this post on Zulip Robert McClure (Oct 30 2016 at 16:45):

This is exactly why I discussed with Stan and then Dan about the use of the emergine new Binding Semantics project (http://wiki.hl7.org/index.php?title=Binding_Syntax#Current_Working_Material) to represent the link between the LOINC observable and the defined set of answers. I urge you all to align. I'll be referencing this discussion back to Stan and Dan via email and include @Grahame Grieve
Stan and Dan agreed they would work to do this and bring it to the LOINC committee for discussion.

view this post on Zulip Grahame Grieve (Oct 30 2016 at 20:25):

I don't thnk this has anything to do with binding syntax

view this post on Zulip Robert McClure (Oct 31 2016 at 17:41):

Josh's need to say "and this value set is associated with LOINC code 11125-2." Is essentially a binding with one big difference, it's to a code and not to a model element. Granted that is a big difference so it's really not what we've decided "a binding" is meant to represent, but the fact is that all the issues of binding actually insert themselves.

Because of this I've asked LOINC to consider rerpresenting "the link" of a LOINC code to the allowed set of answers using a more formal - more computable - expression. RIght now it's simply buried in the LOINC tables - as Josh has noted. I posit that that more formal expression of linkage can be very similar to a binding statement.

view this post on Zulip Josh Mandel (Oct 31 2016 at 17:44):

Thanks @Robert McClure -- though from the perspective of consuming LOINC (e.g. converting LOINC's published tables into FHIR resources) this is straightforward; the data are there. The problem is there's no way to say in FHIR "{this term} in a CodeSystem is associated with the answers defined in {this other} ValueSet."

view this post on Zulip Robert McClure (Oct 31 2016 at 17:51):

Agree there is no way to do that. So far as I can tell, this is somewhat unique to LOINC and some have argued because it's all "inside LOINC" this is really better managed as code system knowledge. That could be a solution (although IMHO this is not the type of information that should be "in a code system" because it's too volatile) but LOINC does not have concept relations that can be used to represent this, so we have to hack it someplace.

Perhaps given all th complexities, instead of representing this link as code to value set we should push LOINC to define the link inside the code system. Then the association you need to support in FHIR is simply a code system query?

view this post on Zulip Grahame Grieve (Oct 31 2016 at 18:12):

right, define LOINC properties for the various codes. That's what Dan and I agreed last week

view this post on Zulip Robert McClure (Oct 31 2016 at 22:00):

WHat "LOINC Property" are we thinking? I'm not aware of any LOINC concept relations. My understanding is that LOINC properties are the things we've wanted for quite some time and they are coded names (in LOINC code system) for each of the "attributes" of a LOINC code (like Method and Scale). I'm not sure how those will work to link to answer sets unless they create yet another attribute "Answer Set ID" or some such. Even then, we still need to find which actual LA codes are in the answer set. SO I'm not sure what you've gotten Dan to agree to that fixes this.

view this post on Zulip Grahame Grieve (Nov 01 2016 at 05:56):

I left it to Dan to sort out the distribution issues; we just agreed on how a terminology server would expose this information


Last updated: Apr 12 2022 at 19:14 UTC