Re: [Gnumed-devel] Two patches

[Karsten Hilbert]

> Not really, they define the data types the form template wants, with
> one display hint.
Ah, OK, this seems to be a point of view I hadn't considered.

I agree this is useful which is why I said it's worth
exploring.

> IMHO a interesting proportion of form GUIs can then be
> auto-constructed, but I agree not all, some forms will need a "hand-written"
> GUI form which then passes the data directly to the templating layer.
I fear most of them will be that way but, hey, your additions
don't limit that. Also there may be more and less smart form
GUIs such that a form *can* be filled out even when there's
no specially tailored GUI for it...

> Some forms may not even have a GUI, one could imagine a nightly cron
> job which prints out patient reminder letters and reports to payors and 
> other third-parties overnight while no-ones using the printer.
True enough.

> >Strings, bools, lists and such don't do the job. Also, for
> >quite some lists we won't know the list content until runtime.
> Indeed, what I'm aiming for is a rich set of high-level types,
> which GUIs can display however they see fit.
Well, it's not just *how* they see fit. Most of the smarts of
an input field is in the supporting context code, eg. even if
a GUI decides to represent "text" fields by STCs and string
fields by phrasewheels there's no way in the world it can
deduce from the DB definition how to attach a phrase matcher
to it or how to set up keyword popups. Unless that's defined
somewhere which, however, should perhaps be kept separate from
the generic field definition as it is application specific.

> For example an AU script is a drug_list and two boolean flags, a
> German one is a drug_list and a payor.
Hell no, if only it was that easy.

> Presumably the "payor" concept applies to other German forms [1]
Yes.

> [1] I suspect you would in reality select the payor once for each patient 
> and store it in the demographics layer,
> then grab it from gmDemographicRecord inside the form code, without having a 
> specific form field for it, but hopefully I'm
> getting the idea across.
No, the situation is a lot more complex. There's *at least*
three possible payor for each script depending on
circumstances.

Also, I would not let the form code access a demographic
record entity. That is way too application specific IMO.

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