Stream: terminology
Topic: Workflow for terminology server in UI
Sean McIlvenna (Jan 30 2018 at 21:18):
This question is related to what @Robert McClure and I were talking about during the connectathon...
In the scenario I imagine, if I load a Questionnaire and generate a UI for it... a value set is represented as a type-ahead/drop-down. I struggle with how best to get the FHIR ValueSet resource with its <expansion>. I talked about possibly using a separate terminology server to provide the <expansion>, but that has some complications. @Robert McClure , you mentioned you thought instead that you could get a pre-expanded value set, and then upload that to the primary FHIR server where the questionnaire gets loaded. However, if you are only supposed to return <expansion> as a result of the $expand operation, then how would I load the expanded ValueSet on the server and then GET the expansion back out, without it having $expand implemented (which I suspect will primarily be implemented by terminology servers, not core/resource FHIR servers)?
Sean McIlvenna (Jan 30 2018 at 21:19):
... I think this has application to far more than just my questionnaire scenario, too, btw.
Grahame Grieve (Jan 30 2018 at 21:39):
" I talked about possibly using a separate terminology server to provide the <expansion>, but that has some complications".. which are...?
Sean McIlvenna (Jan 30 2018 at 23:57):
the big one: as it stands, most terminology servers don't yet implement POST ValueSet/$expand
Sean McIlvenna (Jan 30 2018 at 23:57):
so, if the terminology server doesn't support POST ValueSet/$expand, then what?
Jim Steel (Jan 30 2018 at 23:57):
Switch to one that does ;)
Sean McIlvenna (Jan 30 2018 at 23:57):
POST the ValueSet (with <compose>) to their server and GET ValueSet/[id]/$expand
Sean McIlvenna (Jan 30 2018 at 23:57):
?
Sean McIlvenna (Jan 30 2018 at 23:58):
@Jim Steel , yah... and in lieu of that?
Jim Steel (Jan 30 2018 at 23:59):
If by "in lieu of that", you're suggesting there aren't any, I'd beg to differ. I'd be interested to see the answer to Grahame's question, what are the complications? Data privacy?
Sean McIlvenna (Jan 31 2018 at 00:03):
1) i'd love to get my hands on terminology servers that do support POST $expand... so, please send me any you are aware of. maybe I'm just unlucky... but the handlful that I played with during the connectathon had varying levels of support for POST $expand
2) I'm really trying to figure out if there are alternative workflows to this scenario.
3) I'm wondering what someone would do if they had limited access to terminology servers, and just had their own FHIR resource server
Sean McIlvenna (Jan 31 2018 at 00:04):
In #3's case, maybe they got their hands on a ValueSet that had an <expansion>, and they wanted to use it... what would be the proper way of doing that.
Jim Steel (Jan 31 2018 at 00:04):
https://ontoserver.csiro.au/stu3-latest (demo server for https://ontoserver.csiro.au)
Sean McIlvenna (Jan 31 2018 at 00:04):
if any
Jim Steel (Jan 31 2018 at 00:08):
I'm a little surprised that others don't support it. It really shouldn't be any more difficult than instance expand. Putting pressure on vendors of those servers might lead them to add support for it..
As for alternative workflows, either precalculating an expansion and using it client-side, or creating the ValueSet on a server and using instance expand do seem like the alternatives (albeit with disadvantages)
Jim Steel (Jan 31 2018 at 00:09):
Be aware, too, that the terminology server's performance is pretty important if you're doing typeahead/dropdown completion, especially on large and/or complex ValueSets
Jim Steel (Jan 31 2018 at 00:10):
(Disclaimer: I work for the company that makes Ontoserver. I'm not pretending to be impartial here)
Sean McIlvenna (Jan 31 2018 at 01:15):
Thanks Jim. Yes, I agree with your first point. And especially considering it is such a critical use-case (in my opinion, at least).
Regarding alternative workflows... can you expand on "pre-calculating an expression"
Jim Steel (Jan 31 2018 at 01:15):
expansion
Jim Steel (Jan 31 2018 at 01:16):
At dev time, just calculate the expansion of the ValueSet, and do the searching client-side. Its probably less efficient (provided your terminology server is performant), and it means you don't get updates (new versions of code systems, etc)
Grahame Grieve (Jan 31 2018 at 02:36):
@Sean McIlvenna if you think my server doesn't fully support the spec, please let me know how
Sean McIlvenna (Jan 31 2018 at 05:10):
@Grahame Grieve it does :) supports it well. but, looking for variety, as well.
Sean McIlvenna (Jan 31 2018 at 05:14):
@Jim Steel , your "pre-calc" scenario brings us fully back around to my original question:
if I pre-calc a value set, how do I access it in a FHIR way? I can't just POST the expansion with the value set, because expansion isn't supposed to be returned unless $expand is requested. so, where does the expansion for the value set go that I can retrieve it again in my app? are we just relying on a proprietary solution?
Jim Steel (Jan 31 2018 at 05:23):
Yes, at that point you're just pretty much relying on a proprietary solution. The best you can do is swap out the retrieval of the JSON (retrieve it statically rather than from a server, but then access the JSON structure the same way).
I'm not presenting this as a good alternative. The good option is to use a terminology server that supports POST-style invocation, like Grahame's server, or Ontoserver (or others)
Grahame Grieve (Jan 31 2018 at 12:09):
@Jim Steel it's not wrong to post expansions, and the server returns what it has when you just access the value set
Sean McIlvenna (Jan 31 2018 at 13:12):
@Grahame Grieve , what do you do when you have multiple calculations/expansions of a value set that you need to access?
Grahame Grieve (Jan 31 2018 at 13:17):
then you can't; this is why sharing definitions is way more useful and safe than sharing particular expansions. But whole legacy eco-systems depend on sharing expansions not definitions, and there are occasionally use cases where it's actually useful
Sean McIlvenna (Jan 31 2018 at 14:10):
@Grahame Grieve , would it be worth considering some changes to allow POST/PUTing multiple expansions, and providing a mechanism of returning the expansion desired?
Grahame Grieve (Jan 31 2018 at 15:02):
I don't think so - you can post multiple expansions as different resources; anything beyond that is private business of the srver
Yunwei Wang (Jan 31 2018 at 15:06):
@Sean McIlvenna Our server support POST VaueSet/$expand. If you need access, please let me know.
Sean McIlvenna (Jan 31 2018 at 15:17):
@Grahame Grieve what "other" resources are you thinking of?
Sean McIlvenna (Jan 31 2018 at 15:18):
@Yunwei Wang , yes, that would be great
Grahame Grieve (Jan 31 2018 at 15:19):
different instances of value set
Sean McIlvenna (Jan 31 2018 at 15:19):
gotcha
Peter Jordan (Jan 31 2018 at 15:49):
@Sean McIlvenna it would be interested to see an example of an SCT ValueSet that you wish to POST as a parameter to an $expansion operation request. Although my server is only an exemplar, free to use and (to date) read-only by design; if someone can show me that there are use cases relating to SCT that can only be implemented by this (bearing in mind that ECL expressions can now be passed as filters) I'll review my policy.
Sean McIlvenna (Jan 31 2018 at 15:56):
@Peter Jordan , to be clear... POST ValueSet/$expand does not involve storing the ValueSet being POST'd on the server. It is sending the ValueSet to the server to have the expansion calculated and immediately returned. It is up the server to decide if it should store the ValueSet in the POST or not.
Peter Jordan (Jan 31 2018 at 16:00):
Fully understand that @Sean McIlvenna, but what are the use cases for SCT-based value sets now that ECL expressions can be passed as filters?
Grahame Grieve (Jan 31 2018 at 16:03):
because you have one defined that way, the way that no one currently supports. You have a value set defined any old way. Or even that you have a value set defined that way, but you don't know whether or not the value set is defined on the server, since you sourced it from somewhere else, and you don't want to have to have the security clearance to register value sets on the server with all the associated curation responsibilities. You just have a value set from a profile or a quetsionnaire that you need to have expanded correctly
Sean McIlvenna (Jan 31 2018 at 16:03):
Hit me up in person later and I'll explain my scenario... a bit long winded to type while taking minutes in this meeting :)
Peter Jordan (Jan 31 2018 at 16:11):
Will do @Sean McIlvenna. @Grahame Grieve - doesn't your R4 server support ECL filters? I'm sure that Ontoserver will, given their existing capability. My implementation is still limited and I need to fix a bug that I discovered yesterday.
Grahame Grieve (Jan 31 2018 at 16:13):
no I don't support ECL.
Grahame Grieve (Jan 31 2018 at 16:13):
can't do everything....
Grahame Grieve (Jan 31 2018 at 16:13):
maybe one day
Peter Jordan (Jan 31 2018 at 16:25):
Understand, although servers will need to support ECL if passed as filters within intensional value set definitions POSTed to an expansion request.
Michael Lawley (Jan 31 2018 at 23:50):
FWIW @Sean McIlvenna , the suite of terminology clients we have written (browser: http://ontoserver.csiro.au/shrimp, and simple authoring http://ontoserver.csiro.au/snapper2-dev) make extensive use of ValueSets provided via POST to $expand (and using ECL). The tools themselves can be pointed at other FHIR terminology servers, but as you observe, many are incomplete and thus successful results vary.
Michael Lawley (Jan 31 2018 at 23:53):
The sandbox endpoint @Jim Steel mentioned is freely available (http://ontoserver.csiro.au/stu3-latest) for you to experiment with. From what you've described here I don't think there's anything it won't handle.
Last updated: Apr 12 2022 at 19:14 UTC
