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

Attendees

• Tabitha Albertson
• Tom Bonina
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Don Jorgenson
• Glen Marshall
• John Moehrke Security Co-chair
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve Minutes Feb 9, 2010 & Call for Additional Agenda Items
2. (55 min) Privacy Policy Templates Scope Statement (CBCC Agenda item)

Minutes

1. Action Items

• Pat:

1. Revise Representative Privacy Policies and Associated Vocabulary scope statement based on today's discussion. Updated scope statement will be reviewed in a future meeting of the CBCC WG
2. Contact Lori Forquet to see if she would like to be an interested party on this project and to see if she can share some representative privacy policies that we could use to start our development

4. Updates/Discussion

Privacy Policy Templates Scope Statement

• Pat presented the revised Privacy Policy Templates Scope Statement
• The scope statement will be revised to reflect today’s discussion, the highlights of which are summarized below:

1. The name for the project will be amended to Representative Privacy Policies and Associated Vocabulary
2. The term “template” is an overloaded term and could cause confusion when the scope statement is reviewed by the Steering Division and others outside this project. It was decided we would not use the word template to describe the product of this project, and instead to simply call the generic representation of these policies “Representational Privacy Policies”
3. The term OID was removed from the project scope statement and replaced by “unique identifier”
4. This is categorized as a V3 Foundation – Vocabulary Domains & Value Sets project with the intent is to create a new standard
5. The project will start as a first draft DSTU ballot targeted for September 2010, followed by a Normative ballot. If we unable to make the September 2010 deadline for the first draft DSTU, we will move it forward to January 2011
6. The result of the project will be a set of unique identifiers that point to specific policies. Those unique identifiers will eventually be passed in documents and messages
7. The compelling need for this project is the fact that we’ve passed a DSTU ballot for a CDA R2 CDA document for Consent Directives which specifies a pointer to a consent directive. We therefore have a need to establish the generic representation for a consent directives referenced by unique identifiers to be included in the CDA document or by any other implementation project

The following captures details of the discussion during the project scope statement review. Please take into consideration that the terms "template" and "OID" have been replaced as indicated above:

• A joint project underway in San Diego involving the VA, Kaiser Permanente and the DoD. Mike is implementing the Security component of that project using the CDA R2 IG for Consent Directives
  • This joint project is scheduled to run through October 2010
  • Currently, only a few policies will be implemented, and they are local policies. If this effort could provide something for the VA/DoD/KP project to work with, those templates could be used. This could be one of the first implementations to provide feedback to this DSTU
• A question was posed as to whether this project is only balloting the value sets, the vocabulary, or something else?
  • The project will standardize the language of a set of policies and will associate an identifier with each policy. This will not be establishing a security policy language, but the language of the policy
  • If someone wants to say that value in the value set is represented by a French rendition, it is acceptable. The language in the policy is provided for clarity, but it doesn’t mean that the language must be used to communicate with the patient
  • The "template" will be represented by vocabulary code values that the machine understands
• The structured natural language would be used as the basis for the policy. That structured language could then be used to transform into any other language.
  • So SBVR could be translated into an equivalent French language or an XACML policy fragment, depending on the security engine.
• Where confusion arises is because the scope statement indicates we’re developing vocabulary artifacts, but what we’re defining are new kinds of "templates"
  • When this scope statement goes in front of the Steering Division, they are going to wonder how do these templates differ from other templates developed by HL7?
  • It will be important to define what is meant by template within this context, since this is an overloaded term
• Another point of confusion is saying the policy is referred to by an OID. But this is not an OID assigned to an HL7 template, it is a unique identifier assigned to an example policy
  • We should not declare these policies are identified by OIDs – this is a vocabulary, so it has a unique identifier and that unique ID will be within a value set or a vocabulary that is identified by a unique ID.
  • To say that it is an OID will cause confusion. There was earlier confusion around using OID as if it was a vocabulary value because those values are made up of the vocabulary identifier and the value in the vocabulary
  • Any instance of a consumer agreeing to a policy will be assigned a unique identifier and within that instance, will be a pointer to the policy “template” that is agreed to and the values to be used within the context of that template will have unique identifiers
• What we’re proposing is that the policy “template” vocabulary value will uniquely identify a policy as written in the well-formed English language so that it more easily is translatable into other well-formed English languages, or eventually given a particular context in XACML or other languages
  • What we have is a formal language description for a specific policy and the value sets associated with that. Not English translated to English, but rather formal English that represents a policy that is uniquely identified and has associated value sets.
  • For a specific policy, e.g., HIPPA, you want to have a predefined set of concepts and each of these concepts have associated terminology (value sets)
• In trying to come up with another term to represent the concept of templates as perceived by this project, the terms Rule and Stencil were proposed
  • Rules don’t have value sets; rules have concepts that have value sets. The rule itself is not computable, it is formal natural language at this point
  • This is natural language 101 – formal English. You have a syntax, that syntax identifies what you’re predicates are, and those predicates have value sets
• John asserts that what we are describing is not to that level. We will ultimately create a value instance something like an "Opt-Out and don’t ever allow anyone to have access", period. This would be a different “stencil” than “Opt-Out except for direct care providers only”.
  • In other words, what is the way that value 1 is different from value 2. But we will only describe those differences in the English language, we won’t try to create a computable version of that even though in some cases the computable version could be derived
  • Initially, there are probably 20 policies that cover 80% of the requirements, and if we can get them down to a well known vocabulary value that can be conveyed across countries, where it is clear what the intent of that policy is, we’ve accomplished something
• The fundamental purpose of the project is to identify the set of policies that apply to 80% of everything that gets done. Within that policy language there will be references to specific attributes, and those attributes will have vocabulary. What we expect to happen is that the vocabulary for the most part has been defined. There may be things that we identify as missing and that will inform the Security and Privacy DAM harmonization project, but it is not the intent for this project to identify those values
• We should initially start out expecting that these are whole policies, not fragments. If we want to say we’re supporting fragments of a policy, then we face the issue of combining those fragments and then we may as well go all the way to the bits and bytes
• We might identify the need for code sets as part of this analysis that are needed but not the value sets themselves
• Pat will come up with another term beside template to avoid confusion, and also agrees that we should not use the term OID
  • We may not need to use another term at all, and we can simply call these Representative Privacy Policies
  • Pat will update the project scope statement to remove the overloaded term template from the project definition, so the project name will be "Representative Privacy Policies and Associated Vocabulary" and he will remove the Comment Only from the ballot type
  • Anyone with other ideas for the overloaded terms should send them to the CBCC list
• In addition, it was agreed that we should contact Lori Forquet to see if she would like to be an interested party in this project. Lori consults with a number of health information exchanges, and they have defined a number of these policies within the information exchange. She may have some representative privacy policies that she can share which we could review and see if they are clear enough to us, make them more global if necessary, but this would be a good start.
  • Pat will also tap into Canadian contacts as well
  • John Moehrke will also be added as an interested party
• Project Need: The compelling need for this project is the fact that we’ve passed a DSTU ballot for a CDA R2 CDA document for consent directives which specifies a pointer to a consent directive and we need to reference those identifiers in the CDA document
• Richard questioned whether we need to provide similar functionality to represent organizational and jurisdictional policies as well
  • There is no reason why this project can't support this requirement if we were to extend them to be fully formed policies. But we said this particular activity was not the full policy template, it is only the Consent Directive part as reflected in the CDA R2 Implementation Guide
  • This aspect will be reflected in the scope statement to provide further clarification
• Richard was under the impression that this effort, and the CDA IG as well, was intended to support the tooling for either a patient, provider/institution or a jurisdiction
  • The representative policies are either jurisdictional or organizational policies that allow a patient to express their preferences within those contexts
  • We want to make sure that the policies that are written here are clear and unambiguous and are lay-person friendly
• To boil it down for this scope statement, to say that we are creating templates that can be referred to by an identifier that can be satisfied by the CDA R2 Implementation Guide for Consent Directives is enough
  • Pat will include this statement in the project need but points out that the CDA R2 IG is not the only implementation that is dependent on these templates. There are previous successful ballots that have exactly the same thing that could be used for messages or services. The transport doesn’t matter

Meeting was adjourned at 3:00 PM EST