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

November 19th 2009 CDA R2 Implementation Guide Conference Call

From HL7Wiki
Jump to navigation Jump to search

Back to CBCC Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve Minutes
  2. (55 min) Recommendations from the Structured Documents WG, Review CDA R3 Proposals

Action Items

Ioana:

  1. Follow up with SDWG for their recommendation on the ability to include the functional and/or structural role of the information recipient in the document header and/or the structured body.
  2. Send a question to the Security WG to obtain input as to whether both Structural and Functional role codes need to be supported or whether we can live with just one (and which that one is).

Minutes

Ioana presented a recap of the discussion that took place during the Structured Documents WG meeting on 11/17, as well as presented background on the CDA R3 proposals that she prepared as the result of the guidance suggested by Structured Documents.

Digital signature for header participations - author, authenticator, legalAuthenticator

  • This first item related to how to capture the scanned document representation of a Consent Directive and its signatures.
    • SDWG suggested that for now, observationMedia can be used to capture any type of digitized signature.
    • We could create a section that is specific to signatures (LegalAuthenticator, Authenticator, other co-signers) for this Consent. We just have to make a decision on which signatures we want to capture.
  • Tom: I submit you could use observationMedia to capture the entire document.
  • Ioana: So that's the question. Are we only going after the signatures, or would we prefer to have the whole document scanned which would include the signatures?
  • Tom: For near term, we would want the ability to support scanning in the entire document. This gives us the greatest potential for backward compatibility. But then, as companies or enterprises are able to further break down the CDA document into individual signatures, those can be represented as well.
  • Ioana: To support the ability to allow for digital signatures in all participations, I've submitted this change proposal.
    • The trend for CDA R3 is to include as many of the attributes from the RIM as possible. If we have the flexibility, if the signature becomes part of any Participation, this will allow you to include signature at every level, wherever participation is present, in the header or in the entry.
  • John: The Security WG is also working on the digital signature aspect.
  • Tom: There are (at least) two CDA R3 signature proposals that have been posted.
    • One, for capturing the scanned image of a signature
    • The other, is for a digital signature (represented by a security certificate), so the terms are getting overloaded. (The proposal submitted by HL7 France refers specifically to certificates, but unfortunately that proposal was named Electronic Signatures instead of Digital Signatures.)
  • John: The capturing of a scanned signature image is independent of the digital signature. And you've agreed, why not support both. You're simply leveraging a normal part of documents, we shouldn't be doing anything special simply because this is a Consent Directive.
  • Tom: Yes, but this is a gap in the current CDA. Right now they just assume the "signature is on file". CDA R2 doesn't allow embedding a signature in a document (any form, scanned or digital).
  • John: The digital signature topic is a joint effort that Security WG and Structured Documents has picked up. I don't think we need to do anything special in this work on either (electronic or digital signatures). Our use case should support both types (scanned signatures; digital certificates-certificates).
  • Ioana: What Structured Documents advised is to enter a change proposal to indicate that we have need for a (digital) signature – the digital signature attribute that is already available in all Participations in the RIM.
  • Tom: How would you classify a signature that gets applied to a credit card pad and becomes digitized?
  • John: That's a wet signature.
  • Ioana: So for this Implementation Guide, we are going to use a scanned image of the entire consent directive. Do we need to take a vote on this?
  • Richard: How would you do it otherwise? If you were just capturing the scanned image of a signature, how would you tie it to the rest of the document?
  • Ioana: It would be a bit clunky. SDWG's recommendation is if you were to capture only the wet signatures, you would create a separate signature section. But, I don't think that would meet the needs of this group
  • John: Do not make a policy decision here. If someone wants to use a digitize wet signature without the text, that's their policy.
  • Ioana: But we have to make a design decision. So we’re should create a signature section in addition to allowing you to scan the entire document?
  • Tom: I think we need to support both.
    • Separate question: Is there a distinction between a Privacy policy and a Consent Directive? There are a couple of new LOINC codes (Privacy policy and Privacy policy acknowledgement) that have been defined for this area, and I'm trying to figure out which is the appropriate code to use as the document identifier.
  • Ioana: There is a distinction. Consent Directive is issued by a patient and it is based on a Privacy policy.
  • John: The problem with Consent Directives is if you look up the English definition, it can refer to a number of different things. So you have to apply a qualifier and say, this is a Consent applied to Privacy Policy.
  • Ioana: This is why Consent Directive references an explicit set of privacy policies. You could be consenting to many privacy policies.
  • John: There is a difference between the type of document and the organizations and individuals involved in the agreement. This gets to who are the responsible parties? You have to look in the Part 1 of the CDA document. An agreement between an individual and HCA does not apply to Kaiser Permanente. KP can use the HCA agreement as a basis to map to their policy and then say, do you now agree to these conditions? Now you've created a binding agreement with KP that is based on the preferences defined in the HCA agreement.
  • Ioana: Question to the group. It sounds like a Privacy policy acknowledgement is a specific Consent Directive that acknowledges one or more policies; while a Consent Directive in general could acknowledge zero more policies. I hope that you can provide the appropriate LOINC code. But either way, do we want to use the more generic consent, or do we want to use the more specific policy acknowledgement code?
  • John: I don't think there is actually a difference. In order to be more globally friendly, when I registered this code with LOINC, LOINC required that the words used be more expressive and globally friendly. The term that's referenced by LOINC is Privacy Policy Acknowledgement. The advantage of this terminology is that it allows this code to be used for other types of authorizations (e.g., HIPAA Authorization, CFR 42 Part 2), which are not legally considered to be Consents.

Role codes for information recipient and other participations

This was the outcome of the conversation with SDWG based on another outstanding question from the CDA R2 Implementation Guide mapping exercise.

Ioana: I was advised to submit a change proposal to allow for function code and the role code, (which is Code in the Role class) to be part of the future declaration of both header participation in roles and entry participation in roles.

  • There are two possibilities:
  1. Use the clinical document Participant functionCode to specify either the Functional or Structural role – we'd have to pick one and live with that
  2. Other choice is to create a RIM-based extension. This is already optional in the information model. We would have to be careful not to make this a mandatory RIM-based extension. This would allow for the expression of both Functional and Structural roles.
  • This is referring to the ability to specify the role of the Information Recipient (the recipient of the Consent and the clinical data governed by the Consent).
    • In CDA R2, we can only specify one role. If we feel strongly that we need support for both Functional and Structural role, the current alternative is to create a RIM-based extension to allow these attributes to appear in our structure.
  • Suzanne: I think for now, Functional Role will suffice. I think we can defer Structural role for now.
  • John: I thought where Mike is trying to go initially is to use Structural Role. The problem with Functional role is that it is so dynamic throughout the workflow, it is difficult to identify in any instance in time, what the Functional role is. Even while the doctor is looking at the data, they may be mentally changing their Functional role.
    • If we can support Structural Role, that should satisfy a vast majority of concerns. The possible exception to that is the concept of Care Team or "Legitimate Relationship" which is used in the UK. This represents the concept of whether an individual is a direct or indirect care provider, and is something seems to be emerging as the next step beyond Structural roles. I don't think there's any form of well defined value for that yet.
  • Ioana: What I hear is there an overwhelming voice for one value right now, whether it is Functional or Structural could be specified in the implementation perhaps. Or we can take a vote. The issue is, right now the CDA R2 does not support more than one role. If we want to support both roles, we need to create a RIM-based extension (to declare both functional and structural roles), and we should submit the CDA R3 proposal to add the additional role to information recipient, in which case this will be forward compatible.
    • I will send a question to the Structured Documents list asking them if they have a problem with us using the participant in the header to specify the information recipient (functional or structural) role. If the response is you have to use RIM-based extension, then there is no issue, we can support both.
    • There are actually two information recipients:
  1. Information Recipient in the entry– this Consent is going to this particular individual
  2. Information Recipient in the header – this recipient can be completely different . For example, the Information Recipient is my PHR, but the Consent is intended for a substance abuse clinic.
  • John: I was not expecting we would be encoding the Privacy policy in the header.
  • Ioana: We are encoding some of the information about the custodian in the header. The Information Recipient could be encoded as part of the entry that specifies the structure for the Consent. But the intention is, you would issue this Consent Directive with the custodian of the clinical information. It's only when you have a PHR that the consent recipient and data recipient would be different.
  • John: What I'm hearing is not who is the recipient of the data, but who is being authorized to use this data which is Policy. That is different than who is the target of this data.
  • Ioana: Target is reserved for the patient/client. Information Recipient is the organization to whom the data will be disclosed; the custodian is the organization that holds the clinical information. Information custodian is declared in the header and Information Recipient in part of the header and in the structured entry. To specify the role of the Information Recipient, the CDA has only one attribute. The information model (Privacy DAM) allows you to specify both (structural and functional). If SDWG discourages the use of extensions we'll have to settle for one role.
  • John: I had a different vision of this. I thought it was take the Consent and drop it as an object within a CDA document.
  • Ioana: Some of the content of the Consent Directive is aligned with the header information very well.
  • John: I agree that the identity information in the header makes sense. But when you get into policy declaration…
  • Ioana: That's not in the header; those things are part of the structured section entries.

Confidentiality code support in ClinicalStatement choices

Another item that the SDWG approved is a workaround for the fact that we don’t have a confidentialityCode as part of the structured entry.

  • They agreed it would be adequate to use precondition participation in the Act and Observation choices of the entry.
  • When they created the clinical statement structure, they took it out (it's in the RIM). Right now we don't have the choice to express the idea "I want to issue a policy that relates to an information artifact with this confidentiality."

Participation sequence number

We do not have the choice of specifying multiple Consents and some sort of precedence rule between them in the CDA R2 structure. Consent Directives will have to be standalone assertions. To resolve this issue, I created this proposal to allow for sequence and priority number.

Overall readiness of the CDA R2 Implementation Guide ballot

  • We have coverage for all of the elements that we need.
  • We may need to use some workarounds for the time being (until CDA R3).
    • Some things will be entries like the Policy information references – the action type, purpose code, obligation – that will be part of the structured body of the document
    • Other things will be part of the header.
    • The only sticking point we had was the representation of signatures and scanned documents (and we've determined that we can use ObservationMedia for now).

Meeting adjourned at 2:05 PM EST