The Identropy Blog

Subscribe by Email

Your email:

Current Articles | RSS Feed RSS Feed

Death by Clicking…


Last week, I co-presented during the NJ-DV HIMSS (Healthcare Information and Management Systems Society) Fall Conference 2011 in Atlantic City, alongside my friend François Bodhuin, Technology Director at South Jersey Healthcare.

Our session was titled: “The Importance of Planning an Identity Management Strategy in Healthcare - A Case Study at South Jersey Healthcare”, and in my opinion, not only was well-attended, but allowed the audience to interact and ask very interesting questions. I have uploaded our presentation and you can access it below.

During the session, François talked about SJHS’ past experiences with a single sign-on (SSO) initiative that did not achieve the goals expected, and how that experience helped them decide to take a different approach in a more recent go-around. One of theDeath by Clicking points that François made that really stuck with me was when he described the very realistic scenario of a “death by clicking”, which basically means that a physician could be spending way too much time clicking on a computer trying to access the various systems and records that needed to provide care to a patient, and that having to spend too much time launching applications, signing into them, and then locating the appropriate patient record, could literally mean life or death for the patient.

Somebody from the audience explained that this is particularly acute in emergency care, because ER physicians tend to not be employees of the hospitals where they provide their services, but rather are contracted staff, and rarely log in on the hospital’s internal applications. Consequently, they are frequent victims of account lockout issues, since there are likely to forget their password(s), or experience a high incidence of password expiration cases because they are often unable to either see or act on any password expiration warnings before it expires. In many cases, the same physician is affiliated to multiple ERs so the issue gets compounded. All of this combines to increase the possibility of “death by clicking”.

This was a very sobering point for me. When those of us in the identity world think about the implications, benefits and risks involved in achieving true SSO, we typically see SSO as a convenience that is nothing but the by-product of doing Identity and Access Management (IAM) correctly. Rarely do we think about it being a life or death issue (at least I never do).  What François pointed out made me realize that in some scenarios, SSO is critical and not just convenience.

As I internalized the implications of this realization, I still ended up concluding that SSO is a by-product of a properly implemented IAM infrastructure, but I did change a few assumptions for IAM Governance I had, specifically in the context of emergency care:

  1. Given the plethora of clinical and ancillary systems that are common in healthcare care. SSO, particularly ESSO for non-web applications, and strong authentication combined, offer a very appealing solution to deliver convenience while increasing security. This is not something you find very often in IT Security: higher security actually offering more convenience. In many cases in healthcare, many refer to the term “tap & go” as synonymous with users logging in with their badge and experiencing SSO into their applications. Therefore, given the high impact this capability will have for physicians, particularly in the ER room, healthcare organizations should consider bringing this forth in their IAM roadmaps.
  2. Achieving SSO should still be viewed as a by-product of a well-executed IAM strategy, and organizations should not bypass foundational steps in order to get to SSO. Prioritizing identity mapping and streamlining on-boarding and termination process is fundamental, and should be a precursor to SSO. Being sensitive to the end users desire for SSO, the IAM roadmap should specify a phased approach in which applications, and the backend identity repositories they use, are prioritized appropriately for being brought under governance. A phased approach will allow SSO to be delivered to a subset of the applications, and allow a segment of the user base to benefit earlier. This is in my opinion, what will be different than in other organizations where prioritization may be driven mainly by regulatory compliance or other drivers.
  3. If healthcare organizations are going to pursue a SSO initiative, then they should consider coupling it with a context management capability, such that the applications that a physician utilizes show the electronic record for the patient that the physician is attending to. This capability is gaining momentum in healthcare in part due to the emphasis that the CCOW (Clinical Context Object Workgroup) is giving to the definition of an industry standard for how context management should be achieved. The reason we believe this approach makes sense, despite the obvious added costs and complexity that it will add to the SSO initiative, is that ultimately this capability will have to be implemented anyway, to the  same stakeholders, applications and systems, and the two systems will have to be fairly integrated. So in the end, it is more efficient to pursue them both at the same time. This means of course, that additional discussions, use cases and priorities will need to be considered as part of the initiative, and given that context management has more to do with application information than with IAM, additional coordination will be needed with the SMEs and stakeholders that will design and architect the context management solution. We do not believe that context management is an IAM capability “yet”; hence it will need to be managed by another program, but coordinated in its initial implementation. For the IAM program manager, it will be important to understand how context management may impact SSO, for instance: how would SSO products integrate with context management products to provide a seamless user experience?
  4. Implicit in this phased approach is the fact that an effective password reset and account lockout mechanism, one that is actually user friendly, will need to be a priority. This will be imperative to ensure that users that lock out their accounts can easily recover. Otherwise, the value of SSO will be quickly diluted. And for those systems where SSO is not feasible or will be delivered in a later phase, password synchronization and a centralized password self-service capability will help balance convenience and ease the burden on the help desk.
  5. Lastly, and particularly due to the distributed nature of the ER physician staff (i.e. the same ER physician may work at different hospitals and be employed by a separate entity), we believe that healthcare organizations should consider federated identity management as an effective way to enable these physicians to be more productive in the ER. The idea being that rather than issuing yet more credentials to these physicians, the organization may consider “trusting” credentials issued to the physicians by their employer or primary facility. This will save considerable costs, particularly if authentication is done using two factors, since the authentication device may not need to be issued. It will also save time, since the physician will be familiar with her credentials, and will not need to unlock her account at the ER she happens to be working in at the time. These time savings will translate into more time spent providing care than trying to access applications and information, or worse yet, waiting on the phone for the help desk to reset the password. Evidently, the use cases for how this federated identity scenario will play need to be considered carefully, particularly:
  • Identity lifecycle processes - such as on-boarding, registration, authentication/sign-in and termination
  • Authentication strength - is it acceptable given the sensitivity of the data being accessed and in line with the healthcare organization’s policies?
  • The service availability of the identity provider (IdP) - which will be critical, as well as acceptable fallback mechanisms for cases in which federation is not available, say in the case of a disaster

Given our recent articles on identity in healthcare, I thought that this perspective would be quite relevant to share, and wanted to get your perspectives on it. I would love to hear your comments.


Great presentation and synopsis! I love the idea of a federated solution to the issue of the ER physician with multiple places they may be at. Are there any unique considerations to take into account, or can one of the corporate options available be used?
Posted @ Tuesday, September 27, 2011 11:07 AM by Heather Lasher
Thanks Heather. I believe that the technology aspects of identity federation will be where the risk and complexity is lowest. The maturity and adoption of federation standards today allows for this to be a relatively easy implementation. The real challenges will be in the areas of trust establishment: SLAs, reliability and availability, identity assurance, and whether federation links are established at the corporate level bilaterally, multilaterally (i.e. a federation network), or at the individual user level (unlikely in this context I think).
Posted @ Tuesday, September 27, 2011 7:06 PM by Frank Villavicencio
Post Comment
Website (optional)

Allowed tags: <a> link, <b> bold, <i> italics