Re: [Gnumed-devel] module interdependency

[Karsten Hilbert]

> Originally, we were going to have plugins for import/export of data to
> other formats (XML, Medical Director, $YOUR_FAVOURITE_PROPRIETARY_FORMAT).
We shouldn be very clear about what is what. These seem to me
to be import filters.

> In the distant future we will write
> interface modules to the HIC (Health Insurance Commission) for
> billing patients under Medicare.
I should hope that we'll never do that but instead teach Free
Billing to do so and interface to Free Billing as usual (FreeB
is an OSS medical billing project run by FreePM an mainly
discussed on openhealth-list).

> Of course these need to be pluggable,
> but are non-GUI dependent. Hopefully some of the plugin code
> (unloading/loading, configuring load-order, etc.) can be generalised to
> this level. 
That may be true.

> - inconsistency across the interface
Only since I introduced the document/EMR viewer and the
simple SOAP plugin.

> - loss of the sidebar, which, in Richard's original design, was supposed
> to be there all the time
All the time while *doing clinical tasks* that is. No need for
it when doing SQL queries, reading the manual etc.

> - design confusion. Originally the other notebooks were for
> "non-clinical" things such as the Python console, contacts and the
> manual, however several of them now are clinical (image viewer,
> demographics, etc.)
That's the main point. I just did what was easiest for me
GUI-wise. I am not a great UI designer nor am I particularly
interested in that. I should like others to take care of that
aspect. Yes, "my" clinical plugins can be moved to "better"
places. I don't object much to that.

> 
> > > We could consider going "the whole
> > > hog" and using XRC [http://www.wxwindows.org/manuals/2.4.0/wx478.htm]
> > IMHO gnumed/client/XRC/
> Is that supposed to be in the repository?
No, but it should in the way that this is a client different
from the one we are writing now.

patient['clinical record']
> Exactly. AFAIK, this convention is not callable across XML-RPC. To be
What would be a better convention to use ?

> honest, I'm not sure what advantage it has over 
> EMR = patient.ClinicalRecord ()
None, really.

> But, even that isn't really portable, as XML-RPC functions can't return
> Python objects (for that, you need PRYO), only basic types and their
> structures (lists and dictionaries in Pythonspeak).
Well, for those few things that return objects one would have
to invent something else
(emr_xml_rpc_server.set_patient['ID']).

> > It is not *a* table. Clinically meaningful entities (which
> > should IMHO be the client-side API) need not map *1:1* onto
> > storage entities (say, tables).
> Can updateable views on the server bridge this gap?
IMHO they seem like a good tool for achieving part of that.

> Note in any case I'm only talking about the clinicial service here. For
> the other services, we don't know what backend schema is being used, or
> even if it's in SQL (the XML database for MIMS, for example) so we still
> need the middleware abstraction, even if it's easy to write using our
> 'in-house' databases. 
That's why I have business objects. The frontend doesn't much
care what the business object does out its backside.

> > What exactly do you need to know ? I can do a writeup. But
> Well, I'm a bit unclear about update notification. I know SQL insert,
> update, delete produce a SQL NOTIFY by the auto-generated triggers,
> which the various clients listen for.
Yes, except that we only have that working for allergies and
health issues right now.

> But, how do we prevent clients responding pointlessly to events on
> another patient (which, let's face it, is what would happen 99.9% of
> the time
We can't really because a) PostgreSQL does not allow for
dynamic arguments being added to notifies and b) PostgreSQL
does not allow per-row triggers, currently (and it is murky
at best when to clear rows from a notifies table where one
could store primary keys belonging to notifies). Suggestions
welcome.

> the time) and how do we ensure the middleware layer responds before the
> GUI code (otherwise the GUI would be loading from the old cache)   
Because the backend signals are only listened to by the
business objects, not the GUI. Upon colding the cache the
business object will send out a frontend signal via
gmDispatcher telling the various GUI parts to update
themselves the first of which will transparently update
the cache in the business object.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346