This wiki has undergone a migration to Confluence found Here
Difference between revisions of "September 7th, 2010 Security Conference Call"
Jump to navigation
Jump to search
Finaversaggi (talk | contribs) m (→Attendees) |
Finaversaggi (talk | contribs) |
||
| Line 41: | Line 41: | ||
No update today, but this ballot is now open. Please sign up to vote. | No update today, but this ballot is now open. Please sign up to vote. | ||
====Security & Privacy Ontology Project==== | ====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. | |
| − | + | *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. I have to drop off the call for a few minutes but will be back toward the end of this call. | |
| − | + | **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 concepts, there are only about 120 RBAC objects, so it won't take long to find the best mapping or to determine that none exists. | |
| − | + | **Jon: I think that Mike's intent was for a given RBAC item would function as a container for multiple LOINC items, and that each LOINC item would function as a container for multiple SNOMED concepts. | |
| − | + | **Tony: If the RBAC object catalog had sufficient granularity we could map from LOINC to RBAC to promote interoperability using LOINC codes. If, on the other hand, RBAC wasn'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. | |
| − | + | **Jon: This would drive improvements in the RBAC catalog list which is potentially valuable. | |
| − | + | **Tony: To embark on any effort, you need to be clear about what task you are trying to accomplish, and I'm still not clear on the objective. | |
| − | + | **Jon: I think what Mike is look for in terms of volunteers, is to map RBAC objects to LOINC and that anything that comes out as a gap could drive an improvement. (Not clear as to whether improvements to RBAC are part of Mike's intended scope for this effort however.) | |
| − | + | **Tony: If you want to use LOINC to find gaps in RBAC you'd need to attempt to map LOINC objects to RBAC to find out whether or not there are counterparts in RBAC. | |
| − | + | *Jon: There is a particular weakness for using RBAC (to try to control access to healthcare objects) - to the extent that the RBAC catalog is not about findings or diagnoses which is what the patient would be talking about when referring to their privacy preferences. | |
| − | + | **Mike rejoined the call and pointed out that there are many classes in the Security and Privacy information model that will be taken into account for access decisions, and we've only started with the Role class for this ontology. It is expected that other dimensions (classes) of the information model that we're not looking at here will address that concern. | |
| − | + | **SNOMED-CT is not a Security vocabulary and there are existing Security vocabularies. We are trying to control access to health care objects, but Security people should not be the ones defining health care objects, but this is something that we've been in discussion with SNOMED and IHTSDO about. They have indicated willingness to incorporate some of our activities with SNOMED CT when we get to some level of maturity of our work. This is an ultimate goal for us (in the future), because the security arena doesn't want ownership for managing health care objects. But right now this out of scope of the current project. There is a vision that at some point we would be able to approach SNOMED-CT with more of a goal, which meets their goal to be the defining healthcare ontology for ‘everything’; they might as well have security stuff as well. | |
| − | + | **So the task is to do to mapping. Suzanne will be happy to assist in this task based on her RBAC background in doing this. We might set this up as a separate call or via email, but we should jump in and do this mapping and then report back to this work group (at some future date). | |
| + | **We first need to know who will participate in this effort. If you're interested please send Mike.Davis@va.gov, SUZANNE.L.GONZALES-WEBB@saic.com or Serafina@eversolve.com an e-mail to let us know you would like to be a contributor. | ||
| + | ---- | ||
| + | '''Ontology Updates:''' | ||
| + | ---- | ||
Tony has posted the [http://gforge.hl7.org/gf/download/docmanfileversion/5828/7511/Ontologies.zip first draft] of the Security-Privacy Ontology expressed in OWL 2 and suitable for viewing with the Protégé 4.1 OWL Editor. | Tony has posted the [http://gforge.hl7.org/gf/download/docmanfileversion/5828/7511/Ontologies.zip 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 [http://gforge.hl7.org/gf/download/docmanfileversion/5829/7512/HL7SecurityandPrivacyOntologyUpdate.doc Word document] with screen shots and other information. | *In addition, for those who are not using Protégé, there is a [http://gforge.hl7.org/gf/download/docmanfileversion/5829/7512/HL7SecurityandPrivacyOntologyUpdate.doc Word document] with screen shots and other information. | ||
| Line 103: | Line 107: | ||
---- | ---- | ||
No significant motions or decisions were made. | No significant motions or decisions were made. | ||
| + | |||
[[Security|Back to Security Main Page]] | [[Security|Back to Security Main Page]] | ||
Revision as of 00:52, 14 September 2010
Contents
Security Working Group Meeting
Attendees
- Ed Coyne
- Mike Davis Security Co-chair
- Jon Farmer
- Suzanne Gonzales-Webb CBCC Co-chair
- Michelle Johnston
- Vannak Kann
- Jim Kretz
- Milan Petjovic
- Ken Salyards
- David Staggs
- Cliff Thompson
- Richard Thoreson CBCC Co-chair
- Serafina Versaggi scribe
- Tony Weida
- Craig Winter
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
- Team: #**Please let is know if you would like to participate in an effort to map the RBAC objects to LOINC. If interested, please send Mike.Davis@va.gov, SUZANNE.L.GONZALES-WEBB@saic.com or Serafina@eversolve.com an e-mail to let us know you would how you would like be contribute.
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.
- 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. I have to drop off the call for a few minutes but will be back toward the end of this call.
- 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 concepts, there are only about 120 RBAC objects, so it won't take long to find the best mapping or to determine that none exists.
- Jon: I think that Mike's intent was for a given RBAC item would function as a container for multiple LOINC items, and that each LOINC item would function as a container for multiple SNOMED concepts.
- Tony: If the RBAC object catalog had sufficient granularity we could map from LOINC to RBAC to promote interoperability using LOINC codes. If, on the other hand, RBAC wasn'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.
- Jon: This would drive improvements in the RBAC catalog list which is potentially valuable.
- Tony: To embark on any effort, you need to be clear about what task you are trying to accomplish, and I'm still not clear on the objective.
- Jon: I think what Mike is look for in terms of volunteers, is to map RBAC objects to LOINC and that anything that comes out as a gap could drive an improvement. (Not clear as to whether improvements to RBAC are part of Mike's intended scope for this effort however.)
- Tony: If you want to use LOINC to find gaps in RBAC you'd need to attempt to map LOINC objects to RBAC to find out whether or not there are counterparts in RBAC.
- Jon: There is a particular weakness for using RBAC (to try to control access to healthcare objects) - to the extent that the RBAC catalog is not about findings or diagnoses which is what the patient would be talking about when referring to their privacy preferences.
- Mike rejoined the call and pointed out that there are many classes in the Security and Privacy information model that will be taken into account for access decisions, and we've only started with the Role class for this ontology. It is expected that other dimensions (classes) of the information model that we're not looking at here will address that concern.
- SNOMED-CT is not a Security vocabulary and there are existing Security vocabularies. We are trying to control access to health care objects, but Security people should not be the ones defining health care objects, but this is something that we've been in discussion with SNOMED and IHTSDO about. They have indicated willingness to incorporate some of our activities with SNOMED CT when we get to some level of maturity of our work. This is an ultimate goal for us (in the future), because the security arena doesn't want ownership for managing health care objects. But right now this out of scope of the current project. There is a vision that at some point we would be able to approach SNOMED-CT with more of a goal, which meets their goal to be the defining healthcare ontology for ‘everything’; they might as well have security stuff as well.
- So the task is to do to mapping. Suzanne will be happy to assist in this task based on her RBAC background in doing this. We might set this up as a separate call or via email, but we should jump in and do this mapping and then report back to this work group (at some future date).
- We first need to know who will participate in this effort. If you're interested please send Mike.Davis@va.gov, SUZANNE.L.GONZALES-WEBB@saic.com or Serafina@eversolve.com an e-mail to let us know you would like to be a contributor.
Ontology Updates:
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.
Meeting was adjourned at 2:00 PM EDT
No significant motions or decisions were made.
