structural roles vocabulary

[Richard Franck <Richard_Franck@us.ibm.com>]

Hello one final time (for today),

this last thread is about structural roles. Let me start by describing the evolution of the value set that is listed in the NHIN Authorization Framework document:
1. We started with a spreadsheet created by the VA that attempted to map the structural role vocabulary from ASTM to NUCC codes. I no longer have that spreadsheet on my computer, but I bet Tony and/or Mike do. In any case, this spreadsheet adopted a convention to deal with the fact that NUCC does not define codes for "categories" of roles, but only for "leaf nodes" in the role hierarchy. This convention was to replace with an "X" the digits in an NUCC code that differ between "sibling" roles that ASTM does not differentiate.

So, for example, NUCC defines:
231H00000X Speech, Language and Hearing Service Providers
231HA2400X Speech, Language and Hearing Service Providers, Assistive Technology Practitioner
231HA2500X Speech, Language and Hearing Service Providers, Assistive Technology Supplier

These are represented in a single role "audiologists" as 231HXX.

2. I believe (Tony may be able to clarify a bit) that some rows from the VA spreadsheet were either omitted or "rolled up" into a more general role.

3. This early version was problematic in a couple of respects:
a) There are a significant number of ASTM roles that do not have a suitable code in NUCC, and
b) There may not be a precise mapping from an acutal NUCC code to the shorthand convention adopted by the VA and found in the earliest versions of the Authorization Framework. Thus, even for an organization that uses NUCC codes internally, there would still be required a manual mapping to the specified code.

4. A proposal to use SNOMED CT codes instead of NUCC was adopted by the NHIN Cooperative technical committee. I was able to find on my hard drive an earlier version of the Authorization Framework specification that shows both the NUCC codes and the SNOMED CT codes. (I deleted the "description" column from this table to make it more compact. See attachment) I can see that a later version must have added a few additional roles and codes, including "patient", "patient advocate", and "public health officer". There are a few roles in this list where the SNOMED column says "to be defined as a SNOMED CT extension". In the end, we decided that the value set was getting a bit too long and unwieldy, and that those roles could safely be subsumed by other roles, primarily "administrative healthcare staff".

Turning to the memo from Steve Connolly ("Analysis of Structural Role Value Sets"), I'm not going to do a line-by-line comparison of the ASTM list to the NHIN-adopted value set (my train is about to arrive at my destination), but the major categories that he identified as not being represented in the NHIN value set are:
- Transcription personnel
- Supervisory Personnel
- Health Records
- Financial Services/Billing and Claims
- Accrediting and Regulatory Agencies
- Administrative Management.

Many of those were originally identified as "to be created as a SNOMED extension", and I would map all of those roles to Administrative healthcare staff - 224608005. With the possible exception of Transcription, which I would map to Philologist, translator AND/OR interpreter -- 106330007 (admittedly not an exact match).

So that is my rationale for how the NHIN value set covers the complete list from ASTM-1986. Discussion welcome. But I will stand firm on the principle that the XSPA profiles should not be adopted with an unspecified value set -- that does nothing to further the cause of interoperability.

Regards,

Richard Franck
Certified IT Architect, IBM Global Business Services
Healthcare and Life Sciences
office: 1-919-254-4771
mobile: 1-919-302-3880
e-mail: Richard_Franck@us.ibm.com
(See attached file: Roles_from_Authorization_Framework V1.6.1.doc)

Roles_from_Authorization_Framework V1.6.1.doc