Do we need CSS in CDA R3's XHTML?

Grahame Grieve discusses CSS as The Fly in the XHTML Ointment being applied to CDA Release 3 (and FHIR) in his most recent blog post.

I have to wonder about this.  In the design principles for CDA Release 2.0 (section 1.1.3) it says:

• CDA documents must be human readable using widely-available and commonly-deployed XML-aware browsers and print drivers and a generic CDA style sheet written in a standard style sheet language.

But implementers have been free to date to determine what that style sheet would look like.  No normative style sheet was provided in the CDA standard (an example was provided, but that is non-normative).  

The idea that styles could be dinked around with is supported by the styleCode attribute in CDA Release 2.0.  This attribute is described as follows in section 4.3.5.11:

The styleCode attribute is used within the CDA Narrative Block to give the instance author the ability to suggest rendering characteristics of the nested character data. Receivers are not required to render documents using the style hints provided and can present stylized text in accordance with their local style conventions.

There are a standard set of style codes with specified meanings.  When I implemented "my" style sheet for CDA, I simply created CSS classes and mapped the styleCode attribute to the XHTML classCode attribute (as I show it mapped here).

Code	Definition
Font style (Defines font rendering characteristics.)
Bold	Render with a bold font.
Underline	Render with an underlines font.
Italics	Render italicized.
Emphasis	Render with some type of emphasis.
Table rule style (Defines table cell rendering characteristics.)
Lrule	Render cell with left-sided rule.
Rrule	Render cell with right-sided rule.
Toprule	Render cell with rule on top.
Botrule	Render cell with rule on bottom.
Ordered list style (Defines rendering characteristics for ordered lists.)
Arabic	List is ordered using Arabic numerals: 1, 2, 3.
LittleRoman	List is ordered using little Roman numerals: i, ii, iii.
BigRoman	List is ordered using big Roman numerals: I, II, III.
LittleAlpha	List is ordered using little alpha characters: a, b, c.
BigAlpha	List is ordered using big alpha characters: A, B, C.
Unordered list style (Defines rendering characteristics for unordered lists.)
Disc	List bullets are simple solid discs.
Circle	List bullets are hollow discs.
Square	List bullets are solid squares.

So this became my CSS representation of the styleCode attribute in CDA Release 2.0.

.Bold { font-weight: bold }
.Underline { text-decoration: underline }
.Italics { font-style: italic }
.Emphasis { font-variant: small-caps }
.Lrule { border-left: 1px }
.Rrule { border-right: 1px }
.Toprule { border-top: 1px }
.Botrule { border-bottom: 1px }
.Circle { list-style-type : circle }
.Square { list-style-type: square }
.Disc { list-style-type: disc }
.Arabic { list-style-type: decimal }
.LittleRoman { list-style-type: lower-roman }
.BigRoman { list-style-type: upper-roman }
.LittleAlpha { list-style-type: lower-alpha }
.BigAlpha { list-style-type: upper-alpha }



With the exception of the class code for emphasis, all of the above have the commonly understood rendering interpretation.  Emphasis is interesting.  It's a semantically meaningful description of what bold, underline and italics do typographically in text, but it doesn't say how it is done.  Rather than have to ways to do the same thing, I picked a different way to express emphasis than had already been provided with the other three methods.

For CDA Release 3.0, I think we can simply state that the above classes are assumed to be defined for all CDA Documents.  The use of any other classes or style attributes should be dealt with as if they were extensions.  What CDA has to say about extensions in section 1.4 is this:

... extensions should not change the meaning of any of the standard data items, and receivers must be able to safely ignore these elements. Document recipients must be able to faithfully render the CDA document while ignoring extensions.

I would also be a bit stronger about the use of these classes in Release 3.0 in that we would require that receivers use these style hints in rendering where technically feasible.  The last thing I want is someone to gain an understanding of meaning because of a consistent use of style that someone else disrupts with a different rendering (e.g., by swapping what happens for rendering of underline and italics).

I think this meets the needs of CDA Release 3.0 with respect to what happens regarding rendering, and provides STRONG compatibility with how styling was done in CDA Release 2.0.  The only place where we might have issues is in regard to color, and given that color alone is NOT a good way to deal with conveying information, I would hope that support of extensions to CSS classes, and allowing use of the style attribute would allow the necessary extensibility without creating too many problems.

As far as whether this fits the needs for FHIR, I leave to Grahame to figure out.  I think that we can rely on these classes to support the general needs to descriptive narrative without requiring everyone to have complex layout engines supporting all of CSS.