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:

Screen Shot 2017-06-20 at 7.37.36 pm

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.

 

About David Hay
I'm a Product Strategist at Orion Health, Chair emeritus of HL7 New Zealand and co-Chair of the FHIR Management Group. I have a keen interest in health IT, especially health interoperability with HL7 and the new FHIR standard.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: