What follows is a brief guide to those using CDA to address Meaningful Use Stage 2 requirements ane 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
