Stream: implementers
Topic: valueSetReference vs. valueSetUri
Chris Grenz (Jun 27 2016 at 20:35):
Need some remedial instruction here... it's my understanding that in elementdefinition.binding:
1. Using valueSetUri leads to resolution of the binding via the ValueSet.url field (GET [base]/ValueSet?url=XXX).
2. Using valueSetReference leads to resolution using a FHIR read. In the case of a relative URL, resolving locally. In the case of an absolute URL, resolving by whatever means/policy the server has defined.
Since:
a. Most servers will make some kind of local copy of the FHIR standard valuesets for performance and security.
b. Reference absolute URLs don't actually resolve (http://hl7.org/fhir/vs/use-context).
c. Canonical URLs exist, are stored, and are searchable.
Why don't the standard profiles use valueSetUri rather than valueSetReference? In fact, why would *any* system not just use the canonical URL for conformance resources?
Grahame Grieve (Jun 27 2016 at 20:41):
canonical URLs in the FHIR specfication resolve. The correct URL is http://hl7.org/fhir/ValueSet/use-context. The only time they don't resolve is when they are defined in the current build, and not yet published
Chris Grenz (Jun 27 2016 at 20:42):
Why not just use the canonical URLs?
Grahame Grieve (Jun 27 2016 at 20:42):
the important difference between valueSetUri and valueSetReference is that valueSetReference is defined to be an explicit reference to a value set resource, but valueSetUri may be a reference to something that is not an explicit value set
Grahame Grieve (Jun 27 2016 at 20:43):
I use canonical URLs in valueSetReference
Chris Grenz (Jun 27 2016 at 20:43):
Seems to be forcing some gymnastics when storing these locally - I have to do absolute <-> local conversion of the URLs using the same resource id to resolve locally....
Chris Grenz (Jun 27 2016 at 20:44):
or implement some kind of alternate cache with the original URL intact.
Chris Grenz (Jun 27 2016 at 20:45):
It's taboo to search ValueSet.url to resolve valueSetReference, yes?
Chris Grenz (Jun 27 2016 at 20:46):
And a valueSetUri binding *should* try to resolve via ValueSet.url, yes?
Erich Schulz (Jun 27 2016 at 22:41):
@Grahame Grieve is there any doco/examples on how CQL should play with these notions?
Bryn Rhodes (Jun 27 2016 at 22:46):
@Erich Schulz CQL provides declarations that allow you to reference value sets, but it is silent about how those identifiers resolve underneath. When using FHIR, the recommendation is to use the URI as the identifier for the value set (so valueSetUri in this context). That may resolve to an actual value set reference on your FHIR server, or it may just be a value set identifier that is passed to a terminology server. Or it may be mapped to an OID, or...
Erich Schulz (Jun 27 2016 at 23:37):
thanks @Bryn Rhodes - this is bit of a key issue... a small remnant of the curly brace problem - is it being discussed anywhere?
Erich Schulz (Jun 27 2016 at 23:41):
I guess I specifically trying to figure out how to express notions such "has this code or any subtypes of this code"
Grahame Grieve (Jun 27 2016 at 23:54):
Chris - I treat my local value set copies as a cache and look there for the value set reference by URL first before falling back to looking at the actual literal URL. I haven't found that forced, but perhaps I never thought of any other approach
Grahame Grieve (Jun 27 2016 at 23:55):
it's not taboo to search by URL. but I don't try to do that for ValueSet.uri
Bryn Rhodes (Jun 28 2016 at 00:24):
@Erich Schulz yes, terminology references are an active topic in the various CQF forums. Basically, CQL supports valueset and codesystem membership with the _in_ operator. But we purposely excluded subsumption from the spec (too much possibility for variation of interpretation), but there's nothing that says you couldn't define a subsumption function for use in a particular context. And if you feel it's a necessity, submit a DSTU comment :)
Grahame Grieve (Jun 28 2016 at 00:25):
is there any reason why CQL shouldn't assume the existence of the FHIR terminology service, and map to it's operations directly?
Erich Schulz (Jun 28 2016 at 00:27):
this could work @Grahame Grieve - the goal is to enable authors of "shareable knowledge artifacts" to express knowledge and clinical logic in a standard, transparent manner
Bryn Rhodes (Jun 28 2016 at 00:27):
I'm working on that right now actually. It effectively does assume the existence of a terminology service (or equivalent functionality), the spec just considers that an implementation issue and doesn't specify any particular interface.
Erich Schulz (Jun 28 2016 at 00:27):
that would work internationally and allow easy peer review and validation
Grahame Grieve (Jun 28 2016 at 00:27):
I think that it should specify the FHIR terminology service, and bind to it. I believe that will work in the CDA context too
Bryn Rhodes (Jun 28 2016 at 00:27):
I'm working on an implementation-level interface that would support the terminology operations as exposed by FHIR.
Bryn Rhodes (Jun 28 2016 at 00:29):
And then a plugin that can call any FHIR terminology service with that interface.
Erich Schulz (Jun 28 2016 at 00:29):
i think it should simply refernece the snomed code...
Erich Schulz (Jun 28 2016 at 00:29):
that is the international standard right?
Erich Schulz (Jun 28 2016 at 00:30):
whatever server is providing the subsumption service should be immaterial?? right?
Erich Schulz (Jun 28 2016 at 00:30):
(or ICD or LOINC code as needed)
Bryn Rhodes (Jun 28 2016 at 00:30):
Well, it wouldn't reference any particular terminology, just the concept of a terminology service.
Bryn Rhodes (Jun 28 2016 at 00:30):
Right.
Grahame Grieve (Jun 28 2016 at 00:32):
which server is providing the service should be immaterial, but the spec it's conforming to is very relevant
Erich Schulz (Jun 28 2016 at 00:45):
sorry - i'm possibly missing some basic stuff...
Erich Schulz (Jun 28 2016 at 00:45):
(and on job so bit distracted, not unusually)
Erich Schulz (Jun 28 2016 at 00:46):
but how do specify a cql Retrieve which says "this code on one of its subtypes"
Erich Schulz (Jun 28 2016 at 00:47):
thankfully CQL takes care of all the more complex operations really really well
Erich Schulz (Jun 28 2016 at 00:48):
i'm just trying to join the dots... in a way that will be as simple and as standard as possible for CQL authors
Erich Schulz (Jun 28 2016 at 01:06):
so @Bryn Rhodes I think subsumption is critical
Erich Schulz (Jun 28 2016 at 01:06):
i'll submit a comment I guess
Erich Schulz (Jun 28 2016 at 01:08):
in meantime I'd be open for guidance on how this should be expressed in a standardish way
Michael Lawley (Jul 02 2016 at 04:30):
FWIW, I'm not comfortable resolving references outside the local server - could be anything at the end of that URL - it's a vector for using a FHIR server to launch a DDOS for example. @Grahame Grieve do you whitelist domains or url patterns for external references?
Grahame Grieve (Jul 02 2016 at 10:39):
I ignore them.
Grahame Grieve (Jul 02 2016 at 10:39):
on the public servers
John Moehrke (Jul 02 2016 at 16:21):
Michael, very useful obseravation for "Operational" specifications. Not something a core specification can do much about except to point out that operaional concerns must be addressed. I would entertain adding an additional note to the securty.html page about this URL concern . Can you create a GF tracker with your recommended wording?
David Hay (Jun 19 2017 at 21:57):
@Chris Grenz Reading through this thread it seemed to morph away from the topic! I have a similar question: When creating a binding to a custom ValueSet from a profile, is it best practice to use ValueSetReference or ValueSetUri?. I've taken the position that ValueSetUri is better as it supports registries exposing the lookup query that you describe (and assuming that the value is the canonical URL of the VS). It seems to me that using ValueSetReference means that the valueset must always be hosted at the indicated address as it's supposed to resolve.
But reading Grahames comment, it looks as if best practice is to use the canonical url as the value of ValueSetReference, and if it does not resolve, then look for it in a registry (like simplifier)
Does that make sense?
Lloyd McKenzie (Jun 19 2017 at 22:14):
ValueSetReference means that you expect the specified URL to resolve to a FHIR value set (either directly or by looking up the canonical URL in a registry). valueSetUri doesn't expect to resolve to a FHIR value set definition. At least that's my understanding of the difference.
David Hay (Jun 19 2017 at 22:41):
Ah - I didn't appreciate that the 'looking up in a registry' was an appropriate fallback if the reference didn't resolve as that's not how a normal resource reference works - does it?
Lloyd McKenzie (Jun 19 2017 at 23:02):
Process is a bit different for resources with canonical URLs.
David Hay (Jun 20 2017 at 00:06):
so any reference to a resource with a canonical URL (StructureDefinition, ValueSet, OperationDefinition etc operates in this way?
Grahame Grieve (Jun 20 2017 at 00:08):
in which respect?
Brian Postlethwaite (Jun 20 2017 at 00:13):
I always thought that the canonical URI was done via the Uri, and not the reference.
Grahame Grieve (Jun 20 2017 at 00:18):
in a binding?
Grahame Grieve (Jun 20 2017 at 00:18):
the canonical URL should be a reference not a URI
David Hay (Jun 20 2017 at 01:51):
The question was how to support a registry. I thought that a resource reference MUST resolve to a FHIR resource, so if you are binding a coded item to a ValueSet using binding.ValueSetReference, then the VS had to exist at that location (whether or not the URL is canonical) - if it wasn't found there, then the call would fail to retrieve the VS. That's why I've been using the binding.ValueSetUri - to indicate that the binding was to a canonical URI that could be retrieved from a registry - using a call like [host]/ValueSet?url=xx (as Chris said at the beginning of this thread)
Lloyd is suggesting that you can still use binding.ValueSetReference, but if the call doesn't resolve to a VS, then you can look in your friendly registry for a VS with that URL value and use that...
Grahame Grieve (Jun 20 2017 at 03:44):
yes Lloyd is right. If you look in the standard, we use a URL where it implies a value set - e.g. some of the IETF rfcs
Chris Grenz (Jun 21 2017 at 14:17):
So, again on the "remedial" theme ;) I could assume:
1. A binding with valueSetUri is not technically enforceable and will not be validated except perhaps via "special logic".
2. A binding with a relative URL will attempt to be resolved locally (or via a local/preferred terminology service) via a FHIR ReSTful GET. E.g.: GET http://my.fhir.server/ValueSet/ab123
3. A binding with an absolute URL "http://x.com/some/uri" will attempt resolution via:
a. Local/preferred terminology services via GET http://my.fhir.server/ValueSet?url=http://x.com/some/uri
b. Trusted registry services via GET http://my.trusted.repo/ValueSet?url=XX
c. If policy allows (probably not) by HTTP GET to the URL. GET http://x.com/some/uri
Yunwei Wang (Jun 23 2017 at 14:29):
@Chris Grenz In your use case, 3.a gets the actual valueset. But waht does 3.b return? I assume it returns a canonical URL for that valueset. Is that right?
Lloyd McKenzie (Jun 23 2017 at 18:12):
I would assume all would return the valueset
Chris Grenz (Jun 23 2017 at 20:17):
Yes. All return the valueset.
Last updated: Apr 12 2022 at 19:14 UTC
