Stream: implementers
Topic: CodeSystem $lookup operation
Ivan Dubrov (Jan 15 2019 at 00:45):
According to the specification (https://www.hl7.org/fhir/operation-codesystem-lookup.html), $lookup operation on CodeSystem is only defined on type level. However, other operations on CodeSystem are generally defined either on the type level or on the instance level (https://www.hl7.org/fhir/operationslist.html).
Why is this difference? Is it accidental or on purpose? I don't see any reason why $lookup cannot be defined on the instance level.
Lloyd McKenzie (Jan 15 2019 at 00:46):
@Rob Hausam @Grahame Grieve ?
Eric Haas (Jan 15 2019 at 02:33):
(deleted)
Eric Haas (Jan 15 2019 at 02:36):
and it would presume you knew the CodeSystem id which I don' t think is always the case. You don't need it as it is so why go to the extra trouble?
Ivan Dubrov (Jan 15 2019 at 04:17):
You are correct.
I was curious about discrepancy with other operations. For example, https://www.hl7.org/fhir/codesystem-operation-subsumes.html can be invoked both on type level and on an instance level. I can see how invoking it on an instance level might introduce a conflict (what if CodeSystem identified via "id" does not match the system provided as "coding" parameter?), but same argument could be applied to the "$subsumes" operation.
Rob Hausam (Jan 15 2019 at 13:08):
Yes, this does seem to be an anomaly. I'm not thinking of any discussions or any reason why this operation should not also have been defined at the instance level. Unless @Grahame Grieve knows of something? But the question now is, I guess, is whether we would want to attempt to change this for a normative operation? At least the change itself would be compatible.
Grahame Grieve (Jan 15 2019 at 13:45):
I can't think of any deliberate reason
Rob Hausam (Jan 16 2019 at 02:56):
So do we (or can we) add it in R5?
Grahame Grieve (Jan 16 2019 at 11:55):
yes
Luca Toldo (Mar 22 2019 at 08:54):
According to the specification, code is not compulsory (0..1). What is the expected the behavior of the $lookup in that case ?
Are there tests available to validate the proper behavior of $lookup ?
Michael Lawley (Mar 22 2019 at 13:01):
@Luca Toldo the optionality is so you can provide a code (and system) or a coding
Luca Toldo (Mar 22 2019 at 13:06):
Thankyou @Michael Lawley ! so if I understand correctly
either
a) A code and system
or
b) a coding
must be provided
right ?
Michael Lawley (Mar 22 2019 at 13:09):
Yes. It's there in the text:
When invoking this operation, a client SHALL provide both a system and a code, either using the system+code parameters, or in the coding parameter. Other parameters are optional.
Michael Lawley (Mar 22 2019 at 13:12):
I'd never noticed that [base]/CodeSystem/[id]/$lookup wasn't defined!
I guess this is some kind of hang-over from when it was defined on ValueSet, because CodeSystem instances didn't exist.
Grahame Grieve (Mar 22 2019 at 21:12):
I think that's an oversight. I was certainly surprised when I read that. But I see my server doesn't support it
Michael Lawley (Mar 22 2019 at 23:10):
Neither does ours; looks like a HAPI limitation - @James Agnew
James Agnew (Mar 24 2019 at 21:02):
I mean, yeah.. HAPI was written to implement the operation as its defined in the spec. :)
Peter Jordan (Mar 24 2019 at 22:20):
My Server insists on the system/codeSystem uri input parameter being completed for all operation requests on the CodeSystem resource., regardless of whether an id is passed. That's my own limitation! However, it does support the /[id]/ syntax for the other terminology resources.
Yunwei Wang (Mar 25 2019 at 16:16):
Since the code/system or coding already provide system url, I don't know why there's need for codesystem/id/$lookup?
Michael Lawley (Mar 26 2019 at 00:14):
No actual need, but neither is there one for /ValuseSet/[id]/$expand. However, it would be slightly faster as resolving the system -> Resource (search) naturally takes longer than simply using a lookup for id -> Resource.
Grahame Grieve (Mar 26 2019 at 00:17):
I think the value set expand has a quite different functional reason to call it, as compared to code system expand. But I don’t see any harm in allowing the code system lookup to explicitly identify an id- it would function as a check on the system as well as the system/code combo
Lloyd McKenzie (Mar 26 2019 at 00:47):
Would CodeSystem/$expand take into account available supplements?
Grahame Grieve (Mar 26 2019 at 01:22):
Open discussion.
Peter Jordan (Mar 26 2019 at 01:57):
...so the debate is moving from ValueSet/$lookup to CodeSystem/$expand as a suggested mechanism for requesting multiple properties about a group of concepts?
Jim Steel (Mar 26 2019 at 01:58):
It is?? That certainly wasn't anything like the original question (at least as I read it)
Peter Jordan (Mar 26 2019 at 02:23):
I was merely posing the question, based on some of the above posts, but can see some advantages in doing it that way.
Yunwei Wang (Mar 26 2019 at 13:04):
@Grahame Grieve If allowing id in URL and both id and sysystem URI (in parameter) were provided, which one should take higher priority? For example, id points to SCT and coding.system is LOINC.
Yunwei Wang (Mar 26 2019 at 13:07):
Checking ValueSet.$expand, I noticed that the same was not clarified between valueset/id and url parameter. Is that up to the implementer to decide? My implementation is that if there's id, use id. Otherwise, check url.
Grahame Grieve (Mar 26 2019 at 20:37):
I do the same for ValueSet/$expand.
Grahame Grieve (Mar 26 2019 at 20:37):
for $lookup - I would say that neither has priority; they both must agree
Michael Lawley (Mar 26 2019 at 20:41):
[I thought that was a typo above from @Grahame Grieve when he said "code system expand" and that he actually meant "code system lookup"?]
Grahame Grieve (Mar 26 2019 at 20:56):
y i did
Last updated: Apr 12 2022 at 19:14 UTC
