If a cda code is represented with both a code and a translation, which of the following should be imported as the stored code into CDR:
- a normalised version of the Translation element (using the clinical terminology service)
- the Code element exactly as it is in the cda documentThe argument for option 1 is that since the Clinical Terminology Service is the authoritative source of code translations, we do not need to pay any attention to a ‘code’ field, even though the authoring system has performed the translation themselves (which may or may not be correct). The argument for option 2 is that Clinicians sign off on the code and translation fields provided in a document. Ignoring the code field could potentially modify the intended meaning of the data being provided.
- The user picked code A, and some terminology server performed a translation to code B
- The user picked code A, and some terminology server in a middle ware engine performed a translation to code B
- The user picked code X, and some terminology server performed translations to both code A and B
- The user was in some workflow, and this as manually associated with codes A and B in the source system configuration
- The user used some words, and a language processor determined codes A and B
- The user used some words, and two different language processors determined codes A and B
ok, the last is getting a bit fanciful – I doubt there’s one workable language processor out there, but there are definitely a bunch out there being evaluated. Anyway, the point is, the relationship between code A and code B isn’t automatically that one is translated from the other. The language in the data types specification is a little loose:
A CD represents any kind of concept usually by giving a code defined in a code system. A CD can contain the original text or phrase that served as the basis of the coding and one or more translations into different coding systems
It’s loose because it’s not exactly clear what the translations are of:
- “a code in defined in a code system”
- “the original text”
- the concept
The correct answer is the last – each code, and the text, are all representations of the concept. So the different codes may capture different nuances, and it may not be possible to prove that the translation between the two codes is valid.
Finally, either code A or code B might be the root, and the other the translation. The specification says 2 different things about which is root: the original one (if you know which it is), or the one that meets the conformance rule (e.g. if the IG says you have to use SNOMED CT, then you put that in the root, and put the other in the translation, irrespective of the relationship between them).
Actually, which people do depends on what their trading partner does. One major system that runs several important CDRs ignores the translations altogether….
Turning to the actual question: what should a CDR do?
I think that depends on who’s going to be consuming / processing the data. If the CDR is an analysis end point – e.g. data comes in, and analysis reports come out, and also if the use cases are closed, then you could be safe to mine the CD looking for the code your terminology server understands, and just store that as a reference.
But if the use cases aren’t closed, so that it turns out that a particular analysis would be better performed against a different code system, then it would turn out that storing just the one understood reference would be rather costly. A great case is lab data that is coded by both LOINC and SNOMED CT – each of those serves different purposes.
This some applies if other systems are expected to access the data to do their own analysis – they’ll be hamstrung without the full source codes from the original document.
So unless your CDR is a closed and sealed box – and I don’t believe such a thing exists at design time – it’s really rather a good idea to store the Code element exactly as it is in the CDA document (and if it references that narrative text for the originalText, make sure you store that too)