April 27th, 2010 Security Conference Call

Security Working Group Meeting

Back to Security Main Page

Attendees

• Chirag Bhatt
• Bill Braithwaite, MD
• Jim Buckner
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Michelle Johnston
• Jim Kretz
• Milan Petkovic
• Ioana Singureanu
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve minutes 20 April 2010, Call for additional agenda items & Accept Agenda
2. (55 min) Security and Privacy Ontology Project
   • (Steve Connolly - 10 min) Introduction to S&P Ontology use cases for the Security & Privacy Ontology which illustrate the use hierarchical structures in access control vocabularies
     • Please review prior to the meeting if you have time. Feel free to present additional use cases as well.
   • (45 min) Follow up on questions from last week's meeting (other questions or topics may be presented during call for additional agenda items)
   1. Can OWL and Protégé be used to model/test decision-making process in Mike’s test lab or inside any Access Control Service (ACS).

• Ongoing Projects
• PASS Audit Update
• US Realm Value Sets

Minutes

1. Action Items

Reminder: Composite Security and Privacy Domain Analysis Model ballot is now open until May 9th. Please vote!

3. Updates/Discussion

Pass Audit Update

• The Monday 4/26 PASS call was canceled this week, but we are working at getting the PASS Audit Platform Independent Model published for peer review this week. Expect to see an announcement on the PASS Group list when a new draft of the document is ready for review.

Security and Privacy Ontology Project

• Steve presented the Security & Privacy Ontology use cases which illustrate the function of the hierarchical structure. So far, the focus of these use cases has not been on interoperability since the scenarios take place within a single health care provider, but this is a feature that should be added as we progress.
  • Start with the Actions/Operations. This gives a sense of how a hierarchical structure of actions can be used in access control. . This does not determine or establish a hierarchical structure; it just demonstrates how such a structure would be used
• Use cases from the VA (Structural Roles) have also been taken into account as well as the operations vocabulary from RBAC where a hierarchical structure introduced but was not balloted.

---

• Use Case One
  • Explicitly provides permissions to use a particular operation. This tells the access control decision point that all operations that are subsumed by that particular operation are also allowed.
• Use Case Two
  • Category of object: This assumes that if we have a hierarchical structure of objects, if someone is granted permission to a category of objects, say the rather broad category of a clinical note, then they are granted permission to access all the objects categorized under that head object.
• Use Case Three
  • A hierarchy of roles – in this case, structural role.
• Use Case Four (not yet posted)
  • This use case refers to the category of functional role

---

• There is not a lot in the established standards on structural and functional roles. ASTM has two levels of structural roles and but standards describing functional roles are even sketchier. In these use cases, the definitions for structural and function roles come from ISO 21298
• If we agree that a hierarchical structure for vocabularies is useful, the next step is to roll up our sleeves and start creating the hierarchical structures.
  • Tony has already started this with the Operations vocabulary.
• There are a number of different approaches that can be used for creating the hierarchical structure. Most of the existing work on objects has been to categorize objects in terms of the subject, e.g., radiology documents artifacts would fall under the radiology domain. This may not be all that useful for Security however.
• Suzanne: How are we going to approach categorization for Security? Is there information out there that would be useful to the Security domain?
• Tony: To some extent, categories are useful for organization purposes, for example, radiology objects. It’s plausible that some permissions will be granted based on affiliations with departments. So you might want to prevent someone who is not in the radiology department from operating on radiology-specific objects.
• Suzanne: So will we be creating this list of categories?
• Steve: We can start with the flat vocabulary list from RBAC. I think we can establish two fairly high level categories: administrative artifacts and clinical artifacts. This provides some value for access control. It’s the next level down that we have to get to. We can start by categorizing these along the subject matter – the clinical departments for example.
• Jim Krentz expressed concerns that categorizing objects under their clinical departments could create issues. This is because you can easily have a radiology object that is generated by a different department. There is some confusion about who is doing what when. It is not unusual to have a reproductive endocrinologist performing radiological procedures. If you look through the fee schedule published by Medicare, reimbursement varies depending on the sub-specialty of the provider performing the same procedure. This presents a different type of use case that should be taken into consideration for this ontology.
• Steve: We may decide that for Security, it doesn’t make sense to further categorize clinical objects and instead provide a flat list of clinical objects and say this is as far as we want to take it.
• Tony: I think we should distinguish between build-time use cases and run-time use cases.
  • Organizationally when you’re selecting types of objects to grant or deny permissions, the fact that they’re categorized allows you to find the ones you’re interested in working with efficiently, independent from how you decide whether someone can access them or not.
  • At build time, someone has to make policy decisions about who can perform what operations on what objects. To efficiently find the objects you want to grant permission to, it is easier to navigate a hierarchical organization for picking and choosing during the authoring process than performing a sequential to search through the whole list or trying to remember the name of hundreds of possibilities.
  • At run-time, when somebody tries to perform an action, the security system has to decide whether or not to allow it.
• Steve: What categories would be the most valuable for access control?
• Jim: It’s one thing to classify objects in terms of their specialty areas, it’s quite another to grant access on that basis. That’s a structural view of how healthcare is organized, as opposed to a functional one – who did it, who’s caring for the patient.
• Steve: This is a good point. There are other filters than the hierarchal structure of objects that can be used for access control. I invite people on this call to submit additional use cases.
• Suzanne: Do you want us to send use cases for each of the structural roles? I’m not sure whether you are asking for more general use cases or more specific roles.
• Steve: The use cases drive the requirements for the Security & Privacy ontology. One of the features is hierarchical structure. So we need use cases that drive the creation hierarchical structure, categories. **Currently, we have a flat list of objects and operations. So we need to look at what are the benefits of creating a hierarchical structure.
  • We could also introduce this hierarchical structure into Purpose of Use, but that might not be as compelling at this point.
  • Where this becomes most useful is with the objects list which is currently over one hundred. Providers could use these categories to say grant access according to the fact this is a clinical object or that everything in this category is a clinical object.
  • There are also more instance related use cases. For example, a pharmacist needs access, but they’re not in the right category.

Follow up questions about Protégé and OWL

• During last week’s meeting, Richard asked two questions:

1. How can OWL and Protégé be used to make decisions, at least in the sense of testing out the model for the ontology independent of whether you want to do that in a fielded security system.
2. Richard also had a question about how Mike was doing things in his lab.

• Mike: A couple of years ago a PhD candidate modeled RBAC version 1 in Protégé. I can’t recall all the details, but the gist of the discussion at the time was that modeling in Protégé could lead directly into an implementation of access control. I don’t know exactly how this works, but perhaps Tony can elaborate. But it sounded like Protégé could somehow be connected directly to an access control engine and the ontology could be used to make decisions.
• Tony: I think that’s correct. Heading in that direction, I’ve prepared an example that we could take a look at here.
• Mike: Before we get to that, as far as what is currently going on in the VA lab, we don’t implement a hierarchical system. The system has primarily been used for demonstration purposes, it is not fully operational. The roles are very simple – clinicians and nurses. The objects we’re dealing with are primarily C32 type messages. We haven’t gone into great detail managing all of the potential objects in the Permissions Catalog. One of the reasons we’re engaged in this work is because there is a recognition that this is complex. Currently, the lab does not have experience managing the full 100-something objects in the Permissions Catalog.

Access Control Decisions in Protege with OWL

Tony presented simple examples illustrating the use cases to show how different RBAC items modeled in OWL and Protégé can be used to grant or deny permissions

• Classes are represented in rounded rectangles
• Squared rectangles represent OWL Individuals (instances of classes). Instance names are prefixed with an underscore to distinguish Individuals from Classes in Protégé
• An example: Objects are specialized into Order objects and further specialized into Lab Order Objects
• Permissions allow certain operations to be performed on certain kinds of objects
• The diagrams in this presentation do not show all the details of OWL modeling. The advantage of these diagrams is to show how things are related but it is not possible to capture all of the nuances of the OWL representation and still have the same visual appeal.
• Podunk Grant 1 represents a positive decision based on Description Logic reasoning with OWL
• Podunk Grant 2 represents a negative (denial) decision
  • By modeling the two individuals and running the classifier, you can see in the inferred hierarchy that one successfully classifies under Podunk Grant 1 and the other is unsuccessful and is therefore represents a denial.
  • By using the Reasoner, it is possible to find the right connections/relationships. You’re either proving that the request is valid or failing to approve, meaning that the request is invalid.
• Build time versus Run Time
  • During Build-time, the ontology is modeled which includes all the classes. Think of build-time as a way of testing out the model, a way of demonstrating that the ontology can support the kinds of permissions in the RBAC. Using Protégé, individuals can be created and you test whether the request can be approved or denied
  • It is also possible to build a Run-Time Security system using Protégé,to run the Inferencer and use that to decide at run-time whether to grant or deny permissions. While this is possible, this is not to say this is a recommendation way to use of Protégé. Instead, Protégé can be used to test the ontology by using queries against specific instances
• The primary goal of an ontology is to be able to model classes of interest and to define their relationships, generalizations and specializations. While you can do decision making inside Protégé, and while it may be a good idea for focused cases like access control decisions, I wouldn’t want to try to implement everything you can do within a secure EHR system inside Protégé with OWL.
• Another value for an ontology developed by a standards organization is that it provides a common vocabulary for talking about things. Different organizations and vendors might implement systems in different ways, but using the ontology can refer to things in the same way because names are taken from the same source – the ontology.

---

The presentation was completed at 2:00 PM EDT, and the meeting adjourned to move into the CBCC hour.

No significant motions or decisions were made.

Back to Security Main Page