I think however that the more critical part of this HIE building project is not in picking a vocabulary and a schema. But rather in defining what is the proper behavior related to metadata and related to content. Specifically what happens when content or metadata doesn’t utilize that vocabulary (e.g. historic information, or from a foreign land). What is the sending responsibility to ‘fixup’ codes? What is the receiving responsibility to be ‘robust’ to deviations? Is there a role for a translation-service? What is the medical-legal meaning of content that has been changed simply to meet some coding restriction?
Using a restricted code system should be guidance, not mandate. Conformance should be measured on ‘creation’ events, not necessarily ‘transmission’. Everyone must be liberal in how they process incoming content. This is fundamental to the success of the Internet and is known as “Postel’s Law” or the “Robustness Principle”. http://en.wikipedia.org/wiki/Robustness_principle
Use-cases like insurance or public-health reporting can get away with this code restriction, as there is little ‘danger’ of a loss of accuracy from a coding translation. This is why it is logical and reasonable for the original intention of HIPAA to define specific and constrained code-sets. This is why it is reasonable for public-health to define a coarse grain vocabulary.
The actual codes maintained in the medical record, the ones that would be used for current and future treatment have not changed and are the code that the doctor or medical-device picked as the best code at the time the code was picked. When making treatment decisions, accuracy is very important. Deviations from original accuracy are not unheard of, but when they happen they are clearly identified as a derivative or a transform or a translation.
XDS has had from the beginning the concept of a restricted c ode-set for metadata, the concept of the “XDS Affinity Domain”. But we always expected the document content to be the original content, unless it was a properly approved “Transform” (a concept also supported by XDS). The dynamic document concept is clearly an exception that could be called out specifically. The codes in the metadata are intended to be ‘meta’, and thus a bit of accuracy loss for the benefit of easier communication (interoperability) is reasonable. This is emphasized very specifically for some metadata, like classCode (the high-level classification of the kind of content), but is also true of more fine grain items like typeCode. Meaning that even typeCode is just a code representing the whole and thus not a complete representation of the whole content. They are both ‘meta’.
Even XDS recognized that this constrained “XDS Affinity Domain” vocabulary will evolve over-time. Meaning as much as you think that you can control the vocabulary today, the future will want to have different constraints. These different constraints can only add concepts. It is possible to deprecate “new use” of old concepts. But the old concepts can’t be forbidden.
It is the concept of ‘forbidden’ that worries me most. Anytime a constrained vocabulary is selected, this ‘implies’ that codes outside that vocabulary are ‘forbidden’. This is an ‘implied’ POLICY. Please don’t make it an implied policy. Please make it an explicit policy, and I suggest that the policy follow the Principle of Internet Robustness; aka Postel’s Law. Be specific in what you send, liberal in how you receive.
When put into the context of a longitudinal record, rather than the context of an instant in time message, the ‘send’ point-in-time is the point at which the content is created, not the point when it is transmitted. Meaning when content is created it should be created using the best vocabulary and schema at that time, and it should be intended to be as conforming as possible. However we must recognize that a document created today, might be needed 10 years from now when the schema or vocabulary have changed. The new rules should not be applied, and any system receiving the content should try as hard as it can to understand the 10 year old content. Sometimes this means that it can’t be fully processed and that the user (clinician) needs to be warned of this.
This is the receive side robustness.
Eating an Elephant -- How to approach IHE documentation on Health Information Exchange (HIE)
