FHIR Chat · ValueSet.url · terminology

Stream: terminology

Topic: ValueSet.url


view this post on Zulip Peter Jordan (Oct 29 2019 at 08:35):

The R4 specification states that this is... ."also called its canonical identifier" and..." SHOULD be globally unique and SHOULD be a literal address at which an authoritative instance of this value set is (or will be published)."

I have some questions here in relation to a discussion at today's SNOMED International Business Meeting with regard to proposed urls for SNOMED International ValueSets (including the Global Patient Set and International Patient Summary)...

a. In this context should 'this value set' be strictly interpreted to mean only a FHIR ValueSet Resource?
b. Should this be url be resolvable - and in particular, if the MIME type in the request header is a FHIR one, should a FHIR ValueSet (definition) be returned?
c. If the answer to b. is 'yes' - should that URL be in the format [base]/ValueSet/[id]

view this post on Zulip Grahame Grieve (Oct 29 2019 at 09:14):

a. ummm as opposed to what?
b. yes - should. (not shall).
ba. if a mime type is a FHIR mime type, then it should return an error if it doesn't return the right mime type. (the hl7 site doesn't do that right for turtle, so we couldn't point fingers)
c. it would be good if it is, but that's not even a SHOULD

view this post on Zulip Grahame Grieve (Oct 29 2019 at 09:16):

Peter said the plan was to use the [base]/ValueSet/[id] pattern and to make sure the end point worked. I liked both of those (after accepting that was better than being consistent)

view this post on Zulip Peter Jordan (Oct 29 2019 at 09:22):

a...as opposed to a non-FHIR value set
My understanding of the plan was exactly the same, but different alternatives were discussed (and preferred) at today's meeting of the SNOMED Languages Group - principally (I think) because of their requirement to cater for non-FHIR value sets.

view this post on Zulip Michael Lawley (Oct 29 2019 at 09:35):

A specific context is the GPS - conceptually this is "a set of identified SCT concepts which have specific licensing terms" (my words). This the URI identifies this set of codes. A FHIR ValueSet is one representation, but it is not the thing itself.
Just as fhir+json fhir+xml etc are just different representations of the same real world resource (the Cool URIs page talks about this concept in good detail)

view this post on Zulip Michael Lawley (Oct 29 2019 at 09:37):

https://www.w3.org/TR/cooluris/#semweb

view this post on Zulip Peter Jordan (Oct 29 2019 at 09:55):

Agreed - but this does not address the specific issue of the uri that should be placed in the (canonical) url property of the FHIR ValueSet representation of that subset of SCT concepts.

view this post on Zulip Michael Lawley (Oct 29 2019 at 09:59):

http://snomed.info/valueSet/GPS was, I think, the conclusion of the discussion? I like this because it is syntactically distinct from the URL of a ValueSet resource instance in a server so that it's not mistaken as a URL (even though it is planned to be resolvable)

view this post on Zulip Peter Jordan (Oct 29 2019 at 10:13):

Are you proposing that the (canonical) url property of the FHIR ValueSet representation shouldn't be a URL?

view this post on Zulip Michael Lawley (Oct 29 2019 at 10:24):

I advocate that it shouldn't be a URL modelled after the FHIR API because developers will make unwarranted assumptions that they can and should resolve it. In essence I advocate a level of indirection between the ValueSet's URI and the location of its source of truth artefact. For big orgs like Snomed I think the cost is worth it. In other scenarios perhaps not.


Last updated: Apr 12 2022 at 19:14 UTC