Re: [Gnumed-devel] forms concept (instead of placeholders)

[Karsten Hilbert]

Hello Jerzy,

I am happy to embrace your code as one way to get items with
haptic properties out of GNUmed.

What would be your suggestion to move forward to fold this
functionality into the main code ?

I do realize your approach does not fully deliver what I
would like forms to be but it is still useful.

There is a fundamental difference between what a consider a

        a dynamic "form"

vs

        a dynamically-generated "letter".

The latter (pun acknowledged) is a piece of correspondence
which is pre-generated according to certain rules of
possibly quite some complexity including user interaction.
It may or may not be *editable* after generation but it does
not talk *back* to GNUmed after having been generated.
Examples of this are say referral letters generated by
replacing placeholders inside an OpenOffice template.
Placeholders can range from simple substitutions for static
data or expressed as SQL queries inside the template up to
accessing certain parts of the GNUmed user interface for
user interaction (often selection of items from a list). All
this is static once processing of the template into a
"letter" instance is done despite it possibly being editable
*manually* in, say, OpenOffice Writer post-hoc before actual
printing. The prime example is the "consultant's letter"
which by means of a template quickly pulls together a few
data items and maybe todays/the latest exam/findings/
assessment which is the compiled into a neat letter being
sent back to the referring GP.

Forms, however, should allow access back into GNUmed data at
any time before printing. IOW there should be "fields" which
can be tabbed into and from which certain parts of the data
inside the GNUmed database can be accessed again and again.
Forms are more like user interface widgets with the express
purpose of creating a particular output item. One of the
best examples here are (possibly government imposed)
pre-printed fillout forms being re-done inside a practice
management system -- such as prescriptionn forms in Germany
or admission forms.

Now, if we look carefully we quickly see that we would
ideally want both mechanisms in one: most outgoing pieces of
correspondence can benefit from a schematic,
form-by-field-like pre-filling stage from which they are
being processed and presented for final manual touch-up. At
which stage the user will invariably long for direct access
back into GNUmed to add that one previously forgotten or
skipped over piece of data by selection from a convenient
list or other widget. Copy/Paste works, too, but is often a
lot less convenient.

Despite all this I don't see why we shouldn't include your
approach into GNUmed. After all it is implemented, deployed
and proved by use !

> 1. My needs:
>       - all data from backend should be available to a form, so no fixed list 
> of placeholders is acceptable

I agree that all data is wanted to be available. However,
some data items need means of selection by way of user
interaction inside GNUmed (think picking which SOAP items to
include).

>       - a form may contain data from unknown number of records (1 or more)

+1

>       - a form should be editable after creation

+1

>       - a form with data need NOT be stored in backend after creation

I did find that to something I longed for on quite some
occasions - namely when insurance companies etc write in to
ask for particulars about a certain prescription, physical
therapy referral, or colleague asking for a duplicate letter
etc.

I do think there should be a way to ascertain oneself of the
final state of what actually left the praxis on paper.

> 2. Using OpenOffice Writer with Python bridge did not work for me

It does seem to require fairly well-tuned compatibility, yes.

> 3. Currently the best option IMHO is preparing data for a
> form in XML format, then process it with XSLT template to
> get a HTML file. This file is easily loaded into OO Writer
> or displayed in browser. so it can be previewed, edited and
> printed out. The XML can also be exported to another
> application if needed. This may be a common path for many
> uses.

While HTML isn't particularly suited (nor intended) to cater
for absolute layout this is a viable approach all in all.

Another (perhaps simpler ? because requiring a lesser
toolchain) option could be to still use an OO template file
but use means other than Python UNO to access and replace
any placeholders inside it.

> 4. The key for implementation is the decission to fetch
> data for the template directly from backend using SQL query.
> This query is stored together with template (a new field in
> ref.paperwork_templates is required, I added
> 'sql_query'::text). It may have parameters just like any
> other query executed via gmPG2.run_ro_queries.  It returns
> all data at once, no need to collect data from multiple
> objects.

Sure, this sort of approach works. It, however, has one
major drawback: you cannot interact with the user. Thus the
SQL queries must somehow be crafted extremely meticulously
to select precisely the data that is wanted. However, this
is also not *possible* in all cases.

> 6. I enclose in the attached file the class cFormXSLT I use for this 
> processing.
> The typical invocation is like this:
> -----------------
>       #get a template object
>       template = 
> cFormTemplate(aPK_obj=get_paperwork_template_pk(template_type=print_all_progress_notes))
>       #get a form object based on this template
>       _report = cFormXSLT(template)
>       #process it: fetch data, apply stylesheet
>       #parameters are prepared like for any gmPG2.run_ro_queries
>       _report.process(sql_parameters = {'pkeys': 
> self.__curr_node_data['pk_episode']})        #you can pass more pkeys if you 
> need
>       #display (I always preview the reports in OO Writer)
>       _report.preview()
> -----------------

This looks really good to me !

> 7. This approach is the most flexible and does not need
> any changes in application code to get a form.

That surely is a bonus over the placeholders defined inside
GNUmed. We do need those too, however, for the above
reasons.

> An example SQL queries are here:
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed/application/update.paperwork_templates.sql_query.sql

Nice.

> To resolve problem of text fields with multiple paragraphs
> (hard line breaks) I filter these fields through a function
> 'xml_paragraphs', then add corresponding template in XSLT.
> The function is here:
>
> https://www.xythosondemand.com/home/BLZ/Users/jerzy.luszawski/Public/gnumed/application/function_xml_paragraphs.sql

No problem adding this to the GNUmed database when needed.

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