Moving from HITSP C32 to CCD 1.1

This is the first of a series of posts describing how to move from the HITSP C32 required under Meaningful Use to the CCDA specifications.  Since HITSP C32 was a CCD, the plan is to cover how to deal with changes between the HITSP C32 restrictions on CCD, and the HL7 CCDA version of CCD (CCD 1.1).

I'm assuming that you are going to be starting from your existing HITSP C32 implementations to support the new format.  I'm doing this by manually editing the Robust HITSP C32 example provided by NIST, and manually inspecting my changes against the CCD 1.1 specification in the HL7 CDA Consolidation Guide (when there is other testing available, I'll take advantage of that as well).

I’m first going to address the header constraints.  Later posts will address problems, allergies, medications, lab results and procedures sections, and if there is enough demand, I'll get to other sections as well.  You'll be able to find all of these posts under the 2S2 category.

The CCD 1.1 Header

You’ll need to add two <templateId> elements to the existing set under <ClinicalDocument> to conform to the CCD 1.1 Header constraints. 

  <!-- Added for CCDH: CONF:9441 -->

  <templateId root="2.16.840.1.113883.10.20.22.1.1"
       assigningAuthorityName="HL7/CCDA General Header"/>

  <!-- Added for CCDH: CONF:8450 -->

  <templateId root="2.16.840.1.113883.10.20.22.1.2"
       assigningAuthorityName="HL7/CCD 1.1"/>

The “Robust CCD” example from NIST needs no further alterations to be valid for the “CCD Header Constraints”, but we still have yet to deal with the General Header Constraints.  We’ll hit those next.

General Header Constraints

The H&P General Header Constraints were largely adopted in CCDA, but there are a few additional things that you need to worry about:

templateId elements have obviously changed.

The requirements for id, code, and title in the ClinicalDocument have not.

languageCode changes slightly in that the original General Header Constraints specified the nn or nn-CC form, which is still acceptable, but the CCDA allows anything from the valueSet 2.16.840.1.113883.1.11.11526, which is defined by RFC-4646.  That RFC is a bit more forgiving, but most users of it will follow the general nn or nn-CC pattern.

Most of the changes are minor and affect what you can expect in participants in the header:

On addr and telecom

As before, many participants must have an addr and telecom element.  However, the new CCDA header has tighter constraints on what can be present in addr, and looser constraints on telecom.

The tighter constraints on addr ensured that addresses could be stored in information systems without having to parse them:

The address is fielded into streetAddressLine, city, state, postalCode and country elements, where the first two are required, remaining three are recommended.  Non-whitespace text outside of elements inside the <addr> is not permitted. 

For telephone numbers, we had stricter requirements In the original General Header.  We had specified that phone numbers appeared in a constrained form of the tel: URL format.  The older constrained form is described below:

telephone-url = telephone-scheme ':' telephone-subscriber

telephone-scheme = 'tel'

telephone-subscriber = global-phone-number [ extension ]

global-phone-number = '+' phone-number

phone-number = digits

digits = phonedigit | digits phonedigit

phonedigit = DIGIT | visual-separator

extension = ';ext=' digits

visual-separator = '-' | '.' | '(' | ')'

                 

CONF-HP-12: Telephone numbers SHALL match the regular expression pattern tel:\+?[-0-9().]+

CONF-HP-13: At least one dialing digit SHALL be present in the phone number after visual separators are removed.

These constraints are no longer present in the CCDA General header, but are still considered to be best practice in sending phone numbers.  NOTE: If you apply the constraints of the tel: URL from RFC-3966 (or its predecessor RFC-2806) , the lack of a global phone number (a number beginning with a +) requires use of the phone-context= attribute somewhere in the URL, and if you don’t have that, the URL is not correct.  So, the + form is still preferable.

Patients

The administrativeGenderCode and birthTime elements are still required (and administrativeGenderCode still uses the HL7 vocabulary).  The maritalStatusCode, religiousAffiliationCode, raceCode, and ethnicGroupCode elements are still optional (although maritalStatusCode is now recommended.  These use the same vocabularies as was required in the HITSP C32.

Only one <name> element is permitted in the <patient> element.  HITSP C32 allowed multiple names to be present. 

The <name> element in the new general header is now constrained to require being fielded into components for patients, just as was done in the HITSP C32.

Authors

Authors must contain an <id> element that contains their NPI.  This is a new requirement in the CCDA general header, and you will find it in a number of places, starting with the <author> element.  It isn’t clear how you indicate that the author either doesn’t have an NPI (possible) or what to do when the NPI is unknown. 

If you do not have the author’s NPI, I would recommend this form:

<id root='2.16.840.1.113883.4.6' nullFlavor='UNK'/>

And if they do not have one, this form:

<id root='2.16.840.1.113883.4.6' nullFlavor='NA'/>

The first one indicates that you either don’t know the NPI, or it isn’t applicable (in the second one).  HL7 modeling experts will probably hate these choices, but what else should we do?  This is similar to the old how do I say the patient’s phone number is unknown problem that was solved in a similar fashion years ago.

The <name> element can be fielded, like the patient’s name, or it can just be a string containing the full name of the author, but you cannot mix the two as you could have under the HITSP C32 (not that anybody really tried to do that).

If the author is a medical device, you must include both <manufacturerModelName> and <softwareName>.
 

Data Enterer

Data enterers now require an id, address and telephone number (addr and telecom elements), unlike what was required for HITSP C32.  And if you have an NPI for the data enterer, you should include it.  I’m not sure this isn’t a copy and paste error.

Informant

In the HITSP C32, when the informant was an assignedEntity (a healthcare provider), they must have an address (and it is optional for others).  In CCDA, all informants SHOULD have an address, regardless of who they are.  Again, the name must either be fielded, like the patient name, or just a string.

In HITSP C32, an informant that was not a healthcare provider, was restricted to in the kinds of relationships they could have with the patient.  All of those relationships are still permissible, but other types of relationships can also be used.

Information Recipient

In the old general header, if you had an <intendedRecipient> element, you also had to have either an <informationRecipient> or <recievedOrganization>.  In CCDA, neither are required, but if you do that, basically, you might as well have omitted the element.

Legal Authenticator and Authenticator

Ensure that you include <time value='yyyymmdd'/> and <signatureCode code='S'/> in these elements.  A CCDA should have a Legal Authenticator, and may have other authenticators.  The old general header made no recommendations on the presence of the legal authenticator.

That about covers it for this first installment.  Look for future installments over the next few weeks.