hl7 / cda-core-xsl Goto Github PK

Hello, is the CDA.xsl the QRDA- III stylesheet? How can we use it to view QRDA-III records if we're using Microsoft 365? We aren't able to download the CDA.xsl file and utilize it.

While the default order of document contents is normally what you want, there are also documents where a user could benefit from a consistent order of contents. To this end the stylesheet should allow configuration of the order of the sections.

• Allow reordering by the user while he is viewing the document versus based on some preconfigured order
  • Reordering on-the-fly while viewing would constitute a significant rewrite of the stylesheet and has need for more javascript. It would likely also introduce a need for cookies to save the ordering choices which could in turn spark a need for cookie permissions. For these reason we think a solution that uses the proven methodology of parametrization is a more probable solution
• Does a configuration need to be document type relative, i.e. need to support a different configuration for XDLAB versus an IPS or may we expect the implementer to feed the relevant set based on the document type
  • E.g. C-CDA[section1,section2,section3] or just section1,section2,section3
• How do we inform the user that he is not necessarily looking at the document as-is, but rather reordered
• We assume that the ordering is based on a list of top-level section/codes
• We assume that any section, not in the provided set of section codes will be rendered after the last section is rendered that is in the set.

Hello,

I was trying to use the CDA.xsl file but I encounter the following NPE. I didn't have much luck trying to resolve it. Does anyone have any experience resolving this?

ERROR:  ''
Exception in thread "main" javax.xml.transform.TransformerException: java.lang.NullPointerException
	at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:783)
	at java.xml/com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:370)

Here is some example code I was using.

         StreamSource source = new StreamSource(xml);
        InputStream is = FileUtils.getInternalFile("cda/CDA.xsl").openStream();
        StreamSource styleSource = new StreamSource(new BufferedReader(new InputStreamReader(is, "UTF-8")));

        TransformerFactory factory = TransformerFactory.newInstance();
        Transformer transformer = factory.newTransformer(styleSource);

        transformer.setParameter("vocFile", Thread.currentThread().getContextClassLoader().getResource("cda/cda_l10n.xml").toString());
        
        StringWriter writer = new StringWriter();
        StreamResult result = new StreamResult(writer);
        transformer.transform(source, result);

Reported by Epic: Base64 rendering does not do any sandboxing or checking when it creates an iframe. This leaves the door open for active content like an html document containing javascript.

Suggestions:

• Do mimetype checking
• Add sandbox attribute to iframe

Came up as a use case through Social Determinants of Health (SDoH). Add support for ClinicalDocument/sdtc:statusCode

Suggested place for rendering is in the document title. Example in Dutch for English "Status: completed"

When Creating Patient Authored Advance Directive Documents, we have come across a need to represent a document that has been “voided” by the Patient.
E.g. Person creates a TX Living Will form while living in TX. Five years later the person moves to MI and creates a new MI Advance Directive Document. The person explicitly voids the TX Living Will because it is no longer relevant. The document was not “entered in error”, it was correctly in place for 5 years. We do want a new version of the document to be registered with the “voided” status so that organizations that have previously retrieved that document will now get the “current version” which will show that this document has been “voided”.
Stylesheet Change Request.pptx

To address this need we are adding a constraint to use the ClinicalDocument/sdtc:statusCode field. Thus, we are requesting that the stylesheet render this extension when it is included in a document.

The CDA.xsl contains a growing header part with documentation. It grows with every release note that gets added.

Bringing the release notes back to a bare minimum and leave the full thing on GitHub to the README and wiki would currently save about 7% or 45kb.

Second reason for externalizing the documentation to GitHub is that it could make it more broadly accessible than it is in the package.

I've created the GitHub wiki that covers what's currently in the CDA.xsl.

I don't want to update more than one place for the same information so I think we should choose which to keep: CDA.xsl documentation or GitHub wiki.

There is one issue left with Internet Explorer 10 and 11: they are unable to render iframes with base64 inline pdf contents.

They also do not support html conditionals anymore, hence that method is unsuitable for detection of these browser versions. This may be possible with a javascript solution, but that might open up new issues.

What currently happens when you send in inline base64 PDF data is this:

Is that good enough or does IE 10/11 warrant enough user base to see what we can do through an alternative browser detection e.g. using javascript?

Hi,

We are using this stylesheet to present ClinicalDocuments to end users and got the question about the dutch translation of the word 'Guardian' which in this XSLT is the word 'Voogd'.

https://github.com/HL7/CDA-core-xsl/blob/master/cda_l10n.xml#L335

The Guardian is the 'legal representative' of the patient but the Dutch word 'Voogd' implies a bit that it's only related to guardians of Children whereas its as far is I understand intended to be the 'legal guardian' for patients when the patient itself is not able to make decisions related to the healthcare received - not only intended for Children.

How about changing this translation 'Voogd' into e.g. "wettelijke vertegenwoordiger" or something else?

Kind regards,

Remco van der Werf
Enovation

When you have a(n inline) pdf in your CDA, this is rendered using an iframe. Below iframe nothing is rendered anymore although the footer should have been there. This is extra inconvenient when the pdf is in section that is followed by other sections.

The solution is to not write <iframe .../> but rather have a separate closing tag. To force that, you may put a space in between so <iframe ...> </iframe>. This space does not have any visual impact on the rendering other than making the following html reappear.

Reference: jekyll/jekyll#346.