CDA -> FHIR : Working Backwards to go Forwards

I've been spending quite a bit of time on various FHIR and CDA related topics.  As I mentioned a bit ago, I got distracted by conversions of FHIR JSON to XML and back.  There was a reason for that, as there was a piece of FHIR JSON I wanted in XML so that I could convert it to CDA.

So why am I working backwards on the CDA -> FHIR side?  It could be that you start with what you know.  Or it could be that I figured it would be easier to reverse the process once I figured out how to do it from a different direction.  As the case may be, I've made some progress.

Here's what I did:

1. I download the CDA Templates from the C-CDA DSTU 2.1 Release using Trifolia.
2. I selectively annotated some of the entry templates (section and document templates are boring for the most part) with markup explaining how to map the CDA entry to a FHIR Resource or component thereof.
3. I wrote some utility stuff to map certain CDA basic data types to the FHIR equivalents (I have a similar set for the reverse mapping already done).
4. I wrote a code generator (in XSLT) that generated an XSLT stylesheet from the Template XML I downloaded.
5. I wrote another XSLT that managed the basic parts of the CDA Document to FHIR Bundle conversion, and invoked templates in the stylesheet I automatically generated.

The end result is that I have a model driven transform of CDA to FHIR, and I can probably take the same stuff and figure out how to reverse it.

There's some things that don't quite work because they appear in different orders in CDA and FHIR. For example, the identifiers in a Problem Observation appear AFTER some data in the Problem Act. Since my transform processes things in CDA order (at least for now), it generates some not-quite-correct output.  However, that output is close enough for me to figure out how to address that problem later.  I could probably even use my JSON/XML translator to help with the cleanup [oh damn, there went more sleep as I just came up with that].

   -- Keith