November 10th 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
• Milan Petkovic
• Pat Pyette
• Ioana Singureanu
• Richard Thoreson CBCC Co-chair
• Serafina Versaggi scribe
• Tony Weida

Agenda

1. (05 min) Roll Call, Approve Minutes, Call for Additional Items & Accept Agenda
2. (55 min) DRAFT CDA Implementation Guide - Discussion

Action Items

1. Ioana will schedule a separate CDA Implementation Guide project meeting via the HL7 Conference Calendar. Invitation will be extended to the Structure Documents, CBCC and Security WGs. This meeting will be in addition to the weekly CBCC WG meeting which will be focused on Report Outs from other groups/projects and CBCC specific issues.
2. Mike will write the definitions for the two distinct use cases which illustrate how the CDA can be used to (1) express a client’s privacy request and (2) to express the organization’s privacy policy
3. Tom will send the new LOINC code value for Privacy Policy to the ListServ (CBCC and Structured Documents WGs).

Minutes

Continued from Security WG meeting

Question 4: Are there Privacy policies where data integrity is relevant to Privacy Policy?

Data Integrity is an important criterion for Security for Access Control. With respect to Privacy, Data Integrity is an attribute having to do with the quality or integrity of the data that the patient’s interested in. This has not come up in the discussions about Privacy and Consent Directives. So the question was posed, is this concept relevant to Privacy?

As an outcome of the summarized discussion below, it was decided that there may only be a very narrow use case (where the data integrity of IIHI matters prior to being transferred from a provider to the client’s PHR is called into question), so the decision was to add this issue to a list of open harmonization items (Security & Privacy DAMs):

• Ioana: The data referred to with respect to Data Integrity are the information artifacts subject to Access Control policies – the types of information that would be protected, IIHI. Is there a situation where we want to make assertions about privacy?
• Don: That is not already covered by security policies?
• Ioana: The question is, do we want to assert a Privacy policy that says something about a specific information artifact’s integrity. It doesn’t matter from privacy policy perspective that you can attest to the integrity of a document.
• Tom: Isn’t that up to the document that you’ve retrieved and looked at? The document you retrieve contains the attestation within it. It’s up to you to decide whether you’re going to do anything with it or not.
• Ioana: You would not set that as part of the privacy policy declaration, is that what you’re saying?
• Tom: I’m not sure a patient would understand the difference.
• Don: Would a policy like that be something like if document is corrupted, don’t send to patient?
• Tom: Not necessarily corrupted, but it’s not signed off yet. The physician on record has not signed everything and attested to everything yet, so should that document be released?
• Mike: This is not document integrity or transmission integrity. It’s an ISO attribute identified as belonging to the target’s Access Control information in ISO. “Has the doctor signed off on the progress note” is a good example. We have policies about such things. If the doctor has not signed, then other doctors should not see this; it’s a patient safety issue.
• Tom: Is that a privacy policy or is that an internal policy?
• Mike: That’s what Ioana is asking. Is there a privacy relevant mirror to this integrity marker in the Privacy realm, so the patient would say something to that affect as part of their Consent Directive? So now we’ve defined the problem.
• Don: So there is the case where if a physician hasn’t discussed a certain thing with a patient, then disclosure shouldn’t be made.
• Pat: And it’s not an integrity issue. My take is that integrity is part of the safeguards that you expect as part of fair information practices that a patient expects from a heath care system, so asking them or giving them the authority or the right to determine the collection or disclosure decisions…it’s an assumption that we have to make. It’s certainly a security consideration, but I’ve never heard of it in terms of Privacy. It’s always an assumption in Privacy discussions.
• Mike: Let’s say the patient says I want to insure that in the Access Control realm, that no assertions of policy are made by any of my delegates that I have not authorized. So what you have is a delegate that comes forward and says that I am going to assert something on behalf of this user. And the integrity policy says validate that the sponsor, the “delegator”, has signed off on the delegate having that right. Does that make sense?
• Pat: It does make sense, but that’s in my mind is not necessarily a privacy issue. It’s a client’s preferences policy, but I wouldn’t call it a privacy issue.
• Mike: So is a Consent Directive limited to privacy?
• Pat: That depends on the jurisdiction. We’re trying to have Consent Directives more like the discussion around Consumer Preferences. In my experience, Consent is around informational consent, about privacy. I wouldn’t necessarily think that agreements are not necessarily the same thing as Consents, and shouldn’t necessarily be handled the same way.
• Mike: OK, we’ve defined what we mean by integrity. It means some attribute having to do with the quality or integrity of the data that the patient’s interested in. What Ioana is asking the privacy experts here, is there a use case that requires us to look in the DAM for Privacy? It exists in Security already.
• Ioana: It might just be an assumption that the Access Control enforcement will take care that integrity is verified. But maybe in declaring a privacy policy or a Consent Directive based on the privacy policy, it doesn’t necessarily need it. One of Richard’s use cases is that clients of health care system should be able to express not only Authorization consent, but in the context of Personal Health Records, able to express preferences regarding the automatic update of their PHR (if it’s technically possible). In that case, I don’t want anything in my PHR that has not already been signed off by my providers. So maybe it’s not necessarily an attribute that’s tied to Privacy policies, but maybe in the realm of preferences.
• Pat: This seems like two things are happening here. One, is the client is giving consent to the provider to disclose the information the provider has to the client’s PHR. Second the client is authorizing the provider’s system to update the PHR. There’s a security and access control policy as well as consent directive policy.
• Ioana: It may only be in that narrowly described use case (adding data to a PHR) where the data integrity attribute matters. So I think for now, this will be added as an open issue for harmonization.

Draft CDA Implementation Guide

Prior to delving into the CDA Implementation Guide, Mike brought up a question as to the purpose of the CBCC call.

The group decided that while origin of the CBCC call was to gain a better understanding of the privacy requirements for Security, it would be better to schedule a separate call whose purpose is to support the CDA Implementation Guide. That will allow those who are interested in participating solely in CDA IG, rather than for internal CBCC discussions.

• The CBCC Work Group calls will focus on report outs for the projects (e.g., PASS), and other CBCC-specific issues.
  • A CDA Implementation Guide call will be scheduled for Thursday afternoons (1:00 PM Eastern). The Structured Documents Work Group will be invited to participate
  • The CBCC WG will attend Structured Documents call on Tuesday, 11/17 from 4-6 PM EST to follow up on issues identified in the CDA IG call

The rest of the hour was used to discuss the CDA Implementation Guide

• How do we need to constrain the CDA R2 specification to instantiate a Consent Directive?
• The Structured Documents WG was sent a draft document that maps the Consent Directive classes/attributes to the CDA and identifies some gaps. (This list is incomplete and will be fleshed out in future CDA IG calls).
  • In the left column are the classes and attributes in the DAM; right column maps these items to existing templates or document elements and attributes.
  • One of the identified gaps stems from the attempt to maintain backwards compatibility with the BPPC specification. What happens to the scanned Consent Directive document because the specification doesn’t allow you to put it in an entry as a text element of that entry?
• Tom: There are three answers to that:

1. You can use related document
2. As you did the option that you chose where you’re embedding it into an Act
3. You can achieve the same thing through related document

• Ioana: My understanding is that the related document is supposed to represent the Consent Directive that you’re trying to replace.
• Tom: You can also use it as a transform and reference it as a parent. So if it’s a structured representation, you can point to the scanned version.
• Ioana: So if you already have a scanned version of Consent Directive and you’re moving to this version, you could use related parent document ID and point to the Consent Directive that this new document is replacing, that could be a scanned document.
• Tom: CDA R3 is entertaining the ability to embed a scanned document as part of the structured body.
• Ioana: That would become a possibility. In the meantime, you said we could also use the scanned document in a non-XML body, so if you’re using a structured XML body you wouldn’t have that choice except by reference.
• Tom: Given CDA R2, those are the limitations.
• Ioana: So right now, the proposed mapping is the external document, part of the entryAct (?) reference. And basically the consent directive parent document could also point to a scanned document but it would be the scanned document that explicitly replaces this document, versus the external document which would point you to the equivalent scanned version of this consent.
• Tom: I’d probably use transform instead of replace. If you’re using a scanned document, you don’t have the signature. This is reason I want to embed the image along with the XML document, all in one spot. Is it valid without that signature there? You’d have to retrieve two documents to ensure that the signature exists. I like the fact that you have it tagged as a potential gap so it can be discussed with Structure Documents WG.
  • One additional comment, currently the code you’re using in the display name is the code for the CCD. LOINC created a code for Privacy Policy.
• Ioana: In place of the summarization of episode note or the service event code?
• Tom: Potentially both. Tom will send out the code via the ListServ (CBCC and Structured Documents).
• Pat: There are some jurisdictions that don’t require signatures on Consent Directive and some may in fact, prohibit the requirement that says a patient must sign a Consent Directive. If someone shows up and represents themselves as a certain person, you have to take them at their word.
• Ioana: This specification does not require a scanned document or a signature be included. I have one question for you Pat regarding Shared Secret or Keyword. That should not be sent in a Consent Directive, correct?
• Pat: I agree. That is between the client and the provider
• Ioana: I’m mark this as a private attribute on the DAM (by default, all others a re public attributes). We also have a few questions about InformationReference.sensitivity, FunctionalRole.roleCode and Role.name. That is on the information recipient. This is something that may be relevant to specific jurisdictions. But even if we can’t map these attributes, we will be able to support the majority of Consent Directives that people are formulating right now.
• Tom: From an Authorization to Release Information perspective. You used the consenter as the author of the document.
• Ioana: and also the legal authenticator too.
• Tom: We’re splitting a couple of things here. Let me deal with the consenter first. Then I’ll deal with the author
  • Is the person who signed the document the author, or is it the organization that created the policy really the author of it?
• Ioana: A consent directive is authored by either a client or SDM.
• Tom: I look at an authorization to release information. Technically the agency wrote the document, the client just signed it.
• Mike: It might help if we look at the model for what the CDA would be used for. The first model, the patient is using a CDA to pass a Consent Directive from a PHR to a provider. The form of that to be interoperable, might be the CDA, and it would be originated by the patient as the author. The second form of this might be where the legal policy that the organization agreed to might be passed from a Privacy Management Service that receives requests from patients and passes that in a formatted message to the Security Service for incorporation and enforcement there, and that might be a CDA generated by the organization that is asserting this is the policy that I want you to enforce. It seems you can have different originators in those cases. It’s not constrained to either.
• Ioana: The author can be the patient, SDM, or the organization. But the legal authenticator will always be the patient or the SDM.
• Tom: I’m looking up what CDA uses as a definition legal authenticator versus author.
• Ioana: Basically a difference between who created and who signed.
• Rob: The question that Mike is getting to. Are you using that part of the CDA to identify a relationship with regard to whose policy it is.
• Tom: The policy is the record target itself.
• Rob: It’s more the issue of if this consent is based on Holyoke Hospital policy, that’s who wrote the document, that’s who authored it. The client is consenting. Or a Substitute Decision Maker is consenting. Are you using that author idea as the place where you identify whose policy it is (Holyoke)? The idea of trying to capture who wrote the policy, but then separately identify whose policy we’re working from, then you’re creating something (author) that doesn’t have value.
• Ioana: We have author, legal authenticator, custodian, information recipient.
• Tom: You have one more: the participant, an associated entity.
• Mike: In our separate minds, we have different use cases and we might be talking cross-purposes. This is of interest to SOA (PASS Authorization). We have two use cases, and the interfaces we’re defining. I’ll take an action item to write a description for these two use cases. I think they’re distinct. One is where the CDA policy is used to express a client’s request; one is used to express an organization’s privacy policy which may be nothing more than the acceptance of a client’s privacy policy.
• Pat: This goes back to the distinction between an agreement and a Consent.
• Ioana: The information we’re considering is narrowly constrained by the Consent Directive information model. We have an additional to the Consent Directive Information Model, a privacy policy IF, which is how we would expect an organization’s privacy policy to be stated from a privacy standpoint as a privacy document. We have focused on the CD, which is that document that is issued by a specific client in accordance with a valid privacy policy. So it is related to a privacy policy and it references both an information recipient and a custodian. It has a target record, a target client and a legal authenticator consenter.
• Mike; We have a need to make sure that we create a CDA that handles both. It would be simplistic, but we recognize that a patient may submit a consent directive that would come from the information model in there to a Privacy Management service, which would have the role of adjudicating the request. And then we have the privacy system itself, maybe one provider talking to anther provider, asserting the privacy policies they have which includes specific privacy policies of patients they’ve agreed to that they expect a second organization to know about or enforce. These are the business models we need to support. I’m hoping we can accommodate both in this project.
• Ioana: We can certainly try to do both. It sounds to me that you think there are two kinds of documents. One, to specify the Consent Directive of a client, and the other, a response from the organization?
• Mike: It’s more to the original question, who is the author and who is the signer. I’m seeking flexibility there, it could be the patient, it could be the organization and it’s use case specific.
• Ioana: That is easy enough to accommodate. The author can be an individual or an organization. That would meet your (SSA) needs as well Tom, right?
• Rob: The point I was making is what is that author representing? I realize that we’re thinking about this as I’ve got a piece of paper, who wrote it? But in the context of how that gets used, is it a way of pointing to a policy that is in place, or one entity or another? Is that what this is being created to capture?
• Tom: Part of the Implementation Guide would be to provide guidance on how to use it. We need to figure out what are the possibilities and what makes the most sense, and are we bastardizing the CDA if we use the wrong mechanism.
• Ioana: We say in the analysis model that we want the Consent Directives to be associated with a published policy (zero or more). We recognize that a Consent Directive has a basis in a preexisting policy. But there also those consumer preferences that could existing without a policy. E.g, you request something from a provider, and the provider has to respond whether they can fulfill your request or not. It sounds as if the more flexible way to capture this is for the author to be an organization.
• Tom: If I were to use it this way, it would be an organization, but based on the CDA, it can be either.

Meeting was adjourned at 1:05 PM EST. No significant motions or decisions were made.