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.

Friday, August 2, 2013

Unclear on the Concept

I've been thinking about Concept Domains, and the Concept Domain Binding syntax in HL7, and how that applies to IHE's refactoring of its profiles to accommodate the CDA Consolidation guide.  A recent exchange on the Structured Documents workgroup list had me really scratching my head.  It had to do with interactions between allowed subtypes of Null Flavor on a data element, based on the coding strength associated with the concept domain binding to a value set.  Essentially if the concept domain indicated that the value set being used was CWE (coded with exceptions allowed), then nullFlavor='OTH' would never be needed, to represent a code using another coding system, but if CNE (coded with no exceptions).

My head hurt just thinking about it.

Now, lets add in the idea of MIN and MAX, where MIN specifies the set of values that all systems must support, MAX specifies the set of values that all systems could support, and ignorable and all that.  (This information can be found in Core Principles).

Clearly my head is about to explode. And if my head is about to explode, clearly there have already been some major aneurysms elsewhere in the Health IT world.

I get that the way to describe all the possible cases is important to vocabularists, but what I don't get is WHY implementations need the capability to bind using ALL possible variations.  What is the use case for MIN/MAX/IGNORED?  Why do I need all this complexity?

I don't see a need for specifying this at a regional or national (or multinational) level.  Systems that are implementing an actor (IHE)/application role (HL7) need to support the specified vocabulary without error. If you say the vocabulary is some dynamic subset of RxNORM, then in each interaction, both players must behave well in the presence of a valid code, and in cases where there is some dispute about the status of a valid code (for example, one of the systems hasn't applied the latest updates).

An implementable specification certainly needs to be written to the level of detail where you know what vocabulary terms will cause a system response, which may be stored but otherwise ignored, and what is acceptable.  However, for regional, national or multinational implementations (e.g., HIE), it seems that the most reasonable way to express vocabulary is by what actor pairs produce/consume within the context of an interaction.

From an IHE Profile perspective, the distinctions of MIN/MAX seem to be overkill, and in the CDA Harmonization efforts, I'm simply ignoring them.  Assume that MIN = MAX and IGNORED = the null set. In terms of  CWE/CNE Coding Strength, the key point is that implementations must be able to support CNE and a specified value set.  In the real world, those value sets may be expanded upon in an implementation or for a project (and could remain CNE but with a new value set).  Specifying CWE in an IHE profile is basically saying, and you are free to ignore the vocabulary binding if you want.  So, there is no point in having the constraint if it can be ignored, so we won't use CWE either.

Thus, we will bind to a value set in the profile, and that is how it will be tested and what a declaration of conformance (known as an integration statement) means.  We don't expect these value-set bindings to be fixed in code, but rather to be configurable in product, so that implementations can adjust them as needed.

So, binding syntax?  We don't need no binding syntax.  I'm pretty clear on that concept.