The HealthITBlog

I read with great interest this posting by Adrian Gropper on The Health Care Blog, which was referenced by PracticeFusion’s blog entry on HIT interoperability.

Adrian describes the true case of a soldier injured in Afghantistan and then the hypothetical case of the soldier (or a delegate on his behalf) accessing his personal health record in government and private healthcare providers. The basic premise is that patient only needs to authenticate once to a trusted identity source, thereafter the patient is granted access to their medical record. This is  a sample use-case of Federated Identity, already in use in web applications. Adrian Gropper references OpenId. While that is an example of Federated Identity, the security protocols do not lend themselves towards the access and privacy requirements of medical records.

Firstly, to explain Federated Identity, I offer the following analogy. The European Union (EU), is a trans-national or umbrella organization with member States such as France, Spain, Belgium. Citizens of member States are issued EU passports and may thus travel freely within the other EU member States without requiring visas. The passport official at the airport or frontier, will recognize and trust the EU passport,  but will verify that the bearer of the passport matches the identity in the passport before granting entrance to the individual. Once that individual enters the country they are entitled to services or privileges granted to them, such as tourism or employment, but other privileges may be denied, as they are member State specific, such as retirement benefits.  These privileges differ depending who the user is, a visiting head of state may have higher privileges than an ordinary citizen.

Authentication: The process of matching the identity of the person to the identity claimed in the passport. In computer speak – proving who you are before you can use a computer application.

Authorization: The process of granting services to the person, based on their privileges.  In computer speak – once authenticated, your attributes or role determine what functions of an application you are entitled to use.

In Adrian’s example of an injured soldier accessing their health-record maintained by different health-care providers, the following Federated Identity infrastructure exists:

1. A central Identity Provider (IdP)  (analogous to the EuropeanUnion) who’s role is to issue and revoke digital identities.
2. Healthcare providers, ServiceProviders (SPs), (analogous to EU member States) who provide a service, in this case manage an Electronic Medical Record.
3. Trust relationships between SPs and IdPs. For example, military hospitals, private hospitals, HMOs, physicians etc establish trust relationships with the  Identity Provider. These trust relationships usually entail (a) legal/paperwork agreements and (b) technical exchanges to enable identity certification.

This infrastructure enables the following scenario:

A user of any (Healthcare) ServiceProvider, who has been issued a digital identity by the trusted IdentityProvider, may seamlessly interact with the healthcare providers (SPs). The user will present the digital identity issued by the IdP, the SP will verify the Identity, and the user will be granted access to the Service Provider’s application. However, based on the user’s attributes and role, the functionality available to the user will vary.  A physician may alter a medical record but only within their specialty ( a dermatologist cannot alter a prescription for spectacles). A pharmacist may view but not alter the prescription for insulin in a healthrecord.  A patient may only view but not alter their medical record. In Adrian’s example, the soldier may view his medical record and perhaps authorize it’s transfer to another care provider.

The following provides a graphical view of Federated Identity with the European Union as an analogy and a patient as sample user.