December 8th, 2009 CBCC Conference Call

Attendees

Anticipated

• 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 voice prints, finger prints, 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 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 a 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 a 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 these (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.
    • 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 link to the CDA header when using a document as the mode of transport
  • 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. There is still the need to create metadata describing the type of policy language being used. This is value that HL7 brings to the table. Attachment is in X language using Y vocabularies and other information that is not describable by policy languages themselves. Binding to patient, organization.
• Pat: when multiple policy definition languages are endorsed, part of that endorsement must include a transform from one to the other.
  • 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
• 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. However, it is recognized that coming up with a new markup language or definition for policy is difficult.
• John: Constraints on policy languages are far easier to come up with and closer to our WG subject matter expertise. We can perform analyses of the specific language towards the Privacy and Security DAMs. We don't need a concrete model that represents the DAMS, an abstract model is sufficient. We should only look to Structured Documents for how do we carry this policy blob in a persistent object.
• Tom: one option is to use Observation Media. Another is the non-XML body portion and say the policy is embedded. This is base-64 encoded, but we can indicate through some of the MIME-types and data that this is a certain type of document. Similar to an application pdf being embedded that requires a known application to process it. We can do the same thing with XACML, whatever
• Richard: Can we expect that the consent directive is sent in the same package along with the payload of clinical data?
  • No – this would require two separate documents. CDA would describe the type of document – clinical data versus the privacy policy
• The CDA has the ability to reference documents for example, a clinical document has a reference to a consent
  • Conceptually it works, but there are scalability problems with that approach
• There was discussion in the past about tagging clinical documents with a policy identifier.
  • This is problematic since if policy changes, you have to update the clinical documents
  • Confidentiality code value is the thread – permissions are not applied to a users account, they are applied to a role and users are assigned to roles. There is an indirect relationship between an account and the permission they have. Confidentiality code is a grouping mechanism. You don't apply policy identifiers to the clinical content, you apply policy values to particular confidentialty 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 consent directives to change dynamically over time without having to recode the content.
  • 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

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