Re: [Gnumed-devel] medibase

[Horst Herb]

sjtan wrote:

> Input Output seems to be clearly separated ? a good idea ?

I think not - from a users perspective. A lot easier to implement, and 
maybe the way to go until we have a good and stable rioch text widget - 
but ultimately most users expect nowadays to edit content wherever it is 
presented whenever they feel like.

> To input, the large buttons have to be pressed, but looks like the 
> author really likes clear partitioning : each button is a major use
> case : for instance, 

Yes, it is optically a very clean user interface. But a PITA that many 
items cannot be accessed via key shortcuts

> I wasn't able to try out the prescribing wizard, because the subset 
> commercial drug database was corrupted ( according to error message).

Drug database works fine here, only the import of prescription 
information from MDW had soe quirks. Prescription is cumbersome, too 
many mouse clicks needed, key navigation cumbersome, and too many 
dialogs popping up. IMHO the main drawback of that user interface 
implementation.


> Can't actually remember how one re-edits items, eg. letters,
> immunizations, will need to go back.

Haven't figured that out either yet. Not very intuitive in that aspect, 
I must say. Did not have such problems with Mims script, Locum, Genie or 
Medtech to figure things out.

> I was wondering if Horst got Interbase to work from a unix server, and
> the medibase client to work in Wine , and his impressions?

Have tried it all day today - but only on Windows at work. Will try 
Linux this weekend. The install wizard does not allow to set an 
Interbase server address, wonder how they would do networked 
installations for the computer dummy.

> My impression is that the backend tables aren't too complicated, and
> there is no object model. 

The table schemas are dead simple, almost no normalization. That's 
probably a reason why it is so fast. I wonder whether we should not 
pseudo-denormalize a few tables in gnumed for performance and 
simplicities sake (keeping both foreign key AND redundant referenced 
information in a table, plus a trigger that checks that information 
matches foreign keys)


> I'm not sure if the application was that hard to make: Delphi is
> popular  because one can knock up a database GUI frontends really
> quickly without much coding, and delphi is integrated with interbase
> and , the professional version even comes with an express InstallShield 

You can do that too if you use either C++ or Python and the the newest 
Gideon IDE (KDevelop 3.0 alpha): QT has powerful database aware widgets 
and database abstractions just as Kylix/Delphi. We went for wxWindows to 
be free on all platforms and accepted that it will be harder to develop, 
but to achieve the benefits Delphi or VB have one does not need to go 
the whole stony path of proprietary software: QT will be halfways here 
and there.

> packager. The 3rd party drug database was developed by Mims: not sure if
> it is just a module with a DDE like interface ( DDE is like RPC [remote
> procedure call] to unix systems, I gather, last time I looked in 1995 !

Nope - a quick look suggested MIMS is actually imported into Interbase 
tables and directly accessed from the client.

>  Maybe not quite, RPC can be accessed from one machine to another,
> whereas DDE is mainly inter-process procedure calling within the same
> machine. ) 

The MS equivalent would be DCOM, not DDE. DDE is dprecated anyway.

> I was thinking about how he might have managed to create exporting of 
> patient clinical information from MD, the major gp clinical app  in
> Aust.                                       

Nothing difficult about that. The only difficulty is matching 
prescription information to any other drug database than AZ-DEX.


> ID, and to return various components of the medical record by patient
> id. This could be combined with the fact that MD allows exporting of
> demographic details, which might contain the patient id  

MD uses either plain DBF files - which you always can access as you 
like, or FlexFile3 formatted memo files, which are a bit harder to crack 
- however, on request they provide you with an utility which exports 
memo data (progress notes) into plain text standard memo files which 
again are trivial to handle.

The not-so-trivial issue is making any sense of the un-normalized data 
in a highly normalized system.

> looking at the prices, medibase seems quite low cost, and might be aimed
> at the small practice looking to comply with Aust Practice incentive
> funding , whereas profile which costs several grand and ten times more,
> might be suited to the corporatized gp  BTW has anyone done a
> non-advocate review of Profile? 

I will do one as soon as I have tried it thoroughly, which will take a 
few weeks. Currently, I am using it for every 5th patient live during 
consultation (well, started doing it today) and after the consulattion 
retyping / cuttingand pasting the information into MDW to achieve 
persistence of my records.

Horst