This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

May 11th CBCC Conference Call

From HL7Wiki
Jump to navigation Jump to search

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes May 4th CBCC WG Meeting, call for additional agenda items & Accept Agenda
  2. (55 min) Ongoing Projects Update
    • Privacy Policy Reference Catalog

Minutes

1. Action Items - none

2. Resolutions

  • White paper describing the Privacy Policy Reference Catalog will include diagram(s) to help clarify the relationship between the Composite Security and Privacy Domain Analysis Model, the Security & Privacy Ontology and the catalog itself

3. Updates/Discussion

Privacy Policy Reference Catalog

  • No specific update for the Privacy Policy Reference Catalog project this week.
  • Richard suggested that we continue the previous hour discussion on the Ontology and its purpose since the ontology is relevant to the Policy templates.
  • Pat requested that the scope of the ontology project be clarified since based on the previous hour, it appears that one aspect of the Security & Privacy ontology project he thought was important now seems to be out of scope – that of the ability to convert privacy language to security language so that when we talk about disclosure for something, disclosure can be enforced. To accomplish this, there must be a mechanism for transforming the concept of (privacy) disclosure to one or more security concepts that can be put into an executable policy
  • The group decided to relinquish the CBCC hour to continue the Ontology project discussion.

Security & Privacy Ontology Project – continued

  • The conversation continued, but the discussion was somewhat convoluted and ultimately there was a request that someone create a graphical representation to help clarify the relationship between the Security and Privacy Ontology and the Security & Privacy Domain Analysis Model and Privacy Policy Reference Catalog projects
    • Is the scope was being limited solely to using the ontology for an access decision function as opposed to enabling privacy concepts, which don’t have a direct relationship within security, to be expressed or translated into something that Security systems can understand and enforce?
  • Mike clarified some points from the last hour’s discussion.
    • What is out of scope for the ontology is tackling the whole Information Model, in other words, all of the classes within the model.
    • Based on review of Steve’s use cases, and by focusing on the development of a policy from privacy’s point of view, we can say there is a natural language version which would then need to migrate to a formal language for enforcement purposes.
      • There is a use case for expressing privacy preferences and for getting that into formalized terminology that a system can support.
      • The information model is a representation of concepts, and the ontology ought to be defining vocabularies and showing relationships between the concepts.
      • This ontology will help a patient to create policies because you will be able to map privacy policies to enforceable concepts that can be expressed in a formal language.
  • Don: We are hoping that the structured natural language representation has a formal logic so the concepts being developed in the ontology would inform each other going in both directions. We may uncover some gaps in vocabulary or concepts that would inform the ontology. On the other hand, the Privacy Policy Catalog is the consumer of the ontology. We would be looking for as rich an expression of the concepts that we need for privacy policy to be available in the ontology.
  • Tony: Part of the purpose for the ontology is to provide a unified resource with all the concepts of interest in one place described in a formal logical way and to make it relatively easy to determine if things you expect to find are present.
  • Mike: Here's an analogy - consider the engine and gas. There are various types of engines that consume gas. The gas is the ontology, and depending on the engine, the gas performs differently. If the engine is a car, you are transported; if it’s a printing press, you get books. Most engines are fairly agnostic; they are not specific to a domain. The natural language approach is not written for health care, but we should be able to apply a health care ontology to a natural language approach that informs it and provides specific concepts and relationships between concepts that could be used in health care. It’s analogous to access control enforcement engines – it’s just another engine, we apply a subset of the Information Model. There are certain things that make sense in a particular view of what goes into that particular engine.
  • Don: Where does information model stop and where does ontology start and where are we overlapping?
  • Mike: An Information Model and an Ontology are different representations. An ontology is a higher level representation of information and the relationships than an Information Model is. You need an Information Model before you can create an ontology,
  • Rob: Information Models and ontologies are ways of representing relationships between different ideas. When we talk about Information Models and terminology models, the thinking is that these two approaches to structuring information and then structuring applications - how computers operate on that information, have different value points. You can do certain things better with an Information Model and other things better with a Terminology Model. So you tend to try to represent the world and the stuff that the computer has to interact with – some in the Information Model and other parts in the terminology model.
    • It is true that you could say philosophically, they are at different levels, and could be used to represent and evaluate the same things. But we tend not to do that.
    • Great examples of this in the HL7 world are the message model and the Clinical Document Architecture. I assume this holds true for XACML. So XACML says, here are the kinds of information we want to represent, and there are implicit and explicit relationships between those structural elements.
    • In a message, you may say there are sub-parts of one segment and therefore those things have a relationship – but they aren’t explicit unless you look at the serialization of an object. You look at a Visio diagram and they’re all in the same box.
    • In a Terminology Model, you have explicit relationships between concepts. In the context of this particular thing, we have some Information Models that we’ve worked on. For the HL7 part, they haven’t tended to be created in HL7, i.e., XACML and OASIS. So we refer to them by reference. We’ve tended to focus here on terminology stuff. That’s one of the reasons things get muddied at times. We don’t have clearly defining differences like in other HL7 domains. They have the Visio model (Information Model), and the concept domains that define value sets that go inside of it, and that Terminology Model. Here we don’t have that dividing line. And this project muddies that water even more because we’re using an ontology to help structure our understanding of some of the pieces in the Information Model in XACML or whatever.
  • Mike: In other words, the classes are in the Information Model, but we’re not trying to build an ontology of the classes. You look to the classes in the Information Model to examine the underlying value sets or terminologies that are in the classes and then create an ontology of those vocabularies.
  • Rob: Exactly, this is the important concept to grasp. If we represent those classes like “slots” – things that represent kinds of information and then a specific instance gets filled out with a particular element, term, concept that gets stuck inside that information model instance. We have to put these things (classes) into our ontology and then have to link in what we traditionally think of as value sets and concept domains (in HL7) or the ontology of ideas that are going to be put into instances of that particular information model when you create a real system, i.e., what you see in use cases.
  • Richard: I just think of ontologies as a grouping tool.
  • Rob: To a large degree, that’s true. Steve’s use case (the first) – describes a way to classify clinical objects. But we probably need something more than just two groupings – clinical and administrative.
  • Richard: Our job is to classify the things that people want to control from a privacy perspective.
  • Rob: We need to create an ontology of the kinds of health care related objects that XACML needs to know about.
  • Richard: Rather than saying XACML – that’s just one tool...
  • Rob: The security information objects are the slot names in our Information Model and inside of those are the things we are beginning to identify.
    • What is the upper level classification of things that go into those slots?
    • There’s an ontology of “classes” that come from the Security and Privacy Information Model and from within that, we have an ontology of the classes or classifications that fit inside
    • There are ways that this natural language of interacting with users would lead to mapping to those classified things that are going to be put into the information slots.
    • What we need to do in this ontology project is to identify those things that we need to classify and then to say, what slot do they need to go into?
  • Don: A full-fledged ontology might include the Information Model as we understand it, but we’re going to rely on the existing UML Information Model for those relationships and associations – we’re not going to try to do that in the ontology. But we are going to draw slot names and perhaps value sets that would inform those.
  • Pat: Having said that, we want to make sure that the concepts that are in the DAM are in the ontology. It is a matter of copy rather than discover. I hope that in Protégé, I see things like roles and privacy policies...
  • Rob: We have used ontologic principals to do overall modeling and that’s new to HL7. In HL7, the things that we’re talking about would be in Visio diagrams.
  • Pat: Not necessarily. I’m describing a concept – a policy is a concept. And the ontology might say under policy, we have these instances of a policy which is valid for an ontology, and the relationship between what those things are and what’s contained in them are fully described in an ontology.
  • Rob: This is the value of what we are doing. We may be agreeing, but I’m not sure that we are. The only way to get this figured out is to get it diagrammed and explain it. What I think of as a policy – think of it in terms of slots.
    • There are a series of things that have information inside of them. It’s not just a bunch of terms that come from an ontology. There’s a defined set of things that you expect to see filled out.
    • That set of things is Information Model stuff – it’s slots. It may not be filled out every time for every single policy, but there’s a series of information that are always true for any policy that may or may not be there. But any single instance of a policy may have something that is a clinical object inside it.
  • Richard: So the ontology provides you with a refined set of tools for your policy?
  • Rob: What’s confusing about this is that when one thinks about the Information Model, HL7 names the slots the same way it names the Concept Domains, the same way it names the value sets. So it’s a smear. When you look at it as on overall ontology project, this is an object, and the types of objects are the names of the slots. The things that get filled into it is the oncologic terminology.
  • Pat: The way I view the work we did with the DAM, is that it is an unconstrained model of the business of Privacy and Security. That aligns almost one to one with the upper level structure of an ontology.
  • Don: How do we capture the associations between slots and the terminology instances?
  • Rob: HL7 does that through a Concept Domain.
  • Don: The RIM defines relationships between classes as well.
  • Steve: Do you put the RIM concepts into Protégé and express them in OWL? Or do you simply have individual ontologies?
  • Rob: The RIM is a basic Information Model and uses principals that are very similar to ontologic principals in terms of how things relate to each other.
    • When you design software you make certain design decisions (e.g., database structures and java classes) around the fact that types of “X” will be stored. The “X” part is the Information Model and the instances of that are filled with particular sub-types of “X”.
    • This is a source of confusion. The part we’re tackling with ontology is the terms, the concepts that are necessary to fulfill the Information Model – what are all the kinds of things we want to fill when we create a policy?
      • Let’s say a policy is made up of 10 attributes. Some of these attributes are always going to be filled, while others are not. But when one policy is created, it is filled with particular terms or concepts. Those attributes are Information Model classes or slots.
    • Because there is overlap, we have to describe the Information Model and say, here are the types of things that the terminology has to fill, and then link terminologies ontologies into that.
    • The use cases described so far haven’t gotten to the value of having hierarchical terminologies or an ontology to say things like a clinical object one time, and another time, lab objects, which are a type of clinical object, but different from a radiology object or a clinical note.
    • If we believe it is important to manage Privacy at those levels, we need to describe them. But these things aren’t Information Model objects, they are terminology objects.
    • I think we need diagrams to better communicate what we’re talking about.
  • Richard: I don’t see any problem here. We take what Steve presented earlier and work through the categorizations – roles, actions, objects – we just work through those as best we can. While we’re doing that, we’re looking at what Pat and Don are developing for Privacy Policy Templates and they’re looking at what the ontology is doing. At some point, they both evolve together. What we need to come up with is the 80% of what is relevant.
  • Don: What we’re trying to accomplish is to gather real-world policies, see how they’re expressed and how they’re used. They will be used to inform the ontology, but they will also give us something to test against.
  • Mike: I’m worried that presenting this conversation to others, it won’t be apparent what we’ve been discussing from week to week.
  • Rob: We need to go back and have an accounting of the things that we learned from the Security and Privacy DAM. What are the kinds of objects that are going to need to have terminology concepts in them in order to create instances of Privacy and Security policies. Then we also need to make clear the dividing line between the Information Model and the terminology ontologies necessary to populate instances of these objects.
  • Richard: The templates that we’re working on are the focus of our work– can we implement those with these ontologies?
  • Rob: Pat and Don – are you aligning the privacy policy templates with the Security & Privacy DAM?
  • Pat: I’m not sure we are. The idea is that we gather real-world privacy policies. Instead, I think we are more closely aligning with the Security & Privacy ontology.
  • Steve: There shouldn’t be any distinction between the ontology and the DAM.
  • Serafina: How does the CDA R2 Implementation Guide for Consent Directives fit in? I thought that would refer to these policies.
  • Pat: The idea is that the CDA references an identified privacy policy whose concepts are agreed between partners. I don’t think analysis has been done that says is the DAM robust enough to manage all of the concepts we’re going to find in these privacy policies.
  • Don: The answer to the question is that we’ve got a DAM, and we will work with the DAM and we'll map against it. We may find gaps, but right now the DAM is providing the initial structure. Whatever behavior or description of the relationship between those “slots” should be reflected in the DAM.
  • Rob: I agree with that, but it doesn’t address the question of the relationship to the CDA.
    • May I ask Don, Pat and/or Steve to generate a picture of the relationships between these projects – the Security & Privacy DAM, the Privacy Policy Reference Catalog and the Security and Privacy Ontology?
  • Don: Will the Ontology reflect the DAM enough so the Privacy Policy Reference Catalog can interact with the Ontology?
  • Pat: The DAM was intended to drive out the high level concepts and entities, but wasn’t necessarily meant to be prescriptive about the individual attributes or things that make those entities – and will drive a lot of the vocabulary we will encounter. I have two concerns:
  1. If we use the DAM as the starting place, I’m not sure how far we’ll get with the Privacy Policy Reference Catalog, because it is not detailed enough, whereas I believe the ontology will – or needs to be able to represent the concepts we’ll be identifying.
  2. Do we have a process for updating the DAM when we find gaps? The DAM is intended to be a living document which changes as we discover new things.
  • Steve: The Security Work Group is the place and the process for updating the DAM.
  • Rob: Who owns the DAM at this point? It is done or still in process? Who’s doing the work? The ontology work is likely going to identify some next steps. At this point we have three legs of the stool – and the CDA follows next.
  1. We have an existing DAM – the Information Model as it currently stands.
  2. We are influenced based on existing policies – the Privacy Policy Reference Catalog
  3. The Ontology project.
    • I don’t see the ontology work as being a follow up project but more of a leader. An ontology is a representation of knowledge that has been derived from experts. In the sense you can think of this as a type “Greenfield” project. The modeling part, the work of creating an ontology of things that have been discussed but that hasn’t yet been written down. That is the same modeling activity that Ioana went through in creating the DAM.
    • It’s possible we can do this in collaboration with someone who is responsible for representing the new kinds of Information Model artifacts that need to exist – or we’ve defined that this one general thing, when we’ve got policies that we need to create, has to be made into two new subclasses that will be populated with specific terms and concepts. Who will be doing that work?
  • Suzanne: As those issues come about, more than likely Ioana and Serafina will be addressing this.
  • Rob: I think that having pictures of how all these things relate will help to clear up some of this confusion.
  • Pat: One of the first things that the TSC requested when the Privacy Policy Reference Catalog scope statement was reviewed is a white paper that identifies what the project is all about, how it will be used, what the deliverables will look like and how the catalog will be maintained.
  • Rob: Put pictures in that white paper :-)
  • Pat: Who is responsible for maintaining the Security and Privacy DAM?
  • Mike: Are you looking for a body? It is the responsibility of two working groups (Security and CBCC) to maintain the DAM. The co-chairs are responsible for determining who is going to do what. Updates can be brought to either group –the co-chairs will ask for the use case supporting those update requests.
    • We can have discussions within the groups as to the impact of the proposed change, we can collect these changes and approve them within the two working groups collectively.
    • If we decide that the use case warrants an update to the Information Model, we will do that. But currently the DAM is a DSTU.
    • More than likely, we’ll collect the suggestions. We’re not going to keep balloting the DSTU every six months.
    • It is up to the working groups to decide if and when they would like to schedule another update, assuming that we have changes.
    • We did the same thing with the RBAC catalog. We didn’t get people just coming in from the outside making suggestions. The update to version 2 was driven entirely by our working groups.
    • From a practical perspective, that’s how this will happen. We’ll have people like Pat, Don, Ioana, John, or myself or someone within the working group who feel the need for some change and we’ll bring it up on our call or on the listserv to discuss. We’ll collect the new use case supporting that change request and ballot it at an appropriate time.
  • Suzanne: We’re at the top of the hour. If you have any agenda items for next week, please email Serafina.

Motion to adjourn by Serafina; seconded by Mike

Meeting was adjourned at 3:00 PM EDT.

No significant motions or decisions were made.


Back to CBCC Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=May_11th_CBCC_Conference_Call&oldid=37145"