Clinical Scenarios And C-CDA Constructs (i.e. things for which we want to create XML samples)

[Brian Weiss]

In this thread, we will propose and prioritize the clinical scenarios and C-CDA constructs  for which samples will be created.

Here are some of the clinical scenarios that were active on the HL7 SDWG listserv at the time this Google Group was created.  It's just an initial list to get us started and we may only choose to focus on a small subset of what is below.

1) Clinical Scenarios

1.1) Problems

1.a.i) No known problems

1a.ii) Active problem

1.2) Allergies

1.2.1) No allergy records on file

 

1.2.2) Allergy data may be available (from other systems) but could not be obtained

1.2.3) Patient is not allergic to any medication and this fact has been documented

1.2.4) Patient is allergic to these substances (provide specific list), and where appropriate link to observation event (e.g. Anaphylaxis)

1.2.5) Wide range of allergy types (medications, substances [especially non-consummable], negations, various symptoms, missing RxNorm code, etc.) 

 

1.3) Medications 

1.3.1) Patient is not taking any medications

1.3.2) Medication intervals (B.I.D., T.I.D., Q.I.D., Q.D 1, Q x hrs, etc.)

1.3.3 ) Lifetime does of a medication

1.3.4) Medication history (active/inactive prior medication) 

1.4) MRI results (and other results that are textual, not quantitative, in nature)

1.5) immunization that is not given (or "no immunizations given"

1.6) Smoking status history and use of effectiveTime

2) C-CDA Constructs

2.1) Organizing Structures

2.1.1) Concern act and observations in problems list

2.1.2) Results organizer and results

2.1.3) Allergy concerns and observations

2.2) "...such that it..."

2.3) Several examples of each section template that is guided to by MU2

2.4) Observation/code and Observation/value (including use of SEV and ASSERTION in this context)

2.5) Maiden name

2.6) Deceased patient

2.7) DRIV

2.8) Inversion indicator

2.9) Associating medications or procedures with specific encounters

2.10) Null address (validator issue?)

2.11) Null flavor and negation in various scenarios (e.g. "i have no information about the entry" vs. "i have no information about this particular event", nullFlavor of a negated item such as "I don't know if this happened or not")

2.12) Reason for refusal, reason not performed, etc.

2.13) Procedure vs. observation vs. act

 

 

 

[Brian Weiss]

From Kumara:

Lisa and Brian,

Thanks for your joining our effort to create more <section> examples.

I sent 2 <section> example documents, Problem List active and Problem List resolved in my earlier mails..

I want to make 1 more example "Problem List - aborted status." (act.status = aborted)

It is not uncommon to enter a problem in problem list window of EMR and later delete it because we entered wrong information based on wrong history from patient or family.

We probably have to use problem.status =active with negation indicator + ve to say this problem did not exist.

Another example we need is 

Problem entered as "difficulty breathing" (complaint)

After 2 weeks (more tests done) , this problem was changed to "congestive heart failure" (diagnosis/disease)

My assumption is to generate another section with same act.id and send another document to recipient, so recipient can update data correctly.

In this scenario we cannot call 'difficulty breathing " as resolved. We changed 1 problem type ( complaint) to another problem type (diagnosis) based on tests conducted.

The more examples we can generate, the better for all involved in interoperability.

Kumara

[Brian Weiss]

From Kumara:

Hello,

I will appreciate if any one can comment if there are any errors in this problem list CCDA example for benefit of people with limited experience in HL7/RIM/CDA/CCDA. THIS EXAMPLE REFERS TO AN ACTIVE PROBLEM.

I see 13 items (red color font) are the variables in Problem List section for active problem and every thing else is static text and does not change except the narrative text and reference values to the narrative text.. I will appreciate if some one can comment on this statement and explain what else can change other than these 13 items for an active problem..

I was looking at Bluebuttonplus web site  I have a feeling bluebuttonplus web site has a mistake in resolved problem.

They mention  act.statusocde = "active" for a resolved problem unless the physician is intending to monitor a resolved problem.

(http://bluebuttonplus.org/healthrecords.html#problemlist)

Appreciate if some one can comment on this also.

Kumara

PROBLEM LIST SECTION EXAPMPLE

<component>

<section>

<templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>

<code code="11450-4"  codeSystem="2.16.840.1.113883.6.1"

codeSystemName="LOINC"   displayName="PROBLEM LIST"/>

<title>PROBLEMS</title>

<text> 

free text HTML table representation of the problems, 

start date, end date, active, resolved etc...… 

</text>

<entry>    ( PROBLEM 1 ENTRY STARTS HERE) 

    <act classCode="ACT" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.22.4.3"/>

<id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>

<code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>

<statusCode code="completed"/>

<effectiveTime>  (see comments at the bottom A,B)

<low value="2006"/>

<high nullFlavor="NA"/>

</effectiveTime>

                <!-- PROBLEM OBSERVATION STARTS HERE  -- !>

<entryRelationship typeCode="SUBJ" inversionInd="false">

<observation classCode="OBS" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.22.4.4"/>

<id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>

<code code="64572001"  displayName="Condition" 

codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>  (see comment E)

<text>

<reference value="#PROBSUMMARY_1"/>

</text>

<statusCode code="completed"/>

<effectiveTime>   (see note below C, D)

<low value="2004"/>

<high nullFlavor="NA"/>

</effectiveTime>

<value    xsi:type="CD"  displayName="Asthma" 

code="195967001" codeSystemName="SNOMED" 

codeSystem="2.16.840.1.113883.6.96">

<originalText> <reference value="#PROBSTATUS_1"/></originalText>

</value>

<!-- PROBLEM STATUS OBSERVATION TEMPLATE -->

<entryRelationship typeCode="REFR">

<observation classCode="OBS" moodCode="EVN">

<templateId root="2.16.840.1.113883.10.20.22.4.6"/>

<code code="33999-4" codeSystem="2.16.840.1.113883.6.1" displayName="Status"/>

<statusCode code="completed"/>

<value xsi:type="CE" code="55561003" 

codeSystem="2.16.840.1.113883.6.96" displayName="Active">  (see comment H)

</value>

</observation>

</entryRelationship>

<!-- PROBLEM START AGE AGE OBSERVATION TEMPLATE OPTIONAL ENTRY-- !>

               <!-- Ex. Diabetes Mellitus started at age 45 years -- !>

<entryRelationship typeCode="SUBJ" inversionInd="true"> 

<observation classCode="OBS" moodCode="EVN"> 

<templateId root="2.16.840.1.113883.10.20.22.4.31"/> 

<!-- Age observation template --> 

<code code="445518008" 

codeSystem="2.16.840.1.113883.6.96" 

displayName="Age" 

codeSystemName="SNOMED CT"/> 

<statusCode code="completed"/> 

<value xsi:type="PQ" value="45" unit="a"/>  ( see comments F)

</observation>

</entryRelationship>

<!--Health status observation  OPTIONAL ENTRY-- !>

<entryRelationship typeCode="SUBJ" inversionInd="true"> 

<observation classCode="OBS" moodCode="EVN"> 

<templateId root="2.16.840.1.113883.10.20.22.4.5"/> 

<!-- Health status observation template --> 

<code code="11323-3" 

codeSystem="2.16.840.1.113883.6.1" 

codeSystemName="LOINC" 

displayName="Health status"/> 

<statusCode code="completed"/> 

<value xsi:type="CE" code="313386006" 

codeSystem="2.16.840.1.113883.6.96" 

codeSystemName="SNOMED CT" 

displayName="In Remission"/>  (see commnet G)

</observation> 

</entryRelationship>

</observation>

</act>

</entry>

</section>

</component>

A. act.effetciveTime @lowvalue = date when this problem was "entered in medical record" 

                                 as active problem and being tracked as a "concern"

B. act.effetciveTime @highvalue = date when this problem was entered in medical record 

                                 as resolved/not active problem and no longer tracked as a "concern"

C. observation.effectivetime @low value = problem start date

D.     observation.effectivetime @high value = problem resolved date

Items A and C  may not be the same dates.

Date in A cannot be less than date in C

If problem is still active, observation.effectivetime should be nullflavor = "NA"

We cannot use highvalue = nullflavor = unknown when the problem is still active and not resolved.

E.  SHALL contain exactly one [1..1] code, where the @code SHOULD be 

selected from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18 (CONF:9045).

404684003     Finding ( example "heart Murmur" or "Elevated Calcium", abnormal chest xray)

409586006     Complaint  (Cough or Neck pain or diarrhea)

282291009     Diagnosis  (Viral gastroenteritis, Lung Cancer , Hypertension)

64572001      Condition  ( not sure how it is differant from others)

248536006     Functional limitation (unable to type, Unable to walk, Unable to getup from chair)

418799008     Symptom  (not sure how this is differnat from complaint)

55607006      Problem (looks like catch all if doctor does nto specify any of the above) 

If the doctor does not select the type of problem he is entering into EMR, use as default 55607006???

I am not sure if any EMR makes this selection mandatory for doctors.

If too many things are made mandatory, doctors start hating EMR.

F.

Table 114: Age PQ_UCUM Value Set 

 

Value Set: AgePQ_UCUM 2.16.840.1.113883.11.20.9.21 DYNAMIC  

Code System(s): Unified Code for Units of Measure (UCUM) 2.16.840.1.113883.6.8  

Description: A valueSet of UCUM codes for representing age value units  

Code   

min Minute  

h Hour  

d Day  

wk Week  

mo Month  

a Year  

G.

 

Value Set: HealthStatus 2.16.840.1.113883.1.11.20.12 DYNAMIC  

Code System(s): SNOMED CT 2.16.840.1.113883.6.96  

Description: Represents the general health status of the patient.  

Code Code System Print Name  

81323004 SNOMED CT Alive and well  

313386006 SNOMED CT In remission  

162467007 SNOMED CT Symptom free  

161901003 

SNOMED CT Chronically ill  

271593001 SNOMED CT Severely ill  

21134002 SNOMED CT Disabled  

161045001 SNOMED CT Severely disabled  

H.

HITSP Problem Status - Value Set HITSP Problem Status - 2.16.840.1.113883.3.88.12.80.68

Code System SNOMEDCT - 2.16.840.1.113883.6.96

Code Code System Print Name

55561003 SNOMEDCT Active

73425007 SNOMEDCT Inactive

413322009 SNOMEDCT Resolved

[Brian Weiss]

From Kumara:

Lisa and Brian,

Here is the updated <section> for active problem asthma.

Let us get opinions of any errors.

I will start working on resolved problem <section> example.

Kumara

PROBLEM LIST SECTION EXAMPLE

 

<component>

<section>

          <templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>

          <code code="11450-4"  codeSystem="2.16.840.1.113883.6.1"

                   codeSystemName="LOINC"   displayName="PROBLEM LIST"/>

                   <title>PROBLEMS</title>

                   <text> free text HTML table representation of the problems, 

                          SUGGESTED COLUMNS ARE PROBLEM NAME/ENTERED DATE/ START DATE/

                                                                    END DATE/STATUS/PROBLEM TYPE/AGE OF ONSET

                   </text>

 

          <entry>    ( PROBLEM #1 ENTRY STARTS HERE) 

          <act classCode="ACT" moodCode="EVN">

                   <templateId root="2.16.840.1.113883.10.20.22.4.3"/>

                   <id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>

                   <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>

                   <statusCode code="active"/>  (ACTIVE|COMPLETED|ABORTED|SUSPENDED; see comments J )

                   <effectiveTime>  (see comments at the bottom A,B)

                             <low value="2006"/>

                             <high nullFlavor="NA"/>

                   </effectiveTime>

 

                <!-- PROBLEM OBSERVATION STARTS HERE  -- !>

                   <entryRelationship typeCode="SUBJ" inversionInd="false"> (do we need @inversionindicator??)

                        <observation classCode="OBS" moodCode="EVN">

                             <templateId root="2.16.840.1.113883.10.20.22.4.4"/>

                             <id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>

 <code nullFlavor="NA" />  (if problem type code unknown use this line, see comment E)

                             <code code="64572001"  displayName="Condition" (if problem tyep code known, use this line)

                                       codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>  (see comment E)

                             <text> <reference value="#PROBSUMMARY_1"/> </text>

                             <statusCode code="active"/>  (if problem resolved, >> completed)

                                                          (if problem active >> actvie)

                             <effectiveTime>   (see note below C, D)

                                      <low value="2004"/>

                                      <high nullFlavor="NA"/> (if problem resolved, high value required)

                             </effectiveTime>

                             <value    xsi:type="CD"  displayName="Asthma" 

        code="195967001" codeSystemName="SNOMED" 

                                     codeSystem="2.16.840.1.113883.6.96">

                                     <originalText>     <reference value="#PROBSTATUS_1"/></originalText>

                             </value>

 

                         <!-- PROBLEM STATUS OBSERVATION TEMPLATE - ACTIVE|INACTIVE|RESOLVED -->

                             <entryRelationship typeCode="REFR">

                                      <observation classCode="OBS" moodCode="EVN">

                                                <templateId root="2.16.840.1.113883.10.20.22.4.6"/>

                                                <code code="33999-4" codeSystem="2.16.840.1.113883.6.1" displayName="Status"/>

<text> <reference value="#PROBSUMMARY_STATUSCELL_1"/> </text>

                                                <statusCode code="completed"/>

====================================================================================

A. act.effetciveTime @lowvalue = date when this problem was "entered in medical record" 

                              as active problem and being tracked as a "concern"

B. act.effetciveTime @highvalue = date when this problem was entered in medical record 

                                 as resolved/not active problem and no longer tracked as a "concern"

The effectiveTime element records the starting and ending times during which the concern was active on the Problem List.

"was active on the problem list" = it becomes active when entered into EMR problem list window.??

=====================================================================================

C. observation.effectivetime @low value = problem start date

D.     observation.effectivetime @high value = problem resolved date

Items A and C  may not be the same dates.

Date in A cannot be less than date in C

 

If problem is still active, observation.effectivetime should be nullflavor = "NA"

We cannot use highvalue = nullflavor = unknown when the problem is still active and not resolved.

====================================================================================

E.  PROBLEM TYPE

SHALL contain exactly one [1..1] code, where the @code SHOULD be 

selected from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18 (CONF:9045).

404684003     Finding ( example "heart Murmur" or "Elevated Calcium", abnormal chest xray)

409586006     Complaint  (Cough or Neck pain or diarrhea)

282291009     Diagnosis  (Viral gastroenteritis, Lung Cancer , Hypertension)

64572001      Condition  ( not sure how it is differant from others)

248536006     Functional limitation (unable to type, Unable to walk, Unable to getup from chair)

418799008     Symptom  (not sure how this is differnat from complaint)

55607006      Problem (looks like catch all if doctor does nto specify any of the above) 

If the doctor does not select the type of problem he is entering into EMR, 

use as default 55607006 or use "Code = nullfavor unknown". ?? 

I am not sure if any EMR makes this selection mandatory for doctors.

If too many things are made mandatory, doctors start hating EMR.

====================================================================================

F.  Table 114: Age PQ_UCUM Value Set 

Value Set: AgePQ_UCUM 2.16.840.1.113883.11.20.9.21 DYNAMIC       

Code System(s):   Unified Code for Units of Measure (UCUM) 2.16.840.1.113883.6.8           

Description:         A valueSet of UCUM codes for representing age value units   

Code   

min             Minute          

h                  Hour   

d                  Day     

wk               Week            

mo               Month           

a                  Year  

===============================================

G. 

Value Set: HealthStatus 2.16.840.1.113883.1.11.20.12 DYNAMIC           

Code System(s):   SNOMED CT 2.16.840.1.113883.6.96        

Description:   Represents the general health status of the patient.         

Code Code System        Print Name             

81323004      SNOMED CT      Alive and well        

313386006     SNOMED CT      In remission           

162467007     SNOMED CT      Symptom free        

161901003     SNOMED CT      Chronically ill        

271593001     SNOMED CT      Severely ill   

21134002      SNOMED CT      Disabled       

161045001     SNOMED CT      Severely disabled  

=================================================

 

H.

HITSP Problem Status - Value Set   HITSP Problem Status - 2.16.840.1.113883.3.88.12.80.68

Code System        SNOMEDCT - 2.16.840.1.113883.6.96

Code Code System        Print Name

55561003   SNOMEDCT       Active

73425007   SNOMEDCT       Inactive

413322009 SNOMEDCT       Resolved

========================================================

J. act.statuscode

active: A concern (a.k.a. disease or allergy) that is still being tracked.

suspended: A concern (a.k.a. disease or allergy) that is active, but which may be set aside. For example, this value might be used to suspend concern

about a patient problem after some period of remission, but before assumption that the concern has been resolved.

aborted: A concern (a.k.a. disease or allergy) that is no longer actively being tracked, but for reasons other than because the problem was resolved.

This value might be used to mark a concern as being aborted after a patient leaves care against medical advice.

completed:  The problem, allergy or medical state has been resolved and the concern no longer needs to be tracked except for

historical purposes.

======================================================

98% of the time, EMR does not capture the health status observation for a given problem.

For practical purpsoe, health status observation can be safely ignored.

=========================================================

in 2.16.840.1.113883.10.20.22.4.4 tempalte

observation.code will not be captured in majority of EMR products.

so the most likely option for the coder will be

observation.code = <code nullFlavor="NA" />  

===========================================================

[Brian Weiss]

Lisa and Brian,

Please send any corrections to below <section> example for a problem which is resolved.

Please comment particularly on act.statuscode

If this example is considered 99.99% clean, any one can use by changing a few variables which we will define in later mails.

I want many examples

1. problem active

2. problem resolved

We need foot notes to explain what to do if certain xml element values not available or unknown.

Any one can plug in a few variables in below example and create resolved problem <entry> in no time.

Kumara

PROBLEM LIST SECTION EXAMPLE FOR RESOLVED PROBLEM

 

<component>

<section>

          <templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>

          <code code="11450-4"  codeSystem="2.16.840.1.113883.6.1"

                   codeSystemName="LOINC"   displayName="PROBLEM LIST"/>

                   <title>PROBLEMS</title>

                   <text> free text HTML table representation of the problems, 

                          SUGGESTED COLUMNS ARE PROBLEM NAME/ENTERED DATE/ 

STARTDATE/END DATE/STATUS/PROBLEMTYPE/AGEOFONSET

                   </text>

 

          <entry>    ( PROBLEM #1 ENTRY STARTS HERE) 

          <act classCode="ACT" moodCode="EVN">

                   <templateId root="2.16.840.1.113883.10.20.22.4.3"/>

                   <id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>

                   <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>

                   <statusCode code="completed"/>  (ACTIVE|COMPLETED|ABORTED|SUSPENDED; see comments J )

                   <effectiveTime>  (see comments at the bottom A,B)

                             <low value="20080805"/>

                             <high nullFlavor="20040822"/>

                   </effectiveTime>

 

                <!-- PROBLEM OBSERVATION STARTS HERE  -- !>

                   <entryRelationship typeCode="SUBJ" inversionInd="false"> (do we need @inversionindicator??)

                        <observation classCode="OBS" moodCode="EVN">

                             <templateId root="2.16.840.1.113883.10.20.22.4.4"/>

                             <id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>

                             <code code="64572001"  displayName="Condition" 

                                       codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>  (see comment E)

                             <text> <reference value="#some cell in html table"/> </text>

                             <statusCode code="completed"/>  (if problem resolved, >> completed)

                                                          (if problem active >> active)

                             <effectiveTime>   (see note below C, D)

                                      <low value="20040801"/>

                                      <high value="20040822"/> (if problem resolved, high value required)

                             </effectiveTime>

                             <value    xsi:type="CD"  displayName="Asthma" 

        code="195967001" codeSystemName="SNOMED" 

                                     codeSystem="2.16.840.1.113883.6.96">

                                     <originalText>     <reference value="#somecell in html table "/></originalText>

                             </value>

 

                         <!-- PROBLEM STATUS OBSERVATION TEMPLATE - ACTIVE|INACTIVE|RESOLVED -->

                             <entryRelationship typeCode="REFR">

       <observation classCode="OBS" moodCode="EVN">

                              <templateId root="2.16.840.1.113883.10.20.22.4.6"/>

<code xsi:type="CE"   code="33999-4" 

                                  codeSystem="2.16.840.1.113883.6.1"   codeSystemName="LOINC" 

                                    displayName="Status"/>

                             <text><reference   value="#some cell in html table"</text>

<statusCode code="completed"/>

<value xsi:type="CD" code="413322009"

                                    codeSystem="2.16.840.1.113883.6.96"  codeSystemName="SNOMED CT" 

                                  displayName="Resolved"/> (see comment H)

                              </observation>

                             </entryRelationship>

 

               <!-- PROBLEM START AGE AGE OBSERVATION TEMPLATE OPTIONAL ENTRY-- !>

               <!-- Ex. Diabetes Mellitus started at age 45 years -- !>

                             <entryRelationship typeCode="SUBJ" inversionInd="true"> 

                                      <observation classCode="OBS" moodCode="EVN"> 

                                                <templateId root="2.16.840.1.113883.10.20.22.4.31"/> 

                                                <code code="445518008" 

                                                codeSystem="2.16.840.1.113883.6.96" 

                                                displayName="Age" 

                                                codeSystemName="SNOMED CT"/> 

                                                <statusCode code="completed"/> 

                                                <value xsi:type="PQ" value="45" unit="a"/>  ( see comments F)

                                      </observation>                       

                             </entryRelationship>

 

 

                             <!--HEALTH STATUS OBSERVATION - OPTIONAL ENTRY-- !>

                             <entryRelationship typeCode="SUBJ" inversionInd="true"> 

                                      <observation classCode="OBS" moodCode="EVN"> 

                                                <templateId root="2.16.840.1.113883.10.20.22.4.5"/> 

                                                <!-- Health status observation template --> 

                                                <code code="11323-3" 

                                                codeSystem="2.16.840.1.113883.6.1" 

                                                codeSystemName="LOINC" 

                                                displayName="Health status"/> 

                                                <statusCode code="completed"/> 

                                                <value xsi:type="CE" code="162467007" 

                                                codeSystem="2.16.840.1.113883.6.96" 

                                                codeSystemName="SNOMED CT" 

                                                displayName="Symptom free"/>  (see commnet G)

                                      </observation> 

                             </entryRelationship>

 

          </observation>

                  

          </act>

          </entry>

</section>

</component>

====================================================================================

A. act.effetciveTime @lowvalue = date when this problem was "entered in medical record" 

                              as active problem and being tracked as a "concern"

B. act.effetciveTime @highvalue = date when this problem was entered in medical record 

                                 as resolved/not active problem and no longer tracked as a "concern"

The effectiveTime element records the starting and ending times during which the concern was active on the Problem List.

"was active on the problem list" = it becomes active when entered into EMR problem list window.??

=====================================================================================

C. observation.effectivetime @low value = problem start date

D.     observation.effectivetime @high value = problem resolved date

Items A and C  may not be the same dates.

Date in A cannot be less than date in C

 

If problem is still active, observation.effectivetime should be nullflavor = "NA"

We cannot use highvalue = nullflavor = unknown when the problem is still active and not resolved.

if low value or high value needed but unknown

you cna use

<effectiveTime> 

<low nullFlavor="UNK"/>   (use "NA" for not applicable)

<high nullFlavor="UNK"/>  (use "UNK" for not aplicable)

</effectiveTime> 

====================================================================================

E.  PROBLEM TYPE

SHALL contain exactly one [1..1] code, where the @code SHOULD be 

selected from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2008-12-18 (CONF:9045).

404684003     Finding ( example "heart Murmur" or "Elevated Calcium", abnormal chest xray)

409586006     Complaint  (Cough or Neck pain or diarrhea)

282291009     Diagnosis  (Viral gastroenteritis, Lung Cancer , Hypertension)

64572001      Condition  ( not sure how it is differant from others)

248536006     Functional limitation (unable to type, Unable to walk, Unable to getup from chair)

418799008     Symptom  (not sure how this is differnat from complaint)

55607006      Problem (looks like catch all if doctor does nto specify any of the above) 

If the doctor does not select the type of problem he is entering into EMR, 

use as default 55607006 or use "Code = nullfavor unknown". ?? 

I am not sure if any EMR makes this selection mandatory for doctors.

If too many things are made mandatory, doctors start hating EMR.

if code unknown ( problem type unknown)

use  <code nullFlavor="NA" />  or   <code nullFlavor="UNK" />  

====================================================================================

F.  PROBLEM START AGE AGE OBSERVATION 

ACTIVE: A concern (a.k.a. disease or allergy) that is still being tracked.

SUSPENDED: A concern (a.k.a. disease or allergy) that is active, but which may be set aside. For example, this value might be used to suspend concern about a patient problem after some period of remission, but before assumption that the concern has been resolved.

ABORTED: A concern (a.k.a. disease or allergy) that is no longer actively being tracked, but for reasons other than because the problem was resolved. This value might be used to mark a concern as being aborted after a patient leaves care against medical advice.

COMPLETED:  The problem, allergy or medical state has been resolved and the concern no longer needs to be tracked.

======================================================

98% of the time, EMR does not capture the health status observation for a given problem.

For practical purpose, health status observation can be safely ignored.

[Brian Weiss]

Kumara,

I think this is too broad a topic “Problem List Section Example”.  I appreciate your desire to create a “template” for Problem Lists with “variables” that can be changed – but I think we are going to get all over the map here. For samples to be effective, they have to be very focused/specific.  After we build out a certain set of specific examples we can look at broader / more generic approaches.

Right now, we have one good “samples topic” open – “No Known Problems”. I recommend that we complete that one and in parallel, discuss which ones we want to cover next.

Can you distill a series of SPECIFIC sub-topics from the broad “Problem List” topic and can we prioritize them?

For example:

1)      Basic example of active asthma condition (with enough detail to make the clinical scenario clear).
2)      Basic example of asthma condition that is in remission (with enough detail to make the clinical scenario clear).
3)      Example of a problem list with two conditions – asthma and diabetes [Note: should only be addressed after we do each one separately]

You get the idea…

The road to 100s of samples is one sample at a time and the more narrow and focused the scenario, the more effective it will be.  Just look at how many “sub-agendas” we spun off of “No Known Problems” that we still have to close out:

·         effectiveTime

·         DRIV/COMP

·         inversionInd

·         text reference in a negation

·         SNOMED vs. HL7ActClass for code in the Problem Concern Act

·         statuscode for Concern vs. Observation

·         act.moodcode and act.statuscode

Especially since both you and I are novices, we are going to have to work through some basic stuff (and will probably need help/guidance on much of it) first.  So, no point in raising tens of issues on one sample.  Let’s start with simple samples and work up from there…

Brian

[Brian Weiss]

So far the lead candidates for our next effort after we complete "No Known Problems" is as follows:

1) Suggestion from Ed to expand this out to various flavors of "No Known Problems" (such as "No Information Available About Problems") and also to expand it out to allergies, meds, etc.

2) Suggestion from Kumara to do two basic specific-problem samples ("Pneumonia - active" and "Pneumonia - resolved").

If anyone wants to take a first cut at those, that would be great.  If not, I'll get to them soon.

Meanwhile, here is what remains for us to close out our first sample of "No Known Problems":

• Finalize our approach to statusCode and effectiveTime for both the Problem Concern Act template and the Problem Observation template.  I think we are just about there, but need to hear back from Lisa.

• How do we want to handle the text element (which is a SHOULD) in the Problem Observation template?  Do we point to the text "No known problems" even though the observation has a neagationInd="false"which means that might be interpreted as a double-negative ("does not have no known problems")?

• How to set id in samples - I will propose something here ASAP.
  

The other questionable/uncertain items I will reflect as comments in explanatory text that accompanies the sample.  As soon as we resolve the items above, I will send out a draft of our proposed sample and the explanatory text for any final review/comment from this group - and then post it to the HL7 listserv to see if they want to take it from there... as that is as far as we can go here (we're not "authoritative").

Brian

[Lisa Nelson]

Remarks in-line

 

Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaR...@cox.net

 

From: ccda_s...@googlegroups.com [mailto:ccda_s...@googlegroups.com] On Behalf Of Brian Weiss
Sent: Thursday, June 06, 2013 7:15 AM
To: ccda_s...@googlegroups.com
Subject: {C-CDA Samples} Samples Team Agenda - Status Update

 

So far the lead candidates for our next effort after we complete "No Known Problems" is as follows:

 

1) Suggestion from Ed to expand this out to various flavors of "No Known Problems" (such as "No Information Available About Problems") and also to expand it out to allergies, meds, etc.

[LRN – I agree this is a good idea]

 

2) Suggestion from Kumara to do two basic specific-problem samples ("Pneumonia - active" and "Pneumonia - resolved"). [I think we should show a life cycle –

 

Concern is active, it includes two problem observations, both active.

Concern is still active, but now, one of the problem observations has been resolved.

Concern is completed, now, both of the problem observation have been resolved.

 

3. Not to get too crazy, but I would like to see if anyone else is brave enough to tip toe into the question of data provenance. There is a nuance of what information being documented  was authored by the patient or the patient’s device, or comes from the doctor and is informed by the patient, or is just a finding the doctor makes from his/her own observation.  Anyone want to fold that in here…or shall we save that for another day?  CDA offers the constructs to record this “context” about the information. This would be new territory to actually work out how we could make it work. I’ve been thinking about it a lot and am willing to keep digging if anyone else wants to dig with me.

 

If anyone wants to take a first cut at those, that would be great.  If not, I'll get to them soon.

I think it is very helpful in the process for many contributors to work out WHOLE examples.  We should each work out our whole idea for a problem section with the specified example….then review them each…with the author explaining what he developed and why. This will be the best way for us to learn. There could be more than one right answer and this will help us see what CDA makes possible.

 

 

Meanwhile, here is what remains for us to close out our first sample of "No Known Problems":

• Finalize our approach to statusCode and effectiveTime for both the Problem Concern Act template and the Problem Observation template.  I think we are just about there, but need to hear back from Lisa. Bryan, I think we have agreed about this, and which flavors of null make sense to mean various things.  I wish there was a clearer way to always reinforce that it is act.statusCode of the Problem Concern and the Status Observation of the Problem Observation for the Problem Observation.  Our sloppy speech perpetuates the confusion. ProblemObservation.statusCode will always be “Complete” it IS NOT where the concept of the status of the observation is encoded.  This is really hard for people to get because it is not symmetrical with the behavior for the Concern act.

• How do we want to handle the text element (which is a SHOULD) in the Problem Observation template?  Do we point to the text "No known problems" even though the observation has a neagationInd="false"which means that might be interpreted as a double-negative ("does not have no known problems")?

I have views and fundamental principles on this, but I don’t yet have the time to go through all this in this message.  I can explain all my theories, and will do so when it is my turn to review my sample with this group.  For now, let me say that in the no known problems example, the text element should reference the narrative section text where “no known problems” is written for the humans to read.  The originaltext of the code should be “Problem” and it should also reference this text, or more specifically the word “problems”.

--
You received this message because you are subscribed to the Google Groups "C-CDA Samples" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ccda_samples...@googlegroups.com.
To post to this group, send email to ccda_s...@googlegroups.com.
Visit this group at http://groups.google.com/group/ccda_samples?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Brian Weiss]

Lisa,

 

My only issue with your very good suggestion of two observations is that a while back there was a lot of debate about whether (practically) every observation should have its own concern or not.  So, I prefer we start with the life-cycle for a single-observation concern and then tackle the potential can of works regarding two observations in one concern.

 

Similarly, I think we should hold up on provenance as a separate (dedicated) topic.   Let’s “crawl” first with the basics and then build up from there.  If we get some momentum, eventually we can get braver and tackle tougher samples…

 

I like your idea about “many contributors working out whole examples” – but right now “many contributors” sounds like a code word for “Lisa and Brian”.  So, we might have to build up to that as well... 

 

What I’ll do as soon as my sample is ready is coordinate a convenient time for you and Kumara.  I’ll walk through my “proposed final” samples for “No Known Problem” and we’ll review together.  If you can bring a samples/samples to that as well, great!  We’ll make it a public session that anyone else can also join if they like.  How does that sound to start?

 

Re. Problem Status template (a sub-template of Problem Observation) vs. the statusCode within Problem Observation – that wasn’t me being sloppy, it was me being ignorant!  Do you agree, though, that in the current context of “No Known Problems” where the Problem Observation is “generic SNOMED code for ‘a problem’” there is no need for a Problem Status template?  As we know, this isn’t really an “observation” – it is more like a “placeholder” so we can say what we want to say about problems in general (negationInd or nullFlavor).  Is that right in your view?

 

I’m going to take your “bottom line” guidance on the text reference as best I understand it, and on the review call we can refine, as you suggest.

 

Brian

[Kumara Prathipati]

Lisa and Brian,

Once final  example is ready for various Problem scenarios, I will move forward to create and release the black box. Initially it will be one way black box but soon we will create bidirectional black box.

We will take input from physicians ("in practice for 25 years") who do data entry in patient medical records to see if they feel any thing is missing in simple xml that they require.

The physician is the ultimate consumer of data , so we need their input.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: 'Lisa Nelson' <LisaR...@cox.net>; ccda_s...@googlegroups.com
Sent: Thursday, June 6, 2013 9:04 AM

[Brian Weiss]

Kumara,

 

Your “black box” concept (a new flavor of greenCDA) is nice – and I am sure it will help guide our sample selection (which from your perspective is in support of your project, which is fine) - but not sure it will help us much with the hard part here, which is getting the C-CDA XML right.

 

Of course, whatever input we can get that is helpful is good…

 

But I think what Lisa and I need most are more people who want to help create C-CDA XML for the various clinical scenarios…  so a call-out here to anyone who was interested enough in C-CDA samples to join this Google Group and knows how to “speak C-CDA”.  Volunteers very welcome… J

 

Brian