Writer's Block and a discourse on XHTML for CDA

So, I'm following my own rule about writer's block, staring at a nearly blank page.  I've discussed previously the notion that CDA should not create its own XML for narrative, instead using XHTML.  It's on my to do list, so let's write about that...

The ramifications of using XHTML for CDA Narrative:

For one, there are a number of XHTML tags that have semantic equals in CDA.  We could readily change content to span, paragraph to p, list to ul or ol, styleCode to class, linkHTML to a with little effort.  That would go a long way towards equivalence of the two.  At the very least, this MUST be done.  There is absolutely no reason to maintain different tags at this level.

In CDA, there are sections of content, and each section can have subsections. XHTML doesn't really deal with that notion very well in heading tags. You have "dividers" or section headers using h1 through h6, but nothing to wrap the section. So, a CDA section is more like an XHTML div element.  We could even use the h1 through h6 tags to represent the title of the section. This would be a CDA "profile" of XHTML, restricting certain structures that we don't like.

The next challenge is attaching participations to the section. Participations are repeatable and of varying types: Author, Informant, Subject, the Generic Participant, et cetera.

This challenge is more fundamental and gets right at the RIM based representation of clinical documents.  The document is a composition of narrative sections and "header" information, and sections are compositions of entries, and with optional subsections.  You can attach participations and entries to sections, but if you move the section structure over to XHTML, the linkage is gone and needs to be added back.  Also, the "inheritance" of context in the narrative needs to be readdressed.

Now, the XML ITS is simply one representation of an HL7 model, and is the one upon which CDA is presently based. But arguably, CDA R3 is a composition of two things: optional domain model content (so-called level 3), and a "narrative view" of that content.  Slicing and dicing the domain model into sections and subsections breaks it apart and interferes with the inheritance of context in the domain model.  So, there could arguably be two layers of "context", one imposed by the narrative view, and another imposed by the domain model view.

So, does the narrative view use XML ITS sort of structure to convey context?  I would suggest that it probably does not.  The "narrative" view is meant to be present for human readability, and should remain as true to a standard designed for presentation like XHTML as possible, maybe introducing a few things that XHTML rendering applications could easily ignore.

We could assume context conduction of the "CDA Header" into the narrative, because the only context that could be overridden at the section level are things like author, informant, subject or a generic participant (not present in R2).  So, how do you assign these participations to the section?

One way would be to require all authors, informants, subjects and other participants to be listed in the CDA Header.  These are, after all, participants in some component (and I use that word on purpose) that is part of the document, and so, are also participants with respect to what appears in the document.  This presents a small challenge because we'd like to quickly be able to identify the "principle" subject of the document easily in the CDA header.  I'd propose that we add an organizer to the document header whose express purpose is to act as a collector for document participants that aren't "primary" to the document context (and so by being referenced in the organizer, don't flow down via context conduction).

Now, each of the participants can exist in the XML, but I want to easily reference them.  We could use ID/IDREF or some other referencing mechanism.  I like ID/IDREF because the XML parser verifies uniqueness of ID and existence of an ID for every IDREF, but others may prefer another referencing mechanism.

So, a div element representing a section would need to attach the participants that are associated with it.  That becomes rather easy by adding one ore more attributes to the div element that lists the IDs of the participants that are associated with the section.  You could have a general cda:participants attribute support all, and use the participation types, et cetera in the model, but that's a bit harsh on the consumer.  Easier would be to support an attribute for each major participation type:  Author, informant, subject, and to meet any other needs: participant.  The extra attributes will be ignored by most XHTML renderers, are easily removed, and by using the IDREFS data type.  So, here is the new section markup:

‹div cda:author='a1 a2' cda:informant='i1'›
 ‹h1›Problems‹/h1›
 ‹p›The patient has pharyngitis‹/p›
‹/div›

Note how participations are linked to the "section" via the cda:author attribute.

There are three other class attributes on the section:  code, languageCode, and confidentialityCode.  Now, I'd stick with the XHTML lang attribute to represent the semantics implied by languageCode and call that done (they even use the same vocabulary). [Note: I'll deal with multilingual content in a separate post].  That leaves code and confidentialityCode.

Now, the next challenge is classifying the section (dealing with section.code).  What I'd love to be able to say is put the code in an attribute on the div element, but there's not really a clean way to an express a CD in a string as far as I know.  The alternative is to keep a parallel section structure, or add elements to the div element that appear in another namespace.  I'd kinda like to keep the narrative "clean", not introducing stuff that could wind up being displayed if you just sent the narrative to the browser.  That means that only attributes (like cda:author above) could be added.

So, we need to either attach a section element to the div using a model similar to what was done with author above.  I haven't decided at this point how to approach this step.  If there were a string representation of CD, I know what I'd do right away would be to add cda:code and cda:confidentialityCode attributes to the div element.

Well, that sums up about two hours of thought and research.  So much for writer's block.