The CDA Book is SHIPPING from Amazon! See here for Errata.

Tuesday, July 27, 2010

Moving from C32 Version 2.3 to 2.5

Updated 12/15/2010 to provide an example for uncoded, and added examples for value elements. 
Just for fun, I'm going to pretend that you have ignored my recommendation to use HITSP C32 Version 2.5, and are using an older version, like C32 Version 2.3. Maybe you had 2.3 already implemented, and were waiting to see what happened to meaningful use before you piled on more work. So, now you want to know what you need to do to make the switch?

Moving to V2.4

Fortunately, it's not really all that difficult. Between version 2.3 and version 2.4, the big change was the introduction of C83 (CDA Content Modules) and the harmonization of HITSP Section and Entry templates across HITSP Components. Some HITSP specifications (like C28, C38 and C48) used IHE Profiles, others (like C84) used Health Story/HL7 Implementation Guides, and others (like C32), just used straight CCD. Making the shift between Version 2.3 and 2.4 was basically a matter of replacing the ...88.11.32.xx template identifiers with the ...88.11.83.yy template identifiers (where xx == yy in almost all cases), and adding a few IHE template identifiers. Here are the major changes you need to make:

In the CDA Document

Where you had:
‹ClinicalDocument ...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.1 '/›
   ‹templateId root='2.16.840.1.113883.10.20.1 '/›
You would add the following:
‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.6'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.1.1'/›
   ‹templateId root='2.16.840.1.113883.10.20.3'/›

In the CDA Header

Where you had...
‹languageCommunication›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.2'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.2'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.1'/›

Note: You could remove the template 2.16.840.1.113883.3.88.11.32.2, but need not, and this pattern follows throughout for the 88.11.32.xx templates.

Where you had...
‹participant...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.3'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.3'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.4'/›
Where you had...
‹performer...›
   ‹templateId root='2.16.840.1.113883.3.88.11.32.4'/›
Add...
‹templateId root='2.16.840.1.113883.3.88.11.83.4'/›
   ‹templateId root='1.3.6.1.4.1.19376.1.5.3.1.2.3'/›

In Sections

For each of the sections below, add the specified templates to either the section or the entry
Section NameIn this CCD SectionAdd these Section TemplatesIn this C32/CCD EntryAdd these Entry Templates
Insurance
Providers		2.16.840.1.113883.10.20.1.92.16.840.1.113883.3.88.11.83.101.1
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.7		2.16.840.1.113883.3.88.11.32.5
2.16.840.1.113883.10.20.1.20		2.16.840.1.113883.3.88.11.83.5.1
1.3.6.1.4.1.19376.1.5.3.1.4.17
Allergies2.16.840.1.113883.10.20.1.22.16.840.1.113883.3.88.11.83.102
1.3.6.1.4.1.19376.1.5.3.1.3.13		2.16.840.1.113883.3.88.11.32.6
2.16.840.1.113883.10.20.1.27		2.16.840.1.113883.3.88.11.83.6
1.3.6.1.4.1.19376.1.5.3.1.4.5.3
Problems2.16.840.1.113883.10.20.1.112.16.840.1.113883.3.88.11.83.103
1.3.6.1.4.1.19376.1.5.3.1.3.6		2.16.840.1.113883.3.88.11.32.7
2.16.840.1.113883.10.20.1.27		2.16.840.1.113883.3.88.11.83.7
1.3.6.1.4.1.19376.1.5.3.1.4.5.2
Medications2.16.840.1.113883.10.20.1.82.16.840.1.113883.3.88.11.83.112
1.3.6.1.4.1.19376.1.5.3.1.3.19		2.16.840.1.113883.3.88.11.32.8
2.16.840.1.113883.10.20.1.24		2.16.840.1.113883.3.88.11.83.8
1.3.6.1.4.1.19376.1.5.3.1.4.7
Product2.16.840.1.113883.10.20.1.532.16.840.1.113883.3.88.11.83.8.2
1.3.6.1.4.1.19376.1.5.3.1.4.7.2
Advance
Directives		2.16.840.1.113883.10.20.1.12.16.840.1.113883.3.88.11.83.116
1.3.6.1.4.1.19376.1.5.3.1.3.35		2.16.840.1.113883.3.88.11.32.13
2.16.840.1.113883.10.20.1.17		2.16.840.1.113883.3.88.11.83.12
1.3.6.1.4.1.19376.1.5.3.1.4.13.7
Immunization2.16.840.1.113883.10.20.1.62.16.840.1.113883.3.88.11.83.117
1.3.6.1.4.1.19376.1.5.3.1.3.23		2.16.840.1.113883.3.88.11.32.14
2.16.840.1.113883.10.20.1.24		2.16.840.1.113883.3.88.11.83.13
1.3.6.1.4.1.19376.1.5.3.1.4.12
Vital Signs2.16.840.1.113883.10.20.1.162.16.840.1.113883.3.88.11.83.119
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.2		2.16.840.1.113883.3.88.11.32.15
2.16.840.1.113883.10.20.1.31		2.16.840.1.113883.3.88.11.83.14
1.3.6.1.4.1.19376.1.5.3.1.4.13.1
Result2.16.840.1.113883.10.20.1.142.16.840.1.113883.3.88.11.83.122
1.3.6.1.4.1.19376.1.5.3.1.3.28		2.16.840.1.113883.3.88.11.32.16
2.16.840.1.113883.10.20.1.31		2.16.840.1.113883.3.88.11.83.15.1
1.3.6.1.4.1.19376.1.5.3.1.4.13
Procedures2.16.840.1.113883.10.20.1.122.16.840.1.113883.3.88.11.83.108
1.3.6.1.4.1.19376.1.5.3.1.3.12		2.16.840.1.113883.10.20.1.292.16.840.1.113883.3.88.11.83.17
1.3.6.1.4.1.19376.1.5.3.1.4.19
Encounters2.16.840.1.113883.10.20.1.32.16.840.1.113883.3.88.11.83.127
1.3.6.1.4.1.19376.1.5.3.1.1.5.3.3		2.16.840.1.113883.3.88.11.32.17
2.16.840.1.113883.10.20.1.21		2.16.840.1.113883.3.88.11.83.16
1.3.6.1.4.1.19376.1.5.3.1.4.14
Comment2.16.840.1.113883.3.88.11.32.12
2.16.840.1.113883.10.20.1.40		2.16.840.1.113883.3.88.11.83.11
1.3.6.1.4.1.19376.1.5.3.1.4.2


Moving to V2.5

The major change affecting C32 going from version 2.4 to 2.5 were modifications supporting the meaningful use code sets. If you had already supported the HITSP code sets use in C32 Version 2.3, this didn't really effect you as a producer. As a consumer of C32 Version 2.5, there was a significant change related to coded content. For many of the C32 entries, there was one and only one allowed code system, and if you included the ‹code› element, you used the required code system. In Version 2.5 the requirements were clarified. There are two ways to use ‹code› or the CD data type in ‹value›

  1. Coded data using required vocabularies.
    In this case, the code and codeSystem attributes are required on ‹code› and contain the codes in the required code set. So, for problems, if you used SNOMED-CT, you'd do something like the following: 
    ‹code code='57054005' codeSystem='2.16.840.1.113883.6.96'/›
‹value xsi:type='CD' code='57054005' codeSystem='2.16.840.1.113883.6.96'/›
  2. Coded using other than required vocabularies
    In this case, the nullFlavor attribute is required. If coded using other than the required vocabulary, the alternate code goes in ‹translation›, and the code and codeSystem attributes of the ‹translation› identify the code using an alternative coding scheme.  And if you used ICD-9-CM for problems, you'd do something like the following: 
    ‹code nullFlavor='UNK'›
  ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
‹/code›
‹value xsi:type='CD' nullFlavor='UNK'›
‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
‹/value›
  3. Not coded at all again requires nullFlavor:
    ‹code nullFlavor='UNK'/›
‹value xsi:type='CD' nullFlavor='UNK'/›
Which brings us to the final table of this post, which tells you what OIDS to use and where to put the codes you are using:

Coded ItemVocabularyOIDCode/Translation
ProblemsSNOMED CT2.16.840.1.113883.6.96C
ICD-9-CM2.16.840.1.113883.6.103T
MedicationsRxNORM2.16.840.1.113883.6.88C
NDC2.16.840.1.113883.6.69T
MDDB (Medispan)2.16.840.1.113883.6.162T
MMSL (Multum)2.16.840.1.113883.6.175T
NDDF (First DataBank)2.16.840.1.113883.6.208T
MMX (MicroMedex)2.16.840.1.113883.6.176T
MSH (MeSH)2.16.840.1.113883.6.177T
NDFRT (VHA National Drug File)2.16.840.1.113883.6.209T
SNOMED CT2.16.840.1.113883.6.96T
Lab TestsLOINC2.16.840.1.113883.6.1C
ProceduresCPT-4*2.16.840.1.113883.6.12C**
ICD-9-CM2.16.840.1.113883.6.104***C**

Notes:
*HCPCS is made up of CPT-4 and several other vocabularies. This is just the OID for CPT-4, I'm still digging into the remainder.
**C32 Version 2.5 does not have a preferred vocabulary for procedures, so any code system can be used in the code element
***ICD-9-CM Procedures uses a different OID than ICD-9-CM Diagnoses, this is NOT a mistake

Warning: These aren't necessarily all of the changes that you will need to make to your application, but it does cover the largest ones.
Share | | |
Posted by Keith W. Boone at 2:21 PM Labels: , , , ,

20 comments:

  1. Corey SpearsJuly 30, 2010 at 3:00 PM

    Thanks for posting this Keith, I am sure a lot of people are inquiring. One point I would like to mention is that per C32 the Medication translation code is already purposed to hold the Coded Brand Name (R2).

    ReplyDelete
  2. CauthonOctober 1, 2010 at 4:30 PM

    This comment has been removed by the author.

    ReplyDelete
  3. CauthonOctober 1, 2010 at 11:37 PM

    Is it just me, or is 2.16.840.1.113883.10.20.1.14 incompatible with 1.3.6.1.4.1.19376.1.5.3.1.3.28?

    HL7 CCD Result section groups <observation />s with an <organizer /> IHE PCC omits <organizer /> and requires e<procedure />.

    This, in my mind, is a major part of moving to v2.5.

    ReplyDelete
  4. Keith W. BooneOctober 2, 2010 at 3:23 PM

    These are NOT incompatible business rules. Neither rejects what is said by the other, and both can be used together. Remember that "contains" need not be DIRECT containment, and that any prohibition in either specification are always explicit.

    In CCD, template 2.16.840.1.113883.10.20.1.14 says the Result Organizer template ( 2.16.840.1.113883.10.20.1.32) SHOULD be present in the section.

    In IHE, this section requires a procedure entry to identify the diagnostic procedure/lab test performed.

    Admittedly, the PCC TF could be a bit more explicit about how to pull this all together, and the example it gives could use some work. Feel free to suggest a change proposal to the PCC Technical Committee at pcctech@googlegroups.com

    ReplyDelete
  5. CauthonOctober 4, 2010 at 10:15 AM

    In re-reading CCD Result over the weekend, I agree, they're not mutually exclusive. One source of my initial perspective is that PCC Coded Results is one of the few sections that don't claim a CCD parent.

    I expect that most producers and consumers of v2.3 have an organizer element, and will have to do more than just add the PCC OID to reach v2.5. The HITSP examples posted on the NIST validator site clearly didn't get that.

    I think the PCC may need some refinement, as the HL7 Organizer offers me value in grouping procedures and observations. For CCD, my preference is for each observation to optionally reference a Procedure entry (preferably in the Procedures section)

    ReplyDelete
  6. CauthonOctober 5, 2010 at 1:07 PM

    .//cda:templateId[@root = "1.3.6.1.4.1.19376.1.5.3.1.4.19"]'

    Contains, not directly contains. I get it. Thanks for setting me straight.

    ReplyDelete
  7. Grahame GrieveOctober 6, 2010 at 6:02 PM

    hi Keith

    > Coded using other than required vocabularies
    > In this case, the nullFlavor attribute is required.

    > ‹code nullFlavor='UNK'›
    > ‹translation code='410.9' codeSystem='2.16.840.1.113883.6.103'/›
    > ‹/code›

    This is not correct. In this case, you must use nullFlavor="OTH" not "UNK. And you also must provide the codeSystem

    Grahame

    ReplyDelete
  8. CauthonOctober 9, 2010 at 5:53 PM

    This thread proves my first few interpretations are normally wrong, however C83 2.0 section 1.4.3 deals with this and suggests the use of UNK. UNK is more accurate than OTH to me. C83 also doesn't require the codingSystem when the code is unknown (e.g. C83-[DE-8.13-CDA-2]). However I agree with you, codingSystem should have been required.

    Consider the case of C83 data elements 8.13 and 8.14 which are both available and both coded in NDDF. The cda:code element for manufacturedMaterial has two translations (one RxNorm for Brand, one NDDF for Generic).

    Medication's generic name in NDDF:
    cda:manufacturedMaterial/cda:code[@nullFlavor='UNK' and @codingSystem='2.16.840.1.113883.6.88']/translation[@codingSystem='2.16.840.1.113883.6.208']/@code

    Medication's brand name in NDDF:
    cda:manufacturedMaterial/cda:code[@nullFlavor='UNK' and @codingSystem='2.16.840.1.113883.6.88']/translation[@nullFlavor='UNK' and @codingSystem='2.16.840.1.113883.6.88']/@code/translation[@codingSystem='2.16.840.1.113883.6.208']/@code

    You possibly can get away without @codingSystem on the RxNorm code locations, but it's much less clear.

    ReplyDelete
  9. Keith W. BooneOctober 10, 2010 at 2:10 PM

    Graham,

    If I remember correctly, nullFlavor='UNK' means I don't know the code and nullFlavor='OTH' means I know the code doesn't fit into this vocabulary. This case most closely resembles the case of I don't know the code.

    Keith

    ReplyDelete
  10. Grahame GrieveOctober 11, 2010 at 12:31 AM

    Keith, yes, you remember correctly, and UNK is the correct flavor in that case. But you case appeared to describe both cases - including "the code isn't in this system", which was what I was asked about with regard to this port. This exchange can stand as appropriate clarification

    ReplyDelete
  11. AnonymousNovember 15, 2010 at 7:52 PM

    Why is CCD such a PITA? where are the samples? I need to see samples...

    ReplyDelete
  12. Keith W. BooneNovember 15, 2010 at 8:39 PM

    CCD ships with a carefully crafted example. John Halamka published a CCD example on his blog, with his own data. The C83 document from HITSP has plenty of sample content. The NIST CDA Validator folks produced some excellent examples here: http://xreg2.nist.gov/cda-validation/downloads.html

    Anything else in particular you want, or should I just gift-wrap that up for you?

    ReplyDelete
  13. AnonymousDecember 2, 2010 at 6:55 PM

    Hi Keith ,
    Can you post the sample CCD?.

    ReplyDelete
    Replies
    1. John P.June 17, 2015 at 4:18 PM

      I found some in a google search that seem somewhat legit:

      https://github.com/chb/sample_ccdas/

      Delete
  14. AnonymousDecember 2, 2010 at 6:57 PM

    How do we implement allergen groups in CCD i.e If a person is allergic to all penicillins i.e an allergen group how do we get the rxnorm code and use it in CCD.

    ReplyDelete
  15. AnonymousDecember 15, 2010 at 12:37 AM

    Is procedure entry mandatory
    for results?

    I am using

    still it doesnot pass through NIST validation.

    ReplyDelete
  16. AnonymousDecember 29, 2010 at 2:55 PM

    You must watch out trying to validate against just the CDA schemas when using a C32 document. C32 declares extensions which live in a different namespace and are not included in the CDA thus the validation fails.

    CCD isn't the PITA , CDA is the root of this evil. CDA appears to have been crafted by a bunch of grad school meta data weenies that have never had to implement anything and live in the theoretical . CDA is one of those big band type ideas where it's suppose to solve everything. The problem is Big Bangs are usually just a mess and never work out correctly because you cant think of everything up front, period.

    CDA reminds me of the Evel Knievel snake river canyon jump. The Sky cycle was cool and all this work was done up front and everything was thought of in advance so it was perfect. Thing is he never made it over the canyon and the Sky Cycle ends up being a twisted pile of crap in the end, much like the CDA.

    Here's hoping the greenCDA can make this abomination at least somewhat sensible.

    ReplyDelete
  17. AnonymousFebruary 25, 2014 at 11:53 AM

    What OID should I use for ICD-10-CM under "Problems"? Google wasn't helpful so I decided to post my queries here. Thanks very much in advance!

    ReplyDelete
  18. John P.June 17, 2015 at 3:41 PM

    It looks like : 2.16.840.1.113883.6.3

    ReplyDelete
  19. AnonymousJuly 21, 2017 at 11:55 AM

    Probably a really old archive question, but where can I find an example HITSP C32 document which illustrates the use of the Medications Administered section (Template ID 2.16.840.1.113883.3.88.11.83.115)?
    Sounds crazy but I'm troubleshooting a really old interface and would like a good example how Medications Administered would be represented.

    ReplyDelete

Subscribe to: Post Comments (Atom)