Skip to content

Including OTH in ValueSets #411

@pieter-edelman-nictiz

Description

@pieter-edelman-nictiz

Zib value sets mostly include the option OTH -- sometimes explicitly, but per a recent erratum at least implicitly, except in specific circumstances. It seems that simply including the zib ValueSet doesn't capture the actual intention of the zib and the representation in FHIR. Things to consider:

  • OTH is used to denote that none of the codes in the value set apply. This may be because the value is only available in unencoded form (although UNC would be a more specific match).
  • But it is not explicitly defined in all value sets and so not exported to the ValueSet resources in the package (which could be fixed).
  • For required bindings, this code needs to be present if the intention is to denote that none of the other codes in the ValueSet apply.
  • For extensible bindings however, the rule would actually work out somewhat different. The binding rules state that other codes may only be used if they don't overlap with a code from the value set, but OTH overlaps with all of them. Therefore, including OTH in an extensible bound ValueSet would theoretically prevent the use of any code not in the ValueSet.
  • By including OTH in each ValueSet, ValueSets overlap and slicing by ValueSet becomes problematic (TODO: figure out how problematic exactly).
  • FHIR datatype CodeableConcept has a built-in way to deal with the concept of "other", namely to use .text rather than a .coding. This actually provides more information than what the zib requires, because there's still a textual description. Including both OTH and a .text is redundant.
    • Using .text instead of a coded value in extensible value sets is in line with the zib guidelines.
    • This only works out for extensible bindings though, for required bindings OTH would still be needed.
    • It should be noted though that this mechanism can also be used for sending information for which the code is unknown rather than "something not defined in the list". This is clearly not the intention of the zibs.

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions