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.

Monday, January 10, 2011


@motocycle_guy: @omowizard An archetype, a DCM and a template walk into an #HL7WGM event, stroll up to the bar ... and the bartender says...

@omowizard: @motorcycle_guy ...identical triplets I presume! #HL7WGM

Well, not quite identical, but certainly they share the same parents, intellectually at least.
From the HL7 Perspective:
A Detailed Clinical Model is an information model of a discrete set of precise clinical knowledge which can be used in a variety of contexts. (see the HL7 Conceptual Definition).

A Template is a collection of contraints that can be applied to a model [based on a pronouncement by LLoyd McKenzie at the last MnM/SDWG Meeting of the day, so it must be true ;-) ].  It's also defined in nearly the same words in the HL7 Templates DSTUA template is an expression of a set of constraints on the RIM or a RIM derived model that is used to apply additional constraints to a portion of an instance of data which is expressed in terms of some other Static Model.
Given that the HL7 process works via refinement on the RIM, a Detailed Clinical Model is a refinement of the RIM information model providing a discrete set of precise clinical knowledge...
Which makes it an expression of a set constraints on a RIM derived model, which makes it a template.
Now, quoting from the openEHR perspective (see page 8 of Archetype Definitions and Principles [pdf])
An archetype is a computable expression of a domain content model in the form of structured constraint statements, based on a reference (information) model.
And, a template is: a directly locally usable definition which composes archetypes into a larger structures often corresponding to a screen form, document, report or message. A templates may add further local constraints on the archetypes it mentions, including removing or mandating optional sections, and may define default values. 
But, an openEHR archetype is further specified: openEHR archetypes are based on the openEHR reference model.
So, an HL7 DCM is an archetype, but not an openEHR archetype because is derived from the HL7 Reference model rather than the openEHR reference model (and I think a blog post comparing the two is worth doing).
And an openEHR notion of a template is a collection of constrainsts on screen forms, documents, reports or messages, which means that it is a subset of HL7 templates.  What an openEHR template doesn't include are the set of constraints which make up the detailed clinical model (which HL7 could also express as a template).  These are what we would call document or section templates in HL7 or IHE, and the "DCMs" are what HL7 IHE would describe as a deeper refinement of "Entry Templates" on CDA.
The amount of precision in these fine distinctions is about as useful as trying to cut butter with a lazer.  It may be very precise, but all it really does is get in the way of breakfast.  But, as @omowizard points out, it didn't get in the way of dinner.
So, how do we take the collective intelligence of these two organizations forward.  I would propose a trial project covered by an MOU between the two organizations.  Let's have openEHR provide resources to help HL7 put together DCMs for some stuff, and then, using the outputs of that, have HL7 ballot the materials as a DSTU which would be shared content across both organizations.
That's liable to get me some strange looks in certain circles, especially back in some camps where openEHR isn't even mentioned and the great evil is that other XML perpetuated by yet another organization.
But what can I say?  We've already learned so much from CCD, let's give it another go.  After all, if the project fails, we've lost little, and if it succeeds ...