No Known Problems

[Brian Weiss]

Clinical Scenario: Patient has no known problems.

[Brian Weiss]

Kumara's initial proposal:

<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> No known problems </text>

<entry>

<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" 

displayName="Concern" 

codeSystem="2.16.840.1.113883.5.6"

codeSystemName="HL7ActClass"/> 

<statusCode code="completed"/>

<effectiveTime>

<low nullFlavor="NA"/>

<high nullFlavor="NA"/>

</effectiveTime>

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

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

<templateId root="2.16.840.1.113883.10.20.22.4.4"/>

<code code="ASSERTION" 

codeSystem="2.16.840.1.113883.5.4" 

codeSystemName="HL7ActCode" /> 

<statusCode code="completed" /> 

<value xsi:type="CD" 

code="55607006" 

codeSystem="2.16.840.1.113883.6.96" 

codeSystemName="SNOMED CT" 

displayName="Problem" /> 

</observation>

</act>

</entry>

</section>

</component>

[Brian Weiss]

Kumara,

Usual disclaimer here – I’m not an expert, this non-authoritative, probably significant mistakes here, etc.…

Also, as this is a pretty common scenario, I am sure this has been fully resolved already, and so I am probably just spinning my wheels here while we wait for the right answer…

The C-CDA IG gives an example on page 450 (figure 214) that is consistent with what you provided below.  I made a few changes to your snippet, in my snippet below, as follows:

1) Your snippet was missing a required id element in the Problem Observation template (as was the sample in the IG), so I put one in.

2) Your snippet was missing a text element in the Problem Observation template that is SHOULD, so I put one in.  I am referencing the text at the top (I added a content element for that).  There is an argument here that pointing to text that says “No known problems” is not correct because the whole template is under negationInd=”true” so that says “No, No known problems”.  Interested in what the experts think about this.  I think it makes sense to point to the text and consider the negation a negation of the structured data, not the text.  But I would accept the opposite guidance if that was what was decided by those who decide these things.

3) I left in your use of HL7ActClass to define the code in the Problem Concern Act template because this is what is shown in the IG sample.  However, running that through the NIST validator correctly spits out a warning that the wrong Code System is being used because CONF:9045 says that the code SHOULD be selected from ValueSet Problem Type which uses SNOMED (table 142 on page 326 of the IG).  So, were it not for the sample, I would use the SNOMED code for “Problem” here, rather than the HL7ActClass code for “Concern”.  Again, interested in the view from the experts.

4) statusCode=”completed” is required in the Problem Observation template.  However, in the Problem Concern Act template above it, I would have put statusCode=”active”. The “no problems” concern (or non-concern) is “active”.

5) The effectiveTime is required in the Problem Concern Act (where you put it in with a low and high of N/A).  It is a SHOULD in the Problem Observation Template.  I moved your N/A approach into the Problem Observation Template because I agree it is “N/A” when you observe “no problem”.  But in my book, the concern (or non-concern) of “No Known Problems” is active (as noted in the previous item) and thus has a starting date and no ending date.  So I would put in the date of whenever the status of “no known problems” was first noted as the low.  For effectiveTime ranges that have no end date, the IG samples usually just put in the low with no high.  However, since high is a SHOULD, I put it in with N/A.  Here too, the experts can correct me…

6) I took out your inversionInd=”false” in the entryRelationship element.  

7) I added some comments

I ran my snippet below through the NIST validator (http://transport-testing.nist.gov/ttt/) and the only issue was the warning that I mentioned in item 3) above.  So, syntactically, we are OK here and we can go get certified.  But I of course would also like to know if we are also correct…  

Brian

<!--

********************************************************

PROBLEM LIST - NO KNOWN PROBLEMS

********************************************************

-->

<component>

<section>

<!-- Problem Section with Coded Entries Required -->

<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> <content ID="noproblems1">No known problems </content></text>

<!-- Problem Concern Act -->

<entry>

<!-- Problem Concern Act template -->

<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" 

displayName="Concern" 

codeSystem="2.16.840.1.113883.5.6"

codeSystemName="HL7ActClass"/> 

<statusCode code="completed"/>

<effectiveTime>

<low value=”20000902"/>

<high nullFlavor="NA"/>

</effectiveTime>

<entryRelationship typeCode="SUBJ">

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

<!-- Problem Observation template -->

<templateId root="2.16.840.1.113883.10.20.22.4.4"/>

<id root="84a64e5c-eeff-4447-95b5-a0b754967ab7"/>

<code code="55607006" displayName="Problem"

codeSystem="2.16.840.1.113883.6.96" 

codeSystemName="SNOMED CT" /> 

<text>

<reference value="#noproblems1"/>

</text>

<statusCode code="completed" /> 

<effectiveTime>

<low nullFlavor="NA"/>

<high nullFlavor="NA"/>

</effectiveTime>

<value xsi:type="CD" 

code="55607006" 

codeSystem="2.16.840.1.113883.6.96" 

codeSystemName="SNOMED CT" 

displayName="Problem" /> 

</observation>

</entryRelationship>

</act>

</entry>

</section>

</component>

[Brian Weiss]

Comment from Thomas Davidson:

To tie back into your other email, does the <entry> element need a typeCode=”DRIV”?

[Brian Weiss]

Good point.  I would think so.  In this case, I think DRIV is relevant as we do indeed capture the “No known problems” narrative fully in the structured content.

Setting aside (as per the other thread) whether a receiver will trust our claim on that or not, and even though the validators don’t care either way, I would think it is good form to assert it when it’s true (as it is here).

Kumara – let’s add it to the sample.

Brian

[Brian Weiss]

From Kumara:

Brian,

Thanks for pointing out the observation.id element.

I agree adding the observation.text element is good too.

I will do fine tuning based on your suggestions.

I will send new <section> for "No known problems"  with necessary comments.

About your item 4  act.statuscode

I am confused. From my understanding every thing in health care is  one or acombination of "actions" represented by a generic "act class" or a well defined  act class like "observation act" or "procedure act" "substance administration act"etc..

Every act class can have a state = active or completed or suspended or aborted etc...

In this scenario, I was assuming, there is no concern to monitor since patient has no active problems.

But I realize, the IG wants "active". I will go with it.

act.moodcode vs act.statuscode is area of confusion.

It seems above my head and would use whatever the powers in authority tell me here.

Hopefully, our samples can be used by any one as plug the variables and also learn by examples.

I just added a comment for any one to understand id element conceptually.

Once again, I want to think of people who have limited experience in HL7/RIM/CDA/CCDA/SNOMED etc.. for all these examples.

Hopefully we can complete about 100 <section> examples in next 1 year.

Kumara

[Brian Weiss]

From Lisa:

BTW – re the act.effectiveTime element of the example below.  When act.statusCode is “active” then it makes sense for the effectiveTime/low to hold a date and effectiveTime/high to be null.  When act.statusCode is “completed” then you have either an effectiveTime/low and an effectiveTime/high value with a date, or perhaps just an effectiveTime/high with a date and effectiveTime/low could be null (maybe to say you don’t know when the concern was first identified, but it is no longer a concern).

[Brian Weiss]

Lisa and Kumara - I'm going to use the Google Group now for this stuff - until the two of you join, I will CC you explicitly...

effectiveTime high and low

The C-CDA IG seems to be all over the map on this.

• In section 5.59 Problem Observation, the conformance statement indicates that effectiveTime  SHOULD have both low and high (see CONF:15604 on page 448).  But in the example in figure 212 on page 449  effectiveTime has only a low element with no high.

• In section 5.2 Advance Directive, the conformance statements (page 293, CONF 8656-8661) require high (SHALL) and guide to the use of nullFlavor (NA or UNK as appropriate) - and the example matches on page 295, figure 154.
  

• In 5.4 Allergy - Intolerance Observation, the conformance statement (page 301, CONF:10082) has high as an optional MAY and the example leaves it out.
  

• In 5.5 Allergy Problem Act, the conformance statement requires high (SHALL) if the statusCode=completed (page 307, CONF:10085).  
  

• In 5.27 Functional Status Problem Observation, the wording of the conformance statement (page 362, CONF:14289) is "SHALL be recorded in the high element of the effectiveTime element when known"

This is just a handful of examples out of many, many more.  Maybe there is some special reasoning to each one, but the end result is a mess.  For example, the sample provided by ONC in the S&I Companion Guide for C-CDA CCD sample - when I ran it "as is" through the NIST validator, I got warning messages for "missing high" in:

• the Reaction Observation template in the Allergies section
  
• the Problem Concern Act template in the Problem List (for all 11 problems in the sample)
• the Problem Observation template (for all 11 problems in the sample)

So - setting aside the "logic" of when there should be a high and when there shouldn't, in the cases where there is no high - it's not clear if we leave it out (as the samples seem to do) or put it in (as the conformance rules and associated validators seem to suggest).  

We need to call this one way or the other on our sample. I think we should follow the conformance rules and it it says SHOULD (as it does for both Problem Concern Act template and Problem Observation template) then I think we should put it in with a suitable nullFlavor.  Agreed?

Brian

[Brian Weiss]

I want to summarize where I think we are with this sample.  I have attached the latest proposed sample we have (I think it is more effective to maintain samples as separate .xml files than to paste them into the body of e-mail messages).

Here are the open issues that have surfaced as we work this to closure (and my current thinking on each):

1) effectiveTime

1.1) We have to get alignment on what to put in for effectiveTime (low and high) for both the Problem Concern Act template and the nested Problem Observation template).  My proposal for the Problem Concern Act template is a low indicating the earliest known data of "No Problems Known" and NA for high.  For the Problem Observation template I propose NA for both low and high.

1.2) Where there is no high, we need to determine if we will use nullFlavor or leave out the entry (it is a SHOULD in the conformance statements for both templates).  My proposal is to include it with the nullFlavor as per the conformance rule recommendation of SHOULD

2) DRIV vs. COMP
2.1) We need to decide if the entry for the Problem Concern Act template for this "No known problems" sample should have typecode=DRIV or not.  I think it should.

3) inversionInd
3.1) Do we need inversionInd="false" in the entryRelationship that contains the Problem Observation template.  I don't think so.

4) text reference in a negation
4.1) 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 think we should.

5) SNOMED vs. HL7ActClass for code in the Problem Observation template
5.1) The IG example for No Known Problems on page 450, figure 214, uses the Code System HL7ActCode for the code element in the Problem Observation template.  However, the conformance statement (CONF:9045 on page 448) says that the code SHOULD come from ValueSet Problem Type 2.16.840.1.113883.3.88.12.3221.7.2 STATIC 2012-06-01 (which is SNOMED).  I have reverted to HL7ActCode as per the IG sample, but if that is correct, I think it has to be reported as an errata on the IG.

6) statusCode for Concern vs. Observation
6.1) There is a statusCode in both the Problem Concern Act template and the Problem Observation template.  My current proposal is that in the Problem Concern Act template it should be active and in the Problem Observation template it should be completed.

7) how to set id in samples
There is an id element required in both the Problem Concern Act template and the Problem Observation template.  What should be our approach for generating fictitious id elements in our samples?  For now I just put in "1234567890-1" and "1234567890-2".

I would appreciate any and all input on my proposals above and which ones need further discussion.  Also, any input on whether there are other open issues in this sample?

Brian

[Brian Weiss]

Kumara,

 

Note: I didn’t see your message below get posted into Google Groups – still working out the configuration settings there, we’ll get it right soon…

 

In terms of what you wrote below, we went around the block on this on the listserv a few months back (in January).  I think the discussion there suggested that the concern act is not necessarily when the doctor started monitoring.  It is the data that the doctor now feels the concern started.  So, in your example, the concern act would probably be the earliest date of the observation (June 2006).  But either way, you are right that if someone had three bleeding ulcer episodes over a 5 year period there would be three observations each with their own time range and they could all be in one concern that might still be open-ended about an overall concern related to the recurring ulcers.  It’s a good (but separate) discussion how that matches up with what EMRs capture (and there may be different answers there for different EMRs) as well as some of the nuance on the relationship of the effectiveTime ranges between the concern and its nested observations.

 

But right now, I’d like to stay focused (only) on the question of how to set the effectiveTime and statusCode for “No Problems Known”.

 

What I have proposed based on my understanding from Lisa and others is the following for “No Problems Known”:

 

1)      The Problem Observation template will be set to NA for nullFlavor for both low and high and a statusCode of “completed”

 

2)      The Problem Concern Act template has in low the earliest date when there were “No Problems Known” (the last date there was a Known Problem or a UNK for nullFlavor if you don’t know when the “No Problems Known” status started) and NA for high.  Its statusCode is “active”.

 

Are you good with that or do you want to suggest something else?

 

Brian

 

 

From: Kumara Prathipati [mailto:kuma...@yahoo.com]
Sent: Tuesday, June 04, 2013 17:36
To: Brian Weiss; ccda_s...@googlegroups.com
Cc: 'Lisa Nelson'
Subject: PROBLEM LIST SECTION EFFECTIVE TIME

 

Brian,

With ref to C-CDA IG 5.59 section

 

Problem Observation effective time (2.16.840.1.113883.10.20.22.4.4)

low value = problem start date ( I noticed bleeding stomach ulcer in June 2006)

high value = problem resolved date ( I stopped taking medicines for bleeding ulcer Sept 2006 because ulcer healed.)

 

 

Problem act effective time (patient did not see physician in June 2006. He saw physician in July 2006)

low value = when did the doctor start monitoring the concern - July 2006 (Bleeding ulcer entered into EMR )

how value = when did the doctor stop monitoring this concern ( status changed to resolved or suspended or aborted)

monitoring = monitoring disease progression

                       providing treatment

                       referring to appropriate consultants

                       running blood tests on the problem

                       etc..etc..

 

 

But if we look into many EMR products

none of them capture act.effectivetime

 

They only capture observation.effectivetime

 

 

For problem list ( and also for allergies)

we have 2 important effective times

1. for Problem Act (2.16.840.1.113883.10.20.22.4.3)

1. for Problem Observation (2.16.840.1.113883.10.20.22.4.4)

 

This is my understanding of effective time for Problem act and observation.

 

I am hoping some experts in CCDA will join this group to help us clarify the issues we come across.

 

Kumara

 

---

[Kumara Prathipati]

Agree with Brian and rewriting same concept below

"If no problem exists" for the patient

A. Problem Act Concern effective time low value = effective time when "no problem exists" was identified by doctor

B. Problem Act Concern effective time high value = NA

C. Problem Observation effective time low value = NA

D. Problem Observation effective time high value = NA

If no problem exists,

then 99% of EMR products capture only 1 date

It is amazing, some thing which looks so simple (effective time) is causing more concept level headaches for us.

No wonder , no one wants to write examples with this detail.

Let us get Lisa opinion....

kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: 'Kumara Prathipati' <kuma...@yahoo.com>; ccda_s...@googlegroups.com
Cc: 'Lisa Nelson' <LisaR...@cox.net>
Sent: Tuesday, June 4, 2013 7:59 AM
Subject: RE: PROBLEM LIST SECTION EFFECTIVE TIME

[Lisa Nelson]

Kumara, I agree with you and Brian, but prefer Brian’s analysis which includes consideration of the act.statusCode. The correct answer is conditional, based on the value of the act.statusCode.

 

Table 124: ProblemAct statusCode Value Set Value Set: ProblemAct statusCode 2.16.840.1.113883.11.20.9.19 STATIC 2011-09-09
Code System(s):		ActStatus 2.16.840.1.113883.5.14
Description:		This value set indicates the status of the problem concern act
Code	Code System		Print Name
active	ActStatus		active
suspended	ActStatus		suspended
aborted	ActStatus		aborted
completed	ActStatus		completed

 

 

A.      When the concern is still active (act.statusCode=”active”) then one would expect there to be an act.effectiveTime/low value (date when concern began being tracked) and act.effectiveTime/high would be nullflavor=”UNK”.

 

B.      When the concern is suspended (act.statusCode=”suspended”) then one would expect there to be an act.effectiveTime/low value (date when concern began being tracked) and act.effectiveTime/high would be the date the concern was moved into the status of suspended.

 

C.      When the concern is aborted (act.statusCode=”aborted”) then one would expect there to be an act.effectiveTime/low value (date when concern began being tracked) and act.effectiveTime/high would be the date the concern was moved into the status of aborted.

 

D.      When the concern is completed (act.statusCode=”completed”) then one would expect the act.effectiveTime/low value to be nullflavor=”NA” (because there was no date when a concern began being tracked) and act.effectiveTime/high would be the date the concern was moved into the status of completed.

In the case where the only thing the author wants to document in the problem section is “no known problems”, then it doesn’t seem like the author would want to show an on-going active concern. The author was concerned to learn if the patient had any problems, none were reported or observed, and so the concern, it seems to me, should be documented as completed. The pattern for effectiveTime would follow case D above.  There would be a single Problem Observation with negationInd=”true”. and as Brian noted below, The Problem Observation template will have a statusCode of “completed”.  I think the better option for the effectiveTime on that observation would be to populate the low and high with the date that the observation was made that there were no problems.    The doctor was not concerned at this point in time, because at this point in time, no problems were reported or observed.  I don’t think the effectiveTime should be a null flavor.

 

Sorry to stir the pot again, but I really appreciate the focus we are bringing on this issue. Thanks for making a more comfortable discussion space for these kind of nitty gritty details to be discussed at length.

 

Lisa

 

 

 

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

[Kumara Prathipati]

Lisa and Brian,

I think we should make our system flexible.

If "no problems exist" = true, then

act.statuscode = completed  Then effective time high value exists)

OR

act.statuscode = active (then effective time low value exists

When no problem exists, there is no concern to monitor...

"no problem" is technically not a concern for the doctor...

May be we should make flexible system

add comments for certain xml elements

and comments will show as alternative opinions

We can not avoid 2 opinions on some xml attributes some times

only 85% of CCDA is without controversy.

Instead of getting bogged down, it is better to add alternative opinion comments  at the bottom

and users can decide what they want ...

Kumarta

---

From: Lisa Nelson <LisaR...@cox.net>
To: 'Kumara Prathipati' <kuma...@yahoo.com>; 'Brian Weiss' <brian...@cdapro.com>; ccda_s...@googlegroups.com
Sent: Tuesday, June 4, 2013 2:54 PM
Subject: {C-CDA Samples} RE: PROBLEM LIST SECTION EFFECTIVE TIME

--
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.
 
 

[Kumara Prathipati]

Brian,

if we say 

problem concern = "no problem identified"

act.statuscode= "active"

This means "doctor is monitoring the concern"

act.statuscode= "completed"

This means "doctor is not monitoring the concern"

monitoring = giving treatment, ordering tests/xrays, referring to consultants, examining patient every month  etc..

in our <section> example

let us put most appropriate in the example

and add 2nd most likely appropriate  under comments.

If we do not have a mechanism to handle ambiguous items, we will get bogged down and spend too much time on 1 xml element or attribute.

We can always go to expert gurus to get the ultimate answer.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: 'Kumara Prathipati' <kuma...@yahoo.com>; ccda_s...@googlegroups.com
Cc: 'Lisa Nelson' <LisaR...@cox.net>

Sent: Tuesday, June 4, 2013 7:59 AM

Subject: RE: PROBLEM LIST SECTION EFFECTIVE TIME

[Brian Weiss]

Lisa,

Great stuff as usual.

I definitely feel we need a space like this out of the limelight where we can hash things out (and, in my case, make novice-level stupid mistakes) on our road to getting it right.  Also saves the overhead of explaining why samples are so important (and so hard).  And I want this to be a place where nobody feels they need to defend the standard (and nobody wastes time attacking it).  The standard is a "given" here - we don't create it, we don't influence it, etc. in this context.  We just try to sort it out, practically...  My model is HTML or XML.  Let's think about C-CDA in those terms.  This is a forum of users, not standards makers.

While I definitely want "a space like this", I don't think Google Groups is at all the right tool (especially when we get past the one-off discussions and want to start documenting the outcomes - the samples and associated explanations and insights we create).  So, I'm continuing to work on my CDA PRO web site concept that I believe will ultimately be the right tool for all of this sample-centric approach to learning and working with C-CDA that I really believe in deeply.  I know there is also sitplatform.org, Josh's SMART Github of samples, and other initiatives.  I believe it will all sort itself out in time...

Now, back to the topic at hand...

In terms of your A-D sumary below of statusCode and effectiveTime on concerns, I have two issues:

1) I think for a concern where statusCode="active", high should be nullFlavor="NA" not nullFlavor="UNK" (UNK means "A proper value is applicable, but is not known." whereas NA means "Known to have no proper value")

2) I don't understand why in the case of a concern where statusCode="completed" you have low set as nullFlavor="NA". I would think it should be like in A-C ("when concern began being tracked").  Perhaps that is not going to be known for a concern where statusCode="completed" - in that case I would say that low should be nullFlavor="UNK" (not "NA"). And if it is known, the fact that the concern is now completed doesn't change that date.

If we agree on my two points above, then I think we can reduce all four cases down to the following generalization:

• low is the date when the concern started to be tracked.  If that date is not known (as may often be the case for concerns where statusCode="completed") then low is nullFlavor="UNK" or whatever the suitable nullFlavor is in that specific case ("ASKU", "NASK", etc.).

• high is when the concern moved into its current statusCode for "suspended", "aborted", and "completed" concerns.  For concerns where statusCode="active", high is set to nullFlavor="UNK".
  

For the special case of this topic's clinical scenarior ("No Known Problems") I think we all agree that both low and high have to be nullFlavor="NA".

Which brings us to the question of what the statusCode should be for "No Known Problems"...  I'll reply in a separate post on that...

Brian

[Kumara Prathipati]

Lisa,

Here is my problem with "no problem identified"

4 year old child came to doctor  6/3/2013

Doctor after examination identified the child is health.

Doctor enters into EMR "no known problems"

observation.effectivetime low value = 6/3/2013

observation.effectivetime high value = unknown

we do not know how long the patient will be problem free (so high value unknown)

We can not define high value and have to say it is nullflavor=unknown..

98% of EMR products capture only date the fact was entered

Kumar

---

From: Lisa Nelson <LisaR...@cox.net>
To: 'Kumara Prathipati' <kuma...@yahoo.com>; 'Brian Weiss' <brian...@cdapro.com>; ccda_s...@googlegroups.com
Sent: Tuesday, June 4, 2013 2:54 PM

Subject: {C-CDA Samples} RE: PROBLEM LIST SECTION EFFECTIVE TIME

[Brian Weiss]

Kumara,

At the conceptual level I agree with you.  It's fine to have alternate approaches that we propose in our samples (primary/secondary, or just two side-by-side alternatives).  Later, relevant experts can refine that for us, and in some cases there will always be more than one acceptable way to do something.  So, when we get to the point where we want to "agree to disagree" then I am fine with that approach.  

At the same time, though, I want us to allocate a reasonable about of time to sort things out.  I understand that we want to try to quickly build up many samples, but I think quality matters as well as quantity.  The only thing worse than no samples, is wrong samples...

So, in this specific case, I think we still would do well to kick it around a bit more...

I think that once we agree the statusCode, we will be able to converge on the effectiveTime that goes along with it.

I think it's very important to keep in mind that we have TWO statusCode entries to deal with.  One for the concern (Problem Concern Act template) and one for the observation (Problem Observation template).

The other thing to keep in mind is that we are dealing with an observation where negationInd="true".  This makes things very confusing.  How do you monitor a concern that "isn't there"?  When did you "start monitoring" your non-concern?  It gets pretty absurd pretty quickly.  As you wrote, Kumara:

no problem" is technically not a concern for the doctor

But at the same time, the mechanism in C-CDA to say "No Known Problems" requires the use of a concern.  So, I think we have to accept that there is a "concern which is a non-concern" of "No Known Problems".     When you think about it that way, the concern is ACTIVE because it has not ended and is open-ended (from now and until something changes, the level of concern is the same).  To say that the "No Known Problems" concern completed means that tomorrow (or whatever time interval) I have to create a new concern for it if it "re-surfaces".  So, it is a bit convoluted, but I definitely think the concern has to be active.  It "completes" when the patient develops a problems and "No Known Problems" is no longer a "concern" (non-concern).  As a practical matter, you would just drop it entirely from the C-CDA document at some point - you would not leave it in as "completed" because it adds no value to "document history" for "No Known Problems".  But, conceptually, as a "concern" (in the unique sense that "No Known Problems" can be called a concern) it is "active" for as long as it is true.  That's my feeling.  The IG is silent here because it only provides a sample (Figure 214 on page 50) for the Problem Observation template, not for the Problem Concern Act template.

Now the observation is a different story.  There is not much meaning to "when I observed there was No Known Problem".  And there is no reason for the observation to be "ongoing".  To me that means that the observation is a one time event  (statusCode="completed") for which efffectiveTime has no meaning.  This is exactly what the IG shows in its sample.  However, the IG sample violates (at a "warning" level) conformance statement CONF:9050 that says that effectiveTime SHOULD be included.  So here we either have to follow the IG and leave effectiveTime out, or we have to put it in with NA for both high and low.  As an implementer, I like things to run "clean" through validators.  So, I prefer to put it in (with NA for both high and low) and avoid the warning message.  I'm OK with it being left out, but in that case I think we need to suggest an errata item for the IG that makes it clear that the SHOULD for effectiveTime doesn't apply when an observation has negationInd="true"...

Brian

[Kumara Prathipati]

Brian,

Agree with you.

We should kick the issue around and make good effort to come up with correct answers.

If we put alternative opinion in comments at the bottom, future users will understand that we did think about it (alternative answer), discussed about it and decided not to use it.

Of course, the work group can comment on these issues. This way their time is not wasted while we are kicking these things around to find a correct answer.

In my opinion, you should  lead the effort to announce to the group when to stop further discussion on any sample or reactivate a suspended discussion on any sample in future. 

If we add alternative answers (with a warning "this may not be 100% right answer") at the bottom of example , that will reduce email clutter among group members on single example.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: ccda_s...@googlegroups.com

Cc: Brian Weiss <brian...@cdapro.com>; 'Lisa Nelson' <LisaR...@cox.net>; Kumara Prathipati <kuma...@yahoo.com>
Sent: Tuesday, June 4, 2013 11:40 PM
Subject: {C-CDA Samples} Re: PROBLEM LIST SECTION EFFECTIVE TIME

[Kumara Prathipati]

Brian,

I am OK with your logic and reasoning.

You should decide when to finalize this "no known problems" discussion and move to next one.

I can see 

Problem section for Pneumonia "active" and 

problem  section Pneumonia "resolved"

must be hopefully easy and straight forward.

Kumara

---

From: Brian Weiss <brian...@cdapro.com>
To: ccda_s...@googlegroups.com

Cc: Brian Weiss <brian...@cdapro.com>; 'Lisa Nelson' <LisaR...@cox.net>; Kumara Prathipati <kuma...@yahoo.com>
Sent: Tuesday, June 4, 2013 11:40 PM
Subject: Re: PROBLEM LIST SECTION EFFECTIVE TIME

1. for Problem Act (2.16.840.1.113883.10.20.22.4. 3)

1. for Problem Observation (2.16.840.1.113883.10.20.22.4. 4)

 

[raje...@gmail.com]

On Wednesday, June 5, 2013 1:43:50 PM UTC-7, Kumara Prathipati wrote:
> Brian,
>
>
> I am OK with your logic and reasoning.
> You should decide when to finalize this "no known problems" discussion and move to next one.
>
>
> I can see 
> Problem section for Pneumonia "active" and 
>
> problem  section Pneumonia "resolved"
> must be hopefully easy and straight forward.
>
>
> Kumara
>
>
>
>
>
>
>
>
>
>
>
>

> From: Brian Weiss <brian...@cdapro.com>
> To: ccda_s...@googlegroups.com
> Cc: 'Lisa Nelson' <LisaR...@cox.net>; kuma...@yahoo.com
> Sent: Tuesday, June 4, 2013 6:41 AM
> Subject: Re: No Known
> Problems
>
>  
>
> Lisa and Kumara - I'm going to use the Google Group now for this stuff - until the two of you join, I will CC you explicitly...
>
>  
>
> effectiveTime high and low
>
>  
>
> The C-CDA IG seems to be all over the map on
> this.
>
>  

> In section 5.59 Problem Observation, the conformance statement indicates that effectiveTime  SHOULD have both low and high (see CONF:15604 on page 448).  But in the example in figure 212 on page 449  effectiveTime has only a low element with no high.In section 5.2 Advance Directive, the conformance statements (page 293, CONF 8656-8661) require high (SHALL) and guide to the use of nullFlavor (NA or UNK as appropriate) - and the example matches on page 295, figure 154.In 5.4 Allergy - Intolerance Observation, the conformance statement (page 301, CONF:10082) has high as an optional MAY and the example leaves it out.In 5.5 Allergy Problem Act, the conformance statement requires high (SHALL) if the statusCode=completed (page 307, CONF:10085).  In 5.27 Functional Status Problem Observation, the wording of the conformance statement (page 362, CONF:14289) is "SHALL be recorded in the high element of the effectiveTime element when known"

>
> This is just a handful of examples out of many, many more.  Maybe there is some
> special reasoning to each one, but the end result is a mess.  For example, the sample provided by ONC in the S&I Companion Guide for C-CDA CCD sample - when I ran it "as is" through the NIST validator, I got warning messages for "missing high" in:

> the Reaction Observation template in the Allergies sectionthe Problem Concern Act template in the Problem List (for all 11 problems in the sample)the Problem Observation template (for all 11 problems in the sample)

>
> So - setting aside the "logic" of when there should be a high and when there shouldn't, in the cases where there
> is no high - it's not clear if we leave it out (as the samples seem to do) or put it in (as the conformance rules and associated validators seem to suggest).  
>
>  
>
> We need to call this one way or the other on our sample. I think we should follow the conformance rules and it it says SHOULD (as it does for both Problem Concern Act template and Problem Observation template) then I think we should put it in with a suitable nullFlavor.  Agreed?
>
>  
>
> Brian
>
>  
>
>
> On Tuesday, June 4, 2013 10:54:59 AM UTC+3, Brian Weiss wrote:
>
> From Lisa:
>
> BTW – re the act.effectiveTime element of the example below.  When act.statusCode is “active” then it makes sense for the effectiveTime/low to hold a date and effectiveTime/high to be null.  When
> act.statusCode is “completed” then you have either an effectiveTime/low and an effectiveTime/high value with a date, or perhaps just an effectiveTime/high with a date and effectiveTime/low could be null (maybe to say you don’t know when the concern was first identified, but it is no longer a concern).

Hi All,
We are hitting a patch where we don't have info in our EHR for a patient - like no problems to report, no allergies etc. I see that you all have prior experience with this. From a MU 2 certification perspective, can I get some samples for the no information scenarios to complete the required sections?

Thanks in advance!

Rajesh