The fly in the XHTML ointment: CSS

Jun 10, 2012

In CDA R2, the narrative portion of the document is a format that is based on XHTML, but is not actually XHTML. HL7 provides an xslt that does a reasonable job of transforming it to XHTML for display, but the consequence of this is that authoring the narrative is hard - there’s no off the shelf authoring tools for the CDA narrative. So for CDA R3, the committee has decided to use XHTML. Well, a subset of XHTML, anyway. I think it’s not too hard to describe a reasonable subset of XHTML:

the basic html formatting elements described in chapters 7-11 (except section 4 of chapter 9) and 15 of the HTML 4.0 standard, elements (either name or href), images

(that’s from the FHIR rules for XHTML). In other words, a clinical document isn’t going to contain executable code, forms, objects, frames etc. And that’s not an unreasonable set of restrictions - it’s not going to restrict you from using an off-the-shelf xhtml editor, including the clever little DHTML editor that’s part of word press (which I’m using now).

Images are a problem though:the img source is another resource located somewhere else. This is a problem for CDA because the image is inherently part of the document, and the document loses it’s integrity if the image is lost. The image needs to be available and to move with the document when it is transferred (CDA R2 spec section 3).  There’s various ways to organise that, but as far as I can figure out, none of them are supported out of the box by off-the-shelf xhtml editors. So either you need to modify the editor - not for the faint hearted (and that’s what we were trying to avoid) - or you need to do post-processing to repatch the img src location. Not nice, but possible.

But CSS - there’s a series of problems here for which I don’t see an obvious solution. (Or perhaps, I see an obvious solution, and don’t like it). Just to recap, you can styles to elements in a document 3 different ways:

  • Including a reference to a stylesheet (a css) in the document header
  • Including a set of named styles in the document header
  • Specifying a set of style attributes on the element itself

See tutorial. It turns out that you can include a set of named styles anywhere in the document (at least you can with ie, firefox, and webkit), though where ever you put them they are global to the document. Generally, use of the last method is frowned upon (see here, here, and here). In particular, quoting from the last link:

  1. Separate content from designOne of the main goals of CSS is to remove the design elements from the HTML and place them in another location for the designer to maintain. That means that a designer doesn’t have to also be the content developer to maintain the look of the Web site.
  2. Make maintenance easyOne of the most forgotten elements of Web design is the maintenance. Unlike print materials, once you put out a Web “magazine” it doesn’t go away. Things change - from the look of your site to the content and links within it. And having your CSS in a central place makes it that much easier to maintain.

Perhaps it’s just me, but I don’t find that CSS makes maintenance easy - I often have to load the web page and debug the style stack to figure out why a particular style is being used, and unless you are extremely disciplined about your styling style, you’ll end up in a mess where you aren’t sure what the side effects of changing some particular style might be. As for separating content from design, I find this more true in the aspirational sense than in the reality - using css lets you change colours without touching the content, but it doesn’t take much redesign work before you’re once again playing around with divs and tables in the content to get the effect you want.

Btw, there’s one more option for using styles - you can include a

This all brings us to using xhtml in CDA. It’s hard to use xhtml without using CSS. You don’t have to want anything fancy or dynamic - you want a font color, underlined text? and are deprecated in HTML 4, and not in the xhtml schema, so you have to use css. But system designers aren't going to be happy with the basics - documents have to look good when they are displayed to the user. Font rendering, images, page layout- these matter.

But the other thing that matters is fidelity - the document as rendered needs to match what the author intended. If the author creates and attests to a document where some of the text is red, then that text needs to render red when any clinical user looks at it. This is an important clinical safety issue. And colour and style are frequently used to convey information of clinical importance (abnormal results in diagnostic reports, instructions in clinical summary documents, alerts to adverse reactions…) Though computer centric users (both IT devs and clinicians) frequently forget that a lot of content is faxed, and their look-at-me-colors degrade to a pale grey through the fax process.

The beauty of the existing CDA design - the custom narrative - is that it clearly delineates between what is the author’s responsibility, and what freedom of the rendering system has to present the document.

Replacing the narrative with XHTML presents the following issues:

  • If the styles are provided by reference, and the referenced style isn’t available, the document won’t display correctly - and may not display safely. Unfortunately, the lack of correct display may not be catastrophic (the document may look like it has rendered properly, but something important is missing).
  • Putting the styles in the document - either in line or in the header (which would mean a special place in the CDA document for before it’s transformed to real xhtml) would work, but it would mean that the renderer loses all control over the document

There’s one more issue to consider: Often, documents are assembled from information gathered from multiple sources. Some of it’s mastered in the application preparing the document. But other parts - significant parts - the application will be gathering narratives prepared by other applications, and maybe in other formats. For instance, a clinical summary that includes diagnostic reports. What if these different sources are using different incompatible styles?

From an engineering/standards viewpoint, it’s starting to sound as though we’ll need a single fixed CSS for all users of xhtml in CDA - effectively replicating the current system, where there’s only a fixed set of style codes that you can use. But unlike the current design, where there’s a transform separating the authored and rendered styles, we’ll need a very fine grained and precise list of styles that the author can use, and ones that the renderer can use, and I don’t like the sound of that. More generally, I don’t like the sound of having a fixed CSS for all uses of clinical documents either. And we can abandon all hope of using off-the-shelf authoring tools…

None of these options are any good. Which is why I always preferred CDA to use it’s own narrative.

But in FHIR, we’ve said from the start that the narrative portion is xhtml. Which means we need to solve this properly. I figured we’d solve it when we got to it, but now that we have, I’ve drawn a blank. I’m hoping that someone will explain a simple, elegant and obvious solution that I’ve completely overlooked in the comments to this post.