gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] trying to sort out a few things - From Richard Terry


From: Richard Terry
Subject: Re: [Gnumed-devel] trying to sort out a few things - From Richard Terry
Date: Mon, 21 Jun 2004 13:36:53 +1000
User-agent: Mozilla Thunderbird 0.6 (X11/20040503)

Just a comment about the example below about excluding medications/history items from referral.

This is a good example of where intelligent use of the editing area is valuable. If you remember the vb screen dumps there was a check box labelled 'confidential' which when checked flags an item as not for general distribution - something similar can be in gnuMed. The same concept can be applied to the medication list, but is fraught with danger as the omitted drugs could be relevent in their interactions to something another party prescribes. As any letter etc should be checked by the doctor, they should have the ability to edit its contents and delete what is not necessary/wanted. By in large, I've found 99.9 of patients don't mind what is in a referral letter given to medical or paramedical parties. Public/Political opinion in this country (AU) is really swinging around to 'opt in' by default with 'opt out' by request.
Karsten Hilbert wrote:

Ian,

I'm not sure we will ever need placeholder domains, as simple variables are 
themselves Python expressions.
On second thought you are quite correct. The rub is to think
of all label-type placeholders as variables, eg. not running a
certain intra-client method when seeing @patient_last_name@
but rather pull the value by treating it as standard variable.
The only other "domain" we need would be Python code. However,
   val = eval('some_variable_name')
and
   val = eval('some_python_expression')
work the same. I missed that. And, no, we won't need a domain
for direct SQL either as those can be wrapped in simple python
expressions. So I guess we can pretty much go by your current
design :-)

The other domain you suggested ("gnumedlets") for calling complex scripts inside a form, IMHO it would be better to add a method to the appropriate business object to do whatever complex manipulation.
No. We need UI interaction within gnumedlets.

However, I've no objection if  they are necessary, I have no idea what forms 
you are dealing with.
You are dealing with them, too. It's not the forms, it's the
content.

Here is the use case:

1) I am referring Mr.Jones to a rheumatologist because there is
  something fishy about his random, uncontrollable bouts of
  gout. I certainly cannot just check a box "include meds"
  since I would want to exclude his Viagra prescriptions.

2) Said Mr.Jones is sent to the facial surgeons for treatment
  of an odontogenic abscess. I will want to include past Hx
  but would need to browse and pick entries since they have
  no business knowing about his erectile dysfunction.

Made my point ? ;-)

Granted, but why do we need to run the bootstrapper *3* times to get a working
database (4 if you want Australian extensions)
Simply because I haven't come up with a good way to
   \include that_file.conf
inside bootstrapping conf files at arbitrary locations. Once
we can do that all is fine.

If there are no objections I will add a bootstrap-easy.conf file to our collection of conf files to do this in one go.
An OK quick fix for now, I guess. It's just that I won't be
the one maintaining it but, hey, no objections to someone else
doing it.

Then we can add a wxPython wrapper which asks for the root password in a pretty
dialogue box or whatever.
The password is cached within a single bootstrapper run. No
need to wrap anything else around that unless one feels like
it.

Karsten





reply via email to

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