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" <andrewg at dstc.edu.au> 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" <mge at totalise.co.uk>
>> To: <openehr-technical at openehr.org>
>> 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
>     v    http://staff.dstc.edu.au/andrewg/
> 
> -
> If you have any questions about using this list,
> please send a message to d.lloyd at openehr.org

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

Reply via email to