While working on the "No Problems Found" sample, three things surfaced:
1) For
validation purposes, we need a "baseline C-CDA document" that
validates OK into which we can plug in the specific section/entry templates we
are working on. Most of us have some kind of baseline C-CDA XML file we
use for this purpose.
2) "No
Problems Found" can be interpreted as either "Know/Believed That
There Are No Problems" or "No Information Available One Way Or The
Other About Problems". Keith talks to this distinction and offers
some samples on how to approach them in a blog post from last year. The more common need for
implementers (especially beginners) is for the second case ("No
Information"). Since "No Problems Found" can be
interpreted/mis-interpreted both ways, I prefer we use "No
Information" rather than "No Problems" (or Meds/Allergies/etc.).
3) There is a lot of commonality across various sections re. the core issue of how to say "No Information". There is some difference in various sections (some have "organizers" or "concerns" wrapping observations, some have specific encoding requirements, etc.) - but it seems prudent to tackle them (or at least several of the more common ones) as a group rather than individually.
Putting all of the above together, I decided that instead of our first output here being a "No Problems Found" sample, it would be better if our first output was a full C-CDA CCD that validates OK on the NIST TTT site and basically just says "No Information Available" as concisely as allowed.
So - that is now what this new topic is about.
Brian
Kumara,
As per our previous discussions – I’m OK with alternate
approaches decided on as “this is as far as we go on the debate for now”, but I
want us to drive to a solid “preferred sample” (with or without alternates) for
each example scenario.
I don’t want us to just create “piles of samples”. I want
us create “good samples”. If that means it takes a while for us to build
up a large quantity of samples, that is OK.
To me, good samples means a few things:
1) Focused – not “here’s a complete C-CDA CCD” but
rather “here is a sample section or entry showing clinical scenario X”
2) Solid – subject to our expertise and limits, these should be “as good
as we can make them” (as noted above, to avoid endless academic debates, our
“out” will be to agree documenting alternate approaches for now pending future
guidance from “higher authorities”). This also means we invest required
thought in things like IDs.
3) Annotated – will take us some time to converge on
the correct format, but I outlined earlier what I have in mind now (XML file +
PDF file, PDF file has XML text with line numbers and hyperlinks to educational
and explanatory text).
Input from others on what else is needed for “good” (meaning:
practical, educational, useful) samples is appreciated…
Brian
From: Kumara Prathipati [mailto:kuma...@yahoo.com]
Sent: Saturday, June 08, 2013 06:45
To: Lisa Nelson; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: Re: {C-CDA Samples} Re: Baseline C-CDA CCD With "No
Information"
I think we should
allow for different expressions of "no information available for
problems" and publish from multiple contributors.
Each author can add their comments and justifications why they choose certain codes, attributes/values.
This will make the effort more valuable for many others who will use these samples.
They will also learn from the controversy the finer details of CCDA.
Of course, the
gurus or ONC can give their comments which will be considered official.
Otherwise, if we
insist on only 1 version of any section for a clinical story , we can get
bogged down in discussions and move forward too slow.
Kumara
From: Lisa
Nelson <LisaR...@cox.net>
To: 'Brian Weiss' <brian...@cdapro.com>;
ccda_s...@googlegroups.com
Sent: Friday, June 7, 2013 7:49 PM
Subject: RE: {C-CDA Samples} Re: Baseline C-CDA CCD With "No
Information"
Here is my version of the “no information” sample. I think with these two options, we could move forward to consider how to invent an environment where collaborators could compare their “works of art” and decide what makes sense to be adopted for use as an implementation standard. This will likely give us some interesting comparison and open good discussion.
I tried to work in a way that
left comments in spots where I knew we had a point of comparison to discuss. I
built it in a way that should make it pretty easy to do a side-by-side
comparison.
Lisa
PS - disclosure on the
two warnings this document receives from the same validation techniques used by
Brian.
CCDA Validator |
||
Validating the CCDA against CCDA type <VDT Ambulatory Summary> |
ok |
|
Error |
||
130|Consol General Header Constraints SHALL contain at least one [1..*] author (CONF:5444) each SHALL contain exactly one [1..1] assignedAuthor, where (CONF:5448) assignedAuthor SHOULD contain zero or one [0..1] assignedAuthoringDevice, where its type is Authoring Device |
Warning |
org.openhealthtools.mdht.uml.cda.consol |
1359|Consol Social History Section SHOULD contain zero or more [0..*] entry (CONF:14823, CONF:14824) Contains exactly one [1..1] Smoking Status Observation (templateId: 2.16.840.1.113883.10.20.22.4.78) |
Warning |
org.openhealthtools.mdht.uml.cda.consol |
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: Friday, June 07, 2013 9:17 AM
To: ccda_s...@googlegroups.com
Subject: {C-CDA Samples} Re: Baseline C-CDA CCD With "No
Information"
So... attached is "version one" of my "Baseline C-CDA CCD With No Information".
The file displays as you would expect with the CDA XSL, and it validates without errors or warnings on the TTT site using the "VDT Ambulatory Summary - MU2 170.314 (e)(1) Ambulatory Summary" option.
Well, actually, there are two warnings but both are due to acknowledged defects with testing tool:
https://groups.google.com/forum/#!topic/transport-testing-tool/wOydk7xrNP0
https://groups.google.com/forum/#!topic/transport-testing-tool/yxJxBnFuOTI
so they don't count.
There are quite a few places where the desire to eliminate warning (by meeting SHOULD conformance statements) results in a fair amount of silliness. So, for example, it's not enough to say I have no information about allergies - I have to also say I have no information about the reaction (and its severity) and the severity of the allergy which I know nothing about and may or may not exist. And I even have to use SNOMED codes to describe the reaction (with no option I could see for "no reaction") and the severity of the reaction (on a scale from "Mild" to "Fatal"). Since I'm optimistic by nature, I decided to make the reaction I know nothing about, and that may or may not exist, to the allergy I know nothing about, that also may or may not exist, to be "Treatment not indicated" (which is not a reaction, I know) and to just be "mild". :-)
Humor aside, this is clearly not a good way to document "I don't know" and arguably is just plain wrong. The alternative is to ignore the SHOULD and accept the warning message. The semantics of SHOULD allow you to ignore them "as long as you know what you are doing". But personally I don't think that is good enough - the rules themselves should account for special cases like "No Information" and either make those requirements a MAY or explicitly call out the conditions under which the SHOULD is suspended (with the validator aware of that).
Plenty here that can be debated. This is just a first cut. I'm going to back and go through it more carefully next week and then I'll try to set up a review session with Lisa and anyone else able and willing to participate. Once it feels "right" I'll add a document describing the choices made and their rationale.
It would be great to get feedback on this...
Brian
Re-posting following my accidental delete of this topic...
Here is my version of the “no information” sample. I think with these two options, we could move forward to consider how to invent an environment where collaborators could compare their “works of art” and decide what makes sense to be adopted for use as an implementation standard. This will likely give us some interesting comparison and open good discussion.
I tried to work in a way that left comments in spots where I knew we had a point of comparison to discuss. I built it in a way that should make it pretty easy to do a side-by-side comparison.
Lisa
PS - disclosure on the two warnings this document receives from the same validation techniques used by Brian.
CCDA Validator |
|
Validating the CCDA against CCDA type <VDT Ambulatory Summary> |
|
rror |
||
130|Consol General Header Constraints SHALL contain at least one [1..*] author (CONF:5444) each SHALL contain exactly one [1..1] assignedAuthor, where (CONF:5448) assignedAuthor SHOULD contain zero or one [0..1] assignedAuthoringDevice, where its type is Authoring Device |
Warning |
org.openhealthtools.mdht.uml.cda.consol |
1359|Consol Social History Section SHOULD contain zero or more [0..*] entry (CONF:14823, CONF:14824) Contains exactly one [1..1] Smoking Status Observation (templateId: 2.16.840.1.113883.10.20.22.4.78) |
Warning |
org.openhealthtools.mdht.uml.cda.consol |
Lisa,
Great stuff.
I did the side-by-side comparison. I captured 40
differences (many are variations on a common theme, of course). Hopefully
I caught them all.
Attached is my list of all the differences and my comments.
I think this should make our review session very effective (especially
since I agree or “almost agree” on the vast majority of your corrections).
After we complete our review session and converge on a single
sample (perhaps with some alternate proposals, we’ll see). I will propose a
format for sharing these based on the following “package”:
· The XML of the sample
· The XML of the sample inside the Baseline so that it passes validation (in this case this is identical to the previous, but in general it won’t be)
· A PDF in which the sample is presented with line numbers and hyper-links to explanatory notes
o Educational notes for those new or relatively new to C-CDA who could benefit from that
o Explanatory notes re. subtle or debate-able (or alternates proposed) lines
Brian
From: Lisa Nelson [mailto:LisaR...@cox.net]
Sent: Saturday, June 08, 2013 05:50
To: 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: RE: {C-CDA Samples} Re: Baseline C-CDA CCD With "No
Information"
Here is my version of the “no information” sample. I think
with these two options, we could move forward to consider how to invent an
environment where collaborators could compare their “works of art” and decide
what makes sense to be adopted for use as an implementation standard. This will
likely give us some interesting comparison and open good discussion.
I tried to work in a way that left comments in spots where I knew we had a point of comparison to discuss. I built it in a way that should make it pretty easy to do a side-by-side comparison.
Lisa
PS - disclosure on the two warnings this document receives
from the same validation techniques used by Brian.
...
Re-posting following my accidental delete of this topic...
This is one we will discuss in the review session very soon.
I’m not sure originalText makes a lot of sense in a “No Information” context. There are several places in the sample where there is either a text or originalText element. My approach in “No Information” (and in the Baseline XML) is only to put in what is either required explicitly by a conformance statement in the IG, or a clear underlying CDA best practice.
We’ll need to discuss our overall approach here (I think Lisa mentioned she has given this some thought and has some views on it – so we’ll start with her thoughts as the baseline)…
Brian
From: Kumara Prathipati [mailto:kuma...@yahoo.com]
Sent: Saturday, June 08, 2013 07:17
To: Lisa Nelson; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: Re: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Lisa,
I looked at your problem section example.
I add <original text inside value..
<originalText value="Unable to get information"/>
Below is the definition of OrignalText I found
"The text as seen and/or selected by the user who entered the data" (into EMR)
What is your opinion?
Kumara
<component>
<section>
<templateId root="2.16.840.1.113883.10.20.22.2.5.1"/> <!-- Problem Section with Coded Entries Required -->
<code code="11450-4" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC" displayName="Problem List"/>
<title>PROBLEMS</title>
<text><content ID="problems1">No Information About <content ID="problemType1">Problems</content></content></text>
<entry typeCode="DRIV">
<act classCode="ACT" moodCode="EVN">
<templateId root="2.16.840.1.113883.10.20.22.4.3"/> <!-- Problem Concern Act (Condition) -->
<id root="2.16.840.1.113883.3.3208.101.10" extension="20130607113300-ProblemConcern"/>
<code code="CONC" displayName="Concern" codeSystem="2.16.840.1.113883.5.6" codeSystemName="HL7ActClass"/>
<text></text>
<statusCode code="completed"/> <!-- Do you have any active concerns? No. Brian's example shows the concern as active.-->
<effectiveTime>
<low nullFlavor="NI"/>
<high value="20130607000000-0000"/>
</effectiveTime> <!-- At this time. This isn't open into the future. You would need to check this issue again in the future. -->
<entryRelationship typeCode="SUBJ">
<observation classCode="OBS" moodCode="EVN"> <!-- I removed this nullFlavor="NI" not sure why it was there. In documenting this situation, it was observed that there was no information about problems.-->
<templateId root="2.16.840.1.113883.10.20.22.4.4"/> <!-- Problem Observation -->
<id root="2.16.840.1.113883.3.3208.101.10" extension="20130607113430-ProblemObservation"/>
<code
code="55607006"
codeSystem="2.16.840.1.113883.6.96"
codeSystemName="SNOMED CT"
displayName="Problem">
<originalText><reference value="#problemType1"></reference></originalText>
</code>
<text><reference value="#problems1"/></text> <!-- I don't this this text element should be populated. I think the text element of the outer entry should encompass all the sub-entry parts of the clinical statement. -->
<statusCode code="completed" />
<effectiveTime>
<low nullFlavor="NI"/>
<high value="20130607000000-0000"/>
</effectiveTime> <!-- Up until now. -->
<value xsi:type="CD" nullFlavor="NI"
<originalText value="Unable to get information"/>
</value>
</observation>
</entryRelationship>
</act>
</entry>
</section>
</component>
From: Lisa Nelson <LisaR...@cox.net>
To: 'Brian Weiss' <brian...@cdapro.com>; ccda_s...@googlegroups.com
Sent: Friday, June 7, 2013 7:49 PM
Subject: RE: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Here is my version of the “no information” sample. I think with these two options, we could move forward to consider how to invent an environment where collaborators could compare their “works of art” and decide what makes sense to be adopted for use as an implementation standard. This will likely give us some interesting comparison and open good discussion.
Agreed. The current exercise is a “baseline CCD that passes the validator” and its substance is “No Information” (meaning, conceptually, there is nothing relevant in the EMR record – maybe it’s a record for a new patient visiting the clinic for the first time, tomorrow).
From there, we can explore various other flavors of negation and “no information”/nullFlavor variants (like ASKU).
Lisa - I look forward to getting your full perspective on text and originalText when we hold the review session. Your logic below (and in general J) is very solid in my view…
Brian
From: Lisa Nelson [mailto:LisaR...@cox.net]
Sent: Saturday, June 08, 2013 13:52
To: 'Kumara Prathipati'; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: RE: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Kumara,
I think the discussion of the relationship between the human readable text and the associated machine readable entries will require some longer discussion to set the foundation for considering the question of what is correct to be encoded as the originalText associated with an encoded concept.
The narrative text of the section and the associated entries “balance each other”. If you suggest a change on one side of the equation, you need to simultaneously address the corresponding change on the other side of the equation. Ultimately, the information presented to the humans and the machines needs to be equivalent, or dangerous stuff could be happening when we get the Clinical Decision Support applications for this data – and there is always the issue of how to determine if what we have created is correct. Both of these issues require deeper discussion for us all to get in the same zone of thinking about this material.
So, if you change the OriginalText (which would never have its value documented in the entry, but rather would have its value presented in the human readable text and originalText would then point to the text written there), then we would need to change the narrative text from “No information about Problems” to “Unable to get information about Problems”. And, if you did that, then I would argue that we would need to look at using the nullFlavor of ASKU (asked but unknown) rather than NI (no information). These are subtle but potentially significant differences. Making the change you are considering would require us to generate a different sample, I think.
Lisa
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 Kumara Prathipati
Sent: Saturday, June 08, 2013 12:17 AM
To: Lisa Nelson; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: Re: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Lisa,
I looked at your problem section example.
I add <original text inside value..
<originalText value="Unable to get information"/>
Below is the definition of OrignalText I found
"The text as seen and/or selected by the user who entered the data" (into EMR)
What is your opinion?
Kumara
...
Re-posting following my accidental delete of this topic...
Kumara,
In my document summarizing the differences (Lisa’s suggested changes) I note this in my item 2) for Allergy Problem Act and 21). CDA supports a text element in an act, so it is valid for sure. Whether it is a good idea or not in places where the C-CDA IG doesn’t call for it, is something we will hear Lisa’s view on during our review session.
One of the challenges with C-CDA is that the IG is not a stand-alone document. It is layered on top of the CDA framework overall (which has its own set of rules and best practices) which in turn derives from the RIM model (ditto).
Brian
From: Kumara Prathipati [mailto:kuma...@yahoo.com]
Sent: Saturday, June 08, 2013 16:23
To: Lisa Nelson; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: Re: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Lisa,
I see your example has entry.act.text
Page 444 and page 445 does not show this <text></text> xml element in Act section?
Is this over sight or intentional.
Please clarify.
Kumara
Re-posting following my accidental delete of this topic...
effectiveTime values will be part of the review session – you can see some additional perspectives of mine in the “differences” document I sent earlier today – but mostly I want to hear out Lisa and her preferred approach.
We can, if we need to, agree to disagree and document multiple approaches. Let’s see how the review session goes.
Brian
From: Kumara Prathipati [mailto:kuma...@yahoo.com]
Sent: Saturday, June 08, 2013 16:40
To: Lisa Nelson; 'Brian Weiss'; ccda_s...@googlegroups.com
Subject: Re: {C-CDA Samples} Re: Baseline C-CDA CCD With "No Information"
Lisa,
PROBLEM LIST:
Inside Act block
It is possible to debate effective time for ever.
I "believe" the original intent of effective time in a the document is
when the monitoring of the concern started and
when the monitoring of the concern ended.
We are monitoring the item mentioned inside the <observation></observation> nested inside <ACT>.
If patient is comatosed, and physician is unable to obtain history about patient problems
low value = time patient unable to provide information event started
high value = unknown how long the situation drags on
When a relative comes after 2 days and gives history of patient problems, then high value will be available..
or when patient wakes up and gives history, then high value will be available.
Once again, my feeling is we should not prolong the discussion beyond certain point
and rather provide various view points in examples with rationale from the different authors
and move on to next example.
We can always visit these examples in future.
Kumara
For those of you following along on the HL7 SDWG listserv, there's been a lot of back-and-forth around an important subset of this "baseline" scenario - namely, how to represent "no information" or "missing information", and how exactly nullFlavor should be used.I managed to get my wrist slapped vis a vis the appropriateness of my communications on the HL7 listserv - which I am trying to take in stride... It re-enforces for me why I had to create this Google Group to make progress without annoying the fine folks at HL7. And really, I think some of those folks at HL7 - while incredibly well-intentioned and having done great things in creating and evolving the HL7 standards and their underlying models that we all depend on - are challenged a bit to understand the not-so-academic and compromise-filled world of practical implementations. Or they just don't have a lot of patience for it and/or for relative beginners (though at some point I will stop calling myself a beginner :-) ).Attached is a PDF with the latest and greatest samples specific to this part of the scenario (this is NOT the PDF I have promised for this scenario overall - a little more patience please...). In addition to containing the samples themselves (organized the way Lisa suggested -t thanks, Lisa) this also gives you a good feel for the kind of "annotated samples" I plan to create. Click around a bit and let me know what you think...Brian
I agree and we will work that in…
You can see that I started to do that with terms I came across (see in the PDF starting after the document-specific annotations through the end – everything there is a hyper-linked entity.
It would be great if you could note which terms need that “glossary” in the current document, but don’t yet have it.
Brian