Stream: implementers
Topic: Updating CodeSystems and intensional ValueSets
Thea Mentz Soerensen (Dec 21 2021 at 10:37):
Hi, we have a question which concerns updating ValueSets, CodeSystems and FHIR profiles.
@Anders Jensen @Ole Vilstrup @Jens Villadsen
We have created an IG which includes profiles with references to both extensional and intensional ValueSets. At the moment both profiles and ValueSets are in the same IG, but we intend to split this into two IGs – lets call them the ‘profile IG’ and ‘ValueSets’/’CodeSystem’, and lets say the split is done.
Extensional: We want the extensional ValueSets to be almost static and rarely change version. If an extensional ValueSets is updated, it should reflect as an update in the version of the profile IG.
Intensional: We want the intensional ValueSets to be dynamic and it may change as often as the clinical world demands it to. Most of these changes will be ‘minor’ changes, like addition of a new beta blocker’s code like in the HL7-site example. Codes in the CodeSystem holding the intensional value set may have an activation date or a retirement date.
So… to the questions:
1) How would you handle the versioning of the CodeSystem that holds codes used in the intensional ValueSet and these codes may have an activation or a retirement date?
a. Is it possible to avoid updating the version of a CodeSystem when a code is eg. retired?
b. Is it an advantage to have a separate IG for the CodeSystem?
2) How would you handle versioning of the intensional ValueSet which include codes that may have an activation or a retirement date?
3) We are not interested in changes in the ValueSet and CodeSystem entails a new version in the profile IG. Is it ‘allowed’ to update the version of a CodeSystem or ValueSet, without updating the version of the profile IG which uses the ValueSet?
We are quite uncertain about what is best practice in this area, so we are very interested in your point of views.
Please reach out, if you need further explanation.
Jens Villadsen (Dec 21 2021 at 10:39):
@Michael Lawley your comments would be very much appreciated ;)
Jens Villadsen (Dec 21 2021 at 10:55):
@Thea Mentz Soerensen if I understand you correctly you would also like to add codes to the CodeSystem over time without changing the IG or the version of the CodeSystem, right?
Thea Mentz Soerensen (Dec 21 2021 at 11:00):
@Jens Villadsen Yes, that correct.
Grahame Grieve (Dec 21 2021 at 12:13):
it would be a super bad idea to add codes to the code system without changing the code system version, and the definitions are quite clear about this:
Grahame Grieve (Dec 21 2021 at 12:16):
.. no, not in FHIR. @Rob Hausam the language I'm thinking of it is in core principles? Somewhere? Any change to the meaning of the code system - the codes and their properties - requires a new version
Grahame Grieve (Dec 21 2021 at 12:16):
anyway, this is true in practice, since otherwise you can't know which version you're talking about it. is something valid or not? No one can know....
Jens Villadsen (Dec 21 2021 at 12:22):
Grahame Grieve said:
it would be a super bad idea to add codes to the code system without changing the code system version, and the definitions are quite clear about this:
I had the feeling that you would answer that. So how is this handled in the best way possible - having an IG with a profile with a binding to a valueset that is defined as intensional to a CodeSystem that may or may not be bound to the same IG.
Rob Hausam (Dec 21 2021 at 13:51):
@Thea Mentz Soerensen @Jens Villadsen I think this is actually straightforward and common practice and shouldn't be a problem. You create an intensionally-defined value set (defined in the IG, or defined elsewhere and referenced in the IG) based on the external code system of interest (e.g., SNOMED CT, or other) without specifying a code system version in the value set definition (ValueSet.compose). Then, as the code system itself is updated (with a new version identifier for each update) the contents of the value set that is used by the IG implementations (the value set expansion) will follow and track with the code system updates and you will have the content that you expect and need. I think that gives you exactly what you are asking for.
Jens Villadsen (Dec 21 2021 at 13:55):
And where is the Codesystem then defined?
Rob Hausam (Dec 21 2021 at 13:59):
It depends on the code system. Is it externally defined (e.g., SNOMED CT, ICD, LOINC, etc.), or defined in HL7 and included in THO (or in one of the HL7 product families - V2, V3/CDA or FHIR), or defined locally in your IG?
Jens Villadsen (Dec 21 2021 at 14:01):
The point is that the IG itself should not be updated because new codes gets added to the Codesystem
Jens Villadsen (Dec 21 2021 at 14:04):
Because the Codesystem may need updates frequently
Jens Villadsen (Dec 21 2021 at 14:05):
So the Codesystem will be externally defined
Rob Hausam (Dec 21 2021 at 14:06):
The IG doesn't need to be updated - unless the code system is defined in the IG. That's a good reason to use an external code system, or use or define an HL7 code system that is (or will be) published in THO.
Jens Villadsen (Dec 21 2021 at 14:07):
And there is no issue in defining the Codesystem in another IG, in FHIR
Jens Villadsen (Dec 21 2021 at 14:09):
The IG with the valuesets cannot then declare a dependency to that IG I guess as that requires an explicit version
Jens Villadsen (Dec 21 2021 at 14:10):
So the reference from the valueset to the externally defined Codesystem will be purely logical, right?
Rob Hausam (Dec 21 2021 at 14:15):
I don't know about "purely". :) The reference is via the code system canonical url. But you probably have to (or at least want to) be able to access the actual code system contents in the IG publishing process or in your iG implementations, so the code system will need terminology server support.
Oliver Egger (Dec 21 2021 at 14:27):
Jens Villadsen said:
The IG with the valuesets cannot then declare a dependency to that IG I guess as that requires an explicit version
you can depend on patched versions, see npm, we use this approach for our ch-core ig which depends on external CodeSystem/ValueSet which have maybe add translations or spelling corrections in between the ch-core releases.
Oliver Egger (Dec 21 2021 at 14:29):
so ch-core has a dependency of 2.0.x to ch-epr-term, source
Jens Villadsen (Dec 21 2021 at 15:46):
@Oliver Egger aint that a very liberal interpretation of how to use patch versions?
Jens Villadsen (Dec 21 2021 at 15:49):
@Rob Hausam the Codesystem will be available in a term server for systems implementing the IG
Jens Villadsen (Dec 21 2021 at 18:23):
@Oliver Egger do you then also apply any patches to feature versions that are ahead of your patch versions? Do you then 'frontport' all changes?
Jens Villadsen (Dec 21 2021 at 18:25):
@Thea Mentz Soerensen I think we have enough input to proceed then :smile:
Oliver Egger (Dec 21 2021 at 18:55):
Jens Villadsen said:
Oliver Egger do you then also apply any patches to feature versions that are ahead of your patch versions? Do you then 'frontport' all changes?
i would say, but i'm not 100% sure if i understand the consequences ...
Grahame Grieve (Dec 21 2021 at 18:57):
The point is that the IG itself should not be updated because new codes gets added to the Codesystem
so this is an issue with the publication process - you cannot declare a dependency without declaring a version specific dependency. And so far, code systems have been either publicly available or explicitly defined.
So while it's totally unreasonable to issue new versions of a code system without versioning the code system, it's totally reasonable to update a code system without reissuing a set of IGs.
Grahame Grieve (Dec 21 2021 at 18:59):
however: ImplementationGuide.dependsOn.version is optional. So you can define a non-versioned dependency. I don't think my tools handle it very well, but I haven't really tested it
Jens Villadsen (Dec 21 2021 at 19:00):
@Oliver Egger Consequences of missing a patch in a future minor revision would mean that you actually remove content which would violate the rules of semantic versioning
Grahame Grieve (Dec 21 2021 at 19:00):
nor do we really handle well referring to a code system without referring to an IG, but still declaring where the code system is, which is another way to deal with this.
Jens Villadsen (Dec 21 2021 at 19:01):
Grahame Grieve said:
nor do we really handle well referring to a code system without referring to an IG, but still declaring where the code system is, which is another way to deal with this.
That is probably how we can proceed to start with
Grahame Grieve (Dec 21 2021 at 19:02):
we have an extension for authoritative source of a value set, but not for authoritative source of a code system - and it would not be declared in the code system anyway, but in... the IG, I guess
Jens Villadsen (Dec 21 2021 at 19:03):
It cannot be the first time such a challenge arises, right?
Grahame Grieve (Dec 21 2021 at 19:05):
the extension would be a triple, I guess: the canonical URL, along with a reference to a human readable URL and an end-point that services it.
But actually, we totally have a way to do this: include a CodeSystem resource that declares the CodeSystem, but contains no content, and declares that the content may be found somewhere else. I know my toosl don't handle that scenario - either publication or validation, but they should.
Grahame Grieve (Dec 21 2021 at 19:05):
It cannot be the first time such a challenge arises, right?
it is, yes, because up to now we have just assumed that external code systems are explicit a la Snomed and LOINC
Jens Villadsen (Dec 21 2021 at 19:07):
Okay - well ... yeah ... I've seen that approach before yes, defining an more or less empty codesystem. That would also do the job, yes
Grahame Grieve (Dec 21 2021 at 19:07):
well, only if you explicitly declared that this is what was going on
Grahame Grieve (Dec 21 2021 at 19:07):
and the tools don't know any way to declare that.
Jens Villadsen (Dec 21 2021 at 19:17):
Grahame Grieve said:
It cannot be the first time such a challenge arises, right?
it is, yes, because up to now we have just assumed that external code systems are explicit a la Snomed and LOINC
Noone else have requested/stated the use of external code systems before?
Jens Villadsen (Dec 21 2021 at 19:17):
and whats so special about SNOMED and LOINC in terms of being external?
Grahame Grieve (Dec 21 2021 at 20:32):
we assume that they are well known. We have not explored the space of 'code systems that are not assumed to be well-known but are external' before to my knowledge
Elliot Silver (Dec 21 2021 at 21:58):
Grahame Grieve said:
we assume that they are well known. We have not explored the space of 'code systems that are not assumed to be well-known but are external' before to my knowledge
By "but are external" you mean, external to the IG, right, not external to HL7? I'm surprised this isn't already an issue, as jurisdictions are building out local IGs that need to cross-reference content.
Richard Townley-O'Neill (Dec 22 2021 at 01:15):
AU Base 2 on FHIR R4 uses value sets and code systems that are defined in core, in the IG, and elsewhere.
An example of the last is in Australian Indigenous Status extension which is bound to the value set Australian Indigenous Status value set. That national value set is not maintained by HL7 Australia.
The Validator does not currently validate against it, so it raises warnings, which are suppressed in the qa report e.g.
The valueSet reference https://healthterminologies.gov.au/fhir/ValueSet/australian-indigenous-status-1 on element Extension.value[x] could not be resolved (8 uses)
The Australian Indigenous Status value set has been updated to version 1.0.2 without forcing a change the the extension.
Grahame Grieve (Dec 22 2021 at 07:05):
By "but are external" you mean, external to the IG, right, not external to HL7? I'm surprised this isn't already an issue, as jurisdictions are building out local IGs that need to cross-reference content
not sure what you mean 'external to HL7'. but Richard's case is an illustration that things have been worked around rather than coming up, perhaps
Last updated: Apr 12 2022 at 19:14 UTC
