Stream: terminology
Topic: UTG or FHIR?
Melva Peters (Mar 22 2021 at 21:14):
I'm trying to understand why some value sets are in FHIR and others are in THO but they are the same type. Specifically, I'm looking at MedicationKnowledge Status codes which are in THO - type =Code with required binding. But status codes for MedicationRequest status, MedicationDispense, MedicationUsage and MedicationAdmin are in FHIR. Is this a mistake? How do we fix if it is?
Lloyd McKenzie (Mar 22 2021 at 21:31):
It's a mistake. The status codes should not be in THO. As for how to fix, @Ted Klein?
Rob Hausam (Mar 22 2021 at 21:46):
@Grahame Grieve?
John Moehrke (Mar 22 2021 at 21:56):
so what is the rule? I have valuesets that have disappeared from FHIR, and others that are still there. I am not at all clear why some have moved and not others. AND the ones that have moved are so much harder to update.
Lloyd McKenzie (Mar 22 2021 at 22:05):
Anything that's bound to 'code' must live in FHIR space. Everything else that's not pure junk 'example' codes or low-maturity (FMM-1/2) code systems must live in THO. Yes, it's harder. That's the price of robust terminology governance and public review.
Lin Zhang (Mar 22 2021 at 23:48):
Is it feasible to consider addition of some necessary terminology governance/management requiements to FHIR Terminology Services spec?
Melva Peters (Mar 23 2021 at 18:03):
@Grahame Grieve @Ted Klein can I just create this valueset in the FHIR build and then it can be removed from THO at a later date? I'm trying to get changes made for the R5 ballot...
Ted Klein (Mar 23 2021 at 18:55):
Sigh. When R4 was being published as the current FHIR balloted standard, Grahame went through the value sets and changed the canonical URL for those that he felt were possible to be moved. When THO content was imported, I was directing the import of the v3 coremif content and the v2 content, but Grahame manually moved the code systems and value sets that he had previously changed the URL for and I think some others but I have no idea which ones, and manually loaded them into the THO/UTG source of truth; I had nothing to do with it basically. I have kvetched for almost 2 years that we need to verify what has been moved and what has not, and catch errors or items missed. To my knowledge that effort on the part of FMG and FHIR-I has not been undertaken; if it has, I have not been told the result. @Melva Peters if you are creating a value set whose canonical URL is rooted at http://terminology.hl7.org/ValueSet then it goes into THO via UTG. If it is rooted in http://hl7.org/fhir or internal to a FHIR IG, it is my understanding that it goes into the FHIR ecosystem - but exactly where and how I am not clear on.
Melva Peters (Mar 23 2021 at 20:05):
@Ted Klein the issue is that the value set I need to update is in THO but shouldn't be. It is the status codes which are bound to "code" and as Lloyd indicated these must live in the FHIR space. So back to my question. Can I create the value system in FHIR with a canonical URL rooted in FHIR and then at some point it can be taken out of THO?
Alexander Henket (Mar 23 2021 at 21:05):
This really sounds like a lot of my issues are in here. Lloyd told me in another thread that a List was to be created to say which terminology UTG (THO?) is master for, leaving "the rest" for FHIR. I've been on recreating our OID registry that tries to connect system uris to OIDs in the HL7 OID Registry. It also recognizes that a very considerable part of those OIDs are actually defined inline in the ValueSets/CodeSystems/NamingSystems of the FHIR builds. I'm harvesting DSTU2/STU/R4 currently.
Not really knowing what source of truth is, I'm currently running under these assumptions:
- UTG is the only place I trust for finding url/oid connections
- I'm trusting CodeSystem.identifier and ValueSet.identifier before trusting NamingSystem.uniqueId (I'm currently not looking for inconsistencies between the two in UTG, but I know for sure the FHIR Core Spec is inconsistent there)
- FHIR Core spec is the only place I trust for DSTU2, STU3, R4 contents of the CodeSystems and ValueSets, because those came out before UTG and I expect all reference implementations to run with official FHIR Core package, not UTG
For R5 I really hope to see a more unified view. If people are interested in the resulting OID Registry (iso 13582 format), or interested in all the logic and exception I've had to make ... let me know. I'm filing UTG jira tickets on things that I think should be looked at when it concerns stuff at terminology.hl7.org.
Ted Klein (Mar 23 2021 at 21:09):
It is my understanding that Code Systems that are used for value sets where the value set has a required binding to an element of type 'code' must be in the FHIR space, ie rooted in hl7.org/fhir; also the value set may not contain content from any other code system than that one. I am not fully aware of a hard and fast rule that value sets must live in a particular place though - if they are built on only one code system and that system lives in the FHIR space then from my understanding where the value set is housed and maintained is not critical. However I'll need Lloyd to clarify as I might well be mistaken here. In the meantime, since it does live in THO, probably best to make a change through UTG for now until this is fully resolved; please paste the URL to the value set in question in the THO ci build so I can verify I am giving you the correct advice here.
Alexander Henket (Mar 23 2021 at 21:10):
Well since profiles/resources bind to ValueSets, not CodeSystems, I would be amazed if a required binding on a 'code' datatype to a ValueSet is in UTG while the CodeSystem is in FHIR?
Lloyd McKenzie (Mar 23 2021 at 21:12):
What Lloyd said was that - eventually - we'd have a process to propagate content from FHIR into a THO with a list to designate those things as "read only". That hasn't happened yet and the 'code'-bound elements that are in THO are generally there in error.
Lloyd McKenzie (Mar 23 2021 at 21:14):
In general, few FHIR value sets should be in THO - that should be a conscious decision that the value set is both shareable and amenable to maintenance outside the FHIR ballot process. Our focus has been on ensuring that code systems are in THO when it's appropriate for them to be.
Ted Klein (Mar 23 2021 at 21:14):
Alexander, thanks for doing all this. Right now due to a variety of reasons I won't go into here, the content of THO (terminology.hl7.org) maintained using the UTG process contains ONLY the tip of the master branch in the GitHub source of truth for the THO terminology. Most of that terminology was only imported to GitHub in January 2020 so any content in FHIR prior to then was not imported; only the R4 content was imported, and ONLY the subset whose URLs were changed for the R4 publication to be rooted at terminology.hl7.org - all the other stuff stayed in the FHIR spec and continues to be maintained there. Discussions are underway to move closer to full unification but we have a long way to go yet. Right now, the THO content shown in the FHIR tabs for CodeSystems and ValueSets is both maintained in THO, and should reflect the R5 preview state - it has been advanced since R4.
Lloyd McKenzie (Mar 23 2021 at 21:15):
Ted is correct that the migration happened on a hurry-up basis with minimal review/validation, so it being a bit of a mess isn't super surprising.
Alexander Henket (Mar 23 2021 at 21:16):
@Ted Klein Note that UTG offers an STU3 download containing http://terminology.hl7.org uris instead of the then official http://hl7.org/fhir urls. That is one of the issues I filed.
Ted Klein (Mar 23 2021 at 21:16):
Indeed. Like in much of HL7, the QA review process has been done in a less than desirable completeness, but it is what it is. Great idea to put in a UTG ticket pointing out noticed problems so at least they are listed somewhere centrally.
Alexander Henket (Mar 23 2021 at 21:18):
Another one on the way is a list of V3 terminology without OIDs which for the V3 space is rather difficult.
Ted Klein (Mar 23 2021 at 21:19):
@Alexander Henket yes I believe that entry in the template control file is erroneous as the content is all post=R4. Removing the template link generation control is on my list. I do need to know from @Grahame Grieve though what the tooling does internally in terms of the combined package and the FHIR NPM package system content, as removing the link from the THO UI may still leave the misleading content in places where it will trip folks up.
Ted Klein (Mar 23 2021 at 21:22):
@Alexander Henket another goal (and we are woefully far away still due to not enough folks doing the work) is to properly track the identifiers for code systems. Right now for those that have had their URLs changed (which we all know is a bad thing to do and have tried to avoid it at all costs, but the real world cares little about our tender sensibilities) we have put in quite a bit of effort to create NamingSystem resources in THO to track this. There are two that I know of that had OIDs changed as well, and again it is on a list to be dealt with. But this is a small subset and only for those codes systems generally from external terminology sources, and we are aware that it still has many gaps and errors to be addressed. HTA is working on it.
Alexander Henket (Mar 23 2021 at 21:27):
I aim to finish the work on the OID Registry later this week. I've used this for the past such and so years to generate NamingSystems, and drive connections in ART-DECOR. The only problem is: source of truth. Until last week I trusted the FHIR Core spec for source of truth. Little did I know there. This round I'm fixing around hundreds of connections that are wrong in the FHIR spec with UTG as primary base.
If that work can help you in any way: happy to help. Let me know what/when/where.
Melva Peters (Mar 23 2021 at 22:55):
@Ted Klein I'm not sure if you were asking Alexander or me for that information. Here is the value set I'm referring to http://terminology.hl7.org/2.0.0/CodeSystem-medicationknowledge-status.html. MedicationKnowledge.status (code/required) is bound to this value set.
John Moehrke (Mar 25 2021 at 13:27):
I am very happy for the more formal governance of THO. But when that governance is opaque and freezes legitimate change requests... then that governance is broken. I am referring here to changes that Kathleen has asked for onbehalf of the security workgroup. I am also referring to the technical burden placed upon the proposer that is beyond governance.
Lloyd McKenzie (Mar 25 2021 at 13:31):
In the old harmonization process, the technical burden was on those applying the changes - and that model wasn't sustainable. The technical burden with UTG isn't really any different than making changes directly in FHIR - you need to know how to author the artifacts and you need to understand Git - so UTG vs. FHIR doesn't really change the technical burden that I've noticed. UTG badly needs an automated notification process so that those who are on the hook to review content are regularly pinged about what's on their docket - so that the proponent doesn't have to rattle cages. Are there other concerns?
John Moehrke (Mar 25 2021 at 13:42):
If the GIT technical burden was the same as with IG and fhir core; I would be less worried. But it is a totally different system.
John Moehrke (Mar 25 2021 at 13:43):
Not clear the difference between codes in FHIR core, in an IG, in UTG, or in HTA.
John Moehrke (Mar 25 2021 at 13:44):
what is terminology.hl7.org vs tx.hl7.org?
Lloyd McKenzie (Mar 25 2021 at 14:18):
terminology.hl7.org is a website and official registry of HL7 codes. tx.hl7.org is the terminology server we use when validating and publishing (and includes all the content from terminology.hl7.org, everything from the FHIR core spec, SNOMED, LOINC, UCUM and a whole lot else.
Lloyd McKenzie (Mar 25 2021 at 14:19):
"totally different system" how? Git is Git. You're doing pull requests in both cases. Where's the added complexity? (Not saying there isn't any, I'm just not seeing it.)
Jean Duteau (Mar 25 2021 at 14:46):
I'm just dipping my toe into the UTG process so I'm not completely up to speed with everything, but the first thing I encountered is that by using a BitBucket server instead of just regular Github, there are many Git tools that won't work without paying for them. This forces people who have experience with their Git tooling to either find a different tool or pay for the tool. Not everyone is a command-line Git guru. Is there some reason why UTG is not on the "regular" HL7 Github server?
John Moehrke (Mar 25 2021 at 14:56):
Exactly.. the bitbucket complexity
Lloyd McKenzie (Mar 25 2021 at 15:04):
I think that was because Jira had better integration with Bitbucket than with regular Git. Didn't realize that stops you from using regular Git tools. It's not supposed to... @Joshua Procious ?
Jean Duteau (Mar 25 2021 at 15:13):
depends on your definition of "regular".
Lloyd McKenzie (Mar 25 2021 at 15:16):
"regular" = tools used by committers within the FHIR community normally. So things like TortoiseGit (which I know works with BitBucket) but also whatever Mac folks use
Lloyd McKenzie (Mar 25 2021 at 15:16):
No commercial tools should be required
Joshua Procious (Mar 25 2021 at 15:17):
What tools are you trying to use that do not work with Bitbucket @Jean Duteau, regardless of regular or irregular status?
Jean Duteau (Mar 25 2021 at 15:24):
GitKraken, for instance, works with Bitbucket but not a Bitbucket server. That requires you to pay for a pro or enterprise license. There was another tool that I can't remember when I went to looking for a GitKraken alternative that also doesn't support BitBucket server but does support BitBucket.org.
Melva Peters (Mar 25 2021 at 15:26):
SourceTree is the tool that is recommended for the integration with BitBucket in the documentation.
Jean Duteau (Mar 25 2021 at 15:31):
Melva Peters said:
SourceTree is the tool that is recommended for the integration with BitBucket in the documentation.
Right, thus my point that I either have to upgrade or switch.
Jean Duteau (Mar 25 2021 at 15:32):
I'll point out that this is a minor irritant and is probably not the essence of what John Moehrke was talking about.
John Moehrke (Mar 25 2021 at 15:36):
it is not off topic... I have very simple tools that I use for FHIR core and for IG builds... and I have to do something different with terminology
John Moehrke (Mar 25 2021 at 15:38):
I would like to not have different processes. bitbucket is unusual.
Lloyd McKenzie (Mar 25 2021 at 15:50):
What tools do you use for core and IG build @John Moehrke and what issues do you have using them w/ Bitbucket?
Jean Duteau (Mar 25 2021 at 15:56):
I think that's the wrong question Lloyd. Why is UTG using Bitbucket when all the other IGs are hosted on HL7s Github?
Lloyd McKenzie (Mar 25 2021 at 16:03):
I answered - Jira has better integration w/ BitBucket - and for UTG there was a need for tight linkage between Git and the Jira items
Lloyd McKenzie (Mar 25 2021 at 16:03):
For regular tracker items, we have no integration at all.
Lloyd McKenzie (Mar 25 2021 at 16:04):
There are some new Jira plugins that claim to provide 'pure' Git integration, which might be worth pursuing if BitBucket is causing significant grief. Don't know how hard it would be to switch the application though.
Lloyd McKenzie (Mar 25 2021 at 16:05):
Alternatively, there might be some changes we can make with our Bitbucket implementation so that tools play more nicely with it
Alexander Henket (Mar 26 2021 at 13:58):
Maybe most grief could be mitigated by using bitbucket.org, rather than bitbucket server. I develop certain things against bitbucket.org and everything works with any of my git clients including GitKraken and SourceTree (which is a free btw). I have one sincere problem with SourceTree which is that it refuses to remember I like tabs above windows, which is why GitKraken is what I mostly use, but even the oXygen Git client works fine with anything. I have no experience with BitBucket server so cannot help there. Only github, bitbucket.org, gitlab and some small ones.
Alexander Henket (Mar 26 2021 at 14:14):
Melva Peters said:
Ted Klein I'm not sure if you were asking Alexander or me for that information. Here is the value set I'm referring to http://terminology.hl7.org/2.0.0/CodeSystem-medicationknowledge-status.html. MedicationKnowledge.status (code/required) is bound to this value set.
You are pointing to the CodeSystem. Don't know if that matters for the question but didn't you mean https://terminology.hl7.org/2.0.0/ValueSet-medicationknowledge-status.html?
In any case, if the assertion holds that FHIR code bound terminology has source of truth in FHIR, not in UTG/THO, then you would not be expected to go through UTG/THO processes for a change? So in fact the leading location for that ValueSet is in the FHIR spec and process would be through a Jira ticket?
Melva Peters (Mar 26 2021 at 16:08):
Yes, I believe that both the value set and the code system should be in FHIR and not UTG for this and that changes can be managed via Jira Issue. Still trying to figure out how to fix!
Alexander Henket (Mar 26 2021 at 16:23):
I would know how add a code in a CodeSystem or ValueSet once a motion was approved to do so, but I don't think I can help you on this governance issue:
Can I create the value system in FHIR with a canonical URL rooted in FHIR and then at some point it can be taken out of THO?
Michael Lawley (Apr 01 2021 at 04:26):
I'm still wondering what the answer to this question is:
What tools do you use for core and IG build @John Moehrke and what issues do you have using them w/ Bitbucket?
Melva Peters (Apr 29 2021 at 20:05):
I am going to start to apply some changes to the Pharmacy resources. One of the first things I will be doing is to add the MedicationKnowledge codesystem and value set to the FHIR Code build as it was pulled into UTG in error. Unless I hear differently, I'll be starting this work in the next couple of days. My next set of changes will be to add the example valuesets/codesystems that were move to THO back into the core build. All of these will need to be removed from THO. Should I submit change requests in UTG to have that done? @Ted Klein @Grahame Grieve @Rob Hausam
Grahame Grieve (Apr 29 2021 at 20:27):
yes
Rob Hausam (Apr 29 2021 at 20:40):
Yes, agree with that.
Melva Peters (May 05 2021 at 16:21):
I have created the change request in UTG - https://jira.hl7.org/browse/UP-200 for the removal of MedicationKnowledge Status Codesystem and Value set. @Grahame Grieve @Ted Klein @Rob Hausam - who will do the deletion?
Ted Klein (May 06 2021 at 15:31):
@Lloyd McKenzie Does FHIR-I or FMG have a policy about the canonical URL for the code systems in FHIR? e.g. part of the import of CS: MedicationKnowledgeStatus last year was that Grahame changed the canonical URL to be rooted at terminology.hl7.org; if it is 'moved' back into FHIR, does the URL need to be changed back to be rooted at hl7.org/fhir?
Melva Peters (May 06 2021 at 15:55):
I believe this one should not have been changed last year - all of the other status value sets are rooted in hl7.org/fhir.
Grahame Grieve (May 06 2021 at 21:37):
has to have a matching root URL; if it's moved back, it has to change
Melva Peters (May 06 2021 at 21:39):
I have applied the change to move it back and have added a UTG change request to removed it from UTG.
Last updated: Apr 12 2022 at 19:14 UTC
