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

January 3rd, 2012 Security Working Group Conference Call

From HL7Wiki
Jump to navigation Jump to search

Security Working Group Meeting

Back to Security Main Page

Attendees

Back to Security Main Page

Agenda

  1. (05 min) Roll Call, Approve Minutes & Accept Agenda
  2. (15 min) Security and Privacy Ontology - Tony Weida
  3. (15 min) January 2012 WGM - San Antonio Agenda
  4. (15 min) Reminder for upcoming Co-Chair elections
  5. (5 min) Other Business

Meeting Minutes - **DRAFT**

Roll Call, Approve Minutes & Accept Agenda Additional items added to the agenda

Security and Privacy Ontology - Tony Weida Update

January 2012 WGM - San Antonio Agenda

  • Modeling more of the privacy aspects as well as break out other items in a more modular fashion; starting with the root Security and Privacy ontology (POU and Clinical Condition, RBAC-operations, objects, confidentiality and other ontology elements) this will make it easier to mix and match portions of interests
  • Kathleen – are you modeling against the Security and Privacy DAM? ‘Yes; in general we are following up to and including adopting names (if available) then from the DAM as the next choice.
    • ISO and then other names; if mapped…should be mapped.
    • Committees are agreed upon orders or precedent. i.e. POU – root concept (taken from…? ) will work with Kathleen –has starting point in order to document mapping
  • Tony has questions on intent of ISO for the DAM; specific to the point of what Kathleen has indicated.
  • Issue in DAM; it only supposes type of operation (operations and specific parameters) there is a supposition that the only operation is ‘disclosure’’ but the model supports several operations. POU doesn’t have an act to have an attribute to…. It needs to have a rule that the operation is.. .’Access; or use or discloser’ that the operation is used on that. This makes POU difficult to be implementable in hl7.
  • The way POU is used is in the security context, which is not what HL7 focuses its attention on.
  • If you have a consent direct dive; in previous consent models. You have to have an act the POU would only work in HL& v3 as an actReason code. Understood about the security context, but if you want to convey the POU concept you have to convent the attribute.
  • Mike - I don’t think we are trying to make the RIM compliant, so forcing these things compliant is not necessary; operation of disclosure—I think different classes have different associations with it. What I would think of as security operations associated it. What I think of is functional roles and permissions. Operations on objects---a long list of operations.
  • p. 19 in Security and Privacy; we have specific operations that might; these are not easily related to the RBAC operations in general; they are more about the intent of the RBAC operations. The idea that these are intended to define specialization is confusion. On one hand you have operations as in RBAC, then you have the others such as POU (in my mind)
  • We are coming up against—dual use for the same vocabulary
    • One use – convey in the security context, what is your POU at this transaction for this delivery
    • Second use – different use; how do you convey the rules obligations, constraints of a privacy policy or consent in a consent directive. This I agree this has not been well modeled, but I believe that this is a different perspective. But we cannot expect w have one perspective that we can use both.

• I don’t’ think there is a mistake in the DAM, in order to go to the next step, in order to map to the ontology we need to add the operations in the DAM, and I was making suggestions for the proposal; to a certain extent the

o I.e. read would be for access; storing something in the database=collections; disclose=read, then place in an artifact…for conveyance. There are maps that we should whiteboard this in San Antonio.

o As a group there is a disconnect…we need to line up the DAM, to RBAC and how it’s used as its metadata and how can be accurately captures in the ontology…. To view the source of truth. There could be a different term, which has a similar concept—in the privacy perspective.

o The ontology is an organization of concepts so that the ; not sure if the ontology queries be unique---I can see how different ontology chains, that has some words that are related to other terms—that are completely different. The ontology should have no difficulty in showing those relationships.

• Tony -In an ontology class names should be unique. The goal is to develop an agreed upon set of names and interpretations. And part of clarifying our meaning relationships across classes. This is the hard work of getting all the terms and how they relate to each other.

• John while we are defining our terms how we code it and how we would code it to a security concept assertion—it’s the same concept, but may be defined differently

Tony is leaving on Wednesday… so S&P ontology discussion on or before Tuesday Afternoon. Q3-4 Kathleen to add – cross security artifact of standards artifact mapping ontology to ISO to HL7 (consent directive to Security and Privacy DAM to S&P Ontology to Composite Privacy DAM to Consent Direct (set of messages ‘retirement mode’ shared secret, etc.) to RBAC Permission Catalog; what use is made of terms and context… how it’s different at DAM modeling level, capturing interrelationships.

Additional items added


Reminder for upcoming Co-Chair elections

  • Absentee ballots should be sent to: Nominations@HL7.org, NO LATER THAN: Wednesday, January 11th at NOON

On Ballot

  • John Moehrke (on ballot)
  • Andre Orel (on ballot)
  • Mike Davis (write-in), remember to CHECK BOX or vote will not count!!
  1. (5 min) Other Business

Meeting adjourned at 1053PST

Action Items

Back to Security Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=January_3rd,_2012_Security_Working_Group_Conference_Call&oldid=59048"