September 7th, 2010 Security Conference Call

Security Working Group Meeting

Back to Security Main Page

Agenda

1. (05 min) Roll Call, Accept Minutes August 31st Security Work Group, Call for additional agenda items & Accept Agenda
2. (05 min) Pat Pyette - PASS Audit Update
3. (05 min) John Moehrke - John’s updates regarding the Risk Assessment
4. (50 min) Security and Privacy Ontology project
   • Security Ontology discussion on LOINC table mapping to RBAC objects. Table provides a connection from the ontology to portions of (possibly) SNOMED CT which is part of the project scope.
   • Updates from Tony.

Minutes

1. Action Items

• Tony: Request administrative privileges to update GForge.
  • Mike to approve once request has been submitted
• Mike: Will check with VA terminologists about whether LOINC clinical object codes have been linked to SNOMED-CT

3. Updates/Discussion

PASS Audit Update

No update today, but this ballot is now open. Please sign up to vote.

Security & Privacy Ontology Project

1. LOINC to RBAC discussion:
   • This discussion related to examining the LOINC objects to determine which map to HL7 permission catalog and how they would map to SNOMED CT.
   • The purpose is to determine how we will use the ontology to link a different ontology (a bridge ontologies—which we may use or SNOMED CT directly)
   • Question: Is this a new ontology vs. an update to the current ontology?
     • Yes, we wouldn’t’ necessary put these items in the RBAC catalog directly — instead we should be able to map these terms to the various linkages, e.g., to SNOMED-CT.
   • The premise is that the relationship to SNOMED-CT has been harmonized to LOINC. Mike will check with the VA terminologies to confirm this assumption.
     • The examples used in ASTM-1986-09 have been mapped to SNOMED CT as much as possible.
     • Tony: The UMLS® (Unified Medical Language System), is one source of mapping that we could use in an attempt to extract these relationships to see what it reveals.
       • The UMLS is a meta-thesaurus maintained by the National Library of Medicine (NLM). Its purpose is to facilitate the development of computer systems that behave as if they "understand" the meaning of the language of bio-medicine and health. NLM produces and distributes the UMLS Knowledge Sources (databases) and associated software tools (programs) for use by system developers in building or enhancing electronic information systems.
     • This is very appealing because it would give a linkage from RBAC to these objects at a finer level of granularity. Are there are folks on the call who would like to work as a subgroup on examining this in more detail?
   • Jim Kretz: This listing (from RBAC Permission Catalog) is hardly unique or exhaustive. What does the distinction between laboratories study, pathology or procedure note buy you?
     • Mike: The permission catalog has actions/objects. We have high level objects in the RBAC permission catalog and one of our tasks as part of this project is to map our ontology to another ontology - specifically SNOMED-CT.
     • We’ve looked at SNOMED-CT in the past for instances of objects in the RBAC catalog, but this doesn’t map very well. So we're thinking we should create a bridge technology that would map our ontology to some intermediary which is then mapped to SNOMED-CT.
   • If someone undertakes the task, we will see which are unmappable, exposing our gaps.
     • If these can be mapped into SNOMED-CT, it gives us some level of mapping on an authoritative level. If we define the codes as children of the RBAC objects or parents or equivalents, we will have a desired linkage to SNOMED-CT. Reviewing these in this way may also suggest gaps in the RBAC permission catalog that we would want to address (but this is a secondary task).
     • The mapping may be far from perfect but the exercise may be of value if there are strong gaps. It’s good to say we’ve done the due diligence, even if nothing comes from it.
   • Tony: One of the primary goals of this effort is to set forth the classes of interest that the ontology covers, e.g., a definitive collection of object that operations apply to.
     • There are several potential sources for an authoritative collection of objects we can pull from:
       • RBAC Objects
       • SNOMED-CT Objects
       • LOINC Objects
     • It may make sense, having picked any one of the above, to use the others as sources of information to extend the ontology, as well as providing a mapping between the objects.
     • Then people can see the relationships already available between the concepts and classes in our ontologies and those they have in their systems, e.g., LOINC identifier, SNOMED-CT identifiers and corresponding entries in the ontology. If we are talking authoritative collection of objects, and mappings from that authoritative collection to others, then that is relatively straightforward.
     • If we are talking about picking and choosing from multiple sources in order to arrive at a much larger authoritative collection of objects, that is an extremely large and difficult project. It is difficult to understand how they relate to each other to detect duplication, and relationships that weren't present in 3rd party mappings, etc.
   • Richard: How will access control services could resolve the differences in these different authoritative sources? You can imagine systems being confused if you don't do these mappings.
   • Mike: I agree. If you take just the health care perspective and not just the Security perspective, they're likely to use SNOMED-CT or LOINC or other direct health care standards. But we've looked at those coding systems in the past and they did not provide the proper granularity necessary for Security. If we do this mapping, we provide a more direct linkage, although maybe at a different level, to the health care objects that health care people are referring to. Rather than having them guessing---we provide the mapping, say through SNOMED-CT to the definitive link.
   • Richard: What was driving the level of detail contained in the list of RBAC objects being discussed here (~ 120 objects)?
   • Mike: The level of detail appears to be finer than our objects in the Permission Catalog. We think this is a finer level that could be wrapped up in the objects that we have currently in the RBAC permission catalog. This provides a mapping potentially to SNOMED-CT through LOINC. This is not a list of whole LOINC objects. It’s an extract that was done to meet some of the needs based upon work done by VA and DoD. Th point was to identify shared objects in the health care space.
   • Jon Farmer: Let's make a subset of LOINC that covers the subject matter but is not the exhaustive list of fine grained LOINC codes. You could shoot for full coverage or say, give me the terms that are most referenced. So you don't get full coverage, but you get a lot of utility. If it was extracted from 10 years of operational data, give me the most frequently used terms, but not all the leaf level terms.
     • Mike will investigate with VA and DOD colleagues to see if such a list exists. Not too many terms, but a sweet spot.
     • When we started the RBAC work, we examined LOINC and SNOMED-CT and other standards to see if we could extract a representative set of objects, but this didn't work for everyone.
     • Regardless of defined items, we can define particular objects without breaking the concepts—interoperability at a higher level. What is being showing is lower level (they are standard objects), but not everyone implements LOINC and/or SNOMED-CT in there systems, so this provides a Rosetta stone.
     • We are providing this linkage as part of our project scope. It gives us a connection that would be otherwise very painful for us. If we try to map to a very large collection of objects e.g., SNOMED-CT, would be very painful.
     • The RBAC Permissions Catalog is an interoperability standard - intended for use across enterprises.
     • To the extent that there is already a mapping to LOINC or SNOMED-CT already, we’re providing them with a level of support that we previously didn’t do. The ontology is allowing us to do that.
   • Question: Would the annual updates these code systems (e.g., LOINC and SNOMED-CT) affect what we’re doing here?
     • Even if we were to do this mapping all versions should be stated (LOINC version as well as SNOMED CT version).
     • Tony: SNOMED-CT takes a rigorous approach to remove (not delete) outdated terms. Also duplicates are deprecated, etc.; they provide more help than many terminologies for managing the transition from one version to the next. However, it is necessary to review mappings for any updates when they come out.
   • Mike: I’d like to propose that this be a subtask for our efforts. If there are folks who would like to participate, we'll figure out exactly what that means and how we will do it.
     • Jon Farmer: One approach might be to take a sampling of items and analyze the mappings and see how beneficial the exercise would be.
     • Tony: I'm still not entirely clear what the goal of the exercise is. If the goal of the exercise is to have correspondence between RBAC objects and SNOMED-CT objects, there are only about 120 RBAC objects.

Find the best mapping using the RBAC item, An RBAC item would be a container of using multiple LOINC items.

Not clear on exactly what the objective is here. Are we creating a greater level of specificity? So that people in the end would fine more precise mappings to what people want to control access to.

If RBAC object catalog had sufficient granularity we could map from RBAC to LOINC, on the other hand if RBAC weren’t sufficiently granular and you wanted sources of information for extending them we could methodically go through LOINC and see if this is something we want to add to the RBAC catalog.

Tony has posted the first draft of the Security-Privacy Ontology expressed in OWL 2 and suitable for viewing with the Protégé 4.1 OWL Editor.

• In addition, for those who are not using Protégé, there is a Word document with screen shots and other information.
  • Corresponding wiki entries will be made after Tony Weida obtains proper wiki access.
  • Tony will pass along files to Serafina and Suzanne until he is able to post on GForge.
  • Tony will make a request to join the HL7 Security GForge space. Mike can then approve the addition.

Back to Security Main Page