FHIR Chat · Interdepedency of conditions in C-CDA · C-CDA

Stream: C-CDA

Topic: Interdepedency of conditions in C-CDA

view this post on Zulip Dave Carlson (MIE) (Feb 24 2021 at 19:34):

I am going to give a possible example of something, and want to get feedback if people think this is a "valid" usage of communicating a condition via C-CDA:

Let's say someone has on their list of conditions "Chronic Pain in Both Knees".
There isn't any single "icd-10" code to say that, although you can "frankenstein" together something, and you could theoretically put this:

<entry>
    <act classCode="ACT" moodCode="EVN">
        <templateId root="2.16.840.1.113883.10.20.22.4.3" />
        <templateId root="2.16.840.1.113883.10.20.22.4.3" extension="2015-08-01"/>
        <id root="e5fbc288-659f-4aeb-a5e1-eb7cc8fcdfaf" />
        <code code="CONC" codeSystem="2.16.840.1.113883.5.6" />
        <statusCode code="completed" />
        <effectiveTime>
            <low value="20140403124536-0500" />
            <high value="20140407102516-0500" />
        </effectiveTime>
        <entryRelationship typeCode="SUBJ">
            <observation classCode="OBS" moodCode="EVN">
                <templateId root="2.16.840.1.113883.10.20.22.4.4"/>
                <templateId root="2.16.840.1.113883.10.20.22.4.4" extension="2015-08-01"/>
                <id extension="10241108" root="1.3.6.1.4.1.22812.4.111.0.4.1.2.1" />
                <code code="55607006" displayName="Problem"
                    codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">
                    <translation code="75326-9" codeSystem="2.16.840.1.113883.6.1"
                        codeSystemName="LOINC" displayName="Problem"/>
                </code>
                <text>Chronic Pain in Both Knees</text>
                <statusCode code="completed" />
                <effectiveTime>
                    <low value="20140402" />
                    <high value="20140405235959-0500"/>
                </effectiveTime>
                <value xsi:type="CD" code="M25.561" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10" displayName="Pain in Right Knee">
                    <originalText>Chronic Pain in Both Knees</originalText>
                    <!-- These are common translations of the SNOMED code, ICd-9 and ICd-10 are often used in billing-->
                    <translation xsi:type="CD" code="M25.562" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10" displayName="Pain in Left Knee" />
                    <translation xsi:type="CD" code="G89.29" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10" displayName="Other Chronic Pain" />
                </value>
            </observation>
        </entryRelationship>
    </act>
</entry>

My feeling was that the "multiple codes" on a single condition record was more for "different coding systems" (ie, ICD-9, ICD-10, snomed, etc), not necessarily for "frankensteining" ICD-10s into one concept, but, maybe that is "kosher"? Although considering the use of the word "translation", I don't feel like this is the way to go either, since the other ICD-10 codes aren't a "translation", they are "combining".

Thoughts?

Is there a way to do this within C-CDA at all, or would you just expect to see the 3 ICD-10's entered as separate Entry/Act's, and there isn't a way to "connect" them under an umbrella "term" within C-CDA? Would multiple entryRelationship/Observations under the same Entry/Act be kosher and accomplish this, although there isn't a very good usage of "text" at the Entry/Act level from what I've witnessed.

view this post on Zulip Lisa Nelson (Feb 24 2021 at 22:24):

@Dave Carlson (MIE)

You are correct, CDA does not intent the translations to be "joined" to make some sort of "post coordinated" term. You can't "combine" these concepts to create semantic meaning from the combination.
From a purist point of view, these are supposed to be equivalent translations of the same concept. In reality we tolerate variation that is more specific. And sometimes, I've seem more general, but that is pushing it. We run the risk that "this" may always be a "that", but "that" isn't always a "this".

CDA Examples task force has grappled with inventing a way to do post coordination of terms in the value element, but it hasn't gone anywhere. This would make a GREAT C-CDA IAT Topic for October. Please consider it. You know observation supports multiple value elements. Perhaps a template that support post coordination could be invented based on business requirements/use cases that you present...and a possible straw-man design to be considered.

Ben and Gay both have interest in this area as well.
@Benjamin Flessner @Gay Dolin

view this post on Zulip Dave Carlson (MIE) (Feb 24 2021 at 22:31):

Thanks Lisa... you said October, and below you say there are 3 IAT's this year (one coming up, and I assume a summer one). I'm assuming from you saying October that the summer one is already filled up for topics (along with next months)?

view this post on Zulip Dave Carlson (MIE) (Feb 25 2021 at 18:05):

@Lisa Nelson @Benjamin Flessner @Gay Dolin

I'm going to share an "deidentified" from the 3rd parties example they give on how to "share" their info in CCDA:

<value xsi:type="CD" code="30989003" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Knee pain">
<originalText>Chronic pain of both knees</originalText>
<!-- XYZ Proprietary Code -->
<translation code="01234567" displayName="Chronic pain of both knees" codeSystem="2.16.840.1.113883.3.1.2.3"
codeSystemName="XYZcode"/>
<!-- Additional SNOMED code mappings to capture specificity of the original term -->
<translation code="82423001" codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT" displayName="Chronic pain"/>
<!-- All Code Mappings of each ICD Code System in the order in which XYZ maps them -->
<translation code="M25.561" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM" displayName="Pain in right knee"/>
<translation code="M25.562" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM" displayName="Pain in left knee"/>
<translation code="G89.29" codeSystem="2.16.840.1.113883.6.90" codeSystemName="ICD-10-CM" displayName="Other chronic pain"/>
</value>

From your statement Lisa, this is "bad" advice/instruction on how to code this, correct?

I guess as a broader question, I am still in discussions with this 3rd party on where they came up with the above. If it is something they came up with "internally" (maybe based on a bad interpretation of CCDA) and they never worked with HL7 on making sure it was "kosher", is this something someone(s) at HL7 would approach them about? And depending on how they respond to HL7 (ie, they go "meh, we like what we did here"), would HL7 "proclaim" publicly that they are a "bad actor" in representing CCDA? Just wondering what HL7 does to "promote" correct usage in this way... I know they can't be "everywhere", but, just wondering what the protocols are in that fashion.

view this post on Zulip Natasha Kreisle (Mar 01 2021 at 18:49):

@Dave Carlson (MIE) There are three IATs and, you are correct, the next one will be July 21. There's still plenty of space and time to create this discussion topic for July! Here's a link to the form for topic suggestions too: https://confluence.hl7.org/display/IAT/Sign+Up+for+2021.07.21+C-CDA+IAT

view this post on Zulip Dave Carlson (MIE) (Mar 01 2021 at 19:11):

Thanks @Natasha Kreisle , I accidentially added it twice, if you want to remove the one w/o a link.

view this post on Zulip Natasha Kreisle (Mar 01 2021 at 19:33):

@Dave Carlson (MIE) Mission accomplished!

view this post on Zulip Lisa Nelson (Mar 14 2021 at 15:51):

@Dave Carlson (MIE) and @Benjamin Flessner and @Gay Dolin

I've been thinking about this more, and wondering if we should experiment with a variant Problem Observation Template where we constrain the Observation.code to Diagnosis, and then open Observation.value back up to allow for multiple value elements. The template design would explain that the value holds "all true" diagnosis codes. This pattern might make Problem Observation more fit for purpose for the use case of representing diagnoses.

In general, I feel we have outgrown the time when the Problem Observation template's binding of the code element to a kitchen sink of concepts is helping us. I would love to a project to clarify nuanced guidance for how and where to use this template for each of the codes listed in the ValueSet Problem Type (SNOMEDCT) 2.16.840.1.113883.3.88.12.3221.7.2

view this post on Zulip Dave Carlson (MIE) (Mar 15 2021 at 17:16):

Lisa Nelson said:

Dave Carlson (MIE) and Benjamin Flessner and Gay Dolin

Good thoughts Lisa. I agree that if the current constraints are too limiting for problems that we likely need to modify that to allow for more concept codes to be "grouped" for a broader problem concept that otherwise doesn't have a single code in a particular codeset (generally either aiming for fully "conceptualized" in either ICD-10 codes or SNOMED codes, depending on reasoning for usage).

I am open to whatever is the best path to go down to move on this, if some sort of sub-group with at least us 4 (Lisa, Ben, Gay and I) to discuss and come up with suggestions prior to possible discussion at the July IAT is appropriate or something else.

view this post on Zulip Dave Carlson (MIE) (May 07 2021 at 18:48):

Just to note on this thread, that this is the Jira HL7 ticket that got discussed at Structured Documents and worked towards in a call in April:

https://jira.hl7.org/browse/CDA-20023

Last updated: Apr 12 2022 at 19:14 UTC


An HL7 Website -