CDA in the Wild: Narrative Issues (Installment #5)


A solitary Wild CDA has left its pride. We can only presume it is searching for a mate by its extravagantly complex header and the swish of its long tail of codes. However, research tells us that while a long code tail is nice to have, it is the mating call of the CDA, or its narrative, which attracts the opposite sex. Let’s eavesdrop a bit.


Hmmm…this one’s narrative is quite pathetic. It sounds nothing like the CDAs you hear on the Wild Interoperability reality show, with their strong roars of clinical relevance. In fact it is barely recognizable as the call of a CDA at all, which does not bode well for its chances with the opposite sex. Not only that, but it’s code tail is so out of proportion to the rest of its body that the poor thing can barely keep its balance.


Wait…something rustles in the bush nearby. Was this lackluster narrative enough to attract a mate? Will we be the first to record the mating of two wild CDA’s? Praise provenance!


The potential mate is emerging from the brush, yes I can see it, it’s definitely a…no wait, it’s not. It seems to be a North American XHTML. The CDA and the XHTML approach each other and…


Well, this show is rated TV14 so we won’t describe what happens next, but suffice to say that our previous assumption of genetic tampering to produce that CDA/XHTML hybrid is now called into question. It seems the CDA’s own perverse narrative was the root cause…


When did words take a back seat to codes? At some point, informaticists usurped the concepts of meaningful and useful and convinced implementers that only coded elements are relevant. In fact, the opposite is most often true.


First, I need to provide some background on CDA, why narrative is required, and why codes are optional.


CDA stands for Clinical Document Architecture. Note that the word ‘Document’ is emphasized. CDA was designed for the clinical document use case. Clinical documents filled those manila folders with your name in bright yellow Sharpie at the doctor’s office back in the day. These charts and notes, covered in handwritten prose, describe your health in wonderfully nuanced language. Words that actually meant something to the next person who read them.


And yes, your old doctor still needed codes. How else would she bill for services? But these were understood as billing codes, and nothing more. No one in his or her right mind would consider them a replacement for the words written by your doctor.


This is why CDA documents have a human readability requirement. Each and every CDA document requires human readable narrative text, which represents the clinician’s exact words. A clinician attests to this narrative upon signing a CDA. Codes are meant to support this narrative, not usurp it.


In practice, the current fixation on coded data means that the narrative requirement is either marginalized, poorly implemented, or completely ignored. Below are some examples of “CDA narrative blocks” that pass the CDA XML Schema and Schematron validation. A glance at the resulting document in a web browser, however, instantly reveals that something is wrong.


Examples –


  • Missing or incomplete narrative:
See coded entries
  • Entire documents in observation.text, instead of in the narrative block:
 Title: Procedure Note
 Date: 01/01/2015
 Findings: ...

  • Generated narrative issues (mismatched columns, dates in wrong places, raw SNOMED codes without display names, etc.):

  • Backwards references (expecting the narrative to reference the entries, instead of the other way around):
<td id=”entry1”/>
     <reference value=”#entry1”/>
     Diabetes mellitus

The list goes on and on. In nearly every case, I find a person’s name in the legalAuthenticator section of the document. I don’t see how this is possible without negligence. None of these documents would have properly rendered the clinical content of the document in a browser. Either someone signed the document without reviewing it, or entered a clinician’s name without permission.


By entering a person’s name in the legalAuthenticator field of a CDA document, a developer is stating that this person signed the document and attests to the contents of the narrative block. The attester can be held legally accountable for the content, as if he or she signed a paper document. Are developers giving clinicians a choice to edit this content? Are clinicians even aware that some developers are signing their names for them or blindly populating the legalAuthenticator field with <INSERT-LOGGED-IN-USERNAME>? Some developers enter no name at all, and send unauthenticated documents. That’s better than signing someone’s name without their permission (also known as forgery, which last I checked is a felony). At least they aren’t putting clinicians on the hook for malpractice. Or are they?


For CDA document recipients, what do you do when you receive documents? Do you check the authenticated status? When you load codes, do you do a reality check against the document narrative? Do you realize that your clinicians and/or organization could be liable for acting on unauthenticated information?


Look, I understand the desire to have a one-to-one correspondence between the codes in a document and the narrative. I’m a software developer, and I want everything to be machine-processable. But you can’t always get what you want. Clinicians need to say what they need to say, and recipients need to know that the sender said what they needed to say. If you don’t have codes to express everything clinicians need to say – too bad, you never will. Today, the vast majority of codes exchanged across enterprise boundaries are still just billing codes (no matter what the clinical decision support academics wish for when they click their heals – pun intended).


Codes are not a replacement for narrative.


“But the future is about computability”, you say. “We want true semantic interoperability”. Wonderful goal. I support you, but you are going about it the wrong way. Codes record what can be coded today, however, documents are persistent. Documents are about today and tomorrow. Limiting documents to what can be coded today sacrifices the future.


Can modern codes fully represent what one person needs to say to another? For example, could they completely replace the entire narrative of this blog while conveying the same meaning? The answer is no (Unicode gets a pass here because it’s just coding the characters and keeping the narrative intact).


Think back when Google translate came out in 2010. You would enter some phrase like “How are you today” and get back something ridiculous in the listener’s native language that would just make them laugh. These days though, Google can translate pretty well if you speak “How are you today?” into your smart phone. When the person you are speaking with responds verbally, your phone captures his or her voice and translates it back. The computable value of the same narrative has increased over time. The same words that were not processable 6 years ago are now.


Compare this innovation to codes. In 2010, you entered a code that means “allergy to penicillin”. Is it more computable today? Maybe slightly, if the common understanding of the term associated with the code has evolved; but for the most part it is still just as computable now as it was then. Its value has not changed much, if at all.


So what’s my point? Narrative is far more expressive than codes. Clinicians need to say far more than modern codes allow them to express. If clinicians are limited to expressing themselves in codes, then we are limiting what they can express in total and thereby reducing the long term value of patient medical records.


The FDA recently mandated new warnings for a contraceptive device based on evidence from narratives. Previously, the FDA had noted 125 cases of fetal death from this particular device, but researchers later found approximately 300 cases when using a different approach, “most of the story of what happened and all the side effects, those are going to be in the narrative…So we searched for keywords in that narrative that women and their doctors would use, such as fetal death, miscarriage, still birth, stillborn and ectopic pregnancies.” ( Imagine if the narrative in these records had been generated solely from the data that the FDA relied on in their initial analysis without the ability for clinicians to supply their own narrative. The evidence would have been lost forever.


The spoken word is subtle and nuanced, and ready for the future. We can mine words for richer content each year. What will researchers of the future say about this decade’s medical records? I argue that most of the documents exchanged today under Meaningful Use will appear to them as nothing but a steaming code pile. Researchers will turn their noses away from them and look to the largely narrative documents of the past for rich clinical content.


So how do we fix the current mess? For starters, require clinicians to review CDA documents in a web browser before they are exchanged for accurate review and sign-off. This simple step eliminates the kind of bad narrative examples outlined above. During that review process, clinicians should always have the freedom to modify or rewrite the narrative of any document. Feel free to auto-populate the narrative with content generated from the coded data, but allow clinicians the opportunity to change it as needed (and be sure to remove the DRIV typeCode attributes on the entries if they do make a change to auto-generated content).


We are not adding to the meaningful exchange of clinical data by emphasizing coded data over narrative. Rather, we detract from it. We are sacrificing rich clinical content for expedient coding. Codes are for today, but narrative is forever.


Long live the narrative!


To see the full series click #CDAinthewild


#CDAinthewild;#CDA; #HIT; #HL7