In a message dated 3-12-2008 14:57:33 W. Europe Standard Time, thomas.beale@oceaninformatics.com writes:
I still don’t quite get
what way DCM is going - I thought it was going with archetypes, based on
the meeting a year ago, but in any case, I think the job of
standardising clinical models must be done by clinical people, and on a
far more agile basis than any of the official standards organisations.
DCM is about standardising clinical models done by clinicians. Archetypes are one way to go (if certain conditions are met, see discussions). Other models will remain for a while. Core of DCM is either UML and from there to archetype or to HL7 v3 XML, or transforms.
The official standards organisations can set criteria and methods for the how to. However we need a repository and knowledge manager approach to actually handle the examples. Until now only archetypes are stored such a way, HL7 v3 template / XML artefacts would need similar things, e.g. to be included in a CDA or message.
My big concern is that an Apgar in archetype is different from an Apgar in CDA or message, DCM helps to bridge the (potential) gap on clinical content and DCM helps to fully specify the concept, the Snomed CT id and the Snomed CT fully specified name or display text (which is currently not possible in an archetype, at least the editor often crashes while doing that).
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
Williamtfgoossen@cs.com wrote:
In a message dated 3-12-2008 14:57:33 W. Europe Standard Time,
thomas.beale@oceaninformatics.com writes:
I still don't quite get
what way DCM is going - I thought it was going with archetypes, based on
the meeting a year ago, but in any case, I think the job of
standardising clinical models must be done by clinical people, and on a
far more agile basis than any of the official standards organisations.
DCM is about standardising clinical models done by clinicians.
Archetypes are one way to go (if certain conditions are met, see
discussions). Other models will remain for a while. Core of DCM is
either UML and from there to archetype or to HL7 v3 XML, or transforms.
Hm...you will definitely run into problems with UML, due to the
weaknesses around constraints in general, and also the orientation to
class models rather than object models. They have never really worked
well so far in health and I don't expect them to in the future. They do
give an illusion of working in some simplistic and very controlled
circumstances but in general they won't go the distance. But I am much
more interested to get a definitive list of limitations you see in the
archetype formalism (not the current tools). I went back through the
posts on this list, but still don't have a clear picture of the
requirements you think archetypes don't meet.
With respect to invariants (which I would propose to rename 'rules'),
the current ADL 1.5 spec includes a draft of new facilities (see section
6 of
http://www.openehr.org/wiki/download/attachments/196633/adl_1.5.pdf)
which is more powerful than it was, and will allow any kind of formulas.
The exact syntax is still being decided, but it may well end up being
Xpath-based, and people in Brazil have already done some work on this -
an archetype-path formalism based on Xpath (this will appear soon at
this wiki page -
http://www.openehr.org/wiki/display/spec/A-path+-+Archetype+Path+Language).
The official standards organisations can set criteria and methods for
the how to. However we need a repository and knowledge manager
approach to actually handle the examples. Until now only archetypes
are stored such a way, HL7 v3 template / XML artefacts would need
similar things, e.g. to be included in a CDA or message.
I believe it makes much more sense to just generate them from the
openEHR archetypes and templates. Messages should just be treated as
output formats, not clinical model design formalisms (there is no
re-use, as the world has found out over the last few years).
My big concern is that an Apgar in archetype is different from an
Apgar in CDA or message, DCM helps to bridge the (potential) gap on
clinical content and DCM helps to fully specify the concept, the
Snomed CT id and the Snomed CT fully specified name or display text
(which is currently not possible in an archetype, at least the editor
often crashes while doing that).
it will only be different if it is manually modelled to be that way. But
if we start using a common formalism to do the modelling and generate
message-related formats, just as we already generate other technical
forms, then this problem will go away.
- thomas beale
Hi William
I still can’t see how we are ever going to engage clinicians in signing off on these DCM models if they can only participate in the requirements collection phase and can’t comment on the models themselves? There will be literally only a handful of clinical people around the world who will be able to get their heads around UML (or XML Transforms?) to understand what the model means. I believe that this is the big advantage of archetypes, because they are approachable for non technical clinicians.
regards Hugh
In a message dated 4-12-2008 1:50:06 W. Europe Standard Time, hugh.leslie@oceaninformatics.com writes:
Hi William
I still can’t see how we are ever going to engage clinicians in signing off on these DCM models if they can only participate in the requirements collection phase and can’t comment on the models themselves? There will be literally only a handful of clinical people around the world who will be able to get their heads around UML (or XML Transforms?) to understand what the model means. I believe that this is the big advantage of archetypes, because they are approachable for non technical clinicians.
regards Hugh
Hi Hugh,
I think you misjudge the qualities of clinicians. See my paper in Int Jrn Med Informatics on the perinatology project. At that time we explained clinicians without IT background how the UML models (HL7 RIM format, even complexer), and after two sessions explaining goal of project and how modelling works and how they can express data needs etc, they could fully engage in the project and critically review the models, their relationships and the content of it.
I agree we need to make it simpler. Entering material in the archetype editor is. Reading the adl is not. 
DCM is not about UML, DCM is about setting criteria for clinical content and so on.
UML can be used, HL7 can be used, archetype can be used, XML can be used.
If someone uses A, we as IT specialist should guarantee that the same concept remains if we choose to use B.
If the archetype editor would spit out a full HL7 v3 clinical statement spec, including the code, value, datatype and moodcode for instance (others attributes upon need) e.g. in the MIF format, then we can do business with DCM moving to one format only. However this is still not the case.
I understood that the transformation tools currently existing still require a lot of manual tweeking.
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
Thanks William
Maybe Dutch clinicians are cleverer than Australian ones - but UML is very technical and takes a long time to read and understand fluently. We certainly never require anyone to read the ADL - just like you would never expect someone using software to have to read the source code to understand how it works. Some will - most won’t even want to go there and should never have to.
The archetype editor is never likely to spit out HL7 v3 RIM specs as the outputs and internal function is all based on the openEHR reference model - I think you would have to write a different tool. What we are doing with the transforms is not producing models but producing XML schema that can produce an instance of something like an instance of an HL7 CDA document from an automatically generated XML schema from openEHR models. We haven’t attempted ever to produce HL7 models.
The tool currently automatically generates the XML schema without any tweaking from an openEHR template (called a Template Data Schema). The template may map to something like a application data schema or an HL7v2 message. This schema can be used to produce an XML document using XML based tools (a Template Data Document) and then transformed into an instance of some other thing like an openEHR data instance, a pdf, or a CDA instance. To produce the CDA instance, we need to create a transform based on each archetype in the Template Data Schema and put them together into a bigger transform. These archetype based transforms require a lot of knowledge of CDA and the RIM to produce, however once done once, they can be reused over and over as a library and the CDA produced is always consistent. But at the end of the day, we are still getting a CDA instance and not any kind of V3 model.
Maybe I am still a little confused about what DCM is hoping to achieve - sorry.
regards Hugh
Why don’t we just set up an experiment: take one well established domain (Barthel could be a good candidate or as I suggested earlier create a ‘fake’ domain, so everybody starts from zero). Let the clinicians do their job and give their result to the technicians who model it according to their standards/ using their tools. Then link the 2 systems (1 which follow the openEHr standards and 1 which follows the HL7 standards) and see if the can exchange data which is useable (according to the clinicians). For business purposes it would of course also be very interesting to see how much effort the technical modeling and the implementation is the respective systems cost.
Until now it seem a very academic discussion. I’ve always been taught: the proof is in eating the pudding:-)
Cheers,
Stef
Just out of curiousity. Yesterday I read the article Bert pointed out (en good reasons why an HL7-XML message is not always the best solution
http://www.xml4pharma.com/HL7-XML/HL7-XML_for_CDISC_Standards.pdf)
I was triggered by the following statement in this article :“Though the use of UML may be the perfect and well-established way for translating a software design
to software classes, it is considered bad practice by XML specialists. Transformation of UML to XMLSchema in general leads to “spaghetti XML”, introducing unnecessary complexity. Of course it is an “easy” way: the world has much more UML specialists than it has XML-Schema specialists.
Personally, I would consider transformation of UML to XML-Schema the “lazy man’s way”. The result can however be catastrophical.”
Now thomas seems to have (from my non-technical point of view:-) ) a similar objection against the use of UML.
Is this the idea that using UML is the lazy man’s way leading to ‘spaghetti’ widely accepted among XML specialists? I’m asking this because here in the Netherlands the ‘official’ viewpoint seems that UML is the ‘solution’ for all our problems. In that case are there more articles published about this subject?
If this idea is widely accepted among XML experts, at least, it hasn’t landed at the level of the decision makers in the Netherlands.
Cheers,
Stef
Stef Verlinden wrote:
Hm...you will definitely run into problems with UML, due to the
weaknesses around constraints in general, and also the orientation to
class models rather than object models. They have never really worked
well so far in health and I don't expect them to in the future.
Just out of curiousity. Yesterday I read the article Bert pointed out
(en good reasons why an HL7-XML message is not always the best solution
_http://www.xml4pharma.com/HL7-XML/HL7-XML_for_CDISC_Standards.pdf_)
I was triggered by the following statement in this article :"Though
the use of UML may be the perfect and well-established way for
translating a software design
to software classes, it is considered bad practice by XML specialists.
Transformation of UML to XMLSchema in general leads to “spaghetti
XML”, introducing unnecessary complexity. Of course it is an “easy”
way: the world has much more UML specialists than it has XML-Schema
specialists.
Personally, I would consider transformation of UML to XML-Schema the
“lazy man's way”. The result can however be catastrophical."
this argument is a technical one, and is more or less correct. The
reason is that UML is object-oriented, XML is not (although it has some
features). To give a concrete example, there is no obvious way to decode
which attributes in UML classes should become XML 'attributes' (the
things inside the tags) and which ones XML Elements (things that have
their own tag pair). Another one: there is no proper mapping of UML
container classes to UML tags - there is at least 3 ways of doing it.
Now thomas seems to have (from my non-technical point of view:-) ) a
similar objection against the use of UML.
yes, but this is a different one - it is really to do with the semantics
of UML for expressing constraint models.
Is this the idea that using UML is the lazy man's way leading to
'spaghetti' widely accepted among XML specialists? I'm asking this
because here in the Netherlands the 'official' viewpoint seems that
UML is the 'solution' for all our problems. In that case are there
more articles published about this subject?
it is accepted I would say, but on the other hand, there are accepted
solutions to it. The main practical consequence is that UML tools
generating XML schemas usually don't do a good job. (The reverse is not
always true however).
- thomas beale
Folks may be interested if they have not already seen the following document - which describes a project to do a similar thing to what is suggested below
http://www.ehr.chime.ucl.ac.uk/download/attachments/3375121/HL7-openEHR-13606-Transformability_v1.0.pdf
Steve