December 10th 2009 CDA R2 Implementation Guide Conference Call

Attendees

• Suzanne Gonzales-Webb CBCC Co-chair
• John Moehrke
• Ioana Singureanu
• Serafina Versaggi scribe

Agenda

1. (15 min) Roll Call, Approve Minutes
2. (45 min) CDA Implementation Guide Scope
   • Scope
   • Relationship to CDA R3 Proposals

Summary of the Meeting

• The primary purpose of this call is to address the concerns posed by John about the need for CDA R3 proposals and the scope of the CDA R2 Implementation Guide. John is requesting that we examine other ways to go about expressing a Consent Directive in a CDA document.
• John will begin a dialog on the CBCC and Security lists, focused on gaining a better understanding of requirements (if they exist) for encoding Privacy DAM policy in the structured body of a CDA document.

Action Items

• John:

1. Review the CDA Implementation Guide draft on ballot site.
2. Send an email to the Security and CBCC lists posing the question: If the appropriate information for carrying a policy language (like XCAML or ODRL), and the appropriate metadata and structure is there to carry and identify a Consent Directive, do we need to find a way to encode the Privacy DAM in an HL7-specific structured body of the CDA?

Minutes

• To reiterate, the scope of the CDA R2 guide is to support multiple representations of a Consent Directive:
  • As a narrative, signed document (wet signature), as well as computable statements/entries using standard-based terminology, which could then be used to generate enforceable assertions or rules (e.g. SAML, XACML)
• John: Use the CDA to carry the policy, but not to encode the policy into the current CDA structure
• Ioana: One of the multiple representations is structured content that is implementation neutral. If you don't need that, you can use one of the other representations (XACML, ODRL, other policy languages).
  • This allows others who cannot use a specific policy language to use the templates found in the structured body of the document.
  • We're having a hard time trying to understand what are the issues, and how we can resolve your concerns. I'm trying to distinguish between your concerns about the CDA R3 proposals and the scope of the Implementation Guide. Are you asking for the scope of the project to be changed?
• John: I don't think the CDA R2 IG scope statement mandated that you take the Privacy DAM apart into potential component parts and take it out of context. The discussions that took place were at a very high level. The CDA approach is a logical way to expand on the work of BPPC profile, so I agree to marry the concepts of the Privacy DAM with CDA.
• Ioana: Clearly there has been some misunderstanding. There are different stakeholders with different requirements. So if you don't need to exchange Consent Directives in a structured manner, this guide does not mandate one approach over another. It just means that all three approaches are possible.
• John: Do we have sponsor for the structured Content approach?
• Ioana: Yes, SAMHSA.
• John: That's interesting because in yesterday's CBCC call, Richard Thoreson agreed that we should not be inventing a policy language in HL7 when there are perfectly good policy languages and he explicitly said that XACML is sufficient.
• Ioana: I think you can interpret that to be the power of your persuasion. I think Richard was trying to get to some agreement with you (I don't mean to speak for Richard). But the reality is that none of the SAMSHA implementations will be using XACML. He's agreeing that if all you need is XACML, the structure supports it.
• John: I'm not trying to stop progress. What I want to understand is why are we taking the RIM, based on clinical statements, and trying to make it contain a policy?
  • Clinical Decision Support rules have their own schema for encoding rules, because rules are different than clinical statements. Policies are different than clinical statements as well.
  • Should we be using HL7 as a way to encode policy? I assert that the HL7 RIM is not policy neutral.
• Ioana: The RIM is Implementation neutral. Interoperability means I don't make an assumption that a specific type of engine has been deployed.
• Ioana: What is the best way in which you could help to make this better? You can use the ballot process: review the ballot artifacts on the ballot site, and propose additional language that can best address your concerns.
• John: I would like to have a discussion of the fundamental pathway of solving the particular scope. I would like to understand why, or who needs an HL7 specific encoding of a policy in clinical statements, and I would like to understand from the HL7 RIM architects, why they would endorse using clinical statements to encode policy.
• Ioana: Take a look at Quality Measures. This is one of the reasons behind CDA R3.
  • CDA has outgrown being a one-time clinical document for a specific patient. There is a CDA R3-bake off discussion. It is the clinical document that is being extended. The RIM has always been available, not just for clinical content, for administrative and financial content, etc. It is the CDA R2 that made the separation. They are now revisiting that approach.
  • This is a good opportunity to bring up the question about policy. CDA wasn't originally intended to communicate Quality Measures either.
  • I propos that we have this discussion via some written documentation rather than discussing this verbally with a smaller group of participants.
• John: Question: if I wanted to use XACML or ODRL, this is already available (in a CDA document). If that is true, my question is, why should we do anything else?
• Ioana: I think that is a very worthwhile question that should be posed on the Lists (CBCC and Security), e.g., "why isn't it sufficient for you to exchange Consent Directives in XACML or some other policy language? What other requirements do you have?"
• John: Another question: Are all of the encoding and proper LOINC codes and metadata, already in the draft Guide?
• Ioana: LOINC codes are needed for the sections of Consent Directive (mandatory) and the Signature Section (optional). Every template that has been identified will have its own OID, but we have yet to submit that request to the registry. Since we haven't yet approved the structure, we haven't yet made the request. The ballot shows where the LOINC code or the template OIDs would go, but the specific codes or OIDs haven't yet been requested.
• John: I will formulate my questions based on this conversation and based on a review of the ballot.
  • Now to the current CDA R3 proposals. In particular, the confidentialityCode. If we do not need to encode Privacy DAM information into the body, instead using some externally defined protocol like XAMCL, ODRL, etc., would we need to go through with the confidentialityCode proposal?
• Ioana: No, we wouldn't.
• John: If these CDA R3 proposals went to Structured Documents as they are today, and later we don't need them, is it be a problem to withdraw them?
• Ioana: They are looking to make CDA R3 more encompassing than CDA R2. If they determined that these proposals still make sense for other reasons, they would probably use them even if we no longer required them.
• John: The reason I question this is because in ISO, once a proposal is put forward, it is almost impossible to withdraw.
• Ioana: I don't want to second-guess the process. They would probably prefer we are sure before we submit. But if it turns out that we need these proposals but we haven't submitted them, we're stuck with the CDA R2 workarounds forever.
  • There is no agenda behind these proposals; they are simply reflecting different requirements from different stakeholders.
• John: I just want to make sure that we as a consensus body choose pathways that we all agree with. I don't feel that this is a consensus agreement at this point.
• Ioana: If you have a consensus discussion about any one requirement, you would have a very skinny standard. You need to use consensus where it's appropriate. These multiple approaches stated within the scope represents consensus.
• John: I do think there is still work to be done in terms of showing how the Privacy DAM is encoded in a policy language. There's vocabulary and some structure that would be mandated by HL7.
• Ioana: In the implementation guide, where those vocabularies exist, they have been identified. There are some concept domain value sets that we reused that were created for Consent Directives Release 1. If we create a US-realm IG based on this, we might decide to expand upon some existing value sets. But I wouldn't necessarily do this at the Universal level because they might not be reusable across realms.
• John: What I am interested in understanding is what is the driving force behind this? Another thing to point out is that a policy schema is different than a RIM schema. That may not be obvious to people who think that they want what they think they want.
• Ioana: We are also looking to take the structured content and map it to a couple of languages to have an algorithmic transformation from interoperable Consent Directives to XACML or ODRL.

John: Having the ability to deterministically convert from Privacy DAM to XACML, to ODRL, would be extremely helpful. It also would help to have that evidence to say that we don't need to have an HL7 policy language.

• Ioana: The problem is, if you want that, to enable that transformation from a platform neutral representation to any one of those languages, you need to be express them in the structured body of the CDA document.
  • I have some problem with saying HL7 policy language. It's the same structure that CDA provides for any kind of statements of any kind.
  • We're trying to provide that platform neutral representation so that mapping is possible. It's not an HL7 policy language, it’s a CDA template on an existing structure that's giving you the elements from which the content, based on the DAM that allows you to create the XACML, or whatever the platform desirable language is.
  • That's what we're doing with this representation. Sounds like what would persuade you is to see that transformation from a CDA IG with a structured body to XACML. If it's a deterministic, repeatable transformation, that would persuade you.
• John: No, I don't think that we need to have this. Being able to show that XACML and ODRL fill the bill and we have well enough constrained use of those policy languages to express the Privacy DAM is all we need to do. We don't need an HL7 specific method. The structure of the language is what I'm struggling with. The structure of a policy language is different that the structure of an information model.
• Ioana: Agreed. The question is, can I take an instance of a Consent Directive template and translate that into a set of XACML policies that can be enforced by my favorite SUN reference implementation of XACML?
  • If that's doable in a deterministic manner, then I have a representation of my Consent Directive that can be translated into my policy decision point favorite language.
• John: Everything is doable, it's a question is it the right thing to do and should we work on something else?
• Ioana: A fair point. It will be up to others if they have this need to do the work.
• John: If I thought I could ignore this, I would have ignored this a long time ago. Eventually GE will run up against this (the CDA structured body implementation).
• Ioana: You'll only run up against it if all your exchange partners are unable to use the same access control language. This is a matter of environment. It's only in heterogeneous environments where there is no other way other than to transform into a format that is equally distasteful to all participants. That’s the way interoperability works in this situation.

Meeting adjourned at 2:00 PM EST