PART ONE: Introduction & Meaning vs. Reasoning

The HL7 Consolidated Clinical Document Architecture (C-CDA) Release 2 ballot received an unprecedented 1,000+ comments. A number of those comments include proposals to tighten various constraints within the document. Although tightened constraints sometimes are necessary, they may also represent bad spec design in the form of a “conformance drift,” a situation in which increasingly restrictive conformance verbs are applied to truly optional elements thus idealizing one implementation of the spec to the exclusion of others.

Avoiding unnecessary tightening of constraints

The notion that C-CDA is used exclusively within the Meaningful Use (MU) certification space and the patient transfer situation is incorrect. Because of this, truly optional elements that are required in MU and certain large-scale implementations of C-CDA (think of the most vocal health systems/vendors) undergo a conformance drift. This leaves out smaller hospitals and vendors implementing the same spec who have no need for nor capability to capture these non-essential elements. More importantly though, is the fact that C-CDA is re-used in a number of implementation guides (IGs)—QRDA, NHSN HAI, HIV/AIDS Reports, etc. Unnecessary tightening of constraints erodes the IGs’ capability to extend to other use cases as a parent spec.

Meaning vs reasoning

I agree that some measure of constraint tightening is warranted and even desirable as the spec matures and more users agree that certain elements are required. However, the main problem of conformance drifting is that it disregards the reason why conformance verbs are applied. The meaning of conformance verbs has been explained well (i.e., SHALL = requirement/error, SHOULD = recommendation/warning, MAY = optional element). However, I’ve not seen the reason for these verbs properly explained. Here’s what I have surmised by working with these specs:

SHALL—Is used when an element is an essential subcomponent of a concept or an essential business process piece. For example:

• A Medication Activity cannot exist as a concept without communicating the medication being administered. Thus the consumable is a SHALL within the substanceAdministration of the Medication Activity.
• Likewise a CCD (conceptually) is a document that by consensus is known to have certain sections—Meds, Problems, Labs, etc. Without those sections it would not be considered a CCD. Thus each of those sections is bound by a SHALL.
• However, not all Medication Activities require a maxDoseQuantity to maintain the integrity of the concept that a certain medication was given. Thus, however good it is that we include a maxDoseQuantity it should not be bound by a SHALL. If it is very desirable to have, it should be recommended (i.e., SHOULD) and if it only adds peripherally important information it should be optional (i.e., MAY).
• In the same vein, Immunization Medication Information lotNumberText is a great piece of information to have—but it is not an essential subcomponent of the concept here (the Vaccine Details). For example, if a patient walks into clinic with documentation that he has received a tetanus jab last month, does it really matter that it came from lot 11688 as opposed to lot 11689? This information may be very useful if a vaccine batch is later found to be contaminated but these sort of doomsday scenarios should not distract from the fact that the Immunization Medication Information is primarily for recording vaccines received, not for averting vaccine crises.

SHOULD/MAY—These conformance verbs indicate subcomponents of a concept that are recommended (SHOULD) or simply useful (MAY). Both verbs indicate optionality but can be supplemented by additional explanation in the template description or on the constraint itself.

Stay tuned for PART TWO: Some Arguments Towards Constraint Tightening