Stream: smart
Topic: codes and systems
Josh Mandel (Sep 11 2020 at 16:37):
Yesterday we talked a bit about what it means to have a scope like patient/Observation.s?category=vital-signs -- does this mean a client can query for category codings with any system and a code of vital-signs, or can servers interpret that scope as, effectively, meaning patient/Observation.rs?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs? In other words, can a server "interpret a default", and if so, should this be communicated back to the client? Here are my thoughts...
Josh Mandel (Sep 11 2020 at 16:38):
- US Core specifically documents queries like
GET [base]/Observation?patient=[reference]&category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs
... which to me suggests we should be equally precise in most of our documentation. We shouldn't write vital-signs without a system as a shorthand to make things "look pretty".
Josh Mandel (Sep 11 2020 at 16:39):
- Since FHIR search supports queries like "get me all Observations where the category code is
vital-signs, regardless of system," our scope language should too -- but that doesn't mean we should encourage it.
Josh Mandel (Sep 11 2020 at 16:40):
- It's reasonable for a server to assume a default code, but this must be reflected back to to the client so the client can adjust its queries accordingly. In other words, the granted scopes should signal to a client "here are things I'll allow you to query for". So it'd be a mistake to tell the client that the scope
patient/Observation.s?category=vital-signswas granted, if in fact only the narrowerpatient/Observation.s?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signswas granted. Why? It's a mistake to tell the client the "shorter" scope because the server could reject a query forGET Observation?patient=[]&category=vital-signsas too broad, and the client would have no way to tell why.
Josh Mandel (Sep 11 2020 at 16:43):
- If a server does, in fact grant a fully-specified scope like
patient/Observation.s?category=http://terminology.hl7.org/CodeSystem/observation-category|vital-signs, then it should not allow a query like "GET Observation?patient=[]&category=http://some-other-system|vital-signs`.
* currently https://smart.argo.run violates this expectation :-)
Josh Mandel (Sep 11 2020 at 16:44):
I'd love to hear feedback from others on these points, either through thumbs up/down on the individual posts, or in discussion below :)
Gino Canessa (Sep 11 2020 at 16:53):
For 1., I'm less concerned about "pretty" than I am about scope size limits. Especially if including multiple codes from a system, this will get quite large quite fast.
Pascal Pfiffner (Sep 11 2020 at 16:57):
I think I agree with requiring system, but I also worry about size explosion.
Pascal Pfiffner (Sep 11 2020 at 16:58):
Since category/type based queries are mostly gonna be scoped to the preferred or required coding system, could we invent a shorthand for it?
Pascal Pfiffner (Sep 11 2020 at 17:00):
e.g. patient/Observation.s?category=__preferred|vital-signs
Josh Mandel (Sep 11 2020 at 17:00):
I'm all for suggestions about how to "have our cake and eat it too," but they get complex. In xml and the semantic web, the concept of a "curie" (compact URI) comes into play -- like, you can define prefixes. So we could say that oc: means http://terminology.hl7.org/CodeSystem/observation-category or whatever. This is different from assuming a default system, because it still allows the system to be blank.
Josh Mandel (Sep 11 2020 at 17:00):
Ooh, that's a neat trick Pascal.
Pascal Pfiffner (Sep 11 2020 at 17:01):
Could maybe even be shorter, like p, because p is clearly not a URL :yum:
Josh Mandel (Sep 11 2020 at 17:02):
Yup. Though __ and p are both apparently FHIR uris in the limited sense that they pass Regex: \S* :p
Pascal Pfiffner (Sep 11 2020 at 17:03):
Ah darn I never actually looked at that. But wow :grinning_face_with_smiling_eyes:
Josh Mandel (Sep 11 2020 at 17:04):
So assuming we have a "ccurie" (to coin a term: contextual compact URI) like _ or whatever, we trade off a bit of processing complexity for some bytes in our scope expressions.
Do we agree that none of this comes into play at query time, like I can't ask for "GET Observation?category=_|vital-signs" ?
Josh Mandel (Sep 11 2020 at 17:05):
(I kinda like _ here, as the "throwaway variable" used in programming languages like swift, rust, etc. And you can't get shorter while still being explicit.)
Pascal Pfiffner (Sep 11 2020 at 17:17):
ccurie ™ it is!
So would it be _:vital_signs to align with curie or _|vital_signs for underscore to just mean the preferred or required system?
I think I'd like to also be able to query this way, but that would be a separate balloting question, I don't think we _have_ to be able to.
Josh Mandel (Sep 11 2020 at 17:17):
I was thinking just _|vital-signs in the scopes to align with FHIR query conventions
Pascal Pfiffner (Sep 11 2020 at 17:18):
Yeah I like that too, but your query example above uses _:
Josh Mandel (Sep 11 2020 at 17:18):
Fixed now! Thanks.
Pascal Pfiffner (Sep 11 2020 at 17:18):
Ha, great, works for me!
Josh Mandel (Sep 11 2020 at 17:19):
(Now that takes us to the discussion about.... how do you know what's preferred? How does a server publish its contextual bindings? Does this mechanism only apply for value set bindings in the FHIR core spec, or can it be used in IG-specific ways? etc.)
Pascal Pfiffner (Sep 11 2020 at 17:21):
Yeah good point. Obviously the easiest would be to just have it apply to preferred/required bindings in the core spec and disallow it for others, but this warrants discussion.
Last updated: Apr 12 2022 at 19:14 UTC
