[Top][All Lists]

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

[Gnumed-devel] business

From: Horst Herb
Subject: [Gnumed-devel] business
Date: Thu, 29 May 2003 21:20:32 +1000
User-agent: KMail/1.5

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
+/- 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
+ 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 

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 

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 


reply via email to

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