FHIR Chat · Defining a ValueSet including all versions of a CodeSystem · terminology

Stream: terminology

Topic: Defining a ValueSet including all versions of a CodeSystem

Simone Heckmann (Jul 28 2017 at 21:23):

How do I define a ValueSet that allows all codes from all versions of a CodeSystem, e.g.
if I have multiple versions of ICD-10 and thus multiple CodeSystem resources with the same url=http://hl7.org/fhir/sid/icd-10-de but different versions ("2017", "2016" etc) .
The proper Version always depends on context (like encounter admission date), so when profiling, I don't want to bind to any particular version of the catalogue, just to icd-10 in general.

How do I define a valueSet that includes all ICD-10 Codes regardless of version? Do I need to include all versions explicitly , like

    <compose>
        <include>
            <system value="http://hl7.org/fhir/sid/icd-10-de" />
            <version value = "2017"/>
        </include>
        <include>
            <system value="http://hl7.org/fhir/sid/icd-10-de" />
            <version value = "2016"/>
        </include>
        <include>
            <system value="http://hl7.org/fhir/sid/icd-10-de" />
            <version value = "2015"/>
        </include>
        ...
    </compose>

or do I just omit the version altogether and the tx server will automagically expand the valueset to include all versions?

Grahame Grieve (Jul 28 2017 at 22:36):

well, not quite the same - omitting the version defers the choice of version to the terminology server

Grahame Grieve (Jul 28 2017 at 22:37):

we haven't discussed evaluating outcomes across more than one version. why is that a good idea?

Lloyd McKenzie (Jul 29 2017 at 19:14):

Selecting multiple versions can mean you have concepts that overlap in ways that weren't intended by the organization maintaining the terminology. That said, being able to validate across all versions will be a common requirement.

Simone Heckmann (Aug 03 2017 at 16:46):

There's not necessarily an overlap, since you can set the CodeSystem to versionNeeded=true, then all instances of the codes must carry a version.
But as LLoyd said, in Profiles we don't want to allow only one version, as they can change from time to time and the validation will never be able to evaluate the rules to decide which version applies (e.g. correct version of ICD-10 catalogue in a Condition is determined by the admission date of the Encouter it references - that's beyond the scope of what validation can do.
But we need profiles to be able to make ICD-10 mandatory.

And right now I'm stuck figuring out how to define the ValueSet for the terminology binding that says "any ICD-10 code is valid, as long as it's a valid code in the version of the catalogue it claims to be from".

Grahame Grieve (Aug 03 2017 at 21:17):

"correct version of ICD-10 catalogue in a Condition is determined by the admission date of the Encouter it references - that's beyond the scope of what validation can do." - sounds pretty easy to do this in an invariant

Grahame Grieve (Aug 03 2017 at 21:17):

"any ICD-10 code is valid, as long as it's a valid code in the version of the catalogue it claims to be from". - also could be done in an invariant, or in a value set that simply imports all versions of ICD-10

Simone Heckmann (Aug 04 2017 at 09:56):

"...or in a value set that simply imports all versions of ICD-10"
That's exactly what I'm trying to do. But the question is: Do I explicitly have to explicitly include every single version of ICD-10 (Assuming that each of them is a CodeSystem Resource with the same canonical url but different versions) or is it enough to just include the canonical url and the TX server will "know" that all CodeSystems matching that url need to be included regardless of version.

Even if I validate the "correct" version of a code through an invariant checking the Encounter context at runtime, I'd still need a ValueSet with all versions for the Terminology binding...

Grahame Grieve (Aug 04 2017 at 10:11):

you need to list them all at the moment

Simone Heckmann (Aug 04 2017 at 10:23):

ok. Thanks! This is currently not clearly stated in the spec (unless I'm not seeing it).
This bullet point (sort of) suggests that an unversioned inclusion means "all of them":

If the system reference is not version specific and filters are present, then the contents of the value set are open and change over time as the underlying code systems are updated

http://build.fhir.org/valueset.html#compositions

Lloyd McKenzie (Aug 04 2017 at 15:28):

This seems like something that should have an easier convention. It's also problematic if you want to allow for future versions as you can't really reference those in advance and it would be challenging from a maintenance perspective to have to update the value set every time a new version comes out. We have a convention for referencing versions of [canonicalURL]|[businessVersion]. Would it make sense to use a convention of [canonicalUrl]|* if you wanted to include all versions? Obviously those who want a particular range of versions would need to enumerate, but this would cover a lot of use-cases.

Simone Heckmann (Aug 04 2017 at 15:44):

Yes, the necessity to permantently update the ValueSets when a new version comes out, is a concern. As for the syntax of the convention, I don't have a preference. Whatever suits the TX server implementers best...

Robert McClure (Aug 05 2017 at 00:17):

My perspective is

• Value set definition that does not LOCK any or all of the definition to a specifIc code system version, means to test conformance to that value set definition (version) you have to allow all valid code from any valid expansion.
• Binding semantics come next, if a binding is not STATIC, then to be conformant you need to test against the same thing as above. STATIC will only allow one expansion. I think that code system version should be the one valid when the IG was published
• unless the TS users requests conformance test against a specific code system version, you have to assume any version is ok.

Grahame Grieve (Aug 05 2017 at 21:38):

note that STATIC is not a think in FHIR. we delegate that decision to the value set

Grahame Grieve (Aug 05 2017 at 21:40):

Rob's perspective here is different to FHIR, in that we are specific that if neither value set or the expansion profile specifies the version of the code system, the server performing $expand chooses the version

Rob Hausam (Aug 06 2017 at 12:33):

Yes, and I think a significant point there is that in that case the server chooses THE version - it's not mandated (at least not currently), but in most cases it is probably going to be (and agruably should be) a single version and most likely that version of the code system will be the latest one that the server provides (which won't necessarily always or immediately be the latest version of the code system that is available from the code system publisher). I think that the "all versions" value set is a special case (and one that is potentially fraught with problems), and that, if used, it would be best if it was invoked explicity. In that regard, Lloyd's suggestion of of [canonicalUrl]|* is probably worth considering.

Michael Lawley (Nov 23 2017 at 02:12):

Would * be interpreted as "all versions" or as "all versions known to this terminology server"?

Michael Lawley (Nov 23 2017 at 02:16):

I'm also not sure I understand the original use-case. Surely ICD10-DE 2017 is a superset of ICD10-DE 2016? but just with some codes active status changed. I would expect that just this would be suitable?

   <compose>
        <include>
            <system value="http://hl7.org/fhir/sid/icd-10-de" />
        </include>
    </compose>

Last updated: Apr 12 2022 at 19:14 UTC