Changing a ValueSet in a profile

I learned something today.

Actually, most days I do learn something (and occasionally remember it later on) but this one is worth recording here.

One of the actions that is commonly done when profiling a resource is to change the binding of a coded element to some other ValueSet than the one in the spec. For example, in the UK CareConnect profiles, the Patient.gender element is bound to a different ValueSet.

In the StructureDefinition resource that defines the profile, this done by changing the binding – here’s the entry in the StructureDefinition (actually a child ElementDefinition) where this can be done:

Note that there are 2 ways to do this – either the valueSetUri element or a valueSetReference. In the past, I’ve assumed that the valueSetReference (being a standard resource reference to a FHIR resource) required that the ValueSet be present at the URI that is the value of the element, whereas the valueSetUri refers to the canonical URL for the ValueSet (the ValueSet.url element).

So I’ve always used the valueSetUri, as I believed that it supported a registry of ValueSets (as well as other conformance resources) – you can query the registry with a query like:

[host]/ValueSet?url={value)

But it turns out that that’s not quite right.

• valueSetUri is intended to be used when the profile is not pointing at an explicit ValueSet resource – perhaps a document like an RFC that describes the options.
• valueSetReference is intended to be used when the profile IS pointing to a ValueSet (or to an implicit ValueSet). It SHOULD resolve, but if it doesn’t then it’s perfectly permissible to look it up in a registry. This isn’t the way that ‘ordinary’ resource references work, but does for resources that have a canonical URL (like CodeSystem, ConceptMap and CodeSystem), and is intended to specifically support saving these resources in a separate registry (like Simplifier) if they can’t be directly resolved.

So there you are. If you are using a ValueSet to define the options for a coded element (which is always a good idea) you should always use valueSetReference.

Now I need to go fix clinFHIR. Bother.

Addendum:

As I thought more about this, I realized that this behaviour is not that different to an ‘ordinary’ reference. The reference is saying “The resource can be found at this location” – in fact it’s saying “the most recent version of this resource can be found here”. Because the location is globally unique, there’s nothing stopping there a copy being somewhere else – indeed, that’s exactly what we do in a Bundle – especially a Document bundle’. And you can even be explicit about the version if you need to (as a copy may not be the most recent version of course).

So: not so different then.