Re: [Gnumed-devel] Where to start with gnumed

[Horst Herb]

On Tue, 25 Feb 2003 06:24 am, richard terry wrote:
>
> From a functionality point of view, when typing in a patients name, if the
> name is found (and single instance) then the patient summary screen should
> appear, with the patient name and address in the top text box.
>
> Why don't we just aim to get this much going as a start, now that those
> doing the backend are progressing.
>
> Any Thoughts?

Yes. In recent months I have been more busy involved in health IT politics and 
negotiations with "key stake holders" (oh my, how do I hate these buzzwords).
One suggestion I made raised many eyebrows and a subsequent flood of private 
emails from the most unexpected parties:

To build any one health record system in a modular way, where each module can 
be replaced by a module from any other compliant source. Different players in 
the field would first focus on implementing whatever is most needed at that 
time and whatever their budget/capabilities support: The "air bus" of health 
records.
Whenever anyone is not happy with a module implemented by someone else, they 
roll their own.

Now the clue: instead of using a heavy weight interface like CORBAMED whcih is 
expensive and tedious to implement, each module has a simple lightweight 
XML-RPC interface.
To prevent endless fighting about interfacing standards, the first implementer 
of a module is entitled to define the first interface. All subsequent 
interface modifications have to be backwards compatible - no fiuture version 
is allowed to break clients using the first published version.

The very first module needed of course is a demographic one: a "super address 
book". 
Our gnumed table structure is well suited, and our postgres backend will do 
fine. No changes here.

What changes is that our clients should start using this XML-RPC interface - 
whoever implements it first gets the right to define it.

Example of XML-RPC API required:

- function GetID(searchstring) where search string contains a dict of 
properties (key:value pairs of surname, firstname, dob, zip  ...) with full 
or partial serach expressions, wildcards ('*'=any sequence of characters, 
'?'=one character, ^=case insensitive) allowed : returns a list of IDs 
matching the search expression.

function GetPerson(ID)
returns a dict of properties beloging to the person identified by ID (surname, 
name, dob ...)

dict refers to key:value pairs, in Python the native python dictionary type.

function GetAdddress(ID, category='home')
returns a dict of address related properties (street, town, zip, ...) with an 
optional 'category' classifier (home address, work address)

function GetURL(ID, category, subcategory)
returns a dict of communication related properties such as phone number, 
email, fax, pager, web address ...)

All these functions have their corresponding SetXXX functions

The bad thing about it: I cannot disclose yet who else will participate, and I 
have no binding agreements yet at all, only expressions of interest. 

Still think it is worthwhile doing it - it abstracts the underlying adta 
storage nicely, has no major performance impact, allows for example LDAP 
instead of Postgres for "address book purposes" if one wishes, etc. 
Would fulfill the expectations of the "services" concept of gnumed.
Would allow cooperation with other projects like OSCAR, without any project 
having to "give in" into te concepts or implementations of others

This type of API - as long as nobody breaks backwards compatibility - would 
allow any developer extending it from a primitive base "as needed"

Example: somebody wants "eye colour" as property of "person". He just needs to 
extend the "address server" module to include that property when using 
GetPerson(ID), but any existing modules that don't need nor expect the "eye 
colour" property would still work happily unchanged, and the *interface* 
needs not to be changed either.

It also allows to implement "dummy test modules" for user interface 
implementation and testimg where we are too slow with backend implementation.

XML-RPC in python is dead easy: if it is generally wished, I will post an 
example "proof of concept" server and client to the list (will need a few 
hours to write it)

Horst