There are several dynamic value sets specified in the Consolidated CDA implementation guide. An example is of an existential value set is the one used with the <subject> element in a family history organizer: FamilyHistoryRelatedSubjectCode 2.16.840.1.113883.1.11.19579. This value set is a subset of codes from the HL7 RoleCode vocabulary, which can be updated annually in the HL7 Version 3 Normative Edition.
While it seems unlikely that this value set would be updated, the possibility not only exists, it has happened.
The underlying code system was updated between the creation of CDA Release 2.0 in 2005 and now. The 2011 Normative Edition contains codes for Maternal Great Grandmother (MGGRMTH), which didn't exist in the 2005 edition that ships with CDA.
Imagine that instead of this happening now, it happened some time during Meaningful Use stage 2 implementation. How would your application deal with this?
The value set used in CCDA is defined intentionally in the HL7 Role Code vocabulary, as being FAMMEMB and all its children, and the binding in CCDA is dynamic, which means that when the underlying vocabulary changes, so does the value set.
What would your system do when it was configured to handle the value set in the older version of the coding system, but you received a document using using a new version of the coding system? Until that system is updated to deal with the latest value set (which may need to wait for a schedule-able maintenance opportunity), you could receive CCDA documents that your system won't recognize as being valid, but you don't want to completely reject the content.
Here is one suggestion:
When validating a CCDA, and finding a code you don't recognize in a CCDA, and the code system is asserted to be the correct one for the dynamic value set: recognize that this code could be a result of a value set update, and provide a mechanism to gracefully:
a) replace it with another known valid code OR
b) store the code given OR
c) both a and b
AND (in both cases)
d) schedule some sort of investigation with respect to the new code.
On output, when your applications sees data using a code NOT known to be valid, use the nullFlavor="OTH" pattern in the code value, indicating that the code does not come from the expected set of values and also, put the code that you do have into a <translation> element.
Your output might look something like this:
<code codeSystem='2.16.840.1.113883.5.111' nullFlavor='OTH'>
<translation codeSystem='2.16.840.1.113883.5.111'
code='MGGRMTH'/>
</code>
In this way, you've preserved the information received, and if it's not part of the expected "Meaningful Use" vocabulary, you haven't output something that's invalid.
The same technique can be used to output codes that were stored historically, but have been deprecated (or replaced with a different code set) since Stage 2 was implemented. For example, suppose that you had stored information for a patient using a 2009 version of SNOMED CT (or LOINC, the vocabulary isn't really important), but since then, the code you have was deprecated. You'd basically generate the same XML:
<code codeSystem=' 2.16.840.1.113883.6.96 ' nullFlavor='OTH'>
<translation codeSystem='2.16.840.1.113883.6.96'code='deprecated-code-value'/>
</code>
I expect some will argue that this isn't a valid representation of the CD data type, or that we should be dealing appropriately with codeSystemVersion. The reality is, there needs to be some way to represent deprecated or updated content in way that indicates what your application knows, and still allows applications to understand where to find the "standard codes". Also, CDA Release 2 doesn't support valueSet and valueSetVersion, which are designed to be enhancements to the CD data type to support these cases.
In this, I'm applying Wes Rishel's ABC rule for interoperability. This mechanism means that applications can update themselves to use newer value sets asynchronously, and things will still work.
-- Keith
0 comments:
Post a Comment