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

Attendees

Anticipated

• 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

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

4. Updates/Discussion

Privacy Policy Templates Scope Statement

• Pat presented the revised Privacy Policy Templates Scope Statement
  • This project is closest to a vocabulary project, so we’ve indicated that this is a V3 Foundation – Vocabulary Domains & Value Sets project with the intent is to create a new standard
  • 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
  • The end result will be a set of OIDs that point to specific policies. Those OIDS are what will eventually be passed in documents and messages
• There is a joint project underway in San Diego that includes the VA, Kaiser Permanente and the DoD and 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
• There was a question whether this project is only balloting the value sets, the vocabulary?
  • The project will standardize the language of the policy and will associate an identifier with that policy. This will not be 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 would be represented by vocabulary code values that the machine understands
  • 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
• 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 the confusing arises, is that the scope statement states we’re developing vocabulary artifacts, but what we’re trying to define are these 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
• Where it is confusing is that it has an OID, but it’s not an OID assigned to an HL7 template, but is an OID assigned to an example policy
• We should not declare that this is an OID –it is a vocabulary so it that has a unique identifier and that unique ID will be within a value set or a vocabulary that is identified by a unique ID. But 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 have an identifier and within that instance, would be a pointer to the policy “template” that’s agreed to and the values to be used within the context of that template.
  • What we’re proposing is that the policy “template” vocabulary value would 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 into XACML or other languages
• So I think we agree that what we have 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)
• 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
• What about using the term “stencil”?
  • 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 argues that it 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”.
  • What is the way that value 1 is different from value 2, but 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 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 and we would
  • Pat will update the project scope statement to remove the overloaded term template from the project definition, so the project will be called Representative Privacy Policies and Associated Vocabulary; remove Comment from the ballot; and
  • Anyone with other ideas should send them to the CBCC list
  • We should contact Lori Forquet to see if she would like to ne an interested party. She may be interested. She does a lot of this as consultant to health information exchanges where they do this within the information exchange. She has some representative privacy policies that 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
• 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 establish the templates for a consent directives and reference identifiers so the CDA document can reference them
• Richard questioned whether we would need to provide similar functionality to represent organizational and jurisdictional policies as well?
  • There is no reason why this couldn’t support this requirement as well if we were to extend them to be fully formed. 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 to support or 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
• One of the goals of pseudo-code is to allow organization to create machine implementable policy in a language they would specify
• DSTU Catalog of reference privacy policies
• Privacy view of the Security and Privacy information model

Meeting was adjourned at 3:00 PM EST