[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Health] Patient Registration Scenario - new version GNU Health 1.3.
From: |
Christoph H. Larsen |
Subject: |
Re: [Health] Patient Registration Scenario - new version GNU Health 1.3.4 |
Date: |
Mon, 06 Feb 2012 15:34:20 +0430 |
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,
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.
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?
Cheers (oops, not allowed!) from Kabul!
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