gnumed-devel
[Top][All Lists]
Advanced

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

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


From: richard terry
Subject: Re: [Gnumed-devel] Where to start with gnumed
Date: Tue, 25 Feb 2003 19:31:13 +1100
User-agent: KMail/1.4.3

What is a XML-RPC interface.

Does that mean we drop wxPython and use a web interface!

Can you explain all this in simple terms.


On Wed, 26 Feb 2003 04:54 am, Horst Herb wrote:
> 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
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel





reply via email to

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