Re: [Gnumed-devel] jl-gui - access to log tables

[Karsten Hilbert]

On Thu, Aug 22, 2013 at 08:28:36PM +0000, Jim Busser wrote:

> The precursor questions include whether, as unforked project controller, you
> 
> 1. agree with the proposal that a given thing should happen, within official 
> GNUmed, and

I agree that the current situation

        clin.substance_intake.clin_when NOT NULL

needs improving.

> 2. agree in sufficient depth about the thing that is being proposed to 
> happen, and

I agree with the conceptual proposal to be able to not
require a precise medication start date.

I don't agree with the technical solutions proposed so far
(except the "write PostgreSQL and psycopg2 support for a
custom type 'timestamptz with accuracy' and use that as data
type for clin.clin_root_item.clin_when"-proposal which I
don't feel qualified for ATM).

> 3. (to avoid duplication, to) indicate whether it is
> anything that is on your personal list of things you have
> interest to do,

It is on my personal list of things I'd be interested in
learning to do (and thereby do), but I do not know how long
it will take before I undertake to attempt it or whether I
will succeed because currently I think I lack the skills.

> or whether the thing will need someone else to provide you
> sufficient code to be incorporated into the GNUmed project.

I won't reject patches which implement that proposal that
are of sufficient technical quality (on which outside 4th
party assurance is fine, say, by people from the PostgreSQL
and psycopg2 community, it is not totally necessary that I
personally fully comprehend the scope).

> Where I am "stuck" is in the lack of having yet gotten
> feedback to indicate whether, and to what extent, I have yet
> succeeded to gain agreement that GNUmed
> 
> 1) needs to be able to record that a particular "date started" is, at least, 
> uncertain and

I don't agree that GNUmed "needs to be able" to record the
fact of uncertainty. I agree that it really should somehow
support not entering uncertain dates.

> 2) needs to be able to record a "date started" only to the
> level of the month, or year -- or even not at all (null)

Again, I do not agree it needs to be able to record an
uncertain date. I do agree it should not require a date
under any and all circumstances.

> If there is not yet agreement, why is there not yet agreement?
>
> Have I not yet adequately developed the considerations and implications?
> 
> Or, is it the case that there *is* agreement, and only
> (not yet) a decision of which (or both) of the above -- or
> anything else -- would be the acceptable solution(s) for
> GNUmed, if and when somebody has the opportunity to
> contribute it?

The latter. And that is because your last few mails were a
culmination of a torrent of posts of increasing pressure.

In the very beginning I said that I WON'T be thinking this
through now. This is what I did - step back from that
issue/thread (except watch for low hanging fruit and
outright bugs you might mention). There was no need (and in
fact there is no power with me, or even right of execution)
to try and constrain your posting of brain dumps related to
that issue.

> >> If I am not confident I will ever be able to properly use GNUmed
> > 
> > This is so overly broad a statement as to border on the
> > untrue. In order to make it true you will have to define the
> > precise context of "properly use GNUmed".
> 
> to use GNUmed for what it would like (?) to be able to do ...
> 
> to accurately and unambiguously (safely) manage, report
> and communicate medication use in my circumstances of
> providing care

Yes, within this context you are correct.

> >> However, unless we can get over a few humps in the next 12-24 months,
> > 
> > Within that timeframe a lot is possible. It begs the
> > question by whom and which.
> > 
> > Things being advocated and catered for are a lot more
> > probable to happen than those not.
> 
> Well, this is one thing that I have been continuing to
> 
> 1) advocate, and

Right, and that's why it is more likely to happen than other
things not being talked about.

> 2) cater for, in terms of trying to adequately develop and
> describe the things that need to be taken under
> consideration, and the possible ways these things could be
> handled.

I agree you have made your desired workflow succinctly clear
and have given sufficient evidence as to why that workflow
would be a good idea.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346