gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jerzy Luszawski
Subject: Re: [Gnumed-devel] forms concept (instead of placeholders)
Date: Tue, 20 Oct 2009 23:45:37 +0200
User-agent: KMail/1.9.10

Hello,

> 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.
OK, I understand this difference. I simply used the word "form" because this 
object is based on class cForms and uses cFormTemplate, etc.
So, let's better talk about "reports" (this is more general than "letters").
Reports need only one-way access to backend - READ.

> 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. 
Currently I don't see any simple way of implementing this. The interface to OO 
Writer does not work as expected in this area (at least in Windows, so that 
is not acceptable for me).

> 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.
From my experience, it is much better to implement an even not very convenient 
but simple feature, and teach users to use it correctly, than try to code 
every possibilities to make users happy. (unless you are 100% sure your code 
is bug-free :)
I mean it is easy to teach "you enter data in Gnumed, and only in Gnumed, if 
you enter data elsewhere, you are responsilble for saving it". (I have used 
this principle in my earlier medical system, and it worked nice.)
If you allow users to enter data (into "forms") outside Gnumed, you will have 
to trust them that they will properly close the helper application, they will 
not make duplicate copies, will not open a temporary/local file asking why it 
has not pushed something into Gnumed, or not cause any other trouble.

There is already a way of storing an externally edited document in Gnumed, if 
someone has to do it. 

> > 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).
This is the task of a plugin, dialog window or menu activated before invoking 
the report processing. To invoke report generation: (1)  the template and (2) 
data scope must be known.

> >     - 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 agree it would be handy on some occasions.
For now, I can live without it.

> I do think there should be a way to ascertain oneself of the
> final state of what actually left the praxis on paper.
Agreed.
Solution 1: Do not allow any alteration on generated printouts
Solution 2: Store every printed document in database (as PDF, postscript or 
similar format, with certified timestamp and digital signature)  (that is the 
requirement in Poland to run a totally paperless praxis = mission impossible)
Solution 3: Use Gnumed to access information quickly for everyday use, but 
keep a paper copy of every required document in patient's file, for legal 
purpose. (That is what I do)

> > 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
(...)
> 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.
;) I have already done it in the meantime. OO document is just an XML file. 
You can just replace any text inside. But I couldn't find a way to prepare a 
template for multiple records.

> > 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. 
The interaction takes part before running the query. For example I use a 
report for printing all progress notes from an episode, which is invoked from 
context menu on right-clicing an episode in EMR tree. So I have an episode's 
pk (from the clicked node), and I pass it to the run_ro_queries as a 
parameter. 
Note, that with little modifications the end-user will be able to easily add 
any reports requiring only pk of current tree node, and if you enable 
multiple selections more opportunities arise. 
I realize it is not a perfect solution, and we should work on more flexible 
way of defining data scope.

to be continued...

Jerzy Luszawski




reply via email to

[Prev in Thread] Current Thread [Next in Thread]