Where do I find the Medication Generic Name in a CCD Document

The answer is, it depends on your CCD version:

CCDA 2.1 has this to say:

 4. SHALL contain exactly one [1..1] manufacturedMaterial (CONF:1098-7411).
     Note: A medication should be recorded as a pre-coordinated ingredient + strength + dose form (e.g., “metoprolol 25mg tablet”, “amoxicillin 400mg/5mL suspension”) where possible. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack).

     1. This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.4 DYNAMIC (CONF:1098-7412).

         1. This code MAY contain zero or more [0..*] translation, which MAY be selected from ValueSet Clinical Substance urn:oid:2.16.840.1.113762.1.4.1010.2 DYNAMIC (CONF:1098-31884).

CCDA 1.1 has this to say:

 4. SHALL contain exactly one [1..1] manufacturedMaterial (CONF:81-7411).
     Note: A medication should be recorded as a pre-coordinated ingredient + strength + dose form (e.g., “metoprolol 25mg tablet”, “amoxicillin 400mg/5mL suspension”) where possible. This includes RxNorm codes whose Term Type is SCD (semantic clinical drug), SBD (semantic brand drug), GPCK (generic pack), BPCK (brand pack).

     1. This manufacturedMaterial SHALL contain exactly one [1..1] code, which SHALL be selected from ValueSet Medication Clinical Drug urn:oid:2.16.840.1.113762.1.4.1010.4 DYNAMIC (CONF:81-7412).

         1. This code SHOULD contain zero or one [0..1] originalText (CONF:81-7413).

             1. The originalText, if present, SHOULD contain zero or one [0..1] reference (CONF:81-15986).

                 1. The reference, if present, SHOULD contain zero or one [0..1] @value (CONF:81-15987).

                     1. This reference/@value SHALL begin with a '#' and SHALL point to its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1) (CONF:81-15988).

         2. This code MAY contain zero or more [0..*] translation (CONF:81-7414).

             1. Translations can be used to represent generic product name, packaged product code, etc (CONF:81-16875).

HITSP C32 has this to say (you can actually find this in the HITSP C83 specification):
2.2.2.8.13 Free Text Product Name Constraints
C83-[DE-8.15-CDA-1] The product (generic) name SHALL appear in the <originalText> element beneath the <code>

It's pretty clear that the preferred way to handle this changed in between CCD 1.0 (HITSP C32) and CCDA 1.1, and also that some critical information loss occurred with regard to how to record generic name between CCDA 1.1 and 2.1.  I think as industry understanding of CDA expanded, the need to express the detail about generic name probably changed, but not necessarily for the better.

If you want to include generic name, you would do it in a translation -- when you don't already list the drug using an RxNORM code from the Semantic Clinical Drug value set (generic codes) (e.g., you use a Semantic Branded Drug code).

I have two statements to make about this:

1. Not all implementers are informaticists or would understand the distinction between types of RxNorm codes.  We (HL7) need to remember to speak to who is doing the work, not to ourselves.
2. Brand and Generic information is already represented as relationships embedded in the RxNorm terminology itself.  The simultaneous transmission of a brand code and a generic code for that same drug simply repeats what is already present in RxNorm.  The advice I give these days would be to trust RxNorm before you trust your trading partner, and if what your trading partner tells you CONFLICTS, someone needs to go raise a red flag about inconsistent data.

   Keith

The Longitudinal Identity of a CCD

This question comes up from time to time. For a given patient, how is there a unique identifier which uniquely identifies the CCD for the patient as it evolves over time.

The answer is no, but to understand that, we need to talk a little bit about identifiers in CDA and how they were intended to be used.

Every CDA released into the wild has ONE and only ONE unique identifier by which it is uniquely known to the world.  That is found in /ClinicalDocument/id.  During the production of a clinical document, there are some workflow cases where the document has to be amended or corrected.  And so there is a need to identify a "sequence" of clinical documents, and possibly even to assign that sequence an identifier.  The CDA standard supports this, and you can find that in /ClinicalDocument/setId.

BUT... that field need not be used at all.  You can also track backwards through time using /ClinicalDocument/relatedDocument/parentDocument/id to see what previous version was revised.  And the standard requires neither of these fields to be used in any workflow.

So ... couldn't I just use setId to track the CCD for each patient?

Yes, but fundamentially, you'd be doing something that fails to take into account one of the properties of a ClinicalDocument, and that is context.  Context is the who/where/what/when metadata associated with the activity that the clinical document is reporting on.  When setId is the same for two clinical documents, the assumption is that the Context associated with the content is the same, OR, is being corrected, not that it is being changed wholesale.

The episode of care being reported in a CCD is part of its context, as is the when the information was reported.  If you want to report on a different episode of care, it's not just a new document, it's also a new context.  And that's why I suggest that setId should be different.

This is mostly a philosphical debate, rather than one related to what the standard says, but when you think about the history of clinical documents, you might agree that it makes sense.

Clinical Documents aren't "living" documents.  A key definition of a CCD document is a summary of relevant and pertinent data "at a point in time."  It's that "point in time" part of the definition that makes the CCD document a static item.

Where do they go? Insurance ID Cards and CCD & CCDA

I've gotten a few questions lately about the CCD and C-CDA Payers Section.  This is an vastly underutilized section in most implementations, but could have great value in Patient to Provider communication, as it could eliminate the most annoying, costly (to get wrong), and possibly error-prone part of the registration process.

You know that part where they ask for your insurance card.

Below are some samples of insurance cards.

There are at least four and sometimes more identifiers on these cards, and they all identify different things.  They are usually printed in fairly small type, with 8pt type being fairly common for the less important identifiers, and 6pt type on the back being fairly common for the list of phone numbers you need to call for different things.  There's often no bar code or magnetic stripe (I guess it's not in the payers best interest for these cards to be usable).

There are identifiers for the policy, which is often labeled "Group Number".  This represents the identifier for the policy covering the healthcare activity.  Then there's an identifier for the policy holder, usually called the subscriber identifier.  But that gets confusing because some plans also call that the policy-holder's member number.

Then there's the member id (or member number).  That identifies the family member being covered, and is usually the subscriber-id followed by a sequence number.  Some plans use -1 for the subscriber, -2 for the spouse, and then children as -3 to -n in birth order.  Others alphabetize by first name (as mine did).  That makes my eldest daughter -2, my wife -3, and my youngest daughter -4.

Following that, there could be one or more plan identifiers.  These are the identifiers for the specific kind of insurance plan that you have.  They represent a particular kind of insurance plan, and from what I can tell, are managed by state insurance regulators.  It's not uncommon to have a separate plan covering your regular care (e.g., ambulatory), and a separate plan for hospitalization.

OK, got that?  Now, what about the payer ID?  There isn't one yet, but I expect after the regulations pass and every payer has an identifier, you'll find that there as well.

Some cards also double as Pharmacy Benefit Management cards.  Those will have two additional numbers on them, called RxBIN and RxGRP, which are routing numbers used to identify how to communicate with the PBM (effectively identifiers for the PBM).

When we built CCD, we started from a coverage model developed by the HL7 Financial Management workgroup.  That model appears below:

Within CCD and C-CDA, there are three templates defined:
The Coverage Activity template represents the list of policies (or programs like CHIP, Medicaid, et cetera) that provides coverage to the patient.  It contains one or more policy or program activities which describe one component of the coverage.  These can be sequenced (really prioritized) by the sequenceNumber field in the act relationship.
The policy activity has an identifier.  This is the "policy number" or "group number" associated with the policy or program covering the patient.

The plan act defines the policy and is where you'd put the plan identifier.


The covered party is the patient.  The identifier associated with them is where you put the member id.

The responsible party is the "policy holder", and is where you would put the subscriber id.

Finally, the Payer is who actually makes the payment, and is where you'd put the PBM routing numbers, or payer ids when those become available.

The HITSP C83 specification goes into great detail on this section of the CCD, explaining where the content goes.  At the end of this post, you can find a full example that has been pieced together from various examples in that document.

The C-CDA follows a similar pattern.  You should be able to cross-walk the templates yourself using the template map in the appendix of C-CDA.

  -- Keith


<act classCode='ACT' moodCode='DEF'>
  <templateId root='2.16.840.1.113883.10.20.1.20'/>
  <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.17'/>
    <id root=''/>
    <code code='48768-6' displayName='Payment Sources' 
      codeSystem='2.16.840.1.113883.6.1' codeSystemName='LOINC'/>
    <statusCode code='completed'/>
    <!-- Example 1, A health plan -->
    <entryRelationship typeCode='COMP'>
      <sequenceNumber value='1'/>
      <act classCode='ACT' moodCode='EVN'>
        <templateId root='2.16.840.1.113883.10.20.1.26'/>
        <templateId root='2.16.840.1.113883.3.88.11.83.5'/>
        <id root='2844AF96-37D5-42a8-9FE3-3995C110B4F8'
          extension='GroupOrContract#'/>
        <code code='IP' displayName='Individual Policy' 
          codeSystem='2.16.840.1.113883.6.255.1336' 
          codeSystemName='X12N-1336'/>
        <statusCode code='completed'/>
        <performer typeCode='PRF'>
          <!-- This examples assume an RxBIN of 699999 and an RxPCN of PZZZZ -->
          <assignedEntity classCode='ASSIGNED'>
            <id root='2.16.840.1.113883.3.88.3.1' extension='699999'/>
            <id root='2.16.840.1.113883.3.88.3.1.699999' extension='PZZZZ'/>
            <addr>…</addr>
            <telecom value='…'/>
            <representedOrganization classCode='ORG'>
              <name>…</name>
            </representedOrganization>
          </assignedEntity>
        </performer>
        <!-- Example 2, The patient is a dependent of the subscriber -->
        <participant typeCode='COV'>
          <time>
            <low value='20070209'/>
          </time>
          <participantRole classCode='PAT'>
            <id root='…' extension='MEMBERID#'/>
            <code code='DEPEND' displayName='dependent' 
              codeSystem='2.16.840.1.113883.5.111'  codeSystemName='RoleCode'/>
            <playingEntity>
              <name><given>Baby</given><family>Ross</family></name>
              <sdtc:birthTime value='20070209'/>
            </playingEntity>
        </participant>
        <participant typeCode='HLD'>
          <participantRole classCode='IND'>
            <id root='…' extension='SUBSCRIBERID#'/>
            <playingEntity>
              <name><given>Meg</given><family>Ellen</family></name>
              <sdtc:birthTime value='19600127'/>
            </playingEntity>
        </participant>
        <entryRelationship typeCode='REFR'>
          <act classCode='ACT' moodCode='DEF'>
            <id root='2844AF96-37D5-42a8-9FE3-3995C110B4FA' extension='PlanID'/>
            <code code='HMO' displayName='health maintenance organization policy' 
              codeSystem='2.16.840.1.113883.5.4' codeSystemName='ActCode'/>
            <text>Health Plan Name</text>
          </act>
        </entryRelationship>
      </act>
    </entryRelationship>
</act>

A Dual Compatible CCD

On Wednesday I talked about template versioning.  This morning's post I'm going to expand on how to create a CCD 1.0 that is also a CCD 1.1.

Wes Rishel's Asynchronous Bilateral Cut-over applies here. The rationale for doing this is to enable systems which only understand the CCD 1.0 to understand your newer documents as well as best they can.

Normally, when you create a new version of a template, you would do so in a way that was backwards compatible with the old template.  That is to say, that none of the constraints in the new template would violate the constraints of the old template.  That's just not possible with some of the CCD 1.1 templates, because certain 1.1 templates violate constraints of the 1.0 templates.

So, the question is: How do  you create a document conforming to a particular template in such a way as to support systems that understood older versions and newer versions of the same template. But when you have a two versions which aren't compatible with each other (such as the CCDA Problem Act and the CCD Problem Act), what would you do?

One possible solution is to present the content using both versions of the template. This takes advantage of the "indirect containment rule".  In CCD, certain templates SHALL/SHOULD/MAY contain other templates.  But containment needn't be direct.  That was implicit in CCD 1.0, in the IHE PCC Technical Framework, and in the HITSP C32 (because it relied on those specifications).  This means that to meet the "contains" constraint, a template may be a descendant rather than a direct child of another template.

What we want to be able to do is represent the same content twice using two different versions of the same template. Because the templates are dealing with the same concept, we should be able to assume that the later version is functionally compatible as the earlier version, even if not "wire format" compatible. If they are functionally compatible, then one should be able to transform the newer template into the older format.  Note, that in doing so, it is possible that you could lose some information that isn't supported in the older version. The older version can be created via a transform, derived from the newer version. Given that there is some data loss, you could also consider it an an excerpt from the newer template. Transform (XFRM), derived (DRIV), and Excerpt (XCRPT) are all act relationship types in CDA R2.

So, to represent a CCD 1.1, in a way that was also interpretable as a CCD 1.0, you would include the "wire format" incompatible older templates as being excerpts of the newer template versions.  The example below shows the general structure that you would use.

<entry>
  <act ...>
    <templateId root='newTemplateId'/>
      ...
    <entryRelationship typeCode='XCRPT'>
      <act ...>
        <templateId root='oldTemplateId'/>
          ...
      </act>
    </entryRelationship>
  </act>
</entry>

When the entry templates require containment of other templates, you wind up creating a parallel structure under the first excerpt.

Because of the functional equivalences between the two templates, it should also be possible to create a transform from the CCD 1.0 template to its CCD 1.1 successor (and vice versa).  Developing such transforms isn't necessarily an academic exercise.  It allows systems which understood CCD 1.0 to be used with systems that generate only CCD 1.1, or alternatively, allows systems which generate a CCD 1.0 to be able to generate CCD 1.1 without significant retooling.

Moving on from HITSP C32: Medications

I’m going to continue rolling with this while I can.  I had hoped to stage a few posts to go out while I'm on vacation, but I messed up my calendar, so I'll probable be writing some of this from my mother's house next week (after everyone else is asleep).  I'm thinking about putting this together with some other stuff and building a CCDA Quick-start guide, so while it's cutting into "personal" time, it's also become a personal pet project.  And that material would also be useful for Edition 2 of the CDA Book (which is still quite a ways off, I have two other book ideas to execute on first).   Before I get started on medications, I have a couple of notes for you:

Use the Change History!

Starting at page 522 of Version 1.1 of the CDA Consolidation guide (which was put up on the HL7 DSTU site in July), and going on for about 35 pages is the updated change log.  That  log covers changes to the templates in the problems, medications, results, vital signs and procedures sections and their templates IN DETAIL.  I missed this in my review of the drafts (and in producing these posts).  It's been in the published DSTU that was put out in December of last year as well.  You should definitely make use of it.  I’m covering the essentials to get you up and running faster, but you’ll need look into the details.

Version 2.0? 

If you looked at the HL7 Ballot site (which opened last week), you were probably surprised to see CCDA 2.0 being balloted now.  So were the co-chairs, and the lead of the project who's ballot was supposed to be published under a different title.  It will eventually fold into the CCDA Brand/Product Line, but not yet.  We still have to figure how often to roll that up.

---

Enough rambling, time to get on with it:

Following up after problems and allergies is medications.  The impact of CCDA on your medications section is going to be quite similar to the impact of CCDA on problems and allergies sections.

Medications Section

The key change in your code for the section will be to change the template identifiers, and any contained entries.

<section>

       <templateId root="2.16.840.1.113883.10.20.1.8"/>

       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.19"/>

       <templateId root="2.16.840.1.113883.3.88.11.83.112"/>

       <templateId root="2.16.840.1.113883.10.20.22.2.1"/>

       <templateId root="2.16.840.1.113883.10.20.22.2.1.1"/>

       <id root="41399049"/>

       <code code="10160-0" codeSystem="2.16.840.1.113883.6.1"
              codeSystemName="LOINC" displayName="History of medication use"/>

       <title>…</title>

       <text>…</text>

    <entry>…</entry>

</section>

Medications Entry

The medications entry has numerous possible subcomponents, each of which has its own set of changes which I’ll detail separately.   The example below comes from the NIST Robust CCD example.  In it, they’ve included optional content (in both CCD and CCDA), which I’ve marked in italics.  If you have it, it’s a good idea to send it, but neither specification requires it.

<substanceAdministration classCode="SBADM" moodCode="INT">

       <templateId root="2.16.840.1.113883.3.88.11.83.8"/>

       <templateId root="2.16.840.1.113883.10.20.1.24"/>

       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7"/>

       <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.1"/>

       <templateId root="2.16.840.1.113883.10.20.22.4.16"/>

       <id root="cdbd33f0-6cde-11db-9fe1-0800200c9a66"/>

       <text>

              <reference value="#SIGTEXT_1"/>

       </text>

       <statusCode code="completed"/>

       <effectiveTime xsi:type="IVL_TS">

              <low value="200507"/>

              <high nullFlavor="UNK"/>

       </effectiveTime>

       <effectiveTime xsi:type="PIVL_TS" institutionSpecified="false" operator="A">

              <period value="6" unit="h"/>

       </effectiveTime>

       <routeCode code="C38216" displayName="Respiratory (Inhalation)"
              codeSystem="2.16.840.1.113883.3.26.1.1" codeSystemName="NCI - FDA RouteOfAdministration">

              <originalText>

                     <reference value="#MEDROUTE_1"/>

              </originalText>

              <translation code="IPINHL" codeSystem="2.16.840.1.113883.5.112"
                     codeSystemName="HL7 RouteOfAdministration" displayName="Inhalation, oral"/>

       </routeCode>

       <doseQuantity value="2" unit="puffs"/>

       <administrationUnitCode code="C42944" displayName="Inhalant"
              codeSystem="2.16.840.1.113883.3.26.1.1" codeSystemName="NCI - FDA Dosage Forms">

              <originalText>

                     <reference value="#MEDFORM_1"/>

              </originalText>

       </administrationUnitCode>

       <consumable>

              … see Consumable below …

       </consumable>

       <entryRelationship>

              … see the various subcompnents which follow Consumable …

       </entryRelationship>

</substanceAdministration>

Consumable

This is where you put the drug information.  What you do here hasn’t changed much except for the templates.

       <consumable> … see consumable below …

              <manufacturedProduct>

                     <templateId root="2.16.840.1.113883.3.88.11.83.8.2"/>

                     <templateId root="2.16.840.1.113883.10.20.1.53"/>

                     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.7.2"/>

                     <templateId root="2.16.840.1.113883.10.20.22.4.23"/>

                     <!-- Product template -->

                     <manufacturedMaterial>

                           <code code="307782"

                                  displayName="Albuterol 0.09 MG/ACTUAT inhalant solution"

                                  codeSystemName="RxNorm" codeSystem="2.16.840.1.113883.6.88">

                                  <originalText>

                                         <reference value="#MEDNAME_1"/>

                                  </originalText>

                           </code>

                           <name>Albuterol Inhalent</name>

                     </manufacturedMaterial>

              </manufacturedProduct>

       </consumable>

Over-The-Counter vs. Prescription

In the HITSP C32, we had created a template that allowed one to show whether a medication on the medication list was a prescription, or over the counter.  If you used this template in your CCD, you can continue to use it, but it is not included in CCDA (so many systems will just ignore it).

       <entryRelationship typeCode="SUBJ">

              <observation classCode="OBS" moodCode="EVN">

                     <templateId root="2.16.840.1.113883.3.88.11.83.8.1" />

                     <code code="73639000" codeSystem="2.16.840.1.113883.6.96"
                           displayName="Prescription Drug"/>

              </observation>

       </entryRelationship>

Reason for Medication

The “Reason for Medication” component of the medications entry simply referenced the “Problem” template in the HITSP C32.  In CCDA, there is a new template that duplicates the common content of Problem, now called indications.  Use of this template is optional in both HITSP C32 and CCDA.  If you are a fan of analytics, understanding why a patient is taking a medication (e.g., what problem this is for) is a really good idea.

       <entryRelationship typeCode="RSON">

              <!--Reason for Med-->

              <observation classCode="OBS" moodCode="EVN">

                     <templateId root="2.16.840.1.113883.10.20.1.28"/>

                     <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

                     <templateId root="2.16.840.1.113883.10.20.22.4.19”/>

                     <id root="cdbd5b08-6cde-11db-9fe1-0800200c9a66"/>

                     <code displayName="Condition" code="64572001"
                           codeSystemName="SNOMED-CT" codeSystem="2.16.840.1.113883.6.96"/>

                     <text>

                           <reference value="#SIGTEXT_1"/>

                     </text>

                     <statusCode code="completed"/>

                     <effectiveTime>

                           <low value="20000328"/>

                     </effectiveTime>

                     <value xsi:type="CD" code="56018004" displayName="Wheezing"
                           codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT"/>

              </observation>

       </entryRelationship>

Medication Status

The medication status observation tells you about whether this medication is active or not.  It exists in HITSP C32 (from CCD), but no longer appears in CCDA.  There were three interesting states in this template:  Active, No Longer Active, and On Hold.  Prior History is the last code allowed for, and in this context, more than likely means “No Longer Active”.   You can still use it if you want inside a medication, but because it is no longer in CCDA, it isn’t clear that you need it.  The first effectiveTime associated with the medication gives the start and stop date for the medication.  You don’t need to know Active/No Longer Active if those are used correctly (although On Hold is still an interesting case).  If you do continue to use this template, I’d stick with the first three SNOMED CT codes on output, but accept the fourth on input.

       <entryRelationship typeCode="REFR">

              <!--To Identify Status-->

              <observation classCode="OBS" moodCode="EVN">

                     <templateId root="2.16.840.1.113883.10.20.1.47"/>

                     <code code="33999-4" displayName="Status"

                           codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"/>

                     <value xsi:type="CE" code="55561003" displayName="Active"

                           codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">

                     </value>

              </observation>

       </entryRelationship>

patientInstructions and fulfillmentInstructions

Patient instructions, such as Take with food, consume all this medication, and similar phrases often appear on prescriptions, and are additional directions to the patient.  Fulfillment instructions refers to directions to the pharmacist with regard to formulation or delivery of the medication.   

Both of these properly go with the order information, rather than the substance administration intent/event.  In CCDA, these two different templates were replaces with the singular Instructions template, and so this is just a templateId swap.  That same template is also used with other instructions given to the patient, e.g., education, and the value set of codes recommended (but not required, so you can keep your existing codes) reflects that.

<entryRelationship typeCode='SUBJ' inversionInd='true'>

       <act classCode='ACT' moodCode='INT'>

              <templateId root='2.16.840.1.113883.10.20.1.49'/>

              <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.3'/>
              <templateId root="2.16.840.1.113883.10.20.22.4.20"/>

              <code code='PINSTRUCT' codeSystem='1.3.6.1.4.1.19376.1.5.3.2'

                     codeSystemName='IHEActCode' />

              <text><reference value='#patient-instruction'/></text>

       </act>

</entryRelationship>

Order (Rx) Information

The order information template doesn’t appear in the NIST example, so I’ve modified the HITSP C32 example to show what’d you’d do with that.  This template can appear inside the medication entry, and reflects information about the order for the medication.

The id element is where you’d put the providers medication order number that they transmitted to the pharmacy.  CCDA recommends that the effectiveTime be included and that it be placed in the <high> element, which is a change from HITSP C32.  The author of the supply order is the prescriber.

<entryRelationship typeCode='REFR'>

<supply classCode='SPLY' moodCode='INT'>

              <templateId root='2.16.840.1.113883.3.88.11.83.8.3'/>

              <templateId root='1.3.6.1.4.1.19376.1.5.3.1.4.7.3’/>

              <templateId root="2.16.840.1.113883.10.20.22.4.17"/>

              <id root='14ED7742-2428-4e2c-9446-A9B0D0075272' extension='SCRIP#'/>

              <effectiveTime xsi:type="IVL_TS">

                     <high value="20121012" />

              </effectiveTime>

              <statusCode code="completed"/>

              <repeatNumber value="1"/>

              <quantity value="75"/>

              <product>

                     <manufacturedProduct>

                           <templateId root="2.16.840.1.113883.10.20.22.4.23"/>

                           … See consumable above …

                     </manufacturedProduct>

              </product>

              <author>

                     <time value='20070210'/>

                     <assignedAuthor>

                           <id …/>

                           <assignedPerson>

                                  <name>…</name>

                           </assignedPerson>

                     </assignedAuthor>

              </author>

       </supply>

</entryRelationship>

Medication Dispense

The HITSP C32 used the same template, but set moodCode to EVN to indicate that the <supply> is for a dispense (or fill).  In CCDA, you use pretty much the same content (XML-wise) as the Order Information, but a different templateId: 2.16.840.1.113883.10.20.22.4.18

The dispense should always appear inside the order (because if it was dispensed, you should have the order information).  And order information should appear inside the medication entry (because that’s the way to link the SIG (dose, route, frequency) to the bottle of pills (or other package) that should be provided to the patient, and if you have the order, you should know what to put on its label.

Subcomponents I haven’t Covered

Medication orders are complicated and can have a lot of information.  Here are some of the items I didn’t review.

Medication series number

Little (if ever) found in a HITSP C32, this was the series indicator in a medication that was given in multiple does.  It isn’t used in CCDA.

vehicle

This template in the HITSP C32 was used to document an inactive ingredient used to aid transmission of the medication to the patient (e.g., saline).  I’m not aware of a single system that ever used it.

reaction

If there was an adverse reaction to the medication, it is recorded in this subcomponent.  This uses the same adverse reaction template as I described yesterday in allergies.  So, really, I did cover it, just not in this post.

-- Keith

P.S.  Thanks to all of you who voted for me for the HL7 Board, especially on Monday.  I'll let you know how the election results come out in September (when we all get them).

Moving on from HITSP C32: The CCDA Problems and Allergies Section

Continuing from yesterday’s post, I’ll look at what you need to do with the problems section.  And because Allergies are a specialization of problems, and the changes are related, I’ll do that section as well.

This one is the most challenging, because the new problem concern isn’t backwards compatible with the HITSP C32 version.  It means that you cannot create something that is both a CCD 1.0 and a CCD 1.1 at the same time.

The Problem Section

Adjusting the section is just a matter of swapping out template identifiers.  It is actually the entries within the section that need further alteration.

In the problem section, remove the templateId elements that have been struck out, and add the ones in bold and underline.

<component>

   <section>

      <templateId root="2.16.840.1.113883.10.20.1.11"/>

      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.6"/>

      <templateId root="2.16.840.1.113883.3.88.11.83.103"/>
      <templateId root="2.16.840.1.113883.10.20.22.2.5"/>

      <templateId root="2.16.840.1.113883.10.20.22.2.5.1"/>

      <code code="11450-4" codeSystem="2.16.840.1.113883.6.1"

         codeSystemName="LOINC" displayName="PROBLEM LIST"/>

      <title>PROBLEMS</title>

      <text> … </text>

      <entry> … </entry>

   </section>

</component>

The Allergy Section

Just as in the problems section, the allergies section will also require swapping out identifiers, and the real focus is on the entries.

<component>

   <section>

      <templateId root="2.16.840.1.113883.10.20.1.2"/>

      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.3.13"/>

      <templateId root="2.16.840.1.113883.3.88.11.83.102"/>

      <templateId root="2.16.840.1.113883.10.20.22.2.6"/>

      <templateId root="2.16.840.1.113883.10.20.22.2.6.1"/>

      <code code="48765-2" codeSystem="2.16.840.1.113883.6.1" codeSystemName="LOINC"
         displayName="Allergies, adverse reactions, alerts"/>
      <title>PROBLEMS</title>

      <text> … </text>
      <entry> … </entry>

   </section>

</component>

The Problem Concern

In the CCD 1.0 and HITSP C32 (and the IHE templates in between), the “Problem Concern” did double duty, representing the “Concern” act for both problems and allergies.  In the CDA Consolidation Guide, this act was split into two different templates, one to address problems, and the other to address allergies.  Structurally, they are very similar.  We’ll take on the changes for problem first:

<act classCode="ACT" moodCode="EVN">
   <templateId root="2.16.840.1.113883.3.88.11.83.7"/>

   <templateId root="2.16.840.1.113883.10.20.1.27"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.2"/>

   <templateId root="2.16.840.1.113883.10.20.22.2.5"/>

   <id root="6a2fa88d-4174-4909-aece-db44b60a3abb"/>

   <code nullFlavor="NA"/>

   <code code="CONC" codeSystem="2.16.840.1.113883.5.6"/>

   <statusCode code="completed"/>

   <effectiveTime>

      <low value="1950"/>

      <high nullFlavor="UNK"/>

   </effectiveTime>

   <entryRelationship
      typeCode="SUBJ" inversionInd="false">

   <observation classCode="OBS" moodCode="EVN">

      <templateId root="2.16.840.1.113883.10.20.1.28"/>

      <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5">
      <templateId root="2.16.840.1.113883.10.20.22.4.4"/>

         …

   </observation>

</act>

As you can see, the “breaking change” was for the <code> element, and a different template for the problem observation. 

The Allergy Concern

Moving on now to allergies, again, what changed was <code> and the use of a different template for the allergy observation. 

<act classCode="ACT" moodCode="EVN">

   <templateId root="2.16.840.1.113883.3.88.11.83.6"/>

   <templateId root="2.16.840.1.113883.10.20.1.27"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.1"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5.3"/>

   <templateId root="2.16.840.1.113883.10.20.22.4.30"/>

   <id root="36e3e930-7b14-11db-9fe1-0800200c9a66"/>
   <code nullFlavor="NA"/>

   <code code="48765-2"

      codeSystem="2.16.840.1.113883.6.1"

      codeSystemName="LOINC"

      displayName="Allergies, adverse reactions, alerts"/>

   <statusCode code="completed"/>

   <effectiveTime>

     <low nullFlavor="UNK"/>

     <high nullFlavor="UNK"/>

   </effectiveTime>

   <entryRelationship typeCode="SUBJ" inversionInd="false">

     <observation classCode="OBS" moodCode="EVN">

         <templateId root="2.16.840.1.113883.10.20.1.18"/>

         <templateId root="2.16.840.1.113883.10.20.1.28"/>

         <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

         <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.6"/>

         <templateId root="2.16.840.1.113883.10.20.1.18"/>

         <templateId root="2.16.840.1.113883.10.20.22.4.7"/>

        …

     </observation>

   </entryRelationship>

</act>

Problem Observations

Now we move into the problem and allergy observation templates.  Again, I’ll start with the problem observation.  Note that here you need only add the CCD 1.1 template identifier, and don’t have to remove the prior template identifiers because the two templates are compatible (but see my notes below on backwards compatibility).

The same is true for the problem status observation contained inside the problem observation.  Note that HITSP C32 suggested pointing to the problem text in the value element, while CCD 1.1 does not.  It’s still allowed, and gives you a way to textually describe problems which are not coded.

<observation classCode="OBS" moodCode="EVN">

   <templateId root="2.16.840.1.113883.10.20.1.28"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>
   <templateId root="2.16.840.1.113883.10.20.22.4.4"/>

   <id root="d11275e7-67ae-11db-bd13-0800200c9a66"/>
   <code code="64572001" displayName="Condition"
     codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED-CT"/>

   <text>

     <reference value="#PROBSUMMARY_1"/>

   </text>

   <statusCode code="completed"/>

   <effectiveTime>

     <low value="1950"/>

   </effectiveTime>

   <value xsi:type="CD" displayName="Asthma" code="195967001"
     codeSystemName="SNOMED" codeSystem="2.16.840.1.113883.6.96">

     <originalText>

      <reference value="#PROBSTATUS_1"/>

     </originalText>

   </value>
   <!-- Problem Status Template -->

   <entryRelationship typeCode="REFR">

     <observation classCode="OBS" moodCode="EVN">

      <templateId root="2.16.840.1.113883.10.20.1.50"/>

      <templateId root="2.16.840.1.113883.10.20.22.4.6"/>

      <code code="33999-4" codeSystem="2.16.840.1.113883.6.1"
         displayName="Status"/>

      <statusCode code="completed"/>

      <value xsi:type="CE" code="55561003"
        codeSystem="2.16.840.1.113883.6.96" displayName="Active">

      </value>

     </observation>

   </entryRelationship>

</observation>

Allergy Observation

The allergy observation and its subordinate observations are going to require a few more adjustments because of the contained <participant> describing the allergen, and the shifting of the type of allergy from <code> to <value>, among other things.

<observation classCode="OBS" moodCode="EVN">

   <templateId root="2.16.840.1.113883.10.20.1.18"/>

   <templateId root="2.16.840.1.113883.10.20.1.28"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.5"/>

   <templateId root="1.3.6.1.4.1.19376.1.5.3.1.4.6"/>

   <templateId root="2.16.840.1.113883.10.20.1.18"/>
   <templateId root="2.16.840.1.113883.10.20.22.4.7"/>

   <id root="4adc1020-7b14-11db-9fe1-0800200c9a66"/>

   <code code="416098002" codeSystem="2.16.840.1.113883.6.96"
      displayName="drug allergy" codeSystemName="SNOMED CT"/>

   <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>

   <!-- No longer required or recommended in CCDA, but do it anyway -->

   <text>

     <reference value="#ALGSUMMARY_1"/>

   </text>

   <statusCode code="completed"/>

   <effectiveTime>

     <low nullFlavor="UNK"/>

   </effectiveTime>

   <value xsi:type="CD" code="70618" codeSystem="2.16.840.1.113883.6.88"
      displayName="Penicillin" codeSystemName="RxNorm">

      <originalText>

         <reference value="#ALGSUB_1"/>

      </originalText>

   </value>
   <!-- Put what used to go into <code> here -->

   <value xsi:type="CD" code="282100009" 
      displayName="Adverse reaction to substance"

      codeSystem="2.16.840.1.113883.6.96" codeSystemName="SNOMED CT">

   </value>

   <!-- This is pretty much unchanged (and ought to be a template) -->

   <participant typeCode="CSM">

     <participantRole classCode="MANU">

      <playingEntity classCode="MMAT">

        <code code="70618" codeSystem="2.16.840.1.113883.6.88"
          displayName="Penicillin" codeSystemName="RxNorm">

          <originalText>

           <reference value="#ALGSUB_1"/>

          </originalText>

        </code>

        <name>Penicillin</name>

      </playingEntity>

     </participantRole>

   </participant>

   <entryRelationship typeCode="MFST" inversionInd="true">

     <observation classCode="OBS" moodCode="EVN">

      <templateId root="2.16.840.1.113883.10.20.1.54"/>

      <templateId root="2.16.840.1.113883.10.20.22.4.9"/>

      <!-- Reaction observation template -->

      <code code="ASSERTION" codeSystem="2.16.840.1.113883.5.4"/>

      <text><reference value="#REACTION-1"/></text>

      <statusCode code="completed"/>

      <value xsi:type="CD" code="247472004"
        codeSystem="2.16.840.1.113883.6.96" displayName="Hives">

        <originalText>

          <reference value="#ALGREACT_1"/>

        </originalText>

      </value>

      <entryRelationship typeCode="SUBJ">

         <observation classCode="OBS" moodCode="EVN">

           <templateId root="2.16.840.1.113883.10.20.1.55"/>

           <templateId root=" 2.16.840.1.113883.10.20.22.4.8"/>

           <!-- Severity observation template -->

           <code code="SEV" displayName="Severity"
           codeSystemName="HL7 ActCode" codeSystem="2.16.840.1.113883.5.4"/>

           <text><reference value="#SEVERITY-1"/></text>

           <statusCode code="completed"/>

           <value xsi:type="CE" displayName="moderate" code="6736007"
           codeSystemName="SNOMED" codeSystem="2.16.840.1.113883.6.96"/>

         </observation>

        </entryRelationship>

     </observation>

   </entryRelationship>

   <entryRelationship typeCode="REFR">

     <observation classCode="OBS" moodCode="EVN">

      <templateId root="2.16.840.1.113883.10.20.1.39"/>

      <templateId root="2.16.840.1.113883.10.20.22.4.28"/>

      <!-- Alert status observation template -->

      <code code="33999-4" codeSystem="2.16.840.1.113883.6.1"
        displayName="Status"/>

      <statusCode code="completed"/>

      <value xsi:type="CE" code="55561003" codeSystem="2.16.840.1.113883.6.96"
        displayName="Active">

        <originalText>

          <reference value="#ALGSTATUS_1"/>

        </originalText>

      </value>

     </observation>

   </entryRelationship>

</observation>

On Severity

While I showed the severity template above  in the context of a reaction, the CCDA allows that it can also be used for allergies themselves.  And I note that it doesn’t forbid it from being used in problems, it just didn’t suggest it.  I’m suggesting it.  Severity is simply a special kind of annotation on an problem, allergy, or reaction.  Don’t expect it to be present, or supported by all systems, but if you have it, be kind and share it with others.

On Backwards Compatibility

The new templates for problems and allergies are functionally compatible with the HITSP C32 specifications.  In other words, you can say the same things.  In a few cases, they are even wire compatible.  That is to say that you can create XML that would be valid in both the HITSP C32, and the CCD 1.1.  The question to ask yourself though, is whether you want to take that on.  My advice would be to NOT try to retain compatibility in the same package even if it is technically feasible. 

CCDA takes a different enough approach that you’ll run into challenges.  While this series focuses on production, consumption is a completely different story.  You aren’t in control of what you are going to receive, so you have to be able to accept anything that’s valid. 

That means you cannot take a path of least change to adapt your consumer the way that you can for your producer.  So, create a new package for your CCDA Consumer.  You can start with the same code base you used for the HITSP C32, but you’ll be making enough changes that the end result will be quite a bit different. 

And remember, there will be some time when you still have to deal with both, or at least your customers will.  Not everyone will be able to transition on the same day.  You need to allow for asynchronous bilateral cutover.  It is after all, one of the new ABC’s of interoperability.

Caveats

If it says SHOULD, DO IT.  You will thank me later, or at least, your customer or downstream trading partner will.  SHOULD doesn’t mean “avoid this if you can”, it means that this practice is recommended for maximum interoperability.

If you used additional HITSP C32 templates in these observations, LOOK at them!  I cannot cover everything here, and this post is already TL;DR length.  Furthermore, I offer this information for your education.  Please take responsibility for ensuring the accuracy for your own implementations.