Stream: IG creation
Topic: http://nucc.org/provider-taxonomy
David deRoode (Jul 28 2020 at 18:24):
Getting the following two errors related to nucc.org/provider-taxonomy:
Unknown Code http://nucc.org/provider-taxonomy#207Q00000X in http://nucc.org/provider-taxonomy for "http://nucc.org/provider-taxonomy#207Q00000X"
Unknown Code http://nucc.org/provider-taxonomy#122300000X in http://nucc.org/provider-taxonomy for "http://nucc.org/provider-taxonomy#122300000X"
I have confirmed these codes are included here: https://www.hl7.org/fhir/us/core/ValueSet-us-core-provider-role.html and system value="http://nucc.org/provider-taxonomy"
Grahame Grieve (Jul 28 2020 at 20:47):
@Ted Klein this is a problem with UTG - the UTG definition of this code system does not have these codes which are valid. Nor does it have the definitions of the abstract groupers that we also need (btw @Robert McClure any progress with regard to the codes for the groupers?)
In fact, UTG has 2 definitions for this code system - why?
How to resolve? Should the IG publisher just ignore any definitions for this code system in UTG?
Ted Klein (Jul 28 2020 at 23:18):
@Grahame Grieve I was instructed to remove these codes from the v3 import by HTA and was told having them in there is a violation of IP restriction/licensure. What to do about this NUCC situation @Robert McClure ?
Grahame Grieve (Jul 28 2020 at 23:44):
which codes were you instructed to remove?
Robert McClure (Jul 29 2020 at 15:59):
Regarding arriving at an approach with NUCC on codes for the abstract groupers: Working on it right now. My recommendation is that as a temporary solution we continue to keep the grouper concepts in the code system with the fake codes and mark the concepts as abstract. I understand that is likely different from what @Ted Klein was previously told to do by HTA (@Carol Macumber @Julie James ) for UTG. I will get official confirmation from NUCC as soon as possible. Any alternative solution is much less desirable. I'll also note it would technically help if we could somehow computably restrict those codes from showing up in any expansion. I understand this means expansions could not show the hierarchies but if that is what the NUCC requires of us after we finish our discussion, then I'd like to be able to offer this as s part of the solution - if it is possible. @Grahame Grieve - thoughts?
Ted Klein (Jul 29 2020 at 17:01):
Right ow I am grappling with a problem with the Publisher where we have a number of v3 Value Sets that include abstract grouper codes and in a few of these there are no concrete codes under them - hence the Expansion is not generated as it would be empty (no concepts). This then triggers validation errors that the value set cannot be found for other value sets that include these. Trying to find a workaround... @Grahame Grieve Any ideas on how we can deal with this?
Grahame Grieve (Jul 29 2020 at 19:55):
@Ted Klein @Robert McClure thanks.
- I agree that leaving the abstract codes in for now, marked as abstract, is the right thing to do. And they are marked as abstract now
However:
- I still do not understand why some NUCC codes - not abstract ones - are not present in UTG, and these are causing validation for people now that UTG is working
- It's wrong to automatically restrict the codes from appearing in any expansion whatever because there are some expansions where you want them to appear in the expansions (routing logic / decision support etc). You can specify non-abstract codes if that's appropriate, when you are picking actual concrete codes
- value sets that have no content - how can I reproduce this?
Ted Klein (Jul 29 2020 at 21:44):
OK working through these...the missing NUCC codes - they are in FHIR? ie in (or not in) the v3 source from the December 2019 release? (that is what was imported to UTG this Spring). If they are/were not in the v3 source, then they are not in UTG as NO content from external (non-HL7) code systems was imported from FHIR to UTG. @Robert McClure if you let me know what Is missing and needs to be in there, I can get it into UTG. But please see to it that Julie does not have a fit about it.
Grahame Grieve (Jul 29 2020 at 21:51):
the codes themselves have never been in FHIR. We have a code system that we maintain as a service to terminology servers, including tx.fhir.org, at https://github.com/FHIR/packages/blob/master/packages/fhir.tx.support.r4/package/CodeSystem-nucc-provider-taxonomy.json
Grahame Grieve (Jul 29 2020 at 21:52):
I think I should ignore the UTG nucc entry - it is not useful for us, and we don't know what the provenance of it is
Ted Klein (Jul 29 2020 at 22:31):
I think HTA and Rob M are trying to work out what to be done with NUCC. We have a v3 value set - v3-Prosthodontics - that has the following: <compose>
<include>
<system value="http://nucc.org/provider-taxonomy"/>
<filter>
<property value="concept"/>
<op value="is-a"/>
<value value="1223P0700Y"/>
</filter>
</include>
</compose> and the code 1223P0700Y is not in the v3 code system stub for NUCC or anything - you did make the change in the Publisher so that expansions are generated if their definitions include enumerated codes even if the code system is unknown to the server or to the IG - but that is working for the internal UTG code systems but not for this one whose enumerated code is drawn from NUCC. Methinks we do want to generate these expansions from enumerated <compose> statements even if we are clueless about the code system source; probably should trigger a warning, but generate the expansion anyway. What do you think?
Ted Klein (Jul 29 2020 at 22:33):
Actually methinks that if the IG has an entry for an external code system in the <special-url> parameter then we DO absolutely want to not generate errors and do what we can - because the existence of such a parameter indicates that the value set CLD is deliberate, but the IG and server does not have access to the code system content.
Ted Klein (Jul 29 2020 at 22:35):
I will wait for @Robert McClure and HTA to let me know what needs to be done with this in UTG. I also know that Paul Knapp and Mary Kay are working to get a bunch of X12 content so the implementers can use it. Once they have gotten it, we can make code system resource stubs in UTG with this stuff (see the UTG ada-snodent for an example).
Ted Klein (Jul 29 2020 at 22:38):
It looks like ALL of the value set errors in the UTG build are from enumerated CLDs in value sets (ValueSet.compose) from nucc. If we fix this, then all those errors go away.
Ted Klein (Jul 29 2020 at 22:42):
The dozen or more v3 value sets built on NUCC are ALL enumerated. The v3 MIF publication never published the codes; the MIF definition of the code system is simply: <codeSystem name="nuccProviderCodes" title="NUCC Health Care Provider Taxonomy"
codeSystemId="2.16.840.1.113883.6.101">
<annotations>
<documentation>
<description>
<text>
<p>The Provider Taxonomy Code List is published (released) twice a year on July 1st and January 1st. The July publication is effective for use on October 1st and the January publication is effective for use on April 1st. The time between the publication release and the effective date is considered an implementation period to allow providers, payers and vendors an opportunity to incorporate any changes into their systems. This listing includes Active codes approved for use effective April 1st, 2003, version 3.0; and codes that are New and approved for use effective October 1st, 2003, version 3.1.</p>
<p>It was identified that there is an IP licensure issue with the republishing of the content for this code system by HL7, so the content was removed as of the July 2016 Harmonization cycle release. This external code system content may be accessed from the web page located at http://www.nucc.org/index.php/code-sets-mainmenu-41/provider-taxonomy-mainmenu-40. Multiple formats and means of accessing the content are available from this page.</p>
</text>
</description>
</documentation>
</annotations>
<releasedVersion releaseDate="2019-12-15" hl7MaintainedIndicator="false"
completeCodesIndicator="false"
hl7ApprovedIndicator="false">
<supportedLanguage>en</supportedLanguage>
</releasedVersion>
</codeSystem>. but the old Publishing tooling happily generated the value set expansions from the enumerated definitions. I really think we need to have UTG work this way with the Publisher.
Grahame Grieve (Jul 29 2020 at 22:53):
@Ted Klein you're confused about this - it's confusing. There's 3 code system resources claiming to be for NUCC:
-
https://terminology.hl7.org/CodeSystem-v3-nuccProviderCodes.html
- wrong copyright - no particular claim
- claims that the content was removed in the narrative
- content = not-present (which is correct)
- we should keep this and fix the copyright
-
https://terminology.hl7.org/CodeSystem-v3-HealthcareProviderTaxonomyHIPAA.html
- copyright claims to be HL7 - so wrong
- contains an incorrect list of nucc codes
- we publish it as our content even after we said we couldn't publish it
- we should remove this and I should ignore it now
-
- this has the correct copyright claim
- this is not part of UTG; it's just republished from nucc as a service to the community
- it is what is loaded on tx.fhir.org
- it has the correct codes, but the one in UTG that is wrong is hiding it, and producing the spurious errors
Grahame Grieve (Jul 29 2020 at 22:55):
so the code system is not unknown to the server, and the value sets would be expanded correctly if UTG didn't have the erroneous definition of the code system.
Grahame Grieve (Jul 29 2020 at 22:55):
I don't think we need to wait for HTA to decide to remove the offending code system from UTG: it shouldn't be there by HTA policy and by our previous decisions
Grahame Grieve (Jul 29 2020 at 22:56):
we do not need to add the X12 stuff to UTG either. We can, but we don't need to; we just need to get the code systems loaded on tx.fhir.org with the appropriate licensing
Grahame Grieve (Jul 29 2020 at 22:57):
so, your analysis that followed is all based on the first of the 3 resources, and doesn't consider the second
Ted Klein (Jul 29 2020 at 23:22):
Oh criminal thanks for researching this. Duh. So much dross from v3 that was imported. I will remove that second one ASAP clearly it is bad. I see the harmonization cycle where it was added years ago also. Sigh. The first one should be retired/removed as well - I will make sure all of the value sets have the correct canonical URL for NUCC so they do not erroneously reference the other two bad ones. Technically, by the vocab policy, I should to just removed them, they should be retired with the comment that they were erroneous. I should remove the OID identifier elements from the as well I think. Will that mask it from your server and Publishing operation?
Ted Klein (Jul 30 2020 at 00:48):
ok removing and fixing all this...but introduced many new errors. I think your special handling of the URL http://nucc.org/provider-taxonomy is causing some issues, especially since the manifest wants an entry for it in the tab of External code systems referred to in the IG. Something I perhaps do not understand...there is an entry for <parameter>
<code value="special-url"/>
<value value="http://nucc.org/provider-taxonomy"/>
</parameter> in the IG but still error "List/external-Rendering: List.entry[16].item (l121/c11) error Unable to resolve resource "http://nucc.org/provider-taxonomy". " breaking for dinner I'll look at this later and see if I can get it wound up tonight.
Ted Klein (Jul 30 2020 at 02:36):
Do you think that the code system resource that you have above in #3 (nucc-provider-taxonomy.json) should be imported to UTG?
Ted Klein (Jul 30 2020 at 03:53):
ok I did a bunch of fixes and committed them - still 40 or so errors on value sets trying to enumerate codes in NUCC. If you get a chance, let me know what else needs to be done?
Grahame Grieve (Jul 30 2020 at 04:05):
I think that it shouldn't be imported to UTG. UTG is governance and publishing. So that anything that HL7 should publish, should be in UTG. If it's simply making content available to the ecosystem, then we shouldn't put it in UTG - we should put it in the terminology support package
Grahame Grieve (Jul 30 2020 at 04:05):
you committed to UTG?
Ted Klein (Jul 30 2020 at 04:08):
yes my changes all are pushed to ci 1.0.24
Ted Klein (Jul 30 2020 at 04:08):
good night I am beat here
Grahame Grieve (Jul 30 2020 at 06:01):
the issues with nucc relate to this:
<include>
<system value="http://nucc.org/provider-taxonomy"/>
<filter>
<property value="concept"/>
<op value="is-a"/>
<value value="111N00000N"/>
</filter>
</include>
Grahame Grieve (Jul 30 2020 at 06:01):
what is this code?
Rob Hausam (Jul 30 2020 at 11:43):
This is what I found:
PROVIDER TAXONOMY CODE
111N00000N
PROVIDER TAXONOMY DESCRIPTION TYPE AND CLASSIFICATION
Chiropractors-Chiropractor
PROVIDER TAXONOMY DESCRIPTION SPECIALIZATION
N/A
Ted Klein (Jul 30 2020 at 12:39):
These codes were inserted into V3 by request of someone who claimed they were accurate; the old harmonization process took on faith that submitters knew what they were talking about. If codes are wrong, they need to be fixed - but they have been used in v3 based systems for many years.
Ted Klein (Jul 30 2020 at 12:43):
@Rob Hausam So this code is, in fact, part of NUCC provider taxonomy as published by NUCC and should be valid?
Rob Hausam (Jul 30 2020 at 12:52):
Yes, that's how it appears to me. I assume it's still present and the same in the latest version (but I'm not completely confident that I've verified it to that level).
Ted Klein (Jul 30 2020 at 15:05):
Well we need to do that; the errors might be because the server does not have the correct content or there might be some more subtle thing going on. @Grahame Grieve Can we run this to ground?
Robert McClure (Jul 30 2020 at 15:45):
@Rob Hausam Not sure why you would say that it is in NUCC. What are you basing that on? Neither of the two codes listed in the comments above are in the current version (20.0) of NUCC:
</compose> and the code 1223P0700Y is not in the v3 code system stub for NUCC or anything
** Code 1223P0700Y does not exist. 1223P0700X does exist with description "Prosthodontics"111N00000N - Chiropractors-Chiropractor
** This code does not exist. 111N00000X does exist with the description "Chiropractor"
@Ted Klein @Grahame Grieve So it seems the code system has changed from whatever you all are using. We need to be very cautious about making presumed statements on truthful content in externally defined code systems as this constantly gets us into trouble.
I'm working on getting some clarity for NUCC grouping codes and also clarity on how we can get ongoing access to it. We will have this problem frequently if we make "needed" content we do not have control over available in tx.fhir.org
Ted Klein (Jul 30 2020 at 18:25):
Sigh. I the meantime until you get this all straightened out Rob M, I have 40 errors in the UTG build, all for the v3 codes added for the HIPAA message guide a number of years ago. I really want to get a clean build for UTG...how are we going to proceed? And on what timeline?
Grahame Grieve (Jul 30 2020 at 19:59):
well, we appear to have 2 options:
- fix what we can to the right codes and otherwise go ahead with errors in UTG
- add the wrong codes that we can't fix to the terminology support version of the provider taxonomy while we wait
Ted Klein (Jul 30 2020 at 20:48):
I favor the first option, and we try to contact the folks who can correct errors. The big unknown to me right now is why Rob Hausam found the offending codes in NUCC, but you don't have then and Rob McClure thinks it is not right either. WTF? I think first we need to precisely describe and quantify the problem, ie what is missing from where, or wrong and needs correcting. I am worried if we take your second option, the error will become buried and lost in the sands of time.
Ted Klein (Jul 30 2020 at 21:06):
Doing a bit of research on the NUCC site, it appears that at some point in the past, the last character of the code values was changed from "N" to "X". All of the v3 code values in the enumerated value set definitions end with "N". Upon cursory examination of a handful of them, the rest of the code string looks identical. This beast was added to the v3 coremif in 2009. The content was from earlier than that...and the NUCC site makes the old content available only back to 2009. If a change was made that would account for it. It is very possible that back in 2009 the content was added from the UMLS copy of the provider taxonomy as much of that was being done back then - this predates my taking over the harmonization stuff. So we have a Situation where all of our older codes have been changed.
Grahame Grieve (Jul 30 2020 at 21:07):
well, can we just fix them in the UTG source?
Ted Klein (Jul 30 2020 at 21:39):
Not a hard editorial fix - the issue is that what about any systems or data out there that has used these old codes? They have been published this way in the v3 normative editions for over 10 years now. I am a bit at a loss of the best way to deal with this.
Ted Klein (Jul 30 2020 at 21:40):
It might be that common alternative source (UMLS maybe?) has these codes with the "N", perhaps that is what Hausam used to find it and state that it was accurate.
Grahame Grieve (Jul 30 2020 at 21:42):
given that it's them that changed the codes, not us, then the way to handle this is put an entry in the UTG release notes saying that we've updated for changes, and implementers may need to review their implementations accordingly
Ted Klein (Jul 30 2020 at 21:47):
I'm not sure they changed them, I am thinking more likely that whoever added them to v3 used a different source as NUCC was not making any machine readable data available back then. All source I can find in the last 10 minutes of searching all use the "X". I am liking your suggestion...the problem is smaller since HTA ordered us to remove the code system content so this is only three dozen or so value sets that have enumerated codes in them. But there exists Vocabulary WG policy on such CLD changes...I need to make sure we are not running afoul of things in a way that will make the problem worse.
Ted Klein (Jul 30 2020 at 21:51):
Right now I am trying to get agreement with the vocab chairs that we just make the change to the ValueSet.compose messes, and update the versions of the value sets, and document the issue in detail in the Provenance resources so it shows up in the History.
Last updated: Apr 12 2022 at 19:14 UTC
