December 8th, 2009 CBCC Conference Call

Attendees

• Phillip Barr
• Tom Bonina
• Andre Carrington
• Steven Connolly
• Tom Davidson
• Mike Davis Security Co-chair, absent
• Suzanne Gonzales-Webb CBCC Co-chair, absent
• Allen Hobbs
• Rob Horn
• Rob McClure
• John Moehrke
• Milan Petkovic
• Pat Pyette
• Scott Robertson
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve 12/1 Minutes, Call for Additional Items & Accept Agenda
2. (15 min) PASS Update
3. (30 min) CDA R3 Proposals - Continue discussion & Vote to Endorse
   • Digital signature for header participations - author, authenticator, legalAuthenticator
   • Participation sequence number
4. (10 min) CDA R2 Implementation Guide ConsentDirectiveCDAR2ImplementationGuide
   • Comments/Questions

Minutes

3. Announcements:

• CDA Implementation Guide Meeting will resume on Thursday, 12/10 at 1:00 PM EST

4. Updates/Discussion:

There continues to be swirl around the intent of the CDA R3 proposals and perhaps even the scope of the CDA R2 Implementation Guide that has yet to be resolved. Hopefully progress will be made on Thursday's CDA R2 Implementation Call (1:00 PM EST, 12/10)

CDA R3 Proposals

Digital signature for header participations - author, authenticator, legalAuthenticator

This proposal is about the electronic capturing of signatures, including voiceprints, fingerprints, etc.; any means for "signing" an agreement/consent. As we move into the digital realm, there will be multiple modes of capturing signatures in addition to "wet signature". It was suggested that the CBCC R3 proposal be renamed to Electronic Signature, since it is not specific to interoperable mechanisms

• There are three additional formal CDA R3 proposals related to Digital and/or electronic signatures. Digital signature is a well-known term in the Security realm and is specifically an interoperable mechanism. Only one of these is truly "digital" in terms of being interoperable.
  • CDA R3 Electronic signature, submitted by Nicolas Canu, HL7 France (this is the Security realm proposal)
  • CDA R3 Support non-verification signatures, submitted by Calvin Beebe
  • CDA R3 Support signing content within documents, submitted by Calvin Beebe
• There is no debate this proposal should go forward to the Structured Documents WG, however, Tom will represent CBCC and ask SDWG to clarify and perhaps collapse these related proposals into two distinct proposals:
  • One for digital signatures (certificates, X509, PKI)
  • Another for capturing someone's acknowledgement to something, whether a wet signature, voice print, etc.

Participation Sequence Number

Currently there is no way to specify the order in which participations or act relationships are to be processed. In some cases the order/priority is relevant to processing definitional elements (e.g. privacy rules).

• The bigger question is what does priority have to do with evaluating policy?
  • Depending on the security domain, there may be a superset that determines the order of the evaluation. Transmitting the order that something should be evaluated without transmitting the entirety of it, means the order is meaningless once it gets embedded in someone else's Access Control System
  • Wouldn’t some piece of the decisional algorithm have to be here as well? E.g., if you are a denial decision engine, that always takes precedence first?
  • This is a common concept in Policy languages, which brings up the question again as to why are we reinventing policy languages using ClinicalStatements? This comment led us back to last week's discussion about the confidentiality code proposal

Confidentiality code support in ClinicalStatement choices

• John's concern is that although presenting these proposals for CDA R3 enhancements might look like the right thing to do, he is not convinced that we need to spread the Consent Directive schema into the existing CDA structure
  • Better to keep the policy encapsulated
  • The whole policy is treated as a branch of XML, rather than a leaf in the CDA header, a leaf in the CDA body, etc. (using the current structure of the CDA document to represent the concepts of the Privacy DAM)
  • While putting Policy in the body in an encapsulated form is stating this as a simplified approach, we do need to figure out a way to describe a policy using the Privacy DAM as a policy schema that is HL7.
  • I have no problem using HL7 RIM concepts, but (I advocate) the concept of putting a top to bottom policy as a schema as opposed to spreading the terms out into the existing layout of a CDA document.
    • For example a clinical decision support rule is not unlike a privacy policy, yet they have standalone rule schemas. They don't try to take a clinical decision support rule and explode it out into the existing model. The current CDA is about clinical observations.
• Tom – question posed to John:
  • At what point do we prune off from the current clinical document structure?
    • Do we halt at the body choice, or would we go down into the section and create something other than ClinicalStatements in the sections?
    • Whether it's XACML or RIM-based, I'm trying to figure out at what point have we gone deep enough?
• John: The five primary attributes of the CDA are also important for Consent Directives
  • Header, body, section, narrative block, entries
  • Actual language of the policy is where I get into concerns about confidentialityCode.
    • In the language of Policy, you're not saying that this is being labeled with a confidentiality code, you're saying when documents/objects are labeled with a confidentiality value of "X" it means this from a Policy perspective. So the code set is what you need to include in the Policy, not the confidentiality attribute
    • That’s not to say that the CDA document that is enclosing Consent, does not have a confidentialityCode. But the meaning of confidentialityCode Inside the Privacy DAM, meant that the policies depend on the values within the value set, not any particular location within a CDA document of confidentialityCode. The question is, are we exploding too much of policy out into the structured document?
• Tom: If we were to take John's approach, it sounds like we're advocating adopting the left-hand side of the CDA, but once you start heading toward the right, which is where the ClinicalStatements are, we're making a left turn.
• John: That might be the case. The body of a policy is different than the body of a clinical statement-based document
• Tom: If we head down that route, we are creating a new document or at least asking SDWG to recognize a new body choice
• Richard: That's why this discussion is more appropriately conducted with Structured Documents
• Tom: Structured Documents can make the call as to whether they want Clinical Documents to be able to morph that way. If they say no, the only other option is to create some other security or policy document that incorporates the main clinical document left hand side, but then we are left to define the right hand side
• John: This issue involves more than the Structured Documents WG. I don't want to leave messaging world or clinical decision support behind. It’s a discussion about a higher-level concept of how can we get a privacy policy encoded into something like a document.
  • If there is a desire to get in as many requests for CDA R3 enhancements as we might need and later on, we decide we don't need them, isn't this bad behavior on our part? There is still much to be done in terms of encoding the Privacy DAM for policy
• Question to John: do you have any ideas as to what the model should look like or what elements are needed to express policy? What is the realization of policy?
• John: why reinvent it? There is a set of policy languages out there, why not just endorse two or three of these set of policies (XACML, ODRL, etc.) and describe the metadata we need to have associated with the policy? What part of those languages can be leveraged and where do we need to model the healthcare specific values such as patient and provider/organization identity, roles, etc., versus what is the way you encode sensitivity vocabularies, role vocabularies, purpose of use vocabularies – the concepts that are common among those policy languages. Let's just add the healthcare specific value – the patient, provider identity, etc.
  • I am not saying we should not create a policy schema, but I don't see good reason to create a policy schema if there are policy languages that can be used to map to the privacy DAM concepts and vocabularies. Where does it link to the CDA header in the case of a document versus the mode of transport versus a message mode of transport, versus some mode that is not defined by HL7. I don't think HL7 is subject matter experts in policy schema.
• Richard: That sounds pretty good to me. Does anyone else disagree? We've gone around a bit around XACML and whether we should have vanilla HL7 descriptions of policy. Kathleen would say that we've already got that in terms of the messaging standard. If other policy schemas, languages are already there, I don't think we have to go down that road.
• John: That's good to hear because I thought it was you that was causing HL7 to create a policy language.
• Richard: No I don't think so. But I don't know. I'm interested in minimizing workload at the moment.
• John: Even if we come up with a way of encoding the Privacy DAM, before it can be enforced, it has to be converted into someone else's language.
• Richard: What I was saying is that I don't want us to be locked into someone else's preconceived agenda about what the role of consumers/patients/clients, we didn't have much of a role in some of the ways people are contemplating policy enforcements. If we're on the same page – my identity, my policy description, we're all one the same page these days, it's either mine (client's), the organizations, etc.
• John: A year ago, there were some people who were heading toward XACML or bust, but that has changed. It was Mike who changed TP20 so that XACML would be informative which allowed other languages to be used. Which I thought was very useful. But the problem is then you have to have metadata to explain which language was used. There still is value add that HL7 has to bring to the table. We have to be able to say, there's an attachment, it's in X language using Y vocabularies and whatever else is not completely describable by policy languages themselves, clearly the binding to the patient, to organization.
• Richard: Would that be an attachment to a CDA document?
• John: It would seem to me to be easily doable.
• Pat: I'm in 100% agreement that we should not be inventing a new policy description language, but one of the things we will have to do, and I hope is something we'll be doing as part of PASS or somewhere, is that when multiple policy definition languages are endorsed, part of that endorsement is to include a transform that says, this is how you get from one to the other.
• Richard: Whose job is that?
• Pat: That has to be the project that comes up and says we're going to endorse XACML or MS policy def language, or whatever.
• Tom: that was one of the things that made CDA attractive – if you have one in CDA you can transform into any of those languages. It becomes an implementation guide, and these are the definitions you need. However, I will agree that it is recognized that coming up with a new markup language or definition for policy is difficult.
• Pat: We need to identify the constraints that are necessary on whatever languages we choose so they can be reliably transformed to an instance of a policy and carry the same weight.
• John: Creating constraints on policy languages are far easier to come up with and closer to our WG subject matter expertise than inventing the language.
• Richard: And who does that work? Is that in CBCC, Structured Docs?
• John: That is CBCC and Security. It's an analysis of the specific language towards the Privacy and Security DAMs. We don't need a concrete model that represents the DAMs, the abstract models are sufficient. We should only look to Structured Documents for how do we carry this policy blob in a persistent object.
  • One of the concerns raised around DRM for instance, is that there's "proprietary-ness" to it. ODRL language itself is not proprietary, it's just the implementation of the enforcement of ODRL that is proprietary. So we won't solve the problem of proprietary-ness, since we're only trying to figure out how to encode a patient's desire to have blah happen. So that's policy and that is an open standard.
• Richard: So the thing that might be brought up in Structured Docs is that we would have some type of coding that they would know what they're reading…
• Tom: Along the same lines that potentially some of the suggestions for the CDA R2 IG came out, there is Observation Media that could be pointed to. Or we could use the non-XML body portion and say the policy is embedded.
• Richard: It's still computable?
• Tom: Just because it says it's a non-XML body, it implies that it is base-64 encoded, but we can indicate through some of the MIME-types and data that this is a certain type of document.
• Richard: So you can read it?
• Tom: Yes, similar to an application pdf being embedded; that requires a known application to process it. We can do the same thing with XACML, whatever.
• John: There is sufficient work that we would need to work with Structured Documents on to identify a consent document and the parts within that are mandatory, there are some metadata work that needs to be done, in addition to resolving how would you encapsulate the policy if the policy was self-contained.
• Richard: We could imagine CDA R3, CDA R2, carrying the payload of my clinical data and privacy policy in the same package along?
• Tom: No – this would require two separate documents. CDA can handle describing different types of documents – clinical data versus the privacy policy wrapped clinical document. They are still two separate documents. CDA has the ability to reference documents for example, a clinical document has a reference to a Consent that we might want to ask them to change to point to a particular Consent document. That way you can always refer to the driving policy for this particular document.
• John: Conceptually it works, but there are scalability problems with that approach. You want to have clinical documents and policy documents which are concerned with clinical documents and the two of them can have direct or indirect references to each other. I would shy away from combining policy with clinical content. While it's possible, the problem is it is best to keep your policy and content separate.
• Pat: There was discussion in the past about tagging clinical documents with a policy identifier. Which is problematic since if policy changes, you have to update the clinical documents.
• Richard: There may be something in PASS that tells people how to connect…I understand there's been a long thread.
• John: Confidentiality code value is the thread – the analogy is permissions are not applied to a users account, they are applied to a role, and a set of users are assigned to roles. There is an indirect relationship between user account and the permissions they have.
  • Confidentiality code is a grouping mechanism. You don't apply policy identifiers to the clinical content, you apply policy values to particular confidentiality code values and you apply those values as labels to the documents. That way, when you have a class of documents with confidentialityCode blah, and know what to apply when confidentialityCode blah is encountered. This allows you to more dynamically change Consent Directives over time without having to recode the content.
• Richard: I was thinking that we would associate the policy with an OID.
• John: The problem with associating policy with an OID, is as soon as you change the policy, you have to retroactively change all copies of the clinical content to reflect the new policy. That's why we use the intermediate code set, which is the value set of the confidentialityCode as opposed to going direct to policy objects. The one thing that did come up that was discussed at the face to face (in Atlanta) is that currently today, the confidentialityCode vocabulary is a very specific vocabulary. If someone wants to say they have a type of data that is different than any of the codes in HL7, how do you declare a vocabulary value in my value set. IHE's answer was to use an OID, the problem with that is that the HL7 data type restricted the use of OID as a vocabulary value.
  • The idea of a local domain being able to extend the value set is a good idea, and to use something globally unique is a good idea.
  • Having a way to specify globally unique values into a value set is useful, but that's not to say that the global unique value is the unique object identifier of the policy itself. It is still a grouping OID, not the end policy OID.
• Richard: We're getting to the end of this meeting and I have the feeling this discussion will be continued.
• Pat: A quick question to John. You mentioned confidentialityCode as if it was the only targeted ADI that might be used. I just want to confirm that we haven't gone back to that as the only piece of metadata that might be evaluated for a privacy policy.
• John: it isn't in my view. The context is an open set, and it is far greater than confidentialityCode. But I want to make sure that confidentiality code is as powerful as it can be without losing its value. If you know that class code is usable or something else is important in your policy space, then go ahead and use it.

Time ran out. Further discussion will take place in Thursday's CDA R2 Implementation Meeting at 1:00 PM EST.

Meeting was adjourned at 3:05 PM EST

No significant decisions or motions were made