Stream: implementers
Topic: Binding using valueSetUri
Richard Kavanagh (Jul 13 2018 at 13:49):
In STU3 you can bind elements using valueSetUri (as opposed to valueSetReference ). In R4 this is removed so that you can only use valueSetReference .
So for the use case where previously we "bound" to a URI such as http://acme.com/myCodesAreHere.html what do we do now. We seem to have two choices:
1) Not use a binding at all (after all http://acme.com/myCodesAreHere.html offers no computable benefit)
2) Craft a ValueSet to somehow use the URI
Option 1 is not desirable as we'd still like to know the URI, but not sure how to progress option 2
Have I missed something?
Vadim Peretokin (Jul 13 2018 at 13:58):
I don't think that ability was removed - it was just changed to a canonical
datatype. You can still use a URI as before
Vadim Peretokin (Jul 13 2018 at 14:00):
It's valueSetReference
that was, in a way, removed
Richard Kavanagh (Jul 13 2018 at 14:09):
hmm - reading http://build.fhir.org/references.html#canonical that does not appear to be the case
Lloyd McKenzie (Jul 13 2018 at 18:37):
In R4, we decided that the value sets always have to be FHIR value sets. It's the code system URI that might not resolve to a FHIR code system. The ability to point to a URL for a binding stems from before ValueSet and CodeSystem were split.
Richard Kavanagh (Jul 14 2018 at 07:40):
Thanks @Lloyd McKenzie so in my example would my CodeSystem have the following:
CodeSystem.valueSet = http://acme.com/myCodesAreHere.html
CodeSystem.concept = empty
Lloyd McKenzie (Jul 14 2018 at 09:22):
You wouldn't have a CodeSystem at all
Lloyd McKenzie (Jul 14 2018 at 09:22):
E.g. There's no CodeSystem for mime type
Lloyd McKenzie (Jul 14 2018 at 09:23):
The value set just points to the canonical URL
Richard Kavanagh (Jul 14 2018 at 09:25):
So a Canonical URL does not have to be for a FHIR resource it could be anything?
Lloyd McKenzie (Jul 14 2018 at 17:09):
Right. E.g. http://loinc.org or http://snomedct.info or urn:ietf:bcp:13
Last updated: Apr 12 2022 at 19:14 UTC