‘Extending’ a ValueSet in a profile

In the last post we talked about ValueSets and CodeSystems – and in particular how the ValueSet can be thought of as the set of possible values from one or more CodeSystems for a particular element in a given context.

As you know, the spec provides ValueSets and bindings for all coded elements, and a common need when profiling is likely to be to ‘extend’ the set of possible values – take the contents already in the ValueSet and add others. What’s the best pattern to do that?

This thought was triggered when reviewing the new CareConnect profiles from the UK. This is an initiative being driven by the interOpen project (disclaimer: I’m a vendor representative to the board) and they have published an initial set of profiles and API’s (technically an Implementation Guide) which will going for ballot shortly by HL7 UK.

Take a look at the profile for the Condition resource. What you can see is that the Condition.category field is bound to a new ValueSet which takes the current values from the spec and adds a few others: (They also tightening the binding from ‘example’ to ‘extensible’, which makes sense).

(Here’s a screenshot of what it looks like when viewed in clinFHIR)

The interesting thing is that all of the actual values in this ValueSet point to concepts from a new Code System with the Url https://fhir-test.hl7.org.uk/CareConnect-ConditionCategory-1.

Now, there’s nothing wrong with this approach – but it could be improved.

Here’s the contents of the ValueSet from the spec:

(Note that it’s STU-2). You can clearly see that the values from the codesystem in this set have been duplicated in the CareConnect one – and so are now in a new system.

Why is this undesirable? Well it’s just that it takes a little away from semantic interoperability. We now have 2 codes for the ‘symptom’ concept. One from http://hl7.org/fhir/ValueSet/condition-category and one from https://fhir.hl7.org.uk/CareConnect-ConditionCategory-1 – but they both mean the same thing. More work for the consumer.

A better approach would be to define the contents of the CareConnect ValueSet as follows:

• complaint      (http://hl7.org/fhir/ValueSet/condition-category)
• symptom        (http://hl7.org/fhir/ValueSet/condition-category)
• finding            (http://hl7.org/fhir/ValueSet/condition-category)
• diagnosis        (http://hl7.org/fhir/ValueSet/condition-category)
• need                 (https://fhir.hl7.org.uk/CareConnect-ConditionCategory-1)
• problem          (https://fhir.hl7.org.uk/CareConnect-ConditionCategory-1)

In this way, the 4 concepts that are in both ValueSets come from the same CodeSystem making it just that little bit easier for the consumers. (You could also argue that all of them should come from SNOMED – but I’m not going to go there!)

BTW – I’m not intending to criticize CareConnect – far from it! It’s great to see the sector coming together to do this work – with National buy-in – and to make the work publicly available for comment. These are issues that will arise very commonly by everyone involved in profiling FHIR and it’s great to be able to share the learnings and issues that arise with the FHIR community when doing so.

Indeed, one of the precepts for interOpen is to be – well – open, and this is a good example of that.