Stream: committers
Topic: Removing UTG Content from core build
Michelle (Moseman) Miller (Sep 21 2020 at 17:27):
Did I miss an announcement related to "removing UTG Content from core build"? Following @Grahame Grieve 's changes a couple weeks ago, https://github.com/HL7/fhir/commit/5c0494aacfd0b8bd52bc72c587aa89d0a64246f8#diff-7d6112d906f06fde02ecf08edc8a67c8, it seems like the codesystem files have been removed from the source resource folders. Are work groups still able to update the code systems? If so, how? For example, I am trying to apply J#26464 to update the definitions of codes, but I can't find the codesystem file that I would have previously edited.
Grahame Grieve (Sep 21 2020 at 17:32):
you have to work through the UTG process now
Michelle (Moseman) Miller (Sep 21 2020 at 17:49):
Can you help me locate the process documentation?
I found https://confluence.hl7.org/display/VOC/UTG+Education+and+Rollout+Plan, but that page is pretty recent, so I'm not sure if they have rolled out the education yet.
Grahame Grieve (Sep 21 2020 at 17:50):
@Ted Klein
Jean Duteau (Sep 21 2020 at 23:06):
Pharmacy has a number of codesystems and value sets that we were going to work on during the WGM. We will document these in our notes but we obviously will need to learn how to create/modify needed code systems.
Jean Duteau (Sep 21 2020 at 23:12):
so some pointer to the process would be nice. There is some information on the UTG Confluence pages, but I'm not sure where to start and it looks daunting
Jean Duteau (Sep 21 2020 at 23:13):
if some other WG has done this, that would be great to know their experience
Grahame Grieve (Sep 22 2020 at 02:10):
ths simplest way for now is to get a copy of UTG - it's a FHIR IG - and just do what you were going to and build UTG locally. it takes about the same time as the main build anyway
Grahame Grieve (Sep 22 2020 at 02:10):
or work in a brnach and commit the branch to github, and the ci-build will publish it
Jean Duteau (Sep 22 2020 at 02:12):
if we make changes/additions to exemplar code systems (i.e. code systems that are created purely to show the types of concepts to use on a coded field in core), will we need to go through the whole UTG approval process?
Lloyd McKenzie (Sep 22 2020 at 02:20):
Those code systems probably shouldn't be in UTG because they're not 'real' codes - though the name of the code system should make that clear
Jean Duteau (Sep 22 2020 at 02:34):
hmm, it looks like all code systems where brought lock, stock, and barrel into UTG
Grahame Grieve (Sep 22 2020 at 02:35):
It was according to the long standing UTG agreement, where the only code systems that remain in FHIR are those used in a required binding to a element of type code - those stay in FHIR; everything else goes to UTG
Lloyd McKenzie (Sep 22 2020 at 02:41):
Stuff should have only gone to UTG if it was FMM3+
Lloyd McKenzie (Sep 22 2020 at 02:41):
The stuff that's FMM2 and below is often temporary throw-away stuff
Lloyd McKenzie (Sep 22 2020 at 02:42):
E.g. stuff that might result in a new LOINC or SNOMED code - once we're sure of what we want and it actually makes sense to ask...
Lloyd McKenzie (Sep 22 2020 at 02:42):
The problem with locking all this stuff into UTG now is we've got a bunch of codes that are now 'official' and have to be maintained as such, even though they shouldn't be
Lloyd McKenzie (Sep 22 2020 at 02:43):
Granted, a bunch of the v3 stuff is similarly immature, so it's not like the junky FHIR codes will be in poor company...
Jean Duteau (Sep 22 2020 at 02:43):
i would also have argued that code systems that are created purely to provide example codes should never have gone into UTG
Grahame Grieve (Sep 22 2020 at 02:44):
That wasn't the in the scope of the agreement. Maybe it should have been. But if something is used as an example or is experimental, then UTG governance should be appropriate
Grahame Grieve (Sep 22 2020 at 02:45):
it it turns out that this isn't possible, then I'll support defining examples and drafts elsewhere
Jean Duteau (Sep 22 2020 at 02:45):
np, i understand. now we (core spec committers) just need to figure out how to manage the UTG process
Grahame Grieve (Sep 22 2020 at 02:45):
well, that was necessary anyway.
Jean Duteau (Sep 22 2020 at 02:45):
is this going to apply to HL7 FHIR IGuides as well?
Jean Duteau (Sep 22 2020 at 02:48):
Grahame Grieve said:
it it turns out that this isn't possible, then I'll support defining examples and drafts elsewhere
I'm sure it will be possible, I'm more worried about the timing/effort to create content that is never intended to be official. Time will tell...
Grahame Grieve (Sep 22 2020 at 02:50):
That's an open discussion. It looks to me, based on current discussion, that,
-
for ValueSets, IGs will be able to define their own value sets, but shared ones will be in UTG. note, though, that HTA has jurisdiction over external code system usage
-
for Code systems, I don't yet have a sense of that. IG authors would like to be able to do whatever they want, but I think that an additional quality process is justified for non-draft/experimental code systems. Whether that's UTG... I'm not clear yet
-
for Concept Maps: we haven't had enough discussion for me to have any sense about this
Grahame Grieve (Sep 22 2020 at 02:51):
I'm sure it will be possible
I meant: If it isn't possible to have appropriate governance for experimental / draft value sets & code systems
Jean Duteau (Sep 22 2020 at 02:51):
ah, then we meant the same thing. we are on the same page. :)
Lloyd McKenzie (Sep 22 2020 at 02:57):
Part of the issue is that FHIR itself hasn't had great governance over experimental/draft artifacts. We don't properly differentiate what's fake/temporary/work-in-progress from what's well baked and stable. (In my IGs I've recently started dumping all my 'temp' codes into a single code system with the id 'temp' and a description that makes very clear that "these codes are expected to move somewhere official, once we're sure that a) they say what we want; and b) that we gain consensus on where the appropriate long-term home is". I suspect that the vocab WG would be much less anxious about a single massive FHIR 'temp' code system full of miscellaneous junk. We could then enforce a build rule that artifacts with FMM3+ weren't allowed to point to 'temp'.
Lloyd McKenzie (Sep 22 2020 at 02:57):
The IG-publisher could force something similar - at least for IGs using the HL7 template.
Lloyd McKenzie (Sep 22 2020 at 02:58):
Time allowing, we could perhaps discuss on the joint call.
Jean Duteau (Sep 22 2020 at 02:58):
that is another concern - how to do experimental/draft. Slightly different from my worry around governance of example codes.
Jean Duteau (Sep 22 2020 at 02:59):
dang it, now I'm going to want to go to the Vocab/MnM joint :)
Lloyd McKenzie (Sep 22 2020 at 02:59):
One of the other challenges with our mass migration is that some of that stuff probably should be in LOINC
Lloyd McKenzie (Sep 22 2020 at 02:59):
We could say that example bindings to temp are always fine
Grahame Grieve (Sep 22 2020 at 03:00):
@Ted Klein this is definitely something we need to talk about
Lloyd McKenzie (Sep 22 2020 at 03:00):
The fact that the code system URL says "http://...../tempCodesDoNotUse/..." would hopefully discourage use in production... :)
Rob Hausam (Sep 22 2020 at 03:00):
Something similar might be appropriate. But a large "grab bag" code system full of draft / experimental "junk" sounds fairly frightening, actually!
Rob Hausam (Sep 22 2020 at 03:00):
Agree that url may help.
Lloyd McKenzie (Sep 22 2020 at 03:00):
Less frightening than a bunch of individual code systems that look legit but are in fact still junky?
Jean Duteau (Sep 22 2020 at 03:01):
that would be an interesting switch - right now, we keep creating code systems with the example codes and then a value set that is just "all codes in this fake code system I just made". if we could make a "grab bag" code system that had hierarchy, that might be more manageable. (said with my user voice that asserts anything I don't understand must be easy)
Lloyd McKenzie (Sep 22 2020 at 03:01):
The "doNotUse" would be a bit strong - perhaps one for example only? The low-maturity ones we'd actually want to be used, just for implementers to be aware that we're going to switch them at some point, so be ready and don't whine when that happens.
Grahame Grieve (Sep 22 2020 at 03:02):
http://hl7.org/fhir/examples/CodeSystem/xxx
Grahame Grieve (Sep 22 2020 at 03:02):
we could allow that and enforce that they are marked experimental = true
Lloyd McKenzie (Sep 22 2020 at 03:04):
And prohibit value sets that draw from them from having a binding strength other than example?
Lloyd McKenzie (Sep 22 2020 at 03:05):
For examples, I'd actually like the URL to say "examples-do-not-use". I'm concerned that "examples" isn't concrete enough to stop people from using them in production.
Jean Duteau (Sep 22 2020 at 03:05):
i suspect that even "examples-do-not-use" won't be enough :grinning:
Grahame Grieve (Sep 22 2020 at 03:06):
making warnings in the validator seems to be enough for many people. OTOH, nothing is enough for some
Lloyd McKenzie (Sep 22 2020 at 03:28):
Not all folks in production will use the validator. I'm just worried about those who copy & paste from example instances and use that as the basis for their code. Inevitably, some of the codes will make it into production. However, when we point to the "do-not-use" in the code system URL, I'm hoping they'll have the good grace to at least look sheepish...
Brian Postlethwaite (Sep 22 2020 at 07:58):
What about http://example.com/blah/....
Ted Klein (Sep 22 2020 at 18:40):
Sorry I have not been on this thread been buried with other burning crises...where to begin...we have both the flag for experimental and the version ID element to clearly and processably indicate whether something is 'temporary' or not. The UTG system and process is live, about a half dozen proposals have gone completely through the consensus process and been implemented to the source of truth for the UTG ci build. The documentation for everything is on Confluence, and it would probably be best to start at https://confluence.hl7.org/display/VOC/Vocabulary+Maintenance+at+HL7 from where all the documentation and training stuff can be found. We have not yet made final decisions on removal of stuff that has been published for years in v3 and v2, and we know that some of the experimental stuff from FHIR has been imported; we may either remove this or sequester it somewhere, or flag it so it can be excluded from production builds. Folks can begin putting changes through the process and we will do our very best in supporting them if any difficulties are encountered. We will have discussions on much of this in the UTG and FHIR-I/Vocab sessions this week.
Michelle (Moseman) Miller (Sep 26 2020 at 01:18):
@Grahame Grieve said
It was according to the long standing UTG agreement, where the only code systems that remain in FHIR are those used in a required binding to a element of type code - those stay in FHIR; everything else goes to UTG
PC has some required bindings to an element of type CodeableConcept (I know you love that....not).
Does the data type really make a difference here or should/could the agreement be updated to exempt those required bindings to an element of type CodeableConcept?
Example: Condition clinicalStatus and verificationStatus
Grahame Grieve (Sep 26 2020 at 01:21):
well I can say that the agreement did apply to them. I'm not sure whether the committees would agree to move them back. It would change the URL for the systems if we did.
Michelle (Moseman) Miller (Sep 26 2020 at 01:26):
I thought it was a recent change you just applied a couple weeks ago....so is the URL change impactful if it is only a 'change' in the current build no one has implemented yet? (still trying to catch up on these changes and new processes for making changes)
Grahame Grieve (Sep 26 2020 at 04:04):
the URL is published in R4 as a UTG URL. So changing it to something other than living in UTG will be a change from R4
Lloyd McKenzie (Sep 26 2020 at 04:18):
Of course, if you change them back to code, then a change to the URL won't matter... :)
Melva Peters (Oct 22 2020 at 18:24):
I hate to bring this up again, but I have 5 FHIR Jira issues that involve creating example bindings with example value sets. I don't know if I can do this in the build or if the example bindings/value sets need to go through UTG. Can someone please clarify? @Ted Klein @Grahame Grieve @Lloyd McKenzie
Rob Hausam (Oct 22 2020 at 18:41):
Are they also example code systems (or are the codes from an existing standard code system)?
Jean Duteau (Oct 22 2020 at 18:49):
Yes, for many of them. We will need to create example code systems and then value sets that are basically "include all from code system".
Rob Hausam (Oct 22 2020 at 20:10):
This is for particular IG(s)?
Lloyd McKenzie (Oct 22 2020 at 20:25):
Value sets never need to be defined in UTG. They can be defined in UTG if there's an expectation that they'll either be shared by IGs that won't have a dependency on the originating IG or will be shared by artifacts across product families.
If the maturity level of the IG/referencing profile is <3, code systems don't need to be in UTG, though they should have an id that makes clear that they are temporary. For more mature artifacts, I believe we'd agreed to add a special 'examples' code system to UTG where we'd have a lighter-weight process for introducing content. The code system would have a URL that would make it clear the codes shouldn't ever be used in production.
Grahame Grieve (Oct 22 2020 at 20:41):
@Lloyd McKenzie I don't believe that this is something vocab has agreed to
Lloyd McKenzie (Oct 22 2020 at 20:56):
Which part? I know we discussed both at the WGM
Grahame Grieve (Oct 22 2020 at 21:34):
oh yes, we did. @Ted Klein do we have minutes for that session?
Ted Klein (Oct 22 2020 at 22:10):
Just this morning all the vocab chairs came to consensus agreement for new temporary URIs for external code systems that are still in work by HTA for final authoritative URI values would be:
http://terminology.hl7.org/temporary-uri/codeSystem/xxx for code systems, and
http://terminology.hl7.org/temporary-uri/valueSet/xxx if it is needed for value sets. We did not move the discussion further as to whether this refers to any new code system that it is unknown if it will live or be temporary for examples, etc. (we got tied up in other related discussions). Thus I do think we need to come to agreement on whether or not to use this for the example IG items that this thread began asking about. I could not get decision on the process and steps (yet) for what these string values should be for IG developers to use so they know how to move forward, despite my getting very unpleasant on the caller being too implementation-focussed. Perhaps @Carol Macumber @Robert McClure @Rob Hausam @Carmela Couderc and @Reuben Daniels can weigh in on what we can declare as decided and done since this needs to be solved now (see the urgency of the IG developers' request above in this thread) for such exanple things and IG development. I want very badly to put this to bed and move on to our other priorities ASAP.
Lloyd McKenzie (Oct 22 2020 at 23:33):
I think the 'example' code system approach should be different. Codes under the temporary-uri are expected to be moved elsewhere eventually. On the other hand, 'example' codes aren't expected to be moved anywhere, ever. Personally, I'm not totally clear on the value of putting example codes in UTG at all - I think the value of a single code system containing a grab bag of arbitrary examples from a wide range of IGs is likely to be quite limited - and that we'd be better off saying that such things can simply be defined within the referencing IG, with the only requirement that the URL make very clear that the codes should never appear in production systems.
Lloyd McKenzie (Oct 22 2020 at 23:34):
(Enforcing tight change control and quality management on such codes seems of limited value...)
Jean Duteau (Oct 23 2020 at 00:37):
I think that FHIR core committers who need to create code systems (and a corresponding include all value set) to provide example bindings in their resources should not need to create these in UTG. I see zero value in doing so. As Lloyd said, these are not going to be real codes that will move to some real code system in the future. These are purely fake codes being created to show examples of codes in a resource.
Ted Klein (Oct 23 2020 at 00:43):
Agree
Melva Peters (Oct 23 2020 at 01:48):
@Rob Hausam no, it's for our base resources. We have to have at least an example binding
Grahame Grieve (Oct 23 2020 at 01:55):
it's the example question that hasn't been ruled on by vocab.
Grahame Grieve (Oct 23 2020 at 01:56):
and I think I moved a bunch of examples into UTG since that was the applicable policy
Lloyd McKenzie (Oct 23 2020 at 01:58):
Core spec should presumably follow the same principle - example 'fake' codes should be a FHIR-specific fake code system that isn't in UTG.
Melva Peters (Nov 09 2020 at 22:20):
Do we know when this decision is going to be made by Vocab? I have a bunch of changes to apply that all need change to value sets or addition of example bindings.
Melva Peters (Nov 11 2020 at 15:41):
Where should this topic be raised so that we can get a decision? It is holding up changes to the core specification! @Ted Klein @Grahame Grieve @Lloyd McKenzie
Ted Klein (Nov 11 2020 at 16:01):
The vocab chairs had an active call on this yesterday. I doh't believe we yet have a firm decision. On the one hand, keeping bogus content and dross out of THO is wise, but on the other hand the whole purpose of standing yup the web pages IG for it is so folks can share and not always have to create their own, with a single place to look for stuff. My PERSONAL OPINION is that we should have a tab for Example content on THO, and for code systems whose entire content is only to support examples and is never intended to be used in a production system we have a CodeSystem.status code value to indicate Example not for production use (which seems to me to be in the similar semantic space as something like 'experimental' which exists as a code in the PublicationStatus code system). For the ValueSet resources which are only Example content, I would opine we do the same with an appropriate code added to PublicationStatus that then can be used in ValueSet.status the exact same way.
Ted Klein (Nov 11 2020 at 16:02):
If adding such a code is not a breaking change, it could possibly be done for 4B
Melva Peters (Nov 11 2020 at 16:19):
@Ted Klein this isn't in IG's, this is in FHIR core. We have to have an example binding for any attribute that is a CodeableConcept. We try to point to SCT where we can and where there is a valid hierarchy to use, but if that isn't possible and there isn't another option, we have been creating valuesets as the example.
Melva Peters (Nov 11 2020 at 16:20):
Not sure what you mean about doing it for 4B
Lloyd McKenzie (Nov 11 2020 at 16:43):
There's no need to "look for stuff" if it's example content. There's no need for re-use, and in general, we don't want re-use because the codes themselves are bogus and tuned for specific use-cases. Putting the content in UTG forces an overhead cost on the designers without providing any benefit to the implementer community.
Lloyd McKenzie (Nov 11 2020 at 16:54):
My preferred policy would be as follows:
- if the value set is used only in elements of type 'code' (which by definition requires a 'required' binding, then the code system can be defined in core/in the IG and need never go into UTG. (E.g. status, gender, etc.)
- if the value set is only used with a binding strength of example, then the code system can be defined in core/in the IG but must have a URL that follows an approved convention and makes it obvious that the codes are example-only and should not be used in production. The validator will spit out warning if it sees them, warning that they can't be used in production
- if the value set is being used only in artifacts with maturity of FMM 2 or less (core or IG) , the code system can be a core/IG-specific code system. However, that code system must follow a URL pattern that clearly marks the codes as 'temporary'. The validator will throw an error if a binding to that code system appears in any artifact with a maturity of FMM 3+
The outcome of this is:
- no overhead for purely example codes
- no overhead for low maturity codes
- we still get codes into UTG for the codes that matter
Ted Klein (Nov 11 2020 at 18:03):
Mostly agree Lloyd, but Melva's Use Case is an example value set which includes real SCT codes. We do have to explore the corner cases here.
Lloyd McKenzie (Nov 11 2020 at 18:15):
If there's no codes to define, should be no issue. Valuesets never have to be defined in UTG. Work group needs to consciously decide that the value set is intended to be shared for that to happen.
Melva Peters (Nov 11 2020 at 18:16):
I didn't say it contained real SCT codes. I said we use SCT where we can for example bindings, but where there isn't a valid hierarchy, we create a value set with example codes in it.
Melva Peters (Nov 25 2020 at 23:09):
Has there been any decision on this? We have a bunch of Jira issues that we can't apply because we don't know if our example value sets have to go through UTG. @Ted Klein @Grahame Grieve @Lloyd McKenzie
Lloyd McKenzie (Nov 25 2020 at 23:11):
I've expressed my opinion but I don't know when/where the decision is going to be made.
Grahame Grieve (Nov 25 2020 at 23:43):
This is becoming problematic, and I suspect we're heading towards an executive decision outside vocab if it doesn't progress. @Rob Hausam can you please convey this to vocab co-chairs
Rob Hausam (Nov 26 2020 at 02:19):
We have a Vocab co-chairs call and an additional "External code system identifier subgroup" call scheduled on Monday. We can further discuss it then. Personally, I think we may be making this problem to some degree larger than it really needs to be. Along with Ted, I'm largely in agreement with Lloyd's preferred policy suggestions. I'm not quite sure, though, if the items that he described as "must" might not alternatively be "should" - at least for now, until we do come to an agreement on Lloyd's suggestions (or something similar) as being the official policy. And in the meantime, is it really beneficial to hold up the changes that are needing to be made by Melva and others in the core spec? And if it happens to end up taking a while longer to decide on the final policy, and the changes that were made under the current "rules" would end up making it into R4B (wherever that may be applicable) - then maybe we could agree that we can live with that, and then begin applying the new finalized policy for whatever further changes will be made from that point forward which will end up in R5 (or later)? @Grahame Grieve @Lloyd McKenzie @Ted Klein @Carol Macumber @Robert McClure @Carmela Couderc @Reuben Daniels
Lloyd McKenzie (Nov 26 2020 at 02:41):
I don't think these are rules that belong in the core spec at all. They're methodology rules on HL7 IG developers, not something relevant to implementers.
Rob Hausam (Nov 26 2020 at 03:38):
As I brought up on the Monday evening "external code system identifier" call, I believe it will be true that most (not all) instances of creating new code systems and value sets that are bound as example will still likely be in the core spec. When you are developing an implementation guide, you are going to typically want to constrain the existing example bindings in the core spec to at least preferred (or stronger), whenever possible, and you probably won't (or shouldn't be) creating very many (or any) new code systems and value sets that are bound as example, because by definition those are meant to be only examples and are not intended to be implemented.
Lloyd McKenzie (Nov 26 2020 at 03:44):
Not necessarily. The example bindings in the core spec might only contain 3 or 4 codes. The bindings needed in an IG might not overlap at all with those - so you may well create IG-specific codes
Lloyd McKenzie (Nov 26 2020 at 03:44):
However, it's reasonable that all example codes defined in an IG be drawn from a single code system
Lloyd McKenzie (Nov 26 2020 at 03:45):
(Same for all temporary codes, though that should be a different system from the example system - because they might reasonably show up in production.)
Rob Hausam (Nov 26 2020 at 03:45):
Well, I did make a point of saying "not all". :)
Melva Peters (Dec 02 2020 at 23:22):
Any decision made on this??? No discussion since November 25th! Can we please get a decision!!! @Ted Klein @Rob Hausam @Grahame Grieve @Lloyd McKenzie
Lloyd McKenzie (Dec 02 2020 at 23:42):
When's the next vocab call? And is this on the agenda?
Rob Hausam (Dec 03 2020 at 00:23):
Next Main call is next Thursday. FHIR Tracker call is tomorrow (3:30 PM Eastern). We might be able to spend a few minutes on it tomorrow, if needed. It's pretty much been constantly on the agenda, and I think things are converging toward a consensus (seems to be).
Melva Peters (Dec 03 2020 at 04:07):
This is holding up applying changes! It needs to be resolved soon!!!!
Melva Peters (Dec 14 2020 at 16:22):
@Robert McClure FYI
Robert McClure (Dec 14 2020 at 19:29):
Based on discussions among the Vocab chairs and after the TSC discussion this am the vocab chairs agree to the following:
Example content does not need to be included in the THO publication process or go through UTG at this time.
We reserve the right to improve upon this with a more nuanced approach in the future.
We remained concerned regarding the process by which this will be achieved and any resulting downstream impacts that might have for a more complete solution on how terminology content is defined and managed in FHIR artifacts. It is our assumption in making this decision on only a piece of the problem, all options for the future are still open in crafting a solution all are happy with.
@Rob Hausam @Ted Klein @Carol Macumber @Carmela Couderc @Reuben Daniels @Austin Kreisler @Melva Peters @Grahame Grieve @Jean Duteau @Lloyd McKenzie
Lloyd McKenzie (Dec 14 2020 at 19:56):
Thank you. Happy to participate in discussions of future evolution
Melva Peters (Mar 18 2021 at 17:22):
@Jean Duteau @Lloyd McKenzie
Last updated: Apr 12 2022 at 19:14 UTC
