December 1st, 2009 CBCC Conference Call

Attendees

• Phillip Barr
• Tom Bonina
• Andre Carrington
• Steven Connolly
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• 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, Call for Additional Items & Accept Agenda
2. (10 min) PASS Update
3. (5 min) CDA R2 Implementation Guide ConsentDirectiveCDAR2ImplementationGuide
4. (40 min) CDA R3 Proposals - Call to Endorse

Minutes

1. Actions:

• Team:
  • Please sign up for the CDA R2 Implementation Guide ballot and provide comments
  • Please review PASS Access Control Service draft v.0.6
    • This will be reviewed on Monday, 12/7 during the PASS conference call. Vote will be taken to determine whether to move forward with this ballot, and at what level (DSTU, as currently planned; or move to Informative, or not submit at this time)
  • Please review PASS Architectural Framework draft which will be posted on the PASS Wiki site COB Wednesday, 12/1.
    • Electronic vote to move forward will be taken following Monday's PASS Conference Call allowing everyone to have enough time to review
• Ioana:
  • Include the workaround example using Precondition, related to specifying confidentiality in a ClinicalStatement in the CDA R3 Confidentiality code support in ClinicalStatement choices proposal (it is already depicted in the balloted CDA R2 Implementation Guide)

4. Updates/Discussion:

PASS Update

• PASS Access Control Service draft v.0.6 is posted on the PASS Wiki site
  • Walkthrough on PASS call Monday, 11/30. Looking for review and comments
  • Will call for a vote on Monday, 12/7 to determine whether to continue to ballot as DSTU, or Informational ballot, or not ballot at all.
  • Covers interfaces 1 & 2 – relatively low level Access Control
• Don working on PASS Architecture Framework document that will be posted on the PASS Wiki site by EOD Wednesday, 12/1 (link will be included once posted)
  • This will be balloted as Informative. Looking for approval to go forward, but will probably have to an electronic vote in order for everyone to have enough time to review.
• Next work will be for PASS Access Control, interfaces 3 & 4, which includes Consent Directives.
  • There wasn't enough time to complete these in time for this ballot, so they will be included in upcoming ballot cycles.

CDA R2 Implementation Guide

• CDA R2 Implementation Guide has been submitted for publication and is posted on the HL7 ballot site
• Please sign up to comment on the CDA IG
• Found some good resolutions to some of the mapping issues from domain analysis to the document structure in the existing CDA R2 structure
• We plan to publish the final normative version of this (DSTU) guide using CDA R3

CDA R3 Proposals – Call to Endorse

The official time for CDA R3 proposals has already elapsed, but SD WG indicates that if the proposals are compelling they will be considered when submitted

Role codes for information recipient and other participants

This can be used to define who you intend to receive a particular document

• This CDA document is a policy that rules over other CDA documents
  • The Consent Directive Clinical Document Implementation Guide sets the rules on how you declare a Consent
    • You can say this Consent goes to a specific type of user
    • Within the body of the Consent, I allow this type of information to be disclosed to a specific type of information user
  • We may need to broaden this proposal to apply to ClinicalStatement as well because we want to specify the structural and functional role in both places
  • Assuming this is a request to change the structure of all R3 documents, aren't we putting a little bit of policy in all documents?
    • Concern that this may break some of the work being one in Access Control.
    • The RIM supports this, and CDA R3 is intended to support the creation of richer documents.
    • It appears we're recommending that we allow a mechanism for bits of Access Control policy (structural & functional roles) for who can see this particular document whether it’s a Consent Directive or other clinical document. It's in the document header; it's outside the Access Control system
    • Right now what exists today is the ability to specify who is the intended recipient for a document
      • That's a routing value, not an Access Control value
    • True, but it's also for the purpose of document management
    • Right now you cannot say, the (functional or structural) role of the intended recipient is a physician for instance
    • If you're using CDA to express Consent Directives, you may need specify structural (and functional) roles to include specific types of users
      • The CDA structure is re-usable. It is intended to support all the different types of use cases
    • Identifying the functional or structural role in a CD itself, would be part of the payload of a CD as opposed to a document
      • Why would you put this in the header? This consent directive can only be disclosed
    • Amend it so that it includes the payload (body) Clinical Statement
    • There are two distinct uses, both of which are valid
    • Pat doesn't agree that one is valid
    • The only thing that is missing is the functional and structural roles from the description of the recipient
    • Marking a document that it is intended only for clinicians, not intended for others who have access to the healthcare record for other purpose is a valid use.
      • We already have mechanisms to do this. This document is of a class that has a confidentialityCode that we apply policy to that would do the restriction to the individuals defined
  • Ioana: I'd like to make a motion to approve the proposal
  • Discussion: Don't think we're all thinking about the same concept. We're taking the Privacy DAM and taking parts of that policy to litter this throughout the CDA document and repurpose existing attributes instead of saying here is a policy that needs to be encoded within the body of a CDA document so it can be carried around using the mechanisms that carry a CDA document
  • Here's how we arrived at this requirement:
    • Tried to specify the information recipient using the information recipient for a specific information artefact. Responding to a specify request for data. There is no way to specify who is the intended recipient (unless the recipients is an organization or an individual). You can overload the confidentialityCode
    • This would apply to the information recipient of the policy as well as the information recipient of the Consent Directive
    • This can be done either in the header or the body, which provides more flexibility
    • Vendors are going to implement the implementation guide that is provided to them. They do not have to implement everything that is in the CDA R3 specification.
    • This enhancement only makes things possible. It doesn't mean that you have to implement.
      • I don't have to reference it in the implementation guide if I don't need it.
      • You don't implement CDA R3, you implement a CDA Implementation Guide (for CCD for example)
    • The objective of CDA R3 is to add more of the RIM attributes that were constrained out of CDA R2
    • The purpose of this enhancement is to support the capture and transmission of Consent Directives
  • Call for a Vote:
    • 6 Abstained: (some not enough background/understanding)
      • Rob Horn
      • Milan Petkovic
      • Andre Carrington
      • Phillip Barr
      • Mike Davis
      • Richard Thoreson (co-chair)
    • 2 Opposed
      • John Moerhke
      • Pat Pyette
    • Approved
      • Serafina
  • Proposal is withdrawn due to a significant number of abstentions
    • There's a sense that there is not enough understanding of what this means. Don't want to vote down something that may be useful.
    • For now, appears that we will not submit a formal proposal to Structure Documents, but will revisit the proposal in upcoming meetings to enhance understanding within the work group and determine whether this needs to move forward (including broadening the proposal to apply to the ClinicalStatement

Confidentiality code support in ClinicalStatement choices

In specifying an entry in a CDA R2 document, you cannot specify confidentialityCode

• Where this comes up in a Consent Directive, you cannot say that you want to disclose specific type of information with a certain sensitivity
• Advised by Structured Documents to use a precondition
• Currently you cannot specify the confidentiality of a ClinicalStatement.
  • You can specify the confidentiality of a section or a subsection, and the whole document but if you're trying to describe a CD that part of its assertion has a reference to confidentiality, you cannot do this because confidentiality has been constrained from ClinicalStatement
    • The ClinicalStatement appears only in the body of a document
    • We cannot express a Consent Directive in terms of a confidentiality code using the native RIM confidentialityCode right now
  • The workaround example is in the CDA Implementation Guide, but will also be included in the proposal as well
  • Greater problem of encoding the policy into a CDA document needs further work before this solution is the only way to go about this: I don't think that the attribute of confidentiality code in the context of a policy is the same thing as the context of a conf code in the context of an attribute within a CDA document
  • If that consent directive refers to confidentiality code, you need to refer to the conf code in some fashion. Precondition is how you refer to this now since confidentialityCode has been constrained out of the CDA in R2.
  • John doesn't understand the approach being taken
• It is appropriate to have the Privacy DAM and a way to encode it as policy.
• I don't think that we have to map this to CDA content. We have to encode this as policy because a policy statement is different than a clinical statement
• Where we have captured in the Privacy DAM concepts that are in the RIM, that we have leverage that harmony. I don't think that leverage means force the ClinicalStatement to look like a policy
  • The reason we had problems trying to represent a policy statement using a ClinicalStatement is because it was constrained to be a ClinicalStatement.
    • This proposal asks to expand the ClinicalStatement to allow to specify the policy attributes that are needed by Consent Directives, to allow for a broader set of concepts to be expressed. This proposal addresses the clinical need to express the confidentiality of an order
• CDA is a great envelope for sending Consent Directives. But getting into the policy language, what is encoding the policy of the Consent Directive, that should be a standalone schema that reads top to bottom as pure policy. I don't want to have to go spluenking through all parts of the CDA document to try to put together a cohesive policy
• Back to proposal for adding confidentialityCode to the ClinicalStatement, are you (John) objecting to this proposal
  • I would abstain – because it not clear this is the only way to go forward
    • It's not, there is a workaround. This proposal is intended to eliminate the workaround (precondition criterion by replacing with confidentialityCode in the ClinicalStatement) from CDA R3
    • The overall approach of using an entry in a section in a structured document to express a Consent Directive, instead you might prefer to express this using an access control language which is also possible
    • This proposal allows others who would like a platform-neutral representation way to encode a Consent Directive
  • John's concern is not on the use being described, but on the abuse that would likely happen if these policy fragments show up all over the place. We'll start to see policy fragments show up in Clinical Documents themselves and the Access Control infrastructure will not have a separation of policy from clinical content. Now the Access Control system will now have to read every single byte of every single clinical content looking for somebody's abuse of putting policy statements throughout the clinical information. Separation of access control from clinical content is important.
    • There is nothing in this proposal that implies policies will be mixed with clinical information
    • This addresses the need to encode a Consent Directive using CDA
• There are examples where security is included inside the document itself. Quite common in DOD to classify every paragraph of a document with a marker; instances where we digitally sign or encrypt different sections of a message
  • This is neutral to that. This is the ability to specify a confidentialityCode is continuing something that is already available, Not doing anything that the CDA document is not already doing.
  • It is hard to make an objective evaluation when there are other things that are of concern. This is just a proposal to add a confidentialityCode to the ClinicalStatement
• This conversation should be continued in upcoming meetings. Since Structured Documents is willing to extend consideration for these proposals, we should continue to review the proposals and each person make up their mind as to whether to endorse the proposal or not.

Meeting was adjourned at 3:05 PM EST.

No significant motions or decisions were made.