Thanks Richard. I think we have a plan going forward to
provide complete coverage by using SNOMED CT codes to enumerate the ASTM E1986 “Persons
for Whom RBAC is Warranted”.
BTW, I am the lead for the internal VA effort dealing with RBAC
in healthcare that you mention. I don’t happen to agree with your explanation/conclusions
of our internal VA efforts, NUCC codes, xxx notations etc. In any
case, this is separate from discussion of Standards Development
Organization efforts in ISO, ASTM and HL7 to advance RBAC vocabularies for use
in healthcare security systems.
One thing that you may not know is that this process has been
under discussion for a number of years within the Standards Development
Organizations, and it was the consensus of experts at a number of cross SDO
calls at the time to specify ASTM 1986 “Persons for Whom Role Based
Access Control is Warranted”. My discussion with Tony from the
beginning involved conveying that. ASTM also recognized the need to enumerate
the ASTM value set and are doing so. The E31 Co-chair and other active committee
agreed to accomplish this enumeration quite some time ago which is now moving
forward on a priority basis. I don’t expect this update to be a
major undertaking and is an excellent approach.
Regards, Mike Davis, CISSP
Department of Veterans Affairs
CHIO Emerging Health Technologies
Security Architect
760-632-0294
From: Richard Franck
[mailto:Richard_Franck@us.ibm.com]
Sent: Thursday, June 25, 2009 8:37 AM
To: xspa@lists.oasis-open.org
Subject: [xspa] structural roles vocabulary
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)