TWiki> Main Web>TWikiUsers>MaxwellYoung>MyNotes (revision 2)EditAttach
Back to Main Page



My  Notes



Privacy, Confidentiality, and Electronic Medical Records

This paper is slightly dated but provides a nice introduction to the issue of security in health informatics. Provided are definitions for frequent terms in the security arena as well as an in depth discussion of many key topics. The main points I took away from this paper are the following:

Access Control: this generic terminology refers to the control over how data is accessed. This is a broad topic with many different facets that tie in with security in general as this paper illustrates. The purpose of this page is to provide more detail on access control and this paper is just the start.

Security Policy: is required in order to identify and prioritize those aspects of the system that should be protected. You cannot talk practically about security unless you have a security policy first. In a security policy, you should identify the functional requirements (what functionality needs to be provided), security requirements (what requires protection) and the threat model (the expected types of attacks that will be inflicted on the system).

Data Ownership: this is a complicated issue. In the United States (and also in Canada according to what I’ve read) a patient’s medical record is owned by the patient him/herself. However, there are limits to this ownership and it is these limits which are hard to pin down in the literature. For instance, a patient can be denied access to his/her own medical record if that patient is unstable and might act in a dangerous fashion having obtained said information.

Authentication: refers to the process of validating the identity of a user. It is clear that authentication should take place prior to an individual having access to sensitive data. I have included more information on this topic both in my presentation slides and throughout the papers included on this site. For instance, the use of biometrics, RFID tags, etc.

Audit Trails: consist of recorded data from user sessions. From this data it is possible to identify when a health professional viewed a certain piece of information, where they viewed it from and why they viewed it. Therefore, the examination of audit trails allows for the detection of system abuses whereby an individual might view data he/she was not supposed to access. Unfortunately, this data is often massive in volume and is not in easy-to-read format. This means that detecting violations is time consuming and resource intensive.



A Review of Security of Electronic Health Records

This is a fairly recent paper that investigates the state of security for electronic health records (EHRs). It should be noted that electronic medical records and electronic health records appear almost interchangeably in the literature. However, in other cases, the two concepts are differentiated in that EHRs are more general than EMRs. In particular, EHRs are a conglomeration of medical data taken from many different locations while an EMR is often contextualized as a local document with a limited scope. In this way, an EHR can be composed of many different EMRs. Anyway, with that terminology out of the way, here are what I found to be the main points of this paper:

Consent: theoretically, tolarge degree, patients have the right to privacy. They should control who is allowed to access their medical information and, if information is provided to other parties, the patient should be notified. However, current practices tend to deviate from this ideal substantially. For instance, insurance companies, research personnel and extraneous medical staff exert influence over the flow of data.

Security Breaches: this a practical concern and the paper makes mention of several significant breaches of security. These range from system penetration by an outside ``hacker’’ to the exposure of sensitive data due to internal oversights by hospital staff.

Authentication Mechanisms and Role-Based Access Control: the paper deals with authentication from a technical viewpoint which is helpful. For instance, the use of firewalls is advocated. However, cooperation between two or more health institutions necessitates the use of access control mechanisms that allow for the exchange of data amongst authorized personnel. This introduces the concept of role-based access control (RBAC) whereby access is granted on a per-role basis. RBAC is not discussed by the paper in depth and the reader can obtain more information on this topic via the links on this site. The use of biometrics and RFID chips as effective authentication mechanisms is mentioned in passing; it is argued that these technologies are still being integrated and that they will be valuable security tools.

The final word on this paper is that RBAC is necessary; however, its implementation is still only a partially solved problem; therefore, security for EHRs is still incomplete.



Digest of the Discussion Group Sessions

Despite the informal title, this is indeed a paper published in Elsevier’s International Journal of Medical Informatics. This paper is the culmination of eight discussion group sessions held throughout a conference entitled ``Realising Security of the Electronic Health Record (EHR)’’. The discussion topics encompass the issues of security, patient rights, international implications, implementation challenges and many other aspects related to EHRs. Here are what I feel are the main points of this work:

Rights of the Patient: again, it is emphasized that the patient has the right to access his/her medical information except in a very limited number of scenarios. These scenarios include when (a) the data identifies a sensitive third party without consent and (b) the data is may cause the patient him/herself serious harm or put others at risk. In my mind, I can fathom an instance where a positive diagnosis for HIV might potentially harm the patient if the information was disclosed callously (ie. simply access over the internet) and, furthermore, might jeopardize a third party responsible for the infection. The discussion makes mention that health records should never be deleted if they have been used in a previous clinical process; however, data should be subject to censorship in the case of factual errors that might jeopardize future treatment. The aggregation of personal data into large ``national data sets’’ is an issue of contention. While the benefits include the potential for high quality treatment, the issue of privacy becomes an even more pressing concern.

Health Care Professionals vs. Patients: the idea that the interests of health care professionals and patients might be at odds sounds strange at first. However, consider when a patient decides that certain information contained in his/her medical record should be removed. If the contentious information is considered helpful to the health professional, then this presents a problem. Specific guidelines in such cases need to be developed.

Access Control: there are a large number of issues that the discussion groups tackled and I will mention a few here. First, from an ethical standpoint, who is supposed to benefit from access control? Is it the patient? The health care professional? Or the administration in question? Without prioritizing these entities, it is difficult to formulate standards for access control. Second, should access control differ by the type of record? For instance, should access control mechanisms be different when it comes to centralized records versus distributed records? Third, exactly who should have control and over what portion(s) of the medical record? The commentary on these questions was mostly open-ended and their resolution was not achieved in the discussion.

Authentication: the implementation choices for authentication were discussed. This involves the concepts of public key infrastructure (PKI), biometrics and trusted certification authorities. While PKI is a fairly mature area, it requires substantial costs in terms of set-up and hierarchical organization. It was agreed that biometrics offers a promising alternative to PKI; however, this is still a developing area. Finally, the question of certification (ie. who do we trust to sign off on certain devices and protocols?) was identified, but certainly not resolved.



Giving Patients Access to Their Medical Records via the Internet: The PCASSO Experience

Access to EHRs over the internet is clearly valuable both for the patient’s perspective and the health professional’s. It allows for efficient and convenient capture of information that might be stored on several servers located in geographically distant locations. However, with such functionality comes security concerns that need to be addressed at the implementation level; the Patient-Centered Access to Secure Systems Online (PCASSO ) project attempts to address such concerns.

The main source of concern is the security of the connection between the user and the server containing the information of interest. Under PCASSO, the user executes a program that loads a Java applet which, in turn, talks to a PCASSO server. The connectivity is established by the familiar TCP/IP link. At the PCASSO server, a number of security protocols are effected. For starters, a firewall stands between the server and the outside net. Mutual authentication is performed via a challenge-response protocol (which is standard) using a public-private key pair. The user him/herself is prompted to enter a user ID and password information. Patient data can then be selected along with the authorized actions that can be performed on such data. For instance, the user may request to view the results of a blood test done on a particular patient.

The PCASSO system was first tested by UC San Diego (UCSD) faculty. Patients were able to volunteer to use the system if they met certain criteria such as being a UCSD healthcare patient, if they had access to the internet and their physician agreed to allow their participation. The results of this testing showed that PCASSO was both secure and perceived to be secure by the users (an important distinction). Positive reviews were provided by a number of physicians and patients. More work on this project is currently underway with the focus on improving the ease-of-use and meeting even more stringent privacy expectations from both patients and health professionals.



An Introduction to Role-Based Access Control

This article puts the concept of Role-Based Access Control (RBAC) into context. Access control has developed over the past few decades as the functional and security requirements themselves have become more challenging. Discretionary Access Control (DAC) is the most relaxed form of access control where the user is seen to `own’ the content to which he/she has access. This means that the user is able, at his or her discretion, to grant access to those materials owned by said user. DAC was used in the past in such settings as operating systems where users were entitled to set permissions on their own files and directories; however, this is clearly not a good access control model for protecting EHRs.

Mandatory Access Control (MAC) is more stringent where all users and all data items are assigned a sensitivity label. A user is able to access a data item if and only if that user has a sensitivity label that meets or exceeds the requirement of the sensitivity label of the data item. The sensitivity labels are often assigned by an administrator who is in a position to decide the sensitivity of all data within a certain domain. MAC has been used in government security environments (such as the Department of Defense) and it allows for security in a compartmentalized form. However, there is a large overhead incurred due to the need to assign labels to so many objects; this means there is a large degree of complexity in accessing data but also in terms of updating data. In a hospital setting, where data might need to be accessed and updated rapidly, it seems clear that MAC is unsatisfactory.

RBAC is not necessarily a new access control model. It follows logically from the need to have a model that accommodates the need for a trade-off between a high level of security and ease-of-access in a dynamic environment. In contrast to both DAC and MAC, authority is conferred by role. Some examples of this are that a ``Doctor’’ can prescribe medication to patient A but not patient B, a ``Researcher’’ can collect and analyze anonymous data on a subset of patients and a ``Nurse’’ is restricted from viewing electronic health records of individuals not under his/her care. RBAC is not used exclusively in hospital settings, it is an appropriate model for many business environments in general. It is also suitable for the reason that it can handle heterogeneity in terms of authority and personnel. For instance, access control can be implemented across several hospitals each of which might have different position titles. This heterogeneity is handled easily by setting up roles in the system and then assigning these to personnel from all hospitals. Usually, this is accomplished by establishing a role hierarchy. For example, the role of ``Specialist’’ may contain the roles of ``Doctor’’ and ``Intern’’.



Role-Based Access Control

This is a short but informative Wikipedia article which places RBAC in the context of other forms of access control beyond DAC and MAC. The article does not address access control from a health informatics perspective; however, other versions of access control are presented. In particular, Context-Based Access Control (CBAC) and Lattice-Based Access Control (LBAC) are interesting in their own right. The article is brief and so I refer the reader to this page in full.



Role-Based Access Control Models

This article is an in-depth treatment of RBAC as it is used in practice. As the paper states, a review of 28 organizations by the National Institute of Standards and Technology (NIST) demonstrates that RBAC has found wide deployment. Most of the basic content contained in this paper is covered, although more briefly, in ``An Introduction to Role-Based Access Control’’ by NIST which I have discussed above. However, there are a couple topics which are discussed in more detail here and I now discuss some of the more important ones below:

Role-Hierarchies: these are implemented in systems that use RBAC in order to clearly define roles. Such hierarchies are usually set up visually with the more general or `powerful’ roles at the top, with specificity increasing as one moves downward through a tree structure. This tree defines an ordering that can be described mathematically using basic set theory and logic; however, the details are tedious and I refer the interested reader to the paper itself. Inheritance is a familiar concept to computer scientists (we see it in many object oriented programming languages) and it arises in hierarchies also. For example, the role of ``Optometrist ’’ might possess many of the same privileges as the role of ``Dermatologist’’. This can be achieved by having both of these roles inherit a basic set of privileges from the more general role of ``Doctor’’.

Role Administration: it is easy to view administration as centralized; however, in practice this is an extremely complex aspect of RBAC. As the paper states, the number of roles can number in the thousands! Given that one of the goals of RBAC is to improve over the management burden of MAC, it is important to consider how this might be achieved. Just as there is a role-hierarchy, there exists an administrative-hierarchy. This administrative-hierarchy cuts up the role-hierarchy into domains each of which is managed by one of the roles present in the administrative-hierarchy. For instance, the lesser administrative role of ``Security Officer’’ might be assigned to several related portions of the role-hierarchy. In turn, these security officer roles might be managed by a “Chief Security Officer’’ and so forth. The actual domain assigned to each administrative role must be planned ahead of time and the scope depends upon the system in question.



A Study of Access Control Requirements for Healthcare Systems Based on Audit Trails from Access Logs

In a system employing RBAC, access to sensitive data is secured against unauthorized access. However, security can and does fail and, therefore, it is important to be able such events. The use of audit trails can identify such security failures and, in particular, it allows one to detect when the access control rules have been violated. Whenever a user accesses the system, the audit trail data contains a record of this access with information on the user, what data was viewed, any modifications made, when the data was accessed and from where. Tracing back through this data allows for detection of instances where access control rules were violated.

Notably, not all violations are necessarily illegitimate. In a hospital environment, there are many valid reasons why access control might need to be bypassed. For instance, a medical emergency might dictate the expedient capture of a patient’s medical information from the nearest health professional regardless of their normal access privileges. In such cases, the use of an exception mechanism allows the health professional to bypass access control. Such a mechanism is sensible and, if used in practice sparingly, would seem to fit nicely into the RBAC paradigm despite the fact that access control rules are violated. But what if exception mechanism use is the norm rather than the exception? This paper is an illuminating investigation into answering this question. The authors conducted their study using audit trail data from 8 hospitals in Norway over a 1 month period (March 2006). In these hospitals, two exception mechanisms were available:

Actualization: where the user has access to a patient’s EHR which is not available through normal access control in a single domain. A reason must be provided and the user can select from eight predefined reasons or tailor a reason for the specific situation.

Emergency Access: where the user can open a single document in a patient’s EHR. Notably, this can be used only on a single document; however, the user can access multiple domains. There are no predefined reasons in this case and the user must justify such access in his/her own words.

The findings of this study are surprising and I summarize some of them below:

In the case of emergency access the numbers were too low to analyze. This is probably due to the fact that only a relatively few number of people have this capability. However, actualization is used too frequently to be considered an exception! In contrast to the emergency access, the percentage of people with actualization capability is enormous. The next obvious question is whether this large percentage is justified by the perceived need for this ability. The authors show persuasively that is indeed not the case. Moreover, in analyzing the reasons for why actualization was invoked, the authors found that only 8% of the reasons were self-defined. The use of predefined reasons is both easier for health professionals and provides less specificity; this is not necessarily a good thing.

The authors identified several predefined reasons which they suggest could be folded into normal access control privileges (rather than reserved for the execution of an exception mechanism). They also suggest that the number of individuals with actualization capability should be reduced; the current large numbers are not justified. Adoption of these suggestions would clearly reduce the amount of audit trail data which, in turn, would reduce the burden of checking such voluminous amounts of data.



How to Break Access Control in a Controlled Manner

This paper describes a system based on RBAC that incorporates an exception mechanism that the authors refer to as a ``Break-The-Glass’’ (BTG) policy. This is a recent paper (2006) and the authors argue that traditional access control policies do not incorporate exception capabilities. Given other literature, this claim seems contentious; however, I believe it serves to show just how disjoint the health informatics community can be, especially when it comes to clearly defined models of RBAC. It seems plausible that there is no true standard provided for implementing exception mechanism. The BTG mechanism is fairly simplistic in its conceptualization. The user simply accesses the system according to his/her predefined role and requests access to any data regardless of his/her privileges. If the system detects that the user is not authorized to view such data, the system informs the user of this fact and then queries the user about whether he/she would like to ``break the glass’’. A warning is also issued that employing the BTG mechanism will require a later justification to higher level personnel. If the user responds that he/she would like to indeed break the glass, the user is granted access, all appropriate users in higher levels of the role-hierarchy are alerted and the action is registered.



Authorisation and Access Control for Electronic Health Record Systems

The purpose of this paper is to investigate the functional requirements for a ``future-proof’’ EHR architecture. The maintenance and security of medical information is a rapidly changing and advancing area practical concern. Central to this issue is the ``shared-care’’ paradigm whereby medical information is secure and accessible to authorized personnel independent of the underlying architecture. For instance, this architecture might be centralized or distributed, it might be administered by one hospital or several hospitals, it might be a conglomeration of institutions in North America or it might span national boundaries. In this paper, the author declares standards and develops models to provide longevity, flexibility and, in short, future proof shared-care architectures.

Of particular interest is the ``Role Model’’. This is essentially RBAC but it is defined from a distinctly software engineering perspective. The author identifies two basic types of roles: structural and functional. Structural roles identify the ``organizational categories’’ such as radiologist or dermatologist. Functional roles are more specific about the responsibilities of the role itself, describing such things as ``prescribing doctor’’ or ``member of diagnostic team’’. The author illustrates his model through examples with UML and I refer the interested reader to paper itself.

Another interesting point is the discussion on authentication mechanisms. As has been seen in papers discussed earlier, public key infrastructure (PKI) is identified as the mechanism of choice. The author provides a much detailed discussion of the PKI components to used such as X.509 certificates which is a standard certificate format. This makes sense, since PKI is a fairly mature and well-tested paradigm.



e-Consent: The Design and Implementation of Consumer Consent Mechanisms in an Electronic Environment

As has been discussed in some of the earlier introductory materials, consent is a complicated issue. The question of how to implement a system that allows for patients to record their decision regarding consent is, unsurprisingly, also complicated. As a social concept, consent comes attached with legal and economic consequences. As an implementation challenge, recording, updating and obeying the consent decisions of the patient, remotely on on-site, requires a formal model that outlines the functional and security requirements. This paper presents several models that allow for the determination of consent prior to access to sensitive information is granted.

On of the interesting points addressed by this paper is the impact of patient consent on clinical work. The authors suggest that a formal model is unlikely to be of immediate use in this case since the bulk of clinical work involves interpersonal exchanges that need not, and often do not, pass through a system. However, there is mention that such conversations may, as technology progresses, be subject to more discriminating restrictions. For instance, telephones may become integrated with a consent system and conversations may be analyzed and scrutinized in digital form so that confidential information is protected in real-time. This is an interesting area of research and would seem to have very strong connections to areas of machine learning, voice recognition, etc. in computer science.



Cassandra: Flexible Trust Management, Applied to Electronic Health Records

Cassandra is a policy language developed for use in large-scale heterogeneous distributed systems. As we saw earlier, the development of a security policy is necessary to security. However, the instantiation of such a policy requires a formal language capable of expressing a policy within the confines of system semantics and syntax. Cassandra was developed with the purpose in mind of setting policy for the management of EHRs. Unsurprisingly, it is built around the presupposition of a role-based access control model and this is reflected in the kind of operations/constraints that Cassandra allows. The paper presents the policy language in a distinctly data-base oriented fashion and is, consequently, fairly technical. Generally speaking, Cassandra can specify complicated role hierarchies involving the revocation and delegation of privileges and using 310 rules. As of the publication date (2004) Cassandra incorporated 58 roles which implies a fairly limited prototype. However, this policy language was subsequently adopted in the CBCL OASIS architecture described in the next paper; therefore, it seems that the prototype has merit. For the full details, I refer the interested reader to the paper.



OASIS Role-Based Access Control for Electronic Health Records

The Open Architecture for Secure Interworking Services (OASIS) architecture is a role-based access control model developed at the Cambridge Computer Laboratory. It is a distributed architecture and, therefore, possesses no central policy, no global name space, and incorporates many administrative domains. OASIS itself represents the core system over which the authors implement a role-based access control (RBAC) model; the resulting system is termed CBCL OASIS where CBCL refers to the project partner company Clinical and Biomedical Computing Limited (CBCL).

CBCL OASIS was developed as a prototype for managing EHRs with RBAC. As was mentioned in the introductory materials, a security policy is necessary to establish the functional and security requirements of the system. However, these requirements need to be implemented in a formal language; such a language is called a policy language. Here, the authors employed the policy language Cassandra which was discussed earlier. Another point of interest is that again, we see the use of public key infrastructure (PKI) in attaining a high level of security. This repeated reliance on PKI shows that alternatives such as biometrics and RFID tags are possibly not viewed as viable access control alternatives.

CBCL OASIS is constructed to be flexible. It can handle heterogeneous data sources from different health care organizations so long as basic interoperability is provided. Moreover, these participating organizations can ``tune’’ their own policies within the context of OASIS. The system allows for users, patients and/or doctors, to connect to an EHR network via a secure connection over the internet (HTTPS for those who are interested). Once the connection is established, an OASIS session begins at which point the user can request medical records. Whether access to such records is granted depends on the role of the user. There are additional implementation details that work further to protect patient anonymity and I refer the interested reader to the full paper for details. Finally, the authors note that this work constitutes just the first steps towards a fully functioning system. As of the publication date (2006), no specific administrative tools or convenient auditing interface had been developed.



Access and Authorisation in Glocal e-Health Policy Context

First, it should be mentioned that ``Glocal’’ is not a typo – it the result of merging the terms ``global’’ and ``local’’ and has been used previously in the global health literature. Second, this work reads as an opinion piece; there is little to no technical detail. However, this work does nicely introduce the ideas surrounding the impact that local e-health practices have on the establishment of global e-health. The authors address the challenges facing the adoption of a global health system that allows access to EHRs in spite of geo-political obstacles. The authors recognize that the ``healthcare providers and organizations are in a quandary’’ when it comes to setting a glocal e-health policy. Policies are being practiced regionally and even nationally; however, there is a lack of leadership in establishing limited regulations at the national level. Canada is singled out unfavourably in the paper; however, it is mentioned that the National Initiative for Telehealth (NIFTE) project is establishing guidelines to address this situation along with the Policy and Peer Permission (PPP) project. Hyperlinks to both of these projects are provided on this site and I refer the interested reader there. It should be noted that I am somewhat skeptical as to the validity of these projects.

Edit | Attach | Watch | Print version | History: r6 | r4 < r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r2 - 2007-07-29 - MaxwellYoung
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback