I have a couple of XSLT design patterns that I've been using and improving over the past decade, which I pulled out again last night to do some FHIR to CDA transformations. XSLT isn't what you'd call a strongly object oriented language, nor a strongly typed one. However, the design patterns I used borrow from experiences I've had with strongly typed, object oriented languages such as Java.
The design pattern is a general one which I've used for a number of strongly typed schema to schema conversions. FHIR to CDA is just one example. V2 XML to CDA (or back) is another one, and I've also done this for CDA to ebXML (XDS related work), and at one point for CCR and CDA, even though I'd never really call CCR strongly typed.
The first design pattern is in how I define my transformations. There are two ways in which you can call a template, and they have different benefits. Sometimes you want to use one, and sometimes you want to use the other. When going from one format to another in XML, usually there is a target element that you are trying to create, and one or more source elements you are trying to create it from.
My first method uses apply-templates.
<xsl:apply-templates select='...' mode='target-element-name'/>
You can also call apply-templates with parameters.
<xsl:apply-templates select='...' mode='target-element-name'>
<xsl:with-param name='some-param' select='some-value'/>
</xsl:apply-templates>
This is pretty straight forward. I use mode on my transformation templates for a variety of reasons, one of which is that it allows you to build transformation trees that the XSLT engine automates processing with. More often that not, the name of the mode is the output element I'm targeting to generate.
The second method works more like a traditional function call, using call-template:
<xsl:call-template name='target-element-name'>
<xsl:with-param name='this' select='the-source-element-to-transform'/>
<xsl:with-param name='some-param' select='some-value'/>
</xsl:call-template>
Now, if the source element is always the same for a given target element (e.g., a FHIR address going to a CDA addr element), you create your actual template signature thus:
<xsl:template name='addr' mode='addr' match='address'>
<xsl:param name='this' select='.'/>
...
Note that name and mode are the same. What you want to create here is an <addr> element in CDA. The input you want to convert is a FHIR address element (I checked several dozen places, just about everywhere the Address datatype is used, it is always called address in FHIR resources). So that explains the first line. The name of the template, and its mode, identity what you are trying to create.
The second line is critical, and it has some serious impact on how you write your templates. Instead of assuming a default context for your transformation, the <xsl:param name='this' select='.'/> sets up a parameter in which you can explicitly pass the transformation context, but which will implicitly use the current context if no such parameter is passed. When you write your transformation, you have to be careful to use $this consistently, or you'll have some hard to find bugs, because sometimes it might work (e.g., when called using apply-templates), but other times not (e.g., when called using call-template). It takes some diligence to write templates this way, but after a while you get used to it.
Here's the example for converting a FHIR Address to a CDA addr element. It's pretty obvious:
<xsl:template name='addr' mode='addr' match='address'>
<xsl:param name='this' select='.'/>
<xsl:variable name='use'><xsl:choose>
<xsl:when test='$this/use/@value="home"'>H</xsl:when>
<xsl:when test='$this/use/@value="work"'>WP</xsl:when>
<xsl:when test='$this/use/@value="temp"'>TMP</xsl:when>
</xsl:choose></xsl:variable>
<addr>
<xsl:if test='$use!=""'>
<xsl:attribute name='use'><xsl:value-of select='$use'/></xsl:attribute>
</xsl:if>
<xsl:for-each select='$this/line'>
<streetAddressLine><xsl:value-of select='@value'/></streetAddressLine>
</xsl:for-each>
<xsl:for-each select='$this/city'>
<city><xsl:value-of select='@value'/></city>
</xsl:for-each>
<xsl:for-each select='$this/state'>
<state><xsl:value-of select='@value'/></state>
</xsl:for-each>
<xsl:for-each select='$this/postalCode'>
<postalCode><xsl:value-of select='@value'/></postalCode>
</xsl:for-each>
<xsl:for-each select='$this/country'>
<country><xsl:value-of select='@value'/></country>
</xsl:for-each>
</addr>
</xsl:template>
Or, you can also do it this way:
<xsl:call-template name='addr'>
<xsl:with-param name='this' select='$patient/address'/>
</xsl:call-template>
In that case, you have two templates with the same mode, but different match criteria. AND, you have a named template. Let's presume in the FHIR case, you want to map Resource.id and Resource.identifier to an id data type (it's not to far-fetched an idea, even if not one I would use). You then write:
<xsl:template mode='id' match='id'>
...
</xsl:template>
The design pattern is a general one which I've used for a number of strongly typed schema to schema conversions. FHIR to CDA is just one example. V2 XML to CDA (or back) is another one, and I've also done this for CDA to ebXML (XDS related work), and at one point for CCR and CDA, even though I'd never really call CCR strongly typed.
The first design pattern is in how I define my transformations. There are two ways in which you can call a template, and they have different benefits. Sometimes you want to use one, and sometimes you want to use the other. When going from one format to another in XML, usually there is a target element that you are trying to create, and one or more source elements you are trying to create it from.
My first method uses apply-templates.
<xsl:apply-templates select='...' mode='target-element-name'/>
You can also call apply-templates with parameters.
<xsl:apply-templates select='...' mode='target-element-name'>
<xsl:with-param name='some-param' select='some-value'/>
</xsl:apply-templates>
The second method works more like a traditional function call, using call-template:
<xsl:call-template name='target-element-name'>
<xsl:with-param name='this' select='the-source-element-to-transform'/>
<xsl:with-param name='some-param' select='some-value'/>
</xsl:call-template>
Now, if the source element is always the same for a given target element (e.g., a FHIR address going to a CDA addr element), you create your actual template signature thus:
<xsl:template name='addr' mode='addr' match='address'>
<xsl:param name='this' select='.'/>
...
Note that name and mode are the same. What you want to create here is an <addr> element in CDA. The input you want to convert is a FHIR address element (I checked several dozen places, just about everywhere the Address datatype is used, it is always called address in FHIR resources). So that explains the first line. The name of the template, and its mode, identity what you are trying to create.
The second line is critical, and it has some serious impact on how you write your templates. Instead of assuming a default context for your transformation, the <xsl:param name='this' select='.'/> sets up a parameter in which you can explicitly pass the transformation context, but which will implicitly use the current context if no such parameter is passed. When you write your transformation, you have to be careful to use $this consistently, or you'll have some hard to find bugs, because sometimes it might work (e.g., when called using apply-templates), but other times not (e.g., when called using call-template). It takes some diligence to write templates this way, but after a while you get used to it.
Here's the example for converting a FHIR Address to a CDA addr element. It's pretty obvious:
<xsl:template name='addr' mode='addr' match='address'>
<xsl:param name='this' select='.'/>
<xsl:variable name='use'><xsl:choose>
<xsl:when test='$this/use/@value="home"'>H</xsl:when>
<xsl:when test='$this/use/@value="work"'>WP</xsl:when>
<xsl:when test='$this/use/@value="temp"'>TMP</xsl:when>
</xsl:choose></xsl:variable>
<addr>
<xsl:if test='$use!=""'>
<xsl:attribute name='use'><xsl:value-of select='$use'/></xsl:attribute>
</xsl:if>
<xsl:for-each select='$this/line'>
<streetAddressLine><xsl:value-of select='@value'/></streetAddressLine>
</xsl:for-each>
<xsl:for-each select='$this/city'>
<city><xsl:value-of select='@value'/></city>
</xsl:for-each>
<xsl:for-each select='$this/state'>
<state><xsl:value-of select='@value'/></state>
</xsl:for-each>
<xsl:for-each select='$this/postalCode'>
<postalCode><xsl:value-of select='@value'/></postalCode>
</xsl:for-each>
<xsl:for-each select='$this/country'>
<country><xsl:value-of select='@value'/></country>
</xsl:for-each>
</addr>
</xsl:template>
[There's a little XSLT shorthand nugget in the above transform, another design pattern I use a lot:
<xsl:for-each select='x'> ... </xsl:for-each>
is a much simpler way to say:
<xsl:if test='count(x) != 0'> ... transform each x ... </xsl:if>
especially when x is a collection of items.]
Now, if you want to drop an address in somewhere, you can do something like this:
<xsl:apply-templates select='address' mode='addr'/>Or, you can also do it this way:
<xsl:call-template name='addr'>
<xsl:with-param name='this' select='$patient/address'/>
</xsl:call-template>
Either works, and in developing large scale transformations, I often find myself using the same template in different ways. The elegance of this design pattern in XSLT extends further when you have two or more source elements going to the same target element.
In that case, you have two templates with the same mode, but different match criteria. AND, you have a named template. Let's presume in the FHIR case, you want to map Resource.id and Resource.identifier to an id data type (it's not to far-fetched an idea, even if not one I would use). You then write:
<xsl:template mode='id' match='id'>
...
</xsl:template>
<xsl:template mode='id' match='identifier'>
...
</xsl:template>
<xsl:template name='id'>
<xsl:param name='this'/>
<xsl:apply-templates select='$this' mode='id'/>
</xsl:template>
</xsl:template>
<xsl:template name='id'>
<xsl:param name='this'/>
<xsl:apply-templates select='$this' mode='id'/>
</xsl:template>
And the final named template simply uses the match type to automatically select the appropriate template to use based on your input value.
Sometimes you want to create an output element but it isn't always called the same thing, even though it uses the same internal structure. Using default parameters, you can set this up. Let's look into example above. Not EVERY id element is named id. Sometimes in CDA the have a different name depending on what is being identified. For example, in the CDA header, you have setId (in fact it's nearly the only case for id). A more obvious case is code. Most of the time, code is just code, but sometimes it's ____Code (e.g., priorityCode), but the general structure of a priorityCode (CE CWE [0..1]) is pretty much the same as for code (CD CWE [0..1]). So, if you were going to convert a FHIR CodableConcept or Coding to a CDA CD/CE data type, you might use the same transformation.
<xsl:template mode='code' match='code' name='code'>
<xsl:param name='element' select='"code"'/>
<xsl:element name='$name'>
...
</xsl:element>
</xsl:template>
You get the idea. Usually, you want to generate <code>, and so you say nothing. Sometimes you want to generate something different, and so you add a parameter.
<xsl:call-template name='code'>
<xsl:with-param name='this' select='$that/code'/>
<xsl:with-param name='element' select='"priorityCode"'/>
</xsl:call-template>
Remember you can also pass parameters using apply-templates, so this also works:
<xsl:apply-templates select='$that/code'>
<xsl:with-param name='element' select='"priorityCode"'/>
</xsl:apply-templates>
Enough chatter, back to work. HIMSS is only a couple of days away.
- Keith
P.S. I've missed being able to post while I've been heads down working towards HIMSS and the Interop showcase. Hopefully I'll get more time when I get back.
No comments:
Post a Comment