Re: [Gnumed-devel] re: gui / schema

[Karsten Hilbert]

> The specific uses of the client make it difficult to use the workflow in 
> different environments:
> (e.g.  the lab result widget ; how to get it working with test data  )
It already does. Look at Capt.Kirk. Ask if need be.

> The schema is pretty understandable, except when triggers other than for 
> something cross-cutting like auditing is operating
> (I don't think there are any yet).
All the tables I have worked on are fully audited. And the
audit results have been checked (manually) to contain what one
would expect. Auditing *does* work today.

> I'm not sure about how external id referencing is being used:
Not yet. Or rather, what are you referring to exactly:

xlnk_identity tables or lnk_person2ext_id ?

The former stores identity.id values across separate
"services" but is fairly useless once we go into *really*
distributed databases. However, it affords room for storing a
true PUPIC already.

The latter stores external IDs associated with the patient,
eg. previous EMR system record ID, X-Ray patient ID, etc etc.

> is there already a business object handling this ?
The former: handled by the "main" business object for a
service, eg. cClinicalRecord, cDemographicRecord. The latter:
not really, yet, apart from code in cDemographicRecord.

> It's ok to reuse components for say custom clients too,
Sure. We already use custom clients for indexing or viewing
scanned docs.

> or maybe customization of layout will be done?
Yes.

> Is Ian/someone adding extra customizability to  the client platform ? 
Cleaner separation of the two layout manager paradigms is
underway.

> There's already the plugin load/unload feature which  Karsten did recently,
Only applies to Horst space notebook layout manager.

> Is it possible to generalize Richard's experience about workflow,
No.

> say using a specific behaviour on the editareas as an example,
> citing the reason a certain workflow is recommended (speed, usability 
> comparison to another workflow that didn't work as well)
> ,  and then make guidelines out of them , and perhaps examine 
> applicability with different layouts. ( just discursively , at this stage)
Richard has done exactly that in his extensive docs linked
from the Wiki (for his design, that is).

> The other issue is forking / dilution of effort : is it really forking 
> if some components of the current gui are put into a client customized for
> a particular area/ purpose ?
Not necessarily, depending on how it is done.

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