Stream: terminology
Topic: Searching in a code system
Alexander Henket (Jan 26 2017 at 09:53):
Using the $lookup operation I can get the properties of a concept/code I already know the code for. But how do I ask for:
Gimme concepts/codes from SNOMED CT where displayName contains "frac bon". In our 20160731 release this would return 302 concepts.
I thought that's what the $lookup was for but I don't see how. The CodeSystem search params also do not leave room for this as far as I can tell.
Vadim Peretokin (Jan 26 2017 at 11:56):
Would $expand + ?filter work for you? See http://ontoserver.csiro.au/vstool/ for an interactive demo
Alexander Henket (Jan 27 2017 at 08:12):
That only works if you create an intensional ValueSet for every CodeSystem that includes this full CodeSystem. That really sounds like a workaround. Sure it works, but god forbids someone actually asks for the expansion without filter when it is SNOMED or LOINC.
I'd really expect a search feature on CodeSystem contents, which produces a ValueSet. The search expression could actually be the basis for an intensional value set, while the response could actually be the expansion of the expression
Vadim Peretokin (Jan 27 2017 at 08:15):
Server could return a TooCostly error then if they ask for that unfiltered expansion.
Making the valueset code a codesystem isn't too hard, you wouldn't even need a separate resource - Codesystem.valueSet (http://build.fhir.org/codesystem-definitions.html#CodeSystem.valueSet) can be used to define it on the spot for you
Vadim Peretokin (Jan 27 2017 at 08:16):
I think the idea is that you start working more with valuesets more in general, not with codesystems directly. That's the feeling I get from Grahame's presentations on this
Alexander Henket (Jan 27 2017 at 08:18):
He, that's nice: I totally missed the CodeSystem.valueSet notion... that helps. I will chew on that some more.
Vadim Peretokin (Jan 27 2017 at 08:21):
ok!
Michael Lawley (Jan 27 2017 at 09:58):
In addition, for well-known code systems like SNOMED, there is a well known URL for "all codes in SNOMED" -- http://snomed.info/sct?fhir_vs
Grahame Grieve (Feb 06 2017 at 02:50):
agree - current design is that this a value set thing. There is a usecase for searching code systems, but it generally falls into 'code system maintenance' which we re-affirmed is not in scope for FHIR in San Antonio. That doesn't mean that searching code systems directly itself is always out of scope, but it's certainly an R4 thing at this time
Alexander Henket (Feb 08 2017 at 12:53):
For clarification. I'm looking into codesystem search for valueset authoring purposes only, not codesystem maintenance.
Grahame Grieve (Feb 08 2017 at 18:20):
well, is it reasonable to extend expansion so you can nominate a code system instead of a value set, and make resolving the default value set the server's problem, not the clients?
Alexander Henket (Feb 08 2017 at 20:02):
Had to think on that. I think what you mean is:
[base]/ValueSet/$expand
Parameter codeSystem = http://snomed.info/sct
Parameter filter = frac bone
response = ValueSet
To search for "frac bone" in SNOMED CT? So while you, at first glance, are searching on the ValueSet endpoint, you are in fact searching in CodeSystem because of the codeSystem parameter. You could argue you are still actually searching the implicit ValueSet that contains the full codesystem. I suppose that could work. Would you say this is something likely to be reworked once the 'real release 4' solution comes in, or would you say this proposal has a chance for survival?
Jim Steel (Feb 08 2017 at 22:55):
can't you do that by POSTing a Parameters object with an inline valueSet that includes that codeSystem (and the filter parameter)? I don't understand how having an extra 'codeSystem' parameter changes likely server behaviour
Grahame Grieve (Feb 09 2017 at 03:46):
it makes for a simpler API.
Grahame Grieve (Feb 09 2017 at 03:47):
but it is semantically equivalent, yes
Last updated: Apr 12 2022 at 19:14 UTC
