Project Overview
The rapid worldwide deployment of the Internet and Web is the enabler of a new generation of e-healthcare applications, but the provision of a security architecture that can ensure the privacy and security of sensitive healthcare data is still an open question. Current solutions to this problem are application-dependent and do not address the privacy and security requirements mandated by HIPAA. Our research group believes that web services represent a promising technology for solving this problem. To that end we are building a prototype system to protect the privacy and security of medical data that has these attributes:
Medical portal. Our medical portal is the common entry point for human access to medical data. All physicians, patients, and staff enter through this common website.
Policy-driven security. All authentication, authorization, and federation rules are expressed in XML using a combination of SAML, XACML, and WS-Policy documents.
Authentication. Authentication must be flexible and must advance with technology. We have a common approach to generating authentication tokens that embraces passwords, fingerprints, iris scans, signature and voice recognition, e-Tokens, smart cards, and RSA SecurID.
Trust levels. It is well known that different authentication methods have different levels of reliability. We introduce the concept of trust level, T(), a numerical representation of the reliability underlying each identification technology. Trust levels are established scientifically by determining a technology's false acceptance and false rejection rates. Trust levels can then be used as a component of an authorization rule.
On-demand authentication. Users may establish identity using any identification technology available on their access device. Usage proceeds until the user attempts to access an object whose access rule requires a higher trust level of authentication than currently provided by the user's authentication token. At that point the user is given the opportunity to upgrade his/her authentication token using a technology of higher reliability.
Token substitution. If appropriate, an authorization rule may permit a higher-reliability authentication token to substitute for the lower-reliability version that would normally be required, without requiring a secondary sign-on and authentication procedure.
Authorization. We have implemented an enterprise access control system that extends standard Role Based Access Control (RBAC) and the eXtensible Access Control Markup Language (XACML) to implement Constrained Delegation and Attribute-Based Role Assignment (CaDABRA). To this end, we created an access control system that effectively represents authorization policies, provides dynamic permission definition, assignment, and enforcement, and provides complete administrative control over delegation. As and example, a physician leaving for vacation may temporarily delegate his attending physician rights for a patient to another physician.
Wireless devices. We process access requests from Pocket PCs and Tablet PCs. Authorization rules may require higher reliability authentication from wireless devices if appropriate.
Federation. The hospital is but one component of a modern health services infrastructure. Auxiliary services such as pharmacies, insurance, billing, clinics, private practitioners, and other hospitals are likewise important players. We use trust authorities, trust groups, and trust mappings to reliably manage and exchange authentication credentials among trust domains. For example, a physician's authentication credential, once legitimately established in the hospital's domain, may be exchanged and verified for use in the pharmacy's trust domain if the pharmacy's Policy document permits it.
Notification. When asynchronous events occur, such as the pharmacy having filled a patient's prescription, we use an alert service to notify the patient via telephone using a text-to-speech conversion web service.
Security Architecture
Figure 1 shows our security architecture.
Figure 1. Security Architecture for Protecting Medical Data
Upon accessing the medical portal, the user presents his/her authentication token from previous logins, if any. The trust level of the prior identification is contained in the authentication token along with its period of validity. If no authentication token is presented, then whenever the user first attempts to access a protected object, the user is redirected to the Secure Token Service to establish identity. The STS issues an appropriate authentication token that establishes identity and also encodes the reliability of identity establishment; that token is stored as a cookie (with an expiration time) on the local access device for future use. The action request and the authentication token are forwarded to the medical data web service, whose Policy document determines the conditions of access. The access request and authentication token are forwarded to the authorization web service which retrieves the appropriate authorization rule for the object in question. The web service evaluates the access request and makes an access determination, which is then returned to the medical data web service which then grants or denies data access.
Access to auxiliary services requires crossing a trust domain. For example, to send an electronic prescription from the hospital to the pharmacy requires access to the pharmacy's portal, which in turn requires verification of the prescription. The hospital's STS provides its credentials to the pharmacy's STS. If, per the pharmacy's Policy document, the credentials are acceptable, then a local authorization token in the pharmacy domain is created to accompany the prescription.