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.