@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 DSTU: A 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 ...
Keith,
ReplyDeleteDelighted to see these developments. I am an independent Clinical analyst working primarily with Ocean Informatics on a variety of openEHR based projects.
I largely agree with your analysis above but I think the current description (from the openEHR website) of openEHR templates is a little outdated and misleading. In fact openEHR templates can be modelled at levels below the CDA Section equivalent. For instance in an openEHR paediatric application I am working on, we use Templates to further constrain various openEHR international archetypes down to that specific use-case . In HL7 terms it would be quite possible to produce 'Clinical Statement' level templates that 'clinically' match the templates in CCD identically (leaving aside tricky issues of reference model alignment!!). I think there is a group in Germany actually working on this but I am not sure how far this has progressed.
The key difference, I think, between openEHR archetypes and HL7 templates is that archetypes are modelled 'inclusively' or maximally and then constrained down to specific use-cases within openEHR templates. Whereas HL7 templates, at least currently, are content-wise much more restricted and closer to openEHR templates i.e. heavily constrained down to a specific use-case(s). As I understand the HL7 DCM work, this is philosophically closer to the archetype in capturing a wide range of possible content, which will then have to constrained down for specific use-cases such as CCD. So I see DCM ==archetypes and openEHR Templates== HL7 Templates. The key difference is that openEHR templates are a constraint on archetypes rather than a direct constraint on the Information model as for HL7 Templates. Current openEHR templates use an Ocean format (.oet) but the proposed openEHR official model makes archetypes and openEHR templates technically identical allowing multiply layered constraint.
I look forward to further discussion.
Ian
hi Keith
ReplyDeleteAlmost sounds like you were in patient care this afternoon, where we decided to do something that sounded incredibly similar
"how do we take the collective intelligence of these two organizations forward." and "After all, if the project fails, we've lost little, and if it succeeds ..." - exactly.
ReplyDeleteThis is exactly the reason why we organized a joint HL7 RIMBAA WG / OpenEHR Implementers meeting during the current Sydney WGM. It's focus is not on modeling, but on software implementation aspects of Reference Model and Acrchetype/DCM/Template software applications. We should focus on the common areas shared by both.
See http://wiki.hl7.org/index.php?title=RIMBAA_201101_Agenda for the agenda/minutes of this joint HL7/OpenEHR implementers meeting.
Following on from Ian McNicoll's description, let me illustrate a shortcoming of the HL7 template approach as the major constraint mechanism for CDA, where the template constrains down to a specific use-case, namely CCD, and its many further templated constraints, e.g. via IHE PCC.
ReplyDeleteWe end up with no way to extract blood pressure from a CCD vital signs section, because we have no underlying structural definition of blood pressure! Computationally, it is impossible from a CCD instance, and all its attendant templates, to know if a blood pressure comprises a systolic and a diastolic value. It might just as well be comprised of a diastolic and head circumference value.
On the other hand, openEHR archetypes can provide this information consistently and reliably.
It seems to me that HL7 needs archetypes to make CDA instance information (maximally) useful and reusable.
Hmm, I don't know of anyone having that problem getting at blood pressures, maybe you need to take the CCD class...
ReplyDeletePeople can get at blood pressures only by programmers knowing that a blood pressure is composed of systolic and diastolic components. No terminology, no templates, no structural artefacts used in CCD supply that knowledge!
ReplyDeleteMaybe you need to revisit the CCD specs as a computer instead of as a human with special clinical knowledge.
Hi all,
ReplyDeleteFinally we are getting to the points I tried to move HL7 to in 2005: we do need clinical structural complete expressions of data elements, data relationships and code binding that are beyond the CMET / R-MIM / XML space, but can be easily transformed into that. This is similar to the archetype level as discussed in earlier comments in Keiths blog.
DCM has been introduced as a bridge between clinical content matter and technical specs as HL7 v3 RIM based material and OpenEHR RIM. Yes there are many similarties between DCM and archetype, but DCM do not adhere to any RIM, in particular they do not adhere to HL7 RIM, but DCM can easily be transformed into different technical specifications, including HL7 RM / in particular into clinical statements.
There however is no such thing as a HL7 DCM. HL7 is facilitating the creation of DCM, like other parties around the world. And current work is looking how DCM fit in domain analysis models (DAM) such as the medical device work, and we are looking how DCM can be transformed into HL7 R-MIMs such as clinical statements.
We are also working on the conversion of DCM content to archetype to facilitate the reuse of carefully drafted clinical content in many technologies, despite the specific standard deployed.
For the overlap and difference where Keith is asking for, please see:
Goossen, W.T.F., Goossen-Baremans, A.T.M., (2010). Bridging the HL7 Template – 13606 Archetype gap with Detailed Clinical Models. In: C. Safran et al. (Eds.) MEDINFO 2010. Stud Health Technol Inform. 2010;160(Pt 2):932-6.
Further, a review of 6 different approaches including HL7 templates, OpenEHR archetypes, DCM and equivalent work is currently in press. I will update you on it.
The blog does not allow simple name, so
This is from William Goossen and I can be reached at wgoossen@results4care.nl
Oh, I just forgot:
ReplyDeleteWork is ongoing to create the standard for DCM: ISO/CEN 13972.
Draft material for that is available on the HL7 PC email list, it was distributed right after Cambridge.
William
Hi all,
ReplyDeleteFinally we are getting to the points I tried to move HL7 to in 2005: we do need clinical structural complete expressions of data elements, data relationships and code binding that are beyond the CMET / R-MIM / XML space, but can be easily transformed into that. This is similar to the archetype level as discussed in earlier comments in Keiths blog.
DCM has been introduced as a bridge between clinical content matter and technical specs as HL7 v3 RIM based material and OpenEHR RIM. Yes there are many similarties between DCM and archetype, but DCM do not adhere to any RIM, in particular they do not adhere to HL7 RIM, but DCM can easily be transformed into different technical specifications, including HL7 RM / in particular into clinical statements.
There however is no such thing as a HL7 DCM. HL7 is facilitating the creation of DCM, like other parties around the world. And current work is looking how DCM fit in domain analysis models (DAM) such as the medical device work, and we are looking how DCM can be transformed into HL7 R-MIMs such as clinical statements.
We are also working on the conversion of DCM content to archetype to facilitate the reuse of carefully drafted clinical content in many technologies, despite the specific standard deployed.
For the overlap and difference where Keith is asking for, please see:
Goossen, W.T.F., Goossen-Baremans, A.T.M., (2010). Bridging the HL7 Template – 13606 Archetype gap with Detailed Clinical Models. In: C. Safran et al. (Eds.) MEDINFO 2010. Stud Health Technol Inform. 2010;160(Pt 2):932-6.
Further, a review of 6 different approaches including HL7 templates, OpenEHR archetypes, DCM and equivalent work is currently in press. I will update you on it.
The blog does not allow simple name, so
This is from William Goossen and I can be reached at wgoossen@results4care.nl