|
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
Op 4-dec-2008, om 7:28 heeft Hugh Leslie het volgende geschreven: 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
Williamtfgoossen@cs.com wrote: 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
_______________________________________________
openEHR-clinical mailing list
openEHR-clinical@openehr.org
http://lists.chime.ucl.ac.uk/mailman/listinfo/openehr-clinical
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3662 (20081203) __________
The message was checked by ESET NOD32 Antivirus.
http://www.eset.com
_______________________________________________ openEHR-clinical mailing list |