This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

February 23rd 2010 CBCC Conference Call

From HL7Wiki
Jump to navigation Jump to search

Back to CBCC Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes Feb 16th, 2010 & Call for Additional Agenda Items
  2. (10 min) CDA Implementation Guide sample documents discussion
  3. Privacy Policies Scope Statement review

Announcements

Minutes

1. Action Items

  • Team: Please provide peer review comments for the Harmonized Security and Privacy Domain Analysis Model to Ioana/Serafina or the ListServ by COB March 4th

2. Resolutions

3. Updates/Discussion

CDA Implementation Guide sample documents – Substance Abuse Consent Authorization

  • The intent of this sample document is to provide an example of a Substance Abuse Consent Authorization as rendered based on the CDA R2 Implementation Guide for Consent directives
  • The samples make it considerably easier to make comments against the guide, so this is much appreciated
  • Keith Boone suggested we present this example at the next Structured Documents Work Group meeting on Thursday, Feb 25 to get their input
  • There are many different work group perspectives and Keith’s comments are coming from the perspective that there are a number of things that might not be encoded properly within a CDA document
  • One of the items we can discuss today is related to the email thread, we should not be engineering the signature part of the consent directive. If we discover something that we don’t have the capability for, we can create an action item
  • From an international, HL7 perspective, there are a set of signature mechanisms available:
  1. signature on file
  2. signature mechanisms by which you can scan in and attach the scanned image
  3. a couple of forms of digital signatures
  • To clarify what Ioana was trying to say within the listserv email thread, is that within CDA R2, there is no support for carrying a digital signature; CDA R2 explicitly constrained digital signatures out. The only thing you can have in a CDA document is have a legal authenticator with codes to say that the signature is on file, or is pending or is intended
  • The point of an XML-digital signature is not that you need to have support in the XML blob. You can use an XML-digital signature to wrap any XML, so there is no need for XML-digital signature support within CDA as long as it is an XML blob, it can be signed. This is the position that the Security WG has had for a long time on this subject
    • But you would have to put the signature in another XML wrapper, it would not be part of the CDA payload
  • XML signature is a wrapper, it is not part of the CDA payload
  • CDA requires that the structured content of a document be rendered in a narrative block. For clarification purposes, the CDA document that is being circulated is no replacement for the hard copy that is signed by the patient, but is an interoperable representation of what is being signed and can even be used to convey the content of that scanned document. But it is not intended to be a document that is signed by a patient.
  • There is a requirement that HITSP put in that is not in CDA. The coded content within the structure is represented with a special content tag. If you hover over the coded concepts, you’ll see a reference to the content semantics.
  • There are a number of other sample forms that Ioana will render as examples to help the WG review the specification for the implementation guide. These examples will be sent to the listserv for review

Privacy Policy Reference Catalog scope statement

  • The revised scope statement was presented by Pat
    • The title was changed “Privacy Policy Reference Catalog”. If others disagree with the title, it can be changed
    • Project Need: The Catalog references CDA R2 Implementation Guide for Consent Directives specifically
    • Removed all references to the term “template”
    • Other change is to the deliverables and the target dates. We removed the Comment Only ballot. We’ll go straight to DSTU and after one year trial, we’ll move to a Normative ballot
      • John questioned why we don’t indicate that the DSTU is intended for a two-year trial period. To expect the implementations to evaluate our reference policies and provide feedback within one year, might be too short a time frame
      • The expectation is that the VA and SAMHSA signing up as project implementers, we expect to receive adequate feedback from those early adopters
      • It is easier to indicate this is a two-year trial and then after one year, provided feedback is adequate to go Normative, to do so, than to initially schedule this for a one year trial DSTU and extend it
      • Once the trial DSTU is complete, if there are no changes required to the ballot, it can automatically become a Normative standard
  • Don made a motion to amend the project scope statement as currently written to extend the DSTU for two years, and take a vote to approve
  • The motion was seconded by Pat
    • The motion to approve the project scope statement passed 11/0/0

Due to a number of members attending RSA and HIMSS, the CBCC WG meeting for next week is canceled

Meeting was adjourned at 2:30 PM EST