December 15th, 2009 CBCC Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Don Jorgenson
• John Moehrke
• Milan Petkovic
• Pat Pyette
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve 12/8 Minutes, Call for Additional Items & Accept Agenda
2. (55 min) CDA R2 Implementation Guide for Consent Directives - ListServ discussion

Minutes

3. Announcements: Holiday Schedule

• Meetings scheduled for 12/22 & 12/29 are canceled. We will reconvene on Tuesday, January 5, 2010

4. Updates/Discussion

CDA R2 Implementation Guide for Consent Directives

There's been considerable debate as to whether one of the options included in the CDA R2 Implementation Guide for Consent Directives (the representation of a Consent Directive as computable statements/entries using standard-based terminology in the structured body of a CDA document) is going down the path of creating a new HL7 policy language.

• Ioana was unable to attend today's meeting, and the Guide has already been balloted.
  • Without Ioana to provide further clarification on the approach, it is best to put our thoughts into the ballot comments.
• To reiterate, here is the scope of the CDA R2 IG for Consent Directives:
  • "The project is intended to produce a structured document specification to exchange signed Consent Directives. This specification will make use of the concepts identified in the Composite Privacy Consent Directive – Domain Analysis Model – and the CDA R2 specification. This implementation guide is not only intended to provide a computable representation of a consent directive but the resulting structured documents could be used to generate enforceable assertions or rules (e.g. SAML, XACML).
  • This project is intended to support the management of consent directives and policies.
  • CDA R2 supports the multiple representations of a Consent Directive as a narrative, signed document (wet signature), and computable statements/entries using standard-based terminology."
• One issue appears to be that the representation: computable statements/entries using standard-based terminology leads one to believe this is advocating the development of an HL7-specific policy language.
• John's assertion is that the HL7 RIM is an information model and not a policy language. So we will have to develop mechanisms within HL7 RIM to assist with encoding policies and will end up having to invent stuff that is specific to HL7. We do not need the third HL7-specific way of encoding a policy. The Privacy and Security DAM is sufficient as an intermediary.
• Mike contends that the value of this guide is that it is compatible with existing implementations which are largely application-based.
  • Messages are read by applications.
  • If you're implementing this in an SOA security system with available standards, you would use them. There are profiles of those to pass the same information that is readily usable (e.g., by XACML, XSPA, SAML). They use the information models but they provide the information to a gateway and the organization is free to map that to whatever representation they choose.
  • Or an organization can get an HL7 R2 message and consume that into an application that is not SOA-enabled.
  • The question is, why we're trying to describe what an organization would do internally?
  • How does an R2 message turn into a policy language?
• What triggered Pat (and perhaps others) to believe this is the case is when the CDA R3 proposal Participation Sequence Number was introduced to define what order should the policies be evaluated in
• This smacks of a rule combining algorithm
  • This is just an attribute - don't read more into this
  • If someone can provide something that is in this ballot that says we're going to create a policy model, then Mike agrees, this should be voted down. But if it's just attributes out of the information model that are going to be encoded in an R2 message, then who cares.
• John asserts this is not just an issue of attributes.
  • When you're talking about relationships that are conditional and contextual, you're not just saying here are a set of attributes.
• Does it tell you to do something, or is it just giving you the information you need to make that determination, there's a difference?
• How else are you going to know what the relationships are?
• You can describe the relationships between things in a vocabulary. The information model has lines that describe those relationships.
• Mike would vote against creating a policy language. But if the ballot enables people with the vocabulary they need to make policy decisions, that is appropriate.
• The sense of many in the group is that encoding policy into the structured body of a CDA document using the HL7 RIM is the creation of a policy language. It is agreed that this is only one of the possible options, but it is one option being presented.
  • If we promote the ability to encode this way in the structured body, it means that this work group has to complete the job. We'll have to deal with all of the things that the ORDL committee, XACML committee have dealt with over the years.
• The specific section under debate is Section 4 of the Implementation Guide.
• Question posed to John: Is there a difference between an Access Control Language and a Policy Language?
  • John: Policy language is used to separate the way of encoding a policy in a computable form versus the enforcement that goes along with that policy language. For example, I like the language of expressing an XACML policy, but I don’t like the engine that XACML describes as enforcing those policies. The same thing with ODRL, ODRL is OK, I don't like DRM. The languages are open, but the enforcement part is proprietary.
• The computable representation that is referred to in the IG is not trying to enforce the policy, it is the method for communicating the policy. The IG is not trying to describe something that will be fed directly into an Access Control Engine.
• John emphasized that he feels the vast majority of this ballot is "great stuff".
• We can thank John for pointing out the issue. We will get clarification on the intent of this section through the comments and the ballot reconciliation process.
• If the structured document says, here are the attributes that will be used to instantiate the classes that correspond to the Privacy/Security DAMs, that’s OK, as long as this is the limitation.
  • But when it starts to talk about how these things need to be combined, how they should be executed, then we're talking about a Policy language.
• It seems there is a mixing of terminology. There are three concepts:

1. Access Control Policy
2. Access Control Model
3. Access Control Mechanism

• We are mixing Model and Policy
• When we talk about creating the policies, provisioning the store where a CDA document makes sense, it's one thing.
  • But when we get to where we need to take that information and process it, we're not going to process a CDA document. There's going to be a transform into something that Access Control engines can deal with. So there are two aspects. When we loosely couple them we don't have as many issues.
• Mike brought up the notion that within HL7, we could create pseudo-policies — representational policies, a way to talk about concepts in relation to one another. These aren't formal policy languages.
  • A pseudo-language is a high-level, humanly-readable representation of relationships between terms that end up in a policy language
  • There is a difference between how terms can be related in a pseudo-language and a formal, standardized language that goes into a machine. Pseudo-language does not go into a machine.
  • Pseudo-languages might enable you to encode a policy language that goes into a machine.
• It is useful put our comments into actionable items.
  • One item that has certainly been raised is the fact that the IG is not clear in its representation of what is the intent and where it is to be used.

The meeting was adjourned at 3:00 PM EST. The next time the CBCC Work Group will meet is in a joint meeting with the Security Work Group on Tuesday, January 5, 2010, 1:00 EST.

No significant motions or decisions were made.

Happy New Year!