Re: [Gnumed-devel] gnumed ideas 0.1 and post-0.1

[Ian Haywood]

J Busser wrote:
> At 7:25 PM +1100 2/18/05, Richard Terry wrote:
>
> > 1) Get demographics working (do nothing else until it is) and 
> > demonstrate you
> > can load a patient.
> >
> > But everyone works on this - It's no use running off developing other 
> > more
> > complicated areas until you can do the basics.
>
>
> At 8:05 AM +1100 2/21/05, Ian Haywood wrote:
> Re: [Gnumed-devel] re: v_basic_address.city now urb
>
> > > In v_basic_address,
> > > I suppose urb is a more consistent name than city, but it's been city 
> > > for quite a while.
> >
> > It had been "identity.id" for a while too. ;-)
> > I note some people are using pk_identity, pk_marital_status, etc., 
> > whereas
> > before "fk_foreign_key" had been the convention. Karsten, can you 
> > confirm?
> >
> > > In cOrg, cPerson inherits from cOrg,
> > > What about  v_basic_person.pk_identity vs org.id  , how does that 
> > > integrate with org.id when
> > > trying to refetch addresses ? I thought it was fairly simple just 
> > > overloading a method
> >
> > My preference was to keep org and v_basic_person consistent on the 
> > backend, but I can see this is a losing battle. I've put getId () back.
>
>
> Richard and Ian seem each now to be working on demographics & I surmise 
> also GUI widget development (though I am not sure if Ian works in 
> horst-space or richard-space).
Richard-space as of this week.
The widget should work just fine in "Horst space", please report if it doesn't.
> What is the best way to get demographics working in the shortest time, 
> using the people currently involved?  How do we clear the way? Can their 
> efforts be adversely affected by other things, which should therefore 
> first be solved, resolved, decided and agreed-to?
>
> I am thinking
>
> (a) what more of the demographic functionality for 0.1 is needed to be 
> defined, and let us assure the RoadMap contains the needed detail
Names, addresses, contact details and ID numbers.

We can load all three as of yesterday, creating/saving shouldn't take too
long (it's easier second time around ;-)
> (b) after (a) shall we examine the relevant tables in the schema to 
> identify anything extra that should be added or modified (including any 
> changes of name), doing so, and then *delay* changes EXCEPT as required 
> by demographics, until after 0.1
I have one question for the list. Currently much in demographics is dynamic: 
that is,
the widget gets the various types of addresses ("home", "work", ....),
contacts (phone, fax, ....) and Id number (social security number, Medicare 
number,....)
from the backend, at runtime. This is nice and flexible, but causes problems
when you want to do something programmatically with a piece of data
(i.e send an email)

We can say
if comm = _("email"):

or somesuch, however this creates a "double-translation problem": the string 
may be translated on
both the server and the client: we'd better hope the translators use *exactly* 
the same word
(the best example that comes to mind is "Handy" vs. "Funktelefon", although I 
appreciate the latter
is uncommon)

This is long-winded way of saying we do need to hardwire some database numbers 
in the business
layer, so we can say, "this is an e-mail", "this is a fax" etc, no matter what 
its actually called in the
local language.. For ID numbers it doesn't matter
(because code that uses them will be locale-specific anyway)
> (d) I am new to objects (the classes & API etc) but imagine if they get 
> renamed or restructured then that, too, will break things and might be 
> nice to avoid breaking. Can we identify what issues / needs demographics 
> would have of the objects and again try to freeze or minimally disturb 
> them except as demographics requires during its 0.1 construction?
We've already been through this cycle once, demographics has been
re-written from the ground up over the last 4-5 months.
I'm loathe to do it a *third* time.
> Can we assemble whatever is the to-do list and maybe move what is 
> currently on the RoadMap page to a new page like 
> PatientCreationAndModification
> - should Search be included here?
> - (I like Creation only because Input sounds like inviting what patient 
> think, but I realize we are not really "Creating" patients so mine is a 
> weak argument; it may be more understandable to users if there is value 
> in a shared vocabulary
Unfortunately Jim, I'm basically finishing off this area of functionality:
it's just too late to be discussing design.
(doesn't mean we can't come up with simple changes/extra features to add, etc.)

Ian

signature.asc
Description: OpenPGP digital signature