Re: [Gnumed-devel] Time for a major re-think in 2005 - opinions please.

[catmat]

Richard Terry wrote:

> >    I can't figure out why you say that. I've heard people in
> > university, that are currently involved in health information systems
> > development, saying, after looked at GnuMed project and backend model:
> > 'aren't we reinventing the wheel? Shouldn't we use GnuMed?'.  They are
> > currently not involved in GnuMed, but really appreciate it, and I
> > guarantee they're not *'blind spot'*  or easy to convince...
> >    
>
> I'm not sure if you read Tim's observations, but they don't exactly concur 
> with this view. Again, you seem to be talking about the backend, I'm talking 
> about the whole project.
>
>  
>
> > > I've watched a large number of talented people come enthusiastically to
> > > the project, only to melt away into cyberspace.
> > >      
> >    And many were (legitimally) looking for a ready-to-use software. 
> >    
>
> That's not true Carlos, having been involved with the project a lot longer 
> than yourself. We have had many extremely competent people who had the 
> programming skills to be involved, were involved in area's crucial to gnumed 
> (such as pathology downloding) who expressed interest, but who melted away. 
> One has to ask why, and not just try and defend the status quo.
>
> As you correctly say yourself, gnuMed is a very ambitious project. What we 
> need now is more manpower. Horst doesn't really have the time and probably 
> won't for the forseable future. That really leaves, Karsten,  yourself and 
> Ian as the mainstream developers with Syan who seems to do slightly different 
> work on the edges (Syan - don't get upset about this comment if I'm wrong).
>  
 It's too hard to jump other people's hoops when you realise that
they perhaps don't really want you to jump them, so it's more productive
to  produce many different prototypes : it can't do any harm : for instance
the web client can serve lots of functions - e.g. how to use gnumed schema
to learn struts as well as the workings of a fine evolved schema ( that
might get more java developers to contribute, although it hasn't :( )

the omniorb demographic server interface to gnumed shows
that transforming openemed's interpretation of corba pids can be used
to connect to the demographics part of the gnumed schema  ( any 
developers interested in
CORBA, medical emrs , help with gnumed ? );
 febrl can be adapted to gnumed demographics for functions such as 
periodic deduplication
or for bulk deduplication ( say for bulk transfer of patients from one 
system to another ,
merging any records referring to the same patient)   ( remember the 
name, *FEBRL*) ;
the recent text mode  use of shelf and bsd_db standard python modules
was an attempt to use as few external dependencies outside of python
itself to create a rudimentary emr, which could say later, export a subset
of data to gnumed ; it wouldn't require as much package dependency 
management as
gnumed needs now. One could also re-write  a console system as a command 
line
program with arguments , and then frontend it with a gui later ( as happens
with a lot of unix stuff).  The structure of the text mode console 
"schema" is
ad hoc python dictionaries , but this is easier to export to from the export
format of a popular emr in australia ; also the builtin shelve python module
means  you don't have to manually write all the object-relational 
mapping as occurs in gnumed ;
it might be argued this is at the cost of losing the ease of sql select 
searching,
but research searches still can be done using traversal of all records 
using bsd_db  iterator and  a custom python function, or custom index 
databases where fast searching is needed ( not often).

gnumed has a complex structure, so devising custom sql select statements for
a particular search may take as much time as writing a custom function 
to pick out values from
recursive maps.
If one compares gnumed and other alternatives to the widely used emr's 
in australia,
you could say gnumed is more comprehensive and intellectually 
satisfying, at the cost of being
harder to create user frontends quickly . 
One of the widely used oz emrs  is being moved to a sql server and 
document management
system platform, instead of its current platform , which is multiple 
thick clients using
the operating system network file sharing to make distributed data 
access "transparent".
Using a sql server, they seem to promote the advantage that is "client- 
server", and
the server accesses the data on behalf of the client, providing better 
coordination
, throughput and protection,  which is a feature separate from
the flexibility of search that sql provides ( most of the commonly used 
searches have
been made into functions, which is what gnumed is heading towards, so 
this almost
obviates the need for sql's searching power , for end users anyway).
A bsd-db and xmlrpc based application  also is "client-server", although 
I don't think
the xmlrpc simple server provided in python is  multiple threaded or 
multiprocess but
a simple select server, which means it could run slower then if the 
former two options
were available ( but that might be ok if you had 3 doctors in the 
clinic, and the clinic didn't
want to keep forking out every year, and wanted easy to understand schema
and not complex code for customising by a local programmer who gets paid 
for contract work).