Hi, first I think our threads could use some refreshment in subject lines. Second, I make the observation that there are a bunch of folks who wear a particular orgnizational affiliation hat and who try to pull the poor hungry programmers onto their railroad track. I am honest, I am one of the organizational folks, I'm lobbying for parts of HL7. David is lobbying for CORBAmed. I think, however, that we organizationals should better be more silent than to mess the progress of the hungry programmers up by our battles. If Alvin is asking for SQL tables, he has all the right asking this, and the question should not be put off by saying that it would violate some n-tier principle. This entire discussion is screwed up on a layer where everyone seems to work with presumptions, mostly prejudical, kind of buzzword-presumptions, that may be well understood myths in each organization but are not at all truths so general that they would not deserve the critique of some humble practical workers. I'm trying to put off my HL7 hat here to summarize some facts that I think may be conseseable. I state these things as a credo, since we can't pretend to tell any kind of scientific facts here. I believe that an information model (of any kind) is of foremost importance for any EMR software. I think that such a model would probably best be formalized in UML, since this is the lingua franca of information modeling these days. I believe that the goal of the open EMR project should be to develop a kernel of actually useful software. All specifications or designs or interfaces are nice and fine, but there is no use in them as long as you don't have an actually working system for it. The Open EMR project must aim in building this system, writing the darn code so that we have something that works (and can then be extended.) I believe that a new software project of the complexity of Open EMR kernel should be designed object oriented. I believe that EMR systems live and die from the amount of data they will accumulate. That means, an EMR system needs a robust data management layer. This could be XML documents, but it is unclear how those would scale (I already have found some practical limitations of this approach in my project.) Therefore using a traditional data base seems to be a safe decision, since this is proven to work to some large extent. SQL is the lingua franca of data bases, so go with it. Remember we need actual working code, so there is nothing bad in deciding for something, e.g., SQL data base (PostgreSQL or MySQL, this is a question one should ask at some point.) Then, given we have that UML model, the model needs to be implemented in the data base. And the rules to do that are pretty straight forward. With object technology on top of SQL there are a couple of well known issues that need to be addressed. There are about three commercial software products that sell an object persistence module for Java or C++, but nothing is there on the open source market, as far as I know (I was desperately looking for it myself.) Sun has an interesting research project, "Forest", about orthogonal persistence in Java, but that is not open source either. So, there is a bunch of work to be done to make this object middleware layer a useful reality (remember, we are talking code here, not interface.) I believe that one could spend years on perfecting an object persistence middleware that is data base or even storage independent, however, we want to have code, soon. So, we need to be pragmatic. A manually crafted Java or C++ (what will it be?) object/database interface is all we can do for now. If we can't do that, then we may even need to do less object and more SQL. Remember, this is about practical code. Keep in mind the issue of performance (e.g., speed) if you users have to wait for a minute to switch between patients, you can forget it. The best n-tier distributed object design with x layers of y-independence is useless if you can not make it work on a resonable hardware in resonable practice. Ah, HL7 messages? CORBAmed interfaces? Forget it! Forget it! First you need a system, then we can talk about the inter-systems interface. The only reason why I am lobbying for HL7 here is because I find the particular part of the information model useful for a system that wants to use it as its internal data design. If I see a model that can do similar things, I am fine. If it's already implemented, why not go with it? That's why I won't argue against everyone deciding for GEHR, if they want to use Eiffel, fine. There are very practical issues in using GEHR/Eiffel that one would need to talk about. Let's do that. Please think twice before throwing in terms like "computational models" vs. information models, "n-tier", "model independence", "interfaces", and all this fancy stuff. It doesn't help here. Let's fight the never ending HL7 vs. CORBAmed (vs. XML) battles elsewhere, not on this Open EMR thread. regards -Gunther -- Gunther_Schadow-------------------------------http://aurora.rg.iupui.edu Regenstrief Institute for Health Care 1050 Wishard Blvd., Indianapolis IN 46202, Phone: (317) 630 7960 [EMAIL PROTECTED]#include <usual/disclaimer>
begin:vcard n:Schadow;Gunther tel;fax:+1 317 630 6962 tel;home:+1 317 816 0516 tel;work:+1 317 630 7960 x-mozilla-html:FALSE url:http://aurora.rg.iupui.edu org:Regenstrief Institute adr:;;1050 Wishard Blvd;Indianapolis;Indiana;46202;USA version:2.1 email;internet:[EMAIL PROTECTED] title:M.D. fn:Gunther Schadow end:vcard
