March 9th CBCC Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Rob Horn
• Don Jorgenson
• John Moehrke Security Co-chair
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair, absent
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve Minutes Feb 23rd, 2010 & Call for Additional Agenda Items
2. (55 min) Sample Consent Directive Forms Review

ACTIVE PROJECTS

• CDA Implementation Guide
• Privacy Policy Reference Catalog

Minutes

3. Updates/Discussion

Sample Consent Directive Forms Review

• Sample CDA documents were prepared to show what Consent Directives would look like if they were encoded using CDA document architecture. They will be added to the ballot in the appendix to illustrate the implementation guide
• The examples were reviewed by the SDWG, feedback was provided by Keith Boone and Ioana addressed those concerns
  • One of the issues that Keith raised is the fact that we are referencing a different concept domain that is not appropriate for Act.code. We are fudging the rules by assigning it to Act.reasonCode. We may need an extension. We are waiting for Keith to respond to Ioana’s comments
• Another comment was related to the need to use of the HL7 “cast of characters specified in Appendix D of the Publication Facilitator’s Guide. Ioana noted that none of the CDA Implementation Guides that have been balloted use that cast, nor does the CCD so this hasn’t been enforced
• An Australian Consent Directive example will also be created and included in the Appendix, along with the Canadian Consent Directives which illustrates the Universal Realm aspect of the guide.
• The CDA documents are rendered using a modified style sheet because there were some labels that did not make sense for a Consent Directive as they were taken directly from the CDA clinical document (for example – authenticator was changed to the more meaningful term “witness”
  • The VA Consent provides the ability to specify any information artifacts and the ability to name the purpose of use. There is no restriction as to what a client can enter so this is clearly intended for manual processing at this point
• Since all these forms use similar references to information artifacts, you basically come up with an identical Consent Directive. Therefore the structure that we have defined supports all the different sample forms that were provided to us as examples
• One of the limitations of the existing CDA representation is the fact that these are not embedded in the document; they are referenced as renderable content. The readable part is not a MIME-encoded document, but we have the ability to include it as a binary object
• If you hover over the elements that are outlined in dotted lines, the Content Semantics is displayed. These are references to entries within the structured body of the document. One of the CDA requirements is to have renderable narrative content that is equivalent to the structured content in the section.
• Liora’s team has developed a style sheet that will render the structured content rather than the narrative. We will try that style sheet to see how our content is represented. It may not be that user friendly, but that may not matter since you always have the signed document to refer to as well
• This is the interoperable representation of the Consent, at least for the foreseeable future. This is not intended to replace anything that is being done on paper. That still has to happen. It simply encodes this so that it could be understood by either the receiver of the information or the intended requester of the information depending on how it’s used
• Ioana then displayed the Canadian example. It is much simpler. You can either make the disclosure or revoke the disclosure directive. The Form Number was used as the policy reference.
  • Pat indicates that’s appropriate at this point. Who knows what the policy identifier is the form number is probably as good as it gets. The intent of the Privacy Policy Catalog project is to address this need – to identify a specific policy with an associated identifier
• Currently there is no example of a document that only contains the wet signature. Instead of having the entire document scanned in, there could be a separate document that only shows the signature along with perhaps the printed name of the client, witness, substitute decision maker
  • John said that isn’t necessary since a signature without the text associated with it is not really a legal document despite the fact that the credit card industry is getting away with it
• Ioana has a few more examples to create which will be included in the Appendix. These examples, along with changes to the guide based on the feedback from the SDWG will be included in an updated version which we can circulate to the team and present on an upcoming WG call
• Following the review of the example Consent Directives, Ioana asked whether creating the sample documents helped to clarify the Implementation Guide. The group feels they are a nice sanity check – since you could review the examples and then go back to the text and gain a deeper understanding.
  • As long as people recognize these are examples and don’t think that we are promoting one policy over another. As a matter of fact, we don’t care what kind of policy you want to enforce. We’re policy agnostic, we simply want to be able to exchange these in an interoperable way.
  • As far as a sanity check is concerned, creating these examples has been proof that we’ve covered all the bases. For instance, we haven’t had any input from Australia, yet when we received an example consent directive from them recently, it was clear that we can support it
• Pat made a motion to adjourn the meeting early since this was only the item on today’s agenda. Motion seconded by Ioana

Meeting was adjourned at 2:30 PM

No significant decisions or motions were made