Towards a viable and secure health information system - Part 1

IT for HealthCare - Why it is important..

IT has influenced all most all aspects of human life - from education to communication to transport to banking & trading - for the betterment of the respective fields, and healthcare by no means can have an exception.

Large amount of medical records are generated on a daily basis which include patients' medical history, prescriptions, laboratory results, radiology reports, medications etc.

Generating, storing, maintaining and sharing them as electronic medical records (EMR) has many advantages over paper based medical records.
Making a patient's medical records available as EMRs provides easy and fast access from anywhere a patient goes for treatments which reduces cost and risk of repeating harmful diagnosis tests and treatments . It also avoids missing of any critical information regarding the patient's medical history.
EMRs interfaced with PHR (Personal Health Record) Systems provides patients the better access and control over their medical records. Also, EMRs in turn aid insurance claiming processes and providing statistics for medical research which again contributes to advancement of healthcare.

There are many initiatives and lot of research going on to realize the goal of a robust healthcare information system while protecting patients' privacy and security. But no country has yet achieved the  ultimate country wide system - AFAIK.

Concerns in adopting EHR..

Examples for PHR services that have been emerged over the past years are google health and microsoft health vault, to interface with existing EMR systems. Paper at [1] and the article at [2] talks about the issues encountered and solutions applied wrt above two services in a pilot project.

And this article [3] discusses how the non-effective healthcare information system caused discontinuation of Google Health.

Therefore, along with all the advantages, there are technical, political and practical issues in implementing a country wide robust health information system, among which security risks and privacy concerns play a major role since a healthcare system is involved with highly sensitive and critical data. 

Better the access more the advantages and more the security and privacy concerns invloved.

Research problems inspired from those concerns & my views..

I happened to read this interesting paper at [4] which discusses the recommendations made by PCAST (President's Council of Advisor's on Science and Technology) Health Information Technology Report in its chapter 5, based on the identified problems and requirements - in the space of security and privacy - in healthcare IT. 

While some of the recommended solutions in the above report can be addressed with off the shelf solutions, some opens up research problems for the research community.

This paper[1] identifies and expands research problems which are inspired by the recommendations presented in the PCAST report.

Note:  At the final stages of the series of blog posts that I have been writting on this, I found that the PCAST report on which the research paper[4] was based, has caused some arguments in the field. For an example, refer document [5]. However, the purpose of my research and these blog posts is solely to identify research problems in the space of security and identity management in healthcare information system which upon realizing, will cause human advancement, and not to advocate the PCAST report.

The paper[1] is the focus of the series of posts starting with this. There I summarize the main aspects that the paper discusses with regard to security & privacy of healthcare information systems (IS), along with my views and findings on them where applicable.

Before going into detail, following diagram illustrates the main points to be discussed around a secure healthcare IS.

Lets discuss each of the above aspects in detail..

1. Identity Management and Authentication
Lets start with the first aspect which is managing patients' identities and authenticating users in health information systems.

• Each citizen's EMRs need to be mapped with his/her identity in a robust and accurate manner. This becomes more challenging when EMRs for the same patient is generated by multiple healthcare providers. The report highlights the issue of some countries rejecting to have existing physical identities such as national identity number, social security number to uniquely identifying users and mapping EMRs to user identities which may result in issues such as mapping of one patient's EMRs to multiple identities and multiple patients' EMRs to same identity, when reconciling/merging EMRs from different healthcare providers who have used to store EMRs in different formats in legacy storage.

• On the other hand, authenticating users to access EMRs via different mechanisms such as from their PHR applications on the desktops, mobile devices etc is a critical aspect where proper authentication factors needs to be identified to avoid privacy and confidentiality breaches.

• The report identifies authentication factors in three categories: phisycal credentials, biometrics, secrets and suggests that authentication should happen involving at least two of these factors.

• The paper suggests that the obvious solution is to assign a globally unique healthcare identification number to all patients and every healthcare provider, [which of course can have political & technical issues(wrt legacy databases) involved] because without unique id, managing medical records in a large system consisting of multiple providers and many incompatible vendors becomes a problem as discussed above as well.

• As paper identifies, research problems that are inspired by the above discussed requirements and issues include:

          1. developing/improving existing biometric techniqques to identify individuals          

          2. developing techniques to reconcile data from different sources

          3. developing authentication techniques that are less vulnerable to attacks

Let me mention my views on the above aspects based on my knowledge of existing solutions in the domain and my findings about ongoing research efforts in the domain:

• I too strongly agree with the paper's suggestion on assigning a globally unique id to index individual's EMRs.

Regarding identity management and authentication:

• Although different healthcare providers participate in a country wide  healthcare information system, citizen's identity should be maintained with a centralized trusted authority  which we can identify as the identity provider(IdP) in the entire system. This can be considered as provided by national security infrastructure. Thereby we can avoid having duplicated patients' identities in different systems and also multiple credential anti patterns. Individual healthcare service providers can integrate with the central system and act as relying parties to retrieve a particular user's identity information and to rely on getting the users authenticated from the identity provider.

• With that type of interaction between the systems, existing web based authentication mechanisms such as SAML2 Web browser based Single Sign On and OpenID based decentralized Single Sign On can be used to provide users with seamless access to different portals/web applications in the healthcare information system while managing identity and authentication at a single place.

• And if it is a web service of a  third party healthcare service provider that the user needs to authenticate to, brokered authentication mechanisms built on top of WS-Security such as WS-Trust can be used.

• But in this kind of a centralized identity and authentication management  system, authentication at the central identity provider should be performed based on strong authentication factors including biometrics (such as fingerprint which can be supported easily than other biometrics based authentication)  because an attack at the IdP can lead to attacker gaining access to patient's identity and seamless access to other applications to access EMRs and PHRs.

• An example implementation of XMPP based multifactor authentication to avoid phishing attacks on OpenID provider, can be found here. Some research projects have analyzed different authentication mechanisms including biometrics. For eg: "Human Factors in Online Security and Privacy" project[6] in CERIAS has done such analysis.

• Further, when enforcing authentication at the back-end web services which expose different types of EMRs of a patient and which are usually accessed through different user applications (such as web portals, mobile applications, PHR applications etc) by different principals (such as doctors, laboratory scientists, patients etc), it is better to use  mutual  authentication based trusted sub system pattern where only the trusted applications are allowed to access BE services on behalf of the users who were authenticated at the front end applications. This avoids users credentials being propagated to BE services which expose sensitive EMRs  and thereby reduces the risks that can be caused by individual user credentials breaches. By this way, authentication and authorization of the individual users can be performed at two different layers for which I will give an example in a future post.

• In summary, we discussed identity management and authentication aspect of HealthCare IS in detail in this post and it is clear that there should be an agreed unique identity attribute to map patients' records and while there are number of existing solutions that can be used address the issues in this aspect, there are active research in identifying better and stronger authentication mechanisms.

To be continued...

In this post, we only discussed one aspect out of the several aspects illustrated in the above image, related to a secure healthcare information system. We'll discuss about the other aspects explored in the paper at [4], in the coming posts.

Motivation...

I am passionate about the research carried out in the area of healthcare information systems - mainly related to the security and privacy aspects of it, being computer security is the area of my preferred specialization.

And I believe that I have come across a great paper during the research on the $subject.

The paper[1] has successfully achieved its goal of drawing the attention of the security and privacy research community on the problems in health care IT that needs new solutions, based on the requirements and recommendations highlighted in the PCAST report on health information technology.

References:
[1] The military health system’s personal health record pilot with Microsoft HealthVault and Google Health
[2] Personal Health Records In Action: Google Health and Microsoft HealthVault
[3] How a Broken Medical System Killed Google Health
[4]   A Research Roadmap for Healthcare IT Security inspired by the PCAST Health Information Technology Report
[5] PCAST Workgroup Letter to the National Coordinator
[6] Human Factors in Online Security and Privacy

Security Patterns - Direct Authentication & Role Based Access Control

Authentication and authorization are vital aspects of any secured system or service which expose business assets to outside. Authentication itself is not sufficient when you want to restrict access to different resources for different types of authenticated users.

There are different authentication and authorization patterns.

In this post we will look at how to implement direct authentication and role based access control.

Direct Authentication

In direct authentication, clients share their credentials with server through a trust relationship established prior to the actual service invocation - eg: during user registration.
And when the client accesses the secured service, provided credentials are validated against the ones stored in the user store.
We call this direct authentication since the server itself stores client's credentials and validates them at authentication.

Role Based Access Control
Authorization models have evolved over time. In role based access control, users are assigned to a particular role and the permissions to that role. This is scalable than user-centric permission model where permissions are assigned per user, but coarse grained and coupled with application code as opposed to policy based access control which we'll look at in a future post.

Let us secure a service with above security mechanisms using WSO2 open source Enterprise Service Bus (ESB).

Overview
Before taking you through the steps, following is the architecture diagram of our solution.

- BE Service which exposes the actual business logic is fronted by a proxy service in ESB so that BE service is not exposed to out side directly and also we can enforce all the QoS, auditing, necessary transformation at ESB in this way.

- Proxy service is secured using Web Service Security mechanism to require a UserName Token(containing user name, password of the user) to authenticate the user and RBAC to authorize the user before invoking the BE service.

- User credentials are stored in Active Directory user store connected to ESB.

 Steps:
1.Download and extract latest ESB pack from here.

2.Configure Active Directory as User Store : locate user-mgt.xml file from [ESB_Home]/repository/conf and enable the ActiveDirectoryUserStoreManager element and provide appropriate information to connect to AD in your domain. (WSO2 products can be integrated with heterogeneous user stores and you can connect to any user store that you prefer.)

3.Start the server and access the management console from the browser: https://localhost:9443/carbon and login with credentials : admin, admin.

4.BE Service : Echo Service in ESB will serve as the BE service in our above deployment. Obtain its url(http://localhost:8280/services/echo) and wsdl(http://localhost/services/echo?wsdl) which will be used to create the proxy service.

5. Proxy Service: From left hand panel, select "Services->Add->Proxy Services" and create a pass through proxy with name "SecuredEchoProxy", url and publish wsdl url with the ones obtained in the previous option.

6. Applying Security: Go to the proxy service's dash board like the one shown in above image and select "Security" under Quality of Service Configuration.

Enforcing Authentication:

- select enable security -> yes
- select the WS-Security mechanism we are going to apply -> Username Token

Enforcing Authorization:

- Click Next.
- Select which Roles are authorized to access this resource.

- Finish applying security.

You can invoke the proxy service from SOAP UI client or a java client with different user names belonging to different roles and test.

I have attached a maven project here with a java client which can invoke a service secured with UserName Token security policy.

UserName Token Security Policy:

Message Communication:
Request:

   
      
         
            2012-09-15T12:21:11.203Z
            2012-09-15T12:26:11.203Z
         
         
            admin
            admin
         
      
      https://localhost:8243/services/SecuredEchoProxy 
      urn:uuid:a205c52e-0d22-465b-87c4-8192de4e3cbc
      urn:echoInt
   
   
      
         1
      
   

Response:

   
      
         
            
               2012-09-15T12:21:11.824Z
               2012-09-15T12:26:11.824Z
            
         
         urn:uuid:6ece26cd-e349-4246-9481-7b05f6d928c1
         urn:echoIntResponse
         urn:uuid:a205c52e-0d22-465b-87c4-8192de4e3cbc
      
      
         
            1
         
      
   

Remarks:
1. Request message contains user name and password of the user according to the UserName Token profile of WS-Security. Since password is sent in plain text, the security policy enforces a transport binding which requires HTTPS to be used in message communication to provide confidentiality at transport level.

2. As security policy requires, both request and response contains timestamp values to avoid replay attacks.

3. Rampart is used as the underlying SOAP security processing module. In the security policy shown above, rampart specific configuration is commented out for the  purpose of clarity.