Stream: terminology
Topic: Terminology for FHIR servers
nicola (RIO/SS) (Apr 30 2019 at 14:10):
I've written a post about decoupling terminology and FHIR servers - https://medium.com/@niquola/two-phase-fhir-terminology-e52e1b105f6d. It would be great to get your feedback!
Brian Postlethwaite (Apr 30 2019 at 22:33):
A good write up @nicola (RIO/SS) ,but you might like to add a small section on the $closure opertation, and how that might be useful for the split setup. Then I think that's more or less complete.
Peter Jordan (Apr 30 2019 at 23:49):
Interesting post. I'm not sure about creating a Concept Resource with links to ValueSets as that would create circular references. There are some other challenges with that general approach, for example not all Code Systems facilitate concept permanence and you've got to tackle the versioning issue in that properties (including active status) of a concept can change from one edition to another. I still favour the proxy approach whereby a 'general/clinical' FHIR server passes Terminology Operation Calls to a specialist FHIR Terminology Server. The notion of a single, autonomous, FHIR Server that covers the whole specification is unrealistic - even Grahame's server doesn't implement everything!
Jim Steel (May 01 2019 at 03:54):
Just skimming, GET /ValueSet/v1/$expand?_filter=x should probably be filter, not _filter
Jim Steel (May 01 2019 at 04:29):
If you want to handle (a bounded set of) implicit ValueSets, it might be worth linking from Concepts to ValueSets by URI/version rather than (or as well as) by id
Michael Lawley (May 01 2019 at 23:26):
An interesting approach. How do you propose to handle infinite code systems and those with post coordination?
nicola (RIO/SS) (May 02 2019 at 03:13):
Good question. What other infinite code system than ucum?
nicola (RIO/SS) (May 02 2019 at 03:17):
From terminology service point of view, what means handle post-coordination? Parse expression on validation?
Lloyd McKenzie (May 02 2019 at 03:18):
SNOMED is practically infinite if you include post-coordination
nicola (RIO/SS) (May 02 2019 at 03:20):
Do we have infinite ValueSets?
Rob Hausam (May 02 2019 at 03:21):
Potentially, yes - if they are intensionally defined and based on an "infinite" code system.
nicola (RIO/SS) (May 02 2019 at 03:23):
Does anyone use it in practice? ;)
Lloyd McKenzie (May 02 2019 at 03:23):
There are quite a few value sets that say things like "all UCUM codes" or "all SNOMED codes" or even "all SNOMED Procedure codes"
Lloyd McKenzie (May 02 2019 at 03:23):
And Grahame validates them
Lloyd McKenzie (May 02 2019 at 03:24):
So long as you know the code system and the grammar, you can do it. But you don't do it by expanding all the options ahead of time :)
nicola (RIO/SS) (May 02 2019 at 03:25):
Looks like ucum is more than just terminology.
nicola (RIO/SS) (May 02 2019 at 03:29):
About post coordination - i’m really not a fan of expressions in code - can we imagine structured way to work with it? Or at least use something like .expression element to mark it explicitly. I think, it would be source of mistakes and confusion in real apps
nicola (RIO/SS) (May 02 2019 at 03:45):
We have to handle units of measure on search and comparison. The essential difference of ucum - it involves not only codes, but quantity values as well. One approach is to have automatic translation on save to some canonical units. Does any existing FHIR server handle it properly?
Josh Mandel (May 02 2019 at 03:45):
Yes, I think Vonk does this.
Josh Mandel (May 02 2019 at 03:45):
well, not translation on save; but translation on search.
Jim Steel (May 02 2019 at 03:46):
There are an infinite number of ValueSets we use for SNOMED (hierarchy, ECL), and a very large number for LOINC (hierarchy, answer lists)
nicola (RIO/SS) (May 02 2019 at 03:46):
Josh, is it possible to do it efficiently ? ;)
nicola (RIO/SS) (May 02 2019 at 03:52):
Jim, can you give more details about infinite loinc?
Lloyd McKenzie (May 02 2019 at 04:13):
Lots of systems don't treat post-coordinated terms any differently than regular terms. Would you want "cm" or "mg" flagged as ".expression"? Because that's what they are... It also creates a dividing line between the post and pre-coordinated terms which is contrary to the objectives of terminologies that support post-coordination. (And there's no hope of coming up with a common framework for them - every system that does it does it differently.)
Josh Mandel (May 02 2019 at 12:22):
Josh, is it possible to do it efficiently ? ;)
For units, sure -- just canonicalize each stored value, and canonicalize all searches.
Grahame Grieve (May 03 2019 at 09:37):
most of the big terminologies have some kind of grammar. You might not like it, but it's not going away
Grahame Grieve (May 03 2019 at 09:39):
so your approach is a reasonable one except for grammar, but that won't go away.
Grahame Grieve (May 03 2019 at 09:40):
I don't think that if we define a Concept resource- which might happen - it will include the value set denormalization - that would be extension space. Since it's only valid for a particular set of expansions
Grahame Grieve (May 03 2019 at 09:40):
but also, there is not one single expansion - there's a set of expansions depending on the use of the value set
Grahame Grieve (May 03 2019 at 09:41):
- see the expansion parameters
Michael Lawley (May 04 2019 at 02:35):
What problem does a Concept resource solve?
Grahame Grieve (May 04 2019 at 07:53):
authoring terminologies, and in particular, ad-hoc definition of pieces of knowledge that are not actually in a formal code system
Last updated: Apr 12 2022 at 19:14 UTC
