[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Carlos - Soap2 - design comments

From: Ian Haywood
Subject: Re: [Gnumed-devel] Carlos - Soap2 - design comments
Date: Wed, 10 Nov 2004 15:30:15 +1100

On Wed, 10 Nov 2004 12:19:30 +1100
Richard Terry <address@hidden> wrote:
> tree like list of encounters very often. Having this take up valuable 
> workspace next to your input area's is a waste of screen real-estate
> deprives you of much peripheral information.
Then how should the past history be presented?
(Your original client didn't have a past-history screen, as I recall) IMHO we 
need a rich way of organising the medical history
and a tree widget is the most logical, but I'm happy to consider other options.

One thing is for certain, you are never going to get a bunch of docs
in different countries with different workflows, regulations etc. to agree 100% 
on a GUI (hell, you and Horst work in the *same* discipline in the *same* 
country, and your approaches are poles apart)

This is why we have implemented pluggable window  managers (like window 
managers for X) so we (as developers) can mix'n'match the high-level GUI 
components such as the SOAP control, to our heart's content. Users don't have 
to get involved in this, they can select from a list of pre-made layouts, 
your's among them. 

> would like to contribute time/money to our effort, if only we could > show 
> some progress and unity. 
This the problem, by the time gnuMed has enough functionality to be taken 
seriously, we are "over the hump" and don't need the help so much.
These people, if they are listening: *NOW* is the time to stump up
support if you want a FOSS medical recorda app in Australia, not when the hard 
yards are over!

> us in australia because of local legislation regarding requirements 
> for medical records. If the project actually produced something, it 
> could become part of that process, rather than being trashed by it.
AFAICT Germany already has this law (that medical software be accredited), that 
doesn't seem to stop the brothers Hilbert.
[Karsten/Sebastian, can you clarify this situation?]

Personally I'm not worried: nothing moves slower than an Australian bureaucrat, 
even gnumed ;-)


PGP public key E750652E at
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

Attachment: pgpjT1bZwBzT4.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]