# openEHR security

**URL:** <https://discourse.openehr.org/t/openehr-security/15743>\
**Category:** Technical (archive)\
**Created:** [23 April 2003 22:05 UTC](https://discourse.openehr.org/t/openehr-security/15743 "2003-04-23T22:05:37Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Bill\_Walton1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/ba8739/32.png) [@Bill\_Walton1](https://discourse.openehr.org/u/Bill_Walton1)\
**Post date:** [23 April 2003 22:05 UTC](https://discourse.openehr.org/t/openehr-security/15743/1 "2003-04-23T22:05:37Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bill\_Walton1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/ba8739/32.png) [@Bill\_Walton1](https://discourse.openehr.org/u/Bill_Walton1)\
**Post date:** [24 April 2003 17:14 UTC](https://discourse.openehr.org/t/openehr-security/15743/2 "2003-04-24T17:14:41Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bernd\_Blobel](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/e47c2d/32.png) [@Bernd\_Blobel](https://discourse.openehr.org/u/Bernd_Blobel)\
**Post date:** [24 April 2003 18:45 UTC](https://discourse.openehr.org/t/openehr-security/15743/3 "2003-04-24T18:45:35Z")

</div>

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
> 
> &nbsp;&nbsp;&nbsp;&nbsp;\*From:\* Sam Heard \<mailto:sam.heard@bigpond.com\>  
> &nbsp;&nbsp;&nbsp;&nbsp;\*To:\* Bill Walton \<mailto:bill.walton@jstats.com\> ;  
> &nbsp;&nbsp;&nbsp;&nbsp;openehr-technical@openehr.org \<mailto:openehr-technical@openehr.org\>  
> &nbsp;&nbsp;&nbsp;&nbsp;\*Sent:\* Wednesday, April 23, 2003 6:10 PM  
> &nbsp;&nbsp;&nbsp;&nbsp;\*Subject:\* RE: openEHR security
> 
> &nbsp;&nbsp;&nbsp;&nbsp;Bill  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Security and the EHR - ah theres a question! At least having a  
> &nbsp;&nbsp;&nbsp;&nbsp;reference model of the EHR makes this something that might be  
> &nbsp;&nbsp;&nbsp;&nbsp;tackled effectively. The current openEHR model has and access  
> &nbsp;&nbsp;&nbsp;&nbsp;control feature on ARCHETYPED in the Common Reference Model. The  
> &nbsp;&nbsp;&nbsp;&nbsp;idea being that anything that can be archetyped - that is, it is a  
> &nbsp;&nbsp;&nbsp;&nbsp;coherent clinical composition or concept - can have its access  
> &nbsp;&nbsp;&nbsp;&nbsp;controlled.  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;It is envisaged that the EHR will have an access control list which  
> &nbsp;&nbsp;&nbsp;&nbsp;can be transfered to other centres as part of an extract if  
> &nbsp;&nbsp;&nbsp;&nbsp;required. This requires standardisation of access control groups. We  
> &nbsp;&nbsp;&nbsp;&nbsp;have done some work in Australia to get a set of access groups that  
> &nbsp;&nbsp;&nbsp;&nbsp;could be standardised across health care and I enclose a copy of  
> &nbsp;&nbsp;&nbsp;&nbsp;this document for your consideration.  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Hope this is a start - very interested to work with you on this!  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Cheers, Sam
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\*From:\* owner-openehr-technical@openehr.org  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[mailto:owner-openehr-technical@openehr.org]\*On Behalf Of \*Bill  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Walton  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\*Sent:\* Thursday, 24 April 2003 7:36 AM  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\*To:\* openehr-technical@openehr.org  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;\*Subject:\* openEHR security
> 
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I apologize for not having had the time to dig in and find this  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;out for myself yet, but I'd really appreciate it if someone  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;could tell me if security has been addressed in the openEHR  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;architecture and, if so, point me to the documentation. I'm  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;trying to understand the system's capabilities to limit access  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;not only to authorized individuals, but also to limit the access  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;of authorized individuals to specific subsets of an individual's  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;record. Thanks in advance for showing me where to dig.  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Best regards  
> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bill

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.

Best regards

Bernd

---

<div class="post-metadata">

**Author:** ![Bill\_Walton1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/ba8739/32.png) [@Bill\_Walton1](https://discourse.openehr.org/u/Bill_Walton1)\
**Post date:** [24 April 2003 20:09 UTC](https://discourse.openehr.org/t/openehr-security/15743/4 "2003-04-24T20:09:40Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [25 April 2003 19:53 UTC](https://discourse.openehr.org/t/openehr-security/15743/5 "2003-04-25T19:53:41Z")

</div>

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 to set consent just on individual items? THis will not be realistic for most patients - they would have to trawl the record after every addition setting consent all over the place. Could it be set on the basis of problem? How does "exclude all users except treating physicians from accessing HIV/ADIS information". WHat information is HIV/AIDS related? Certain drug prescriptions clearly are, but so are certain patterns of common infections; a medically competent user could identify a person suffering AIDS even if the obvious items were blocked.

Philippe Ameline, the producer of the Odyssee product has some really interesting ideas in this area - patients set traffic light colours in a dartboard representing access control to each unit of the record.

- I think notarising is relatively easy to solve technically - just a case of working out a scheme whcih works in a distributed environment. Hashes need to be generated for each item and sent to a trusted third party notary service.

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:

---

<div class="post-metadata">

**Author:** ![Sam](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/s/5f9b8f/32.png) [@Sam](https://discourse.openehr.org/u/Sam)\
**Post date:** [26 April 2003 01:22 UTC](https://discourse.openehr.org/t/openehr-security/15743/6 "2003-04-26T01:22:50Z")

</div>

Bill

---

<div class="post-metadata">

**Author:** ![Thomas\_Clark](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@Thomas\_Clark](https://discourse.openehr.org/u/Thomas_Clark)\
**Post date:** [26 April 2003 18:36 UTC](https://discourse.openehr.org/t/openehr-security/15743/7 "2003-04-26T18:36:39Z")

</div>

Hi Thomas,

I have been monitoring the messages and have a keen interest in security  
issues (background in secure operating systems and Enterprise storage).  
Patient Centered Healthcare Informatics is a main focus currently.

This thread is really going well! I would like to add to it:  
1)Many of the current security systems address organizational security,  
e.g., hospital, clinic, practitioner.The goals in many cases conflict since  
issues related to the applications identified often clash. For example,  
assuming a compartmented security system in which all of these applications  
participate is usually unable to handle participation by a new application,  
e.g., patient security (US versus EU).

Modifying or eliminating the existing system to accommodate a new  
application is probably over-reacting. Building a security interface to a  
separate system appears to be more efficient.

2)By their nature security systems are not flexible. Suggesting this one  
would likely result in extended conversations.

3)Security systems obscure both data and relationships, e.g., who did what,  
when, where and what happened. By necessity they implement walls.

4)Security systems are often compromised by information working relations  
and people, e.g., a secure, compartmented operating system can neither  
monitor nor control conversations at the coffee machine. Another example is  
control over printed secure data.

5)Secure systems are effective only when security process, procedures and  
data are monitored, controlled, protected and violations are prosecuted.

6)Security overhead is enormous and expensive.

7)Cost-effectiveness of security systems is essential.

8)Secure systems and networks have a hard time communicating.

This is an overview meant only to cover my background.

With an interest in Patient Centered Healthcare that includes security I  
believe that a Secure Data Store in conjunction with Patient unique  
applications can provide secure Patient -controlled, secure Healthcare  
records. Selection of and control over the Secure Data Store is exercised by  
the Patient with the market providing a selection of services.

Data transmission can be accommodated using appropriate protocols and  
implementations such as the US HIPPA. Obvious modifications would include  
Patient permission and Public Health mechanisms.

Organizations and Practitioners would be able to choose a security system  
that suits their purpose and is able to communicate with other over a set of  
standardized, secure data transmission systems using perhaps different  
send/receive filters, e.g., versioning, paths. At all points NEED TO KNOW  
governs access and data records are composed of multiple physical records  
with secured components, each component potentially unique.

My preference is for appropriately encapsulated, time-and access-limited,  
secure objects, each entity (e.g., Patient, Hospital, Clinic, Practitioner)  
generating their own. This overall mechanism could include OpenEHR records  
accessible via standardized applications. It could include others as well.

COMMENT:  
There is significant potential for misuse between two or more users of  
OpenEHR records. These records must have their own security mechanisms. They  
should be affected to some extent by other security systems that transmit  
them, e.g., security trailer tracing handling back to sources. Security  
monitors should be able to review and audit the trailers. Security  
verification should then close loopholes. Security consistency checks can  
verify multiple local and remote copies.

UPDATES  
Updates to OpenEHR records looks like a problem. If several organizations,  
Practitioners and the Patients start communicating and updating OpenEHR  
records it can result in a significant update problem, e.g., delayed  
reports, as well as a major security problem. One might consider the  
assignment of an ADMINISTRATOR OF UPDATES to sort this stuff out, which also  
could result in use of Secure Data Stores to handle temporary files and  
other information.

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.

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.

Nationwide role-based access may be good for Public Health personnel but  
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.

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

Security systems attempt to structure data transmission

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [27 April 2003 12:48 UTC](https://discourse.openehr.org/t/openehr-security/15743/8 "2003-04-27T12:48:41Z")

</div>

[...]

> 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

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [27 April 2003 15:48 UTC](https://discourse.openehr.org/t/openehr-security/15743/9 "2003-04-27T15:48:53Z")

</div>

This is a very useful post - I have thrown in some comments below - mainly as a means of stimulating further discussions, not providing answers. I hope that the security experts amongst us will be motivated to think seriously about solutions for openEHR.

Thomas Clark wrote:

> With an interest in Patient Centered Healthcare that includes security I  
> believe that a Secure Data Store in conjunction with Patient unique  
> applications can provide secure Patient -controlled, secure Healthcare  
> records. Selection of and control over the Secure Data Store is exercised by  
> the Patient with the market providing a selection of services.

By "secure data store" - I think you mean security mechanisms in the persistence infrastructure - i.e. database level encryption, database-level user authentication (i.e. distinct from application or network secure login) etc.

At one level, it seems to me that these things are organisational security issues in the sense that they are the same for all enterprise information reseources - and we don't need to say anything special in the EHR specifications. On the other hand, we are talking about distributed patient-centred health information here, not employee emails. Do we need a formal model of the virtual EHR (i.e. distributed pieces of EHR) in which security facilities are defined (at least abstractly) for persistence and exchange? I think we do. Everyone has a lot of ideas about this, but I don't think we have seriously thought about defining a distributed EHR model on which we can hang security definitions - we only (so far) try to define security "in-the-small".

> Organizations and Practitioners would be able to choose a security system  
> that suits their purpose and is able to communicate with other over a set of  
> standardized, secure data transmission systems using perhaps different  
> send/receive filters, e.g., versioning, paths. At all points NEED TO KNOW  
> governs access and data records are composed of multiple physical records  
> with secured components, each component potentially unique.
> 
> My preference is for appropriately encapsulated, time-and access-limited,  
> secure objects, each entity (e.g., Patient, Hospital, Clinic, Practitioner)  
> generating their own. This overall mechanism could include OpenEHR records  
> accessible via standardized applications. It could include others as well.

at this level do you see the physical EHR fragments (i.e. piece of EHR at each physical location) as being the "object" at which these systemic security features should be defined?

> COMMENT:  
> There is significant potential for misuse between two or more users of  
> OpenEHR records. These records must have their own security mechanisms. They  
> should be affected to some extent by other security systems that transmit  
> them, e.g., security trailer tracing handling back to sources. Security  
> monitors should be able to review and audit the trailers. Security  
> verification should then close loopholes. Security consistency checks can  
> verify multiple local and remote copies.

I think we need to separate out the security needs which are specific to EHRs from those which would apply to any enterprise information.  
One principle that we think needs to be observed is that clearly secure access to peoples EHRs will be violated, however infrequently; therefore access audit trails do need to exist so that the a) the EHR subject can be notified that there was a breach; b) the means of violation can be identified and fixed and c) hopefully the violator can be identified and appropriate action taken. We at least need to guarantee that a) occurs - this requires that all violations are knowable and known.

> UPDATES  
> Updates to OpenEHR records looks like a problem. If several organizations,  
> Practitioners and the Patients start communicating and updating OpenEHR  
> records it can result in a significant update problem, e.g., delayed  
> reports, as well as a major security problem. One might consider the  
> assignment of an ADMINISTRATOR OF UPDATES to sort this stuff out, which also  
> could result in use of Secure Data Stores to handle temporary files and  
> other information.

I don't believe there will be any problem with update within any given health care facility - it will work in a very similar way to a configuration management (CM) system, in which (in general) there are multiple, competing, simultaneous modifiers. These systems work like clockwork already in many enterprises. The difference in health is - of course - security - in a normal CM system, there are not differential security settings on the controlled items.

I would not claim to have worked out all the details, but I suggest that the basic idea is that the "checkout" operation of a piece of EHR by any user be where the security be applied - the user 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

---

<div class="post-metadata">

**Author:** ![system](https://discourse.openehr.org/uploads/default/original/2X/f/f0a1dedb20c42747bddcafd6c7df9db5f34f003c.svg) [@system](https://discourse.openehr.org/u/system)\
**Post date:** [27 April 2003 17:05 UTC](https://discourse.openehr.org/t/openehr-security/15743/10 "2003-04-27T17:05:18Z")

</div>

Hi,

What is needed are several scenario's or use cases.

I think we need those for two situations at least:  
- within an organisation  
- between organisations

And then we need to take into account variations in possible architectures.  
? With or without an Authorisation server  
? The situation where information is polled from a system containing all  
possible information  
? The situation where information is published from a system containing all  
information

Without a series of accepted restrictions the problem will be intractable.  
(N persons, O Roles, P Participations, Q types of information, R exceptions  
and S Contexts)

Gerard

> 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 to set consent just  
> on individual items? THis will not be realistic for most patients - they  
> would have to trawl the record after every addition setting consent all  
> over the place. Could it be set on the basis of problem? How does  
> "exclude all users except treating physicians from accessing HIV/ADIS  
> information". WHat information is HIV/AIDS related? Certain drug  
> prescriptions clearly are, but so are certain patterns of common  
> infections; a medically competent user could identify a person suffering  
> AIDS even if the obvious items were blocked.
> 
> Philippe Ameline, the producer of the Odyssee product has some really  
> interesting ideas in this area - patients set traffic light colours in a  
> dartboard representing access control to each unit of the record.
> 
> - I think notarising is relatively easy to solve technically - just a  
> case of working out a scheme whcih works in a distributed environment.  
> Hashes need to be generated for each item and sent to a trusted third  
> party notary service.
> 
> 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
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;From: Sam Heard \<mailto:sam.heard@bigpond.com\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;To: Bill Walton \<mailto:bill.walton@jstats.com\> ;  
> > &nbsp;&nbsp;&nbsp;&nbsp;openehr-technical@openehr.org \<mailto:openehr-technical@openehr.org\>  
> > &nbsp;&nbsp;&nbsp;&nbsp;Sent: Wednesday, April 23, 2003 6:10 PM  
> > &nbsp;&nbsp;&nbsp;&nbsp;Subject: RE: openEHR security
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;Bill  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > &nbsp;&nbsp;&nbsp;&nbsp;Security and the EHR - ah theres a question! At least having a  
> > &nbsp;&nbsp;&nbsp;&nbsp;reference model of the EHR makes this something that might be  
> > &nbsp;&nbsp;&nbsp;&nbsp;tackled effectively. The current openEHR model has and access  
> > &nbsp;&nbsp;&nbsp;&nbsp;control feature on ARCHETYPED in the Common Reference Model. The  
> > &nbsp;&nbsp;&nbsp;&nbsp;idea being that anything that can be archetyped - that is, it is a  
> > &nbsp;&nbsp;&nbsp;&nbsp;coherent clinical composition or concept - can have its access  
> > &nbsp;&nbsp;&nbsp;&nbsp;controlled.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > &nbsp;&nbsp;&nbsp;&nbsp;It is envisaged that the EHR will have an access control list  
> > &nbsp;&nbsp;&nbsp;&nbsp;which can be transfered to other centres as part of an extract if  
> > &nbsp;&nbsp;&nbsp;&nbsp;required. This requires standardisation of access control groups.  
> > &nbsp;&nbsp;&nbsp;&nbsp;We have done some work in Australia to get a set of access groups  
> > &nbsp;&nbsp;&nbsp;&nbsp;that could be standardised across health care and I enclose a copy  
> > &nbsp;&nbsp;&nbsp;&nbsp;of this document for your consideration.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > &nbsp;&nbsp;&nbsp;&nbsp;Hope this is a start - very interested to work with you on this!  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > &nbsp;&nbsp;&nbsp;&nbsp;Cheers, Sam
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;From: owner-openehr-technical@openehr.org  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;[mailto:owner-openehr-technical@openehr.org]On Behalf Of Bill  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Walton  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sent: Thursday, 24 April 2003 7:36 AM  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;To: openehr-technical@openehr.org  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Subject: openEHR security
> > 
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;I apologize for not having had the time to dig in and find  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;this out for myself yet, but I'd really appreciate it if  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;someone could tell me if security has been addressed in the  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;openEHR architecture and, if so, point me to the  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;documentation. I'm trying to understand the system's  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;capabilities to limit access not only to authorized  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;individuals, but also to limit the access of authorized  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;individuals to specific subsets of an individual's record.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Thanks in advance for showing me where to dig.  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Best regards  
> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Bill

-- \<private\> --  
Gerard Freriks, arts  
Huigsloterdijk 378  
2158 LR Buitenkaag  
The Netherlands

+31 252 544896  
+31 654 792800

---

<div class="post-metadata">

**Author:** ![Mike\_Mair](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/0ea827/32.png) [@Mike\_Mair](https://discourse.openehr.org/u/Mike_Mair)\
**Post date:** [27 April 2003 19:37 UTC](https://discourse.openehr.org/t/openehr-security/15743/11 "2003-04-27T19:37:47Z")

</div>

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](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](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

---

<div class="post-metadata">

**Author:** ![Thomas\_Clark](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@Thomas\_Clark](https://discourse.openehr.org/u/Thomas_Clark)\
**Post date:** [28 April 2003 01:45 UTC](https://discourse.openehr.org/t/openehr-security/15743/12 "2003-04-28T01:45:53Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![thomas.beale](https://discourse.openehr.org/user_avatar/discourse.openehr.org/thomas.beale/32/35_2.png) [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)\
**Post date:** [28 April 2003 03:12 UTC](https://discourse.openehr.org/t/openehr-security/15743/13 "2003-04-28T03:12:30Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Karsten\_Hilbert](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/k/e56c9b/32.png) [@Karsten\_Hilbert](https://discourse.openehr.org/u/Karsten_Hilbert)\
**Post date:** [28 April 2003 09:37 UTC](https://discourse.openehr.org/t/openehr-security/15743/14 "2003-04-28T09:37:11Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Thomas\_Clark](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@Thomas\_Clark](https://discourse.openehr.org/u/Thomas_Clark)\
**Post date:** [28 April 2003 16:26 UTC](https://discourse.openehr.org/t/openehr-security/15743/15 "2003-04-28T16:26:48Z")

</div>

A prior comment.

-Thomas Clark

---

<div class="post-metadata">

**Author:** ![Thomas\_Clark](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/t/eada6e/32.png) [@Thomas\_Clark](https://discourse.openehr.org/u/Thomas_Clark)\
**Post date:** [28 April 2003 17:36 UTC](https://discourse.openehr.org/t/openehr-security/15743/16 "2003-04-28T17:36:34Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Bill\_Walton1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/ba8739/32.png) [@Bill\_Walton1](https://discourse.openehr.org/u/Bill_Walton1)\
**Post date:** [28 April 2003 19:01 UTC](https://discourse.openehr.org/t/openehr-security/15743/17 "2003-04-28T19:01:53Z")

</div>

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 from a physician’s system to the research organization’s system.

> > BW: 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

More to come under seperate headings.

Best regards,  
Bill

---

<div class="post-metadata">

**Author:** ![Bill\_Walton1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/b/ba8739/32.png) [@Bill\_Walton1](https://discourse.openehr.org/u/Bill_Walton1)\
**Post date:** [28 April 2003 21:33 UTC](https://discourse.openehr.org/t/openehr-security/15743/18 "2003-04-28T21:33:06Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Philippe\_AMELINE1](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/p/838e76/32.png) [@Philippe\_AMELINE1](https://discourse.openehr.org/u/Philippe_AMELINE1)\
**Post date:** [29 April 2003 07:54 UTC](https://discourse.openehr.org/t/openehr-security/15743/19 "2003-04-29T07:54:28Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![Mike\_Mair](https://discourse.openehr.org/letter_avatar_proxy/v4/letter/m/0ea827/32.png) [@Mike\_Mair](https://discourse.openehr.org/u/Mike_Mair)\
**Post date:** [29 April 2003 08:56 UTC](https://discourse.openehr.org/t/openehr-security/15743/20 "2003-04-29T08:56:33Z")

</div>

Dear Bill,

&nbsp;&nbsp;&nbsp;&nbsp;""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

&nbsp;&nbsp;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](http://www.health.nsw.gov.au/iasd/imcs/iso-215/areas/atehr2000.pdf)

Original Message -----

[Next page](https://discourse.openehr.org/t/openehr-security/15743.md?page=2)