health
[Top][All Lists]
Advanced

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

Re: [Health] Freely configurable Party and Products Flags with Configura


From: Christoph H. Larsen
Subject: Re: [Health] Freely configurable Party and Products Flags with Configurable Per-Group Defaults
Date: Fri, 20 Apr 2012 11:28:33 +0700
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.20) Gecko/20110820 Iceowl/1.0b2 Icedove/3.1.12

Dear Luis,

On 20/04/12 10:53, Luis Falcon wrote:
> 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.
Sure, and this functionality could be pushed into the "Party" context,
if is_patient=TRUE.
> 
> The SSN is not a sequence, so it has to be entered by hand, in
> contrast to the internal Health center patient ID.
Precisely. This field will be required to be available even for clerical
staff during patient registration.
>>
>> 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.
My thoughts, indeed. Which is why I am thinking of an ex-category tags
concept that can set to certain (enforced or suggested) defaults for
certain groups, and linked to rules.
> 
> But it's a good discussion and I'm open to suggestions !
Thanks!
> 
> 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
>>
> 
> 
> 

-- 
Dr. Christoph H. Larsen
synaLinQ (Vietnam)                      synaLinQ (Kenya)
P.O. Box 55, Bưu điện NT, 01 Pasteur    P.O. Box 1607, Village Market
Nha Trang, Khánh Hòa                    Nairobi 00621
Vietnam                                 Kenya
Mobile: +84-98-9607357                  Mobile: +254-753-632481
        +49-176-96456254 (Germany)
Fax:    +49-231-292734790
Email:  address@hidden



reply via email to

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