EMR vs EHR redux

Nate Bagley from Software Advice asked me to review his article and it jogged my memory… I wrote this a few years ago.  Only Nate offers some Google data to back up the idea that essentially an Electronic Medical Record (EMR) is a patient’s medical record sourced from one provider; an Electronic Health Record (EHR) is sourced from several providers. This is in line with Nate’s quote from Don Fluckinger, “EHR seems to refer to a record that can be shared back and forth and amended among multiple providers.

If I get my healthcare from one provider, say Sutter Health, where one electronic record is shared between primary care, nurses and specialists, is that an EHR or EMR?

Until the NHIN or HIEs gain traction, Sutter’s health record cannot be shared with Stanford Hospital literally across the street!

Advertisements

Health Internet vs NHIN: in pictures

I read with great interest, David Kibbe’s posting on the HealthCare blog, NHIN vs The Health Internet; that same week I also read Robert Rowley’s take on the NHIN vs The Health Internet.  So I thought I would sum up the two perspectives with two pictures. (Forgive the delay, I took a break over Thanksgiving)

  • NHIN – National Health Information Network – “is a collection of standards, protocols, legal agreements, specifications, and services that enables the secure exchange of health information over the internet.” Basically a Federal push for standards, specs and protocols to allow electronic data to be exchanged.
  • HealthInternet – an open-market standards-based approach to enable the exchange and sharing of electronic health data, using existing Internet standard protocols and web technologies.

So here then a graphical view of the two approaches

NHIN

Health Internet

Federated Identity for Electronic Medical Records

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.

Federated Identities for Electronic Medical Records