Williamtfgoossen at cs.com schreef: > Yes Bert, > > I agree with many of the problems. > > My point was: today I cannot go to a live implementation of a OpenEHR > system. You support this. > > Today I can point you at least to 3 working systems that have HL7 v3 > Care Provision as the founding principle and they run, although still > in test environment. 3 worldwide? And in how far and what do they implement, which DMIM.? Or only five RIM classes?
Willaim, I am a developer, you may have noticed that. Except from information-architects, application architects and developers are needed to build a system. In OpenEHR we are lucky to attract all these kinds of people. I write to you, below, from a developer point of view, without developers you will never get a running application, so the developers point of view is very important, in medical informatics this is sometimes forgotten, and monstrums (is that an English word? it means to say: like a terrible inefficient creature, T-Rex stumbling on its own weight) are designed, just waiting to fail. ---------- There are two problems with this discussion. - HL7 is meant to be a message-format, that is also how it will be used in the Netherlands, it is meant to convert data in a system to a HL7 message, and at receiver-side, get them back into the system. OpenEHR is something completely different, and it is for an OpenEHR system as difficult as fort every other information system to export its data to a HL7 message. - The other problem with this discussion is that denying that OpenEhr has a lot of potential is not very smart. It may not ahve many implemantations right now, same as with HL7, mentioning that there three worldwide, is the practically the same as none, and thereby, we cannot judge its technical qualities, I have seen many bad systems (even in hospitals), so I don't trust a system from hearsay. ---------------------- > > I do know one system in New Zealand based on HL7 v3 RIM which is fully > operational. I know, one can build systems on a model that is meant to be a message-model, but what do you get? I know that the Prica DMIM has about 500 classes. Many of them are very similar, but they got other class-identifiers. I hope you will not be picky on the terminology. I use the word "classes" because you can see them as such. if you run the XSD-files through JAXB you get Java-classes representing the DMIM. HL7 puritans are often very picky on words, I think, in a attempt to distinguish the true believers from the followers. I see two possibilities to implement HL7 as a storage machine, both not very elegant, a horror for developers. 1) - So as a developer you run into a problem, you can take over this information model as represented in the DMIM/RMIM's, but you will get a monstrum (I explained this word above) with many hundreds of classes that all have to be mapped into a database-system. This will be an application that every developer will hate to maintain. This application will be something you will regret for ever. (specially if class-definitions change (they will for sure, nothing is perfect), and having to maintain several versions of the same class, distinguishable by numerical ID). The DMIM-implemenataion is not a good way. 2) - The other approach as to leave the structure of the message and build a own system, which has the capability to map the message to. So to say, an DMIM based storage. Maybe even a RIM based machine may be possible? I don't know, but it is not important because, still, this brings the developer to manually map the data from the base (DMIM or RIM) to the RMIM-classes, which are again hundreds, this again has to be done manually, and maintained manually, and have the same horror scenario In my point of view a RIM is only a theoretically model of thinking, not something that is useable in the real world as an architecture for a machine. because: as I said, this second approach brings us to the same problem, having to manually define/map information to its message-models. Concluding: the RIM-based system is a shift of the original problem from a RMIM-based machine. I heard in Nictiz-environments (sorry, I do not mention names, that is the way the Dutch Medical Informatics is structured for many years now. Not HL7-based, not Edifact based, but PARANOIA-based (I am joking, but not really)), were was I, Oh, I heard in Nictiz-rings, people say soft, that there are Prica implementors who are developing a one to one mirror of the prica-model into a database. So taking the first approach. This is really a very dumb thing to do. Concluding: Maintaining a HL7 machine will need developers for changing classes, changing XML-definitions, a very error-prone system, changing databases, doing conversions, not having smooth migration/evolution paths ------------------- Compare this to the elegance of OpenEHR. Difficult comparing, because OpenEHR is not a message format, it is not the same thing. Stupid that we often end up comparing things that are not comparable. Let's try anyway, it is a definition and storage machine, very simple on the downside, and doing its internal mappings to the complex outside automatically (means without maintaining, without errors, low cost) I only name a few advantages, read the OpenEHR website to find more. - Archetypes are used to store and retrieve information. - Archetypes can be build without a developer needed, only a specialist with a medical informatics background. (in the HL7 situation both are needed, and more, that is why Nictiz needed 50 million Euro's, which is a crazy amount of money) - Archetypes are able to extend, It is also possible to extend and regard backwardscompatibility. In HL7, you will have to look to the ID's of the classes to be sure you are doing the right thing, so there is not really a backwardscompatibility possible, this makes migrationpaths to new situations expensive and hopping (not smooth) - It is possible to generate GUI's from archetypes in every needed programming language (this is done in the Archetype Editors). One can with the same ease generate interface-definitions (and messages) for every other purpose, XML for data transport, etc. Even, one can let a XML message more or less be self explaining One can even, I said before, use OpenEHR to export HL7 messages, even let the outside of the machine give the impression of being a DMIM/RIM based machine. But why should one want that? As Thomas pointed out, there is a lot of knowledge hidden in the DMIM's which is very useful and valuable. We must be careful not to throw it away. But this does not mean that one has to take over the HL7 approach one to one. It is not my profession, OpenEhr allows the shift between pure technicians and people with knowledge of medical informatics. So, this is not my professional view, but I can imagine, that if one want to design an information model, one will want to learn from HL7, but not build it one to one. So it could be very well possible to build a RIM-looking machine from OpenEHR, but that is taking the HL7 problems to Openehr environment. That is not a good approach, but again, I leave that to medical informatics. > > Of course we need to be patient. It is a difficult task! > > Good luck and yes I look forward to seeing it work and consider myself > on the list of invitees to see the formal release. > > With respect to the dinosaur systems for GPs, stemming from the 80 > ies, I agree, these have difficulties with HL7 v3, and they would have > similar troubles with OpenEHR archetypes. We can take another approach on this. We can, if we want, no problem at all, build an OpenEHR machine with the interface of a dinosaur. So the GP may think he is working in MicroHIS, but he isn't. Even thse GP's who will miss Elias and Arcos, next year (both are end of life products, text-terminal based), the could be facilitated in an Elias and Arcos interface, with an OpenEHR engine below. No problem at all. > > My point is that you need to change to new desigs to make it work. I agree with that. Kind regards Bert Verhees -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20061017/5d7805d9/attachment.html> -------------- next part -------------- _______________________________________________ openEHR-technical mailing list openEHR-technical at openehr.org http://www.chime.ucl.ac.uk/mailman/listinfo/openehr-technical
