Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Monday, October 11, 2010

What the C32 says about translation for Medications

A number of people have asked questions about how to represent medications using coding systems other than the recommended RxNORM values.  The problem stems from interpretation of the C83 specification.  The table below comes from page 51 of C83 Version 2.0.

cda:consumable/
 cda:manufacturedProduct
Medication Information
R/Y
2.2.2.8.10
  cda:manufacturedMaterial/
   cda:code/@code
8.13 - Coded Product Name
R2/Y
2.2.2.8.11
    cda:translation/@code
8.14 - Coded Brand Name
R2/Y
2.2.2.8.12
    cda:originalText
8.15 - Free Text Product Name
R/N
2.2.2.8.13
  cda:manufacturedMaterial/
     cda:name
8.16 - Free Text Brand Name
R2/N
2.2.2.8.14

What the highlighted line says is that the coded brand name is found in the translation element, and is required if known.  We (HITSP Care Management and Health Records) put the medication brand name in translation because for clinical purposes, the concept that would seem to be most important are the active ingredients in the medication (the product), rather than any specific brand name medication.

What is interesting here is the HITSP mapping process.  The concepts (found in C154) were givens (even when C32 was original constructed), and the harmonization task was mapping them onto CDA Release 2.0 and the CCD specification.  That means that our process established where this information belongs in the CDA specification.  But this mapping may not be one-to-one and onto.  That is to say that similar concepts may map into the same location.  An example of where this occurs is in the identification of allergens.  There are several different ways to identify substances to which a patient may have an adverse reaction.  These may be medications, classes of medications, or specific substances that may not even be a medication.  All of these wind up mapping to the same place in the CDA document, and it is the vocabulary that is used that identifies the purpose for which the content is mapped.

So, as it turns out, we have a similar situation with medications.  The interoperable concept we want to exchange is a value set for products from RxNROM, and other codes that may get you to that concept should appear in the translation element.  That means that you can include translations to a brand name code from a separate value set in RxNORM (the value set identifying brand name medications), or you could include translations from other coding systems,  such as First Data Bank, MediSpan or NDC.

When we get to clarify the C83 specification, we should modify it to indicate that translation/@code is to be interpreted as brand name when the value set used is from the RxNORM.

This illustrates the challenge with mappings.  It is only when a mapping is one to one and onto that you can assume that a data element in one place always means what has been mapped to it from another.

2 comments:

  1. as it turns out, we have a similar situation with medications

    ReplyDelete
  2. Hi Keith,

    Quick background of what I am trying to do... I'm trying to parse the HL7 medication RXO or RXE to extract the medication code and name and store that into our exchange repository, also parsing CCD ang store it into our exchange repository.

    When it comes to CCD generation, I am not sure what is the best way to determine if that medication code and name parse from HL7 can be specified in either CCD Medication Coded Product Name or Coded Branded Name. Also when parsing out the Coded Product Name and Coded Branded name from CCD, which code would fit to send out in an HL7 RXO\RXE Give code. Would a terminology service be needed to address this different use cases?

    I have your CDA book and I really find it helpful the mapping it provided for Labs between HL7 messages and CDA.


    Thanks,
    Vivette

    ReplyDelete