[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] The future of patient care computing?
From: |
Sebastian Hilbert |
Subject: |
Re: [Gnumed-devel] The future of patient care computing? |
Date: |
Mon, 09 Jul 2012 19:29:01 +0200 |
User-agent: |
KMail/4.9 beta1 (Linux/3.2.0-26-generic-pae; KDE/4.8.80; i686; ; ) |
On Monday, July 09, 2012 05:10:37 PM Busser, Jim wrote:
> http://www.cmaj.ca/content/184/10/E527.full?etoc
>
> This really does raise the question of, eventually,
>
> 1) how a patient's record (as contained in GNUmed) can be made more
> accessible to them and
>
Technically this isn't hard. Making it safe is another thing. There is some
ideas but not neccesarly code to be gotten from
http://www.open-emr.org/wiki/index.php/Patient_Portal
In the end it boils down to writing another client (e.g. webbased) and making
sure that a given login is associated with a subset (e.g. just one)
> 2) how a doctor using GNUmed may wish GNUmed to interact with an external
> system in which the patient may be managing their own health information.
>
A readily available choice would be IndivoX
http://indivohealth.org/
This is one-way however. No information to be pulled from a PHR.
> If GNUmed were deployed under a master-slave configuration, could one of the
> slaves be made available read-only?
>
Sure. Or the code could set up a read-only connection.
> Would it be reasonable to allow a patient to view (read-only) the
> information using a defined subset of plugins, in a way that
>
That is up to you to determine. Largely depends on your patients.
> - required them to provide sufficient identifiers (for example, a date of
> birth together with a health number) to uniquely match themselves and - to
> access an instance of GNUmed which is 'locked" to that record
>
This is one way but there are numerous. While I have thought about this for a
long time I have yet to understand the benefit of it.
Technically this can all be done.
Sebastian