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

June 1st CBCC Conference Call

From HL7Wiki
Jump to navigation Jump to search

Community-Based Collaborative Care Working Group Meeting

Back to CBCC Main Page

Attendees

Agenda

  1. (05 min) Roll Call, Approve minutes May 25th CBCC WG Meeting, Call for additional agenda items & Accept Agenda
  2. (55 min) CDA R2 Implementation Guide for Consent Directives ballot reconciliation - time allocated to address remaining comments
    • To download current version of the consolidated ballot spreadsheet, click File/Save Page As and add .xls extension
  • Ongoing Projects
  • Privacy Policy Reference Catalog

Minutes

1. Action Items

2. Resolutions

3. Updates/Discussion

CDA R2 Implementation Guide for Consent Directives – Ballot Reconciliation

Ballot reconciliation began with Keith Boone’s comments

Item #33: Use of PreConditions

  • Preconditions are used in some cases in this guide to specify confidentialityCode because confidentialityCode was constrained out of Entry in the CDA R2 specification.
  • Keith’s response: confidentialityCode is not constrained out of the spec, however it does not allow the use of multiple codes.
    • The problem with the given example is that heart attack is not a precondition. Heart attack is a problem. You can’t say “if Heart Attack” to mean anything. You have to say “If diagnosis = Heart Attack” to mean something.
    • If you’re going to use a code, the code has to have semantic meaning that can be understood as being a precondition. What has been done with Preconditions is to use a bunch of nouns as preconditions that are not testable. You haven’t given enough in the criteria to provide semantics as to what the precondition means. For instance, “If dilation” – dilation could be a procedure, it could be a status, a verb or a noun.
  • Ioana: The way we’re trying to use this is “if data is related to HIV, then don’t send it”. So we’re using precondition to specify HIV as a problem
  • Keith: Then what you need to do in your precondition is not just use a code for HIV, because HIV in and of itself is not a test. You have to use something that expresses the semantics of what the precondition is that needs to be met.
  • Ioana: How is this done? Is there any way to add semantics to precondition, or is precondition always lacking in semantics?
  • Keith: This is a good question. I don’t have an answer for this, but what you probably need is a post-coordinated SNOMED expression that would allow you to express diagnosis for the condition and the diagnosis which is the qualifier for that diagnosis...
  • Rob Horn: I thought SNOMED had some pre-coordinated diagnoses as conditions
  • Keith: SNOMED might have some pre-coordinated diagnoses as conditions. But my comments were based on the examples in the IG because people follow the examples. The guide needs something that expresses that the diagnosis is “X”, but this only expresses the condition of “X”.
  • Rob Horn: Here’s an example: Cancer Diagnosis based on primary site histological evidence
  • Keith: That’s a good pre-condition
  • Ioana: There are semantics – in the precondition, we have a criterion classCode of Observation
  • Rob: Cancer diagnosis is not an observation; it’s in the diagnosis tree. It’s a clinical finding as opposed to an observation in the SNOMED tree.
  • Keith: What Rob is saying is that Cancer diagnosis is not SNOMED-CT observable; it is however going to appear in an HL7 observation class.
  • Ioana: Back to the example in the document – the criterion is an observation and the code is corresponding to the history of substance abuse in this case.
  • Keith: History of substance abuse is a navigation concept; it is not a concept that means there is a history of substance abuse
  • Ioana: So the closest thing to semantics we have is the criterion classCode which is an observation. So that says it is an observation of a history of substance abuse.
  • Keith: You need to find someone who understands SNOMED and how SNOMED is appropriately used in preconditions to correct the problem.
    • The semantics of several examples here are equal to “if FOO”; there is no way to test this. This is supposed to have meaning without pre-coordinated rules for using this.
  • Ioana: So the way you would read this is if the pre-condition observation equals 37142002, then...
  • Keith: In terms of general modeling principles, 371422002, that doesn’t have that meaning in SNOMED. It doesn’t mean there is a history of substance abuse. That code is a navigational concept that says everything under here describes some history of substance abuse.
    • What you need to do is use post-coordinated SNOMED concept that says if this observable entity has this particular value. I’m not experienced enough with SNOMED to tell you how to do that, but I am familiar enough to tell you that history of substance abuse does not mean what you think here.
  • Rob: Very few of the SNOMED codes meet the criteria that we need.
  • Keith: You’re not going to be able to do this with pre-coordinate concepts, but you will be able to find a very general post-coordination pattern that says observable entity of – and has this value.
  • Rob: The problem you’ll find with history of substance abuse is that you can say, history of substance abuse = No, and I don’t think that is what you mean.
  • Ioana: We need to replace the pre-condition with something that gives us the semantics of the related diagnosis. Pre-condition doesn’t do this sufficiently according to Keith’s evaluation
  • Rob: Post-coordinate with a combination of a statement that you have confirmed presence of (observed) and then the condition
  • Ioana: We could use related acts, we don’t have to use pre-condition, but that is something we decided not to do a while back.
    • The resolution to this comment will be updated to Persuasive with Mod and will use related act and the act will be in DEF mood (Definition Mood).
  • Keith: Then the other issue that has been introduced by going this route is that you’re using a different model for saying essentially the same thing as is being said in the eMeasure work and was hashed out with M&M. You need an expert to help with this.
  • Ioana: HQMF has been published as a DSTU so presumably the source of truth is there. We will look to HQMF to see how it deals with related diagnoses for measures (and preconditions as well).
    • I will also mentioned that for confidentialityCode we used precondition because there was no way to express confidentialtyCode because it was removed from all the Acts in ClinicalStatement. So what do we do with the confidentialityCode? We’re trying to say that something that has a specific confidentialityCode is included in this definition.
  • Keith: You can put this in precondition.text
  • Ioana: So that seems to be the only way?
  • Keith: Look at the HQMF; I’m not sure it has the exact solution you need but we worked through many of these issues with M&M to make sure that we got it right.
  • Ioana: HQMF however does not use CDA R2, so they are not bound to the same rules.
  • Keith: You’re correct, but if you find out how they model it, we should be able to map it to what is in CDA R2.
  • Ioana: It’s relatively easy to map if you aren’t constrained to CDA R2. I’ll look into this and follow up with Keith.

Item #50: There is no distinction between a privacy preference and privacy policy in the document.

  • Ioana: The resolution to this comment is to remove reference to privacy policy and state that consent directives are used to exchange privacy preferences.
  • John: So are you saying that Consent Directives will only be used to exchange client privacy preferences and not used to communicate an agreed-to policy?
  • Ioana: It describes the privacy preferences of the client; you could use it to create a privacy policy; it references a de-facto privacy policy. Once the Consent Directives are accepted by an organization it is out of scope for this specification. This only says, here is how to encode consent Directives using CDA.
  • Pat: So the CDA is used to express a Consent Directive (an accepted policy based on the jurisdictional and/or organizational policy and the client privacy preferences), or the client privacy preferences (before they are accepted by the organization/jurisdiction.
  • Ioana: We will use the term Consent Directives consistently, so the wording will be change to say “representing consent directives in a standard form for exchange…”

Item #53: The comment here may not be related to Figure 1 as the spreadsheet indicates since there are no dependencies in this figure.

  • We did not resolve this issue and will have to go back on June 8th to resolve since disposition remains Pending Input from Submitter.

Item #54: The requirements upon which the CDA R2 Implementation Guide for Consent Directives is the Composite Privacy Domain Analysis model which is an approved DSTU 2.

  • The document will be updated to reflect that the DAM is already an approved DSTU.

Item #69: The Future Work section is relevant to the Normative track since we are planning to go Normative when CDA R3 is published.

At the top of the hour, a motion was made by Richard to take a vote on the comments addressed during today’s meeting as well as those discussed last week; seconded by Ioana.

  • Vote:
    • 11/0/0

Meeting was adjourned at 3:00 PM EDT

Back to CBCC Main Page

Retrieved from "https://wiki.hl7.org/w/index.php?title=June_1st_CBCC_Conference_Call&oldid=38915"