>> al"). >> > > well, I can't speak for "the designers" (I'm spending some time with him > today on this subject ;-), but archetypes and HL7 models are the same thing. > I can interconvert between them. The only issues are syntactical differences > in things that are allowed in each language, and they are minor. Obvious > conclusion: they are the same thing. > Yes, this is partly true. I even started writing a tool which translated automatically HL7 XSD's to ADL-files. So it was possible to use OpenEHR as a HL7 storage machine. I stopped this work because there is a bug in the java-kernel concerning Archetype-slots, which are really necessary for this job.
Now, also, because I changed my plans, the need disappears to finish this, but it can be done, in fact, I did it, except from the places where CMETs which incorporate other CMETs (and a few other smaller things), and the code is quite easy, from which one can conclude that ADL is fit to store CMETs. So, OpenEHR is fit as a HL7 storage machine. The product is however in beta, beta phase. I wrote it in a few weeks, and it needs some time to come to a really stable and good product. (it even is more powerful, than for HL7 storage machine, my code does not know it is handling HL7, it handles every XSD-file, also when more are referred to each other, which almost always is) The code I wrote is however based on the 0.95 kernel. But it can easily be transformed to a newer version. And why is this good? ------ I know, in the field there are some problems how to handle the many CMETs that appear, even in a small RMIM. The number reaches 300 hundreds in a patient-record. Very many of them are very similar, f.e. being just a demographic CMET, one with Address, one without, etc.... There are some companies which translate CMETs to software objects, because when doing this, they can generate code from XSD with f.e. JAXB. It maybe clear that this code-result is a shame when comparing it to code which is designed on well design principles. So, generating code is not a solution, but handling hundreds of CMETs, defined in XSD-files on another way is quite programmer-intensive, and also, because of the many CMETs to be done, error-prone. concluding: That is why OpenEHR is a very good HL7 storage-machine, but there are a few technical problems to be resolved (archetype slots), which will be very soon. ---- That is the technical part, but what is more important, is the informational part ( philosophical stuff, I think this is what Graham means by...). That is not my job But I understand there are, except from discussion on the technical parts, also discussions on the informational parts. That is even more interesting I hope to read more about that Thanks Bert > There are differences, but they are really primarily engineering differences. > And some philosophical stuff in the reference models, but I'm starting > to think this isn't as big as I thought > > It appears that this is stuff we can sort out and actually work together. > > Grahame > > _______________________________________________ > openEHR-technical mailing list > openEHR-technical at openehr.org > http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical > > >
