Re: [Health] Freely configurable Party and Products Flags with Configurable Per-Group Defaults

[Christoph H. Larsen]

Dear Luis, dear Alexandre,

Let me try once more to clarify my concerns, which have been around for
a while, and have been echoed by the Malaysian working group examining
the GNU Health / Tryton ERP work flows:

At present, you can let clerical staff handle patent registration, and
prohibit viewing and editing of medical details using field acces
permissions in the group permission facility. However, this is awkward,
ad as new medical fields are added over time, you have to be constantly
on the watch not to expose medical details to clerical staff. (I know
that ideally, patient registration should be done by a triage nurse,
certainly in an A&E environment, but this is in an ideal world...)

So, this is why I strongly suggest to move the patient registration,
read: entering of core contact data, date of birth, etc. into the Party
domain, already existing in Tryton. This works, in principle, already,
the only problems remaining are that, first: patient numbers re not
issued at that state, second: there is no access to the SSN field, and
third: the field is_patient has to be activated manually, which leaves
plenty of room for human error.

>From this stems my suggestion as follows, which may also give some ideas
for the handling of various product classes (dressings, drugs, vaccines,
etc.):
Strictly speaking, the fields is_patient, is_institution, etc. are
hard-coded categorisations, and, being hard-coded, may deny the
flexibility required for future extensions. It may be desirable either
to migrate them entirely into categories, and make such categories
available to easy-to-handle rules (currently not really solved!), or to
create a separate field group called, for instance, "tags", where any
such tags "patient, employee, ..." can be accumulated.
In addition, such tags (or categories, if the former solution is
preferred) should be assignable by default to certain groups. thisd
means that, for instance, the group "Patient Registration" ALWAYS tags
parties as "patient", be (enforced) default.
I strongly believe that such system offers more flexibility, and, if
combined with somewhat more functional and easier to handle rule sets, a
powerful way to handle any kind of party, product or location. (I
suppose that is it for these three dimensions where such configurable
tagging should become a reality.)
The underlying philosophy is to use the ERP functionality of Tryton as
much as possible, in order to foster further integration and achieve the
goal of a truly comprehensive HMIS cum hospital ERP.
Hope this is a bit clearer now. If not, kindly let me know!

Bests,
Chris

On 19/04/12 20:34, Luis Falcon wrote:
> Hi Chris !
> 
> On Thu, Apr 19, 2012 at 12:49 AM, Christoph H. Larsen
> <address@hidden> wrote:
>> Dear All,
>> One important issue that I would loe to see in the next version of GNU
>> Health, and that would make the GNU Health workflow more logical:
> Yes, there is work to do on workflow optimization !
>> Patient registration at the party level, with automatic creation of
>> patent ID, and SSN, if the new party is a patient.
> I think is good to have it sepatared. Today, you can create the
> patient directly from the patient form. This will also create the
> party.
> The other way around should not be automatic. For example. The
> administrative sector will enter all the people from a  health center.
> Some of the will become patients and others will be just contacts.
> Furthermore,
>> This would include default setting of fields like is_patient=TRUE for
>> certain groups, e.g. group=PATIENT_REGISTRATION - but this can currently
>> not be achieved in a freely configurable manner, b8t only, if patients
>> are added as patients, not parties.
>> Further flags will be helpful, ideally even freely editable flags, like:
>> Add flags to party: patient, employee, etc.
>> Also: Add flags to products: vaccine, drugs, etc, all of the above with
>> freely configurable defaults for certain user groups.
>> Does this make sense?
> I think I'm not understanding your point :-)
> 
> Bests
>> Bests,
>> Chris