There are some who feel that a move to CDA for electronic prescribing is a better option than using HL7 V2 messages. I would contend that this is seriously misguided.
Prescribing is in effect an ordering activity and orders have line items and are not documents in any logical sense. While printed prescriptions may appear to be documents to a casual observer they are in fact a collection of orders and as is usually the case with orders each line item has state that changes in an independent fashion form the other line items. It is not uncommon the cancel an order, or modify the dose or form and this needs to be done at a line item level, not a document level. In effect each line item has methods to change its state, eg from ordered to cancelled or to update it. In a similar fashion the dispenser may substitute one line item for another or decide to cancel one line item. Also they may want to forward one line item to another dispenser, but dispense the others. In effect each drug order is an object with state and methods which supports an extensive array of methods that change its state and allow these state changes to be notified. A brief glance at the HL7 V2 Medication standard produced by Standards Australia with show a vast array of interactions and state changes rather than transfers of simple documents. Supporting these with a document is messy at best as the document is supposed to be static, when in fact every line item is dynamic with a life of its own. To do this with CDA would require adding all the methods as external logic and result in a huge number of new documents, without any good mechanism to identify which line item was changing.
In contrast HL7 V2 has a mature and if need be complex array of ways to effect these state changes. The challenge to is fact to define what you want to eliminate to make it easier to implement rather than a complete lack of abilities. Having a mechanism that supports the full range of state changes may seem complex at first, but ignoring the complexity of the real environment and going for a simple document solution may seem attractive at first but the pain is merely delayed as the lack of support for the know use cases will make future changes extremely difficult and the document model is wrong.
To suggest that CDA is more advanced is wrong. It is a technology that is still under development and a move to V3 of CDA, which is not backward compatible, is planned. The HL7 V3 medication messaging model would be more suitable, but is not ready and in a similar fashion there are changes planned with a move to V2 of the HL7 V3 data types (and V3 of the CDA standard).
We have a standard and well defined use cases in HL7 V2 and know that the model can support the rich interactions that should be part of the future. With CDA we have a trendy document format, never designed for Medication orders, and unproven in this role. The basic functionality of sending a document would be relatively easy, but that is the tip of the iceberg and all other interactions will involve re-engineering the order interactions that have been a proven part of v2 orders for many years. Its fools gold and will not provide us with a path to the future, but will be an expensive diversion. If HL7 V3 is the target we need Medication Messaging and not documents. Medication messaging is harder because the use cases are harder.
What we have in CDA is a solution for the easiest use case, but no path to a rich eHealth landscape.