Skip to end of metadata
Go to start of metadata

The CDA Release 2.0 and 2.1 publications come with an informative stylesheet based on XSLT 1.0. The stylesheet is maintained under responsibility of the Structured Documents Workgroup.

All contents and further documentation may be found:

Security Fix workspace

Last week (September 16, 2020) a security issue in the generic stylesheet for display surfaced. This has been fixed in version 4.0.2 beta 8 and further refined in subsequent betas. At the virtual HL7 WGM September 2020 we held a meeting on what happened, who do we inform, how do we do that, what do we tell them.

This keeps track of action items (until we have a better place):

Where can I find a clean copy with no known security vulnerabilities? - check latest beta of v4.0.2 or up. 

1. Scheduled time with StrucDoc for approval to formally release CDA XSL 4.0.2 with the fixes → Tabled to talk to Wayne Kubick

2. Consider adding sandbox to iframes with PDF which is now exempted. Found it. This documents that plug-ins are disallowed, which means pdf rendering is out when sandboxing is on

  • Alexander Henket Find documentation on how sandboxing affects PDF
  • Alexander Henket SDWG: Implement a stylesheet parameter that sandboxes pdf by default but might be switched on locally

3. Created a Github wiki page to support communication and linked that from the front page:

4. Deactivated the older Gforge downloads for the stylesheet in the Structured Documents project  to avoid new downloads from there

5. Looking in the master grid with family CDA sorted by date, checking every standard without a date and everything on/after Jan 23, 2018. CCDA 2.1 refers for the XSL (but to GForge), CDAR2_IG_CCDA_CLINNOTES_R1_DSTU2.1_2015AUG_2019JUNwith_errata actually contains version 4.0.1 inside which means vulnerable. HL7 IPS refers for the stylesheet, but to Gforge HL7 CDA® R2 IG: C-CDA Templates for Clinical Notes R2.1 Companion Guide, Release 2 - US Realm Contains stylesheet v4.0.1 hence vulnerable

Other observations are that lots of publications with samples don't have a reference to the XSL at all or to the Lantana version. PHER has lots of CDA support zips in GForge. As far as I can tell all of those contain just xml and schematron or Lantanas version of the stylesheet.

I've seen various publications use version 3.x of the cda.xsl and/or Lantana 'forks' of version 3.x. These are not proven to be vulnerable but could benefit from better references to the current version of the stylesheet

  • Lisa R. Nelson Identify publication packages at that contain vulnerable versions of the CDA Stylesheet
  • Lisa R. Nelson Setup how to talk to other workgroups that publish CDA based specifications and need to be informed
  • Lisa R. Nelson Gather 'intel' on how to compile an effective readme to be added to publication packages. This should be pointing users to the right locations, rather than unnecessarily including things in the packages that run outdated

For the readme.txt

HL7 International has a general purpose rendering stylesheet for CDA. This stylesheet comes without warranty and should be locally tested by implementers before production release.

Find the CDA Stylesheet repository here:
These materials were tested with:
Or alternatively you may get the latest version here:

Proposed _readme.txt Template

A scan of 12 different readme.txt files from various different CDA IG download packages were studies to determine a common, best practice set of content to include.  A best practice format was also devised by reviewing what has been done previous. The analysis also produced findings about what a readme.txt file needed to include for an errata package, so that information was included in the readme template. A sample errata list file was also prepared.

Proposed _readme.txt template: _readme TEMPLATE R1 US INF1.0.0 20200925.txt

Sample errata list file: _Product_R1_US_STU4.0.0_Errata_List_2020-09-25 SAMPLE.xlsx

6. In the process Austin Kreisler made us aware that the CDA Stylesheet publication process normally never went past beta. This was to signal users they have an obligation to test the final bits and pieces before putting it into production in their own environments. This bit of the publication process was not known/followed as of version 4.0.0 of the stylesheet and as such version 4.0.0 and 4.0.1 have a 'stable' status, and the notion that testing by implementers is in required, was deferred to the that comes with the stylesheet. Also due to differences in how GitHub publications work versus how GForge publications used to work, this may be reconsidered. After discussion with Wayne Kubick on that policy, it was decided that SDWG will put discussion on the policy on the agenda. Publishing beta versions instead of stable or production versions is re-instated until such time that policy is revised.

  • No labels