Stream: implementers
Topic: How to bind multiple ValueSets
Ardon Toonstra (Jan 05 2021 at 15:48):
What's the best practice for binding multiple ValueSets?
- Create a ValueSet that includes the multiple ValueSets
- Slice the element or the Coding element and bind a ValueSet to each slice
- Other?
Pro cons?
Lloyd McKenzie (Jan 05 2021 at 15:51):
The former sets an expectation for one code from any of the sets. It's problematic if codes from the referenced value sets have overlapping meaning. The latter allows you to set expectation for inclusion of multiple codes - and different expectations via both cardinality and binding strength for the inclusion, though things get messy if the binding strengths aren't all 'required' because a code that doesn't fall into any of the value sets will potentially match against all slices with 'extensible' bindings.
Ardon Toonstra (Jan 05 2021 at 16:38):
Thanks Lloyd. That helps. I am however wondering why it is problematic if codes from the reference value sets have overlapping meaning.
Lloyd McKenzie (Jan 05 2021 at 16:44):
It results in inconsistent data. If there are two different codes that mean the same thing and both are allowed, then software needs to check for both codes when looking for a particular meaning
Grahame Grieve (Jan 05 2021 at 21:04):
why are there multiple value sets? What's the purpose?
Yunwei Wang (Jan 06 2021 at 02:20):
I did it in once. The underlying terminology server does not support creating valueset from different code systems directly. So if I want to say include these three codes from SCT and those five codes from LONIC, I have to create three value sets, one for SCT and one for LONIC, and then the 3rd value set to include codes from those two value sets for binding.
Gay Dolin (Jan 06 2021 at 15:36):
The multiple value sets (contained value sets being from different code systems) are grouped into one value set. MANY value sets in VSAC are like this (aka "Grouping). When from different code systems it doesn't matter if terms have overlapping meaning - in fact they will. However, there should be no need to create and bind to different value sets from the SAME code system that are appropriate for the bound context - it would not make sense. Also, this thread should be in the Terminology stream.
Lloyd McKenzie (Jan 06 2021 at 17:26):
I agree it happens. (i.e. multiple codes in a value set with the same/overlapping meaning) However, it's something to avoid as much as you can
Gay Dolin (Jan 06 2021 at 17:50):
Example of perfectly OK: a Diabetes type 2 problem value set with SNOMED disorder codes in one subset, and ICD10 CM in the other "fused" into a grouping value set . Perfection is the enemy of the good and we need to support clinicians and the implemented vocabularies and the terms the clinician select. I disagree it should be avoided.
Gay Dolin (Jan 06 2021 at 17:52):
And as you know both terms could be sent
Lloyd McKenzie (Jan 06 2021 at 18:26):
Sure. But you do that because of a need to support multiple stakeholders or legacy data, not because you really want diabetes to be coded two different ways. "Avoid if you can" isn't an absolute, but it means to be aware of the costs.
Vassil Peytchev (Jan 06 2021 at 19:07):
Is creating a combined value set the only option? Can slicing be used to indicate, for example, that either a SNOMED code from a SNOMED value set, or an ICD code from an ICD value set, or both can be sent in the CodeableConcept? And also require that if both are sent, they follow a ConceptMap?
Gay Dolin (Jan 06 2021 at 19:10):
@Robert McClure , @Carol Macumber @Rob Hausam @Ted Klein --- FYI this discussion (which should be in vocab)
Yunwei Wang (Jan 06 2021 at 19:49):
@Vassil Peytchev That has been answered above by Lloyd (2nd post in this thread).
Vassil Peytchev (Jan 06 2021 at 19:52):
Ah, yes, that was part of the original question. I was responding on @Gay Dolin 's comment that combining value sets with overlapping codes (in her example) should not be avoided.
Michael Lawley (Jan 06 2021 at 22:44):
It really depends on the use-cases for the ValueSet. If it's to bind a field for data entry, then you don't want codes with overlapping meaning (esp. you don't want to mix clinical codes with classification codes), but if it's for retrieval / validation / the range of a conceptmap, etc then it may be exactly the right thing.
Michael Lawley (Jan 06 2021 at 22:45):
Hence @Grahame Grieve 's question above - what is the purpose in this case?
Richard Townley-O'Neill (Jan 11 2021 at 05:48):
So another option would be to use a compound value set for validation and provide written implementation guidance on the different component value sets.
Ardon Toonstra (Jan 11 2021 at 09:50):
Thanks all for the discussion. For now, I will continue here although I noted that it should be transferred to another stream. Can we copy the whole thread?
To give a bit more background information regarding my initial question. We are modelling Dutch Health Care information models to FHIR. Some models concern similar concepts as FHIR resources, for example, the hcim-Procedure. To classify a procedure 5 different code systems can be used according to this model. They are represented as code lists / ValueSet as they can also contain a selection of a code system. Different Healthcare domains will likely use different code systems. Within one domain/use case, a single code system should be sufficient is the general idea.
So we are wondering how we could best represent these information models in FHIR while we take into account that derived profiles can be created to specify the specific requirements of a healthcare domain/use case. Our current thinking it to bind one ValueSet that includes other needed ValueSets.
Thomas Tveit Rosenlund (Jan 12 2021 at 18:22):
I might have to do that as well @Ardon Toonstra The official validator does not like this profile: https://simplifier.net/hl7norwayno-basis/nobasisendpoint
Because we try to slice a non repeating element as a way to include codes from the norwegian specific Endpoint.connectionType CodeSystem.
A possible solution would be to instead bind the connectionType to a third ValueSet that includes both:
- EndpointConnectionType
- NoBasisConnectionType
That would probably validate.
Lloyd McKenzie (Jan 12 2021 at 18:43):
Slicing is only allowed right now if an element repeats or is polymorphic (and in the latter case, you can only slice by type)
Last updated: Apr 12 2022 at 19:14 UTC
