[Gnumed-devel] business

[Horst Herb]

Proposal regarding the business object implementation:

------------------------- (GUI) client layer
====================================================
(GUI) client: as few dependencies as possible, preferrably pure Python
to facilitate portability, ease of installation and use on low end machines
__________________________________________________________
Python 
+/- wxPython (or QT, curses, TKinter)  
+/-  RPC library (Pyro? Jabber? Fnorb?)

====================================================
business object layer: can reside on the client, or the server, or in between 
(middleware optional) to suit available hardware / network architecture. 
Consists of zero to many services which group business objects into self 
contained entities
__________________________________________________________
Python
+ PostgreSQL client (PyGreSQL? PyPgSQL? PsygoPG?)
+/- RPC library as above


====================================================
Server layer: PostgreSQL with as much business logic as possible implemented 
as stored procedures and trigger functions
__________________________________________________________


So the client would talk to the business objects which are logically grouped 
on different services, and these services would talk to the backend(s). 
Clients cannot directly talk to the backend(s) by design, though backend(s) 
are organized in a way that the EHR cannot be broken by direct access 
(trigger functions and audit trailing).
One service routes SQL queries through to the backend allowing maximum 
flexibility on the client without need for backend connection libraries 
installed on the client.


Proposal for business object groups:

1.) gnumed_server: provides persistent server side configuration information 
(including information about distribution of services) and allows to execute 
arbitrary SQL statements

2.) Demographics: identities, relationship between identities and related 
geographic information. Cannot refer to any other service, completely 
self-contained.

3.) Clinical_Records: clinical encounters, observations, management .... Can 
refer to all other services, has to do housekeeping of "foreign" references. 
May store (cache) some externally referenced information redundantly where 
performance requires it.

4.) External_Reports: Pathology, Imaging, Discharge Summaries etc. Can refer 
only to Demographics.

5.) drugref: pharmaceutical reference information, interactions etc. Self 
contained, no external references OR references allowed to 
clinical_references

6.) clinical_references: therapeutic guidelines, patient information sheets 
etc. Self contained, no external references OR references allowed to drugref

7.) Administration: scheduling, appointments, billing, rosters. External 
references to demographics only. Stores neccessary clinical and coding 
information redundantly.

8.) Coding (LOINC, ICPC, ICD ...): self contained, no external refernces 
allowed



Horst