The fly in the XHTML ointment: CSS

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, <a> 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. 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 design
    One 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 easy
    One 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.

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? <u> and <font> 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.



  1. Arno says:

    Coming from a programming/comp sci background I have seen different approaches to the 2 problems you mention.

    For the images modern browsers are powerful enough to encode and decode the image as a base64 string (which can be stored as such in most databases). This is being used currently in HL7 v2 to include images into ORU messages containing RTF documents with images. The downside is that this will dramatically increase the size of a document.

    To the issue of the CSS a similar issue was/is present in creating HTML based applications where you want to minimize the load time and size of the application. But one approach is to rely on the fact that commonly used libraries like jQuery are stored by CDNs (Google), and more than likely thses are already cached on your local device. And by referencing these in your application you can most often cut down on the loading time and size.

    I can envision a similar system where tool specific CSSs are stored on CDN and every renderer would build a cache of the CSSs that they render.

  2. Grahame Grieve says:

    so you’re suggesting to do it by reference, but provision a single server that’s guaranteed to be reliable, and require all css to be hosted there?

  3. Joshua Varner says:

    The acid test ( approach used to improve css uniformity and support could provide a model.

    From an implementation viewpoint, no one is going to build a custom HTML renderer for their application so that means they are going to use the standard WebKit, .Net, java … components. If you are using css that means you are by definition bringing along all of their baggage related to differences in the way css works. While this is much better than it used to be, it is by no means identical.

    Since clinical fidelity is the primary goal of maintaining the look then defining a set of styles for “significant” information conveying could allow the definintion of an acid like test that vendors would need to support. A reference implementation of css to support this could be created as a common resource, but vendors could create their own versions that are customized to their application context.

    If the standard set of styles are defined in terms of their semantic meaning you might be able to address the fax issue you mention, in that there are 2 contexts of display that must be supported: a color/full display version, but also a greyscale/printing mode that could use alternate indicators that would survive faxing better.

  4. Victor Chai says:

    I think we should get the following questions answered before trying to come up any solution.

    1. Did anyone ever use off-the-shelf authoring tool to create CDA in the first place for production system use? I would expect the CDA including its narrative text will be created by the sending application rather than human being using authoring tool.

    2. On receiving end, except in the situation where users view the received CDA in standalone web browser, did anyone ever expect any computerized application to display CDA document as it is? I think in reality these application will always use its own way (following its own UI design including CSS) to display the CDA narrative text.

    • Grahame Grieve says:

      1. there is no off-the-shelf tool, but the sending application needs to get the narrative from somewhere. If they get it from a human, how? They want to use an off-the-shelf editor

      2. Yes. People expect the narrative to display as the author intended it. This is a basic clinical safety concern that all the providers of clinical documents bring to the table: who is liable if it doesn’t render properly…

  5. Victor Chai says:

    For the first point, as you mentioned, the CDA narrative text probably will be extracted from various applications, I can’t imagine a situation where a user authors the CDA narrative text ever using off-the-shelf tool, and then pass to some application to stuff the content into CDA. Do you have real use case to illustrate?

    For the second point, I am not saying that receiving applications will discard the intended display of the narrative text. What I am trying to say that the receiving application will achieve the goal eg display the narrative text with some highlighted red bold font etc in this own way. Take the simple example of CSS, each application has its own way to manage CSS esp if we are developing applications in technologies such as JSF

  6. Bert Zwep says:

    The arguments you use against inline styles are not valid in the CDA context. Because inline styles have the highest priority, clinical fidelity will be ensured, e.g:
    style=”color:red” will ensure that the characters are displayed red. I would say: just use inline styles and not document or linked styles.

  7. Piers Hollott says:

    Using color to indicate clinical importance of text is a risk in any case… unless it’s “greenCDA®” in which case colour is apparently imperative.

Leave a Reply

Your email address will not be published. Required fields are marked *

question razz sad evil exclaim smile redface biggrin surprised eek confused cool lol mad twisted rolleyes wink idea arrow neutral cry mrgreen


%d bloggers like this: