Re: [Gnumed-devel] Two patches

[Ian Haywood]

Karsten Hilbert wrote:
> > Ian,
> >
> > I have committed your schema patches with some changes here
> > and there. Your concepts are untouched though. I do like the
> > way with form_fields though I am wary how it will work out.
>
>
> I have thought about this more. We need to be very clear about
> the separation of definitions for *display and input* - which
> is what your form_fields defines
Not really, they define the data types the form template wants, with
one display hint. 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.
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.

> 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.
For example an AU script is a drug_list and two boolean flags, a
German one is a drug_list and a payor. Presumably the "payor" concept applies 
to other
German forms [1], and drug_list is shared between the locales (although it is an 
"arbitrary" field
specific to the script form within our own formsets)

Ian

[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.