At 11:21 AM 11/23/99 -0500, Gunther Schadow wrote:
>Hi,
>
>first I think our threads could use some refreshment in subject lines.
I agree
>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.
My point continues to be that HL7 and CORBAmed are complimentary
technologies that need to work together to help solve the healthcare
systems problem. One doesn't choose one or the other. Use the
capabilities of each where they are best suited. There seems to be a
considerable lack of
understanding of CORBAmed is doing relative to HL7. CORBAmed is trying to
provide additional process functionality to the already rich HL7
model. The separation of the computational model
from the information model and both from the engineering model is well
established in the ISO community and
should be taken account in any system design, whether one uses CORBA, HL7,
CEN, GEHR, DCOM, "My Favorite Model," or whatever.
>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 not trying to come to this with prejudices, but with recommendations on
how to approach
a robust distributed medical record system.
>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.
Absolutely.
>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 couldn't agree more.
>I believe that a new software project of the complexity of Open EMR
>kernel should be designed object oriented.
Which means handling both an information model and a computational
model. RM-ODP of ISO
argues that these should be different views of a system (along with an
enterprise view and a technology view).
>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.
Absolutely. But my only argument is not to expose SQL to a client if you
don't have to.
>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.
Agreed. But this could be in an ODBMS as well and it shouldn't matter to
an end user.
Clients could be developed independently from a server and provide
different functionality.
I am arguing for components and trying to present the value of utilizing
component technology .
>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.)
Objects on top of SQL presents an impedance mismatch. I agree that
there aren't any good open-source solutions here which map tables to
objects and vice versa.
Which is why we like to deal with objects directly in the persistent store,
and there are good open-source solutions available through that route.
>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.
I'm not sure how hard this actually is, but it is being done today.
>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.
I also agree completely. In our modest experience, the ODBMS's provide
better performance
in this regard than do RDBMS. And one doesn't have to give up any querying
functionality of
SQL to do so.
>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.
Precisely, but keep in mind that if you want a client to be able to talk to
multiple
disparate servers, you will need to worry about this issue of
interfaces. Interfaces
are extremely valuable in providing the well documented "design by
contract" methodology,
so that implementation does contaminate the design. The design should
involve functionality
not just information. What is the system? Should it be a single system
or a system made
up of a set of components. If the latter, then interfaces are even more
important to isolate design from implementations. If you want to build a
monolithic system, then you don't need a lot of this stuff. But
I believe monolithic systems are a bad idea to model an openEMR around.
>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.
I don't see a battle here at all. There is no HL7 "vs" CORBAmed. If one
doesn't deal with interfaces in some form or other, system extensibility
(and interoperability, if needed) will be severely sacrificed. Good principles
of design are important. UML is a tool which allows one to express these
principles. Systems should utilize these principles.
I hope this discussion is useful. There is no single solution to this
problem. There is no silver bullet.
Dave
>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>
