CDA Stylesheet Control

Apr 27, 2011

We’ve been having a rather intense debate within NEHTA about stylesheet control with a CDA implementation community. The context here is that you have a nationally sponsored CDA implementation guide, and a community that is built around that. The community have trading partner agreements, and there is CCA testing at the point of entry to the community. In addition, the CDA documents that are exchanged within the community will also be archived into some wider form of EHR either immediately, or in the future. (Application doesn’t really matter, but could be Diagnostic Reporting, Prescribe/dispense, Discharge Summary, Shared Health Summary, Procedural note, etc)

The question is how the stylesheets should be managed. Generally, there’s the following 3 choices:

  • Author provides the stylesheet that is used whenever the CDA document is displayed
  • Community agrees to a single stylesheet that is always used
  • The receiving application provides it’s own stylesheet

The CDA specification is actually pretty loose here:

the contents of the Section.text field must rendered per the rules defined inSection Narrative Block (§ 4.3.5 ) rendering of the CDA document header is at the discretion of the recipient

While HL7 provides cda.xsl with the CDA specification, it is not required that documents render “properly” with that stylesheet, though many implementation guides require that a document should render properly with it. Part of the problem is that “properly” can only be understood in terms of section 4.3.5 which is descriptive rather than proscriptive.

In particular, there’s still a lot that is open to stylesheets - colors, fonts, borders on tables, how to squeeze space out of the screen/page, what html structures to use, which browsers to target, and most of all, how to handle attachments. (On a related note - the HL7 cda.xsl has several issues in this space, and only primitive support for handling image attachments.)

What else can you do with a style sheet? Well, you can first of all define your own styles for use in the styleCode attribute - your corporate look and feel, for instance. And on that subject, you can do more corporate branding like including images and stylesheets from your own web site, and make the CDA document rendering look exactly like how you want. And, in fact, you can define entities in the xml that are expanded out to commonly used sentences in the stylesheets and really save space. (Yep, people keep putting this to me as an option at CDA training courses).

So obviously it’s best to let the authors provide their own stylesheets, and send the stylesheets around with the document, and you always use the specified stylesheet when viewing that particular document. After all, this is the point of Keith Boone’s self-displaying CDA.

But wait a minute….

The biggest problem I have with this is that systems can’t just use any stylesheet. Firstly, when it comes to image attachments, how they must be handled depends on the system architecture - do they just spawn a browser as a separate process to view the CDA document (which browser?) - and how do they secure that? Or maybe they use an internal web browser control, and control the way that images are provided from their own resources? Or maybe it’s a web server anyway, and things are even more complicated? Are these systems supposed to auto-import any old transform? And on that subject, how on earth would you secure that?

You can see the implications of this in the long list of things a self-displaying CDA document isn’t allowed to do, such as have images in it.

I’m not sure that you can build an infrastructure where the author is allowed to send custom stylesheets. Even if you could somehow prevent them from abusing that - given that you could even define what abuse was - there’s still too many dangerous things for an author to do and depend on for a receiving system to fail on. Not safe at all.

So maybe the receiver should do it. They could just make their own decisions…. that makes sense, because they are the ones who know how much context is shown by the application, what the screen they are targeting is (yay iPhone!), what standard look and feel they have in their application (fonts, colors, operating systems etc)

But then how can an author be confident that their document renders properly - after all, they’re on the hook for that. How do they test?

I think the best thing is for the community to specify a single transforms. Authors have to test by the standard transform. Receivers have to implement the standard transform as best as they are able to given their Operating System and output constraints.

I don’t know quite how you would do CCA on their use of the transform.I suspect it’s going to come back to human testing in a consensus environment.

NEHTA has had a robust discussion about this issue. Over time we’ve gradually converged one what I think is the least worst approach: for the community to define a single stylesheet, and everyone to target that one as best they can.

Which leaves open for us the question of how much of the CDA header should be displayed by the stylesheet, and how much delegated to the application. Perhaps the answer is that nothing delegated to the application. The application could choose to display it’s current patient details, for instance, but should still be required to display the patient details embedded in the CDA document, since they might have changed…