Re: [Gnumed-devel] XML forms

[Richard Terry]

Forms, one of my pet subjects.

There is NO NEED        for anything other than a common form with the 
exception of a 
prescription . I've proved that myself. In my program there is only one style 
of output. Doesn't matter whether you are ordering pathology, cardiology, 
sleep study, xray, physio etc. All you need on each of these is the 
same:company/address/patient details/space to request/space for clinical 
information/some check boxes if desired (change for each form), space for 
paitent instructions, box at bottom for multiple addresses (intelligent - 
lists those in area), spot to sign. I did alot of work determining the 
optimal space allocation on an A4 Page. Pity I don't have a scanner I could 
scan one in and post the png.

Despite hospitals/radiologists/physios/ etc etc etc sending their own forms I 
have refused to, and have never used them since I implemented this form 
generation back in 1998. Never had one refused ever ever ever.

Don't get led down the road of the concept that everyone needs their different 
form.

What you do need is a good contacts database in the background and some 
intelligent coding. I can show all this stuff at the conference if desired 
and time available.

Referral letters are not a form, they are a referral letter and are treated 
differently.

Regards

Richard

On Monday 28 July 2003 18:24, Karsten Hilbert wrote:
> > In that case, you might as well do the whole UI as XML: interesting,
> > but IMHO should be post-1.0
>
> No, I am not thinking in terms of defining the interrelations
> of a rich widget set in XML. I don't understand why if one
> thing seems to be a natural fit for something it ought be be
> applied to other things that seem similar. XUL showed that that
> road is slow, IIRC.
>
> > We already have empty UI widgets for all the core modules
>
> For the few essential forms (say, prescription, referral)
> this will do well but not for the myriad other forms that are
> bound to happen to us. For those we need a way of describing
> them (XML?), displaying and accepting input into them and
> printing them. The displaying and accepting input part need
> not be all too sophisticated. I am using a forms engine daily
> that maps forms to a text user interface, accepts a few
> restricted field types only (free text, number and date, mainly) has
> some logic attached to the fields via their definition and
> prints out via text mode on the printer. That works extremely
> well.
>
> But for the roadmap we can stick to just
> prescription/referrals. For just *that* we don't even need
> the forms engine, initially.
>
> Karsten