Convert your FHIR JSON -> XML and back here. The CDA Book is sometimes listed for Kindle here and it is also SHIPPING from Amazon! See here for Errata.

Tuesday, March 26, 2013

The Map is not the Territory

I get asked a lot how someone should structure their database to support generating or using CDA documents with some sort of application.  I always find it challenging to answer these questions, because I don't have a one-size-fits-all answer.  It really does depend on what you are trying to do.

The HL7 CDA standard is designed principally to serve as electronic documentation of an encounter with a healthcare provider.  For some applications, that is directly in line with what they do (e.g., EHR systems).  For others, that's not their main purpose.  A Clinical Decision Support application can use CDA to capture and communicate specific data elements to implement its workflow, either as input or output.  An analytics application can survey CDA documents and gather statistics suitable for computation of quality measures and development of dashboarding applications.  Another kind of application could do disease surveillance.  So the CDA Model (the map), may or may not be well aligned with the way you need information to be structured (the territory).

One of my least favorite forms of this question is how can I get JAXB to map the CDA Schema to my database.  My head just explodes.  I understand the desire to get a computer to do the mapping.    But I've mapped CDA, CCR, and numerous other models of healthcare information into existing database structures.  I've also mapped them into brand-new structures that are purpose designed for my application.  I have never been able, except for the simplest of things, to go from exchange format to useful database structures or object models, without significant human intervention.  The introduction of the smallest bit of recursion, or data type dependency leads to the need for manual guidance.

Nor have I ever designed the data structures or models of an application to serve the interchange formats.  I've always preferred to design the model to serve the purpose for which it is being used, rather than around how I get the data.  The reason for this is that data exchange events are generally rare as compared to general use of the data processing internally in the systems I'm working with.

I really don't want to bear exchange (e.g., data marshaling) costs during data processing.  A simple example of what I mean:  It's far more efficient for a CPU to process some data in binary form (e.g., for integer and floating point arithmetic).  However, it can also compute in BCD (Binary Coded Decimal format), and it's much easier to get data into and out of BCD than it is in binary formats for integers or IEEE floating point arithmetic.  Is that a good reason to keep it in that form?

When you look at the efficiency in computation gained by performing calculations in a format that is better suited, the answer is a resounding no.  The number of times that you must convert from compute friendly formats to exchange friendly formats and back is small enough that it is well worth while to go to a compute friendly structure as soon as possible.

So, should you ask me what database structures you should use, don't be surprised if I ask what you are doing, and if my response has nothing to do with CDA whatsoever.


  1. Looking at the experiences of those CDA implementers who presented their work to the HL7 RIMBAA group (HL7s software implementers) - we haven't seen any attempts to create a database model based on the CDA interchange format. It would just add complexity without a lot of benefits.

    We have seen implementations based on XML databases, but you effectively have to morph the XML IT expression of the CDA into a RIM-based XML ITS in order to create XML element names that are queryable using XML query techniques.

    Yes, one could persist a series chunks of a CDA instance - I fail to see how that would actually help anything.

    The other option, not for the faint hearted, is to create a persistence model based on the RIM itself (=not an exchange model). This is however only really useful for certain kinds of projects that collect all sorts of data from all sorts of sources. If you only ever are going to receive C-CDA (for ex.) uch an approach would be overkill.

  2. I think the reciprocal of this is when talking with a good number of people from HL7 and discussing the issues with trying to map CDA documents into a systems data model and they say, "Well just put it into your rim based database." And it's all you can do not to punch them in the face.

    1. I do understand the temptation. In my experience, it is hard to find that many HL7 people delivering real products that use a RIM-based database.