FHIR Chat · fhir_version valueset normative · terminology

Stream: terminology

Topic: fhir_version valueset normative

Brian Postlethwaite (Nov 03 2018 at 11:54):

(Cross posting from the committers)
Is this valueset/codesystem really going to be normative?
http://build.fhir.org/valueset-FHIR-version.html
I think it needs to be extensible, and obviously needs to be changed for publishing the final version.
And if the CapabilityStatement doesn't change, how can it be a required binding to exactly this valueset, and not extensible to add in the new versions as they are built?
I picked up the FHIR Version valueset change as its a required binding in http://hl7.org/fhir/2018Sep/capabilitystatement.html to an id value, but in the CI build its a code type, hence we generate an enumeration for it.
Is this as much of a problem as I think it is?

Brian Postlethwaite (Nov 03 2018 at 11:57):

The resource_type valueset/codesystem also has a similar issue, however there is a note on that stating that it will be regenerated from version to version.
(however it won't need to be updated for final publication or R4)

Brian Postlethwaite (Nov 03 2018 at 12:01):

@Lloyd McKenzie

Lloyd McKenzie (Nov 03 2018 at 14:37):

Answered on committers. In short, normative and required (not extensible) is correct. Required bindings can be extended by HL7 in new versions. The fhir_version code system is no different from gender, observation status or any other required binding in that sense.

Brian Postlethwaite (Nov 03 2018 at 19:57):

So normative valueset can change from version to version, and this one will change for every version (even connectathon inerin builds)

Brian Postlethwaite (Nov 03 2018 at 19:57):

I'll re-read the versioning rules page.

Robert McClure (Nov 04 2018 at 05:45):

Let's keep in mind that a required binding is a binding to a value set definition, not to an expansion. Restriction to a specific expansion would only occur is the binding was STATIC. So if the CLD is "all codes in code system x" and the code system gets a new version, the conformant expansion will change without any other thing being versioned even with a required binding.

Lloyd McKenzie (Nov 04 2018 at 15:16):

It's also a code data type - which means that for the purpose of code generation, it is a STATIC binding. the set of codes can't change except with a new release

Michael Lawley (Nov 06 2018 at 21:36):

There's something seriously wrong with this code system - the code 3.6.0 has the definition Current Development build but as soon as we get R4, this definition will be wrong

Grahame Grieve (Nov 06 2018 at 21:46):

this value set should have this extension added to it:

<extension url="http://hl7.org/fhir/StructureDefinition/valueset-special-status">
    <valueString value="This Value Set is normative - it is generated based on the information defined in this
     specification. The definition will remain fixed  across versions, but the actual contents
     will change from version to version"/>
  </extension>

Grahame Grieve (Nov 06 2018 at 21:46):

for me, that's a technical correction

Grahame Grieve (Nov 06 2018 at 21:47):

there's 4 other value sets like this

Brian Postlethwaite (Nov 06 2018 at 21:54):

Can that be a coding I stead of just string so my generator can pick it up without matching the description?

Grahame Grieve (Nov 06 2018 at 21:55):

I don't understand this question

Michael Lawley (Nov 06 2018 at 22:31):

My concern is that the "definition" of the codes in the underlying CodeSystem will change from version to version. This does not gel with the notion of concept permanence

Grahame Grieve (Nov 06 2018 at 23:15):

no that won't happen

Lloyd McKenzie (Nov 06 2018 at 23:37):

It can't happen for this one - but it could for other normative code systems -e.g. ones that list value sets. If the description/scope for a draft resource definition changes, then the "definition" of the code will absolutely change. The special status will have to draw attention to this

Michael Lawley (Nov 06 2018 at 23:40):

So the code "3.6.0" will forever have the definition "Current development build"?

Brian Postlethwaite (Nov 07 2018 at 00:47):

The value foreach build / snapshot changes is what I understand (now)

Brian Postlethwaite (Nov 07 2018 at 00:47):

So current keeps moving (there is now value current though)

Grahame Grieve (Nov 07 2018 at 00:55):

current keeps moving, but I will remove old current versions - e.g. 3.6.0 will disappear

Grahame Grieve (Nov 07 2018 at 00:56):

when I publish R4, it will have 4.0.0, and current will become 4.1.0

Michael Lawley (Nov 07 2018 at 01:00):

So, I am expecting the 4.0.0 version of the CodeSystem to have a code "4.0.0" with display = "4.0.0" and definition = something like "FHIR Release 4 (R4)", but I am not expecting that the 4.0.0 version of this CodeSystem will have the code "3.6.0" with a definition of "Current Development build", but rather another code like "4.1.0" with that "definition"
(um, I think this is as @Grahame Grieve just said).

My concern here is that the text being used to define the code is not defining because it is inherently relative to a point in time.

Grahame Grieve (Nov 07 2018 at 01:02):

this is only true for the current version, and it will always be removed.

Grahame Grieve (Nov 07 2018 at 01:03):

I suppose we could make the definition clear by changing the definition of the current build to "Current Development build - post Baltimore Meeting Sept 2018"

Michael Lawley (Nov 07 2018 at 01:09):

That would be better, yes. Is removal of the code 3.6.0 "correct", or should it be made inactive (or retired) instead? Should it currently be marked experimental?

Also, is there a reason that "4.0.0" is not already defined?

Grahame Grieve (Nov 07 2018 at 01:11):

doesn't exist yet. I do that sort of stuff in the run in to actually publishing R4, which will start in early December

Grahame Grieve (Nov 07 2018 at 07:52):

those old codes would be made retired if we kept them around. but why would we do that?

Grahame Grieve (Nov 07 2018 at 07:52):

this is not a clinically meaningful terminology

Lloyd McKenzie (Nov 07 2018 at 12:57):

No one should ever go into production with "current build" because it reflects content that changes many hundred times over the course of a release. There's no frozen snapshot of it and you'd have no hope of getting interoperability.

Robert McClure (Nov 07 2018 at 17:41):

@Grahame Grieve Oh boy do I strongly dislike the idea of embedding "current build" into the definition of a code when that idea will be moved from code to code over time. Remember the foundational premise of meaning permanence. Why is this needed?? Name the version meaning as you have done in all the other codes and identify which one is "current" some other way please! Seems to me it will always be the one with the largest semantic value? Or last one in the code system?

Lloyd McKenzie (Nov 07 2018 at 18:43):

It's needed because the code generators need it. When we're publishing the CI build, something must be present in the version element and it must be present in the value set. I guess in theory we could ditch semantic versioning for the CI build and just have a fixed code of "current", but I'm not sure if that would cause other issues.

Grahame Grieve (Nov 07 2018 at 19:34):

it'll never be in a release version of the code system. But just to make everyone happy, I will make the useless definition specific

Rob Hausam (Nov 07 2018 at 19:42):

Actually, I think we can do this by retiring the old "Current Development build" code (we shouldn't remove it) and creating a new one - so there will be only one code with the definition of "Current Development build" that is active at any point in time. As long as the '3.6.0' code, for example, isn't going to be used to indicate anything other than the current build during the period that it is active (which is what Grahame described), then I don't think this is a problem (and I don't think we have to make it "specific").

Grahame Grieve (Nov 07 2018 at 19:44):

Right. this is not about concept permanence at all

Michael Lawley (Nov 07 2018 at 22:43):

You've already ditched semantic versioning because 3.6.0 has breaking changes with respect to 3.x for x <= 5

Grahame Grieve (Nov 07 2018 at 23:27):

only for current build

Grahame Grieve (Nov 07 2018 at 23:40):

actually, no. we use semver - but we prefix with a milestone...

Brian Postlethwaite (Nov 08 2018 at 00:17):

So the intent is that each published version of that CodeSystem will be updated, and no published version will ever have the current build included in it?
(I don't see any harm in adding R4 there now though...)

Grahame Grieve (Nov 08 2018 at 00:19):

yes

Grahame Grieve (Nov 08 2018 at 00:19):

agree that there's no harm in adding R4, I just haven't got to it yet

Last updated: Apr 12 2022 at 19:14 UTC