TermInfo - CCDA sample for No Immunization administered (email thread)

4 April 2013

Vinayak Kulkarni

• I am looking for an example of "No Immunization Administered". Since we have CVX code fore "No Vaccine Administered" with Code = 998, shall we use it without using negationInd="true"?

Is following sample is a valid example?

<section>
 <templateId root="2.16.840.1.113883.10.20.22.2.2.1"/>
 <code code="11369-6" codeSystem="2.16.840.1.113883.6.1" displayName="History of immunizations" codeSystemName="LOINC"/>
 <title>Immunizations</title>
 <!--**** Immunzations Section Narrative Block ****-->
 <text>
  <paragraph>
   <content ID="ZImmunizations.Immunizations.ORD-PHL02-NO-DATA">No immunizations administered or ordered.</content>
  </paragraph>
 </text>
 <entry typeCode="DRIV">
  <!--**** Immunzations Section Narrative Block ****-->
   <substanceAdministration classCode="SBADM" moodCode="INT" negationInd="false">   
   <templateId root="2.16.840.1.113883.10.20.22.4.52"/>
   <id nullFlavor="NI"/>
   <statusCode code="completed"/>
   <effectiveTime nullFlavor="NI"/>
   <consumable>
    <manufacturedProduct classCode="MANU">
     <templateId root="2.16.840.1.113883.10.20.22.4.54"/>
     <manufacturedMaterial>
       <code code="998" displayName="No Immunization administered" codeSystem="2.16.840.1.113883.12.292" codeSystemName="CVX"/>    
     </manufacturedProduct>
   </consumable>
  </substanceAdministration>
 </entry>
</section>

Lisa Nelson

• Vinayak,

Two things I notice about the sample you provided:

1. The moodCode=”INT” says, the entry is intended or planned. I don’t think that represents the right verb tense for the act. I think you need moodCode=”EVN”. (see table below for options)
2. I prefer to see examples include information in the effectiveTime element. I think you should explicitly think through the effectiveTime element and show if there should be a low or high or both, etc., just to make sure the longitudinal aspect of things doesn’t complicate the analysis.

Finally, I know these issues of semantics always open a large can of worms, but….

I think we have a vocabulary issue here. When the term is not just a clean “noun concept”, the semantics of what we are saying gets really messy and confusing. See how the concept includes the notion of the act (the verb) “baked in”, so to speak. The action concepts of “administered” and “ordered” are acts that I think our CDA architecture intends for us to represent in our act statements. Using the substance administration act already gives us the action concept of “administering a substance”. We have the moodCode attribute to control the verb tense of that action. Now, when we plug in the noun, we really need a term that is free from the other “conceptual clutter” of verbs or timeframes. So, I’m sorry to say, I think the code you are using makes for a problematic clinical statement that is necessarily ambiguous. Am I preaching to the choir, barking up the wrong tree, or being too idealistic in my expectations of what we should be aiming to accomplish with our machine readable data?

This table is from the CDA R2 standard. It shows the moodCode attribute valueSet for CDA R2. Further constraints may be included in specific templates, but this is the initial starter set of possible moodCodes for SubstanceAdministration:

Table 109: Value set for SubstanceAdministration.moodCode (CNE)
Code	Definition
EVN (event)	The entry defines an actual occurrence of an event.
INT (intent)	The entry is intended or planned.
PRMS (promise)	A commitment to perform the stated entry.
PRP (proposal)	A proposal that the stated entry be performed.
RQO (request)	A request or order to perform the stated entry.

Tom de Jong

• Dear Vinayak,

I am not an expert in the modelling of immunizations, but Pharmacy WG and PHER WG have always shared the opinion that we should treat vaccines just like ‘regular’ medicines. Having said that, and please don’t take this personally, the example below is a semantic monstrosity. One thing is clear ‘No Immunization administered‘ is not a manufactured material. You can’t administer ‘No Immunization administered‘ as a vaccine, you can’t even NOT administer it. The proper way to represent this using SBADM is by either using a SBADM.code that represents ‘immunization’ (as a general concept) or having a manufactured material code that represents all vaccines (i.e. ‘vaccine’ as a general concept). The resulting substance administration can then be negated to express that there was no occurrence of an administration of a vaccine (i.e. no immunization).

By the way, this is the same method that was used to represent ‘no known medication’ in the context of C-CDA (at least while I was involved).

I copied PHER WG, since I strongly believe domain-specific concepts should be represented consistently, regardless of the exchange mechanism.

Jean Duteau

• I agree with Tom.

Since you're not asserting that any specific vaccine/immunization did not occur, I would leave out the manufacturedMaterial altogether and just set negationInd to true and possibly use a code in the SBADM to indicate that it was an immunization. The other thing is that the mood needs to be EVN or you are just saying "we do not intend to give any immunizations".

  <!--**** Immunzations Section Narrative Block ****-->
   <substanceAdministration classCode="SBADM" moodCode="EVN" negationInd="TRUE">   
   <templateId root="2.16.840.1.113883.10.20.22.4.52"/>
   <id nullFlavor="NI"/>
   <statusCode code="completed"/>
   <effectiveTime nullFlavor="NI"/>
  </substanceAdministration>

Tom de Jong

• Lisa essentially raised the same point, but explained it in a much nicer way. I forward her response to PHER, because they should be in the loop.

By the way, totally agree that the moodCode should be EVN.

Joginder Madra

• Tom is correct. In POIZ, we would have a substance administration act in EVN mood with code = ‘IMMUNIZ’, statusCode = ‘completed’ and negationInd =’true’. You must additionally specify the date you did not administer as well as the vaccine you did not administer.

Eric Larson

• Hi all-

Just to chime a bit more on CVX code 998. In general, this alone isn't enough information. We generally need to know why and which vaccine. (I see Joginder has also chimed in as I was writing this and we are in agreement).

Code 998 in the V2 2.5.1 IG is used in the RXA segment to indicate a vaccine was not administered, but is followed by one or more OBX segments to explain why an immunization was not administered (immunity, contraindications)

"I didn't administer a vaccine because of history of chicken pox"

"I didn't administer a vaccine because of an allergy to eggs"

While both of these are client level observations the 2.5.1 guide doesn't allow for an OBX under the PID (in a VXU) and the RXA is required. Hence, 998.

The other place 998 is used is to message the forecast (or care plan) for the next date a dose should be administered. This would be similar to the SubstanceAdministrationProposal in C-CDA (I think that's correct)

C-CDA might not need code 998 at all to get the same message across. It's possible C-CDA has better places to convey these types of "non-administrations".

One final piece on non-administration in 2.5.1 (and these are truly non-administrations):

In 2.5.1, a refusal (parental, religious, etc...) of a vaccine are not a 998 situation. The CVX not administered (107^DTaP-NOS) is used in RXA-5 with code for refusal in RXA-20 and the reason for the refusal in RXA-18.

Hope this helps,

Kevin Coonan

• That is really putting a lot of meaning on a very ambiguous, and deprecated (x4 years), attribute, and I am not sure that the meaning is all that clear. It is quite possible that different implementation guides would interpret the meaning differently. You cannot infer what part(s) of the SubstanceAdministration Event is negated.

You don't know if the statement means that it immunization was given some other time (e.g. ten minutes later, i.e. not within the effectiveTime stated), or if it is currently being given (i.e. there is an active SubstanceAdministration Event).

Negating an event isn't the same as saying it didn't happen. Saying that something didn't happen is a positive assertion, and isn't at all what Act.negationInd means. By negating it, you simple say that the particular set of described values. There is an actionNegationInd attribute which should be used, if your choice of code systems doesn't properly support negative assertions.

Per the current RIM:

This attribute was deprecated for future use in HL7 Design Models at the September, 2008 Working Group Meeting, effective with RIM release 0221. The semantics of this attribute have been divided between the new actionNegationInd attribute and the Observation.valueNegationInd attribute. For existing models, designers should examine the model documentation and usage to determine which set of semantics apply. New models and new versions of existing models SHALL NOT use this attribute.

This attribute was removed from the RIM in version 2.38, per Harmonization decision in March 2012. However, subsequent analysis of the result of that step upon CMETs, Wrappers and other shared models that use this attribute led to the conclusion in July 2012 Harmonization that the action was too precipitate. The attribute was returned to the RIM in version 2.40 per Harmonization Action on July 11, 2012. It will be removed in a later version (with Harmonization approval) once a strategy to deal with this removal in existing models has been put in place.

I would encourage that PHER talk with Patient Care and Pharmacy regarding this at the next work group meeting. We need to have some harmonization and review so that immunization content can be properly represented in/between EHRS, pharmacy systems, and public health.

Vinayak Kulkarni

• Thanks to all for your inputs.

Has anybody tested "No Known Medication" scenario from NIST validator? Apperantly it is thowing error which is contradicting with the example shown in the CCDA IG below

Figure 13: No known medications example

<entry>
  <substanceAdministration moodCode="EVN" classCode="SBADM" negationInd=”true”>
    <text>No known medications</text>
    <consumable>
      <manufacturedProduct>
        <manufacturedLabeledDrug>
          <code code="410942007" displayName="drug or medication"
                codeSystem="2.16.840.1.113883.6.96"           
                codeSystemName="SNOMED CT"/>
         </manufacturedLabeledDrug>
       </manufacturedProduct>
     </consumable>
  </substanceAdministration>
</entry>

The NIST validator is expecting manufacturedMaterial/Code or manufacturedLabeledDrug/Code for respective valueset (RxNorm code in case of Medications and CVX code in case of immunizations). When you specify negationInd as "true", I would expect at least it should not fail for SNOMED code on which I am negating on.

Error :

1670|Consol Immunization Medication Information SHALL contain exactly one [1..1] manufacturedMaterial (CONF:9006) manufacturedMaterial SHALL contain exactly one [1..1] code, where the @code SHALL be selected from ValueSet Vaccines administered (CVX) 2.16.840.1.114222.4.11.934 STATIC 7 (CONF:9007)

1552|Consol Medication Information SHALL contain exactly one [1..1] manufacturedMaterial (CONF:7411) manufacturedMaterial SHALL contain exactly one [1..1] code, where the @code SHALL be selected from ValueSet Medication Clinical Drug 2.16.840.1.113883.3.88.12.80.17 DYNAMIC (CONF:7412)

Thanks

Joginder Madra

• Hi Kevin,

I was speaking to an approach within the context of the version of the RIM used by CDA (which does not support actionNegationInd) as the question originated from the Structured Documents list.

For clarity, the Normative POIZ models use actionNegationInd and not negationInd.

Rob Savage

• It is also used to to cover the case where an observation about a person is needed that does not relate to an immunization administered. This is fixed in V 2.8

Jean Duteau

• Unfortunately, Kevin, the CCDA has no recourse to using a newer RIM. Within their context, the best that they can do is use negationInd. I do not believe that there will be any need for a discussion on this point since CCDA can only use what they have at hand. For them, the solution that Joginder has stated is correct and is really the only semantically correct way of asserting that an event did not happen. With the extra information that Joginder has indicated should be provided (the specific date and vaccine), it effectively becomes a positive assertion that "no vaccine of this type was given on this day".

6 April 2013

Kevin Coonan

• Jean,

You are correct. What I apparently didn't elaborate on enough is that this begs for a proper terminology solution. It would be much clearer to assert "vaccine not given" than to negative "vaccine given".

Using negationInd when there is a readily obtainable terminology solution (at least for the IHTSDO pseudorealm) in SNOMED is a problem in CDA r2. Rather than accept it as necessary, I think we will be much better off if we define a good valueset for SubstanceAdministration.code that obviates the need for this awkward (and, as I mentioned, recognized as problematic) attribute. Just because it is the RIM used by CDA r2 doesn't mean that using it is a good idea.

SNOMED-CT has a base concept of 371900001|Medication not administered| which would serve as the parent concept, and it would be a simple matter of defining the 363589002|Associated procedure| attribute's range to be the children of 127785005|Immunization|. This would let you specify which immunization (via the expansion of 127785005|Immunization| to all of its children). We could also just do this in a value set using the right SNOMED-CT expression. 371900001:363589002=127785005 means exactly immunization not given. I would propose that this be used. If implementations will explode with >18 characters or use of non-digit characters it is easy enough to request a 'pr-ecoodinated' concept that means the same. If we do this, we probably would want to expand to a subset meaning "never done", v. "not done at this time" (this is an optional attribute of 371900001|Medication not administered|).

We could even go crazy and 'pre-coordinate' with reasons it wasn't given, e.g. so we can say that 'Varicella Zoster virus vaccine not given at this because the patient is pregnant'. I would actually suggest we don't do this, since adding a 'Reason' ActRelationship to the Clinical Statement ActChoice would give us a lot more flexibility.

William Goossen

• Kevin,

I agree with you on this:

NegationIndicator is the #1 patient safety issue in it.

But the multi pre ordination is too difficult. I would suggest to not even think about handling imperfect terminology solutions where the information model is superior.

14 April 2013

Tom de Jong

• Hi William, Kevin,

I disagree that negating a statement is a patient safety issue, but we’ve been around that loop many times. Fact is that it’s very hard to cover specific negated concepts in a terminology (even SNOMED) without introducing something very similar to a negation indicator. There are as many ‘negative’ statements to make as there are positive (did not get any immunization, did not get this specific vaccine, did not get it this year, etc.).

But even if there is a terminology that captures the most common cases with a specific code (and I’m not contesting that SNOMED does that), there is still the fact that our information models (in both V3 and FHIR) should not be terminology-dependent. They should support the terminology (which the proposed model certainly does), but they should also have a way of negating statements, independent of terminology.

Let´s agree to disagree about the merits of negation (whether it’s CDA R2 style or current RIM style) and accept that both methods can co-exist.

15 April 2013

William Goossen

• Tom,

Lets agree on the clinical requirement for negation of things. (never an issue in our discussion)

Lets agree that it can be met in both terminology and/or information model (we do)

Lets agree that it needs to be handled very precisely and explicit (we do) for patient safety reasons

Lets agree the terminological solution is more difficult due to the option to use of multiple terminologies (I.e. Snomed Ct and / or something else).

Lets agree we prefer some kind of HL7 solution in the information model space (we do, don't we?) .

Lets disagree to the negation indicator in any Act.

I could live with an extensional or explicit modelling of some negation however.

I think we can have an explicit class (OBS or Diagnosis) which says where it is about: e.g. Snomed ct diagnosis from observable entity going into codeCode and Code 1234567890 for disease X going in the value.

To negate we would use a second act serving as modifier to the OBS which states true, expected to be true, NOT TRUE, and more. Our discussion started any years ago. Recently I see the semantic health net ontologists move in this direction of explicitness, which I concur with of course.

So my preferred solution is to have a small cluster for diagnosis with at least one obs with code and value plus a second obs class specifying anything particulars i.e. a modifier to the diagnosis, where modifier does what Stan Huff says: changes the meaning in clinical sense.

Of course we will need more to it, it is just the principle of how to negate with less risks .

The risk is underpinned with the option to have both the negation indicator in an Act on true and a terminology construct with a negator. No_Cancer coming out as valid through the HL7 schema's. (And hence the need to heavily constrain via schematrons).

Rob Hausam

• I'm adding the TermInfo list to this discussion thread. TermInfo has provided specific guidance on negation in the past, in the original TermInfo DSTU, but it is and it has been rather obvious for a while that the existing TermInfo guidance isn't nearly enough. People are either not well enough aware of it, or the guidance is perceived as being too limited in scope (i.e. V3 and SNOMED CT only), or people disagree with the recommendations and prefer to do it a different way - or likely some combination of the above. Plus, the existing TermInfo DSTU itself has now been expired for several years.

In our TermInfo 2 effort we have already decided to provide further guidance on negation, with a broader scope that includes all of the HL7 information model "flavors" (V2, V3, CDA, FHIR). This discussion thread certainly reinforces that something like this is obviously needed. We intend to devote most or all of one of the TermInfo quarters in Atlanta to discussing and trying to progress this, as it is #1 on our current list of "hot topics". We haven't yet determined whether this discussion will be during Q1 or Q2 on Tuesday, but we will do that on the TermInfo call next Wednesday - if you have a preference, please post it to the TermInfo list or otherwise let us know.

I'm interested in the possibility of the "extensional or explicit modelling" that William mentioned, as I don't recall seeing much about that in the past, and it certainly is a possible approach. Whatever we do, though, we should try to be careful to not simply add it into the mix and thereby create one more option that makes it less likely that we will achieve reliable interoperability. These recent (and past) discussions have made me think that possibly what TermInfo should do is work toward creating a new IG (likely DSTU) that focuses specifically on the topic of negation (or possibly negation and uncertainty, as they are closely related) and covers all of the information model "flavors" and addresses both terminology and information model solutions and, to the extent possible, how they can interoperate. I think we would want to target bringing an initial version to ballot relatively quickly (likely one or at most two cycles).

Of course this isn't going to be easy, but we should be able to make some progress that will ultimately be helpful to everyone by bringing some degree of consensus and closure to this issue, and having a particular place where it is documented. I'll put this item on the agenda for the TermInfo call next week. I would like to hear thoughts, pro or con, and of course participation would be most welcome.

William Goossen

• Hi Rob,

Excellent suggestions! I agree to relate it to uncertainty, but we should consider a full range of modifications allowable to a diagnosis. E.g differential, hypothetical, ruled out, the paper that Pieter de Vries Robbe just provided can help to identify the relevant modifications.

Kevin Coonan

• Lets just get a SNOMED code for 'immunization not given'. We can get all sorts of children codes if helpful; e.g. "varicella vaccine not given", "immunization not given due to current acute febrile illness" etc.

Don't make this hard.

Gaby Jewell

• The thing is, we already need to report a ‘negation’ to the state immunization registries, not a SNOMED CT code of “xxxxx not given”.

So in reality, asking the EMR vendor to translate what was documented (vaccine “xxxxx”, status “not given”) to the appropriate SNOMED CT code is making it hard. Asking us to set a negation indicator is easy.

William Goossen

• Hi Gaby, yes easy errors as well.

I have worked on the design of a juvenile care record system which allows to enter a vaccin to the list for a child. Then it can be modified as planned (including date of next visit), given when actually administered, postponed to another visit, or not given (with optional the reason why not given).

That is to me much better than a negation indicator, which in combination with a terminology that also has negating statements, can confuse at in particular the receiving side.