Re: [Gnumed-devel] gnumed architecture

[Karsten Hilbert]

>> Agreed. But again I must whine about the lack of proper
>> authentication.
> Performance (persistent connections!) + authentication is nicely taken care 
> of 
> if we run XML-RPC via Jabber. The Jabber client library is slim, and AFAIk 
> tehre are even pure python implementatins (no installation troubles for end 
> users)
Hm, cannot comment on this as I haven't tried or looked.

>>>> If we would limit ourselves to Python (which we should not),
> But we would if we would use the elegant PYRO (Python Remote Objects) as 
> model 
> for distributing services/processes. It would be horrendous work to port it 
> to any other language (except for Java)
See, this is why I am weary of OODBMS. I always wonder how to
retrieve them objects with any language other than the one that
put them in the database. Probably I am wrong. But a relational
database is the equivalent of a text interface. It is
immediately readable (at the SQL query result level, anyways).

> I would actually join billing & scheduling into a single service, 
Yes.

> I would fancy separating clinical from "external reports",
That's what I was trying to get at.

> but have some redundancy in clinical (embedding
> relevant reports/results into the narrative 
> part of clinical)
For referral reports a short summary can be put into the
narrative by the user. For processable external lab results
they can be stored in clinical directly (we get them in a
well-defined text format). The current BLOBs implementation
does have a field for "short comment" the content of which may
be used to represent the link to the full "external results"
document. No further magic needed here.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346