health
[Top][All Lists]
Advanced

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

Re: [Health] Patient Registration Scenario - new version GNU Health 1.3.


From: Luis Falcon
Subject: Re: [Health] Patient Registration Scenario - new version GNU Health 1.3.4
Date: Mon, 6 Feb 2012 21:59:33 -0300

Dear Chris

On Mon, Feb 6, 2012 at 8:04 AM, Christoph H. Larsen <address@hidden> wrote:
Dear Luis,

Thanks, as always for your reply! I did think of the SSN field, but,
alas, this won't float either, as a national ID will be required for
quite a few clinical settings. Hence, it would be very counterproductive
to block this field and function.
The strategy of entering patient core data via the "Party" facility has
another disadvantage: It is not fail-safe: Patient registration staff
might well forget to activate the "is_patient" field, and thus lock
themselves out, depending on access rights to that record.
Privilege separation will be required within the "Party" facility, as
there will be other people/groups adding data, like human resources,
accounting, procurement, etc.
 
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.

So, there is nothing all too wrong with entering patients from within
the "Health / Patients / Patients" facility, we just need some model
that separates the patient core data from their clinical details. After
messing around a lot with both approaches, I agree with Cédric before
that going through the "Patients" channel is the best approach...
  
Thoughts anyone?

This won't be hard. We can have different approaches, from the access level at model and field levels, or even at view level, by hiding the clinical information group fields depending on the person who is actually logged in.

I think once we define the first part, implementing the access to the Patient ID will be OK.
 
Cheers (oops, not allowed!) from Kabul!

Best ! :-)
 
Chris


On 06/02/12 14:39, Luis Falcon wrote:
> Hi Chris
>
> On Mon, Feb 6, 2012 at 12:48 AM, Christoph H. Larsen
> <address@hidden <mailto:address@hidden>>
> wrote:
>
>     Dear Luis,
>
>     On 06/02/12 03:25, Luis Falcon wrote:
>     > Hi Chris !
>     >
>     >
>     > On Sun, Feb 5, 2012 at 4:09 PM, Christoph H. Larsen
>     > <address@hidden
>     <mailto:address@hidden>
>     <mailto:address@hidden
>     <mailto:address@hidden>>>
>     > wrote:
>     >
>     >     Dear Crowd,
>     >
>     >     I am sitting in a scenario, where patient registration is done by
>     >     non-clinical staff that should not have any access to medical
>     >     information.
>     >     I am using the Health / Patients/ Patients facility to
>     register new
>     >     patients, and to retrieve old once, and in order to hide any
>     clinical
>     >     date, there are currently two ways to do so.
>     >
>     >
>     > The best way to register patients should be from the Party model
>     (Party
>     > -> Parties ). The idea is that the admin stuff can have access to all
>     > the administrative information, without getting in the Medical part.
>     >
>     > There you have all the information (name, contacts, Social Security
>     > Number, Insurances... ). Look at the Party "Health" tab for more info.
>     > When the person is actually set up as a patient, just click on
>     > "Patient". Then the health professional will find all the patients
>     > enabled from the administrative stuff.
>     >
>     > Same applies for retrieving them.
>     This was indeed my frst approach, but then I found that there is one
>     single, but overpowering reason, why I cannot do this:
>     Enter patient core data at the "Party" ponit of entry does not produce
>     patient IDs. And the very same are needed throughout the system, from
>     patient reception to, well, the patient's demise.
>
>
> Good point. We can use SSN (a party field) to look for it. Today the
> patient looks for it. I can make a function to retrieve the patient ID
> when entering the SSN, and show it in the health section on the party.
> This would be the best approach.
>
> Can you do me a favor and create a bug for this as a wishlist or
> functionality ?
>
> Thanks a lot
> Luis
>
>
>
>     Hence my rather convoluted different approach!
>     Thanks!
>     Chris
>     >
>     > Hope this helps !
>     >
>     >     First, the easy way: I can define zero rights to the "Surgical
>     >     Functionality" model by adding it to the "Access Model" list, with
>     >     rights ----. In this case, the patient registration staff can
>     only see
>     >     the tab "Surgeries", but when they click on it, it is empty.
>     Not very
>     >     cute (ideally, the "Surgery" tab should disappear!), but easy.
>     >     Unfortunately, this does not work with those tabs that have
>     sub-tabs,
>     >     namely "Gyneco/Obs", "Lifestyle", "Genetics" and "Socioeconomics".
>     >     Here, I have to do it the hard way, by adding all fields of
>     the foresaid
>     >     tabs into the "Access Field" list, with zero access rights.
>     This is not
>     >     only cumbersome, but also leaves the sub-tabs visible.
>     >     It would be terrific, if "Geneco/Obs", "Lifestyle", "Genetics" and
>     >     "Socioeconomics" could be be translated into respective
>     models, which
>     >     can be called for, with zero access rights.
>     >     Also, is there an easy way to make those empty remaining tabs and
>     >     sub-tabs invisible?
>     >
>     >     Thanks a lot for any ideas!
>     >
>     >     Bests from Afghanistan -
>     >
>     >     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
>     <mailto:address@hidden>
>     >     <mailto:address@hidden
>     <mailto:address@hidden>>
>     >
>     >
>     >
>     >
>     > --
>     > Luis Falcon
>     > GNU Health
>     > http://health.gnu.org
>
>     --
>     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
>     <mailto:address@hidden>
>
>
>
>
> --
> Luis Falcon
> GNU Health
> http://health.gnu.org

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




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

reply via email to

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