CDA provides a mechanism to explicitly reference from an entry to the corresponding narrative, as illustrated in the following example (see CDA Release 2, section 4.3.5.1 content for details):
CONF-29: A CCD entry SHOULD explicitly reference its corresponding narrative (using the approach defined in CDA Release 2, section 4.3.5.1
There's a rationale and a couple of use cases behind this idea. The IHE (and underlying HL7) specifications don't require that code be valued, but in those cases, you do need the originalText. The whole point was to be able to identify the "free text" that would have been coded. There were two choices:
- Duplicate the text.
- Leave the text in the narrative and point to it from the entry.
Duplicating the text seemed to be a potential source of errors that could be avoided by pointing to it. Others have reported that pointing to it is also a potential source of errors, but at least that can be better detected and corrected for. You cannot detect mismatches between entries and narrative by allowing for duplication.
The use cases that I've encountered for using the pointers include:
Ensuring that each machine readable entry has associated narrative
One can this in the CDA document by verifying that each reference/@value attribute can be associated with an ID attribute using that URL. You cannot automatically detect that it is the correct narrative but the next two use cases help.
Providing popups that display the machine readable data associated with the Entry
The simplest method is to use the HTML title attribute to generate the "popup", but you get get a lot fancier. Essentially, for any element with an ID attribute, you add a title attribute to the output HTML that lists the code, display name and coding system name in the title. This can also be used to facilitate manual testing of appropriate association of coded entries with narrative content.
Identifying Narrative Content that isn't associated with a machine readable entry
You can also put narrative content in a different style if there is an entry associated with this. This is just a slight variation on the popup trick I described above. It easily makes it apparent which narrative content isn't associated with an entry.
Now, some have suggested that when the Narrative is completely derived from the text, as indicated by the DRIV typeCode attribute value on the component element, that this constraint is unnecessary. As the narrative is reported by the document to be completely derived from the entries, there should be no reason to put in the linking code. I'm of mixed opinions about this, because even when "narrative is derived from entries" there is still a need to make sure that it was done correctly. The linking capability makes this possible.
It's very clear that there are some who would have this be changed. The question of whether this is even within the scope of the project is also under debate in HL7 Structured Documents. Given that all IHE did was strengthen a CCD SHOULD constraint into a SHALL constraint, I would argue that it isn't. However, the SDWG seems content to ignore that issue, and see what others want to do in this regard. I know that not everyone likes this constraint, and that SDWG added it to CCD as part of ballot reconciliation to harmonize with what IHE had done. But even though it was hotly debated then, doesn't really make for a good excuse to weaken it now. Even so, I'm likely to lose this battle, and will have to figure out how to ensure that this change will not cause problems even though it won't be backwards compatible. There's quite of bit of IHE work implemented Internationally which adheres to this constraint.
Identifying Narrative Content that isn't associated with a machine readable entry
You can also put narrative content in a different style if there is an entry associated with this. This is just a slight variation on the popup trick I described above. It easily makes it apparent which narrative content isn't associated with an entry.
Now, some have suggested that when the Narrative is completely derived from the text, as indicated by the DRIV typeCode attribute value on the component element, that this constraint is unnecessary. As the narrative is reported by the document to be completely derived from the entries, there should be no reason to put in the linking code. I'm of mixed opinions about this, because even when "narrative is derived from entries" there is still a need to make sure that it was done correctly. The linking capability makes this possible.
It's very clear that there are some who would have this be changed. The question of whether this is even within the scope of the project is also under debate in HL7 Structured Documents. Given that all IHE did was strengthen a CCD SHOULD constraint into a SHALL constraint, I would argue that it isn't. However, the SDWG seems content to ignore that issue, and see what others want to do in this regard. I know that not everyone likes this constraint, and that SDWG added it to CCD as part of ballot reconciliation to harmonize with what IHE had done. But even though it was hotly debated then, doesn't really make for a good excuse to weaken it now. Even so, I'm likely to lose this battle, and will have to figure out how to ensure that this change will not cause problems even though it won't be backwards compatible. There's quite of bit of IHE work implemented Internationally which adheres to this constraint.
One additional reason may be that it empowers "native CDA editors".
ReplyDeleteMost diacharge letters (not CDA based) are currently populated using structured data, and a clinician only removes those parts that aren't necessary in a given context, and adds a few details.
Imagine a "native CDA editor", i.e. an editor that has full understanding of CDA. If I then were to copy (CTRL C) the word "Asthma", then the application would know that there's an entry associated with that word. Paste in a new document (CTRL V) and I'd not just paste the word, but also the entry.
I proposed that the linking of text and entry be called CDA "level 4", to stress its importance in the structuring of a document content. This is more of a merketing ploy than anything else. Unfortunately the suggestion wasn't accepted for use in CDA R3. Note that CDA R3 may just have one very big entry in it, and lots of textual sections, which will only increase the need for better links between the textual part and the entries. The danger of those becoming disjunct is increasing, not decreasing, in CDA R3.