openEHR security; Directed to Thomas Beale

[Thomas Beale]

another "old" post that deserves a reply...

Tim Churches wrote:

>
>Maybe I've missed something much earlier on this thread, but don't you need a 
>target security policy and associated threat model before you start designing 
>ways to implement it?
>
some work has been done on this, and I would expect that in openEHR we 
will be able to post some kind of analysis in the coming months.

> The problem, of course, is that there is no single agreed 
>policy, even in broad terms. But to me, the best starting point is still Ross 
>Anderson's exposition of the policy he developed for the British Medical 
>Association - for the CiteSeer reference see 
>http://citeseer.nj.nec.com/anderson96security.html
>
>There are still major technical challenges in addressing that policy, 8 or 9 
>years 
>after it was first published, particularly with respect to trusted computing 
>bases ( 
>the NSA version of Linux with mandatory access control offers promise there) 
>and statistical disclosure control (where theory still lags behind ad hoc 
>practice 
>rather badly). But the rest can probably be implemented using role-based 
>security concepts - the level of granularity of roles required by the Anderson 
>policy is still orders of magnitude finer than anything which has been fielded 
>to 
>date, I think.
>
agree. One big issue is for everyone to start agreeing on where 
"consolidated" EHRs really live, and the role of more global ad hoc 
messaging for unexpected care info requests. THere are some animated 
slides on this at 
http://www.oceaninformatics.biz/publications/EHR_vision.zip on the issue.

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security)

[Thomas Beale]

Bill,

there are two kinds of audit trails in openEHR - the audit trail of a 
change to a transaction or other artifact (eg. access control group) - 
see the COmmon RM for the semantics; and audit trails of access. openEHR 
has not yet defined these, and I don't know if it should - I suspect 
they will differ everywhere. I expect that it has to be defined by an 
archetyped structure, so that basic semantics can be stated, and the 
normal archetype mechanism used as for everything else.

I cannot comment on HIPAA compliance at this stage - not enough time to 
study it in detail.

- thomas


Bill Walton wrote:

>Hi Thomas,
>
>Thomas Beale wrote:
>  
>
>>Bill Walton wrote:
>>
>>
>BW:  Further, it looks like the EHR access history should include
>  
>
>>>reads as well as writes.  That way, the trail would lead to the
>>>providers that have, with permission, made copies of the EHR within
>>>their own systems.
>>>
>>>  
>>>
SH: True - it will only be able to be stored as an HTML rendition


>>>unless there is an extract in openEHR - but you are right - this could
>>>be saved - this is difficult to police.
>>>
>>>Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
>>>specifies, under the Transaction Rules that go into effect in October
>>>of this year, a number of EDI transactions between systems that would
>>>require this.  HTML will not be sufficient.
>>>  
>>>
>>Can anyone clarify this bit of the debate - I have lost track of what is
>>being said here!
>>
>>
>
>I was inquiring about the audit trail capabilities intended to be
>incorporated in v1.0 of openEHR and Sam was very graciously trying to
>enlighten me.  His commment re: HTML made me expand the question to
>extracts.  I'm not sure I was sufficiently clear about my line of
>questioning, and comments by others make me wonder whether or not I should
>take this off-line.  I am specifically trying to ascertain the applicability
>of openEHR to the emerging requirements here in the U.S. and do not wish to
>infringe on the group's bandwidth if there is a less intrusive way to handle
>my questions.  Please let me know how you'd like me to proceed.  And thank
>you all for your patience to date.
>
>Best regards,
>Bill
>
>
>
>  
>

-- 
..
Deep Thought Informatics Pty Ltd  
mailto:thomasXXX at YYYdeepthoughtZZZ.WWWcom.AAAau (remove all caps)

openEHR - http://www.openEHR.org
Archetypes - http://www.deepthought.com.au/it/archetypes.html   
Community Informatics - http://www.deepthought.com.au/ci/rii/Output/mainTOC.html
..



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

OODBMS, lost events; was: openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas,

>> What do you do when your object-oriented application falls
>> over ? Here, an open source application/database is even more
>> important than in plain relational DBs.
> There should be sufficient redundancy in the application to enable a
> recovery.
No, I mean when your application is dead, your vendor's dead
and you don't have the source. Isn't it much easier to extract
the data from a RDBMS or do I just not know enough about how
objects are stored in OODBMS' ?

IOW: Is there something like the PostgreSQL shell "psql" that
lets me easily browse my data in an OODBMS no matter what
application/programming language put it there ?

> Interesting example from the legal world:
> 1)Patient has never had a broken right arm
> 2)Patient enters a nursing room
> 3)Patient remains for six months
> 4)Upon discharge Patient has experienced a broken right arm
> 5)No entry in the record regarding the event and perhaps subsequent
> treatment
> 
> Hence, regardless of the competence of the record-based system there will
> be situations where some things will remain the same.
Hm, I understand the content of this paragraph. I am not sure,
however, what you wanted to say with it. Did you want to say
that it can happen that events do not get recorded ? Well,
that's sure true but what wisdom does knowing that buy us ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

OODBMS, lost events; was: openEHR security; Directed to Thomas Beale

[lakew...@copper.net]

Hi Karsten,

Comments in text.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Friday, May 09, 2003 3:27 AM
Subject: OODBMS, lost events; was: openEHR security; Directed to Thomas
Beale


> Thomas,
>
> >> What do you do when your object-oriented application falls
> >> over ? Here, an open source application/database is even more
> >> important than in plain relational DBs.
> > There should be sufficient redundancy in the application to enable a
> > recovery.
> No, I mean when your application is dead, your vendor's dead
> and you don't have the source. Isn't it much easier to extract
> the data from a RDBMS or do I just not know enough about how
> objects are stored in OODBMS' ?
>
> IOW: Is there something like the PostgreSQL shell "psql" that
> lets me easily browse my data in an OODBMS no matter what
> application/programming language put it there ?
>

Sorry. This was all too familiar a problem. Fault tolerant systems in the
background causes specific responses.

PostgreSql was one of the DBs I was thinking about. Regardless, the
SQA background covers events that could result in the application
going dead leaving one with a very short message indicating that the
application is dead.

Even RDBs fail, although many have had sufficient time-in-operation to
have encountered the most common errors and failures.

Redundancy in DB operations provides the additional resources
required to recover from a significant portion of the errors and failures.
Cost more though! But open-source should permit one to modify this.

On a nice clear day with no problems you shouldn't have to worry about
this because the SQA should have covered these issues. Should have!

Database clusters (http://citeseer.nj.nec.com/504360.html), certainly not
for a workstation or deskside server, but possibly for a facility or remote
service.
Example commercial database servers:
http://www.usgenesis.com/npdbservers.html
http://www.polyhedra.com/customer/Default.asp
http://www.ose.com/news/pressreleases/2002/02-04-28.asp
http://www.nacio.net/storage/NACIOProductBrief-DedicatedStorageArray.pdf
Example medical application:
http://home.mcis.washington.edu/amcis/amcissc/amcissc_11802.html
http://www.biostat.wisc.edu/generaladmin/resource.html

After all this the application can still die, possibly suddenly with
critical impacts,
which could include data loss and/or corruption. No guarentees.

This is an indirect plug for external, secure Data Store Facilities which
can be
used to store intermediate data as well as permanent.

> > Interesting example from the legal world:
> > 1)Patient has never had a broken right arm
> > 2)Patient enters a nursing room
> > 3)Patient remains for six months
> > 4)Upon discharge Patient has experienced a broken right arm
> > 5)No entry in the record regarding the event and perhaps subsequent
> > treatment
> >
> > Hence, regardless of the competence of the record-based system there
will
> > be situations where some things will remain the same.
> Hm, I understand the content of this paragraph. I am not sure,
> however, what you wanted to say with it. Did you want to say
> that it can happen that events do not get recorded ? Well,
> that's sure true but what wisdom does knowing that buy us ?
>
> Karsten

Proper tracking permits the construction of a chain of events that
identifies and
possibly explains major events, e.g., 'broken right arm'. In the example
there
are several possible 'gaps' in the record. In this example everyone involved
will
get the opportunity to provide information outside the record.

The underlying duty to update the record falls upon those with custody
and/or
control over the record. This is true for countless other business entities,
e.g.,
your bank. One has the duty to properly update the record with appropriate,
correct information. The information contained in the record is for the use
of
others beside Practitioners.

> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

> Tracking is super-important. Include the image.
Of course one does. If you have the image you store it.

> My preference is for an object-oriented database since I might want to
> retrieve all ER-related information quickly (includes narratives and images).
What do you do when your object-oriented application falls
over ? Here, an open source application/database is even more
important than in plain relational DBs.

> If content is there upon
> retrieval it likely was not there upon creation.
I am completely puzzled by this assertion. Please explain.

Thanks,
Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[lakew...@copper.net]

Hi Karsten,

Comments in text.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Thursday, May 08, 2003 2:04 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> > Tracking is super-important. Include the image.
> Of course one does. If you have the image you store it.
>
> > My preference is for an object-oriented database since I might want to
> > retrieve all ER-related information quickly (includes narratives and
images).
> What do you do when your object-oriented application falls
> over ? Here, an open source application/database is even more
> important than in plain relational DBs.
>

There should be sufficient redundancy in the application to enable a
recovery.
Granted there are a lot of them that do not support this in an acceptable
manner, some not at all.

Highly available systems and networks go part of the distance; redundancy
in applications and storage another bit; redundancy in archiving and
retrieving
another bit; redundancy in updating. No guarentees however, e.g., the
network
inject nasty problems.

Tough question; answers can range from hardware-OS-local/distributed
applications to hardware failures and software errors. Checkpoint and
backup.

> > If content is there upon
> > retrieval it likely was not there upon creation.
> I am completely puzzled by this assertion. Please explain.
>
> Thanks,
> Karsten

Recognize the thought but the above  looks ill-formed.

Refers to:
1)Information not present in prior history
2)Initial contact does not contain a reference
3)No input during treatment, etc
4)Information present upon discharge.

Gap in the 'chain-of-events'. I could also have been ready to call it a
day. The above, however, is a major problem that may or may not
be related to the update of the records, e.g., generated a paper record
whose content was never entered into the record.

Suppose you look at a record one month later where this occurred
at another facility. What would you conclude?

Interesting example from the legal world:
1)Patient has never had a broken right arm
2)Patient enters a nursing room
3)Patient remains for six months
4)Upon discharge Patient has experienced a broken right arm
5)No entry in the record regarding the event and perhaps subsequent
treatment

Hence, regardless of the competence of the record-based system there will
be situations where some things will remain the same.

> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Tim Churches]

An embedded and charset-unspecified text was scrubbed...
Name: not available
URL: 

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas,

>> To me this is simply:

> Patient prior history missing.
Sure but that was just an example to illustrate that a text
field can easily provide storage for reassessing narrative.

> Relying 100% on visual inspections and observations may not cut it,
Of course not. But even in the imaging-crazed US American
Healthcare industry www.trauma.org teaches one to dismiss a
potential neck injury patient if there's no clinical evidence
whatsoever for such injury (clinical being hand/eyes/mind
here).

> An append-only text field might be great for a User Interface supporting
> text input but handling this over a course of treatment by multiple
> Practitioners gets a little tough. Suppose four Practitioners decide to
> update their narrative simultaneously and they all 'finish' simultaneously.
> What happens to the record?
Uhm, you end up with as many additions to the record as there
are updating doctors ? (This is the multiple-update problem
well known in CS). So, what's the big issue here ? I mean,
what they all type is not going to be funny essays about their
recent holidays but information relevant to the current
encounter with that patient.

> Single-user, semaphore-based UI applications are just not good enough. If
> someone forgets to unlock the record and leave for the evening I hope you
> have their cell number.
Why would the application have to lock the entire record ? Why
would there not be a timeout for that lock, perhaps based on
presence-detection (timeout) + timebased login restrictions
for the account that forgot to "unlock" ? Why is the
front-door swipecard system not sending a signal to the EMR:
"X is leaving" ? (This, again, does not apply todoay to
"remote areas of Y".)

> Narrative in their 'final' form are of interest to the record designer and
> they will likely not look like anything you though you entered, e.g., 
> encrypted,
> compressed, pdf file that becomes a history file (unchangeable).
But it better make damn sure it *contains* everything I typed
in the way I wanted to represent it with the given input
means (eg. hand formatted into columns or such).

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Bill Walton]

Tim Churches wrote:
/snip/

> Maybe I've missed something much earlier on this thread, but don't you
need a
> target security policy and associated threat model before you start
designing
> ways to implement it? The problem, of course, is that there is no single
agreed
> policy, even in broad terms. But to me, the best starting point is still
Ross
> Anderson's exposition of the policy he developed for the British Medical
> Association - for the CiteSeer reference see
> http://citeseer.nj.nec.com/anderson96security.html

/snip/

> Anyway, the Anderson paper is worth a read, or a re-read.

Thanks for the link.  I definitely found it worthwhile.  Anderson has a page
at Cambridge that's got a lot of good stuff worth spending some time on.
His work on Medical Records (and other stuff too) is at
http://www.cl.cam.ac.uk/~rja14/#Med

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Sam Heard]

Dear All

I would like to raise the issue that there are structural models required to
deal with security - what structural components are you going to have access
to or not - containers if you will. And then there is content - though only
when organised appropriately - so that information in an 'organisational'
category can be made private.

THe later is much more problematic and I do not think can operate outside of
any specific jurisdiction safely - the former is safer. As openEHR shares
transactions as the lowest level of transfer, I would propose that our
initial work is based on this level. The fact that you can see a problem
list - but it only contains some elements - is of concern to me. I would
rather not have access to the problem list and operate on that basis.

What do others think?

Sam

> This is important since 'linked' messages, e.g., XML database, can be used
> to
> handle both status messages from a single Practitioner and multiple
> Practitioners. The real problem is to decide/filter what gets in the
> permanent record.

> This can have legal impacts in the local jurisdiction. For
> example, charting
> is
> performed but most cases at some later time (an issue since memory
> recall is suspect) and is typically a paper record Some facilities are
> attempting to automate this as well as other practices. What to
> do with this
> information for many remains an unsolved puzzle.
>
> Narratives can be hard to handle in record-based systems as can scannable
> entries, e.g., charts and images.
>
> What you do is important and should/must be saved. A possible approach is
> a collection of databases handling specific information with posting in a
> EHR/EPR/EMR, both surviving as permanent data.
>
> This puts a focus on record format/structure, i.e., there are limitations
> imposed by implementation, jurisdiction, users, performance, networking,
> etc. Small block sizes is desirable; records can be composed of multiple
> blocks; narratives from multiple Practitioners might be hard to handle.
>
> Interesting problem!
>
> -Thomas Clark
>
> ----- Original Message -
> From: "Karsten Hilbert" 
> To: 
> Sent: Tuesday, May 06, 2003 2:06 PM
> Subject: Re: openEHR security; Directed to Thomas Beale
>
>
> > Hi Thomas,
> >
> > > Constructive! Do you anticipate entering this type status information
> > > into an OpenEHR record?
> > Absolutely ! I do record such information even today.
> >
> > > If so, what record?
> > I do so now in the narrative part of the record, at times
> > linked to previous data by plain and simple layout of data
> > items.
> >
> > Karsten
> > --
> > GPG key ID E4071346 @ wwwkeys.pgp.net
> > E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi karsten,

Comments in text.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Wednesday, May 07, 2003 4:14 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> Thomas,
>
> >> To me this is simply:
>
> > Patient prior history missing.
> Sure but that was just an example to illustrate that a text
> field can easily provide storage for reassessing narrative.
>

OK

> > Relying 100% on visual inspections and observations may not cut it,
> Of course not. But even in the imaging-crazed US American
> Healthcare industry www.trauma.org teaches one to dismiss a
> potential neck injury patient if there's no clinical evidence
> whatsoever for such injury (clinical being hand/eyes/mind
> here).
>

I admit, then, to be image-crazed. If you properly order an X-Ray in the
ER because you suspect visual indications are insufficient, then the
image should be in the record. If the Patient is treated for an injury that
is not
obvious upon admitting and/or leaves the facility with identifiable injuries
that were not present previously the tail gets pinned on the facility.

Tracking is super-important. Include the image.

As for clinical evidence, many Patients have records in multiple facilities,
insurance companies and individual practitioners files. They are neither
available nor in a form that would require a modicum of effort to interpret
(obviously suggesting that prior diagnosis/review of a Patient's records
is a good idea; a priori data mining performed by software applications).

Sufficient/insufficient clinical evidence at any point is an issue. One
benefit of
EHR/EPR/EMR systems is that this issue becomes substantially muted.

> > An append-only text field might be great for a User Interface supporting
> > text input but handling this over a course of treatment by multiple
> > Practitioners gets a little tough. Suppose four Practitioners decide to
> > update their narrative simultaneously and they all 'finish'
simultaneously.
> > What happens to the record?
> Uhm, you end up with as many additions to the record as there
> are updating doctors ? (This is the multiple-update problem
> well known in CS). So, what's the big issue here ? I mean,
> what they all type is not going to be funny essays about their
> recent holidays but information relevant to the current
> encounter with that patient.
>

The 'multiple-update' problem can be solved mechanistically. Consider a
Healthcare where entries can be associated with the Patient, facility,
Practitioners (including Nursing Staff), support functions, medical devices,
administration, billing and groups/sub-groups of the above.

A lot gets dumped into the record. There needs to be structure! There are
others that have to access and interpret all that stuff. You can turn it
into
a format similar to an analog tape, or microfiche, and spend
time/bandwidth/etc
accessing it. Could turn it into a structure format so that the contents can
be
quickly loaded into a database and accessed therefrom.

My preference is for an object-oriented database since I might want to
retrieve
all ER-related information quickly (includes narratives and images).

> > Single-user, semaphore-based UI applications are just not good enough.
If
> > someone forgets to unlock the record and leave for the evening I hope
you
> > have their cell number.
> Why would the application have to lock the entire record ? Why
> would there not be a timeout for that lock, perhaps based on
> presence-detection (timeout) + timebased login restrictions
> for the account that forgot to "unlock" ? Why is the
> front-door swipecard system not sending a signal to the EMR:
> "X is leaving" ? (This, again, does not apply todoay to
> "remote areas of Y".)
>

Used 'Single-user, semaphore-based UI applications' as an example since
some deployed software relies on this approach.

"lock/unlock" approaches are sometimes used in secure OS/applications
because of a 'security hierarchy'.  Used as an example; not recommended.

> > Narrative in their 'final' form are of interest to the record designer
and
> > they will likely not look like anything you though you entered, e.g.,
encrypted,
> > compressed, pdf file that becomes a history file (unchangeable).
> But it better make damn sure it *contains* everything I typed
> in the way I wanted to represent it with the given input
> means (eg. hand formatted into columns or such).
>
> Karsten

Everything contained in the 'final' form will be retrieved. The
'encrypted, compressed, pdf file' becomes an object managed by the
record system. An issue is the encryption and who holds the keys.

This has to be a secure, permanent object. If co

openEHR security

[David W. Forslund]

I'm not sure which part this refers to.  For example, theRAD is a standard 
specification that
can be implemented in multiple technologies.

Thanks,

Dave
Thomas Clark writes:
 > Hi David,
 > 
 > Definitely a component to be included in the:
 > facility-facility-DataStore-Management
 > network. There are other candidates, i.e., want to avoid focusing on a
 > single technology.
 > 
 > -Thomas Clark
 > 
 > - Original Message -
 > From: "David Forslund" 
 > To: "Patrick Lefebvre" ;
 > ; "Thomas Beale"  deepthought.com.au>
 > Sent: Tuesday, May 06, 2003 11:29 PM
 > Subject: Re: openEHR security
 > 
 > 
 > > At 03:18 PM 5/6/2003 +0200, Patrick Lefebvre wrote:
 > > >Hi everyone,
 > > >
 > > >As Thomas & al. pointed, security addresses "a number of aspects",
 > > >including security policy (defining who does what), data safety, and how
 > > >security is ensured: so, including safety of the network, the application
 > > >architecture -including management of messages: asynchronous/EHRcom/XML,
 > > >or synchronous/CorbaMed/IDL-, the programs, and the platform.
 > >
 > > Just a minor comment here.  "CORBAmed" and thus CORBA deals with both
 > > asynchronous and synchronous "messaging".
 > > I would also second the comment by Tom Culpepper about a service which
 > goes
 > > a long way to mediate the security requirements in healthcare.
 > >
 > > Dave
 > >
 > > >Great.
 > > >
 > > >I agree with Gerard Freriks's considerations (legal, social control and
 > > >organisational aspects) but for now I only focus on the technical
 > > >specification.
 > > >
 > > >For now, I will focus on far restricted objectives.
 > > >One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure
 > > >ascending compatibility.
 > > >ENV13606 messages (part  3 : "distribution rules") describe access policy
 > > >in terms of objects ("Who", "When", "Where",etc.) whose instanciations
 > > >define the allowed access context to message objects.
 > > >
 > > >So, in the viewpoint of EHRcom release 1 in 2004,
 > > >* Will this (or such an) architecture be reused in EHRcom ?
 > > >* If no, will we have a tool to convert distribution rules into
 > > >corresponding archetypes ?
 > > >* If no, how is it planned to ensure ascending compatibility ?
 > > >
 > > >Another basic, technical, concrete security point is: ensuring data
 > > >(transmission + authoring) integrity in the message.
 > > >One solution proposed by ENV13606 was: systematic digital signature of
 > > >each transaction.
 > > >Will EHRcom reuse this mechanism ?
 > > >
 > > >One last point is: our deadline for a (definitive ? initial ?)
 > specification.
 > > >In EHRcom specs, what can we define for now as a stable 2004 milestone ?
 > > >
 > > >Maybe my questions are FAQs.
 > > >Thank you for your kind replies.
 > > >
 > > >-- Patrick Lefebvre
 > > >
 > > >-
 > > >If you have any questions about using this list,
 > > >please send a message to d.lloyd at openehr.org
 > >
 > > -
 > > If you have any questions about using this list,
 > > please send a message to d.lloyd at openehr.org
 > 
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas,

maybe I'm too dense but I cannot appreciate the complexity of
the issue as you hash it out.

To me this is simply:

3.5.2003 10:35 am first seen patient
 medium pain frontal skull after contusion in traffic accident
5 mins ago, no neurological abnormalities right now, GCS 15

3.5.2003 10:45 check up
 pain on pressure to 2nd cervical vertebra, dizziness,
 nausea, claims fuzzy vision, left pupil dilated responding to
 light slower than right, now severe pain frontal/retroorbital/
 right temporal region. GCS 12.

Clearly, there's some new and some updated information in this
narrative. This is the point where I immediately ship the
patient to the next CT/MRI scanning facility with on-duty
neuro/neuro-surgery.

All this requires is an append-only text field. Of course, it
can be handled much more fanciful inside the EMR, trying to
link items, graphing trends on scales, etc. etc. The basics,
however, can be handled by free text fields. And even they do
not just emulate the paper based record but offer one clear
advantage: they are readable by me even if someone else wrote
down the first assessment.

> Narratives can be hard to handle in record-based systems as can scannable
> entries, e.g., charts and images.
But they are absolutely necessary.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[David Forslund]

At 03:18 PM 5/6/2003 +0200, Patrick Lefebvre wrote:
>Hi everyone,
>
>As Thomas & al. pointed, security addresses "a number of aspects", 
>including security policy (defining who does what), data safety, and how 
>security is ensured: so, including safety of the network, the application 
>architecture -including management of messages: asynchronous/EHRcom/XML, 
>or synchronous/CorbaMed/IDL-, the programs, and the platform.

Just a minor comment here.  "CORBAmed" and thus CORBA deals with both 
asynchronous and synchronous "messaging".
I would also second the comment by Tom Culpepper about a service which goes 
a long way to mediate the security requirements in healthcare.

Dave

>Great.
>
>I agree with Gerard Freriks's considerations (legal, social control and 
>organisational aspects) but for now I only focus on the technical 
>specification.
>
>For now, I will focus on far restricted objectives.
>One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure 
>ascending compatibility.
>ENV13606 messages (part  3 : "distribution rules") describe access policy 
>in terms of objects ("Who", "When", "Where",etc.) whose instanciations 
>define the allowed access context to message objects.
>
>So, in the viewpoint of EHRcom release 1 in 2004,
>* Will this (or such an) architecture be reused in EHRcom ?
>* If no, will we have a tool to convert distribution rules into 
>corresponding archetypes ?
>* If no, how is it planned to ensure ascending compatibility ?
>
>Another basic, technical, concrete security point is: ensuring data 
>(transmission + authoring) integrity in the message.
>One solution proposed by ENV13606 was: systematic digital signature of 
>each transaction.
>Will EHRcom reuse this mechanism ?
>
>One last point is: our deadline for a (definitive ? initial ?) specification.
>In EHRcom specs, what can we define for now as a stable 2004 milestone ?
>
>Maybe my questions are FAQs.
>Thank you for your kind replies.
>
>-- Patrick Lefebvre
>
>-
>If you have any questions about using this list,
>please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Thomas Clark]

Hi David,

Definitely a component to be included in the:
facility-facility-DataStore-Management
network. There are other candidates, i.e., want to avoid focusing on a
single technology.

-Thomas Clark

- Original Message -
From: "David Forslund" 
To: "Patrick Lefebvre" ;
; "Thomas Beale" 
Sent: Tuesday, May 06, 2003 11:29 PM
Subject: Re: openEHR security


> At 03:18 PM 5/6/2003 +0200, Patrick Lefebvre wrote:
> >Hi everyone,
> >
> >As Thomas & al. pointed, security addresses "a number of aspects",
> >including security policy (defining who does what), data safety, and how
> >security is ensured: so, including safety of the network, the application
> >architecture -including management of messages: asynchronous/EHRcom/XML,
> >or synchronous/CorbaMed/IDL-, the programs, and the platform.
>
> Just a minor comment here.  "CORBAmed" and thus CORBA deals with both
> asynchronous and synchronous "messaging".
> I would also second the comment by Tom Culpepper about a service which
goes
> a long way to mediate the security requirements in healthcare.
>
> Dave
>
> >Great.
> >
> >I agree with Gerard Freriks's considerations (legal, social control and
> >organisational aspects) but for now I only focus on the technical
> >specification.
> >
> >For now, I will focus on far restricted objectives.
> >One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure
> >ascending compatibility.
> >ENV13606 messages (part  3 : "distribution rules") describe access policy
> >in terms of objects ("Who", "When", "Where",etc.) whose instanciations
> >define the allowed access context to message objects.
> >
> >So, in the viewpoint of EHRcom release 1 in 2004,
> >* Will this (or such an) architecture be reused in EHRcom ?
> >* If no, will we have a tool to convert distribution rules into
> >corresponding archetypes ?
> >* If no, how is it planned to ensure ascending compatibility ?
> >
> >Another basic, technical, concrete security point is: ensuring data
> >(transmission + authoring) integrity in the message.
> >One solution proposed by ENV13606 was: systematic digital signature of
> >each transaction.
> >Will EHRcom reuse this mechanism ?
> >
> >One last point is: our deadline for a (definitive ? initial ?)
specification.
> >In EHRcom specs, what can we define for now as a stable 2004 milestone ?
> >
> >Maybe my questions are FAQs.
> >Thank you for your kind replies.
> >
> >-- Patrick Lefebvre
> >
> >-
> >If you have any questions about using this list,
> >please send a message to d.lloyd at openehr.org
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

Comments in text.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Tuesday, May 06, 2003 4:43 PM
Subject: Re: openEHR security; Directed to Thomas Beale


> Thomas,
>
> maybe I'm too dense but I cannot appreciate the complexity of
> the issue as you hash it out.
>
> To me this is simply:
>
> 3.5.2003 10:35 am first seen patient
>  medium pain frontal skull after contusion in traffic accident
> 5 mins ago, no neurological abnormalities right now, GCS 15
>

Patient prior history missing. Potential head injury should indicate
query-response might be a problem. Record might show allergies to
drugs and injuries to other areas that could complicate such
procedures as X-Ray, e.g., steel plate in neck which may
represent collateral damage that is not obvious.

Relying 100% on visual inspections and observations may not cut
it, especially where the Patient has an easily accessible EHR, etc.,
such as the hospital you are standing in. Good legal material, i.e.,
the Patient has a medical card for the hospital and has had prior
surgery at this hospital. Why not punch up the card number on the
computer terminal in the ER?

> 3.5.2003 10:45 check up
>  pain on pressure to 2nd cervical vertebra, dizziness,
>  nausea, claims fuzzy vision, left pupil dilated responding to
>  light slower than right, now severe pain frontal/retroorbital/
>  right temporal region. GCS 12.
>

Narratives are supplements to tracking which should be integrated
into the record. Doesn't really help if the record shows that the Patient
entered the hospital but not what transpired. Big RED button.

> Clearly, there's some new and some updated information in this
> narrative. This is the point where I immediately ship the
> patient to the next CT/MRI scanning facility with on-duty
> neuro/neuro-surgery.
>

Narratives are great tools are are used frequently today, and are often
interpreted  in the legal environment. They can include charts and images
to support a diagnosis and treatment. They can also be very lengthy and
difficult to accomodate in records systems, e.g., a digital representation
of a
CAT scan requires large numbers of storage with high resolution scans
requiring lots of bytes (e.g., several gigabytes).  A lot of these images
are
trashed (could be redundant or just bad).

An append-only text field might be great for a User Interface supporting
text input but handling this over a course of treatment by multiple
Practitioners
gets a little tough. Suppose four Practitioners decide to update their
narrative simultaneously and they all 'finish' simultaneously. What happens
to
the record?

Single-user, semaphore-based UI applications are just not good enough. If
someone forgets to unlock the record and leave for the evening I hope you
have their cell number.

Inside the EMR there needs to be practitioner identification, events,
pointers
to associated data, etc so that something later backtracking and
reconstruction
are possible. Everything of significance is entered, even spelling errors.

> All this requires is an append-only text field. Of course, it
> can be handled much more fanciful inside the EMR, trying to
> link items, graphing trends on scales, etc. etc. The basics,
> however, can be handled by free text fields. And even they do
> not just emulate the paper based record but offer one clear
> advantage: they are readable by me even if someone else wrote
> down the first assessment.
>
> > Narratives can be hard to handle in record-based systems as can
scannable
> > entries, e.g., charts and images.
> But they are absolutely necessary.
>
> Karsten

The User Interface is a 'connected' issue; it generates input for the
record. Medical
devices generate input. Both will get formatted, possibly encrypted,
compressed
and integrated or linked to the record.

Narrative in their 'final' form are of interest to the record designer and
they will
likely not look like anything you though you entered, e.g., encrypted,
compressed,
pdf file that becomes a history file (unchangeable).

> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Hi Thomas,

> Constructive! Do you anticipate entering this type status information
> into an OpenEHR record?
Absolutely ! I do record such information even today.

> If so, what record?
I do so now in the narrative part of the record, at times
linked to previous data by plain and simple layout of data
items.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas

> Unless you are planning on an early retirement, etc., it is feasible in
> the short term. It is an easy sell; try Canada.
Having been to remote areas of Thailand, Vietnam, India, Egypt
and China myself (as a traveller, however, not a health
professional) let me assure you that it may be an easy sell
in Canada but not necessarily so in other regions.

> asking a Patient with a history of pain if they
> are in pain has to be different from one that just started.
Surely, but it makes a lot of sense to ask the patient if the
pain has worsened/bettered/shifted in location or type. Or if
other symptoms have become apparent since the first
assessment.

> Patient expectations are reasonable, usually. They expect some action
> soon, and it should be proper and timely.
The difference between "soon" and "timely" often makes all the
difference in perception of adequate immediate care between
provider and patient.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

This is important since 'linked' messages, e.g., XML database, can be used
to
handle both status messages from a single Practitioner and multiple
Practitioners. The real problem is to decide/filter what gets in the
permanent record.

This can have legal impacts in the local jurisdiction. For example, charting
is
performed but most cases at some later time (an issue since memory
recall is suspect) and is typically a paper record Some facilities are
attempting to automate this as well as other practices. What to do with this
information for many remains an unsolved puzzle.

Narratives can be hard to handle in record-based systems as can scannable
entries, e.g., charts and images.

What you do is important and should/must be saved. A possible approach is
a collection of databases handling specific information with posting in a
EHR/EPR/EMR, both surviving as permanent data.

This puts a focus on record format/structure, i.e., there are limitations
imposed by implementation, jurisdiction, users, performance, networking,
etc. Small block sizes is desirable; records can be composed of multiple
blocks; narratives from multiple Practitioners might be hard to handle.

Interesting problem!

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Tuesday, May 06, 2003 2:06 PM
Subject: Re: openEHR security; Directed to Thomas Beale


> Hi Thomas,
>
> > Constructive! Do you anticipate entering this type status information
> > into an OpenEHR record?
> Absolutely ! I do record such information even today.
>
> > If so, what record?
> I do so now in the narrative part of the record, at times
> linked to previous data by plain and simple layout of data
> items.
>
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Patrick Lefebvre]

Hi everyone,

As Thomas & al. pointed, security addresses "a number of aspects", 
including security policy (defining who does what), data safety, and how 
security is ensured: so, including safety of the network, the application 
architecture -including management of messages: asynchronous/EHRcom/XML, or 
synchronous/CorbaMed/IDL-, the programs, and the platform.
Great.

I agree with Gerard Freriks's considerations (legal, social control and 
organisational aspects) but for now I only focus on the technical 
specification.

For now, I will focus on far restricted objectives.
One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure 
ascending compatibility.
ENV13606 messages (part  3 : "distribution rules") describe access policy 
in terms of objects ("Who", "When", "Where",etc.) whose instanciations 
define the allowed access context to message objects.

So, in the viewpoint of EHRcom release 1 in 2004,
* Will this (or such an) architecture be reused in EHRcom ?
* If no, will we have a tool to convert distribution rules into 
corresponding archetypes ?
* If no, how is it planned to ensure ascending compatibility ?

Another basic, technical, concrete security point is: ensuring data 
(transmission + authoring) integrity in the message.
One solution proposed by ENV13606 was: systematic digital signature of each 
transaction.
Will EHRcom reuse this mechanism ?

One last point is: our deadline for a (definitive ? initial ?) specification.
In EHRcom specs, what can we define for now as a stable 2004 milestone ?

Maybe my questions are FAQs.
Thank you for your kind replies.

-- Patrick Lefebvre

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas,

apologies for I at times respond a bit too rashly :-)

I was not trying to advocate to just base decisions on what
the patient tells me. I was just struck by the example:
patient with elevated temperature, coughing and slight
difficulty breathing (generally feeling unwell) just having
arrived from a known SARS area. My response was simply based
on those facts and the only sane (clinical) response is to
get the patient to the next infectious diseases ward
relatively quickly for further assessment. This is, of course,
coloured by my working in a clinic, not a hospital department.

However, it would certainly be very wonderful to be able to
access OpenEHR()ed records from the backwaters of China but I
wonder if I'll live to see that happen (I'm 28). So, yes,
electronically available pre-recorded information is very
helpful and OpenEHR is immensely useful at any of those parts
of dealing with the above patient.

> obvious bump on the head (swollen). The Emergency Room nurse
> retrieved my name and address and then asked if I was in pain. Being
> Irish is a detriment at times, but I managed to respond that I was indeed
> in a lot of pain, was unable to stand, could not drive a car, and a prior
> neck injury was causing considerable distress, all of which was already
> on the record (same hospital and ambulance technician record).
Your current assessment of a situation is just as valuable as
what is recorded somewhere. I routinely do ask patients for
about the same information (or more specifically their current
assessment of said information) that they have provided
previously. It does help to establish a clinical path
beforehand such as "We will attend to alleviating your current
discomfort right away but I must re-assess some information
because some of the further treatment may alter your
perception of it." I have generally found patients very
responsive to that explanation. It takes about 2 seconds.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

Comments in text.

-Thomas Clark

- Original Message - 
From: "Karsten Hilbert" 
To: 
Sent: Tuesday, May 06, 2003 8:56 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> Thomas
> 
> > Unless you are planning on an early retirement, etc., it is feasible in
> > the short term. It is an easy sell; try Canada.
> Having been to remote areas of Thailand, Vietnam, India, Egypt
> and China myself (as a traveller, however, not a health
> professional) let me assure you that it may be an easy sell
> in Canada but not necessarily so in other regions.
> 

Hope SARS can modify this!

> > asking a Patient with a history of pain if they
> > are in pain has to be different from one that just started.
> Surely, but it makes a lot of sense to ask the patient if the
> pain has worsened/bettered/shifted in location or type. Or if
> other symptoms have become apparent since the first
> assessment.
> 

Constructive! Do you anticipate entering this type status information
into an OpenEHR record? If so, what record?

> > Patient expectations are reasonable, usually. They expect some action
> > soon, and it should be proper and timely.
> The difference between "soon" and "timely" often makes all the
> difference in perception of adequate immediate care between
> provider and patient.
> 
> Karsten

Correct!

> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Thomas Clark]

Hi Patrick,

Good questions! I have been looking at the issues at the record level:

1)archival (personal, facility, Secure Data Store; no direct government
involvement)
2)who serves the records (e.g., can't keep going to the archive)
3)record updates at the server
4)EDI for the records
5)Translation for the records (temporary vs permanent foreign format)
6)Interfacing with Insurance organizations (priority databases)
7)maintaining records at the Healthcare facility (temporary vs permanent;
single vs multiple record formats; caching records; facility records that
incorporate non-healthcare data; privacy, security)
8)inter-facility, record-based communications, e.g., conferencing, remote
and
roving participation
9)replication and modification
10)summary record formats, e.g., for the Patient and facilitators (e.g.,
administrators)

Lots of development issues embedded here, both record implementation and
information. Moving content between record systems and retrieving,
re-formatting and
transmitting information are the two main areas.

Possible solutions/directions:
1)a 'carrier' system for Healthcare records, e.g., a 'wrapper' for
Healthcare records
that is capable of many formats and essentially passes the buck to the
recipient
system (FibreChannel transmission; frame-based communications)
2)multiply-formatted information (redundant), e.g., identical information
stored
in multiple, dissimilar records (different formats; each potentially serving
different
areas, legal systems, etc)
3)yet another Healthcare record format

My suspicion is that facilities will be dealing with multiple record formats
for a rather long
time. Deployed software uses foreign record formats and is unlikely to
change when
an OpenEHR format/protocol is announced.

My suggestion is to direct efforts at developing a format/protocol that
interfaces to
most of the existing formats and grows from there. Would be nice to form a
close
relationship with device vendors on this.

The bottom line is that deployment requires something close to transparency,
i.e.,
a facility should be able to ignore the fact that there are devices and
systems working
together that support different record formats.

-Thomas Clark



- Original Message -
From: "Patrick Lefebvre" 
To: ; "Thomas Beale"

Sent: Tuesday, May 06, 2003 6:18 AM
Subject: Re: openEHR security


> Hi everyone,
>
> As Thomas & al. pointed, security addresses "a number of aspects",
> including security policy (defining who does what), data safety, and how
> security is ensured: so, including safety of the network, the application
> architecture -including management of messages: asynchronous/EHRcom/XML,
or
> synchronous/CorbaMed/IDL-, the programs, and the platform.
> Great.
>
> I agree with Gerard Freriks's considerations (legal, social control and
> organisational aspects) but for now I only focus on the technical
> specification.
>
> For now, I will focus on far restricted objectives.
> One of EHRcom's startpoints is ENV 13606-1999, and we all want to ensure
> ascending compatibility.
> ENV13606 messages (part  3 : "distribution rules") describe access policy
> in terms of objects ("Who", "When", "Where",etc.) whose instanciations
> define the allowed access context to message objects.
>
> So, in the viewpoint of EHRcom release 1 in 2004,
> * Will this (or such an) architecture be reused in EHRcom ?
> * If no, will we have a tool to convert distribution rules into
> corresponding archetypes ?
> * If no, how is it planned to ensure ascending compatibility ?
>
> Another basic, technical, concrete security point is: ensuring data
> (transmission + authoring) integrity in the message.
> One solution proposed by ENV13606 was: systematic digital signature of
each
> transaction.
> Will EHRcom reuse this mechanism ?
>
> One last point is: our deadline for a (definitive ? initial ?)
specification.
> In EHRcom specs, what can we define for now as a stable 2004 milestone ?
>
> Maybe my questions are FAQs.
> Thank you for your kind replies.
>
> -- Patrick Lefebvre
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

Thanks for the response. Comments in text.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Tuesday, May 06, 2003 5:05 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> Thomas,
>
> apologies for I at times respond a bit too rashly :-)
>
> I was not trying to advocate to just base decisions on what
> the patient tells me. I was just struck by the example:
> patient with elevated temperature, coughing and slight
> difficulty breathing (generally feeling unwell) just having
> arrived from a known SARS area. My response was simply based
> on those facts and the only sane (clinical) response is to
> get the patient to the next infectious diseases ward
> relatively quickly for further assessment. This is, of course,
> coloured by my working in a clinic, not a hospital department.
>

My hope is that clinics are connected locally, regionally, nationally and
globally in a peer-peer network with lots of interaction. Information
must flow freely with no borders. The SARS situation shows that
this is a requirement. Globally we are lucky!

Considerable effort have gone into configuring systems that can
handle a global population and related Public Health issues. Technology
presents no impediment; politics and funding do.

Travelers are being scanned, their backgrounds checked and prior
information checks performed, some related to Healthcare alerts.
It is a small step to include connections to the departure and arrival
Healthcare systems and related databases. Since we are spending
billions on security of this type the connection should be a necessary
addition; at least the Public Health people seem to think so.

It would be a great tool especially since the economic benefits would
be significant, i.e., the SARS situation has shown what emotions can
accomplish.

Unless you are planning on an early retirement, etc., it is feasible in
the short term. It is an easy sell; try Canada.

> However, it would certainly be very wonderful to be able to
> access OpenEHR()ed records from the backwaters of China but I
> wonder if I'll live to see that happen (I'm 28). So, yes,
> electronically available pre-recorded information is very
> helpful and OpenEHR is immensely useful at any of those parts
> of dealing with the above patient.
>
> > obvious bump on the head (swollen). The Emergency Room nurse
> > retrieved my name and address and then asked if I was in pain. Being
> > Irish is a detriment at times, but I managed to respond that I was
indeed
> > in a lot of pain, was unable to stand, could not drive a car, and a
prior
> > neck injury was causing considerable distress, all of which was already
> > on the record (same hospital and ambulance technician record).

> Your current assessment of a situation is just as valuable as
> what is recorded somewhere. I routinely do ask patients for
> about the same information (or more specifically their current
> assessment of said information) that they have provided
> previously. It does help to establish a clinical path
> beforehand such as "We will attend to alleviating your current
> discomfort right away but I must re-assess some information
> because some of the further treatment may alter your
> perception of it." I have generally found patients very
> responsive to that explanation. It takes about 2 seconds.
>
> Karsten

Communicating with the Patient is vital for the Patient and the
practitioner.
The practitioner must work with an adjustable bar, i.e., communicating
with a Taxi driver is unlike applying the same approach with a Medical
doctor. Medical history (assuming an unknown at the time of the
communication) is a factor; asking a Patient with a history of pain if they
are in pain has to be different from one that just started.

Patient expectations are reasonable, usually. They expect some action
soon, and it should be proper and timely. I, for one, expect communications
to be direct, to the point, on a reasonably high intellectual level and not
repetitive. I also avoid British Army nurses.

Repetitive questions about the obvious is frustrating. Give me a significant
news item or a good joke. I'll last a lot longer that way.

-Thomas Clark


> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Uhm,

> Faced with handling a potential
> SARS Patient worrying about retrieving precise, accurate information from
> them about non-SARS history might be wasted effort and highly frustrating,
[...]
> Presuming that the Patient just arrived from the recesses of China an
> initial effort might be an attempt to:
  ^^^
>
> 1)determine if that recess has an EHR/EPR/EMR based system that can
> be accessed, assuming that your site supports OpenEHR.
[...]
> 11)attempt to update the recess-local EHR/EPR/EMR database
> 12)continue OpenEHR record processing and update (local and recess-local)

You surely got to be kidding me ?

How about getting the patient to an appropriately
equipped/staffed hospital ?

I do see your technical point, though.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Matt Evans]

Hi Thomas,

I forgot I had set up an inbox rule for posts from this forum so have
probably missed the last 40 or more posts. Will have to go back through them
all to see exactly what has been covered.

Thank you for your useful description.

I had meant to put my case as a clinican but as this is the 'technical'
forum I don't know if it was the right place.

I agree that the described approach makes sense and offers a great deal of
customsation regarding access. What I am concerned about, I suppose, is how
the system will be implemented. These concerns stem from some examples I
have heard - for instance an orthopaedic surgeon only requiring information
to perform an operation. Perhaps this is an inaccurate example?

My viewpoint is that I spend up to an hour when assessing a patient
carefully extracting as much information as possible. My colleagues rely on
the thoroughness of this information to look after this patient. We also
rely on full access to the entire medical record (ever recorded) in order to
safely and holistically care for our patients. I would hope I would have
full access to the medical record in order to fulfill my clinical
responsibilities.

In my field, it is not unusual for patients to either provide unreliable
details or to conceal facts. We often rely on recorded facts rather than
what we are told. In these circumstances I have concerns about the patient's
right to keep private parts of their records. I believe that the suggestion
that a patient may essentially exclude sections of their notes from viewing
represents a major shift in the way we work. I would also argue that it's
difficult for a patient to know when this concealment may put themself or
others at risk.

Is the intended approach that the viewer would know there was information
that they could not view or that it is simply hidden?

Matt

>-Original Message-
>From: Thomas Clark [mailto:tclark at hcsystems.com] 
>Sent: 02 May 2003 04:18
>To: Matt Evans; openehr-technical at openehr.org
>Subject: Re: openEHR security; Directed to Thomas Beale
>
>
>Hi Matt,
>
>Fragmented records and securing individual and groups of 
>records is a common
>approach. It is very much like taking a 300 page document and 
>building a
>security system that enables security:
>1)covering the entire document
>2)separate security covering chapters and
>3)separate security for tables, graphs and figures.
>
>Access to the document is the first step; access to a specific chapter
>requires separate authentication; access to tables, etc can 
>require separate
>authentication. This focuses a specific reader's requests to 
>those portions
>that are "relevant"/"germane".
>
>"one authentication" systems, e.g., password to your windows 
>PC or Linux
>workstation are really ancient security systems. There are 
>typically more
>ways to break-in than log-in.
>
>Recall than system and network managers are often the targets 
>of security
>probes because they can access your raw data at will; that may 
>include your
>sensitive data. If you grant access to the entire EHR for a Patient to
>anyone successfully passing a "one authentication"  gate you 
>are likely to
>experience some real "pushback".  Your obligation as a 
>designer is to ensure
>that "relevance" and NEED TO KNOW are essential elements of 
>the security
>system and that a successful authentication carries with it an 
>assurance
>that the requestor is provided access to only "relevant"/"germane"
>information.
>
>-Thomas Clark
>
>
>- Original Message -
>From: "Matt Evans" 
>To: 
>Sent: Thursday, May 01, 2003 2:30 PM
>Subject: FW: openEHR security; Directed to Thomas Beale
>
>
>> >[...]
>> >> At all points NEED TO KNOW
>> >> governs access
>> >[...]
>> >
>> >Except that the Need-To-Know paradigm doesn't work very well
>> >in healthcare. The provider may not know what she needs to
>> >know at the time of the patient encounter. The patient can't
>> >possibly correctly decide what her doctor must know in order
>> >to be able to make the right decisions (of course, the patient
>> >is fully able to decide what she *wants* the doctor to know).
>> >Etc.
>> >
>> >Medicine is neither the military nor a secret service, literally
>> >(it's not mass media either, on the other end of the spectrum).
>> >
>> >Just a clinician's muttering ...
>> >
>> >Karsten
>> >--
>>
>> Karsten,
>>
>> I agree and have concerns about being expected to take responsibility
>> without access to all the fact

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Alby Creevey]

There a many other products that will provide the same sort of Secure
Message Delivery as well. (HIPPA ain't an insignificant piece of work,,, but
hey,, they might not have it right)

Guys,,,Don't get bogged down in the technical detail,, define the business
process and rules first,, and the rest will follow.




  _

Alby Creevey

ph: (melb) +61 (0)3 9533   (syd) +61 (0)2 9263 2700
fx:  (melb) +61 (0)3 9533 9988  (syd) +61 (0)2 9263 2711
mob: +61 (0)419 478 650url: www.SeeBeyond.com

acreevey at SeeBeyond.com <mailto:acreevey at SeeBeyond.com>







-Original Message-
From: owner-openehr-techni...@openehr.org
[mailto:owner-openehr-technical at openehr.org]On Behalf Of Thomas Clark
Sent: Monday, 5 May 2003 1:54 PM
To: Bill Walton; openehr-technical at openehr.org; Thomas Beale
Subject: Re: Access controls and Audit trails (was Re: openEHR
security); Bill Walton


Hi Bill.

The following link might be appropriate for ftp-based messaging solutions:

http://www.linuxmednews.com/linuxmednews/1046134538/index_html

TITLE: "... and open-source Electronic Data Interchange"

NOTES:
-"... SolAce Server was designed to do reliable, secure messaging in
compliance with the HIPAA Security Rule ..."

-written in Java

-Thomas Clark

- Original Message -
From: "Bill Walton" 
To: ; "Thomas Beale"

Sent: Sunday, May 04, 2003 8:14 PM
Subject: Re: Access controls and Audit trails (was Re: openEHR security)


> Hi Thomas,
>
> Thomas Beale wrote:
> >
> > Bill Walton wrote:
> > >
> > > > > BW:  Further, it looks like the EHR access history should include
> > > reads as well as writes.  That way, the trail would lead to the
> > > providers that have, with permission, made copies of the EHR within
> > > their own systems.
> > >
> > > > SH: True - it will only be able to be stored as an HTML rendition
> > > unless there is an extract in openEHR - but you are right - this could
> > > be saved - this is difficult to police.
> > >
> > > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > > specifies, under the Transaction Rules that go into effect in October
> > > of this year, a number of EDI transactions between systems that would
> > > require this.  HTML will not be sufficient.
> >
> > Can anyone clarify this bit of the debate - I have lost track of what is
> > being said here!
>
> I was inquiring about the audit trail capabilities intended to be
> incorporated in v1.0 of openEHR and Sam was very graciously trying to
> enlighten me.  His commment re: HTML made me expand the question to
> extracts.  I'm not sure I was sufficiently clear about my line of
> questioning, and comments by others make me wonder whether or not I should
> take this off-line.  I am specifically trying to ascertain the
applicability
> of openEHR to the emerging requirements here in the U.S. and do not wish
to
> infringe on the group's bandwidth if there is a less intrusive way to
handle
> my questions.  Please let me know how you'd like me to proceed.  And thank
> you all for your patience to date.
>
> Best regards,
> Bill
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

A SARS Patient example was chosen because initial screening detects
people with elevated temperatures, e.g., airport screening. Once detected
early access to records should be facilitated. Information contained in
these
records is likely to be more extensive, accurate and precise than
information from a Patient who is suffering an attack.

Reminds me of my car accident two years ago in which I received an
obvious bump on the head (swollen). The Emergency Room nurse
retrieved my name and address and then asked if I was in pain. Being
Irish is a detriment at times, but I managed to respond that I was indeed
in a lot of pain, was unable to stand, could not drive a car, and a prior
neck injury was causing considerable distress, all of which was already
on the record (same hospital and ambulance technician record).

Having experienced the flu on prior occasions I can confidently say that
things I say during this time period I will neither remember nor understand
why I said them. Including these statements in the record probably is not
a good idea nor is basing a diagnosis, other that 'He is out-of-it', on this
information.

The presumption that a Patient is 100% lucent in a stressful situation is
subject to debate, e.g., accidents, flu, labor and delivery.

Retrieve the information from the Patient; analyze it; compare it with the
record, if available, but give it a proper weighing. Don't forget the
symptoms and the reasons the Patient ended up in the facility.

It is an information retrieval/analysis/credibility/reliability problem. The
information needs to be sorted.

Getting the Patient to an appropriately staffed hospital/clinic is a
response to the above. Such a response should not be based solely
on information retrieved from the Patient, e.g., they may still want to
attend that meeting.

-Thomas Clark


- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Monday, May 05, 2003 9:14 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> Uhm,
>
> > Faced with handling a potential
> > SARS Patient worrying about retrieving precise, accurate information
from
> > them about non-SARS history might be wasted effort and highly
frustrating,
> [...]
> > Presuming that the Patient just arrived from the recesses of China an
> > initial effort might be an attempt to:
>   ^^^
> >
> > 1)determine if that recess has an EHR/EPR/EMR based system that can
> > be accessed, assuming that your site supports OpenEHR.
> [...]
> > 11)attempt to update the recess-local EHR/EPR/EMR database
> > 12)continue OpenEHR record processing and update (local and
recess-local)
>
> You surely got to be kidding me ?
>
> How about getting the patient to an appropriately
> equipped/staffed hospital ?
>
> I do see your technical point, though.
>
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Bill Walton]

Hi Alby,

Alby Creevey wrote:


> There a many other products that will provide the same sort of Secure
> Message Delivery as well. (HIPPA ain't an insignificant piece of work,,,
but
> hey,, they might not have it right)

I'll be checking into it.  The test phase for HIPAA compliance re: the
Transaction Rules has just started and should yield some publicly available
information in short order.

> Guys,,,Don't get bogged down in the technical detail, define the business
> process and rules first,, and the rest will follow.

HHS (Dept.of Health and Human Services of the U.S. Food and Drug
Administration) has, through the promulgation of the HIPAA Privacy Rule
(compliance date of 4/14/03), Transaction Rule (compliance date of
10/16/03), and Security Rule (compliance date of 4/20/05) defined a new set
of business rules for Health care providers, plans, and clearinghouses here
in the U.S..  The new rules are seen by practioners as introducing new costs
and risks in a business that's already under attack on many fronts.  If
automation emerges that can help them reduce the costs and risks, the
likelihood is that they'll adopt it quickly.  This is being viewed as an
important opportunity by EHR vendors, one that could see the rapid and
widespread adoption of EHR systems.  IMO, it's an even larger opportunity
for the open source community given the financial pressures the provider
community are already under.  So now it's time to see if we're up to the
task.

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Bill Walton]

Hi Thomas,

Thanks for the link.  I've enjoyed your posts.

Best regards,
Bill

- Original Message -
From: "Thomas Clark" 
To: "Bill Walton" ; ;
"Thomas Beale" 
Sent: Sunday, May 04, 2003 10:54 PM
Subject: Re: Access controls and Audit trails (was Re: openEHR security);
Bill Walton


> Hi Bill.
>
> The following link might be appropriate for ftp-based messaging solutions:
>
> http://www.linuxmednews.com/linuxmednews/1046134538/index_html
>
> TITLE: "... and open-source Electronic Data Interchange"
>
> NOTES:
> -"... SolAce Server was designed to do reliable, secure messaging in
> compliance with the HIPAA Security Rule ..."
>
> -written in Java
>
> -Thomas Clark
>
> - Original Message -
> From: "Bill Walton" 
> To: ; "Thomas Beale"
> 
> Sent: Sunday, May 04, 2003 8:14 PM
> Subject: Re: Access controls and Audit trails (was Re: openEHR security)
>
>
> > Hi Thomas,
> >
> > Thomas Beale wrote:
> > >
> > > Bill Walton wrote:
> > > >
> > > > > > BW:  Further, it looks like the EHR access history should
include
> > > > reads as well as writes.  That way, the trail would lead to the
> > > > providers that have, with permission, made copies of the EHR within
> > > > their own systems.
> > > >
> > > > > SH: True - it will only be able to be stored as an HTML rendition
> > > > unless there is an extract in openEHR - but you are right - this
could
> > > > be saved - this is difficult to police.
> > > >
> > > > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > > > specifies, under the Transaction Rules that go into effect in
October
> > > > of this year, a number of EDI transactions between systems that
would
> > > > require this.  HTML will not be sufficient.
> > >
> > > Can anyone clarify this bit of the debate - I have lost track of what
is
> > > being said here!
> >
> > I was inquiring about the audit trail capabilities intended to be
> > incorporated in v1.0 of openEHR and Sam was very graciously trying to
> > enlighten me.  His commment re: HTML made me expand the question to
> > extracts.  I'm not sure I was sufficiently clear about my line of
> > questioning, and comments by others make me wonder whether or not I
should
> > take this off-line.  I am specifically trying to ascertain the
> applicability
> > of openEHR to the emerging requirements here in the U.S. and do not wish
> to
> > infringe on the group's bandwidth if there is a less intrusive way to
> handle
> > my questions.  Please let me know how you'd like me to proceed.  And
thank
> > you all for your patience to date.
> >
> > Best regards,
> > Bill
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[lakew...@copper.net]

Hi Matt,

Comments in text.

- Original Message -
From: "Matt Evans" 
To: "'Thomas Clark'" ; 
Sent: Monday, May 05, 2003 7:09 AM
Subject: RE: openEHR security; Directed to Thomas Beale


> Hi Thomas,
>
> I forgot I had set up an inbox rule for posts from this forum so have
> probably missed the last 40 or more posts. Will have to go back through
them
> all to see exactly what has been covered.
>
> Thank you for your useful description.
>
> I had meant to put my case as a clinican but as this is the 'technical'
> forum I don't know if it was the right place.

Your 'case as a clinican' is in the right forum. It is at the top of the
heap.
The development should support the clinician at all levels.

A 'cold turkey' visit with a Patient (no prior contact) is the worst case.
Focusing on this for the moment, the need is to conduct a Patient
Query-Response diagnosis to build a basic information base that includes
some prior information as well as the reason(s) why they are there.
At first glance it would appear that there is no need for a system such as
OpenEHR during this brief contact.

The reality is that the opposite is true. Faced with handling a potential
SARS Patient worrying about retrieving precise, accurate information from
them about non-SARS history might be wasted effort and highly frustrating,
e.g., sorting "relevant"/"germane" information could impact the schedule and
result in dumping portions later on (mental state is operative).

Presuming that the Patient just arrived from the recesses of China an
initial
effort might be an attempt to:
1)determine if that recess has an EHR/EPR/EMR based system that can
be accessed, assuming that your site supports OpenEHR.
2)make contact with the Patients record-based system, if possible, and
resolve access-related difficulties (e.g., get permission from the Patient
or
recess-local officials, since this would be a public health issue, to access
the information)
3)Assuming the information is made available, perform a translation into
English if available; if not, make contact with a translator
4)Make sense of the record, if possible; if not, make contact with a
translator
5)Retrieve "relevant"/"germane" information; if not possible, make contact
with
a translator
6)Retrieve extra-record information, e.g., public health officials; if not
possible, make contact with news sources
7)Build an EPR that contains prior information (OpenEHR-compatible)
8)use an appropriate software application to analyze the EPR and highlight
loopholes and significant information
9)update the EPR with information related to the Patient's family and
contacts
10)update the EPR with current information
11)attempt to update the recess-local EHR/EPR/EMR database
12)continue OpenEHR record processing and update (local and recess-local)

Seems like very heavy involvement of OpenEHR at the initial point of
contact.
Note the presumption regarding the existence of intelligent medical/health
software applications.

>
> I agree that the described approach makes sense and offers a great deal of
> customsation regarding access. What I am concerned about, I suppose, is
how
> the system will be implemented. These concerns stem from some examples I
> have heard - for instance an orthopaedic surgeon only requiring
information
> to perform an operation. Perhaps this is an inaccurate example?
>

Hope the prior description covers the needed suport of a global, Enterprise
system capable of securely accessing and updating local and remote data
sources

> My viewpoint is that I spend up to an hour when assessing a patient
> carefully extracting as much information as possible. My colleagues rely
on
> the thoroughness of this information to look after this patient. We also
> rely on full access to the entire medical record (ever recorded) in order
to
> safely and holistically care for our patients. I would hope I would have
> full access to the medical record in order to fulfill my clinical
> responsibilities.
>

Opinion:
A thorough, in-depth attempt at retrieving information from a Patient who
is in considerable pain or who is marginally present is probably not an
effective approach. A person that sustained a head injury in a car
accident would be more interested in receiving treatment than answering
a long list of questions. Probably would not remember the answers later.

The need for OpenEHR- like and -compatible systems is obvious. The
information base is reviewable, verifiable, consistent and can be readily
retrieved and updated, e.g., tied to medical devices and mobile/remote
Practitioners.

> In my field, it is not unusual for patients to either provide unreliable
> details or to conceal facts. We often rely on recorded facts rather than
> what we are told. In these circumstances I have concerns about the
p

Access controls and Audit trails (was Re: openEHR security)

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:
>
> Bill Walton wrote:
> >
> > > > BW:  Further, it looks like the EHR access history should include
> > reads as well as writes.  That way, the trail would lead to the
> > providers that have, with permission, made copies of the EHR within
> > their own systems.
> >
> > > SH: True - it will only be able to be stored as an HTML rendition
> > unless there is an extract in openEHR - but you are right - this could
> > be saved - this is difficult to police.
> >
> > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > specifies, under the Transaction Rules that go into effect in October
> > of this year, a number of EDI transactions between systems that would
> > require this.  HTML will not be sufficient.
>
> Can anyone clarify this bit of the debate - I have lost track of what is
> being said here!

I was inquiring about the audit trail capabilities intended to be
incorporated in v1.0 of openEHR and Sam was very graciously trying to
enlighten me.  His commment re: HTML made me expand the question to
extracts.  I'm not sure I was sufficiently clear about my line of
questioning, and comments by others make me wonder whether or not I should
take this off-line.  I am specifically trying to ascertain the applicability
of openEHR to the emerging requirements here in the U.S. and do not wish to
infringe on the group's bandwidth if there is a less intrusive way to handle
my questions.  Please let me know how you'd like me to proceed.  And thank
you all for your patience to date.

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security); Bill Walton

[Thomas Clark]

Hi Bill.

The following link might be appropriate for ftp-based messaging solutions:

http://www.linuxmednews.com/linuxmednews/1046134538/index_html

TITLE: "... and open-source Electronic Data Interchange"

NOTES:
-"... SolAce Server was designed to do reliable, secure messaging in
compliance with the HIPAA Security Rule ..."

-written in Java

-Thomas Clark

- Original Message -
From: "Bill Walton" 
To: ; "Thomas Beale"

Sent: Sunday, May 04, 2003 8:14 PM
Subject: Re: Access controls and Audit trails (was Re: openEHR security)


> Hi Thomas,
>
> Thomas Beale wrote:
> >
> > Bill Walton wrote:
> > >
> > > > > BW:  Further, it looks like the EHR access history should include
> > > reads as well as writes.  That way, the trail would lead to the
> > > providers that have, with permission, made copies of the EHR within
> > > their own systems.
> > >
> > > > SH: True - it will only be able to be stored as an HTML rendition
> > > unless there is an extract in openEHR - but you are right - this could
> > > be saved - this is difficult to police.
> > >
> > > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
> > > specifies, under the Transaction Rules that go into effect in October
> > > of this year, a number of EDI transactions between systems that would
> > > require this.  HTML will not be sufficient.
> >
> > Can anyone clarify this bit of the debate - I have lost track of what is
> > being said here!
>
> I was inquiring about the audit trail capabilities intended to be
> incorporated in v1.0 of openEHR and Sam was very graciously trying to
> enlighten me.  His commment re: HTML made me expand the question to
> extracts.  I'm not sure I was sufficiently clear about my line of
> questioning, and comments by others make me wonder whether or not I should
> take this off-line.  I am specifically trying to ascertain the
applicability
> of openEHR to the emerging requirements here in the U.S. and do not wish
to
> infringe on the group's bandwidth if there is a less intrusive way to
handle
> my questions.  Please let me know how you'd like me to proceed.  And thank
> you all for your patience to date.
>
> Best regards,
> Bill
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security)

[Thomas Beale]

Bill Walton wrote:

 >
 > > > BW:  Further, it looks like the EHR access history should include
 > reads as well as writes.  That way, the trail would lead to the
 > providers that have, with permission, made copies of the EHR within
 > their own systems.
 >
 > > SH: True - it will only be able to be stored as an HTML rendition
 > unless there is an extract in openEHR - but you are right - this could
 > be saved - this is difficult to police.
 >
 > Oops!  I'd assumed there would be extracts in openEHR.  HIPAA
 > specifies, under the Transaction Rules that go into effect in October
 > of this year, a number of EDI transactions between systems that would
 > require this.  HTML will not be sufficient.

Can anyone clarify this bit of the debate - I have lost track of what is
being said here!

 >
 > I'm taking this to mean that there will be configurable permissions on
 > type of access.  Yes?

yes - probably quite sophisticated ones.

 >  > SH: Research access will be via the kernel with an approved program
 > unless it is one-to-one reading of records when the patient's consent
 > is required anyway.
 >
 > Hmmm  Again, perhaps a difference at the national level.  Research
 > here is the U.S. typically requires extracted data to be
 > transferred from a physician's system to the research organization's
 > system.

both scenarios are equally ok. I would also have expected the one Bill
mentions to be more likely - especially as data transformation and
anonymisatino are often needed.

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Thomas Beale]

Bill Walton wrote:

 >Hi Thomas,
 >
 >Thomas Beale wrote:
 >
 >>So. What do we know?
 >>- role-based access control is required. To make it work properly in a
 >>shared care community context (e.g. a hospital, 50 GPs, aged care homes,
 >>nursing care, social workers etc etc) then the roles need to be defined
 >>congruently. I seem to remember some Canadian project coming to the
 >>conclusion that really the roles need to be defined the same across the
 >>entire (national) health care system. I think this is both correct and a
 >>the same time unrealistic.
 >>
 >>
 >
 >With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
 >correct.  (Pragmatism R Us ;-) )
 >
 >I'd like to offer food for thought.  The fundamental assumption at 
work here
 >seems to be that care givers will access the same system, thus driving the
 >need for all users of the system to be assigned roles that are defined
 >congruently.  Let's consider an alternative model.
 >
when I wrote "health system" above, I meant the whole health delivery
system in a country or region, not literally an information system.

 >
 >When I travel from the U.S. to the U.K., I (the physical being) move from
 >one socio-cultural-legal model to another.  That does not change who / 
what
 >I am, but it does change my behavior because I operate under a 
different set
 >of norms and mores in the new environment.  I accept new forms of
 >interaction and find that familiar forms are no longer available.
 >
 >Why should it be any different for the information about me than it is for
 >me?
 >
exactly right. So many aspects of security, care process, what
archetypes are used etc will change.

 >If we work from a perspective that posits that health information will 
move
 >from system to system and be used / modified based on the rule sets in 
place
 >within the various systems, does that make the problem more amenable to
 >solution?
 >
I think this is our base assumption. All I wanted to say above is that
access control rules somehow have to deal with the varying definitions
of same-named roles across widely differing jurisdictions.

I like Mike's paper too, I need to give it more thought.

- thomas



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Access controls and Audit trails (was Re: openEHR security)

[Thomas Beale]

Bill Walton wrote:

>
> > > BW:  Further, it looks like the EHR access history should include 
> reads as well as writes.  That way, the trail would lead to the 
> providers that have, with permission, made copies of the EHR within 
> their own systems.
>  
> > SH: True - it will only be able to be stored as an HTML rendition 
> unless there is an extract in openEHR - but you are right - this could 
> be saved - this is difficult to police. 
>  
> Oops!  I'd assumed there would be extracts in openEHR.  HIPAA 
> specifies, under the Transaction Rules that go into effect in October 
> of this year, a number of EDI transactions between systems that would 
> require this.  HTML will not be sufficient.

Can anyone clarify this bit of the debate - I have lost track of what is 
being said here!

>  
> I'm taking this to mean that there will be configurable permissions on 
> type of access.  Yes?

yes - probably quite sophisticated ones.

>  > SH: Research access will be via the kernel with an approved program 
> unless it is one-to-one reading of records when the patient's consent 
> is required anyway.
>  
> Hmmm  Again, perhaps a difference at the national level.  Research 
> here is the U.S. typically requires extracted data to be 
> transferred from a physician's system to the research organization's 
> system.

both scenarios are equally ok. I would also have expected the one Bill 
mentions to be more likely - especially as data transformation and 
anonymisatino are often needed.

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Gerard Freriks]

On 2003-05-02 19:25, "Bill Walton"  wrote:

> Hi Gerard,
> 
> Gerard Freriks wrote:
> 
> /snip/
> 
>> In other words: the OpenEHR can assume that the Access Control function
>> operates as if it is a fire wall that executes a set of rules
>> and that the
>> Audit trail is the log with violations (Exceptions) the fire wall had to
>> grant.
>> 
>> The operation of the 'firewal' and audit trail are outside the scope of
> Open
>> EHR.
> 
> While I support the concept of seperating the access control functionality
> from the storage / retrieval functionality, I'm afraid I have to disagree,
> with all due respect, to the segregation of the audit trail and to what I
> understand your definition of what needs to be contained in the audit trail.
> The notion that the audit trail only log exceptions will be a non-starter
> here in the U.S., I think.
>

I understand your remarks.
But.

The following information must be added to get a fuller picture of how I
envisage things:

-0- The context for my remarks is the discourse, using human and computer
processable documents, between health professionals over time and space. My
context is not updating databases using messages.
-1- Electronic systems must provide at least the same quality in all aspects
when compared with paper based systems. The quality can be better but never
less.
-2- Of course persons entering the system are logged
-3- And only information is readily available to which one has rightful
access because one is working in the same department the patient is in.
All access to the information will not be logged in the audit trail.
(paper based systems don't record where the eyes hit the paper and ink)
I assume a high degree of social control in a department.
-4- Audit trails in the sense that is recorded why, what, when, from where,
by whom has used the exception path to reach information are needed when the
requestor is overruling the access controls.
-5- the preferred way of obtaining information must stay (as it always was)
direct contact between health professionals either orally or by writing.

My fear is that because anything can be recorded and tracked or traced we
feel obliged to do so in the electronic domain.
Example: The Data Registrars Office in the Netherlands is of the opinion
that access to electronic medical records can be granted only by using two
ways authentication (password AND biometrics) The only justification is that
it is possible. But it is unaffordable and to complex to organise in the
healthcare domain)



--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[lakew...@copper.net]

Hi Gerard,

Good list of requirements. My question concerns contact between Healthcare
Practitioners and others which may include geographically remote locations
and roving, e.g., in-hospital via  wearable or hand-held units. This contact
would extend beyond that of the Practitioner-Patient.

A good example would be Remote Surgery with requirements that amount to
secure, continuous audio/visual connections. Another would be my clinic
where they have migrated to computer systems within the exam room and at
other points of contact.

If a process, procedure, technology is already in use would it be integrated
within the OpenEHR scope, requirements, goals and implementation? Judging
from the difficulty getting something implemented it would seem that
somewhere, sometime someone was able to justify the project and get it
implemented.

-Thomas Clark

- Original Message -
From: "Gerard Freriks" 
To: "Bill Walton" ; 
Sent: Saturday, May 03, 2003 2:37 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> On 2003-05-02 19:25, "Bill Walton"  wrote:
>
> > Hi Gerard,
> >
> > Gerard Freriks wrote:
> >
> > /snip/
> >
> >> In other words: the OpenEHR can assume that the Access Control function
> >> operates as if it is a fire wall that executes a set of rules
> >> and that the
> >> Audit trail is the log with violations (Exceptions) the fire wall had
to
> >> grant.
> >>
> >> The operation of the 'firewal' and audit trail are outside the scope of
> > Open
> >> EHR.
> >
> > While I support the concept of seperating the access control
functionality
> > from the storage / retrieval functionality, I'm afraid I have to
disagree,
> > with all due respect, to the segregation of the audit trail and to what
I
> > understand your definition of what needs to be contained in the audit
trail.
> > The notion that the audit trail only log exceptions will be a
non-starter
> > here in the U.S., I think.
> >>>>>
>
> I understand your remarks.
> But.
>
> The following information must be added to get a fuller picture of how I
> envisage things:
>
> -0- The context for my remarks is the discourse, using human and computer
> processable documents, between health professionals over time and space.
My
> context is not updating databases using messages.
> -1- Electronic systems must provide at least the same quality in all
aspects
> when compared with paper based systems. The quality can be better but
never
> less.
> -2- Of course persons entering the system are logged
> -3- And only information is readily available to which one has rightful
> access because one is working in the same department the patient is in.
> All access to the information will not be logged in the audit trail.
> (paper based systems don't record where the eyes hit the paper and ink)
> I assume a high degree of social control in a department.
> -4- Audit trails in the sense that is recorded why, what, when, from
where,
> by whom has used the exception path to reach information are needed when
the
> requestor is overruling the access controls.
> -5- the preferred way of obtaining information must stay (as it always
was)
> direct contact between health professionals either orally or by writing.
>
> My fear is that because anything can be recorded and tracked or traced we
> feel obliged to do so in the electronic domain.
> Example: The Data Registrars Office in the Netherlands is of the opinion
> that access to electronic medical records can be granted only by using two
> ways authentication (password AND biometrics) The only justification is
that
> it is possible. But it is unaffordable and to complex to organise in the
> healthcare domain)
>
>
>
> --   --
> Gerard Freriks, arts
> Huigsloterdijk 378
> 2158 LR Buitenkaag
> The Netherlands
>
> +31 252 544896
> +31 654 792800
>
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Andrew Goodchild]

Hi Guys,

You know I think it would be more productive to realize that the
granularity of access control differs from enterprise to enterprise, from
state to state and from culture to culture.

Trying to demand that openEHR support a specific level of granualrity
(e.g. transaction vs. entry vs. structured item) is too hard as it will
never please everybody.  If anything openEHR should be agnostic about such
things and just say that there is a "security service" out there which
gives users "priveleges" and these priveleges tell the EHR what kind of
data a user can see. In some enterprises such priveleges might give access
to whole transactions and in others it suppress certain kinds of
information.  The definition of how priveleges are interpreted should be
totally up to the implementing organization.

In our case for an application we are building we use priveleges to allow
users to see different "views" on transactions (e.g. an administrators
view vs. a clinicians view vs. a mental health care team member's view)
and the priveleges are assigned based on the user's role and patient
consent.  However, I would not impose this scheme on anyone else unless it
worked well with their local enterprise requirements and culture.

cheers, Andrew


On Thu, 1 May 2003, Thomas Clark wrote:

> Hi Matt,
>
> Fragmented records and securing individual and groups of records is a common
> approach. It is very much like taking a 300 page document and building a
> security system that enables security:
> 1)covering the entire document
> 2)separate security covering chapters and
> 3)separate security for tables, graphs and figures.
>
> Access to the document is the first step; access to a specific chapter
> requires separate authentication; access to tables, etc can require separate
> authentication. This focuses a specific reader's requests to those portions
> that are "relevant"/"germane".
>
> "one authentication" systems, e.g., password to your windows PC or Linux
> workstation are really ancient security systems. There are typically more
> ways to break-in than log-in.
>
> Recall than system and network managers are often the targets of security
> probes because they can access your raw data at will; that may include your
> sensitive data. If you grant access to the entire EHR for a Patient to
> anyone successfully passing a "one authentication"  gate you are likely to
> experience some real "pushback".  Your obligation as a designer is to ensure
> that "relevance" and NEED TO KNOW are essential elements of the security
> system and that a successful authentication carries with it an assurance
> that the requestor is provided access to only "relevant"/"germane"
> information.
>
> -Thomas Clark
>
>
> - Original Message -
> From: "Matt Evans" 
> To: 
> Sent: Thursday, May 01, 2003 2:30 PM
> Subject: FW: openEHR security; Directed to Thomas Beale
>
>
> > >[...]
> > >> At all points NEED TO KNOW
> > >> governs access
> > >[...]
> > >
> > >Except that the Need-To-Know paradigm doesn't work very well
> > >in healthcare. The provider may not know what she needs to
> > >know at the time of the patient encounter. The patient can't
> > >possibly correctly decide what her doctor must know in order
> > >to be able to make the right decisions (of course, the patient
> > >is fully able to decide what she *wants* the doctor to know).
> > >Etc.
> > >
> > >Medicine is neither the military nor a secret service, literally
> > >(it's not mass media either, on the other end of the spectrum).
> > >
> > >Just a clinician's muttering ...
> > >
> > >Karsten
> > >--
> >
> > Karsten,
> >
> > I agree and have concerns about being expected to take responsibility
> > without access to all the facts.
> >
> > I suppose this may not be an issue as I suspect that most people won't
> > restrict the information in their file.
> >
> > However, to fragment a medical file into bits I can and can't see is
> similar
> > to taking the view that mind and body are separate entities.
> >
> > If something is restricted, will I know there is something there that I
> > can't see? Or will I be blisfully ignorant? How can I know if a piece of
> > information is irrelevant unless I can see it to assess it?
> >
> > More mutterings!
> >
> > Matt
> >
> >
> > -
> > If you have any questions about using this list,
> > please send a message to d.lloyd at openehr.org
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>

  _-_|\Andrew Goodchild
 / *   DSTC Pty Ltd
 \_.-._/   Brisbane, Australia
  vhttp://staff.dstc.edu.au/andrewg/

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Bill Walton]

Hi Gerard,

Gerard Freriks wrote:

/snip/

> In other words: the OpenEHR can assume that the Access Control function
> operates as if it is a fire wall that executes a set of rules
> and that the
> Audit trail is the log with violations (Exceptions) the fire wall had to
> grant.
>
> The operation of the 'firewal' and audit trail are outside the scope of
Open
> EHR.

While I support the concept of seperating the access control functionality
from the storage / retrieval functionality, I'm afraid I have to disagree,
with all due respect, to the segregation of the audit trail and to what I
understand your definition of what needs to be contained in the audit trail.
The notion that the audit trail only log exceptions will be a non-starter
here in the U.S., I think.  The "appropriateness" of an access to a record
can only be determined ex post facto in many cases.  An example may help.
Suppose a nurse prints a copy of one of her patient's records during her
shift.  Is this appropriate access?  On it's face, at the time of access, it
would appear so.  Suppose further,  though, that the nurse later sells that
copy to a third party who uses it to the patient's disadvantage.  Now it's
clear that the access was for inappropriate purposes.  No system can
pre-judge intent.  If the access is not logged, there will be no trail to
the event that led to the inappropriate disclosure and the system will have
contributed to the patient's disadvantage.  Further, unless the list of
accesses is maintained as part of the EHR, there's no guarantee that the
patient will have access to that information.  Thus, I believe the audit
trail functionality must be "in scope" for openEHR, at least to the extent
that the group intends it to be viable here in the U.S..

Best regards,
Bill


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Gerard Freriks]

HI,

What is the EHR OpenEHR is building?
What is the scope?
Is it a complete EHR system?
Or is it that part of the EHR system that stores health data and that
retrieves it?

I think it is the latter. The question of privacy to answer boils down to:
What elements in the domain model for the EHR do we need (need to store and
transmit) in order for an other part of the system perform the access
control function?
The second question is: Access control needs Audit trails; which information
elements are necessary in the domain model for the audit trail function to
work.

These two questions are not to difficult to answer.
In other words: the OpenEHR can assume that the Access Control function
operates as if it is a fire wall that executes a set of rules and that the
Audit trail is the log with violations (Exceptions) the fire wall had to
grant.

The operation of the 'firewal' and audit trail are outside the scope of Open
EHR.

Gerard

On 2003-05-02 5:46, "Andrew Goodchild"  wrote:

> 
> Hi Guys,
> 
> You know I think it would be more productive to realize that the
> granularity of access control differs from enterprise to enterprise, from
> state to state and from culture to culture.
> 
> Trying to demand that openEHR support a specific level of granualrity
> (e.g. transaction vs. entry vs. structured item) is too hard as it will
> never please everybody.  If anything openEHR should be agnostic about such
> things and just say that there is a "security service" out there which
> gives users "priveleges" and these priveleges tell the EHR what kind of
> data a user can see. In some enterprises such priveleges might give access
> to whole transactions and in others it suppress certain kinds of
> information.  The definition of how priveleges are interpreted should be
> totally up to the implementing organization.
> 
> In our case for an application we are building we use priveleges to allow
> users to see different "views" on transactions (e.g. an administrators
> view vs. a clinicians view vs. a mental health care team member's view)
> and the priveleges are assigned based on the user's role and patient
> consent.  However, I would not impose this scheme on anyone else unless it
> worked well with their local enterprise requirements and culture.
> 
> cheers, Andrew
> 
> 
> On Thu, 1 May 2003, Thomas Clark wrote:
> 
>> Hi Matt,
>> 
>> Fragmented records and securing individual and groups of records is a common
>> approach. It is very much like taking a 300 page document and building a
>> security system that enables security:
>> 1)covering the entire document
>> 2)separate security covering chapters and
>> 3)separate security for tables, graphs and figures.
>> 
>> Access to the document is the first step; access to a specific chapter
>> requires separate authentication; access to tables, etc can require separate
>> authentication. This focuses a specific reader's requests to those portions
>> that are "relevant"/"germane".
>> 
>> "one authentication" systems, e.g., password to your windows PC or Linux
>> workstation are really ancient security systems. There are typically more
>> ways to break-in than log-in.
>> 
>> Recall than system and network managers are often the targets of security
>> probes because they can access your raw data at will; that may include your
>> sensitive data. If you grant access to the entire EHR for a Patient to
>> anyone successfully passing a "one authentication"  gate you are likely to
>> experience some real "pushback".  Your obligation as a designer is to ensure
>> that "relevance" and NEED TO KNOW are essential elements of the security
>> system and that a successful authentication carries with it an assurance
>> that the requestor is provided access to only "relevant"/"germane"
>> information.
>> 
>> -Thomas Clark
>> 
>> 
>> - Original Message -
>> From: "Matt Evans" 
>> To: 
>> Sent: Thursday, May 01, 2003 2:30 PM
>> Subject: FW: openEHR security; Directed to Thomas Beale
>> 
>> 
>>>> [...]
>>>>> At all points NEED TO KNOW
>>>>> governs access
>>>> [...]
>>>> 
>>>> Except that the Need-To-Know paradigm doesn't work very well
>>>> in healthcare. The provider may not know what she needs to
>>>> know at the time of the patient encounter. The patient can't
>>>> possibly correctly decide what her doctor must know in order
>>>> to be able to make the right decisions (of course, t

FW: openEHR security; Directed to Thomas Beale

[Matt Evans]

>[...]
>> At all points NEED TO KNOW
>> governs access
>[...]
>
>Except that the Need-To-Know paradigm doesn't work very well
>in healthcare. The provider may not know what she needs to
>know at the time of the patient encounter. The patient can't
>possibly correctly decide what her doctor must know in order
>to be able to make the right decisions (of course, the patient
>is fully able to decide what she *wants* the doctor to know).
>Etc.
>
>Medicine is neither the military nor a secret service, literally
>(it's not mass media either, on the other end of the spectrum).
>
>Just a clinician's muttering ...
>
>Karsten
>-- 

Karsten,

I agree and have concerns about being expected to take responsibility
without access to all the facts.

I suppose this may not be an issue as I suspect that most people won't
restrict the information in their file.

However, to fragment a medical file into bits I can and can't see is similar
to taking the view that mind and body are separate entities.

If something is restricted, will I know there is something there that I
can't see? Or will I be blisfully ignorant? How can I know if a piece of
information is irrelevant unless I can see it to assess it?

More mutterings!

Matt


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Matt,

Fragmented records and securing individual and groups of records is a common
approach. It is very much like taking a 300 page document and building a
security system that enables security:
1)covering the entire document
2)separate security covering chapters and
3)separate security for tables, graphs and figures.

Access to the document is the first step; access to a specific chapter
requires separate authentication; access to tables, etc can require separate
authentication. This focuses a specific reader's requests to those portions
that are "relevant"/"germane".

"one authentication" systems, e.g., password to your windows PC or Linux
workstation are really ancient security systems. There are typically more
ways to break-in than log-in.

Recall than system and network managers are often the targets of security
probes because they can access your raw data at will; that may include your
sensitive data. If you grant access to the entire EHR for a Patient to
anyone successfully passing a "one authentication"  gate you are likely to
experience some real "pushback".  Your obligation as a designer is to ensure
that "relevance" and NEED TO KNOW are essential elements of the security
system and that a successful authentication carries with it an assurance
that the requestor is provided access to only "relevant"/"germane"
information.

-Thomas Clark


- Original Message -----
From: "Matt Evans" 
To: 
Sent: Thursday, May 01, 2003 2:30 PM
Subject: FW: openEHR security; Directed to Thomas Beale


> >[...]
> >> At all points NEED TO KNOW
> >> governs access
> >[...]
> >
> >Except that the Need-To-Know paradigm doesn't work very well
> >in healthcare. The provider may not know what she needs to
> >know at the time of the patient encounter. The patient can't
> >possibly correctly decide what her doctor must know in order
> >to be able to make the right decisions (of course, the patient
> >is fully able to decide what she *wants* the doctor to know).
> >Etc.
> >
> >Medicine is neither the military nor a secret service, literally
> >(it's not mass media either, on the other end of the spectrum).
> >
> >Just a clinician's muttering ...
> >
> >Karsten
> >--
>
> Karsten,
>
> I agree and have concerns about being expected to take responsibility
> without access to all the facts.
>
> I suppose this may not be an issue as I suspect that most people won't
> restrict the information in their file.
>
> However, to fragment a medical file into bits I can and can't see is
similar
> to taking the view that mind and body are separate entities.
>
> If something is restricted, will I know there is something there that I
> can't see? Or will I be blisfully ignorant? How can I know if a piece of
> information is irrelevant unless I can see it to assess it?
>
> More mutterings!
>
> Matt
>
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Mike Mair]

Dear Bill,

""Is a biologically-based security model
> fundamentally better aligned with the needs of an information system about
> biological entities than alternative models?"

The view we developed when working on the ISO/TC215 access proposal (1.) was
that ownership was itself a cultural concept, and one extreme of a spectrum
of reciprocal relationships between rights and obligations. Pure ownership
is all rights and no obligations, which is scarcely achievable. It would
imply, for example, the right to destroy records, which would probably be
denied even where the paradigm of individual autonomy reigns supreme.

We suggested that there was no interoperability without an access control
mechanism being shared (how can you interoperate if you can't access?),
which was why we went for an actual technique for access control, which
developed
into the CDA 'detachable headers' concept in the later paper to which you
refer at the foot of this mail. The crucial components of this idea are
that:

- 'role for access' be part of a culture defined 'set' of roles, recognized
within a jurisdiction, and that these role sets and their access rules
change within and between jurisdictions.
-There would be a basic 'unit' of healthcare information which we called the
'attestable unit'. Later we learnt that the CDA was just such a unit
- That the header should contain 'role for access (role needed to access
that attestable unit).
-The header should be stored separately from the body,
and should act as a pointer to it when 'activated' by an appropriate search.

- Later we found that the CDA already had 'sections' to which different
access levels could apply. The culture defined (and dynamic) role set within
a
jurisdiction could connect in to a finite set of options within a finite
structure, the CDA.. The immunoglobin (biological) metaphor
seems very apt ('Gaia immunology'),

The audit trails of access are built in to the concept, since the data stays
put on the  server, which also collects an audit trail of 'hits'.. but
the device itself, the CDA and its bifunctional structure are  shared.

Thanks again for your interest.

Regards

Mike Mair

  1.. 'Access to Electronic Health Records' NZ access proposal to ISO/TC 215
Current Work Item Proposals Available from: user name 'wg1' Password 'berlin
'. NB Section 3.2 had different authoring and contains conclusions that are
inconsistent with the other sections (the work item is not current at this
time). http://www.health.nsw.gov.au/iasd/imcs/iso-215/areas/atehr2000.pdf


Original Message -
From: "Bill Walton" 
To: 
Sent: Tuesday, April 29, 2003 9:33 AM
Subject: Re: openEHR security


> Hi Thomas,
>
> Thomas Beale wrote:
>
>
> /snip/
>
> > So. What do we know?
> > - role-based access control is required. To make it work properly in a
> > shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> > nursing care, social workers etc etc) then the roles need to be defined
> > congruently. I seem to remember some Canadian project coming to the
> > conclusion that really the roles need to be defined the same across the
> > entire (national) health care system. I think this is both correct and a
> > the same time unrealistic.
>
> With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
> correct.  (Pragmatism R Us ;-) )
>
> I'd like to offer food for thought.  The fundamental assumption at work
here
> seems to be that care givers will access the same system, thus driving the
> need for all users of the system to be assigned roles that are defined
> congruently.  Let's consider an alternative model.
>
> When I travel from the U.S. to the U.K., I (the physical being) move from
> one socio-cultural-legal model to another.  That does not change who /
what
> I am, but it does change my behavior because I operate under a different
set
> of norms and mores in the new environment.  I accept new forms of
> interaction and find that familiar forms are no longer available.
>
> Why should it be any different for the information about me than it is for
> me?
>
> If we work from a perspective that posits that health information will
move
> from system to system and be used / modified based on the rule sets in
place
> within the various systems, does that make the problem more amenable to
> solution?
>
> > I think we will be able to find ways of
> > having diversely defined roles without every health care facility having
> > incompatible definitions of "consultant", "treating physician" etc.
> > Bernd's work on this area is pretty detailed.
>
> I thank Bernd for opening my eyes to what should h

openEHR security

[Philippe AMELINE]

Hi Paul, hi the list,

Thanks for your post - I thought nobody took the time to read mine ;o)

I tried to keep my post in the range of openEHR, however, since you are 
pushing me one step further, I need to tell that, from my point of view, 
continuity of care is probably a step to cross, but not the ultimate goal.

Once you agree that the patient is the owner of a system (say the EHR in 
the taxonomy you are proposing), you have to ask yourself : "when, why and 
by who shall this system get used ?". If you think that Electronic Health 
Record is the right concept for continuity of care, it is probably because 
you realized that Health doesn't mean "no disease", and that even people 
with chronic disease are most often managing their health than they are 
subject of care.

The conclusion we made is that if the system belongs to the patient, it 
must be a tool for the person (and not only the patient). So, this very 
tool must be a he "health capital" manager. Since the system we are working 
on is problem oriented, and it allows to establish health objectives - and 
not only records, we called it : Individual Health Project.

Now the taxinomy is richer, with three acronyms EMR, EHR and IHP ;o)

Philippe

>Philippe,
>
>The approach you have identified makes a lot of sense to me and goes a 
>long ways toward clarifying "ownership" of the record.  I do think it 
>would be helpful to develop standard taxonomy for distinguishing the two: 
>EMR signifying within a closed health care system, and EHR signifying the 
>continuity of care record which is the property of the patient.  It seems 
>to me that if this distinction is not made, "ownership" is going to boil 
>down to issues like "intellectual property."   The way I see it, ownership 
>and access are two, separate, albeit, overlappying issues.  Did I hear 
>somebody mention Napster?
>
> >>> Philippe AMELINE  04/29/03 
> 12:54AM >>>
>Hi,
>
>I must confess I didn't read very carefully each message on this thread ;
>however, I think that I may contribute by explaining the direction we are
>currently following.
>
>First I think we must distinguish between care coordination (inside an
>openEHR node) and continuity of care.
>Continuity of care means that you manage to index every contributions for
>a single patient (these contributions can be openEHR contributions or other
>systems contribution, or even data here and there).
>
>The acces rules must be very different in both cases since :
>- inside a node (care coordination) the system belongs to the team and/or
>the careplace (say it is a domain, maybe a meta-domain) and see patients
>passing through (from in to out).
>- a continuity of care system necesseraly belongs to the patient (when you
>consider a wide period of time, it is the only stable user) and see medical
>teams passing through.
>
>To adress this change of point of view (from a steady referential to a
>moving referential), we are building a system with the following rules :
>- the continuity of care system is an index of existing contributions and
>is granted access rights to the nodes
>- inside the continuity of care system, people that may access data are
>given a position inside the patient "health team" : the position depends on
>the people "job" (doctor, other health professional, family, social worker)
>and depends on his "distance" from the patient (usual care giver vs unusual
>one).
>
>Hence the access rights to the contribution are determined for each
>possible position and depends on the current role inside the personal halth
>team at the very moment.
>
>You can like the way we do it or not, however, I don't think you can make
>proper access rights if you don't adress the issue of steady referential
>(care coordination - or groupware) vs moving referential (continuity of
>care - every episod of care for every care team).
>
>Philippe
>
>
> >Hi Thomas,
> >
> >Thomas Beale wrote:
> >
> >
> >/snip/
> >
> > > So. What do we know?
> > > - role-based access control is required. To make it work properly in a
> > > shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> > > nursing care, social workers etc etc) then the roles need to be defined
> > > congruently. I seem to remember some Canadian project coming to the
> > > conclusion that really the roles need to be defined the same across the
> > > entire (national) health care system. I think this is both correct and a
> > > the same time unrealistic.
> >
> >With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
> >correct. (Pragmatism R Us ;-) )
> >
> >I'd like to offer food for thought. The fundamental assumption at work here
> >seems to be that care givers will access the same system, thus driving the
> >need for all users of the system to be assigned roles that are defined
> >congruently. Let's consider an alternative model.
> >
> >When I travel from the U.S. to the U.K., I (the physical being) move from
> >one socio-cultural-legal model to another. That does

openEHR security

[Bernie Cohen]

Most of the serious issues in EHR security are essentially ethical, not
legal, in nature.
When the NHS first introduced a nationwide Healthcare Network, the BMA
Ethics Committee advised all practitioners to put NO patient-related data
on it because it had not been PROVED that the network's security mechanims
could guarantee non-violation of the ethical principles governing access
to such data (see Anderson, R. A., Security in Clinical Information
Systems, BMA, 1996).
Of course, such a proof cannot be performed, not only because the
security mechanisms are not formally defined, but because the ethical 
principles themselves are not formally stated.
In an attempt to overcome this obvious impasse, I prepared a tentative
formal definition of some of the dozen or so governing ethical principles
stated in the BMA document. Unfortunately, this met with a deafening
silence from both sides of the argument.
I suspect that something of this nature is still needed and that the need
for it cannot be admitted by any of the stakeholders. The latest round of
discussions of this group merely confirm that suspicion.
Those who are interested in this line of enquiry may care to read my
seven-year-old paper at http://www.soi.city.ac.uk/~bernie/hsp.pdf


On Mon, 28 Apr 2003, Bill Walton wrote:

> Date: Mon, 28 Apr 2003 16:33:06 -0500
> From: Bill Walton 
> To: openehr-technical at openehr.org
> Subject: Re: openEHR security
> 
> Hi Thomas,
> 
> Thomas Beale wrote:
> 
> 
> /snip/
> 
> > So. What do we know?
> > - role-based access control is required. To make it work properly in a
> > shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> > nursing care, social workers etc etc) then the roles need to be defined
> > congruently. I seem to remember some Canadian project coming to the
> > conclusion that really the roles need to be defined the same across the
> > entire (national) health care system. I think this is both correct and a
> > the same time unrealistic.
> 
> With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
> correct.  (Pragmatism R Us ;-) )
> 
> I'd like to offer food for thought.  The fundamental assumption at work here
> seems to be that care givers will access the same system, thus driving the
> need for all users of the system to be assigned roles that are defined
> congruently.  Let's consider an alternative model.
> 
> When I travel from the U.S. to the U.K., I (the physical being) move from
> one socio-cultural-legal model to another.  That does not change who / what
> I am, but it does change my behavior because I operate under a different set
> of norms and mores in the new environment.  I accept new forms of
> interaction and find that familiar forms are no longer available.
> 
> Why should it be any different for the information about me than it is for
> me?
> 
> If we work from a perspective that posits that health information will move
> from system to system and be used / modified based on the rule sets in place
> within the various systems, does that make the problem more amenable to
> solution?
> 
> > I think we will be able to find ways of
> > having diversely defined roles without every health care facility having
> > incompatible definitions of "consultant", "treating physician" etc.
> > Bernd's work on this area is pretty detailed.
> 
> I thank Bernd for opening my eyes to what should have been obvious to me at
> a much earlier stage.  The security problem with EHR systems is
> fundamentally the same problem faced in OLAP databases.  Or perhaps I should
> say that it's the OLAP security problem with a twist.  At least OLAP
> databases are typically confined to one environment / business.  It's clear
> that the EHR problem is more difficult in that EHR's must, IMO, be capable
> of moving between environments.  Perhaps, by requiring a more generalized
> solution, the EHR problem will actually be easier to solve.
> 
> I don't know if you've checked out Mike Mair's paper but it implicitly poses
> a very interesting question.  "Is a biologically-based security model
> fundamentally better aligned with the needs of an information system about
> biological entities than alternative models?"  I'm hopeful the list will
> have some comments on Mike's paper.  I think the question is worth some
> thought / discussion.
> 
> /snip/
> 
> Best regards,
> Bill
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
> 


Prof Bernard Cohen, Dept of Comp Sc, City Univ, Northampton Sq. 
London EC1V 0HB   tel: ++44-20-7040-8448 fax: ++44-171-477-8587 
b.cohen at city.ac.uk  WWW: http://www.soi.city.ac.uk/~bernie
"Patterns lively of the things rehearsed" 

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

normalizing access vs. normalizing denial (was openEHR security)

[Bernd Blobel]

Thomas Clark wrote:
> Hi Bill,
> 
> Suggested roles:
> 
> FAMILY
> Class #1:
> -immediate
> Class #2:
> -legal next of kin
> Class #3:
> -parents
> -siblings
> 
> EMERGENCY:
> -first responders
> -transport
> -emergency room
> -life support
> 
> NON-MEDICAL CAREGIVERS:
> -Patient identified
> outpatient services
> 
> LEGAL
> -Patient attorney
> -health services
> -social services
> -police services
> -fire services
> -public health services
> 
> MEDICAL
> -family physician
> -substitute family physician
> -family medical designee
> -nursing services
> 
> The Patient can supply specific persons and organizations. However, some
> should be identified and granted access based upon their function, e.g.,
> health and social services.
> 
> -Thomas Clark
> 
> - Original Message -----
> From: "Bill Walton" 
> To: 
> Sent: Monday, April 28, 2003 12:15 PM
> Subject: normalizing access vs. normalizing denial (was openEHR security)
> 
> 
> 
>>This is a multi-part message in MIME format.
>>
>>--=_NextPart_000_0183_01C30D90.8FC88240
>>Xontent-Type: text/plain;
>>charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>HI Sam,
>>=20
>>
>>>>BW:  Related to all of the above, it seems like there are probably a =
>>
>>number of circumstances that would require that the control of the =
>>Access Control list itself be capable of being over-ridden or delegated. =
>> It looks to me like, as currently defined, the only roles that could =
>>grant access would be the patient and Next of Kin roles.  But assume, =
>>for example, that a patient is hospitalized, needs a test performed that =
>>can't be performed in the facility, and has designated a Next of Kin =
>>that's not present.  Perhaps it's just a difference between our systems, =
>>but in the U.S. I can imagine a need to delegate the right to change the =
>>Access Control list without delegating some of the other decisions =
>>(e.g., "pull the plug") that are associated with Next of Kin here.  =
>>Again, as long as the Audit Trails are in place it seems that fears of =
>>inappropriate access might be effectively balanced against the needs of =
>>providers re: access to the records for the purpose of delivering the =
>>appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.
>>=20
>>
>>>SH: The whole approach is to normalise access rather than normalise =
>>
>>denial - so a transfer of a record (or part there-of) would almost =
>>always mean that the person giving permission for the transfer was happy =
>>with the hospital policy - as advertised under these 6 roles. The access =
>>control list would have to be changed by an authorative person when =
>>parts of the record required for ongoing care had been limited a =
>>clinician who had left. Logging these things is far more important than =
>>being highly restrictive - the latter being possible if the patient =
>>wants this.
>>
>>It looks to me like maybe there needs to be rights to change the Access =
>>Control List associated with each of the roles currently defined.  Or =
>>maybe there already are and I've just misunderstood.  I completely agree =
>>that logging is far more important than being restrictive.  We certainly =
>>can't hamper the timely provision of care.
>>
>>Thanks,
>>Bill
>>=20
>>
>>
>>--=_NextPart_000_0183_01C30D90.8FC88240
>>Xontent-Type: text/html;
>>charset="iso-8859-1"
>>Content-Transfer-Encoding: quoted-printable
>>
>>
>>
>>>http-equiv=3DContent-Type>
>>
>>
>>
>>
>>HI =
>>Sam,
>> > > BW:  Related to =
>>all of the=20
>>above, it seems like there are probably a number of circumstances that =
>>would=20
>>require that the control of the Access Control list itself be capable of =
>>being=20
>>over-ridden or delegated.  It looks to me like, as currently =
>>defined, the=20
>>only roles that could grant access would be the patient and Next of Kin=20
>>roles.  But assume, for example, that a patient is hospitalized, =
>>needs a=20
>>test performed that can't be performed in the facility, and has =
>>designated a=20
>>Next of Kin that's not present.  Perhaps it's just a difference =
>>between our=20
>>systems, but in the U.S. I can imagine a need to delegate the right to =
>>change=20
>>the Access Control list without deleg

openEHR security

[Bernd Blobel]

Bill Walton wrote:
> Hi Thomas,
> 
> Thomas Beale wrote:
> 
> 
> /snip/
> 
> 
>>So. What do we know?
>>- role-based access control is required. To make it work properly in a
>>shared care community context (e.g. a hospital, 50 GPs, aged care homes,
>>nursing care, social workers etc etc) then the roles need to be defined
>>congruently. I seem to remember some Canadian project coming to the
>>conclusion that really the roles need to be defined the same across the
>>entire (national) health care system. I think this is both correct and a
>>the same time unrealistic.
> 
> 
> With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
> correct.  (Pragmatism R Us ;-) )
> 
> I'd like to offer food for thought.  The fundamental assumption at work here
> seems to be that care givers will access the same system, thus driving the
> need for all users of the system to be assigned roles that are defined
> congruently.  Let's consider an alternative model.
> 
> When I travel from the U.S. to the U.K., I (the physical being) move from
> one socio-cultural-legal model to another.  That does not change who / what
> I am, but it does change my behavior because I operate under a different set
> of norms and mores in the new environment.  I accept new forms of
> interaction and find that familiar forms are no longer available.
> 
> Why should it be any different for the information about me than it is for
> me?
> 
> If we work from a perspective that posits that health information will move
> from system to system and be used / modified based on the rule sets in place
> within the various systems, does that make the problem more amenable to
> solution?
> 
> 
>>I think we will be able to find ways of
>>having diversely defined roles without every health care facility having
>>incompatible definitions of "consultant", "treating physician" etc.
>>Bernd's work on this area is pretty detailed.
> 
> 
> I thank Bernd for opening my eyes to what should have been obvious to me at
> a much earlier stage.  The security problem with EHR systems is
> fundamentally the same problem faced in OLAP databases.  Or perhaps I should
> say that it's the OLAP security problem with a twist.  At least OLAP
> databases are typically confined to one environment / business.  It's clear
> that the EHR problem is more difficult in that EHR's must, IMO, be capable
> of moving between environments.  Perhaps, by requiring a more generalized
> solution, the EHR problem will actually be easier to solve.
> 
> I don't know if you've checked out Mike Mair's paper but it implicitly poses
> a very interesting question.  "Is a biologically-based security model
> fundamentally better aligned with the needs of an information system about
> biological entities than alternative models?"  I'm hopeful the list will
> have some comments on Mike's paper.  I think the question is worth some
> thought / discussion.
> 
> /snip/
> 
> Best regards,
> Bill
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
> 
> 
Dear friends,

A crucial challenge for EHR security is the formalisation of policies 
and their rule-based but also interactive negotiation. This reflects 
some of the issues mentioned.
Formal policy modelling is a CEN workitem over many years. Meanwhile 
(due to time constraints by other businesses also this project takes 
years), the issues mentioned are also content of a common 3 part CEN and 
ISO standard on Privilege Management and Access Control Management.
Formal policy modelling and policy negotiation are essential aspect of 
the specification.

Kindest regards

Bernd

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Philippe AMELINE]

Hi,

I must confess I didn't read very carefully each message on this thread ; 
however, I think that I may contribute by explaining the direction we are 
currently following.

First I think we must distinguish between care coordination (inside an 
openEHR node) and continuity of care.
Continuity of care means that you manage to index every  contributions for 
a single patient (these contributions can be openEHR contributions or other 
systems contribution, or even data here and there).

The acces rules must be very different in both cases since :
- inside a node (care coordination) the system belongs to the team and/or 
the careplace (say it is a domain, maybe a meta-domain) and see patients 
passing through (from in to out).
- a continuity of care system necesseraly belongs to the patient (when you 
consider a wide period of time, it is the only stable user) and see medical 
teams passing through.

To adress this change of point of view (from a steady referential to a 
moving referential), we are building a system with the following rules :
- the continuity of care system is an index of existing contributions and 
is granted access rights to the nodes
- inside the continuity of care system, people that may access data are 
given a position inside the patient "health team" : the position depends on 
the people "job" (doctor, other health professional, family, social worker) 
and depends on his "distance" from the patient (usual care giver vs unusual 
one).

Hence the access rights to the contribution are determined for each 
possible position and depends on the current role inside the personal halth 
team at the very moment.

You can like the way we do it or not, however, I don't think you can make 
proper access rights if you don't adress the issue of steady referential 
(care coordination - or groupware) vs moving referential (continuity of 
care - every episod of care for every care team).

Philippe


>Hi Thomas,
>
>Thomas Beale wrote:
>
>
>/snip/
>
> > So. What do we know?
> > - role-based access control is required. To make it work properly in a
> > shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> > nursing care, social workers etc etc) then the roles need to be defined
> > congruently. I seem to remember some Canadian project coming to the
> > conclusion that really the roles need to be defined the same across the
> > entire (national) health care system. I think this is both correct and a
> > the same time unrealistic.
>
>With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
>correct.  (Pragmatism R Us ;-) )
>
>I'd like to offer food for thought.  The fundamental assumption at work here
>seems to be that care givers will access the same system, thus driving the
>need for all users of the system to be assigned roles that are defined
>congruently.  Let's consider an alternative model.
>
>When I travel from the U.S. to the U.K., I (the physical being) move from
>one socio-cultural-legal model to another.  That does not change who / what
>I am, but it does change my behavior because I operate under a different set
>of norms and mores in the new environment.  I accept new forms of
>interaction and find that familiar forms are no longer available.
>
>Why should it be any different for the information about me than it is for
>me?
>
>If we work from a perspective that posits that health information will move
>from system to system and be used / modified based on the rule sets in place
>within the various systems, does that make the problem more amenable to
>solution?
>
> > I think we will be able to find ways of
> > having diversely defined roles without every health care facility having
> > incompatible definitions of "consultant", "treating physician" etc.
> > Bernd's work on this area is pretty detailed.
>
>I thank Bernd for opening my eyes to what should have been obvious to me at
>a much earlier stage.  The security problem with EHR systems is
>fundamentally the same problem faced in OLAP databases.  Or perhaps I should
>say that it's the OLAP security problem with a twist.  At least OLAP
>databases are typically confined to one environment / business.  It's clear
>that the EHR problem is more difficult in that EHR's must, IMO, be capable
>of moving between environments.  Perhaps, by requiring a more generalized
>solution, the EHR problem will actually be easier to solve.
>
>I don't know if you've checked out Mike Mair's paper but it implicitly poses
>a very interesting question.  "Is a biologically-based security model
>fundamentally better aligned with the needs of an information system about
>biological entities than alternative models?"  I'm hopeful the list will
>have some comments on Mike's paper.  I think the question is worth some
>thought / discussion.
>
>/snip/
>
>Best regards,
>Bill
>
>-
>If you have any questions about using this list,
>please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please sen

openEHR security

[Paul Juarez]

Philippe,

The approach you have identified makes a lot of sense to me and goes a
long ways toward clarifying "ownership" of the record.  I do think it
would be helpful to develop standard taxonomy for distinguishing the
two: EMR signifying within a closed health care system, and EHR
signifying the continuity of care record which is the property of the
patient.  It seems to me that if this distinction is not made,
"ownership" is going to boil down to issues like "intellectual
property."   The way I see it, ownership and access are two, separate,
albeit, overlappying issues.  Did I hear somebody mention Napster?

>>> Philippe AMELINE  04/29/03
12:54AM >>> 
Hi, 

I must confess I didn't read very carefully each message on this thread
; 
however, I think that I may contribute by explaining the direction we
are 
currently following. 

First I think we must distinguish between care coordination (inside an 
openEHR node) and continuity of care. 
Continuity of care means that you manage to index every contributions
for 
a single patient (these contributions can be openEHR contributions or
other 
systems contribution, or even data here and there). 

The acces rules must be very different in both cases since : 
- inside a node (care coordination) the system belongs to the team
and/or 
the careplace (say it is a domain, maybe a meta-domain) and see patients

passing through (from in to out). 
- a continuity of care system necesseraly belongs to the patient (when
you 
consider a wide period of time, it is the only stable user) and see
medical 
teams passing through. 

To adress this change of point of view (from a steady referential to a 
moving referential), we are building a system with the following rules :

- the continuity of care system is an index of existing contributions
and 
is granted access rights to the nodes 
- inside the continuity of care system, people that may access data are 
given a position inside the patient "health team" : the position depends
on 
the people "job" (doctor, other health professional, family, social
worker) 
and depends on his "distance" from the patient (usual care giver vs
unusual 
one). 

Hence the access rights to the contribution are determined for each 
possible position and depends on the current role inside the personal
halth 
team at the very moment. 

You can like the way we do it or not, however, I don't think you can
make 
proper access rights if you don't adress the issue of steady referential

(care coordination - or groupware) vs moving referential (continuity of 
care - every episod of care for every care team). 

Philippe 


>Hi Thomas, 
> 
>Thomas Beale wrote: 
> 
> 
>/snip/ 
> 
> > So. What do we know? 
> > - role-based access control is required. To make it work properly in
a 
> > shared care community context (e.g. a hospital, 50 GPs, aged care
homes, 
> > nursing care, social workers etc etc) then the roles need to be
defined 
> > congruently. I seem to remember some Canadian project coming to the 
> > conclusion that really the roles need to be defined the same across
the 
> > entire (national) health care system. I think this is both correct
and a 
> > the same time unrealistic. 
> 
>With all due respect, Thomas, it it's unrealistic then, IMO, it can't
be 
>correct. (Pragmatism R Us ;-) ) 
> 
>I'd like to offer food for thought. The fundamental assumption at work
here 
>seems to be that care givers will access the same system, thus driving
the 
>need for all users of the system to be assigned roles that are defined 
>congruently. Let's consider an alternative model. 
> 
>When I travel from the U.S. to the U.K., I (the physical being) move
from 
>one socio-cultural-legal model to another. That does not change who /
what 
>I am, but it does change my behavior because I operate under a
different set 
>of norms and mores in the new environment. I accept new forms of 
>interaction and find that familiar forms are no longer available. 
> 
>Why should it be any different for the information about me than it is
for 
>me? 
> 
>If we work from a perspective that posits that health information will
move 
>from system to system and be used / modified based on the rule sets in
place 
>within the various systems, does that make the problem more amenable to

>solution? 
> 
> > I think we will be able to find ways of 
> > having diversely defined roles without every health care facility
having 
> > incompatible definitions of "consultant", "treating physician" etc. 
> > Bernd's work on this area is pretty detailed. 
> 
>I thank Bernd for opening my eyes to what should have been obvious to
me at 
>a much earlier stage. The security problem with EHR systems is 
>fundamentally the same problem faced in OLAP databases. Or perhaps I
should 
>say that it's the OLAP security problem with a twist. At least OLAP 
>databases are typically confined to one environment / business. It's
clear 
>that the EHR problem is more difficult in that EHR's must, IMO, be
capable 
>of moving betwe

normalizing access vs. normalizing denial (was openEHR security)

[Thomas Clark]

Hi Bill,

Suggested roles:

FAMILY
Class #1:
-immediate
Class #2:
-legal next of kin
Class #3:
-parents
-siblings

EMERGENCY:
-first responders
-transport
-emergency room
-life support

NON-MEDICAL CAREGIVERS:
-Patient identified
outpatient services

LEGAL
-Patient attorney
-health services
-social services
-police services
-fire services
-public health services

MEDICAL
-family physician
-substitute family physician
-family medical designee
-nursing services

The Patient can supply specific persons and organizations. However, some
should be identified and granted access based upon their function, e.g.,
health and social services.

-Thomas Clark

- Original Message -
From: "Bill Walton" 
To: 
Sent: Monday, April 28, 2003 12:15 PM
Subject: normalizing access vs. normalizing denial (was openEHR security)


> This is a multi-part message in MIME format.
>
> --=_NextPart_000_0183_01C30D90.8FC88240
> Xontent-Type: text/plain;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> HI Sam,
> =20
> > > BW:  Related to all of the above, it seems like there are probably a =
> number of circumstances that would require that the control of the =
> Access Control list itself be capable of being over-ridden or delegated. =
>  It looks to me like, as currently defined, the only roles that could =
> grant access would be the patient and Next of Kin roles.  But assume, =
> for example, that a patient is hospitalized, needs a test performed that =
> can't be performed in the facility, and has designated a Next of Kin =
> that's not present.  Perhaps it's just a difference between our systems, =
> but in the U.S. I can imagine a need to delegate the right to change the =
> Access Control list without delegating some of the other decisions =
> (e.g., "pull the plug") that are associated with Next of Kin here.  =
> Again, as long as the Audit Trails are in place it seems that fears of =
> inappropriate access might be effectively balanced against the needs of =
> providers re: access to the records for the purpose of delivering the =
> appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.
> =20
> > SH: The whole approach is to normalise access rather than normalise =
> denial - so a transfer of a record (or part there-of) would almost =
> always mean that the person giving permission for the transfer was happy =
> with the hospital policy - as advertised under these 6 roles. The access =
> control list would have to be changed by an authorative person when =
> parts of the record required for ongoing care had been limited a =
> clinician who had left. Logging these things is far more important than =
> being highly restrictive - the latter being possible if the patient =
> wants this.
>
> It looks to me like maybe there needs to be rights to change the Access =
> Control List associated with each of the roles currently defined.  Or =
> maybe there already are and I've just misunderstood.  I completely agree =
> that logging is far more important than being restrictive.  We certainly =
> can't hamper the timely provision of care.
>
> Thanks,
> Bill
> =20
>
>
> --=_NextPart_000_0183_01C30D90.8FC88240
> Xontent-Type: text/html;
> charset="iso-8859-1"
> Content-Transfer-Encoding: quoted-printable
>
> 
> 
>  http-equiv=3DContent-Type>
> 
> 
> 
> 
> HI =
> Sam,
>  > > BW:  Related to =
> all of the=20
> above, it seems like there are probably a number of circumstances that =
> would=20
> require that the control of the Access Control list itself be capable of =
> being=20
> over-ridden or delegated.  It looks to me like, as currently =
> defined, the=20
> only roles that could grant access would be the patient and Next of Kin=20
> roles.  But assume, for example, that a patient is hospitalized, =
> needs a=20
> test performed that can't be performed in the facility, and has =
> designated a=20
> Next of Kin that's not present.  Perhaps it's just a difference =
> between our=20
> systems, but in the U.S. I can imagine a need to delegate the right to =
> change=20
> the Access Control list without delegating some of the other decisions =
> (e.g.,=20
> "pull the plug") that are associated with Next of Kin here.  Again, =
> as long=20
> as the Audit Trails are in place it seems that fears of inappropriate =
> access=20
> might be effectively balanced against the needs of providers re: access =
> to the=20
> records for the purpose of delivering the appropriate care.  Or =
> perhaps I'm=20
> misunderstanding the Next of Kin role. > SH: The whole =
> approach=20
> is to normalise access rather than no

openEHR security

[Bill Walton]

Hi Thomas,

Thomas Beale wrote:


/snip/

> So. What do we know?
> - role-based access control is required. To make it work properly in a
> shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> nursing care, social workers etc etc) then the roles need to be defined
> congruently. I seem to remember some Canadian project coming to the
> conclusion that really the roles need to be defined the same across the
> entire (national) health care system. I think this is both correct and a
> the same time unrealistic.

With all due respect, Thomas, it it's unrealistic then, IMO, it can't be
correct.  (Pragmatism R Us ;-) )

I'd like to offer food for thought.  The fundamental assumption at work here
seems to be that care givers will access the same system, thus driving the
need for all users of the system to be assigned roles that are defined
congruently.  Let's consider an alternative model.

When I travel from the U.S. to the U.K., I (the physical being) move from
one socio-cultural-legal model to another.  That does not change who / what
I am, but it does change my behavior because I operate under a different set
of norms and mores in the new environment.  I accept new forms of
interaction and find that familiar forms are no longer available.

Why should it be any different for the information about me than it is for
me?

If we work from a perspective that posits that health information will move
from system to system and be used / modified based on the rule sets in place
within the various systems, does that make the problem more amenable to
solution?

> I think we will be able to find ways of
> having diversely defined roles without every health care facility having
> incompatible definitions of "consultant", "treating physician" etc.
> Bernd's work on this area is pretty detailed.

I thank Bernd for opening my eyes to what should have been obvious to me at
a much earlier stage.  The security problem with EHR systems is
fundamentally the same problem faced in OLAP databases.  Or perhaps I should
say that it's the OLAP security problem with a twist.  At least OLAP
databases are typically confined to one environment / business.  It's clear
that the EHR problem is more difficult in that EHR's must, IMO, be capable
of moving between environments.  Perhaps, by requiring a more generalized
solution, the EHR problem will actually be easier to solve.

I don't know if you've checked out Mike Mair's paper but it implicitly poses
a very interesting question.  "Is a biologically-based security model
fundamentally better aligned with the needs of an information system about
biological entities than alternative models?"  I'm hopeful the list will
have some comments on Mike's paper.  I think the question is worth some
thought / discussion.

/snip/

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

normalizing access vs. normalizing denial (was openEHR security)

[Bill Walton]

HI Sam,
 
> > BW:  Related to all of the above, it seems like there are probably a number 
> > of circumstances that would require that the control of the Access Control 
> > list itself be capable of being over-ridden or delegated.  It looks to me 
> > like, as currently defined, the only roles that could grant access would be 
> > the patient and Next of Kin roles.  But assume, for example, that a patient 
> > is hospitalized, needs a test performed that can't be performed in the 
> > facility, and has designated a Next of Kin that's not present.  Perhaps 
> > it's just a difference between our systems, but in the U.S. I can imagine a 
> > need to delegate the right to change the Access Control list without 
> > delegating some of the other decisions (e.g., "pull the plug") that are 
> > associated with Next of Kin here.  Again, as long as the Audit Trails are 
> > in place it seems that fears of inappropriate access might be effectively 
> > balanced against the needs of providers re: access to the records for the 
> > purpose of delivering the appropriate care.  Or perhaps I'm 
> > misunderstanding the Next of Kin role.
 
> SH: The whole approach is to normalise access rather than normalise denial - 
> so a transfer of a record (or part there-of) would almost always mean that 
> the person giving permission for the transfer was happy with the hospital 
> policy - as advertised under these 6 roles. The access control list would 
> have to be changed by an authorative person when parts of the record required 
> for ongoing care had been limited a clinician who had left. Logging these 
> things is far more important than being highly restrictive - the latter being 
> possible if the patient wants this.

It looks to me like maybe there needs to be rights to change the Access Control 
List associated with each of the roles currently defined.  Or maybe there 
already are and I've just misunderstood.  I completely agree that logging is 
far more important than being restrictive.  We certainly can't hamper the 
timely provision of care.

Thanks,
Bill
 

-- next part --
An HTML attachment was scrubbed...
URL: 

Access controls and Audit trails (was Re: openEHR security)

[Bill Walton]

Hi Sam,

Sam Heard wrote:

> > BW: First, and perhaps you consider this a seperate issue that's out of 
> > scope for Access Control, but what about Audit Trails? 
 
> SH: openEHR has full version control of all components so we have this 
> thoroughly covered. If you are talking about auditing what is viewed, our 
> research in the early 90s suggested that clinicians were totally against this 
> - and it is very difficult to be sure what is seen unless refresh times, 
> screen size and scrolling are all monitored - the idea is terrifying!

I'm talking here about logging system activity at run-time, not version 
control.  Also, I note that there seems to be concern about the phrase Audit 
Trails.  I agree that it's way out of scope to try to log exactly what's seen.  
What's accessed (at the file or field level) is another question.  I'll have 
more to say about this in another email in response to / support of Thomas 
Clark's comments.
 
> > BW: In addition to the choices / decisions you summarize on Page 3, I 
> > believe there's a key question the system needs to be able to answer: "Who 
> > has had what access to my records?" 
 
> SH: We do believe that it is essential to log access - but not to what unless 
> there is an over-ride on the constraints set by the patient. This could 
> result in an automatic email to the patient in the future. But not policing 
> what the clinician who has access looks at.

Hmmm  I'm guessing this may be a difference at the national level in how 
the medical delivery systems work.  I'll have more to say about this in the 
email response anticipated by the above, but here are some of the new 
requirements we having to come to grips with here in the U.S  Under HIPAA, 
the patient has the right to request an accounting of disclosures and the 
physician must furnish that accounting.  Moreover, HIPAA requires that 
disclosures of protected health information, even to others within the 
physician's office, be kept to the minimum needed by the requestor to fulfill 
their job duties.  In addition, the patient has a right to request that 
specific information be kept confidential.  Along with the Privacy and Security 
standards, HIPAA contains enforcement provisions and the commentary has been 
very explicit that sanctions are an essential component of any security scheme. 
 It appears to me that, here in the U.S., we have to anticipate maintaining a 
log of accesses to allow a reviewer to determine whether or not HIPAA's 
requirements have been adhered to.
 
> > BW:  To answer this question it looks to me like the system needs to 
> > maintain two types of information: 1) a history of the changes to the 
> > Access Control List,  
 
> SH: In openEHR this is versioned like anything else...

Excellent.  So past Access Control Lists are kept and could be reused?  This 
will become important for us (in the U.S.) because the fact that a physician 
had access to a patient's full medical history in the past does not mean they 
continue to have that level of access.
 
> > BW:  and 2) a history of accesses to the EHR itself. 
 
> SH: I agree as long as we are talking access - that is logged - and 
> over-rides and who authorised them and for what reason ( perhaps unconscious 
> in Emergency is appropriate. Patients could set the over-ride capability to 
> be turned off.

More on this in other emails, but I think there's more to it than over-rides.
 
> > BW:  Further, it looks like the EHR access history should include reads as 
> > well as writes.  That way, the trail would lead to the providers that have, 
> > with permission, made copies of the EHR within their own systems. 
 
> SH: True - it will only be able to be stored as an HTML rendition unless 
> there is an extract in openEHR - but you are right - this could be saved - 
> this is difficult to police. 

Oops!  I'd assumed there would be extracts in openEHR.  HIPAA specifies, under 
the Transaction Rules that go into effect in October of this year, a number of 
EDI transactions between systems that would require this.  HTML will not be 
sufficient.

> > BW:  This is tied to the first question I think, but how does the system 
> > deal with the needs of Consulting Physicians and Researchers who are not 
> > going to provide care, but may need read access to the full record?  If I 
> > read this correctly, the mechanism controls what information can be 
> > accessed, but not the type of access permitted (i.e., read vs. write). 
 
> SH: The fact is, unlike usual systems, there will be  more restraints on 
> reads than writes. 

I'm taking this to mean that there will be configurable permissions on type of 
access.  Yes?

> SH: Research access will be via the kernel with an approved program unless it 
> is one-to-one reading of records when the patient's consent is required 
> anyway.

Hmmm  Again, perhaps a difference at the national level.  Research here is 
the U.S. typically requires extracted data to be transferred f

openEHR security; Directed to Thomas Beale

[Thomas Beale]

Thomas Clark wrote:

>Hi Karsten,
>
>NEED TO KNOW is a 'working label' that has a meaning dependent upon the
>particular circumstance. A Healthcare Practitioner selected to perform foot
>surgery has a NEED TO KNOW pertinent information about the patient's feet,
>especially the one the surgery is to be performed on. This would include any
>condition that could impact the surgery and recovery, e.g., abnormal blood
>pressure.
>
would simply the term "relevance" be better than "need to know"?

- thomas beale



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

Thomas

> NEED TO KNOW is a 'working label' [...]
I see. That, of course, changes the situation. I thought you
were referring to the well-established paradigm (well, the
only well-established paradigm known to me as an ESL speaker).
Reason I thought so was that you capitalized the phrase.

Regards,
Karsten Hilbert
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

NEED TO KNOW is perhaps an unfortunate label that may have been coined by
military security, a unique environment. It seems to have taken root because
participants in that organization structure rarely ask questions or engage
in "pertinent" discussions or intellectual debates. Such is not the case in
Healthcare, however some label is required to discuss and explain filtering
and blocking processes (not suggesting either as a label).

NEED TO KNOW as a label does imply that a NEED has to be established prior
to granting access. A bridging label between the Healthcare and Security
communities would be nice.

-Thomas Clark

- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Monday, April 28, 2003 2:37 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> Thomas
>
> > NEED TO KNOW is a 'working label' [...]
> I see. That, of course, changes the situation. I thought you
> were referring to the well-established paradigm (well, the
> only well-established paradigm known to me as an ESL speaker).
> Reason I thought so was that you capitalized the phrase.
>
> Regards,
> Karsten Hilbert
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

Fw: openEHR security; Directed to Thomas Beale

[Thomas Clark]

A prior comment.

-Thomas Clark

- Original Message -
From: "Thomas Beale" 
To: "Thomas Clark" 
Sent: Monday, April 28, 2003 3:26 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> [Thomas - you might want to send this reply to the list]
>
> Thomas Clark wrote:
>
> >Hi Thomas,
> >
> >"relevance" is understandable as is "germane" (a bit stronger). Both
imply
> >judgments that may occur prior to and/or after access to information,
e.g.,
> >granting access because something might be "relevant" or "germane" and
later
> >discovering that the information was or was not "relevant" or "germane".
> >This would be categorized as "a fishing trip".
> >
> >a priori information is or is not "relevant" or "germane". Security
systems
> >usually require such a classification before access is granted. Once the
> >information is accessed any protection provided by a Security system is
> >substantially diminished.
> >
> >A patient in a hospital should not be required to provide access to all
> >members of the staff (including IT) who may or may not decide beforehand
to
> >build a case for "relevance".
> >
> >Relevant to what? If a member of the staff has no direct connection with
my
> >care then can there be "relevance"? Is anything they are doing or wish to
do
> >"germane"?
> >
> >Speaking for myself, if the requestor is not directly connected with my
care
> >then they can bugger-off!
> >
> >Phrased differently, they do not have a NEED TO KNOW. In advance of my
stay
> >in the hospital, etc., if the requestors cannot be identified with
> >sufficient clarity then perhaps I am in the wrong place.
> >
> >A different viewpoint is that of a security auditor. An auditor would
> >certainly object to access based upon foundations centered on "relevance"
> >that have not been sufficiently defined beforehand and a determination of
> >NEED TO KNOW made and implemented.
> >
> >Basically, one cannot afford to be found to have made the records less
> >secure than they were when received. There is a legal side to security
and
> >one should strive to maintain security while the records are in your
> >possession.
> >
> >Try "relevance" | "germane" -> NEED TO KNOW -> policies and procedures
> >
> >-Thomas Clark
> >
> >
> >
> >- Original Message -
> >From: "Thomas Beale" 
> >To: "Thomas Clark" 
> >Cc: "Karsten Hilbert" ;
> >
> >Sent: Sunday, April 27, 2003 8:12 PM
> >Subject: Re: openEHR security; Directed to Thomas Beale
> >
> >
> >
> >
> >>Thomas Clark wrote:
> >>
> >>
> >>
> >>>Hi Karsten,
> >>>
> >>>NEED TO KNOW is a 'working label' that has a meaning dependent upon the
> >>>particular circumstance. A Healthcare Practitioner selected to perform
> >>>
> >>>
> >foot
> >
> >
> >>>surgery has a NEED TO KNOW pertinent information about the patient's
> >>>
> >>>
> >feet,
> >
> >
> >>>especially the one the surgery is to be performed on. This would
include
> >>>
> >>>
> >any
> >
> >
> >>>condition that could impact the surgery and recovery, e.g., abnormal
> >>>
> >>>
> >blood
> >
> >
> >>>pressure.
> >>>
> >>>
> >>>
> >>would simply the term "relevance" be better than "need to know"?
> >>
> >>- thomas beale
> >>
> >>
> >>
> >>-
> >>If you have any questions about using this list,
> >>please send a message to d.lloyd at openehr.org
> >>
> >>
> >
> >
> >
> >
> >
>
> --
> ..
> Deep Thought Informatics Pty Ltd
> mailto:thomasXXX at YYYdeepthoughtZZZ.WWWcom.AAAau (remove all caps)
>
> openEHR - http //www.openEHR.org
> Archetypes - http //www.deepthought.com.au/it/archetypes.html
> Community Informatics - http
//www.deepthought.com.au/ci/rii/Output/mainTOC.html
> ..
>
>
>

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Mike Mair]

Dear Bill,

I gave a paper on 'the immunological model of access' control at the HL7 CDA
conference last year in Berlin. It is to be found at
http://www.hl7.de/cda2002/progoverz.html , the last paper. The power point
version does not load well from this site, and
is found at my own web page at http://www.eyetech.co.nz/?page=ehr.inc (but
it takes a while to load). Interestingly, a presentation from Finland at the
same conference had almost the same idea, although the access control aspect
was not quite the same. The proposed mechanism, based on a concept from
immunology, would also work for a simplified version of the Openehr
architecture.  I think the model has the potential to facilitate a global
ehr and
access system.

Regards

Mike Mair

- Original Message -
From: "Bill Walton" 
To: 
Sent: Friday, April 25, 2003 8:09 AM
Subject: Re: openEHR security


> Bernd Blobel wrote:
>
> > Dear Bill, dear Sam
> >
> > Meanwhile, security constraint modelling succeeds. This concerns policy
> > modelling, policy negotiation, privilege management, access control,
> > object security categorisation. Unfortunately, the preparation of EU 6th
> > Framework proposals was so time comsuming that I had no time to continue
> > and to distribute the results. The modelling is also part of the EU
> > modEHRa proposal OIA (Thomas and Sam) will be involved in.
>
> Bernd,
>
> I'd not previously studied security constraint modeling but a quick Google
> put me onto some interesting research.  If you have any links to share,
I'd
> appreciate it.  Thanks for the new (to me) tack.
>
> Best regards,
> Bill
>
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org
>
>


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Beale]

 role be compared to the 
access group definitions & sensitivy markers on the relevant EHR data 
and Access Control service setting; the checkout (like a pure read) 
either proceeds or not.

The biggest issue in my mind is the secure control of the information 
_during the checkout period_, and also post check-out. In a CM system, 
there is the concept of a "user workspace" which is where information is 
checked out  into. In EHR-land, this needs to be a _secure workspace_ - 
one which is a totally controlled part of the system. The challenge is 
what to do with EHR information which needs to be checked out for a long 
time (longer than a session), made persistent in the workspace, etc etc. 
I don't think this is insurmountable, but it does need to be part of the 
design.

>SECURITY REVIEWS
>This is a big one. In a potentially global system security can't be
>standardized. The systems and networks are usually different as is the user
>community. In this regard, security must be adaptable and reviews tailored
>to the local environment.
>
so what is the abstract model for this - is one possible - and what do 
local implementors have to do?

>ACCESS
>Role-based access is central. However, it must be limited, e.g., by the
>Patient. There should be other models as well. For instance, prior to
>surgery I would like to DEDICATE ACCESS to a practitioner who in turn
>IDENTIFIES members of a TEAM and ASSOCIATES (including organizations)
>involved in a current procedure. It would a time- and function-limited
>dedication.
>
intersting idea - this is essentially identifying a 'consent proxy', 
same as e.g. an intellectually impaired person would have to do - only 
for most people it would presumably be time-limited. But a proxy does 
pose new challenges as well - who is legally responsible for access 
violations by people the proxy allowed (incorrectly to access the 
patient data? Does the proxy have the right to dynamically change the 
settings at any time? Is an appropriate legal metaphor the "power of 
attorney"?

>Nationwide role-based access may be good for Public Health personnel but
>
and anyway, that kind of access would probably be to 
de-identified/anonymised data - so it will be through a different mechanism.

>role-based access for all Physicians in Canada is NOT a great idea, e.g.,
>there probably would not be interest and dissemination of or wide access to
>secure, private information violates many security requirements.
>
Sure - but is there any need for any standardisation of role definitions 
across a health system - i.e. that the meaning of "registrar" be the 
same everywhere? I would have thought it very desirable since EHR 
information can easily be shared over a wide area due to patients 
moving, specialist care/testing etc etc.

>Emergency-based access is crucial. In a variety of situations one would not
>necessarily be in a position to grant access. A nationwide emergency access
>mechanism is definitely a good idea.
>
>CONCLUSION
>OpenEHR security should:
>1)address record-based security issues
>2)produce a structure that would support information transfer with other
>security systems
>3)integrate access control from identified, global primaries
>4)support security applications to monitor, review, audit and control
>individual and groups of records
>5)support reporting and review to primaries
>  
>
we have work to do!

- thomas beale

>  
>



-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Gerard Freriks]

come fascinated with the discussion over how best to
>> balance the needs of the various parties involved in the provision and
>> payment of healthcare services so as to improve the quality and
>> decrease the cost of health care here in the U.S..  Talk about a
>> non-trivial problem!  Interestingly, it looks to me like all
>> the nonsense can be traced back to the health record and some
>> fundamental questions about who owns it, who controls access to it,
>> etc.  Thanks again for sharing.  Hope to hear from you soon.
>>  
>> Best regards,
>> Bill
>>  
>> 
>> - Original Message -
>> From: Sam Heard <mailto:sam.heard at bigpond.com>
>> To: Bill Walton <mailto:bill.walton at jstats.com> ;
>> openehr-technical at openehr.org <mailto:openehr-technical at 
>> openehr.org>
>> Sent: Wednesday, April 23, 2003 6:10 PM
>> Subject: RE: openEHR security
>> 
>> Bill
>>  
>> Security and the EHR - ah theres a question! At least having a
>> reference model of the EHR makes this something that might be
>> tackled effectively. The current openEHR model has and access
>> control feature on ARCHETYPED in the Common Reference Model. The
>> idea being that anything that can be archetyped - that is, it is a
>> coherent clinical composition or concept - can have its access
>> controlled.
>>  
>> It is envisaged that the EHR will have an access control list
>> which can be transfered to other centres as part of an extract if
>> required. This requires standardisation of access control groups.
>> We have done some work in Australia to get a set of access groups
>> that could be standardised across health care and I enclose a copy
>> of this document for your consideration.
>>  
>> Hope this is a start - very interested to work with you on this!
>>  
>> Cheers, Sam
>> 
>> -Original Message-
>> From: owner-openehr-technical at openehr.org
>> [mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill
>> Walton
>> Sent: Thursday, 24 April 2003 7:36 AM
>> To: openehr-technical at openehr.org
>> Subject: openEHR security
>> 
>> I apologize for not having had the time to dig in and find
>> this out for myself yet, but I'd really appreciate it if
>> someone could tell me if security has been addressed in the
>> openEHR architecture and, if so, point me to the
>> documentation.  I'm trying to understand the system's
>> capabilities to limit access not only to authorized
>> individuals, but also to limit the access of authorized
>> individuals to specific subsets of an individual's record.
>> Thanks in advance for showing me where to dig.
>>  
>> Best regards
>> Bill
>> 

--   --
Gerard Freriks, arts
Huigsloterdijk 378
2158 LR Buitenkaag
The Netherlands

+31 252 544896
+31 654 792800


-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

Hi Karsten,

NEED TO KNOW is a 'working label' that has a meaning dependent upon the
particular circumstance. A Healthcare Practitioner selected to perform foot
surgery has a NEED TO KNOW pertinent information about the patient's feet,
especially the one the surgery is to be performed on. This would include any
condition that could impact the surgery and recovery, e.g., abnormal blood
pressure.

A brain specialist would likely not have a NEED TO KNOW nor an interest in
result related to the foot surgery, except for those 'cross-over' areas that
could impact the surgery, e.g., abnormal blood pressure. In both cases the
'potential impacts' had better be identified and handled.

Security systems are commonly compartmented, e.g., if a requestor needs to
have access to information contained in a compartment then a NEED TO KNOW is
established along with security policies and procedures.

The Patient may or may not be in a position to contribute re NEED TO KNOW.
Where they are they must be included, e.g., where a specific Healthcare
Practitioner is to be excluded per a Patient's request. Failure to honor
such a request may become expensive.

Certain privacy requests should also be honored, e.g., Patient statements
made in certain Healthcare environments (e.g., labor and delivery). Access
to Patient, and related, records should be restricted where requested unless
a superior demand is present, e.g., legal action.

Identification and clarification of a specific is generally needed before
NEED TO KNOW can be determined for individuals. One can say, however, that
the Flower Lady does not have a NEED TO KNOW but the CHEMIST might. One is
no; the other is maybe (conditional).

The Patient's family Physician has a NEED TO KNOW, the Public Health
Administrator may be conditional, and the Physician that lives down the
block has to build a case for having some NEED TO KNOW.

-Thomas Clark


- Original Message -
From: "Karsten Hilbert" 
To: 
Sent: Sunday, April 27, 2003 5:48 AM
Subject: Re: openEHR security; Directed to Thomas Beale


> [...]
> > At all points NEED TO KNOW
> > governs access
> [...]
>
> Except that the Need-To-Know paradigm doesn't work very well
> in healthcare. The provider may not know what she needs to
> know at the time of the patient encounter. The patient can't
> possibly correctly decide what her doctor must know in order
> to be able to make the right decisions (of course, the patient
> is fully able to decide what she *wants* the doctor to know).
> Etc.
>
> Medicine is neither the military nor a secret service, literally
> (it's not mass media either, on the other end of the spectrum).
>
> Just a clinician's muttering ...
>
> Karsten
> --
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Karsten Hilbert]

[...]
> At all points NEED TO KNOW
> governs access
[...]

Except that the Need-To-Know paradigm doesn't work very well
in healthcare. The provider may not know what she needs to
know at the time of the patient encounter. The patient can't
possibly correctly decide what her doctor must know in order
to be able to make the right decisions (of course, the patient
is fully able to decide what she *wants* the doctor to know).
Etc.

Medicine is neither the military nor a secret service, literally
(it's not mass media either, on the other end of the spectrum).

Just a clinician's muttering ...

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security; Directed to Thomas Beale

[Thomas Clark]

s one would not
necessarily be in a position to grant access. A nationwide emergency access
mechanism is definitely a good idea.

CONCLUSION
OpenEHR security should:
1)address record-based security issues
2)produce a structure that would support information transfer with other
security systems
3)integrate access control from identified, global primaries
4)support security applications to monitor, review, audit and control
individual and groups of records
5)support reporting and review to primaries





Security systems attempt to structure data transmission
- Original Message -
From: "Thomas Beale" 
To: "Bill Walton" 
Cc: 
Sent: Friday, April 25, 2003 12:53 PM
Subject: Re: openEHR security


>
> Hi Bill,
>
> good questions
>
> Security has been thought about, and is still being thought about!
> Essentially there are a number of aspects:
> A - what is the model of access control - the main problem here is
> different definitions of roles in different "bricks-and-mortar"
> institutions at which the one patient might appear (I shouldn't really
> say bricks-and-mortar, since we include emergency health workers, social
> workers, mobile nurses etc)
> B - what is needed in the EHR architecture (i.e. what we call the
> "openEHR reference models") to support security/privacy requirements?
> What is the granularity of privacy control required
> C - how is information to be protected when it moves?
> D - the related issues of encryption, notarising (for legal protection
> or investigation of previous clinical acts)
> E - who sets the privacy settings which control how secure access occurs
> at runtime?
>
> We have not yet written a comprehensive document on this. However, we
> think we know a fair few things, mainly based on the ideas of other
> people. Work has been done at the DSTC in Australia on many aspects of
> security, including a national PKI proposal. Bernd Blobel has probably
> described security and health information in the most detail that I know
> of, in his various papers and recent book. The US GCPR project probably
> made more progress on security in the CPR than it did elsewhere.
>
> So. What do we know?
> - role-based access control is required. To make it work properly in a
> shared care community context (e.g. a hospital, 50 GPs, aged care homes,
> nursing care, social workers etc etc) then the roles need to be defined
> congruently. I seem to remember some Canadian project coming to the
> conclusion that really the roles need to be defined the same across the
> entire (national) health care system. I think this is both correct and a
> the same time unrealistic. I think we will be able to find ways of
> having diversely defined roles without every health care facility having
> incompatible definitions of "consultant", "treating physician" etc.
> Bernd's work on this area is pretty detailed.
>
> - the EHR architecture does not need too much complexity added to
> support consent-based secure access. We currently think it needs to have
> the ability to store something like 'sensitivity' and access control
> group id(s) at each 'significant' (i.e. not the smallest) node, the
> lowest being the openEHR Entry.  The access control groups will
> themselves be defined in their own service.
>
> - when the decision is being made at runtime to grant or deny access to
> a certain part of the EHR to a certain user, the user role (already
> authenticated etc etc) and access group ids in the piece of EHR
> requested are compared to the access group definitions. Further, some
> way of establishing _relevance_ of this user accessing that bit of the
> EHR is required - i.e. the link between the patient and the user who is
> a treating physician, or on a team providing care. Other users who are
> not providing care would probably be treated differently. Certificates
> would be created if access is granted; these might be time-limited
> (again I think Bernd has experience in time-limited access); they might
> be more like keys if we are talking about sending the data outside the
> secure environment in the form of an encrypted extract.
>
> - the patient or competent guardian must be the setter of consent, but
> most likely with the professional advice of the physician.
>
> - the problem of what categories or ways a patient could set consent is
> hard to define - I don't think anyone has worked it out. If a patient
> wants to say "exclude family from access to my mental health EHR items"
> - which items are "mental health"? Some obviously are, but if other
> mundane items are useful to mental health clinical professionals, do we
> exclude them or not? Or do we allow the patient

openEHR security

[Sam Heard]

Bill
  First, and perhaps you consider this a seperate issue that's out of scope
for Access Control, but what about Audit Trails?

  SH: openEHR has full version control of all components so we have this
thoroughly covered. If you are talking about auditing what is viewed, our
research in the early 90s suggested that clinicians were totally against
this - and it is very difficult to be sure what is seen unless refresh
times, screen size and scrolling are all monitored - the idea is terrifying!

  In addition to the choices / decisions you summarize on Page 3, I believe
there's a key question the system needs to be able to answer: "Who has had
what access to my records?"

  SH: We do believe that it is essential to log access - but not to what
unless there is an over-ride on the constraints set by the patient. This
could result in an automatic email to the patient in the future. But not
policing what the clinician who has access looks at.

  To answer this question it looks to me like the system needs to maintain
two types of information: 1) a history of the changes to the Access Control
List,

  SH: In openEHR this is versioned like anything else...

   and 2) a history of accesses to the EHR itself.

  SH: I agree as long as we are talking access - that is logged - and
over-rides and who authorised them and for what reason ( perhaps unconscious
in Emergency is appropriate. Patients could set the over-ride capability to
be turned off.

  Further, it looks like the EHR access history should include reads as well
as writes.  That way, the trail would lead to the providers that have, with
permission, made copies of the EHR within their own systems.

  SH: True - it will only be able to be stored as an HTML rendition unless
there is an extract in openEHR - but you are right - this could be saved -
this is difficult to police.

  This is tied to the first question I think, but how does the system deal
with the needs of Consulting Physicians and Researchers who are not going to
provide care, but may need read access to the full record?  If I read this
correctly, the mechanism controls what information can be accessed, but not
the type of access permitted (i.e., read vs. write).

  SH: The fact is, unlike usual systems, there will be  more restraints on
reads than writes. Research access will be via the kernel with an approved
program unless it is one-to-one reading of records when the patient's
consent is required anyway.

  How do Emergency medicine providers get access to the records?  It looks
like there needs to be an override to allow the timely delivery of service
in Emergency situations.  It would seem to me that the existence of the
Audit Trails above might calm fears of inappropriate access.

  SH: As above

  Related to all of the above, it seems like there are probably a number of
circumstances that would require that the control of the Access Control list
itself be capable of being over-ridden or delegated.  It looks to me like,
as currently defined, the only roles that could grant access would be the
patient and Next of Kin roles.  But assume, for example, that a patient is
hospitalized, needs a test performed that can't be performed in the
facility, and has designated a Next of Kin that's not present.  Perhaps it's
just a difference between our systems, but in the U.S. I can imagine a need
to delegate the right to change the Access Control list without delegating
some of the other decisions (e.g., "pull the plug") that are associated with
Next of Kin here.  Again, as long as the Audit Trails are in place it seems
that fears of inappropriate access might be effectively balanced against the
needs of providers re: access to the records for the purpose of delivering
the appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.

  SH: The whole approach is to normalise access rather than normalise
denial - so a transfer of a record (or part there-of) would almost always
mean that the person giving permission for the transfer was happy with the
hospital policy - as advertised under these 6 roles. The access control list
would have to be changed by an authorative person when parts of the record
required for ongoing care had been limited a clinician who had left. Logging
these things is far more important than being highly restrictive - the
latter being possible if the patient wants this.


  What's an EPR, what's in it, and what, if any, information overlap does it
have with an associated EHR?  You introduce EPR in the first example, but
there's no definition provided and no reference to an external source.

  SH: Again, we have had a lot to say about this over the years. In
openEHR - it is the EHR - so the boundary is the model itself. There is a
real problem in the federated approach with addressing this - but I think
openEHR gives a clean approach.

  This is a really interesting problem space to me.  I've been studying
HIPAA (the Health care Information Portability and Accountability Ac

openEHR security

[Thomas Beale]

Audit trails are taken care of inside the architecture - have a look at 
the definition of the classes Transaction (EHR RM), Entry (EHR RM), and 
the change control classes (COmmon RM). All relevant party ids, dates, 
times and locations are recorded (or so we believe!).


- thomas beale



Bill Walton wrote:

> Sam,
>  
> Thanks much for sending that along.  I haven't made my way through all 
> the examples yet, but I like where you're going.  A few questions / 
> comments if you don't mind.
>  
> First, and perhaps you consider this a seperate issue that's out of 
> scope for Access Control, but what about Audit Trails?  In addition to 
> the choices / decisions you summarize on Page 3, I believe there's a 
> key question the system needs to be able to answer: "Who has had what 
> access to my records?"   To answer this question it looks to me like 
> the system needs to maintain two types of information: 1) a history of 
> the changes to the Access Control List, and 2) a history of accesses 
> to the EHR itself.  Further, it looks like the EHR access history 
> should include reads as well as writes.  That way, the trail would 
> lead to the providers that have, with permission, made copies of the 
> EHR within their own systems.
>  
> This is tied to the first question I think, but how does the system 
> deal with the needs of Consulting Physicians and Researchers who are 
> not going to provide care, but may need read access to the full 
> record?  If I read this correctly, the mechanism controls what 
> information can be accessed, but not the type of access permitted 
> (i.e., read vs. write).
>  
> How do Emergency medicine providers get access to the records?  It 
> looks like there needs to be an override to allow the timely delivery 
> of service in Emergency situations.  It would seem to me that the 
> existence of the Audit Trails above might calm fears of inappropriate 
> access.
>  
> Related to all of the above, it seems like there are probably a number 
> of circumstances that would require that the control of the Access 
> Control list itself be capable of being over-ridden or delegated.  It 
> looks to me like, as currently defined, the only roles that could 
> grant access would be the patient and Next of Kin roles.  But assume, 
> for example, that a patient is hospitalized, needs a test performed 
> that can't be performed in the facility, and has designated a Next of 
> Kin that's not present.  Perhaps it's just a difference between our 
> systems, but in the U.S. I can imagine a need to delegate the right to 
> change the Access Control list without delegating some of the other 
> decisions (e.g., "pull the plug") that are associated with Next of Kin 
> here.  Again, as long as the Audit Trails are in place it seems that 
> fears of inappropriate access might be effectively balanced against 
> the needs of providers re: access to the records for the purpose of 
> delivering the appropriate care.  Or perhaps I'm misunderstanding the 
> Next of Kin role.
>  
> What's an EPR, what's in it, and what, if any, information overlap 
> does it have with an associated EHR?  You introduce EPR in the first 
> example, but there's no definition provided and no reference to an 
> external source.
>  
> This is a really interesting problem space to me.  I've been studying 
> HIPAA (the Health care Information Portability and Accountability Act) 
> and have become fascinated with the discussion over how best to 
> balance the needs of the various parties involved in the provision and 
> payment of healthcare services so as to improve the quality and 
> decrease the cost of health care here in the U.S..  Talk about a 
> non-trivial problem!  Interestingly, it looks to me like all 
> the nonsense can be traced back to the health record and some 
> fundamental questions about who owns it, who controls access to it, 
> etc.  Thanks again for sharing.  Hope to hear from you soon.
>  
> Best regards,
> Bill
>  
>
> - Original Message -
> From: Sam Heard <mailto:sam.heard at bigpond.com>
> To: Bill Walton <mailto:bill.walton at jstats.com> ;
> openehr-technical at openehr.org <mailto:openehr-technical at openehr.org>
> Sent: Wednesday, April 23, 2003 6:10 PM
> Subject: RE: openEHR security
>
> Bill
>  
> Security and the EHR - ah theres a question! At least having a
> reference model of the EHR makes this something that might be
> tackled effectively. The current openEHR model has and access
> control feature on ARCHETYPED in the Common Reference Model. The
> idea being that anything that can be archetyped -

openEHR security

[Bernd Blobel]

Bill Walton wrote:
> Sam,
>  
> Thanks much for sending that along.  I haven't made my way through all 
> the examples yet, but I like where you're going.  A few questions / 
> comments if you don't mind.
>  
> First, and perhaps you consider this a seperate issue that's out of 
> scope for Access Control, but what about Audit Trails?  In addition to 
> the choices / decisions you summarize on Page 3, I believe there's a key 
> question the system needs to be able to answer: "Who has had what access 
> to my records?"   To answer this question it looks to me like the system 
> needs to maintain two types of information: 1) a history of the changes 
> to the Access Control List, and 2) a history of accesses to the EHR 
> itself.  Further, it looks like the EHR access history should include 
> reads as well as writes.  That way, the trail would lead to the 
> providers that have, with permission, made copies of the EHR within 
> their own systems.
>  
> This is tied to the first question I think, but how does the system deal 
> with the needs of Consulting Physicians and Researchers who are not 
> going to provide care, but may need read access to the full record?  If 
> I read this correctly, the mechanism controls what information can be 
> accessed, but not the type of access permitted (i.e., read vs. write).
>  
> How do Emergency medicine providers get access to the records?  It looks 
> like there needs to be an override to allow the timely delivery of 
> service in Emergency situations.  It would seem to me that the existence 
> of the Audit Trails above might calm fears of inappropriate access.
>  
> Related to all of the above, it seems like there are probably a number 
> of circumstances that would require that the control of the Access 
> Control list itself be capable of being over-ridden or delegated.  It 
> looks to me like, as currently defined, the only roles that could grant 
> access would be the patient and Next of Kin roles.  But assume, for 
> example, that a patient is hospitalized, needs a test performed that 
> can't be performed in the facility, and has designated a Next of Kin 
> that's not present.  Perhaps it's just a difference between our systems, 
> but in the U.S. I can imagine a need to delegate the right to change the 
> Access Control list without delegating some of the other decisions 
> (e.g., "pull the plug") that are associated with Next of Kin here.  
> Again, as long as the Audit Trails are in place it seems that fears of 
> inappropriate access might be effectively balanced against the needs of 
> providers re: access to the records for the purpose of delivering the 
> appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.
>  
> What's an EPR, what's in it, and what, if any, information overlap does 
> it have with an associated EHR?  You introduce EPR in the first example, 
> but there's no definition provided and no reference to an external source.
>  
> This is a really interesting problem space to me.  I've been studying 
> HIPAA (the Health care Information Portability and Accountability Act) 
> and have become fascinated with the discussion over how best to balance 
> the needs of the various parties involved in the provision and payment 
> of healthcare services so as to improve the quality and decrease 
> the cost of health care here in the U.S..  Talk about a non-trivial 
> problem!  Interestingly, it looks to me like all the nonsense can be 
> traced back to the health record and some fundamental questions about 
> who owns it, who controls access to it, etc.  Thanks again for sharing.  
> Hope to hear from you soon.
>  
> Best regards,
> Bill
>  
> 
> - Original Message -----
> *From:* Sam Heard <mailto:sam.heard at bigpond.com>
> *To:* Bill Walton <mailto:bill.walton at jstats.com> ;
> openehr-technical at openehr.org <mailto:openehr-technical at openehr.org>
> *Sent:* Wednesday, April 23, 2003 6:10 PM
> *Subject:* RE: openEHR security
> 
> Bill
>  
> Security and the EHR - ah theres a question! At least having a
> reference model of the EHR makes this something that might be
> tackled effectively. The current openEHR model has and access
> control feature on ARCHETYPED in the Common Reference Model. The
> idea being that anything that can be archetyped - that is, it is a
> coherent clinical composition or concept - can have its access
> controlled.
>  
> It is envisaged that the EHR will have an access control list which
> can be transfered to other centres as part of an extract if
> require

openEHR security

[Bill Walton]

Bernd Blobel wrote:

> Dear Bill, dear Sam
>
> Meanwhile, security constraint modelling succeeds. This concerns policy
> modelling, policy negotiation, privilege management, access control,
> object security categorisation. Unfortunately, the preparation of EU 6th
> Framework proposals was so time comsuming that I had no time to continue
> and to distribute the results. The modelling is also part of the EU
> modEHRa proposal OIA (Thomas and Sam) will be involved in.

Bernd,

I'd not previously studied security constraint modeling but a quick Google
put me onto some interesting research.  If you have any links to share, I'd
appreciate it.  Thanks for the new (to me) tack.

Best regards,
Bill

-
If you have any questions about using this list,
please send a message to d.lloyd at openehr.org

openEHR security

[Bill Walton]

Sam,

Thanks much for sending that along.  I haven't made my way through all the 
examples yet, but I like where you're going.  A few questions / comments if you 
don't mind.

First, and perhaps you consider this a seperate issue that's out of scope for 
Access Control, but what about Audit Trails?  In addition to the choices / 
decisions you summarize on Page 3, I believe there's a key question the system 
needs to be able to answer: "Who has had what access to my records?"   To 
answer this question it looks to me like the system needs to maintain two types 
of information: 1) a history of the changes to the Access Control List, and 2) 
a history of accesses to the EHR itself.  Further, it looks like the EHR access 
history should include reads as well as writes.  That way, the trail would lead 
to the providers that have, with permission, made copies of the EHR within 
their own systems.

This is tied to the first question I think, but how does the system deal with 
the needs of Consulting Physicians and Researchers who are not going to provide 
care, but may need read access to the full record?  If I read this correctly, 
the mechanism controls what information can be accessed, but not the type of 
access permitted (i.e., read vs. write).

How do Emergency medicine providers get access to the records?  It looks like 
there needs to be an override to allow the timely delivery of service in 
Emergency situations.  It would seem to me that the existence of the Audit 
Trails above might calm fears of inappropriate access.

Related to all of the above, it seems like there are probably a number of 
circumstances that would require that the control of the Access Control list 
itself be capable of being over-ridden or delegated.  It looks to me like, as 
currently defined, the only roles that could grant access would be the patient 
and Next of Kin roles.  But assume, for example, that a patient is 
hospitalized, needs a test performed that can't be performed in the facility, 
and has designated a Next of Kin that's not present.  Perhaps it's just a 
difference between our systems, but in the U.S. I can imagine a need to 
delegate the right to change the Access Control list without delegating some of 
the other decisions (e.g., "pull the plug") that are associated with Next of 
Kin here.  Again, as long as the Audit Trails are in place it seems that fears 
of inappropriate access might be effectively balanced against the needs of 
providers re: access to the records for the purpose of delivering the 
appropriate care.  Or perhaps I'm misunderstanding the Next of Kin role.

What's an EPR, what's in it, and what, if any, information overlap does it have 
with an associated EHR?  You introduce EPR in the first example, but there's no 
definition provided and no reference to an external source.

This is a really interesting problem space to me.  I've been studying HIPAA 
(the Health care Information Portability and Accountability Act) and have 
become fascinated with the discussion over how best to balance the needs of the 
various parties involved in the provision and payment of healthcare services so 
as to improve the quality and decrease the cost of health care here in the 
U.S..  Talk about a non-trivial problem!  Interestingly, it looks to me like 
all the nonsense can be traced back to the health record and some fundamental 
questions about who owns it, who controls access to it, etc.  Thanks again for 
sharing.  Hope to hear from you soon.

Best regards,
Bill

  - Original Message - 
  From: Sam Heard 
  To: Bill Walton ; openehr-technical at openehr.org 
  Sent: Wednesday, April 23, 2003 6:10 PM
  Subject: RE: openEHR security


  Bill
   
  Security and the EHR - ah theres a question! At least having a reference 
model of the EHR makes this something that might be tackled effectively. The 
current openEHR model has and access control feature on ARCHETYPED in the 
Common Reference Model. The idea being that anything that can be archetyped - 
that is, it is a coherent clinical composition or concept - can have its access 
controlled.
   
  It is envisaged that the EHR will have an access control list which can be 
transfered to other centres as part of an extract if required. This requires 
standardisation of access control groups. We have done some work in Australia 
to get a set of access groups that could be standardised across health care and 
I enclose a copy of this document for your consideration.
   
  Hope this is a start - very interested to work with you on this!
   
  Cheers, Sam
-Original Message-
From: owner-openehr-technical at openehr.org 
[mailto:owner-openehr-technical at openehr.org]On Behalf Of Bill Walton
Sent: Thursday, 24 April 2003 7:36 AM
To: openehr-technical at openehr.org
Subject: openEHR security


I apologize for not having had the time to dig in and fi

openEHR security

[Bill Walton]

I apologize for not having had the time to dig in and find this out for myself 
yet, but I'd really appreciate it if someone could tell me if security has been 
addressed in the openEHR architecture and, if so, point me to the 
documentation.  I'm trying to understand the system's capabilities to limit 
access not only to authorized individuals, but also to limit the access of 
authorized individuals to specific subsets of an individual's record.  Thanks 
in advance for showing me where to dig.

Best regards
Bill
-- next part --
An HTML attachment was scrubbed...
URL: