Re: [Gnumed-devel] vaccinations

[Karsten Hilbert]

On Sun, Sep 25, 2005 at 07:19:08PM +1000, Ian Haywood wrote:

> I'm trying to get vaccinations working, I've run against this problem:
> cClinicalRecord.add_vaccination () requires an episode,
...
> However, with an unattached progress note, get_problem() returns None
...
> This leads into the broader question of when popup-generated clinical objects 
> get
> committed to the backend.
I have been thinking about this all day. Eventually your
approach seems to be the only real way out of the dilemma:

> IMHO popups should save their widgets to a dictionaries, held by
> cResizingSoapPanel, which then commits the lot en masse to the middleware
> on it's own save_data ()
The reason I did not employ this approach in the first place
is the following:

Popup keywords are handled by the cResizingSTC objects
*inside* the cResizingSoapPanel. The latter does not know
anything about what's happening with popups or not.

Now, the cResizingSTC objects don't know how to store the
popup data in cResizingSoapPanel. They could be taught how
to do so but that would make them dependant on their parent
being a cResizingSoapPanel. If we accept that all is fine.

The other line of argument would be to let the cResizingSTC
objects keep their popup dicts to themselves until
cResizingSoapPanel.save() is called. This is fine, too, but
we would then lose the ability to edit popup dicts *across*
input fields. Imagine you enter a previous vaccination in
"Subjective". You then enter the vaccination you gave today
in "Plan". During that the patient eventually finds his vacc
sheet somewhere in a coat pocket. When you look at it you
find out that the previous vaccination you entered in
"Subjective" has to be edited because it's a different
vaccine and now you also know the proper batch no. Now one
would have to *go back* to "Subjective" and re-popup the
previous dict. It would surely be desirable to able to
re-edit/re-popup the "Subjective" vaccination right from any
field we chose. But this would require the cResizingSTCs to
be able to get at the dicts of either the parent
cResizingSoapPanel or the other cResizingSTCs which sounds
horribly fragile.

But, hehe, spelling out the problem brings the solution
to mind:

Upon instantiating a cResizingSTC a "master dict root" is
passed in which must be a dict. The STC gets the data dict
from the popup and stores it into that master dict like so:

cResizingSoapPanel.master_dict = {}
cResizingSoapPanel.add_cResizingSTC(dict = self.master_dict)

in cResizingSTC on GetData() (or GetValue):

self.master_dict[popup_type] = [{
        'field type': 's',              # either of SOAP
        'ID': 'some vaccination',
        'data': the_popup_data
}]

Such that the master_dict could end up being:

master_dict = {
        'vaccination': [
                {
                        'field type': 's',
                        'ID': 'vaccination tetanus 12.07.2001',
                        'data': the_popup_dict
                }, {
                        'field type': 'p'
                        'ID': 'vaccination tetanus 26.09.2005',
                        'data': the_popup_dict
                }
        ],
        'prescription': [
                {},
                {}
        ]
}

given that two vaccinations were added and two prescription
items. The 'ID' field is needed to allow selection of which
field is to be re-edited.

cResizingSoapPanel.save() would do:

for popup_type in self.master_dict.keys():
        if popup_type == 'vaccination':
                data_list = self.master_dict['vaccination']
                for popup_data in data_list:
                        gmVaccination.create_vaccination(data_list['data'])
        elif popup_type == ...:
                ...
        else:
                log(unknown type)



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