Stream: implementers
Topic: Terminology
Michael Lawley (Feb 19 2016 at 05:49):
[reposting from Skype Terminology list]
My little VSTool is now available: http://ontoserver.csiro.au/vstool/ It has a limited number of pre-configured endpoints supporting FHIR Terminology (let me know if you want others added) and a some pre-configures sample ValueSets to work with. Hover over an endpoint name to see some additional details, click on a code to do a $lookup on that code with the server of the same column
Each column shows the reported number of matching codes (only the 1st 10 are requested) and the response time (timing started separately for each request, but potentially affected by processing a quicker server's response).
The bottom of the table shows the actual request (sans endpoint) that was sent to each server
Michael Lawley (Feb 22 2016 at 05:52):
Looking for any further details on http://hl7.org/fhir/StructureDefinition/conformance-supported-system -- @Grahame Grieve you server seems to use http://hl7.org/fhir/StructureDefinition/conformance-common-supported-system instead?
Grahame Grieve (Feb 22 2016 at 19:44):
Michael, what further details do you want? I think we should replace that extension with a direct reference to the code system resource
Chris Grenz (Feb 29 2016 at 15:27):
Server implementers - how are you validating bcp47 tags? Is this special handling? I can't see a way to implement a bcp47 valueset that isn't hopelessly huge... @Grahame Grieve @Ewout Kramer @James Agnew ?
Josh Mandel (Feb 29 2016 at 15:47):
I thought FHIR had defined some constraints on BCP47, but it appears not. This is a nice practical tool for exploring the BCP47 space: http://schneegans.de/lv/.
Also https://github.com/DanSmith/languagetags-sharp
For some reason it's the C# community that seems to care about this :-)
Chris Grenz (Feb 29 2016 at 15:48):
Yep...we've been using that to better understand...
Chris Grenz (Feb 29 2016 at 15:48):
The FHIR bindings though imply that the normal ValueSet @validate will be used to determine validity
Chris Grenz (Feb 29 2016 at 15:49):
Which leads either to a valueset with all possible combinations of tags OR special case handling
Josh Mandel (Feb 29 2016 at 15:49):
"Ha!". Yeah, that's not realistic for a grammar like this (similar to the story for UCUM).
Chris Grenz (Feb 29 2016 at 15:49):
Does valueset need some kind of capability to support these? Or at least indicate special handling?
Josh Mandel (Feb 29 2016 at 15:49):
It's also worth pointing out that unconstrained BCP47 tags make the "language" search param on Patient pretty hard to use.
Josh Mandel (Feb 29 2016 at 15:50):
i.e. no good way to say "all patients who speak english".
Chris Grenz (Feb 29 2016 at 15:50):
right...need some kind of hierarchy or equivalence...
Josh Mandel (Feb 29 2016 at 15:51):
Hmm, at https://hl7-fhir.github.io/patient.profile.xml I see
<binding> <strength value="required"/> <description value="A human language."/> <valueSetUri value="http://tools.ietf.org/html/bcp47"/> </binding>
which doesn't use a FHIR valueset at all. Where are you looking?
Chris Grenz (Feb 29 2016 at 15:51):
doesn't valueSetUri imply a valueset?
Josh Mandel (Feb 29 2016 at 15:53):
It's a fair question :-) But what I mean is, I don't see a FHIR ValueSet resource written down anywhere (let alone written down and stating "this can't be used for validation because it doesn't implement the necessary grammar")
Chris Grenz (Feb 29 2016 at 15:53):
Hmm...Documentation>System List uses urn:ietf:bcp:47
Josh Mandel (Feb 29 2016 at 15:53):
Yes, I just saw this in an example too, at http://hl7-fhir.github.io/patient-example-f001-pieter.json.html
Chris Grenz (Feb 29 2016 at 15:53):
Agree - there's nothing in the validation package for bcp47
Chris Grenz (Feb 29 2016 at 15:54):
Do any of the servers validate these tags?
Josh Mandel (Feb 29 2016 at 15:54):
Mine doesn't.
Josh Mandel (Feb 29 2016 at 15:54):
I'd be surprised.
Chris Grenz (Feb 29 2016 at 15:55):
ok...might consider a gForge
Chris Grenz (Feb 29 2016 at 15:56):
although I'm not sure what to put in it!
Josh Mandel (Feb 29 2016 at 15:56):
In the FHIR build at implementations/csharp/Hl7.Fhir.Model/Validation/xhtml/xml.xsd I love the following
Attempting to install the relevant ISO 2- and 3-letter codes as the enumerated possible values is probably never going to be a realistic possibility.
Chris Grenz (Feb 29 2016 at 15:57):
Huh...known issue, eh?
Josh Mandel (Feb 29 2016 at 15:57):
Well, buried in a validation file in the c# implementation (which I didn't think was even maintained in the build anymore; that file is pretty orphaned)
Josh Mandel (Feb 29 2016 at 15:58):
Yeah, for a GForge issue the question is basically How on earth do we use language tags in FHIR?
Chris Grenz (Feb 29 2016 at 15:58):
ok...I'll open one. Chime in as you see fit!
Josh Mandel (Feb 29 2016 at 16:06):
Sure -- just share a link here if you would!
Chris Grenz (Feb 29 2016 at 16:08):
Done. http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemEdit&tracker_item_id=9647
Josh Mandel (Feb 29 2016 at 16:08):
Thanks!
Josh Mandel (Feb 29 2016 at 16:09):
Very clear -- I don't think I have anything to add :-)
Chris Grenz (Feb 29 2016 at 16:09):
Maybe just a "yeah!" ;)
Josh Mandel (Feb 29 2016 at 16:10):
Done!
Grahame Grieve (Feb 29 2016 at 16:42):
k. so the value set is implicit. e.g. it needs special case handling. I don't think I've done the special case handling for this yet
Grahame Grieve (Feb 29 2016 at 16:42):
there's no way to represent this complexity in an explicit value set, though you can make restricted enumeration value sets on the languages
Ewout Kramer (Feb 29 2016 at 17:10):
doesn't valueSetUri imply a valueset?
Not in the sense of a ValueSet resource, the element value[x] is either a Uri or a Reference. In the latter case, this would point to a FHIR ValueSet resource, otherwise it's a more informal reference.
Alexander Henket (Feb 29 2016 at 18:58):
@Ewout Kramer Are you saying that the implied value set could be of any format then?
Ewout Kramer (Feb 29 2016 at 19:04):
When referenced to by valueUri, yes, indeed. In fact, you could leave out value[x] completely and just use 'description' to describe what you are referring to instead of having an actual reference - even more informal.
Alexander Henket (Feb 29 2016 at 19:06):
O wow. Is there any language to discourage that? Or is this support for SVS, CTS2, Word, Excel and what have you to be more common than I would hope?
Grahame Grieve (Feb 29 2016 at 19:06):
we've only used it in 2 places, where we refer to w3c specs for language and mediatype
Grahame Grieve (Feb 29 2016 at 19:07):
since they're not really processible, I figure that we don't need to add any language around this; people that do it out of laziness will get beaten upon
Alexander Henket (Feb 29 2016 at 19:08):
OK, so uncommon in the base spec, but a potential invitation for people not to invest in FHIR processable value set if and when possible. Some language on dos and donts is probably in order
Ewout Kramer (Feb 29 2016 at 19:10):
We should be more specific about the kind of punishment you will receive, yes.
Ewout Kramer (Feb 29 2016 at 19:10):
;-)
Grahame Grieve (Feb 29 2016 at 19:10):
you'll get dutch people screaming at you?
Alexander Henket (Feb 29 2016 at 19:25):
Errr... not volunteering...
James Agnew (Feb 29 2016 at 19:48):
@Chris Grenz I'm assuming you're thinking for the Resource.language property? HAPI doesn't validate that currently. That sounds.... painful to implement :)
James Agnew (Feb 29 2016 at 19:48):
Oops, I see I missed a bunch of the subsequent discussion.
James Agnew (Feb 29 2016 at 19:49):
Still getting used to Zulip :)
Michael Lawley (Mar 01 2016 at 00:52):
Sorry for delay in responding. I'm wondering which is the right (best) one to use (only the first one resolves to anything). Looking closer, I'm thinking that it only supports identifying a particular code system as being supported, but not which versions of that code system are supported (which is what I also need to do)
Grahame Grieve (Mar 01 2016 at 01:08):
Michael - what's the context of that?
Michael Lawley (Mar 01 2016 at 01:17):
argh, I thought zulip did "real" threading and thus would attach my reply to the message I replied to, but I gather it just does topics
The context was my (week old) question about the extensions to list supported code systems in the metadata Conformance Resource.
Chris Grenz (Mar 01 2016 at 14:44):
@James Agnew Anywhere that the bcp47 binding is found. Patient and practitioner communication is probably more immediately interesting. I've opened a gForge. My thought at this point is that it should look like a simple ValueSet binding if it's not simple!
Chris Grenz (Mar 01 2016 at 14:46):
And I also missed some later comments...not sure it's very clear that a "valueSetUri" may not point to a ValueSet.
Peter Jordan (Mar 01 2016 at 22:34):
@Michael Lawley The example in the spec states that this is "a todo for a future version to standardise things like which versions are supported etc." One possibility is to include the version in the URI - where, like SNOMED CT, the Code System has this facility - although I'm not sure if that would be permissible?
Brian Postlethwaite (Mar 03 2016 at 17:34):
@Chris Grenz @Josh Mandel That file from the c# model is still there in the github code. Just no in the build process anymore. (I just checked)
Chris Grenz (Mar 03 2016 at 20:40):
@Brian Postlethwaite Sorry....which file? The bcp47 sub-tag registry?
Brian Postlethwaite (Mar 03 2016 at 22:46):
The xsd file (Validation/xhtml/xml.xsd) that josh reference that is no longer in the build process (as its now external)
Grahame Grieve (Mar 05 2016 at 01:01):
what xsd file?
Grahame Grieve (Mar 08 2016 at 01:16):
now that we're defining the CodeSystem resource, are we going to define standard code system resources for SNOMED CT, LOINC, etc?
Grahame Grieve (Mar 08 2016 at 01:16):
in fact, for this list:
Grahame Grieve (Mar 08 2016 at 01:16):
http://hl7.org/fhir/terminologies-systems.html
Lloyd McKenzie (Mar 08 2016 at 01:57):
It would be a good idea
Grahame Grieve (Mar 08 2016 at 02:01):
does anyone want to volunteer to make some up?
Reuben Daniels (Mar 08 2016 at 03:41):
Grahame: I assume you mean FHIR code system resource instances for those terminologies, but without their content (codes, descriptions, relationships, tec.) ?
Reuben Daniels (Mar 08 2016 at 03:41):
*etc
Grahame Grieve (Mar 08 2016 at 03:44):
yes. maybe a very few we'll carry the full code system, but that would have to come with careful consideration. (we do for DICOM, for instance)
Grahame Grieve (Mar 08 2016 at 03:44):
well, with out the code,s, but with the definition of the properties
Michael Lawley (Mar 10 2016 at 05:32):
please no :( We don't need another "distribution format" for SNOMED; I thought the whole idea of the termiology service support in FHIR was to avoid having to do this kind of thing
Grahame Grieve (Mar 10 2016 at 05:39):
no, not the content. Just the properties and filters.
Patrick Werner (Mar 16 2016 at 12:53):
oh ok, good to know. We almost started to extend a library of ours in order to import the whole ICD-10-GM-* dataset onto a fhir server. What OpenSource terminologyserver would you recommend
Grahame Grieve (Mar 16 2016 at 20:47):
well, ontoserver is probably the best. Or you can use mine (healthintersections.com.au/FhirServer) or Apelons
Patrick Werner (Mar 16 2016 at 22:34):
thx
nicola (RIO/SS) (Dec 01 2016 at 15:30):
Definition of valuesets by both inclusion and exclusion with imports makes expansion not optimizable, i.e. forces expansion to be sequential and depends on order of rules. It's like problems with negation in logic or mess in security rules with allow & deny. If we will take into account versions - efficient and correct implementation of terminology becomes really challenge. Set of codes from different code-systems also induces some semantic doubts :)
Grahame Grieve (Dec 01 2016 at 18:43):
how does it make it sequential? I don't think the definition is sequential.
Grahame Grieve (Dec 01 2016 at 18:43):
I agree that it's much harder to optimise than it was. But reality doesn't go away even when you want to (and I really tried on this one!)
Michael Lawley (Dec 02 2016 at 11:20):
The only "sequential" bit is that excludes happen after includes, but we compile the definition into a single query and send it off for evaluation. This also includes complex things like the SNOMED CT Expression Constraint Language
nicola (RIO/SS) (Dec 02 2016 at 12:42):
You could not compile value set into one non-nested query because import + exclude, because exclude has scope, to which it's applied
nicola (RIO/SS) (Dec 02 2016 at 12:44):
Just for example vs2 (include:[c1], import: [vs1]) and vs1 (include[c1,c2], exclude:[c1]) - should vs2 contains c1?
nicola (RIO/SS) (Dec 02 2016 at 13:25):
Without exclude we could implement efficient import, or even better without import we have less problems. Do we really need this inheritance in ValueSets? Could we replace it with composition in profiles? i.e. this element should be coded from VS1 or VS2
Grahame Grieve (Dec 02 2016 at 19:11):
we do need it, yes. And if we moved the problem to profiles, we would have to deal with and and or in profiles - messy. There's already a proposal to complicate the binding and it's one of the most contentious parts of the typing system now
Grahame Grieve (Dec 02 2016 at 19:11):
and in your example, vs2 won't contain anything in c1
nicola (RIO/SS) (Dec 02 2016 at 21:37):
@Grahame Grieve do you mean vs2 should not contain c1, even after it's stated explicitly vs2(include: [c1])?
Grahame Grieve (Dec 03 2016 at 01:15):
well, you include it, but you also exclude it. So nothing from it will be present in the end. It's a bit redundant
nicola (RIO/SS) (Dec 03 2016 at 19:47):
This behaviour could be confusing for designers of valuesets, because import/inheritance is implicit and you could build long chain of imports and after that get situation where the parent exclude rules will override children's includes :(( But good news if exclude rules are global for the chain, we could optimize expansion :) I still have doubts that imports is a good idea, because such ambiguity.
Grahame Grieve (Dec 03 2016 at 20:11):
'parent' and 'child' are the wrong words. By the stated rules, excludes in an imported values set will not override excludes in the value set that imports it
nicola (RIO/SS) (Dec 03 2016 at 20:13):
I mean excludes in imported valuesets will override includes in VS that imports it ?!
Grahame Grieve (Dec 03 2016 at 20:17):
no
Stefan Lang (Dec 03 2016 at 21:45):
But then vs2 would contain c1, since vs2 includes c1, which is not to be overriden by exclude:[c1] in the imported vs1 ?
Which in fact seems more consistent to me, though making optimization harder ;-)
Stefan Lang (Dec 03 2016 at 21:59):
Basically I would think of vs1 as readily processed when it "arrives"as an import into vs2, so whatever happens when generating vs2 is not influenced by the rules from which vs1 was generated but only by the final content of vs1. Right?
nicola (RIO/SS) (Dec 04 2016 at 15:28):
That's what i call - "sequential" logic of expansion - i should expand included value sets and then compose - i could not change order of this proccess
Grahame Grieve (Dec 04 2016 at 19:39):
well, you can change the order within the include list, and within the exclude list, but not otherwise, no
Robert McClure (Dec 05 2016 at 04:49):
Per the VSD, "included" value sets are to pass expansions to the value set they are included in. In other words you SHALL expand from the inside out. The expression used to define an "included" value set is scoped FOR THAT VALUE SET ONLY. I.E.: No "exclude" in an "included" value set should ever dictate behavior in an "including" value set. If you want to do that DON"T use an "include value set" function. Instead you should explictly craft a single expression for the value set you want.
nicola (RIO/SS) (Dec 05 2016 at 08:55):
@Robert McClure do you mean "import", not "include"?
Robert McClure (Dec 06 2016 at 04:05):
Ah, sorry I did mean "Import". I'm assuming that "import value set" is the same as "include" it's expansion. Is that correct? BTW, where is the url for import? I don't see that operation in the value set resoure page.
Grahame Grieve (Dec 06 2016 at 04:14):
it's not an operation. It's this:
Grahame Grieve (Dec 06 2016 at 04:14):
http://build.fhir.org/valueset-definitions.html#ValueSet.compose.include.valueSet
Grahame Grieve (Dec 06 2016 at 04:15):
but it used to be called 'import' before the change Nicola is unhappy about (which we decided Wed Q1 in Baltimore0
Robert McClure (Dec 06 2016 at 14:35):
Ok - that makes sense because it certainly seems like an "Include".
Do you agree with what I have noted above? That when a value set is "included" into another value set that resolving the definition of the included vs to determine an expansion set should done, essentially, from the inside out. And that each value set is "resolved" to an expansion set and then that result is passed to the value set that includes it. This makes things pretty straight forward IMO.
So any concept in the expansion of an included value set can subsequently be excluded by the value set using it. Or the opposite, a concept excluded in an "inner" value set can be subsequently included.
This means you should not try to create some uber-combined definition expression to determine the final expansion.
Grahame Grieve (Dec 06 2016 at 19:24):
I absolutely agree with that
Rob Hausam (Dec 06 2016 at 22:50):
agree
nicola (RIO/SS) (Dec 07 2016 at 09:21):
was compose.import replaced with compose.include.valueSet?
nicola (RIO/SS) (Dec 07 2016 at 09:23):
May be make it's type (VS.compose.import.valueSet) Reference(ValueSet) instead of uri?
Grahame Grieve (Dec 07 2016 at 10:48):
yes that's what happened. The data type was always uri, and so it stayed URI. we could replace uri with reference, or allow a choice...
Michael Lawley (Dec 09 2016 at 05:25):
coming back to this late @nicola (RIO) yes you need a form of nesting in the query so that in your example, the expansion of vs1 is {c2} and the expansion of vs2 is {c1,c2}
Brian Postlethwaite (Jan 04 2017 at 05:59):
Valueset expansions against the implicit SNOMED valueset, should these also include the nestings where appropriate?
e.g. Expansion.contains.contains to be populated with stuff
Grahame Grieve (Jan 04 2017 at 08:25):
can (not should)
Grahame Grieve (Jan 04 2017 at 09:09):
no problems. I am writing transforms from r2 to r3 for most resources, and have picked up quite a few issues
Brian Postlethwaite (Jan 04 2017 at 09:10):
Thanks Grahame.
Grahame Grieve (Jan 04 2017 at 09:11):
oops. that message was in the wrong topic
Brian Postlethwaite (Jan 05 2017 at 00:52):
I'm re-implementing terminology expansions in my server and wanted to check that my understanding is right.
http://hl7.org/fhir/2017Jan/valueset-detectedissue-category.html
This seems to not be expanding right.
The is-a codes are not included in the expansion. (this looks like a descendants-of expansion.
Brian Postlethwaite (Jan 05 2017 at 00:52):
(Ontoserver is returning the values though)
Brian Postlethwaite (Jan 05 2017 at 00:53):
Brian Postlethwaite (Jan 05 2017 at 01:13):
Is this related to the property http://hl7.org/fhir/concept-properties#notSelectable on the concept for the groupers? (as documented here http://hl7.org/fhir/2017Jan/codesystem.html#status
Brian Postlethwaite (Jan 05 2017 at 02:03):
Having updated to process with this assumption, now getting the same values (think is an onto-server bug).
Also wondering that there is http://hl7.org/fhir/concept-properties#deprecationDate but there is no concept for when it was introduced, anyone else had that need?
Grahame Grieve (Jan 05 2017 at 04:09):
I
Grahame Grieve (Jan 05 2017 at 04:10):
I'll have to investigate
Michael Lawley (Jan 12 2017 at 02:12):
@Brian Postlethwaite Why would "not selectable" affect expansion? It's a directive about appropriate client use.
Brian Postlethwaite (Jan 12 2017 at 02:20):
Looking for reasons why could be a difference between what you have and what the spec's expansion has.
(One of them has a problem)
Michael Lawley (Jan 12 2017 at 03:40):
hmm, if the expansion in the spec is the desirec contents, then it looks like the definition should be using descendent-of rather than is-a. Ontoserver is expanding is-a so it includes the "non-selectable" codes.
Grahame Grieve (Jan 12 2017 at 20:45):
I'll have to debug the build to see waht is going on
Last updated: Apr 12 2022 at 19:14 UTC
