| |
|
|
CDA Implementation Guides - (not) invented herePublication date: Apr 17, 2013
Although inspired by the upcoming creation of a Dutch CDA implementation guide the issue addressed by this column applies to other settings as well:
what if one has to create a national CDA implementation guide for a use-case that’s similar to that of the (US-specific) CCD – should one try and
adapt that US-specific implementation guide, use some universal implementation guide instead, or look for other CDA implementation guides (e.g.
from neighboring countries) that are likely to fit with the Dutch –specific requirements? What are the criteria for deciding what implementation
guide or existing templates one should look at as a source of inspiration?
Let’s have a look at some of the details of the Dutch project: the Dutch federation of university hospitals (Dutch acronym: NFU), in cooperation with Nictiz (the coordinating body for the use of healthcare IT standards in the Netherlands) have defined the requirements for the ‘referral/transfer of care’ scenario. The data set is based on the 17 sections as defined by the ASTM CCR. The data set has been defined as a set of DCMs – independent of any implementation syntax such as CDA R2. The next issue up for discussion in this project is the question as to (and I quote) “what specification should be used as the basis for this Dutch project: CCD 1.0, CCD 1.1, consolidated CDA (C-CDA), CDA R2 with extensions or some other specification?” Some of the key choices are related to
Open v. Closed TemplatesOne of the choices a project has to make is whether the requirements will be specified in the form of open templates (some minimalistic requirements are listed, but other data may be supplied as well) or closed templates (the requirements are listed, no other data nor data elements may be supplied). Open templates have the advantage that they allow for extensions above and beyond the minimal requirements; closed templates have the advantage that they can fully validated and that they are much easier to implement.Almost all current CDA R2 implementations are based on open templates, the English NHS uses closed templates. The Dutch project has used DCMs to express the requirements. A DCM captures all of the requirements (although some of those may be optional), the equivalent at the CDA implementation level is a closed template. However, there is a rule that states that one has the ability to create an 'extended DCM' (a superset of another DCM), at the CDA implementation level this is yet another closed template. A vendor, or software implementer doesn't have the option of adding data to a CDA instance without defining a new 'extended DCM' and a corresponding new template. The drawback of using closed templates is that there are very few tools that actually support their validation. Choice of Template ManagerEspecially if one uses open templates one has to have a registry of templates, and a template manager/editor to define, document, and manage the templates and their relationships. There are two main (open source) candidates: MDHT (mainly used in the US) and ART-DECOR (mainly used in some European countries).Both of these tools allow one to define templates using their own domain specific language (DSL). The template definitions are used as the basis for model driven validation (MDHT, which generates validation source code) or Schematron based validation (ART-DECOR). See this whitepaper for details of those two validation methods. For the Dutch project the choice of tooling is influenced by a couple of things: Nictiz, one of the partners in the project, is one of the main sponsors of the ART-DECOR toolkit. To me the use of this toolkit for this project has two disadvantages: it uses Schematron based validation instead of model based validation, and it doesn’t contain a library of the CCD/C-CDA/IHE MS templates (should this project wish to re-use any existing templates). The Dutch requirements are captured as DCMs (and expressed as XMI files) – regardless of the tool being chosen one would hope (for scalability reasons) there would be a semi-automated process of mapping the requirements (DCMs) to the template DSL as used by the toolkit. Existing CDA implementation guidesThe CCD (or its successor: the consolidated CDA a.k.a. C-CDA) is a widely known and implemented specification. It’s available in English, which eases international re-use. There are tons of online discussions, blog posts and other information about the CCD – but that doesn’t necessarily mean it’s a good match for the Dutch specific requirements. There is an alternative with a universal scope: the IHE Medical Summary CDA Implementation guide (IHE MS, defined in the IHE PCC profile). The IHE MS specification was part of the reconciliation work that lead to the C-CDA specification, and IHE is currently working on updating IHE MS to be the universal variant of C-CDA.In 2009 I wrote a blogpost about the HL7 roadmap for CDA R3 and the CCD – which among other things discusses the relationship between the US and the Universal CDA implementation guides. The European epSOS implementation guide may prove to be a good source for some templates – one should question the quality of some of the templates that were created as part of this project - some parts however are likely to be reusable. The German Discharge Letter implementation guide (eArztbrief) should probably also be looked at: this is the base specification used by other German speaking countries such as Austria, Switzerland and Luxembourg. There are UK NHS (rather NHS specific), French DMP and Finnish CDA specifications (re-used in some of the Baltic countries). The latter are a fine example of a set of high-quality CDA implementation guides that are inaccessible to most readers because of the language barrier. There are some Dutch CDA implementation guides as well, related to Laboratory/Pathology and Perinatology observations. There is no way of knowing whether any CDA existing implementation guide covers the requirements of a subsequent project. The Dutch project defined its requirements without looking at any pre-existing CDA template definitions (well, they did actually look at the CCD templates to verify whether they captured all of the requirements, and they looked at vendor applications to see if thsoe had the capability to send certain data items). The requirements contain lots of terminology bindings that are Dutch specific. As such the chances of re-using a significant portion of existing (US specific) CCD/C-CDA templates is rather small. The IHE MS specification isn’t country specific, as such there is a much lower risk of there being a clash between the IHE MS specification and the Dutch requirements. RecommendationTo reiterate the question for the Dutch project: “what specification should be used as the basis for this Dutch project: CCD 1.0, CCD 1.1, consolidated CDA (C-CDA), CDA R2 with extensions or some other specification?” Given that the requirements have been modeled without looking at any existing CDA templates in mind I’d use CDA R2 with extensions, without actually trying to re-use any existing CDA templates. I would certainly look at those other implementation guides (starting with the current Dutch CDA Implementation Guides) to validate whether or not the Dutch requirements have been accurately captured.In general, the chances that one can re-use an existing country-specific implementation guide in another country are quite low. If one disregards any bindings related to vocabularies and identification schemes, and the impact of administrative/legal requirements on the scope of the data, then yes, one may indeed be able to re-use the remainder of the specification. Although IHE MS, because of its universal flexibilities, may never be a widely implemented specification, it is currently the best starting point if one has to create a national CDA specification. -Rene
PermaLink to this page: http://www.ringholm.com/column/CDA_Implementation_Guide_not_invented_here.htm
Index of columns:
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards. |
Rene is the Tutor-in-chief of Ringholm. [e-mail] |