The genesis of that requirement in IHE PCC came about as a result of a discussion we had back in the first year of the Patient Care Coordination Domain. Our main concern was that machine readable entries would need to contain the same text as appeared in the narrative. In CDA there are two ways to accomplish this: by value (duplicating the content), or by reference (pointing or linking to the text).
Duplicating the content in two places results in a potential for programming errors, as machine readable and narrative content are often generated by two different software routines. These errors would not necessarily be detectable either. Pointing to that content was deemed to be safer, because it would avoid the duplication, and you could at least verify that the content was present.
There are arguments both ways. Counter-arguments include:
- It is hard
- Implementations are inconsistent in the way that they implement it
- It isn't properly tested for by current validation tools.
- For narrative content that is derived from entries it is technically not necessary.
I have little sympathy with avoidance of a hard requirement that attempts to mitigate a potential patient safety issue. Yes, it does in fact make implementation a little bit more difficult. I have also seen a great many implementations do this properly.
With regard to inconsistencies in that way that the requirement is met, I would have to agree. Some organizations would link to the entire medication including the dose, route, frequency and dates in the narrative, and others would just link to the medication name. The rule is that the entire narrative that is being described by the machine readable entry should be referenced, not just a part of it. I think some clarification for how to implement it would certainly be helpful.
Validation is an easy fix. One need only verify that all fragment identifiers in the @value attributes in reference elements of the machine readable entries appear as an ID attribute of some component of a text element in the document.
The necessary X-Path statements appear below:
content: reference[substring(@value,1,1)='#']
assertion: //cda:text//*[@ID = substring-after(current()/@value,"#")]
In the last case, when machine readable entries drive the narrative, rather than the other way around, the argument made is certainly true. The assertion made by setting the typeCode attribute of the component element to DRIV is exactly that the narrative is created from the machine readable entries.
What I've seen in the real world is that FEW implementations use the DRIV component relationship. So, the choice becomes introducing the need to have two code paths to get to the value which must be present in the narrative, or to have only one. Fewer code paths is, in my view, the better, safer way to address these issues.
One other benefit of the IHE requirement is enforcement is machine readable entries that software may use to interpret the content WILL ALWAYS have associated narrative that a clinician can see. That means that you won't get two lists: One that the clinician sees, and a separate and possibly different list that the software operates with.
It also means that software can actually detect text in the narrative that isn't associated with a clinical statement. That might even be important to highlight to the clinician (and can be done via an XSLT stylesheet).
If you want to weigh in on this question, and are participating in the CDA Consolidation project, I recommend you leave your comments there [I've turned off comments here for this post].
-- Keith
