This wiki has undergone a migration to Confluence found Here
February 9th 2010 CBCC Conference Call - Joint Call with Security
Contents
Back to CBCC Main Page
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
- Serafina Versaggi scribe
- Tony Weida
Agenda
Joint Meeting with Security Work Group. See Security WG Agenda
Minutes
1. Action Items
2. Resolutions
3. Announcements
4. Updates/Discussion
Privacy Policy Templates Scope Statement
- There have been different viewpoints in the approach to this project
- It’s recognized that there is a difference between what a patient and a Privacy Officer may consider and 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
- Mike asserts this scope is too narrow and was looking to expand the scope of 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
- The CDA R2 document needs the machine-computable version of the policy that the CDA’s attributes are informing
- 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.
- There are standards have emerged that can take a standards rules format and map them into any number of back-end languages (XACML, DRM). This would take a natural language expression that people can understand and map it into something that is computable. This is what Richard 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:
- 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.
- Or we can create policy templates that represent the business viewpoint, focused on the Consent Directive only: 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.
- 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 be valuable and is the approach that has been 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 are at two different levels
- The first, here are the details of the policies
- The second is how we construct access control policies knowing we have security policies, privacy policies at multiple levels along with 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:
- We could start with an exploration into the modeling, to develop our process
- Second, as a first iteration, create a model that would be privacy/consent directive oriented
- A third part would be to integrate the privacy part into an overall policy model
- We can 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 are different
- It was pointed out that there was an intent support for 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 that has been defined. The group agreed that
- Based on the discussion, it was apparent that most on the call agreed this 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.
- The scope of the other component is up to the Security WG to propose, but this project should be approved first.
- This approach is different than what we discussed during the Phoenix WGM on Thursday.
- Security could 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 (for the CDA)
- 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.
- We need to bring this to a vote – whether or not to separate these two components. Second, we then need to assign what CBCC would be doing and what Security WG will be doing on whatever is decided
- The proposal is that CBCC will prepare a draft Scope Statement along the lines we discussed today. We can then formally review and vote to approve it and then submit to the CBCC Steering Division.
- 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
- 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
- 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