gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] screenshots of 0.9 features


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] screenshots of 0.9 features
Date: Tue, 26 Oct 2010 22:44:27 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Oct 26, 2010 at 08:56:40AM -0700, Jim Busser wrote:

> > Attached find the improved master data management interface.
> > 
> > Diligent readers will notice the "Organisations" list ...
> 
> Nice... would Hospitals be configured inside Organisations?
> 
> Would Organizations be relevant to the demographics of the
> phone numbers at which a patient may be able to be reached
> at work,

For one thing, patients can have "at work" phone numbers.

OTOH, once we start associating persons with organisations,
then, yes, that link can be followed.

> or to one of the patient's addresses?

Same.

> Knowing where
> a patient works (geographically) can be helpful to planning
> their care, when they are still well enough to be working
> while they get their tests or treatments or visits.

That can easily be done by attaching work addresses to
patients.

> Would Diagnostic organizations include not just path labs,
> but diagnostic imaging,

Sure, in fact I hope to merge "Diagnostic organizations"
into "Organizations" with respective categories.

> and do Organizations handle
> "branches" where the name may be the same but in addition to
> each branch having a distinct address) there may be a branch
> "number" or other sub-identifier?

Surely so.

Since the organizations as such are nearly conceptual only
(the only fields they carry are category and name) the user
will most of the time work on/with the organizational units
only and directly.

> This will be important in the viewing of any search
> listings, where the name alone will rarely be enough for a
> precise choice. The subidentifier plus maybe address / phone
> numbers could be relevant to try to show.

        Sure. This is the table structure:

create table dem.org (
        pk serial primary key,
        description text,
        fk_category integer
) inherits (audit.audit_fields);

create table dem.org_unit (
        pk serial primary key,
        description text,
        fk_org integer,
        fk_address integer,
        fk_category integer
) inherits (audit.audit_fields);


        And this is the view for the business object the code
        will mostly work with:


create view dem.v_org_units as

select
        dou.pk
                as pk_org_unit,
        dvo.organisation,
        dou.description
                as unit,
        dvo.category
                as organisation_category,
        _(dvo.category)
                as l10n_organisation_category,
        doc.description
                as unit_category,
        _(doc.description)
                as l10n_unit_category,
        dvo.pk_org,
        dvo.pk_category_org,
        dou.fk_category
                as pk_category_unit,
        dou.fk_address
                as pk_address
from
        dem.org_unit dou
                left join dem.v_org dvo on (dou.fk_org = dvo.pk_org)
                        left join dem.org_category doc on (dou.fk_category = 
doc.pk)
;


That'll make it easy to display the appropriate information.

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



reply via email to

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