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.
Hi Keith - splitting this into two to fit within your limits.
ReplyDeleteI agree that not all situations are going to require all of this complexity, but some *do*. If the conformance profile defines only a max and no min, then that means the system can comply if it only supports one or two codes - or even none. At the international level, that may be the best we can do in terms of consensus. But as you get closer to implementation, there's often a need to declare a certain minimum set of codes that *must* be supported.
The use-case for Ignored is to differentiate between the set of codes you don't support, but won't break the communication exchange (because you'll silently ignore them) vs. those you don't support that will cause you to actively reject the instance (there are use-cases where that needs to happen and others where the system design is "un-graceful"). The distinction makes a big difference in figuring out if two systems will play nicely together out-of-the-box and how much, if any, customization/transformation of the instance will be necessary to make exchanges work.
Ignoring MIN/MAX at the International level (CDA, IHE, etc.) is quite reasonable. Ignored should be exceptionally rare in any standard at all - it's primary purpose is for implementation profiles - "this is what I support, this is what I can accept but will ignore, and everything else will trigger an error".
Part 2:
ReplyDeleteCWE does **NOT** say you're free to ignore the vocabulary binding. If you have a CWE binding, you **MUST** use the specified codes for the provided concepts. However, it's legitimate to use other codes/original text when you encounter concepts not covered by the base value set. It makes good sense for things like diagnosis codes, drug codes, procedure codes, etc. You want standardization on the common codes. So you'll force RXNorm for drugs or SNOMED for procedure or diagnosis codes. However, you also recognize that new diagnosis, procedures, drugs, etc. show up on a regular basis and might need to be captured faster than the underlying code systems/value sets will evolve. And thus you allow original text/local codes in those situations.
If someone sends a custom code for "broken arm" rather than the SNOMED code, when an appropriate SNOMED code exists in the value set, that system is non-conformant - CWE or CNE. On the other hand, if you send a custom code or original text for "arm began growing pink and green-striped fur" (I'm assuming there's no code for that in SNOMED, but being proven wrong wouldn't be a huge surprise :>), then you're conformant if the binding is CWE, but would have to send a null flavor of OTH if the binding is CNE.
So the real difference between CWE and CNE is whether you're going to force a null flavor for exceptions. Allowing null flavors means you can't mark the element as mandatory, and there are cases where you want to do that - you want to say it can't be "Unknown" or "Not applicable" or any of those others - and thus can't be "Other" either. However, it's also an indication to systems of whether they should expect there to be exceptions. CWE says "not everything is going to be covered in this value set". CNE says "everything *should* be covered in this value set, and if it isn't, something weird is going on".
As for binding syntax, you *definitely* need a binding syntax, even if you choose to constrain it to a simplified one. There's a number of places in the various CDA implementation guides where the interpretation of the MAY, SHOULD, etc. verbage is ambiguous. Different implementers make different assumptions, as do those crafting the validation tools. Having a single, clear, consistent syntax for defining bindings eliminates that problem. You can choose to not use parts of the syntax if you don't need some of the more sophisticated parts. You can declare "We will only specify MAX bindings" "We will only use CWE bindings" "We will only use version-agnostic bindings" or any other constraints that simplify what information you need to express. So long as those constraints are declared up front, then clarity is retained and the syntax needed in the IGs is simplified. But saying you don't need a syntax says that you're comfortable with the mess that exists now - and I really hope you aren't.
Not comfortable with the mess, but would prefer something a lot simpler.
DeleteOnce you've got a complete syntax, you can simplify to exclude those bits that you deem irrelevant in context by either prohibiting their use or declaring them to be fixed. If you can't do either of those things, then it's complexity you need and will have to live with - "as simple as possible, but no simpler . . ."
DeleteI get it. I think that's what I did in IHE.
Delete