Sam Heard wrote:
>Dear Jim and others,
>
>One of our difficulties with the GEHR Ocean Kernel is the binding of our
>kernel to database engines. We believe our appoach is a good one - offering
>a standard open source component as middleware with COM and CORBA
>interfaces - but building and optimising the backend bindings for all major
>databases is beyond our resources and expertise. For that reason I would
>like to try and set up an international project to write bindings to a
>number of suitable database products - perhaps with vendors as partners and
>the openSource community looking at Postges and mySQL.
>
>It is possible at GEHR to remain compatible (we believe) with the HL7
>efforts (at least drawing attention to when they have internal
>inconsistancies) and CORBAMed interfaces. This is important in itself. I
>kind of summarise the different approaches as:
>_________________________________________________________
>
>Approach             Activities             Transfer           Implement
>Design
>_________________________________________________________
>
>Messaging           HL7  v2               ASCI                 ++++
>+
>                              HL7 v3                Any
>++++               +++
>
>API                        CORBAMed      Objects             +++
>+++
>
>
>Record Architecture    PRA            XML                 ++?
>+++
>                               GEHR kernel    EHRs                +?
>++++
>_________________________________________________________

Your table broke up in transit so it is not clear to me what you were saying 
above.

>
>This analysis is speculative (Gunther?) and obviously will have to be
>proven - we hope out current trial of the Ocean GEHR kernel in Australia
>will demonstrate some of the utility of using a common component - when 3 
GP
>systems start to share Health Summaries and Diabetic records.
>
>I do see that binding the kernel to current DBs is required - even for
>testing. So the question is - can we get some energy together to test the
>kernel with MUMPS, Oracle....

I think the most interesting thing might be a binding to the VA Fileman DBMS 
(a MUMPS application) and to existing open source healthcare applications in 
the VA VistA. For this, Greg Kreis or Gregory Woodhouse might be of help.


>While this may send horrors through the - I'll only use it if its free
>community - clearly it is a reality in health care that people will have a
>diverse range of DBs behind their EHR systems.

Actually, there are a couple of free (although not open source) 
implementations of MUMPS and a project to develop an open source MUMPS.

---------------------------------------
Jim Self
Manager and Chief Developer
VMTH Computer Services, UC Davis
(http://www.vmth.ucdavis.edu/us/jaself)

Reply via email to