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

[Luis Falcon]

Hi Chris !

On Thu, Apr 19, 2012 at 11:27 PM, Christoph H. Larsen
<address@hidden> wrote:
> 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.
When the patient is created from the patient form, the patient field
is marked automatically.

The SSN is not a sequence, so it has to be entered by hand, in
contrast to the internal Health center patient ID.
>
> 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!

I like the category concept. Actually the signs and symptoms section
in 1.4.5 has been redesigned to be more scalable. No more checkboxes.
Now the health professional chooses from the ICD-10  (or other
standard) sign and symptoms list.
I am also using the category/group concept in diseases, so we can take
actions upon those groups.

Now,  we have to be careful with using categories for everything. This
can create major issues if modified or deleted, specially when using
them within a domain. The good thing about finite/small number of
possibilities, like in the parties types for health, I still believe
that the Boolean type is optimal.

But it's a good discussion and I'm open to suggestions !

Bests

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



-- 
Luis Falcon
GNU Health
http://health.gnu.org