October 27th 2009 CBCC Conference Call

Attendees

• Bernd Blobel Security Co-chair, absent
• Tom Bonina
• Steven Connolly
• Tom Davidson
• Mike Davis Security Co-chair
• Suzanne Gonzales-Webb CBCC Co-chair
• Don Jorgenson
• Rob McClure
• Steve Meyer
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida
• Craig Winter

Agenda

1. (05 min) Roll Call, Approve Minutes, Call for Additional Items & Accept Agenda
2. (20 min) Privacy Consent DAM Ballot reconciliation - Canadian comments
3. (25 min) DRAFT CDA Implementation Guide - Discussion

Action Items

1. Pat will draft clarification the definition for Shared Secret, which will be added to the glossary (Item #16, line 19)
2. Ioana will address the outstanding items in the Privacy DAM Ballot (related to diagram fixes/changes.)
3. Review draft CDA Implementation Guide for next meeting. Continue discussion related to using sectionText versus actText on the ListServ.

Minutes

1. Accept Agenda

• PASS Consent Requirements Draft review taken off the agenda
  • Was only on the agenda as a carry over item from previous weeks
  • Not needed for the current PASS Ballot, likely to be for the May ballot, so it will be removed for now

2. Privacy Consent DAM Ballot reconciliation – Canadian Comments

• Last few comments were discussed. After review, a vote was taken to approve the Canadian dispositions
• Item 57: Match Keyword (to override consent): This use case will be renamed so it doesn't imply a match is done.
  • This comment is related to comment #30. The Match Keyword use case will be renamed to Assert Patient Consent (to override consent)
  • Shared Secret and Keyword are equivalent terms from the Canadian perspective (Keyword is in use in British Columbia & Newfoundland for their drug system). Keyword enables clients to allow providers access to sensitive and/or masked/hidden information upon the provision of the Keyword at the point of care
  • In the US, the concept of Keyword may be replaced by a “password/shared secret” or other mechanism that can be revealed at the point of care by the client if necessary
• Item 58: There was a misunderstanding about a use case triggered by Figure 4, which was cleared up by the following discussion. The Privacy DAM will be updated to clarify the intent of the use case, Information System Flags Masked Health Record Information, found in the Appendix.
  • Pat’s interpretation of this use case was to set the confidentiality code on an object; it wasn’t related to the policy side. Policy would then execute based on the operations being done on that object.
  • Ioana: This came across incorrectly and we will clarify it in the document. Flagging happens as a result of executing a specific set of rules then determining whether this user with these particular assertions can see that information.
    • The intent of this use case is to determine whether or not you can see masked information, even to see whether or not masked information exists (something masked without your knowledge). It isn’t related to setting confidentiality codes.
    • Information is marked as masked, but without this feature, you would know there is something that you cannot see.
  • This provides the ability, based on jurisdiction, to distinguish whether you should even know there is information that you can see. Some jurisdictions allow you to know, some do not.
  • Disposition changed from Not Persuasive to Not Related.
• Item 62: Disposition was changed to Persuasive and proposed wording replaced existing wording for Manage Shared Secret use case
• Item 71: Pat had a question about object reference that has a single attribute of category and there’s also information reference that has a category. What is the difference?
  • Ioana: The answer to the question is: object reference has a code that is an information object and information reference has a category code that is a whole category of information, like Medication. One refers to atomic objects; the other refers to categories of data. Information reference that has an attribute called category code and then objects that have an attribute called code that is an information object code like Order, Medication. Basically reflecting the current distinction in HL7 – broad categories like laboratory results, then you can have the discrete object types that would be in laboratory. There is a difference in the granularity of the data. There is a value set from RBAC for information objects.
  • Disposition comment: we will clarify the difference between category and object code.
• Item 75: The intent of the comment was to suggest a change to the model so the client, the consenter, and target record would be different. The Information Model (figure 10, not figure 8) will be updated to reflect the appropriate relationships.
  • Rob was concerned about the change to the model.
  • Pat provided the clarification for the change.
    • My original concern was that Client was hanging off of consenter and consenter is from a consent directive perspective is only there from an Audit thing. Who is it that created this Consent Directive? Whereas the client is a first class and key information blob associated with the consent directive and I wanted to make sure from a modeling perspective, yes the client could be the consenter or the consenter could be an SDM, but the client wasn’t dependent on a consenter, so if the consenter went away the client wouldn’t.
  • Ioana: This also provides the capability to capture the relationship between the client and the consenter. This works well for CDA as well. The consenter has a relationship already, a property of this association. It is much easier in the DAM to show the consenter has a relationship to the client so that is by virtue of this relationship between the client and the consenter, there would be an attribute of this association: that would be the relationship. That’s the major change. This basically preserves the semantics and I think it’s a better organization.
  • Rob: I’m thinking about using these things rather than creating them. Where is this going to occur?
  • Ioana: When you issue a consent directive, you can have a SDM as the consenter who signs off on the consent. And the consent refers to a specific client’s medical record or set of records. We’re capturing the sign-off of the consent is separate from the consent itself. But we also capture the relationship between the consenter and the client.
  • Rob: Is there a use case that would say, for this client, I consenter, am consenting for these kind of records.
  • Ioana: You’re consenting for a specific client for a specific set of records but it’s in the consent rule that you’re naming specific information objects or categories of information.
  • Pat: Specific set of records doing that based on, you could say, all of them based on a category or a confidentiality code, or sensitivity code or purpose of use.
  • Ioana: These are the detailed rules on what parts of my records would be protected by this particular consent that is pointing to information for patient xyz.
  • Rob: what you’re saying is that a consenter can provide a consent directive for a client. But when you apply that consent directive to a personal health record, it would, through a process you can identify; these are the records that are managed by that consent. But that is completely outside of this DAM. That’s a secondary thing. I was worried that you were saying that within the context of this DAM you have some link between the consenter and the personal health record without the client, and you don’t. I think this change does make sense and makes it much clearer.
  • Ioana: No, this change doesn’t change the intent.
  • Disposition is updated to Persuasive and the information model will be updated.
• Ioana made a Motion to approve the revised Canadian dispositions.
  • Seconded by Pat Payette
• Vote: Abstain: 1 (chair); Oppose: 0; Approval: 15

3. CDA Implementation Guide draft

We don’t have time to fully review the draft Implementation Guide this week. We will devote the full hour to it next time. Ioana provided background on the intent of the document and addressed some of the concerns raised in an email from Tom Davidson.

• Ioana: There are a few objectives for this Guide. One intention is to stay backwards compatible with the basic privacy consent DAM. I don’t know if that’s a good idea or now. The question is what effect will it have on a structured document?
• Tom: The BPPC currently has constraints in it that may be too restrictive for what we’re doing. Right now, it only defines a mechanism and the structured body to allow a physician to assert the consent. It doesn’t capture half of what we’re trying to. So one of the questions I posed is, are we required to be bound by this, because BPPC already has an implementation guide for a CDA document? Do we want to look at this as a starting point but not necessarily constrain ourselves to it?
• Pat: I’ve had discussions with Glen and John about this. BPPC was never meant as the thing that we’re trying to do with the DAM. It was “the best we can do at this time”. They fully expected that in time, an APPC would be out there. We should try to be compatible where we can but we shouldn’t be bound by it.
• Ioana: My intention is to inherit the constraints that BPPC introduces. Things like constraints on the header that are already in place, like document type, service event code. Where we are differing is in the structure of the body.
  • So right now the BPPC implementation guide supports only a Non-XML body, which is a base-64 representation of a scanned document. That’s all it has.
  • So what the CDA consent directive Implementation Guide would introduce is additional templates to constrain, either a non-XML body or a structured body. You can have both. That’s why I didn’t see a problem technically inheriting BPPC because you have to make a choice.
  • If you make a choice to do a scanned document, you’ll be consistent with BPPC. That’s where the backwards compatibility comes in.
  • If you make a choice to use a structured body, you will use the constraints in the implementation guide. We’re going to provide guidance on how you use the clinical statement to describe all the consent directive criteria that we have in the DAM. That’s in a nutshell what we were trying to do.
  • You’ll also see tat we need additional constraints to the CDA header as well. We need to include Information Recipient, to support the overall behavior of revocation of consent directives we need to support the document parent. So there are things like that in the header that we are adding on, but we are re-using the handful of constraints from BPPC. Anyone who confirms to the CDA IG, you will have to implement additional characteristics. If you conform to this guide, you have to do many more things than you’d have to do with BPPC. But one of those choices could be to only support a scanned document. If you disagree with this, we can take this out.
• Pat: we can support both simultaneously, right?
• Ioana: We can support either a scanned document or a computable version. But in the structured document you can have an HTML version of the document. BPPC made a choice to put a scanned document in the non-XML body.

Tom: That’s because there’s a CDA constraint that limits the allowable form in a structured body. There are some proposals for release 3 to allow that but right now this is a limitation.

• Ioana: The actText in the structured body could be base-64.

Tom: But the sectionText cannot. So we’re getting into whether we use actText or scetionText and we’re probably going to loose people quickly.

• Ioana: If you have ideas and suggestions, these are the basic questions. We can continue in this backward compatible way; if you want to use sectionText you’re going to implement a document body like BPPC suggests and scanned document, because that comes directly from scanned document XDSD. Our objective it to accommodate structure as well as encoded policies, something like an XACML representation of a consent directive along side an HL7 structured representation of that same directive along with an HTML form and/or pdf form of that signed document. We would like to support all three representations.
• Tom: That’s a lot to include in a single document. There are other mechanisms for referring to other related documents that we might want to look at.
• Ioana: That’s correct. You can have a reference document, so we could reference the scanned document.
• Tom: Those are options as well; you can have external references or related documents. That can be a scanned document; the other form might be an XACML representation of it.
• Ioana: We have about a month. What you see in the CBCC DAM is what we want to represent. We just have to look at the CDA R2 for the optimal way of doing this. I would encourage everyone to provide feedback and suggestions and we can continue the discussion about sectionText versus actText conversation on the Listserv.

Meeting adjourned at 3:10 PM EDT