Using SSO to Streamline Security and the Clinical Experience

April 2011

By Gregg Mohrmann
Principal, Aspen Advisors

The American Recovery and Reinvestment Act’s meaningful use incentives are driving an unprecedented level of investment in health information technology and accelerating many Electronic Medical Record (EMR) initiatives already underway. Healthcare executives are continually challenged with how to not only implement technology but how to drive adoption. One of the leading barriers to clinician adoption is the potential impact to efficiency, time management, and patient clinical service. With advancements in identity management tools / platforms, it is possible to reduce these barriers.

Identity management enables clinical staff to improve the speed and efficiency at which they access critical patient data, leading to increased productivity and better patient care. It simplifies access to patient data, removes the need for separate logon credentials for each system, facilitates user handoffs on shared workstations, and promotes rapid access to patient data resident in disparate applications. With increasing focus on the privacy and security of health data, identity management also provides a single audit source for user access, simplifying HIPAA auditing and reporting.

For these reasons, identity management has become a priority for many healthcare organizations. Yet, as beneficial as identity management can be, there is significant planning that must go into an implementation due to the deployment complexities faced in a diverse and complex hospital environment. The obstacles, technology trends, and best practice approaches to accelerate the process, reduce costs, and assure successful outcomes will be examined in this paper.

Definitions

Identity management has two components: 1) user context (often referred to as single sign-on) and context management, which will be discussed in this paper, and 2) user provisioning, which will be discussed in a Part II paper on identity management.

User Context and Single Sign-On

User context or single sign-on (SSO) is defined as the ability for a single user to utilize one username and password to access multiple applications. SSO provides the ability for system access to follow the user from system to system.

Patient Context Management

The second component that goes hand in hand with SSO is called patient context management, which enables the end user to find a patient and then go to another clinical application with the patient still selected (eliminating the need to reselect the patient), thus keeping that patient in context throughout the process.

Clinical Context Object Workgroup

Patient context management follows an industry standard called Clinical Context Object Workgroup (CCOW), a HL7 standard protocol designed to enable disparate applications to synchronize in real-time and at the user-interface level. CCOW is vendor independent and allows applications to present information at the desktop and/or portal level in a unified way. Vendors in the healthcare industry are quickly adopting the CCOW standard.

It is important to note that although SSO (user context) is much easier and less challenging to implement than patient context, both of these components are extremely valuable and critical to preparing a healthcare organization for the realities of a paperless environment.

Benefits and Importance of SSO and Patient Context

If implemented correctly, SSO and patient context drive many benefits to healthcare organizations including clinician satisfaction, efficiency gains, and compliance improvement. Each of these categories provides specific benefits that establish the business case for SSO and patient context deployment.

Increase in Staff Satisfaction

In many healthcare organizations, clinicians use multiple passwords to get into different systems. Often, they forget these passwords or have them written on pieces of paper which may get misplaced or lost. As a result, they have to call the help desk to get their password(s) reset, which impacts their perceptions of the supporting technology and their levels of efficiency. Having one password that can be used to access multiple applications improves staff satisfaction and efficiency.

Security Administration Efficiency

Forgotten passwords cause IS security administrators and the IS help desk to spend a lot of time resetting passwords. When there is only one password to reset for multiple applications, a lot of time can be saved with password resets alone. Additionally, calls to the help desk for password resets are reduced.

HIPAA Audit Capability

Lost or misplaced passwords written on pieces of paper can cause privacy and security issues. Also, it is extremely difficult in today’s complex IS environments in hospitals to audit various systems to determine where users have “traveled” in the systems they have access to. SSO and patient context solutions provide the organization with the ability to have a clear view into which user saw which patient record and when. This makes the auditing process very efficient and ensures effective security processes and adherence to governmental regulations.

Improved Workflow Efficiency

SSO and patient context provides the ability to view patient information across multiple applications rather than requiring a user to log into and out of several systems and then search for the patient they are taking care of. With SSO and patient context this process of logging in and searching is two steps at most and enables clinicians to focus on caring for the patient, rather than spend time searching for patient information.

Exploring Different SSO and Patient Context Approach Options

There are several ways that an organization can approach implementing SSO and patient context. The approach an organization takes depends on their tolerance for risk, ability to rapidly introduce change, and need to deploy identity management. There are three main implementation approaches that an organization has at its disposal:

a big bang approach in which the organization would skip a pilot and go with deployment at a major facility with both SSO and patient context;
a modified big bang approach in which the organization would skip a pilot and go with deployment at a major facility with only SSO and then layer in patient context at a later time; and
a conservative approach in which the organization would conduct a pilot at a small facility in one or two units with SSO and patient context deployed for a few key systems and then proceed to deploy to the remainder of the facilities after addressing issues identified in the pilot.

Big Bang Approach

An organization with time constraints due to increasing staff dissatisfaction, pressing EMR implementation needs around clinical workflow, and/or delayed single sign-on initiatives might lean towards a big bang approach to SSO and patient context. This approach requires an extremely solid delivery team, structured program management, and a solid testing approach. A limited set of three applications should be included in the scope of the initial deployment. Typically, there is a six to nine month implementation timeframe, but with an aggressive approach, implementation can be completed in five months. Due to the complexities of implementing a robust identity management solution, it is often not recommended that an organization pursue this approach since it can lead to unforeseen problems that would have been caught through a more conservative approach.

Modified Big Bang Approach

It is much more reasonable for an organization to pursue SSO without patient context in a modified big bang approach. This still doesn’t allow time for a controlled pilot. However, with a very strong delivery team inclusive of a structured project management process, an experienced project manager (PM), and solid plans for implementation, communication, testing, training, and activation, this strategy can work. In a mid-sized hospital system (three to five hospitals), the rollout should reasonably take four to six months. Again, it is also important to limit the number of applications that are included in the initial rollout scope. Doing too much too fast can cause technological issues and potential user dissatisfaction.

Conservative Approach

For those organizations not pressed for more streamlined security, less IT spend on security administration, and/or better workflow to support a new EMR, a more conservative approach should be taken. It is less risky, allows the organization to grow with the change in workflow and system access, and enables more testing and piloting to take place to reduce potential issues.

A conservative approach considers a handful of critical applications that the users frequently use in their day-to-day workflow. Additionally, the plan includes a well thought out pilot of one to two hospital units in the most stable facility in the health system. After the pilot, a lessons learned review is conducted, and then the remaining facility rollouts are planned. By completing a pilot and then carefully planning each facility, an organization can expect about a nine month rollout that requires fewer resources, is less risky, and helps the transition of the technology change.

For any of the above approaches, complexity will increase if any one of the following factors occurs: more applications are deployed, more facilities are deployed, or shorter deployment timeframes are needed.

Key Implementation Considerations

There are some very important deployment considerations which should be taken into account while planning the implementation of SSO and patient context management. These include considerations around the technology, end users, resources, deployment and activation, and ongoing support.

Technology Considerations

The technology considerations include CCOW compliance, high availability, session timeouts, and centralized versus decentralized management.

CCOW Compliance

Most vendors state that they are CCOW compliant. This is industry terminology for “My application can support user and patient context management”. What vendors may fail to reveal is that many applications don’t do a good job at being CCOW compliant by loosely adhering to the standards and making the configuration of their application for CCOW capability very cumbersome and error prone. Additionally, they often interpret CCOW compliance in different ways than would typically occur in end user workflow in a typical hospital scenario or configure their application in such a way that it won’t work in conjunction with other CCOW applications typically used by end users (e.g., ED systems, CIS systems, etc.) – thus defeating the purpose of CCOW in the first place.

For non-clinical applications (e.g., general financial applications), CCOW compliance is not relevant since patient context management is not needed. Business type applications like ERP, General Ledger, Time and Attendance, and Human Resources systems are often not CCOW compliant. However, these applications will often be Lightweight Directory Access Protocol (LDAP) compliant, which means they will integrate with the active directory system. Some of these business applications will also be SSO compliant and will have user context enablement.

For clinical applications, CCOW compliance is important to help streamline integration with the SSO/patient context platform that the organization has chosen.

If a vendor is not CCOW or LDAP compliant or has some other compliance with SSO technology, a “bridge” between that application and the SSO/patient context platform will likely need to be built. Bridges take more time to build, are customized, simulate user clicks through a sign in and patient search process, and do have to be updated each time a target application is upgraded.

As a result, the following questions should be asked to the vendor:

Is your application CCOW compliant?
If so, what are the specifications on how this compliance is achieved?
How easy is CCOW to enable (i.e., do you need to be a technological wizard?)
If you are not CCOW compliant, are you LDAP compliant?

High Availability

Additionally, the IS team will need to examine the infrastructure that is required to run the SSO and patient context solution. The infrastructure must be highly available with a quick turnaround disaster recovery (DR) solution that can be put into place in 15 to 30 minutes. Because SSO/patient context solutions control the organization’s access to its systems once you turn them on, this solution should be considered a Tier I application with quick turnaround on problems and operating on an extremely secure and reliable technology platform.

Session Timeouts

Last, but not least, in terms of technology and configuration considerations, it is important that the concept of system and application timeouts is discussed. The SSO/patient context solution will have defaults as to how long an end user’s session will remain active (e.g., when the user will be logged out and when the screen saver will come on). Additionally, each application enabled with SSO/patient context should have the same timeout. The industry standard recommended by security vendors is that the screen locks and the screen saver goes on between eight to 10 minutes, and after 30 minutes, the user is logged off of SSO/patient context. This standard is in place to prevent HIPAA security breaches and should be adhered to unless there is some compelling reason not to adhere to that standard such as with OR workstations inside an operating room suite.

However, every organization’s needs are different, and it is very important for this discussion to take place with the IS security team and the hospital users to ensure the right timeouts are put in place.

Central vs. Decentralized System Management

When buying an identity management solution, it’s important to ask the vendor if the application and system can be centrally managed. A centrally managed system and application allows the IS department and staff to control all the users, roles, and configuration to all the facilities and desktops remotely without having to push any files or configuration onto each desktop/workstation in the hospital environment.

There are systems out in the marketplace that are fairly well known but which require major administration to each and every desktop/PC. Additionally, each PC would need some individual configuration pushed out or installed whenever a change to the identity management system is made. This is extremely time consuming, inefficient, and error prone, as well as hard to test and monitor.

The best approach is to select from among only centrally managed identity management systems; decentralized systems will have increased administration costs, issues, and time investment required. This aspect often overshadows the benefits of a full-fledged best of breed system.

End User Considerations

Identity management is not a back office type of technology that doesn’t require hospital staff involvement. It’s extremely important to consider how to engage the end users.

The three areas where end users should be included and their feedback incorporated into the system design are: 1) understanding application workflow and how users utilize the applications to do their jobs, 2) ensuring that the end users participate in user acceptance testing, and 3) having a viable training approach to ensure quick and effective user adoption.

Workflow Design

Clinicians will use applications differently based on their organizational role. Applications accessed by the various user types and the associated workflow must be clearly defined for each user role. This should be kept fairly straightforward. For instance, you might define a role called Hospital Staff that includes everyone in the hospital with the exception of physicians and have a separate Physician role for the physicians. This is very easy to administer, train on, and test.

Once the various roles are defined, it’s important to work with the end users to determine what applications need to be enabled with SSO/patient context in that particular role and what the flow of those applications is (e.g., where do I spent most of my time and from which application do I jump to during the day and why). For instance, an ED nurse will primarily use the ED system or module as and may only go to the ancillary systems occasionally, whereas a pharmacy technician may never go into the main EMR or CIS and just stay in the pharmacy system or module, occasionally going into another business system such as an ERP to order materials. Physicians typically like to stay within some type of portal structure where all their applications are in one place and SSO enabled.

End User Testing

End user testing is often overlooked because the application seems overly simple. However, it is critical that the IS team and end users test the design for each role that was created with a valid number of test scripts. Even physicians should be part of the test.

Training

Copious amounts of training are not required, but some training is necessary to clearly articulate the change in user workflow that will occur. The best way to train for this type of implementation is through a 10 to 15 minute web-based training, easily accessible and simple to use. Additionally, tipsheets should be handed out and placed on the intranet as well to supplement the training and help refresh those who either didn’t take the training or forgot the material.

Resource Considerations

When planning an SSO/patient context identity management project, the implementation team should be carefully considered. This is to ensure that the organization can effectively implement the solution in the short term while preparing to support the solution in the long term without significant reliance on the product vendor.

Some recommendations for team structures include:

Project Manager - It is essential that the project is led by a project manager with SSO/patient context experience. Because of the complexities of this type of implementation, it is not enough to have a PM who just knows how to manage a project.
Server Engineer – If the vendor product is not centrally managed, you’ll also want to have a skilled server engineer setup the highly available environment and create and then push out configuration updates to the PCs and laptops in the environment.
System Administrator - A system administrator is important for understanding and maintaining the product configuration within the system based on system design and vendor recommendations as this requires in depth product knowledge. The system administrator would also create bridges to applications that are not CCOW compliant. The vendor usually has their own bridge technology, but the system administrator will need to know how to program in VB, C++, or the like to ensure that the bridges are appropriately setup.
Security Lead - Someone from the security team should be involved to handle user access since this person will need to be intricately involved in the planning, design, rollout, and support of the product. The security team will support the user setup after the implementation is done, so they need to understand how it works. The security lead should cross train the other security team members.
Product Vendor Subject Matter Expert - A technical expert from the product vendor should be involved during all phases of the work. The vendor leaves after implementation, and SSO/patient context products are such that you’ll want vendor expertise on site and highly available during the implementation phases, so that the vendor can teach and assist the IS staff at-the-elbow during the implementation. This individual from the vendor should not be remote, or it will adversely affect the implementation.
Desktop Administrator – Depending on whether the product is centrally managed, you may need someone from the desktop team since they will most likely have some part to play in maintaining the proper configurations at the desktop level.
Application Analysts - It is extremely important that the appropriate application analysts are available as needed to work with the SSO/patient context team. Their role will be to help work with each vendor for the applications selected for inclusion in the SSO / patient context deployment to help configure and support the CCOW requirements.

Deployment and Activation Considerations

It’s crucial to consider the activation needs around the SSO/patient context deployment. It is often assumed that the concept of signing into all the affected systems with one password is a simple concept and doesn’t require a lot of support. That is, however, not the case.

First, a lot of users share passwords to different systems regardless of whether the organization has policies against this or not. Since there are many different systems with different passwords, users may borrow other passwords rather than calling the help desk to get their passwords reset.

Second, the look and feel of SSO/patient context requires some getting used to but this is easy to grasp with some at-the-elbow support.

Third, it’s important to remember that since the entire desktop is now locked down by SSO, f for some reason end users didn’t get their new SSO passwords, lost them already, and/or have trouble logging in, they will need immediate support or their ability to perform patient care will be hampered.

Lastly, the actual activation is dependent on if the vendor’s product is centrally managed. If the product is not centrally managed, you should have your desktop team perform hands-on implementation of each PC by hospital unit followed right after by the go live support team to perform at-the-elbow support and guidance. If the vendor product is centrally managed, you will have to figure out how to push the configuration to certain machines by unit, so you can ensure your go live support team will be ready for each hospital user when they get the new look and feel of the desktop.

It is essential that the go live support team understands the system, has tipsheets that can be handed out to all the users, is centrally organized through an onsite command center, and includes onsite support from the vendor as well as the security administration team, so that any login issues can be immediately corrected. Security will be the single biggest go live support ticket item for an SSO/patient context implementation, so it is essential to have security team members onsite.

To keep your go live support team numbers down, the project team should plan for the rollout by hospital unit. Start in the morning with three units and provide support for the next three shifts. The next day, move to the next three units and support them. On each successive day, have the support team rotate through the units from the previous days to ensure any end users who may have not been working those days can access the system with no problems.

Remember that support for an SSO/patient context solution should be 24x7 and include the weekend for the staff who only works weekends. The bigger the facility, the more days of support you’ll need since there are more units.

Another quick tip is that after the team enables PCs in a particular hospital unit, they should mark the PC with a sticker that states “SSO Enabled” since not all the PCs in the hospital will have been SSO enabled. This helps direct floating staff on whether they need to use their new SSO password or not.

Ongoing Support

It’s important to consider the ongoing support requirements for the operational teams that will support the SSO/patient context solution. There are certain key items which have to be considered, reviewed, documented, and trained before the operational handoff can happen.

First, clear roles and responsibilities should be defined. This will be used by each of the operational managers to ensure their staffing and on call schedule is appropriate and by the help desk to categorize and assign the support tickets.

Second, the system configuration and infrastructure needs to be well documented and stored in a readily accessible place that one member of the operations team keeps updated, so that is does not go out of date. This includes the server layout, the design configuration, the version number, system roles and how they are setup, and each application’s CCOW and bridge specifications.

Third, there should be a troubleshooting guide developed and knowledge base documented and transitioned to all the operational teams inclusive of the help desk. This document should be loaded into the current knowledge base repository for the help desk and also easily accessible by all the operational teams.

Fourth, the production change control process should be firmly documented if it isn’t already for the system or enterprise including the downtime and maintenance windows, so that all of the support teams and the end user understand the support parameters.

Fifth, downtime procedures should be documented, reviewed, and updated with the end users. If SSO goes down, there will be no way for them to access their critical applications. Hopefully, due to the robust setup of the infrastructure, this will not happen. However, the organization needs to be prepared to distribute passwords to key systems and go to paper if necessary.

Remember: none of the end users will know their passwords to the systems since they go through SSO to access those systems in the new environment. It is not only the downtime procedures in this case but the staffing in the help desk and security that will need to be carefully considered since the impact in IS will most likely be felt the most by those two teams.

Planning for the SSO/Patient Context Future

An SSO/patient context identity management implementation typically doesn’t end after the first go live. It is essential for an organization to properly plan out their SSO/patient context roadmap and prioritize both clinical and business applications using the following guidelines:

Number of users - the more users, the more value will be seen by the organization by enabling those applications;
Workflow criticality - if an application sits in the middle of a critical clinical workflow, then that application may be high on the list to be enabled since patient context and SSO will help make that workflow more efficient; and
The difficulty of enabling the application - the more difficult applications to enable should be weighed against number of users and workflow considerations.

The organization will need to create, socialize, and publish a multi-year roadmap for enabling the organization with SSO/patient context. If the organization does not do this, more and more application owners and end users will start requesting that their applications be enabled. By planning the roadmap, putting a process in place for adding new applications as time goes on, and communicating it, you’ll be setting the agenda in alignment with your organization’s business objectives and your governance processes.

Case Study: SSO Deployment a Success

For a detailed example of an SSO deployment at a multi-hospital system, view the case study “Virtua Implements Single Sign-On to improve Clinical System Access, Satisfaction and Security”.

Conclusion

If your organization is becoming more digitized especially in the clinical areas, has many users with more than one logon to the systems needed to do their jobs, and desires better auditing capability, then you should strongly consider moving towards implementing both SSO and patient context. The technology is fairly mature, and the end users will quickly adapt when they discover all of the advantages of an SSO/patient context solution. This type of implementation is a very visible and viable solution that quickly shows results.

SSO and patient context are only one component to an identity management solution. User access provisioning is another critical and valuable identity management component that organizations serious about identity management should undertake. In Part II of this two part series, we will look at how user provisioning is implemented with best practices in mind, its benefits, challenges, and important considerations.