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

[J Busser]

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).

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

(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

(c) can we figure out to get the db schema as generated by PG autodoc 
to reflect it? is the cron job running and is it tripping over 
anything?

(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?

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