[Top][All Lists]

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

Re: [Health-dev] [bug #35461] Privilege Separation for Patiet Registrati

From: Christoph H. Larsen
Subject: Re: [Health-dev] [bug #35461] Privilege Separation for Patiet Registration
Date: Tue, 07 Feb 2012 11:41:19 +0430
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110820 Iceowl/1.0b2 Icedove/3.1.12

Dear Luis,
Thanks a lot for your long reply! Yes, I think I fully understnad the
point you are making: Internal HC-specific Patient ID (like in our case
in Afghanistan), versus the SSN ~ UPI = Universal Patient Identifier.
For patient core data to be entered via the "Party" facility, the
following features would be desirable:

A more finely grained management of Rules: Presently, a rule is
fulfilled, if the FIRST condition is fulfilled. This renders AND
conditions hard to implement, unless you go through added groups.
This rule-governed behaviour would be great to secure access right to
different groups of parties is_patient versus NOT is_patient, or all
parties that are NOT is_patient AND NOT is_institution as addresses
relevant for medical care providers).

Also, it would be great, if we could easily define DEFAULT values for
specific fields, e.g. setting is_patient to TRUE be default for a
certain group. Is there currently any way to do so?

Finally, automatic Patient ID generation would still be great even at
the Party facility level. (Dcotors are not very good at IT, so we have
to make their lives as easy as possible - grin!)

Hope this is some extra food for thought. Let me know how I can help.


On 07/02/12 05:52, Luis Falcon wrote:
> Update of bug #35461 (project health):
>                   Status:                    None => Need Info              
>              Assigned to:                    None => meanmicio              
>                  Release:                    None => 1.4.2                  
>     _______________________________________________________
> Follow-up Comment #1:
> Hi Chris
> Let me just copy / paste my comments on the mailing list and we'll take it
> from there :-)
> I think that this deserves a bit of explanation on my side. At any center, the
> patient will have two codes
> 1) SSN : Any state unique ID that identifies that patient (SSN is probably the
> most used, but any other stated issued ID will work)
> 2) Health Center Patient ID : Specific for each health center.
> The one that is "universal" for all the health centers would be SSN or
> equivalent. On the patient's clinical record, that is the number to export and
> to show. You can now retrieve a patient in the patient model from either the
> Patient ID or the SSN.
> So, on this topic... from the GNU Health point of view, the SSN is __very__
> important, and the Health Center patient ID is important to the center itself,
> but it has limited value outside the center.
> Now, different health centers and even different scenarios work differently.
> For instance :
> a) Some centers will fill in the patient general information at the front
> desk. This is :
> - SSN
> - Gender
> - Date of Birth
> - Marital Status
> - Insurance type
> - And at this point, the internal Patient ID is generated.
> b) Other centers and scenarios will ask limited (or even none) information
> before the health professional gets to see it
> - Public hospitals
> - Emergency departments
> - Small offices
> - Single practitioner
> Actually, the "b" scenario is the most common. In many cases, because there is
> no health informatics and everything is on paper. What you see in this cases
> is somebody at the front desk that writes down basic patient info and then
> send the patient to the doctor room, where she or he starts the interview from
> zero.
> So, in case "b", the health center patient ID and the SSN are generated /
> retrieved at the same time.
> So, when is the patient actually created ? Again 2 approaches show up :
> a) Administration department view : A person becomes a patient at the moment
> that she / he signs up for an appointment at that specific health center. We
> have to remember that the attribute of "person" exists at the party level, so,
> for example, all the family members or contacts of an specific patient can
> exist at GNU Health, but not necesarily are patients.
> b) Clinical approach: The patient is actually a patient after the first
> evaluation / encounter with a health professional (doctor, nurse... ). This
> is/was the GNU Health approach, but of course, can be modified.
> ...
> I think once we define the first part, implementing the access to the Patient
> ID will be OK.
> Best
> Luis
>     _______________________________________________________
> Reply to this item at:
>   <>
> _______________________________________________
>   Message sent via/by Savannah

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]