Stream: terminology
Topic: GF#16490
Grahame Grieve (May 14 2018 at 20:52):
GF#16490 again raises the subject of ExpansionProfile.fixedVersion.versionOverride
Grahame Grieve (May 14 2018 at 20:53):
I discussed this with @Rob Hausam tonight. It's not a new subject: the requirement to do this is real, and arises over time due to version rot. But that doesn't mean that we like it, or it isn't dangerous. It is both of those things.
Grahame Grieve (May 14 2018 at 20:54):
And I agree that we haven't widely considered the case in HL7, so it's not surprising that the Value Set Definition project hasn't considered this. I don't, however, agree that it should be removed from FHIR until that project addresses the topic.
Grahame Grieve (May 14 2018 at 20:57):
having said that, it's definitely troublesome. Rob and I came up with 4 different possible dispositions for this task; I describe these for dsicussion here in the hope that we can clarify the proposals, dispose the ones that are a waste of time, and save committee time.
Grahame Grieve (May 14 2018 at 20:57):
before describing the options, I should point out that this is trial use content, not normative track content. That makes a difference to how to dispose of the issue
Grahame Grieve (May 14 2018 at 20:58):
(1) - decide that the previous discussions of the committee should stand, that we don't like the case, but the warning comment is sufficient, and we will review it's standing after trial use when we have both implementation experience with it, and further consideration from the VSD project
Grahame Grieve (May 14 2018 at 20:59):
(2) decide that we'll leave it there, with an explicit note that our analysis of the case is not complete, and we are considering removing it after trial use, but we leave it defined during trial use to gather experience about it's use
Grahame Grieve (May 14 2018 at 21:00):
(3) remove it to an extension with an explanation similar to above
(3a) - leave it in the code system and make the binding extensible to a value set that doesn't include it (vocab extensibility)
(3b) define a FHIR extension for it (fhir extensibility)
Grahame Grieve (May 14 2018 at 21:04):
(4) (the radical option): remove ExpansionProfile altogether, and define a parameter format for specifying the fixed version for a code system, and then split the parameters we've defined into the primary common ones (including at least fixed version, language, activeOnly, excludeNotForUI) and also a bag of less common codes (including includeDesignations, includeDefinition, and other stuff out of ExpansionProfile).
Grahame Grieve (May 14 2018 at 21:05):
that last option ducks the issue; we just wouldn't define anything about overriding versions. note that operation parameters are even more extensible than anything else - implementers can just define whatever parameter they want
Grahame Grieve (May 14 2018 at 21:05):
@Carmela Couderc @Rob Hausam @Robert McClure @Ted Klein @Russ Hamm @Michael Lawley @Carol Macumber
Grahame Grieve (May 16 2018 at 08:07):
GET [base]/ValueSet/[id]/$expand?version=http://loinc.org|2.56
Grahame Grieve (May 16 2018 at 08:07):
GET [base]/ValueSet/[id]/$expand?force-version=http://loinc.org|2.56
Michael Lawley (May 16 2018 at 11:49):
And when there are two code systems you want to select the version for?
GET [base]/ValueSet/[id]/$expand?version=http://loinc.org|2.56&version=http://snomed.info/sct|http://snomed.info/sct/20621000087109/version/20180131
Grahame Grieve (May 16 2018 at 13:46):
y
Michael Lawley (May 17 2018 at 05:28):
I think we (Ontoserver) need to pre-adopt support for external selection of code system version specifically for the use-case of choosing a SNOMED CT Edition where the ValueSet hasn't specified anything. This would align with one of the modes default and check (I anticipate our check would also allow for sensible behaviour for SNOMED Edition-only versions, and probably also semantic versioning for other CodeSystems.)
I am currently favouring something based on option 4 with fixed-system taking a canonical; I dislike @Grahame Grieve 's examples of version and force-version because it ambiguously suggests that we're talking about the ValueSet version
I'm also more in favour of keeping the mode in a separate parameter: fixed-system-mode
Grahame Grieve (May 17 2018 at 07:20):
what's mode?
Grahame Grieve (May 17 2018 at 07:21):
oh - we can't keep it in a separate parameter. Consider this:
$expand?system-version=[uri]|[version]&system-version=[uri]|[version]&mode=override
Michael Lawley (May 17 2018 at 09:24):
I wondered about that. So you don't want it to override in both cases.
I presume there is a reason the version can't be fixed (updated) in the ValueSet definition itself? For example, is the use-case one of transient overriding?
Grahame Grieve (May 17 2018 at 09:32):
right. you don't have access to fix the underlying value set. Of course that would be a better thing to do
Michael Lawley (May 17 2018 at 11:25):
So that's a rare case (we hope). What about the default & check modes? I can see use cases for both but, the difference is subtle; hard to decide which would be best as system-version
Grahame Grieve (May 17 2018 at 16:31):
system-version & check-system-version, I guess?
Last updated: Apr 12 2022 at 19:14 UTC
