This week, I have left the bush behind and retreated to the comfort of my office. I am attempting to decode the works of the famous biologist Brice Schneuer, who spent the later part of his career dedicated to Wild CDA research.

 

Although he published many authoritative works on the species, Schneuer jealously guarded his unpublished works because he feared his detested rival, the Frenchman Étiezne Baneries (whom Brice called “The French Swine”), would plagiarize his research. Thus, Schneuer encrypted everything on his computer.

 

Schneuer published nothing during the last five years of his life, but remained sequestered in his office working on what he referred to only as his “seminal work”. When questioned, his typical reply would be, “Why don’t you ask the French Swine. You know what his reply would be? Les oink!” 

 

Others have since named his final work the Tribeca Project, because his disheveled office was in Tribeca, Lower Manhattan. He was supposedly in the final stages of editing the project when he was found dead, slouched in a threadbare armchair. His computer had gone into standby mode, and his files had automatically dismounted and re-encrypted themselves.

 

The only clue to his death was a half chewed piece of paper hanging from his mouth, and only the numbers 225589000 remained visible. It seems he died chewing a secret message which he was unable to digest.

 

Researchers attempting to decrypt the files concluded that Schneuer must have bypassed all standard encryption algorithms, and employed a variation of a one-time pad using the text of some book as the key.

 

Only Brice knew which book—until now.

 

After much due diligence (contacting former colleagues, family members, as well as some rather disreputable associates) I have discovered that he used an ancient occult book known only as the SNOMEDINOMICON for his one-time pad.

 

Yes, the SNOMEDINOMICON is The Key to Tribeca. 

 

I have found an electronic copy of this text and I’m decrypting the Tribeca Project now, live via modular arithmetic [6], so that we can all experience this together. What insights await!

 

Hmm. That’s odd.

 

The Tribeca Project seems to be an archive of video files. I was expecting text. Well, let’s click on one and see what comes up.

 

Ugh…Well now I know what Brice’s seminal work was. Gigabytes of CDA mating videos. I think we had enough of that in our last episode…

____________________________________________________________

Previously, I ranted against codes taking priority over narrative. Readers might think that I don’t like coded data, but nothing could be further from the truth. I love codes. I just like narrative better.

 

I love caramel too, but caramel is not chocolate.

 

That said, once you get your narrative right, codes are extremely beneficial when implemented correctly. Sadly, that’s rarely the case.

 

As the name implies, coded data essentially means sharing secrets. Successful communication is only possible if both parties share codes. If not, then communication is impossible. Or worse, there’s miscommunication.

 

That’s why narrative is key, but I already went there in my last post.

 

When you both share the secret key and understand the codes in use, amazingly concise and precise communication is possible. In reality, however, codes are often missing data, gibberish, insider information, and so on. And what the heck do you do when you decode the codes and they don’t match the narrative?

 

Here are some examples of coded data gone wrong:

     <code/>

 

This looks like a case of someone trying to fake out the Schema. A code is required, so they just put in the empty element. While this may pass the Schema, it violates HL7 data type rules. You either need a @code and @codeSystem attributes, or @nullFlavor (indicating why the previous attributes are not populated).

 

So, you need a code:

     <code code="1"/>

 

Anyone know what “1” means? Likely not – unless you know the codeSystem. But a codeSystem without a code is just as lonely:

     <code codeSystem="2.16.840.1.113883.6.1"/>

 

That’s the OID for LOINC, but what LOINC code are you trying to send?

     <code code="51849-8" codeSystem="LOINC"/>

 

Close, but you can’t put the name of the code system in the code system attribute; you need to put the code system OID there.

     <code code="51849-8" codeSystemName="LOINC"/>

 

Closer, but still not right. The codeSystemName attribute doesn’t actually identify the code system, it’s just there for debugging purposes so someone reading the XML doesn’t have to look up the OID to know what code system it represents. So you still need to put the LOINC OID in the codeSystem attribute.

 

And finally here is one of my favorites…not (tip of the hat to John D’Amore for raising this issue)

     <section><title>Medications</title>
     <text><paragraph>Penicillin</paragraph></text>
     …
     <code code="2670" displayName="penicillin " codeSystem="2.16.840.1.113883.6.88" 
     codeSystemName="RxNorm"/>

 

Nice try. The narrative says “Penicillin”, but that’s actually the RxNorm code for codeine.

 

The list goes on and on.

 

I suspect everyone is familiar with ZDoggMD’s EHR State of Mind. Well, guess what? As much as EHRs suck, their auto-generated CDA summaries are likely to suck to the same extent.

 

Think your EHR is the exception? Take a closer look. These are CDA trophies curated from the wild – that means they may come from your EHR.

 

Bottom line, codes are your best friend – when done right. The @code and @codeSystem attributes must align, and they must not contradict the narrative. Codes support computability while computers catch up with human speech. But codes done wrong are just bad, and I don’t mean bad in the bad is good sense. Far too much CDA coding today is bad-bad. Couple that with neglect-of-narrative syndrome and we have to ask whether interoperability can survive in the wild.

 

To see the full series click #CDAinthewild

 

#CDAinthewild;#CDA; #HIT; #HL7