Sunday, November 11, 2012

Towards a viable and secure health information system - Part 2

I have started discussing the $subject in my previous post based on a research paper[1] that I happened to read.
This is the second post of the series. Lets again take a look at the following image which summarizes the key considerations with regard to security, privacy and identity management of a healthcare information system.

In my previous post, I have given an overall idea on security in health care IS and discussed the first aspect, which is Identity Management and Authentication.
In this post, I am going to take the second aspect into consideration..

2. Authorization
Since a health information system contains personal information with varying sensitivity, not only authentication is sufficient, but also the rights of the authenticated principals to access certain data should be validated - which we refer as authorization.

For an example, a patient's medical records should only be possible to access by an authenticated principal in the role of a physician and also only during his/her working hours, while clinical data can be accessed by nurses as well. On the other hand, researchers can access medical data only if they are properly de-identified.
There should be proper mechanisms in place to enforce such fine grained authorization.

Let me discuss this in terms of, what the paper[1] analyzes and what my views are, on the mechanisms to accomplish the security requirement of authorization.
  • The PCAST report highlights that according to current regulations, it is not necessary to have patients' consent to disclose treatment/payment information in certain conditions. Therefore patients do not have control over privacy of their medical records which affects negatively to build and maintain public's trust in health care IT.
  • Mentioning some background information, report advocates the idea of a universal language to exchange health information between different healthcare providers who may still have proprietary formats/schema of storing data. It proposes to use a language structured as individual data elements, together with metadata that provide an annotation for each data element. It can be an extensible markup language, where individual pieces of data can be tagged with context-sensitive metadata.
  • Report envisions that such a data representation framework can enable fine grained authorization/privacy preferences where the consent for access each data element (authorization policy) is expressed through meta data attached to it. 
  • The paper[1] believes that the data representation framework plays a big role in secured EMR system with fine grained access control, and illustrates how the above recommendations motivates interesting research problems such as:
          - how to programatically tag data based on a particular security/authorization policy
          - how to efffectively feed tagged-data elements to an policy engine to get the decision whether the   requested access is allowed or not.
          - how to efficiently parse and process tagged data elements.

Let me mention some of my views on this aspect:
  •  Although I do not have much understanding to comment on meta-data tagged data elements[2], I too strongly believe that there should be fine grained authorization models employed which are also robust, efficient and scalable to achieve the level of privacy that the records in a healthcare IS needs.
  • From my understanding about the authorization models used in the identity/privacy world, XACML is a good candidate to implement a fine grained authorization system for healthcare information echo system. It is a policy based mechanisms which is flexible for changing requirements and which facilitates to define fine grained authorization policies based on identity attributes of the principals.Other key attributes of a XACML based solution are: loosely coupled, externalized, centralized and standardized.
  • A real world use case example of using a XACML based authorization solution for health care can be found at [3].
  • Privacy preserving secure search is an interesting aspect brought to discussion by the PCAST report. Although the search engines aggregate relevant data from multiple providers and provide the result for a search query, engine itself can not see the data which is authorized to be seen only by the certain parties.
  • Authorization delegation is another aspect which has not been taken into consideration in the above report and the paper. It is important when physicians and patients use various mobile devices to access EHR and PHR where constrained authorization delegation needs to be performed. Industry standard to accomplish this requirement is OAuth[4].
  • I found an interesting research project description [5] which develops an security schema for Veterans Affairs (VA) which claims to provide a secure, manageable, portable, scalable and cost effective solution with fine grained access control in place and which is easily pluggable to the existing system.

In summary:
- Enabling to specify fine grained authorization rules based on privacy preferences and to enforce access control is a key aspect of a secure healthcare information system.
- It should be possible to realize such an authorization model even with existing legacy EMR systems with minimal or no change to the underlying persistent mechanisms.
- One strong mechanism suggested by PCAST report is to use metadata in a tagged data elements framework to achieve this which motivates several research problems.
- Some existing technologies and standards can be used to implement certain aspects of an authorization solution for a health information system such as XACML for fine grained policy based access control and OAuth for authorization delegation.

[1]  A Research Roadmap for Healthcare IT Security inspired by the PCAST Health Information Technology Report
[2] Metadata and Meaningful Use
[3] XACML Sample for Health Care Application
[4] OAuth
[5] Trusted Medical Information System and Health Informatics

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.