This is a reply to an early note on the discussion about openEMR.
I think that the right level for defining the "kernel" objects is UML,
not SQL.
1) This way behaviour as well as data can be declared.
2) There are multiple ways to map UML attributes to SQL. The right one
can be chosen as an implementation detail.
3) This level is still specific enough to be usable in the short term.
There are many ways that a UML definition could be used with or without
using Corba. If non-Corba code is written using the same objects,
attributes, and methods, (ie: the same model) integrating it later would
be much simplified.
The big issue with using SQL to define the kernel is that it means that
expectations about the SQL tables get widely distributed in the code. A
complex data structure modifed by lot's of code written by independent
groups is unmaintainable and scales poorly. Security and data integrity
become real headaches. A "kernel" is going to need to scale well if it
becomes popular.
It's true that SQL does have some facilities for processing as well as
data, but these tend to vary widely from database to database and are
not always available.
The real difference is the point of view of the modelers. Using Corba
just to "wrap" SQL tables is throwing away it's major benefits. Using
SQL to implement Corba objects is a common design approach, but the data
storage mechanism becomes just an implementation decision.
The drawback of not defining the SQL is that data exchange must be
defined in some higher level protocol, such as XML or special methods
for data copying.
In any event, there is a huge advantage to selecting a standard model
for everyone to work with. The way this model gets specified in UML,
however, must allow for additional data elements without requiring
changes to the interface. The PIDS spec shows one way to do this -- all
of the identifying data elements of HL7 are accessibible without
restricting an implementation to just those elements.
-Brian
"Alvin B. Marcelo" wrote:
>
> So far, the following technologies have been cited in the posts:
>
> HL7
> CEN
> CORBAmed
> M(umps)
> VistA
> and the projects listed in Dan's paper.
>
> We can actually stop right now and agree that we (as OpenEMR projects) will
> develop CORBA implementations of each of our own projects and just make
> sure to keep our lines open.
>
> OR,
>
> we can push the stake further (and make it easier for start-ups coming from
> nothing) by defining a very simple database design/structure for a primary
> care setting (stand-alone).
>
> Alex Caldwell sent me mail and I agree that there is value in being able to
> choose from modules from different Open EMR projects.
>
> If Open EMR projects are built from a common kernel with pluggable modules,
> we can probably expect a flurry of development from all sides with everyone
> getting the best of the others' ideas.
>
> If we pursue the second option, we need to define the basic elements of a
> primary care record (patient? provider? medication? diagnosis? procedure?
> -- details of each?).
>
> And we also need to define a "format" for presentation of the projects so
> that openEMR developers can easily assimilate/understand each other's work
> and lessen the learning curve. We can post all these in Tim Cook's website
> (with permission from Tim).
>
> Eg, an OpenEMR project README would probably have the ff:
>
> <START>
>
> Project Name: Open-PCP
> Designed for: Primary care practice (TCP-IP network)
> Contact person: John Doe ([EMAIL PROTECTED])
> Information model: see ./erd_image.jpg
>
> Requirements: Linux, Postgresql, Apache
>
> The following tables have to be added (on top of the OpenEMR kernel) (note:
> these are just examples! just to show the point):
>
> 1. LOINC (subset for rheumatology)
>
> CREATE TABLE loinc
> loinc_id VARCHAR (10) ---[i'm just guessing here...]
> etc, etc
>
> 2. FDA Orange Book
>
> CREATE TABLE medications
> drug_id VARCHAR (10) ---
> etc, etc
>
> 3. LOINC-patient
>
> CREATE TABLE loinc-patient
> loinc_id VARCHAR (10),
> patient_id CHAR (10),...
>
> <END>
>
> I know this might sound contra to Dave Forslund's suggestion (stick to
> abstract models, N-tier, then implement) but if you will look at it
> closely, it is not. CORBA may still play a big part in it (as a wrapper).
>
> It's up to the group.....
>
> alvin
>
> Alvin B. Marcelo
>
> PGP keyID: 0x6E9941D1
> PGP server: http://www.keyserver.net
