February 9th 2010 CBCC Conference Call - Joint Call with Security

Attendees

• Tabitha Albertson
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Allen Hobbs
• Don Jorgenson
• Glen Marshall
• Rob McClure, MD
• John Moehrke Security Co-chair
• Milan Petkovic
• Pat Pyette
• Richard Thoreson CBCC Co-chair, Absent
• Serafina Versaggi scribe
• Tony Weida

Agenda

Joint Meeting with Security Work Group. See Security WG Agenda

Minutes

1. Action Items

• Suzanne will schedule meeting with CBCC Co-Chairs, Don Jorgenson and Pat Pyette to prepare a revised draft Policy Templates scope statement

2. Resolutions

• Draft Privacy Policy Templates Scope Statement will be revised to reflect today's discussion

4. Updates/Discussion

Privacy Policy Templates Scope Statement

• There have been different viewpoints in the approach to this project reflecting

1. What a patient and a Privacy Officer may consider and
2. What a Security system needs to enforce that policy

• Don’s view, perhaps reflecting Richard’s viewpoint, is that one aspect of this project is to create a set of privacy policy templates that can be referenced in a CDA R2 Consent Directive document
• There is a recognized need to reference policy templates by OID, and these policies could then be expressed in whatever formal policy language desired
• There is value in having “structured natural language policy representations” that look like pseudo-code, something that is relatively easy for a chief privacy officer to understand
• Going into this discussion, Mike asserted that this is too narrow for the scope, and was looking to expand this project to include templates for Security-specific policy as well as patient constraints, or in the absence of patient constraints, Organizational and Jurisdictional policies. The templates would reference the classes in the Privacy and Security DAM Information models
  • There is a need to create a machine-computable version of the policy that is informed by the attributes of the CDA R2 document
• Standards have emerged that can take a standard rules format and map those rules into any number of back-end languages (XACML, DRM). This project proposes to take a natural language expression that people can understand and map it into something that is computable. This is what Richard and the SOA WG finds intriguing
• There is also the need to take various privacy policy viewpoints (Security, Patient, Jurisdictional/Organizational) and bring them together into something computable across the entire policy set. This will probably happen by an access decision system
• This project could be approached in two ways:

1. We could handle the entire problem and tackle both the business and engineering (architectural/component level) viewpoints by developing a complete model.
   • There have been three different demonstration projects where for instance, 16 XACML policies were able to represent full policy representations exposed in a pseudo-code manner
2. Or we can create policy templates that represent the business viewpoint, focused on the Consent Directive
   • Develop a limited set of privacy policy templates focused on the Consent Directive only. The CBCC WG can develop the pseudo code that would inform the CDA R2 document

• There’s work for both viewpoints that needs to be done, the question is can we do his work by allocating the Security-specific work in the Security WG, and the writing the representative policies from the patient-viewpoint in the CBCC WG?
• The Privacy Policy template approach (business viewpoint) was considered to have the most value and that was the approach taken in Canada. There are a finite number of privacy policies that can be referenced (>10<50) and it doesn’t matter how these policies are referenced (messaging implementation, CDA document implementation, etc.)
• The other approach is trying to answer: How do those templates fit into the overall set of access control policies? But these questions are at two different levels
  • The first, here are the details of the policies
  • The second, how do we construct access control policies knowing we have security policies, privacy policies at multiple levels and Consent Directives?
• Given that the group recognizes the need for and value of the two approaches, we could create a broad scope statement with different deliverables:

1. We can start with an exploration into the modeling and develop our process
2. Second, create a model that would be privacy/consent directive oriented
3. Third, integrate the privacy part into an overall policy model

• We could accomplish this in either a single project as described above, or in two parts where the detailed Privacy policy work can be plugged in the architectural Security Policy work
• The advantage of breaking this into two separate projects is that each work product passes or fails on its own merits
  • The Privacy Templates might only be publishable as Informative
• Glen raised the point that from an HL7 perspective, the best approach is to break this into two separate projects because the Security work could be internationalized whereas Privacy policy might resist internationalization and the audiences that you need to work with to complete these tasks are different
  • It was pointed out that there was an intent to support cross-border exchange of privacy policies
  • Glen thought this would require yet a third project. Trying to support cross boarder privacy policies when those policies vary so much among nations is like trying to boil the ocean. There is greater chance for success by breaking this into discrete projects
  • The greatest problem is posed by the fact that within HL7, no US domain has been defined
• Based on the discussion, most of those on the call agreed this project should be broken into discrete projects with tightly aligned concepts
  • The messaging is fairly clear. Everything gets brought together in the policy and attribute engines, so the actual exchange of policies will be in patient consent policy messages while other policies will be sent in different types of messages
  • Breaking this into a project that is focused on creating pseudo code or templates that are based on the combined information models and satisfy the need to have a reference-able OID for the CDA R2 CD is a clear, concise and understandable objective
• If this is the approach that is approved by the group, the CBCC should lead this project and Security would be a co-sponsor
• This approach is different than what we discussed during the Phoenix WGM on Thursday
• The scope of the other component is up to the Security WG to propose, but this project should be approved first
• Security can then consider developing a similar project dealing with the composite information model for expressing security policy where the privacy policy is reference-able/consumable by the enforcement engine.
• There doesn’t appear to be as much urgency on the Security side as there is to have a reference-able and interoperable description of policies
  • The consent directive is something that is communicated between entities and needs to be interoperable (we have a CDA document to do this). We need policy references to complete the communication. The knitting together of policies into a composite policy that is managed by a policy engine is inside the black box – it is a problem, but it is not an interoperability problem.
• Next steps:

1. Decide whether or not to separate this project into two components and bring this to a vote
2. Assign what CBCC would be doing and what Security WG will be doing based on that decision

• The group proposed that the CBCC WG should prepare a draft Scope Statement along the lines we discussed today. We can formally review it next week, take a vote, and then if approved, submit the scope statement to the CBCC Steering Division for their approval
• SOA would like to be a co-sponsor on both of the newly described projects
• Pat and Don have offered to help the CBCC chairs craft the revised scope statement
• Assuming that the other CBCC co-chairs agree to this approach, we will present the revised scope statement at next week’s CBCC WG meeting
• The scope statement should include:
  • Exploration of pseudo code languages
  • Develop a process that would also be used by the Security project
  • The specifics for creating a normative ballot for the reference-able policy template and vocabularies
• Next week, we will review the revised Privacy Policies scope statement
• The Security WG will learn from this effort and will leverage the work done to identify tools and the process for tackling this component - the interoperability effort

Motion to adjourn the meeting was made by John and seconded by Pat at 2:35 PM EST