Stream: argonaut
Topic: NUCC provider taxonomy
Jay Lyle (Nov 07 2018 at 18:36):
NUCC Provider Taxonomy codes have up to three text values, Grouping, Classification, and Specialization. The FHIR publication lists only the last (Specialization) term for each code. In some cases, this is legible, though it may require some inference: it's not a great stretch to infer from "Addiction (Substance Use Disorder)" that the provider is a counselor. In other cases, it's not legible: it's not clear that a "Professional" is a counselor.
@Eric Haas suggested a SNOMED-like axis parenthesis, but I don't see any other discussion since 2017.
How are other implementers handling the rendering of NUCC Provider Taxonomy terms?
Jay Lyle (Jan 31 2019 at 16:53):
@Rob Hausam @Robert McClure any thoughts?
Jay Lyle (Jan 31 2019 at 17:03):
Argonaut PrationerRole.code & specialty are both bound to NUCC Provider taxonomy.
R4 has more general terms for Code and specialties for specialty.
Perhaps we could use the NUCC text 1 for Code and text 2+3 for specialty
E.g.,
Code: 207RR0500X, Allopathic & Osteopathic Physicians
Specialty: 207RR0500X, Internal Medicine - Rheumatology
or
Code: 103TC0700X, Behavioral Health & Social Service Providers
Specialty: 103TC0700X, Psychologist - Clinical
Rob Hausam (Jan 31 2019 at 17:26):
I should brush up on the details of NUCC (I think I've tried to largely avoid it in the past!). Based on what you've said, it seems that NUCC pre-coordinates all three of these "axes" into each individual NUCC code. So if you use an NUCC code for PractitionerRole.code, then you get the code information itself and you also get the specialty information along with it for "free". So, if that's actually the case, then there really isn't any need to additionally populate PractitionerRole.specialty (it's an optional element in US Core - and, of course, if you do also populate it there is always the redundancy and the potential risk of inconsistency). Let me know if anything I've said is incorrect or incomplete (it certainly could be) or seems like it doesn't make sense.
Eric Haas (Jan 31 2019 at 17:49):
For VHDIR I created a set of NUCC Maps to gernerate a bunch of synthetic data....
NUCC to healthcareservice ( my own made up set of services)
NUCC to roles as Jay suggests above
NUCC to SNOMED mapping Incomplete and source VA
Eric Haas (Jan 31 2019 at 17:50):
e.g.,
nucc_healthcareservice_map = {
'101': 'counseling',
'102': 'counseling',
'103': 'counseling',
'104': 'counseling',
'105': 'counseling',
'106': 'counseling',
'111': 'chiroquackery',
'122': 'dentistry',
'124': 'dentistry',
'125': 'dentistry',
'126': 'dentistry',
'132': 'nutrition',
'136': 'nutrition',
'146': 'emergency response',
'152': 'ophthalmology',
'156': 'ophthalmology',
'163W00000X': 'general practice',
'163WA0400X': 'counseling',
...
Eric Haas (Jan 31 2019 at 17:51):
NUCC to role map:
nucc_role_map ={
'101Y00000X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
'101YA0400X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
'101YM0800X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
'101YP1600X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
'101YP2500X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
'101YS0200X': ('101Y00000X', 'Behavioral Health and Social Service Providers'),
....
Eric Haas (Jan 31 2019 at 17:52):
NUCC to SNOMED:
nucc_sct_specialty_map = {
'231H00000X': ('94578005','Audiological medicine'),
'208D00000X': ('394814009 ','General practice'),
'1223G0001X': ('394814009','General practice'),
'163WG0000X': ('394814009','General practice'),
....
Eric Haas (Jan 31 2019 at 17:53):
finally a NUCC to SNOMED role map:
nucc_sct_role_map = {
'231H00000X':('309418004', 'Audiologist'),
'124Q00000X':('26042002', 'Dental hygienist'),
'122300000X':('106289002', 'Dental surgeon'),
'1223S0112X':('49993003', 'Maxillofacial surgeon'),
'133V00000X':('159033005', 'Dietician'),
'163W00000X':('224535009', 'Registered nurse'),
....
Eric Haas (Jan 31 2019 at 18:00):
Can share the file formatted as Python dictionaries not as resources.
Jay Lyle (Jan 31 2019 at 21:09):
The dictionaries look like a nice tactic.
Rob, US Core2 doesn't require either field; Argonauts provider directory requires both.
So we can (a) repeat all 3 (or sometimes 2) labels for both instances of the code, or we can (b) just surface part 1 for code and part 2 (& 3 if present) for specialty. That seems to fit requirements; it is, however, a little klugey wrt the data type design. Are there compelling reasons to go one way or the other, or is this one of those things?
Robert McClure (Feb 12 2019 at 15:59):
Sorry for avoiding this for so long...
NUCC has "three levels" in it's taxonomy: Grouping, Classification, Specialization. They only assign unique codes to Classification and Specialization concepts (ie: There is a code for Chiropractor -111N00000X (or Chiroquackery for Eric ;-) and there is a different code for "Neurology" that is a Chiropractor - 111NN0400X. There is no code for the Grouping of chiropractic - "Chiropractic Providers" but as Eric has figured out, they use a consistent start to all the codes in a group, 11xx for Chiropractic. Sometime (true for Chiropractic) there is consistency across the first 4 characters in a Group (111N here) but for other Groupings only the first two characters are the same and the other two increment across what I assume are considered sub-Groupings (or they just need more numbers - hence the value of "meaningless Ids.) Of note, they have multiple "codes" with the same "specialization" description - ie: there are more than one "neurology" code. NUCC does not officially (or if they do now, perhaps it's because I've complained...) have an official way of packing together the Classification & Specialization text to get a unique description.
Jay Lyle (Feb 12 2019 at 17:06):
That sounds like an accurate description of the problem.
I haven't heard any complaints about my proposed solution: concatenating all three (or sometimes 2) labels.
Or about the more detailed and possibly problematic one: using just the first label when the code is used for PractitionerRole.code ("Roles which this practitioner may perform") and the 2nd (& 3rd if present) for PractionerRole.specialty ("Specific specialty of the practitioner").
Grahame Grieve (Feb 13 2019 at 11:40):
Grahame Grieve (Feb 13 2019 at 11:40):
is there a problem with that?
Brian Postlethwaite (Feb 14 2019 at 10:57):
Can the nucc be included in the VhDir as an example set without copyright issues?
Jay Lyle (Feb 14 2019 at 18:26):
Well, it looks like a reasonable approach for fitting the NUCC structure into a JSON structure, but it's different. What would the value set look like?
You can represent NUCC multiple labels in JSON by using a hierarchy, but
a NUCC doesn't define a "base-1" code
b the display you get back using a simple query is incomplete
c you can fix (b) but you have to to walk up the tree to do it
d it's still not obvious what goes in coding.display.
Does Vocab have a problem with (a) or (b)? Do implementers have a problem with (c) or (d)?
I think our transform guidance to generate the resources is going to suggest concatenation for (d).
Robert McClure (Feb 14 2019 at 19:03):
Graham's package is an accurate edition of the published content. I will go on record saying that to include this is a "commercial product" we MUST do the following - Graham, have you done this?:
Vendors must request a license to include this in a product per the following: “Vendors interested in incorporating the Health Care Provider Taxonomy code set into their commercial products must complete the license request form found on the CSV page.” Using the form at the url listed. The preamble is reproduced below: http://www.nucc.org/index.php?option=com_content&view=article&id=111&Itemid=110."
Jay pointed out something that I left out of the comment above - that the first level "Grouping" phrase does not have an assigned NUCC code. Basically the code system, as published, is a PITA due to poor descriptions and complicated meaningful identifiers. Now this code system is defined by the NUCC but is maintained and distributed (for free!) by the AMA. Here is the real question - can we "enhance" the content of the code system within our use so that we determine a code for the Grouping phrase (say "10" for "Behavioral Health & Social Service Providers" and so on) and can we also provide a second description that packs together all the pieces into a single fully specific "full" description? We could add the full description using a "code system supplement" if we wanted to do this correctly. But to add a code for the Grouping we'd need to either declare this a new FHIR code system, pretend we owned it and simply add the codes, potentially as a code system fragment. Or we can find the person responsible and see if they will fix things. I tried that in the distant past and didn't get far.
Eric Haas (Feb 14 2019 at 19:48):
I think we can include with the copyrighted text. is VHDIR a commercial product?
Brian Postlethwaite (Feb 14 2019 at 20:55):
I mean the hl7 vhdir implementation guide as an example.
Grahame Grieve (Feb 17 2019 at 13:19):
I updated the copy right. My take is that we can publish a new code system with the extra concepts, and a code system supplement that adds a property to the NUCC concepts for the grouping code
Last updated: Apr 12 2022 at 19:14 UTC
