This wiki has undergone a migration to Confluence found Here
September 7th, 2010 Security Conference Call
Revision as of 17:39, 13 September 2010 by Finaversaggi (talk | contribs) (→Security & Privacy Ontology Project)
Contents
Security Working Group Meeting
Attendees
Agenda
- (05 min) Roll Call, Accept Minutes August 31st Security Work Group, Call for additional agenda items & Accept Agenda
- (05 min) Pat Pyette - PASS Audit Update
- (05 min) John Moehrke - John’s updates regarding the Risk Assessment
- (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
2. Resolutions - none
3. Updates/Discussion
PASS Audit Update
No update today, but this ballot is now open. Please sign up to vote.
Security & Privacy Ontology Project
- 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.
- There are several potential sources for an authoritative collection of objects we can pull from:
- 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.
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.