[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
__________________________________________________________
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
- [Gnumed-devel] business,
Horst Herb <=
Re: [Gnumed-devel] business, Karsten Hilbert, 2003/05/30