I have code to build the archetypes from the internal source of the R-MIM's rather than the schemas. I will be publishing this through eclipse shortly.
I will be able to go the other way too, but both formats will need modifications for gap coverage. I am presenting changes to the RMIM diagrams tomorrow for HL7 consideration, and also talking to Thomas about changes to ADL to address the gap. Grahame Bert Verhees wrote: > >>> 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 >> >> >> > > -- Grahame Grieve CTO, Jiva Medical Software Integration Tools CTO, Kestral Computing Healthcare Applications
