CCHIT - access restrictions per SOAP note

[Sebastian Hilbert]

requirement:

Enter some information to be identified as “confidential,” for example, that
the patient had once been a victim of domestic violence, into the chart and
designate as accessible only to Physician Users.

...

This is handled at database level already ,isn't it ?


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-11-07, at 10:04 AM, Sebastian Hilbert wrote:

> requirement:
>
> Enter some information to be identified as “confidential,” for  
> example, that
> the patient had once been a victim of domestic violence, into the  
> chart and
> designate as accessible only to Physician Users.
> ...
>
> This is handled at database level already ,isn't it ?

This exists in the table clin.health_issue as boolean field  
is_confidential

Karsten, if the affected row were to be refused access permissions to  
the class of user who is not doctor, how would this interest with the  
current GUI?

- would there be an error?
- would the query need modifying so that the WHERE would take into  
account the privileges and, for low-privilege users, exclude  
is_confidential from the listing?

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-11-07, at 10:59 AM, Jim Busser wrote:

> On 2009-11-07, at 10:04 AM, Sebastian Hilbert wrote:
>
>> requirement:
>>
>> Enter some information to be identified as “confidential,” for  
>> example, that
>> the patient had once been a victim of domestic violence, into the  
>> chart and
>> designate as accessible only to Physician Users.
>> ...
>>
>> This is handled at database level already ,isn't it ?
>
> This exists in the table clin.health_issue as boolean field  
> is_confidential
>
> Karsten, if the affected row were to be refused access permissions  
> to the class of user who is not doctor, how would this interest with  
> the current GUI?
>
> - would there be an error?
> - would the query need modifying so that the WHERE would take into  
> account the privileges and, for low-privilege users, exclude  
> is_confidential from the listing?

Related to the above was the August 2009 list thread archived here:

        http://lists.gnu.org/archive/html/gnumed-devel/2009-08/threads.html#00066

        (Managing users: restricting access within GNUmed)

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Nov 07, 2009 at 07:04:15PM +0100, Hilbert, Sebastian wrote:

> requirement:
>
> Enter some information to be identified as “confidential,” for example, that
> the patient had once been a victim of domestic violence, into the chart and
> designate as accessible only to Physician Users.
>
> This is handled at database level already ,isn't it ?

Not really. We encourage using cut-n-paste of GPG
encrypted text:

Doctor types "domestic violence victim, ..." into the soap
note. Doctor selects text. Doctor cuts text from soap note.
Doctor inserts text into GPG encryptor frontend and encrypts
it outputting ASCII armored data. Doctors cuts that from
encryptor. Doctors pastes ASCII armored text into soap note.

Reading this needs the reverse process.

This could use symmetric or asymmetric cryptography with
different degrees of confidentiality and different
protection properties:

using per-patient symmetric key:

        share key between patient and provider

using one symmetric key per provider for all patients:

        key only known to provider

encrypting with public key of patient:

        patient MUST consent to disclose content because
        only patient can unlock her private key

encrypting with public key of provider:

        only this provider can retrieve content because
        only provider can unlock his private key

The last two can usefully be combined.

One day we should support that from within GNUmed.

Signing of notes is actually quite similar: Just GPG-sign
the clear-text note (just like this e-mail is signed) and be
done with it.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Nov 07, 2009 at 10:59:45AM -0800, Jim Busser wrote:

> >requirement:
> >
> >Enter some information to be identified as “confidential,” for
> >example, that
> >the patient had once been a victim of domestic violence, into the
> >chart and
> >designate as accessible only to Physician Users.
> >...
> >
> >This is handled at database level already ,isn't it ?
>
> This exists in the table clin.health_issue as boolean field
> is_confidential
>
> Karsten, if the affected row were to be refused access permissions

This is not easily possible. PostgreSQL so far does not
natively support row level access permissions.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Sebastian Hilbert]

Am Samstag 07 November 2009 20:47:14 schrieb Karsten Hilbert:
> On Sat, Nov 07, 2009 at 07:04:15PM +0100, Hilbert, Sebastian wrote:
> > requirement:
> >
While that would work I am not sure that is what they had in mind. I guess
they accept it being clear text in the database and delegating the
confidentiality stuff to the application level.

I wonder if on the fly encryption is possible. Supposedly there is a pg_crypto
module. However, the data becomes inaccessible when the key / password changes
unless all data is reencrypted during a planned key / password change.

I guess they would accept using different sql queries / views for that. When
flagged _is_confidential the returned value would be 'confidential'
On selecting 'show confidential record' one would be asked for the password
again which would trigger the other view or sql query.

Still not encrypted but I doubt the other vendors do it any different.
Eventually we should surpass the requirements :-)

Sebastian


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Sebastian Hilbert]

Am Samstag 07 November 2009 20:58:49 schrieb Karsten Hilbert:

> On Sat, Nov 07, 2009 at 10:59:45AM -0800, Jim Busser wrote:
> > >requirement:
> > >
> > >Enter some information to be identified as “confidential,” for
> > >example, that
> > >the patient had once been a victim of domestic violence, into the
> > >chart and
> > >designate as accessible only to Physician Users.
> > >...
> > >
> > >This is handled at database level already ,isn't it ?
> >
> > This exists in the table clin.health_issue as boolean field
> > is_confidential
> >
> > Karsten, if the affected row were to be refused access permissions
>
> This is not easily possible. PostgreSQL so far does not
> natively support row level access permissions.
>
> Karsten
>

All I could find is that
http://bytes.com/topic/postgresql/answers/422181-row-level-security-possible


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Nov 07, 2009 at 09:33:22PM +0100, Hilbert, Sebastian wrote:

> > > Karsten, if the affected row were to be refused access permissions
> >
> > This is not easily possible. PostgreSQL so far does not
> > natively support row level access permissions.
> >
> All I could find is that
> http://bytes.com/topic/postgresql/answers/422181-row-level-security-possible

Again, natively it doesn't support it. PG only recently (8.4
I think) gained *column* level permissions.

There is a system called "Veil" which puts a layer of views
on top of the normal views / tables in which the WHERE
clause validates against permissions set in other tables.
This is quite effective and is my preferred solution when we
attempt to implement this fully.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Sat, Nov 07, 2009 at 09:28:46PM +0100, Hilbert, Sebastian wrote:

... GPG encryption of SOAP content ...

> While that would work I am not sure that is what they had in mind. I guess
> they accept it being clear text in the database and delegating the
> confidentiality stuff to the application level.

Tell you what - I don't care what they have in mind :-))  
What I do care about is whether the feature makes any real
sense or not. If so we'll think of a way to implement it
reasonable and not just as a certification fake.

However, if Verbus and his Band Of Brothers implement a
"sufficient quick fix" into their version of GNUmed and then
acquire certification for that -- no problem.

> I wonder if on the fly encryption is possible.

It is but we don't want that. It is too slow as well.
Imagine a free-text search across the medical record ;-)

> Supposedly there is a pg_crypto module.

Yep, and it's great.

> However, the data becomes inaccessible when the key / password changes
> unless all data is reencrypted during a planned key / password change.

Another reason not to want that.

What IS desirable is encryption *below* PostgreSQL at the
disk level, however. For that, dedicated encryption hardware
can be used if speed is an issue.

> I guess they would accept using different sql queries / views for that. When
> flagged _is_confidential the returned value would be 'confidential'
> On selecting 'show confidential record' one would be asked for the password
> again which would trigger the other view or sql query.

Yep, that could work.

> Still not encrypted but I doubt the other vendors do it any different.

You could well be correct there !


> Eventually we should surpass the requirements :-)

We will. In fact, implementing the approach I outlined isn't
at all technically challenging. It's just a matter of time
and priority.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-11-07, at 11:58 AM, Karsten Hilbert wrote:

> This is not easily possible. PostgreSQL so far does not
> natively support row level access permissions.

Could it manageably be achieved indirectly via Postgres' views in  
which views could include or exclude rows having a specified value?

If yes, then we could have

- nonclinical views that all (including staff) could access
- clinical views (routine) WHERE clin.health_issue.is_confidential IS  
FALSE
- clinical views (unrestricted)


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Wed, Nov 11, 2009 at 12:06:37AM -0800, Jim Busser wrote:

> Subject: Re: [Gnumed-devel] CCHIT - access restrictions per SOAP note
> X-Mailer: Apple Mail (2.1076)
>
> On 2009-11-07, at 11:58 AM, Karsten Hilbert wrote:
>
> >This is not easily possible. PostgreSQL so far does not
> >natively support row level access permissions.
>
> Could it manageably be achieved indirectly via Postgres' views in
> which views could include or exclude rows having a specified value?
>
> If yes, then we could have
>
> - nonclinical views that all (including staff) could access
> - clinical views (routine) WHERE clin.health_issue.is_confidential
> IS FALSE
> - clinical views (unrestricted)

Wouldn't *all* clinical information be confidential from
non-clinical users regardless of their is_confidential
health issue status ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Jim Busser]

On 2009-11-11, at 4:19 AM, Karsten Hilbert wrote:

> Wouldn't *all* clinical information be confidential from
> non-clinical users regardless of their is_confidential
> health issue status ?

Yes, but it appeared in CCHIT that they wanted nurse clinicians to be  
able to access the clinical record without accessing items marked  
is_confidential.

Therefore the question about views remains relevant?


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Verbus Counts]

All,

I think views is the way to go here.

Verbus

On Wed, Nov 11, 2009 at 8:45 AM, Jim Busser <jbusser@...> wrote:

On 2009-11-11, at 4:19 AM, Karsten Hilbert wrote:

Wouldn't *all* clinical information be confidential from
non-clinical users regardless of their is_confidential
health issue status ?

Yes, but it appeared in CCHIT that they wanted nurse clinicians to be able to access the clinical record without accessing items marked is_confidential.

Therefore the question about views remains relevant?

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

--
Regards,
Verbus M. Counts
803-727-8576          http://palmedtech.com/problems

_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel

[Karsten Hilbert]

On Wed, Nov 11, 2009 at 05:45:48AM -0800, Jim Busser wrote:

> >Wouldn't *all* clinical information be confidential from
> >non-clinical users regardless of their is_confidential
> >health issue status ?
>
> Yes, but it appeared in CCHIT that they wanted nurse clinicians to
> be able to access the clinical record without accessing items marked
> is_confidential.

"Items" then means "certain SOAP notes" ?

> Therefore the question about views remains relevant?

That would work, yes.

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346


_______________________________________________
Gnumed-devel mailing list
Gnumed-devel@...
http://lists.gnu.org/mailman/listinfo/gnumed-devel