In a message dated 7-11-2008 9:24:56 W. Europe Standard Time, thomas.beale@oceaninformatics.com writes:
William,
I don’t know what DCM is ‘using’ - is there are new formalism?
Detailed Clinical Modelling is currently using multiple formats:
-
For legacy systems to extract clinical knowledge, and to come up with an expression that 2 and 3 below at least can use: UML
-
For messaging HL7 v3: template formalism (i.e. HL7 v3 XML and schematron)
-
For 13606 RIM based archetyping: ADL
-
For some testing of multiple sets of constraints: OWL (see Rector and Marley work on medications).
Purposes of DCM include:
1] to allow quality of clinical content to be discussed and verified by clinicians,
2] setting quality criteria for what should be in an archetype / template / DCM (what was discussed in Brisbane meeting last year)
3] making sure that in any transform from one formalism to another the robustness of clinical content remains. If we could express all we need in an ADL editor we would be ready and could step over. But ADL is missing several important features at the moment, including process related, decision support related and message exchange related features. For instance, we cannot include a display text if a coded ordinal is required.
And we do not know how to express the formula, or logic between multiple variables in an archetype, e.g. how a total score is obtained.
4] setting criteria for repositories so that we can share amongst the different standards and deploying communities.
I would like to attach a recent paper on it, but it usually gets stripped of when submitting to the list.
If an ADL editor would allow expressing some additional features, allowing to convert ADL to HL7 v3 XML, the discussion would be obsolete for the formalism part of things. I have seen the ADL in HL7 v2 messages which looks very promising and at least allows us to move further with the definition of clinical content.
Sincerely yours,
dr. William TF Goossen
director
Results 4 Care b.v.
De Stinse 15
3823 VM Amersfoort
the Netherlands
email: Results4Care@cs.com
phone + 31654614458
fax +3133 2570169
www.results4care.nl
Dutch Chamber of Commerce number: 32133713
This would be interesting. You can always upload it to the wiki.
http://www.openehr.org/wiki/dashboard.action
--Tim
William,
DCM hopefully will help to ‘bridge the gap’. From my point of view is good to separate the clinical domain knowlegde as much as possible from the technical discussion.
Asfat as the technique goes: thanks to Eric we have a good overview of the shortcomings of HL7 from the openEHR viewpoint. If I understand it correctly your paper sums up the shortcoming of 13606/openEHR from the HL7 viewpoint. This wil help to create mutual understandig so we can work on solutions.
Do you have an url where we can find your paper?
For now, can you provide ‘real life’ examples of what you mean by:
For instance, we cannot include a display text if a coded ordinal is required.
And we do not know how to express the formula, or logic between multiple variables in an archetype, e.g. how a total score is obtained.
Cheers,
Stef
Hi William,
naturally we are interested to know how to improve the archetype formalism and methodology. The first thing to realise is that ADL depends for its underlying semantics on a reference model, which acts as a ‘base level ontology’. The openEHR reference model currently supplies the based-level ontology for existing archetypes. Over time, we expect further primitives to be added to the reference model to allow more complex constraining. Nothing is ‘finished’ of course, so permit me to explore the ‘missing bits’ for a moment
-
process-related: do you mean care plans made up of task/action steps? The basics of this are already available, including Instructions and Actions. A forthcoming concept, currently called the ‘Instruction Index’ will provide a fuller basis for care plan modelling.
-
decision-support related: can you provide some more detail here?
-
message-related: a priori, I would say details of how information is represented or transferred should not be part of clinical models; this is one of the big problems with any such models expressed as part of an RMIM. In openEHR, we generate message definitions instead, from templates, based on archetypes. This is called a Template Data Schema in openEHR.
-
formulae / logic: this is already possible and has always been in ADL. The current archetype editors don’t yet have an editor for creating the expressions, this is coming.
-
display text/coded ordinal example: not sure of exactly the requirement here, but you can certainly allow a coded ordinal and a text or coded text as alternatives for the same attribute. What the application does on the screen is another matter of course.
-
conversion in and out of HL7v3 XML - I presume you mean MIF. I don’t know how easy this would be, since no-one has asked for it. Generating some kind of CDA template I suspect would be easier, although the strange custom design of the CDA entries make things harder than they should be. Anyway, I would like to first understand what purpose this would serve.
-
thomas
(attachments)
William,
Regarding coded ordinals, ADL provides for both the ordinal value and the
corresponding text. If we use the Barthel Index archetype ( e.g.
http://www.openehr.org/svn/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.barthel.v1.html
) as an example, then you can see that both the ordinal ( assessment score
) and the corresponding meaning (both in English and in Dutch in the above
example ADL) are included.
Again, taking Barthel Index as an example, the ability to derive the total
score from the individual ten assessments as a formula in the model is
attractive since it documents the meaning of the total score explicitly in
the model. This is possible with ADL.
One problem is in adding such capabilities into the user interface of the
editor. Ideally, I suspect clinicians designing archetypes would like to
be able pull down a sum() function from a list of functions and reference
each of the 10, say, contributing scores used to build the total Index
score.
Generalising such capabilities is not trivial. Where would one stop with
building formulas? What if you wished to reference data items outside of
the current archetype? How complex should the expression builder be? Have
you a list of such requirements?
The second problem, is that it is then not possible to translate such
formulas into a formalism of your choice - certainly not into HL7 RIM
based models as you might wish, since, as far as I know, it does not have
the cability, and it violates the fundamental V3 principle that all
knowledge is expressed in the foundation RIM components and cited
vocabularies.
regards,
eric Browne
Eric Browne wrote:
William,
Regarding coded ordinals, ADL provides for both the ordinal value and the
corresponding text. If we use the Barthel Index archetype ( e.g.
http://www.openehr.org/svn/knowledge/archetypes/dev/html/en/openEHR-EHR-OBSERVATION.barthel.v1.html
) as an example, then you can see that both the ordinal ( assessment score
) and the corresponding meaning (both in English and in Dutch in the above
example ADL) are included.
Again, taking Barthel Index as an example, the ability to derive the total
score from the individual ten assessments as a formula in the model is
attractive since it documents the meaning of the total score explicitly in
the model. This is possible with ADL.
In the Apgar, it is :
invariant
Sum: /data/events[at0003]/data/items[at0005]/value +
/data/events[at0003]/data/items[at0009]/value +
/data/events[at0003]/data/items[at0013]/value +
/data/events[at0003]/data/items[at0017]/value +
/data/events[at0003]/data/items[at0021]/value =
/data/events[at0003]/offset/value
Naturally, this would be displayed on a UI in friendlier fashion.
One problem is in adding such capabilities into the user interface of the
editor. Ideally, I suspect clinicians designing archetypes would like to
be able pull down a sum() function from a list of functions and reference
each of the 10, say, contributing scores used to build the total Index
score.
Generalising such capabilities is not trivial. Where would one stop with
building formulas? What if you wished to reference data items outside of
the current archetype? How complex should the expression builder be? Have
you a list of such requirements?
yes, this is indeed the challenge. The formalism will handle pretty much
any complexity of expression, but building expression editors that
anyone can understand is hard work. We had this same challenge in a
financial system I worked on, and rewrote the expression editor three
times (the current version is a tree-on-its-side, after trying much more
complicated things).
- thomas beale
Hi William
I think that the biggest problem I have with DCM is this bit -
"Purposes of DCM include:
1] to allow quality of clinical content to be discussed and verified by clinicians, "
Most of the formalisms that you have mentioned including UML and V3 RIM and OWL and Gello are very technical - how do you propose that these can be used by clinicians to discuss and verify clinical concepts? This doesn’t seem to be as much of an issue with openEHR archetypes as we find that they are very approachable for clinicians generally (as the NHS report into the openEHR trial found).
regards Hugh