Stream: terminology / utg
Topic: Extensions question
Grahame Grieve (Apr 25 2019 at 21:23):
I'm just chatting to Ted and Jessica about the extensions defined in UTG. What we said was that we would define UTG extensions in a UTG meta IG. So we would have 2 IGs - UTG itself, and an IG that describes UTG
Grahame Grieve (Apr 25 2019 at 21:23):
I
Grahame Grieve (Apr 25 2019 at 21:24):
I
Grahame Grieve (Apr 25 2019 at 21:25):
I'm going to build the guts of both today (or very soon). But I see that we (?) made all the extension URLs http://hl7.org/fhir/StructureDefinition/xxx - in other words they are defined in the main spec.
Grahame Grieve (Apr 25 2019 at 21:56):
so the question is - should we change the extensions to a UTG extension space? or not do a UTG meta IG. @Lloyd McKenzie ?
Lloyd McKenzie (Apr 25 2019 at 23:37):
We should change them - We can just do a search and replace.
Grahame Grieve (Apr 26 2019 at 00:33):
do we have a version policy for UTG? an agreed current version?
Lloyd McKenzie (Apr 26 2019 at 01:55):
Not sure what you mean
Grahame Grieve (Apr 26 2019 at 03:08):
what is the current version of UTG/
Grahame Grieve (Apr 26 2019 at 03:08):
when does the major version increment?
Grahame Grieve (Apr 26 2019 at 03:10):
do all the publised resources have that common version?
Lloyd McKenzie (Apr 26 2019 at 03:11):
For UTG terminology, I don't think the notion of major/minor version applies. It'd essentially be a timestamp-based versioning or a single incrementing number
Lloyd McKenzie (Apr 26 2019 at 03:12):
We might continue on the version numbering from the v3 repository
Grahame Grieve (Apr 26 2019 at 03:13):
what's that version number?
Lloyd McKenzie (Apr 26 2019 at 03:19):
Most recent is 1436-20190320
Grahame Grieve (Apr 26 2019 at 03:19):
well, we need semver...
Lloyd McKenzie (Apr 26 2019 at 03:19):
We're not going to follow semver
Lloyd McKenzie (Apr 26 2019 at 03:19):
The most important part is the date
Grahame Grieve (Apr 26 2019 at 03:19):
err, yes, we are
Lloyd McKenzie (Apr 26 2019 at 03:19):
Not for terminology
Lloyd McKenzie (Apr 26 2019 at 03:20):
No such thing as major vs. minor change
Grahame Grieve (Apr 26 2019 at 03:20):
we are for the UTG package
Lloyd McKenzie (Apr 26 2019 at 03:20):
The tooling IG yes, but not the vocab IG
Grahame Grieve (Apr 26 2019 at 03:20):
yes the vocab IG - we have to, because of NPM
Lloyd McKenzie (Apr 26 2019 at 03:20):
Might drop and add whole new code systems or might change a comma. Still a new version
Lloyd McKenzie (Apr 26 2019 at 03:21):
And we won't differentiate
Lloyd McKenzie (Apr 26 2019 at 03:21):
Because we don't care
Grahame Grieve (Apr 26 2019 at 03:22):
we'll still be using semvar. But as we talk about, I'm sure we already discussed this. @Ted Klein ?
Lloyd McKenzie (Apr 26 2019 at 03:22):
Just make the major version the date and set the others to zeros
Grahame Grieve (Apr 26 2019 at 04:44):
hmm a problem: ValueSet-v3-RespiratoryAndOrRehabilitativeAndOrRestorativeSpecialistOrTechnologistHIPAA
Grahame Grieve (Apr 26 2019 at 04:44):
that's a very illegal resource id -- too long
Ted Klein (Apr 26 2019 at 11:25):
We discussed semver quite a while ago (3 WGMs?).. I am in support of it, but Lloyd convinced me that the juice was not worth the squeeze. For the overall UTG terminology, following the naming pattern of V3 (e.g 1436-T120190320) I think carries forward a lot of useless baggage; the part to the right of the hyphen refers to the harmonization cycle (3 per year) and the date of the coremif generation. The integer to the left of the hype is really the version number that changes every update using the v3 tools. This having been said, v2 uses a completely different scheme, as does FHIR vocabulary. I am in favor of the simplest possible versioning that reflects the unification of the terminology in UTG.
Ted Klein (Apr 26 2019 at 11:28):
The main issue with semantic versioning IMHO is that any change at all could be important to users and be potentially a 'breaking' change. Any judgment we made on major vs. minor change is guaranteed to generate issues in the community IMHO. The simplest versioning is just an incrementing integer, however the date is pretty useful; I'm ok with a version reference table that has information on the dates a new version was done. For vocabulary, each code system or vsd needs to be versioned when changed, and I have received a compelling argument that changes to concepts within a code system also need to be versioned (which we currently do not do).
Ted Klein (Apr 26 2019 at 11:29):
I though this was truncated let me check with Dave who stated it was fixed.
Grahame Grieve (Apr 26 2019 at 11:40):
ok, so we have to use semver. no choice....
Grahame Grieve (Apr 26 2019 at 11:41):
so, major version increments when we change the UTG structure. minor version is date of release. patch is for patches to versions
Ted Klein (Apr 26 2019 at 11:50):
makes total sense for the software and infrastructure. For the content, I am not sure the best approach. We have quite a few different kinds of objects in the content: 1. UTG code system resources. 2. UTG value set definition resources. 3. UTG manifests (LIST resources). 4. releases (published collections of a proper subset of the content) 5. concepts within a code system. 6. value sets expansion instances. The last two we currently have no clue and discussions continue, but the first 4 we need to land on the versioning ASAP.
Ted Klein (Apr 26 2019 at 11:53):
the version number in v3 (like 1436-20190320) is a version applied to the entire release. Inside v3 we do have some primitive version tracking in the database that I don't think is surfaced at this time in the MIF. V2 does not individually version the tables before the tables project created versions for them, using incrementing integers. It is my understanding that at the current time Trifolia has NO versioning numbering or version/change tracking on value sets maintained there. So unifying the versioning mechanisms is part of the 'unified' in UTG, and is still a not-yet-completed design effort.
Ted Klein (Apr 26 2019 at 11:58):
I am ok with your notion to start with for now: major number increment for structure/layout changes, minor number for approved content changes, patch number for technical patch fixes. But some questions in my mine such as: if we add extensions what kind of a change is that? if we add or change how we will use or name the manifests, what kind of change is that? etc. Not clear to me in terms of what we are doing with UTG what would comprise a major vs. a minor number increment, and how this benefits the community.
Lloyd McKenzie (Apr 26 2019 at 13:53):
What sort of breaking change could happen to UTG structure? The resources are normative...
Lloyd McKenzie (Apr 26 2019 at 13:54):
If we want to say that major version is locked at 1, that's fine. My only concern is that we're not going to bother with tracking breaking changes to value set or code system content as part of the package version because that would be a nightmare.
Grahame Grieve (Apr 26 2019 at 20:20):
so I hear that we won't be imposing the UTG version on the individual code systems or value sets - they have their own version. And I have nothing to say about how those are maintained at this time.
Grahame Grieve (Apr 26 2019 at 20:20):
as for changing structure - concept maps are not normative at this time.
Grahame Grieve (Apr 26 2019 at 20:21):
but actually, what I was thinking about is restructuring the arrangements within UTG - if we changed the identifiers for v2/v3 code systems, for instance
Grahame Grieve (Apr 26 2019 at 20:21):
btw this:
a problem: ValueSet-v3-RespiratoryAndOrRehabilitativeAndOrRestorativeSpecialistOrTechnologistHIPAA
I am stuck on this - it's fatal to me progressing, and we need to shorten it
Grahame Grieve (May 03 2019 at 09:26):
@Lloyd McKenzie this is really your issue. can I just change the id of this value set?
Lloyd McKenzie (May 03 2019 at 12:00):
I'd already asked for it to be changed. I thought it had been - but not in the URL. I don't think it's actually referenced by anything, so it should just be a question of changing it in the source MIF that's used to create the XML files I process.
Grahame Grieve (May 03 2019 at 15:58):
ok I'm just going to change it then
Ted Klein (May 23 2019 at 18:44):
I thought we changed it in the latest Git image already...
Last updated: Apr 12 2022 at 19:14 UTC
