Why Old Issues Regarding CDA Are Once Again New

In two posts from the last few days (here and here) I comment on recent intense exchanges within the HL7 CDA community concerning proper coding of clinical data using CDA. The reader is invited to examine these exchanges and to determine whether she agrees with me in the conclusion that HL7 CDA is, like the RIM on which it is based, so clunky, and so counterintuitive, as to threaten  dangers for safety and security (dangers which become all the more worrying to the degree that HL7 CDA is associated with government edicts requiring its use). 

Yesterday I added a further post, recalling Eric Browne's argument from January 2012 to the effect that this state of affairs is bringing about a situation where (to paraphrase only slightly) 

we are in grave danger of setting in train a collection of safety and quality time bombs, spread around [the world] in a system of repositories, with no understanding of the clinical safety, quality and medico-legal issues that might be unleashed in the future.

As Grahame Grieve points out in his comment to this post, he had already responded to Eric's argument on his healthintersections blog in February of that year. 

No news here, therefore; we should all just move along and get back to the more important issues of the day. 

But what is Grahame's response?

Eric’s key issue is that HL7 CDA allows data to be supplied simultaneously in two distinct, yet disconnected forms – one which is “human-readable”, narrative text displayable to a patient or clinician in a browser  panel;  the other comprising highly structured  and coded clinical “entries” destined for later computer processing.

As Grahame points out, CDA is built around the notion of the twin forms – a human presentation, and a computer processible version. But when Eric complains that clinicians have no way to inspect how the data and the narrative relate, nor is there an algorithm to test this, his response is 

This is true – and it would be a whole lot more concerning except that this is true of all the forms of exchange we currently have – it’s just that they don’t have any human fall back to act as a fail safe check.

Thus the miserable complexity and clunkiness and unteachability of the structured part of HL7 CDA (thus of the HL7 part) are not a problem – because ... well, because of what? 

Is it that HL7 CDA structured data is good because the problem of uncheckability (either by human beings or by algorithms) is faced by all attempts to create structured healthcare data?

Does experience thus far (including experience of panic on the strucdoc listserv in just the last few days) suggest that HL7 CDA is a good candidate to overcome this  problem, given that we are all agreed that it needs to be overcome?

Critical Safety Issue for HL7 CDA

We have addressed (for example here and here) a number of what seem to be astonishingly difficult problems which face those who attempt to use HL7 CDA for coherent coding of clinical information.   

In his "Critical Safety Issue for the PCEHR", Eric Browne makes clear why such problems may be of more general interest. Eric is talking here about the Australian Personally Controlled Electronic Health Record, but his warning (in bold below) is of much broader significance:

One major problem with HL7 CDA, as currently specified for the PCEHR, is that data can be supplied simultaneously in two distinct, yet disconnected forms – one which is “human-readable”, narrative text displayable to a patient or clinician in a browser  panel;  the other comprising highly structured  and coded clinical “entries” destined for later computer processing. The latter is supposed to underpin clinical decision support, data aggregation, etc. which form much of the justification for the introduction of the PCEHR system in the first place. The narrative text may appear structured on the screen, though is not designed for machine processing beyond mere display for human consumption.

Each clinician is expected to attest the validity of any document prior to sharing it with other healthcare providers, consumers or systems, and she can do so by viewing the HTML rendition of the “human-readable” part of the document ( see the example discharge summary here). However, the critical part of the document containing the structured, computer-processable data upon which decision support  is to be based is totally opaque to clinicians, and cannot be readily viewed or checked in any meaningful way. Moreover, I know of no software anywhere in the world that can compare the two distinct parts of these electronic documents to reassure the clinician that what is being sent in the highly structured and coded part matches the simple, narrative part of the document to which they attest. This is due almost entirely to the excessive complexity and design of the current HL7 CDA standard.

It seems to me that we are in grave danger of setting in train a collection of safety and quality time bombs, spread around Australia in a system of repositories, with no understanding of the clinical safety, quality and medico-legal issues that might be unleashed in the future.

As an illustration of the sort of problems  we might see arising, I proffer the following. I looked at 6 sample discharge summary CDA documents  provided by the National E-health Transition Authority recently. Each discharge summary looked fine when the human-readable part was displayed in a browser, yet unbeknownst to any clinician that might do the same, buried in the computer-processable part, I found that each patient was dead at the time of discharge. One patient had been flagged as having died on the day they had been born – 25 years prior to the date that they were purportedly discharged from hospital! Fortunately this was just test, not “live” data.

Why do HL7's Attempts to Create a Structured Clinical Document So Conspicuously Fail?

I estimate the total number of words posted to HL7's STRUCDOC (structured documents) listserv for the single day of June 18, 2013 to be in the order of 8,000. The Digest of these postings is provided below. (I do not provide the postings themselves, for reasons of space, though samples of earlier such exchanges are available, for example here.)

The general tone of these exchanges is a mixture of authority (from persons who have been participating in such email fora for a long time), concern (from persons new to HL7 who are interested in learning how to deal with sometimes difficult topics), puzzlement (from persons who wonder why these problems cannot be handled in a simpler and more intuitive way), and panic ("if HL7 generates such furious and seemingly interminable debates of such a high degree of complexity, how will we ever be able to safely use it to address the day-to-day practical problems that we face in coding healthcare information?" "How will we ever be able to teach people to use it?").

I have been asked to explain why I think HL7 generates debates of this sort, and I here provide a first list of what I believe to be the most important factors. 

A. As argued from the very beginning of this blog, the RIM (Reference Information Model), which is the basis of HL7 V3, rests on a fatal confusion between model of information and model of reality. This brings the consequence that the persons involved in these debates lack a clear foundation for debate. I have argued at length that it is impossible to use the RIM to produce an intuitively satisfactory representation of any even modestly complex matter -- since parts of such a representation will relate to information about the world and parts to the world itself (for example to the condition of the patient). (Matters are made worse by the fact that the very framework obfuscates the difference between the two.) 

B. This failure to provide intuitively satisfactory representations implies a failure in consistent understandability. This will mean that (for example) lists of codes and statements of coding principles will be understood differently by different individuals, some of whom will fight over whose interpretation is correct.

C. These fights will sometimes lead to adjustments to the principles. (They may even lead to improvements; some have even led to the addition of elements drawn from realist ontology to the HL7 framework.) Unfortunately, and perhaps most regrettably, the explications of these adjustments do not replace the existing HL7 documentation. Rather, they are simply inserted into the documents alongside the original, logically incoherent, formulations, as outlined here. This means that the result of such adjustments is that the HL7 documentation itself becomes logically ever more incoherent, leading to ever more furious debates over its interpretation.

D. The end-effect is that people leave, and when the new people who join start their work they have to rely  on bloated and confused documentation -- but now without the benefit of having experienced the criticisms of shoddy work advanced (for example on this blog). And so the same mistakes are made all over again.

To see why such issues might be important for reasons other than morbid curiosity, see "Critical Safety Issue for HL7 CDA" above.

STRUCDOC Digest for Tuesday, June 18, 2013.

1. SUBJECT CHANGE: Debate about whether we need to deal with C-CDA reality
2. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
3. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
4. SUBJECT CHANGE: Debate about complexity of standards
5. Re: SUBJECT CHANGE: Debate about complexity of standards
6. RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
7. Fix CDA's problems, don't encourage half measures.  Was:  RE: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set8. header >> race code ambiguity
9. RE: header >> race code ambiguity
10. Re: SUBJECT CHANGE: When to use OTH and when to use UNK when you don't have a code in the Value Set
11. Re: header >> race code ambiguity
12. Re: header >> race code ambiguity
13. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
14. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
15. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
16. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
17. RE: header >> race code ambiguity
18. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
19. RE: header >> race code ambiguity
20. RE: header >> race code ambiguity
21. SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
22. Re: header >> race code ambiguity
23. RE: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
24. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
25. Re: Significant and Not Easily Addressed Validator Issue re. CWE Value Set Bindings
26. RE: Block Vote 06/20/2013: Structured Form Definition Implementation Guide Ballot Reconciliation
27. Re: header >> race code ambiguity
28. Re: SUBJECT CHANGE: raceCode in MU, C-CDA IG, and TTT Validator
29. RE: Block Vote 06/20/2013: Questionnaire Response Implementation Guide Ballot Reconciliation
30. RE: header >> race code ambiguity
31. Re: header >> race code ambiguity
32. Re: header >> race code ambiguity
33. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
34. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
35. Hijack Subject: Can we indicated "translation closeness" in CD
36. Re: Hijack Subject: Can we indicated "translation closeness" in CD
37. Re: Hijack Subject: Can we indicated "translation closeness" in CD
38. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
39. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
40. Re: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
41. RE: Value Set question, split from thread "Validator Issue re. CWE Value Set Bindings"
42. Automatic Conference Call Reminder for Structured Documents

HL7 V3 Makes Great Strides in Providing a Clear Representation of Body Weight

BodyWeight has Device

Device is a coded description 

Clothing is a coded description 

BodyWeight has Clothing 

BodyWeight is a physical quantity 

BodyWeight has BodyWeight 

From:

V3_DCM Models_R1_I1_2010Sep-BodyWeight-v1.08.pdf

What could go wroNg?

Meaningful Use of CDA When Medication Code is Unknown

What follows is a brief guide to those using CDA to address Meaningful Use Stage 2 requirements and who need to code information pertaining to use of a medication that is not included in any existing code set.


From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org]
On Sun, Jun 9, 2013 at 8:53 PM, Tom de Jong ‹tom@nova-pro.nl› wrote:

Hi Keith, Brian,
I want to provide feedback from Pharmacy WG here, because I believe strongly that implementation guidelines for medication-related information should NOT be dependent on the carrier (i.e. a message or a document), when semantics should only be determined by the generic V3 backbone.
That having been said, it should most certainly be possible to leave the code empty (i.e. use a nullFlavor) when there is no official code available.
But I believe the proper nullFlavor to use is 'OTH', since the concept (i.e. medication type) is not codable within the value set that's available to you. It's perfectly OK to have a description of the medication type in the ‹originalText›. That leaves only one question: should it be necessary to state the RxNorm codeSystem OID? The current validators may require it, but
I believe it's against standing V3 datatype guidance. Technically, it would be useful to express the value set that the concept is *not* codable in, but I have always heard that using nullFlavor precludes using any other elements within the CD datatype, except ‹originalText›. Guidance on this should be
common across all of HL7, and should be documented at the level of the data type (i.e. not be dependent on the context of use). So both Pharmacy and SD WG have a good reason for getting this settled.

Best,
Tom


From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On
Behalf Of Lloyd McKenzie
Sent: Monday, June 10, 2013 07:36
To: Tom de Jong
Cc: Boone, Keith W (GE Healthcare); Brian Weiss; HL7 Structured Documents;
pharmacy@lists.hl7.org
Subject: Re: Uncoded medication

Hi Tom,
Unfortunately it's *not* against standing data types advice.  If you use the OTH null flavor in data types R1, codeSystem *must* be populated.  It's a silly rule because it doesn't give you any useful information.  Your value set may not draw from the whole code system you can't infer that the OTH means the code isn't from the specified code system.  Furthermore, the value
set might span code systems.
The rule in Data Types R2 is a bit more reasonable.  You must specify either the code system (in circumstances when the value set is "all codes from code system X") or a value set id.  I still think it's a little onerous given that 90%+ of receivers aren't going to care.  However at least it's useful information.  However, for CDA R2, you're using Data Types R1.
Lloyd


From: Brian Weiss [mailto:brian.weiss@cdapro.com]
Sent: Tuesday, June 11, 2013 02:06
To: 'Lloyd McKenzie'; 'Kevin Coonan, MD'
Cc: 'Tom de Jong'; 'Boone, Keith W (GE Healthcare)'; pharmacy@lists.hl7.org;
'HL7 Structured Documents'
Subject: RE: Uncoded medication

Lloyd and Kevin,
I think we have to be clear here what context you are talking about:

1)      RIM

2)      CDA Normative Edition

3)      C-CDA IG

4)      TTT Validator

And then I think we also need to qualify if we are referring to "clear formal statement" (where we can cite chapter and verse from a published spec) vs. "intent".

For example, in the case of the TTT Validator, leaving something out that is a SHALL or SHOULD does NOT default to nullFlavor="NI", it generates an Error or a Warning (respectively).  So, in that context, "technically" there is a big difference (meeting MU2 or not), indeed.
In the C-CDA IG, I also didn't think it was acceptable to leave something out that is a SHALL and have it default to nullFlavor="NI".  If I'm right (not sure), this would not be something for which we ought to open a defect with the validator writers, either.
That doesn't mean your statement below is incorrect from a model standpoint - we just have to be clear what context we are talking about as there are different audiences on this listserv with different agendas. With all due respect to the folks working on the standards, an implementer tasked with achieving MU2 certification by their employer, really doesn't care at this point what the intent was, what the model says, etc.  The only thing that really matters is the validator (and, whether it's legit to report something as a validator defect or not).
Brian

On Tue, Jun 11, 2013 at 3:32 PM, Tom de Jong ‹tom@nova-pro.nl› wrote:
Hi Grahame,
I think it's pointless trying to get harmony between CDA and pharmacy is pointless because the CDA expression is so limited, unless, that is, the pharmacy committee commits to working within the constraints that CDA imposes (not fun).
There are many cases where the CDA expression is just as rich as the one in the Pharmacy domain, i.e. rich enough to capture the proper semantics (more cases than where it is not). This is such a case. My point is: if both paradigms allow the same expression, we should use the same expression.
Ø  There is - and always has been - a rule that if OTH is provided, then the codeSystem must be populated:
Ah, I’ve asked about that rule many times, but I was never pointed to it (and obviously never able to find it). I guess this is in the abstract data type spec, which explains why it was hard to find. Apologies for missing it, but I do understand why implementers say the spec is hard to crack.
Ø  I'm sure you wouldn't otherwise think that simply because a rule is not enforced in the schema it's free to ignore, so I don't know why you think that here.
Like I said, I knew the rule was not enforced by the XML Schema. I looked for it in the XML ITS for the data type, but now know that I should have looked in the abstract data type spec. It would be REALLY helpful if data type rules like this would simply be listed as Schematron rules or even as template-style statements in the data type ITS. That way, we could simply ignore the abstract spec, which is what most implementers do anyway.
I’ll stay out of the rest of the discussion, because it’s very specific to the restrictions in the C-CDA spec.
Thanks,
Tom

Van: Victor Chai [mailto:victorchai01@gmail.com]
Verzonden: dinsdag 11 juni 2013 11:21
Aan: Tom de Jong
CC: Grahame Grieve; Lloyd McKenzie; Boone, Keith W (GE Healthcare); Brian Weiss; HL7 Structured Documents; pharmacy@lists.hl7.org
Onderwerp: Re: Uncoded medication
So end of this discussion, have we confirmed whether the below example from Keith valid in CDA?
Rgds
Victor Chai
‹manufacturedProduct classCode="MANU"›
‹templateId root="2.16.840.1.113883.10.20.22.4.23"/›
 ‹id/›
 ‹manufacturedMaterial›
 ‹code nullFlavor='UNK'
   codeSystem="2.16.840.1.113883.6.88"›
 ‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
 ‹/manufacturedMaterial›
 ‹manufacturerOrganization›...‹/manufacturerOrganization›
‹/manufacturedProduct›


From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Tom de Jong
Sent: Tuesday, June 11, 2013 13:15
To: 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'Brian Weiss'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Repeating from the main point in my original e-mail: the nullFlavor should be ‘OTH’. Other than that, the snippet is correct.
Best,
Tom

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 6:25 AM
To: 'Tom de Jong'; 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
I thought we said that with nullFlavor=”OTH” we would put in the codeSystem (and with nullFlavor=”NI” we would not)?  Perhaps I misunderstood…
Brian

From: Lisa Nelson [mailto:LisaRNelson@cox.net]
Sent: Tuesday, June 11, 2013 15:38
To: 'Brian Weiss'; 'Tom de Jong'; 'Victor Chai'
Cc: 'Grahame Grieve'; 'Lloyd McKenzie'; 'Boone, Keith W (GE Healthcare)'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Wow is this painful!  I’m tracking with Brian on this… I thought we said that with nullFlavor=”OTH” we would put in the codeSystem (and with nullFlavor=”NI” we would not).
Further, I understand that the use of nullFlavor=”NI” (and no codeSystem) has the semantic meaning the corresponds to “No information about…”.
However, I’m having trouble inventing a sentence to capture the meaning that would correspond to a use of nullFlavor=”OTH” (with codeSystem).  What would be the information in the human  readable text to go with this machine readable entry? Is this the case where the medication is a medication that does not have a code in the specified value set?  Value sets can have codes from different code systems, so how would I know which was the correct codeSystem to include?  Is this a possible use case for nullFlavor=”OTH”? The IG specifies that this code SHALL come from value set ABC (CWE) and value set ABC has RxNorm and NDF-RT codes populating it. The medication I need to represent is some drug in a clinical trial that doesn’t have an RxNorm or NDF-RT code yet. I would encode the code element using nullFlavor=”OTH” with originalText=”Name-of-new-drug”.  Is that right?   What would I choose for the codeSystem attribute?  Would I use the OID for RxNorm or NDR-RT?
If this isn’t correct, could someone please construct this scenario for me, and explain how we determine the correct codeSystem to use.  I’m not clear on how we factor in the issue of a conformance to have the code come from a particular value set.  The value set conformance seems to play a role in determining that nullFlavor=”OTH” is the correct encoding, but  then I feel like I should be including the valueSet attribute rather than the codeSystem attribute to make the encoding for the code element really make sense.

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


On Tue, Jun 11, 2013 at 9:34 PM, Brian Weiss ‹brian.weiss@cdapro.com› wrote:
Lisa,
Everything you wrote below seems correct and consistent with our discussion (which I think is converging) up to the point where you introduce a distinction between Value Set and codeSystem (with the example of a Value Set that includes multiple Code Systems like RxNorm and NDF-RT).  I wasn’t aware that was the case in C-CDA – can you give some examples?  If that is the case then I suppose it would be problematic to select one codeSystem for the nullFlavor=”OTH” case (since it is “other” relative to both).
So, this issue you have raised is one open question.  Another is my question about what originalText should point to in the nullFlavor=”NI” case.
I think we have converged on the following so far (with the two open questions noted):
For the case where manufacturedMaterial is not in the codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
codeSystem="2.16.840.1.113883.6.88"›  ‹!-- Lisa open question about what happens if valueSet corresponds to multiple codeSystems --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI'
‹originalText›‹reference value="#something"/›‹/originalText›  ‹!-- Brian open question about what #something shoul point to --›
‹/code›
‹/manufacturedMaterial›
Brian

From: Victor Chai [mailto:victorchai01@gmail.com]
Sent: Tuesday, June 11, 2013 10:40 AM
To: Brian Weiss
Cc: Lisa Nelson; Tom de Jong; Grahame Grieve; Lloyd McKenzie; Boone, Keith W (GE Healthcare); HL7 Structured Documents; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
For the case where manufacturedMaterial is not in the codeSystem, and there is NO code avail, then codeSystem attribute shall be empty.
‹manufacturedMaterial›
‹code nullFlavor='OTH'
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the codeSystem, but there IS code avail, then codeSystem attribute shall be populated with the corresponding code system where the code is drawn from, e.g the below example where the code is from SNOMED CT, not from the required RxNorm code system.
‹manufacturedMaterial›
‹code nullFlavor='OTH' code="XXXX"
codeSystem="2.16.840.1.113883.6.96"›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
Rgds
Victor Chai

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Victor Chai
On Tue, Jun 11, 2013 at 10:50 PM, Boone, Keith W (GE Healthcare) ‹keith.boone@ge.com› wrote:
›From where do you get that specification?
According to abstract data types:
invariant(CD x)
      where x.other {
   x.code.other;
   x.codeSystem.nonNull;
};
That implies that, when nullFlavor='OTH' (x.other above), that codeSystem must be present (x.codeSystem.nonNull).
Keith W. Boone

Sent: Tuesday, June 11, 2013 17:59
To: Boone, Keith W (GE Healthcare)
Cc: Brian Weiss; Lisa Nelson; Tom de Jong; Grahame Grieve; Lloyd McKenzie; HL7 Structured Documents; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
So what would you recommend to fill in codeSystem attribute for the this case?
For the case where manufacturedMaterial is not in the codeSystem, and there is NO code avail, then codeSystem attribute shall be empty.
Rgds
Victor Chai

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 18:18
To: 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Lisa Nelson'; 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
If there is only one codeSystem specified by the IG, I would of course specify that.  That is typically the case, I believe.  If we take the manufacturedMaterial example specifically, CONF 7142 says:
This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug Name Value Set 2.16.840.1.113883.3.88.12.80.17 DYNAMIC (CONF:7412).
As per Table 119 on page 304, that Value Set (2.16.840.1.113883.3.88.12.80.17) is draws from RxNorm.  So, codeSystem=”2.16.840.1.113883.6.88”
Now, I think Lisa was saying that in some cases a Value Set can draw from multiple Code Systems, which is news to me (still need to get an example – Lisa?).  But other than that, at least in a practical C-CDA context, I think that is the answer.
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Brian Weiss
Sent: Tuesday, June 11, 2013 11:30 AM
To: 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Lisa Nelson'; 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
I was pleased to see that the validator was fine with an alternate codeSystem being used alongside nullFlavor=”OTH”  as Victor suggested.
So, we now have three updated samples that reflect our convergence thus far (I’m suspending the multiple codeSystem question pending a sample from Lisa or otherwise):
For the case where manufacturedMaterial is not in the required codeSystem, but is in a different known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
     code=”XXXX” ‹!-- whatever it is in the different codeSystem --›
codeSystem="a.b.c.d.e.f.g.h"›  ‹!-- whatever the different codeSystem is --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the required codeSystem, and not in any other known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
codeSystem="2.16.840.1.113883.6.88"›  ‹!-- the codeSystem required for this code --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
‹originalText›‹reference value="#something"/›‹/originalText›  ‹!—Brian has an open question about what #something should point to --›
‹/code›
‹/manufacturedMaterial›
Additional comments welcome…
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Lisa Nelson
Sent: Tuesday, June 11, 2013 19:29
To: 'Brian Weiss'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication
Brian,
This is very good progress, but I am really struggling with the way you are wording the conclusions.  The phrase, “not in the required codeSystem” is just not sitting well with me.  Read any conformance statement in an IG and you will read that a code is required to come from a particular Value Set. The specification in an IG does not reference the code system in what it says is required.  To make these conclusions work, I think we need to specify the value set  and binding syntax that an implanter is up against in an IG.  Otherwise, you leave a gap that implementers have to leap across for themselves.
For the case where manufacturedMaterial is not in the required valueSet and the binding syntax permits CWE, and there is a code for the concept in a different known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
     code=”XXXX” ‹!-- whatever it is in the different codeSystem --›
codeSystem="a.b.c.d.e.f.g.h"›  ‹!-- whatever the different codeSystem is --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where manufacturedMaterial is not in the required valueSet and the binding syntax is CE, or the binding is CWE and the concept is not in any other known codeSystem:
‹manufacturedMaterial›
‹code nullFlavor='NA' ‹!-- Could this be NAV – temporarily unavailable, as it could become part of an updated version of the value set at a future time, if the value set were being sustained. --›
‹!-- the codeSystem is not required for this case --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
For the case where there is no information about manufacturedMaterial:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
‹originalText›‹reference value="#something"/›‹/originalText›  ‹!—Brian has an open question about what #something should point to --›
‹!—Lisa thinks the originalText should reference the statement in the narrative text which says, “No information available about medications.” --›
‹/code›
‹/manufacturedMaterial›
Lisa
Lisa R. Nelson, MSc, MBA | Consultant | Life Over Time Solutions | cell: 401.219.1165 | Westerly, RI | LisaRNelson@cox.net

From: Brian Weiss ‹brian.weiss@cdapro.com›
To: 'Lisa Nelson' ‹LisaRNelson@cox.net›; 'Victor Chai' ‹victorchai01@gmail.com›; "'Boone, Keith W (GE Healthcare)'" ‹keith.boone@ge.com›
Cc: 'Tom de Jong' ‹tom@nova-pro.nl›; 'Grahame Grieve' ‹grahame@healthintersections.com.au›; 'Lloyd McKenzie' ‹lloyd@lmckenzie.com›; 'HL7 Structured Documents' ‹strucdoc@lists.hl7.org›; pharmacy@lists.hl7.org
Sent: Tuesday, June 11, 2013 10:39 AM
Subject: RE: Uncoded medication
Lisa,
Thanks to your e-mails, I’m gaining an appreciation for the problem in my interchangeable use of “Code System” and “Value Set”.  I noticed that all the Value Set tables in the IG indicate “Code System(s):” – although as a practical matter there is always just one.
I’ve tried to switch my wording to “Code System specified by the required Value Set”.  I think in a C-CDA IG context, that covers us.  I want to limit my samples below to C-CDA IG as going beyond that is more than I feel I can handle, someone else can potentially look to expand this to generic CDA.  And in terms of the broader case outside of C-CDA where someone defines a Value Set with multiple Code Systems, I think they will have to come up with some explicit guidance on what to do in terms of “OTH” – perhaps making one of the Code Systems “primary” or something like that, I don’t know.
I also see that you proposed an answer to my originalText question, thanks.  I’m going to go with that unless someone else chimes in with something else.
I have not adopted your proposal re. “NA” or “NAV” instead of “OTH” – do you still think it is needed given the way the cases are defined below?  Is there a need for another case.
Finally, I have not gotten into CWE vs. CE.  Is this a practical issue in a C-CDA IG context?  If not, I’m going to ask to defer it to whoever picks this up from a broader CDA perspective…
1) For the case where we don’t know the encoding of the concept in the Code System of the required Value Set, but have a code for it in a different Code System…
1A) …if we don’t know the code in the Code System of the required Value Set, but think it might exist:
‹manufacturedMaterial›
‹code nullFlavor='UNK'›
Since you are asserting that you don’t know what the specific type of manufactured material is, it is nonsensical (and not allowed) to also say what it is via the original text. Also, if you don’t have the CD.code specified, you cannot use translations.  Translations are explicitly defined as a translation of the concept represented by the CD.code+codeSystem, which is not even allowed for UNK.
     ‹originalText›‹reference value="#manmat1"/›‹/originalText›
     ‹translation code="XXXX" codeSystem="a.b.c.d.e.f.g.h" /›  ‹!-- whatever the different code and codeSystem is --›
‹/code›
‹/manufacturedMaterial›
1B) …if we believe a code doesn’t exist in the Code System of the required Value Set:
‹manufacturedMaterial›
‹code nullFlavor='OTH'›
     ‹originalText›‹reference value="#manmat1"/›‹/originalText›
Translations are explicitly defined as a translation of the concept represented by the CD.code+codeSystem.  If these are not present, translations are not used.
     ‹translation code="XXXX" codeSystem="a.b.c.d.e.f.g.h" /›  ‹!-- whatever the different code and codeSystem is --›
‹/code›
‹/manufacturedMaterial›
2) For the case where we don’t know the encoding of the concept in any Code System:
‹manufacturedMaterial›
‹code nullFlavor='OTH'
You must provide a code + code system (both)
codeSystem="2.16.840.1.113883.6.88"›  ‹!-- the codeSystem required for this code --›
‹originalText›‹reference value="#manmat1"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
3) For the case where there is no information about the concept at all:
‹manufacturedMaterial›
‹code nullFlavor='NI' ‹!-- No need for code or codeSystem when using NI --›
You have no information, thus there is never an original text.  Nothing else is allowed.
‹originalText›‹reference value="#noinfotext"/›‹/originalText›
‹/code›
‹/manufacturedMaterial›
Brian

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Kumara Prathipati
Sent: Tuesday, June 11, 2013 15:46
To: Brian Weiss; 'Lisa Nelson'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: Re: Uncoded medication
Brian,
Thanks for the final clarity you are providing for this issue of "code not known" and various scenarios in that category..
I like the wording "Code System specified by the required Value Set" which eliminates confusion for any one who is not an expert in CDA.
Kumara

From: owner-strucdoc@lists.hl7.org [mailto:owner-strucdoc@lists.hl7.org] On Behalf Of Kevin Coonan, MD
Sent: Wednesday, June 12, 2013 03:54
To: 'Kumara Prathipati'; 'Brian Weiss'; 'Lisa Nelson'; 'Victor Chai'; 'Boone, Keith W (GE Healthcare)'
Cc: 'Tom de Jong'; 'Grahame Grieve'; 'Lloyd McKenzie'; 'HL7 Structured Documents'; pharmacy@lists.hl7.org
Subject: RE: Uncoded medication

All four examples are invalid.
There is a good deal of helpful information in the Core Principles and Properties of HL7 Version 3 Models, particularly section 5, which defines terminology binding.   It is in the Foundation standards.  In addition, reviewing the RIM and data types specification (data types r2 section 3.1.2, data types r1 1.11.4.  Also see the usage notes in the vocabulary for NullFlavor.  Also in Foundation standards) would have answered your questions.
Unless you are using a tool which constrains you to only saying things which are valid per the CDA XML Schema/templates and which prevents you from violating the basic semantics of HL7 v3, you will need to understand these parts of the standard in order to create valid examples.  It is not reasonable to continue to expect to use the SD WG and pharmacy WG lists to continue to provide proof reading and tutorial services to you,  or to listen to your complain when people don’t.  Please avail yourself of the existing documentation and then feel free to ask any questions of the group.  HL7 provides in-person training ‹http://www.hl7.org/implement/training.cfm?ref=common›  (e.g. at WGMs and at educational summits) 6 times a year where you can get started.  If you need additional tutoring, or custom training, there are many expert consultants within HL7 who provide this service.  You may also wish to avail yourself of the well regarded CDA Academy ‹http://www.cdaacademy.com/›  which Lantana offers in fall.
Keith, Lloyd, etc.  correct me on the details of CDA r2 version of the data types & RIM (or my XPath grammar—been a while since I used it), etc. but the examples are not legal.  If you assert that SomeClass@code is an exceptional value, it means that the information is not available.  In these cases, you would not expect to see anything else.  I.e. ‹code nullFlavor=UNK/› means you do not know the information which would be otherwise be conveyed by the attribute.
You cannot claim that an ManfuacturedMaterial/code@nullFlavor=anything other than INV or OTH and include ManfuacturedMaterial/code@code,  ManfuacturedMaterial/code@codeSystem,  ManfuacturedMaterial/code@valueSet or ManfuacturedMaterial/code/translation.  Only in cases where  ManfuacturedMaterial/code@nullFlavor= {INV|OTH|UNC} would you use ManfuacturedMaterial/code@origionalText .
You can state ManufacturedMaterial/code@code@nullFlavor=OTH, and specify the ManufacturedMaterial/code@codeSystem (and if relevant, you could also convey the value set) where the code could not be found.  In the current datatypes/vocab, the correct nullFlavor when a proper code isn’t available in the source vocabulary is either OTH or INV.
I don’t recall if C-CDA (sorry, I am not where I can look it up) is still using the datatypes r1, where the only valid  ManufacturedMaterial/code@code@nullFlavor is OTH.  If you think there is a code in the code system, you need to look it up and use it, or just send the original text and state ManufacturedMaterial/code@code@nullFlavor=UNC.  There isn’t a use case to send a coded value where you would assert that you are too lazy, or care so little that you are understood, that you couldn’t be bothered to look something up.  The code either exists in the code system or it doesn’t. It either exists in the value set or it doesn’t.  There isn’t any such thing as “I think there is a proper code”.  Just send original text and hide your shame.
If the non-allowed concept doesn’t come from the required value set, you have two choices:  say  ManfuacturedMaterial/code@nullFlavor=OTH and then just provide the code and code system, or just drop the value set information (i.e. don’t assert membership in the value set) and don’t use an exceptional value at all.  It will depend on the particulars of the template whether or not you need a value set assertion.  If there is not any valid concept from any code systems at your disposal, then ManfuacturedMatieral/code@nullFlavor = INV/OTH, and just supply the original text.  As mentioned, you could use the  ManfuacturedMatieral/code@code@nullFlavor plus the code system to say which code system it could not be found in, but don’t send any translations in this case.  Since this is only used with CNE, you really are not   If the non-allowed code wasn’t in the value set, you would never say the ManfuacturedMaterial/code@code is OTH|INV and supply it as a translation.  That is only done if the code isn’t in the code system. It never makes sense to say MaufacturedMaterial/code@code@nullFlavor=UNK.  Use INV or OTH.  UNC is the only other relevant nullFlavor value (it would not make sense to assert code.code = NI—you can do this on the RIM attribute, but as mentioned before, nothing else would be included.  You just leave it out.
In the examples below, saying MaufacturedMaterial/code@nullFlavor=UNK means the sender doesn’t know what type of manufactured material was involved.   Nothing else can be conveyed in MaufacturedMaterial/code.
Saying MaufacturedMaterial/code@nullFlavor=NI means you have no information.  Nothing else can be conveyed in MaufacturedMaterial/code.
You[r] example MaufacturedMaterial/code@code@nullFlavor=OTH isn’t valid, since you didn’t supply a code to go with the code system—both are mandatory, i.e. MaufacturedMaterial/code@code@nullFlavor.  Any time you use a CD datatype, you must either send a code plus code system, or leave both out.   So you could make the expression valid by adding MaufacturedMaterial/code@code@nullFlavor=OTH (you would only do this if you wanted to be explicit which code system you couldn’t find the code in, but it seems duplicative, as this is only done when CNE, so there is a pretty good change the recipient either knows what should have been sent or they don’t care).   In most cases you would just say MaufacturedMaterial/code@nullFlavor=OTH and send a valid, but non-allowed code + code system and/or original text.  You can include translations to other code systems as you fancy.  If   MaufacturedMaterial/code@nullFlavor=OTH, you only include the original text, or some non-allowed code + code system, or both.  But you have to commit to one of the these three valid options. NOTE:  You only do this when binding is CNE.  If it is CWE, then you do not use OTH, you just send the code/code system of your choice.  In general, I would suggest that for coded values, it would be clearer to assert MaufacturedMaterial/code@code@nullFlavor=OTH only when there was a choice of code systems or when you wanted to send something else in the translation along with the original text, rather than MaufacturedMaterial/@code=OTH (In this case you would send the non-allowed code and code system, and any translations would be translations of the non-allowed code into other code systems, perhaps in hope that the recipient under stood one of them, although a phone call may be more effective).
If you don’t send a valid code (i.e. you say what code + code system), don’t send a translation.  There may be an exception:  if you really want to provide translations of a non-existent code into another code system(s) (i.e. you are effectively saying I could not find the code in this code system, but the concept that the code would have represented, had it been there, would be translated as such) and there is some ambiguity in the CNE specification which would make this useful to say which code system a valid code could not have been located.  I don’t think this is a very good practice, but couldn’t find anything that said it was prohibited.   It may be permissible to assert MaufacturedMaterial/code@code@nullFlavor=OTH and still include translations, and there may be an edge case to use it, but in general, this isn’t a good practice.  (Lloyd?  Looking for some help here.  Is this even allowed?  I couldn’t find anything that said it wasn’t.)  I suppose if you wanted to say MaufacturedMaterial/code@code@nullFlavor=OTH and MaufacturedMaterial/code/translation@code= 74964007, @codeSysstem=2.16.840.1.113883.6.96, @displayName=other I wouldn’t get too dyspeptic.  Regardless, unless both MaufacturedMaterial/code@code and MaufacturedMaterial/code@codeSystem are both present, you cannot send translations.
Regards,
Kevin


Subject: RE: Uncoded medication
From: "Brian Weiss" ‹brian.weiss@cdapro.com›
Date: Wed, 12 Jun 2013 09:00:01 +0300
X-Message-Number: 1

Kevin,
I didn’t really think I was using this list as a “proof reading and tutorial service” or as a sounding board for complaints.  I was sensitive to the fact that the amount of volume I was generating on the list might not be welcome, which is why I set up a separate Google Group for working on my samples.
Keith asked a question about uncoded medication.  It seems that even some of the folks who are past the “proof reading and tutorial service” stage were struggling a bit to crystallize the XML syntax for C-CDA that is required by MU2 when faced with the scenarios outlined (Keith’s original, and some additional ones that Lisa ably outlined better than I did earlier).  I actually thought I was adding value here (as did a few others – though they also may be suffering from some of my obvious deficiencies).
Though  I know I’m not worthy or qualified to critique one as erudite and significant a physician as yourself, might I humbly suggest to his worthiness, that after the competent, capable, properly versed folks here complete their discourse and summary – it might be beneficial to take a page out of my plebian playbook and actually provide the correct XML samples for the scenarios we outlined?  With similar humility and recognition of the unreasonableness of further wasting your time, might I also suggest that if those examples don’t pass the TTT validator and/or are not unambiguously guided to by the C-CDA IG, it might behoove you and your fellow Olympians to ensure that suitable errata and defects are suitably registered, on the, perhaps remote (but nonetheless not entirely unfathomable) possibility that, otherwise, compatriots of mine amongst the unwashed masses might fail to get it right in the future?
J
Seriously, I get where you are coming from.  I accept a lot of your critique.  I think it’s a bit over-stated, but I can appreciate that the level of novice-level errors I make as I participate here can be frustrating/annoying.   On the flip side, if you cut through some of that noise, I think we’re addressing some non-trivial things here (and Lloyd’s reply to you, highlights that even for the folks with much more experience and knowledge, this stuff is not so easy).  I will try to work harder to improve my signal-to-noise ratio on this listserv.  In my experience, public listservs are what they are… and they can get noisy… the good news is that you can always quickly see that an e-mail originates with me and just delete it without reading it.
The counter-critique here from me, having been paying close attention to the listserv for almost a year, is that there is a tendency here to leave the debate at the level of the model and theory and not adopt the required (in my view) rigor of translating the theory into XML examples.  Yes, RIM and CDA are much, much more than C-CDA MU2 requirements, but I think you have to understand and accept that the floodgates are opening.  HL7 and its leaders such as yourself should be very proud that you have advanced things to this stage – but success has its price.  Being adopted by the US government as a mandated standard with billions of dollars indirectly tied to it, changes things.
It’s legit to try set the bar where you and other HL7 leaders want to set it for participation in this listserv.  It’s SDWG’s listserv and its leadership should decide what does and doesn’t belong here. The world won’t end if I am barred from further participation (just ask me nicely, and I’ll go away, though I would like to ask for a refund on my quite steep HL7 membership dues in that case). But if there’s a notion that everyone is going to be signing up for Lantana’s CDA Academy, attending HL7 WGMs, and reading through the RIM foundational materials, as a pre-requisite for working on MU2-certified products or otherwise working effectively with C-CDA…  that dog won’t hunt.
I really do respect and appreciate what you have done, and are continuing to do, to make HL7 and its standards work.  That is ultimately much more important than my view of things, and my preferences.  No hard feelings on my end – I hope none we can’t overcome on yours…
Thanks,
Brian

On Mon, Jun 10, 2013 at 12:50 AM, Brian Weiss ‹brian.weiss@cdapro.com›
wrote:
Tom and Lloyd,
Thanks so much for stepping up on this.
I want to remind us collectively that in addition to Keith's use-case below (which may be a great fit for "OTH") we also have the use-case of "No Information Available".  I think nullFlavor="NI" is the only way to capture that without giving the erroneous impression that there is more information here than that.
Adding anything to the nullFlavor="NI" by definition adds no value (since there is no information and thus nothing more to really say).  So, it's just down to meeting guidance and passing validators.  Right now, the practical combination required in most caess is to add in codeSystem.  So, that is
what we are currently doing in our samples.  Should the ultimate guidance flowing form this thread (or otherwise) be different, we will adjust.
Brian


On Jun 10, 2013, at 12:32 PM, Lloyd McKenzie ‹lloyd@lmckenzie.com› wrote:

Technically, there's no semantic difference between sending an instance with null flavor of NI and sending an instance where the attribute/element is omitted.  "NI" is the default interpretation for all missing data.
--------------------------------------
Lloyd McKenzie