Re: [Gnumed-devel] forms

[Karsten Hilbert]

On Wed, Jun 20, 2007 at 03:20:11PM +0200, Ruthard Baudach wrote:

> I agree that the capability to handle forms is crucial to EMR's used under  
> the reign of bureaucrazy, as in Germany and presumably in Austria.
Yes !

> The test and score widgtet I'm working on is eventually nothing else than  
> a set of sophisticated forms.
True, indeed. The only difference between it and the
"normal" forms is - the *target*. The target for your score
"forms" is a method that calculates something from the
content and stores it in the database. The target for "real"
forms is printer and paper - also via a method.

> I tried to paint scanned form on a panel and define wx.TextCtrl instances  
> using absolute poistioning. It seems to work.
It does ?? Pretty cool :-)   I didn't know that. This is how
open source works: some people (like you) do some work which
is then improved by other people. BTW, the OOo-interfacing
code was contributed by another German, Kai Schmidt.

I was thinking of simply using OpenOffice to do exactly that
- load a scanned form as a background image - and define
textboxes at the appropriate places. Even a clever user can
do that - which is very important, I suppose (as a poor-mans
form editor, that is).

There *might* be a process where later the GNUmed team takes
user-defined OOo forms and converts them into
scan-and-textctrl forms for better integration with GNUmed.

> Thus a definiton of a form could consist of a dictionary
> 
> form = {
>       'background': '/path/to/file/with/background/image',
>       'control_1': {
>               'type': 'xx',
>               'pos': (x,y),
>               'size': (x,y),
>               'default': 'default value, which should involve some magic 
>               fairy or  demon in order to automagically fill in gnumed-data',
>               'tooltip': 'This is a ToolTipText'
>               },
>       'control_2': {
>               ...
>               }
>       }
> 
> preferably the background image should be stored in the same file as the  
> control definition, I just did'nt figured out how to do this yet.
Pretty much, yes, except that both background and
definitions will be stored in the database. We even have
tables for that already :-)

One reason is that this will enable all workstations in a
local network to immediately use the form once it has been
defined.

As for the actual definition I am sure we can learn from NetEpi.

> Displaying this definiton is easy, reading the data filled in by the user  
> is also no problem.
> 
> I've got no idea,
>       * how to get this data on the form
That is why I was thinking to use OOo for that and let it do
the hard part - sending the on-screen stuff to the printer
(to CUPS, actually).

For forms integrated with GNUmed we could do it like this:

- pull the data from the GNUmed-onscreen form
- merge the data into a template (for example OOo) by
  means of replacing placeholders
  - BTW, we have code to do that already :-))
- connect to OOo and tell it to print the file
  - this will NOT require the user to interact with OOo !

>       * how to store this data in a GNUmedish way
No problem. I will take care of that.

>       * where to hunt down the mentioned fairies and demons.
You tell me which fairy you need I pull it out of my hat.
Also, this years theme is Kukishinden Ryu - Fighthing like
Nine Demons. I think I can handle the demons :-)

> Writing these files by hand is very time consuming - a form editor would  
> be fine. Well, we'll see.
Well :-)   That's why I was thinking to use OOo as a poor
man's form editor ...

As for the actual definition and implementation I think we
should carefully study the NetEpi approach.

There are two pages in the Wiki which collect a few ideas
and thoughts about form handling. Ruthard, would you like to
follow the ideas we develop here and document them in the
Wiki ? Feel free to merge the discussion with what is
already there so that we have a good plan on how we will go
about this.

BTW: the main point of the next release is the OOo letter
handling - which really is nothing more than one special
form.

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